❓ Quiz — intermediate/session-08

Question 1 — 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

Question 2 — 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

Question 3 — 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

Question 4 — 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)

Question 5 — 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

Question 6 — 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

Question 7 — 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

Question 8 — 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

Question 9 — 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

Question 10 — 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

Question 11 — Qu’est-ce que la quantization d’un modèle, et à quoi sert-elle ?

A Limiter le nombre de requêtes par minute pour rester sous le rate limit B Réduire le nombre de bits par poids (ex. FP16 → INT8 → INT4) : le modèle occupe moins de mémoire et se lit plus vite, au prix d’une légère perte de qualité — c’est « le JPEG des modèles » C Compresser les tokens du prompt pour qu’ils coûtent moins cher à l’API D Entraîner un petit modèle pour qu’il devienne aussi bon qu’un grand

Question 12 — Vous devez auto-héberger un modèle open-weights de 70 milliards de paramètres (souveraineté des données) sur deux cartes de 24 Go de VRAM. En FP16 il pèse ≈ 140 Go. Quelle approche est la plus raisonnable ?

A Impossible : il faut obligatoirement passer par l’API d’un fournisseur B Le charger tel quel en FP16 : les 140 Go tiendront sur 48 Go de VRAM C Le quantifier en INT4 (Q4, format GGUF) : il tombe à ~40 Go, tient sur les deux cartes, avec une perte de qualité généralement minime (1–3 points ⚠) D Le découper en 70 petits modèles d’un milliard de paramètres exécutés l’un après l’autre

Question 13 — Dans une architecture IA d’entreprise, que signifie réellement Zero Data Retention (ZDR) ?

A Le fournisseur ne facture pas les tokens d’entrée B Le fournisseur ne conserve pas les prompts/réponses, et idéalement pas les métadonnées exploitables ; cela réduit l’exposition mais ne remplace pas un environnement possédé C Le modèle oublie automatiquement ses poids après chaque requête D L’application n’a plus besoin de logs internes

Question 14 — Pour une charge de travail contenant des secrets industriels critiques, quelle option offre l’assurance structurelle la plus forte ?

A API standard avec une clause contractuelle de confidentialité B Cloud avec ZDR, sans autre contrôle technique C Environnement possédé et isolé (owned / air-gapped), éventuellement avec modèle open-weights quantifié si l’auto-hébergement est requis D Changer régulièrement de fournisseur pour réduire la dépendance

Quiz — Session 8 : Infrastructure & Déploiement