# 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 :
1. **Un dossier d'architecture** (4–8 pages ou équivalent slides) remis avant la séance.
2. **Une soutenance de 4 minutes** + 2 minutes de questions.
3. **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 :**
1. **`CLAUDE.md` versionné à 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.
2. **`.claude/settings.json` versionné** — 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 — un `CLAUDE.md` disant « ne pas migrer sans relecture » ne l'aurait *pas* empêché (consigne contournable/oubliable).
3. **`.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.