Gouvernance des données et des modèles de pilotage

La gouvernance rend explicites les règles de production et d’utilisation des chiffres : leur sens, leur origine, leurs responsables et leurs conditions de modification. Elle couvre les données aussi bien que les calculs, car une information correcte peut conduire à une décision erronée si le modèle qui la transforme est mal défini.

• Attribuer une responsabilité à chaque objet important. Le propriétaire de donnée est la personne qui répond de sa définition et de ses règles d’usage ; le responsable de modèle répond de la cohérence des hypothèses et des calculs. Ils ne réalisent pas nécessairement toutes les tâches, mais arbitrent les désaccords et acceptent les changements. Une donnée sans responsable devient rapidement un sujet de négociation entre services ; un modèle sans responsable dépend de la seule personne qui sait le faire fonctionner.
• Partager un langage et des contrôles. Le dictionnaire de données est le document qui décrit le sens, le format, l’unité et les règles d’utilisation des informations. Il précise aussi le périmètre des indicateurs et les exceptions admises. Les contrôles vérifient ensuite que les données reçues respectent ces conventions. Un total identique ne suffit pas : deux services peuvent agréger les mêmes montants selon des catégories différentes et produire des lectures incompatibles.
• Encadrer les changements et conserver les preuves. La traçabilité est la capacité à retrouver l’origine d’une information et les opérations qui l’ont transformée. Elle relie une valeur publiée à sa source, aux règles appliquées et aux validations obtenues. Une nouvelle formule, une correction ou un changement de périmètre doit donc être documenté, testé et autorisé. L’objectif n’est pas de bloquer les équipes, mais de distinguer une exploration libre d’un chiffre officiellement utilisé pour décider.

Sans gouvernance, la direction financière passe une partie de son temps à expliquer pourquoi plusieurs chiffres prétendent représenter la même réalité. Le chiffre d’affaires (CA) est le montant des ventes reconnu sur une période selon les règles retenues. Pourtant, une équipe peut inclure certaines ventes internes, une autre les exclure, et une troisième utiliser la date de commande plutôt que la date de reconnaissance. Le désaccord porte alors sur la définition avant de porter sur la performance.

Les difficultés se cumulent lorsque chacun corrige son fichier localement. Un code produit change sans information des utilisateurs ; une formule conserve une ancienne hypothèse ; une extraction est remplacée sans conserver sa date. Le chiffre final paraît plausible, mais personne ne peut expliquer précisément sa construction. Les réunions deviennent des séances de rapprochement, c’est-à-dire de comparaison des informations pour identifier et expliquer leurs différences, plutôt que des moments de décision.

Le problème concerne aussi le budget, c’est-à-dire la référence chiffrée approuvée pour une période. Si la structure des activités évolue en cours d’année sans règle de comparaison, une variation peut traduire un reclassement plutôt qu’une amélioration réelle. Une modification silencieuse du modèle peut ainsi changer l’interprétation de la performance sans changer les opérations de l’entreprise.

La gouvernance réduit cette ambiguïté en séparant les questions : la donnée est-elle conforme, la règle est-elle correcte, le périmètre est-il comparable et la publication a-t-elle été approuvée ? Elle ne garantit pas qu’une prévision sera juste ni qu’une décision sera bonne. Elle permet de connaître les conventions utilisées et de traiter les désaccords au bon niveau.

Elle complète la qualité des données de pilotage : la qualité décrit l’aptitude des informations à l’usage attendu ; la gouvernance organise les responsabilités et les décisions nécessaires pour l’obtenir et la maintenir.

La mécanique consiste à faire passer chaque information importante d’une source identifiée à une publication autorisée, avec des responsabilités explicites à chaque étape.

1. Définir l’usage. Préciser la décision à éclairer, les utilisateurs et le niveau de détail nécessaire. Une analyse commerciale et une lecture financière peuvent utiliser des conventions différentes, à condition de les nommer et de ne pas les confondre.
2. Identifier les objets à gouverner. Recenser les sources, indicateurs, hypothèses et formules. Un référentiel est un ensemble partagé de codes et de descriptions qui identifie les objets de gestion, comme les produits ou les entités. Les référentiels finance doivent avoir des règles de création, de modification et de désactivation.
3. Attribuer les décisions. Désigner qui propose, qui vérifie, qui approuve et qui publie. La finance porte les conventions de gestion ; les métiers expliquent les données opérationnelles ; l’équipe informatique sécurise les traitements et les accès. Les frontières exactes dépendent de l’organisation.
4. Contrôler avant utilisation. Vérifier les champs obligatoires, les codes inconnus, les doublons et la cohérence avec la source. Définir les anomalies qui bloquent la publication et celles qui peuvent être acceptées avec réserve. Une réserve doit avoir un responsable et une échéance de résolution.
5. Tester les transformations. Vérifier les correspondances entre codes, les agrégations et les calculs sur des cas connus. Le lignage des données, ou lineage, décrit le chemin suivi entre une source et un résultat ; sa documentation facilite la recherche d’une erreur.
6. Valider, publier et conserver. Enregistrer les approbations, identifier la version utilisée et conserver les éléments nécessaires pour reproduire le résultat. Lorsqu’une règle change, préciser sa date d’effet et le traitement des périodes antérieures.

