Délégation d'agent :
votre agent dev délègue le test
La délégation d'agent permet à votre agent dev de finir une feature et de passer la validation à un agent QA séparé. Le dev continue à coder avec le modèle en qui vous avez confiance pour les vrais problèmes. L'agent QA exécute le test sur un modèle moins cher. Les deux communiquent via les serveurs MCP d'AgentsRoom, donc la délégation d'agent fonctionne de bout en bout sans que vous copiez quoi que ce soit.
Vous arrêtez de payer le prix Opus pour des clics dans un browser. Vous arrêtez de polluer le contexte de votre agent dev avec des screenshots et des dumps DOM. La délégation d'agent route chaque tâche vers le bon modèle au bon prix, et quand l'agent QA a fini, il pinge l'agent dev en retour pour que la boucle se ferme toute seule.
La délégation d'agent en action : l'agent dev Codex finit la feature, appelle run_qa_test, l'agent QA ouvre le browser sur un modèle moins cher et rapporte.
Voici le problème que la délégation d'agent résout. Vous faites tourner un agent dev costaud (Claude Opus, Codex, le genre de modèle qui conçoit une API ou refactorise un store). L'agent livre la feature en 10 minutes. Puis il passe les 8 minutes suivantes à cliquer dans un browser pour vérifier que la feature marche. Même tarif de token cher. Même modèle qui réfléchissait à votre logique métier, qui lit maintenant des labels de boutons.
La délégation d'agent corrige ça. Quand la feature est terminée, l'agent dev appelle un seul outil MCP, run_qa_test, avec un scénario. AgentsRoom spawn un agent QA éphémère sur le modèle que vous avez choisi pour la QA : Claude Haiku, Codex mini, GPT-4 mini, ce que vous voulez. L'agent QA reçoit le Browser MCP d'AgentsRoom, drive la page, vérifie le résultat et répond par un verdict. L'agent dev lit le verdict et passe à la suite.
C'est ça la délégation d'agent, et c'est la seule boucle que cette page couvre. Un dev, un QA, un MCP. Même idée qu'un ingénieur senior qui délègue les tests de régression à un junior ou à la QA : le senior continue à concevoir, le junior déroule la checklist. La délégation d'agent vous donne ce même partage entre modèles.
La délégation d'agent visualisée : l'agent dev parent (Codex) et l'agent QA enfant (Claude) apparaissent dans la même liste, avec un passage dev vers QA clair.
Pourquoi la délégation d'agent vaut vraiment le coup
D'abord, l'argent. Un passage de test sur Claude Opus et un passage de test sur Claude Haiku coûtent des sommes radicalement différentes. Même browser, même asserts, mêmes screenshots. La délégation d'agent laisse le modèle pas cher faire le travail pas cher. Les gens qui ont activé ça rapportent une facture de tokens divisée d'un vrai facteur sur les jours QA, pas de 5 à 10 pour cent.
Ensuite, le contexte. Quand un agent dev fait le test lui-même, chaque screenshot, chaque dump DOM, chaque log console atterrit dans la fenêtre de contexte du dev. Vingt minutes de clics, ce sont des mégaoctets de bruit que l'agent dev doit traîner pour le reste de la session. La délégation d'agent isole ce bruit dans l'agent QA éphémère. L'agent dev récupère un 'pass' ou 'fail' propre, rien d'autre.
Troisième point, l'écologie. Chaque délégation d'agent économise du calcul réel. Faire tourner Haiku là où Opus tournait divise par deux l'empreinte énergie de cette étape. Multipliez par tout le monde dans l'équipe et par chaque boucle de test dans l'année, et la délégation d'agent devient un vrai levier sur le côté carbone de votre stack.
Quatrième point, la fiabilité. Un agent dev qui drive le browser tout seul a tendance à dériver. Deux screenshots plus tard, il a oublié ce qu'il voulait valider. L'agent QA dans la délégation d'agent a un seul job et un seul prompt. Il teste, il rapporte, il meurt. La boucle est courte, prévisible et facile à déboguer.
Le seul flow que cette page couvre
Un agent dev. Un agent QA. Un appel MCP. La délégation d'agent, de bout en bout.
L'agent dev livre la feature
Votre agent dev (Claude Opus, Codex en raisonnement élevé, n'importe quel modèle cher en qui vous avez confiance) termine l'implémentation. Nouvelle endpoint, nouvel écran, nouveau flow. Code écrit, fichiers sauvegardés.
L'agent dev appelle run_qa_test
Au lieu d'ouvrir le browser lui-même, l'agent dev appelle un seul outil MCP du serveur AgentsRoom Test Runner : run_qa_test, avec un scénario en anglais courant. C'est toute la surface API de la délégation d'agent.
AgentsRoom spawn l'agent QA
AgentsRoom Test Runner spawn un agent QA éphémère sur le modèle moins cher que vous avez configuré (Claude Haiku, Codex mini, GPT-4 mini). L'agent QA récupère les outils Browser MCP d'AgentsRoom : navigate, click, type, screenshot, evaluate, get_logs, get_state.
L'agent QA exécute le test
L'agent QA ouvre la page, déroule le scénario, vérifie le résultat, capture des screenshots si besoin et lit les logs console pour attraper les erreurs runtime qu'un agent dev aurait ratées.
L'agent QA soumet le verdict
Une fois fini, l'agent QA appelle submit_verdict avec un résultat pass, fail ou inconclusive et un court résumé. Screenshots et logs attachés. Le process de l'agent QA est détruit. Sa fenêtre de contexte part avec.
L'agent dev lit le verdict et continue
L'agent dev reçoit le verdict en retour comme réponse à run_qa_test. Sur pass, l'agent dev commit ou passe au ticket suivant. Sur fail, l'agent dev lit le résumé d'échec, corrige le bug et déclenche un nouveau cycle de délégation d'agent. La boucle se ferme toute seule.
L'économie de la délégation d'agent
Pourquoi un partage dev vers QA intelligent baisse votre facture IA sans baisser vos standards.
Les tests browser sont répétitifs. Ouvre la page, clique le bouton, lis le label, vérifie le toast. Un modèle à 50 dollars par million de tokens fait ce travail aussi bien qu'un modèle à 3 dollars par million de tokens. Peut-être mieux, parce que le modèle pas cher ne s'ennuie pas. La délégation d'agent met le modèle pas cher sur la moitié ennuyeuse du travail.
Vrais chiffres sur de vraies sessions : un test end-to-end typique sur un flow complexe brûle 60k à 200k tokens entre screenshots, dumps DOM et étapes de raisonnement. Sur Opus, c'est du vrai argent par test. Sur Haiku, c'est de la monnaie. La délégation d'agent transforme une habitude QA quotidienne d'un souci budgétaire en un réflexe gratuit.
Multipliez par chaque boucle. Une journée dev normale sur une feature non triviale fait tourner le test cinq à vingt fois. La délégation d'agent compose sur ces répétitions. L'agent dev reste cher (vous le voulez cher), l'agent QA reste pas cher, et l'écart, c'est de l'économie pure.
La délégation d'agent est aussi plus douce pour la planète. Moins de calcul sur le même travail veut dire moins d'énergie, moins d'eau dans le datacenter, moins de carbone. Ce n'est pas la seule raison de câbler la délégation d'agent, mais c'est un bel effet secondaire de router les tâches vers des modèles bien dimensionnés.
Un vrai partage de modèles pour la délégation d'agent
Ce que les gens branchent vraiment côté dev et côté QA de la délégation d'agent.
Côté dev (cher exprès)
- Claude Opus 4.7
- Claude Sonnet 4.6
- Codex raisonnement élevé
- GPT-4 raisonnement profond
- Gemini 2.5 Pro
Côté QA (délégué au moins cher)
- Claude Haiku 4
- Claude Sonnet 4 (effort bas)
- Codex mini
- GPT-4 mini
- Gemini 2.5 Flash
La délégation d'agent ne fige pas la matrice. Vous configurez le modèle QA par projet. Vous pouvez même déléguer vers un provider totalement différent : Opus côté dev, Codex mini côté QA, aucun contexte partagé, juste un appel MCP.
Ce que la délégation d'agent fait vraiment sous le capot
La délégation d'agent repose sur la stack MCP d'AgentsRoom. L'agent dev tourne dans son CLI (Claude Code, Codex, Gemini, OpenCode, Aider). AgentsRoom injecte le serveur MCP Test Runner dans cet agent. Le Test Runner expose un seul outil : run_qa_test. C'est le point d'entrée de chaque appel de délégation d'agent.
Quand run_qa_test se déclenche, AgentsRoom spawn un nouveau process CLI dans le même projet, avec une config différente. Cette config a le Browser MCP attaché, le system prompt QA attaché, et le modèle swappé vers celui que vous avez réglé côté QA. Le nouveau process est un agent QA éphémère : il vit le temps du test et meurt après submit_verdict.
Pendant que l'agent QA tourne, l'agent dev est en pause sur l'appel run_qa_test. AgentsRoom affiche l'agent QA dans la même liste d'agents, indenté sous l'agent dev (visible sur l'image plus haut). Quand l'agent QA finit, son verdict est renvoyé comme résultat de run_qa_test et l'agent dev reprend. La délégation d'agent, c'est un seul aller-retour MCP du point de vue de l'agent dev.
L'agent dev ne reçoit jamais les outils browser. AgentsRoom retire les outils browser_* de la liste autorisée de l'agent dev au moment du spawn. C'est cette partie qui rend la délégation d'agent fiable : l'agent dev ne peut pas retomber sur faire le test lui-même, même quand son instinct est d'attraper un screenshot. Le seul chemin possible, c'est run_qa_test. Délégation d'agent par soustraction, pas par demande polie.
Où la délégation d'agent tourne aujourd'hui, et la suite
La délégation d'agent dans AgentsRoom est browser-first aujourd'hui. Même forme, plus de surfaces à venir.
Aujourd'hui : délégation de tests browser
L'agent QA drive le browser embarqué d'AgentsRoom via le Browser MCP. Serveur de dev localhost, tunnel de preview public, URL de staging, tout ce que Chromium peut afficher. Formulaires, modales, drag and drop, dialogs, logs console, erreurs réseau. La délégation d'agent couvre toute la surface qu'un QA web humain couvrirait.
Délégation de tests d'app Electron
Si vous shippez une app Electron vous-même, vous pouvez installer la lib AgentsRoom Electron MCP dans votre projet. L'agent QA se connecte à votre app Electron de la même façon qu'à un onglet Chromium. La délégation d'agent passe sur le test d'app desktop sans changer le côté dev.
Délégation de tests d'app React Native (roadmap)
La même forme de délégation d'agent arrive sur React Native. L'agent QA drivera un simulateur iOS ou Android via un AgentsRoom React Native MCP. L'agent dev livre un écran, l'agent QA tape dedans. Même appel run_qa_test, même passage dev vers QA, cible mobile.
Sans délégation d'agent vs avec délégation d'agent
Même feature, même passage QA. Facture différente, contexte différent, fiabilité différente.
Sans délégation d'agent
- : L'agent dev (cher) ouvre le browser lui-même.
- : Chaque screenshot, chaque dump DOM et chaque log console finit dans le contexte de l'agent dev.
- : 20 minutes de clics brûlent des tokens Opus sur un travail qu'un modèle moins cher ferait.
- : L'agent dev oublie ce qu'il faisait deux screenshots plus tard.
- : Vous payez plein tarif pour des clics browser, la planète aussi.
Avec délégation d'agent
- : L'agent dev appelle run_qa_test et attend.
- : Un agent QA pas cher fait les clics, les asserts, la capture de screenshots.
- : Seul le verdict (pass, fail, résumé) atteint l'agent dev.
- : L'agent QA est éphémère : il meurt après submit_verdict, zéro pollution de contexte.
- : Facture de tokens en baisse, agent dev qui reste concentré, boucle qui se ferme toute seule.
La délégation d'agent, c'est le gain de fiabilité le moins cher à câbler dans un setup d'agent de codage.
À quoi ressemble un appel de délégation d'agent
Voici toute la forme d'une délégation d'agent dev vers QA. L'agent dev lance ça via le Test Runner MCP et attend la réponse.
Appel d'outil MCP (agent dev)
run_qa_test({
scenario: "Ouvre http://localhost:3000/login.\n Tape l'utilisateur de test seedé dans le champ email.\n Soumets le formulaire.\n Vérifie que l'URL dashboard est atteinte et que le nom de l'utilisateur s'affiche dans le header.\n Capture un screenshot en cas de succès, capture les logs console en cas d'échec."
})FAQ
C'est quoi la délégation d'agent dans AgentsRoom ?
La délégation d'agent, c'est un passage dev vers QA entre deux agents de codage IA. L'agent dev finit une feature, appelle un seul outil MCP (run_qa_test), et un agent QA éphémère exécute le test sur un autre modèle. L'agent dev lit le verdict et passe à la suite. Tout le flow de délégation d'agent se passe via les serveurs MCP d'AgentsRoom.
Pourquoi est-ce que je voudrais une délégation d'agent au juste ?
Trois raisons. L'argent : l'agent QA tourne sur un modèle moins cher, donc les passages de test coûtent une fraction de ce qu'ils coûteraient sur le modèle dev. Le contexte : l'agent dev reste propre, tous les screenshots et dumps DOM meurent avec l'agent QA. La fiabilité : l'agent QA a un seul job, donc il teste mieux qu'un agent dev qui jongle avec des clics browser.
Quels modèles marchent pour la délégation d'agent ?
N'importe quel modèle qu'AgentsRoom supporte : Claude (Opus, Sonnet, Haiku), Codex (high, mini), Gemini (Pro, Flash), OpenCode, Aider. La délégation d'agent est cross-provider. Un partage courant est Claude Opus ou Codex côté dev et Claude Haiku ou Codex mini côté QA, mais vous choisissez.
La délégation d'agent, c'est uniquement pour des tests browser ?
Aujourd'hui, oui, l'agent QA drive le browser Chromium embarqué d'AgentsRoom. Demain, la même forme de délégation d'agent couvrira les apps Electron (installez la lib AgentsRoom Electron MCP dans votre projet Electron) et les apps React Native (roadmap, simulateurs iOS et Android).
Comment la délégation d'agent empêche l'agent dev de faire le test lui-même ?
AgentsRoom retire les outils browser_* de l'agent dev au moment du spawn. L'agent dev ne peut littéralement pas appeler browser_navigate ou browser_screenshot. Le seul chemin browser, c'est run_qa_test, qui déclenche la délégation d'agent. La contrainte est mécanique, pas une demande polie dans un prompt.
La délégation d'agent, c'est cloud ou local ?
Local-first. L'agent dev, l'agent QA éphémère, le bridge MCP et le browser tournent sur votre machine. La délégation d'agent n'utilise le cloud que quand le modèle sous-jacent (Claude, Codex, Gemini) parle à son propre provider, exactement comme un run d'agent normal.
La délégation d'agent fait économiser du vrai argent ?
Oui, d'un facteur important sur les jours QA-lourds. Un test end-to-end complexe sur Opus ou Codex high vs le même test sur Haiku ou Codex mini, c'est à peu près une différence de coût 10x. La délégation d'agent étalée sur une journée dev d'équipe scale cet écart vite.
Que reçoit l'agent dev en retour de la délégation d'agent ?
Un court verdict structuré : pass, fail ou inconclusive, avec un résumé, un chemin de screenshot optionnel et des logs console optionnels. Aucun screenshot brut dans le contexte, aucun dump DOM. C'est tout l'intérêt de la délégation d'agent : isoler le bruit QA dans l'agent QA.
L'agent QA peut-il créer un ticket backlog quand il échoue ?
Oui. La délégation d'agent donne au QA l'accès au Backlog MCP. Un échec peut atterrir comme ticket backlog sur le projet, avec le scénario, le screenshot et les logs console attachés. L'agent dev lit le verdict, le ticket backlog porte les détails longs.
Où la délégation d'agent se positionne par rapport aux autres features AgentsRoom ?
La délégation d'agent vit au-dessus de Browser Automation (qui donne le browser à l'agent QA) et des serveurs MCP AgentsRoom (qui donnent à chaque agent sa surface d'outils). Agent Teams, c'est l'éditeur de workflow multi-agents plus large : la délégation d'agent en est la saveur dev vers QA, mais exposée comme un appel MCP unique pour que n'importe quel agent de n'importe quel provider puisse l'utiliser sans configurer de graphe.
Va bien avec
Browser Automation
La couche Chromium et Browser MCP que le côté QA de la délégation d'agent drive. Vrai browser persistant par projet.
Agent Teams
Éditeur de workflow multi-agents visuel. La délégation d'agent est la saveur dev vers QA, Agent Teams est la version graphe complet avec N nœuds et feedback loops.
AgentsRoom MCP
Les serveurs MCP qui rendent la délégation d'agent possible : Test Runner, Browser, Backlog, Terminal Commands, Prompt Library.
Multi-Provider
Faites tourner Claude, Codex, Gemini, OpenCode et Aider côte à côte. La délégation d'agent est l'angle cross-provider de la même idée.
Claude Code Token Usage
Compteur de tokens en direct par session. Le moyen le plus rapide de confirmer les économies en dollars que la délégation d'agent vous donne en pratique.
Public Backlog
Quand un agent QA échoue un passage de délégation d'agent, le bug atterrit ici. Clients et coéquipiers voient la régression, l'agent dev la reprend.
Arrêtez de payer le prix Opus pour des clics QA
Téléchargez AgentsRoom et essayez la délégation d'agent. Câblez votre agent dev sur le modèle en qui vous avez confiance, votre agent QA sur un modèle moins cher, et laissez le passage dev vers QA se faire tout seul via MCP.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Gemini CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.