Exercices — Niveau Avancé, Session 8

« Contexte, fiabilité & provenance »

Programme : Applied AI — Yann Isola Public : Architectes solutions — préparation Claude Certified Architect Durée totale estimée : 3 h 30 à 4 h 30 (individuel ou binôme) Prérequis : clé API Anthropic, Python 3.10+, SDK (SDK = Software Development Kit) anthropic, la session 8 suivie, la page web interactive de la session pour vérifier vos calculs.

⚠ Tous les chiffres de tarification, tailles de fenêtres, quotas et SLA (SLA = Service Level Agreement, engagement de niveau de service) utilisés ci-dessous sont volatils. Notez systématiquement la date et la source de la grille tarifaire que vous utilisez — c’est même une exigence explicite de l’exercice 1.

Exercice 1 — Calculateur de budget de contexte (60-75 min)

Contexte

Votre équipe déploie « ComplianceScan », l’agent d’investigation de conformité vu en session. Avant toute ligne de code d’agent, l’architecte que vous êtes doit répondre à trois questions : combien de tours l’agent peut-il tenir ? combien coûte une investigation ? quelle stratégie de contexte s’impose ? Vous allez construire l’outil qui répond — un calculateur de budget de contexte réutilisable.

Données d’entrée (profil de charge)

Poste	Valeur
Fenêtre de contexte du modèle	200 000 tokens ⚠
Prompt système + politique de conformité	3 200 tokens
Définitions d’outils (12 outils)	4 100 tokens
Tour utilisateur/agent moyen (question + raisonnement + appel d’outil)	800 tokens
Résultat d’outil brut moyen	2 500 tokens
Résultat d’outil filtré par hook PostToolUse	400 tokens
Réserve de sortie (`max_tokens`)	8 000 tokens
Investigation type	150 tours, 1 appel d’outil par tour

Travail demandé

Modèle de calcul. Écrivez un module Python context_budget.py avec une fonction simulate(profile, strategy) -> Report qui simule tour par tour la taille du contexte et retourne : le tour de saturation (ou None), le total de tokens d’entrée facturés cumulés sur l’investigation (rappel : à chaque tour, tout le contexte est renvoyé et refacturé), et la répartition finale par poste (système / outils / historique / résultats d’outils).
Scénario A — brut, sans stratégie. Résultats d’outils bruts, aucun filtrage, aucune compression. À quel tour l’agent sature-t-il ? L’investigation de 150 tours est-elle possible ?
Scénario B — hook PostToolUse. Résultats filtrés (400 tokens au lieu de 2 500). Nouveau tour de saturation ? Facteur de gain ?
Scénario C — hybride (hook + résumé + fenêtre glissante). En plus du filtrage : tous les 30 tours, les tours au-delà des 10 derniers sont compressés en un résumé de 1 500 tokens (le résumé précédent est absorbé dans le nouveau). Modélisez aussi le coût de l’appel de compression lui-même. L’investigation de 150 tours passe-t-elle ? Avec quelle marge ?
Chiffrage économique. Pour chaque scénario faisable, calculez le coût d’une investigation complète, puis de 200 investigations/jour, en utilisant la grille tarifaire officielle du jour (datez et sourcez ⚠). Bonus : ajoutez la variante « prompt système + définitions d’outils en cache » et quantifiez l’économie.
Note d’architecture (1 page max). Votre recommandation : quelle stratégie, quels seuils (palier de compression, taille de fenêtre verbatim, plafonds du hook), quels risques résiduels (que perd-on dans les résumés ? comment le scratchpad compense-t-il ?).

Critères de réussite

Le simulateur est paramétrique (aucune constante en dur dans la logique).
Le scénario A démontre chiffres à l’appui l’impossibilité des 150 tours.
Le coût des appels de compression du scénario C est compté (l’oublier est l’erreur classique).
Les tarifs utilisés sont datés et sourcés.
La note d’architecture arbitre explicitement coût / capacité / risque de perte d’information.

