La lente violence des mauvaises données
Le tableur n'a pas crié
Le tableur n'avait pas l'air dangereux. C'est presque toujours ainsi que cela commence. Il se trouvait dans un dossier partagé avec un nom sensé, trois colonnes masquées, deux formats de date, un champ de commentaires devenu un petit roman, et un onglet nommé final qui mentait de la manière traditionnelle. Une équipe l'utilisait pour rapprocher les dossiers clients avant d'alimenter un nouveau flux de travail. Personne n'était imprudent. On vérifiait les totaux. On supprimait les doublons évidents. On demandait à la personne qui avait hérité du fichier de la personne qui avait hérité du fichier. Les réponses étaient assez plausibles pour continuer.
Trois mois plus tard, le préjudice est apparu, mais pas comme un événement unique. Un client a dû fournir des documents déjà remis. Un autre a été orienté vers la mauvaise file de service. Un signal de risque est apparu sur un dossier parce qu'un compte fermé semblait encore actif. Un agent du support a passé vingt minutes à s'excuser pour un système qui insistait sur une ancienne adresse. Un responsable a constaté un débit légèrement meilleur et une confiance légèrement moindre. Aucun de ces incidents ne semblait assez important pour arrêter le programme. Ensemble, ils étaient le programme.
Les mauvaises données sont souvent décrites comme un inconvénient technique. Champs manquants, codes incohérents, lignes en double, enregistrements obsolètes, libellés faibles. Ce langage est exact et trop étroit. Les mauvaises données deviennent une violence lente lorsque de petites erreurs transfèrent silencieusement le coût à des personnes qui ne les ont pas créées. Elles obligent les citoyens à prouver ce que l'institution a oublié. Elles obligent les employés à réparer ce que le pipeline a déformé. Elles obligent les clients à se répéter. Elles obligent les auditeurs à reconstruire le sens après qu'il a été jeté. Elles donnent aux modèles une apparence incertaine, biaisée ou stupide alors qu'ils reflètent en partie une défaillance de tenue des dossiers.
La violence est lente parce que les dégâts sont répartis. Aucune ligne ne prend de responsabilité. Aucun tableau de bord n'admet la dette. Le système continue de fonctionner et semble donc réussi de loin. Le préjudice se manifeste dans les appels supplémentaires, les demandes rejetées, les lettres erronées, les accès refusés, le personnel frustré, la réputation endommagée et les décisions qui deviennent plus difficiles à contester parce que le dossier a appris à paraître officiel. Les mauvaises données n'ont pas besoin de drame. Elles ont de la patience.
La qualité n'est pas la propreté
La qualité des données est souvent réduite à leur propreté, comme si l'objectif était une table sans miettes visibles. La propreté aide. Les formats standard, les valeurs valides, les champs complets, les lignes dédupliquées et les plages raisonnables sont nécessaires. Mais un jeu de données propre peut tout de même être inadapté à la tâche. Un champ peut être parfaitement formaté et sémantiquement cassé. Une date peut être valide et obsolète. Une étiquette peut être cohérente et injuste. Un enregistrement peut être complet parce que quelqu'un a remplacé inconnu par non, ce qui explique comment beaucoup de petits désastres se mettent sur leur trente-et-un.
La qualité, c'est l'aptitude à un usage, avec des preuves à l'appui. Le même enregistrement peut être suffisant pour envoyer une newsletter, insuffisant pour une décision de crédit, dangereux pour un modèle de triage médical et hors de propos pour une évaluation de politique publique. Le contexte décide. Qui a créé l'enregistrement. Selon quelle règle. Pour quelle tâche. Avec quelle méthode de mesure. À quelle fréquence il est mis à jour. Quelles omissions sont attendues. Quelles valeurs sont déduites. Quelles valeurs sont fournies par l'utilisateur. Quelles transformations ont eu lieu en cours de route. Sans ce contexte, la qualité devient une humeur et le tableau de bord devient de la décoration intérieure.
L'IA rend cette distinction plus difficile parce que les modèles ont faim d'échelle. L'échelle a un effet séduisant sur les organisations. Un grand jeu de données peut amener les gens à cesser de se demander si les lignes signifient encore ce qu'ils pensent qu'elles signifient. Plus de données peuvent couvrir le bruit statistiquement, mais elles peuvent aussi propager plus loin une hypothèse erronée. Si une étiquette a été produite par une équipe surchargée, un million d'étiquettes peuvent vous donner une très grande mesure de la surcharge. Si un champ manquant signifie refusé dans un système et inconnu dans un autre, les fusionner crée une catégorie qui devrait porter un gilet de signalisation.
La vieille expression garbage in, garbage out est toujours utile, mais elle est trop optimiste. Les systèmes modernes peuvent transformer des déchets entrants en sorties confiantes, en files d'attente priorisées, en courriers automatisés, en scores de risque, en rapports de gestion et en retours de formation qui alimentent le modèle suivant. Les déchets ne sortent plus poliment. Ils circulent, apprennent l'organigramme et se font inviter aux comités de pilotage.
Le défaut par défaut devenu politique
De nombreuses défaillances de données commencent par une valeur par défaut. Le vide devient faux. Le manquant devient zéro. L'inconnu devient faible risque. L'absence de réponse devient consentement. La dernière adresse connue devient l'adresse actuelle. L'enregistrement le plus récent devient le meilleur enregistrement. Une note en texte libre devient une étiquette parce que quelqu'un devait livrer le tableau de bord. Les valeurs par défaut ne sont pas mauvaises. Les systèmes ont besoin de valeurs par défaut. Le problème survient lorsque les valeurs par défaut deviennent une politique sans être nommées comme telle.
Une valeur par défaut est une décision sur l'incertitude. Elle dit ce que l'organisation fera lorsqu'elle ne sait pas. Cette décision peut être inoffensive dans un flux de travail à faible impact et inacceptable dans un flux à conséquences importantes. Si une préférence marketing est vide, une valeur par défaut prudente peut simplement éviter un message. Si un champ d'éligibilité à une prestation est vide, le traiter comme non peut refuser un soutien. Si un champ d'allergie clinique est vide, le traiter comme aucune n'est pas un choix de données. C'est une très mauvaise journée qui arrive en avance.
Une bonne gouvernance des données force les valeurs par défaut à sortir de l'ombre. Elle distingue inconnu, non applicable, non collecté, refusé, en attente, estimé, hérité, déduit et vérifié. Ces catégories semblent fastidieuses jusqu'à ce que l'alternative transforme une cellule vide en autorité. Un système qui ne peut pas représenter l'incertitude fera souvent disparaître l'incertitude en prétendant la résoudre. C'est efficace de la même manière que balayer du verre sous un tapis est efficace. Le sol est propre. Le pied n'est pas d'accord plus tard.
Le test pratique est simple : un examinateur pourrait-il voir où la valeur par défaut a agi. Si une recommandation de modèle, un itinéraire de flux de travail ou une métrique de rapport dépend d'une valeur par défaut, l'enregistrement devrait le montrer. Si la valeur par défaut change, les résultats précédents devraient rester interprétables. Si des personnes ne sont pas d'accord avec la valeur par défaut, il devrait y avoir un responsable. Sinon, l'organisation n'a pas automatisé une règle. Elle a automatisé une hypothèse qui évite le contact visuel.
Les mauvaises étiquettes font une politique silencieuse
Les étiquettes méritent une suspicion particulière, car elles paraissent souvent plus objectives qu'elles ne le sont. Fraude, haut risque, éligible, conforme, urgent, mauvaise qualité, satisfait, dangereux, résolu. Ces mots compressent le jugement humain, la politique, les habitudes, les incitations, la pression du temps et parfois les préjugés institutionnels dans un champ assez court pour un modèle. L'étiquette circule ensuite comme s'il s'agissait d'un fait. Au moment où elle atteint l'entraînement, l'argument qui l'a créée est généralement déjà rentré à la maison.
Une étiquette peut être fausse parce que l'humain s'est trompé. Elle peut aussi être fausse parce que la consigne était floue, que la politique a changé, que le relecteur manquait de contexte, que la catégorie était trop large, que l'outil encourageait la rapidité, ou que l'organisation récompensait un certain résultat. Une étiquette peut être cohérente et coder quand même une mauvaise pratique. La cohérence n'est pas une vertu. C'est simplement de la répétabilité, et la répétabilité peut répéter la sottise avec une discipline admirable.
Pour l'IA, les étiquettes faibles deviennent plus qu'un bruit de reporting. Elles deviennent la cible que le modèle apprend. Si les décisions antérieures ont été influencées par un accès inégal, des biais historiques, de mauvaises incitations ou des dossiers incomplets, le modèle peut apprendre le tissu cicatriciel de l'institution et l'appeler prédiction. Cela ne rend pas le modèle malveillant. Cela rend la cible d'entraînement insuffisamment examinée. Blâmer le seul algorithme est séduisant, car les algorithmes n'assistent pas aux évaluations de performance.
Une meilleure pratique d'étiquetage n'a rien de glamour. Rédigez des consignes. Enregistrez l'identité ou le rôle du relecteur lorsque c'est approprié. Capturez les désaccords. Échantillonnez pour la qualité. Conservez des exemples de cas limites. Révisez les étiquettes après les changements de politique. Séparez les étiquettes créées pour les opérations de celles créées pour l'entraînement. Nommez l'incertitude. Autorisez les relecteurs à dire impossible à déterminer. Cette dernière option est étonnamment radicale dans les organisations qui préfèrent des colonnes bien nettes au doute honnête.
La duplication n'est pas qu'un gaspillage de stockage
Les enregistrements en double ressemblent à un problème de stockage jusqu'à ce qu'ils rencontrent une personne. Ils deviennent alors des rendez-vous manqués, une éligibilité erronée, un historique fragmenté, des intégrations répétées, plusieurs factures, des scores de risque contradictoires et des lettres qui s'adressent à un seul humain comme à trois clients. La base de données peut penser qu'elle a plus d'enregistrements. La personne, elle, vit l'échec de l'institution à la reconnaître. C'est une catégorie de défaut différente.
L’identité est particulièrement difficile à gérer parce que le monde réel est désordonné. Les personnes changent de nom, d’adresse, d’employeur, de médecin, d’école et de structure familiale. Les entreprises fusionnent. Les actifs se déplacent. Les appareils sont remplacés. Les services renomment leurs programmes, comme si le monde manquait de confusion. Les règles de rapprochement exigent de l’humilité. Trop strictes, elles divisent une même personne entre plusieurs dossiers. Trop souples, elles fusionnent des personnes distinctes en une seule fiction institutionnelle. Ces deux erreurs causent du tort.
Les systèmes d’IA amplifient les problèmes d’identité parce qu’ils s’appuient sur un contexte assemblé. Un résumé de dossier peut omettre un historique pertinent parce que les enregistrements ont été divisés. Un score de risque peut surestimer l’exposition parce que les doublons ont été comptés deux fois. Une recommandation peut citer un dossier appartenant à quelqu’un d’autre après une fusion trop agressive. La récupération peut remonter le mauvais fichier parce que des identifiants ont été réutilisés. Le modèle devient le visage visible d’une couche d’identité qui était discrètement malade.
Une bonne gouvernance de l’identité donne aux doublons un processus, et pas seulement une opération de nettoyage ponctuelle. Elle définit la confiance de rapprochement, les seuils de révision humaine, l’autorité des sources, les droits de fusion et de défusion, les pistes d’audit, les obligations de notification et les voies de correction. Surtout, elle traite la défusion comme une opération de première classe. Les organisations adorent fusionner parce que cela donne l’impression de ranger. C’est en défusionnant qu’elles découvrent si le rangement a cassé la réalité.
L’obsolescence est un problème de gouvernance
Les données ne restent pas vraies parce que personne n’y touche. Certains faits se dégradent. Adresses, situation professionnelle, état de compte, règles juridiques, conditions cliniques, consentement, niveaux de risque, positions de stock, éligibilité aux services, propriété, étalonnage des appareils, statut des fournisseurs. Une valeur obsolète peut passer parfaitement la validation. Elle a le bon type, le code autorisé et la posture professionnelle. Elle est pourtant fausse aujourd’hui.
L’obsolescence est dangereuse parce que les systèmes traitent souvent l’absence de mise à jour comme une preuve de stabilité. Dans de nombreux domaines, le silence signifie que personne n’a vérifié. Un flux source peut avoir échoué. Un client peut ne pas avoir eu de raison de se connecter. Un registre public peut accuser du retard. Un capteur peut être déconnecté. Un service peut encore utiliser l’extraction du trimestre dernier parce que la tâche d’actualisation appartient à une personne actuellement en congé. Les données ne deviennent pas actuelles en restant sagement dans une base.
Chaque champ important a besoin d’un contrat de fraîcheur. Quel âge cette valeur peut-elle avoir pour cet usage. Quelle source la confirme. Que se passe-t-il quand la fraîcheur expire. Le flux peut-il continuer avec un avertissement, exiger une révision humaine, interroger une source en direct, ou s’arrêter. La fraîcheur doit dépendre de l’objectif. Une adresse postale pour une lettre d’information peut tolérer plus d’ancienneté qu’une adresse utilisée pour une notification légale. Un indicateur de risque pour les opérations quotidiennes ne peut pas vivre sur le même calendrier que le rapport annuel.
Les contrats de fraîcheur aident aussi l’évaluation de l’IA. Quand un modèle échoue, les équipes se demandent souvent si le modèle a compris les données. Elles devraient d’abord se demander si les données étaient encore vivantes. Un enregistrement obsolète mais valide est un piège particulièrement désagréable parce qu’il passe les contrôles techniques et échoue face à la réalité. La réalité, comme d’habitude, ouvre moins de tickets que nous le souhaiterions.
Le modèle est accusé pour l'archive
Quand la sortie de l'IA est mauvaise, le modèle est le suspect le plus facile. Il est visible, coûteux, nouveau et parfois merveilleusement trop confiant. Mais beaucoup de sorties ne sont aussi solides que les enregistrements qu'elles peuvent voir. Un modèle invité à résumer un fichier incomplet produira une incomplétude polie. Un modèle invité à classer des cas à partir d'étiquettes incohérentes apprendra l'incohérence avec une excellente posture. Un modèle invité à récupérer une politique à partir d'une base de connaissances obsolète citera le passé comme s'il avait encore accès au bureau.
Cela compte parce que les corrections centrées sur le modèle peuvent faire perdre du temps. Le réentraînement ne réparera pas le consentement manquant. Une fenêtre de contexte plus grande ne corrigera pas les identités en double. Une meilleure invite ne restaurera pas le sens supprimé. Plus d'évaluation n'aidera pas si l'ensemble de test porte les mêmes étiquettes cassées que la production. Le modèle peut encore avoir besoin de travail. Mais la couche de données doit être examinée comme un suspect avec des moyens, un mobile et une longue histoire.
Il y a aussi une commodité politique à blâmer le modèle. Si le modèle est en faute, la correction appartient à l'équipe IA. Si les données sont en faute, la correction peut appartenir aux opérations, au juridique, à la politique, au produit, au service client, à la gestion des dossiers, aux fournisseurs et à la direction. C'est une table plus grande. Les tables plus grandes produisent plus de points à l'ordre du jour. Certaines organisations préfèrent une table plus petite et une explication pire.
Un examen sérieux d'incident commence donc plus tôt. Quelle source portait le fait. Était-elle à jour. Était-elle autorisée. Le sens était-il préservé. L'étiquette était-elle valide pour cet usage. Le comportement de correspondance d'identité a-t-il bien agi. Une valeur par défaut a-t-elle agi. Une correction humaine a-t-elle atteint le système en aval. L'ensemble d'évaluation incluait-il ce type de défaillance. Ce n'est qu'après ces questions que le modèle devrait être invité à se défendre. Il peut encore être coupable. Il ne devrait pas être seul.
La réparation doit atteindre la source
Beaucoup d'organisations ont des processus de correction qui réparent le cas visible mais pas le système de données. Un agent du support met à jour l'adresse pour la lettre d'aujourd'hui, mais l'enregistrement maître reste ancien. Un travailleur social annule l'éligibilité, mais le champ manquant reste manquant. Un médecin corrige un résumé, mais la règle d'extraction continue de produire la même erreur. Une note du service client dit d'ignorer la valeur précédente, ce qui est une façon courageuse mais fragile de gouverner une base de données.
La réparation doit voyager en amont. Si une erreur est trouvée au point d'utilisation, la correction devrait atteindre la source faisant autorité ou au moins créer un état réconcilié avec des preuves. Le système devrait savoir si la correction est locale, temporaire, contestée, vérifiée ou structurelle. Une correction qui ne peut pas être propagée devient un autre morceau de mauvaise donnée. Très efficace, dans le sens sombre.
The repair path should also protect people from becoming unpaid data stewards for institutions. It is reasonable to ask someone to provide missing information once. It is not reasonable to make them correct the same record across five channels because the organisation's systems enjoy independence too much. When people repeatedly supply facts and the institution repeatedly forgets them, the problem is not user friction. It is institutional memory failure.
Good repair creates learning. If many corrections hit the same field, the collection form may be unclear. If many unmerges occur after a matching rule change, the threshold is wrong. If a label is disputed often, the guideline needs review. If stale records drive incidents, freshness contracts are missing. Data quality improves when correction is treated as evidence, not inconvenience.
Bad data is not morally neutral
It is tempting to treat data quality as a back-office concern. The records are messy, yes, but every organisation has messy records. That is true in the same way every building has dust. The question is whether the dust is on a shelf or inside the ventilation system. Once bad data drives automated decisions, prioritised work, AI outputs, reporting, compliance, payments or public services, it stops being back-office housekeeping. It becomes a way power is exercised.
That does not mean every error is a scandal. Serious institutions can make mistakes. The moral question is whether mistakes are visible, correctable and prevented from multiplying. A recordkeeping system that hides uncertainty, resists correction, punishes the person affected with repeated proof, and keeps using derived errors is not merely untidy. It is unfair in a durable way.
There is no single cure. Data work is local, domain-specific and occasionally humbling. But the posture is clear. Treat important fields as decisions with owners. Make uncertainty representable. Keep provenance close. Attach freshness to purpose. Audit labels. Govern identity. Propagate corrections. Measure repair burden, not only processing speed. When AI is involved, test the data path as hard as the model path. The records are not scenery. They are part of the machinery.
The spreadsheet did not shout because spreadsheets rarely do. The system did what systems do: it converted quiet assumptions into louder consequences. The lesson is not that all data must be perfect before work can begin. That would end civilisation, or at least Tuesday planning. The lesson is that bad data should not be allowed to act with authority while remaining cheap, invisible and someone else's problem. Slow violence becomes slower when nobody names it. It becomes smaller when the record finally has to answer for itself.