Architecture agentique et orchestration

Commencez par la décision qui précède toutes les autres : flux ou agent ? Un flux (workflow), c’est du code écrit à l’avance — une séquence fixe d’appels au modèle et d’étapes déterministes, la même forme à chaque exécution. Un agent, c’est un modèle dans une boucle — il décide, acte par acte, quelle est l’étape suivante, au vu de ce qu’il a déjà vu. L’examen vous tendra un scénario et demandera lequel convient ; posez correctement la question sous-jacente et chaque variante se répond d’elle-même.

La question sous-jacente : à quel point le chemin est-il prévisible ? Si les étapes sont connues d’avance — résumer, classifier, formater, envoyer — écrivez les étapes vous-même ; c’est un flux, et il est moins cher, plus testable et plus facile à déboguer. Si le nombre d’étapes, leur ordre ou leur nature même dépend de ce que le travail révèle — « trouve le bug et corrige-le », « documente-toi puis rédige » — il vous faut le modèle dans la boucle, parce que quelqu’un doit regarder chaque résultat et décider de la suite. Ce quelqu’un, c’est l’agent.

01La boucle de l’agent, ouverte

Tout agent sur lequel l’examen vous interrogera — Claude Code, un subagent, ce que vous construisez sur l’Agent SDK — exécute la même boucle. Apprenez-la une fois au niveau mécanique et une douzaine de questions deviennent des reformulations.

Dans le Claude Agent SDK, cette boucle est le travail du harness, pas le vôtre. Vous lancez une requête avec un prompt et une configuration ; le SDK envoie les requêtes au modèle, exécute les appels d’outils, renvoie les résultats, et produit des messages typés vers votre code au fil de l’exécution. Vous n’écrivez pas de while autour d’appels d’API — vous lisez un flux de messages typés et vous réagissez.

Cinq sortes de messages sortent de ce flux, et l’examen aime la taxonomie : SystemMessage (informations de session, une fois au départ), AssistantMessage (ce que Claude a dit ou fait — blocs text, tool_use, thinking), UserMessage (résultats d’outils, saisies utilisateur, contexte injecté par un hook — tout ce que le harness renvoie), StreamEvent (deltas incrémentaux si vous les avez demandés), et ResultMessage (le bilan d’une requête : sous-type, coût, durée, usage). Un piège habite ici : le message de résultat n’est pas garanti d’être le dernier élément du flux, et « l’exécution est finie » n’est pas « l’exécution a réussi » — itérez jusqu’au bout et vérifiez le sous-type. « success » est celui que vous voulez.

02Les conditions d’arrêt — comment la boucle se termine

Un agent sans conditions d’arrêt est un while-true avec une carte bancaire. L’examen attend que vous conceviez les sorties, et il y en a exactement quatre sortes à savoir nommer. L’achèvement naturel : le modèle émet end_turn parce qu’il estime la tâche faite. Les budgets de tokens et de tours : max_tokens plafonne une génération ; votre harness ou le SDK plafonne les tours, pour qu’un agent confus se prenne un mur plutôt que l’infini. Les stop sequences : des chaînes littérales qui coupent la génération — précises, mécaniques, pour le contrôle de format. Et les arrêts externes : hooks, refus de permission, un humain qui freine, un timeout dans votre couche d’orchestration.

La lecture de conception compte plus que la liste. Les budgets sont un filet, pas une stratégie — un agent qui atteint son maximum de tours a généralement été mal cadré, et le remède est une tâche plus petite ou de meilleurs outils, pas un budget plus grand. Quand un scénario dit « l’agent boucle indéfiniment sur une entrée mal formée », la réponse n’est presque jamais « augmenter la limite » ; c’est « valider le résultat d’outil et rendre l’échec lisible pour le modèle » — la religion du domaine 2 qui débarque dans le domaine 1.

03Systèmes multi-agents : le motif coordinateur

Dès qu’une tâche est trop grosse pour une fenêtre de contexte — ou trop variée pour un seul prompt — l’examen attend le motif coordinateur–subagent, parfois sous le nom d’Anthropic : orchestrator–workers. Un agent meneur possède la tâche, le plan et l’utilisateur ; il délègue des morceaux à des subagents, chacun exécutant la boucle que vous venez d’apprendre dans sa propre conversation avec ses propres outils ; leurs résultats remontent au coordinateur, qui décide de la suite. Le coordinateur est le seul à parler à l’utilisateur et le seul à voir l’ensemble ; les ouvriers voient leur tranche.

