Le LLMOps est la discipline qui transforme les applications à base de modèles de langage en services véritablement maîtrisables. Une PME n'a pas besoin d'une plateforme énorme : elle doit savoir quels modèles elle utilise, évaluer des tâches réelles, versionner les prompts et les connaissances, déployer avec des portes de contrôle, superviser la qualité et le coût, gérer les incidents et pouvoir revenir à une version sûre.
Inventaire minimal
Chaque application doit consigner :
- le propriétaire ;
- la finalité ;
- le modèle et le fournisseur ;
- la version et la région ;
- le prompt/la politique ;
- les données et le RAG ;
- les outils ;
- les permissions ;
- les métriques ;
- le coût ;
- le statut et la date.
Les fonctionnalités d'IA intégrées dans des SaaS comptent aussi : sans ce registre, impossible de savoir combien d'applications à base de modèles de langage fonctionnent réellement dans l'entreprise.
Environnements
Séparer développement, évaluation et production. Les tests n'utilisent pas de données réelles sans nécessité. Identifiants et limites diffèrent selon l'environnement.
Le passage en production exige une validation et des preuves. Le prompt ne se modifie jamais directement en production sans version, car ce contrôle évite les changements improvisés que personne ne peut ensuite expliquer ni annuler.
Versionner le système complet
La réponse dépend :
- du modèle ;
- des paramètres ;
- du prompt ;
- des outils ;
- de la politique ;
- de l'index et des documents ;
- du code ;
- du format de sortie.
Une « version de l'agent » doit figer toutes ces dépendances pour reproduire une défaillance ; sans ce figeage, deux exécutions apparemment identiques peuvent donner des résultats différents.
Évaluation
Le jeu de test contient des cas ordinaires, des cas limites, des questions sans réponse, des données incomplètes, des attaques et des échecs d'outils.
Métriques :
| Couche | Métrique |
|---|---|
| Résultat | exactitude, exhaustivité et format |
| Fidélité | ancrage dans les sources |
| Sécurité | fuite, injection et action interdite |
| Exploitation | latence, disponibilité et coût |
| Humaine | corrections, escalades et adoption |
| Impact | réclamations et préjudice |
Les classes critiques ont une tolérance zéro : un échec sur l'une d'elles bloque le passage en production, même si les autres métriques s'améliorent.
Tests de régression
Ils s'exécutent à chaque changement de modèle, de prompt, de fournisseur, de source, d'outil ou de politique. La nouvelle version et la précédente sont comparées sur le même jeu de test.
Une version n'est jamais promue simplement parce qu'elle est meilleure en moyenne si elle dégrade des cas critiques.
Déploiement progressif
- Mode fantôme, sans action.
- Utilisateurs internes.
- Population limitée.
- Automatisation à faible impact.
- Montée en charge conditionnée.
Chaque phase a des critères de sortie et un plan de retour arrière, car avancer sans les respecter reporte directement le risque sur les utilisateurs réels.
Observabilité
La trace inclut :
- la requête et l'identité ;
- la version ;
- les sources ;
- les outils ;
- les validations ;
- la réponse ;
- l'approbation ;
- les tokens, le coût et la latence ;
- le retour utilisateur.
Les données personnelles et les secrets sont réduits au minimum. Les journaux ne sont pas une copie indiscriminée des conversations : l'objectif est de pouvoir reconstituer ce qui s'est passé, pas d'accumuler des informations superflues.
Alertes
- hausse des erreurs ;
- augmentation de l'abstention ;
- coût anormal ;
- latence p95 ;
- outils rejetés ;
- changements de distribution ;
- documents obsolètes ;
- accès refusé ;
- boucles.
Chaque alerte a un propriétaire et un runbook, car une alerte que personne ne traite équivaut à ne pas avoir d'alerte du tout.
Sécurité et chaîne d'approvisionnement
L'OWASP met en avant des risques liés aux modèles, aux données, aux dépendances et aux plateformes. Ce qui est vérifié :
- provenance des modèles ;
- hachages et signature ;
- paquets ;
- permissions ;
- injection de prompt ;
- sortie non fiable ;
- secrets ;
- fournisseurs ;
- SBOM le cas échéant.
Une sortie du modèle n'est jamais exécutée sans validation : la confiance dans le modèle ne remplace pas la vérification de ce qu'il produit.
Gestion des coûts
Des budgets sont fixés par application, par utilisateur et par tâche. Le coût est mesuré par résultat valide.
Techniques :
- routage selon la difficulté ;
- modèles plus petits ;
- contexte minimal ;
- cache avec expiration ;
- limites du nombre d'étapes ;
- récupération sélective ;
- traitement par lots.
On ne réduit jamais le coût au détriment des preuves ou de la sécurité, car cette économie coûte généralement bien plus cher dès qu'un incident survient.
Incidents
La procédure doit permettre de :
- arrêter ;
- révoquer les identifiants ;
- identifier la version ;
- reconstituer les actions ;
- revenir en arrière ;
- évaluer les personnes et les données concernées ;
- corriger le jeu de test ;
- communiquer.
Les enseignements tirés sont intégrés à l'évaluation, afin que le même échec ne passe plus inaperçu dans la version suivante.
Fournisseurs
Surveiller les changements de conditions, de modèles, de prix, de régions, de sous-traitants et de limites. Tout changement annoncé par le fournisseur déclenche une régression et, le cas échéant, une revue de confidentialité.
Gouvernance légère
| Rôle | Responsabilité |
|---|---|
| Product owner | valeur et périmètre |
| Équipe technique | architecture et exploitation |
| Sécurité | menaces et réponse |
| Juridique/DPO | obligations et données |
| Métier expert | jeu de test et acceptation |
| Direction | risque et ressources |
Plan sur 60 jours
Jours 1–15
Inventaire, propriétaires et risques.
Jours 16–30
Jeu de test, métriques et versions.
Jours 31–45
Traces, alertes, sécurité et coûts.
Jours 46–60
Pilote, retour arrière et incidents.
Erreurs fréquentes
- Ne versionner que le modèle.
- Tester avec les exemples du prompt.
- Mesurer une préférence subjective.
- Changer de fournisseur sans régression.
- Enregistrer des secrets.
- Ne pas plafonner le coût.
- Ne pas avoir de retour arrière.
- Ne pas tester les attaques.
- Ignorer le RAG.
- Ne pas avoir de propriétaire.
Checklist
- Inventaire.
- Versionnement complet.
- Évaluation indépendante.
- Portes critiques.
- Environnements.
- Traces et alertes.
- Sécurité et chaîne d'approvisionnement.
- Budgets.
- Incidents et retour arrière.
- Revue du fournisseur.
Questions fréquentes
Le LLMOps est-il réservé aux grandes entreprises ?
Non. Les contrôles peuvent être mis en œuvre avec des outils simples, à condition d'être reproductibles.
Faut-il conserver tous les prompts ?
Pas sans discernement. Il faut conserver les preuves nécessaires, avec minimisation et sécurité.
Qu'est-ce qui déclenche une régression ?
Tout changement de modèle, de prompt, d'outil, de données, d'index, de politique ou de fournisseur.
Sources consultées
Summum IA peut mettre en œuvre l'évaluation, l'observabilité, la sécurité et le contrôle des coûts de vos applications à base de modèles de langage, en coordination avec vos agents d'IA.