Guide Professeur — Session 8 : Infrastructure & Déploiement

Programme : Applied AI — Niveau Intermédiaire Instructeur : Yann Isola Durée : 2 heures (120 minutes) Module couvert : Module 6 — Infrastructure & Déploiement

1. Vue d’ensemble de la session

Objectifs pédagogiques

À la fin de cette session, chaque participant doit être capable de :

Décrire le fossé notebook → production : ce qui fonctionne « sur mon ordinateur portable » pour 1 utilisateur ne tient pas face à 10 000 utilisateurs — et lister les 6 chantiers qui séparent les deux mondes (authentification, latence, coûts, observabilité, sécurité, montée en charge).
Intégrer proprement une API (Application Programming Interface, interface de programmation applicative) de LLM (Large Language Model, grand modèle de langage) : gestion des clés API, OAuth (Open Authorization, protocole d’autorisation déléguée), limites de débit (rate limits), stratégies de nouvelle tentative (retry) avec backoff exponentiel (attente qui double à chaque échec).
Raisonner en budget de latence : combien de temps l’utilisateur peut-il attendre ? Expliquer pourquoi le streaming via SSE (Server-Sent Events, événements envoyés par le serveur) transforme l’expérience perçue.
Piloter les coûts : compter les tokens, exploiter le prompt caching (mise en cache du prompt — jusqu’à 90 % d’économie ⚠), router intelligemment (modèle économique pour les tâches simples, modèle puissant pour les tâches difficiles).
Mettre en place l’observabilité : journaliser chaque requête/réponse, suivre la consommation de tokens, les percentiles de latence (p50, p95, p99), les taux d’erreur.
Traiter les prompts comme du code : versionnage, tests, revue — et intégrer une suite d’évaluations dans la CI/CD (Intégration Continue / Déploiement Continu).
Choisir un patron de déploiement : serverless (sans serveur — Lambda, Cloud Functions), conteneur (Docker), instance GPU (Graphics Processing Unit, processeur graphique) dédiée — et justifier le choix selon le cas d’usage.
Sécuriser la production : jamais de clé API côté client, assainissement des entrées (input sanitization), filtrage des sorties (output filtering).

Prérequis

Sessions 1 à 7 suivies (notamment Session 5 — tool calling, et les sessions sur les prompts et le RAG, Retrieval-Augmented Generation, génération augmentée par récupération).
Comprendre ce qu’est une requête HTTP (HyperText Transfer Protocol, protocole de transfert hypertexte) et une réponse JSON (JavaScript Object Notation, format d’échange de données).
Aucune compétence DevOps (fusion développement/exploitation) préalable requise : cette session est l’initiation DevOps appliquée à l’IA.

Matériel nécessaire

Vidéoprojecteur + slides (slides/slides.md).
Page web interactive (webpage/index.html) — fonctionne hors ligne : calculateur de coûts en tokens, constructeur d’architecture de déploiement, maquette de tableau de bord de monitoring avec métriques animées.
Feuilles d’exercices (exercises/exercises.md).
Quiz de fin de session (quiz/quiz.md).
Idéalement : un ordinateur portable pour deux participants (le calculateur de coûts est l’activité phare).

Message central de la session

« Un prototype IA qui marche, c’est 20 % du travail. Les 80 % restants s’appellent production : authentification, latence, coûts, observabilité, sécurité, montée en charge. Personne ne verra jamais ces 80 % — sauf quand ils manquent. »

Répétez cette idée sous plusieurs formes tout au long de la session. Un participant qui ne retient que cela repart avec l’essentiel : la production est une discipline, pas un détail.

Fil conducteur narratif

Toute la session suit une seule application fil rouge : « SupportBot », un assistant de support client interne qui répond aux questions des employés d’une entreprise de 5 000 personnes. On le suit du notebook du développeur jusqu’à un service qui encaisse 10 000 requêtes/jour. Chaque partie de la session résout un problème que SupportBot rencontre en grandissant :

