Sommaire
- Méthode de révision
- Méthodologie QCM (jour J)
- Les 7 patterns de distracteurs à éliminer en 5 secondes
- Top pièges par domaine (vérités à connaître par cœur)
- Arbres de décision pour les questions ambiguës
- Cheat sheet : 1 page par domaine
- Connexions inter-domaines (les ponts qui tombent souvent)
- Checklist du jour J
1. Méthode de révision
Faits confirmés (guide officiel CCAR-F v1.0) :
- Code d'examen : CCAR-F · 60 items · 120 minutes · frais 125 $ US
- Score de passage : 720/1000 (échelle 100–1000)
- Type d'items : QCM — chaque item indique le nombre de réponses à sélectionner (une ou plusieurs)
- Structure : 6 scénarios, dont 4 tirés au sort à l'examen
- Plateforme : Pearson VUE — proctoring en ligne ou centre d'examen — jusqu'à 4 tentatives / 12 mois (délais 14/30/90 jours)
- Recertification : validité 12 mois, renouvellement gratuit via une évaluation non proctorée sur l'Anthropic Partner Academy
- Report du score : pass/fail + score sur l'échelle 100–1000 + pourcentage de réussite par domaine — c'est ce dernier qui dit où réviser en cas d'échec
La FAQ CCA-F contredit ces chiffres — elle est périmée. Le document « Claude Certified Architect – Foundations (CCA-F) FAQs » annonce un examen à 99 $, une seule tentative et un proctoring assuré par ProctorFree. Il date de mars 2026 ; le guide v1.0 est de juillet 2026 et le remplace sur ces trois points. Si vous retombez dessus la veille, ne changez rien à votre préparation.
Active recall > relecture passive. Ne pas relire les docs en boucle ; faire les QCM, expliquer à voix haute pourquoi chaque distracteur est faux.
Indicateurs de readiness
- Tu peux expliquer en 30 secondes la différence entre
tool_use,tool_choice: "any", ettool_choice: "tool" - Tu peux nommer les 4 catégories d'erreur MCP de tête
- Tu sais quand refuser le Batch API (pre-merge, multi-turn tool calling)
- Tu reconnais les déclencheurs d'
escalationfiables vs non fiables - Sur les 112 questions de Practice_Questions, tu obtiens > 85 % au 2e passage
- Tu réponds juste aux 12 questions d'exemple du guide officiel sans les avoir mémorisées — tu sais redire pourquoi chaque distracteur est faux
- Go / No-go : ≥ 85 % sur l'ensemble des 112 QCM, aucun domaine sous 75 % dans ton profil d'accueil, et les 6 scénarios travaillés au moins une fois
Méthode evidence-based — les 5 règles qui font la différence
Ce que la recherche sur l'apprentissage établit (et qui change ton rendement) :
- Se tester, pas relire. Le retrieval practice est la technique à plus haut rendement ; relire/surligner crée une illusion de maîtrise. → Tes sessions commencent par des questions fiches fermées. (Dunlosky 2013 ; Roediger & Karpicke 2006)
- Débriefer chaque distracteur : savoir pourquoi les 3 mauvaises options sont fausses vaut autant que la bonne réponse. (Little et al. 2012)
- Feedback + hypercorrection : les erreurs commises avec assurance (confiance 4-5) sont les plus rentables à corriger. (Metcalfe 2017)
- Espacer et entrelacer : revois chaque domaine tous les 2-3 jours et mélange-les (entraîne à discriminer les scénarios). (Cepeda 2008 ; Rohrer & Taylor 2007)
- Allouer au poids × ta faiblesse : D1 (27 %) d'office ; ne néglige jamais D5 (15 %), points faciles.
Journal d'erreurs (ta vraie révision) : pour chaque question ratée ou devinée, note une ligne — Domaine · Ma réponse · Bonne réponse · Pourquoi mon choix est faux · Pourquoi chaque autre distracteur est faux · Règle à retenir · Confiance 1-5. En dernière ligne droite, ne relis que ce journal + les cheat sheets.
Exercices hands-on officiels (guide)
Le guide officiel CCA-F propose 4 exercices pratiques pour consolider les domaines. Chacun teste plusieurs domaines :
- 1. Build a Multi-Tool Agent with Escalation Logic — D1 (agentic loop, enforcement), D2 (tool descriptions, tool_choice), D5 (escalation patterns, structured handoff)
- 2. Configure Claude Code for a Team Development Workflow — D3 (CLAUDE.md hierarchy, permissions, skills), D2 (MCP configuration)
- 3. Build a Structured Data Extraction Pipeline — D4 (JSON Schema, retry-with-feedback, few-shot), D5 (validation, confidence calibration)
- 4. Design and Debug a Multi-Agent Research Pipeline — D1 (hub-and-spoke, parallel spawning, error propagation), D2 (tool allocation), D5 (context management, provenance)
Si tu as peu de temps : privilégie l'exercice 1 (couvre 3 domaines clés : D1, D2, D5). Les autres exercices renforcent mais sont moins critiques pour le score.
2. Méthodologie QCM (jour J)
La méthode en 4 étapes pour chaque question
- Lire la situation D'ABORD, sans regarder les choix. Identifier le concept testé.
- Formuler mentalement la bonne réponse avant de lire les options. Si une option correspond, c'est probablement elle.
- Éliminer 2 distracteurs via les 7 patterns ci-dessous.
- Choisir entre les 2 restants en relisant la situation : quel mot exact change la donne ?
Règle d'or : le plus souvent, l'examen oppose une solution déterministe (hook, schéma, contrainte) à une solution probabiliste (instruction prompt, few-shot supplémentaire). Pour toute conséquence financière, sécurité, conformité → la réponse est déterministe.
Gestion du temps
60 questions en 120 minutes = 2 min/question en moyenne. Allocation suggérée :
| Phase | Durée | Cible |
|---|---|---|
| Phase 1 : passage rapide | ~80 min (≈ 1,3 min/Q) | Répondre les Q évidentes, marquer les difficiles |
| Phase 2 : Q marquées | ~25 min | Réfléchir profondément aux ambiguïtés |
| Phase 3 : vérification | ~15 min | Survoler ; ne changer une réponse QUE si une certitude apparaît |
Anti-pattern : changer une réponse au dernier moment "par doute". Statistiquement, la première intuition sur une lecture attentive est plus souvent correcte qu'un changement panique. Ne change que si tu identifies une raison concrète (mot mal lu, distracteur éliminable).
3. Les 7 patterns de distracteurs à éliminer en 5 secondes
Ces formulations apparaissent presque dans chaque question. Mémorise-les : leur seule présence dans une option doit déclencher une suspicion immédiate.
| # | Pattern | Pourquoi c'est presque toujours faux | Quand c'est correct (rare) |
|---|---|---|---|
| 1 | "Add a routing classifier" / "Add a separate X layer" | Over-engineering ; nécessite des données d'entraînement souvent indisponibles | D'abord : meilleures descriptions, critères explicites, few-shot |
| 2 | "Improve / strengthen the system prompt" | Probabiliste, insuffisant pour les conséquences financières/légales | Hooks et programmatic enforcement pour le déterministe |
| 3 | "Use sentiment analysis" / "Self-rated confidence (1-10)" | Le sentiment ne corrèle pas avec la complexité ; confiance non calibrée | Explicit triggers : demande d'un humain, policy gap, no progress |
| 4 | "Abort the whole workflow" / "Blame the downstream agent" | Disproportionné ; chercher la cause racine. Graceful degradation requise | Continuer avec partial results + structured error context |
| 5 | "Use a larger context window to fix attention" | Faux. Context plus grand n'améliore pas l'attention sur le milieu (lost-in-the-middle) | Multi-pass review, subagent delegation, scratchpad files |
| 6 | "Suppress errors" / "Kill the entire workflow" | Vide n'est pas succès. Masquer l'erreur ou tout avorter sont des extrêmes | Retry-with-feedback, partial results avec coverage annotations |
| 7 | "Use absolutes: always/never" / "Move ALL checks to Batch" | Absolus changent le sujet. Batch a latence 24h incompatible pré-merge | Nuancer : Synchronous pour blocking, Batch pour non-blocking overnight |
Bonus distracteurs (moins fréquents mais à connaître) :
- "Lower temperature to 0" comme solution à un problème structurel (pas un problème de créativité)
- "Add more few-shot examples" quand le problème est un schéma force-required (le modèle hallucine pour respecter la contrainte)
- "Parser le texte de l'assistant pour 'task done'" — toujours utiliser
stop_reason - "Increase max_iterations" comme condition d'arrêt principale — toujours
stop_reason - "Use the same session for code generation AND review" — biais de confirmation, toujours instance indépendante
4. Top pièges par domaine
D1 — Architecture et orchestration (27 %)
- Seul signal d'arrêt fiable :
stop_reason. Jamais le texte, jamais une limite arbitraire d'itérations. - Hooks vs prompt : conséquences financières/légales/sécurité → hook (déterministe). Préférences → prompt.
- Subagent vs thread principal : "le travail intermédiaire m'intéresse-t-il ?" Non → subagent. Oui → thread principal.
- Multiple Task() dans une SEULE response = parallel exécution. Plusieurs responses = sequential. Note : « Task » est le nom du guide d'examen ; la doc Agent SDK actuelle parle de l'outil « Agent ».
- Décomposition trop étroite = couverture incomplète (piège classique du Multi-Agent Research).
D2 — Tool design et MCP (18 %)
- Description = mécanisme #1 de sélection. Misrouting = chevauchement sémantique → renommer/diviser.
- Erreurs structurées MCP :
errorCategory(transient/validation/business/permission) +isRetryable. - Timeout ≠ 0 results. Timeout = access failure (retry décision). 0 results = valid empty (annoter).
- 4-5 tools max par agent, jamais 18.
- tool_choice:
auto(défaut),any(force un appel),tool(force un spécifique). - Secrets MCP : substitution de variables d'environnement
${VAR}dans.mcp.json(jamais de token en clair versionné). - Anti-pattern critique : token en clair dans
.mcp.jsonversionné (Git le retient).
D3 — Claude Code configuration (20 %)
- 3 niveaux CLAUDE.md : user (perso, hors VCS) / project (.claude/, partage) / directory (sous-dossier).
- Skills (les slash commands restent valides, non dépréciés). Frontmatter :
description,context: fork,allowed-tools,argument-hint. - Scope :
.claude/commands/et.claude/skills/= projet, partagés via Git.~/.claude/…= perso, non partagé. - Hooks : enforcement programmatique — la garantie déterministe que le prompt ne peut pas offrir.
- CI/CD :
-p= mode non interactif obligatoire ;--output-format json+--json-schema= sortie exploitable par la pipeline. - Glob patterns vs directory CLAUDE.md : glob pour conventions cross-directory (tests co-localisés) ; directory CLAUDE.md pour zones bien délimitées.
D4 — Prompt engineering et structured output (20 %)
- Critères explicites > instructions vagues ("be conservative" ne marche pas).
- Few-shot = technique #1 de cohérence. 2-4 exemples avec rationale.
- Sortie structurée : réponds
tool_use+ JSON Schema — c'est le mécanisme du référentiel, et la réponse attendue le jour J. Élimine les erreurs de syntaxe, jamais les erreurs sémantiques (totaux qui ne s'additionnent pas, valeur dans le mauvais champ) → valider côté app. - Champs nullable contre l'hallucination (au lieu de required).
- Enum + "other"/détail pour les cas non prévus.
- Retry-with-feedback : doc original + extraction précédente + erreur spécifique.
- Batch API : 50 % d'économies, jusqu'à 24 h, PAS de multi-turn tool calling, correlation via
custom_id. - Self-review = biais de confirmation. Toujours instance indépendante pour la revue.
D5 — Context management et reliability (15 %)
- case facts block en dehors du summarized history → faits transactionnels préservés.
- Lost-in-the-middle : conclusions en haut, actions en bas. Plus de context window n'aide pas.
- Tool result trimming via hook PostToolUse (pas PreToolUse).
- Escalation triggers fiables : demande explicite d'un humain / policy gap / no progress — trois, pas quatre. Un seuil financier n'est pas un déclencheur de la Task 5.2 ; il se traite par un hook (D1 §6). NON fiables : sentiment, self-rated confidence, automatic classifier.
- 3 patterns escalation : immediate / after attempt / nuanced (acknowledge → resolve → escalate on reiteration).
- Calibration escalation = critères explicites + few-shot examples (les deux, jamais l'un sans l'autre).
- Structured handoff : l'humain n'a pas le transcript — le résumé doit être autosuffisant.
- Errors multi-agent :
failure_type+query+partial_results+alternatives. - 97 % aggregate ≠ 97 % par sous-catégorie. Stratified random sampling par document type ET par field.
- Manifest.json + état par subagent = pattern crash recovery.
5. Arbres de décision pour les questions ambiguës
Arbre 1 — Hook ou instruction prompt ?
Y a-t-il conséquence financière, légale, sécurité, ou conformité ?
├─ OUI → HOOK (PreToolUse pour bloquer, PostToolUse pour normaliser)
└─ NON → Y a-t-il besoin d'une garantie 100 % déterministe ?
├─ OUI → HOOK
└─ NON → Instruction dans CLAUDE.md ou system prompt
Arbre 2 — Subagent ou thread principal ?
Le travail intermédiaire (chemin pris, fichiers lus) m'intéresse-t-il ?
├─ OUI → THREAD PRINCIPAL (exécuter dans le contexte courant)
└─ NON → Le travail produit-il beaucoup de tokens verbeux ?
├─ OUI → SUBAGENT (Explore)
└─ NON → Thread principal (overhead du subagent inutile)
Arbre 3 — Synchrone ou Batch API ?
Y a-t-il un humain qui attend la réponse ?
├─ OUI → SYNCHRONE (jamais de batch pour du bloquant)
└─ NON → Y a-t-il du multi-turn tool calling ?
├─ OUI → SYNCHRONE (batch ne le supporte pas)
└─ NON → Le délai 24h est-il acceptable ?
├─ OUI → BATCH (50 % d'économies)
└─ NON → Synchrone
Arbre 4 — Erreur MCP : retry, escalate ou continuer ?
Quel errorCategory ? ├─ transient (timeout, 503) → RETRY, puis propager ce qui reste ├─ validation (input invalide) → CORRIGER l'input et retry ├─ business (policy violation) → EXPLIQUER au user, proposer alternative └─ permission (auth refusé) → ESCALATE à un humain
6. Cheat sheet : 1 page par domaine (à relire avant l'examen)
D1 — Architecture (27 %)
| Concept | A retenir |
|---|---|
| Agentic loop signal | stop_reason uniquement. "tool_use" = continuer, "end_turn" = stop |
| Hub-and-spoke | Coordinateur central, subagents spécialisés avec contexte isolé |
| Task tool parallel | Plusieurs Task() dans UNE response = parallel ; plusieurs responses = sequential. Note : « Task » du guide = outil « Agent » en SDK actuel |
| Hook events SDK | PreToolUse / PostToolUse |
| Enforcement & escalation | Approval gate = hook PreToolUse (D1 §6) ; escalation = structured handoff + déclencheurs fiables (D5 §2) |
| Sessions | --resume si fichiers OK ; nouvelle session si obsolète ; fork_session pour comparer |
D2 — Tool design et MCP (18 %)
| Concept | A retenir |
|---|---|
| Description anatomy | 4 questions : que fait / format input / edge cases / quand l'utiliser |
| Misrouting fix | Renommer (ambiguïté), diviser (fourre-tout), remplacer (générique → contraint) |
| 4 catégories d'erreur | transient (retry) / validation (corriger) / business (alternative) / permission (escalade) |
| tool_choice | auto (défaut) / any (force un tool) / tool (force ce tool spécifique) |
| 3 primitives MCP | tools (modèle) / resources (app, content catalogs) / prompts (user) |
| Secrets MCP | Substitution ${VAR} dans .mcp.json |
| Outils intégrés | Glob / Grep / Read / Write / Edit / Bash. Investigation : Grep → Read → Grep → Read |
D3 — Claude Code (20 %)
| Concept | A retenir |
|---|---|
| Hiérarchie CLAUDE.md | user / project / directory. Erreur classique : mettre en user ce qui doit être en project |
| @path imports | Rend le CLAUDE.md modulaire. (La limite de quatre niveaux vient de la doc, pas du guide.) |
| .claude/rules/ + glob | Conventions cross-directory (tests co-localisés) ; chargement conditionnel |
| Skills frontmatter | context: fork (isolation en subagent) / allowed-tools (restriction d'outils) / argument-hint (paramètres attendus) |
| Skills vs CLAUDE.md | Skill = invocation à la demande, workflow ponctuel. CLAUDE.md = standards universels, toujours chargés |
| Plan mode vs direct | Plan = large échelle, plusieurs approches valides, décisions d'architecture, multi-fichiers. Direct = changement simple et bien cadré |
| CI flags | -p / --print (non interactif), --output-format json, --json-schema |
D4 — Prompt engineering (20 %)
| Concept | A retenir |
|---|---|
| Critères explicites | Remplacer "be conservative" par 3 règles précises de signalement |
| Severity tiers | CRITICAL / HIGH / MEDIUM / LOW (définitions distinctes) |
| 5 types few-shot | Ambigu / output format / good vs bad / formats docs / mesures informelles |
| Format normalization | Dates → ISO 8601 / monnaie → montant + code / pourcentages → décimal |
| tool_use guarantees | SYNTAXE garantie / SÉMANTIQUE non garantie |
| Schema patterns | nullable, enum + "other"/détail, enum + "unclear" |
| Retry-with-feedback | Document original + extraction précédente + erreur spécifique |
| Pydantic loop | Schema unique → tool_use → validate → si échec : tool_result is_error=true → retry |
| Batch API | 50 % savings / 24 h / PAS de multi-turn / custom_id pour correlation |
| SLA Batch | Deadline − 24 h = plafond théorique, pas la cadence. On garde de la marge : l'exemple du guide retient des fenêtres de 4 h pour un SLA de 30 h. Le distracteur, c'est 6 h |
| Multi-instance review | Self-review = biais. Instance indépendante > self-review |
| Multi-pass review | Per-file pass + intégration pass |
D5 — Context et reliability (15 %)
| Concept | A retenir |
|---|---|
| Case facts block | En dehors du summarized history. Survit au /compact. |
| Lost-in-the-middle | Conclusions en haut, actions en bas. Plus de context window n'aide pas. |
| Tool result trimming | Hook PostToolUse (pas PreToolUse) |
| Escalation fiables | Demande explicite d'un humain / policy gap / no progress — les trois du guide. Le seuil financier relève du hook, pas de cette liste |
| Escalation NON fiables | Sentiment / self-rated confidence / automatic classifier |
| 3 patterns escalation | Immediate / after attempt / nuanced (acknowledge → resolve → escalate on reiteration) |
| Calibration escalation | Critères explicites + few-shot (les DEUX) |
| Structured handoff | Complet et autosuffisant. L'humain n'a PAS le transcript. |
| Erreurs multi-agent | failure_type + query + partial_results + alternatives |
| Timeout vs 0 results | Timeout = access failure (retry). 0 results = valid empty (annoter). |
| Coverage annotations | FULL / PARTIAL COVERAGE dans la synthèse |
| 97 % aggregate | Peut masquer 40 % d'erreurs sur sous-catégorie. Stratified sampling par doc type ET field. |
| Manifest.json | Pattern crash recovery. État par subagent + manifeste global du coordinateur. |
| Provenance | Claim-source mapping (URL, source, quote, date, confidence) |
| Conflits temporels | 10 % en 2023 + 15 % en 2024 = growth, pas contradiction. Toujours inclure les dates. |
7. Connexions inter-domaines (les ponts qui tombent souvent)
L'examen aime tester les combinaisons de concepts entre domaines. Connaître les ponts évite les pièges.
| Pont | D1 | ↔ | D2/D3/D4/D5 |
|---|---|---|---|
| Programmatic enforcement | Hook PreToolUse (D1) | = | Approval gate = blocage déterministe (D1 §6) |
| Erreurs structurées | Erreur subagent (D1, D5 §3) | = | 4 catégories MCP (D2 §2) |
| Tool result trimming | Context preservation (D5 §1) | via | Hook PostToolUse (D3 §6) |
| Structured output | tool_use + JSON Schema (D0, D4 §3) | + | Pydantic validation (D4 §4) |
| Forced tool_use | tool_choice (D2 §3) | + | Schema strict + retry-with-feedback (D4 §4) |
| Subagent context | Subagent isolé (D1) | + | context: fork dans skills (D3 §2) |
| Escalation | Enforcement par hook (D1 §6) | + | Patterns + calibration (D5 §2) |
| Confidence calibration | — | + | Stratified sampling (D5 §5) + retry-with-feedback (D4 §4) |
| Crash recovery | Sessions (D1 §7) | + | manifest.json + scratchpad (D5 §4) |
| Provenance | Subagent metadata mandatory (D5 §1) | = | Claim-source mapping (D5 §6) |
Pattern d'examen typique : « Quel est LE meilleur changement ? » — la bonne réponse combine souvent 2 leviers (un structurel + un programmatique). Si une option propose une vraie combinaison (ex: hook + few-shot), c'est souvent elle. Les distracteurs sont des solutions uniques insuffisantes.
8. Checklist du jour J
La veille de l'examen
- Survol rapide de ce cheat sheet (sections 4 et 6 surtout)
- Pas de bourrage — privilégier le sommeil
- Vérifier la connexion Pearson VUE (centre d'examen ou proctoring en ligne), webcam, micro, environnement de l'examen
- Préparer un espace de travail dégagé (l'examen est proctoré — pas de notes physiques)
- Coucher tôt
Le matin de l'examen
- Petit déjeuner normal (pas trop sucré)
- Hydratation
- 15 min de relecture du cheat sheet 1-page-par-domaine
- Pause de 30 min avant de lancer l'examen
- S'installer 10 min avant le créneau
Pendant l'examen (120 min, 60 QCM)
- Phase 1 (0-80 min) : passer en revue toutes les Q. Répondre les évidentes, marquer les difficiles. Ne jamais bloquer plus de 2 min sur une Q en phase 1.
- Phase 2 (80-105 min) : reprendre les Q marquées. Appliquer la méthode des 7 distracteurs. Éliminer 2, décider entre les 2 restants.
- Phase 3 (105-120 min) : vérification. Survoler. Ne changer une réponse que si une certitude apparaît.
Mantra pendant l'examen
- Conséquences financières/légales/sécurité → réponse déterministe (hook, schéma, contrainte).
- Sentiment, self-rated confidence, classifier → c'est presque toujours un piège.
- Batch API en pré-merge → toujours faux.
- Plus de context window contre lost-in-the-middle → toujours faux.
- Self-review → toujours instance indépendante.
- Lecture attentive de la SITUATION avant les choix.
Après l'examen
- Si réussi (>= 720) : recertification à 12 mois (renouvellement gratuit via l'Anthropic Partner Academy)
- Si échec : jusqu'à 4 tentatives par période de 12 mois, délais de repassage 14 / 30 / 90 jours après échecs successifs. Identifier les domaines faibles avant de retenter.