

- Description
- Une longue-vue à pièces face à la vue d'ensemble d'une ville : cadrer ce que l'on veut regarder
- Source
- Cbaile19 · page d’origine
- Licence
- CC0 Domaine public
Cadrage, valeur et cas d'usage
Un projet data coûte rarement cher à construire et presque toujours cher à entretenir : chaque rapport livré devient une promesse de maintenance, de rafraîchissement et de support. Livrer «…
Niveau : 🟢→🔴 · Code thème : VAL
Pourquoi ce thème#
Un projet data coûte rarement cher à construire et presque toujours cher à entretenir : chaque rapport livré devient une promesse de maintenance, de rafraîchissement et de support. Livrer « le rapport demandé » sans avoir identifié la décision qu'il éclaire produit le syndrome du cimetière de tableaux de bord : des dizaines de pages, quelques-unes utilisées, aucune reliée à un gain. Le coût de l'ignorer n'apparaît pas à la livraison, mais deux ans plus tard, quand l'équipe ne peut plus rien arrêter ni rien prioriser. Ce thème porte sur la qualité du besoin et sur la preuve du bénéfice, avant et après le développement. La conduite générique du cadrage est traitée dans la matrice PI, cadrage et vision ; ici, on traite ce que la donnée change : un besoin d'indicateur est souvent flou, et sa valeur dépend de l'usage, pas de la livraison.
Ce que mesure le thème#
- Axe : du « livrer des rapports » au « arbitrer un portefeuille de produits de données sur leur valeur ».
- Indicateur clé : part des produits de données rattachés à une décision nommée, avec un bénéfice mesuré après livraison.
- Unité : pourcentage de produits du portefeuille ayant (a) un décideur, (b) un critère de succès, (c) une mesure d'usage ou d'effet.
Les cinq niveaux#
| Niveau | Nom court | Promesse | Indicateur type (ordre de grandeur) |
|---|---|---|---|
| 1 | Commande | Le demandeur obtient les rapports qu'il a décrits, sans que l'on sache à quoi ils servent. | < 20 % des produits reliés à une décision |
| 2 | Question | Chaque livrable répond à une question métier écrite, posée par un demandeur identifié. | ≥ 60 % des demandes avec question et demandeur |
| 3 | Hypothèse | Le sponsor sait quel bénéfice est attendu, comment on le reconnaîtra et ce qui n'est pas dans le périmètre. | ≥ 80 % des projets avec critère de succès signé |
| 4 | Bénéfice | Le bénéfice est mesuré après livraison, et les écarts à l'hypothèse alimentent les décisions suivantes. | ≥ 70 % des produits revus à 3–6 mois sur usage et effet |
| 5 | Portefeuille | L'organisation arbitre, finance et retire ses produits de données selon leur valeur démontrée. | Retraits annuels documentés ; > 90 % du portefeuille évalué |
Jalons par niveau#
| ID | Jalon | Preuve vérifiable |
|---|---|---|
| PD-VAL-1.1 | Les demandes de données arrivent dans un lieu unique (backlog, tickets). | Un backlog existe ; on y retrouve les demandes des trois derniers mois. |
| PD-VAL-1.2 | Un demandeur nommé existe pour chaque rapport livré. | Champ « demandeur » renseigné sur ≥ 80 % des éléments livrés. |
| PD-VAL-1.3 | La livraison est tracée (date, version, destinataires). | Historique de livraisons consultable. |
| PD-VAL-1.4 | Le périmètre de chaque livraison est écrit, même brièvement. | Description ou note de livraison pour chaque version. |
| PD-VAL-2.1 | Chaque demande est reformulée en question métier (« quelles références sortent du linéaire ? »). | Élément du backlog avec champ « question » ; reformulation relue avec le demandeur. |
| PD-VAL-2.2 | Le décideur concerné (celui qui agit sur le chiffre) est distinct du demandeur et nommé. | Fiche de cadrage avec « qui décide, de quoi ». |
| PD-VAL-2.3 | Les indicateurs sont définis avant le développement (formule, périmètre, granularité, fréquence). | Fiche d'indicateur validée avant la première ligne de code. |
| PD-VAL-2.4 | Le besoin est confronté aux produits existants avant de créer (réutilisation). | Trace de la recherche de doublon dans la fiche de cadrage. |
| PD-VAL-3.1 | Chaque projet porte une hypothèse de valeur (« si nous savons X à J+1, nous réduisons Y de Z »). | Hypothèse écrite et validée par le sponsor. |
| PD-VAL-3.2 | Un critère de succès mesurable est signé (usage, délai, écart, coût évité). | Critère présent dans la charte, avec méthode de mesure. |
| PD-VAL-3.3 | La donnée disponible est vérifiée avant l'engagement (faisabilité : sources, qualité, historique). | Note de faisabilité ou preuve de concept datée, avec constats sur la qualité. |
| PD-VAL-3.4 | Le « hors périmètre » et l'impact RGPD sont explicitement écrits. | Section « hors périmètre » ; renvoi à l'analyse du thème SEC. |
| PD-VAL-4.1 | Une revue post-livraison à 3–6 mois compare l'hypothèse au constat. | Compte rendu de revue de valeur par produit. |
| PD-VAL-4.2 | L'usage réel est mesuré (consultations, utilisateurs distincts, requêtes). | Tableau d'usage alimenté automatiquement. |
| PD-VAL-4.3 | Les produits sans usage sont signalés et traités (maintien justifié ou retrait). | Liste des produits < seuil d'usage, avec décision. |
| PD-VAL-4.4 | Les écarts de valeur modifient le backlog suivant. | Éléments du backlog issus d'une revue de valeur. |
| PD-VAL-5.1 | Un portefeuille unique classe les produits par valeur et coût (voir FIN). | Vue de portefeuille revue au moins deux fois par an. |
| PD-VAL-5.2 | Des produits sont retirés chaque année, avec archivage et préavis. | Journal de retraits avec date, motif, destinataires prévenus. |
| PD-VAL-5.3 | Les cas d'usage sont évalués sur des critères communs (valeur, faisabilité, risque, coût) avant tout financement. | Grille d'évaluation appliquée à toutes les nouvelles demandes. |
| PD-VAL-5.4 | Les bénéfices sont reconnus par la direction financière ou le métier, pas auto-déclarés par l'équipe data. | Validation écrite d'un tiers métier sur au moins trois produits. |
Lecture détaillée par niveau#
🟢 Niveau 1 — Commande#
- Signes observables : la demande est un mail (« peux-tu me sortir les ventes par client ? ») ; le même rapport est redemandé sous trois formes ; personne ne sait qui l'ouvre.
- Ce qu'on gagne : réactivité apparente, relation de service.
- Ce que ça ne garantit pas : que le chiffre serve ; que deux demandeurs mettent le même sens derrière « ventes ».
- Difficulté : 1/5 · Effort : 1/5.
🟢 Niveau 2 — Question#
- Signes : chaque élément du backlog a une question en français courant ; le décideur est identifié ; la fiche d'indicateur précède le code.
- Ce qu'on gagne : moins de retours en recette (« ce n'est pas ce que je voulais ») et moins de doublons.
- Ne garantit pas : que le chiffre change réellement une décision ; une question peut être légitime et sans effet.
- Difficulté : 2/5 · Effort : 2/5.
🟡 Niveau 3 — Hypothèse#
- Signes : la charte contient une hypothèse chiffrée même grossière ; la faisabilité des données est vérifiée avant l'engagement ; le sponsor sait dire non à une extension de périmètre.
- Ce qu'on gagne : on évite les projets « beaux sur le papier, impossibles sur la donnée » ; le succès est discutable.
- Ne garantit pas : que l'hypothèse se vérifie ; que la mesure promise sera faite.
- Difficulté : 3/5 · Effort : 3/5.
Sur un datamart alimenté par une application de force de vente, la demande « un rapport des relevés de linéaire par enseigne » devient : « le responsable de catégorie veut savoir, chaque lundi, quelles enseignes ont perdu plus de 2 points de linéaire pour négocier avant la fin du mois ». L'hypothèse de valeur : une négociation ciblée par semaine. Le critère de succès : rapport consulté par les 12 responsables sous 3 mois, et au moins 3 négociations citant le chiffre. La faisabilité révèle que 30 % des relevés n'ont pas d'enseigne : sans ce constat avant engagement, le projet aurait « réussi » techniquement et échoué sur l'usage.
🟡 Niveau 4 — Bénéfice#
- Signes : une revue à 3–6 mois existe ; l'usage est mesuré sans effort (journaux de consultation) ; des produits sont mis en sursis.
- Ce qu'on gagne : la preuve que la donnée sert ; un argument factuel au moment des arbitrages budgétaires.
- Ne garantit pas : l'attribution causale (un usage élevé n'est pas un effet) ; la qualité des chiffres consultés.
- Difficulté : 4/5 · Effort : 3/5.
🔴 Niveau 5 — Portefeuille#
- Signes : un comité arbitre ; des produits sont retirés sans drame ; le métier cofinance ; la valeur déclarée est contresignée.
- Ce qu'on gagne : une dette de produits maîtrisée ; des ressources redéployées vers ce qui compte.
- Ne garantit pas : l'exactitude du calcul de valeur, souvent fragile ; le risque est de remplacer le jugement par un score.
- Difficulté : 5/5 · Effort : 4/5.
Atteinte partielle et notation#
On note chaque jalon 0 / 0,5 / 1 selon la règle commune du README. Pratique : évaluez sur un échantillon de cinq produits récents, pas sur « ce que l'équipe fait en général ». Un jalon vaut 1 si les cinq le satisfont, 0,5 si deux à quatre, 0 sinon.
Un « 5 partiel » : un portefeuille où les 20 produits les plus coûteux sont évalués sur la valeur (PD-VAL-5.1), où deux produits ont été retirés l'an dernier (5.2), mais où les bénéfices restent auto-déclarés (5.4 à 0,5) et la grille commune n'est pas encore appliquée aux petites demandes (5.3 à 0,5). Score plausible : 4,0 + 0,75 × 0,99 ≈ 4,7 si les niveaux 1–4 sont acquis.
Le jalon PD-VAL-4.2 (usage mesuré) se détourne en « nombre de vues » : on gonfle l'usage en envoyant le lien à tout le monde. Symptôme : usage haut, décisions inchangées. Remède : mesurer des utilisateurs distincts récurrents et croiser avec les décisions citées.
Passer au niveau suivant#
Moyens possibles (facultatifs) — ce sont des leviers, pas des exigences ; la promesse seule définit le niveau.
| Passage | Leviers possibles |
|---|---|
| 1 → 2 | Un gabarit de demande (« En tant que… je veux savoir… pour décider… ») ; refuser toute demande sans question ni décideur. |
| 2 → 3 | Un atelier de cadrage d'une heure ; la vérification de faisabilité par une requête de profilage sur la source avant le chiffrage (voir QUA). |
| 3 → 4 | Journaliser les consultations dès le premier jour ; planifier la revue de valeur à la signature de la charte. |
| 4 → 5 | Un comité de portefeuille semestriel ; une règle de péremption (un produit non consulté 6 mois est archivé sauf justification). |
Pièges transverses : (1) Faux positif — une charte remplie mécaniquement (« gain : amélioration de la décision ») ; exigez un chiffre, même approximatif. (2) Goodhart — viser un « nombre de produits évalués » pousse à évaluer des produits sans importance. (3) Valeur invisible — certains produits préviennent un risque (conformité) : leur valeur est un coût évité, à documenter comme tel.
L'IA aide à reformuler une demande floue en question métier, à proposer des critères de succès et à résumer un journal d'usage. Elle ne connaît pas la décision réelle ni la tolérance au risque du sponsor : toute valeur chiffrée proposée est une hypothèse à faire valider. Ne lui confiez pas d'extraits de données clients.
Voir aussi#
- Même matrice : 02 Gouvernance · 11 Pilotage coût et valeur · 09 Adoption · README de la matrice
- Autres matrices : PI — cadrage et vision · PI — budget, valeur et bénéfices · BI — modèle sémantique
- Pratique : méthodes spécifiques data · Scrum et data · checklist de projet reporting · fondamentaux
- Glossaire · Notation
✻ Rédigé par Claude Sonnet 5.5