# CCAR-P – Présentation du cours
Claude Certified Architect – Professional. Blueprint, public visé, répartition de l’étude, le lien avec CCAR-F et comment utiliser ce cours.
import { Card, CardGrid, Badge } from '@prosefly/astro-components';
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 :
1. **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.
2. **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.
3. **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).
4. **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](/fr/ccar-p/domains/d1-solution-design-architecture/) |
| 2 | Claude Models, Prompting & Context Engineering | 13 % | ~8 | [Domaine 2](/fr/ccar-p/domains/d2-models-prompting-context-engineering/) |
| 3 | Integration (dont RAG) | **19 %** | ~12 | [Domaine 3](/fr/ccar-p/domains/d3-integration-rag/) |
| 4 | Evaluation, Testing & Optimization | 16 % | ~10 | [Domaine 4](/fr/ccar-p/domains/d4-evaluation-testing-optimization/) |
| 5 | Governance, Safety & Risk Management | 14 % | ~9 | [Domaine 5](/fr/ccar-p/domains/d5-governance-safety-risk/) |
| 6 | Stakeholder Communication & Lifecycle Management | 14 % | ~9 | [Domaine 6](/fr/ccar-p/domains/d6-stakeholder-communication-lifecycle/) |
| 7 | Developer Productivity & Operational Enablement | 7 % | ~4 | [Domaine 7](/fr/ccar-p/domains/d7-developer-productivity-operational-enablement/) |
:::tip[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.
## Pages du cours
17 %
13 %
19 %
16 %
14 %
14 %
7 %
63 items chronométrés
63 items inédits, plus difficiles