📓 Partie A : SupportBot marche dans le notebook… et c’est tout.
🔑 Partie B : SupportBot se fait couper par les rate limits.
⏱️ Partie C : les utilisateurs trouvent SupportBot « lent ».
💸 Partie D : la facture mensuelle explose.
🔭 Partie E : « ça marche pas » — mais personne ne sait pourquoi.
🚀 Partie F : où et comment déployer, sécuriser, monter en charge.

La continuité narrative est votre meilleur outil pédagogique : chaque concept arrive comme la solution d’un problème vécu par SupportBot, jamais comme une notion abstraite.

2. Déroulé minute par minute

Horaire	Durée	Séquence	Support
0:00 – 0:05	5 min	Accueil, rappel Session 7, objectifs, présentation de SupportBot	Slides 1–3
0:05 – 0:18	13 min	Partie A — Le fossé notebook → production	Slides 4–6
0:18 – 0:33	15 min	Partie B — Intégration API : auth, rate limits, retry & backoff	Slides 7–11
0:33 – 0:45	12 min	Partie C — Budget de latence & streaming (SSE)	Slides 12–14 + démo web (dashboard, courbe latence)
0:45 – 1:00	15 min	Exercice 1 : Calculateur de coûts (sur la page web)	Feuille d’exercices + webpage
1:00 – 1:05	5 min	☕ Pause courte	—
1:05 – 1:20	15 min	Partie D — Gestion des coûts : tokens, caching, routage de modèles	Slides 15–18 + calculateur web
1:20 – 1:32	12 min	Partie E — Observabilité, versionnage des prompts, CI/CD	Slides 19–22 + maquette dashboard web
1:32 – 1:45	13 min	Exercice 2 : Concevoir une architecture de déploiement	Feuille d’exercices + constructeur web
1:45 – 1:53	8 min	Partie F — Patrons de déploiement, sécurité, montée en charge	Slides 23–27
1:53 – 2:00	7 min	Quiz éclair + Exit Tickets + annonce Session 9	Slides 28–30

Note de flexibilité : l’Exercice 3 (conception d’un tableau de bord de monitoring) est prévu comme devoir à la maison ou activité bonus. Si vous prenez du retard, compressez la Partie F à 5 minutes en projetant seulement le tableau comparatif serverless / conteneur / GPU dédié — mais ne sacrifiez jamais la Partie D (coûts) ni le passage sécurité « jamais de clé API côté client » : ce sont les deux protections les plus rentables pour vos participants.

3. Notes pédagogiques détaillées par séquence

0:00 – 0:05 | Accueil et cadrage

Quoi dire : « La dernière session, vous avez construit des systèmes qui raisonnent et agissent. Aujourd’hui, question brutale : combien d’entre vous ont déjà vu un prototype génial… qui n’est jamais sorti du notebook ? » (Mains levées garanties.) « Cette session, c’est le mode d’emploi pour franchir ce fossé. »

Présentez SupportBot en 30 secondes : un assistant RAG + outils qui répond aux questions internes. Il marche parfaitement… pour son développeur, seul, un mardi après-midi.

Piège à éviter : ne laissez pas les non-développeurs décrocher dès la première minute. Annoncez explicitement : « Zéro ligne de code à écrire aujourd’hui. On raisonne en architecte, pas en développeur. Les décisions qu’on va apprendre à prendre sont des décisions de gestion de projet et de budget autant que des décisions techniques. »

0:05 – 0:18 | Partie A — Le fossé notebook → production

Idée maîtresse : « ça marche sur mon ordinateur » et « ça sert 10 000 utilisateurs » sont deux métiers différents.

Déroulé :

