Qualité des données de pilotage

La qualité des données de pilotage consiste à rendre les informations suffisamment fiables et explicites pour l'usage attendu. Elle ne se limite pas à supprimer des erreurs : elle garantit aussi que les chiffres couvrent le bon périmètre, arrivent au bon moment et reposent sur des définitions partagées. Une donnée n'est donc pas « bonne » dans l'absolu, mais adaptée à une décision et accompagnée de ses limites.

• Vérifier plusieurs dimensions, pas seulement les totaux. L'exactitude est la concordance d'une donnée avec la réalité qu'elle représente ; la complétude est la présence des données attendues ; la cohérence est l'absence de contradictions entre informations liées. S'y ajoutent l'unicité, absence de doublons non légitimes, la validité, respect des formats et règles autorisés, et la fraîcheur, caractère suffisamment récent et à jour des données pour l'usage attendu, apprécié à partir de leur date d'observation ou de mise à jour. La disponibilité à l'échéance désigne la réception de données exploitables avant la date attendue ; elle est mesurée en section « Indicateurs et livrables associés ». Un fichier livré à temps peut contenir des données obsolètes. Un total juste ne prouve pas que chaque ligne est correcte.
• Organiser la responsabilité de bout en bout. La gouvernance des données est l'ensemble des responsabilités et règles encadrant leur création, leur modification et leur utilisation. Le métier définit le sens attendu, l'équipe informatique sécurise les traitements, et la finance décide si les informations peuvent être utilisées. Chaque anomalie importante doit avoir un responsable, une action et une échéance, plutôt qu'une correction anonyme dans un fichier.
• Rendre la confiance visible. La traçabilité est la possibilité de retrouver l'origine d'une donnée et les transformations qu'elle a subies. Elle permet d'expliquer un résultat, de distinguer une correction d'une évolution économique et de reproduire une publication. L'utilisateur doit savoir ce qui est validé, ce qui reste provisoire et quelles réserves peuvent modifier sa décision.

Sans démarche explicite, la direction financière passe une partie de son temps à arbitrer entre des chiffres concurrents. Les ventes peuvent être extraites à des dates différentes, des entités oubliées, des montants exprimés dans des unités incompatibles ou des fichiers intégrés plusieurs fois. Le problème n'est pas seulement technique : deux équipes peuvent employer le même libellé pour désigner des réalités différentes.

Le chiffre d'affaires (CA) est le montant des ventes de biens et services reconnu sur une période, selon les règles applicables. Une équipe peut pourtant transmettre des commandes tandis qu'une autre fournit des ventes comptabilisées. Additionner ces données sans préciser leur nature produit un résultat trompeur, même si le calcul est exact.

Des difficultés très concrètes

La préparation du reporting mensuel de gestion, c'est-à-dire la restitution périodique des résultats pour analyser et décider, devient une succession de corrections urgentes. Les contrôleurs expliquent des variations qui viennent en réalité d'un changement de classement. Les responsables opérationnels contestent les tableaux et conservent leurs propres fichiers. La direction hésite entre plusieurs versions au moment de décider.

La qualité des données réduit cette ambiguïté en distinguant les faits économiques, les conventions de mesure et les défauts de traitement. Elle rend aussi visible une information manquante : une absence ne doit pas être interprétée automatiquement comme une activité nulle.

Une confiance encadrée, pas une perfection abstraite

L'objectif est de sécuriser les décisions sensibles. Une donnée provisoire peut rester utile si sa limite est connue et si son usage est restreint. À l'inverse, une anomalie apparemment faible peut être bloquante lorsqu'elle change le sens d'une décision ou empêche d'identifier une entité. La démarche évite ainsi deux excès : publier sans contrôle ou attendre une perfection qui retarde inutilement le pilotage.

La mécanique relie un besoin de décision à des contrôles observables, puis à un traitement explicite des anomalies. Elle fonctionne sur chaque flux de données, depuis son origine jusqu'à sa publication.