Cet exemple est fictif : une entreprise de taille intermédiaire compare la performance de deux activités, Alpha et Bêta, sur un même mois. La marge sur coûts variables est le chiffre d’affaires diminué des coûts variables, c’est-à-dire des coûts qui varient avec le niveau d’activité dans le périmètre retenu.

La règle approuvée prévoit d’affecter chaque coût variable à l’activité qui consomme la ressource. Un ancien code fait pourtant affecter à Bêta un coût de 60 000 € qui concerne Alpha. Le total reste correct : un contrôle portant uniquement sur l’entreprise ne détecte donc pas l’erreur.

| Montants en euros | Alpha avant correction | Bêta avant correction | Alpha validé | Bêta validé | Total validé | | --- | ---: | ---: | ---: | ---: | ---: | | Chiffre d’affaires | 600 000 | 400 000 | 600 000 | 400 000 | 1 000 000 | | Coûts variables | 300 000 | 260 000 | 360 000 | 200 000 | 560 000 | | Marge sur coûts variables | 300 000 | 140 000 | 240 000 | 200 000 | 440 000 | | Taux de marge sur coûts variables | 50 % | 35 % | 40 % | 50 % | 44 % |

Le taux de marge sur coûts variables est la marge sur coûts variables divisée par le CA. Après correction, Alpha présente une marge de 600 000 − 360 000 = 240 000 €, soit 240 000 / 600 000 × 100 = 40 %. Bêta présente 400 000 − 200 000 = 200 000 €, soit 200 000 / 400 000 × 100 = 50 %.

Les opérations de correction sont explicites : coûts d’Alpha = 300 000 + 60 000 = 360 000 € ; coûts de Bêta = 260 000 − 60 000 = 200 000 €. Le total reste 360 000 + 200 000 = 560 000 €. La marge totale est 1 000 000 − 560 000 = 440 000 €, soit 44 % du CA.

Le propriétaire de donnée confirme l’affectation, le responsable de modèle vérifie le calcul et la finance approuve la republication. La table de correspondance est corrigée avec une date d’effet ; l’ancienne publication est conservée et signalée comme remplacée. La gouvernance évite ici une mauvaise lecture des activités, même lorsque le total paraît fiable.

Le déploiement doit partir d’un usage concret plutôt que d’un inventaire exhaustif de toutes les données. Choisir un processus récurrent, suffisamment important pour mobiliser les équipes et suffisamment délimité pour produire des règles applicables.

1. Délimiter le périmètre. Identifier les décisions, les publications et les principaux risques : mauvaise affectation, accès excessif, formule non maîtrisée ou rupture de comparaison. Livrable : une note de périmètre indiquant les objets couverts, les utilisateurs et les exclusions.
2. Recenser l’existant. Décrire les sources, fichiers, traitements, hypothèses et personnes réellement sollicitées. Relever les corrections manuelles et les dépendances à une personne. Livrables : un inventaire des données et modèles, accompagné d’un schéma de circulation de l’information.
3. Clarifier les responsabilités. Construire une matrice RACI, tableau distinguant le responsable de l’exécution, l’autorité qui approuve, les personnes consultées et les personnes informées. Prévoir un remplaçant et un mécanisme d’arbitrage. Livrable : une matrice approuvée pour les décisions sensibles.
4. Formaliser les conventions. Rédiger les définitions, les règles de calcul, les unités, les périmètres et les règles de conservation. Livrables : un dictionnaire et un registre des règles, chacun avec un propriétaire et une date d’effet.
5. Organiser contrôles et changements. Définir les vérifications, les preuves attendues et le chemin d’approbation. Livrables : un catalogue de contrôles et une procédure de changement couvrant les corrections urgentes comme les évolutions planifiées.
6. Tester sur un cycle complet. Appliquer les règles à une collecte, un calcul et une publication réels. Livrables : résultats de tests, anomalies traitées, approbation de mise en service et guide utilisateur.
7. Installer la revue régulière. Examiner les incidents, les changements et les objets devenus inutiles. Livrable : un plan d’amélioration avec responsables et échéances. La planification budgétaire constitue un terrain possible, car elle mobilise données, hypothèses et validations.