Pour aller plus loin

Comparez vos estimations heuristiques (~4 caractères/token en anglais, ratio différent en français) avec l’endpoint officiel de comptage de tokens sur 5 messages réels. Quel écart ? Quelle marge de sécurité en déduisez-vous pour votre simulateur ?

Exercice 2 — Conception d’une chaîne de provenance (75-90 min)

Contexte

L’équipe conformité accepte de déployer ComplianceScan à une condition posée par l’audit interne : « Pour tout rapport généré, nous devons pouvoir remonter de chaque affirmation jusqu’à sa source primaire, reconstituer ce que le modèle a vu, et savoir quelle version du système a produit quoi. » Vous concevez et prototypez la chaîne de provenance complète.

Travail demandé

Schéma de sortie avec attribution. Définissez un schéma JSON (JSON = JavaScript Object Notation) de rapport où chaque finding porte : l’affirmation, un pointeur de source résoluble (tool, call_id, record_id(s)), un niveau de confiance (établi / à vérifier / inféré), et où l’enveloppe porte : prompt_version (hash + identifiant sémantique), identifiant de modèle complet, température, horodatage, identifiant de corrélation d’investigation.
Prompt de génération. Écrivez le prompt (système + structure XML d’injection séparant <contexte_systeme>, <donnees>, <instructions>) qui contraint le modèle à produire ce schéma, avec la règle explicite : aucune affirmation sans pointeur de source ; en l’absence de source, l’affirmation passe en inféré avec justification.
Journal d’audit. Implémentez un AuditLog (fichiers JSON dans une arborescence audit/<date>/<investigation_id>/) qui journalise : prompt système (avec hash), chaque message, chaque appel d’outil — arguments, résultat brut, résultat filtré entré au contexte (le triplet args/raw/ctx), et le manifeste final (modèle, version, paramètres, hashes).
Vérificateur de citations. Écrivez verify_provenance(report, audit_log) -> VerificationResult qui, pour chaque finding : (a) vérifie que le call_id existe dans le journal ; (b) vérifie que les record_id cités apparaissent bien dans le résultat brut de cet appel ; © signale toute citation orpheline. Testez-le en corrompant volontairement un rapport (inventez un record_id plausible — simulez l’hallucination de citation) et vérifiez que le contrôle le détecte.
Scénario d’audit à blanc. En binôme : l’un joue l’auditeur et choisit une affirmation au hasard dans un rapport généré ; l’autre doit, en moins de 5 minutes et uniquement avec le journal, produire : la source primaire, ce que le modèle a réellement vu (ctx vs raw), et la version du prompt. Documentez ce qui a manqué ou ralenti.
Question de fond (10 lignes). Votre direction demande : « Peut-on garantir la regénération à l’identique d’un rapport pour prouver son origine ? » Rédigez la réponse honnête de l’architecte : ce que température 0 + version épinglée + seed ⚠ garantissent, ce qu’ils ne garantissent pas (« déterministe-ish »), et pourquoi le journal d’audit — pas la regénération — est la véritable garantie de conformité.

Critères de réussite

Le schéma distingue provenance des données (sources) et provenance du générateur (prompt, modèle, paramètres).
Le vérificateur détecte la citation hallucinée du test de corruption.
Le journal permet de répondre « qu’a vu le modèle exactement ? » (ctx ≠ raw).
L’audit à blanc aboutit en < 5 min.
La réponse sur la reproductibilité ne sur-promet pas.

Pour aller plus loin

Ajoutez un chaînage d’intégrité : chaque entrée du journal inclut le hash de l’entrée précédente (chaîne de hachage). Que gagne-t-on face à un auditeur ? Que ne prouve-t-on toujours pas ?

Exercice 3 — Pipeline de traitement batch (60-90 min)

Contexte

Nouvelle politique de conformité v3.3 : les 80 000 dossiers clients doivent être re-notés cette semaine. Appels synchrones = trop lent, trop cher, rate limits. Vous construisez le pipeline complet sur la Message Batches API : soumission, suivi, dépouillement, reprise sur erreur — avec optimisation batch + cache et chiffrage à l’appui.