1. Définir ce qui est attendu. Préciser la mesure, la période, le périmètre, l'unité et la date de disponibilité. La granularité est le niveau de détail auquel une donnée est enregistrée, par exemple une facture ou un total par entité et par mois. Le contrôle doit porter sur ce niveau, sans mélanger des lignes détaillées et leurs totaux.
2. Identifier les sources et les correspondances. Désigner la source faisant autorité pour chaque information. Un référentiel est une liste organisée de valeurs communes, comme les entités ou les produits. Le mapping, ou table de correspondance, relie les codes d'une source aux codes utilisés pour le pilotage. Ces règles doivent être explicites et datées ; voir la notion de référentiel.
3. Contrôler à l'entrée. Vérifier les champs obligatoires, les valeurs autorisées, les périodes et les doublons. Une clé d'identification est un champ ou un ensemble de champs permettant de distinguer un enregistrement. Elle doit tenir compte des cas légitimes, comme plusieurs lignes appartenant à une même facture.
4. Contrôler après transformation. Un rapprochement est une comparaison de données issues de sources ou de traitements différents pour expliquer leurs écarts. Comparer les nombres de lignes et les montants avant et après traitement, puis vérifier les règles de calcul et les regroupements.
5. Qualifier et traiter les anomalies. Distinguer un rejet bloquant d'un avertissement. Attribuer un responsable, conserver la preuve du diagnostic et corriger à la source lorsque c'est possible. Toute correction locale doit être autorisée et traçable.
6. Valider et publier. Conserver les résultats des contrôles et les réserves acceptées. La publication doit identifier sa date et sa version afin qu'une nouvelle extraction ne remplace pas silencieusement les données déjà utilisées.

Ce cas est fictif : une entreprise de taille intermédiaire (ETI), catégorie d'entreprise située entre les petites et moyennes entreprises (PME) et les grandes entreprises, prépare son analyse mensuelle des ventes. Toutes les données sont exprimées en euros, sur la même période et le même périmètre. Le fichier attendu contient des lignes identifiées individuellement ; certaines sont absentes et d'autres chargées en double.

| Situation dans le flux | Lignes | Montant de CA | Traitement | |---|---:|---:|---| | Lignes attendues distinctes présentes, hors copies supplémentaires | 98 | 490 000 € | Conserver | | Copies supplémentaires de lignes déjà présentes | 2 | 20 000 € | Supprimer | | Lignes attendues absentes du chargement | 2 | 10 000 € | Ajouter depuis la source | | Chargement initial | 100 | 510 000 € | Contrôler | | Données corrigées | 100 | 500 000 € | Valider |

Pourquoi compter les lignes ne suffit pas

Le chargement initial contient bien 98 + 2 = 100 lignes, comme le nombre attendu. Mais il ne couvre que 98 lignes attendues distinctes : la complétude vaut 98 / 100 × 100 = 98 %. Le ratio du nombre de clés distinctes au nombre de lignes reçues vaut 98 / 100 × 100 = 98 %. Il ne mesure pas la proportion de lignes dont la clé apparaît une seule fois. Ces mesures portent ici uniquement sur l'identification des lignes, pas sur l'exactitude de tous leurs champs.

Le montant initial est 490 000 + 20 000 = 510 000 €. La correction donne 510 000 − 20 000 + 10 000 = 500 000 €. Le nombre final de lignes est 100 − 2 + 2 = 100 ; la couverture des lignes attendues atteint 100 / 100 × 100 = 100 %.

Conséquence sur l'analyse financière

Le budget est une référence chiffrée approuvée pour une période. Avec un budget de CA de 490 000 €, l'écart budgétaire, défini comme réel − budget, paraît d'abord égal à 510 000 − 490 000 = +20 000 €. Après correction, il est de 500 000 − 490 000 = +10 000 €, favorable pour les ventes, sans préjuger de la rentabilité.

Les coûts variables, charges évoluant avec le niveau d'activité dans le cadre retenu, sont ici validés à 300 000 €. La marge sur coûts variables, égale au CA moins les coûts variables, passe donc de 510 000 − 300 000 = 210 000 € à 500 000 − 300 000 = 200 000 €. Un simple contrôle du total des lignes aurait laissé subsister une surestimation de 10 000 €.

Le déploiement doit partir des décisions à sécuriser, plutôt que d'un inventaire exhaustif de tous les fichiers. Un périmètre limité permet de tester les règles et les responsabilités avant de les étendre.

1. Choisir un usage prioritaire. Décrire la décision concernée, les utilisateurs et les conséquences d'une donnée erronée. Retenir un flux dont les difficultés sont visibles et dont les responsables sont disponibles. Livrable : une fiche de périmètre avec données critiques, calendrier et critères de publication.
2. Établir un diagnostic partagé. Examiner les données historiques, les corrections récentes et les contestations des utilisateurs. Le profilage des données est l'analyse de leur structure et de leurs valeurs pour repérer des caractéristiques ou anomalies. Livrable : un état initial distinguant erreurs de source, de définition et de transformation.
3. Formaliser les définitions. Rédiger un dictionnaire de données, document décrivant le sens, le format, l'unité et les règles d'utilisation de chaque donnée. Fixer la source faisant autorité et les exceptions admises. Livrable : un dictionnaire validé et des correspondances approuvées.
4. Attribuer les responsabilités. Identifier qui décide de la définition, qui corrige, qui valide et qui utilise. Prévoir une procédure d'escalade lorsqu'un problème dépasse le responsable du flux. Livrable : une matrice des responsabilités cohérente avec la gouvernance.
5. Construire et tester les contrôles. Introduire volontairement des anomalies dans des jeux d'essai : doublon, période incorrecte, code inconnu, ligne manquante. Vérifier également que les cas légitimes passent. Livrable : un catalogue de règles et les preuves de test.
6. Installer le fonctionnement courant. Définir les délais de traitement, les conditions de publication et les modalités de correction. Livrable : un registre des anomalies, une procédure de validation et un tableau de suivi.

L'extension à d'autres flux intervient lorsque les équipes savent expliquer les alertes et fermer les incidents. Déployer davantage de contrôles sans capacité de traitement ne fait qu'accumuler des problèmes visibles.

Relier chaque contrôle à un risque

Une règle doit répondre à une question utile : quelle décision serait faussée si cette anomalie passait ? Cette justification permet d'arbitrer entre contrôles bloquants et simples avertissements. Elle évite de mobiliser les équipes sur des écarts sans conséquence tout en négligeant les informations indispensables.

Documenter avant d'automatiser

Pour chaque contrôle, préciser les données concernées, la formule, les exclusions, le résultat attendu et le responsable. Une règle automatique mal définie reproduit fidèlement une mauvaise convention. Les métiers doivent donc approuver le sens du contrôle avant sa mise en production.

Corriger au plus près de l'origine

Une correction durable vise la cause : saisie ambiguë, code absent, extraction incomplète ou correspondance obsolète. Une correction locale peut être nécessaire pour publier, mais elle doit rester identifiable, autorisée et réversible. Sans cela, plusieurs couches de corrections finissent par masquer la donnée initiale.

Conserver les preuves et les versions

Le lineage, ou filiation des données, décrit le chemin entre les sources, les transformations et les résultats. Une documentation de lineage utile permet de retrouver les fichiers reçus, les règles appliquées et les validations. Conserver aussi les dates d'effet des référentiels : une entité peut changer de rattachement sans que les périodes déjà publiées doivent être recalculées.

Tester les cas qui doivent passer

Un contrôle de doublons ne doit pas rejeter des lignes distinctes d'une même facture. Une vérification de montant doit tenir compte des avoirs et des annulations autorisés. Tester les situations légitimes réduit les alertes inutiles et protège la confiance des utilisateurs dans le dispositif.

Expliquer les réserves aux lecteurs

Associer les alertes à un effet potentiel : périmètre incomplet, résultat provisoire ou comparaison limitée. L'utilisateur n'a pas besoin de tous les détails techniques, mais il doit comprendre ce que la réserve change dans son interprétation. Une qualité visible et contextualisée est plus utile qu'un indicateur global affiché sans explication.

Confondre total juste et données justes

Deux erreurs peuvent se compenser. Un total rapproché ne garantit ni le bon classement par produit ni l'absence de doublons. Pour l'éviter, combiner les contrôles de montant, de couverture et d'identification, puis effectuer des vérifications ciblées au niveau de détail utilisé pour décider.

Transformer une absence en zéro

Une valeur numérique égale à zéro peut signifier qu'aucune activité n'a eu lieu ; une donnée absente signifie que l'information n'est pas disponible. NULL est un marqueur représentant une information absente ou inconnue dans de nombreux systèmes de données. Une valeur NULL ne doit pas être assimilée automatiquement à zéro. Remplacer systématiquement l'absence par zéro rend les calculs plus simples mais masque les défauts de couverture. Conserver un statut explicite et décider séparément si une estimation est autorisée.

Choisir des seuils sans justification

La matérialité est l'importance d'une information ou d'une erreur au regard des décisions qu'elle peut influencer. Un seuil identique pour tous les flux ignore leurs enjeux respectifs. Définir les tolérances selon l'usage et le risque, sans oublier qu'une erreur de code ou de période peut être bloquante indépendamment de son montant.

Corriger sans laisser de trace

Modifier un fichier final peut résoudre l'urgence et rendre impossible l'explication du mois suivant. Conserver la donnée reçue, la correction, son motif et son approbation. Prévoir ensuite une action à la source pour éviter que l'équipe répète la même réparation à chaque cycle.

Mesurer uniquement les alertes détectées

Moins d'alertes ne signifie pas nécessairement une meilleure qualité : un contrôle peut avoir été désactivé ou un flux retiré du périmètre. Suivre aussi la couverture des contrôles et les changements de règles. Une amélioration doit être interprétée à périmètre comparable.

Assimiler qualité du réel et qualité de la prévision

Une prévision est une estimation d'un résultat futur fondée sur des informations et hypothèses disponibles. Elle peut manquer sa cible malgré des données d'entrée correctes, parce que les hypothèses évoluent. À l'inverse, une prévision proche du résultat ne démontre pas que les sources sont fiables. Séparer les incidents de données des erreurs de modèle ou d'hypothèse permet d'agir sur la bonne cause.

Un KPI, ou indicateur clé de performance, est une mesure retenue pour suivre un objectif et orienter l'action. Pour la qualité des données, chaque indicateur doit préciser son périmètre, son unité de comptage et sa date de mesure. Si le dénominateur est nul, afficher « non applicable » plutôt qu'un résultat artificiel.

Indicateurs à combiner

• Complétude des enregistrements = nombre d'enregistrements attendus présents / nombre d'enregistrements attendus × 100. La liste attendue doit venir d'une référence indépendante ; sinon, les omissions risquent de rester invisibles.
• Complétude des champs obligatoires = nombre de champs obligatoires renseignés / nombre de champs obligatoires attendus × 100. Ce contrôle ne démontre pas que les valeurs saisies sont exactes.
• Ratio clés distinctes / lignes reçues = nombre de clés distinctes / nombre de lignes reçues × 100. Cette formule suppose qu'une ligne est attendue par clé ; les exceptions doivent être exclues ou traitées séparément.
• Taux de conformité aux règles = nombre d'enregistrements respectant toutes les règles applicables / nombre d'enregistrements contrôlés × 100. Publier aussi les résultats par règle pour rendre les causes compréhensibles.
• Disponibilité à l'échéance = nombre de flux reçus et exploitables avant l'échéance / nombre de flux attendus × 100. Un fichier reçu mais inutilisable n'est pas considéré comme disponible.
• Délai moyen de résolution = somme des durées entre détection et résolution / nombre d'incidents résolus. L'accompagner de l'âge des incidents encore ouverts pour ne pas masquer les problèmes persistants.

Livrables à maintenir

Le dictionnaire des données et le catalogue des contrôles décrivent les règles. Le registre des anomalies conserve les faits, les responsables, les décisions et les preuves de résolution. Le dossier de validation rassemble les rapprochements, les corrections approuvées et les réserves de publication.

Un tableau de qualité doit présenter ces éléments par flux critique. Éviter un score unique qui compenserait une absence bloquante par de bons résultats sur des contrôles secondaires. La lecture doit permettre de décider quoi publier et quoi corriger.

