Ce que les mauvaises données coûtent vraiment à votre entreprise — et pourquoi les détecter tôt revient moins cher

Un guide non technique du coût économique d'une mauvaise qualité des données — où part réellement l'argent, pourquoi une erreur devient environ dix fois plus chère à chaque étape qu'elle survit, et comment calculer votre propre chiffre au lieu d'emprunter celui d'un analyste.

· 11 min read

Les mauvaises données coûtent de l'argent à quatre endroits : les heures que votre équipe passe à les corriger, les décisions prises de travers à cause d'elles, la confiance qu'elles détruisent dans des rapports auxquels plus personne ne croit, et les clients comme les régulateurs qui les voient avant vous. L'important n'est pas le total — c'est la forme de la courbe. Une erreur détectée à son point d'entrée coûte quelques minutes. La même erreur détectée dans un dossier de conseil d'administration coûte une réunion, un rectificatif et une part de votre crédibilité. La détecter tôt n'est pas une préférence technique : c'est toute l'économie du problème.

Le chiffre que vous avez probablement déjà vu

Gartner a estimé le coût moyen d'une mauvaise qualité des données à environ 12,9 millions de dollars par organisation et par an. Vous trouverez ce chiffre dans la présentation de chaque éditeur d'outils de qualité des données — y compris, désormais, celle-ci.

Considérez-le comme une entrée en matière, pas comme une preuve. C'est une moyenne établie sur des organisations extrêmement différentes, elle date de plusieurs années, et aucun directeur financier n'a jamais approuvé un budget parce qu'un cabinet d'analystes a publié une moyenne. Le chiffre qui fera réellement bouger votre direction financière est celui que vous calculez à partir de vos six derniers mois — et ce chiffre est généralement plus facile à produire qu'on ne le croit.

La partie la plus utile de ces recherches n'est pas le total. C'est le constat, systématique, que le coût d'une erreur croît avec la durée pendant laquelle elle survit.

La règle du 1-10-100

La règle empirique largement utilisée en gestion de la qualité veut que les coûts augmentent d'environ un ordre de grandeur à chaque étape :

Les multiplicateurs exacts ne sont pas l'essentiel et n'ont jamais prétendu être précis. L'essentiel, c'est la forme, et elle résiste à l'expérience de à peu près tout le monde : corriger une fiche client en double au point de saisie est un geste anodin ; démêler six mois d'attribution de chiffre d'affaires dupliquée à travers trois systèmes en aval est un projet.

C'est pourquoi « détectez-le tôt » mérite d'être dit à voix haute. Cela sonne comme un lieu commun. C'est en réalité l'énoncé d'un écart de coût d'un facteur cent.

Où part réellement l'argent

Quatre postes, grossièrement classés par degré de visibilité :

CoûtÀ quoi cela ressemblePourquoi il se cache
RepriseDes analystes qui rapprochent deux chiffres censés concorder ; des ingénieurs qui relancent des pipelines ; une « semaine qualité des données » chaque trimestreNoyé dans les salaires, jamais détaillé
Mauvaises décisionsDu stock commandé sur la base d'une prévision cassée ; une campagne visant une liste mal segmentée ; un recrutement décidé sur un pipeline commercial gonfléImputé à un mauvais jugement, pas à de mauvaises données d'entrée
Perte de confianceDes équipes qui se construisent des tableurs privés parce qu'elles ne croient pas au tableau de bordRessemble à de la culture d'entreprise, coûte comme une infrastructure dupliquée
Défaillance externeFactures erronées, déclarations réglementaires fausses, un client à qui l'on affirme quelque chose d'inexact sur son propre compteComptabilisé seulement quand cela devient un incident

Le premier poste est celui que tout le monde ressent et que personne ne mesure. Si vos analystes passent une journée par semaine à rapprocher des chiffres, cela représente environ 20 % de votre capacité d'analyse consacrée à prouver que les données d'hier étaient justes — un coût qui n'apparaît sur aucune ligne budgétaire, et que vous pourriez quantifier cet après-midi.

Le quatrième poste est celui qui finit en conseil d'administration. C'est aussi celui que la détection précoce élimine presque entièrement, car les défaillances externes proviennent rarement de problèmes exotiques. Elles proviennent de problèmes ordinaires que personne ne surveillait.

Pourquoi les erreurs coûtent d'autant plus cher qu'elles voyagent loin

Une erreur dans une table source est un fait relatif à une table. Une fois passée par votre couche de transformation, c'est un fait relatif à tous les modèles bâtis sur cette table. Arrivée dans un tableau de bord, c'est un fait relatif à chaque décision prise par quelqu'un qui le regardait.

Trois effets se cumulent.

Le rayon d'impact s'élargit. Une colonne défectueuse alimente cinq modèles, qui alimentent vingt tableaux de bord. Corriger la colonne est facile ; retrouver les vingt consommateurs, les prévenir et rectifier ce qu'ils ont déjà fait ne l'est pas.

