Les 5 domaines de l'examen CCA-F

L'examen CCA-F (Claude Certified Architect — Foundations) évalue cinq domaines de compétence complémentaires, eux-mêmes découpés en sous-domaines (objectifs). Cette page détaille, pour chacun, ce qu'il couvre, les connaissances évaluées et les compétences attendues sous-domaine par sous-domaine, puis des exemples concrets et les erreurs que commettent souvent les candidats.

Les pondérations indicatives retenues dans ce guide sont les suivantes : Domaine 1 — 27 %, Domaine 2 — 18 %, Domaine 3 — 20 %, Domaine 4 — 20 %, Domaine 5 — 15 %. Ces proportions vous aident à doser votre effort de révision, mais elles doivent être confrontées au descriptif officiel d'Anthropic, susceptible d'évoluer depuis le lancement de la certification le 12 mars 2026.

Domaine 1 — Architecture agentique & orchestration

Avec une pondération indicative de 27 %, l'architecture agentique et l'orchestration constituent le domaine le plus structurant de l'examen. Il porte sur la conception de systèmes dans lesquels Claude n'est pas un simple générateur de texte, mais un acteur capable de raisonner, de décider, d'appeler des outils et d'enchaîner plusieurs étapes — éventuellement réparties entre plusieurs agents — pour atteindre un objectif.

Sous-domaines évalués

1.1 — Conception de la boucle d'agent

Connaissances évaluées : le cycle de vie d'une boucle d'agent — envoyer une requête à Claude, inspecter le stop_reason, exécuter l'outil demandé quand il vaut tool_use, renvoyer le résultat, et recommencer jusqu'à end_turn.

Compétences attendues : implémenter un flux de contrôle qui poursuit la boucle tant que stop_reason vaut tool_use et s'arrête proprement sinon.

1.2 — Patterns coordinateur–sous-agents

Connaissances évaluées : l'architecture en étoile (hub-and-spoke) où un agent coordinateur délègue à des sous-agents spécialisés, et ses compromis face à un agent unique.

Compétences attendues : choisir entre agent unique et organisation multi-agents selon la complexité et le besoin d'isolation des contextes.

1.3 — Contexte et création de sous-agents

Connaissances évaluées : comment un sous-agent reçoit un contexte restreint, est lancé (spawning) via l'outil dédié, et restitue un résultat synthétique au coordinateur.

Compétences attendues : dimensionner le contexte transmis à un sous-agent au strict nécessaire pour limiter le bruit et le coût.

1.4 — Application de workflows multi-étapes

Connaissances évaluées : les mécanismes qui imposent un enchaînement d'étapes ordonné plutôt qu'une exécution libre.

Compétences attendues : structurer un workflow pour garantir qu'une étape critique ne soit pas sautée par l'agent.

1.5 — Hooks de l'Agent SDK (PostToolUse)

Connaissances évaluées : les points d'interception (hooks) du cycle de vie, notamment PostToolUse, et leur rôle de validation ou d'automatisation.

Compétences attendues : placer un hook au bon moment pour vérifier, formater ou journaliser une action sans alourdir la boucle principale.

1.6 — Décomposition des tâches

Connaissances évaluées : les stratégies pour fractionner un objectif complexe en sous-tâches traçables.

Compétences attendues : découper un problème de façon que chaque sous-tâche soit vérifiable indépendamment.

1.7 — État de session et reprise

Connaissances évaluées : la persistance de l'état d'une session et les mécanismes de reprise (reprendre une session existante, ou en dériver une copie).

Compétences attendues : concevoir un agent capable de reprendre un travail interrompu sans repartir de zéro.

Exemple concret

Imaginons un assistant de support technique. Une chaîne déterministe suffit s'il s'agit toujours de classer un ticket puis de répondre. En revanche, si l'assistant doit consulter une base de connaissances, ouvrir un ticket dans un outil tiers et parfois escalader vers un humain, une architecture agentique avec boucle d'outils devient justifiée. La bonne réponse d'examen privilégie l'architecture la plus simple qui résout réellement le problème.

Erreurs fréquentes

Beaucoup de candidats considèrent l'agent autonome comme la solution par défaut. C'est un piège : l'examen valorise la sobriété architecturale. Autre erreur classique, oublier les garde-fous d'arrêt, ce qui rend un agent coûteux et imprévisible. Pour approfondir, consultez nos cours sur Claude Code et la page anti-patterns.

Domaine 2 — Conception d'outils & intégration MCP

Avec une pondération indicative de 18 %, ce domaine porte sur deux faces d'une même médaille : concevoir des outils que Claude utilise sans se tromper, et connecter le modèle à des données et systèmes externes via le Model Context Protocol (MCP), le standard ouvert qui uniformise ces intégrations.

Sous-domaines évalués

2.1 — Conception des interfaces d'outils

Connaissances évaluées : ce qui rend un outil compréhensible pour le modèle — nom explicite, description claire, paramètres bien typés et documentés.

