Habr AI : comment Pipeline Triad monte un pipeline d'agents IA à la place d'une équipe de développement

L'idée d'un développeur IA universel unique cède peu à peu la place à un schéma plus pragmatique : au lieu d'un « super-agent », un pipeline de trios spécialisés, où un agent produit le résultat, un deuxième traque les erreurs et un troisième tranche. C'est ainsi que fonctionne le Pipeline Triad Pattern, un modèle de développement conçu non pour les démonstrations mais pour les tâches d'entreprise typiques, où les exigences, les normes et les règles sont déjà décrites et où l'humain garde la main sur quelques-uns des points les plus coûteux du processus.

Le schéma repose sur trois rôles : Créateur, Critique et Arbitre. Le premier génère un artefact, le deuxième vérifie la logique, la qualité et les risques, le troisième décide de laisser passer le résultat ou de le renvoyer en révision. L'approche part d'une idée simple : les modèles de langage corrigent mal leurs propres erreurs sans contrôle extérieur, il est donc plus fiable de ne pas renforcer indéfiniment un seul agent, mais de bâtir un trio indépendant aux fonctions distinctes. L'auteur du pattern transpose au développement par agents le principe d'entreprise bien connu maker-checker-approver et l'étend à tout le SDLC.

Pipeline Triad n'est pas présenté comme un remplaçant du CI/CD. Les pipelines automatiques continuent de compiler, tester et déployer le code, mais une couche supplémentaire apparaît au-dessus : celle de la délégation aux agents, où les décisions ne suivent pas un script rigide mais tiennent compte du contexte, des règlements et des règles métier.

Le schéma complet compte 14 étapes, de la définition de la tâche jusqu'à la production. Sept sont des étapes d'agents : analyse, développement, code review, tests, régression, sécurité et préparation des artefacts de livraison. Quatre autres points restent aux mains des humains : validation des exigences, approbation de la préparation, confirmation du déploiement et vérification finale avant la production.

À chaque étape, le trio doit fournir non pas une simple réponse textuelle, mais un paquet formalisé : l'artefact lui-même, des critères PASS ou FAIL, le journal des remarques du Critique et la décision de l'Arbitre : valider, renvoyer ou valider partiellement. Le pipeline cesse ainsi d'être un ensemble de prompts pour devenir un processus reproductible avec traçabilité des décisions. L'étape suivante ne démarre pas tant qu'elle n'a pas reçu une entrée valide, ce qui permet de mettre en place des audits, de mesurer la qualité et d'analyser les erreurs a posteriori.

La valeur pratique du pattern se voit mieux sur une tâche typique. Comme exemple, l'auteur prend un endpoint bancaire de gel de compte. D'abord, le trio précise les exigences et les cas limites. Ensuite, des trios distincts écrivent le code, vérifient les droits d'accès, ajoutent des tests de conditions de concurrence, puis lancent la régression et les contrôles de sécurité. Après quoi l'humain se contente de confirmer quelques décisions clés. Dans ce scénario, l'implication humaine est estimée à environ une heure au total, contre deux à trois semaines dans un processus d'entreprise classique.

Côté coût, l'auteur chiffre un passage complet par l'API à environ 42–84 appels au modèle, 1–2 million de tokens en entrée et 200–400 mille en sortie, soit un ordre de grandeur de 6–12 dollars par tâche. Pour des pilotes et des bancs d'essai personnels, un abonnement peut revenir moins cher, mais pour un flux de production stable il faudra tout de même compter les limites, le budget et la consommation réelle de tokens.

Le modèle a toutefois des limites strictes. Il convient bien aux change requests, aux bugfixes, aux tâches CRUD et API, aux intégrations et aux modifications d'infrastructure, là où le domaine est formalisé et où le résultat peut être vérifié par des tests et des artefacts. Pipeline Triad fonctionne le moins bien là où l'incertitude domine : discovery, architecture greenfield sans normes mûres, R&D et grands refactorings inter-équipes.

Les risques sont eux aussi très concrets : un agent peut inventer une règle métier inexistante, un Critique mal réglé laissera passer les erreurs ou rejettera tout en bloc, et le travail en parallèle sur plusieurs tâches se heurtera vite à des conflits de contexte, de migrations et de branches.

La sécurité du pipeline lui-même est un chapitre à part. Si l'on ouvre aux agents l'accès au dépôt, aux secrets et au déploiement sans restrictions strictes, le nouveau processus devient une surface d'attaque supplémentaire. L'auteur insiste donc sur le principe du moindre privilège, des droits séparés par rôle, un audit log complet, un policy engine pour l'usage des outils et le filtrage des données sensibles avant leur entrée dans le contexte du modèle.

Concrètement, l'idée d'une « équipe d'agents » cesse d'être un fantasme d'employé IA universel pour devenir un modèle d'ingénierie plus terre à terre, où l'accélération vient de la spécialisation, d'entrées formalisées et du contrôle aux étapes coûteuses. Mais le texte montre aussi honnêtement les limites de l'approche : elle n'élimine pas les validations organisationnelles, ne règle pas le problème d'un cadrage faible et ne décharge pas de leur responsabilité les profils expérimentés, qui doivent valider le résultat. Si de tels pipelines deviennent un standard de travail, ce sera d'abord dans des domaines d'entreprise prévisibles, où le coût de l'erreur est élevé et où les règles peuvent déjà être transformées en processus vérifiable.