Un EPM, pour Enterprise Performance Management, est un ensemble de processus et de logiciels destiné à planifier, analyser et piloter la performance. Il peut rendre les contrôles plus systématiques en les intégrant aux étapes de collecte, de calcul et de validation. Il ne garantit pas, à lui seul, l'exactitude des sources.

Des fonctionnalités à examiner concrètement

Un EPM peut centraliser les référentiels, encadrer les saisies, contrôler les correspondances et conserver plusieurs versions de données. Des droits d'accès, autorisations accordées aux utilisateurs selon leur rôle, limitent les modifications non prévues. Un workflow, enchaînement organisé de tâches et de validations, permet de distinguer les données reçues, corrigées, approuvées et publiées.

Selon le produit, les modules et la configuration, le dispositif peut aussi proposer des journaux de chargement, des contrôles de cohérence, des commentaires associés aux anomalies et une trace des modifications. Il faut vérifier si cette trace couvre seulement les actions dans l'application ou également les transformations effectuées en amont.

Des éditeurs à considérer selon le besoin

OneStream et CCH Tagetik proposent des environnements de gestion financière dans lesquels les processus de collecte et de validation peuvent être structurés. Oracle EPM couvre notamment des usages de planification et de consolidation, celle-ci étant le regroupement des comptes de plusieurs entités selon des règles définies. Anaplan propose une plateforme de planification et de modélisation dont les règles et processus peuvent encadrer les données utilisées.

D'autres solutions, comme SAP Analytics Cloud, Pigment, Board ou Workday Adaptive Planning, peuvent être étudiées selon le périmètre. Le choix doit reposer sur une démonstration avec les anomalies réelles de l'entreprise : doublon, code inconnu, donnée manquante et correction après validation. Vérifier les possibilités disponibles, les compléments nécessaires et les responsabilités hors outil est plus utile qu'un classement général.

La maturité se juge sur la capacité à prévenir, expliquer et traiter les anomalies, pas sur le seul équipement logiciel. Une organisation peut disposer d'une plateforme centralisée tout en conservant des définitions contradictoires et des corrections informelles.

Débutant : la qualité dépend des personnes

Les contrôles sont surtout manuels, souvent réalisés juste avant la publication. Les fichiers circulent sans statut clair et les corrections reposent sur la mémoire des contrôleurs. Les désaccords se règlent en recherchant la personne qui connaît la source. Les anomalies récurrentes sont réparées, mais leur cause n'est pas toujours traitée.

Le signe distinctif est la difficulté à reproduire un résultat sans son auteur. La priorité consiste à identifier les sources faisant autorité, formaliser les principales définitions et conserver un registre commun des anomalies. Automatiser immédiatement tous les traitements risquerait de figer des pratiques encore ambiguës.

Intermédiaire : des règles partagées et vérifiables

Les données critiques ont un responsable, les contrôles sont documentés et les publications disposent d'un statut explicite. Les référentiels et leurs changements sont suivis. Les anomalies bloquantes sont distinguées des réserves acceptables, avec une validation conservée.

Le signe distinctif est la possibilité d'expliquer un résultat et de retrouver les corrections sans dépendre d'une seule personne. La priorité devient la prévention : corriger les causes récurrentes, élargir la couverture des contrôles et tester les modifications de traitement avant leur utilisation.

Avancé : une qualité pilotée selon les risques

Les contrôles suivent les flux critiques de leur origine à leur utilisation. Les changements de définition ou de source déclenchent une analyse des conséquences. Les équipes suivent les incidents ouverts, leur récurrence et leurs effets sur les décisions, plutôt qu'un simple volume d'alertes.

Le signe distinctif est la capacité à anticiper les zones fragiles et à encadrer les exceptions. Ce niveau n'implique pas l'absence d'erreurs : il implique qu'elles soient détectées, expliquées et traitées sans correction invisible. La priorité reste l'adaptation des règles aux nouveaux usages.