Projetez le tableau des différences (slide 5). Faites-le vivre avec SupportBot :
- Notebook : 1 utilisateur (le développeur), clé API en clair dans le code, aucune gestion d’erreur, coût invisible, latence « on s’en fiche ».
- Production : 10 000 requêtes/jour, secrets protégés, pannes réseau inévitables, facture mensuelle scrutée par la direction, utilisateurs qui abandonnent après 5 secondes.
Introduisez les 6 chantiers (slide 6) : authentification & intégration API, latence, coûts, observabilité, sécurité, montée en charge. Annoncez que la session les traite dans cet ordre.

Analogie qui fonctionne bien : le food-truck vs le restaurant. La recette (le prompt, le modèle) est la même. Mais le restaurant a besoin de réservations (rate limits), d’une cuisine dimensionnée (scaling), d’une comptabilité (coûts), d’hygiène contrôlée (sécurité) et d’un chef qui sait ce qui se passe dans sa salle (observabilité).

Question à poser à la salle : « Quel est, selon vous, le chantier le plus souvent oublié ? » Réponse attendue et correcte : l’observabilité — parce qu’elle ne se voit pas tant que tout va bien.

0:18 – 0:33 | Partie B — Intégration API : authentification, rate limits, retry

Concepts à couvrir, dans l’ordre :

Clés API (slide 8) : une clé API est un mot de passe de service. Règles d’or :
- Jamais dans le code source (ni dans Git, l’outil de gestion de versions).
- Jamais côté client (navigateur, application mobile) — quiconque ouvre les outils développeur du navigateur peut la lire et la voler.
- Toujours dans des variables d’environnement ou un gestionnaire de secrets (AWS Secrets Manager, HashiCorp Vault, etc.).
- Rotation régulière : une clé doit pouvoir être révoquée sans tout casser.
OAuth (slide 9) : quand l’application agit au nom d’un utilisateur (accéder à son agenda Google, son CRM — Customer Relationship Management, gestion de la relation client), on n’utilise pas une clé API globale mais OAuth : l’utilisateur autorise explicitement, l’application reçoit un jeton (token d’accès) limité et révocable. Simplifiez : « clé API = badge de l’entreprise ; OAuth = badge visiteur nominatif, avec date d’expiration ».
Rate limits (slide 10) : les fournisseurs limitent le débit — typiquement en RPM (Requests Per Minute, requêtes par minute) et TPM (Tokens Per Minute, tokens par minute). ⚠ Les chiffres exacts varient selon le fournisseur et le niveau de compte : donnez un ordre de grandeur (ex. quelques centaines à quelques milliers de RPM) et insistez sur le réflexe : lire la réponse HTTP 429 Too Many Requests et l’en-tête retry-after.
Retry & backoff exponentiel (slide 11) : quand un appel échoue (erreur 429 ou 5xx), on réessaie — mais pas immédiatement et pas indéfiniment :
- Tentative 1 échoue → attendre 1 s → tentative 2 → attendre 2 s → tentative 3 → attendre 4 s → tentative 4 → abandon propre.
- Ajouter du jitter (variation aléatoire) pour éviter que 1 000 clients réessaient exactement au même instant (effet « troupeau » — thundering herd).
- Ne jamais réessayer les erreurs 400/401/403 (requête invalide, authentification manquante, interdit) : réessayer une requête invalide donnera le même résultat invalide.

Anecdote SupportBot : « Lundi matin, 9 h 00 : 800 employés ouvrent SupportBot en même temps. Sans retry ni backoff, 30 % des requêtes échouent avec une erreur 429 et les utilisateurs voient “Erreur serveur”. Avec backoff + jitter : tout le monde est servi, avec 2–3 secondes d’attente pour les moins chanceux. Même code métier, expérience radicalement différente. »

Erreur fréquente des participants : confondre rate limit (limitation volontaire du fournisseur) et panne (indisponibilité involontaire). Les deux se gèrent par retry, mais le rate limit se prévient aussi : lisser le trafic, mettre en file d’attente, demander une augmentation de quota.

0:33 – 0:45 | Partie C — Budget de latence & streaming

Concepts :

