Le POC fonctionne. Le modèle répond bien en démo. L’équipe est enthousiaste. Et maintenant ?
Mettre un LLM en production dans un contexte métier réel, c’est une opération d’une complexité catégoriquement différente du déploiement d’une API classique. Les équipes qui l’ont découvert après coup ont payé le prix fort : réponses hors-sujet en production, coûts d’inférence qui explosent, impossibilité d’auditer un comportement problématique, régression non détectée après un changement de prompt.
LLMOps, c’est l’ensemble des pratiques qui permettent d’éviter ces écueils. Voici ce que ça couvre réellement.
Ce qui rend les LLM différents des autres composants logiciels
Un composant logiciel classique est déterministe : les mêmes inputs produisent les mêmes outputs. Un LLM est probabiliste : les mêmes inputs produisent des outputs qui varient selon la température, le sampling, et l’état interne du modèle.
Cette propriété change fondamentalement la façon dont on teste, monitore et maintient le système.
Pas de test unitaire classique. On ne peut pas écrire assertEqual(llm.generate(prompt), expected_output). On écrit des évaluations probabilistes : “sur 100 appels avec ce prompt, au moins 90% des réponses doivent satisfaire ces critères.”
Pas de versioning classique. Quand le fournisseur met à jour son modèle de base (GPT-4 → GPT-4o, Claude 2 → Claude 3), votre système change, même si vous n’avez rien touché. Et vous pouvez ne pas le savoir.
Pas de debugging classique. Comprendre pourquoi le modèle a produit une réponse particulière n’est pas aussi simple que lire une stack trace.
Source : METR, Evaluating Frontier AI (août 2024). Performance des agents IA sur des tâches nécessitant 30 min à 8h à un humain compétent. La progression entre 2019 et 2024 illustre pourquoi les pratiques LLMOps deviennent critiques : les modèles évoluent vite, et les systèmes qui les embarquent doivent suivre.
Les 5 piliers du LLMOps
1. La gestion des prompts comme du code
Le prompt engineering est du développement. Les prompts doivent être versionnés, revus, testés et déployés avec les mêmes rigueurs que du code applicatif.
Ce que ça implique concrètement :
- Les prompts sont stockés dans le dépôt de code (ou un système dédié comme LangSmith, PromptLayer)
- Chaque changement de prompt passe par une revue et une suite d’évaluations
- Le déploiement d’un nouveau prompt suit un pipeline CI/CD avec tests automatisés
- La version du prompt est loggée avec chaque appel en production
Un prompt modifié sans ces garde-fous peut dégrader silencieusement la qualité des réponses pendant des jours avant que quelqu’un s’en aperçoive.
2. L’évaluation systématique (evals)
Les evals sont l’équivalent LLM des tests automatisés. Ce sont des ensembles de cas de test avec des critères d’évaluation, exécutés avant chaque déploiement et régulièrement en production.
Types d’evals :
Evals basées sur des critères objectifs : le modèle doit extraire une date d’un texte. La date extraite est soit correcte, soit ne l’est pas. Mesurable exactement.
Evals basées sur un modèle juge : un second LLM (souvent plus puissant) évalue la qualité de la réponse selon des critères définis (pertinence, exactitude, ton, longueur). Plus flexible mais introduit sa propre variance.
Evals humaines : un panel d’évaluateurs humains note les réponses selon une grille. Coûteux, lent, mais seul moyen d’évaluer des dimensions subjectives.
Ce qu’il faut mesurer :
- Taux de réponses dans le format attendu (JSON valide, longueur respectée, etc.)
- Taux de refus inappropriés (le modèle refuse de répondre alors qu’il le devrait)
- Taux d’hallucinations détectables (affirmations factuelles vérifiables)
- Cohérence entre appels (même question → réponse cohérente)
- Dérive par rapport à une baseline de référence
3. L’observabilité en production
Monitorer un LLM en production va bien au-delà de la latence et du taux d’erreur HTTP.
Métriques techniques :
- Latence time-to-first-token (TTFT) et latence totale
- Nombre de tokens consommés (entrée + sortie), directement corrélé au coût
- Taux d’erreur API (timeout, rate limiting, context length exceeded)
- Coût par appel, coût par session utilisateur, coût total
Métriques qualité :
- Distribution des scores d’évaluation automatique sur les appels en production
- Taux de feedback négatif utilisateur (si un mécanisme de feedback existe)
- Anomalies de longueur des réponses (réponses anormalement courtes ou longues)
- Détection de patterns de réponses hors-sujet
Tracing : Les appels LLM s’insèrent dans des chaînes de traitements plus larges (RAG, agents, multi-step). Le tracing distribué (LangSmith, Arize Phoenix, ou OpenTelemetry avec des spans custom) permet de reconstituer le contexte complet d’un appel problématique.
4. La gestion du drift
Le drift en LLMOps a deux sources :
Drift du modèle : le fournisseur met à jour le modèle sous-jacent. Même si le nom de l’endpoint reste identique (“gpt-4”), le comportement peut changer. La seule protection est de pin la version exacte du modèle (gpt-4-0613 plutôt que gpt-4) et d’avoir une suite d’evals qui détecte les régressions.
Drift des données : la distribution des inputs utilisateurs change avec le temps. Un modèle entraîné ou ajusté sur des données de janvier peut mal performer sur les patterns de juillet. La surveillance de la distribution des inputs (embedding drift) permet de détecter ces glissements.
Drift des prompts : l’accumulation de modifications de prompts peut créer des incohérences non détectées si chaque modification n’est pas testée dans le contexte global.
5. La gestion des coûts
Le coût d’un LLM en production est proportionnel au nombre de tokens traités. Un système mal conçu peut générer des coûts 10x supérieurs aux estimations initiales.
Les leviers de maîtrise des coûts :
Caching : les réponses à des requêtes identiques ou très similaires peuvent être cachées. LLM providers proposent souvent un prompt caching (les tokens du système prompt ne sont pas re-facturés à chaque appel).
Routing intelligent : toutes les requêtes ne nécessitent pas le modèle le plus puissant. Un router qui dirige les requêtes simples vers un modèle moins coûteux (GPT-4o mini, Haiku) et les requêtes complexes vers le modèle premium peut diviser le coût par 5 à 10.
Optimisation des prompts : les prompts verbeux coûtent plus cher. Un audit régulier des prompts pour supprimer les instructions redondantes réduit la consommation.
Batch processing : pour les cas d’usage non temps réel (génération de rapports, enrichissement de données), le batch API est significativement moins cher (50% de réduction chez OpenAI).
Le pipeline de déploiement d’un LLM
Le shadow mode est particulièrement précieux : il permet de comparer le comportement du nouveau prompt avec l’ancien sur des requêtes réelles, sans risque pour les utilisateurs.
Ce que l’AI Act change pour le LLMOps
Pour les systèmes IA à risque élevé (systèmes de prise de décision dans des domaines réglementés : finance, santé, emploi, justice), l’AI Act impose des exigences qui se traduisent directement en pratiques LLMOps :
- Journalisation : conservation des logs d’utilisation permettant une auditabilité a posteriori
- Supervision humaine : points de contrôle humain définis pour les décisions à fort impact
- Exactitude et robustesse : métriques d’évaluation documentées et maintenues
- Transparence : documentation des capacités et limitations du système
Ces exigences ne sont pas incompatibles avec une opération efficace, à condition de les intégrer dès la conception, pas en rattrapage.
Conclusion
Mettre un LLM en production sans pratiques LLMOps, c’est comme déployer une application sans monitoring ni tests. Ça peut fonctionner un temps, mais les problèmes arrivent au pire moment.
La bonne nouvelle : les pratiques LLMOps ne sont pas des inventions. Elles s’appuient largement sur ce que le monde du DevOps a développé depuis 20 ans, adapté aux spécificités probabilistes des modèles de langage. Les équipes qui ont une culture MLOps solide ont la moitié du chemin fait.
L’autre moitié, c’est comprendre ce qui est fondamentalement nouveau : l’évaluation probabiliste, la gestion du drift de modèle, et la traçabilité dans des systèmes agentiques multi-étapes.
Vous industrialisez un usage IA dans un contexte métier critique ? Parlons de votre architecture LLMOps.