DevOps vs MLOps vs LLMOps : comment l’IA générative est passée en production

Le schéma courant présente trois pipelines comme des générations successives. Il aide à s’orienter, mais masque l’essentiel : DevOps, MLOps et LLMOps ne sont ni des produits concurrents ni des remplacements successifs. Ce sont des réponses opérationnelles à des artefacts toujours plus difficiles à définir et à vérifier. Le logiciel a ajouté l’automatisation de la livraison ; le machine learning, les données et le comportement statistique ; les modèles de fondation, le contexte en langage naturel, les fournisseurs externes, les outils et le risque sémantique.

Voici l’histoire documentée de cette évolution et, surtout, un guide de ce qu’une équipe LLMOps doit réellement exploiter. Il n’existe pas de date de naissance universellement reconnue pour MLOps ou LLMOps ; la chronologie retient donc des jalons vérifiables plutôt que d’inventer un auteur unique.

Trois noms, trois artefacts à maintenir

Ces frontières ne sont pas rigides. Un produit LLM a toujours besoin de CI/CD, secrets, réseaux, rollbacks et SLO. S’il possède ses poids, il lui faut aussi la traçabilité des données et un registre de modèles. LLMOps étend DevOps et MLOps ; il ne les efface pas.

2009 : DevOps et le problème du passage de relais

À Velocity 2009, John Allspaw et Paul Hammond présentent 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.^[flickr] Le titre contient déjà la thèse : livrer souvent repose moins sur un héros jetant un paquet par-dessus un mur que sur la coopération et l’automatisation. Le premier DevOpsDays se tient à Gand la même année.^[devopsdays]

Anecdote documentée : dix déploiements par jour paraissent provocateurs quand beaucoup d’organisations publient au trimestre. L’enseignement n’est pas le chiffre dix. De petits changements raccourcissent le feedback et partagent la responsabilité. DORA formalisera ensuite les métriques de livraison et montrera que vitesse et stabilité ne sont pas nécessairement opposées.^[dora]

2015–2017 : lorsque l’artefact commence à apprendre

Avec le ML, le comportement ne provient plus du seul code. Il dépend des données, transformations, hyperparamètres et du monde de production. L’article de Google sur la dette technique cachée popularise deux images : le code du modèle n’est qu’une petite partie du système ; dans un système enchevêtré, modifier une chose peut tout modifier.^[debt]

D’où le besoin aujourd’hui appelé MLOps : reproduire données et features, valider les schémas, suivre expériences et modèles, éviter l’écart training-serving, surveiller le drift et déclencher le réentraînement. En 2017, le ML Test Score propose 28 tests et besoins de monitoring pour la production.^[mltest]

Une histoire mesurée : le papier TFX raconte comment Google remplace des scripts de liaison fragiles par des composants standardisés. Pour un déploiement Google Play alimenté par de nouvelles données, les auteurs rapportent des cycles plus rapides, un passage en production réduit de mois à semaines et 2 % d’installations supplémentaires associés à une meilleure analyse des données et des modèles.^[tfx] C’est le résultat de ce cas, pas une promesse générale.

MLOps ajoute à CI/CD la livraison continue du pipeline et le continuous training. Le guide Google Cloud distingue processus manuel, pipeline ML automatisé et automatisation CI/CD complète.^[mlops]

2020–2022 : du modèle isolé au système de fondation

Trois évolutions préparent LLMOps. RAG associe en 2020 mémoire paramétrique et index externe, donc connaissance actualisable et provenance.^[rag] Le rapport Stanford de 2021 consolide ensuite le terme foundation model : un modèle largement entraîné et adaptable, puissant levier dont les défauts peuvent aussi se propager à de nombreux produits.^[foundation]

En 2022, InstructGPT montre que le feedback humain change fortement l’utilité : sur la distribution de prompts étudiée, les évaluateurs préfèrent le modèle de 1,3 milliard de paramètres à GPT‑3 de 175 milliards, même s’il commet encore des erreurs simples.^[instruct] HELM défend la même année une évaluation multidimensionnelle et transparente plutôt qu’un score unique.^[helm]

Le mot LLMOps se diffuse dans ce contexte. Il ne signifie pas « MLOps plus un prompt » et n’impose pas d’entraîner un modèle de fondation. Beaucoup d’applications exploitent API, prompts, retrieval, outils et règles sans entraîner de poids. Leur unité de changement est le système LLM composé.

Ce que LLMOps exploite réellement

1. Un bundle versionné, pas un prompt isolé

Une version déployable identifie au minimum : fournisseur et version du modèle, paramètres d’inférence, messages système et templates, schémas d’outils, corpus RAG, parseur, chunking, embeddings et index, politiques de sécurité, jeu d’évaluation et code d’orchestration. Deux exécutions au prompt visible identique deviennent deux produits si l’un de ces éléments change.

La promotion doit être immuable : app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id. Sans reconstruction de cet ensemble, ni explication d’incident ni rollback fiable.

2. Évaluer avant d’optimiser

Le logiciel compare une sortie attendue. Le langage admet plusieurs bonnes formes et des réponses éloquentes mais fausses. LLMOps commence donc par un dataset d’évaluation issu de tâches réelles, de cas limites et d’abus prévisibles. Chaque exemple exige une grille, pas seulement une chaîne « parfaite ».

• Qualité métier : exactitude, exhaustivité, format et respect des instructions.
• RAG : recall du retriever, pertinence du contexte, fidélité et qualité des citations ; retrieval et génération doivent être évalués séparément.
• Sécurité : injections directes et indirectes, fuite de données, abus d’outils et contenus interdits.
• Exploitation : latence de bout en bout, tokens, coût, retries, erreurs et saturation des quotas.

