Comment les agents IA gestionnaire et exécutants travaillent ensemble

#Pourquoi un agent unique atteint ses limites

Un agent IA unique fonctionne selon une boucle simple : lire le contexte, décider, agir, observer, recommencer. Cela fonctionne très bien pour des tâches au périmètre clair et restreint — répondre à une question, écrire une fonction, résumer un document. Ça cesse de bien fonctionner dès qu'une tâche exige plus d'une compétence, plus d'appels d'outils que ce qui tient confortablement dans une seule fenêtre de contexte, ou plus de matière brute qu'un seul agent ne peut retenir sans perdre de vue l'objectif réel.

Prenons un exemple banal : « analyser trois concurrents et transformer les résultats en rapport comparatif ». Un agent unique qui fait tout dans une seule session continue va consommer l'essentiel de son contexte sur des résultats de recherche bruts et des pages à moitié lues, avant même d'arriver à la rédaction et à la relecture. Donnez-lui tous les outils dont il pourrait avoir besoin — recherche web, lecteur de documents, tableur, outil de rédaction, vérificateur de faits — et sa liste d'outils devient si longue qu'il finit par choisir le mauvais outil au mauvais moment. Les systèmes multi-agents existent précisément pour contourner ce problème : au lieu d'un généraliste qui fait tout dans un contexte unique et sans cesse grandissant, le travail est réparti entre plusieurs spécialistes, chacun avec une mission plus étroite, son propre contexte propre, et son propre budget d'outils, limité.

#Le modèle de base : un gestionnaire, plusieurs exécutants

Le modèle qui revient sans cesse — dans les systèmes de support client, les assistants de code, les outils de recherche — est le modèle gestionnaire/exécutants (aussi appelé orchestrateur/sous-agents, ou superviseur/spécialistes). Il comporte trois éléments :

• Un agent gestionnaire qui reçoit l'objectif réel de l'utilisateur, le découpe en sous-tâches, décide quel exécutant traite chacune, et reste responsable de la réponse finale.
• Des agents exécutants, chacun cantonné à une mission plus étroite — un « agent de recherche », un « agent de code », un « agent de rédaction » — avec ses propres instructions, ses propres outils, et son propre contexte privé.
• Une couche de coordination : la mécanique de transmission de messages et de suivi de statut qui permet au gestionnaire de déléguer le travail et de récupérer les résultats sans que les deux parties partagent directement leur mémoire.

Le gestionnaire ne fait pas le travail lui-même. Il décompose, délègue et intègre. Cette séparation compte parce qu'elle garde le contexte de chaque agent propre : le contexte du gestionnaire se remplit de statuts de tâches et de résumés courts, jamais de résultats de recherche bruts ni de contenus de fichiers complets — il peut ainsi continuer à piloter une tâche longue sans jamais manquer de place. De son côté, le contexte de chaque exécutant ne se remplit que de ce dont sa propre sous-tâche a réellement besoin.

#Anatomie d'un agent gestionnaire

Le prompt système d'un gestionnaire contient en général trois éléments dont un exécutant n'a pas besoin : une description des exécutants disponibles et du moment où utiliser chacun, une politique sur le niveau de détail à demander en retour, et une règle sur la conduite à tenir quand un exécutant échoue ou renvoie quelque chose d'inutilisable.

Concrètement, la boucle d'un gestionnaire ressemble à ceci :

1. Lire l'objectif réel de l'utilisateur.
2. Décider s'il peut être traité directement, ou s'il doit être découpé en sous-tâches.
3. En cas de découpage, rédiger une fiche de tâche autonome pour chaque sous-tâche — assez claire pour qu'un exécutant sans aucun historique de conversation puisse la reprendre à froid et savoir exactement ce qui est attendu.
4. Envoyer les fiches de tâche, soit une à la fois (séquentiel), soit toutes ensemble (parallèle).
5. Récupérer le résultat de chaque exécutant — sa réponse finale structurée, jamais sa transcription brute ni son raisonnement intermédiaire.
6. Décider si le résultat est suffisant, s'il nécessite une tâche de suivi, ou s'il doit être réassigné avec une consigne corrigée.
7. Une fois toutes les sous-tâches résolues, synthétiser la réponse finale pour l'utilisateur.