Les preuves disparaissent. Un doublon détecté le jour de son arrivée peut être rattaché au chargement qui l'a produit. Le même doublon découvert lors d'une revue trimestrielle doit être reconstitué à partir de journaux peut-être déjà purgés, par quelqu'un qui n'était pas là.

La confiance ne se regagne pas à la vitesse où elle se perd. Un seul rapport rectifié vous vaut des mois de gens qui revérifient discrètement vos chiffres dans leurs propres tableurs. Ce coût est réel, permanent, et invisible dans tous les budgets que vous rédigerez.

Calculez votre propre chiffre

Vous n'avez besoin ni d'un modèle de maturité ni d'un consultant. Prenez vos six derniers mois et répondez à cinq questions :

  1. Combien d'incidents de données avez-vous eus ? Comptez tout ce qui a obligé quelqu'un à corriger, relancer ou s'excuser pour un chiffre.
  2. Combien de temps a-t-il fallu pour détecter chacun ? Pas pour le corriger — pour le *remarquer*. C'est généralement la réponse qui surprend.
  3. Combien de temps pour résoudre chacun, en additionnant toutes les personnes impliquées, pas seulement l'ingénieur qui a écrit le correctif.
  4. Combien ont été trouvés par un consommateur plutôt que par vous ? Un interlocuteur métier qui découvre votre erreur relève d'une catégorie différente, et bien plus coûteuse, que vous la découvrant vous-même.
  5. Combien a réellement coûté le pire d'entre eux, en décisions prises, en remboursements émis ou en déclarations corrigées ?

Multipliez les heures par un coût horaire chargé, ajoutez le pire cas, et vous obtenez un chiffre défendable, bâti entièrement sur votre propre historique. Dans la plupart des équipes, le résultat rend la discussion sur l'outillage très courte.

La métrique la plus utile de cette liste est de loin le délai de détection. C'est celle sur laquelle vous avez le plus de prise, celle qui détermine dans quel panier du 1-10-100 tombe une erreur, et celle qu'un outil de surveillance fait bouger directement.

Ce que « détecter tôt » signifie concrètement

La détection précoce n'est pas une culture de la vigilance. C'est un petit nombre d'habitudes concrètes et ennuyeuses.

Contrôlez les données là où elles entrent, pas là où elles sont consommées. La validation a sa place à la frontière — le point où les données arrivent d'un système source ou atterrissent après un chargement — parce que c'est là que le rayon d'impact tient encore dans une seule table.

Écrivez ce que « correct » veut dire, avant d'en avoir besoin. La plupart des incidents de données n'ont rien d'exotique. C'est un champ obligatoire devenu nul, une clé qui s'est dupliquée, une colonne de statut qui a gagné une valeur que personne n'attendait, une table qui ne s'est tout simplement pas mise à jour. Ces attentes peuvent être énoncées à l'avance, en termes simples, par la personne qui possède les données — et une fois écrites, elles peuvent être vérifiées automatiquement, pour toujours, sans effort supplémentaire.

C'est exactement ce qu'est un contrat de données. C'est un accord entre celui qui produit un jeu de données et tous ceux qui en dépendent, rédigé dans un format lisible aussi bien par un humain que par une machine : ces colonnes existent, celle-ci n'est jamais vide, celle-là est unique, cette autre ne contient jamais que ces cinq valeurs, et cette table n'a jamais plus d'un jour d'ancienneté. Catalyst utilise l'Open Data Contract Standard précisément pour cela, afin que l'accord vive dans un format ouvert et portable plutôt qu'à l'intérieur du produit d'un éditeur.

Surveillez la fraîcheur, pas seulement l'exactitude. L'incident de données le plus courant n'est pas une donnée fausse. C'est une donnée *absente* — un chargement qui ne s'est silencieusement pas exécuté, laissant les chiffres de la veille paraître parfaitement valides. Un contrôle de fraîcheur est la règle la moins coûteuse que vous écrirez jamais, et elle attrape une part disproportionnée des incidents réels.

Alertez sur le changement, pas sur l'état. Prévenez les gens quand quelque chose *commence* à échouer. Répéter « toujours en échec » toutes les heures, c'est ainsi qu'un canal finit en sourdine — et un canal en sourdine est pire que pas de canal du tout, parce qu'il donne l'illusion d'une couverture.

Acheminez l'alerte vers celui qui peut la corriger. Une défaillance de qualité qui atterrit dans un canal général est le problème de tout le monde, donc de personne. Elle doit parvenir au propriétaire désigné dans le contrat.

Défendre le projet en interne

Trois façons de présenter les choses qui portent généralement mieux que le coût des mauvaises données lui-même.

