Slides — Session 8 : Infrastructure & Déploiement

Programme : Applied AI — Niveau Intermédiaire — Instructeur : Yann Isola
Format : 30 slides. Chaque slide comporte le contenu projeté puis les notes orateur.
Palette : encre #1A2230, sarcelle #0F7A6C, cuivre #B4612A, sarcelle claire #E9F6F3, fond #F4F7F6.

Slide 1 — Titre

Infrastructure & Déploiement

Du notebook aux 10 000 utilisateurs

Applied AI — Session 8 — Yann Isola

Notes orateur : Accueil. Question d'ouverture : « Qui a déjà vu un prototype IA génial… qui n'est jamais sorti du notebook ? » Les mains se lèvent. « Aujourd'hui, on apprend à franchir ce fossé. » Zéro code à écrire : on raisonne en architecte.

Slide 2 — Rappel express : Session 7

• Vous savez construire des systèmes IA qui lisent (RAG — Retrieval-Augmented Generation, génération augmentée par récupération) et agissent (outils)
• Vous savez évaluer la qualité de leurs réponses
• Il manque une chose : les faire tourner pour de vrai, pour de vrais utilisateurs

Notes orateur : 90 secondes max. Transition : « Un système brillant que personne ne peut utiliser vaut zéro. »

Slide 3 — Objectifs de la session

À la fin de ces 2 heures, vous saurez :

1. Nommer les 6 chantiers entre notebook et production
2. Intégrer une API proprement : clés, OAuth, rate limits, retry avec backoff
3. Raisonner en budget de latence et expliquer le streaming (SSE)
4. Réduire la facture : tokens, caching, routage de modèles
5. Mettre en place observabilité et alertes ; traiter les prompts comme du code
6. Choisir un patron de déploiement et sécuriser la production

Notes orateur : Contrat clair. Précisez le fil rouge : « On va suivre une seule application, SupportBot, du notebook à la production. Chaque concept résout un problème qu'elle rencontre en grandissant. »

Slide 4 — Voici SupportBot

• Assistant de support interne : RAG + outils, répond aux questions des employés
• Dans le notebook du développeur : il marche parfaitement
• 1 utilisateur · clé API en clair · aucune gestion d'erreur · coût invisible · latence ignorée
• Demain : 5 000 employés, 10 000 requêtes/jour

Notes orateur : Plantez le décor en 60 secondes. Insistez : rien n'est « faux » dans le prototype — il est juste conçu pour un monde qui n'existe pas (un utilisateur, réseau parfait, budget infini).

Slide 5 — Notebook vs Production

	Notebook	Production
Utilisateurs	1 (vous)	10 000/jour
Clé API	en clair dans le code	gestionnaire de secrets
Erreur réseau	on relance la cellule	retry automatique
Coût	invisible	scruté par la direction
Latence	« on s'en fiche »	abandon après 5 s
« Ça marche pas »	vous debuggez en direct	il faut des journaux

Notes orateur : Analogie food-truck vs restaurant : même recette, mais le restaurant a besoin de réservations, d'une cuisine dimensionnée, d'une comptabilité, d'hygiène et d'un chef qui voit sa salle. La recette (le prompt) est la partie facile.

Slide 6 — Les 6 chantiers de la production

1. Intégration API — auth, rate limits, retry
2. Latence — budget, streaming
3. Coûts — tokens, caching, routage
4. Observabilité — journaux, percentiles, alertes
5. Sécurité — secrets, entrées, sorties
6. Montée en charge — scaling, files d'attente

Notes orateur : C'est le plan de la session. Question à la salle : « Lequel est le plus souvent oublié ? » Réponse : l'observabilité — invisible tant que tout va bien, indispensable dès le premier incident. Message central à marteler : « un prototype qui marche = 20 % du travail ».

Slide 7 — Chantier 1 : parler à l'API du fournisseur

• Votre application appelle l'API (Application Programming Interface, interface de programmation applicative) d'un fournisseur de LLM (Large Language Model, grand modèle de langage)
• Trois questions à régler :
  1. Qui a le droit d'appeler ? → authentification
  2. À quel rythme ? → rate limits
  3. Et quand ça échoue ? → retry & backoff