Remarquez ce que le gestionnaire ne voit jamais : les appels d'outils intermédiaires d'un exécutant, ses fausses pistes, ses allers-retours internes. C'est voulu — le contexte du gestionnaire reste petit et concentré sur l'orchestration, jamais sur le détail d'exécution.

#Anatomie d'un agent exécutant

Un agent exécutant est, de son propre point de vue, un agent unique tout à fait ordinaire. Il reçoit une tâche, obtient l'accès aux outils dont cette tâche a besoin, et fait tourner sa boucle jusqu'à ce qu'il ait terminé. En général, il ignore complètement qu'il fait partie d'un système plus vaste, sauf si le gestionnaire le lui dit explicitement. Maintenir les exécutants « dans l'ignorance » de la vue d'ensemble est d'ailleurs souvent un choix de conception délibéré : un exécutant qui sait seulement « extraire tous les détails tarifaires de ce document » produit un résultat plus précis et plus fiable qu'un exécutant qui porterait aussi tout le brief du projet de plusieurs semaines dans son contexte, à moitié distrait par des objectifs qui ne sont pas les siens.

La seule discipline supplémentaire qu'un exécutant doit avoir, qu'un agent autonome classique n'a pas besoin d'avoir, c'est de savoir rendre compte proprement. Un exécutant qui renvoie trois paragraphes de raisonnement narré est bien plus difficile à exploiter pour un gestionnaire qu'un exécutant qui renvoie un résultat court et structuré : ce qui a été fait, ce qui a été trouvé, ce qui reste incertain, et ce qu'il n'a tout simplement pas pu terminer.

#Comment les agents se parlent réellement

C'est la partie qu'on a tendance à trop romancer, alors qu'elle est en pratique assez mécanique. Il n'y a aucune conscience partagée entre un gestionnaire et ses exécutants — il y a de la transmission de messages, et cela prend généralement l'une de ces trois formes :

