Vous passez des semaines à ajuster un chatbot IA. Les réponses sont exactes. Les parties prenantes valident, et vous le mettez en production. Trois mois plus tard, le système se trompe avec assurance sur environ un tiers des questions posées par les utilisateurs. Personne n’a modifié le modèle, et personne n’a touché aux prompts. Le monde a évolué, les prix ont changé, une politique a été mise à jour, une spécification produit a livré une nouvelle version, et la base de connaissances sous-jacente n’a pas suivi.

Ce n’est pas une hypothèse. C’est actuellement l’un des modes de défaillance en production les plus courants dans l’IA d’entreprise, et la plupart des équipes d’ingénierie des données ne disposent pas des bons outils pour le détecter, quelle que soit la manière dont le système d’IA récupère les données. Alors que les entreprises passent des pilotes IA à des déploiements de production à grande échelle — Gartner a régulièrement identifié la qualité des données comme l’un des principaux obstacles à l’adoption de l’IA — cette catégorie de défaillance passe du désagrément occasionnel au risque systémique.

La défaillance qui ne ressemble pas à une défaillance

Une application d’IA ne se soucie pas de savoir si elle récupère des informations depuis un vector store, un index documentaire ou un appel API. Quel que soit le mécanisme, rien dans un pipeline de récupération standard ne vérifie si ce qu’il sert est encore correct. Un document tarifaire obsolète est récupéré avec autant d’assurance qu’un document à jour, car le système note la pertinence ou la disponibilité, pas l’exactitude. Un enregistrement auquel il manque silencieusement un champ passe tout aussi proprement qu’un enregistrement complet, pour la même raison.

La défaillance est donc invisible par conception. Des données obsolètes ou incomplètes obtiennent encore un score élevé de pertinence, ou réussissent tous les contrôles pour lesquels un pipeline de données a été conçu. Le modèle répond avec une confiance totale parce que le contexte récupéré paraît faisant autorité. Tous les tableaux de bord que vous surveillez restent au vert. Le système semble fonctionner. Il est simplement faux.

J’ai observé une version similaire de ce phénomène en dehors du contexte de l’IA, dans un pipeline fintech. Un système en amont a modifié un champ sans en informer les utilisateurs en aval. Le pipeline n’a pas échoué ; il a simplement propagé de mauvaises valeurs dans les tableaux de bord, parce que le système vérifiait seulement si la tâche s’était terminée, et non si les données étaient toujours correctes. Le problème n’a émergé que lorsqu’un client a remarqué une incohérence. À ce moment-là, les mauvaises données avaient déjà circulé en aval.

Qu’il s’agisse d’un document devenu obsolète ou d’un champ disparu silencieusement, la forme de la défaillance est la même : l’absence d’erreur ne signifie pas la présence d’exactitude, et sans couches de validation appropriées, rien dans le pipeline ne pouvait identifier le problème. Les enjeux augmentent aussi à mesure que les agents IA passent de la réponse aux questions à l’exécution d’actions — un agent agissant sur la base de prix obsolètes ou d’une politique dépréciée pourrait exécuter une transaction erronée, et pas seulement renvoyer une mauvaise réponse.

Pourquoi c’est un problème d’ingénierie des données

Les équipes confrontées à cette défaillance ont tendance à mal la diagnostiquer, et généralement à deux reprises.

Accuser le modèle : Le premier réflexe consiste à incriminer le modèle, à essayer un autre LLM, à ajuster le prompt. Le véritable problème se situe plus en amont, au niveau de l’ingénierie des données — le même réflexe que dans la défaillance fintech décrite plus haut : une supervision conçue pour le pipeline, pas pour les données.

Accuser la couche de récupération : Une fois le modèle écarté, le réflexe suivant consiste à accuser la couche de récupération ou de contexte, puis à en acheter une meilleure. Le calendrier n’a rien d’une coïncidence. À mesure que les entreprises poussent ces systèmes dans le monde réel de la production, c’est précisément cette lacune qui commence à apparaître, et les fournisseurs y répondent de toutes parts. AWS vient d’entrer dans la course à la « couche de contexte » avec un graphe de connaissances qui apprend à partir de l’usage des agents. Les nouveaux Horizon Context et Cortex Sense de Snowflake ciblent exactement le symptôme par lequel cet article a commencé : des agents qui donnent avec assurance de mauvaises réponses parce que rien ne gouverne la logique métier sous-jacente.

Ces deux réponses sont réelles face à un vrai problème, mais elles se situent une couche au-dessus ; un graphe de connaissances dépend toujours de ce qui l’alimente. Le véritable problème se trouve plus en amont, au niveau de l’ingénierie des données. Les équipes vérifient si une tâche s’est exécutée, pas si les données qu’elle a déplacées sont toujours vraies — un réflexe qui précède l’IA de plusieurs années. La supervision est conçue pour le pipeline, pas pour les données.

Ce qui manque réellement : l’observabilité des données