Il existe exactement quatre raisons de faire appel à un subagent, et l’examen les cite toutes. L’isolation de contexte : les lectures et les impasses du subagent se passent dans sa propre fenêtre, donc le contexte du parent reste propre — c’est autant une décision de gestion de contexte qu’organisationnelle. Le parallélisme : des ouvriers indépendants s’exécutent simultanément (un contrôle de style, un scan de sécurité, un audit de couverture en même temps). Les instructions spécialisées : un prompt système réglé pour un seul métier bat un prompt généraliste à tous les chapeaux. La restriction d’outils : un relecteur limité aux outils de lecture ne peut physiquement pas modifier de fichiers, quoi que la tâche lui tente de faire — la restriction par construction bat une instruction polie à tous les coups.

04Les subagents en pratique : définir, invoquer, passer le contexte

Comment un subagent vient-il au monde ? Trois voies, et l’examen teste le menu. Dans le code, sur l’Agent SDK : un subagent est un agent-comme-outil — vous définissez un agent avec son propre prompt et ses propres outils et vous l’exposez comme un outil que l’agent meneur peut appeler, d’où l’approximation acceptable « un subagent est juste un outil avec une conversation ». En fichiers markdown : un fichier de définition (nom, description, prompt système, outils autorisés) dans .claude/agents/ rend Claude Code lui-même capable de faire naître cette persona à la demande — c’est la voie filesystem, celle qu’un scénario « sans modifier le code » réclame. Ou en intégré : Claude Code embarque general-purpose, et le SDK a les siens.

L’invocation et le passage de contexte obéissent à une règle que l’examen reteste sans cesse : le contexte se passe par valeur, pas par référence. Le parent écrit une description de tâche — le prompt dans le prompt — et le subagent démarre une fenêtre neuve contenant son propre prompt système, cette description, et les outils qu’il a le droit d’utiliser. Il ne peut pas faire défiler l’historique du parent. Quand il a fini, ce qui revient est son rapport final (et une sortie structurée si vous l’avez demandée), pas sa transcription. Deux conséquences suivent. Écrivez les briefs de délégation comme pour un collègue compétent mais nouveau — autoporteurs, avec l’objectif, les contraintes et la définition du fini, parce que « vois la conversation précédente » n’est pas quelque chose qu’on peut mettre dans un brief. Et attendez-vous à payer la synthèse : l’ouvrier a peut-être lu 50 000 tokens ; le parent ne voit que le condensé. Ce n’est pas un bug, c’est exactement le but.

Un détail mécanique qui vaut de vrais points : dans Claude Code, les subagents définis en fichiers sont découverts dans des répertoires qui existaient au démarrage de la session. Créez .claude/agents/ pour la première fois en pleine session et les définitions ne se chargeront pas — redémarrez la session et elles apparaissent. Et la précédence quand un même nom est défini deux fois : les paramètres managés priment sur tout, puis le drapeau --agents, puis .claude/agents/ du projet, puis ~/.claude/agents/ personnel, puis les plugins. Première correspondance gagnante.

05Imposition et passations dans les flux multi-étapes

Un agent avec des outils est un inconnu avec des clés. L’imposition (enforcement), c’est l’architecture des serrures, et l’examen veut que vous raisonniez en couches. La couche la plus interne est la définition de l’outil lui-même — un outil en lecture seule ne peut pas écrire, quoi qu’ait dit le prompt ; la restriction par construction bat l’instruction. Autour, les permissions : des règles allow et deny qui filtrent quels outils peuvent s’exécuter (deny bat allow, à chaque fois). Autour encore, les hooks — du code qui s’exécute à des moments du cycle de vie et peut opposer son veto ou orienter (section suivante). À l’extérieur, le flux : vous l’architecte, qui décidez quelles étapes sont des étapes d’agent et lesquelles sont du code déterministe — des portes de validation, une approbation humaine obligatoire entre phases, un formateur que la sortie doit franchir. L’imposition se compose ; les mauvaises réponses de l’examen offrent généralement une couche quand le scénario en réclame une autre.

Les passations (handoffs) sont l’autre moitié de l’orchestration multi-étapes : le transfert planifié du travail entre acteurs — d’agent à agent, d’agent à humain, d’humain à agent. Une passation agent-agent transporte un contrat (le brief, les entrées, la définition du fini) et un chemin de retour (rapport, résultat structuré, artefacts sur disque). Une passation agent-humain n’est pas un état d’échec ; c’est un point de contrôle conçu — HITL, human-in-the-loop — et les questions de conception sont toujours les mêmes trois : qu’est-ce qui la déclenche (criticité de la tâche ? rayon d’action ? confiance faible ?), que voit l’humain (la proposition, les preuves, le diff — de quoi juger sans refaire), et que se passe-t ensuite (approuver et continuer, corriger et continuer, ou rejeter avec des raisons qui retournent dans le contexte de l’agent comme retour d’expérience).

