Un pipeline de données qui prouve lui-même sa justesse

On observe un décalage discret dans la manière dont le monde des données adopte l'IA. La plupart des outils « agentiques » destinés aux ingénieurs de données sont conçus pour accélérer l'écriture de code : il suffit de décrire un modèle pour obtenir une requête SQL en quelques secondes.

Si la rapidité est facilement mesurable, elle ne suffit pas : la rapidité sans confiance ne mène à rien. L'application la plus intéressante de l'IA agentique dans l'ingénierie des données est l'autovérification : un pipeline de données peut tester sa propre logique au fur et à mesure de sa construction, et ces mêmes tests l'accompagnent jusqu'à la mise en production, de sorte que la logique résiste au contact avec les données réelles.

Le secteur a mal évalué cette victoire

Le secteur du logiciel dans son ensemble subit déjà les conséquences d’une optimisation axée uniquement sur la rapidité de génération de code. Plusieurs études montrent clairement que les outils de codage basés sur l’IA ont exacerbé cette tendance :

• Dans Enquête « State of Code » 2025 de Sonar Sur un échantillon de plus de 1 100 développeurs, les outils d’IA généraient une part importante du code validé. Cependant, 96 % des développeurs interrogés ont déclaré se méfier des résultats obtenus, car ceux-ci semblent corrects à première vue tout en masquant des erreurs subtiles. Le temps gagné au clavier se répercutait en aval sous forme de révision et de validation.
• Rapport d'entreprise 2026 a révélé que 43 % des modifications de code générées par l'IA nécessitaient encore un débogage manuel en production après avoir franchi l'étape de préproduction. Une création plus rapide a entraîné un surcoût de vérification, qui s'est fait sentir par la suite.

L'ingénierie des données est confrontée à une version plus complexe de ce problème. Lorsqu'un code d'application est erroné, il génère généralement une erreur manifeste, directement au niveau de l'erreur. En revanche, une erreur de calcul dans un pipeline de données passe inaperçue. Par exemple, un chiffre d’affaires surévalué en raison d’une jointure en double s’affiche sous la forme d’un chiffre « propre » sur un tableau de bord, impossible à distinguer d’un chiffre correct, jusqu’à ce qu’un utilisateur en aval agisse en fonction de celui-ci.

Le coût lié au fait que l'IA génère plus rapidement du code de transformation, sans pour autant que ce code ne gagne en crédibilité, reste caché jusqu'à ce qu'un décideur de l'entreprise prenne une décision sur la base d'un chiffre qui était erroné depuis le début.

Qu'est-ce qu'un pipeline de données auto-vérifiable ?

Dans un pipeline de données traditionnel, un ingénieur définit les transformations, puis rédige des tests pour les valider dans une étape distincte. Un pipeline auto-vérificateur est généré avec ses propres contrôles intégrés, et ces contrôles continuent de s'exécuter sur les données de production après le déploiement.

La vérification a toujours fait partie intégrante de l'ingénierie des données : profilage des colonnes, test des clés avec dbt, vérification des relations entre les tables. Avec un système auto-vérificateur, la nouveauté réside dans l'origine de ces vérifications : elles découlent directement de la logique métier sous-jacente à une transformation et sont générées parallèlement au pipeline, au lieu d'être ajoutées a posteriori par un intervenant humain.

Un système agentique peut répartir le travail de vérification entre plusieurs agents, de sorte qu’aucun agent IA n’évalue son propre travail. Un agent génère une transformation ou un mappage, puis un agent vérificateur distinct l’examine par rapport à exigences métier et peuvent l'approuver ou le renvoyer ; enfin, des agents indépendants vérifient que le modèle est capable de répondre aux questions métier auxquelles il est censé répondre.

Dans l'idéal, la vérification boucle la boucle avec le « copilote » de l'ingénieur : une exécution sur l'ensemble des données de production renvoie les résultats au système agentique, qui procède alors aux ajustements nécessaires.

L'auto-vérification se manifeste dans trois domaines spécifiques :

1. Lorsque le système propose un mappage, il analyse à la fois le nom de la colonne et les valeurs qu'elle contient, et signale tout décalage en cas de divergence entre les deux. Un champ « customer_name » rempli d'identifiants aléatoires est ainsi détecté comme suspect au lieu d'être considéré comme fiable.
2. Chaque transformation générée s'accompagne de contrôles mécaniques qui garantissent sa validité : nombre d'enregistrements vérifié, unicité des clés, catégories couvertes. Ces contrôles sont intégrés au projet dbt ; ils sont donc fournis avec le code et réexécutés sur les données de production bien après la fin de la génération.
3. Lorsque le système se heurte à une lacune dans les exigences métier que les données seules ne permettent pas de combler, il évite de « s'inventer » une réponse. Il transmet à l'ingénieur de données la question exacte à poser aux parties prenantes métier, afin qu'aucune hypothèse ne se transforme en chiffre erroné.

Exemple : analyse des marges entre deux systèmes

Prenons l'exemple d'un distributeur MRO industriel. Celui-ci gère des dizaines de milliers de références, de fixations et de raccords qui transitent par des entrepôts régionaux avant d'être livrés à des entrepreneurs.

