Au-delà du code : l’architecture multi-agents est la prochaine frontière de notre gouvernance IT

Tommy Lambert, Directeur des Systèmes d’Information & IA chez Converteo, pilote la modernisation et l’unification du SI pour accompagner la croissance. Il allie gouvernance des données, cybersécurité et intégration de l’IA pour automatiser les workflows et maximiser l’efficacité opérationnelle.

À retenir

• L’architecture multi-agents répond au véritable goulot d’étranglement des DSI en automatisant non seulement la génération de code, mais aussi la supervision et la validation de son exécution.
• La gouvernance de ces écosystèmes exige des règles opérationnelles strictes, notamment des rapports de passation structurés pour garantir la traçabilité, ainsi qu’une exécution sérielle du développement afin d’éviter les conflits de code et la surconsommation de tokens.
• Le déploiement de cette approche agnostique permet de tripler la productivité des flux de travail à effectif constant. Elle libère ainsi les ingénieurs des tâches d’exécution à faible valeur ajoutée pour les recentrer sur la conception et la stratégie.

En tant que directeurs de la technologie et de la donnée, nous passons une grande partie de nos journées à résoudre une équation complexe : comment accélérer le delivery de notre feuille de route (roadmap) SI sans exploser nos budgets, sans accumuler de dette technique, et surtout, sans épuiser nos équipes.

Pendant longtemps, nous avons pensé que l’intelligence artificielle générative allait résoudre ce problème en écrivant du code à la place des humains. C’était une erreur de perspective.

Aujourd’hui, l’intelligence brute des modèles n’est plus le facteur limitant. Le véritable goulot d’étranglement de nos directions informatiques, c’est l’attention humaine (Luke Alvoeiro, Factory, 2026). Un ingénieur senior, aussi brillant soit-il, ne peut superviser et valider que deux ou trois chantiers complexes en même temps.

C’est ici que l’approche multi-agents change la donne. Elle ne se contente pas de générer des lignes de code ; elle automatise la supervision de l’exécution.

Structurer le chaos : une taxonomie pour nos choix d’architecture

Lorsque l’on explore l’écosystème des frameworks multi-agents, on fait face à un bruit marketing considérable. Pour piloter nos choix technologiques, nous devons nous appuyer sur une taxonomie claire et pragmatique. Luke Alvoeiro (Factory) identifie cinq modes d’interaction fondamentaux :

• La délégation : Un agent maître distribue des sous-tâches à des agents spécialisés (ex. : la modélisation d’un schéma de base de données). C’est le premier niveau d’automatisation.
• Le couple créateur / vérificateur : Indispensable pour la qualité. L’agent qui écrit le code a un biais naturel à vouloir que son œuvre fonctionne. Confier la revue à un agent tiers, doté d’un contexte vierge, élimine ce biais cognitif.
• La communication directe : Des échanges de pair à pair sans superviseur. Un modèle séduisant sur le papier, mais hautement risqué pour notre gouvernance, car l’état de l’information se fragmente rapidement.
• La négociation : Idéale pour la gestion des ressources partagées (accès API, conflits de fusion de code ou merge conflicts) via des protocoles de compromis non conflictuels.
• La diffusion : La transmission synchrone des règles métier et des contraintes d’architecture à l’ensemble du système, garantissant l’alignement continu des agents.

Le framework « Missions » : piloter l’IT par des contrats de validation

Pour dépasser le stade du simple gadget, une architecture multi-agents doit pouvoir tourner de manière autonome pendant plusieurs jours. C’est ce que propose le concept de « Missions », une approche industrialisée reposant sur trois rôles stricts : un Orchestrateur (qui cadre le besoin et gère le découpage), des Travailleurs (qui exécutent le code sur un contexte propre) et des Validateurs (qui contrôlent la qualité).

Du point de vue du DSI, la véritable rupture réside dans la validation par l’adversaire.
Pour éviter le piège classique du vibe coding — où le code est produit à la volée sans garde-fous —, le framework de Factory inverse le paradigme : le contrat de validation est rédigé par l’Orchestrateur pendant la phase de cadrage, avant l’écriture de la moindre ligne de code de production. La validation devient une barrière de sécurité indépendante, déclinée en deux étapes :

1. La validation de rigueur : Analyse statique du code, linters, typage et revues de code automatisées.
2. La validation comportementale (QA) : Via le computer use, des agents déploient l’application dans un bac à sable (sandbox), simulent le comportement d’un utilisateur réel (clics, remplissage de formulaires) et vérifient la cohérence fonctionnelle de bout en bout.

Gouvernance de la donnée et performance : 2 règles d’or

Pour que ces écosystèmes d’agents s’intègrent dans nos SI sans créer de dérive, deux principes opérationnels doivent être respectés :

1. La passation structurée (Handoffs)

Le plus grand risque des longues sessions d’exécution est la perte de contexte. Les agents ne doivent pas simplement soumettre du code ; ils doivent générer des rapports de passation structurés détaillant les objectifs atteints, les erreurs rencontrées, les codes de sortie des terminaux et les décisions prises. C’est cette traçabilité macroscopique qui permet au système de s’auto-corriger lors des passages de jalons (milestones).

2. Le pragmatisme de l’exécution sérielle

La tentation de la parallélisation massive entre agents de développement est forte, mais elle s’avère contre-productive. Elle génère des conflits de fusion (merge conflicts) insolubles et des incohérences d’architecture qui surconsomment nos tokens. La bonne pratique consiste à exécuter les fonctionnalités de manière sérielle, et à ne paralléliser que les tâches en lecture seule (recherche documentaire, exploration de bases de code, revues de code).

Le Droid Whispering : vers une DSI agnostique et spécialisée

Pour nous, décideurs IT, cette transition marque la naissance d’une nouvelle compétence managériale au sein de nos équipes : le « droid whispering ». Il ne s’agit plus de choisir un LLM unique pour toute l’entreprise, mais de savoir placer le bon modèle au bon poste :

• Les capacités de raisonnement lent et structuré pour l’Orchestrateur.
• La fluidité syntaxique et la rapidité pour les Travailleurs.
• Le respect strict et rigide des instructions pour les Validateurs (en utilisant idéalement un fournisseur de modèle différent des concepteurs pour éviter les biais d’apprentissage).

Cette approche agnostique protège nos organisations du verrouillage technologique (vendor lock-in) et transforme la structure de nos coûts grâce à l’utilisation fine du cache de requêtes (prompt caching).

Quel ROI pour nos organisations ?

Le déploiement en production de ces architectures (parfois testées sur des cycles continus allant jusqu’à 16 jours) montre des résultats chiffrés tangibles :

• Productivité des équipes : Volume de flux de travail actif multiplié par 3 à effectif constant.
• Qualité du code : Taux de couverture de tests atteignant fréquemment 90 %.
• Répartition de l’effort : ~60 % du temps et des tokens consommés se concentrent sur l’implémentation.