Tout le secteur se rue sur les evals — et esquive la vraie question
En 2026, l’une des pratiques ingénierie les plus en vogue dans l’écosystème AI consiste à construire des « systèmes d’évaluation » (evals) pour les modèles et les agents.
Le manuel est déjà bien rodé : on constitue un jeu de données de référence à partir de vrais échecs, on entraîne un scoreur en qui on a confiance, on fait arbitrer par un LLM « aligné sur des évaluateurs humains », et on pose un verrou en CI pour bloquer toute régression qualité. Anthropic a publié un guide complet sur la construction d’evals ; une enquête indique que 32 % des équipes citent la qualité comme premier frein au déploiement de produits AI. Le mouvement s’est cristallisé : les evals sont présentés comme la discipline d’ingénierie qui rend l’AI fiable.
L’outillage est réel. Mais mon observation est la suivante : tout le monde est en train de déguiser un problème organisationnel en problème d’ingénierie — et ce problème-là, les evals ne peuvent pas le régler.
Enlever le vernis ingénierie : qu’est-ce qu’un eval, vraiment ?
Débarrassez un système d’evals de son habillage technique — jeux de données, scoreur, CI — et il ne reste que deux choses : une définition écrite de « ce qu’on considère comme bon et ce qu’on ne tolère pas », plus un mécanisme pour l’appliquer.
Monter le pipeline et faire tourner la CI, c’est la partie facile ; c’est aussi celle que les outils absorbent en premier. Le difficile, c’est la première moitié de la phrase — qu’est-ce qui est bon, au juste ? Ce n’est pas une question d’ingénierie, c’est une question de jugement. Et le jugement, précisément, est ce que les evals cherchent à contourner sans jamais y parvenir.
« LLM-as-judge » ne fait que déplacer le problème d’un cran
La mode actuelle est de confier l’arbitrage à un LLM déclaré « aligné sur des évaluateurs humains ». Ça sonne scientifique — jusqu’à ce qu’on pose la question évidente : aligné sur quels humains ? Sur le goût de qui ?
Le modèle-juge ne génère pas de standards ; il reproduit ceux qu’on lui a injectés. Votre jeu de données de référence est porteur des jugements de quelqu’un, et vos evals n’auront jamais plus de hauteur que ces jugements. « Constituer un dataset à partir de vrais échecs », c’est en réalité produire un document de valeurs déguisé en données de test — un registre de ce que votre équipe refuse de tolérer.
Autrement dit : les evals amplifient le goût que vous avez déjà, ils ne vous en donnent pas. Une équipe au jugement médiocre qui se dote d’un beau pipeline d’evals n’obtient pas un bon produit — elle obtient « de la médiocrité produite plus vite et plus régulièrement ».
Ce que la fièvre des evals révèle vraiment
Le grand récit « l’AI peut tout faire » promettait de dissoudre le rôle de celui qui contrôle la qualité. La fièvre des evals, c’est le secteur en train de discrètement le faire revenir — avec un nom ingénierie à la place.
Le sous-texte est inconfortable : l’AI n’a pas supprimé la personne qui a du jugement, elle en a fait le goulot d’étranglement. Plus l’exécution coûte peu, plus « définir ce qui est bon » devient rare. S’empresser de construire des evals, c’est admettre — tardivement — cette réalité.
Mon pronostic pour la suite : les gagnants ne seront pas les équipes au pipeline d’evals le plus sophistiqué, mais celles qui ont l’opinion la plus tranchée sur ce que signifie « bon » et qui le définissent avec la plus grande clarté. Parce que le pipeline exécute fidèlement le standard qu’on lui donne — et chez la plupart des équipes, ce standard est une bouillie informe.
Les evals n’ont jamais été un problème de mesure. Ils sont l’aveu progressif du secteur qu’il faut bien que quelqu’un décide ce qui est bon — et que c’est précisément la chose la moins industrialisable qui soit.
Discussion