Notes orateur : Recadrez : dans 90 % des projets, vous n'hébergez PAS le modèle — vous appelez une API. Toute la fiabilité de votre produit dépend donc de la qualité de cette intégration.

Slide 8 — Les clés API : le badge de l'entreprise

• Une clé API = un mot de passe de service
• Règles d'or :
  • jamais dans le code source (ni dans Git)
  • jamais côté client — navigateur, appli mobile
  • variables d'environnement ou gestionnaire de secrets
  • rotation : révocable sans tout casser

Notes orateur : Démonstration mentale : « Ouvrez F12 dans votre navigateur, onglet Réseau. Tout ce que le navigateur envoie, VOUS le voyez. Une clé dans le front-end est publique de fait — elle sera volée et utilisée à vos frais. » C'est la règle de sécurité n° 1 de la session, elle reviendra slide 25.

Slide 9 — OAuth : le badge visiteur nominatif

• OAuth (Open Authorization, protocole d'autorisation déléguée)
• Quand l'application agit au nom d'un utilisateur : son agenda, son CRM (Customer Relationship Management, gestion de la relation client), ses fichiers
• L'utilisateur autorise explicitement → l'application reçoit un jeton limité, expirable, révocable
• Clé API = badge de l'entreprise · OAuth = badge visiteur nominatif avec date d'expiration

Notes orateur : Ne rentrez pas dans le détail du protocole (flows, scopes) — retenez le QUAND : identité globale de service → clé API ; action au nom d'un utilisateur précis → OAuth. Exemple SupportBot : consulter le solde de congés de cet employé → OAuth vers le SIRH (système d'information RH).

Slide 10 — Rate limits : la file d'attente du fournisseur

• Les fournisseurs limitent le débit :
  • RPM (Requests Per Minute, requêtes/minute)
  • TPM (Tokens Per Minute, tokens/minute)
• Les valeurs dépendent du fournisseur et du niveau de compte
• Dépassement → réponse HTTP 429 « Too Many Requests » + souvent un en-tête retry-after
• Le 429 n'est pas une panne : c'est une consigne — ralentissez