L’observabilité des données est un concept bien connu qui ne reçoit pas assez d’attention dans sa mise en œuvre concrète. La catégorie elle-même a mûri au cours des dernières années — des entreprises comme Monte Carlo Data et d’autres ont créé des plateformes dédiées, et IBM a acquis Databand en 2022 pour renforcer ses propres capacités d’observabilité des données — mais l’adoption reste inégale, en particulier parmi les équipes qui n’ont commencé que récemment à construire des applications d’IA au-dessus d’infrastructures de données existantes.

La métrique pertinente n’est pas un pourcentage — c’est la couverture : quelle fraction des jeux de données critiques dispose d’une traçabilité réellement interrogeable, plutôt que de n’exister que dans la tête de quelqu’un.

Uber a construit une plateforme dédiée à la qualité et à l’observabilité des données bien avant l’existence de la génération augmentée par récupération. Sa plateforme Unified Data Quality prend en charge plus de 2,000 jeux de données critiques et détecte environ 90% des incidents de qualité des données avant qu’ils n’atteignent les consommateurs en aval.

Netflix a résolu une autre partie du même problème, en construisant un système de traçabilité des données à l’échelle de l’entreprise afin que chacun puisse savoir d’où vient un jeu de données et ce qui l’a touché en chemin. Il cartographie les dépendances entre les topics Kafka, les modèles ML et l’expérimentation, pas seulement les tables d’entrepôt de données. Comme chez Uber, la plateforme a été conçue pour les humains, et elle est désormais devenue plus importante avec l’essor des applications IA/LLM.

À elles deux, Uber et Netflix couvrent deux des quatre éléments qui valent la peine d’être construits. En pratique, je les considère comme quatre dimensions, chacune mesurable selon ses propres termes.

Exactitude : Chaque enregistrement respecte-t-il la structure et les règles prévues — bons types de champs, absence de valeurs nulles inattendues, valeurs dans la plage attendue. Des outils comme Great Expectations et Soda gèrent bien cela : validation automatisée au niveau des lignes et des colonnes au lieu de contrôles manuels après qu’un problème s’est produit. Suivez le pourcentage d’enregistrements qui réussissent la validation à chaque exécution.

Fraîcheur : Les données sont-elles encore à jour par rapport à leur source, et pas seulement à jour au moment de leur dernier contrôle. Suivez le temps écoulé depuis la dernière mise à jour réussie par source, avec un SLA par jeu de données plutôt qu’un seuil unique général, car certaines sources nécessitent un rafraîchissement horaire et d’autres non.

Cohérence : Le même fait est-il lu de la même manière partout où il est stocké ou indexé. Cette défaillance est silencieuse — elle n’apparaît que lorsque deux systèmes alimentés par la même source commencent à diverger. Un contrôle croisé périodique entre destinations en aval, signalant un taux de non-concordance supérieur à un seuil, suffit à la détecter tôt.

Traçabilité : Pouvez-vous remonter de n’importe quelle sortie jusqu’à sa source et chaque transformation qu’elle a traversée — la même question à laquelle Netflix a conçu son système pour répondre.

Rien de tout cela ne nécessite une infrastructure que la plupart des équipes data n’ont pas déjà. Je le sais parce que je l’ai construite, pas seulement parce que j’en ai défendu l’idée.

Chez Socure, les données clients arrivaient dans le format que le client choisissait d’envoyer, et parfois de façon discrètement erronée. Le défi consistait à construire un système capable d’identifier les données incorrectes avant qu’elles ne se propagent en aval. Les mêmes principes s’appliquaient : valider ce qui arrivait, comprendre d’où cela venait et empêcher les mauvaises données de devenir le problème de quelqu’un d’autre.

Great Expectations est devenu une partie de cette fondation : validation du schéma et des plages à l’ingestion, SLA par source pour la fraîcheur, contrôles intersystèmes pour la cohérence et traçabilité au niveau des fichiers. Le tout reposait sur un modèle write-audit-publish, dans lequel les données arrivaient en zone de staging, étaient validées, puis ne passaient en aval que si elles réussissaient les contrôles requis.

Le résultat s’est vu en aval : une meilleure précision dans l’ensemble, dans le reporting, dans les modèles ML et dans la récupération IA construite au-dessus de ces mêmes données.

Que faire lundi matin

Si vous exploitez en production des systèmes d’IA fondés sur la récupération, la question de diagnostic n’est pas de savoir quel modèle essayer ensuite ni vers quelle architecture de récupération migrer. Elle se décline en quatre questions plus ciblées :

1. Les données sous-jacentes sont-elles validées par rapport aux normes exigées par leurs consommateurs ?
2. Quel est le contenu le plus ancien actuellement servi avec un haut niveau de confiance ?
3. Deux fragments de la même source pourraient-ils jamais se contredire dans le même résultat de récupération ?
4. Pourriez-vous retracer son origine s’il s’avérait incorrect ?

Si vous ne pouvez pas répondre à ces questions, la lacune se situe dans le pipeline entre vos systèmes sources et ce que lit votre agent. C’est un correctif d’ingénierie des données, pas un changement de modèle ni une migration de fournisseur.

Que vous construisiez des pipelines de reporting, des systèmes ML ou des agents IA, l’exactitude, la fraîcheur, la cohérence et la traçabilité sont ce qui rend les données fiables. L’IA ne fait qu’exposer des faiblesses qui existent depuis toujours dans l’ingénierie des données.