Table des matières
1. Format de l'examen (rappel)
| Élément | Détail |
|---|---|
| Code d'examen | CCAR-F |
| Nombre de questions | 60 items |
| Durée | 120 minutes (≈ 2 min/question) |
| Type de questions | QCM — chaque item indique le nombre de réponses à sélectionner (une ou plusieurs) |
| Score | Échelle de 100 à 1000, passing score = 720 |
| Scénarios | 4 scénarios sélectionnés aléatoirement sur les 6 possibles |
| Plateforme | Proctored via Pearson VUE — proctoring en ligne ou centre d'examen |
| Tentatives | Jusqu'à 4 tentatives par période de 12 mois, délais de repassage 14/30/90 jours après échecs successifs |
Pratique avant le jour J : l'examen tire 4 scénarios au hasard sur les 6 ci-dessous — tu ne peux donc en négliger aucun. Travaille les 6, puis les 112 QCM corrigés : c'est le seul entraînement chronométrable dont tu disposes ici. Les 12 premières questions sont les exemples officiels du guide, elles donnent le calibrage exact du niveau attendu.
Stratégie critique : réponds à TOUTES les questions, même en cas de doute — une réponse laissée vide est forcément fausse, une réponse tentée a une chance d'être juste. Ne jamais laisser une question vide.
Implication : Comme tu ne sais pas quels 4 scénarios tomberont, il faut maîtriser les 6 scénarios. Chaque scénario teste principalement 2-3 domaines, mais tous les domaines sont couverts collectivement.
2. Les 6 scénarios
Scénario 1 : Customer Support Resolution Agent
Description : Construire un agent qui gère les retours, litiges de facturation et problèmes de compte avec le Claude Agent SDK. Utilise les MCP tools (get_customer, lookup_order, process_refund, escalate_to_human). Objectif : 80%+ first-contact resolution avec escalation appropriée.
Domaines principalement testés : D1 (agentic loop, hooks, enforcement), D2 (tool descriptions, tool_choice), D5 (escalation patterns, structured handoff)
Concepts clés à maîtriser
stop_reasonpour contrôler l'agentic loop- Programmatic enforcement : bloquer
process_refundsansget_customervérifié au préalable - Escalation triggers fiables : explicit request du client, policy gap, no progress — les trois, pas deux
- Escalation triggers NON fiables : sentiment analysis, self-rated confidence
- Structured handoff protocol : transmettre le contexte complet à l'humain
- Tool descriptions précises pour éviter le misrouting entre
get_customeretlookup_order - Few-shot examples pour les multi-issue requests
Pièges typiques dans les questions
"Improve the system prompt" quand le problème a des conséquences financières → la bonne réponse est hooks / programmatic enforcement, pas le prompt.
"Sentiment analysis" ou "self-rated confidence (1-10)" comme triggers d'escalation → ce sont des proxies unreliable. Privilégier les critères explicites.
"Add a routing classifier" → overengineering quand le vrai problème est la description des tools.
Scénario 2 : Code Generation with Claude Code
Description : Utiliser Claude Code pour accélérer le développement : génération, refactoring, debugging, documentation. Intégration avec custom slash commands et CLAUDE.md.
Domaines principalement testés : D3 (CLAUDE.md hierarchy, skills, planning mode, CI/CD), D5 (context management via Explore subagent)
Concepts clés à maîtriser
- CLAUDE.md hierarchy : user-level → project-level → directory-level
.claude/rules/avec YAML frontmatterpathspour conditional loading (glob patterns)- Commands :
.claude/commands/(project, VCS) vs~/.claude/commands/(personal) - Skills avec
context: fork,allowed-tools,argument-hint - Planning mode vs direct exécution : quand utiliser chacun
- Explore subagent pour isoler les outputs verbeux
Pièges typiques dans les questions
"Put everything in root CLAUDE.md" → utiliser
.claude/rules/ avec glob patterns pour charger conditionnellement les règles pertinentes.
"Claude Code learns per-user preferences" → FAUX. Il n'y a pas d'apprentissage par utilisateur : tout repose sur la CLAUDE.md hierarchy.
Confondre user-level et project-level → un nouveau membre de l'équipe qui n'a pas les bonnes instructions = probablement un problème de project-level CLAUDE.md manquant (il ne voit que son user-level).
Scénario 3 : Multi-Agent Research System
Description : Un coordinateur délègue à des subagents spécialisés : web research, document analysis, synthesis, report generation. Le système doit produire des rapports complets avec citations.
Domaines principalement testés : D1 (hub-and-spoke, Task tool, décomposition, parallel spawning), D2 (scoped tool access, erreurs structurées des subagents), D5 (error propagation, provenance, context management)
Concepts clés à maîtriser
- Hub-and-spoke : toute communication passe par le coordinateur, jamais directement entre subagents
- Subagent context isolation : context passing explicite à chaque délégation
- Narrow décomposition risk : ne couvrir que l'art visuel pour "creative industries" = couverture insuffisante
- Parallel spawning : multiple
Taskcalls dans une seule réponseTaskest le nom donné par le guide d'examen (réponse attendue) ; la doc Agent SDK actuelle parle de l'outilAgent. Même concept. - Structured error propagation :
failure_type,partial_results,alternatives - Coverage annotations dans la synthèse
- Provenance : claim-source mappings, conflicting data handling
- Lost-in-the-middle effect sur les aggregated results
Pièges typiques dans les questions
"Direct communication between subagents" → TOUJOURS via le coordinateur. C'est le principe fondamental du hub-and-spoke.
"Abort the whole workflow on one failure" → disproportionné. Continuer avec partial results et signaler le gap.
"Generic error status" → insuffisant. Utiliser structured error context avec
failure_type, partial_results, alternatives.
"Arbitrarily choose one value" quand des sources sont conflictuelles → preserve both with attribution. Laisser l'utilisateur décider.
Scénario 4 : Developer Productivity with Claude
Description : L'agent aide les développeurs à explorer des codebases inconnus, générer du boilerplate, et automatiser les tâches routinières. Utilise les built-in tools et MCP servers.
Domaines principalement testés : D2 (built-in tools, MCP), D3 (Claude Code config), D1 (subagent delegation, task decomposition)
Concepts clés à maîtriser
- Built-in tools :
Glob(find files by pattern),Grep(search content),Read/Write,Edit,Bash - Incremental investigation strategy : Grep entry points → Read → Grep usages → repeat
- Read + Write fallback quand
Editéchoue (non-unique match) - Scratchpad files pour préserver les key findings entre les étapes
- Subagent delegation pour protéger le context window du main agent
Pièges typiques dans les questions
Confondre
Glob et Grep : Glob = trouver des fichiers par nom/pattern. Grep = chercher du contenu dans les fichiers. Ce sont des usages différents.
"Read all files at once" → saturation du context window. Utiliser une stratégie d'incremental investigation.
Scénario 5 : Claude Code for Continuous Integration
Description : Intégrer Claude Code dans un pipeline CI/CD pour automated code reviews, test generation, et PR feedback. Minimiser les false positives.
Domaines principalement testés : D3 (CI/CD config), D4 (explicit criteria, few-shot, Batch API, multi-pass review)
Concepts clés à maîtriser
-pflag pour non-interactive mode (SEUL moyen correct en CI)--output-format json+--json-schemapour structured output- Session context isolation : instance indépendante pour review (pas la même qui a généré le code)
- Prior review results pour éviter les duplicate comments
- Explicit criteria vs vague instructions pour code review
- Impact des false positives sur la developer trust
- Message Batches API : 50% savings, up to 24h, pas de multi-turn tool calling
- Synchronous pour blocking checks, batch pour overnight reports
- Multi-pass review : per-file pass + intégration pass
Pièges typiques dans les questions
Oublier le
-p flag → le job CI hangs indefinitely en attendant une interaction utilisateur.
"Move blocking pre-merge checks to Batch API" → latence inacceptable (jusqu'à 24h). Le Batch API est pour les workloads non-blocking uniquement.
"Batch API supports multi-turn tool calling" → FAUX. Le Batch API ne supporte pas le multi-turn tool calling.
"Larger context window fixes attention quality" → FAUX. Plus de contexte ne résout pas les problèmes d'attention. Utiliser multi-pass review à la place.
Scénario 6 : Structured Data Extraction
Description : Extraire de l'information de documents non structurés, valider avec JSON schémas, maintenir une haute précision. Gérer les edge cases correctement.
Domaines principalement testés : D4 (JSON schémas, validation, retry, few-shot, self-correction), D5 (confidence calibration)
Concepts clés à maîtriser
tool_use+ JSON Schema : garantit la syntactic validity, PAS la semantic correctness- Schema design :
requiredvsoptional,nullablefields,enum+"other",enum+"unclear" - Retry-with-feedback : original doc + incorrect extraction + specific error → relance
- Self-correction :
stated_totalvscalculated_total→conflict_detected - Format normalization rules : dates en ISO 8601, currency = amount + code
- Pydantic pour validation structurelle ET sémantique
- Stratified random sampling : 97% global peut masquer 40% d'erreurs sur certaines catégories
- Field-level confidence scores
- Few-shot pour informal measurements et formats variés
Pièges typiques dans les questions
"Required field for info that may be absent" → le modèle va fabriquer une valeur. Utiliser
nullable à la place.
"Retry when info is absent from source" → le retry ne peut pas créer de l'information qui n'existe pas dans le document source. C'est inutile.
"97% accuracy means the system works" → vérifier par document type ET par field. Le score global peut masquer des faiblesses graves (stratified sampling).
3. Tableau croisé Scénario x Domaine
Ce tableau montre quels domaines sont principalement testés par chaque scénario. Utile pour cibler ta révision si tu veux renforcer un domaine spécifique.
| Scénario | D0 API Basics | D1 Agentic | D2 Tools | D3 Claude Code | D4 Prompt Eng. | D5 Context & Reliability |
|---|---|---|---|---|---|---|
| S1 Customer Support | ✓ agentic loop, hooks, enforcement | ✓ tool descriptions, tool_choice | ✓ escalation, structured handoff | |||
| S2 Code Generation | ✓ hiérarchie CLAUDE.md, skills, commands | ✓ context management (Explore subagent) | ||||
| S3 Multi-Agent Research | ✓ hub-and-spoke, Task tool, parallel spawning | ✓ scoped tool access, erreurs structurées | ✓ error propagation, provenance, context | |||
| S4 Developer Productivity | ✓ subagent delegation, task decomposition | ✓ built-in tools, MCP | ✓ Claude Code config | |||
| S5 CI/CD Integration | ✓ CI/CD config, -p flag | ✓ explicit criteria, few-shot, Batch API | ||||
| S6 Data Extraction | ✓ JSON schémas, retry, few-shot, self-correction | ✓ confidence calibration, sampling |
Lecture du tableau :
- D1 (Agentic) : surtout testé via S1, S3 et S4
- D2 (Tools) : surtout testé via S1, S3 et S4
- D3 (Claude Code) : surtout testé via S2, S4 et S5
- D4 (Prompt Engineering) : surtout testé via S5 et S6
- D5 (Quality) : surtout testé via S1, S2, S3 et S6
Stratégie de révision : Si tu es faible sur un domaine, concentre-toi sur les scénarios correspondants. Par exemple, pour renforcer D1 (Agentic), travaille en priorité S1, S3 et S4.
4. Hors-scope — ne révise pas ça
Ce qui N'EST PAS testé par l'examen CCA-F : la liste ci-dessous reprend l'intégralité des Out-of-Scope Topics de l'appendice du guide (deux entrées voisines y sont regroupées en une puce). Les ignorer permet de concentrer ta révision sur ce qui compte vraiment.
- Fine-tuning / entraînement de modèles : l'examen se concentre sur l'utilisation d'API et d'agents, pas sur comment entraîner Claude.
- Architecture interne de Claude, processus d'entraînement, poids du modèle : rien de ce qui se passe sous le capot n'est testé.
- Constitutional AI, RLHF, méthodes de safety training : les méthodologies d'alignement sont explicitement hors périmètre.
- Détails d'implémentation d'un langage ou d'un framework : au-delà de ce qu'exige la configuration d'un tool et de son schéma, aucune question ne porte sur la syntaxe d'un langage particulier.
- Embeddings & vector databases (RAG détaillé) : le contexte et la retrieval sont couverts, mais pas l'architecture vectorielle profonde ni les stores spécialisés.
- Computer use : interactions browser ou contrôle de desktop ne sont pas des sujets d'examen.
- Vision / image processing : pas de vision multimodale dans les domaines évalués.
- Streaming API : les appels API standard et Batch API oui, mais pas le streaming détaillé.
- Hébergement de serveurs MCP / AWS Bedrock / GCP Vertex : les MCP tools locaux et Claude API sont couverts, mais pas le déploiement d'infrastructures ou de services cloud concurrents.
- Auth, billing, gestion de compte : les aspects opérationnels API (clés, authentification basique) sont hors périmètre.
- OAuth, rotation de clés d'API, protocoles d'authentification : entrée distincte du guide — un distracteur qui propose un flow OAuth est hors sujet par construction.
- Rate limiting, quotas, calcul de pricing : la facturation détaillée et les limitations d'usage ne sont pas testées.
- Tokenization & token counting (détails internes) : savoir que les tokens existent oui, mais pas les algos de tokenization ou les outils de counting avancés.
- Détails internes du prompt caching (au-delà de savoir qu'il existe) : le context reuse est couvert, mais pas les mécanismes internes ou l'optimisation fine-grained.
- Benchmarking / comparaison de modèles : focus sur Claude, pas sur comparatifs avec d'autres LLM.
Principe : Si tu te trouves à réviser un de ces sujets et que tu n'es pas sûr qu'il soit couvert, relis les 6 scénarios. S'il n'apparaît pas, c'est probablement hors périmètre de l'examen.
5. Les patterns de distracteurs récurrents
À travers les 6 scénarios, certains types de mauvaises réponses reviennent systématiquement. Reconnaître ces patterns permet d'éliminer rapidement les distracteurs.
Ces patterns sont détaillés dans la Stratégie d'examen, section 3 — sept entrées avec, pour chacune, la raison pour laquelle elle est presque toujours fausse et le cas rare où elle ne l'est pas. Une seule liste, pour ne pas en réviser deux versions.
Règle d'or : Quand une option de réponse propose d'ajouter de la complexité (classifier, agent, couche supplémentaire), demande-toi d'abord si un correctif simple (meilleure description, critère explicite, hook) ne suffirait pas. L'examen privilégie la solution la plus directe et la plus fiable.
Méthode d'élimination : Sur chaque question, commence par éliminer les distracteurs connus (cette liste couvre la majorité). Il reste généralement 2 options crédibles. Relis alors l'énoncé pour identifier le vrai problème (financier ? attention ? routing ?) et choisis en conséquence.