Le 19 octobre 2026, l'équipe d'ingénierie de Meta a publié sur son blog d'ingénierie officiel un retour d'expérience sur la refonte de ses agents de pipelines de données : la couche de contrôle est devenue un orchestrateur mince d'environ 1 300 lignes de code, qui se limite à router le travail et à appliquer des contrôles de fiabilité, sans aucun raisonnement métier, tout en répartissant plus de 20 flux de travail entre 14 sous-agents spécialisés aux contextes isolés. Après cette refonte, la préparation de la configuration d'une nouvelle colonne de données est passée de trois à quatre jours de travail manuel, et environ un jour avec l'ancien système, à moins d'une heure.
Pourquoi l'agent omniscient a échoué le premier
Meta a commencé comme la plupart des équipes : un seul agent chargé de toutes les connaissances métier, avec schémas de configuration, règles de génération de code, exigences de validation et modèles d'alimentation pour plus de 10 sources de données dans un unique contexte. Cela fonctionnait en démonstration, puis les hallucinations ont commencé en production : au-delà d'un certain seuil de contexte, les connaissances supplémentaires dégradaient les performances, et les conventions de nommage comme les modèles de génération de différents sous-systèmes se contaminaient mutuellement. L'équipe a mesuré un taux de réussite de 70 à 80 % pour l'approche à agent unique lorsque les ingénieurs rédigeaient un prompt sur mesure pour chaque tâche, tombant à 10 à 20 % sans cet accompagnement. Une prépublication citée montre le même schéma : les systèmes multi-agents orchestrés ont conservé 65,3 % de précision sur des lots de 80 tâches, là où les agents uniques chutaient à 16,6 %, avec une consommation de jetons jusqu'à 65 fois moindre.
Une seule des sept étapes utilise le grand modèle
L'orchestrateur mince exécute un protocole fixe en sept étapes pour chaque demande : lire le fichier d'instructions du sous-agent concerné, vérifier si la cible existe déjà, recueillir les champs obligatoires auprès de l'utilisateur, découvrir automatiquement ce qui peut être déduit, passer un contrôle de fiabilité, déléguer au sous-agent avec le contexte complet, puis traiter les résultats et les erreurs. Les étapes un à cinq et l'étape sept sont déterministes ; seule la sixième implique un raisonnement de grand modèle, et il a lieu dans un sous-agent isolé ne contenant que ses propres connaissances métier. Chaque sous-agent suit la même structure : sources de connaissances, liste de collecte préalable, étapes d'exécution, modèles de recherche de code et correspondances de dépannage. Plus de 25 fichiers de connaissances sont chargés à la demande, de sorte qu'une mise à jour prend effet dès la session suivante, sans modifier l'orchestrateur. Si un sous-agent échoue, l'orchestrateur réessaie ou escalade, et l'échec ne peut pas corrompre les contextes des autres sous-agents.
Les nouveaux scénarios viennent de modèles de flux, pas de nouveaux agents
L'intégration de colonnes, l'intégration d'événements et la migration de pipelines réutilisent le même vivier de 14 sous-agents, dans des ordres différents. La migration de pipelines était un cas d'usage entièrement nouveau, pourtant l'équipe n'a écrit aucun nouveau code d'agent : un nouveau modèle de flux, enchaînant les agents existants autrement, a suffi à livrer une capacité complète en production. Environ deux tiers des modifications du système passent désormais en production sans retouche humaine notable. Le conseil de Meta aux autres équipes est direct : le routage est une décision déterministe, il ne faut pas le confier à un grand modèle ; tout le raisonnement métier doit descendre dans des spécialistes isolés. Cela rejoint le sujet déjà traité sur ce site, Anthropic consultant des avocats sur les règles des agents : ce qui décide du succès d'agents en production, ce n'est pas un modèle unique plus intelligent, mais des limites et des règles fixées à l'avance.
