Les 5 domaines de l'examen CCA-F

L'examen CCA-F (Claude Certified Architect) évalue cinq domaines de compétence complémentaires. Cette page détaille, pour chacun, ce qu'il couvre, les concepts clés à maîtriser, les compétences attendues le jour de l'examen, des exemples concrets et les erreurs que commettent souvent les candidats.

Les pondérations indicatives retenues dans ce guide sont les suivantes : Domaine 1 — 25 %, Domaine 2 — 20 %, 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

Avec une pondération indicative de 25 %, l'architecture agentique est 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 pour atteindre un objectif.

Ce que couvre le domaine

Ce domaine traite du cycle de vie d'un agent : la boucle qui consiste à recevoir une demande, à raisonner, à choisir une action, à exécuter cet outil, à observer le résultat, puis à recommencer jusqu'à la résolution de la tâche. Il aborde aussi l'orchestration : comment décomposer un problème complexe en sous-tâches, comment coordonner plusieurs agents spécialisés, et comment fixer des critères d'arrêt pour éviter les boucles infinies.

Concepts clés

• Boucle d'agent : l'alternance raisonnement → action → observation, et la manière dont le contexte s'enrichit à chaque tour.
• Appels d'outils (tool use) : définition de schémas d'outils clairs, description de leurs paramètres, gestion des erreurs renvoyées par un outil.
• Orchestration multi-étapes : enchaînement séquentiel, exécution parallèle, et patterns de type orchestrateur-exécutants.
• Garde-fous : limites de tours, validation des actions sensibles, approbations humaines (human in the loop), et journalisation.
• Critères de fin : comment l'agent sait qu'il a terminé, et comment signaler un échec proprement plutôt que de s'enliser.

Compétences attendues

Vous devez être capable de choisir, face à un cas d'usage donné, entre un appel unique au modèle, une chaîne déterministe d'appels, ou un véritable agent autonome. L'examen attend que vous sachiez justifier ce choix : un agent autonome apporte de la souplesse mais coûte plus cher et se contrôle moins bien qu'une chaîne fixe. Vous devez aussi savoir dimensionner les garde-fous en fonction du risque associé aux actions (lecture seule contre écriture irréversible, par exemple).

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 l'architecture agentique et la page anti-patterns.

Domaine 2 — Intégration MCP

Avec une pondération indicative de 20 %, ce domaine porte sur le Model Context Protocol (MCP), le standard ouvert qui permet de connecter Claude à des sources de données et à des outils externes de façon uniforme.

Ce que couvre le domaine

Le MCP définit une façon standardisée pour un modèle d'accéder à des ressources, d'invoquer des outils et de réutiliser des invites prédéfinies. Le domaine couvre l'architecture client-serveur du protocole, le rôle du serveur MCP comme passerelle vers un système, et les bonnes pratiques de sécurité associées à l'exposition de données sensibles.

Concepts clés

• Serveur MCP : un service qui expose des capacités (ressources, outils, invites) à un client compatible.
• Ressources : données en lecture exposées au modèle, identifiées par des URI.
• Outils : actions que le serveur met à disposition et que le modèle peut déclencher.
• Transport : les modes de communication entre client et serveur (par exemple en local via les flux standard, ou à distance).
• Sécurité et permissions : portée minimale des accès, authentification, isolement des données, et contrôle de ce que le modèle peut réellement faire.

Compétences attendues

Vous devez comprendre quand un serveur MCP est la bonne réponse plutôt qu'une intégration directe codée à la main. L'examen attend que vous sachiez raisonner sur la surface d'exposition : quelles ressources rendre visibles, quels outils autoriser, et comment limiter les droits au strict nécessaire. La capacité à identifier un risque de fuite de données ou d'élévation de privilèges dans une configuration MCP est particulièrement valorisée.

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 avec nos cours sur le Model Context Protocol et entraînez-vous sur les questions de pratique.

Domaine 3 — Claude Code

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.

Ce que couvre le domaine

Le domaine porte sur l'utilisation de Claude Code dans des projets réels : configuration du contexte projet, personnalisation du comportement, automatisation de tâches récurrentes et délégation à des sous-agents. Il s'agit moins de connaître chaque commande par cœur que de comprendre comment structurer un projet pour que l'assistant soit fiable et productif.

