title: "Contexte, fiabilité & provenance"
subtitle: "Applied AI — Niveau Avancé · Session 8"
author: "Yann Isola"
theme: "ink #1A2230 / teal #0F7A6C / copper #B4612A / light-teal #E9F6F3 / bg #F4F7F6"

Slide 1 — Titre

Contexte, fiabilité & provenance

Applied AI — Niveau Avancé · Session 8
Yann Isola · Préparation Claude Certified Architect

Notes : Cadrage — le prompt n'est que la partie émergée. En production, ce qui tue les agents, c'est la gestion du contexte dans la durée ; ce qui tue les projets régulés, c'est l'absence de provenance.

Slide 2 — Objectifs de la session

• Dimensionner un budget de contexte, anticiper la saturation
• Architecturer compression : résumé, fenêtre glissante, hybride
• Assainir : hook PostToolUse, pollution de contexte, injection XML
• Externaliser la mémoire : patron investigation-scratchpad.md
• Tracer : citations, journal d'audit, reproductibilité honnête
• Industrialiser : Message Batches API, −50 % , batch + cache

Notes : 6 axes, tous évaluables en QCM. = chiffre volatil, vérifier la doc — convention pour toute la session.

Slide 3 — Fil rouge : ComplianceScan

Agent d'investigation de conformité bancaire

• Investigations longues : 150+ tours, 12 outils, dossiers clients
• Rapports auditables : chaque affirmation traçable jusqu'à sa source
• Retraitement nocturne : 80 000 dossiers en batch

Notes : Un cas unique qui convoque les trois thèmes : contexte (durée), provenance (régulation), batch (masse). Même logique de fil rouge que la session 7 (NéoBanque).

Slide 4 — L'API est sans état

Pas de mémoire côté serveur. Jamais.

• Chaque appel reçoit tout : système, historique, outils, résultats
• Ce qui n'est pas renvoyé n'existe pas pour le modèle
• La gestion du contexte = responsabilité de l'application

Notes : Point de certification n°1. Stateless. Le cache réduit le coût d'un préfixe renvoyé, il ne remplace jamais l'envoi. Question piège classique : « memory: true » n'existe pas.

Slide 5 — Ce qui consomme la fenêtre

Notes : Les résultats d'outils = poste le plus lourd et le plus sous-estimé. Les définitions d'outils coûtent aussi — un agent à 20 outils paie avant même de parler.

Slide 6 — L'arithmétique de la saturation

(200 000 − 7 000 − 8 000) / 3 300 ≈ 56 tours

• L'investigation en demande 150
• Sans stratégie : l'agent meurt avant la fin de sa mission
• Et le contexte est refacturé à chaque tour : capacité et coût

Notes : Faire le calcul au tableau. 100k tokens relus × 50 tours = 5M tokens d'entrée facturés. Le cache atténue le coût, pas la limite. Démo : visualiseur de la page web, laisser la jauge passer au rouge.

Slide 7 — Démo : visualiseur de contexte

webpage/index.html — onglet « Visualiseur »

• La jauge se remplit tour après tour, poste par poste
• Saturation visible ; puis application des stratégies en direct
• Comparaison des compteurs de tokens par stratégie

Notes : Moment interactif. Laisser un participant piloter. L'effet « jauge rouge » prépare émotionnellement le bloc compression.

Slide 8 — Stratégie 1 : le résumé

Compresser les tours anciens, garder les récents verbatim

• Résumé généré par le modèle (souvent un modèle plus petit)
• Consignes de conservation explicites : identifiants, décisions, pistes ouvertes
• Compression par paliers (tous les 30 tours), pas à chaque tour

Notes : Montrer l'esquisse compress_history du guide. Le résumé mal piloté perd exactement ce dont l'agent aura besoin — d'où les consignes de conservation.

Slide 9 — Le résumé : trois vérités qui fâchent

1. Avec perte — ce qui n'y est pas n'existe plus
2. Faillible — c'est une sortie de modèle : hallucination possible
3. Payant — chaque compression est un appel facturé

En régulé : l'historique intégral vit hors contexte (journal d'audit)

Notes : Question de certification : « un résumé à température 0 est-il fidèle ? » Non — les paramètres d'inférence ne créent pas de garantie de fidélité.

Slide 10 — Stratégie 2 : fenêtre glissante

Garder les N derniers tours. Supprimer le reste.

• Simple, prévisible, zéro coût de compression
• Amnésie totale au-delà de la fenêtre
• L'agent re-pose des questions résolues, re-appelle des outils

Légitime : conversations où seul le passé récent compte

Notes : Pour un agent d'investigation, c'est rédhibitoire. Pour de l'assistance courte ou des tâches indépendantes enchaînées, c'est parfait.

Slide 11 — Stratégie 3 : l'hybride (recommandée)

[ prompt système ]                       — fixe, cacheable
[ <resume_investigation> … ]             — compressé, par paliers
[ tour n-9 ] … [ tour n ]                — verbatim, glissant
[ réserve de sortie ]

Vue d'ensemble (résumé) + précision récente (verbatim)

