Pourquoi votre équipe data va adorer l’IA… quand elle arrêtera de tout casser

Pour beaucoup d’ingénieurs data, l’intelligence artificielle dans la gestion des flux de données se résume à une seule chose : corriger une erreur dans un pipeline. Un développeur ouvre Claude Code, copie-colle des logs, et une pull request est automatiquement générée pour résoudre le problème.

LE PIÈGE DU « SELF-HEALING » : UNE QUESTION DE VOCABULAIRE

Quand on parle de self-healing (auto-réparation), il faut d’abord comprendre qu’on parle en réalité de self-managing (autogestion). Le vrai défi de l’IA n’est pas de remplacer l’humain, mais de s’en passer complètement. Le rêve ultime ? Des pipelines et des flux de travail qui fonctionnent sans aucune intervention humaine. Pourtant, entre cette utopie et la réalité, sept barrières se dressent.

1. L’IA MANQUE DE CONTEXTE : LE SAVOIR DES HUMAINS N’EST PAS DANS LES LOGS

Un agent IA peut corriger une erreur dans un pipeline, mais il ne connaît pas toujours les subtilités du système. Par exemple, dans une entreprise nommée Acme, l’accès à un cluster Kubernetes est réservé à une seule personne, Bob, qui possède une clé d’accès cachée dans AWS Secrets Manager avec un en-tête non standard. L’IA ne connaît pas cette clé et ne pourra donc pas réparer le cluster.

Autre exemple : Analyst Sophie sait que, chez Widgets Incorporated, il est normal de masquer le fait que les ventes sont rapportées en plusieurs devises et d’ajuster les chiffres pour les rendre 10 % plus élevés que la veille. L’IA, elle, ne sait pas comment manipuler ces données.

Parfois, l’IA ne sait même pas qu’il faut relancer une API interne entre 2h47 et 3h12 du matin pour éviter une erreur. Ces exemples peuvent sembler absurdes, mais ils illustrent un point crucial : le savoir-faire pour résoudre ces problèmes réside souvent dans la tête des employés, pas dans les logs ou la documentation écrite.

Comme le disent les data engineers : « Au fond, seuls les humains savent où sont enterrés les corps. »

2. L’INFRASTRUCTURE « ÉLASTIQUE » : UNE QUESTION DE CONTRÔLE

Pour qu’une IA puisse réparer une infrastructure, celle-ci doit être « élastique ». Ce terme ne signifie pas seulement qu’elle peut monter en charge, mais aussi qu’elle dispose d’une API de gestion accessible. Par exemple, une instance EC2 d’Amazon n’est pas élastique, car elle ne peut pas être gérée au-delà d’un certain seuil. Un cluster Kubernetes sur une machine verrouillée n’est pas élastique non plus, car il n’y a pas d’API pour le contrôler.

Les fournisseurs de SaaS ont ici une opportunité en or. En prenant en charge la gestion de l’infrastructure pour les équipes data, ils libèrent ces dernières d’un fardeau technique. Mais cette approche, bien qu’amicale pour l’IA, bute sur un obstacle majeur : la barrière numéro 6, que nous aborderons plus tard.

3. LES DONNÉES NE SE « BRANCHENT » PAS : UN PROBLÈME DE GESTION

Pete, du service financier, a encore écrasé la feuille Google Sheets de planification des opérations et de l’approvisionnement pour les États-Unis. Les prévisions internationales sont brisées, et le pipeline de données échoue. Résultat : il n’y a plus aucune ligne dans usforecastdec_v1, et forecasts_agg est obsolète. L’IA indique que les connecteurs fonctionnent, mais qu’il n’y a pas de données. Elle ne peut rien faire.

Que faire dans ce cas ? Aucune solution n’est parfaite. Toutes les options vont de « mauvaise » à « absurde ». En réalité, la quatrième option ne nécessite même pas d’IA, mais simplement une meilleure coordination d’équipe.

La qualité des données reste la priorité absolue pour un data engineer. Lors des entretiens, une question clé à poser est : « Quelle est la qualité de vos données ? » C’est un facteur déterminant pour la qualité de vie au travail, et pourtant, il est souvent négligé.

4. L’IA DOIT-ELLE MODIFIER LES DONNÉES EN PRODUCTION ? UN DILEMME DE SÉCURITÉ

Prenons l’exemple d’un nouveau contrat de 10 millions de dollars. Peut-être que le chiffre correct est 1 million. Un agent IA équipé d’une clé API Salesforce pourrait facilement corriger cette erreur et relancer le pipeline. Mais est-ce une bonne idée de modifier directement les données en production ?

Les environnements Salesforce sont souvent multiples. Si l’agent modifiait par erreur un contrat valant réellement 10 millions, ce serait catastrophique. Mieux vaut que l’agent modifie d’abord une instance de staging (test) avant de propager les changements.

Pour que cela fonctionne, il faut une structure permettant à l’IA de travailler sur une nouvelle branche. Cette branche doit inclure des clones de données sans copie (zero-copy clones), une approche « Git pour les données », et la possibilité de basculer efficacement vers les données corrigées à la fin.

