ai-machine-learning

Évaluation LLM en ligne vs hors ligne : laquelle choisir (et quand)

Écrit par Mert Batur
Aug 1, 2026
14 lecture
Évaluation LLM en ligne vs hors ligne : laquelle choisir (et quand)

Évaluation LLM en ligne vs hors ligne : laquelle choisir (et quand)

L'évaluation LLM en ligne vs hors ligne est une seule décision, pas deux, et notre suite promptfoo l'a prouvé mardi dernier : un prompt système réécrit, 47 cas de test, une fidélité (faithfulness) qui chute de 0,91 à 0,74 en environ 90 secondes de CI. Le contrôle hors ligne a intercepté cette régression avant le merge ; le monitoring de production l'aurait découverte plus tard, déguisée en ticket support. Hors ligne ou en ligne, même verdict : deux voies, deux métiers.

L'évaluation LLM hors ligne confronte votre modèle à un jeu de données figé avant le déploiement, pour prouver qu'un changement n'a pas cassé la qualité mesurée. L'évaluation en ligne note le trafic de production réel après la mise en ligne, et révèle ce que le jeu de données n'a jamais contenu. La plupart des équipes ont besoin des deux, dans cet ordre : le hors ligne verrouille le déploiement, l'en ligne attrape la dérive.

Points clés à retenir

  • L'évaluation hors ligne tourne sur un jeu de données figé avant le déploiement ; l'évaluation en ligne note le trafic réel après la mise en ligne.
  • La plupart des équipes ont besoin des deux : le hors ligne verrouille les déploiements, l'en ligne attrape ce que le jeu de données a manqué.
  • Le hors ligne intercepte les régressions de prompt et les formats cassés ; l'en ligne détecte la dérive, la latence sous charge et les bizarreries d'intégration.
  • Branchez les evals hors ligne comme porte de merge en CI ; injectez les scores en ligne issus des traces de production dans votre jeu d'eval.

En quoi l'évaluation en ligne et l'évaluation hors ligne diffèrent-elles vraiment ? (9 dimensions)

Les deux modes divergent sur neuf axes, mais l'axe décisif est la source de données : l'évaluation hors ligne note un jeu de données figé et versionné avant le déploiement, tandis que l'évaluation en ligne note le trafic réel après la mise en ligne. Toutes les autres différences (coût, latence, risque, gouvernance) découlent de cette scission.

Le centre d'apprentissage de Label Studio présente la paire comme des modes complémentaires plutôt que des rivaux, et nous sommes d'accord. Le tableau prolonge cette lecture avec des métriques spécifiques aux LLM que leur version ML générique ne couvre pas.

DimensionHors ligneEn ligne
Source de donnéesJeu de données doré figé, versionné dans gitTraces de production réelles, échantillonnées
MomentAvant déploiement, sur chaque PRAprès mise en ligne, en continu
Coût par exécutionTokens du juge par exécution de suite ; coût marginal quasi nulTokens du juge sur trafic échantillonné ; augmente avec le volume
Contrainte de latenceAucune ; traitement par lots à loisirBudgets infra-seconde sur les chemins critiques
Risque utilisateurZéro ; les échecs n'atteignent jamais les utilisateursRéel ; les mauvaises sorties touchent des sessions actives
Vitesse de feedbackMinutes par PRSecondes à minutes en flux
Types de métriquesFidélité, pertinence des réponses, conformité de format, scores de benchmarkPercentiles de latence, taux d'erreur, taux d'hallucination, feedback utilisateur
RépétabilitéDéterministe à modèle et jeu de données figésNon déterministe ; le mix de trafic change chaque jour
Gouvernance et auditArtefacts versionnés, diffables entre releasesDashboards et alertes ; reproduction plus difficile

Notre interprétation : la colonne hors ligne répond à « ce changement a-t-il cassé quelque chose ? », et la colonne en ligne à « la production dévie-t-elle de ce que nous avons testé ? ». La ligne des types de métriques est là où les deux divergent le plus ; notre guide des métriques d'évaluation LLM détaille chacune d'elles.

Que détecte chaque mode, et qu'est-ce qui passe entre les deux ?

Chaque mode possède une classe privée de défaillances que l'autre ne voit pas. Le hors ligne détecte les changements que vous avez faits ; l'en ligne détecte les changements que le monde a faits autour de vous. Les échecs coûteux, ceux qui passent entre les deux filets, demandent un relecteur humain. Cette taxonomie est notre synthèse de ce que chaque mode remonte, pas un standard publié.

QuadrantExemplesAction
Hors ligne uniquementRégressions de prompt, formats de sortie cassés, chute des scores de benchmark, fidélité sous le seuilBloquer le merge en CI
En ligne uniquementDérive de distribution, latence sous charge, bizarreries d'intégration, schémas d'abus adversesAlerter, échantillonner les traces, les router vers le jeu d'eval
Détecté par les deuxPics du taux d'hallucination, érosion de la cohérence factuelleGarder les deux ; dédoublonner l'effort, pas la couverture
Détecté par aucunCas limites inédits, jugements de qualité subjectifs, dérive de la voix de marqueFile de revue humaine ; les cas labellisés alimentent le jeu hors ligne

Le quadrant « hors ligne uniquement » est celui où les portes CI gagnent leur salaire : un prompt réécrit qui fait passer la conformité de format de 99 % à 91 % en silence est invisible en code review et évident dans une suite de 47 cas. Le quadrant « en ligne uniquement » est plus sournois. Les vrais utilisateurs formulent des choses que votre jeu doré n'a jamais vues, les APIs tierces timeout à des horaires que le staging ne touche jamais, et quelqu'un enverra un prompt de 40 000 caractères à votre chatbot juste pour voir ce qui se passe. Pour ce versant, notre guide sur l'évaluation des agents en production couvre le scoring des trajectoires multi-étapes, pas seulement des sorties unitaires.

La dernière ligne est celle que les équipes sautent, et celle qui les brûle. Les échecs qui vous coûtent des utilisateurs sont ceux qu'aucun des deux modes n'attrape seul. Ils exigent un humain dans la boucle.

Comment brancher les evals hors ligne sur une porte CI ? (La config que personne ne montre)

Ajoutez un runner d'eval comme status check obligatoire sur chaque pull request qui touche un prompt, un modèle ou une config de retrieval. Affirmez un seuil. Bloquez le merge en dessous. promptfoo documente exactement ce pattern CI, et c'est celui que nous utilisons.

L'étape GitHub Actions

Une version épurée de la porte que nous faisons tourner aujourd'hui :

yaml
name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

La config YAML déclare les cas de test et les assertions ; eval sort avec un code non nul quand la suite passe sous le seuil, GitHub marque le check obligatoire comme échoué, et le bouton de merge devient gris. Le filtre paths compte : une correction de README ne devrait pas brûler des tokens de juge.

Ce que la porte attrape vraiment

La version en production score notre chaîne RAG d'agent support contre 47 cas dorés sur chaque PR touchant un prompt. Une exécution complète prend environ 90 secondes de CI, et le merge se bloque automatiquement si la fidélité passe sous 0,82. En trois mois, elle a intercepté deux régressions qui auraient sinon été livrées : une réécriture de prompt système qui a fait chuter la fidélité de 0,91 à 0,74, et un changement de retriever qui a doublé la longueur du contexte et fait passer la pertinence des réponses sous le seuil. Aucune des deux n'avait l'air dangereuse en review.

Une porte de fidélité en CI coûte 90 secondes par PR. Une régression de fidélité en production vous coûte un ticket support et un rollback.

Nous avons comparé les runners que vous pouvez brancher sur ce pattern — promptfoo, DeepEval et les autres — dans notre panorama des outils d'évaluation LLM.

Quels outils font tourner quel mode ? (Matrice outil-mode)

Aucun outil ne possède proprement les deux voies. promptfoo et DeepEval sont des runners offline-first qui peuvent scorer des données de production exportées selon un planning ; Langfuse et LangSmith sont des stores de traces online-first qui greffent des scoreurs LLM-as-judge sur les traces ingérées. La matrice est notre lecture de la doc de chaque éditeur : une interprétation, pas une vérité d'évangile.

OutilRunner hors ligneScorer en ligneLes deux nativement ?Ce qu'il ne fait PAS
promptfooOui : suites YAML, natif CI, packs red-teamPartiel : mêmes configs sur logs exportésHors ligne d'abord ; l'en ligne exige une étape d'exportIngérer des traces en direct ; servir de dashboard de monitoring
DeepEvalOui : tests façon pytest, 14+ métriquesOui, via la plateforme Confident AIOui, avec l'add-on hébergéLa bibliothèque open-source seule est hors ligne uniquement
LangfusePartiel : expérimentations sur datasets via SDKOui : évaluateurs juges sur traces ingéréesOui : datasets plus scoreurs de tracesFaire tourner votre porte de merge CI ; vous le câblez vous-même
LangSmithOui : datasets et expérimentations hors ligneOui : des automatisations notent les traces échantillonnéesOuiVivre hors de l'écosystème LangChain sans friction
OpenAI EvalsOui : evals YAML façon registreNonNonPipelines de traces de production ; modèles non-OpenAI
Arize PhoenixOui : expérimentations notebook d'abordOui : spans et traces avec évaluateurs inlineOuiInstallation légère ; l'observabilité passe en premier

Choisissez promptfoo ou DeepEval si votre premier besoin est une porte de merge qui bloque les mauvais prompts en CI. Choisissez Langfuse ou LangSmith si votre premier besoin est de scorer le trafic en direct, et notre comparaison Langfuse vs LangSmith creuse ce choix. OpenAI Evals reste l'outsider : un runner hors ligne façon registre, sans volet production.

promptfoo verrouille vos PRs. Langfuse score vos traces de production. Aucun ne remplace l'autre.

Comment la boucle de feedback transforme-t-elle les échecs en ligne en tests hors ligne ?

Échantillonnez les traces de production mal notées, labellisez-les, et committez-les dans le jeu d'eval hors ligne. La suite de régression grandit alors à chaque surprise que la production vous envoie, et le prochain déploiement est verrouillé sur le jeu élargi. Le cadrage en volant d'inertie est de nous ; c'est la partie que la plupart des équipes ne construisent jamais.

Le cycle, tel que nous le faisons tourner :

  1. Les scoreurs en ligne signalent les traces sous un score de juge de 0,7.
  2. Nous échantillonnons 20 à 30 traces signalées par semaine.
  3. Un humain labellise chacune : sortie attendue plus classe de défaillance.
  4. Les cas labellisés rejoignent le jeu d'eval hors ligne comme nouveaux exemples dorés.
  5. La PR suivante tourne sur la suite élargie, et la boucle redémarre.

L'échantillonnage démarre à votre couche d'observabilité LLM, parce que les traces sont la matière première. Côté cadence : l'hebdomadaire bat le mensuel, parce que la dérive se cumule. Nous labellisons 10 à 15 cas par semaine, et le jeu est « assez grand » quand les nouveaux labels ne font plus bouger le taux de réussite, soit environ 150 à 250 cas pour un agent support au périmètre étroit. La frontière entre les modes ne cesse de se brouiller : Deepchecks rapporte que les ingénieurs de Union.ai planifient leurs évaluations « hors ligne » toutes les quelques minutes, ce qui en fait de fait des contrôles quasi temps réel.

Votre jeu d'eval n'est pas un artefact figé. Il grandit chaque semaine où la production vous surprend.

Quand faut-il les deux ? (Évaluation LLM en ligne vs hors ligne par étape)

Vous avez besoin des deux dès la semaine de lancement, mais l'équilibre se déplace selon l'étape : le hors ligne porte seul le travail de pré-déploiement, la semaine de lancement ajoute le scoring shadow ou canari, le régime de croisière s'appuie sur le monitoring en ligne avec des ré-exécutions hors ligne périodiques, et une alerte de dérive doit aboutir à un test hors ligne reproduit plus un jeu d'eval élargi.