Le budget de latence (slide 12) : partir de l’utilisateur, pas de la technique. Repères UX (User eXperience, expérience utilisateur) classiques :
- < 1 s : perçu comme instantané ou fluide.
- 1–3 s : acceptable avec un indicateur d’attente.
- 3–10 s : frustrant ; nécessite du streaming ou une barre de progression honnête.
- > 10 s : à traiter en asynchrone (« nous vous notifierons quand ce sera prêt »).
Décomposer la latence (slide 13) : réseau aller (+ ~50–100 ms) + TTFT (Time To First Token, délai avant le premier token — souvent 200 ms à 1 s ⚠) + génération (proportionnelle au nombre de tokens de sortie) + réseau retour. Le poste dominant est presque toujours la génération des tokens de sortie. Conséquence directe : une réponse deux fois plus courte est ~deux fois plus rapide — le contrôle de la longueur de sortie est une optimisation de latence.
Streaming via SSE (slide 14) : au lieu d’attendre la réponse complète, le serveur envoie les tokens au fil de la génération. SSE = Server-Sent Events, un mécanisme HTTP standard où la connexion reste ouverte et le serveur pousse des événements. La latence totale ne change presque pas, mais la latence perçue s’effondre : l’utilisateur voit le premier mot en moins d’une seconde.

Démo web : ouvrez la page interactive, onglet « Monitoring », montrez la ligne TTFT vs latence totale. Puis posez la question : « Que préférez-vous : une réponse complète en 8 secondes d’écran figé, ou un premier mot à 0,8 s et la suite qui défile ? » C’est exactement pourquoi toutes les interfaces de chat IA streament.

Point subtil à mentionner : le streaming complique légèrement le code (gestion d’événements partiels, gestion d’erreur en cours de flux) et le filtrage de sortie (on filtre quoi, si la réponse arrive par morceaux ?). Rien d’insurmontable, mais ce n’est pas gratuit.

0:45 – 1:00 | Exercice 1 — Calculateur de coûts (15 min)

Organisation : binômes, un ordinateur par binôme, page web onglet « Calculateur de coûts ». La feuille d’exercices guide pas à pas.

Objectif pédagogique caché : faire découvrir par la manipulation trois vérités :

Les tokens de sortie coûtent plus cher que les tokens d’entrée (souvent 3 à 5× ⚠).
Le prompt caching change radicalement l’équation quand le prompt système est long et répété.
Le routage de modèles (petit modèle pour 80 % des cas) est souvent la plus grosse économie disponible.

Circulation dans la salle : repérez les binômes qui ont fini tôt et lancez-leur le défi bonus (« trouvez la configuration qui divise la facture par 10 sans changer le volume de requêtes »).

Restitution (3 dernières minutes) : demandez à deux binômes leurs chiffres. Écrivez au tableau la facture « naïve » vs la facture « optimisée ». L’écart (souvent 5–15×) est le moment mémorable de la session.

1:00 – 1:05 | ☕ Pause

Pendant la pause, laissez projetée la maquette du dashboard de monitoring (métriques animées) : elle intrigue et prépare la Partie E.

1:05 – 1:20 | Partie D — Gestion des coûts

Concepts, appuyés sur ce que l’Exercice 1 vient de faire vivre :

