# Quiz — Session 8 : Infrastructure & Déploiement **Programme :** Applied AI — Niveau Intermédiaire — Instructeur : Yann Isola **Format :** 10 QCM (questionnaire à choix multiples) — une seule bonne réponse par question — durée conseillée : 8 minutes. --- **Q1. Quelle est la différence essentielle entre un prototype en notebook et un service en production ?** - A. Le prototype utilise un modèle moins puissant que la production - B. La production doit gérer ce que le prototype ignore : authentification, pannes, latence, coûts, observabilité, sécurité et montée en charge pour des milliers d'utilisateurs - C. Le prototype est écrit en Python, la production dans un autre langage - D. Il n'y a pas de différence si le prompt est bien écrit **Q2. Pourquoi ne faut-il JAMAIS placer une clé API dans le code côté client (navigateur, application mobile) ?** - A. Parce que cela ralentit le chargement de la page - B. Parce que les fournisseurs interdisent plus de deux clés par compte - C. Parce que quiconque inspecte le code du client (outils développeur, décompilation) peut lire la clé, la voler et consommer l'API à vos frais - D. Parce que les clés API ne fonctionnent que sur les serveurs Linux **Q3. Votre application reçoit une réponse HTTP 429 (Too Many Requests). Quelle est la bonne réaction ?** - A. Réessayer immédiatement, en boucle, jusqu'à ce que ça passe - B. Attendre puis réessayer avec un backoff exponentiel (1 s, 2 s, 4 s…) et du jitter (variation aléatoire), en respectant l'en-tête `retry-after` s'il est fourni - C. Abandonner définitivement la requête : une erreur 429 signifie que le compte est banni - D. Changer de clé API pour contourner la limitation **Q4. Quelle catégorie d'erreurs ne doit-on PAS réessayer automatiquement ?** - A. Les erreurs 429 (rate limit dépassé) - B. Les erreurs 500/503 (erreur ou indisponibilité temporaire du serveur) - C. Les erreurs 400/401/403 (requête invalide, authentification manquante, accès interdit) — réessayer la même requête invalide produira la même erreur - D. Les délais d'attente réseau (timeout) **Q5. Pourquoi le streaming via SSE (Server-Sent Events, événements envoyés par le serveur) améliore-t-il l'expérience utilisateur ?** - A. Il réduit le nombre de tokens générés, donc la latence totale - B. Il rend la génération du modèle plus rapide côté fournisseur - C. Il compresse la réponse pour économiser la bande passante - D. Il affiche les tokens au fil de la génération : la latence totale ne change presque pas, mais la latence perçue s'effondre car le premier mot apparaît en moins d'une seconde **Q6. Comment le prompt caching (mise en cache du prompt) permet-il des économies pouvant atteindre ~90 % ⚠ sur la partie cachée ?** - A. Le fournisseur facture à tarif très réduit les tokens du début de prompt identiques d'une requête à l'autre (prompt système, documents, outils) — d'où la règle : contenu stable au début, contenu variable à la fin - B. Le cache stocke les réponses complètes, le modèle n'est plus jamais appelé - C. Le caching compresse les tokens pour qu'ils comptent moitié moins - D. Le caching n'économise que du temps, jamais de l'argent **Q7. Qu'est-ce que le routage de modèles (model routing) ?** - A. Répartir le trafic réseau entre plusieurs centres de données - B. Diriger chaque requête vers le modèle le moins cher capable de la traiter : un petit modèle pour les tâches simples (souvent la majorité du trafic), un grand modèle pour les tâches difficiles - C. Changer de fournisseur de LLM chaque mois selon les prix - D. Utiliser systématiquement le modèle le plus récent **Q8. Pourquoi surveille-t-on la latence en percentiles (p50, p95, p99) plutôt qu'en moyenne ?** - A. Les percentiles sont plus simples à calculer que la moyenne - B. La moyenne est toujours plus élevée que le p99 - C. La moyenne masque la queue de distribution : un service peut avoir une bonne moyenne et un p99 catastrophique — or ce sont les utilisateurs des pires cas qui se plaignent. Les SLA (Service Level Agreement, engagement de niveau de service) s'écrivent en percentiles - D. Les outils de monitoring ne savent pas calculer de moyenne **Q9. Que signifie « les prompts sont du code » en pratique ?** - A. Les prompts doivent être écrits dans un langage de programmation - B. Les prompts sont versionnés (Git), relus par des pairs et testés : à chaque PR (Pull Request, demande de fusion) qui modifie un prompt, une suite d'évaluations tourne en CI/CD (Intégration Continue / Déploiement Continu) pour détecter les régressions - C. Les prompts doivent être compilés avant d'être envoyés au modèle - D. Seuls les développeurs ont le droit de modifier les prompts **Q10. Vous devez résumer 50 000 documents chaque nuit, sans humain devant l'écran, avec un rate limit fournisseur de 500 requêtes/minute ⚠. Quelle architecture choisir ?** - A. Envoyer les 50 000 requêtes d'un coup et réessayer celles qui échouent - B. Une instance GPU (Graphics Processing Unit, processeur graphique) dédiée, indispensable pour ce volume - C. Une architecture à file d'attente (queue) : les documents sont déposés dans la file, des workers les consomment au rythme du rate limit, les résultats sont stockés pour le matin - D. Le streaming SSE, pour que les résumés arrivent plus vite --- ## Grille de correction | Question | Réponse | Rappel express | |---|---|---| | Q1 | **B** | La production = les 80 % invisibles : auth, pannes, latence, coûts, observabilité, sécurité, échelle. | | Q2 | **C** | Une clé côté client est publique de fait. Toujours un backend intermédiaire. | | Q3 | **B** | 429 → backoff exponentiel + jitter, respecter `retry-after`. | | Q4 | **C** | Les erreurs 4xx « de requête » (400/401/403) sont déterministes : réessayer est inutile. | | Q5 | **D** | Le streaming joue sur la latence *perçue* (premier token), pas sur la latence totale. | | Q6 | **A** | Cache = tokens stables du début de prompt à tarif réduit. Structure : stable d'abord, variable ensuite. | | Q7 | **B** | Le bon modèle pour la bonne tâche — souvent le plus gros levier d'économie. | | Q8 | **C** | La moyenne ment ; les percentiles révèlent l'expérience réelle des pires cas. | | Q9 | **B** | Versionnage, revue, évals en CI : les régressions de prompt se détectent avant la production. | | Q10 | **C** | Charge massive asynchrone = file d'attente + workers. Ni streaming ni GPU n'ont de sens ici. | **Barème conseillé :** 1 point par question. ≥ 8/10 : production-ready 🚀 · 6–7 : solide, revoir les points manqués · ≤ 5 : relire le guide et refaire l'Exercice 1 avant la Session 9.