Ben Lorica chez Gradient Flow a nommé le problème central : « Un mode de défaillance récurrent dans les workflows agentiques est celui où un agent a accès aux données mais n’a pas la logique métier pour les interpréter. » C’est le « fossé de contexte ». Le code applicatif dispose de tests qui vérifient la correction — si une fonction doit renvoyer 42 et retourne 41, le test échoue. Les transformations de données dépendent du sens métier : le « Chiffre d’affaires » est calculé différemment par la Finance et par les Ventes ; les NULL signifient des choses différentes selon les tables ; les dimensions à variation lente nécessitent de comprendre l’état historique par rapport à l’état actuel. Les critères de correction vivent dans les esprits des personnes, pas dans un système que l’IA peut interroger.
Ce que l’IA ne peut pas savoir
Tristan Handy, fondateur de dbt Labs, a identifié les tâches qui résistent à l’automatisation dans un article de mars 2025 : « Concevoir collaborativement des modifications des assets de données existants pour répondre à de nouvelles exigences », et des questions comme « quels sont les cas limites à connaître pour calculer le coût des marchandises vendues ? » Ces questions requièrent une connaissance organisationnelle qu’aucun schéma ni aucun graphe de lineage ne capture.
Cédric Charlier l’a formulé de manière plus concrète. La plupart des outils IA ne peuvent pas répondre de manière fiable à ces questions :
- Que signifie « Status » ? Est-ce brouillon, intermédiaire, final, annulé ?
- « Amount » est-il net ou brut ?
- « CustomerID » pointe-t-il vers la version actuelle ou une dimension à variation lente ?
Ces questions ont des réponses définitives dans chaque organisation. Mais les réponses ne sont écrites nulle part où l’IA puisse y accéder. Elles existent comme savoir accumulé au fil des années de travail avec les données, transmis dans des conversations d’intégration, des fils Slack, et des commentaires de revue de code du type « ah, en fait, ce champ ne signifie pas ce que vous pensez ».
Un commentateur sur Data Engineering Weekly a donné l’exemple qui rend cela viscéral pour quiconque a travaillé avec des systèmes d’entreprise : « Dans le monde SAP, un champ comme PRCTR se comporte différemment selon les codes sociétés. Certains types de documents dans ACDOCA doivent être exclus pour des scénarios de reporting spécifiques. Cette connaissance est tacite. » On ne peut pas l’encoder dans un fichier CLAUDE.md parce que personne ne l’a entièrement mis par écrit. Elle existe sous forme de jugement.
Pourquoi l’ingénierie des données est plus difficile que l’ingénierie applicative pour l’IA
Cela mérite d’être compris structurellement, pas seulement anecdotiquement. Le code applicatif et le code de transformation de données se ressemblent — les deux sont du code, les deux peuvent être générés par l’IA — mais leurs propriétés de vérification sont fondamentalement différentes.
Le code applicatif est auto-vérifiable. On écrit un test qui affirme le comportement attendu. Si le comportement change, le test échoue. Les critères de correction sont encodés dans la suite de tests.
Le code de transformation de données dépend d’un sens externe. Une instruction CASE WHEN status = 'active' n’est correcte que si on sait ce que « active » signifie dans le contexte de ce système particulier. Cela inclut-il les comptes en période d’essai ? Les comptes payants qui ne se sont pas connectés depuis un an ? Le SQL est syntaxiquement identique quelle que soit la réponse. Seul le contexte métier rend une interprétation correcte et l’autre erronée.
Cette asymétrie signifie que l’IA peut écrire du code de transformation de données syntaxiquement parfait, logiquement cohérent, et complètement incorrect d’un point de vue métier. Les recherches sur les modes de défaillance le confirment : 97 % du SQL incorrect généré par IA s’exécute sans avertissement.
Les dépendances inter-systèmes aggravent le problème. Un stack de données moderne implique des transformations dbt, des connecteurs Airbyte ou Fivetran, du stockage cloud, des limites de taux d’API, des outils d’orchestration et des plateformes BI. Chaque système a ses propres conventions, limitations et modes de défaillance. L’IA ne peut pas raisonner sur le flux de bout en bout — ce qui se passe quand la limite de taux d’API déclenche un chargement partiel, qui cause le traitement incremental d’une moitié seulement des lignes attendues, qui fait chuter une métrique en aval de 50 %.
Databricks a signalé que plus de 80 % des nouvelles bases de données sont désormais lancées par des agents IA. Mais comme ils l’ont noté, un SQL « suffisamment proche » « cesse d’être acceptable dès lors que le logiciel prend des décisions ». La marge d’erreur se réduit à mesure que le code généré par IA passe des notebooks d’analyse aux pipelines de production qui alimentent des décisions automatisées.
Le problème du savoir tacite
La version la plus profonde du fossé de contexte est le savoir tacite — l’expertise que son détenteur ne sait même pas posséder. Un ingénieur données expérimenté ne pense pas consciemment « je devrais vérifier si cette jointure modifie la granularité ». Il le vérifie… automatiquement. C’est le résultat d’avoir été brûlé suffisamment de fois par des explosions de granularité pour que la vérification devienne instinctive.
Ce savoir tacite est ce qui rend l’exemple SAP si puissant. Personne ne s’est assis pour écrire « PRCTR se comporte différemment selon les codes sociétés » dans un système de documentation. Les personnes qui le savent l’ont appris en rencontrant des résultats incorrects, en traçant le problème, et en construisant des modèles mentaux de la façon dont le système fonctionne réellement (par opposition à la façon dont le schéma suggère qu’il fonctionne).
L’IA n’accumule pas de savoir tacite. Chaque conversation repart de zéro. Même avec des fichiers d’instructions structurés, on encode des connaissances explicites — les choses que quelqu’un a pensé à noter. La couche tacite, le « ah, aussi, ne faites pas confiance au champ order_date pour les enregistrements antérieurs à 2019 parce qu’on a migré depuis l’ancien système et les dates ont été altérées » — reste inaccessible à moins que quelqu’un ne la convertisse en documentation explicite.
C’est un vrai goulot d’étranglement, pas un théorique. Chaque organisation possède des dizaines de ces règles tacites. La plupart en ont des centaines. Celles qui sont notées sont généralement celles qui ont causé les incidents de production les plus douloureux. Les autres vivent dans les esprits des personnes qui sont là depuis assez longtemps pour les connaître.
Réduire le fossé
Le fossé de contexte n’est pas un problème qu’on résout une fois. C’est une discipline continue.
La documentation comme facilitateur de l’IA. Tiger Data a constaté que l’ajout de catalogues sémantiques — des descriptions générées par LLM de ce que signifient les tables et les colonnes — améliorait la précision de l’IA de 27 %. La documentation systématique n’est plus seulement destinée aux humains. C’est l’entrée principale qui rend l’IA utile.
Les fichiers de contexte structurés. La principale source d’erreurs de Claude Code était le désalignement avec les conventions. La solution était CLAUDE.md — un fichier qui indique à l’IA comment ce projet spécifique fonctionne. Le modèle se généralise : chaque élément de contexte métier qu’on peut encoder dans un fichier que l’IA lit automatiquement est un mode de défaillance de moins.
Le contexte comme pratique d’équipe. Les organisations qui tireront le meilleur parti de l’IA sont celles qui traitent la documentation du contexte comme un travail d’ingénierie fondamental, pas comme un projet secondaire. La revue de code devrait demander « avez-vous mis à jour les descriptions de colonnes ? » de la même façon qu’elle demande « avez-vous ajouté des tests ? »
Rien de tout cela n’élimine le fossé de contexte. Cela le réduit. Le fossé résiduel — le savoir véritablement tacite, les cas limites que personne n’a documentés, les interactions inter-systèmes trop complexes à décrire — reste le domaine des humains expérimentés. C’est pourquoi la discipline émergente de l’ingénierie du contexte importe : c’est la pratique systématique de structurer ce que l’IA doit savoir.