Les juges LLM facilitent le passage à l’échelle, mais restent des modèles : il faut les calibrer avec des humains, les versionner et conserver les désaccords. Une vraie gate combine tests déterministes, juges, tests adversariaux et échantillonnage humain.

3. RAG comme pipeline de données en ligne

RAG ne consiste pas à « brancher une base vectorielle ». La chaîne est : autorisation des documents → extraction → nettoyage → chunking → embeddings → indexation → retrieval → reranking → construction du contexte → génération → citations. Chaque flèche peut régresser.

Il faut versionner corpus et index, mesurer la fraîcheur, appliquer les ACL, conserver les identifiants de chunks dans les traces et tester avec des questions aux sources connues. Le retrieval améliore l’ancrage sans transformer la sortie en vérité ni supprimer l’injection de prompt ; OWASP le précise.^[owasp]

4. Observabilité sémantique et FinOps

Un HTTP 200 ne dit pas si la réponse est utile. Une trace doit relier entrée, politique, retrieval, reranking, appels modèle, outils, retries et sortie. OpenTelemetry définit des conventions pour modèles, tokens, messages et appels d’outils ; la capture du contenu doit rester facultative, car il peut être sensible.^[otel]

Les tableaux de bord utiles croisent qualité et exploitation : réussite et groundedness par version, latences p50/p95/p99, tokens, coût par tâche terminée, cache hit rate, profondeur de l’agent, erreurs d’outils et escalades humaines. Un token bon marché devient cher si l’agent boucle.

Les SLO partent de l’expérience utilisateur — disponibilité, latence et correction.^[sre] Exemple : « 95 % des questions autorisées sur une politique reçoivent en moins de six secondes une réponse avec citation valide, sans fuite entre tenants ».

5. Sécurité, gouvernance et limites d’agence

Le modèle reçoit données et instructions par le même canal. Cette ambiguïté fait de l’injection de prompt un problème d’architecture, pas un filtre final. OWASP maintient un catalogue de risques LLM ; le profil NIST structure les actions de gouvernance, mesure et gestion du risque génératif.^{[nist][owasp]}

• Traiter textes récupérés, pages web et résultats d’outils comme non fiables.
• Appliquer le moindre privilège par outil ; séparer lire, proposer et exécuter.
• Valider les sorties avant SQL, shell, e-mail, paiement ou changement d’infrastructure.
• Exiger une approbation humaine pour les actions irréversibles ou à fort impact.
• Définir rétention, masquage des PII, résidence et accès aux prompts et traces.
• Prévoir kill switch, limites d’étapes et de budget, timeouts et rollback.

Un pipeline LLMOps de production en neuf étapes

1. Définir tâche et risque : décision, permissions, responsabilité et interdits.
2. Créer le jeu d’évaluation : cas normaux, limites, langues, groupes pertinents et attaques.
3. Choisir selon les contraintes : qualité métier, latence, confidentialité, région, contexte, outils et coût.
4. Construire le contexte : RAG si connaissance ou traçabilité ; préserver ACL, provenance et fraîcheur.
5. Instrumenter avant le lancement : versions, corrélation, spans, tokens, coûts et évaluations.
6. Exécuter les gates offline : régression, sécurité, charge et budget.
7. Déployer en shadow ou canary : comparer le trafic réel sans pleine autonomie.
8. Échantillonner la production : signaux automatiques, feedback contextualisé et revue humaine respectueuse de la vie privée.
9. Promouvoir ou revenir sur le bundle entier : modèle, prompt, index, outils et politiques ensemble.

Trois anecdotes devenues règles d’exploitation

Flickr, 2009 : on retient « dix déploiements par jour », mais « coopération Dev et Ops » était la moitié durable du titre. La fréquence était l’effet visible d’un feedback plus court et d’une responsabilité partagée.^[flickr]

TFX, 2017 : le problème de production n’a pas été résolu par un meilleur algorithme, mais par le remplacement du glue ad hoc par une plateforme répétable. C’est le passage de « nous avons un modèle » à « nous savons exploiter des modèles ».^[tfx]

Tay, 2016 : Tay précède les LLM modernes et ne doit donc pas être présenté comme un incident LLM. C’était bien un avertissement opérationnel. Microsoft indique qu’une attaque coordonnée a exploité une vulnérabilité imprévue pendant les premières 24 heures, puis que le bot a été retiré.^[tay] Tests de laboratoire, red teaming, observation en direct et capacité de retrait font partie du produit.

Erreurs LLMOps fréquentes

• Appeler un catalogue de prompts « plateforme » : sans évaluation, traçabilité, permissions, traces et rollback, ce n’est qu’un stockage.
• Ne mesurer que les hallucinations : utilité, abstention, format, sécurité, latence et coût comptent aussi.
• Journaliser tous les prompts sans politique : l’observabilité peut copier clandestinement des données sensibles.
• Changer de modèle directement en production : même « meilleur », il modifie style, tool calling, longueur et coût.
• Donner aux outils les droits du compte de service : l’agent doit utiliser le périmètre utilisateur ou une identité minimale.

La véritable évolution : élargir l’objet de responsabilité

DevOps a rendu opérable le changement logiciel. MLOps y a ajouté les données changeantes et le comportement prédictif. LLMOps ajoute contexte, intention et action. Une pratique mûre sait répondre à cinq questions pour chaque sortie : quelle version l’a produite, avec quel contexte, comment elle a été évaluée, ce qu’elle avait le droit de faire et combien elle a coûté.

Avec ces réponses, le système peut progresser sans acte de foi. Sans elles, le « pipeline LLMOps » reste une démo reliée au réseau de production.

Sources et lectures complémentaires

Articles scientifiques, documentation officielle et retours d’incident de première main utilisés dans cet article.

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives