How Meta Used AI to Map Tribal Knowledge in Large-Scale Data Pipelines

Le problème du tribal knowledge à grande échelle

Dans toute organisation technique qui a grandi vite, une partie de la connaissance ne réside pas dans des documents ou des wikis — elle est incarnée dans les personnes. C'est ce qu'on appelle le "tribal knowledge" : la logique métier qui explique pourquoi un pipeline agrège les données d'une certaine façon, pourquoi un seuil de filtre est fixé à telle valeur, pourquoi deux tables sont jointes selon un certain critère. Cette connaissance n'est jamais explicitée parce qu'elle semblait évidente au moment de l'écriture, ou parce que le temps manquait.

Chez Meta, ce phénomène avait atteint une échelle critique. L'entreprise exploite des milliers de pipelines de données construits sur Spark et Dataswarm — son orchestrateur de workflows de données interne. Beaucoup de ces pipelines ont été écrits il y a plusieurs années, par des ingénieurs qui ont depuis changé de poste ou quitté l'entreprise. Résultat : modifier, migrer ou simplement comprendre ces systèmes nécessitait soit de retrouver l'auteur original, soit de passer un temps considérable à décrypter le code ligne par ligne.

Le problème n'est pas uniquement une question de documentation manquante. C'est une question de dette de connaissance organisationnelle : chaque pipeline non documenté est un risque latent — risque d'erreur lors d'une modification, risque de régression lors d'une migration, risque de perte de sens lors d'un changement d'équipe.

Pourquoi l'IA et pas une équipe humaine

La réponse à cette question est arithmétique. Avec des milliers de pipelines à documenter, même en mobilisant une équipe dédiée, le temps nécessaire pour qu'un ingénieur comprenne, résume et documente chaque pipeline individuellement est tout simplement incompatible avec les contraintes d'une organisation en mouvement. Et pendant que l'équipe documente, de nouveaux pipelines sont créés.

C'est là qu'intervient l'IA. Un modèle de langage entraîné sur du code et des données structurées peut analyser le code d'un pipeline, identifier les tables sources, les transformations appliquées, les règles de filtrage et les agrégations, puis produire une description en langage naturel de ce que fait ce pipeline — en quelques secondes. Appliqué à des milliers de pipelines en parallèle, ce qui aurait pris des mois à une équipe humaine peut être accompli en quelques jours de traitement automatisé.

Meta précise que l'objectif n'était pas seulement de produire de la documentation pour les humains. Il s'agissait aussi de créer des représentations structurées et interrogeables de ces pipelines — permettant par exemple de rechercher "tous les pipelines qui consomment la table X" ou "tous les pipelines qui calculent une métrique liée aux revenus".

L'approche technique : extraction, classification, génération

L'équipe de Meta a conçu un pipeline d'analyse en plusieurs étapes.

Extraction statique du code : la première étape consiste à analyser le code source des pipelines Spark et Dataswarm pour en extraire les éléments structurels — tables en entrée, tables en sortie, transformations, jointures, filtres, agrégations. Cette extraction est en grande partie déterministe : elle s'appuie sur des parseurs syntaxiques et des règles d'analyse statique, sans IA.

Enrichissement contextuel par l'IA : la deuxième étape mobilise un LLM pour donner du sens à ces éléments structurels. À partir du code extrait, du nom des tables, des noms de colonnes et des éventuels commentaires présents dans le code, le modèle produit une description en langage naturel du pipeline : ce qu'il fait, à quel domaine métier il appartient, quelles métriques il calcule. C'est à cette étape que le tribal knowledge latent dans le code est explicité.

Classification par domaine : les pipelines sont ensuite classifiés automatiquement par domaine métier — analytics produit, sécurité, finance, infrastructure — en combinant les descriptions générées et les métadonnées disponibles. Cette classification permet de créer un catalogue navigable par les équipes.

Validation et itération : Meta a impliqué des ingénieurs experts pour valider un échantillon des descriptions générées, identifier les cas d'erreur systématiques et affiner les prompts. Ce processus d'évaluation humaine dans la boucle est essentiel pour calibrer la confiance accordée aux sorties du modèle.

Les limites rencontrées

L'honnêteté intellectuelle de l'article mérite d'être soulignée : Meta ne présente pas ce projet comme une solution parfaite. Plusieurs limites sont identifiées.

Certains pipelines ont une logique tellement implicite — des constantes magiques, des noms de colonnes cryptiques, une logique répartie sur plusieurs jobs interdépendants — que même un LLM performant ne peut pas en déduire le sens métier réel sans contexte supplémentaire. Dans ces cas, la documentation générée est techniquement exacte mais sémantiquement vide.

La fraîcheur de la documentation est aussi un défi. Un pipeline documenté aujourd'hui peut évoluer demain. Intégrer la génération de documentation dans le cycle de vie du code — par exemple, mettre à jour automatiquement la documentation à chaque merge request — est un problème d'ingénierie à part entière, non résolu au moment de la publication.

Enfin, la classification automatique par domaine métier atteint ses limites sur les pipelines transverses qui alimentent plusieurs domaines simultanément. La tentation de forcer une classification unique peut introduire des erreurs de catégorisation.

Impact et enseignements

Le bénéfice premier est opérationnel : les ingénieurs qui doivent modifier ou migrer un pipeline ont désormais accès à une description de son intention originale, ce qui réduit drastiquement le temps d'investigation préalable. Les migrations de plateforme — un défi récurrent dans les grandes organisations data — deviennent moins risquées quand on comprend ce que chaque pipeline est censé faire.

L'impact secondaire est organisationnel : la documentation générée sert de base à un catalogue de données interne, qui permet aux équipes data de découvrir quelles données existent, comment elles sont produites et qui les consomme. Ce type de catalogue — souvent appelé data catalog — est une infrastructure critique pour la gouvernance des données, et Meta a pu en construire les fondations à partir de pipelines existants plutôt que de repartir de zéro.

L'enseignement principal pour d'autres organisations est le suivant : l'IA est particulièrement efficace pour les tâches de compréhension et de génération de documentation sur du code existant, car elle combine la capacité à lire du code technique et à produire du langage naturel — deux compétences qui, séparées, ne suffisent pas.