Code d’examen CCAR-P 63 items · 120 min 175 $ Réussite 720/1000

Ce que valide la certification

Que vous savez architecturer des systèmes Claude de production de bout en bout — traduire des problèmes métier ambigus en solutions résilientes, attentives au coût et conformes ; sélectionner les modèles et router entre eux ; concevoir les couches de récupération et d’intégration ; mettre en place des programmes d’évaluation et d’optimisation ; gouverner la sûreté et le risque réglementaire ; et communiquer les décisions sur tout leur cycle de vie à des parties prenantes techniques et non techniques.

Il s’agit de l’examen Architect de niveau Professional. Il suppose que vous opérez déjà au niveau Foundations et évalue le jugement d’architecte senior : arbitrages sous contrainte, matrices de décision, modèles de coût, raisonnement de type ADR, et la capacité à justifier pourquoi une conception est correcte pour un contexte donné plutôt qu’à réciter des fonctionnalités.

Public visé : les architectes de solutions, les ingénieurs staff/principal et les référents techniques qui portent la conception de systèmes Claude en entreprise, y compris dans les secteurs réglementés.

Public non visé : les nouveaux utilisateurs de Claude, ou les rôles qui ne font que consommer Claude comme outil de productivité (voir CCAO-F).

Lien avec CCAR-F (à lire en premier)

CCAR-P n’est pas un programme disjoint de l’examen Architect – Foundations. Chacun des cinq domaines de CCAR-F réapparaît dans CCAR-P à plus haute altitude — on ne vous demande plus ce qu’est un patron, mais quand le choisir sous contraintes conflictuelles et comment défendre ce choix.

Domaine CCAR-F	Réapparaît dans CCAR-P comme	Changement d’altitude
Agentic Architecture & Orchestration (27 %)	D1 Solution Design & Architecture ; volets multi-agents de D3	De « construire une boucle coordinateur/sous-agents » à « choisir workflow vs agentique vs augmented-LLM sous contraintes de SLA, de coût et de fiabilité, et rédiger l’ADR »
Prompt Engineering & Structured Output (20 %)	D2 Models, Prompting & Context Engineering	De « écrire un bon prompt » à « gouverner les prompts comme des actifs versionnés, router à travers un portefeuille de modèles, gérer les changements incompatibles et l’architecture de caching »
Tool Design & MCP Integration (18 %)	D3 Integration (dont RAG)	De « définir un schéma d’outil » à « analyse de la surcharge de capacités et du moindre privilège, propagation d’identité, sélection MCP vs API vs agent-à-agent »
Context Management & Reliability (15 %)	HA/repli de D1 ; ingénierie de contexte de D2 ; optimisation de D4	De « gérer la fenêtre de contexte » à « planification de capacité, paliers de rate-limit, conception de repli, observabilité à l’échelle »
Claude Code Configuration & Workflows (20 %)	D7 Developer Productivity & Operational Enablement	De « configurer CLAUDE.md et les settings » à « déployer des politiques managées et des programmes d’activation à travers les équipes »

Les quatre écarts à étudier

Quatre domaines sont nouveaux ou nettement plus approfondis au niveau Professional. Si vous n’avez le temps que de combler des lacunes, comblez celles-ci :

Architecture RAG (D3, 19 % — le plus gros domaine). Stratégie de chunking selon la forme des données, récupération dense/sparse/hybride, reranking, grounding/citations, évaluation de la récupération, et la décision RAG vs long-context vs fine-tuning. Quasi absente au niveau Foundations.
Frameworks d’évaluation et tests A/B (D4, 16 %). Golden sets, calibration de LLM-as-judge, tests par paires avec significativité statistique, évals offline vs online, suites de régression en CI, et diagnostic structuré des défaillances.
Conformité en secteur réglementé (D5, 14 %). GDPR/DPIA/résidence, HIPAA/BAA/PHI, FedRAMP High via Bedrock/Vertex, SOC 2, EU AI Act, Zero Data Retention (et l’exigence de rétention de 30 jours de Fable 5.1).
Communication avec les parties prenantes et gestion du cycle de vie (D6, 14 %). Frameworks de découverte, ADR et matrices de décision, documentation C4, phases du cycle de vie avec critères de sortie, et gestion des dépréciations de modèle comme un événement du cycle de vie.

