Atelier — feuille de route vers la production

Pourquoi un atelier plutôt qu'un cours

Les onze chapitres précédents ont couvert l'installation, l'optimisation, la sécurité et l'observabilité des LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire locaux. Ce dernier chapitre ne présente aucune notion nouvelle : il assemble ce qui a déjà été vu dans un format que les équipes utilisent réellement — une feuille de route. L'objectif est de passer d'un pilote qui fonctionne sur le poste d'un ingénieur à un service dont la direction technique peut assumer la responsabilité devant les utilisateurs, les auditeurs et, le cas échéant, un régulateur.

La plupart des projets de LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire local échouent non pas à cause d'un mauvais choix de modèle, mais parce qu'aucune date de bascule n'a jamais été fixée. Un pilote sans échéance devient un pilote permanent, financé sur un budget d'expérimentation, jamais audité, jamais renforcé. La checklist qui suit sert précisément à éviter ce piège.

Une mise en production n'est pas un état technique, c'est une décision organisationnelle. Le système peut être prêt techniquement plusieurs semaines avant que l'organisation ne soit prête à en porter la responsabilité. La feuille de route sert à synchroniser les deux.

La checklist go-live en trois horizons

Jour 0 à 30 — cadrer et sécuriser le socle

Cette phase ne doit produire aucune fonctionnalité visible par l'utilisateur final. Son seul objectif est de rendre l'infrastructure auditable.

• Inventaire des cas d'usage réellement demandés (pas ceux imaginés en comité de pilotage)
• Choix du ou des modèles, avec justification écrite du dimensionnement (paramètres, quantification, contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire)
• Choix du moteur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire (Ollama ou vLLM, voir plus bas) et validation du besoin GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire
• Isolation réseau : le service LLM ne doit pas avoir de sortie Internet directe une fois les poids téléchargés
• Journalisation des requêtes et des réponses, avec politique de rétention documentée
• Définition des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire interdites en entrée (secrets, données de santé, données personnelles non anonymisées selon le cas d'usage)

Beaucoup d'équipes valident le socle technique puis découvrent, trois semaines avant la bascule, qu'aucune politique de rétention des logs n'a été validée par le service juridique. Faites signer cette politique dès le jour 0, pas au jour 25.

Jour 30 à 60 — industrialiser et mesurer

Cette phase transforme le pilote en système observable et reproductible.

• Mise en place d'un pipeline d'évaluation automatisé (jeu de questions de référence, scoring reproductible)
• Définition des seuils d'alerte : latence P95, taux d'erreur, taux de refus du modèle, consommation mémoire GPU
• Test de charge représentatif du trafic réel attendu, pas seulement d'un trafic synthétique lissé
• Rédaction du runbook d'incident (voir plus bas) et répétition à blanc avec l'équipe d'astreinte
• Mise en place d'un environnement de rollback : pouvoir revenir à la version précédente du modèle ou du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire système en moins de 15 minutes

Jour 60 à 90 — bascule progressive et stabilisation

• Déploiement en canari sur un sous-ensemble d'utilisateurs ou de cas d'usage à faible risque
• Revue hebdomadaire des métriques de qualité perçue (retours utilisateurs, taux de correction manuelle)
• Extension progressive du périmètre, avec un critère d'arrêt explicite en cas de dégradation
• Formation des équipes support à l'usage du runbook d'incident
• Décision formelle de généralisation, documentée et signée par le responsable métier et le responsable technique

Ne calez jamais la fin de la phase 60-90 jours sur une date calendaire fixe communiquée en externe (« le LLM sera en production le 1er du mois »). Calez-la sur la satisfaction de critères mesurables. Une date fixe pousse à ignorer les signaux d'alerte pour « tenir le planning ».

Matrice de risques

Une matrice de risques utile tient sur une page et distingue la probabilité, l'impact et le porteur de la mitigation. En voici une version type pour un déploiement de LLM local en entreprise.

Cette matrice doit être révisée à chaque changement significatif : nouveau modèle, nouveau cas d'usage, changement de fournisseur d'infrastructure. Une matrice de risques figée après la mise en production perd rapidement sa valeur.

Plan de capacité

Le plan de capacité répond à une question simple : combien de requêtes simultanées le système peut-il servir avec une latence acceptable, et à partir de quel volume faut-il ajouter des ressources ?

Trois éléments structurent ce plan :

1. La charge de référence — nombre de requêtes par minute observé ou estimé en régime établi, avec un facteur de marge (généralement x2 à x3 pour absorber les pics).
2. Le coût unitaire par requête — temps GPU consommé par requête selon la longueur moyenne du contexte et de la réponse, mesuré empiriquement et non calculé théoriquement.
3. Le seuil de déclenchement — le niveau d'utilisation GPU (mémoire et calcul) au-delà duquel une instance supplémentaire doit être provisionnée, ou au-delà duquel le système bascule vers un modèle plus léger.

Le schéma suivant illustre le principe d'un plan de capacité à paliers, du pilote jusqu'à la bascule vers un second nœud.

Un plan de capacité mal calibré présente deux défauts symétriques : des seuils trop bas provoquent un provisionnement excessif et coûteux, des seuils trop hauts laissent le système dériver jusqu'à l'incident. Le calibrage correct s'obtient par observation réelle sur plusieurs semaines, jamais par une estimation unique en amont.

Concrètement, un plan de capacité opérationnel documente au minimum quatre chiffres pour chaque cas d'usage : le nombre moyen de requêtes par minute en heure de pointe, la longueur moyenne du contexte fourni en entrée, le temps de génération moyen par réponse, et la marge de sécurité retenue avant déclenchement d'une action. Sans ces quatre chiffres, toute discussion sur le nombre de GPU nécessaires reste une négociation à l'aveugle entre l'équipe infrastructure et l'équipe métier, où chacun défend une intuition plutôt qu'une mesure.

Il est tentant de provisionner large « pour être tranquille ». En pratique, un GPU inutilisé coûte autant qu'un GPU saturé, et ce coût s'accumule mois après mois. Mieux vaut un plan de capacité serré mais révisé chaque mois qu'un plan large jamais révisé.

Runbook d'incident

Un runbook n'est utile que s'il est rédigé pour quelqu'un qui découvre l'incident à trois heures du matin, sans le contexte du projet. Trois scénarios couvrent la majorité des incidents rencontrés en exploitation de LLM local.

Scénario 1 — saturation mémoire (OOM)

Symptôme : le service redémarre en boucle, les requêtes échouent avec une erreur d'allocation mémoire GPU.

1. Vérifier immédiatement le nombre de requêtes concurrentes et la longueur moyenne des contextes sur les cinq dernières minutes.
2. Réduire temporairement la limite de contexte maximal ou la taille des lots (batch) si le moteur le permet.
3. Si la charge dépasse la capacité provisionnée, activer le mode dégradé (modèle plus léger ou file d'attente) plutôt que de laisser le service s'effondrer.
4. Après stabilisation, analyser si l'incident provient d'un pic de trafic légitime ou d'un usage anormal (boucle applicative, script mal configuré côté client).

Scénario 2 — dérive de qualité (drift)

Symptôme : les utilisateurs signalent des réponses moins pertinentes qu'auparavant, sans changement de code apparent.

1. Comparer les réponses actuelles sur le jeu d'évaluation de référence par rapport à la dernière mesure validée.
2. Vérifier si le modèle, le prompt système ou une dépendance (bibliothèque d'inférence, quantification) a changé récemment.
3. Si la dérive est confirmée, revenir à la dernière configuration validée via l'environnement de rollback préparé en phase 30-60 jours.
4. Documenter la cause dans le registre d'incidents avant de retenter le changement, avec un test préalable sur le jeu de référence.

Scénario 3 — fuite de données

Symptôme : des informations sensibles apparaissent dans une réponse, un log, ou sont accessibles par un utilisateur non autorisé.

1. Isoler immédiatement l'accès concerné (couper l'endpoint ou révoquer les jetons d'accès plutôt que d'attendre une analyse complète).
2. Identifier le canal de fuite : contexte de conversation mal cloisonné entre utilisateurs, log non chiffré, cache partagé entre sessions.
3. Notifier le responsable sécurité et, selon la nature des données, engager la procédure de notification réglementaire applicable.
4. Corriger le cloisonnement avant de rouvrir l'accès, et ajouter un test de non-régression spécifique à ce cas.

Une fuite fréquente en environnement multi-utilisateur vient d'un cache de contexte partagé par erreur entre deux sessions distinctes lors d'un pic de charge, faute d'isolation stricte des identifiants de session dans la couche de mise en cache. Le correctif technique est simple ; le délai pour s'en rendre compte est souvent long si aucun audit de logs n'est en place.

Exercice guidé — choisir une stack pour un cas documentaire confidentiel

Contexte : un cabinet doit déployer un assistant de recherche sur un fonds documentaire interne contenant des données contractuelles confidentielles. Le volume de requêtes est modéré (quelques centaines par jour), mais la confidentialité est non négociable et deux utilisateurs avancés souhaitent aussi expérimenter des variantes de prompts.

Étape 1 — cadrer la contrainte dominante. Ici, ce n'est pas le débit qui domine, c'est la confidentialité et la simplicité d'exploitation par une équipe technique restreinte.

Étape 2 — comparer les deux options.

• Ollama : déploiement simple, empreinte opérationnelle faible, adapté à un volume modéré et à une équipe qui n'a pas de compétence dédiée à l'exploitation d'inférence à grande échelle.
• vLLM : débit supérieur grâce au traitement par lots continu, mais complexité opérationnelle plus élevée, justifiée seulement à partir d'un volume de requêtes concurrentes significatif.

Étape 3 — trancher. Pour ce cas, le volume modéré et la priorité donnée à la simplicité d'audit orientent vers Ollama, déployé sur une infrastructure isolée sans accès Internet sortant après le téléchargement des modèles. Un passage à vLLM ne se justifierait que si le volume de requêtes concurrentes venait à décupler, ou si plusieurs équipes distinctes devaient partager la même instance avec des exigences de débit strictes.

Étape 4 — définir les critères de succès mesurables.

• Latence P95 inférieure à 4 secondes pour une requête de recherche documentaire standard
• Zéro occurrence de contenu confidentiel dans les journaux exportables sans chiffrement
• Taux de réponses jugées pertinentes par échantillonnage manuel supérieur à 85 % sur le jeu d'évaluation de référence
• Temps de retour à un état stable après incident inférieur à 30 minutes, conformément au runbook

Le choix d'Ollama pour sa simplicité ne dispense pas des mesures de sécurité réseau et de journalisation. Un moteur d'inférence simple à exploiter reste un système qui traite des données confidentielles ; l'isolement réseau et la politique de logs s'appliquent quel que soit le moteur retenu.

Ce que la feuille de route ne remplace pas

Aucune checklist ne remplace le jugement d'une équipe qui connaît son contexte. Un projet à fort enjeu réglementaire justifiera une phase de cadrage plus longue que 30 jours ; un projet interne à faible risque pourra accélérer certaines étapes. La valeur de cette feuille de route n'est pas dans ses délais précis, mais dans l'ordre des priorités qu'elle impose : sécuriser et auditer avant d'industrialiser, industrialiser avant de généraliser, mesurer avant de décider.

Un dernier point mérite d'être souligné : la responsabilité d'un LLM en production ne se transfère jamais entièrement à l'outil, même le mieux configuré. Les critères de succès mesurables définis plus haut — latence, absence de fuite, pertinence, temps de résolution d'incident — ne sont utiles que s'ils sont revus périodiquement par une personne identifiée, et non archivés une fois le projet déclaré « en production ». Un service jugé stable pendant six mois peut se dégrader silencieusement si les seuils d'alerte n'ont jamais été réévalués après une évolution du volume d'usage ou un changement de version du moteur d'inférence. La feuille de route décrite dans ce chapitre ne s'arrête donc pas au jour 90 : elle boucle, à un rythme plus lent, sur elle-même.

Synthèse des livrables attendus en fin d'atelier

Avant de considérer la feuille de route comme appliquée, il est utile de vérifier que chacun des livrables suivants existe sous une forme écrite et accessible à l'équipe d'astreinte :

• Une checklist go-live datée et signée pour chacun des trois horizons
• Une matrice de risques avec porteur nommé pour chaque ligne, révisée à la dernière date de changement majeur
• Un plan de capacité chiffré, avec les quatre indicateurs cités plus haut et la date de dernière révision
• Un runbook d'incident testé à blanc, couvrant au minimum les trois scénarios présentés dans ce chapitre
• Une liste de critères de succès mesurables, distincts des critères de succès perçus par les seuls porteurs du projet

Si un seul de ces livrables manque, la mise en production reste un pilote élargi, pas un service de production au sens propre.

Cette formation touche ici sa fin. Les onze chapitres précédents ont donné les briques techniques ; cet atelier donne la méthode pour les assembler sans se précipiter vers une mise en production que l'organisation ne serait pas en mesure de soutenir dans la durée.