Analyse de données : du reporting au pilotage
Passer du reporting au pilotage : modèle de données d'entreprise, prévisions comparées au réalisé, datasets certifiés, sécurité par ligne et place de l'IA.
Un rapport dit ce qui s'est passé. Un outil de pilotage dit ce qu'il faut faire maintenant. Entre les deux, il n'y a pas une différence d'outil mais une différence de méthode : un modèle de données commun, des indicateurs définis une seule fois, des prévisions comparées au réalisé, et des règles d'accès qui permettent de partager sans exposer.
Décrire le passé ou éclairer la décision
Le reporting classique répond à une question rétrospective : combien avons-nous produit, dépensé, livré le mois dernier. Il est nécessaire pour rendre compte, mais il arrive après la bataille : quand le rapport mensuel signale un dérapage de coûts sur un projet, l'argent est déjà dépensé.
Le pilotage change la question. Il ne demande pas « qu'est-ce qui s'est passé » mais « où en sommes-nous par rapport à ce qui était prévu, et que se passe-t-il si nous ne changeons rien ». Trois éléments sont nécessaires : le réalisé, la prévision et le reste à faire. Le reporting n'a que le premier.
Dans un bureau d'études, piloter un projet consiste à comparer les heures consommées aux heures prévues, à estimer le reste à faire avec les chefs d'équipe et à projeter la date de fin. Dans un atelier, à comparer la production au plan, à intégrer les arrêts prévus et à anticiper le retard avant qu'il ne soit visible en expédition. La logique est la même en finance, en supply ou en ressources humaines.
- Ce qui s'est passé, par mois et par service
- Un extrait par demande, un fichier par réunion
- Des chiffres qui se contredisent selon l'auteur
- Personne ne sait quel rapport fait foi
- Prévisions comparées au réalisé, écart expliqué
- Projection sur les mois suivants
- Un référentiel unique, des indicateurs définis une fois
- Un propriétaire par indicateur, une décision par écart
Un modèle de données d'entreprise
Le pilotage échoue quand chaque fonction a son propre référentiel. La finance parle en centres de coût, les ressources humaines en matricules et en emplois, la production en ordres de fabrication, le bureau d'études en projets et en lots. Tant qu'ils ne se rejoignent pas, on ne peut pas répondre à une question aussi simple que « combien coûte réellement ce projet, heures internes comprises ».
Le modèle de données d'entreprise est ce point de jonction. Il définit les objets communs et leurs clés : un projet est rattaché à un centre de coût, une personne à un emploi et à une équipe, une heure pointée relie une personne, un projet et une période. Quelques tables de référence bien tenues suffisent pour réunir finance, ressources humaines et avancement opérationnel dans une même vue.
Ce modèle se construit avec les propriétaires de chaque référentiel et s'implémente dans la plateforme data sous forme de modèles versionnés et testés. Avec un outil comme dbt, chaque table de référence a une description, des tests d'unicité sur ses clés et un propriétaire. C'est un travail de gouvernance, et c'est lui qui rend le pilotage possible.
Comparer prévisions et réalisé, puis projeter
Une fois le modèle en place, le pilotage repose sur une mécanique simple : mettre côte à côte ce qui était prévu et ce qui s'est passé, à la même maille.
Cela suppose que les prévisions soient elles-mêmes des données. Trop souvent, le budget vit dans un fichier, le plan de charge dans un autre, le planning dans un troisième. Les intégrer dans la plateforme, avec leur version et leur date, permet de comparer le réalisé à la prévision d'origine comme aux prévisions révisées : on voit l'écart et son évolution.
La projection n'a pas besoin d'être sophistiquée pour être utile. Le reste à faire déclaré par les équipes, ajouté au réalisé, donne une estimation à terminaison qui, comparée au budget, indique tôt si une décision est nécessaire. Des méthodes plus avancées sont possibles, mais la première valeur vient de la discipline : un reste à faire mis à jour à chaque cycle, par les personnes qui savent.
Datasets certifiés et sécurité par ligne
Partager le pilotage suppose des chiffres fiables et des accès maîtrisés. Deux mécanismes y répondent.
Le dataset certifié, dans Power BI ou dans un outil équivalent, est un jeu de données publié par l'équipe data, validé en recette par les métiers et marqué comme référence. Les rapports s'y connectent ; ils ne rechargent pas leurs propres extractions. Qui ouvre un rapport certifié sait que les chiffres viennent de la couche sémantique commune, avec les définitions officielles. Un rapport non certifié peut exister, mais il est signalé comme tel.
La sécurité par ligne, ou RLS (Row-Level Security), permet de publier un seul rapport que chacun voit selon ses droits. Un responsable de site voit son site ; un contrôleur de gestion voit ses entités ; la direction voit tout. Les règles sont définies une fois sur le modèle, à partir des droits construits avec les métiers, et s'appliquent à tous les rapports.
Les heures pointées, les coûts salariaux, les effectifs sont des données personnelles au sens du RGPD (règlement général sur la protection des données). La sécurité par ligne permet de les intégrer au pilotage sans les exposer au-delà de ce que la finalité justifie. C'est la condition pour que la direction des ressources humaines accepte de participer au modèle commun.
Gouvernance des indicateurs
Un système de pilotage s'effondre dès que deux chiffres contradictoires circulent pour le même indicateur. La règle tient en une phrase : un chiffre, une définition, un propriétaire.
La définition précise la formule, la maille, la période, les exclusions ; elle est écrite dans la couche sémantique et visible depuis les rapports. Le propriétaire est la personne métier qui répond de cette définition et arbitre les cas ambigus. Quand un indicateur change de définition, le changement est daté et l'historique est conservé.
Cette gouvernance coûte du temps au démarrage. Elle se rembourse à chaque comité où l'on discute de décisions plutôt que de la validité des chiffres.
La place de l'IA
Avec un modèle commun, des indicateurs gouvernés et des accès maîtrisés, une nouvelle possibilité s'ouvre : interroger le pilotage en langage naturel. Un responsable d'atelier demande « quel est l'écart entre réalisé et prévu sur ma ligne cette semaine » et obtient une réponse chiffrée, avec la définition de l'indicateur et la source.
Les assistants fondés sur un LLM (grand modèle de langage), qu'il s'agisse de Claude, de GPT, de Mistral ou d'un autre, ne calculent pas les indicateurs eux-mêmes. Ils traduisent la question en requête sur la couche sémantique, et c'est cette couche qui garantit la réponse. Les architectures RAG (génération augmentée par recherche) et des protocoles comme MCP (Model Context Protocol) connectent l'assistant aux définitions et aux données certifiées, dans le respect des droits de la personne qui interroge.
C'est là que la conviction se vérifie : la gouvernance ne freine pas l'IA, c'est ce qui permet de lui dire oui. Sans couche sémantique, l'assistant invente une formule. Sans sécurité par ligne, il montre des données à qui ne doit pas les voir. Sans propriétaire, personne ne peut valider sa réponse. Avec ces trois éléments, l'assistant devient un moyen d'accès sûr à un pilotage déjà fiable. Le cadre européen, notamment l'AI Act, va dans ce sens : traçabilité, maîtrise des données, responsabilité identifiée.
À retenir
- Le reporting décrit le passé ; le pilotage compare le réalisé à la prévision et projette.
- Un modèle de données d'entreprise réunit finance, ressources humaines et avancement opérationnel sur des clés communes.
- Les prévisions et le reste à faire sont des données à intégrer, versionner et mettre à jour à chaque cycle.
- Les datasets certifiés garantissent la source ; la sécurité par ligne garantit que chacun voit ce qu'il doit voir.
- Un indicateur, c'est une définition écrite et un propriétaire nommé.
- L'IA en langage naturel ne remplace pas cette gouvernance ; elle en dépend.
Checklist
- Les référentiels de la finance, des ressources humaines et de l'opérationnel partagent des clés communes.
- Les budgets, plans de charge et plannings sont chargés dans la plateforme avec leur version.
- Le reste à faire est mis à jour à chaque cycle par les équipes concernées.
- Les rapports de pilotage se connectent à un dataset certifié, jamais à une extraction locale.
- La sécurité par ligne est définie sur le modèle et testée avec des utilisateurs de chaque profil.
- Chaque indicateur a une définition écrite, un propriétaire et un historique de changements.
- Les données personnelles intégrées au pilotage ont une finalité documentée conforme au RGPD.