ÉtapeHors ligneEn ligneAction
Pré-déploiementPorte de régression sur chaque PRRien encoreBloquer le merge sous le seuil
Semaine de lancementSuite complète sur la release candidateScoring shadow ou canari sur 5-10 % du traficComparer les scores en ligne à la baseline hors ligne
Régime de croisièreRé-éval périodique sur un jeu rafraîchi, hebdo ou mensuelScoring échantillonné continu plus alertesSurveiller la dérive ; rebaseliner chaque trimestre
Dérive détectéeReproduire les traces en échec hors ligneL'alerte qui a déclenchéAjouter les traces labellisées au jeu d'eval ; reverrouiller le prochain déploiement

Le pré-déploiement est l'endroit le moins cher pour être strict : un merge bloqué coûte des minutes ; une mauvaise release coûte la confiance. La semaine de lancement est celle où les équipes sous-investissent, alors qu'un scoring shadow sur une petite tranche de trafic coûte peu et révèle si le jeu doré a menti. Le régime de croisière est celui où la complaisance s'installe, alors inscrivez la ré-éval au calendrier.

Et l'EU AI Act ?

Les obligations « haut risque » de l'EU AI Act entrent en vigueur progressivement jusqu'en août 2026, avec le calendrier complet des échéances publié sur EUR-Lex, et le pattern de conformité se mappe proprement sur les deux modes. Une preuve hors ligne documentée montre que le système atteignait les objectifs de qualité avant la sortie ; un monitoring en ligne continu montre qu'il continue de les atteindre après. Notre lecture est qu'une piste d'audit a besoin des deux artefacts, car les logs hors ligne seuls ne prouvent pas que le système est resté conforme, et les dashboards seuls ne prouvent pas qu'il l'était au lancement. C'est une interprétation, pas un avis juridique ; notre pilier pipeline d'évaluation LLM cartographie l'ensemble des exigences.

L'évaluation hors ligne est votre preuve. L'évaluation en ligne est votre système d'alerte précoce. Les régulateurs veulent les deux.

À propos de l'auteur : Mert Batur est cofondateur de Techsy.io, où l'équipe livre des agents IA, des systèmes d'automatisation et des pipelines voix/SDR pour des clients B2B. Il écrit sur la stack d'outillage LLM que l'équipe Techsy utilise réellement en production. Retrouvez-le sur LinkedIn.

Questions fréquemment posées

Qu'est-ce que l'évaluation LLM hors ligne ?

L'évaluation LLM hors ligne fait tourner un modèle ou un prompt contre un jeu de données figé et versionné avant le déploiement. Les contrôles typiques incluent la fidélité au contexte récupéré, la pertinence des réponses, la conformité de format et les scores de benchmark. Comme le jeu de données ne change jamais en cours d'exécution, les résultats sont reproductibles et diffables, ce qui explique précisément pourquoi les suites hors ligne fonctionnent comme portes de merge CI.

Qu'est-ce que l'évaluation LLM en ligne ?

L'évaluation LLM en ligne note le trafic de production réel après la mise en ligne. Un scoreur LLM-as-judge évalue des traces échantillonnées pour l'hallucination, le ton ou la justesse des appels d'outils, et les scores alimentent un dashboard en flux. Elle absorbe aussi des signaux que les tests hors ligne ne voient pas : la latence sous charge, le feedback utilisateur, et l'écart entre les requêtes réelles et votre jeu doré.

Quand utiliser l'évaluation LLM hors ligne plutôt qu'en ligne ?

Utilisez l'évaluation hors ligne pour verrouiller les déploiements : chaque changement de prompt, de modèle ou de retrieval doit passer la suite avant le merge. Utilisez l'évaluation en ligne pour surveiller ce qui est livré. La plupart des équipes enchaînent les deux plutôt que d'en choisir une : le hors ligne d'abord, l'en ligne dès la semaine de lancement, avec les échecs de production qui refluent vers le jeu hors ligne.

Un exemple d'évaluation LLM en ligne vs hors ligne ?