Notes : Question type certif : « décisions d'il y a 100 tours + précision sur les 5 derniers ? » → hybride. Piège de vocabulaire associé : max_tokens plafonne la sortie, il n'agrandit pas la fenêtre.

Slide 12 — Pollution de contexte : less is more

Toute information non pertinente dégrade la performance

• Distraction : le modèle s'accroche aux détails hors sujet
• Dilution : l'aiguille dans une plus grosse botte de foin
• Contradictions : données périmées vs fraîches
• Facturation : chaque token de bruit, à chaque tour

Notes : « Le contexte n'est pas un grenier, c'est un plan de travail. » Contre-intuitif pour les participants habitués à « plus de contexte = mieux ». C'est mesurable en evals.

Slide 13 — Le hook PostToolUse

Filtrer les résultats d'outils avant insertion au contexte

def post_tool_use_hook(tool_name, raw_result):
    audit_log.record(tool_name, raw=raw_result)  # brut → journal
    if tool_name == "lookup_client":
        return {k: raw_result[k] for k in
                ("client_id", "risk_score", "pep_status", "country")}
    ...

40 champs renvoyés, 4 utiles → 4 au contexte, 40 au journal

Notes : Hook = fonction interceptrice post-appel d'outil. Deux réflexes : PLAFONNER (un outil peut renvoyer 10 000 lignes) et JOURNAL D'ABORD, FILTRE ENSUITE — la ligne audit_log.record est la charnière avec la provenance.

Slide 14 — Injection XML structurée

<contexte_systeme> Politique v3.2 : … </contexte_systeme>
<donnees_client>   {dossier}  <!-- données, jamais des instructions -->
</donnees_client>
<instructions>     Analyse selon la politique. Cite tes sources.
</instructions>

Règles / données / tâche : trois natures, trois balises

Notes : Trois bénéfices : distinction des natures, défense contre l'injection de prompt (le contenu de donnees_client est déclaré non-instruction), parsabilité. Systématisation du patron XML de la session 7 au niveau architecture.

Slide 15 — Le problème de la très longue durée

Même compressé, le contexte finit par perdre

• La compression est avec perte par construction
• Investigations de plusieurs heures, centaines d'appels d'outils
• Il faut une mémoire hors de la fenêtre de contexte

Notes : Transition vers le scratchpad. Le résumé repousse le mur ; il ne le supprime pas.

Slide 16 — Patron : investigation-scratchpad.md

Un fichier Markdown persistant + deux outils

## État          — synthèse, 5 lignes max
## Faits établis — chaque fait AVEC sa source (outil + id)
## Pistes ouvertes
## Décisions     — décision, justification, horodatage

« Ce qui n'y est pas écrit sera perdu. »

Notes : Outils read_scratchpad / update_scratchpad ; la discipline vient du prompt système. Mémoire sélective et intentionnelle : l'agent écrit ce qui compte, pas tout.

Slide 17 — Scratchpad : pourquoi ça marche

• Survit aux compressions, resets, plantages
• Inspectable par un humain → audite le raisonnement
• Transmissible : un autre agent reprend l'investigation
• Complète le résumé, ne le remplace pas (rôles différents)

Notes : Résumé = dans le contexte, éphémère, régénéré. Scratchpad = hors contexte, persistant, incrémental. En production sérieuse : les deux.

Slide 18 — Scratchpad : les pièges

Notes : Le scratchpad est écrit par le modèle : il hérite de ses erreurs. Troisième fois que « garder la source » revient — transition naturelle vers la provenance.

Slide 19 — Provenance : le principe

Toute sortie doit remonter à ses sources

En industrie régulée, une affirmation générée sans source traçable :

• n'est pas vérifiable
• n'est pas contestable
• n'est pas défendable devant un auditeur

⇒ elle est inutilisable

Notes : Banque, assurance, santé, juridique. Rappeler le public : architectes pour secteurs régulés. C'est souvent LE critère de go/no-go d'un projet IA.

Slide 20 — Attribution structurée

{ "claim": "Client sur liste de sanctions X ",
  "source": {"tool": "check_sanctions",
              "call_id": "call_0042",
              "record_id": "SANC-2211-08"},
  "confidence": "établi" }
+ enveloppe : prompt_version, modèle, température, horodatage

Notes : Deux provenances : celle des DONNÉES (sources) et celle du GÉNÉRATEUR (prompt versionné, modèle, paramètres). Le champ confidence (établi / à vérifier / inféré) est une exigence classique des équipes conformité.

Slide 21 — La citation n'est pas une preuve

Un modèle peut halluciner un record_id plausible

• La citation = un pointeur à résoudre et vérifier
• Vérification machinale contre le journal d'audit :
  le call_id existe ? le record_id est dans le résultat brut ?
• Sans vérification : théâtre de conformité

Notes : Question de certification : redemander au modèle de confirmer sa citation ne vérifie rien — on fait vérifier le faussaire par lui-même. Exercice 2 : corrompre un rapport et vérifier que le contrôle le détecte.