Gouverner selon le risque

Toutes les données ne demandent pas le même niveau de contrôle. Une hypothèse exploratoire peut rester souple ; une formule utilisée pour rémunérer, investir ou communiquer nécessite une validation plus exigeante. Cette distinction évite de transformer la gouvernance en circuit administratif uniforme.

Séparer définition et réalisation

Le métier explique le sens de la donnée, la finance précise son usage dans le pilotage et l’équipe technique met en œuvre les traitements. Une seule personne peut cumuler certains rôles dans une petite équipe, mais une modification sensible doit être relue par quelqu’un d’autre. La séparation des tâches consiste à répartir des actions incompatibles entre plusieurs personnes pour limiter erreurs et abus.

Documenter ce qui change la décision

Prioriser les périmètres, les unités, les règles de calcul et les exclusions. Une documentation courte, reliée au modèle et tenue à jour vaut mieux qu’un dossier exhaustif que personne ne consulte. Toute définition doit pouvoir être illustrée par un exemple et un contre-exemple.

Préserver les résultats approuvés

La gestion des versions consiste à identifier et conserver les états successifs d’un objet. Elle doit porter sur les données, les hypothèses et les règles de calcul : conserver uniquement le fichier de sortie ne permet pas toujours de reproduire un résultat. Une publication approuvée ne doit pas être remplacée silencieusement.

Prévoir les exceptions

Une anomalie non bloquante peut être acceptée si son effet est compris, son approbation enregistrée et sa résolution suivie. L’exception doit rester visible pour les utilisateurs. Une correction urgente doit ensuite repasser dans le processus normal afin de ne pas devenir une règle implicite.

Intégrer la gouvernance au travail courant

Placer les contrôles au moment de la collecte et les validations au moment de la publication. Réutiliser les mêmes définitions dans les supports de formation et les écrans de saisie. Les équipes comprennent mieux la règle lorsqu’elles voient le risque qu’elle prévient et savent à qui demander un arbitrage.

Confondre outil et gouvernance

Centraliser des fichiers ne décide pas qui possède les définitions ni qui peut changer une formule. Avant de configurer un outil, formaliser les autorités, les règles et les preuves attendues. Sinon, les désaccords sont simplement déplacés dans une application commune.

Nommer un responsable sans lui donner de pouvoir

Un propriétaire de donnée ne peut pas répondre de sa qualité s’il n’a ni accès aux anomalies ni capacité d’obtenir leur correction. Lui donner un périmètre précis, un interlocuteur opérationnel et un recours d’arbitrage. Sa responsabilité porte sur un objet défini, pas sur toutes les données de l’entreprise.

Ne contrôler que les totaux

Une mauvaise affectation peut laisser le total inchangé, comme dans l’exemple. Compléter les rapprochements globaux par des contrôles de codes, de périodes et de répartition.

Modifier l’historique sans expliquer la comparaison

Une nouvelle structure peut être appliquée aux périodes anciennes ou seulement aux nouvelles. Les deux choix peuvent être justifiés, mais ils n’ont pas le même effet. Conserver la lecture initiale et expliquer la lecture recalculée, avec les règles utilisées pour passer de l’une à l’autre.

Accumuler les validations indistinctes

Lorsque chaque évolution suit le même circuit, les équipes contournent le processus. Distinguer un changement de libellé d’une modification de calcul ou de périmètre. Réserver les validations renforcées aux risques réellement importants, sans supprimer la trace des changements simples.

Oublier les fichiers périphériques

Une publication contrôlée peut être retraitée dans un tableur puis utilisée pour décider. Identifier ces transformations finales et préciser si elles relèvent d’une analyse personnelle ou d’un résultat officiel. La gouvernance doit suivre l’usage de l’information, pas seulement la frontière d’un système.

Un indicateur clé de performance (KPI) est une mesure suivie pour apprécier un objectif ou un processus. Les indicateurs de gouvernance évaluent la maîtrise de la production des chiffres, pas directement la performance économique. Leur périmètre et leur période doivent rester stables pour permettre une comparaison.