L’échelle d’escalade — quand le système passe la main vers le haut — compose les deux : un agent règle ce qu’il peut, diffère l’ambiguïté vers le haut selon ses instructions, et un humain règle ce que l’échelle lui envoie. Les conditions de déclenchement sont à vous de concevoir, et l’examen les formule en arbitrages : chaque échelon ajouté achète de la sûreté et coûte de la latence ; chaque échelon retiré achète de la vitesse et dépense du contrôle. Il n’y a pas de bonne réponse universelle — il y a la réponse qui convient aux enjeux du scénario, et les questions sont construites pour que la compétence testée soit de lire les enjeux.

06Hooks de l’Agent SDK : interception et normalisation

Les hooks sont du code fourni par l’utilisateur qui s’exécute à des points fixes du cycle de vie de l’agent — du code déterministe accroché à un système non déterministe, ce qui est exactement la raison de leur existence. Les deux qui intéressent l’examen d’architecte encadrent l’appel d’outil. PreToolUse se déclenche avant l’exécution d’un outil, peut voir l’entrée, puis approuver, refuser ou demander. PostToolUse se déclenche après, voit l’entrée et le résultat, et peut normaliser ce qui sera consigné. Ensemble, ils implémentent les deux verbes préférés de l’examen : l’interception (arrêter ou détourner quelque chose avant qu’il arrive) et la normalisation (nettoyer quelque chose après, avant qu’il n’entre dans les annales).

Les scénarios d’interception ont tous la même forme. Un hook PreToolUse refuse les commandes Bash qui matchent rm -rf, refuse les écritures hors du répertoire de migration, force une confirmation sur tout ce qui contient production dans le chemin. La mécanique de décision : un hook communique par code de sortie et, pour un contrôle plus riche, en JSON sur stdout — le code 0 laisse l’appel passer, le code 2 le bloque, et une décision JSON peut dire approve, deny (avec une raison que le modèle lit vraiment) ou ask, et peut même réécrire l’entrée de l’outil avant son exécution. Ce dernier point mérite réflexion : un hook peut silencieusement corriger un chemin, injecter un drapeau obligatoire ou caviarder un secret au vol. Le refus motivé vaut généralement mieux que la correction silencieuse, parce que le modèle apprend de la raison — les corrections silencieuses produisent un agent qui continue d’essayer la chose cassée.

La normalisation PostToolUse est là où vit l’hygiène des données : retirer tokens et données personnelles des sorties d’outils avant qu’elles n’entrent dans la transcription, reformater un fouillis en JSON sur lequel les étapes suivantes pourront compter, consigner l’appel dans votre piste d’audit. Le cadrage que l’examen récompense : la transcription est du contexte — tout ce que vous y laissez entrer devient partie de chaque décision future, donc normaliser la sortie d’outil est de l’ingénierie de contexte, pas du rangement. Deux notes de bas de page : les événements de hook diffèrent entre les langages du SDK et Claude Code (tout n’existe pas partout — à jour de septembre 2026), et la chaîne de permissions complète s’exécute hooks → règles deny → règles ask → mode de permission → règles allow → rappel canUseTool du SDK. Les hooks passent premiers ; rien en aval ne peut sauver ce qu’un hook a refusé.

07Stratégies de décomposition des tâches

Avec un coordinateur et des ouvriers, comment découper le travail ? Le catalogue de réponses de l’examen compte quatre formes, et les scénarios se reconnaissent à celle qui convient. Map–reduce : découpez la tâche en unités indépendantes, traitez-les en parallèle, puis combinez — un subagent par service pour la vague d’audit, résultats fusionnés par le coordinateur. Le test du map–reduce, c’est l’indépendance : les unités ne doivent pas avoir besoin de l’état intermédiaire des autres. Pipeline : des étapes fixes, la sortie de chaque agent étant l’entrée du suivant — le chercheur rédige, l’éditeur réécrit, le vérificateur contrôle. Le test, c’est la spécialisation : chaque étape veut un prompt ou un jeu d’outils différent. L’hybride — un pipeline de map–reduce — est la vraie vie : la plupart des systèmes en production sont une étape de recherche qui éclate, une étape de synthèse, une étape de revue qui éclate à nouveau.

