Exam guide CCA-F décrypté : scénarios et objectifs

Pour la certification Claude Certified Architect – Foundations (code officiel CCAR-F, abrégé « CCA-F » par la communauté), le point de départ est l'exam guide publié par Anthropic. Cette page en propose une lecture commentée en français, pour en tirer un programme de révision concret.

Ce qu'est ce document, et pourquoi le lire en entier

L'exam guide est la version 1.0, en vigueur depuis juillet 2026 (après deux brouillons en février et juin 2026). Anthropic le présente comme la référence qui fait foi pour les candidats et précise qu'il peut évoluer sans préavis : vérifiez donc le numéro de version avant de réviser.

Le document répond à trois questions que tout candidat se pose :

• Qui est visé ? Un architecte de solutions qui conçoit des applications de production avec Claude, avec environ six mois de pratique de l'API, de l'Agent SDK, de Claude Code et de MCP (repère, pas prérequis).
• Qu'est-ce qui est évalué ? Le jugement plus que la mémoire : choisir l'option qui règle la cause réelle avec l'effort le plus proportionné.
• Comment se préparer ? Le guide propose des recommandations, quatre exercices pratiques et douze questions d'exemple commentées.

Le format en un coup d'œil

L'évaluation est critériée : vous êtes comparé à un standard fixe, pas aux autres candidats. Le rapport affiche un pourcentage par domaine, mais seul le score global décide du résultat. Pour les conditions d'inscription et de report, voir notre guide de l'examen.

Les six scénarios de l'examen

Chaque bloc de questions s'ouvre sur un contexte de production réaliste. Le tirage étant aléatoire, préparez les six.

Scénario 1 — Agent de résolution pour le support client

Vous construisez avec l'Agent SDK un agent qui traite des demandes floues (retours, litiges de facturation, problèmes de compte). Il accède au système d'information via des outils MCP maison — recherche de client, de commande, remboursement, transfert vers un humain — et doit résoudre une large majorité des demandes au premier contact tout en sachant passer la main.

Domaines mobilisés : 1 (architecture agentique), 2 (outils et MCP), 5 (contexte et fiabilité).

Ce qu'il faut savoir faire :

• imposer par le code (et non par le prompt) qu'une vérification d'identité précède toute opération financière ;
• rédiger des descriptions d'outils qui évitent de confondre deux outils voisins ;
• définir des critères d'escalade explicites, illustrés par des exemples ;
• préparer une note de passation structurée pour l'agent humain qui n'a pas l'historique.

Leçon la plus proche : les hooks.

Scénario 2 — Génération de code avec Claude Code

Une équipe utilise Claude Code au quotidien pour générer, refactorer, déboguer et documenter. Il s'agit de l'intégrer proprement au flux de travail : commandes personnalisées, fichiers CLAUDE.md bien organisés, et bon usage du plan mode.

Domaines mobilisés : 3 (Claude Code), 5 (contexte et fiabilité).

Ce qu'il faut savoir faire :

• placer une instruction au bon niveau de la hiérarchie (utilisateur, projet, sous-dossier) ;
• partager une commande avec toute l'équipe via le dépôt ;
• choisir entre plan mode et exécution directe selon l'ampleur du changement ;
• appliquer des conventions à des fichiers dispersés grâce aux règles par chemin.

Leçon la plus proche : le fichier CLAUDE.md.

Scénario 3 — Système de recherche multi-agents

Un agent coordinateur répartit le travail entre des sous-agents spécialisés : recherche web, analyse de documents, synthèse, rédaction du rapport final. Le système doit produire des rapports complets et sourcés.

Domaines mobilisés : 1, 2 et 5.

Ce qu'il faut savoir faire :

• découper un sujet sans en oublier des pans entiers ;
• transmettre explicitement à chaque sous-agent le contexte dont il a besoin ;
• faire remonter les échecs sous une forme exploitable par le coordinateur ;
• conserver le lien entre chaque affirmation et sa source jusqu'au rapport.

Leçon la plus proche : les sous-agents.

Scénario 4 — Productivité des développeurs

Un agent construit avec l'Agent SDK aide des ingénieurs à explorer une base de code inconnue, comprendre du code hérité, produire du code répétitif et automatiser des tâches. Il s'appuie sur les outils intégrés (lecture, écriture, shell, recherche) et sur des serveurs MCP.

Domaines mobilisés : 2, 3 et 1.

Ce qu'il faut savoir faire :

