CCA-F Domaine 1 — Architecture agentique & orchestration (27 %) : la leçon complète

Le domaine 1 pèse 27 % de la note — environ 16 questions sur 60. C'est le plus lourd des cinq, et c'est aussi celui où les candidats expérimentés se plantent le plus : ils connaissent les agents, mais l'examen ne teste pas « est-ce que tu sais faire un agent ». Il teste si tu choisis le bon mécanisme dans une situation de production donnée — et neuf fois sur dix, le piège consiste à proposer une instruction dans le prompt là où l'examen attend un mécanisme programmatique.

Cette leçon suit exactement les 7 « task statements » du guide officiel v1.0 (juillet 2026). Chaque section donne le concept, le schéma, ce qu'il faut savoir, ce que l'examen attend comme réflexe, et le piège associé. À la fin : la checklist de la veille, cinq questions-scénario originales corrigées, un quiz et le lexique du domaine. Les deux scénarios d'examen qui tirent le plus sur ce domaine sont le Customer Support Resolution Agent (scénario 1) et le Multi-Agent Research System (scénario 3) — garde-les en tête, la plupart des questions y sont ancrées.

La carte du domaine

Avant le détail, la vue d'ensemble. Les sept task statements ne sont pas indépendants : ils forment trois couches. La mécanique de base (boucle, sessions), la coordination (hub-and-spoke, sous-agents, décomposition), et les garde-fous (enforcement, hooks). L'examen mélange les couches dans un même scénario ; toi, tu dois savoir instantanément à quelle couche appartient la question.

1.1 — La boucle agentique : le contrat stop_reason

Un agent n'est rien d'autre qu'une boucle : tu envoies une requête à Claude avec des outils, tu regardes pourquoi il s'est arrêté, tu exécutes ce qu'il demande, tu lui renvoies le résultat, et tu recommences. Tout le domaine repose sur cette mécanique, et l'examen la teste avec une précision chirurgicale.

Ce qu'il faut savoir

Le cycle. Requête → inspection de stop_reason → exécution des outils demandés → ajout des tool_result à l'historique → nouvelle requête. Le point qui fait la différence entre un agent et un simple appel : le résultat d'outil est réinjecté dans la conversation, ce qui permet au modèle de décider de l'action suivante à la lumière de ce qu'il vient d'apprendre.

Les deux valeurs qui comptent. "tool_use" signifie « j'ai besoin que tu exécutes ceci » : la boucle continue. "end_turn" signifie « j'ai fini » : la boucle s'arrête et tu présentes la réponse. Il existe d'autres valeurs ("max_tokens", "stop_sequence", "refusal"), mais l'examen se concentre sur ces deux-là ; "max_tokens" est à traiter comme une anomalie (sortie tronquée), jamais comme une fin normale.