Blueprint (Exam Guide v1.0, en vigueur juillet 2026)

#	Domaine	Poids	Items (approx.)	Page du cours
1	Solution Design & Architecture	17 %	~11	Domaine 1
2	Claude Models, Prompting & Context Engineering	13 %	~8	Domaine 2
3	Integration (dont RAG)	19 %	~12	Domaine 3
4	Evaluation, Testing & Optimization	16 %	~10	Domaine 4
5	Governance, Safety & Risk Management	14 %	~9	Domaine 5
6	Stakeholder Communication & Lifecycle Management	14 %	~9	Domaine 6
7	Developer Productivity & Operational Enablement	7 %	~4	Domaine 7

Où sont les points

Integration/RAG (19 %), Solution Design (17 %) et Evaluation (16 %) représentent ensemble 52 % de l’examen. Les deux domaines « soft » — Governance (14 %) et Stakeholder/Lifecycle (14 %) — pèsent 28 % de plus et sont là où les candidats de niveau Foundations perdent des points. Ne les traitez pas comme du remplissage.

L’état d’esprit de l’Architect

L’examen récompense constamment une posture : un architecte choisit sous contrainte et sait défendre son choix par des preuves. Les bonnes réponses tendent à :

Partir des piliers de valeur métier (efficacité, coût, SLA de performance) et en dériver la conception, pas l’inverse.
Préférer l’application programmatique (hooks, validation, stop_reason) à l’application par prompt pour les règles critiques.
Appliquer le moindre privilège aux outils — retirer les capacités inutiles plutôt que de les journaliser ou de les confirmer.
Concevoir pour la défaillance : modèles de repli, reprises avec backoff, idempotence, points de contrôle humains sur les actions irréversibles.
Mesurer avec des métriques par segment et une évaluation indépendante, jamais uniquement agrégées ni auto-déclarées.
Adapter le placement cloud et la rétention à la résidence des données et à la conformité, pas à la commodité.
Traiter les prompts, les modèles et les outils comme des actifs versionnés et gouvernés avec des plans de déploiement et de retour arrière.

Les mauvaises réponses tendent à : sur-concevoir (multi-agents là où un flux de travail suffit), faire confiance à la confiance auto-déclarée, utiliser des plafonds d’itérations arbitraires ou l’analyse du langage naturel pour le flux de contrôle, donner 18 outils aux agents « au cas où », optimiser un seul chiffre en masquant des régressions par segment, et sauter le DPIA/BAA/point de contrôle humain parce que « c’est interne ».

Répartition du temps suggérée (plan sur 35 heures)

Domaine	Poids	Heures
Integration (dont RAG)	19 %	8
Solution Design & Architecture	17 %	6,5
Evaluation, Testing & Optimization	16 %	6
Governance, Safety & Risk Management	14 %	5
Stakeholder Communication & Lifecycle	14 %	5
Models, Prompting & Context Engineering	13 %	3
Developer Productivity & Operational Enablement	7 %	1,5

Liste de préparation pratique

Construisez un pipeline RAG de bout en bout (ingestion → chunk → embed → index → récupération → rerank → grounding) et instrumentez recall@k et la fidélité.
Reproduisez la défaillance confiant-mais-faux-après-rafraîchissement : modifiez un document, observez une récupération obsolète produire une réponse fausse, et corrigez-la au niveau de l’index.
Rédigez un ADR pour une décision workflow-vs-agentique avec une matrice de décision et les alternatives rejetées.
Mettez en place une éval LLM-as-judge dans une session/un modèle distincts et calibrez-la par rapport à des étiquettes humaines.
Menez un test A/B par paires de deux prompts et calculez si la différence est statistiquement significative.
Modélisez le coût d’un routage Haiku 4.5 → Sonnet 5 → Opus 5 avec prompt caching et Batch API sur une charge de travail réaliste.
Faites une revue de surcharge de capacités / moindre privilège de l’ensemble d’outils d’un agent et retirez les outils destructeurs inutiles.
Rédigez un plan de DPIA et une note de traitement BAA/PHI pour un déploiement réglementé ; décidez Bedrock vs Vertex vs API directe sur des critères de résidence.
Produisez une vue C4 contexte + conteneur et un runbook pour un système.