20 mai 2026
Pourquoi l'évaluation des LLM est le vrai travail d'ingénierie
Pourquoi le vrai levier sur un système LLM en production n'est ni le prompt ni le modèle, mais une boucle d'évaluation capable d'attraper les régressions avant vos utilisateurs.
Le mauvais centre de gravité : prompts, modèles, démos
Beaucoup d'équipes passent l'essentiel de leur temps à comparer des modèles, réécrire des prompts et discuter du framework du moment. C'est logique : c'est la partie visible, la plus facile à montrer en réunion, et celle qui donne l'impression d'avancer vite. Mais un système LLM ne vaut pas par ce qu'il promet. Il vaut par ce qu'il fait de manière fiable sur une tâche réelle, avec de vraies entrées, dans un vrai workflow.
C'est là que l'illusion tombe. Un prompt peut sembler meilleur sur cinq exemples choisis à la main et pourtant dégrader le produit sur cinquante cas réels. Un nouveau modèle peut impressionner sur des réponses longues et rester pire sur la structure, la prudence ou la stabilité attendues par l'utilisateur. Tant que l'équipe ne mesure pas le comportement du système, elle n'ingénierie pas vraiment. Elle ajuste une démo.
En production, une eval n'est pas un benchmark. C'est un garde-fou aligné sur l'usage.
Évaluer un système LLM en production, ce n'est pas réciter un score généraliste ni reprendre un benchmark public. C'est construire un set de cas qui représente la tâche réellement servie, avec les attentes métier, les critères de qualité, les bons refus, les cas ambigus, et les sorties inacceptables. Une bonne eval répond à une question utile : si je change le prompt, le modèle, le retrieval, l'outil ou le routing, est-ce que le système s'améliore vraiment pour mes utilisateurs ?
Cela implique des tests spécifiques, vivants, versionnés, et capables de prévenir les régressions. Sur un assistant support, on regardera par exemple la justesse factuelle, la conformité au ton attendu, l'usage correct des sources, la capacité à dire qu'il manque une information, et la distance d'édition côté agent humain. Sur un workflow interne, on ajoutera les contraintes de format, de latence, de sécurité ou d'escalade. Une eval utile n'est donc pas une note unique. C'est un instrument de pilotage.
L'évaluation humaine ne scale pas, mais elle reste obligatoire au début
Au démarrage, il faut presque toujours de l'évaluation humaine. Pas parce que c'est élégant, mais parce que personne n'a encore assez de signal pour automatiser proprement le jugement. Quelqu'un doit regarder les sorties, repérer les erreurs réellement coûteuses, distinguer une réponse acceptable d'une réponse dangereuse, et écrire les premiers critères qui serviront ensuite au reste de la boucle.
Évidemment, cette approche ne scale pas très loin. Elle coûte du temps, fatigue les reviewers et crée parfois de la variance entre évaluateurs. Mais essayer de l'éviter trop tôt est une erreur. Si vous n'avez pas encore observé plusieurs dizaines ou centaines de vrais cas, vous ne savez pas vraiment ce qu'il faut mesurer. La bonne séquence est simple : humain d'abord pour définir le standard, puis automatisation progressive quand les critères deviennent assez stables.
Les patterns LLM-as-judge sont utiles, à condition de savoir ce qu'on leur demande
Le pattern LLM-as-judge fonctionne plutôt bien pour des tâches où le critère peut être formulé clairement : respect d'un format, présence d'éléments attendus, comparaison relative entre deux sorties, classification d'un type d'erreur, ou scoring d'une réponse par rapport à un rubric précis. C'est particulièrement utile pour accélérer la boucle et filtrer ce qui mérite une revue humaine plus coûteuse.
En revanche, il devient fragile dès qu'on lui demande de juger la vérité d'un contenu subtil, le risque métier réel, ou la préférence utilisateur sans calibration sérieuse. Un juge LLM hérite des biais du prompt, du modèle et des exemples qu'on lui donne. Il faut donc le calibrer sur un lot annoté par des humains, mesurer son accord avec eux, suivre ses faux positifs et faux négatifs, et conserver des audits réguliers. Le juge automatisé peut réduire le coût d'eval. Il ne remplace pas la discipline d'eval.
La boucle qui marche ressemble rarement à un one-shot
Dans la pratique, l'eval utile ressemble à une boucle courte et répétée : générer des sorties, scorer, corriger, re-scorer, puis recommencer. On modifie un prompt, un exemple few-shot, une stratégie de retrieval, un seuil de routing ou un fallback. Ensuite on repasse immédiatement le set d'eval pour voir ce qui s'améliore, ce qui casse, et où le gain apparent cache une régression ailleurs.
C'est ce caractère itératif qui fait le vrai travail d'ingénierie. On ne cherche pas un prompt magique trouvé une fois pour toutes. On construit un système qui peut évoluer sans perdre sa baseline. Les équipes solides traitent leur suite d'eval comme du code produit : elle est versionnée, enrichie à partir des incidents réels, et exécutée avant chaque changement important. Le but n'est pas d'obtenir un score flatteur. Le but est de rendre la qualité plus prévisible.
Trois erreurs reviennent sans cesse, et elles coûtent cher
Première erreur : tester sur les mêmes données que celles qui ont servi à tuner. On croit mesurer la qualité, on mesure surtout la mémoire de son propre processus d'optimisation. Deuxième erreur : ignorer les edge cases jusqu'au jour où la production les découvre pour vous. Les cas rares ne restent rares que jusqu'à ce qu'un client important tombe dessus. Troisième erreur : shipper sans baseline. Sans comparaison avec la version précédente, un workflow manuel ou une règle simple, impossible de dire si la nouvelle version aide réellement.
La conséquence pratique est simple : construisez votre suite d'eval avant la mise en ligne, pas après l'incident. Même petite, elle vaut plus qu'un grand discours sur la qualité. Trente cas bien choisis, une baseline claire, quelques revues humaines et un rituel de régression feront progresser votre système plus vite que des semaines passées à débattre du meilleur prompt. Sur les LLM, l'évaluation n'est pas la finition. C'est le coeur du travail.