• choisir entre Grep (recherche dans le contenu) et Glob (recherche de chemins) ;
• explorer progressivement plutôt que tout lire d'emblée ;
• savoir quoi faire quand une édition ciblée échoue faute d'ancre unique ;
• décider entre un serveur MCP communautaire et un développement maison.

Leçon la plus proche : configurer un serveur MCP.

Scénario 5 — Claude Code en intégration continue

Claude Code tourne dans la chaîne CI/CD : revue automatique des pull requests, génération de tests, commentaires. L'enjeu est d'obtenir des retours utiles en limitant les faux positifs.

Domaines mobilisés : 3 (Claude Code), 4 (prompt et sortie structurée).

Ce qu'il faut savoir faire :

• lancer Claude Code en mode non interactif pour qu'un job ne reste pas bloqué ;
• obtenir une sortie JSON conforme à un schéma, publiable en commentaires ;
• écrire des critères de revue précis plutôt que des consignes vagues ;
• faire relire le code par une instance indépendante de celle qui l'a écrit.

Leçon la plus proche : automatisation CI/CD.

Scénario 6 — Extraction de données structurées

Le système lit des documents non structurés, en extrait des informations, valide le résultat contre un schéma JSON et alimente d'autres applications. Il doit rester précis et gérer proprement les cas limites.

Domaines mobilisés : 4 et 5.

Ce qu'il faut savoir faire :

• concevoir un schéma avec champs facultatifs pour ne pas pousser le modèle à inventer ;
• mettre en place une boucle validation-relance qui renvoie l'erreur précise ;
• choisir entre traitement synchrone et traitement par lots ;
• router vers une revue humaine les extractions les moins fiables.

Leçon la plus proche : le SDK Claude Code.

Les cinq domaines et leurs objectifs

Les pondérations ci-dessous sont celles du guide officiel ; elles indiquent la part approximative des questions notées issues de chaque domaine. Notre page les 5 domaines les développe avec des exemples.

Domaine 1 — Architecture agentique et orchestration (27 %)

• 1.1 Boucle agentique : poursuivre tant que la réponse s'arrête sur une demande d'outil (tool_use), s'arrêter sur end_turn, et réinjecter chaque résultat d'outil dans l'historique.
• 1.2 Coordinateur et sous-agents : architecture en étoile où tout passe par le coordinateur, qui choisit dynamiquement quels sous-agents solliciter.
• 1.3 Lancement des sous-agents : outil de délégation autorisé chez le coordinateur, contexte transmis explicitement dans le prompt, appels parallèles émis dans une même réponse.
• 1.4 Workflows contraints : barrières programmatiques pour les étapes obligatoires, notes de passation structurées lors d'une escalade.
• 1.5 Hooks : normaliser des formats hétérogènes après un appel d'outil, intercepter un appel contraire à la politique pour le rediriger.
• 1.6 Décomposition : chaînage fixe pour les revues prévisibles, décomposition adaptative pour les enquêtes ouvertes.
• 1.7 Sessions : reprendre une session nommée, la dupliquer (fork) pour comparer deux pistes, ou repartir d'un résumé si les données sont périmées.

Pièges mis en avant : arrêter la boucle en analysant le texte produit ; faire d'un plafond d'itérations arbitraire le mécanisme d'arrêt principal ; confier une règle métier critique à une simple consigne de prompt ; un découpage trop étroit qui oublie des pans du sujet ; supposer qu'un sous-agent hérite du contexte du coordinateur.

Domaine 2 — Conception d'outils et intégration MCP (18 %)

• 2.1 Descriptions d'outils : c'est d'abord sur elles que le modèle choisit ; préciser entrées, exemples, limites, et découper un outil fourre-tout.
• 2.2 Erreurs structurées : signaler l'échec (drapeau isError), en donner la catégorie (transitoire, validation, règle métier, permission) et dire si une relance a un sens.
• 2.3 Répartition des outils : peu d'outils par agent, limités à son rôle ; maîtriser tool_choice en mode automatique, obligatoire ou forcé.
• 2.4 MCP dans Claude Code : configuration partagée au niveau projet (.mcp.json) ou personnelle au niveau utilisateur, secrets passés par variables d'environnement, ressources MCP pour exposer des catalogues.
• 2.5 Outils intégrés : Grep pour le contenu, Glob pour les chemins, Read et Write pour les fichiers entiers, Edit pour une modification ciblée.

Pièges mis en avant : des descriptions minimales ou redondantes ; une erreur générique (« opération échouée ») qui empêche toute décision de reprise ; confondre échec d'accès et résultat vide légitime ; surcharger un agent d'outils ; coder un serveur maison quand un serveur communautaire existe.

