Exercices — Niveau Avancé, Session 10
« Examen blanc & projet final »
Programme : Applied AI — Yann Isola Contenu : grille d’évaluation détaillée du projet final (/100) + 3 mini-défis d’architecture pour l’échauffement Usage : les mini-défis se font en ouverture de séance ou en révision individuelle (10 min chacun) ; la grille sert aux soutenances du bloc 3 et à l’auto-évaluation en amont.
⚠ Les chiffres d’examen (60 questions, 90 min, seuil 72 %, pondérations) et les tarifs/limites d’API cités sont volatils : vérifier les sources officielles Anthropic.
Partie 1 — Le projet final : cadre et grille d’évaluation
Le livrable attendu
Chaque participant présente l’architecture complète d’un système IA répondant à un problème réel — idéalement issu de son contexte professionnel — conçue et raffinée au fil des sessions 4 à 9. Le livrable comprend :
- Un dossier d’architecture (4–8 pages ou équivalent slides) remis avant la séance.
- Une soutenance de 4 minutes + 2 minutes de questions.
- Un schéma d’architecture obligatoire (flux, composants, points de contrôle humain).
Les quatre familles de projets travaillées dans le parcours sont des bases valables (à personnaliser) :
- Système de support client multi-agents (routage, spécialistes, escalade humaine)
- Serveur MCP (MCP = Model Context Protocol) pour un domaine métier avec outils, ressources et prompts
- Intégration Claude Code dans le pipeline CI/CD (CI/CD = intégration et déploiement continus) d’une équipe
- Pipeline de traitement documentaire avec harnais d’évaluation complet
Grille d’évaluation — /100
Critère 1 — Problème & cadrage métier (15 points)
| Niveau | Points | Descripteur |
|---|---|---|
| Excellent | 13–15 | Problème réel, chiffré (volume, coût actuel, enjeu) ; périmètre explicite avec ce qui est exclu et pourquoi ; critères de succès mesurables définis avant l’architecture. |
| Solide | 9–12 | Problème réel et clair ; périmètre défini ; critères de succès présents mais partiellement mesurables. |
| Fragile | 5–8 | Problème plausible mais non chiffré ; périmètre flou ; succès défini comme « ça marche ». |
| Insuffisant | 0–4 | Problème artificiel ou prétexte ; aucune notion de périmètre ni de mesure. |
Question du jury associée : « Comment sauras-tu, chiffres à l’appui, que le système vaut son coût ? »
Critère 2 — Architecture & justification des choix (30 points)
Le cœur de la note. On évalue la justesse du niveau de complexité autant que la conception elle-même.
| Sous-critère | Points | Ce qu’on vérifie |
|---|---|---|
| 2a. Niveau de complexité justifié | 10 | Chaque étage (appel simple → chaîne → agent → multi-agents) est justifié par une insuffisance démontrée de l’étage inférieur. La sur-ingénierie est pénalisée au même titre que la sous-ingénierie. |
| 2b. Découpage & responsabilités | 8 | Composants à responsabilité unique ; frontières nettes ; contextes isolés là où c’est utile ; le schéma correspond au discours. |
| 2c. Choix de modèles & routage | 6 | Modèle rapide/économique pour les tâches fermées, modèle puissant où le raisonnement le justifie ; le routage des requêtes est explicite. |
| 2d. Gestion de l’état & des sessions | 6 | État durable hors contexte (l’API est sans état) ; stratégie de reprise ; compaction prévue pour les sessions longues. |
Questions du jury associées : « Pourquoi pas un simple workflow ici ? » · « Qu’est-ce qui casse si tu doubles le volume ? »
Critère 3 — Conception des outils & intégrations (15 points)
| Niveau | Points | Descripteur |
|---|---|---|
| Excellent | 13–15 | Outils orientés tâche (pas calqués sur l’API interne) ; descriptions avec périmètre ET contre-indications ; erreurs d’outils retournées comme données actionnables ; si MCP : primitives (outils/ressources/prompts) correctement affectées, transport justifié. |
| Solide | 9–12 | Outils cohérents, schémas corrects ; descriptions honnêtes mais sans contre-indications ; gestion d’erreur présente. |
| Fragile | 5–8 | Granularité calquée sur l’API existante (trop fine ou trop grosse) ; descriptions vagues ; erreurs = exceptions techniques. |
| Insuffisant | 0–4 | Outils « fourre-tout » ou accès brut (SQL/shell) sans garde-fou ; aucune réflexion sur la sélection d’outils. |
Critère 4 — Fiabilité, sécurité & supervision humaine (20 points)
| Sous-critère | Points | Ce qu’on vérifie |
|---|---|---|
| 4a. Consigne vs garantie | 6 | Tout ce qui est critique (validation de sortie, permissions, limites d’action) est appliqué par du code, pas seulement demandé dans un prompt. La confusion consigne/garantie est éliminatoire de l’excellence. |
| 4b. Humain dans la boucle | 5 | Point d’approbation placé au point de non-retour, proportionné au risque (seuils) ; ni approbation-partout (système inutilisable), ni autonomie totale sur l’irréversible. |
| 4c. Modes de panne | 5 | Réponse aux questions : que se passe-t-il si un outil échoue ? si l’API renvoie 429/529 ? si le modèle hallucine ? Dégradation gracieuse décrite, pas seulement « on gère les erreurs ». |
| 4d. Surface d’attaque | 4 | Injection de prompt via contenus externes envisagée ; données sensibles (PII = données personnelles identifiantes) minimisées dans les contextes et les journaux. |
Drapeau rouge (à sanctionner) : « le modèle est intelligent, il gérera. »
Critère 5 — Coûts, évaluation & exploitation (10 points)
| Niveau | Points | Descripteur |
|---|---|---|
| Excellent | 9–10 | Estimation de coût par requête et par mois au volume cible ⚠ ; cache de prompt exploité (contenu stable en tête) ; harnais d’évaluation défini (golden set, métriques, déclenchement) ; journalisation de provenance (version de prompt, modèle, outils appelés). |
| Solide | 6–8 | Ordres de grandeur de coût présents ; évaluation prévue mais sommaire ; journalisation évoquée. |
| Fragile | 3–5 | Coûts « à voir plus tard » ; pas d’éval automatisée ; logs = logs applicatifs génériques. |
| Insuffisant | 0–2 | Aucune notion de coût, d’éval ni de traçabilité. |
Critère 6 — Clarté de la soutenance (10 points)
| Niveau | Points | Descripteur |
|---|---|---|
| Excellent | 9–10 | Tient les 4 minutes ; schéma lisible et exploité ; hiérarchise (l’essentiel d’abord) ; répond aux questions en assumant les limites (« non couvert, et voici pourquoi c’est acceptable »). |
| Solide | 6–8 | Structure claire, léger dépassement ; répond aux questions honnêtement. |
| Fragile | 3–5 | Déborde nettement ; lit ses slides ; élude les questions difficiles. |
| Insuffisant | 0–2 | Confus, sans schéma, réponses défensives ou fabulées. |
Barème global
| Total | Verdict |
|---|---|
| 85–100 | Niveau architecte confirmé — le dossier pourrait être présenté à un comité d’architecture réel. |
| 70–84 | Solide — quelques angles morts identifiés, corrigés en une itération. |
| 50–69 | Fondations en place — retravailler les critères < 60 % avant tout usage en production. |
| < 50 | Reprendre la conception avec l’appui des guides des sessions 4 à 8. |
Modalité de notation en séance : évaluation croisée (2 pairs par projet) + note du formateur ; note indicative = moyenne des trois. L’écart entre auto-évaluation préalable et note reçue est en soi un enseignement — le sous-estimé chronique et le sur-confiant chronique ont tous deux un biais à corriger avant l’examen.
Partie 2 — Trois mini-défis d’architecture (échauffement)
Format : 10 minutes par défi, seul ou en binôme. Produire : (1) un choix d’architecture en une phrase, (2) trois justifications, (3) le principal risque résiduel. Puis comparer au corrigé.
Défi A — « Le triage des sinistres »
Énoncé. Un assureur reçoit 30 000 déclarations de sinistre par jour (formulaire libre + photos). Il faut : classifier le type de sinistre (7 catégories), estimer l’urgence (3 niveaux), extraire les champs clés en JSON, et transmettre les cas « urgence maximale + montant estimé > 10 k€ » à un gestionnaire humain. Latence cible : < 5 s. L’équipe propose un système multi-agents avec un orchestrateur et sept agents spécialisés (un par catégorie de sinistre).
Question. Valider ou contre-proposer, en justifiant.
Corrigé
Contre-proposition : pas de multi-agents. C’est un pipeline à étapes fixes — le chemin est connu d’avance (classifier → estimer → extraire → router), rien ne dépend de découvertes intermédiaires.
Architecture cible : un seul appel multimodal (texte + photos) avec sortie structurée forcée par schéma d’outil (catégorie en énumération, urgence, champs extraits, montant estimé) sur un modèle rapide ; puis règle programmatique (pas un prompt !) pour l’escalade « urgence max + > 10 k€ → file humaine ». Éventuellement un second appel de vérification sur les seuls cas escaladés (faible volume, enjeu élevé).
Justifications : (1) volume élevé + tâche fermée → latence et coût dominent, un appel suffit ; (2) l’escalade est un seuil critique → garantie par code, jamais par consigne ; (3) le schéma force la structure → le pipeline aval ne casse pas.
Risque résiduel : les cas ambigus entre catégories — se traite par few-shot de cas limites + éval sur golden set, pas par des agents supplémentaires.
Piège évité : « 7 catégories = 7 agents » — la taxonomie métier ne dicte pas la topologie du système.
Défi B — « L’assistant d’investigation »
Énoncé. Une équipe SRE (SRE = Site Reliability Engineering, ingénierie de fiabilité des systèmes) veut un assistant qui, sur incident, explore de lui-même : logs, métriques, changements récents (déploiements, PR fusionnées), et propose un diagnostic avec les preuves. Les causes sont par nature imprévisibles. L’assistant a accès en lecture aux systèmes d’observabilité et au dépôt Git. L’équipe hésite : workflow scripté ou agent autonome ? Et faut-il lui donner le droit de redémarrer les services ?
Question. Trancher les deux points, avec les garde-fous.
Corrigé
Point 1 : agent. Cas d’école — chaque indice détermine la prochaine investigation, le chemin est inconnaissable d’avance. Un workflow scripté ne couvrirait que les pannes déjà vues. Garde-fous d’agent : budget d’itérations plafonné, compaction du contexte pour les investigations longues, outils de lecture seule avec descriptions incluant les contre-indications, obligation de citer les preuves (extraits de logs, identifiants de déploiements) — la citation vérifiable est l’anti-hallucination du diagnostic.
Point 2 : non au redémarrage autonome — mais oui au redémarrage proposé. Le redémarrage est une action à effet de bord sur la production : point de non-retour → approbation humaine. Conception : l’agent produit une proposition structurée (action, cible, justification, risque), un humain approuve en un clic, l’exécution est faite par le système avec journalisation complète. La frontière lecture/écriture est appliquée par les permissions (garantie), pas par le prompt (consigne).
Risque résiduel : l’injection via les logs eux-mêmes (un attaquant peut écrire dans les logs des instructions déguisées) → traiter tout contenu de log comme donnée non fiable, jamais comme instruction.
Défi C — « Le savoir de l’équipe dans Claude Code »
Énoncé. Une équipe de 15 développeurs adopte Claude Code sur un monorepo (monorepo = dépôt unique contenant plusieurs projets). Constats après 3 semaines : l’agent propose des commandes de build fausses, ignore les conventions de l’équipe, et un incident a eu lieu — un développeur a laissé l’agent exécuter une migration de base sur l’environnement de staging sans relecture. Proposer le dispositif de gouvernance complet.
Question. Quels fichiers, quels mécanismes, quelle répartition consigne/garantie ?
Corrigé
Trois couches :
CLAUDE.mdversionné à la racine (+ par sous-projet du monorepo) — la consigne permanente : commandes de build/test exactes par sous-projet, conventions de code, architecture des dossiers, pièges connus. Court et dense : chargé à chaque session, chaque ligne coûte des tokens. Revu en revue de code comme n’importe quel fichier..claude/settings.jsonversionné — la garantie partagée : allowlist des commandes toujours autorisées (tests, lint, build), approbation obligatoire pour le reste, interdiction explicite des commandes de migration et de tout ce qui touche staging/production. C’est ce qui aurait empêché l’incident — unCLAUDE.mddisant « ne pas migrer sans relecture » ne l’aurait pas empêché (consigne contournable/oubliable)..claude/commands/— les rituels à la demande :/revue-pr,/notes-version,/verif-migration(qui prépare et vérifie une migration sans l’exécuter). Chargés seulement à l’appel : zéro coût permanent.
Compléments : mode plan par défaut recommandé pour tout changement multi-fichiers ; revue automatique headless en CI (claude -p … --output-format json ⚠, lecture seule) ; l’incident devient un post-mortem qui alimente CLAUDE.md (piège connu) ET settings.json (interdiction).
Répartition à retenir : ce que l’agent doit savoir → CLAUDE.md ; ce que l’agent ne doit pas pouvoir → settings.json ; ce qu’on lui demande parfois → commandes slash.
Après les défis
Reporter vos trois auto-diagnostics dans le tableau de bord de préparation (page web, onglet « Préparation ») : chaque défi couvre respectivement les domaines D1+D4 (défi A), D1+D2+D5 (défi B), D3 (défi C). Un défi raté avec le corrigé incompris = zone rouge sur les domaines associés, quelle que soit votre impression générale.