Claude Developer Program

Programme officiel de la formation préparatoire — Sopheria Global Academy (SGA)

English version

1. Fiche programme

Séparation formation/certification. La SGA forme ; le SGCB certifie. Suivre le Claude Developer Program prépare à la certification CASD™ mais ne garantit ni ne facilite son obtention : l'évaluation certifiante (projet certifiant, soutenance orale, QCM de connaissances) est administrée de manière indépendante par le SGCB, dans les mêmes conditions pour tous les candidats.

Avis de marque. Claude et Claude Code sont des marques d'Anthropic, PBC. La SGA et le SGCB sont des entités indépendantes, non affiliées à Anthropic et non endossées par elle. La formation s'appuie sur la documentation publique d'Anthropic.

2. Pédagogie : pourquoi 5 participants et un coaching individuel

Le Claude Developer Program repose sur un parti pris pédagogique délibéré : des cohortes très réduites et un accompagnement individuel intensif, plutôt qu'un cours magistral à grande échelle.

Cohortes de 5 participants maximum. Ce plafond n'est pas un argument commercial : c'est la condition pour que chaque session de groupe de 3 heures fonctionne comme un atelier de travail, et non comme un cours descendant. Chaque participant présente régulièrement l'avancement de son projet devant la cohorte, bénéficie de la revue de code en direct de son propre code par le formateur, et apprend des choix d'architecture — et des erreurs — des quatre autres projets. À cinq, personne ne peut rester spectateur.

Deux rencontres individuelles d'une heure par semaine. Chaque participant construit un projet différent, avec sa pile technique, son domaine métier et ses contraintes propres. Les huit heures de coaching individuel du programme servent précisément à cela :

• personnalisation : le formateur adapte les concepts du référentiel CASD™ au projet réel du participant, plutôt que d'illustrer sur des exemples génériques ;
• revue de code en direct : lecture commentée du code écrit entre les sessions, identification des défauts de conception, refactorisation guidée ;
• déblocage : résolution en séance des points durs (erreurs d'API, boucles agentiques défectueuses, caches invalidés) sans laisser le participant perdre une semaine ;
• exigence : le rythme de deux rendez-vous par semaine crée une obligation de progression continue sur le projet.

Le projet comme colonne vertébrale. Il n'y a pas de labs artificiels : le terrain d'application de chaque semaine est le projet du participant lui-même. Ce projet, défini en semaine 1 et livré en fin de semaine 4, est conçu dès le départ pour respecter le cahier des charges de l'épreuve A (projet certifiant) du référentiel CASD™ — il peut donc être soumis tel quel à l'évaluation certifiante du SGCB (voir section 7).

Préparation explicite aux trois épreuves. La formation prépare aux trois épreuves de l'évaluation CASD™ — projet certifiant (60 %), soutenance orale (25 %), QCM de 30 questions (15 %) — et la semaine 4 comprend un QCM blanc en conditions réelles et une simulation de soutenance individuelle.

3. Correspondance semaines ↔ domaines du référentiel CASD™

Les six domaines et leurs objectifs d'apprentissage détaillés figurent dans le curriculum officiel CASD™ (curriculum.md).

4. Programme détaillé des 4 semaines

Semaine 1 — Fondations et cadrage du projet (Domaines 1 et 2)

Session de groupe (3 h).

• Fonctionnement d'un LLM autorégressif : tokenisation, fenêtre de contexte, limites (hallucinations, coupure de connaissances) ; famille de modèles Claude, critères de sélection (qualité, latence, coût, contexte), cycle de vie et migration ; calcul de coût par requête ; plateformes de distribution (API Anthropic, clouds partenaires) (D1) ;
• Anatomie de la Messages API : requête, réponse, blocs de contenu, usage, stop_reason ; authentification et configuration client ; streaming SSE ; conversations multi-tours ; gestion des erreurs et retries (D2) ;
• Démonstration live coding : squelette d'application avec streaming, gestion d'erreurs typée et journalisation des identifiants de requête ;
• Atelier de cadrage : chaque participant présente son idée de projet ; la cohorte et le formateur la confrontent au cahier des charges du projet certifiant CASD™.

Rencontres individuelles (2 × 1 h).

• Rencontre 1 — cadrage. Validation du périmètre du projet : cas d'usage, valeur, faisabilité en 4 semaines, couverture des six domaines exigée par le cahier des charges de l'épreuve A ; choix de la pile (Python ou TypeScript) et du modèle Claude par route.
• Rencontre 2 — première revue de code. Revue du dépôt initialisé : structure, gestion des secrets, client API avec streaming et gestion d'erreurs ; déblocage des premiers appels.

Avancement attendu du projet en fin de semaine. Dépôt Git initialisé ; document de cadrage d'une page (périmètre, architecture cible, correspondance avec les six domaines) ; intégration Messages API fonctionnelle avec streaming et gestion d'erreurs ; première estimation de coûts.

Semaine 2 — Prompts de production et boucles agentiques (Domaines 3 et 4 — 1re partie)

Session de groupe (3 h).

• Architecture d'un prompt de production : system prompt, hiérarchie des instructions, séparation canal opérateur / contenu utilisateur ; balisage XML ; few-shot ; contrôle du format de sortie et sorties structurées ; prefill et ses limites selon les générations de modèles (D3) ;
• Raisonnement : chain-of-thought, raisonnement étendu/adaptatif, réglage de l'effort, arbitrage qualité/latence/coût ; itération sur les prompts : jeux d'essai, comparaison de variantes, non-régression ; robustesse face à l'injection de prompt (D3) ;
• Du prompt à l'agent : critères de décision appel unique → workflow → agent ; boucle agentique sur la Messages API (stop_reason == "tool_use", tool_result, is_error, bornes d'itérations et budgets) ; tool runners des SDK ; conception de la surface d'outils (D4) ;
• Revue croisée en cohorte : chaque participant soumet un prompt clé de son projet à la critique du groupe.