Commencez par le délai de détection, pas par la qualité. « Aujourd'hui, nous découvrons nos problèmes de données quand un interlocuteur métier nous écrit, en moyenne onze jours plus tard » est une phrase qui débloque un budget. « Notre qualité des données est mauvaise » est une phrase qui obtient un hochement de tête.

Cadrez le projet sur une décision, pas sur une plateforme. Choisissez les trois jeux de données derrière votre rapport le plus consulté et couvrez-les en premier. Personne n'approuve « surveiller tout ». Beaucoup de gens approuvent « faire en sorte que le tableau de bord du chiffre d'affaires ne soit plus jamais faux ».

Rapportez la couverture, pas les incidents. Une fois la surveillance en place, le chiffre qui montre le progrès est la part des jeux de données critiques sous contrat, et la tendance de la rapidité avec laquelle les défaillances sont détectées. Un nombre d'incidents en baisse est ambigu : cela peut vouloir dire que les choses se sont améliorées, ou que vous avez cessé de regarder.

Par où commencer

  1. Listez vos dix jeux de données les plus utilisés. Pas tous — ceux à partir desquels les gens prennent réellement des décisions.
  2. Pour chacun, demandez au propriétaire ce qui devrait être vrai pour que la donnée soit fausse. Vous obtiendrez quatre ou cinq réponses, et elles seront simples.
  3. Consignez-les dans un contrat et transformez-les en contrôles automatisés.
  4. Exécutez les contrôles à la cadence des données, juste après le traitement qui les charge.
  5. Envoyez les échecs au propriétaire, et seulement au moment du basculement en échec.

C'est une semaine de travail pour la plupart des équipes, et cela fait passer votre erreur type du panier à 100 $ au panier à 1 $. Quel que soit le multiplicateur réel dans votre organisation, c'est là que se trouve le retour sur investissement.

Questions fréquentes

Combien coûte une mauvaise qualité des données à une entreprise ?

Gartner a estimé une moyenne d'environ 12,9 millions de dollars par organisation et par an, mais des moyennes calculées sur une économie entière ne constituent pas la base d'un dossier d'investissement. Calculez le vôtre à partir des six derniers mois : comptez vos incidents de données, les heures passées à détecter et résoudre chacun, et le coût du pire. Ce chiffre est défendable, ce qu'un indicateur emprunté ne sera jamais.

Qu'est-ce que la règle du 1-10-100 en qualité des données ?

Une règle empirique issue de la gestion de la qualité : il en coûte environ 1 $ pour prévenir une erreur, 10 $ pour la corriger une fois qu'elle est dans vos systèmes, et 100 $ pour assumer les conséquences d'avoir agi sur elle. Les multiplicateurs n'ont jamais prétendu être des mesures précises — le point essentiel est que le coût augmente fortement avec la durée pendant laquelle une erreur passe inaperçue.

Pourquoi détecter tôt les erreurs de données revient-il moins cher ?

Parce que le coût d'une erreur croît avec son rayon d'impact. Détectée à la source, elle n'affecte qu'une table et peut être rattachée au chargement qui l'a causée. Laissée en place, elle se propage dans chaque modèle et chaque tableau de bord en aval, les preuves nécessaires au diagnostic s'effacent avec le temps, et les gens prennent des décisions sur sa base. La détection précoce, c'est la différence entre une correction de cinq minutes et un rapprochement de plusieurs semaines.

Comment mesurer le coût des mauvaises données dans ma propre organisation ?

Suivez quatre indicateurs : le nombre d'incidents, le délai de détection, le délai de résolution, et la part de ceux signalés par un consommateur plutôt que trouvés en interne. Multipliez l'effort par un coût horaire chargé et ajoutez les conséquences directes du pire incident. Le délai de détection est le plus actionnable des quatre, parce qu'il détermine le coût final de tous les autres incidents.

Faut-il des ingénieurs pour mettre en place une surveillance de la qualité des données ?

Pas pour ce qui compte le plus. Les règles utiles sont des règles métier — ce champ est toujours rempli, cet identifiant est unique, ce statut ne prend que ces valeurs, cette table se met à jour quotidiennement — et la personne qui les connaît est le propriétaire des données, pas un ingénieur. Catalyst lit automatiquement la structure de votre table et propose un jeu de contrôles de départ : le travail consiste alors à relire et ajuster plutôt qu'à écrire du code.

N'est-ce pas déjà ce que fait notre entrepôt de données ?

Les entrepôts imposent une structure, pas un sens. Ils vous empêcheront de mettre du texte dans une colonne numérique, mais ils accepteront volontiers une commande à total négatif, un client dupliqué quatre fois, ou une table qui n'a pas été mise à jour depuis jeudi. Plusieurs entrepôts très répandus n'appliquent pas du tout les contraintes d'unicité — voyez les remarques sur Redshift et BigQuery, où les clés primaires déclarées ne sont jamais vérifiées. C'est dans l'écart entre « structurellement valide » et « réellement correct » que vivent les incidents de données.