Quand tout le monde peut travailler en même temps

Imaginons un développeur qui confie une petite fonctionnalité à trois agents. Il s’agit d’un bouton d’export. Un agent construira l’interface, un autre le service derrière, un troisième la documentation. Le travail semble facile à répartir. Pendant qu’ils avancent, le développeur passe à autre chose.

Le premier résultat est réussi. Le bouton se trouve là où on l’attend, avec un état de chargement et un message d’erreur. Le deuxième agent a construit un service qui vérifie les permissions et produit un fichier. Le troisième a rédigé une courte explication pour télécharger ses données.

Puis on essaie l’ensemble.

Le bouton est accessible à tous les membres. Le service n’autorise que les administrateurs. La documentation annonce un téléchargement limité aux enregistrements de la personne qui le demande. Le service exporte les données de toute l’organisation.

Cet exemple est fictif, mais il offre un point d’arrêt utile. Chaque agent a produit une version plausible d’une fonctionnalité insuffisamment définie. Le développeur a maintenant trois livrables qui ont l’air terminés et une décision produit à prendre.

La conversation arrive après le travail

Supposons que le développeur précise que la fonctionnalité permet aux administrateurs d’exporter les données de l’organisation. L’agent d’interface modifie la visibilité du bouton. L’agent de documentation réécrit son explication. L’agent du service confirme que son comportement correspond déjà à la demande.

Pour le moment, tout concorde.

Puis l’agent d’interface demande ce qui doit se passer si l’administrateur perd son rôle pendant l’export. L’agent du service a supposé que la permission était vérifiée au début de la requête. L’agent de documentation a décrit l’accès comme si la permission devait encore exister au moment du téléchargement. Le développeur doit revenir.

Une partie de cette conversation est précieuse. Les agents ont fait apparaître une question que la demande initiale laissait ouverte. La difficulté est que les premières réponses prenaient déjà forme dans le code et le texte avant que quelqu’un reconnaisse leur portée commune.

Essayons autrement. Donnons toute la discussion à chaque agent. Ils reçoivent maintenant la demande initiale, l’exigence révisée, l’idée abandonnée d’un export personnel et la question encore ouverte du changement de rôle en cours d’opération.

Ils ont davantage d’informations. Ils doivent aussi déterminer quelles parties gouvernent leur prochaine action. Si le développeur change la réponse dans une conversation, les autres doivent encore être mises à jour.

La promesse du travail parallèle reste intéressante. Certaines parties peuvent être terminées indépendamment. L’équipe dépense de l’énergie à découvrir où cette indépendance s’arrête.

Qu’est-ce qui appartient à toute l’équipe ?

Reprenons cette même fonctionnalité hypothétique avec une autre répartition des responsabilités. Avant l’implémentation, une personne prend en charge un petit groupe de décisions sur l’accès : qui peut demander l’export, quels enregistrements il contient et quand la permission est vérifiée. Une autre prend en charge le contrat de livraison : comment suivre la requête, signaler son achèvement et traiter un échec.

L’agent d’interface peut choisir la présentation de la progression à l’intérieur de ce contrat. Il n’a pas besoin de redécouvrir le modèle d’accès. L’agent de documentation peut expliquer le même comportement validé sans le reconstituer à partir de l’implémentation du service.

On peut appeler cela des groupes de décisions si le terme aide. Dans cet exemple, c’est leur contenu qui compte. Les décisions qui obligent plusieurs tâches à changer ensemble ont un emplacement partagé et un responsable identifié. Les choix dont les effets restent locaux peuvent rester entre les mains de l’agent qui effectue le travail.

Cette organisation demande un peu de travail avant l’implémentation. Quelqu’un doit distinguer ce qui est établi de ce qui reste ouvert. Elle peut aussi révéler qu’une tâche ne se délègue pas encore proprement. Mieux vaut le savoir avant que trois agents en terminent trois interprétations différentes.

L’enregistrement n’a pas à devenir une spécification miniature de tout le système. Pour l’export, quelques phrases précises sur le périmètre et l’accès résoudraient une grande partie du désaccord. Consigner la raison d’une règle donne aussi à l’agent un élément à examiner lorsqu’une nouvelle exigence la remet en question.

La question de la perte du rôle administrateur peut alors revenir au responsable sous la forme d’une exception précise. Une fois tranchée, elle met à jour la description commune du fonctionnement. Les tâches d’implémentation disposent d’une même réponse.

D’autres équipes ont rencontré ce problème

Cursor décrit des planificateurs qui tranchaient indépendamment la même question dans ses groupes d’agents, ainsi que des agents qui modifiaient plusieurs fois leur travail à partir de conceptions contradictoires. Parmi les réponses rapportées figurent des documents de décision partagés, des responsabilités plus claires, des références vérifiées contre ces documents et un traitement neutre des conflits. L’équipe a aussi expérimenté un court guide fourni aux nouveaux agents. Ces changements sont décrits dans son retour d’ingénierie.

Anthropic rapporte un problème voisin dans son système de recherche multi-agent : des missions vagues conduisaient les agents à dupliquer leur travail. Des objectifs, des livrables et des limites plus précis aidaient à définir la contribution de chacun. Le récit aborde aussi le coût et la difficulté de coordination des tâches comportant de nombreuses dépendances.

Ces exemples donnent à une petite équipe des questions utiles sur son propre fonctionnement. Où deux agents peuvent-ils décider de la même chose ? De quelle réponse héritera le prochain agent ? Que se passe-t-il lorsqu’un changement local raisonnable affecte une autre tâche ?

Mana peut soutenir une partie de cette organisation en rendant les décisions et leurs sources accessibles entre les sessions. Ses enregistrements identifiés par une clé peuvent être corrigés en conservant leur historique, et son contexte permanent peut transmettre des consignes communes aux nouvelles sessions. L’équipe doit encore décider qui porte la question et comment lui faire parvenir un conflit. Qui peut lire la décision constitue une autre limite. Stocker une décision ne prouve pas que chaque tâche l’a suivie.

Garder une place pour l’agent qui découvre une faille

On pourrait lire l’histoire de l’export comme une invitation à tout régler avant de commencer. Poussée trop loin, cette approche rend le développeur responsable d’anticiper chaque détail. Les agents attendent des réponses que le travail lui-même aurait pu faire émerger.

Revenons au changement de rôle pendant l’export. Si le seul objectif était de réduire les messages, on pourrait supprimer la question et sembler efficace tout en conservant le défaut.

Je surveillerais la différence entre rouvrir une réponse parce qu’elle a été perdue et la rouvrir parce qu’un nouvel élément change le problème. La mémoire partagée peut aider dans le premier cas. Une équipe capable doit laisser de la place au second.

Je me garderais aussi d’affirmer que les groupes de décisions ont fait gagner du temps simplement parce que les conversations ont raccourci. Il faut comparer le résultat terminé, les corrections nécessaires et le coût de préparation de chaque session. Tant que ces résultats ne sont pas mesurés, cette organisation reste une proposition à examiner.

À la fin de notre export hypothétique, le développeur relit un bouton, un service et une explication qui décrivent le même comportement. Une question imprévue a modifié la conception. Le reste a avancé sans qu’il ait à raconter à nouveau la fonctionnalité dans trois conversations.

C’est une ambition qui me paraît plus intéressante que d’occuper tous les agents. Donner à chacun assez de compréhension commune pour travailler seul, et un moyen clair de rapporter ce que l’équipe n’a pas encore compris.