Domaine 3 — Configuration et workflows Claude Code (20 %)

• 3.1 Hiérarchie CLAUDE.md : niveaux utilisateur, projet et sous-dossier ; imports, dossier .claude/rules/, commande /memory pour diagnostiquer.
• 3.2 Commandes et skills : portée projet (versionnée) contre portée personnelle ; options de frontmatter des skills comme context: fork, allowed-tools et argument-hint.
• 3.3 Règles par chemin : fichiers de règles activés par des motifs glob, idéaux pour des fichiers dispersés (tests, par exemple).
• 3.4 Plan mode ou exécution directe : plan mode pour les changements d'architecture ou multi-fichiers, exécution directe pour un correctif bien délimité ; sous-agent Explore pour isoler une exploration verbeuse.
• 3.5 Raffinement itératif : exemples d'entrée et de sortie, tests écrits d'abord, pattern « interview » où Claude pose ses questions avant de coder.
• 3.6 CI/CD : mode non interactif (-p), sortie JSON contrainte par schéma, contexte projet fourni via CLAUDE.md, relecture par une instance distincte.

Pièges mis en avant : des consignes d'équipe rangées dans le fichier personnel d'un développeur ; un CLAUDE.md racine fourre-tout ; l'exécution directe sur une refonte d'architecture ; faire relire le code par la session qui l'a écrit ; relancer une revue sans ses remarques précédentes.

Domaine 4 — Ingénierie de prompt et sortie structurée (20 %)

• 4.1 Critères explicites : dire précisément quoi signaler et quoi ignorer, car les faux positifs érodent la confiance des développeurs.
• 4.2 Few-shot : deux à quatre exemples ciblés sur les cas ambigus, en montrant pourquoi une option l'emporte sur une autre.
• 4.3 Sortie structurée : passer par un outil doté d'un schéma JSON ; champs facultatifs, valeurs « autre » avec précision, valeur « incertain ».
• 4.4 Validation et relance : renvoyer le document, l'extraction ratée et l'erreur précise ; savoir quand une relance ne sert à rien.
• 4.5 Traitement par lots : l'API Message Batches, moins chère mais sans garantie de délai, pour les tâches non bloquantes ; corrélation par custom_id.
• 4.6 Revues multi-instances et multi-passes : une passe par fichier, puis une passe d'intégration entre fichiers.

Pièges mis en avant : les consignes du type « sois prudent », qui n'améliorent pas la précision ; croire qu'un schéma strict élimine aussi les erreurs de sens (totaux incohérents, valeur mal placée) ; rendre obligatoire un champ parfois absent ; relancer quand l'information manque dans la source ; passer par les lots pour un contrôle bloquant avant fusion.

Domaine 5 — Gestion du contexte et fiabilité (15 %)

• 5.1 Préserver l'essentiel : isoler montants, dates et identifiants dans un bloc de faits hors résumé ; élaguer les sorties d'outils ; tenir compte de l'effet « perdu au milieu ».
• 5.2 Escalade : céder immédiatement à une demande explicite d'humain, escalader quand la politique est muette ou ambiguë, demander un identifiant en cas de correspondances multiples.
• 5.3 Propagation des erreurs : remonter type d'échec, requête tentée et résultats partiels, après une tentative de reprise locale.
• 5.4 Grandes bases de code : fichiers de notes (scratchpad), délégation à des sous-agents, /compact, manifestes d'état pour reprendre après incident.
• 5.5 Revue humaine : échantillonnage aléatoire stratifié, précision mesurée par type de document et par champ avant d'automatiser.
• 5.6 Provenance : conserver le lien affirmation–source, annoter les données contradictoires, dater les informations.

Pièges mis en avant : escalader selon le sentiment du client ; se fier à une confiance auto-déclarée par le modèle ; choisir au hasard entre plusieurs clients correspondants ; supprimer silencieusement une erreur (résultat vide présenté comme un succès) ou, à l'inverse, arrêter tout le workflow pour un seul échec ; se fier à une précision globale qui masque un type de document mal traité ; trancher arbitrairement entre deux sources fiables.

Ce qui est hors programme

Le guide exclut explicitement ces sujets :

