CCAR-F – Présentation du cours

Code d’examen CCAR-F 60 items · 120 min 125 $ Réussite 720/1000

Ce que valide la certification

Que vous savez concevoir des systèmes agentiques sur Claude qui soient corrects, fiables et attentifs au coût — choisir entre flux de travail et agents, orchestrer des hiérarchies coordinateur/sous-agents, configurer Claude Code pour des équipes, faire de l’ingénierie de prompts et de sortie structurée, concevoir des outils et des intégrations MCP, et gérer la fenêtre de contexte et les modes de défaillance qui font ou défont les systèmes en production.

L’examen Architect – Foundations est piloté par scénarios. Les items sont tirés de 4 des 6 scénarios de référence : vous devez donc savoir raisonner sur un système décrit, et pas seulement restituer une définition. Chaque question demande en réalité : étant données ces contraintes, quelle est la décision architecturale correcte, et quelles options tentantes sont les anti-patterns ?

Public visé : les architectes de solutions, les référents techniques et les ingénieurs seniors qui conçoivent des systèmes agentiques fondés sur Claude et fixent les standards pour les équipes qui construisent avec l’API, l’Agent SDK, Claude Code et MCP.

Public non visé : les utilisateurs métier non techniques (voir l’Associate CCAO-F) ou ceux qui écrivent uniquement du code applicatif sans concevoir le système (une grande partie du Developer CCDV-F recoupe le sujet mais reste orientée mise en œuvre).

Blueprint (Exam Guide v1.0, juillet 2026)

#	Domaine	Poids	Items (approx.)	Page du cours
1	Agentic Architecture and Orchestration	27 %	~16	Domaine 1
2	Claude Code Configuration and Workflows	20 %	~12	Domaine 2
3	Prompt Engineering and Structured Output	20 %	~12	Domaine 3
4	Tool Design and MCP Integration	18 %	~11	Domaine 4
5	Context Management and Reliability	15 %	~9	Domaine 5

Les six scénarios d’examen

Les items sont tirés de 4 des 6 scénarios ci-dessous. Vous ne saurez pas à l’avance lesquels : préparez donc les six. Chacun correspond à un groupe de domaines.

#	Scénario	Domaines principaux	Décisions caractéristiques
1	Customer Support Resolution Agent	D1, D4, D5	Agent SDK, outils MCP, escalade fondée sur la capacité
2	Code Generation with Claude Code	D2, D3	hiérarchie CLAUDE.md, plan mode, slash commands, hooks
3	Multi-Agent Research System	D1, D5	coordinateur/sous-agents, passage de contexte explicite, gestion des défaillances partielles
4	Developer Productivity	D2, D4	outils intégrés, serveurs MCP, exploration du code
5	Claude Code for CI/CD	D2, D3	headless mode, sortie structurée, Batch API, revue multi-passes
6	Structured Data Extraction	D3, D4	schémas JSON, tool_use-comme-schéma, reprise sur validation

Les descriptions complètes, les architectures de référence et 18 questions d’entraînement figurent sur la page Scénarios.

L’état d’esprit de l’Architect

L’examen récompense constamment une posture : le déterminisme là où la justesse compte, le modèle là où le jugement compte, et des contrats explicites partout entre les deux. Les bonnes réponses tendent à :

• Préférer la solution la plus simple qui satisfait l’exigence — un prompt unique ou un flux de travail avant un système multi-agents.
• Piloter le flux de contrôle depuis stop_reason, non par l’analyse de la prose du modèle ni par le plafonnement des itérations.
• Faire respecter les règles métier critiques par des hooks programmatiques, jamais par des instructions de prompt.
• Escalader sur demande explicite (immédiatement) ou par capacité (après avoir tenté la résolution) — jamais sur le sentiment ni sur la confiance auto-déclarée.
• Passer le contexte aux sous-agents de manière explicite ; ne jamais compter sur l’auto-héritage.
• Faire remonter des erreurs structurées (catégorie, réessayable, résultats partiels) plutôt que des messages génériques ou des résultats vides silencieux.
• Donner à chaque agent 4 à 5 outils ciblés ; recourir à la recherche d’outils et à defer_loading au-delà d’~10.
• Protéger la fenêtre de contexte principale par l’isolation des sous-agents, l’édition de contexte et la compaction, et placer tout ce qui doit survivre dans le memory tool ou un état externe.

Les mauvaises réponses tendent à : sur-concevoir (multi-agents là où un flux de travail suffit), faire confiance à l’auto-évaluation du modèle, faire respecter les règles par le prompt, masquer les erreurs, surcharger les agents d’outils, et laisser la fenêtre de contexte se remplir jusqu’à dégrader la qualité.

Répartition du temps suggérée (plan sur 30 heures)

Domaine	Poids	Heures
Agentic Architecture and Orchestration	27 %	9
Claude Code Configuration and Workflows	20 %	6
Prompt Engineering and Structured Output	20 %	6
Tool Design and MCP Integration	18 %	5
Context Management and Reliability	15 %	4

Liste de préparation pratique

• Construisez un système coordinateur/sous-agents à deux niveaux et passez le contexte à un sous-agent de manière explicite ; observez ce qui casse si vous comptez sur l’héritage.
• Mettez en œuvre une boucle agentique qui se termine sur stop_reason et gère tool_use, end_turn, max_tokens, pause_turn et refusal.
• Écrivez un PreToolUse hook Claude Code qui bloque rm -rf et un PostToolUse hook qui exécute un linter ; confirmez que le code de sortie 2 bloque l’action.
• Configurez une hiérarchie CLAUDE.md de projet avec un @import et un sous-agent .claude/agents/ doté de sa propre liste d’outils autorisés et de son propre modèle.
• Obtenez une sortie structurée de trois façons — schéma JSON output_config.format, tool-use-comme-schéma et strict tools — et notez quand chacune est la bonne.
• Mettez en place un serveur MCP minimal (stdio) exposant un outil et une ressource ; connectez-le depuis Claude Code et via le connecteur MCP de la Messages API.
• Forcez une boucle de reprise sur validation : renvoyez une erreur de schéma au modèle et confirmez qu’il se corrige de lui-même.
• Déclenchez la compaction et l’édition de contexte sur une session longue ; vérifiez ce qui survit via le memory tool.

Pages du cours