Compter les tokens (slide 15) : un token ≈ ¾ de mot en anglais, un peu moins en français (≈ 1,3–2 tokens par mot ⚠ selon le tokeniseur). La facture = tokens d’entrée × prix d’entrée + tokens de sortie × prix de sortie. Ordres de grandeur ⚠ (mi-2026, à vérifier avant chaque session) : de ~0,1–1 $ par million de tokens d’entrée pour les petits modèles à ~3–15 $ pour les grands ; la sortie coûte typiquement 3–5× l’entrée.
Prompt caching (slide 16) : si le début du prompt est identique d’une requête à l’autre (prompt système, documents de référence, définitions d’outils), le fournisseur peut le mettre en cache et facturer les tokens en cache à une fraction du prix — jusqu’à 90 % d’économie sur la partie cachée ⚠. Règle pratique : mettre tout le contenu stable au début du prompt, le contenu variable (question de l’utilisateur) à la fin.
Routage de modèles (slide 17) : toutes les requêtes ne se valent pas. « Quels sont les horaires du support ? » n’a pas besoin du même modèle que « Analyse ce contrat de 40 pages ». Architecture : un classifieur (ou un petit modèle, ou des règles simples) route chaque requête vers le modèle le moins cher capable de la traiter. En pratique, 70–90 % ⚠ du trafic d’un assistant de support relève du modèle économique.
Plafonds et alertes (slide 18) : budget mensuel de tokens, alerte à 50 %/80 %/100 %, coupure ou dégradation gracieuse (bascule vers le petit modèle) en cas de dépassement. « Une facture surprise de 20 000 € tue plus de projets IA qu’un bug. »

Piège pédagogique : ne transformez pas cette partie en cours de tarification — les prix changent tous les trimestres. Enseignez la méthode de calcul et le réflexe « je vérifie la grille tarifaire du jour », pas les chiffres.

1:20 – 1:32 | Partie E — Observabilité, versionnage des prompts, CI/CD

Concepts :

Journaliser chaque requête/réponse (slide 19) : horodatage, identifiant de requête, version du prompt, modèle utilisé, tokens entrée/sortie, latence, statut. Sans journal, le premier « ça ne marche pas » d’un utilisateur est indiagnosticable. Attention RGPD (Règlement Général sur la Protection des Données) : définir la durée de rétention et anonymiser/pseudonymiser si les prompts contiennent des données personnelles.
Percentiles de latence (slide 20) : la moyenne ment. p50 (médiane) = l’expérience typique ; p95 = l’expérience d’1 utilisateur sur 20 ; p99 = les pires cas. Un service peut afficher 1,2 s de moyenne et 9 s au p99 — et ce sont les utilisateurs du p99 qui se plaignent et partent. Les SLA (Service Level Agreement, engagement de niveau de service) s’écrivent en percentiles : « p95 < 3 s », jamais « moyenne < 2 s ».
Taux d’erreur et alertes (slide 21) : seuils d’alerte sur le taux d’erreur (ex. > 2 % sur 5 minutes), la latence p95, le budget de tokens. Une alerte doit être actionnable : si personne ne sait quoi faire quand elle sonne, supprimez-la ou documentez-la.
Les prompts sont du code (slide 22) : versionnés (Git), revus (revue de pairs), testés (suite d’évaluations). CI/CD pour l’IA : à chaque PR (Pull Request, demande de fusion de code) qui modifie un prompt, la suite d’évals tourne automatiquement — tests de régression de prompts. « Changer un mot dans un prompt peut casser 15 % des réponses. Sans évals en CI, vous le découvrez en production, via vos utilisateurs. »

Démo web : maquette du dashboard — montrez les métriques qui bougent, le p95 qui décroche, l’alerte budget qui passe à l’orange. Demandez : « Quelle métrique regarderiez-vous en premier lundi matin ? »

Lien avec les sessions précédentes : rappelez que la suite d’évaluations a été construite conceptuellement dans les sessions consacrées à la qualité des prompts — ici, on l’automatise.

1:32 – 1:45 | Exercice 2 — Architecture de déploiement (13 min)

Organisation : mêmes binômes. Cahier des charges dans la feuille d’exercices (trois scénarios au choix : chatbot RH interne, API de résumé de documents à fort volume, assistant temps réel côté client). Le constructeur d’architecture de la page web sert de support visuel : glisser les composants (passerelle API, fournisseur LLM, cache, file d’attente, base de données) et lire l’estimation de latence.

Ce que vous évaluez en circulant :