• Appel de fonction ou d'outil. Le gestionnaire traite « appeler l'exécutant de recherche » exactement comme il traiterait « appeler l'API météo » : l'exécutant est enveloppé comme un outil, avec un schéma d'entrée défini et un schéma de sortie défini. C'est le modèle le plus courant aujourd'hui, car il réutilise exactement la même mécanique d'appel d'outils que les agents utilisent déjà pour tout le reste.
• File d'attente de tâches partagée. Le gestionnaire écrit des tâches dans une file ; les exécutants les récupèrent, les traitent, et écrivent leurs résultats dans un espace de stockage dédié. Cela découple le minutage — les exécutants n'ont pas besoin d'être actifs au moment précis où le gestionnaire crée une tâche — et cela passe naturellement à l'échelle avec de nombreux exécutants, mais cela nécessite une infrastructure (file d'attente, stockage de résultats, logique de réessai) qu'un simple appel d'outil n'exige pas.
• État partagé de type tableau blanc. Tous les agents lisent et écrivent dans un même espace partagé — un document, un enregistrement de base de données, un objet de type tableau blanc — et déduisent leur prochaine action de ce qui s'y trouve déjà, plutôt que d'une instruction directe qui leur serait adressée personnellement. Cette forme est moins courante pour la délégation pure de tâches, et plus courante pour l'édition collaborative, où plusieurs agents convergent progressivement vers un même artefact partagé.

La plupart des systèmes multi-agents en production aujourd'hui s'appuient sur la première forme pour la délégation simple et synchrone, et sur la deuxième pour tout ce qui doit survivre à une panne, monter en charge, ou tolérer qu'un exécutant soit temporairement hors ligne.

#À quoi ressemble concrètement la transmission

Tracé du diagramme

Chaque échange de ce diagramme est, en dessous, un message de type JSON-RPC transmis via stdio, HTTP, ou un bus d'événements. Le gestionnaire ne parle jamais directement aux outils sous-jacents pour un travail qu'il a délégué — il ne voit que le résultat structuré que chaque exécutant choisit de lui renvoyer.

#Le cycle de vie d'une tâche, étape par étape

Zoomez sur une seule sous-tâche, et vous trouverez un cycle de vie que tout système bien conçu suit, quelle que soit la forme de coordination utilisée en dessous :

Tracé du diagramme

1. Décomposer. Le gestionnaire transforme un objectif large en sous-tâches réalisables de façon indépendante — aucune sous-tâche ne devrait dépendre en silence du résultat d'une autre sans l'attendre explicitement.
2. Spécifier. Chaque sous-tâche reçoit une consigne autonome : objectif, contraintes, format de sortie attendu, et les entrées dont l'exécutant a réellement besoin — pas « va te renseigner sur X », mais « lis cette URL et extrais ces quatre champs, dans ce format ».
3. Assigner. Le gestionnaire choisit un exécutant. Parfois il n'existe qu'un seul type d'exécutant par compétence ; parfois le gestionnaire choisit dans un pool selon la charge en cours ou la spécialisation.
4. Exécuter. L'exécutant fait tourner sa propre boucle, avec ses propres outils, de façon totalement opaque pour le gestionnaire jusqu'à ce qu'il ait terminé.
5. Rendre compte. L'exécutant renvoie un résultat structuré, idéalement validé contre un schéma, pour que le gestionnaire n'ait pas à analyser du texte libre pour trouver ce dont il a besoin.
6. Vérifier. Le gestionnaire, ou un agent vérificateur dédié, contrôle le résultat par rapport à la consigne d'origine. C'est l'étape que la plupart des systèmes sautent au début, et qu'ils regrettent ensuite — sans elle, un résultat d'exécutant faux mais confiant peut discrètement contaminer la réponse finale.
7. Intégrer ou réessayer. Suffisant → l'intégrer à la réponse en cours de construction. Insuffisant → réassigner avec une consigne corrigée, ou remonter le problème à l'utilisateur plutôt que de deviner.

#Quatre façons de coordonner les exécutants

Séquentiel. L'exécutant B a besoin du résultat de l'exécutant A pour démarrer. C'est la forme la plus simple à raisonner et à déboguer, mais aussi la plus lente — le temps total est la somme de chaque étape. C'est le bon choix par défaut quand les sous-tâches dépendent réellement les unes des autres, comme « faire le plan, puis rédiger, puis relire ».

Parallèle. Des sous-tâches indépendantes partent en même temps, et le gestionnaire attend qu'elles se terminent toutes — ou les premières qui comptent — avant de continuer. Le temps réel chute nettement, mais le coût augmente, puisque chaque exécutant en parallèle consomme ses propres jetons et ses propres appels d'outils en même temps, et il faut une étape de fusion, car le gestionnaire doit désormais réconcilier plusieurs résultats au lieu d'un seul enchaînement propre.

Hiérarchique. Pour les tâches vraiment volumineuses, un gestionnaire peut déléguer non pas à un exécutant, mais à un autre gestionnaire, qui décompose à son tour. Un gestionnaire de haut niveau chargé de « produire une étude de marché » pourrait déléguer « couvrir le marché européen » et « couvrir le marché asiatique » à deux sous-gestionnaires régionaux, qui délèguent ensuite chaque recherche d'entreprise à des exécutants. Cela passe bien à l'échelle, mais ajoute de la latence à chaque niveau, et complique le débogage — un mauvais résultat trois niveaux plus bas doit remonter à travers deux gestionnaires avant que quiconque ne s'en aperçoive.

Tableau blanc / mémoire partagée. Plutôt que le gestionnaire ne route chaque information à la main, les agents lisent et écrivent dans un espace partagé et réagissent à ce qui y change. Cette forme convient mieux aux tâches ouvertes et collaboratives — plusieurs agents qui convergent progressivement vers un même document partagé — qu'à la délégation de tâches discrètes, et elle exige une gestion soigneuse des conflits, puisque deux agents peuvent écrire au même endroit en même temps.

#Quand ne pas recourir à plusieurs agents

La coordination n'est pas gratuite. Elle coûte des jetons à chaque transmission, ajoute de la latence à chaque frontière, et ajoute une réelle complexité d'ingénierie — schémas, réessais, étapes de vérification — dont un agent unique bien cadré n'a tout simplement pas besoin. Évitez le modèle multi-agents quand la tâche tient confortablement dans une seule fenêtre de contexte, ne demande qu'une seule compétence du début à la fin, ou quand un humain va de toute façon vérifier le résultat, rendant redondant le contrôle croisé par un second agent. Le vrai signal qu'une tâche a besoin d'être découpée n'est pas « c'est difficile » — beaucoup de tâches difficiles restent des tâches à une seule compétence. Le signal, c'est que la tâche exige plus d'une compétence distincte, plus de matière brute que ce qui tient dans une seule fenêtre, ou qu'elle bénéficie clairement de sous-parties indépendantes exécutées en même temps plutôt que l'une après l'autre.

#Ce qui peut mal tourner, et comment on le gère

Les systèmes multi-agents échouent de façons qu'un agent unique ne connaît tout simplement pas, surtout parce qu'il y a plus d'endroits où l'information peut se perdre ou se déformer en transit entre agents :

• Transmissions avec perte. Une nuance découverte par un exécutant se retrouve aplatie en une seule ligne dans son rapport, et le gestionnaire prend une décision fondée sur cette ligne aplatie — en manquant la nuance qui aurait tout changé. Le remède : des schémas de sortie plus stricts, qui forcent l'exécutant à signaler l'incertitude et les réserves comme des champs structurés, jamais comme du texte libre que le gestionnaire pourrait survoler.
• Échec silencieux. Un exécutant expire, rencontre une erreur d'outil, ou obtient un résultat peu fiable, mais renvoie quand même quelque chose qui ressemble à « terminé », parce que c'est la forme que le gestionnaire attend de voir. Le remède : faire de l'échec une valeur de retour à part entière, pas une exception que le gestionnaire doit deviner par son absence.
• Travail dupliqué. Deux exécutants en parallèle enquêtent indépendamment sur la même sous-question, parce que le découpage du gestionnaire n'était pas aussi indépendant qu'il en avait l'air sur le papier. Le remède : un découpage plus rigoureux en amont et, dans les systèmes plus vastes, un registre partagé de ce qui est « déjà couvert », que les deux exécutants peuvent consulter.
• Délégation incontrôlée. Un gestionnaire capable d'engendrer des sous-gestionnaires peut, sans limite, engendrer un arbre d'agents qui ne converge jamais vers une réponse. Les systèmes en production imposent des plafonds stricts sur la profondeur de délégation, le nombre d'exécutants en parallèle, et le budget total de jetons ou d'appels d'outils par tâche.
• Dérive du contexte. Sur une tâche longue, le résumé courant que tient le gestionnaire de ce qui s'est passé peut dériver par rapport à ce qui s'est réellement passé, surtout quand le résumé lui-même est réalisé par un autre agent sous contrainte de temps. Conserver les fiches de tâche brutes et les résultats structurés d'origine — pas seulement la paraphrase qu'en fait le gestionnaire — donne quelque chose de concret sur lequel s'appuyer pour vérifier plus tard.

#Contexte et mémoire : ce que garde un gestionnaire, ce que garde un exécutant

Le contexte du gestionnaire, c'est l'état de coordination : quelles sous-tâches existent, leur statut actuel, et un court résultat structuré pour chacune — jamais les transcriptions complètes des exécutants. Le contexte d'un exécutant, lui, se limite à ce dont sa propre sous-tâche a besoin et rien de plus ; il ne voit en général jamais la requête complète d'origine de l'utilisateur, les résultats des autres exécutants, ni les délibérations internes du gestionnaire sur la façon de répartir le travail.

Cette séparation est aussi ce qui rend les systèmes multi-agents assez résistants au problème du « perdu au milieu » (lost in the middle) qui touche les contextes uniques très longs — aucun contexte d'agent individuel n'a besoin de dépasser ce qu'exige une seule sous-tâche bien ciblée, aussi grande que devienne la tâche globale.

#Un exemple détaillé : une équipe d'agents pour un rapport de recherche

Supposons que l'objectif soit « produire un rapport comparant les tarifs de trois fournisseurs cloud pour une charge de travail donnée ». Un découpage gestionnaire/exécutants pourrait ressembler à ceci :

• Le gestionnaire lit l'objectif et le décompose en trois sous-tâches de recherche identiques — une par fournisseur — plus une sous-tâche de synthèse qui dépend de l'achèvement des trois premières.
• Trois exécutants de recherche tournent en parallèle, chacun disposant de la recherche web et d'outils de lecture de documents, chacun renvoyant une grille tarifaire structurée pour son fournisseur — un tableau de champs, pas du texte libre.
• Le gestionnaire vérifie que chaque résultat contient tous les champs requis, et réassigne ceux qui reviennent incomplets avec une consigne corrigée et plus précise.
• Une fois les trois résultats obtenus, le gestionnaire envoie une sous-tâche de synthèse — en transmettant les trois résultats structurés, jamais les transcriptions brutes des exécutants — à un exécutant rédacteur dont la seule mission est de transformer des données structurées en comparaison lisible.
• Le gestionnaire relit le brouillon une dernière fois par rapport à l'objectif d'origine, puis le renvoie à l'utilisateur.

Chaque étape ci-dessus reste lisible parce que la mission de chaque agent est assez restreinte pour qu'un humain, ou un autre agent, puisse réellement la vérifier.

#Principes de conception pour construire ce genre de système

• Faites descendre le détail, gardez les résumés en haut. Les gestionnaires devraient manipuler des résultats courts et structurés ; les exécutants devraient manipuler tout le niveau de détail que leur unique sous-tâche exige réellement.
• Faites de l'échec une valeur, pas une exception. Chaque réponse d'exécutant doit pouvoir dire « je n'ai pas pu faire cela » de façon tout aussi structurée qu'une réponse de succès — jamais un vide silencieux que le gestionnaire doit deviner.
• Découpez pour l'indépendance, pas seulement pour la taille. Découper une tâche en morceaux qui dépendent encore secrètement les uns des autres crée toute la surcharge de coordination d'un agent unique, sans aucun des bénéfices du parallélisme en contrepartie.
• Plafonnez tout, explicitement. Profondeur de sous-délégation, nombre d'exécutants en parallèle, budget total par tâche — bornez tout cela à l'avance, car « le gestionnaire saura quand s'arrêter » n'est pas un plan.
• Vérifiez avant d'intégrer. Un contrôle de cohérence simple et ciblé sur le résultat d'un exécutant détecte plus de problèmes réels que le simple fait de passer à un modèle plus capable, parce que ce contrôle examine exactement ce que l'exécutant était censé produire, au lieu de redériver la réponse depuis zéro.

#En résumé

Le modèle gestionnaire/exécutants ne consiste pas vraiment à rendre les agents « plus intelligents ». C'est une réponse d'ingénierie à un problème de mise à l'échelle : garder le contexte, la liste d'outils et la responsabilité de chaque agent assez restreints pour rester fiables, tout en restant capable de s'attaquer à des tâches trop grandes pour qu'un seul agent les porte seul. Toute la valeur du gestionnaire tient dans la décomposition, la délégation et la vérification ; toute la valeur de chaque exécutant tient dans le fait de bien faire une chose précise, et de rendre compte proprement. En pratique, ce qui fait vraiment fonctionner ces systèmes est peu spectaculaire — des consignes de tâche claires, des sorties structurées, des états d'échec explicites, et des plafonds stricts sur la profondeur de délégation autorisée — bien plus que quoi que ce soit d'exotique à l'intérieur des modèles eux-mêmes.