(Pour l’exercice, travaillez sur 200 dossiers synthétiques ; le code doit être dimensionné pour 80 000.)

Travail demandé

Génération du jeu. Script make_dossiers.py : 200 dossiers synthétiques JSON (id, pays, activité déclarée, liste de transactions, drapeaux divers) — dont ~10 volontairement malformés (champ manquant, encodage douteux) pour tester la robustesse aval.
Soumission. Script submit_batch.py :
- construit les requêtes avec un custom_id robuste (convention à documenter : p. ex. v33-{dossier_id}-{hash_court_du_contenu} — justifiez chaque composant) ;
- place la politique de conformité (bloc système long et identique) en cache (cache_control) ;
- découpe en lots si nécessaire (limite de 100 000 requêtes/batch ⚠ — votre code doit gérer le découpage même si le jeu de test tient en un lot) ;
- persiste localement le manifeste de soumission : batch_id, liste des custom_id, horodatage, version de prompt (provenance !).
Suivi. Script poll_batch.py : interroge le statut à intervalle raisonnable (backoff progressif, pas de boucle serrée), journalise les transitions in_progress → ended.
Dépouillement et reprise. Script collect_results.py :
- dépouille les résultats en rattachant chaque résultat à son dossier via custom_id (rappel : l’ordre n’est pas garanti) ;
- route par type : succeeded → base de résultats ; errored → file de retry avec le détail d’erreur ; expired / canceled → file de re-soumission ;
- est idempotent : relançable après plantage à mi-course sans double-traitement (justifiez le mécanisme — marqueurs de progression, upsert par custom_id…) ;
- produit un rapport de complétude : soumis / réussis / échoués / manquants, avec la liste nominative des manquants.
Chiffrage comparatif. Avec la grille tarifaire du jour (datée, sourcée ⚠), calculez pour 80 000 dossiers (système partagé 3 200 tokens, entrée variable ~900 tokens, sortie ~350 tokens) le coût dans 4 configurations : synchrone sans cache / synchrone + cache / batch sans cache / batch + cache. Présentez le tableau et le facteur d’économie total. Vérifiez vos ordres de grandeur avec le calculateur de la page web de la session.
Note d’exploitation (½ page). SLA 24 h ⚠ : quelles conséquences sur la planification (fenêtre de nuit, marge, criticité) ? Que se passe-t-il si 3 % des requêtes expirent ? Quel est votre critère de « campagne terminée » ?

Critères de réussite

La convention de custom_id est documentée et permet corrélation + idempotence + audit.
Le dépouillement traite les 4 statuts terminaux et survit aux 10 dossiers malformés.
collect_results.py relancé deux fois de suite ne double-traite rien.
Le chiffrage montre le cumul batch + cache, tarifs datés et sourcés.
Le rapport de complétude désigne nominativement tout dossier manquant.

Pour aller plus loin

Branchez la sortie de l’exercice 2 : chaque résultat de batch alimente le journal d’audit et le schéma de provenance. Un custom_id devient alors le fil qui relie dossier → requête → réponse → rapport → audit. C’est exactement l’architecture attendue d’un Claude Certified Architect : les trois briques de la session n’en font qu’une.

Barème indicatif (si évaluation notée)

Exercice	Points	Dont
1 — Budget de contexte	30	Simulateur 12, scénarios 10, note d’architecture 8
2 — Chaîne de provenance	40	Schéma 8, journal 10, vérificateur 12, audit à blanc 5, reproductibilité 5
3 — Pipeline batch	30	Soumission 8, dépouillement/reprise 12, chiffrage 6, exploitation 4

Seuil de validation : 60/100. La détection de la citation hallucinée (ex. 2.4) et l’idempotence du dépouillement (ex. 3.4) sont éliminatoires si absentes : ce sont les deux réflexes non négociables du métier.