Décision pilotée par le modèle vs arbre de décision. Un agent au sens de l'examen, c'est Claude qui choisit lui-même quel outil appeler ensuite, en fonction du contexte. Un arbre de décision pré-câblé (« d'abord get_customer, puis lookup_order, puis… ») est un workflow, pas un agent. L'examen te demandera parfois lequel des deux convient : la réponse dépend de la prévisibilité de la tâche (voir 1.6).

from anthropic import Anthropic
client = Anthropic()

def run_agent(system: str, tools: list, user_msg: str, max_turns: int = 40) -> str:
    messages = [{"role": "user", "content": user_msg}]
    for _ in range(max_turns):                       # filet de sécurité, PAS la condition d'arrêt
        resp = client.messages.create(
            model="claude-sonnet-4-5", max_tokens=2048,
            system=system, tools=tools, messages=messages,
        )
        messages.append({"role": "assistant", "content": resp.content})

        if resp.stop_reason == "end_turn":           # ← la SEULE fin normale
            return "".join(b.text for b in resp.content if b.type == "text")

        if resp.stop_reason != "tool_use":           # max_tokens, refusal… → anomalie
            raise RuntimeError(f"stop_reason inattendu: {resp.stop_reason}")

        results = []
        for block in resp.content:
            if block.type == "tool_use":
                try:
                    out = execute_tool(block.name, block.input)
                    results.append({"type": "tool_result", "tool_use_id": block.id,
                                    "content": out})
                except Exception as e:               # on renvoie l'erreur, on ne casse pas la boucle
                    results.append({"type": "tool_result", "tool_use_id": block.id,
                                    "content": str(e), "is_error": True})
        messages.append({"role": "user", "content": results})   # ← réinjection

    raise RuntimeError("Plafond de tours atteint — à traiter comme un incident")

Les trois anti-patterns que l'examen adore

Le guide officiel les liste explicitement. Si tu vois l'un d'eux dans une option de réponse, c'est un distracteur.

1. Parser le langage naturel pour détecter la fin. Chercher « J'ai terminé » ou « Voici le résultat final » dans le texte. La formulation de Claude varie ; c'est fragile par construction.
2. Un plafond d'itérations comme mécanisme d'arrêt principal. for i in range(10) sans regarder stop_reason. Le plafond est un filet de sécurité contre les boucles infinies, pas une condition d'arrêt fonctionnelle.
3. Tester la présence de texte dans la réponse. « S'il y a un bloc texte, c'est fini. » Faux : une réponse peut contenir du texte et un tool_use (« Je vais vérifier la commande… » suivi de l'appel).

1.2 — Hub-and-spoke : le coordinateur au centre

Dès qu'un système a plusieurs agents spécialisés, la question devient : qui parle à qui ? L'examen a une réponse unique et l'applique partout : le coordinateur au centre, les sous-agents en rayons, jamais de communication directe entre rayons.

Ce qu'il faut savoir

Le rôle du coordinateur. Il décompose la tâche, délègue, agrège les résultats, gère les erreurs, et — point important — décide quels sous-agents invoquer selon la complexité de la requête. Un coordinateur qui fait systématiquement passer chaque requête par les quatre sous-agents dans le même ordre est un pipeline déguisé ; l'examen attend une sélection dynamique.

Le contexte isolé. Un sous-agent ne voit pas l'historique du coordinateur. Il ne voit que ce qu'on lui met dans son prompt. Corollaire : si le sous-agent de synthèse a besoin des résultats de la recherche, c'est au coordinateur de les lui passer, en clair, dans le prompt.

Le risque de décomposition trop étroite. C'est la question 7 du guide officiel, et elle est emblématique : un système de recherche sur « l'impact de l'IA sur les industries créatives » ne produit que des résultats sur les arts visuels. Les sous-agents ont tous bien travaillé. Le coupable est le coordinateur, qui a découpé le sujet en « art numérique, design graphique, photographie » — en oubliant la musique, l'écriture, le cinéma. Réflexe d'examen : quand les sous-agents ont réussi mais que la couverture est incomplète, regarde la décomposition, pas l'exécution.

Le partitionnement du périmètre. Pour éviter que deux sous-agents fassent le même travail, on leur assigne des sous-sujets distincts ou des types de sources distincts (académique / presse / données). C'est du partitionnement, pas de la redondance.

La boucle de raffinement itératif. Le coordinateur évalue la synthèse, repère les trous, re-délègue des requêtes ciblées aux sous-agents de recherche et d'analyse, puis relance la synthèse — jusqu'à ce que la couverture soit suffisante. Ce n'est pas un pipeline à passage unique.

1.3 — Sous-agents : Task, allowedTools, contexte explicite

Cette section est celle des détails de configuration du Claude Agent SDK. Elle est courte à apprendre et rapporte beaucoup : les questions sont factuelles.

Ce qu'il faut savoir

L'outil Task. C'est le mécanisme de spawn d'un sous-agent dans le Claude Agent SDK. Pour qu'un coordinateur puisse invoquer des sous-agents, son allowedTools doit inclure "Task". Si un coordinateur « ne délègue jamais » malgré un prompt qui le lui demande, la première chose à vérifier est cette configuration.

Le contexte est explicite, toujours. Le sous-agent n'hérite pas du contexte parent et n'a pas de mémoire entre deux invocations. Si le sous-agent de synthèse doit travailler sur les résultats de la recherche web et de l'analyse de documents, ces résultats doivent être inclus en entier dans son prompt. Pas un pointeur, pas « comme vu précédemment » : le contenu.

AgentDefinition. Chaque type de sous-agent est configuré avec une description (qui sert au coordinateur pour choisir), un system prompt, et des restrictions d'outils. Un sous-agent de synthèse n'a pas besoin de la recherche web ; lui donner tous les outils dégrade la fiabilité de sélection (c'est aussi un thème du domaine 2).

Contenu vs métadonnées. Quand on passe du contexte entre agents, on sépare les deux dans un format structuré : le texte de la trouvaille d'un côté, l'URL source, le nom du document, la page de l'autre. Sinon l'attribution se perd à la synthèse (thème repris au domaine 5).

Parallélisme en un seul tour. Pour lancer trois sous-agents en parallèle, le coordinateur émet trois appels Task dans la même réponse, pas un par tour. Un appel par tour = exécution séquentielle = latence triplée.

Objectifs, pas procédures. Le prompt d'un coordinateur vers un sous-agent spécifie le but et les critères de qualité (« couvrir les cinq secteurs, citer des sources datées de moins de deux ans, signaler les statistiques contradictoires »), pas une procédure pas à pas. Le sous-agent doit pouvoir s'adapter à ce qu'il découvre.

Fork. fork_session permet de créer plusieurs branches indépendantes à partir d'une analyse commune, pour explorer des approches divergentes sans refaire l'analyse de base (détaillé en 1.7).

# Sketch conceptuel (Claude Agent SDK) — lancement parallèle de deux sous-agents
# Le coordinateur émet DEUX appels Task dans une seule réponse.
coordinator = AgentDefinition(
    description="Coordonne la recherche, agrège, contrôle la couverture",
    prompt=COORD_SYSTEM,
    tools=["Task"],                      # sans "Task", aucune délégation possible
)
web_search = AgentDefinition(
    description="Recherche des sources web récentes sur un sous-sujet précis",
    prompt=WEB_SYSTEM, tools=["WebSearch", "WebFetch"],   # scope minimal
)
doc_analysis = AgentDefinition(
    description="Analyse des documents fournis et extrait des faits sourcés",
    prompt=DOC_SYSTEM, tools=["Read"],
)

# Contexte passé EXPLICITEMENT au sous-agent de synthèse (pas d'héritage) :
synthesis_prompt = f"""
Objectif : rapport sur {topic}. Critères : couvrir {sectors}, citer sources datées.
== Trouvailles recherche web (JSON, claim/source/date) ==
{json.dumps(web_findings, ensure_ascii=False)}
== Trouvailles analyse documents ==
{json.dumps(doc_findings, ensure_ascii=False)}
"""

1.4 — Enforcement et handoff : quand le prompt ne suffit plus

C'est le cœur philosophique du domaine, et la question 1 du guide officiel en est l'archétype : dans 12 % des cas, l'agent saute get_customer et appelle lookup_order avec le seul nom déclaré par le client. Résultat : comptes mal identifiés, remboursements erronés. Que faire ?

Ce qu'il faut savoir

Deux régimes. Le guidage par prompt (instructions, few-shot) est probabiliste : il améliore les taux, il ne garantit rien. L'enforcement programmatique (gates de prérequis, hooks) est déterministe : l'action non conforme n'est physiquement pas possible. Le choix dépend d'une seule question : que se passe-t-il si ça échoue une fois sur cent ? Un ton un peu sec, on s'en remet. Un remboursement sur le mauvais compte, non.

Le gate de prérequis. On bloque les appels aval (lookup_order, process_refund) tant qu'un appel amont (get_customer) n'a pas rendu un identifiant vérifié. Le blocage renvoie un tool_result d'erreur explicite ; l'agent se corrige et continue. Note que l'option « classifier la requête et n'activer que les outils pertinents » (option D de la question 1) règle un problème de disponibilité des outils, pas d'ordre — c'est le distracteur le plus subtil.

Le handoff structuré. Quand l'agent escalade vers un humain en cours de traitement, l'humain n'a pas accès à la transcription. Le résumé de transfert doit donc être structuré et autoportant : identifiant client, cause racine identifiée, montant en jeu, action recommandée, ce qui a déjà été tenté. « Le client est mécontent, voir la conversation » n'est pas un handoff.

Les demandes multi-sujets. « Mon colis est arrivé cassé, ET je vois deux prélèvements, ET je veux changer d'adresse. » Le pattern attendu : décomposer en items distincts, investiguer chacun en parallèle avec le contexte partagé (même client, même session), puis synthétiser une réponse unifiée. Pas traiter le premier item et oublier les deux autres, pas les traiter en série avec trois allers-retours client.

# Gate de prérequis — enforcement programmatique dans la boucle d'outils
REQUIRES_VERIFIED_CUSTOMER = {"lookup_order", "process_refund", "update_address"}

def execute_tool(name: str, args: dict, state: dict):
    if name in REQUIRES_VERIFIED_CUSTOMER and not state.get("verified_customer_id"):
        # L'appel n'est pas exécuté. L'agent reçoit une erreur actionnable.
        return {"error": "PREREQUISITE_MISSING",
                "message": "Appelle get_customer et obtiens un ID vérifié avant cette opération.",
                "retryable": True}
    if name == "get_customer":
        result = backend.get_customer(**args)
        if result.get("verified"):
            state["verified_customer_id"] = result["customer_id"]
        return result
    return backend.call(name, args)

# Handoff structuré vers un humain — autoportant, pas un renvoi à la transcription
def build_handoff(state, analysis) -> dict:
    return {
        "customer_id": state["verified_customer_id"],
        "root_cause": analysis["root_cause"],
        "amount_at_stake_eur": analysis["amount"],
        "recommended_action": analysis["recommendation"],
        "already_attempted": state["actions_log"],
        "policy_gap": analysis.get("policy_gap"),   # pourquoi l'agent n'a pas pu conclure
    }

1.5 — Les hooks du SDK : intercepter avant et après

Les hooks sont l'outillage concret de l'enforcement. Le Claude Agent SDK expose des points d'interception autour de chaque appel d'outil ; l'examen en teste deux usages précis.

Ce qu'il faut savoir

Le hook d'interception d'appel (avant). Il examine l'appel que le modèle veut faire et peut le bloquer selon une règle métier — l'exemple canonique du guide est bloquer tout process_refund au-dessus de 500 € et rediriger vers l'escalade humaine. C'est déterministe : le remboursement de 800 € ne part jamais, quoi que le modèle ait décidé.

Le hook PostToolUse (après). Il transforme le résultat d'un outil avant que le modèle ne le lise. Cas typique : trois serveurs MCP renvoient des dates en Unix timestamp, en ISO 8601, et en « 12/03/2026 », et des statuts tantôt numériques tantôt textuels. Plutôt que de demander au modèle de jongler (et de se tromper), on normalise dans le hook. Le modèle voit toujours le même format.

Hooks vs prompt. Même logique qu'en 1.4 : les hooks fournissent des garanties, le prompt fournit des probabilités. Quand une règle métier « doit » être respectée, c'est un hook.

# Hooks conceptuels (Claude Agent SDK) — noms et signatures simplifiés
from datetime import datetime, timezone

def pre_tool_use(tool_name: str, tool_input: dict, ctx):
    """Interception AVANT exécution : enforcement d'une règle métier."""
    if tool_name == "process_refund" and tool_input.get("amount_eur", 0) > 500:
        ctx.escalate(reason="refund_over_threshold", payload=tool_input)
        return {"block": True,
                "message": "Remboursement > 500 € : transféré à un agent humain."}
    return {"block": False}

STATUS_MAP = {1: "pending", 2: "processing", 3: "shipped", 4: "delivered"}

def post_tool_use(tool_name: str, result: dict, ctx) -> dict:
    """Interception APRÈS exécution : normalisation avant lecture par le modèle."""
    if isinstance(result.get("created_at"), int):                 # Unix ts → ISO
        result["created_at"] = datetime.fromtimestamp(
            result["created_at"], tz=timezone.utc).isoformat()
    if isinstance(result.get("status"), int):                     # code → libellé
        result["status"] = STATUS_MAP.get(result["status"], "unknown")
    return result

1.6 — Décomposition de tâches : chaîne fixe ou plan adaptatif

Ici l'examen ne teste pas « sais-tu découper une tâche » mais « sais-tu choisir entre deux stratégies de découpage selon la nature du travail ».

Ce qu'il faut savoir

Prompt chaining. Une séquence fixe d'étapes, chacune alimentant la suivante. Idéal pour un travail prévisible à aspects multiples : une revue de code passe sécurité, puis performance, puis lisibilité — toujours dans cet ordre, toujours les mêmes passes.

Décomposition dynamique. Le plan se construit au fur et à mesure. « Ajouter des tests complets à un code legacy » ne se planifie pas d'avance : on cartographie d'abord la structure, on identifie les zones à fort impact, on produit un plan priorisé, et ce plan s'adapte quand on découvre une dépendance inattendue.

Le cas des grosses revues. C'est la question 12 du guide officiel : une PR de 14 fichiers, une revue en une seule passe, et des résultats incohérents (feedback détaillé sur certains fichiers, superficiel sur d'autres, un pattern signalé ici et approuvé là). Cause : dilution de l'attention. Solution attendue : des passes par fichier pour les problèmes locaux, puis une passe d'intégration séparée pour le flux inter-fichiers. Les distracteurs : « un modèle avec plus de contexte » (la taille du contexte ne règle pas la qualité de l'attention), « imposer des PR plus petites » (déplace le problème), « trois passes et vote majoritaire » (supprime la détection des vrais bugs intermittents).

1.7 — Sessions : reprendre, brancher, repartir de zéro

Dernier task statement, orienté Claude Code et Agent SDK. Trois mécanismes, et surtout : savoir quand ne pas reprendre.

Ce qu'il faut savoir

Reprise nommée. --resume <nom-de-session> continue une conversation précise. On nomme ses sessions d'investigation (audit-paiements, migration-orm) pour pouvoir y revenir d'une journée de travail à l'autre.

Signaler les changements. Si tu reprends une session après avoir modifié du code, dis-le à l'agent : « les fichiers X et Y ont changé depuis ton analyse ». Il ré-analyse de façon ciblée au lieu de tout ré-explorer — ou pire, de raisonner sur une version périmée sans le savoir.

Résultats périmés → session neuve. Si la majorité des résultats d'outils de l'ancienne session ne sont plus valides (refactoring large, dépendances changées), reprendre la session revient à raisonner sur du faux. La bonne réponse est de démarrer une session neuve avec un résumé structuré des conclusions encore valides, injecté en contexte initial. Plus fiable, et moins de tokens.

fork_session. Depuis une analyse de base commune (par exemple, la cartographie d'un codebase), on crée deux branches indépendantes pour explorer deux approches (deux stratégies de tests, deux plans de refactoring) sans refaire l'analyse et sans que les branches se contaminent.

Les pièges transversaux du domaine 1

En plus des pièges par section, quatre réflexes de lecture qui valent sur toutes les questions du domaine.

1. La proportion. L'examen favorise la réponse « proportionnée » : la première étape à faible effort qui traite la cause racine. Un classifieur ML séparé, une couche de routage, un modèle plus gros sont presque toujours sur-dimensionnés quand une correction de configuration ou un gate suffit.
2. La cause racine, pas le symptôme. Quand les logs sont donnés dans l'énoncé, ils désignent le coupable. Lis-les avant les options.
3. Garantie vs probabilité. Si le scénario mentionne une conséquence réelle (argent, données, conformité), une solution probabiliste est éliminée d'office.
4. Séparation des rôles. Toute option qui donne à un agent des outils hors de son rôle, ou qui fait communiquer deux sous-agents directement, viole le pattern attendu.

Checklist de la veille

Cinq questions-scénario originales, corrigées

Ces questions sont écrites par nAIvigate dans l'esprit de l'examen. Elles ne reproduisent aucun item réel (le contenu de l'examen est confidentiel). Cache les corrections, réponds, puis compare.

Question 1 — Scénario support. Ton agent de support utilise une boucle qui s'arrête dès qu'un bloc text apparaît dans la réponse. En production, 8 % des sessions se terminent avec une réponse du type « Je vais vérifier votre commande… » sans que la vérification ait lieu. Quelle est la correction la plus juste ?

A. Ajouter au prompt : « Ne produis jamais de texte avant d'avoir appelé tous les outils nécessaires. » B. Continuer la boucle tant que stop_reason == "tool_use" et ne s'arrêter que sur "end_turn", quel que soit le contenu textuel. C. Passer le plafond d'itérations de 5 à 15. D. Détecter la phrase « Je vais vérifier » et forcer un tour supplémentaire.

Question 2 — Scénario recherche. Ton coordinateur lance les sous-agents de recherche web, d'analyse de documents, de synthèse et de rapport, dans cet ordre, sur chaque requête — y compris « quelle est la date de publication du rapport X ? ». La latence moyenne est de 4 minutes. Que changer en priorité ?

A. Paralléliser les quatre sous-agents. B. Faire analyser la complexité de la requête par le coordinateur et n'invoquer que les sous-agents nécessaires. C. Remplacer le sous-agent de synthèse par un appel API direct. D. Réduire le nombre de résultats renvoyés par la recherche web.

Question 3 — Scénario support. La politique interdit tout remboursement au-dessus de 300 € sans validation humaine. Le prompt le précise en gras. Un audit trouve 4 remboursements de 350 à 600 € passés sans validation en un mois. Quelle mesure garantit la conformité ?

A. Réécrire l'instruction en majuscules et la répéter en fin de prompt système. B. Ajouter cinq exemples few-shot d'escalade pour des montants élevés. C. Un hook d'interception qui bloque process_refund quand amount > 300 et déclenche l'escalade humaine. D. Demander à l'agent de s'auto-évaluer sur une échelle de confiance avant chaque remboursement.

Question 4 — Scénario recherche. Le sous-agent de synthèse produit des rapports qui ignorent les documents internes pourtant analysés par le sous-agent d'analyse. Les logs montrent que l'analyse s'est bien exécutée et a renvoyé 14 faits sourcés au coordinateur. Cause la plus probable ?

A. Le sous-agent de synthèse a un system prompt trop court. B. Le coordinateur n'a pas inclus les 14 faits dans le prompt envoyé au sous-agent de synthèse. C. Le sous-agent d'analyse devrait appeler directement le sous-agent de synthèse. D. Il faut donner au sous-agent de synthèse l'outil Read pour relire les documents.

Question 5 — Scénario productivité développeur. Tu as une session nommée audit-auth où l'agent a cartographié le module d'authentification. Depuis, l'équipe a refactoré 70 % de ce module. Tu veux maintenant générer des tests. Meilleure approche ?

A. --resume audit-auth et demander la génération de tests. B. --resume audit-auth en indiquant que « quelques fichiers ont changé ». C. Démarrer une session neuve en injectant un résumé structuré des conclusions encore valides (frontières du module, dépendances externes, conventions). D. fork_session depuis audit-auth pour tester deux stratégies.

Quiz de validation

Pour aller plus loin

La suite logique est le Domaine 2 — Tool Design & MCP (18 %), qui reprend la question des outils par sous-agent, des descriptions et des erreurs structurées. Les questions de contexte isolé et d'attribution des sources reviennent au domaine 5. Pour la mécanique complète des agents Claude en production, notre formation sur l'architecture des systèmes agentiques et le guide mettre en place des agents Claude communicants donnent le code complet.

Si tu veux certifier une équipe entière — ou passer d'une préparation théorique à un système multi-agents réellement déployé, avec ses gates, ses hooks et son observabilité — c'est précisément ce que nAIvigate Studio fait en Sprint.