Rencontres individuelles (2 × 1 h).

• Rencontre 1 — prompts du projet. Refonte en direct des prompts du participant : structure XML, jeu d'essai, mesure avant/après sur ses propres cas.
• Rencontre 2 — boucle agentique. Revue de code de la boucle agentique et de la définition des outils du projet ; conditions d'arrêt, gestion des erreurs d'outils, points d'approbation humaine.

Avancement attendu du projet en fin de semaine. Prompts de production versionnés avec jeu d'essai ; au moins un agent outillé fonctionnel avec boucle complète, bornes de sécurité et tests ; journal des itérations de prompts.

Semaine 3 — MCP, RAG, caching et gestion du contexte (Domaines 4 — 2e partie — et 5)

Session de groupe (3 h).

• Model Context Protocol : architecture hôte/client/serveur, primitives (tools, resources, prompts), transports ; développement d'un serveur MCP ; sécurité et authentification des serveurs ; positionnement du Claude Agent SDK et panorama des approches de construction d'agents ; orchestration multi-agents, mémoire et compaction en boucle longue (D4) ;
• Chaîne RAG de bout en bout : chunking, embeddings (fournisseurs spécialisés, Anthropic n'offrant pas d'API d'embeddings propre), bases vectorielles, recherche hybride, reranking ; arbitrage RAG vs contexte long ; citations natives pour des réponses sourcées ; évaluation de la récupération et de la fidélité (groundedness) (D5) ;
• Prompt caching : invariant du préfixe, ordre tools → system → messages, breakpoints cache_control, TTL, économie écriture/lecture, audit des invalidateurs silencieux (D5) ;
• Atelier : diagnostic collectif d'un cache défaillant et d'une récupération RAG de mauvaise qualité sur des cas apportés par les participants.

Rencontres individuelles (2 × 1 h).

• Rencontre 1 — capacités du projet. Selon le projet : développement du serveur MCP du participant, ou conception de sa chaîne RAG/contexte long avec citations ; revue de code en direct.
• Rencontre 2 — optimisation. Audit du caching sur le projet réel (preuve par les champs usage), stratégie de coûts par route, gestion du contexte en conversation ou boucle longue.

Avancement attendu du projet en fin de semaine. Toutes les composantes techniques exigées par le cahier des charges en place : outil exposé via MCP, composante RAG ou contexte long avec réponses sourcées, prompt caching mesuré avec analyse de coûts. Le projet est fonctionnel de bout en bout ; il reste à le durcir et le documenter.

Semaine 4 — Production, déontologie et préparation aux trois épreuves (Domaine 6 et révision D1–D6)

Session de groupe (3 h).

• Durcissement production : gestion des secrets, défense en profondeur contre l'injection (validation déterministe, allowlists, confirmation humaine, sandboxing), garde-fous et modération, gestion des refus et stratégies de repli, résilience (retries, backoff, dégradation gracieuse) (D6) ;
• Évaluation et observabilité : jeux d'évals, LLM-as-judge et ses limites, non-régression ; journalisation structurée, traces, métriques, alertes (D6) ;
• Usage responsable : politique d'usage du fournisseur, données personnelles (minimisation, RGPD), transparence, supervision humaine, biais, documentation des limites (D6) ;
• QCM blanc en conditions réelles (30 questions, 60 minutes, format SGCB) suivi d'une correction commentée avec diagnostic par domaine ;
• Revue transversale des six domaines : erreurs fréquentes des candidats, lecture guidée des grilles publiques d'évaluation du SGCB.

Rencontres individuelles (2 × 1 h).

• Rencontre 1 — finalisation. Revue finale du projet au regard du cahier des charges de l'épreuve A : dépôt de code, README, rapport technique (10–15 pages), démonstration vidéo (≤ 10 min) ; note d'analyse déontologique ; plan d'action sur les écarts résiduels.
• Rencontre 2 — simulation de soutenance. Soutenance blanche individuelle de 30 minutes au format SGCB : démonstration live, questions techniques, questions de vérification de paternité ; débriefing et plan de révision personnalisé pour le QCM.

Avancement attendu du projet en fin de semaine. Projet complet et durci : évals automatisées, observabilité, garde-fous, analyse déontologique ; livrables au format du projet certifiant (dépôt, README, rapport technique, vidéo) prêts à être soumis au SGCB si le participant s'inscrit à l'évaluation.

5. Livrables hebdomadaires

Les livrables sont revus par le formateur lors des rencontres individuelles. La SGA délivre une attestation de suivi aux participants ayant assisté aux sessions et remis les livrables des quatre semaines. Cette attestation atteste du suivi de la formation ; elle est sans effet sur l'évaluation certifiante CASD™ et ne confère aucun titre.

6. Prérequis techniques

• 2 ans minimum de développement logiciel professionnel ;
• maîtrise de Python 3.11+ ou TypeScript/Node.js 20+ (l'accompagnement est assuré dans les deux langages) ;
• aisance avec Git, la ligne de commande, HTTP/REST et JSON ;
• poste de développement personnel et clé d'API Anthropic propre (le participant supporte ses coûts d'API, généralement modestes à l'échelle d'un projet de formation ; le formateur aide à les budgéter dès la semaine 1) ;
• une idée de projet à construire — affinée et validée en semaine 1 ;
• recommandé : certification AIPE™ (AI Prompt Engineer) ou expérience équivalente en conception de prompts.

Un entretien de positionnement (30 min) précède l'inscription : il vérifie les prérequis et la viabilité de l'idée de projet, afin de garantir l'homogénéité de la cohorte.

7. Articulation formation SGA / certification SGCB

La séparation entre la formation et la certification est stricte et structurelle :

• La SGA forme. Elle conçoit et anime le Claude Developer Program, encadre le projet du participant et délivre une attestation de suivi.
• Le SGCB certifie. Il administre seul les trois épreuves de l'évaluation CASD™ — projet certifiant (60 %), soutenance orale (25 %), QCM de 30 questions (15 %) — selon le référentiel d'évaluation public (exam-blueprint.md).
• Le capstone peut devenir le projet certifiant. Le projet construit pendant la formation est aligné dès la semaine 1 sur le cahier des charges de l'épreuve A ; le participant qui s'inscrit à l'évaluation CASD™ peut le soumettre tel quel. Il est alors évalué de manière indépendante par deux évaluateurs du SGCB sur la grille publique — jamais par le formateur du candidat. Aucune note, appréciation ou recommandation issue de la formation n'est transmise au SGCB ni prise en compte dans la décision de certification.
• Aucun avantage certifiant. La réussite de la formation ne confère ni dispense, ni bonus, ni voie accélérée : l'évaluation certifiante est identique pour tous les candidats, qu'ils aient suivi le programme, un autre parcours ou une auto-préparation.
• Inscription distincte. L'inscription à l'évaluation CASD™ s'effectue séparément, auprès du SGCB, aux tarifs et conditions publiés par celui-ci.

8. Modalités pratiques

© Sopheria Global Institute of Technology — Sopheria Global Academy. « Scientia. Integritas. Futurum. » Claude et Claude Code sont des marques d'Anthropic, PBC. La SGA et le SGCB sont des organismes indépendants, non affiliés à Anthropic.