Cadrer un projet data : du besoin métier au premier indicateur
Cadrer un projet data en partant d'une décision à prendre : question métier, propriétaires des données, indicateurs définis une seule fois, pièges à éviter.
Beaucoup de projets data démarrent par une source : « on a des données dans la GMAO, faisons quelque chose avec ». Ils finissent souvent en tableau de bord que personne ne consulte. Le cadrage qui tient dans la durée part de l'autre bout : une décision à prendre, une question métier claire, et un premier indicateur défini une seule fois pour toute l'entreprise.
Partir d'une décision, pas d'une source
Un projet data existe pour aider quelqu'un à décider mieux ou plus vite. Avant d'ouvrir un outil, il faut nommer cette décision. Qui la prend ? À quelle fréquence ? Avec quelles informations aujourd'hui ?
Dans un atelier de maintenance, la décision peut être : « quels équipements planifier en révision ce mois-ci ». En supply, ce sera : « faut-il relancer ce fournisseur avant la rupture ». En finance, « le reste à faire de ce projet justifie-t-il un ajustement de budget ». Chaque décision appelle une question précise, et chaque question appelle une poignée de données. Pas l'inverse.
Si personne ne peut dire quelle décision changera grâce au projet, le projet n'est pas mûr. On peut explorer, mais alors il faut le dire et borner l'exploration dans le temps.
Formuler la question métier
Une question métier bien posée tient en une phrase et contient un sujet, une mesure, une période et un périmètre. « Quel est le taux de disponibilité des lignes de la zone Nord, par semaine, sur les trois derniers mois » est une question. « Analyser la performance de l'atelier » n'en est pas une.
Ce travail se fait avec les métiers, pas pour eux. Un atelier avec le responsable de maintenance, un planificateur et un contrôleur de gestion suffit souvent pour passer d'une demande floue à trois questions ordonnées par priorité. La première deviendra le premier indicateur.
C'est aussi le moment de repérer les mots qui n'ont pas la même définition d'un service à l'autre. « Disponibilité », « retard », « coût complet » : chacun croit savoir de quoi il parle, et chacun a une formule différente dans son fichier. Ces écarts se règlent maintenant, sur papier, plutôt que dans six mois devant deux tableaux de bord qui se contredisent.
Identifier les données et leurs propriétaires
Une fois la question posée, on liste les données nécessaires. Pour chaque donnée, trois informations : où elle se trouve (ERP, GMAO, fichier de bureau d'études, capteur), qui en est le propriétaire métier, et quelle est sa qualité connue.
Le propriétaire n'est pas l'informaticien qui administre le système. C'est la personne métier capable de dire ce que vaut la donnée et de trancher quand elle est ambiguë. Sans lui, l'indicateur n'a pas de garant.
C'est ici que la gouvernance entre en jeu, et c'est aussi pourquoi elle rend l'intelligence artificielle possible. Un assistant fondé sur un LLM (grand modèle de langage) ou un système RAG (génération augmentée par recherche) ne vaut que par les données qu'on lui donne à lire. Si personne ne sait qui possède la donnée, si les données personnelles ne sont pas repérées, si les règles d'accès ne sont pas écrites, on ne peut pas dire oui à l'IA. Avec ces éléments en place, on peut. La gouvernance ne freine pas, elle autorise.
Concrètement, dès le cadrage : repérer les données personnelles au sens du RGPD (règlement général sur la protection des données), noter qui y accède, et vérifier que la finalité du projet est cohérente avec celle de la collecte. Quelques lignes dans le document de cadrage suffisent.
Définir les indicateurs une seule fois
Le piège le plus fréquent : chaque équipe recalcule ses indicateurs dans son outil. Les chiffres divergent, les réunions tournent à la réconciliation.
La réponse est structurelle. Un indicateur se définit une seule fois, dans une couche sémantique partagée, avec une formule, une unité, une granularité, une source et un propriétaire. Les outils de visualisation viennent lire cette définition ; ils ne la réinventent pas. Cette couche vit dans les modèles dbt ou dans un modèle sémantique exposé aux outils de reporting. Le principe compte plus que l'outil : une définition, un endroit, un responsable.
Cette couche s'appuie sur un modèle de données d'entreprise. Pas un schéma de deux cents tables dessiné pendant un an, mais un noyau : les objets que tout le monde manipule (équipement, ordre de travail, projet, centre de coût, salarié) avec leurs clés et leurs relations. Le premier indicateur en utilise deux ou trois ; les suivants en ajouteront.
Périmètre minimal et environnements
Le premier livrable doit être petit et réel. Un indicateur, un périmètre (un site, une ligne, un centre de coût), un rafraîchissement quotidien ou hebdomadaire, un utilisateur nommé qui l'attend. Tout ce qui ne sert pas cette première décision sort du périmètre et va dans une liste d'attente visible.
Dès ce premier lot, on travaille avec trois environnements : développement, recette, production. La recette est l'endroit où le métier valide les chiffres avant qu'ils ne fassent foi. Sauter cette étape se paie toujours : un indicateur faux mis en production perd la confiance de ses lecteurs, et cette confiance se regagne lentement.
Critères de succès
Le cadrage fixe aussi comment on saura que le projet a réussi. Sans inventer de chiffre cible que personne ne saurait justifier, on peut écrire des critères observables :
- l'indicateur est consulté par la personne qui prend la décision, à la fréquence prévue ;
- deux services regardent le même chiffre et n'ont plus de réunion de réconciliation ;
- le propriétaire de la donnée sait expliquer un écart quand on le lui demande ;
- l'indicateur est documenté et son historique est rejouable.
Ces critères valent mieux qu'un retour sur investissement calculé avant d'avoir livré quoi que ce soit.
Les pièges à éviter
Le projet outil. Le projet est lancé parce qu'une licence a été achetée. L'outil devient la finalité. Symptôme : la première réunion parle de connecteurs et jamais de décision.
Le périmètre qui gonfle. Chaque atelier ajoute une demande, et le premier lot n'arrive jamais. Antidote : une liste d'attente publique et un sponsor qui tranche.
L'absence de sponsor. Sans responsable métier qui porte le projet, les arbitrages entre services n'ont pas de lieu. Le projet s'enlise poliment.
La donnée personnelle découverte tard. On s'aperçoit en production que l'indicateur expose des données de salariés sans base légale. Repérer ce point au cadrage coûte une heure ; le corriger après coûte le projet.
- Part d'une source ou d'une technologie
- Périmètre qui gonfle à chaque réunion
- Succès mesuré à la livraison
- Sponsor absent ou trop loin du terrain
- Part d'une décision à prendre
- Périmètre minimal, extensions décidées ensuite
- Succès mesuré à la décision prise
- Sponsor métier nommé et disponible
Le second coûte moins cher, livre plus tôt, et prépare le terrain aux usages suivants, y compris l'IA.
À retenir
- Un projet data commence par une décision à prendre, jamais par une source de données.
- La question métier se formule en une phrase : sujet, mesure, période, périmètre.
- Chaque donnée a un propriétaire métier ; sans lui, l'indicateur n'a pas de garant.
- Un indicateur se définit une seule fois, dans une couche sémantique partagée, sur un modèle de données d'entreprise.
- Le premier lot est petit, validé en recette par le métier, et attendu par une personne nommée.
- La gouvernance posée au cadrage est ce qui permettra ensuite de dire oui à l'IA sur ces mêmes données.
Checklist
- La décision à prendre est écrite, avec son décideur et sa fréquence.
- La question métier tient en une phrase validée par les métiers.
- Chaque donnée nécessaire a un système source et un propriétaire nommé.
- Les données personnelles sont repérées et la finalité est cohérente avec le RGPD.
- Le premier indicateur a une définition écrite, unique et documentée.
- Le périmètre du premier lot est réduit et la liste d'attente est visible.
- Les environnements de développement, recette et production sont en place.
- Un sponsor métier est identifié et arbitre les demandes.