• l'entraînement ou le fine-tuning de modèles ;
• l'authentification, la facturation et la gestion de compte de l'API, ainsi que la rotation de clés et les protocoles comme OAuth ;
• le détail d'un langage ou d'un framework au-delà de ce qu'exige la configuration d'outils et de schémas ;
• le déploiement et l'hébergement de serveurs MCP (réseau, conteneurs) ;
• le fonctionnement interne de Claude, son entraînement, l'IA constitutionnelle et le RLHF ;
• les modèles d'embeddings et les bases vectorielles ;
• le computer use et l'analyse d'images ;
• le streaming et les événements envoyés par le serveur ;
• les limites de débit, les quotas et les calculs de tarification de l'API ;
• les configurations spécifiques à un fournisseur cloud ;
• les benchmarks et comparaisons de modèles ;
• le prompt caching au-delà du fait qu'il existe, et le fonctionnement de la tokenisation.

Les quatre exercices du guide, en plan d'action

Voici les quatre exercices du guide, transformés en quatre semaines de travail.

Exercice 1 — Un agent multi-outils qui sait escalader (domaines 1, 2, 5). Créez trois ou quatre outils, dont deux volontairement proches. Écrivez la boucle pilotée par stop_reason. Ajoutez des erreurs structurées : l'agent doit relancer une erreur transitoire et expliquer une erreur métier. Posez un hook qui bloque une opération au-delà d'un seuil et la redirige vers un humain. Testez des messages mêlant plusieurs demandes.

Exercice 2 — Claude Code configuré pour une équipe (domaines 3, 2). Rédigez un CLAUDE.md de projet, ajoutez des règles par chemin (API, tests) et vérifiez qu'elles ne se chargent que sur les bons fichiers. Créez une skill de projet isolée avec context: fork. Configurez un serveur MCP partagé et un serveur personnel, et vérifiez qu'ils coexistent. Comparez plan mode et exécution directe sur trois tâches de difficulté croissante.

Exercice 3 — Un pipeline d'extraction (domaines 4, 5). Définissez un outil d'extraction avec schéma (champs facultatifs, valeur « autre »). Sur des documents incomplets, vérifiez qu'il renvoie des valeurs nulles au lieu d'inventer. Ajoutez la boucle validation-relance, soumettez un lot via l'API Message Batches en ne relançant que les échecs, puis routez les extractions peu fiables vers une revue humaine.

Exercice 4 — Un pipeline de recherche multi-agents (domaines 1, 2, 5). Construisez un coordinateur et au moins deux sous-agents, en leur passant les résultats directement dans le prompt. Lancez-les en parallèle et mesurez le gain. Structurez chaque résultat (affirmation, extrait, source, date). Simulez une panne pour vérifier que l'erreur remonte avec les résultats partiels, puis confrontez le système à deux sources contradictoires : les deux valeurs doivent survivre dans le rapport, attribuées.

Les douze questions d'exemple

Le guide se termine par douze questions commentées, issues du test d'entraînement officiel. Nous ne les reproduisons pas ; voici seulement leurs thèmes, pour vous aider à les situer :

1. Garantir qu'une vérification de client précède toute opération de commande.
2. Corriger un mauvais choix entre deux outils aux descriptions trop courtes.
3. Mieux calibrer l'escalade d'un agent qui résout trop peu au premier contact.
4. Rendre une commande personnalisée disponible à toute l'équipe.
5. Choisir la bonne approche pour découper un monolithe en microservices.
6. Appliquer des conventions différentes selon le type de fichier.
7. Trouver la cause d'un rapport de recherche qui ignore une partie du sujet.
8. Faire remonter la panne d'un sous-agent de recherche au coordinateur.
9. Donner à l'agent de synthèse un moyen de vérifier des faits sans casser la séparation des rôles.
10. Débloquer un job CI où Claude Code attend une saisie interactive.
11. Réduire les coûts d'analyse sans pénaliser les contrôles bloquants.
12. Réorganiser une revue de pull request trop volumineuse et incohérente.

Lisez surtout leurs explications : elles révèlent la logique de l'examen — traiter la cause racine et préférer la solution proportionnée.

Comment utiliser ce guide avec le site

1. Cartographiez. Lisez l'exam guide, puis notre page les 5 domaines pour les exemples et erreurs fréquentes par domaine.
2. Planifiez. Calez les quatre exercices dans le plan d'étude, en commençant par le domaine 1.
3. Révisez les notions clés dans le glossaire : boucle agentique, hooks, tool_choice et Batch API.
4. Repérez les pièges avec la page anti-patterns, qui recoupe largement les listes ci-dessus.
5. Mesurez-vous avec l'examen blanc CCA-F et revenez au guide sur chaque domaine où vous perdez des points.

Revérifiez la version de l'exam guide juste avant de vous inscrire.