# 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 : | Attente | Perception | Réponse technique | |---|---|---| | < 1 s | instantané | rien à faire | | 1–3 s | acceptable | indicateur d'attente | | 3–10 s | frustrant | **streaming** obligatoire | | > 10 s | inacceptable en direct | passer en **asynchrone** | > **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.