Guides

LLMOps: faire tourner des LLM en production sans chaos

LLMOps: la méthode pour opérer des LLM en production, avec des evals, des prompts versionnés, l'observabilité, le budget tokens et des garde-fous.

Illustration pour l'article : LLMOps: faire tourner des LLM en production sans chaos

LLMOps: la prod des systèmes à tokens

Le LLMOps regroupe les pratiques qui servent à développer, déployer, observer et améliorer des applications basées sur des LLM. Concrètement, on parle moins de slides « AI strategy » et plus de pipelines rejouables: des prompts versionnés, des evals, des logs, des budgets et une gestion d'incidents.

La différence avec le MLOps tabulaire classique tient à l'objet. La sortie est du langage, donc floue. Le coût se compte souvent au token. Les dépendances externes (API de modèles, tools, MCP) bougent hors de ton contrôle. Et le « dataset » est parfois un corpus documentaire vivant.

Sans LLMOps, chaque dev garde son prompt dans un pad, la facture surprise tombe en fin de mois, et personne ne sait expliquer pourquoi la qualité a chuté mardi.

Eval: la seule boussole

Pour piloter un système LLM, tu as besoin de trois couches d'évaluation complémentaires:

  1. Des tests unitaires offline: des cas gold et des assertions déterministes sur le JSON ou la structure
  2. Des juges LLM bornés, avec une bonne dose de méfiance et un échantillon relu par un humain
  3. Du monitoring online: les thumbs, les éditions humaines et les incidents

Commence petit, avec 30 cas métier critiques, et bloque le merge dès que la régression dépasse un seuil. Un modèle « meilleur sur un bench public » qui casse tes 30 cas n'est pas une upgrade.

Pour un RAG, sépare l'eval du retrieval et celle de la génération. Pour un agent, évalue la trajectoire complète (les tools appelés), pas seulement le texte final.

Versioning: prompts, modèles, tools

Tout ce qui change le comportement du système mérite un identifiant versionné:

  • Le prompt système et les skills
  • Les paramètres comme la temperature
  • Le modèle, pinné sur un snapshot précis
  • Les tools et les serveurs MCP
  • Le corpus RAG

Logue ces identifiants sur chaque requête. Et bannis le « on a changé le prompt en prod sans ticket »: un prompt suit la même discipline que le code, avec une PR, une revue et un rollback possible.

Les feature flags complètent le dispositif: tu actives un nouveau prompt sur 5% du trafic, ou sur un workspace interne, avant de passer à 100%.

Observabilité et coût

Les traces sont la base du debug. Enregistre la latence du retrieve, de la génération et des tools, les tokens entrants et sortants, les erreurs provider et les retries, avec OpenTelemetry quand tu peux. Sans trace, déboguer un agent revient à lire des logs au hasard.

Le budget se pilote aussi: fixe un plafond par équipe, par projet et par jour, avec des alertes et des dashboards. Les multi-agents et les modes ultra multiplient les fenêtres de contexte, donc le coût n'est plus linéaire avec « un chat ».

Côté qualité online, suis le taux d'édition humaine, les rejets et les tickets support liés à l'IA. Ce sont tes vrais KPI, pas le leaderboard du vendor.

Garde-fous et déploiement

Les garde-fous couvrent l'essentiel du risque:

  • La validation de schéma sur les sorties
  • Les filtres PII
  • Une allowlist de tools
  • Une validation humaine (HITL) sur les actions à risque
  • Une sandbox pour l'exécution

Pour le design de la supervision, appuie-toi sur le guide human-in-the-loop. Côté déploiement, sépare les environnements (dev, staging, prod), sors les secrets du code, et pose des timeouts et des circuit breakers pour absorber les lags du provider. Un agent sans timeout est une facture ouverte.

Prépare enfin deux runbooks d'incident: un pour la « qualité en chute » (dernier changement, logs, rollback du prompt ou du modèle) et un pour le « coût en flambée » (top routes, multi-agent, boucles de tools).

LLMOps minimal pour une PME (checklist)

Le socle tient en sept points:

  1. Un owner est nommé pour le système IA
  2. 30 cas d'eval tournent en CI
  3. Les prompts et les modèles sont pinnés
  4. Les logs et les traces couvrent 100% du trafic prod
  5. Un budget tokens existe, avec une alerte
  6. Une validation humaine protège les actions à risque
  7. Une revue hebdo de 30 minutes suit la qualité et le coût

Une plateforme LLMOps enterprise peut attendre. Ce qui compte le jour 1, c'est d'écrire ces sept points et de les tenir.

Si vous voulez poser un socle LLMOps sur un agent ou un RAG réel, on peut cadrer le sujet ensemble en 20-40 minutes.

FAQ

C'est quoi LLMOps ?
Le LLMOps regroupe les pratiques qui servent à opérer des applications LLM en production: les evals, le versioning, l'observabilité, le suivi des coûts, les garde-fous, le déploiement et la gestion d'incidents.
LLMOps vs MLOps ?
Les deux partagent le même esprit de reproductibilité et de monitoring, mais l'objet change: le LLMOps gère du langage, des tokens, des prompts, des tools externes et des corpus documentaires plutôt que des features tabulaires seules.
Par où commencer en PME ?
Commence par une eval de 30 cas, un pin du modèle et du prompt, et des logs de tokens. Ajoute ensuite la validation humaine et le budget. La plateforme vient après la discipline.
Faut-il une plateforme LLMOps payante ?
Pas le jour 1. Les outils existants (la CI, OpenTelemetry, des tables de logs) suffisent pour démarrer. Achète une plateforme quand le volume ou la conformité l'exige.
Comment lier RAG et LLMOps ?
Un RAG a besoin d'une eval du retrieval, d'un versioning du corpus et d'un suivi de la fraîcheur. Le LLMOps fournit le cadre, et le guide RAG LLM détaille le pipeline.
Les multi-agents changent-ils LLMOps ?
Oui: ils ajoutent des traces, des tokens et des modes de panne. Les plafonds de hops et d'outils deviennent obligatoires. Le guide multi-agents et l'actu sur les contrôles des coding agents creusent le sujet.

Sources et repères

  1. Hidden Technical Debt in Machine Learning Systems

    Sculley et al., NeurIPS, 2015

    Pourquoi le modèle est la plus petite partie du système. Écrit bien avant les LLM, et toujours juste aujourd'hui.

  2. Service Level Objectives (Site Reliability Engineering)

    Google, 2016

    Comment poser des seuils qu'une équipe peut tenir. À transposer sur la latence et le taux de réponses acceptées.

  3. Semantic conventions for generative AI systems

    OpenTelemetry

    Le vocabulaire standard pour tracer les appels de modèle sans t'enfermer chez un fournisseur d'observabilité.

Articles liés

Cadrez votre premier agent IA

20 minutes pour vérifier vos outils, vos données et le premier cas utile. Sans jargon, sans engagement.