L'essentiel sur le LLMOps
Le LLMOps est l'ensemble des pratiques qui rendent un système à base de LLM observable, évaluable et pilotable en production. Il répond à trois questions qu'aucun POC ne traite : est-ce que la qualité tient dans le temps, combien coûte réellement une requête, et que s'est-il passé quand un utilisateur remonte une réponse aberrante. Sans réponse à ces trois questions, un LLM reste une démonstration — pas un composant du système d'information.
Ce n'est pas du MLOps rebadgé. En MLOps, l'artefact central est le modèle et sa métrique de qualité est calculable. Avec un LLM, l'artefact qui change le plus souvent est le prompt système, le contexte injecté par le RAG, la liste des outils exposés à l'agent ou le paramétrage de température — et la métrique de qualité n'existe pas par défaut : il faut la construire cas d'usage par cas d'usage, sur un jeu d'évaluation qui reflète le métier réel.
Notre périmètre couvre six chantiers : traces distribuées de bout en bout (requête, retrieval, appels d'outils, génération, latence, tokens), évaluation continue sur jeu de référence versionné, détection de dérive (données, contexte, comportement du modèle, usage), maîtrise du coût par requête et par fonctionnalité avec budgets et alertes, versioning de prompts avec CI/CD et rollback, et garde-fous applicatifs alignés OWASP LLM. Le tout déployable sur infrastructure souveraine, sans télémétrie sortante hors UE.
Le positionnement Nehos ne change pas ici : on chiffre le ROI avant de signer, on livre et on mesure. Concrètement, un dispositif LLMOps ne se vend pas comme une assurance — il se justifie par ce qu'il permet d'arbitrer : réduire un coût d'inférence identifié, autoriser un déploiement bloqué par la conformité, ou fermer un incident qualité qu'aucune équipe ne sait aujourd'hui expliquer.
LLMOps — Mettre vos LLM sous contrôle avant qu'ils ne vous échappent
Observabilité, évaluation continue, détection de dérive, budget tokens, versioning de prompts, garde-fous et CI/CD des modèles. Nehos instrumente vos agents IA et vos pipelines RAG pour que la qualité et le coût soient mesurés en continu — pas constatés en fin de trimestre. Stack souveraine Mistral, Qdrant, OVHcloud SecNumCloud.
Nos clients types
#LLMOps : ce que ça recouvre, et ce que ça ne recouvre pas
Un LLM en production ne se comporte pas comme un logiciel classique : le même prompt produit deux réponses différentes à cinq minutes d'intervalle, la qualité se dégrade sans qu'aucune ligne de code n'ait bougé, la facture d'inférence double parce qu'on a ajouté trois documents au contexte.
Ce n'est pas du MLOps rebadgé. En MLOps, l'artefact central est le modèle : dataset, run d'entraînement, poids, avec une métrique de qualité calculable. Avec un LLM, ce qui bouge le plus souvent n'est ni le modèle ni les poids : c'est le prompt système, le contexte injecté par le RAG, les outils exposés à l'agent, la stratégie de chunking. Et la métrique de qualité n'existe pas par défaut — il faut la construire, cas d'usage par cas d'usage.
Ce que le LLMOps ne fait pas : rattraper un cas d'usage mal cadré. C'est pour ça qu'on le vend après un cadrage ROI, jamais à la place.
#Observabilité : tracer d'abord, dashboarder ensuite
L'erreur la plus fréquente consiste à commencer par un tableau de bord : volume de requêtes, latence moyenne, compteur de tokens — et quand un utilisateur signale une réponse fausse, personne ne peut rejouer ce qui s'est passé. L'observabilité LLM commence par la trace, pas par le graphique.
Une trace exploitable capture tout le chemin d'une requête : entrée utilisateur, version du prompt système, chunks récupérés avec scores et sources, appels d'outils, réponse, tokens, latence et coût. Sur une architecture LangGraph ou CrewAI, chaque nœud du graphe devient un span rattaché à la trace parente.
Deux principes : instrumenter au standard, via les conventions sémantiques GenAI d'OpenTelemetry ; héberger la télémétrie là où sont les données, une trace contenant requêtes utilisateurs et extraits de documents internes.
#Évaluation continue : construire la métrique qui n'existe pas
Sans jeu d'évaluation, la qualité se discute à coups d'anecdotes en réunion. Avec, elle se compare entre deux versions de prompt. Le golden set d'abord : cent à quelques centaines de cas écrits avec les experts métier, versionnés dans le dépôt au même titre que le code, couvrant cas nominaux, cas limites et questions hors périmètre.
Les métriques ensuite. Sur un pipeline RAG, quatre indicateurs de type RAGAS font une base solide : fidélité aux sources, pertinence, précision et rappel du contexte. Sur un agent outillé, on ajoute le taux de sélection correcte de l'outil et le taux d'échec d'exécution. L'évaluation par LLM juge apporte de la scalabilité — à condition de calibrer le juge sur un échantillon annoté humainement, sinon on mesure ses biais, pas la qualité.
L'automatisation enfin : le jeu s'exécute à chaque modification de prompt, de modèle ou de retrieval, en intégration continue, avec seuil bloquant. Une régression de fidélité empêche le déploiement, comme un test unitaire en échec. En production, on rejoue un échantillon quotidien, complété par un retour utilisateur rattaché à la trace.
#Dérive : quatre choses à surveiller
La dérive ne se manifeste pas par une panne, mais par une érosion silencieuse.
Dérive des entrées : la distribution des questions change ; on suit la part de requêtes éloignées du golden set. Dérive du contexte : le corpus vieillit, des documents sont modifiés sans réindexation ; on suit l'ancienneté des chunks servis et les scores de retrieval. Dérive du modèle : sur API managée, une mise à jour fournisseur modifie le comportement sans préavis — argument concret pour un modèle auto-hébergé à version figée, sujet traité dans la méthode Stack Souveraine Nehos. Dérive d'usage : les utilisateurs détournent l'outil — souvent le meilleur signal produit dont vous disposez, à condition de le voir.
#Coût des tokens : du budget opaque au coût unitaire
La question d'un directeur financier n'est pas « combien de tokens avons-nous consommés » mais « combien coûte une réponse, et est-ce que ça vaut le coup ». Y répondre suppose d'attribuer chaque appel à une fonctionnalité, une équipe et un environnement, dès l'instrumentation.
Les leviers sont ensuite cumulables. Router vers le modèle adéquat plutôt qu'envoyer tout vers le plus gros : une classification d'intention n'a pas besoin de Mistral Large 2 quand un Mixtral suffit. Mettre en cache les préfixes stables. Réduire le contexte : un reranking sérieux fait souvent passer de vingt chunks à cinq sans perte sur le golden set, et le coût baisse d'autant. Plafonner par budgets et alertes par environnement, pour qu'un test de charge ne se découvre pas sur la facture.
Optimiser sans jeu d'évaluation, c'est dégrader la qualité à l'aveugle. L'ordre ne change pas : instrumenter, évaluer, puis optimiser en vérifiant que les métriques tiennent.
#Versioning de prompts, garde-fous et CI/CD
Un prompt système est du code : il vit dans le dépôt, passe en revue, est versionné et déployable indépendamment de l'application. Chaque trace enregistre la version utilisée, ce qui permet de corréler une baisse de qualité à un changement précis.
La chaîne de livraison type enchaîne évaluation à seuils bloquants, non-régression sur les garde-fous, déploiement en canari, comparaison des métriques entre versions, puis généralisation ou rollback — mêmes règles pour un changement de modèle.
Trois couches de garde-fous se complètent : filtrage en entrée contre l'injection de prompt, sortie structurée validée par schéma, vérifications en sortie (citations attendues, absence de données personnelles). Cadre complet sur notre page sécurité LLM OWASP.
#Périmètre d'intervention et stack
Deux configurations. Sur un système existant : audit d'observabilité, instrumentation, golden set construit avec les métiers, évaluation continue, suivi de coût, transfert aux équipes. Sur un projet neuf, le dispositif est intégré dès la conception.
Stack de référence, souveraine et open source : Mistral Large 2 et Mixtral, Qdrant, LangGraph ou CrewAI, OpenTelemetry, PostgreSQL pour les traces, Grafana, Next.js pour les interfaces de revue. Déploiement OVHcloud, workloads sensibles sur offre SecNumCloud, aucune télémétrie sortante hors UE.
Brique amont : RAG entreprise. Catalogue : agents IA. Infrastructure : IA souveraine.
Questions fréquentes sur le LLMOps
Le MLOps s'organise autour du modèle : versionnage des datasets et des poids, pipelines d'entraînement reproductibles, métriques calculables sur un jeu de test étiqueté, surveillance de la dérive statistique des features. Le LLMOps déplace le centre de gravité. Le modèle est souvent un composant que vous ne réentraînez pas ; ce qui change au quotidien, ce sont le prompt système, le contexte injecté par le retrieval, les outils exposés à l'agent et les paramètres d'inférence. Trois conséquences pratiques. Premièrement, la métrique de qualité doit être construite : il n'y a pas de vérité terrain fournie avec le système, il faut un jeu d'évaluation écrit avec les métiers. Deuxièmement, la brique d'observabilité doit tracer une chaîne d'appels — retrieval, outils, génération — et pas seulement une prédiction. Troisièmement, le coût est variable et proportionnel au contexte, ce qui en fait une métrique de production à part entière, au même titre que la latence. Le LLMOps réutilise les principes du MLOps (reproductibilité, tests, livraison continue) mais sur des artefacts différents.
Par les traces, systématiquement. Tant que vous ne pouvez pas rejouer une requête problématique de bout en bout — prompt appliqué, chunks récupérés, outils appelés, réponse générée, tokens et latence — tout le reste est de l'interprétation. L'instrumentation initiale se pose en quelques jours sur une application déjà structurée, à condition d'utiliser un standard comme les conventions sémantiques GenAI d'OpenTelemetry plutôt qu'un agent propriétaire. Une fois les traces disponibles, deux semaines de production suffisent généralement à faire apparaître les vrais sujets : requêtes récurrentes hors périmètre, chunks systématiquement inutiles, fonctionnalité minoritaire qui consomme la majorité du budget tokens. C'est seulement ensuite qu'on construit le golden set et qu'on branche l'évaluation continue, parce que les traces vous disent quels cas doivent y figurer. Commencer par le tableau de bord donne l'illusion du pilotage sans la capacité de diagnostic.
En croisant des signaux indirects plutôt qu'en cherchant une métrique unique. Sur les entrées, on suit la distribution des requêtes et la part de questions éloignées du golden set — une hausse signale que le périmètre réel s'écarte du périmètre conçu. Sur le contexte, on suit l'ancienneté des documents servis, le taux de réindexation et l'évolution des scores de retrieval : un corpus qui vieillit dégrade la qualité bien avant que le modèle soit en cause. Sur la génération, on rejoue quotidiennement un échantillon du jeu d'évaluation et on surveille la tendance des métriques de fidélité et de pertinence, ainsi que le taux d'abstention — un système qui se met à répondre à tout est souvent plus inquiétant qu'un système qui refuse. Sur l'usage enfin, le retour explicite des utilisateurs, rattaché à la trace, reste le signal le plus rapide. Aucun de ces indicateurs ne prouve à lui seul une dérive ; leur convergence, oui, et c'est ce qui déclenche une revue.
En optimisant dans un ordre précis. D'abord attribuer : chaque appel doit porter une étiquette de fonctionnalité, d'équipe et d'environnement, sinon vous arbitrez sans savoir d'où vient la dépense. Ensuite router : une classification d'intention, une extraction structurée ou une reformulation ne justifient pas le plus gros modèle disponible ; un Mixtral traite ces tâches à une fraction du coût de Mistral Large 2, réservé aux réponses finales exigeantes. Ensuite mettre en cache les préfixes de prompt stables et les réponses aux questions récurrentes. Ensuite réduire le contexte : c'est souvent le levier le plus rentable, parce qu'un reranking correct permet de passer de vingt chunks injectés à cinq, avec un coût qui baisse dans la même proportion. Enfin plafonner par des budgets et des alertes par environnement. La règle non négociable : chaque optimisation est validée en rejouant le jeu d'évaluation. Sans cette vérification, vous ne réduisez pas un coût, vous déplacez un problème vers la qualité.
Non, mais l'auto-hébergement résout deux problèmes que l'API managée ne résout pas. Premier problème : la stabilité de version. Sur une API managée, une mise à jour côté fournisseur peut modifier le comportement du modèle sans que vous ayez rien changé — ce qui rend vos comparaisons entre versions de prompt difficilement interprétables. Un modèle auto-hébergé, avec version figée et migration décidée par vous, supprime cette variable. Second problème : la circulation des données. Les traces LLM contiennent des requêtes utilisateurs et des extraits de documents internes ; sur des cas d'usage juridiques, RH ou de santé, les envoyer vers un service hors UE contredit l'effort de conformité mené par ailleurs. Cela dit, on peut parfaitement faire du LLMOps rigoureux sur API managée, à condition d'épingler la version du modèle quand le fournisseur le permet, de conserver les traces sur votre propre infrastructure et de rejouer le jeu d'évaluation à chaque annonce de mise à jour.
Cela dépend surtout de la maturité de l'application existante, pas du volume. Sur une application correctement structurée, l'instrumentation et la collecte des traces se posent en quelques jours. La constitution du golden set avec les experts métier est l'étape la plus longue en temps calendaire, parce qu'elle dépend de leur disponibilité : comptez plusieurs ateliers étalés sur deux à quatre semaines pour couvrir cas nominaux, cas limites et refus attendus. Le branchement de l'évaluation dans la chaîne d'intégration continue, avec seuils bloquants et déploiement en canari, s'ajoute ensuite. Un dispositif complet — traces, évaluation continue, suivi de coût, versioning de prompts, garde-fous — se met en place sur un ordre de grandeur de six à dix semaines pour un premier cas d'usage, puis se réplique beaucoup plus vite sur les suivants puisque l'outillage est mutualisé. Le chiffrage précis se fait après un cadrage : on estime la charge, on la met en face du gain attendu, et on vous dit si l'investissement se justifie.