Exemple hors ligne : une suite promptfoo fait tourner 200 questions support dorées sur chaque pull request et bloque le merge si la fidélité passe sous 0,82. Exemple en ligne : Langfuse score 10 % des traces en direct avec un check d'hallucination LLM-as-judge et alerte quand la moyenne hebdomadaire fléchit. Même rubric, source de données différente.

Comment l'humain dans la boucle s'intègre-t-il à l'évaluation LLM ?

Les humains comblent l'écart qu'aucun des deux modes ne couvre : cas limites inédits, jugements de qualité subjectifs et dérive de la voix de marque. Une cadence pratique consiste à labelliser 10 à 20 traces mal notées échantillonnées par semaine et à committer les cas labellisés dans le jeu d'eval hors ligne. La file de revue est une entrée du pipeline, pas un projet annexe.

Comment fonctionnent les évaluations Langfuse pour le scoring en ligne ?

Langfuse ingère les traces de votre application, puis attache des évaluateurs LLM-as-judge qui notent chaque trace contre une rubric : hallucination, pertinence, toxicité ou prompt personnalisé. Les scores atterrissent sur un dashboard indexé par sessions et utilisateurs. Les équipes exportent les traces durablement mal notées dans un jeu de données hors ligne pour les tests de régression. Notre panorama des plateformes d'observabilité compare les stores de traces qui alimentent ce pattern.

Comment ajouter des evals hors ligne à un pipeline CI/CD ?

Ajoutez un runner d'eval comme status check obligatoire sur les pull requests qui touchent prompts, modèles ou config de retrieval. promptfoo et DeepEval tournent tous deux en headless et sortent avec un code non nul en cas d'échec d'assertion, ce qui bloque le merge automatiquement. La porte YAML présentée plus haut dans cet article est un template fonctionnel ; démarrez avec 30 à 50 cas.

L'EU AI Act exige-t-elle l'évaluation hors ligne ou en ligne ?

En pratique, les deux. Pour les systèmes à haut risque, la loi attend une preuve documentée que les objectifs de qualité étaient atteints avant la sortie, donc des artefacts hors ligne, plus un monitoring continu après le déploiement, donc de la télémétrie en ligne. Ses échéances progressives courent jusqu'en août 2026 selon EUR-Lex. C'est notre lecture du pattern de conformité, pas un avis juridique.

Le LLM-as-a-judge peut-il tourner en mode hors ligne et en ligne ?

Oui, et il le devrait, car la rubric se transpose. En hors ligne, le juge note en batch chaque sortie du jeu d'eval pendant le CI. En ligne, le même prompt de juge note les traces de production échantillonnées en quasi temps réel. Conserver une seule rubric sur les deux modes est ce qui rend votre baseline hors ligne comparable à votre signal de dérive en ligne.

Quelles métriques diffèrent entre évaluation hors ligne et en ligne ?

Les métriques hors ligne mesurent la qualité des sorties contre une vérité terrain : fidélité, pertinence des réponses, conformité de format, scores de benchmark. Les métriques en ligne ajoutent des signaux opérationnels et comportementaux : latence p95, taux d'erreur, taux d'hallucination sur trafic réel, score de dérive et satisfaction utilisateur. La liste hors ligne demande « est-ce bon ? » et la liste en ligne « est-ce toujours bon ? ».

La version courte

  • Les évaluations hors ligne et en ligne sont des voies complémentaires, pas un choix exclusif : l'une verrouille ce que vous livrez, l'autre surveille ce que vous avez livré.
  • Démarrez par la porte CI cette semaine, ajoutez le scoring de traces en ligne au lancement, et câblez la boucle de feedback avant que votre jeu d'eval ne devienne obsolète.
  • La boucle est le système. Un jeu doré statique pourrit ; un jeu qui grandit compose.

Si vous voulez un second regard sur votre pipeline d'eval, obtenez une consultation gratuite.

Tags

évaluation llm en ligne vs hors ligneévaluation llmllm-as-a-judgeporte ci evalmonitoring llm production

Partager cet article

Démarrez Votre Projet

Prêt à construire quelque chose d'extraordinaire ?

Transformons votre vision en réalité. Notre équipe est prête à vous aider à créer un logiciel qui fait la différence.