MLflow pour LLM en 2026 :
le guide pratique

Pourquoi MLflow en pivot

L'écosystème MLOps LLM en 2026 est riche : Langfuse, Arize Phoenix, LangSmith, Weights & Biases, Helicone, Truelens, Comet. Tous excellents sur leur niche. Mais aucun ne couvre, seul, les quatre besoins fondamentaux d'un projet IA d'entreprise.

MLflow, depuis sa version 3.0, le fait. C'est la raison pratique pour laquelle nous le positionnons en pivot dans nos missions : une seule plateforme couvre tracking, registry, tracing et evaluation — et le tout en self-host, open-source, déployable en EU sans contrainte juridique. On y ajoute Langfuse pour le dashboard temps-réel et c'est tout.

Les quatre piliers

① MLflow Tracking — l'expérimentation

Le pilier originel de MLflow. Chaque essai (changement de prompt, de retriever, de modèle, d'hyperparamètres de fine-tuning) est tracé : paramètres, métriques, artefacts, tags.

import mlflow

mlflow.set_experiment("acpr-rag-prod")

with mlflow.start_run(run_name="v2.3-hybrid-rerank") as run:
    mlflow.log_params({
        "retriever": "qdrant_hybrid",
        "reranker": "bge-reranker-v2",
        "top_k_retrieval": 50,
        "top_k_rerank": 5,
        "embedder": "mistral-embed",
        "llm": "claude-sonnet-4-6",
    })

    metrics = run_ragas_eval(eval_set)
    mlflow.log_metrics({
        "ragas_faithfulness": metrics.faithfulness,
        "ragas_answer_relevancy": metrics.answer_relevancy,
        "ragas_context_precision": metrics.context_precision,
        "p95_latency_ms": metrics.p95_latency,
        "cost_per_query_eur": metrics.cost,
    })

    mlflow.log_artifact("eval_set.jsonl")
    mlflow.set_tag("team", "rag-platform")
    mlflow.set_tag("env", "staging")

Le backend recommandé en production : Postgres pour les métadonnées, S3 ou MinIO pour les artefacts. Le déploiement est simple — un binaire MLflow Tracking Server, un Postgres, un bucket. Pas de dépendance cloud propriétaire.

② MLflow Tracing — l'observabilité LLM

Introduit en 2.14 et massivement enrichi en 3.0, MLflow Tracing est l'équivalent OpenTelemetry des appels LLM : chaque appel à un modèle est un span, chaque tool call est un sous-span, les agents LangGraph deviennent des arbres de spans inspectables.

L'auto-instrumentation couvre nativement LangChain, LangGraph, LlamaIndex, Anthropic SDK, OpenAI SDK :

import mlflow

# Active l'auto-trace pour LangGraph et LangChain
mlflow.langchain.autolog()

# Désormais chaque graph.invoke(...) est tracé automatiquement
result = my_langgraph_agent.invoke({"messages": [msg]})
# → dans l'UI MLflow : trace complète avec timing par nœud

Vous obtenez, par invocation : la séquence exacte des appels LLM, leurs prompts (avec privacy redaction si configurée), leurs réponses, leurs tokens consommés, leur latence, leur coût estimé. Tout est interrogeable via SQL et exportable.

③ MLflow Model Registry — le versioning

Chaque modèle fine-tuné est enregistré dans le Registry avec versioning sémantique, stages (Staging / Production / Archived), signature de schéma, métadonnées d'évaluation. La promotion d'une version à l'autre est tracée et auditable.

# Après fine-tuning, on enregistre dans le Registry
mlflow.transformers.log_model(
    model,
    artifact_path="model",
    registered_model_name="acpr-mistral-7b-lora",
    metadata={
        "base_model": "mistral-7b-instruct-v0.3",
        "method": "LoRA r=32",
        "training_examples": 4200,
        "eval_faithfulness": 0.91,
    },
)

# Promotion en production (idéalement via workflow d'approval, pas en CLI)
client = mlflow.MlflowClient()
client.transition_model_version_stage(
    name="acpr-mistral-7b-lora",
    version=3,
    stage="Production",
    archive_existing_versions=True,
)

Depuis 3.0, le Registry étend ses fonctions au-delà des modèles ML classiques : il versionne aussi les prompts, les configurations de retrieval, les graphes LangGraph. Le concept est : tout ce qui peut faire varier le comportement de votre IA doit être versionné comme un artefact de release.

④ MLflow Evaluation — l'évaluation continue

Suite d'évaluation native, avec RAGAS intégré et llm-as-judge first-class. Conçu pour tourner en CI/CD : chaque PR sur les prompts ou le graphe déclenche l'eval, et la PR est bloquée si la qualité régresse.

import mlflow
from mlflow.metrics.genai import faithfulness, answer_relevance

eval_set = mlflow.data.from_jsonl("eval_set.jsonl")

with mlflow.start_run():
    result = mlflow.evaluate(
        model=my_rag_chain,  # callable ou registered model
        data=eval_set,
        targets="expected_answer",
        evaluators="default",
        extra_metrics=[
            faithfulness(model="anthropic:/claude-opus-4-7"),
            answer_relevance(model="anthropic:/claude-opus-4-7"),
        ],
    )

    # result.metrics : agrégats — moyenne, médiane, P95
    # result.tables : détail par exemple — utile pour identifier les failures

Les métriques peuvent être : RAGAS, llm-as-judge avec rubrique custom, métriques numériques (BLEU, ROUGE, exact match), classifieurs de toxicité, validateurs structured output. Tout est traçable et comparable d'un run à l'autre.

Comment ça s'articule

Une architecture MLOps LLM complète chez nos clients ressemble à ceci :

• Dev / Exploration : les ingénieurs travaillent dans des notebooks ou des scripts, chaque essai logué via mlflow.start_run(). L'UI MLflow permet de comparer les runs.
• CI/CD : à chaque PR sur le repo IA, GitHub Actions lance la suite mlflow evaluate sur le jeu d'éval. Si Faithfulness baisse de plus de 2 points, la PR est bloquée.
• Promotion : une PR validée déclenche la promotion d'une version dans le Registry (Staging → Production), avec workflow d'approval pour les changements majeurs.
• Production : les appels LLM en prod sont tracés via MLflow Tracing. Langfuse, branché en parallèle, fournit le dashboard temps-réel pour les opérateurs (latence, coût, erreurs).
• Monitoring qualité : un job nocturne échantillonne 5 % des trajectoires production, les passe par llm-as-judge, alerte si la qualité dérive de plus de 3 points sur 7 jours.

Comparatif outils observability

Conformité AI Act native

L'AI Act (entrée en vigueur progressive 2024-2027) exige pour les systèmes IA à haut risque :

• Art. 11 — documentation technique du modèle, des données d'entraînement, des méthodes d'évaluation.
• Art. 12 — logs d'événements de toute la période d'utilisation, permettant la traçabilité.
• Art. 15 — exactitude, robustesse, cybersécurité documentées et continues.

Une plateforme MLflow + MLflow Tracing correctement mise en place couvre ces trois articles nativement, sans surcoût : les runs MLflow documentent les expérimentations (art. 11), les traces MLflow archivent les événements (art. 12), MLflow Evaluation documente la qualité continue (art. 15). C'est l'un des arguments économiques majeurs du choix MLflow.

Pièges fréquents

Piège 1 — Backend SQLite en production

MLflow démarre en SQLite par défaut. C'est nickel en dev. En production, dès que vous avez 2+ utilisateurs ou un job CI/CD parallèle, SQLite fait des locks. Passer à Postgres dès le premier déploiement.

Piège 2 — Artefacts pas isolés

Les artefacts vivent par défaut sur le filesystem local. Quand vous scalez horizontalement, ça casse. Configurer un backend S3-compatible (S3 réel ou MinIO) dès le début.

Piège 3 — Trop de runs, pas de tags

Au bout de 6 mois, vous avez 10 000 runs et vous ne savez plus retrouver le bon. Tagger systématiquement : env, team, commit_sha, experiment_type. Et avoir une politique d'archivage des vieux runs.

Piège 4 — PII dans les traces

Les traces capturent les prompts et les réponses. Si vos prompts contiennent des PII de vos utilisateurs, c'est un problème RGPD. Configurer une privacy filter au niveau du tracer ou redacter les PII en amont via Microsoft Presidio ou équivalent.