csrdready Inscrivez-moi sur la liste d'attente

Kennisbank

Pourquoi un chiffre précis n'est pas la même chose qu'un chiffre fiable

Un chiffre d'émission à trois décimales après la virgule donne une impression de précision. Mais la précision ne dit rien sur la fiabilité. Un nombre peut être calculé jusqu'à la décimale près et pourtant être basé sur une unité erronée, un facteur de conversion périmé ou une estimation que quelqu'un a saisie il y a des années et qui n'a plus jamais été vérifiée. C'est cela, la fausse précision : un chiffre qui paraît plus exact qu'il ne l'est réellement.

Cela ne se produit pas parce que les gens sont négligents. Cela se produit parce qu'un rapport est la dernière étape d'une longue chaîne, et qu'à la fin de cette chaîne, on ne voit plus ce qui s'est passé en chemin. Une feuille de calcul à trois décimales a la même apparence, que la valeur source ait été un chiffre mesuré ou une estimation approximative. Sans règles définissant ce qu'est une valeur valide, cette différence reste invisible.

Ce qu'est une valeur valide

Chaque donnée a des limites à l'intérieur desquelles une valeur est plausible. Une consommation d'énergie par site ne peut pas être négative. Un facteur d'émission ne change pas d'un facteur dix chaque trimestre. Un effectif ne s'écarte pas de plusieurs milliers par rapport au mois précédent sans raison identifiable. Ce ne sont pas des modèles statistiques compliqués, ce sont des limites simples et documentables par donnée.

La question de savoir ce qu'est une valeur valide ne se répond pas de la même manière partout. Ce qui compte comme une plage acceptable pour une donnée est trop large ou trop stricte pour une autre. Ce choix appartient à la donnée elle-même, tout comme la question de ce qu'est une valeur valide et de qui le remarque quand cela dérape. Sans rendre ce choix explicite, chaque valeur entrante est tacitement considérée comme correcte, même lorsqu'elle ne l'est pas.

Ce qu'est un signal

Outre une limite stricte, il existe une deuxième couche : des écarts qui ne sont pas invalides, mais qui sont néanmoins notables. Une valeur qui se situe dans la plage autorisée, mais qui s'écarte fortement du schéma des périodes précédentes, n'est pas erronée, mais constitue un signal que quelqu'un devrait examiner.

La différence entre un rejet strict et un signal est un choix délibéré. Un contrôle de valeur valide bloque ; un signal attire l'attention sans bloquer. Les deux sont nécessaires, et les deux doivent être définis au niveau de la donnée, avec la question de la manière de configurer un écart signal et de qui le remarque quand cela se produit comme point de départ. Sans cette définition, c'est le hasard qui détermine qui remarque une valeur étrange, et quand.

Qui le voit

Une règle sans destinataire est une règle que personne ne lit. Si une valeur sort de la limite ou déclenche un signal, il doit être établi qui en est informé : la personne qui saisit, le data owner, le contrôleur qui traite le chiffre par la suite. Sans cette étape, un écart disparaît dans un fichier journal que personne ne consulte, et une erreur signalée devient une erreur passée inaperçue.

C'est aussi là que de nombreux mécanismes de contrôle s'arrêtent en pratique. Une règle est mise en place, mais personne n'est chargé d'y réagir. La règle existe, l'alerte apparaît, et rien ne se passe. Les contrôles qui doivent accompagner une donnée et qui les voit dépendent de la vue d'ensemble plus large de quels contrôles accompagnent une donnée et qui le remarque si quelque chose dérape. Un contrôle que personne ne voit n'est en pratique pas un contrôle.

Pourquoi cela ne se résout pas avec un seul outil

Il existe des systèmes qui détectent automatiquement les écarts et envoient des alertes. Ces systèmes sont utiles, mais ils ne résolvent rien si les questions sous-jacentes restent sans réponse : qu'est-ce qu'une valeur valide pour cette donnée spécifique, qu'est-ce qu'un signal, et qui est le destinataire désigné. Un outil qui fonctionne sur des règles que personne n'a réfléchies produit des alertes que personne ne prend au sérieux ou des avertissements qui sont systématiquement ignorés. Le résultat ressemble à du contrôle, mais ne l'est pas.

C'est la raison pour laquelle ces questions doivent d'abord être résolues au niveau de la donnée, avant qu'un système ne puisse les exécuter. La règle appartient à la donnée, pas au logiciel qui la surveille par hasard.

Là où cela rejoint d'autres points de blocage

La fausse précision apparaît souvent en combinaison avec un autre problème : des parties de l'organisation qui définissent différemment une même donnée. Si un site comptabilise les mètres carrés de surface de bureau et un autre non, un contrôle de plausibilité des valeurs ne suffit pas, car les valeurs ne sont pas comparables entre elles. Ce que vous faites avec des définitions qui diffèrent selon les entités et comment cela s'articule avec le contrôle des valeurs valides est décrit sur la page consacrée aux définitions divergentes et à la question de contrôle correspondante. Celui qui met en place des règles de qualité sans examiner d'abord cette question de définition risque de contrôler des valeurs plausibles qui, en réalité, ne sont pas comparables entre elles.

Des règles à la vue d'ensemble

Ce scan établit, pour chaque donnée, ce qu'est une valeur valide, ce qu'est un signal, et qui en est le destinataire désigné. Cette vue d'ensemble n'est pas le point final, mais le point de départ : elle indique où aucune règle n'existe actuellement, où une règle existe sans destinataire, et où la définition même d'une donnée crée déjà de la confusion entre les entités. Une fois cette image établie, on peut voir quels contrôles pèsent le plus lourd et où l'attention doit se porter en priorité.

Une fois cette vue d'ensemble établie, une autre question peut être posée : quelle partie du travail actuellement effectué manuellement peut, après cette classification, être transférée à un processus automatisé. C'est à cela que sert le scan de travail de FTE TO AI : il calcule, par tâche, quelle partie du travail peut être reprise par l'IA, non pas comme un remplacement des règles de qualité établies ici, mais comme une étape suivante à la vue d'ensemble qui en résulte.

Marvinde assistent van de Data Readiness Scan

Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.

Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.