La clé API est-elle bien côté serveur (jamais dans le navigateur) ?
Y a-t-il un composant d’observabilité (journalisation) ?
Le scénario asynchrone utilise-t-il une file d’attente ?
Le choix serverless/conteneur/GPU est-il justifié (et pas juste « Docker parce que c’est cool ») ?

Restitution (3 min) : un binôme présente son architecture ; la salle challenge. Vous jouez l’avocat du diable : « Que se passe-t-il si le fournisseur LLM tombe 10 minutes ? » (Réponses attendues : retry, message dégradé, file d’attente qui absorbe, éventuellement fournisseur de secours.)

1:45 – 1:53 | Partie F — Patrons de déploiement, sécurité, montée en charge

Cette partie est volontairement dense et rapide — l’Exercice 2 a déjà fait manipuler les concepts.

Trois patrons de déploiement (slide 24) :
- Serverless (Lambda, Cloud Functions) : zéro serveur à gérer, facturation à l’exécution, montée en charge automatique. Limites : durée d’exécution plafonnée, démarrage à froid (cold start). Idéal pour trafic irrégulier et équipes réduites.
- Conteneur (Docker, orchestré par exemple avec Kubernetes) : portable, reproductible, contrôle fin. Coût de compétence plus élevé. Idéal pour un trafic soutenu et régulier.
- Instance GPU dédiée : uniquement si vous hébergez le modèle vous-même (open-weights) — souveraineté des données, coût fixe élevé, expertise pointue. La majorité des projets n’en a pas besoin : l’appel API à un fournisseur suffit.
Sécurité (slide 25) : les trois règles non négociables — clé API jamais côté client (toujours un backend intermédiaire), assainissement des entrées (longueur maximale, détection d’injection de prompt), filtrage des sorties (données sensibles, contenu inapproprié) avant affichage.
Montée en charge (slide 26) : montée horizontale (plusieurs instances derrière un répartiteur de charge — load balancer) plutôt que verticale (une machine plus grosse). Pour les traitements longs ou massifs : architecture à file d’attente (queue) — le client dépose une tâche, des workers la traitent au rythme des rate limits, le client est notifié. C’est LE patron pour le traitement par lots.

Raccourci si retard : projetez uniquement le tableau comparatif des trois patrons et la slide sécurité. La file d’attente a déjà été vue dans l’Exercice 2.

1:53 – 2:00 | Quiz, Exit Tickets, clôture

Quiz : 10 QCM (questionnaire à choix multiples), 5–6 minutes, auto-correction collective rapide si le temps le permet (sinon corrigé en ligne).
Exit tickets (ci-dessous) : 1 minute, un post-it ou formulaire par participant.
Teaser Session 9 : « Vous savez maintenant déployer. La prochaine fois : comment savoir si ce que vous avez déployé est bon — évaluation avancée et amélioration continue. »

4. Les 5 Exit Tickets

À distribuer (papier ou formulaire) dans les 5 dernières minutes. Chaque participant répond à une question (distribuez-les en alternance) ou aux cinq en version courte.

« Citez deux différences entre un prototype en notebook et un service en production, et expliquez pourquoi elles comptent. » Attendu : deux éléments parmi — gestion des secrets, retry/rate limits, latence maîtrisée, suivi des coûts, observabilité, sécurité, montée en charge — avec une justification d’une phrase.
« Votre application reçoit une erreur HTTP 429. Que signifie-t-elle et que doit faire votre code ? » Attendu : rate limit dépassé (Too Many Requests) → attendre puis réessayer avec backoff exponentiel (+ jitter), en respectant l’en-tête retry-after s’il est présent. Ne pas marteler l’API.
« Expliquez en deux phrases pourquoi le streaming SSE améliore l’expérience utilisateur sans réduire la latence totale. » Attendu : les tokens sont affichés au fil de la génération ; le premier token arrive en < 1 s, donc la latence perçue chute, même si la génération complète prend le même temps.
« Donnez deux leviers pour réduire la facture d’une application LLM sans réduire le volume de requêtes. » Attendu : deux parmi — prompt caching (contenu stable en début de prompt), routage vers un modèle moins cher pour les tâches simples, réduction de la longueur des sorties, réduction du contexte injecté (meilleur RAG).
« Pourquoi dit-on que “les prompts sont du code” ? Citez une pratique concrète qui en découle. » Attendu : un changement de prompt change le comportement du système comme un changement de code → versionnage Git, revue de pairs, tests de régression (suite d’évals) exécutés en CI/CD à chaque modification.