Sans cette structure, il est difficile de faire confiance à l’IA pour réparer les pipelines de manière fiable. Cela créerait un cauchemar de gouvernance, avec des risques d’accès en écriture non contrôlés sur les données de production.

5. L’INTEROPÉRABILITÉ : LE MAILLON FAIBLE DES SYSTÈMES MODULAIRES

En 2025, des Outils comme Fivetran et dbt ont mis en avant l’infrastructure de données ouverte. Mais attention : il ne s’agit pas d’open source, mais d’une approche appelée « architecture de données modulaire ». Chaque fonctionnalité dispose de son propre outil, comme dans l’exemple ci-dessous.

Un système auto-réparateur ne peut fonctionner que si ses composants sous-jacents le permettent. Les fournisseurs de services doivent fournir des APIs pertinentes pour supporter les principes de cette architecture, ainsi que des fonctionnalités d’auto-réparation.

Prenons l’exemple d’un fournisseur ELT (Extract, Load, Transform) qui subit une défaillance silencieuse : le sous-schéma change, mais les colonnes et les types restent les mêmes. Par exemple, des devises sont désormais rapportées en yens en plus des dollars, mais les colonnes currency et local_value restent identiques.

La bonne solution ? Modifier le job ELT dans son environnement de staging, vérifier le reste du pipeline avec ces données corrigées, puis basculer vers les données désormais correctes. Enfin, remplacer le job ELT qui fonctionnait par erreur.

Beaucoup d’outils ELT ne fournissent pas les APIs nécessaires pour cette fonctionnalité. Pourtant, si vous utilisiez un script Python que vous contrôlez vous-même, ce serait possible. Cela exercera une pression énorme sur les fournisseurs ETL actuels pour qu’ils modifient leurs structures ou disparaissent.

6. L’ORCHESTRATION : LE LIEU IDÉAL… MAIS UNE QUESTION DE SÉCURITÉ

Le lieu logique pour exécuter des agents de réparation est un outil d’orchestration. Cet outil dispose des éléments dont l’agent a besoin. Pourtant, un problème majeur se pose : la sécurité.

Des entreprises comme Cloudflare ont développé des « bacs à sable » (sandboxes) pour les agents. Par exemple, le modèle Fable (récemment banni) peut s’échapper d’un bac à sable et causer des dommages, surtout s’il est attaqué par une injection de prompt. Les outils d’orchestration traditionnels ne sont pas conçus pour gérer les agents de cette manière. Les risques de sécurité sont immenses.

Les charges de travail de l’IA pourraient également empiéter sur celles des données . Il est clair que les agents auront besoin d’accéder aux frameworks d’orchestration. Que ce soit via des orchestrateurs fournis par OpenAI et Anthropic, de nouveaux orchestrateurs avec bacs à sable intégrés, ou une forme d’interopérabilité entre les deux, quelque chose doit évoluer. Car la sécurité prime sur tout.

7. LA SÉCURITÉ : LE CASSE-TÊTE DES PROXIES ET DES MCP

Une approche pour sécuriser les agents consiste à mettre en place un service proxy. Au lieu d’installer les secrets dans le bac à sable, l’agent n’a accès qu’à un nombre limité d’outils ou de MCPs (Model Context Protocols). Le service proxy est le seul à avoir accès aux systèmes externes.

Même si l’agent devient victime d’une attaque par injection de prompt, il ne peut accéder qu’aux endpoints limités par les MCP dont il dispose. Cependant, la configuration de ces services proxy n’est pas évidente. MCP est un protocole complexe, et Cloudflare a récemment lancé Code Mode. Si un agent doit accéder à plusieurs endpoints différents, la configuration des serveurs MCP devient un casse-tête.

Les normes ouvertes devraient s’imposer. Tout agent cherchant à interagir de manière sécurisée avec plusieurs systèmes bénéficierait, du point de vue de la sécurité, d’une interaction avec un service proxy. Ces services existent déjà, mais souvent dans des outils SaaS privés comme Foundry.

Des frameworks pour concevoir des agents devraient également émerger. Dans l’exemple ci-dessus, un seul agent nécessitant une intégration à des centaines de systèmes pourrait ne pas être réalisable, car le contexte requis pour accéder à des centaines de MCP serait trop volumineux.

Si ces défis sont relevés, les équipes data pourront construire un tableau de bord unique pour l’IA. Ce tableau de bord permettrait aux agents IA d’opérer de manière sécurisée, d’exécuter des tâches au moment opportun, et d’avoir le contexte nécessaire pour accomplir leur mission.

LE FUTUR : UNE PRESSION SUR LES FOURNISSEURS POUR PLUS D’INTEROPÉRABILITÉ

Les équipes data qui souhaitent mettre en place une architecture autonome exerceront une pression significative sur les fournisseurs existants pour qu’ils supportent l’interopérabilité. Cela accélérera la consolidation du marché, car des géants comme Salesforce, SAP et ServiceNow déploient leurs propres produits agentiques et studios de données capables de contrôler l’ensemble du processus sans offrir d’interopérabilité.