• Couverture des responsabilités = objets critiques ayant un propriétaire désigné / objets critiques recensés × 100. La liste des objets critiques doit être approuvée et datée ; retirer des objets pour améliorer le taux masquerait le risque.
• Complétude documentaire = objets critiques dont la documentation obligatoire est à jour / objets critiques recensés × 100. Définir ce qui est obligatoire : source, unité, règle, propriétaire, date d’effet et procédure de contrôle, par exemple.
• Conformité au premier passage = lots conformes lors du premier contrôle / lots contrôlés × 100. Un lot est un ensemble de données traité comme une unité de collecte. Ne pas mélanger ce taux avec une mesure calculée au niveau de chaque ligne.
• Délai moyen de résolution = somme des durées entre ouverture et clôture des anomalies résolues / nombre d’anomalies résolues. Préciser l’unité de temps et suivre aussi les anomalies encore ouvertes, que cette moyenne ne représente pas.
• Maîtrise des changements = changements sensibles mis en service avec tests et approbation / changements sensibles mis en service × 100. Inclure les interventions urgentes pour ne pas embellir artificiellement la mesure.

Lorsque le dénominateur est nul, indiquer « non applicable » plutôt qu’un taux trompeur. Fixer les seuils selon le risque et l’usage, sans supposer qu’une cible universelle conviendra partout.

Les livrables associés sont le dictionnaire, le registre des modèles, la matrice des responsabilités, le catalogue des contrôles, le journal des anomalies et l’historique des changements. Les approbations de publication et les décisions d’exception complètent cet ensemble. Chaque document doit avoir un responsable de mise à jour et un emplacement connu ; sa simple existence ne prouve pas que la règle est appliquée.

L’Enterprise Performance Management (EPM) désigne un ensemble de processus et de méthodes de gestion de la performance de l’entreprise. Un logiciel EPM soutient ces processus en organisant les données, les calculs et les travaux de planification, de suivi et d’analyse. Il peut matérialiser des règles de gouvernance dans le travail quotidien, sans remplacer les décisions de l’organisation.

Les fonctionnalités à examiner sont concrètes : gestion des droits par rôle et périmètre, circuits de validation, contrôles de saisie, conservation des versions, verrouillage des périodes et journal des modifications. Un journal d’audit est un historique des actions permettant de retrouver qui a changé quoi et quand. Vérifier quels objets il couvre réellement : données, règles, structures, droits ou publications.

Un logiciel EPM peut aussi centraliser les calculs partagés et relier les résultats aux données détaillées. Cela facilite l’application d’une convention commune, mais ne prouve pas que cette convention est correcte. La visibilité de l’origine des chiffres peut dépendre de la manière dont les sources et traitements sont intégrés.

Des solutions comme OneStream, CCH Tagetik, Oracle EPM et Anaplan, ainsi que SAP Analytics Cloud, Pigment, Board et Workday Adaptive Planning, sont à examiner selon les usages visés. Les possibilités exactes varient selon les produits, modules, configurations et contrats ; cette liste n’établit aucun classement.

La démonstration doit partir de situations de gouvernance : corriger un code sans altérer une publication passée, faire approuver une formule, limiter l’accès à des données sensibles ou expliquer une modification. Demander à voir les preuves produites, pas seulement l’écran final.

Enfin, distinguer ce qui relève de l’application et ce qui reste dans les systèmes sources ou les fichiers périphériques. Un modèle centralisé peut rester fragile si ses données d’entrée sont mal définies. L’outil rend les règles exécutables ; les propriétaires, les contrôles et les arbitrages les rendent légitimes.

Débutant : rendre les responsabilités visibles

Les définitions sont dispersées, les corrections circulent par messages et la connaissance des modèles repose sur quelques personnes. Les publications restent difficiles à reproduire. Le premier progrès consiste à identifier les objets critiques, leurs responsables et les règles minimales de validation.

Les signes distinctifs d’un débutant en progrès sont un inventaire partagé, des définitions approuvées et un emplacement unique pour les publications officielles. Un tableur maîtrisé peut suffire à ce stade. L’objectif est de sortir de l’implicite, pas de déployer immédiatement une infrastructure complexe.

Intermédiaire : appliquer un processus commun

Les principales données ont un propriétaire ; les changements suivent une procédure ; les contrôles sont réalisés avant publication. Les anomalies sont enregistrées, les exceptions approuvées et les versions conservées. Les utilisateurs savent distinguer une analyse en préparation d’un résultat validé.

Le signe déterminant est la répétabilité : un remplaçant peut exécuter le processus et expliquer un résultat sans dépendre du concepteur initial. Les limites apparaissent souvent dans les traitements périphériques, les changements d’organisation ou les modèles locaux encore peu documentés.

Avancé : maîtriser les dépendances et les évolutions

L’organisation connaît les liens entre sources, règles et publications. Avant une modification, elle peut identifier les résultats susceptibles d’être affectés. Les contrôles adaptés au risque sont intégrés aux traitements ; les droits sont revus et les modèles devenus inutiles sont retirés.