Les chiffres d'affaires sont enregistrés dans l'ERP, tandis que les coûts liés à la préparation des commandes, au stockage et à l'expédition de chaque ligne de commande sont gérés dans le WMS. Le directeur financier souhaite connaître la marge par gamme de produits, et cette demande est transmise à l'équipe chargée des données.

La jointure la plus évidente ne prend que quelques minutes à mettre en place : faire correspondre le chiffre d'affaires de chaque commande issu de l'ERP à son coût de traitement issu du WMS, aligner les produits par SKU, puis regrouper par gamme de produits. Le résultat s'affiche clairement et est transmis au tableau de bord. Or, ce résultat est erroné, et le tableau de bord reste identique dans les deux cas :

• L'ERP et le WMS utilisent des identifiants différents pour un même produit. L'ERP suit la référence fabricant, tandis que le WMS suit un code de rayonnage interne. Pour faire le lien entre les deux, une personne crée une table de correspondance indiquant « référence X = code d'emplacement Y ». Cette correspondance est gérée séparément des deux systèmes et se décale à chaque fois que l'entrepôt déplace un produit vers un nouvel emplacement, que le service des achats ajoute une nouvelle référence ou que l'un ou l'autre des systèmes retire un ancien produit.
• Lorsqu'une entrée de mappage est manquante, la jointure entre l'ERP et le WMS supprime la ligne. Lorsqu'une entrée obsolète fait en sorte que deux codes de emplacement renvoient à la même référence, la jointure duplique la ligne. Aucun de ces cas n'est signalé comme une erreur, et le résultat ressemble à un tableau propre comportant un chiffre légèrement erroné.
• Une commande retournée perturbe la correspondance entre le chiffre d'affaires et les coûts. Le système ERP supprime le chiffre d'affaires lié à une commande retournée, mais le coût de traitement reste enregistré dans le WMS, car la préparation et l'expédition ont déjà eu lieu.
• Lorsque la jointure est exécutée, cette ligne de coût « orpheline » ne trouve aucune recette correspondante et est donc supprimée. Le retour efface discrètement à la fois la recette et son coût, ce qui fait que la marge apparaît plus élevée qu’elle ne devrait l’être ; les gammes de produits présentant le plus grand nombre de retours affichent ainsi l’écart le plus important entre la marge déclarée et la marge réelle.

Pour un ingénieur de données travaillant sur des données ERP, cette complexité n'est qu'un lundi comme les autres.

L'application de l'IA à ces données génère un tableau de bord des marges erroné qui donne pourtant l'impression d'être fiable et précis. Un agent de codage peut tenter d'harmoniser les données, supposer que la référence correspond au code de bac, choisir une méthode de gestion des retours et écrire un code SQL propre à partir de ces hypothèses. Ce qu'il ne peut pas faire, c'est vous dire si ces hypothèses étaient correctes.

C'est là toute la différence qu'apporte une compilation auto-vérifiable. Les agents d'une compilation auto-vérifiable peuvent certes harmoniser les deux systèmes, mais ils vérifient également leur propre harmonisation et justifient leur démarche :

• Les agents vérifient la correspondance entre les deux systèmes d'identification à l'aide des données réelles, afin de repérer les entrées manquantes, obsolètes ou celles associant un même numéro de pièce à plusieurs codes de emplacement.
• Ils génèrent des tests qui signalent clairement les échecs lorsqu'une ligne est omise lors d'une jointure ou qu'une clé n'est pas unique, ce qui empêche toute erreur de comptage silencieuse d'apparaître sur le tableau de bord.
• Lorsque les sources ne parviennent pas à s'accorder sur le cheminement d'un retour, elles soulèvent cette divergence en tant que question spécifique que l'ingénieur devra résoudre.

A chaîne de traitement des données à auto-vérification qui signale précisément les points d'incertitude, au lieu de les masquer, offre à l'ingénieur un avantage que l'agent de codage a négligé : une liste précise des lacunes qui nécessitent encore une intervention humaine.

Le résultat examiné par l'ingénieur de données est un code dbt lisible dont il est l'auteur, dans lequel les lacunes sont clairement signalées, plutôt qu'un chiffre apparemment fiable dont il doit établir la fiabilité par une analyse rétrospective.

Les exigences élevées de l'ingénierie des données agentique

Jusqu’à présent, les assistants de programmation et les copilotes basés sur l’IA ont permis d’accélérer l’écriture de code SQL.

Tous les risques qui ralentissent déjà l'ingénierie des données s'aggravent lorsqu'un outil génère du code sans vérifier si le résultat est fiable. Une donnée erronée est alors diffusée plus rapidement, déguisée en fait avéré.

L'autovérification, c'est la correction. Lorsqu'un pipeline de données intègre sa propre vérification, avec des mappages testés sur des données réelles, des contrôles automatiques qui se répercutent en production, et des lacunes métier mises en évidence sous forme de questions plutôt que de suppositions, la confiance ne repose plus sur la révision manuelle de chaque ligne par un humain. C'est ce qui justifie l'investissement en termes de rapidité pour une équipe de données qui évalue des outils autonomes.

Aujourd'hui, n'importe qui peut créer un pipeline de données. La question est de savoir si le système est capable de valider ses résultats.