MLflow, Kubeflow, LangSmith, Weights & Biases : en 2026, aucune stack unique ne couvre le machine learning classique et les applications à base de LLM. Voici une grille de décision méthodologique, coûts à l'appui.
Pendant longtemps, un seul terme, MLOps, a suffi à désigner l'ensemble des pratiques de mise en production des modèles. Ce n'est plus le cas. MLOps et LLMOps partagent des concepts mais divergent suffisamment en matière d'artefacts, de modes de défaillance et d'outillage pour que les équipes de production fassent tourner deux stacks parallèles en 2026.
La différence tient d'abord à la nature de l'objet piloté. En MLOps, l'unité de travail est un artefact de modèle réentraîné : un fichier sérialisé (pickle, ONNX, TensorFlow SavedModel, PyTorch state dict) produit par un pipeline d'entraînement sur un jeu de données labellisé, qui est ensuite enregistré, signé, versionné et déployé. À l'inverse, une équipe qui opère des applications LLM en 2026 ne réentraîne presque jamais un modèle : elle ajuste un prompt système, change de modèle fournisseur, modifie un corpus RAG, ajoute un outil au planificateur, puis déploie.
Les modes de défaillance ne sont donc pas les mêmes. Côté ML classique, le risque typique est un pipeline de features qui a cassé silencieusement ou une distribution de labels qui a dérivé. Côté LLM, on parle plutôt d'un changement de prompt qui a cassé l'ancrage des citations, d'une mise à jour de poids chez le fournisseur qui a fait dériver le taux de refus, ou d'un nouvel outil que le planificateur a sélectionné au mauvais moment. Un stack de monitoring conçu pour la dérive de features ML classique ne détecte tout simplement pas ce type d'incident.
Les équipes qui ont vécu la bascule en production le confirment de manière très concrète. Une équipe utilisant LangFuse ou LangSmith pour le tracing des prompts, Ragas pour l'évaluation des pipelines RAG, MLflow pour le suivi des expériences, Pydantic pour la validation des schémas de sortie, Argilla pour la revue humaine et Qdrant ou Pinecone pour le stockage vectoriel décrit un stack LLMOps typique de 2026. Le retour d'expérience est sans ambiguïté : après un incident lié au prompt, le stack MLOps existant n'avait aucune visibilité sur ce type de problème, sans versioning des prompts, sans validation de schéma de sortie, sans détection de dérive sémantique — l'équipe volait à l'aveugle sans le savoir.
Ce que suit un stack LLMOps mature en 2026 diffère aussi dans ce qu'il mesure. LLMOps ne surveille pas les mêmes signaux que MLOps : des sorties textuelles non déterministes, un coût en tokens par requête, des versions de templates de prompt et un taux d'hallucination, et non plus seulement la précision du modèle et la dérive des données. Un exemple concret illustre l'enjeu : une étude d'Amazon de février 2025 a montré qu'une quantification INT4 a provoqué une baisse de précision de 39,46 % sur Llama-3.3 70B — une régression silencieuse qu'un simple changement de version de modèle, jugé « sans risque », peut introduire sans qu'aucun système de monitoring MLOps classique ne l'alerte.
À l'inverse, l'infrastructure de gouvernance dont dispose déjà le MLOps fait cruellement défaut côté LLM. MLOps dispose d'une décennie d'infrastructure durement acquise : lignage des données, catalogues de métadonnées, pistes d'audit et versioning des modèles. Côté LLMOps, la question reste souvent sans réponse : quelle version de prompt a tourné, quels documents ont été récupérés, quelle source de données alimentait l'index vectoriel, quel pipeline a produit cette donnée — sans ces réponses, le débogage relève du tâtonnement.
La question à se poser en premier n'est pas « quel outil » mais « quel est l'actif central du système ». Pour la plupart des acheteurs en 2026, la ligne de partage reste utile : si l'actif central est un modèle entraîné sur mesure, on privilégie un outil MLOps ; si l'actif central est une application de prompt et de récupération sur un modèle de fondation, on privilégie un outil LLMOps.
Concrètement :
Dans la majorité des organisations, la coexistence des deux stacks devient la norme plutôt que l'exception : LLMOps introduit des défis supplémentaires autour du versioning des prompts, des pipelines de fine-tuning, de l'évaluation du texte généré et de la gestion des coûts d'inférence ; en 2026, la plupart des équipes en entreprise ont besoin des deux — MLOps pour leurs charges de travail ML existantes et des pratiques LLMOps pour toute initiative d'IA générative.
MLflow est entièrement open source sous licence Apache 2.0 et gratuit à auto-héberger, sans coût de licence ; une version managée existe via Databricks, facturée séparément. C'est l'outil de référence pour le tracking d'expériences en ML classique, et il reste utilisé même dans les stacks LLMOps pour le suivi des runs. Le coût réel n'est pas la licence mais l'infrastructure : MLflow repose sur une architecture de serveur de tracking centralisé où expériences, runs et artefacts sont journalisés vers un backend partagé ; ce design est simple à déployer via une commande unique, mais devient un goulot d'étranglement à l'échelle sans planification d'infrastructure soignée.
Kubeflow est le meilleur choix pour les équipes Kubernetes-natives, avec pipelines, serving et tuning sur K8s. Mais son coût caché est humain avant d'être financier : Kubeflow est une « taxe Kubernetes » que la plupart des équipes n'ont pas besoin de payer, et faire tourner Kubeflow sur Kubernetes exige des ingénieurs plateforme dédiés. La recommandation qui revient le plus souvent : si l'entreprise fait déjà tourner Kubernetes avec une équipe plateforme, Kubeflow se justifie ; sinon, la combinaison Airflow plus MLflow couvre 80 % du besoin sans la charge opérationnelle.
W&B se positionne comme l'alternative SaaS à MLflow, avec une facturation par siège. W&B facture par siège : une équipe de 10 personnes paie 500 dollars par mois pour le plan Teams, le tarif Entreprise étant personnalisé et incluant SSO, journaux d'audit et support dédié. L'écart de fond avec MLflow n'est pas fonctionnel mais organisationnel : MLflow fait économiser de l'argent — gratuit, auto-hébergeable, contrôle total — quand Weights & Biases fait gagner du temps, avec une interface soignée, collaborative, opérationnelle en quelques minutes.
Pour la partie LLMOps, LangSmith illustre bien la logique de facturation à l'usage propre aux applications génératives. La formule Plus coûte 39 dollars par siège et par mois avec 10 000 traces de base incluses ; au-delà, les traces de base (rétention 14 jours) coûtent 2,50 dollars pour 1 000 et les traces étendues (rétention 400 jours) 5 dollars pour 1 000. Ce modèle peut vite dériver : pour une équipe de 10 à 20 développeurs, le coût des sièges bite plus fort — une équipe de 10 paie 390 dollars par mois en sièges, une équipe de 20 paie 780 dollars, et les volumes de production à cette échelle, souvent entre 500 000 et 2 millions de traces par mois, ajoutent entre 1 225 et 4 975 dollars de dépassement. Une alternative open source existe pour les équipes sensibles au coût : Langfuse propose la tarification la plus agressive, à 29 dollars par mois pour 100 000 unités sans multiplication par siège — une équipe de 10 personnes paie le même prix qu'une équipe de 2 pour un usage équivalent.
Le prix affiché sur la page tarifaire n'est jamais le coût total de possession. Pour une stack MLOps auto-hébergée, il faut ajouter l'infrastructure : un coût d'infrastructure entre 500 et 5 000 dollars par mois pour les instances cloud quand on choisit la voie open source (MLflow, Kubeflow, BentoML). Pour LangSmith, l'écart entre facture affichée et facture réelle peut être considérable : une analyse évalue que les coûts réels de LangSmith atteignent 10,7 fois l'abonnement de base une fois pris en compte l'implémentation réelle, l'archivage et les frais opérationnels, le tarif de 39 dollars par siège n'étant que le début.
Ce delta entre coût nominal et coût réel doit être intégré dès la phase de cadrage budgétaire, un exercice que nous menons systématiquement lors de nos missions de conseil en industrialisation IA : arbitrer entre self-hosting et SaaS ne se limite jamais à comparer deux prix catalogue.
Le choix d'architecture MLOps/LLMOps en 2026 ne peut plus s'affranchir du contexte réglementaire européen. C'est en août 2026 que les obligations les plus lourdes de l'AI Act deviennent pleinement opposables pour les systèmes d'IA classés à risque élevé, les entreprises concernées devant avoir finalisé leur documentation technique, mis en place des systèmes de gestion des risques et assuré la traçabilité des données. Or, un stack MLOps mature répond nativement à cette exigence de traçabilité — registre de modèles, versioning, audit trail — quand un stack LLMOps encore jeune peine parfois à documenter la chaîne prompt-donnée-sortie. Un allègement récent nuance toutefois la portée immédiate de ces obligations pour les plus petites structures : le paquet omnibus numérique publié en juin 2026 allège significativement les obligations pour la grande majorité des entreprises, les systèmes d'IA industriels intégrés à des produits déjà conformes CE étant désormais quasi exemptés du régime haut risque.
Reste une obligation qui, elle, ne dépend pas du type de système déployé : la formation des équipes. L'obligation d'AI literacy, formation minimale des équipes manipulant l'IA, est déjà applicable depuis février 2025 — les collaborateurs utilisant des outils IA sans formation aux risques associés exposent déjà l'entreprise à un risque de non-conformité. C'est un point que nous intégrons systématiquement dans nos parcours de formation IA et data pour les équipes techniques comme pour les métiers.
Pour trancher rapidement entre les configurations possibles :
Le point commun à toutes ces configurations : auditer sa stack actuelle par rapport à la cartographie du cycle de vie, puis piloter l'outil unique qui comble le plus gros manque plutôt qu'une refonte à six outils d'un coup. C'est l'approche méthodologique que nous appliquons dans nos missions d'accompagnement, détaillées sur notre page offre de conseil, pour éviter aux directions data un empilement d'outils redondants.