English

Slides — Session 8 : Infrastructure & Déploiement

Programme : Applied AI — Niveau Intermédiaire — Instructeur : Yann Isola
Format : 33 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 ⚠ (juillet 2026) : ~0,1–1 $/M tokens d'entrée (petits modèles) à ~2–15 $/M (grands) — vérifiez la grille du jour

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

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

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. »

Slide 18a — Levier 4 : la quantization — le JPEG des modèles

Un modèle = des milliards de poids (des nombres). Combien de bits par poids ?

  • FP16 (16 bits) : précision d'origine
  • INT8 / INT4 : on réduit les bits → on réduit la taille et on accélère

La quantization, c'est le JPEG des modèles : un peu de qualité en moins, beaucoup de poids en moins.

Slide 18b — Le compromis en chiffres

Précision Bits Modèle 70B ≈ Qualité
FP16 16 140 Go référence
INT8 (Q8) 8 70 Go quasi identique
INT4 (Q4) 4 ~40 Go −1 à −3 pts ⚠

Q4 = ~4× plus léger que FP16, pour une perte minime → un 70B tient sur du matériel grand public.

Slide 18c — En pratique : GGUF + Ollama, et QUAND s'en servir

ollama run llama3:8b-instruct-q4_K_M "Bonjour !"
# 70B : ollama pull <modele>:70b-q4_K_M  # ~40 Go, GGUF
  • API fournisseur (défaut) → la quantization ne vous concerne pas
  • Auto-hébergement (souveraineté, données sensibles, gros volume) → Q4 par défaut, montez si besoin

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

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 »

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 %)

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

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

Trois dernières questions :

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

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

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

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

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

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. Auto-hébergement : quantization Q4/GGUF pour faire tenir un grand modèle localement
  6. Observabilité : journaux exhaustifs, percentiles, alertes actionnables
  7. Les prompts sont du code : versionnés, relus, testés en CI/CD
  8. Clé API jamais côté client

Slide 29 — Quiz & Exit Tickets

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

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: 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.

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

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. »

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).

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.

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 ».

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.

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.

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).

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).

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 ».

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.

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.

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.

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.

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.

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 »).

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.

Notes orateur: Reliez à la Session 1 : l'inférence est limitée par la **bande passante mémoire**. Moins de bits à relire par token = plus vite ET plus léger. L'analogie JPEG est la clé de voûte : tout le monde a déjà compressé une photo.

Notes orateur: Faites vivre le chiffre : 140 Go = impossible sur une carte 24 Go. 40 Go = deux cartes 24 Go, ou un Mac à mémoire unifiée. Curseur : au-delà d'INT4 (ex. 2 bits), la qualité décroche visiblement — le modèle devient « flou ».

Notes orateur: `q4_K_M` = 4 bits, blocs « K », taille medium. Insistez : la quantization ne rend pas un petit modèle aussi bon qu'un grand — elle rend un **grand modèle exécutable** localement. Un 70B-Q4 > un 8B-FP16 à empreinte comparable. Transition vers l'observabilité.

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.

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. »

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.

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.

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

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).

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.

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.

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.

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 ».

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

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.