La maturité avancée ne signifie pas absence d’erreur. Elle se reconnaît à la capacité de détecter, expliquer et corriger un problème tout en informant les utilisateurs concernés. Les équipes évaluent aussi le coût des contrôles et simplifient ceux qui n’apportent plus de valeur.

Le passage d’un niveau à l’autre se juge sur les pratiques observables. Acheter un outil, rédiger une charte ou créer un comité ne suffit pas si les décisions continuent à être prises hors du cadre annoncé.

Cette checklist sert à examiner un processus ou un modèle précis. Une case ne devrait être cochée que si une preuve existe et si les personnes concernées savent appliquer la règle. Une réponse négative appelle une action proportionnée au risque, avec un responsable et une échéance.

• [ ] L’usage du modèle et les décisions qu’il doit éclairer sont-ils explicitement décrits ?
• [ ] Les données, hypothèses et calculs critiques sont-ils recensés dans un inventaire tenu à jour ?
• [ ] Chaque objet critique a-t-il un propriétaire identifié, disponible et doté d’un pouvoir d’arbitrage ?
• [ ] Un remplaçant peut-il expliquer et exécuter le processus sans dépendre de son concepteur ?
• [ ] Les indicateurs ont-ils une définition partagée, une unité, un périmètre et une règle de calcul ?
• [ ] Les sources autorisées et les dates de collecte sont-elles connues des utilisateurs ?
• [ ] Les créations, modifications et désactivations de codes suivent-elles une règle explicite ?
• [ ] Les contrôles vérifient-ils les affectations et les périodes, au-delà des seuls totaux ?
• [ ] Les anomalies bloquantes sont-elles distinguées des réserves acceptables avant publication ?
• [ ] Chaque exception acceptée a-t-elle une justification, une approbation et une échéance de résolution ?
• [ ] Une modification sensible de formule ou de périmètre est-elle testée avant son utilisation officielle ?
• [ ] Les versions de données, d’hypothèses et de règles permettent-elles de reproduire un résultat publié ?
• [ ] La date d’effet des changements et leur traitement dans les comparaisons historiques sont-ils précisés ?
• [ ] Les droits d’accès correspondent-ils aux responsabilités actuelles et sont-ils revus lors des départs ?
• [ ] Les retraitements effectués hors de l’outil central sont-ils identifiés lorsqu’ils alimentent une décision ?
• [ ] Les utilisateurs sont-ils avertis lorsqu’une publication est corrigée ou remplacée ?
• [ ] Les incidents récurrents débouchent-ils sur une correction de leur cause, et pas seulement du chiffre final ?

À retenir : la gouvernance relie un chiffre à une définition, une source, un responsable et une validation. Elle doit couvrir les données comme les modèles, préserver les publications approuvées et autoriser les évolutions sans rendre leurs effets invisibles.

Qui doit porter la gouvernance ?

La direction financière porte généralement les conventions de pilotage et les priorités de contrôle. Elle ne doit pas assumer seule toutes les données : les métiers restent responsables de leur signification opérationnelle et l’équipe informatique des dispositifs techniques. Une autorité d’arbitrage tranche les désaccords qui dépassent un processus.

Faut-il gouverner tous les fichiers ?

Non, pas avec la même intensité. Commencer par les informations et calculs qui alimentent des décisions importantes ou des publications récurrentes. Un fichier exploratoire peut rester souple. Dès que ses résultats deviennent une référence partagée, ses sources, hypothèses et validations doivent être explicites.

Quelle différence entre gouvernance des données et des modèles ?

La première encadre le sens, l’origine et les conditions d’usage des informations. La seconde encadre leur transformation : hypothèses, formules, agrégations et comparaisons. Les deux sont indissociables. Des données exactes ne compensent pas une mauvaise formule ; une formule correcte ne compense pas des données mal affectées.

Comment gérer une correction urgente ?

Prévoir un circuit d’exception : identifier le problème, mesurer son effet, obtenir l’autorisation et conserver la trace de la correction. Informer les utilisateurs si un résultat publié change. Après l’urgence, tester la solution durable et vérifier si d’autres périodes ou modèles sont concernés.

Peut-on démarrer sans EPM ?

Oui. Un dictionnaire partagé, des responsabilités claires, des contrôles documentés et une conservation maîtrisée des versions permettent de commencer. Le logiciel EPM devient utile pour intégrer ces règles dans des processus partagés et limiter les manipulations dispersées. Le besoin dépend de la complexité, des risques et du nombre d’intervenants, pas d’un seuil universel.