Exploitation : lisez les tickets avant la Session 9. Si plus de 30 % des réponses au ticket 2 confondent 429 et panne serveur, prévoyez 5 minutes de rappel en ouverture de la session suivante.

5. Questions fréquentes des participants (et réponses prêtes)

« Pourquoi ne pas appeler l’API du fournisseur directement depuis le navigateur ? Ce serait plus simple. » Parce que la clé API serait visible par quiconque ouvre les outils développeur du navigateur (F12 → onglet Réseau). Elle serait volée en quelques heures et utilisée à vos frais. Un backend intermédiaire — même minuscule, même serverless — est obligatoire. C’est la règle de sécurité n° 1 de la session.

« Le prompt caching, c’est nous qui le gérons ou le fournisseur ? » Le fournisseur héberge le cache, mais vous structurez le prompt pour en profiter : contenu stable au début, contenu variable à la fin, et selon les fournisseurs un marqueur explicite de point de cache. Si votre prompt système change à chaque requête (horodatage dynamique, par exemple), le cache ne sert à rien.

« Faut-il un GPU pour déployer une application IA ? » Non, dans la grande majorité des cas. Si vous appelez l’API d’un fournisseur (Anthropic, OpenAI, Mistral…), le GPU est chez lui. Vous n’avez besoin de GPU que si vous hébergez vous-même un modèle open-weights — un choix qui se justifie par la souveraineté des données ou un volume énorme, pas par défaut.

« Combien coûte vraiment une application comme SupportBot ? » ⚠ Cela dépend des tarifs du jour, mais la méthode est stable : volume quotidien × (tokens d’entrée × prix d’entrée + tokens de sortie × prix de sortie), puis appliquer caching et routage. L’Exercice 1 donne la méthode ; refaites le calcul avec la grille tarifaire du moment. Ordre de grandeur : de quelques dizaines à quelques milliers d’euros/mois selon le volume et l’optimisation.

« La moyenne de latence de notre service est bonne, pourquoi les utilisateurs se plaignent-ils ? » Parce que la moyenne cache la queue de distribution. Regardez le p95 et le p99 : si le p99 est à 9 s, 1 requête sur 100 est insupportable — et ces utilisateurs-là sont bruyants. Engagez-vous sur des percentiles, pas des moyennes.

« On a déjà une CI/CD pour notre code. Qu’est-ce qui change avec l’IA ? » Deux ajouts : (1) la suite d’évaluations tourne à chaque PR qui touche un prompt ou un paramètre de modèle — ce sont les tests unitaires du comportement du modèle ; (2) les sorties étant non déterministes, les tests portent sur des critères (format respecté, présence d’informations clés, score d’un juge) plutôt que sur une égalité stricte.

6. Matériel de secours (si la technique lâche)

La page web ne s’ouvre pas → l’Exercice 1 est faisable à la main : la feuille d’exercices contient la grille tarifaire fictive et les formules. Prévoyez des calculatrices (ou téléphones).
Pas de vidéoprojecteur → le tableau comparatif des patrons de déploiement et le schéma retry/backoff se dessinent au tableau blanc en 2 minutes chacun ; les gabarits sont dans les notes des slides 11 et 24.
Session à distance → partagez la page web en amont (fichier unique, fonctionne hors ligne) ; les binômes deviennent des salles de sous-groupes de 15 minutes.