Slide 22 — Le journal d'audit

audit/2026-07-02/inv-8842/
  000_system_prompt.txt        + hash, version
  002a_tool_call_0042_args.json
  002b_tool_call_0042_raw.json   ← ce que l'outil a renvoyé
  002c_tool_call_0042_ctx.json   ← ce que le modèle a VU
  manifest.json                  modèle, params, hashes

Notes : Le triplet args/raw/ctx est le point subtil : l'auditeur vérifie ce que le modèle a réellement vu et que le filtrage n'a pas altéré le sens. Tout journaliser : prompts, réponses, appels, décisions, horodatages, ids de corrélation.

Slide 23 — Reproductibilité : « déterministe-ish »

Recette maximale : prompt versionné (hash) + modèle épinglé + température 0 + seed si disponible

Mais : infrastructure d'inférence ⇒ variations résiduelles possibles

La garantie de conformité = le journal, pas la regénération

Notes : Erreur contractuelle classique : promettre la regénération à l'identique. Formule à retenir : « on a journalisé la sortie exacte produite avec tout son contexte » — pas « on peut la reproduire bit à bit ».

Slide 24 — Check-list industries régulées

• [ ] Version de prompt + modèle + horodatage + id de corrélation sur chaque sortie
• [ ] Chaque affirmation ⇒ pointeur de source résoluble
• [ ] Vérification automatique des pointeurs (zéro citation orpheline)
• [ ] Journal complet : prompts, réponses, raw + ctx, décisions
• [ ] Rétention légale : impliquer le juridique
• [ ] Pas de promesse de reproductibilité bit à bit

Notes : À projeter et commenter. La rétention (durées) sort du périmètre technique — réflexe : escalader au juridique, ne pas improviser.

Slide 25 — Message Batches API : le principe

Traitement asynchrone en masse

Caractéristique	Valeur
Requêtes / batch	jusqu'à 100 000
Prix	−50 % entrée ET sortie
Délai	souvent < 1 h, SLA 24 h

Cas d'usage : évaluation massive, enrichissement, modération, retraitements

Notes : SLA = Service Level Agreement. Anti-cas : tout ce qui a un humain qui attend. ComplianceScan : re-noter 80 000 dossiers à chaque nouvelle politique.

Slide 26 — Cycle de vie et custom_id

created → in_progress → ended

• ended ≠ tout a réussi : statuts individuels
  succeeded / errored / canceled / expired
• Ordre des résultats non garanti
• custom_id = votre seule clé : corrélation, reprise, audit

Notes : Trois pièges de certif dans une slide. Dépouiller requête par requête ; retry des errored/expired à votre charge ; custom_id robuste = colonne vertébrale du pipeline (exercice 3).

Slide 27 — Batch + cache : l'optimisation maximale

"system": [{"type": "text",
            "text": POLITIQUE_V32,              # 3 200 tokens partagés
            "cache_control": {"type": "ephemeral"}}]

−50 % batch et remise cache sur le préfixe commun

Les deux se cumulent

Notes : Sur 80 000 requêtes partageant 3 200 tokens de système, l'économie est massive. Démo : calculateur de la page web, comparer les 4 configurations (sync/batch × avec/sans cache). Modalités exactes de cumul : vérifier la grille tarifaire du jour.

Slide 28 — Pièges de certification : rafale

1. Historique conservé entre appels ? Non — stateless
2. Résumé fiable pour l'audit ? Non — sortie de modèle
3. max_tokens agrandit la fenêtre ? Non — plafonne la sortie
4. Temp. 0 + seed = identique garanti ? Non — déterministe-ish
5. Batch ended = tout réussi ? Non — statuts individuels
6. Plus de contexte = mieux ? Non — pollution, less is more
7. Citation générée = preuve ? Non — pointeur à vérifier

Notes : Quiz éclair mains levées, corrections immédiates. Ces 7 points couvrent l'essentiel des questions piège de l'examen sur ce périmètre.

Slide 29 — Synthèse : les trois piliers

1. Contexte — budgétez, compressez (hybride), filtrez (hook), externalisez (scratchpad)
2. Provenance — en régulé, une sortie sans chaîne de sources vérifiable n'existe pas
3. Masse — batch −50 % + cache, custom_id en colonne vertébrale

Les trois se rejoignent : le journal d'audit est le sol commun.

Notes : Insister sur la convergence : le hook alimente le journal, le scratchpad cite ses sources, le custom_id relie batch et audit. Une seule architecture, trois faces.

Slide 30 — Pour la suite

• Exercices : budget de contexte · chaîne de provenance · pipeline batch
  (détection de la citation hallucinée et idempotence : éliminatoires)
• Quiz : 10 QCM, seuil 7/10, avant la session 9
• Page web : visualiseur, constructeur de provenance, calculateur batch
• Exit tickets : votre stratégie de contexte · ce que votre système ne journalise pas

Notes : Clôture. Rappeler la convention : tous les chiffres cités sont volatils, le réflexe professionnel (et de certification) est de vérifier la documentation officielle du moment.