Introduction
On a passé la CCAF cette semaine. Autant le dire tout de suite : on est tous les deux juniors, sans des mois d'arbitrages de prod derrière nous, nous savions donc que notre expérience ne nous aiderait pas. Ce qu'on pensait, plus modestement, c'est que bien connaître les concepts suffirait à couvrir l'essentiel. Ça ne suffit pas non plus. Pas parce que la certif est ésotérique ou piégeuse pour le plaisir, mais parce qu'elle teste une compétence qui se construit normalement par des mois d'arbitrages en prod, celle de trancher, en quelques secondes, entre plusieurs réponses qui sonnent toutes correctes, et qu'on a dû, nous, la reconstruire à froid.
L'exam guide officiel fait très bien son travail de syllabus : il liste les domaines, les tâches à connaître, la répartition des scénarios. Ce qu'il ne peut pas faire, parce que ce n'est pas sa fonction, c'est vous montrer à quoi ressemble, concrètement, le moment où deux réponses sur quatre semblent également défendables et où il faut choisir en fonction d'un détail de l'énoncé que vous avez failli survoler. C'est cette zone-là, entre la théorie du guide et la mécanique réelle de l'examen, que cet article couvre. On ne va pas résumer l'exam guide, vous l'avez déjà lu, ou vous pourrez le faire en dix minutes. On va plutôt raconter ce qu'on a appris en le préparant pour de vrai, avec les erreurs de raisonnement qu'on a commises en cours de route.
À qui ça s'adresse vraiment, et un avertissement honnête
La CCAF cible, sur le papier, un profil précis : solution architects, tech leads, devs qui ont déjà mis des agents AI en production ou en pré-prod. Bien que la certification soit portée par un environnement Anthropic, elle reste assez agnostique à la technologie utilisée, les concepts peuvent être répliqués pour d’autres providers. L'exam guide parle de "6+ mois d'expérience", et en pratique, ça veut dire avoir déjà été confronté à un vrai arbitrage : un budget de tokens qui explose, un outil mal décrit qui fait dérailler un agent, une politique de garde-fou qu'il a fallu resserrer après un premier incident en prod. Nous, on n'a pas ce vécu-là, pas de prototype passé en prod, pas d'incident réel à raconter. On est juniors, et on l'a quand même passée. Si votre expérience se limite, comme la nôtre, à des prototypes personnels sans contrainte de coût ni de fiabilité, vous allez buter sur des scénarios qui supposent un vécu que vous n'avez pas encore : c'est exactement ce qui nous est arrivé, et c'est pour ça qu'on peut vous témoigner de notre ressenti.
La certif ne teste ni votre capacité à écrire un prompt système élégant, ni votre connaissance fine de l'API (les paramètres, les formats de réponse, la tarification précise). On s'attendait à des questions sur la syntaxe exacte des appels d'outils ou sur les limites de rate-limiting, il n'y en a pas, ou presque. On s'attendait aussi à devoir réciter des définitions ("qu'est-ce qu'un system prompt ?"), ce n'est pas non plus le format. Ce qu'elle teste, c'est votre capacité à lire un scénario de trois paragraphes, identifier la vraie contrainte cachée dedans, et choisir l'option qui l'adresse sans en introduire une nouvelle. Si vous révisez la doc comme un glossaire, vous vous préparez pour le mauvais examen.
Ce qui surprend vraiment dans l'examen
L'exam guide liste les domaines, conception d'agents, usage des outils et du contexte, fiabilité et garde-fous, évaluation et itération, entre autres, et pour chacun, une série de tâches attendues. Ce qu'il ne dit pas, c'est que ces domaines ne sont pas cloisonnés dans l'examen lui-même. Une même question de scénario peut vous demander simultanément de juger un choix d'architecture d'outils et une décision de garde-fou, parce que dans un vrai système de prod, les deux sont rarement séparables. C'est la première surprise : on révise domaine par domaine, mais on est testé de façon transversale.
La deuxième surprise, plus structurante : les questions testent le jugement, pas la mémorisation. Sur d'autres certifs tech, une bonne partie du score se gagne en connaissant par cœur une limite chiffrée ou un nom de paramètre. Ici, connaître la théorie ne suffit pas à choisir la bonne réponse, il faut l'appliquer à un cas concret, souvent ambigu, avec un contexte métier qui pousse vers une réponse "raisonnable" mais fausse. C'est le même exercice mental qu'un post-mortem d'incident : plusieurs explications sont plausibles, une seule tient compte de tous les faits donnés.
Troisième point, très concret côté stratégie : le format présente 6 scénarios et vous en traitez 4. Ça ne veut pas dire que vous pouvez sacrifier un domaine à la révision, les scénarios ne sont pas répartis un-domaine-par-scénario, chacun peut mobiliser plusieurs domaines à la fois. Impossible de parier sur "je saute la partie garde-fous, je ne serai pas interrogé dessus" : le sujet peut resurgir dans le scénario que vous pensiez porter uniquement sur le choix d'outils.
Enfin, les distracteurs. Ils ne sont pas conçus pour piéger un débutant, un débutant ne verrait même pas pourquoi ils sont tentants. Ils sont écrits pour piéger quelqu'un qui a des bases solides et qui reconnaît un pattern familier, mais l'applique au mauvais niveau de granularité. C'est le piège le plus redoutable de l'examen : reconnaître la bonne famille de solution et se tromper quand même parce qu'on n'a pas vérifié qu'elle s'applique à ce scénario précis.
Notre méthode de préparation
On a utilisé l'exam guide comme un syllabus, pas comme un cours. Concrètement : on a listé les domaines et les tâches, et pour chaque tâche, on s'est posé la question "est-ce que je pourrais l'expliquer à un collègue avec un exemple concret, là, tout de suite ?". N'ayant pas d'exemple de prod à piocher dans notre propre vécu, il fallait soit en construire un plausible, soit en trouver un dans la doc ou chez Claude. Si on n'y arrivait pas, c'était le signe qu'on connaissait le concept sans en comprendre l'enjeu, exactement le point à creuser.
Le point qui a le plus changé notre façon de réviser : utiliser Claude comme tuteur interactif plutôt que de lire passivement la documentation. Domaine par domaine, tâche par tâche, on demandait des questions de mise en situation proches du format de l'examen, on répondait, on demandait pourquoi c'était juste ou faux, et surtout pourquoi les autres options ne l'étaient pas. C'est ce dernier réflexe, comprendre pourquoi une mauvaise réponse est mauvaise, pas seulement pourquoi la bonne est bonne, qui prépare vraiment au format à choix multiple de l'examen, parce que c'est exactement le travail cognitif qu'on vous demande le jour J.
La documentation Anthropic (docs.anthropic.com) a servi de deuxième cercle, pour aller creuser les points restés flous après les sessions avec Claude, typiquement les détails de comportement d'une fonctionnalité qu'on utilisait déjà mais sans jamais avoir eu besoin d'en connaître les limites exactes.
Bien qu'utiles pour appréhender les concepts clés, les exercices pratiques de l'exam guide manquent de la profondeur requise pour l'examen, qui est quant à lui très axé sur des cas d'usage réels en production. Là où l’exam parle de prod, les exercices aident à se faire une idée des concepts et à les appliquer partiellement.
La logique de réflexion à avoir sur les questions
La différence entre "je connais le concept" et "je réponds bien à l'examen" tient dans un seul réflexe : ne jamais s'arrêter à la première réponse qui semble correcte. Il faut systématiquement se demander ce qui, dans l'énoncé, élimine les trois autres. Voici quatre exemples annotés, reconstitués à partir de scénarios rencontrés en préparation, avec le raisonnement qu'on a dû reconstruire, parfois après s'être trompés une première fois.
Exemple 1, Deux réponses semblent correctes : chercher le critère discriminant
Scénario : une équipe veut que Claude applique systématiquement une convention de nommage de commit dans un repo, ET propose dynamiquement des snippets réutilisables selon le langage détecté dans le fichier ouvert.
Options plausibles :
A. Documenter la convention et les snippets dans CLAUDE.md avec @import
B. Créer une Skill dédiée qui encapsule la convention et les snippets
C. Mettre la convention dans CLAUDE.md et les snippets dans une Skill
D. Tout mettre dans une seule Skill volumineuse
Raisonnement :
- A et B semblent chacune "correctes" si on ne regarde que la moitié du besoin.
- Le critère discriminant est la NATURE de chaque besoin : la convention de nommage est un contexte permanent, toujours pertinent, à faible coût de chargement -> CLAUDE.md. Les snippets dépendent d'une condition (langage détecté) et ne doivent être chargés qu'à la demande -> Skill.
- C'est C qui respecte cette distinction. A charge des snippets non pertinents en permanence ; B traite un contexte permanent comme une capacité à la demande, ce qui ajoute une latence d'activation inutile.
L'erreur qu'on a failli commettre : choisir A parce que "tout centraliser dans CLAUDE.md" a l'air propre. Le piège, c'est que la propreté apparente n'est pas le critère testé, le critère, c'est le coût et la pertinence du chargement de contexte.
Exemple 2, Attention à ce que la Batch API supporte vraiment
Scénario : une équipe veut faire une revue de code automatisée sur 500 PRs en attente, avec des allers-retours itératifs : Claude appelle un outil pour lire un fichier, analyse, appelle un autre outil pour vérifier une dépendance, puis rend un verdict.
A) Utiliser exclusivement la Batch API pour chaque PR
B) Exécuter une orchestration synchrone (API Standard) parallélisée avec gestion de boucle d'outils (Tool Loop)
C) Utiliser une approche hybride par étape (Multi-step Batching)
D) Utiliser la Batch API uniquement avec du Prompt Caching
Option tentante : utiliser la Batch API pour traiter les 500 PRs en parallèle à moindre coût.
Raisonnement :
- La Batch API est effectivement conçue pour du volume à coût réduit.
- Mais le scénario décrit un usage itératif de tool calling avec plusieurs allers-retours dépendants les uns des autres AVANT le verdict final.
- Le vrai critère à vérifier : est-ce que le mode d'exécution batch visé supporte ce pattern d'appels d'outils enchaînés dans un seul job, ou seulement des requêtes indépendantes soumises en lot ?
- Si l'énoncé précise que chaque PR nécessite une séquence d'appels d'outils interdépendants avant conclusion, la bonne réponse n'est pas "batch pour tout", c'est une architecture hybride : orchestration synchrone du tool calling par PR, avec parallélisation au niveau du lancement des jobs.
Le piège ici n'est pas de mal connaître la Batch API en général, c'est de plaquer une solution qu'on associe au mot "volume" sans vérifier qu'elle couvre le pattern d'interaction réellement décrit.
Exemple 3, Solution générale vs solution qui adresse la root cause
Scénario : un agent a accès à deux outils, analyze_content et
analyze_document, aux descriptions proches. En prod, l'agent choisit parfois le mauvais outil pour des requêtes sur des PDF structurés.
Options :
A. Renommer les outils pour plus de clarté
B. Ajouter des exemples d'usage dans chaque description d'outil
C. Fusionner les deux outils en un seul avec un paramètre de type de contenu
D. Retirer un des deux outils du set disponible pour cet agent
Raisonnement :
- A et B réduisent le taux d'erreur mais n'éliminent pas la cause racine : deux outils qui se recouvrent fonctionnellement laissent toujours une zone d'ambiguïté, même mieux documentée.
- D est une solution partielle qui sacrifie une capacité réelle.
- C adresse la cause racine : s'il n'existe plus qu'un seul point de décision (le paramètre), il n'y a plus de choix erroné possible entre deux outils distincts.
C'est l'exemple le plus révélateur du style de piège CCAF : A et B "font quelque chose d'utile", mais sur le symptôme, pas sur la cause. La bonne réponse est celle qui rend l'erreur structurellement impossible, pas seulement moins probable.
Points clés par domaine
Le but ici n’est pas de vous faire un résumé des domaines, mais plutôt de vous donner quelques astuces ou points clés qui selon notre ressenti sont fortement testés lors de l’examen.
Domaine 1: Agentic Architecture & Orchestration:
Le pattern de coordinateur et subagents, avec la gestion de la mémoire partagée, du transfert de contexte et la bonne séparation des tâches est littéralement le sujet d’un des scénarios. Bien savoir arbitrer quand mettre en place des briques programmatiques déterministes est aussi une compétence clé ciblée par plusieurs scénarios.
Exemple , Gestion du passage de contexte dans un pattern orchestrateur
En production, un coordinateur délègue l'analyse de contrats juridiques sur mesure et non structurés à un sous-agent dédié. Lors des pics de charge, le système subit une hausse de la latence de +400% et des erreurs répétées de dépassement de limite de contexte (Context Window Exceeded). L'analyse montre que le coordinateur réinjecte dans le sous-agent de synthèse l'intégralité du dialogue brut d'analyse du sous-agent pour récupérer les conclusions.
Options :
A. Remplacer le sous-agent par un script de parsing déterministe pour extraire directement les clauses cibles.
B. Configurer le sous-agent pour qu'il génère et renvoie uniquement une synthèse structurée des points clés au coordinateur au lieu du dialogue complet.
C. Stocker le dialogue complet du sous-agent dans une mémoire partagée (ex: base de données) pour que le coordinateur et l'agent de synthèse puissent y accéder directement.
D. Passer le coordinateur sur un modèle disposant d'une fenêtre de contexte plus large pour absorber l'ensemble des échanges.
Raisonnement :
A. Les contrats étant très variés et non structurés, une approche programmatique déterministe échouera face à la diversité des formulations juridiques.
C. Placer le dialogue brut dans une mémoire partagée ne résout rien si le coordinateur lit toujours cette mémoire pour avancer : le volume de tokens réinjecté dans son prompt reste identique.
D. Augmenter la fenêtre de contexte traite le symptôme au lieu de la cause. Cela augmente considérablement les coûts et la latence du coordinateur, tout en repoussant le problème au document suivant.
B. Puisque l'analyse sémantique par LLM est nécessaire (documents variés), la solution réside dans l'optimisation du transfert de contexte. Le coordinateur n'a pas besoin du raisonnement intermédiaire (chain of thought) ni du dialogue complet du sous-agent, mais seulement de ses conclusions.
Domaine 2: Tool Design & MCP Integration:
Pour ce domaine, une des priorités de la certification est de valider que vous êtes capables de construire un ensemble de tools adaptés aux besoins spécifiques des agents, avec des descriptions claires et précises. Il faudra aussi être capable de bien gérer la distribution de ces tools parmis les agents pour éviter les mauvais choix et hallucinations.
Exemple , Routage d'outils via un serveur MCP
Scénario : un agent est connecté à un serveur MCP qui expose douze outils (gestion de tickets, requêtes SQL en lecture seule, envoi de notifications, etc.). Les utilisateurs rapportent que l'agent invoque parfois des outils sans rapport avec leur demande initiale.
Options :
A. Ajouter un prompt système qui liste les bons outils à utiliser par cas
B. Exposer uniquement le sous-ensemble d'outils pertinent selon le contexte de la tâche en cours, via un filtrage côté serveur MCP
C. Ajouter des exemples d'utilisation dans la description des outils
D. Fusionner tous les outils du serveur MCP en un seul outil générique
Raisonnement :
- A traite le symptôme au niveau du prompt, mais laisse les douze outils visibles en permanence : la surface d'erreur reste identique.
- C est dans la même idée que A: une proposition qui améliore surement les performances mais n'addresse pas le problème principal qui est le nombre de tools inadapté.
- D détruit la granularité utile (on perd la possibilité de distinguer une lecture SQL d'un envoi de notification côté permissions et audit).
- B réduit la surface de décision à la source, exactement comme dans l'exemple 3 : moins d'outils visibles et non pertinents dans le contexte d'une tâche donnée, c'est moins de choix erronés possibles, sans perte de granularité côté architecture globale.
Domaine 3: Claude Code Configuration & Workflows:
Dans le domaine 3, le plus important selon nous est de bien comprendre les fonctionnalités de Claude Code vis à vis de la sauvegarde du contexte. Il existe plusieurs outils (Claude.md, skills, rules…) qu’il est essentiel de savoir utiliser habilement pour ne charger dans Claude que le contexte qui concerne ce sur quoi il travaille.
Exemple , Outillage Claude Code pour une gestion fine du contexte
Scénario: Vous travaillez sur un grand monorepo où les développeurs utilisent Claude Code. L'équipe rencontre un problème : la fenêtre de contexte de Claude Code est régulièrement saturée dès le début des sessions, ce qui entraîne des coûts inutiles et réduit la capacité de raisonnement de l'agent sur des tâches complexes.
Le fichier CLAUDE.md à la racine contient plus de 1 200 lignes regroupant les commandes de build et de test globales du projet, des règles spécifiques au module React Frontend, et un guide étape par étape pour exécuter les migrations de la base de données SQL.
Quelle restructuration de la configuration devez-vous appliquer pour minimiser le contexte tout en garantissant que Claude Code accède à la bonne information au bon moment ?
Options :
A. Conserver tout le contenu dans CLAUDE.md à la racine, mais activer l'option Auto Memory (MEMORY.md) pour que Claude Code compresse automatiquement ce fichier à chaque démarrage.
B. Conserver les commandes de build globales dans CLAUDE.md, déplacer les directives Frontend dans un fichier de règle dédié (ex. .claude/rules/frontend.md), et convertir le guide de migration SQL en un skill sur-demande (ex. /migrate).
C. Découper le fichier CLAUDE.md en trois sous-fichiers dans .claude/ et les importer tous obligatoirement via des directives d'import au début du fichier CLAUDE.md principal.
D. Conserver les commandes de build globales dans CLAUDE.md, et convertir à la fois les normes Frontend et le guide de migration SQL en deux skills distincts (ex. /frontend-rules et /migrate).
Raisonnement :
A. L'Auto Memory (MEMORY.md) est un mécanisme où Claude enregistre lui-même ses apprentissages au fil des sessions. Il ne sert pas à compresser ou tronquer un fichier CLAUDE.md volumineux écrit par un humain.
C. Importer systématiquement plusieurs fichiers dans CLAUDE.md revient au même sur le plan du contexte et ne règle pas le problème.
D. Sauvegarder les bonnes pratiques et normes de code dans une skill n'est pas la bonne approche car les règles de style et conventions doivent être appliquées en continu pendant le développement, alors qu'une skill (ou commande slash) n'est chargée dans le contexte qu'au moment explicite où l'utilisateur l'invoque.
B. C'est la gestion optimale du budget de contexte dans Claude Code: le CLAUDE.md racine pour les règles globales, les règles ciblées (.claude/rules/) pour des sous-dossiers ou fichiers spécifiques (ex: frontend), et les skills pour des méthodologies ou guides de procédures complexes ou multi-étapes (comme une migration SQL).
Domain 4: Prompt Engineering & Structured Output:
Ce domaine est selon nous le plus piégeux, car choisir la technique de prompt engineering adaptée pour chaque scénario de question n’est pas instinctif. Il faudra donc bien vous entraîner à comprendre les intérêts de chaque technique de prompting (et même des techniques programmatiques comme les hooks) pour savoir utiliser la bonne au bon moment.
Exemple , Améliorer l’extraction de données
Scénario: Vous avez déployé en production un assistant conversationnel pour une plateforme de e-commerce. À la fin de chaque échange, le modèle doit renvoyer un résumé de l'interaction. Bien que le modèle comprenne le sens de la conversation et génère des synthèses de qualité, le backend rejette environ 12 % des requêtes à cause d'erreurs de format
Quelle action devez-vous privilégier pour corriger cet incident de production de la manière la plus fiable, robuste et déterministe ?
Options :
A. Donner des spécifications extrêmement détaillées dans le prompt système concernant la syntaxe JSON et le format strict de chaque champ.
B. Mettre en place du Few-Shot Prompting en ajoutant dans le prompt plusieurs exemples complets de requêtes utilisateur associées au JSON parfaitement typé attendu.
C. Utiliser un Tool Schema pour contraindre directement le modèle à respecter le schéma JSON requis.
D. Mettre en place un Hook de post-processing déterministe pour intercepter la réponse et corriger le JSON avant l'envoi au CRM.
Raisonnement :
A. Bien que des instructions claires soient indispensables à un bon prompt, définir un format de sortie de cette manière reste une approche peu fiable que le modèle peut ignorer occasionnellement.
B. Le Few-Shot Prompting est très efficace pour assurer la compréhension sémantique du modèle et spécifier globalement la forme de l'output, mais il ne garantit pas à 100 % le respect strict d'un format ou d'un typage en sortie.
D. Tenter de corriger un JSON malformé avec du code déterministe n'est pas robuste car il est pratiquement impossible de prévoir tous les cas d'erreur
C. Lorsque l'objectif est de garantir à 100 % qu'un LLM génère une structure de données selon un format très précis, la solution native et déterministe consiste à passer par un Tool Schema qui force le modèle à respecter une structure précise
Domaine 5: Context Management & Reliability:
Pour ce dernier domaine, pas de focus particulier ou d’aspects plus présents que les autres dans les questions. Nous le voyons un peu comme un ensemble de règles et bonnes pratiques (par exemple les critères d’escalade vers un humain ou comment gérer l’incertitude et documenter la provenance des sources), et si vous les retenez bien vous ne rencontrerez pas trop de difficultés pour les questions qui y sont liées.
Nos tips personnels
Tip 1, Chaque tâche de l'exam guide est une question possible. Ce n'est pas une formule creuse : si une tâche est listée, un scénario qui la mobilise directement ou indirectement peut apparaître. Ne sautez aucune ligne du guide en vous disant "ça, c'est trop niche".
Tip 2, Les distracteurs sont souvent "partiellement vrais". Le réflexe à automatiser : pour chaque option qui semble correcte, se demander explicitement "est-ce que ça résout le problème à la racine, ou juste un de ses symptômes ?". Les exemples 2 et 3 ci-dessus sont construits exactement sur ce ressort.
Tip 3, Repérez les mots-clés de l'énoncé. "Bloquant" vs "non-bloquant", "politique floue" vs "politique définie", "connu à l'avance" vs "découvert en cours d'exécution", "demande explicite du client", ces mots ne sont jamais décoratifs dans un énoncé de scénario. Ils désignent souvent, à eux seuls, le critère qui élimine deux des quatre options.
Tip 4, Méfiez-vous des garde-fous placés au mauvais niveau. Un garde-fou (validation humaine, permissions scopées, limite de nombre d'actions) qui est correct dans l'absolu peut être une mauvaise réponse s'il est positionné au mauvais endroit du pipeline, par exemple une validation humaine ajoutée après l'exécution d'une action irréversible plutôt qu'avant. La question à se poser : ce garde-fou intervient-il avant que le risque décrit dans l'énoncé se matérialise ?
Tip 5, Les pièges transversaux reviennent dans plusieurs domaines. Déterministe vs probabiliste, scope projet vs scope utilisateur, "quand" agir vs "quoi" faire : ce sont des distinctions qui reviennent sous des habillages différents dans des domaines apparemment sans rapport. Une fois qu'on les repère une fois, on les repère partout.
Tip 6, Gérez le temps comme un vrai scénario de prod. Avec 4 scénarios à traiter, il vaut mieux répondre à un jugement de premier passage sur chacun, marquer les incertains, puis revenir dessus, plutôt que de creuser un scénario à fond et se retrouver à bâcler le dernier. C'est, encore une fois, une compétence de prod : savoir quand une décision imparfaite maintenant vaut mieux qu'une décision parfaite trop tard.
Tip 7, Evitez l'over engineering. Certaines propositions améliorent sans doute la précision du système pour les questions évoquant des métriques de performances, mais sont souvent trop lourdes pour les gains apportés, d’autant plus quand d’autres propositions s’attaquent plus directement à la cause du problème bien que d’apparence très basiques.
Ce que la certif apporte concrètement
Le bénéfice le plus immédiat n'est pas le badge, c'est le vocabulaire commun que ça donne pour les discussions d'architecture en équipe. Après la préparation, des expressions comme "ce n'est pas un problème de description d'outil, c'est un problème de granularité" ou "ce garde-fou est positionné après le point de non-retour" deviennent des raccourcis partagés, au lieu de devoir ré-expliquer le raisonnement à chaque fois.
Deuxième bénéfice, plus discret mais tout aussi utile : les patterns de l'examen se reconnaissent ensuite instantanément en code review et en design doc. Un outil dont la description recouvre celle d'un autre, un garde-fou ajouté trop tard dans le pipeline, un choix "CLAUDE.md vs Skill" fait par habitude plutôt que par analyse du coût de chargement, ce sont exactement les questions qu'on a maintenant le réflexe de poser en review, parce qu'on les a vues sous forme de piège à l'examen.
Enfin, très concrètement, et ici notre situation de juniors change la nature du bénéfice : on n'avait pas de décisions d'architecture en prod à réviser après coup, contrairement à un lecteur qui a déjà des mois de production derrière lui. Ce qu'on a gagné, c'est l'inverse : un ensemble de critères déjà explicites, qu'on n'aura pas à découvrir un par un au prix d'un incident, la première fois qu'on devra vraiment trancher entre deux options qui semblent aussi raisonnables l'une que l'autre en prod.
Conclusion + ressources
La CCAF est exigeante, mais elle n'est pas arbitraire : une fois qu'on a compris qu'elle teste un raisonnement plutôt qu'un vocabulaire, les pièges deviennent prévisibles et les concepts, cohérents entre eux. Gardez à l'esprit que les modèles et les pratiques évoluent vite ; ça vaut la peine de vérifier, au moment où vous passez la certif, si une durée de validité ou une version de contenu est indiquée dans l'exam guide, pour savoir quand revisiter vos acquis.
Ressources utiles pour préparer la vôtre :
- Les modules recommandés sur https://anthropic-partners.skilljar.com/page/all-courses (MCP, subagent, skill, claude code, claude API)
- L'exam guide officiel de la CCAF, comme point de départ (syllabus, pas contenu).
- La documentation Anthropic sur docs.anthropic.com, pour creuser chaque point flou identifié pendant la révision.
Si vous avez déjà des mois de production derrière vous, vous avez la matière première : la certif vous demandera surtout de formaliser un jugement que vous exercez déjà par réflexe. Nous, on est partis sans cette matière première, et il a fallu la reconstruire scénario par scénario, plus lent, mais pas impossible. Dans les deux cas, ce qui manque le plus souvent n'est pas la connaissance des concepts, c'est l'entraînement à trancher vite entre deux réponses qui semblent toutes les deux raisonnables.