La quatrième forme est celle qu’on oublie : ne pas décomposer. Un agent unique avec de bons outils bat un comité sur toute tâche qui tient dans une fenêtre de contexte, parce que la coordination n’est pas gratuite — chaque brief écrit, chaque rapport réconcilié, chaque conflit arbitré est du travail et du risque qu’une tâche mono-fenêtre n’a jamais réclamés. Les deux modes d’échec que l’examen teste sont symétriques : la sous-décomposition (un agent qui se noie dans son périmètre — symptômes : épuisement du contexte, contraintes oubliées, qualité dégradée en fin d’exécution) et la sur-décomposition (un essaim dont le coût de coordination et les bugs d’interface dépassent la tâche elle-même — symptômes : sorties d’ouvriers contradictoires, coordinateur réduit à du copier-coller). Décomposez sur preuves — la tâche dépasse vraiment une fenêtre, ou exige vraiment des jeux d’outils ou de permissions différents — pas par ambition.

Deux règles de conception rendent toute décomposition digne de confiance. Définissez l’unité de travail pour qu’elle soit autoporteuse — un ouvrier doit pouvoir réussir à partir de son brief seul, parce qu’il ne voit rien d’autre. Et définissez l’interface entre étapes avant d’écrire le moindre prompt — ce qu’un ouvrier renvoie (format, champs, confiance) est un contrat ; la justesse du coordinateur ne peut jamais dépasser la discipline de sortie des ouvriers.

08État de session, reprise et fork

Le travail agentique est long, et le travail long s’interrompt — crashes, déploiements, le simple fait qu’un humain soit rentré chez lui. Les mécaniques de session sont ce qui permet à une exécution de survivre à une pause. Dans l’Agent SDK, une session est une conversation persistante avec un identifiant : même identifiant de session à la requête suivante, et l’exécution reprend où elle s’était arrêtée — historique complet intact, rien à relire, rien à raisonner à nouveau. Un nouvel identifiant de session repart de zéro. Dans Claude Code, le même levier existe sous forme de --resume pour continuer une session enregistrée et --fork-session pour reprendre une conversation dans une nouvelle session sans toucher à l’originale — créer une branche, expérimenter, comparer.

Le fork est la moitié architecturalement intéressante. Un fork partage l’historique du parent jusqu’à un point et diverge après — le motif derrière « essayer le correctif risqué dans une branche », comparer deux approches à partir d’une même investigation partagée, ou relancer une revue avec une checklist différente sans payer deux fois l’exploration. Notez ce que le fork n’est pas : ce n’est pas un mécanisme de reprise après crash. La reprise (resumption) est la continuité ; le fork est l’expérience en parallèle. Les verbes du scénario vous disent lequel l’examen veut — « continuer » signifie reprendre, « comparer » ou « essayer les deux » signifie forker.

Les questions de conception qui valent des points : ce qui appartient à l’état de session (la conversation — et c’est tout ce que la plateforme vous promet) contre ce qui appartient dehors (tout ce que votre flux doit durablement garder : artefacts écrits sur disque, résultats en base, progression dans votre propre stockage — parce qu’une session reprise restaure la transcription, pas le système de fichiers ni la mémoire de votre processus). Quand l’agent d’un scénario reprend et « oublie » un fichier qu’il avait créé, ce n’est pas un bug à corriger par un prompt plus astucieux ; c’est un état qui aurait dû vivre dans la conception, pas dans la session.

09Les pièges de ce domaine

• —« Donne plus de liberté à l’agent pour gérer les cas limites. » La liberté se paie. Le réflexe de l’architecte : le plus petit jeu d’outils et l’ensemble de permissions le plus serré qui fassent le travail — les cas limites se traitent par de meilleurs outils et des contrats plus clairs, pas par des laisses plus lâches.
• —« Le multi-agents est l’évolution naturelle ; l’agent seul, c’est l’entrée de gamme. » C’est l’inverse. La chose la plus simple qui fonctionne est la réponse du sénior ; un coordinateur existe parce que la tâche dépasse une fenêtre ou un jeu d’outils, pas parce qu’un schéma serait plus joli.
• —« Les subagents partagent le contexte, le coordinateur n’a qu’à le pointer. » Non. Le contexte se passe par valeur, par brief. Chaque scénario « l’ouvrier aurait dû savoir ce que l’autre a trouvé » est une erreur de conception, et le remède passe par le coordinateur.
• —« Le hook a échoué, mais le mode de permission l’autorisait, donc ça s’est exécuté. » Non. La chaîne exécute les hooks en premier ; un refus de hook ne se rattrape pas en aval. L’ordre : hooks → deny → ask → mode → allow → canUseTool.
• —« Monte la limite de tours pour qu’il arrête de se tronquer. » Les budgets sont des filets. Une exécution qui les atteint est mal cadrée — mieux décomposée ou avec des résultats d’outils réparés. La réponse « augmenter la limite » est la réponse-piège.
• —« La reprise restaure tout après le crash. » Elle restaure la conversation. Fichiers, environnement et état applicatif n’y ont jamais vécu.