Les démonstrations impressionnent, mais la mise en œuvre réelle pose problème. Un agent fonctionne parfaitement sur une tâche isolée, mais dès qu’on en déploie plusieurs simultanément, les résultats deviennent incohérents : des doublons apparaissent, des conflits surgissent sur les mêmes fichiers, et des décisions prises plus tôt sont ignorées. Le vrai défi ? La coordination.

L’enjeu de la coordination

Quand on fractionne une fonctionnalité entre plusieurs agents, on crée automatiquement des dépendances qui doivent être explicites. Chaque agent agit en fonction de ce qu’on lui donne, donc tout ce qui n’est pas clairement défini dans la structure lui est invisible. Par exemple, si on sépare un service en trois : un agent pour la sécurité (authentification, permissions), un autre pour les données (schémas, migrations) et un troisième pour l’API (endpoints), chaque agent est compétent individuellement. Mais l’agent API ne peut finaliser un endpoint tant que la migration de données n’est pas validée. L’agent sécurité doit revoir toute modification touchant aux permissions avant livraison. Si l’agent données renomme un champ, l’agent API doit en être informé avant de coder sur la version obsolète.

Ces transferts, dépendances et validations constituent le système réel. Ils n’existent pas à l’intérieur d’une boucle individuelle, et ne se créent pas spontanément. C’est à vous de les concevoir.

La visualisation en graphes

Imaginez l’organisation comme un graphe. Chaque agent est un nœud : une unité spécialisée dans une partie du travail. Les connexions entre eux sont les arêtes : transferts, dépendances et étapes de validation qui définissent ce qui doit précéder quoi. Ce graphe tient sur un tableau blanc et inclut un planificateur qui répartit le travail entre spécialistes, des vérificateurs pour contrôler les résultats et toujours une personne pour valider les choix critiques.

Ce qui décide du succès du graphe est plus subtil : ce que chaque agent peut voir (le nœud) et ce qui circule entre eux (les arêtes). Une transmission doit contenir suffisamment de détails pour le prochain agent, et un réviseur doit voir les preuves, pas seulement la conclusion. La même architecture produit des résultats très différents selon ces choix.

Le socle indispensable

Un graphe de coordination ne tient que si les agents partagent une vision commune du travail. Plutôt qu’un historique de chat qui se réinitialise à chaque exécution, il faut un système durable où chaque tâche conserve ses liens réels : la décision qui l’a motivée, le code qu’elle modifie, les travaux dont elle dépend et la personne responsable. Avec cette base, un agent peut voir la migration dont il a besoin ou le contrat à respecter sans chercher des indices cachés. Sinon, chaque agent travaille avec une vue partielle et la coordination échoue précisément là où les tâches sont le plus interconnectées.

La topologie du graphe détermine qui fait quoi et dans quel ordre. Le registre partagé est ce que la topologie lit et écrit, donc une tâche terminée met à jour la même structure que la suivante lira. Le contexte s’accumule au sein de l’équipe plutôt que d’être reconstruit manuellement à chaque exécution.

Implications pour les DSI

Faire évoluer les agents au-delà des démonstrations est d’abord un problème de conception organisationnelle avant d’être une question d’outils. Ce qui distingue une équipe performante, c’est la qualité de sa couche de coordination pour les agents, incluant un registre partagé et lisible par machine des travaux à coordonner. Cette couche est longue à construire et difficile à dupliquer, ce qui en fait la frontière entre une utilisation efficace des agents et leur simple multiplication.

Pour les DSI, maîtriser cette coordination est devenu un impératif stratégique. C’est le seul moyen de transformer des agents isolés en système cohérent et évolutif.