Notes orateur : Anecdote SupportBot : lundi 9 h, 800 employés se connectent en même temps → rafale de 429. Distinguer : rate limit = limitation volontaire, prévisible, négociable (augmentation de quota) ; panne = involontaire. Les deux se gèrent par retry, mais le rate limit se prévient aussi (lissage, file d'attente).

Slide 11 — Retry & backoff exponentiel

Tentative 1 → échec (429/5xx)
   attendre 1 s (+ jitter)
Tentative 2 → échec
   attendre 2 s (+ jitter)
Tentative 3 → échec
   attendre 4 s (+ jitter)
Tentative 4 → échec → abandon PROPRE (message clair à l'utilisateur)

• Jitter = variation aléatoire → évite que 1 000 clients réessaient au même instant
• Ne jamais réessayer les 400/401/403 : une requête invalide reste invalide

Notes orateur : Schéma à reproduire au tableau si besoin. Expliquez le « thundering herd » (effet troupeau) : sans jitter, tous les clients réessaient à la même seconde et recréent le pic. Avec backoff + jitter, l'expérience du lundi 9 h passe de « 30 % d'erreurs » à « 2–3 s d'attente pour les moins chanceux ».

Slide 12 — Chantier 2 : le budget de latence

Partir de l'utilisateur, pas de la technique :

Notes orateur : « Combien de temps l'utilisateur peut-il attendre ? » est une question produit, pas une question technique. Fixez le budget AVANT de choisir modèle et architecture. Un utilisateur de chat n'attend pas comme un service batch de nuit.

Slide 13 — Où part le temps ?

Latence totale =
   réseau aller (~50–100 ms)
 + TTFT (Time To First Token, délai avant le 1er token : ~0,2–1 s )
 + génération (proportionnelle aux tokens de SORTIE)
 + réseau retour

• Le poste dominant : la génération des tokens de sortie
• Conséquence : une réponse 2× plus courte ≈ 2× plus rapide

Notes orateur : Insight contre-intuitif : contrôler la longueur des réponses (consigne de concision, max_tokens) est une optimisation de LATENCE autant que de coût. Les participants croient souvent que la latence vient du réseau — non, elle vient de la génération.

Slide 14 — Streaming : SSE change tout (sauf la latence)

• SSE (Server-Sent Events, événements envoyés par le serveur) : la connexion HTTP reste ouverte, le serveur pousse les tokens au fil de la génération
• Latence totale : quasi inchangée
• Latence perçue : effondrée — premier mot < 1 s
• C'est pourquoi toutes les interfaces de chat IA streament

Notes orateur : Question rhétorique : « Vous préférez 8 secondes d'écran figé, ou un premier mot à 0,8 s et la suite qui défile ? » Mentionnez le coût caché : gestion d'erreur en cours de flux et filtrage de sortie plus délicats (on filtre quoi, si la réponse arrive par morceaux ?). Démo : onglet Monitoring de la page web, ligne TTFT.

Slide 15 — Chantier 3 : la facture se compte en tokens

Coût = tokens_entrée × prix_entrée + tokens_sortie × prix_sortie

• 1 token ≈ ¾ de mot en anglais ; en français ≈ 1,3–2 tokens/mot
• La sortie coûte 3 à 5× plus cher que l'entrée
• Ordres de grandeur (mi-2026) : ~0,1–1 $/M tokens d'entrée (petits modèles) à ~3–15 $/M (grands) — vérifiez la grille du jour

Notes orateur : N'enseignez pas les prix (ils changent chaque trimestre), enseignez la MÉTHODE et le réflexe « je vérifie la grille tarifaire avant de projeter un budget ». Transition : « Voyons les trois leviers pour faire fondre cette facture. » L'Exercice 1 vient de le faire vivre — appuyez-vous sur leurs chiffres.

Slide 16 — Levier 1 : le prompt caching

• Le début du prompt est souvent identique à chaque requête : prompt système, documents, définitions d'outils
• Le fournisseur le met en cache → tokens cachés facturés à une fraction du prix
• Jusqu'à 90 % d'économie sur la partie cachée
• Règle d'or : stable au début, variable à la fin

Notes orateur : Chiffres de l'Exercice 1 : SupportBot passe de 9 000 à ~4 100 $/mois juste avec le cache. Piège classique : insérer un horodatage dynamique en tête de prompt système → cache invalidé à chaque requête, économie zéro. Le cache est géré par le fournisseur, mais c'est VOTRE structure de prompt qui le rend possible.

Slide 17 — Levier 2 : le routage de modèles

• Toutes les requêtes ne se valent pas :
  • « Quels sont les horaires du support ? » → petit modèle
  • « Analyse ce contrat de 40 pages » → grand modèle
• Un routeur (règles simples ou petit classifieur) dirige chaque requête vers le modèle le moins cher capable de la traiter
• En pratique : 70–90 % du trafic d'un assistant support relève du petit modèle

Notes orateur : C'est souvent LE plus gros levier : dans l'Exercice 1, le routage 80/20 fait passer la facture de ~4 100 à ~1 100 $/mois (−88 % vs naïf). Le risque : mal router une question difficile vers le petit modèle → prévoir une escalade (le petit modèle peut dire « je passe la main »).

Slide 18 — Levier 3 : plafonds et alertes budgétaires

• Budget mensuel de tokens défini à l'avance
• Alertes à 50 % / 80 % / 100 % du budget
• À 100 % : coupure ou dégradation gracieuse (bascule vers le petit modèle)

« Une facture surprise de 20 000 € tue plus de projets IA qu'un bug. »

Notes orateur : Histoire vraie générique : la boucle d'agent qui tourne toute la nuit, ou le script de test lancé sur la mauvaise boucle. Sans plafond, on le découvre sur la facture. Avec plafond + alerte, on le découvre à 50 %. La dégradation gracieuse vaut mieux que la coupure sèche : le service continue, en mode économique.

Slide 19 — Chantier 4 : l'observabilité — journaliser TOUT

Pour chaque requête, consigner :

• horodatage · identifiant de requête · version du prompt
• modèle utilisé · tokens entrée/sortie
• latence · statut (succès/erreur)

RGPD (Règlement Général sur la Protection des Données) : durée de rétention définie, pseudonymisation si données personnelles

Notes orateur : Scénario : un utilisateur dit « hier, SupportBot m'a répondu n'importe quoi ». Sans journal : impossible à diagnostiquer. Avec journal : vous retrouvez la requête, le prompt exact, la version, le modèle — et vous reproduisez. La « version du prompt » dans le journal prépare la slide 22.

Slide 20 — La moyenne ment : pensez percentiles

• p50 (médiane) : l'expérience typique
• p95 : l'expérience d'1 utilisateur sur 20
• p99 : les pires cas — ceux qui se plaignent et partent

Exemple : moyenne 1,2 s… et p99 à 9 s

Les SLA (Service Level Agreement, engagement de niveau de service) s'écrivent en percentiles : « p95 < 3 s » — jamais « moyenne < 2 s »

Notes orateur : Démo web : le dashboard affiche p50/p95/p99 en direct — montrez le p95 qui décroche pendant que la moyenne reste sage. Phrase choc : « Vos utilisateurs ne vivent pas la moyenne ; chacun vit SA requête. »

Slide 21 — Alertes : chaque alarme a un mode d'emploi

Format d'une règle d'alerte :

SI taux d'erreur > 2 % PENDANT 5 min ALORS astreinte notifiée FAIT vérifier statut fournisseur, activer mode dégradé

Les 3 alertes de base :

1. Taux d'erreur (seuil sur fenêtre glissante)
2. Latence p95 (le SLA)
3. Budget de tokens (50/80/100 %)

Notes orateur : Règle absolue : une alerte sans action documentée est du bruit — elle sera ignorée dès la 3e fois, y compris quand ce sera grave. Si personne ne sait quoi faire quand elle sonne : supprimez-la ou écrivez le mode d'emploi.

Slide 22 — Les prompts sont du code

• Un mot changé dans un prompt peut casser 15 % des réponses
• Donc les prompts sont :
  • versionnés (Git, l'outil de gestion de versions)
  • relus (revue de pairs, comme une PR — Pull Request, demande de fusion)
  • testés : la suite d'évaluations tourne à chaque PR → tests de régression de prompts
• C'est la CI/CD (Intégration Continue / Déploiement Continu) appliquée à l'IA

Notes orateur : Pont avec les sessions précédentes : « Vous avez appris à construire des évals. Ici, on les branche sur le robinet : elles tournent automatiquement à chaque modification. » Spécificité IA : sorties non déterministes → tester des critères (format, présence d'infos clés, score d'un juge), pas une égalité stricte. Sans ça, les régressions se découvrent en production, via les utilisateurs.

Slide 23 — Chantier 5 & 6 : déployer, sécuriser, encaisser

Trois dernières questions :

1. Où faire tourner le backend ? → patrons de déploiement
2. Comment le protéger ? → sécurité
3. Comment encaisser la charge ? → scaling & files d'attente

Notes orateur : Transition rapide — l'Exercice 2 a déjà fait manipuler ces choix. Cette partie consolide et nomme les patterns.

Slide 24 — Trois patrons de déploiement

	Serverless	Conteneur	GPU dédié
Exemples	Lambda, Cloud Functions	Docker (+ Kubernetes)	instance GPU cloud/on-prem
Gestion serveur	zéro	moyenne	totale
Facturation	à l'exécution	à l'instance	fixe, élevée
Montée en charge	automatique	à configurer	manuelle
Limites	durée max, démarrage à froid	compétences requises	coût + expertise
Idéal pour	trafic irrégulier, petite équipe	trafic soutenu et régulier	auto-hébergement d'un modèle open-weights

Notes orateur : Point clé : le GPU (Graphics Processing Unit, processeur graphique) dédié n'est nécessaire QUE si vous hébergez le modèle vous-même — souveraineté des données ou volume extrême. Si vous appelez une API, le GPU est chez le fournisseur. 90 % des projets : serverless ou conteneur suffisent. Cold start : première requête après inactivité plus lente — acceptable ou non selon le budget de latence (boucle avec slide 12).

Slide 25 — Sécurité : les 3 règles non négociables

1. Clé API jamais côté client → toujours un backend intermédiaire, même minuscule
2. Assainir les entrées (input sanitization) : longueur max, détection d'injection de prompt
3. Filtrer les sorties (output filtering) : données sensibles, contenu inapproprié — avant affichage

Notes orateur : La règle 1 boucle avec la slide 8 — c'est voulu, répétition espacée. Règle 2 : rappel de la session sur l'injection de prompt — en production, l'attaquant existe vraiment. Règle 3 : le modèle peut régurgiter des données du contexte (ex. données d'un autre client si le RAG est mal cloisonné) — dernier filet avant l'écran de l'utilisateur.

Slide 26 — Monter en charge : horizontal + file d'attente

• Horizontal : plusieurs instances identiques derrière un répartiteur de charge (load balancer) — plutôt qu'une machine géante
• Pour l'asynchrone massif : architecture à file d'attente (queue)

Producteurs → [ File d'attente ] → Workers (au rythme du rate limit) → Résultats

Exemple : 50 000 documents/nuit, rate limit 500 req/min → la file absorbe, les workers lissent, tout est prêt au matin

Notes orateur : La file d'attente réconcilie deux rythmes incompatibles : l'arrivée massive des tâches et le débit autorisé par le fournisseur. Bonus : résilience gratuite — si le fournisseur tombe 10 minutes, la file grossit puis se vide, rien n'est perdu. C'était le scénario B de l'Exercice 2.

Slide 27 — L'architecture de SupportBot en production

Employé → Passerelle API → Backend (serverless)
              │                 │  ├── cache de prompt (fournisseur)
              │                 │  ├── routeur petit/grand modèle
              │                 │  └── retry + backoff
              │                 ▼
              │          Fournisseur LLM (streaming SSE)
              └── Journalisation → Dashboard + alertes

10 000 req/jour · p95 < 3 s · ~1 100 $/mois · zéro clé exposée

Notes orateur : Slide de synthèse — la boucle est bouclée : chaque composant répond à un problème vu dans la session. Faites nommer chaque brique par la salle : « À quoi sert la passerelle ? Le routeur ? Pourquoi le journal est-il branché partout ? » 2–3 minutes de récapitulation active.

Slide 28 — Ce qu'il faut retenir

1. La production = les 80 % invisibles du travail
2. 429 → backoff exponentiel + jitter ; jamais de retry sur 400/401/403
3. Streaming SSE : la latence perçue s'effondre, pas la latence totale
4. Coûts : caching (stable au début) + routage (bon modèle, bonne tâche) + plafonds
5. Observabilité : journaux exhaustifs, percentiles, alertes actionnables
6. Les prompts sont du code : versionnés, relus, testés en CI/CD
7. Clé API jamais côté client

Notes orateur : Lisez lentement. Chaque ligne correspond à un chantier de la slide 6. Si un participant ne retient qu'une phrase : « la production est une discipline, pas un détail ».

Slide 29 — Quiz & Exit Tickets

• Quiz : 10 QCM — 6 minutes
• Exit ticket : 1 question, 1 minute, avant de sortir

Notes orateur : Distribuez les 5 exit tickets en alternance dans la salle. Relevez-les : ils calibrent l'ouverture de la Session 9.

Slide 30 — La suite : Session 9

Vous savez déployer.

Mais comment savoir si ce que vous avez déployé est bon ?

Session 9 : évaluation avancée & amélioration continue
— évals en production, feedback utilisateurs, boucles d'amélioration

Notes orateur : Teaser en 30 secondes. Rappelez la question piège de l'Exercice 3 (le dashboard ne voit pas la qualité) : « C'est exactement le trou que la Session 9 va boucher. » Remerciez, restez disponible pour les questions individuelles.