Le LLMOps regroupe les pratiques qui permettent de faire fonctionner durablement des applications fondées sur des LLM : évaluer chaque changement avant de le déployer, observer le comportement réel en production et maîtriser un coût qui varie à chaque requête. Il prolonge le MLOps, mais s'en distingue sur trois points : les sorties ne sont pas déterministes, le comportement change dès qu'on modifie un prompt ou une version de modèle, et la facture dépend directement du volume de texte traité.
La réponse courte à la question « comment exploiter un LLM en production » tient en trois boucles : une boucle d'évaluation qui bloque les régressions, une boucle de supervision qui détecte les dérives, et une boucle FinOps qui relie chaque jeton consommé à une unité métier. Aucune des trois ne fonctionne sans l'autre : réduire le coût sans mesurer la qualité dégrade le service, et mesurer la qualité sans tracer les requêtes ne permet pas de diagnostiquer.
Cet article détaille ces trois boucles et l'organisation nécessaire pour les faire tourner, côté intégration et exploitation.
Ce que le LLMOps ajoute au MLOps
En MLOps classique, l'artefact à gérer est principalement le modèle entraîné. Avec un LLM consommé ou auto-hébergé, le comportement de l'application dépend d'un ensemble plus large, dont chaque élément doit être versionné et déployé comme du code :
- le modèle et sa version exacte, y compris chez un fournisseur d'API qui fait évoluer ses modèles ;
- les prompts système et les gabarits de prompts ;
- les paramètres de génération (température, longueur maximale de sortie, format imposé) ;
- la configuration de recherche documentaire et des outils appelés, le cas échéant ;
- les jeux d'évaluation et les seuils d'acceptation associés.
Une modification de prompt est donc une mise en production à part entière. Elle passe par le même circuit que le code : revue, évaluation automatique, déploiement progressif, possibilité de retour arrière immédiat.
Évaluer avant de déployer : jeux de référence, seuils et LLM juge
Le profil d'IA générative du NIST AI RMF (NIST AI 600-1, juillet 2024) recommande d'évaluer les capacités et la robustesse des systèmes avant leur déploiement puis de manière continue, d'utiliser des seuils minimaux de performance comme critères de décision pour la mise en production, et de recourir au red teaming contre l'injection de prompt et l'empoisonnement de données 1. Traduit en pratique d'exploitation, cela donne un pipeline d'évaluation déclenché à chaque changement.
Ce pipeline combine trois familles d'évaluateurs, du moins coûteux au plus coûteux :
- Contrôles déterministes : format JSON valide, présence des champs obligatoires, absence de données interdites, longueur, langue.
- Comparaison à une référence : réponse attendue, document source attendu, classification correcte.
- Évaluation par un LLM juge pour les critères qualitatifs (exactitude, complétude, ton), calibrée sur un échantillon noté par des experts humains.
Le LLM juge est utile mais imparfait. Les travaux qui l'ont popularisé ont identifié des biais de position, de verbosité et d'auto-complaisance, tout en constatant que des juges performants atteignaient plus de 80 % d'accord avec les préférences humaines, un niveau comparable à l'accord entre humains 2. Il faut donc mesurer régulièrement l'accord entre le juge et vos annotateurs, alterner l'ordre des réponses comparées et éviter de faire juger un modèle par lui-même.
Une modification de prompt est une mise en production à part entière.
Superviser en production : traces, métriques et qualité
L'observabilité d'une application LLM repose sur des traces qui relient la requête de l'utilisateur, les appels au modèle, la recherche documentaire et les outils invoqués. OpenTelemetry définit pour cela des conventions sémantiques dédiées à l'IA générative, désormais maintenues dans un dépôt spécifique et toujours au statut « Development » à la date de rédaction. Elles prévoient notamment les métriques gen_ai.client.token.usage, gen_ai.client.operation.duration et gen_ai.client.operation.time_to_first_chunk côté client, gen_ai.server.time_to_first_token côté serveur, ainsi que des métriques propres aux agents et aux outils 3. Le statut de développement implique que des noms peuvent encore changer : adoptez-les, mais figez la version utilisée et prévoyez les migrations.
Au-delà des métriques techniques, la supervision doit couvrir la qualité perçue. Les indicateurs utiles en exploitation sont les suivants :
- latence de bout en bout et délai avant le premier jeton, en percentiles et non en moyenne ;
- taux d'erreurs et de dépassements de délai, par modèle et par fournisseur ;
- jetons d'entrée et de sortie par requête, pour détecter un contexte qui gonfle ;
- taux de refus, de réponses vides ou de réponses « je ne sais pas » ;
- retours explicites des utilisateurs et score du LLM juge sur un échantillon de trafic réel.
La journalisation des prompts et des réponses est indispensable au diagnostic, mais elle crée un nouveau stock de données potentiellement personnelles ou confidentielles. Masquage à la source, durées de conservation courtes et accès restreint aux journaux complets doivent être décidés avant la mise en production, pas après le premier incident.
Maîtriser le coût des LLM : du jeton à l'unité métier
Les travaux de la FinOps Foundation sur l'IA recommandent de suivre le coût par inférence, par jeton et par appel d'API, puis de le rapporter à des unités métier, par exemple le coût par appel au service client. Ils soulignent que l'allocation est plus difficile que pour des charges classiques lorsqu'un même modèle sert plusieurs interfaces, conseillent une refacturation indicative (showback) pour responsabiliser les équipes, une budgétisation ascendante plutôt que descendante et l'alignement de la qualité du modèle sur la difficulté réelle de la tâche 4.
Les leviers techniques sont connus, et leur effet se mesure sur le jeu d'évaluation avant d'être généralisé :
- Router les requêtes simples vers un modèle plus petit et réserver les grands modèles aux tâches qui le justifient.
- Exploiter la mise en cache des préfixes de prompts : chez Anthropic, par exemple, la lecture d'un prompt en cache est facturée 0,1 fois le prix d'entrée de base, et moins encore sur certains modèles récents 5.
- Basculer les traitements non interactifs vers les API de traitement par lots, facturées 50 % moins cher chez ce même fournisseur à la date de rédaction 5.
- Plafonner la longueur des sorties et réduire le contexte injecté aux fragments réellement utiles.
- Mettre en cache les réponses à des questions identiques lorsque le cas d'usage le permet.
Le coût est aussi un risque de sécurité
L'OWASP classe la consommation non bornée parmi les dix principaux risques des applications LLM : requêtes surdimensionnées ou répétées qui saturent le service, et « déni de portefeuille » qui fait exploser la facture d'un service payé à l'usage. Les parades recommandées sont la limitation de débit, les quotas par utilisateur, la validation de la taille des entrées, les délais maximaux et la détection d'anomalies de consommation 6. Une passerelle LLM commune, placée devant tous les modèles, est l'endroit naturel pour appliquer ces contrôles et collecter les métriques de coût.
Organiser l'exploitation : rôles et rituels
Le LLMOps échoue rarement pour des raisons techniques ; il échoue faute de propriétaire. Chaque application LLM doit avoir un responsable produit, qui arbitre qualité et coût, et une équipe d'exploitation, qui tient les seuils. Quelques rituels suffisent à installer la discipline :
- Toute modification de modèle, de prompt ou de paramètres passe par le pipeline d'évaluation et un déploiement progressif.
- Une revue mensuelle croise qualité, incidents, consommation et coût par unité métier.
- Un plan de réponse aux incidents couvre les dérives de qualité, les fuites de données et les pannes du fournisseur, avec un mode dégradé documenté.
- Le jeu d'évaluation s'enrichit chaque mois des cas réels mal traités en production.
Une attention particulière va aux modèles consommés par API. Le fournisseur annonce des dépréciations et publie de nouvelles versions à son rythme : chaque annonce doit déclencher une campagne d'évaluation sur la version cible, bien avant la date de retrait. Référencer explicitement une version datée du modèle dans la configuration, plutôt qu'un alias qui pointe vers « la dernière version », évite qu'une mise à jour silencieuse ne modifie le comportement de l'application sans passer par le pipeline.
Conclusion
Le LLMOps n'est pas une nouvelle plateforme à acheter, mais une discipline d'exploitation : versionner tout ce qui influence le comportement, évaluer avant chaque changement, tracer chaque requête avec des conventions ouvertes et piloter le coût par unité métier. Les organisations qui installent ces trois boucles tôt peuvent changer de modèle sereinement ; les autres découvrent leurs régressions par les utilisateurs et leurs dépassements par la facture. DATASWING accompagne la mise en place de cette chaîne d'exploitation, de la passerelle à l'observabilité.
— Questions fréquentes
Ce qu'on nous demande souvent
Quelle différence entre MLOps et LLMOps ?+
Le MLOps gère surtout le cycle de vie de modèles entraînés en interne. Le LLMOps ajoute la gestion des prompts, des versions de modèles fournis par des tiers, des paramètres de génération et de la recherche documentaire, avec des sorties non déterministes à évaluer par des jeux de référence et des juges. Le coût variable par jeton devient aussi un indicateur d'exploitation de premier plan.
Comment évaluer un LLM en production ?+
En combinant des contrôles déterministes (format, champs obligatoires), des comparaisons à des réponses de référence et un LLM juge calibré sur des annotations humaines. Ces évaluations sont rejouées à chaque modification de prompt ou de modèle, avec des seuils bloquants, puis appliquées à un échantillon du trafic réel, complété par les retours des utilisateurs.
Comment réduire le coût d'un LLM en production ?+
Les principaux leviers sont le routage des requêtes simples vers des modèles plus petits, la mise en cache des prompts répétés, le traitement par lots des tâches non interactives, le plafonnement des sorties et la réduction du contexte injecté. Chaque levier doit être validé sur le jeu d'évaluation pour vérifier qu'il ne dégrade pas la qualité, et suivi par un coût par unité métier.
Quelles métriques suivre pour superviser un LLM ?+
Au minimum la latence en percentiles, le délai avant le premier jeton, les taux d'erreur, les jetons d'entrée et de sortie par requête, le coût par requête et par unité métier, ainsi qu'un indicateur de qualité issu des retours utilisateurs ou d'un juge automatique. Les conventions GenAI d'OpenTelemetry offrent un vocabulaire commun pour ces mesures.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
- [1]
- [2]
-
[3]
Semantic conventions for generative AI metrics ↗OpenTelemetry (dépôt semantic-conventions-genai) · 2026
-
[4]
FinOps for AI Overview ↗FinOps Foundation · 2026-02
-
[5]
Pricing ↗Anthropic (documentation Claude Platform) · 2026
-
[6]
LLM10:2025 Unbounded Consumption ↗OWASP GenAI Security Project · 2025