Compétences attendues : rédiger une définition d'outil qui réduit les appels erronés et les paramètres mal remplis.

2.2 — Réponses d'erreur structurées

Connaissances évaluées : l'intérêt de renvoyer des erreurs exploitables (indicateur d'erreur, message actionnable) plutôt que des échecs muets.

Compétences attendues : concevoir un retour d'erreur qui permet à l'agent de se corriger ou d'escalader, au lieu de boucler.

2.3 — Répartition des outils entre agents

Connaissances évaluées : comment limiter les outils disponibles par agent (par exemple via une liste d'outils autorisés) pour cadrer son périmètre.

Compétences attendues : n'exposer à chaque agent que les outils nécessaires à sa mission, selon le principe du moindre privilège.

2.4 — Intégration de serveurs MCP

Connaissances évaluées : l'architecture client-serveur du MCP, le rôle du serveur comme passerelle, et sa déclaration (par exemple un fichier .mcp.json).

Compétences attendues : décider quand un serveur MCP est préférable à une intégration codée à la main, et configurer une connexion propre.

2.5 — Outils intégrés

Connaissances évaluées : les outils fournis nativement — lecture, écriture, édition, exécution shell, recherche par motif et par fichier (Read, Write, Edit, Bash, Grep, Glob).

Compétences attendues : choisir l'outil intégré adapté à une tâche plutôt que de réinventer une capacité existante.

Exemple concret

Une entreprise veut que Claude réponde à des questions sur sa documentation interne et puisse créer des tâches dans son outil de suivi. Un serveur MCP qui expose la documentation en ressources (lecture seule) et l'outil de suivi via un outil restreint à la création de tâches constitue une intégration propre. Exposer un accès en écriture complet à la base documentaire serait un contre-exemple typique.

Erreurs fréquentes

L'erreur la plus répandue est d'accorder des permissions trop larges « pour que ça marche ». Le principe du moindre privilège doit guider chaque décision. Une autre confusion fréquente consiste à mélanger ressources et outils : une ressource se lit, un outil agit. Approfondissez en explorant nos cours et entraînez-vous sur l' examen blanc CCA-F.

Domaine 3 — Claude Code : configuration & workflows

Avec une pondération indicative de 20 %, ce domaine évalue la maîtrise de Claude Code, l'assistant d'Anthropic qui opère directement dans un dépôt de code et dans le terminal — sa configuration, ses commandes personnalisées et son intégration dans des workflows reproductibles.

Sous-domaines évalués

3.1 — Hiérarchie des fichiers CLAUDE.md

Connaissances évaluées : comment les fichiers CLAUDE.md se combinent à plusieurs niveaux (global, projet, sous-dossier) et la mécanique d'import entre eux.

Compétences attendues : organiser le contexte projet pour que les règles les plus spécifiques l'emportent au bon endroit.

3.2 — Commandes slash et Skills personnalisées

Connaissances évaluées : la définition de commandes slash et de Skills réutilisables pour encapsuler des procédures récurrentes.

Compétences attendues : créer une commande personnalisée qui standardise une tâche répétée plutôt que de la réécrire à chaque fois.

3.3 — Règles spécifiques par chemin

Connaissances évaluées : comment appliquer des règles ciblées à certains chemins du dépôt.

Compétences attendues : restreindre une consigne à la partie du code réellement concernée.

3.4 — Plan mode vs exécution directe

Connaissances évaluées : la différence entre planifier avant d'agir (plan mode) et exécuter directement, et le risque associé à chaque approche.

Compétences attendues : choisir le plan mode pour les changements sensibles ou ambigus, l'exécution directe pour les tâches simples et cadrées.

3.5 — Techniques de raffinement itératif

Connaissances évaluées : les boucles d'amélioration progressive d'un résultat plutôt qu'une production « du premier coup ».

Compétences attendues : itérer de façon mesurée en s'appuyant sur des retours concrets (tests, revue, exécution).

3.6 — Intégration aux pipelines CI/CD

Connaissances évaluées : comment intégrer l'assistant dans des chaînes d'intégration et de déploiement continus.

Compétences attendues : insérer une vérification automatisée au bon endroit du pipeline sans bloquer le flux de travail.

Exemple concret

Sur un projet où chaque modification doit passer un linter et une suite de tests, configurer un hook de fin d'édition qui lance ces vérifications évite les régressions silencieuses. De même, déléguer la recherche documentaire à un sous-agent en lecture seule laisse l'agent principal concentré sur l'implémentation.

Erreurs fréquentes

L'erreur typique est de négliger le fichier de contexte projet, puis de se plaindre que l'assistant ne respecte pas les conventions. Autre piège : confier des permissions d'exécution trop larges sans réfléchir aux commandes destructrices. Nos cours sur Claude Code détaillent une configuration de référence, et la page plan d'étude indique quand l'aborder.

Domaine 4 — Ingénierie de prompt & sortie structurée

Avec une pondération indicative de 20 %, ce domaine couvre la conception d'invites robustes et la production de sorties exploitables par des systèmes en aval. C'est la compétence transversale qui irrigue tous les autres domaines.

Sous-domaines évalués

4.1 — Conception de critères explicites

Connaissances évaluées : l'importance de définir des critères de réussite clairs plutôt que des consignes vagues.

Compétences attendues : transformer une demande floue en consigne précise et vérifiable.

4.2 — Prompting few-shot

Connaissances évaluées : l'apprentissage en contexte par l'exemple, et le choix d'exemples représentatifs.

Compétences attendues : montrer plutôt que décrire en sélectionnant quelques cas bien choisis.

4.3 — Sortie structurée via outils / schémas JSON

Connaissances évaluées : comment imposer un format exploitable, notamment en s'appuyant sur des outils ou des schémas JSON.

Compétences attendues : concevoir une sortie structurée fiable à intégrer dans un traitement automatisé.

4.4 — Boucles de validation, retry et feedback

Connaissances évaluées : les mécanismes qui vérifient une sortie, la rejouent en cas d'échec et renvoient un retour exploitable.

Compétences attendues : mettre en place une boucle de validation qui corrige automatiquement une sortie non conforme.

4.5 — Stratégies de traitement par lots

Connaissances évaluées : l'intérêt du traitement par lots pour des volumes importants, et ses compromis de latence et de coût.

Compétences attendues : choisir un traitement par lots quand le volume le justifie et que la latence n'est pas critique.

4.6 — Revue multi-instances et multi-passes

Connaissances évaluées : le recours à plusieurs passes ou instances pour fiabiliser un résultat (revue croisée).

Compétences attendues : organiser une revue en plusieurs passes pour réduire les erreurs sur une tâche à fort enjeu.

Exemple concret

Une consigne « résume ce document » est fragile. Une version d'examen solide précise la longueur attendue, le public visé, le format (par exemple une liste de points), et fournit un exemple de résumé jugé satisfaisant. Pour valider, on constitue un petit jeu de documents avec des résumés de référence.

Erreurs fréquentes

L'erreur la plus répandue est de juger un prompt sur une seule sortie réussie, sans évaluation systématique. Autre piège : empiler des instructions contradictoires en espérant couvrir tous les cas. Consultez nos cours sur les fondamentaux et exercez-vous via l'examen blanc CCA-F.

Domaine 5 — Gestion du contexte & fiabilité

Avec une pondération indicative de 15 %, ce domaine porte sur la maîtrise de la fenêtre de contexte et sur la fiabilité des systèmes : sélectionner la bonne information, la maintenir pertinente dans la durée, gérer les erreurs et garder un humain dans la boucle quand l'enjeu l'exige.

Sous-domaines évalués

5.1 — Préservation du contexte conversationnel

Connaissances évaluées : comment conserver l'essentiel d'une conversation longue sans saturer la fenêtre de contexte.

Compétences attendues : distinguer mémoire de travail et connaissances persistantes, et décider quoi conserver.

5.2 — Escalade et résolution d'ambiguïté

Connaissances évaluées : les situations où le système doit demander une clarification ou escalader plutôt que de deviner.

Compétences attendues : concevoir un comportement qui escalade une ambiguïté au lieu de produire une réponse hasardeuse.

5.3 — Stratégies de propagation d'erreur

Connaissances évaluées : comment une erreur se propage dans un système multi-étapes et comment l'isoler.

Compétences attendues : éviter qu'une erreur locale ne contamine silencieusement tout le résultat.

5.4 — Exploration de grandes bases de code

Connaissances évaluées : les approches pour explorer un large dépôt sans tout charger en contexte.

Compétences attendues : récupérer de façon ciblée les fichiers pertinents plutôt que d'injecter l'ensemble du dépôt.

5.5 — Workflows de revue humaine

Connaissances évaluées : le rôle de la validation humaine (human in the loop) sur les actions sensibles.

Compétences attendues : placer un point de revue humaine là où le risque le justifie, sans bloquer inutilement le reste.

5.6 — Provenance de l'information et synthèse multi-sources

Connaissances évaluées : l'importance de tracer l'origine d'une information et de synthétiser plusieurs sources sans les confondre.

Compétences attendues : produire une réponse qui cite ses sources et signale les contradictions entre elles.

Exemple concret

Un agent de longue durée qui accumule tout l'historique finit par dépasser des limites et par diluer l'information utile. La bonne approche consiste à résumer périodiquement les échanges anciens, à conserver les décisions importantes en mémoire structurée, et à ne récupérer les documents qu'au moment où ils sont nécessaires.

Erreurs fréquentes

L'erreur la plus fréquente est de croire qu'« ajouter plus de contexte » améliore toujours la réponse : au-delà d'un certain point, le bruit nuit à la précision et le coût explose. Autre piège, compacter de façon agressive au point de perdre des décisions structurantes. Approfondissez en parcourant nos cours et la FAQ de la certification.