• [ ] Quelle décision chaque donnée critique doit-elle éclairer, et que se passerait-il si elle était erronée, absente ou disponible trop tard ?
• [ ] La définition de chaque mesure précise-t-elle sa période, son périmètre, son unité et les événements économiques qu'elle représente ?
• [ ] Une source faisant autorité est-elle désignée pour chaque information, avec une règle d'arbitrage lorsque plusieurs sources divergent ?
• [ ] La granularité attendue et la clé d'identification permettent-elles de distinguer un vrai doublon de plusieurs lignes légitimes ?
• [ ] La liste des données attendues est-elle connue indépendamment du chargement reçu, afin de détecter les omissions ?
• [ ] Les valeurs absentes, les valeurs numériques égales à zéro et les données non applicables sont-elles distinguées dans les traitements et les restitutions ?
• [ ] Les codes et correspondances sont-ils validés, datés et compatibles avec les périodes analysées ?
• [ ] Les contrôles couvrent-ils les montants, les lignes, les périodes et les classements, plutôt qu'un seul total général ?
• [ ] Chaque règle indique-t-elle sa formule, ses exclusions, sa tolérance et la conduite à tenir lorsqu'elle échoue ?
• [ ] Des essais démontrent-ils que les anomalies sont détectées et que les situations légitimes ne sont pas rejetées ?
• [ ] Chaque incident possède-t-il un responsable, une échéance, une cause identifiée et une preuve de résolution ?
• [ ] Les corrections locales sont-elles approuvées et conservées sans effacer les données initialement reçues ?
• [ ] Les conditions de publication précisent-elles les anomalies bloquantes et les réserves pouvant être acceptées ?
• [ ] Un lecteur peut-il identifier la version utilisée et comprendre les limites qui influencent l'interprétation du résultat ?
• [ ] Les indicateurs de qualité précisent-ils leur dénominateur et les changements de périmètre ou de règles ?
• [ ] Le dispositif conserve-t-il une trace exploitable des sources, transformations, validations et modifications ?
• [ ] Les anomalies récurrentes donnent-elles lieu à une action durable à la source, et pas seulement à une nouvelle réparation ?

À retenir. La qualité des données de pilotage repose sur des définitions partagées, des contrôles adaptés au risque et des responsabilités explicites. Un résultat utile est un résultat dont on connaît le périmètre, l'origine et les limites. La démarche doit rendre les anomalies traitables, pas seulement visibles.

Qui est responsable de la qualité des données ?

La responsabilité est partagée, mais elle ne doit pas être diffuse. Le métier responsable de la donnée définit son sens et les règles attendues. L'équipe informatique sécurise les échanges et les transformations. La finance valide l'aptitude à l'usage de pilotage. Pour chaque anomalie, une personne doit être chargée de coordonner le traitement et d'obtenir les décisions nécessaires.

Faut-il bloquer une publication dès qu'une anomalie apparaît ?

Non. La décision dépend de l'effet potentiel sur l'usage. Une information critique manquante ou une période erronée peut justifier un blocage. Une réserve limitée peut être acceptée si elle est documentée, approuvée et visible pour les lecteurs. L'acceptation ne doit pas faire disparaître l'incident ni remplacer son traitement durable.

Peut-on commencer sans changer d'outil ?

Oui. Un dictionnaire partagé, des rapprochements documentés et un registre d'anomalies permettent de structurer un premier périmètre. L'outil devient utile pour systématiser les règles, gérer les droits et conserver les preuves. Il faut d'abord savoir ce que l'on contrôle et qui agit ; sinon, la centralisation déplace les ambiguïtés sans les résoudre.

Une donnée valide est-elle forcément exacte ?

Non. Un montant peut respecter le format attendu et rester faux. Un code peut appartenir au référentiel tout en désignant le mauvais produit. La validité vérifie la conformité à une règle ; l'exactitude exige des éléments permettant de confirmer la réalité représentée. Il faut donc combiner contrôles automatiques, rapprochements et vérifications ciblées.

L'intelligence artificielle peut-elle résoudre le problème ?

L'intelligence artificielle (IA) désigne des techniques permettant à des systèmes d'accomplir des tâches de reconnaissance, de prédiction ou de génération. Elle peut aider à repérer des valeurs inhabituelles ou à orienter un diagnostic. Elle ne remplace ni les définitions métier ni l'approbation des corrections. Ses alertes doivent être évaluées, et une valeur plausible ne doit jamais être confondue avec une donnée vérifiée.