Concepts clés

• Fichier de contexte projet (de type CLAUDE.md) : conventions, commandes de build et de test, et règles que l'assistant doit respecter.
• Hooks : scripts déclenchés automatiquement à certains moments du cycle de travail, par exemple pour formater le code ou lancer des vérifications.
• Sous-agents : délégation de tâches spécialisées à des agents dédiés, avec un périmètre et des outils restreints.
• Permissions et outils : contrôle de ce que l'assistant peut exécuter, notamment les commandes shell sensibles.
• Automatisation : intégration dans des workflows reproductibles, y compris en intégration continue.

Compétences attendues

Vous devez savoir comment fournir le bon contexte à Claude Code pour réduire les allers-retours, comment encadrer ses actions par des permissions, et quand recourir à un sous-agent plutôt que de tout confier à un agent unique. L'examen attend une vision pratique : reconnaître une configuration de projet saine, repérer un hook mal placé, ou identifier une délégation pertinente.

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

Avec une pondération indicative de 20 %, ce domaine couvre la conception d'invites robustes, claires et reproductibles. C'est la compétence transversale qui irrigue tous les autres domaines.

Ce que couvre le domaine

Le domaine porte sur la rédaction de consignes efficaces : structuration de l'invite, rôle et instructions système, emploi d'exemples, contrôle du format de sortie, et méthodes pour évaluer la qualité des réponses. Il aborde aussi les techniques de raisonnement guidé et la façon de rendre un prompt résistant aux entrées inattendues.

Concepts clés

• Structuration : séparation claire des instructions, du contexte et des données, souvent à l'aide de délimiteurs explicites.
• Exemples (apprentissage en contexte) : montrer plutôt que décrire, en choisissant des cas représentatifs.
• Formats de sortie : imposer un format exploitable, par exemple structuré, pour faciliter le traitement en aval.
• Raisonnement guidé : laisser le modèle réfléchir étape par étape avant de conclure quand la tâche le justifie.
• Évaluation : construire des jeux de tests et des critères pour mesurer objectivement la qualité, plutôt que de juger « à l'œil ».

Compétences attendues

Vous devez savoir transformer une consigne vague en consigne précise et testable, choisir entre instruction et exemple, et concevoir une évaluation qui détecte les régressions. L'examen attend que vous compreniez qu'un prompt n'est pas figé : il s'améliore par itération mesurée, pas par intuition.

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 d'ingénierie de prompt et exercez-vous via les questions de pratique.

Domaine 5 — Gestion du contexte

Avec une pondération indicative de 15 %, ce domaine porte sur la maîtrise de la fenêtre de contexte : sélectionner la bonne information, la maintenir pertinente dans la durée, et garder les coûts sous contrôle.

Ce que couvre le domaine

Le domaine traite de la façon dont l'information circule dans une session : quelles données fournir au modèle, comment les organiser, comment gérer la mémoire entre les tours, et comment réduire l'encombrement du contexte sans perdre ce qui compte. Il aborde aussi l'impact direct du contexte sur la latence et sur le coût.

Concepts clés

• Fenêtre de contexte : sa taille limitée, et le principe que plus de contexte n'est pas synonyme de meilleure réponse.
• Sélection de l'information : récupérer et n'injecter que les éléments pertinents, par exemple via une recherche sémantique.
• Mémoire : conserver l'essentiel d'une conversation longue, en distinguant mémoire de travail et connaissances persistantes.
• Compaction : résumer ou condenser l'historique quand il devient trop volumineux, sans perdre les décisions clés.
• Maîtrise des coûts : relation entre volume de contexte, latence et facturation, et arbitrages associés.

Compétences attendues

Vous devez savoir diagnostiquer un contexte trop chargé ou mal ordonné, proposer une stratégie de récupération d'information ciblée, et décider quand compacter l'historique. L'examen attend que vous reliiez ces choix à des critères concrets : qualité de réponse, latence et coût.

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 avec nos cours sur la gestion du contexte et la FAQ.