On a migré notre scheduler Airflow vers Kubernetes cette année. Techniquement, ça s'est bien passé. Le KubernetesExecutor tourne, les pods se lancent correctement, la conso de ressources est plus fine qu'avant. Si je m'arrête là, c'est une migration réussie de plus dans une liste de migrations réussies.
Sauf que le vrai problème n'était pas dans les logs de déploiement. Il était ailleurs, et il a mis plusieurs semaines à devenir visible.
Ce qu'on a découvert en touchant des DAGs qu'on ne touchait jamais
Une migration d'exécuteur, ça oblige à repasser sur chaque DAG. Pas juste pour changer la config, mais pour vérifier que rien ne casse une fois isolé dans son propre pod, avec ses propres ressources, sans les raccourcis que permettait le vieux setup (des dépendances de fichiers locaux, des variables d'environnement partagées entre workers, des trucs qu'on ne remarque jamais tant qu'on ne change rien).
C'est en faisant ce passage DAG par DAG qu'on est tombés sur un problème qui n'avait rien à voir avec Kubernetes : un paquet de nos pipelines dépendaient de données dont personne n'était clairement propriétaire.
Pas des silos au sens classique, avec une équipe qui garde jalousement son schéma et refuse l'accès. Rien d'aussi net. Juste des pipelines qui tournaient depuis trois, quatre ans, écrits par quelqu'un qui avait changé d'équipe depuis longtemps, lisant une table dont la doc datait d'avant une refonte produit, sans SLA, sans owner dans notre catalogue (quand on avait un catalogue), sans personne à qui poser la question "est-ce que je peux faire confiance à cette colonne".
Ce genre de dette ne se voit pas tant qu'on ne touche à rien. Elle tourne, elle produit un résultat, ce résultat alimente un dashboard ou un modèle en aval, et tout le monde suppose que c'est fiable parce que ça n'a jamais explosé. Le jour où on doit toucher le pipeline pour de vrai, c'est-à-dire comprendre exactement ce qu'il fait et pourquoi, on découvre qu'on ne peut pas répondre à des questions basiques sur une donnée qu'on utilise depuis des années.
L'infrastructure moderne ne répare pas une gouvernance bancale, elle l'expose
C'est le point qui m'a le plus marqué dans cette migration. Kubernetes n'a rien cassé. Il n'a fait qu'obliger à regarder d'un peu plus près quelque chose qu'on évitait de regarder.
C'est même plutôt logique en y réfléchissant. Une infra plus moderne, c'est en général plus d'isolation, moins de comportements implicites hérités d'un vieux setup, plus de rigueur sur ce qui est réellement déclaré comme dépendance. Tout ce qui reposait sur du flou, des suppositions ou de la mémoire d'équipe finit par remonter à la surface au moment où on formalise l'infrastructure. Ce n'est pas la migration qui crée le problème. Elle enlève juste le tapis sous lequel il était.
Et c'est là qu'on comprend un truc simple, qu'on sait en théorie mais qu'on redécouvre à chaque fois en pratique : moderniser l'infra ne répare rien de la gouvernance data. Ça l'expose, plus vite et plus fort qu'avant, parce que d'un coup on n'a plus le choix de l'ignorer.
Le parallèle avec le AI First
Le débat "AI First" en ce moment me fait penser exactement à ça. Beaucoup d'entreprises veulent déployer des agents IA, des copilots, de l'automatisation poussée, sur des fondations data qu'elles n'ont jamais vraiment auditées. On demande à un agent de synthétiser, de décider, de déclencher des actions à partir de données dont, en interne, personne ne pourrait dire avec certitude si elles sont à jour, complètes, ou possédées par quelqu'un capable d'en répondre.
Une IA n'invente pas la fiabilité que la donnée n'a pas. Elle l'amplifie dans les deux sens. Si la donnée est bonne, l'agent devient un vrai levier. Si la donnée est bancale, l'agent produit des réponses confiantes et fausses à une vitesse qu'aucun humain n'aurait avant.
Le problème, c'est que ce genre de dette ne se voit pas non plus tant qu'on ne pousse pas dessus. Un agent qui répond correctement 9 fois sur 10 sur une base de données mal gouvernée donne l'illusion que tout va bien, exactement comme nos vieux DAGs Airflow tournaient sans encombre jusqu'au jour où on a dû vraiment les regarder.
Avant de choisir l'outil, se poser la bonne question
Avant de se demander quel outil IA déployer, la vraie question c'est souvent : est-ce qu'on sait déjà répondre à "qui possède cette donnée, et peut-on lui faire confiance" ? Si la réponse est non pour une part significative de ce qu'on prévoit de brancher à un agent, le vrai chantier n'est pas le choix du LLM ou du framework d'orchestration. C'est un chantier de gouvernance, beaucoup moins excitant à annoncer, mais c'est celui qui détermine si tout le reste vaut quelque chose.
Concrètement, ce qu'on a mis en place après cette migration, et que je recommande avant tout projet IA sérieux :
- Un owner par dataset critique, nommé, pas une équipe vague. Si personne ne peut être identifié en moins de trente secondes, c'est un signal.
- Des métadonnées d'ownership directement dans le code, pas dans un wiki qui prend la poussière. Chez nous ça passe par les
metade dbt, avec un owner et une fraîcheur attendue par modèle. - Une politique claire pour les pipelines orphelins. Un DAG sans owner identifiable depuis plus de six mois devrait être un candidat à la dépréciation, pas un mystère qu'on laisse tourner par prudence.
- Un monitoring de fraîcheur, pas juste de succès d'exécution. Un DAG qui termine sans erreur ne veut pas dire que la donnée qu'il produit est encore pertinente.
Rien de spectaculaire là-dedans. C'est même plutôt ennuyeux comparé à annoncer qu'on déploie des agents partout. Mais c'est le travail qui, dans mon expérience, détermine si le reste tient debout ou pas.
Ce que je retiens
La migration technique s'est bien passée parce qu'on a suivi une méthode connue : DAG par DAG, tests, rollback prêt, observabilité en place avant de basculer. Le vrai chantier, celui de la gouvernance des données qu'on avait laissé s'accumuler pendant des années, n'a pas de raccourci équivalent. Il faut juste accepter de le regarder avant qu'un outil plus rapide, IA ou pas, ne nous force à le découvrir en production.