Sommaire

Vous avez peaufiné vos prompts, ajouté des connaissances avec le RAG, et peut-être même fait du fine-tuning — alors comment confirmer que cela « s'est vraiment amélioré » ? C'est là que les AI evals (évaluation) entrent en scène. D'ici 2026, l'évaluation est devenue si essentielle à la construction de l'IA qu'on la qualifie d'« infrastructure ».

Cet article explique aux débutants ce que sont les AI evals, pourquoi vous en avez besoin, les deux méthodes d'évaluation, le fonctionnement et les pièges du fameux « LLM-as-judge », et comment le mettre en œuvre en pratique.

AI EVALS · ON N'AMÉLIORE QUE CE QUE L'ON MESURE

Mesurez avec du code ; jugez le goût avec l'IA

— transformez le « ça a l'air pas mal » en un chiffre

📏

Définir les critères

Transformez « une bonne réponse » en un étalon concret.

⚙️

Noter automatiquement

Évaluez de façon cohérente à chaque fois, avec du code ou de l'IA.

📈

Suivre l'évolution

Surveillez en continu ce qui s'améliore ou se dégrade.

1. Que sont les AI evals ?

Les AI evals consistent à mesurer systématiquement la qualité des sorties d'un LLM. « Cette réponse est-elle exacte ? » « Y a-t-il des hallucinations (faits inventés) ? » « Le format requis est-il respecté ? » « Le ton est-il approprié ? » — vous notez ces points selon un étalon fixe plutôt qu'à l'instinct sur le moment.

Imaginez « corriger une copie ». Vous donnez à l'élève (l'IA) une question (l'entrée) et vous la notez par rapport à un corrigé ou à une grille. Une fois que vous pouvez noter, vous voyez enfin « quel changement l'a améliorée et lequel l'a dégradée ». Sans evals, l'amélioration n'est qu'une intuition.

💡 En une ligne : les evals = « un système qui note les sorties de l'IA ». Les ajustements de prompt et le fine-tuning ne prennent du sens que lorsque vous disposez d'un étalon pour les mesurer.

2. Pourquoi en avez-vous besoin : ne livrez pas au feeling

Un programme ordinaire est figé — « l'entrée A donne toujours la sortie B » — mais l'IA varie même sur une entrée identique (elle est non déterministe), et « bon ou mauvais » est souvent subjectif. Du coup, « j'en ai essayé quelques-uns, ça avait l'air bien, on livre » est risqué. Les quelques cas que vous avez vus n'étaient peut-être bons que par chance.

Systématiser l'évaluation vous permet de faire ceci :

  • Juger les changements par les chiffres : quand vous changez un prompt ou un modèle, comparez par score
  • Détecter les régressions : vérifiez si une « amélioration » a cassé autre chose
  • Surveiller la qualité en production : repérez quand la performance de l'IA se dégrade en exploitation

Cela se marie bien avec le développement piloté par la spécification. Décidez « quoi construire » (la spec) et « mesurez si vous l'avez construit » (les evals) — avec les deux en place, le développement IA devient enfin gérable.

3. Deux méthodes : code vs LLM-as-judge

Il existe globalement deux façons d'évaluer. Mesurez mécaniquement avec du code ; faites noter par une IA ce qui est subjectif — ce partage est le principe de base.

À BASE DE CODE (déterministe)

Juger mécaniquement par des règles

  • Correspondance exacte, format requis (JSON, etc.)
  • Contient un mot requis / évite un mot interdit
  • Rapide, peu coûteux, même résultat à chaque fois
  • Idéal pour les éléments à réponse claire
LLM-AS-JUDGE (noté par modèle)

Faire noter une IA par une IA

  • Hallucination, pertinence, utilité, ton
  • Éléments subjectifs sans réponse unique
  • Plus rapide et moins cher que les humains, à grande échelle
  • Mais attention à ses travers (les biais)

La règle d'or : « ne faites pas noter par une IA ce que vous pouvez mesurer avec du code ». L'évaluation par code est plus rapide, moins chère et plus stable. Réservez le LLM-as-judge aux éléments subjectifs que le code a du mal à juger, comme la présence d'une hallucination.

4. Comment fonctionne le LLM-as-judge

Le LLM-as-judge consiste à utiliser un LLM puissant comme « arbitre » pour noter la sortie d'une autre IA. Vous transmettez au LLM juge un prompt contenant les critères, l'entrée et la sortie, et il renvoie un score, un pass/fail, ou « lequel est le meilleur ». Il existe deux grands styles.

Comparaison pairwise

Placez deux réponses côte à côte et demandez « laquelle est la meilleure ? » L'IA est douée pour juger laquelle est relativement plus forte. Parfait pour la comparaison A/B.

Notation d'une seule sortie

Évaluez une réponse par rapport à une grille pour lui attribuer un score. Idéal pour suivre la qualité absolue dans le temps.

⚠️ Une notation grossière est plus précise : l'IA est mauvaise pour la notation fine de 1–10 et fluctue. Une échelle grossière comme « pass/fail » ou « 1–3 » donne en réalité des résultats plus stables.

5. Le piège : les biais du juge

Le LLM-as-judge a ses « travers d'arbitre ». Si vous les ignorez, vous ferez trop confiance aux scores et apporterez les mauvaises améliorations. Gardez à l'esprit ces trois biais majeurs.

① Biais de verbosité

Tend à mieux noter les réponses plus longues et plus complexes — même un contenu mince gagne par la seule longueur.

② Biais de position

L'ordre dans lequel vous listez les réponses (p. ex. celle affichée en premier) crée un avantage ou un désavantage.

③ Préférence pour soi

Tend à mieux noter les réponses qu'il a lui-même rédigées (la même famille de modèle).

Les contre-mesures sont simples.

  • Utilisez un modèle différent comme correcteur : ne notez pas une sortie GPT avec GPT. Faites arbitrer par une autre famille — Claude, Gemini, etc. — pour éviter la préférence pour soi.
  • Inversez l'ordre et notez deux fois : conservez le résultat si les deux concordent, écartez-le s'ils divergent (contrôle du biais de position).
  • Inscrivez la « concision » dans la grille : « ne juge pas selon la longueur » ne suffit pas à lui seul. Ajoutez un critère de concision et demandez au juge de pénaliser la verbosité.
  • Calibrez par rapport au jugement humain : faites noter un petit échantillon par une personne et ajustez les critères pour qu'ils correspondent aux scores de l'IA. C'est l'étape la plus efficace.

6. En pratique : l'évaluation comme « infrastructure »

Dans la pratique de 2026, l'évaluation n'est pas ponctuelle — la norme est de la faire tourner en continu sur trois niveaux (« l'évaluation comme infrastructure »).

① Vérification instantanée à chaque changement

Lancez automatiquement des evals légères à base de code à chaque modification du code (CI). Bloquez instantanément les casses évidentes.

② Tests de régression nocturnes

Notez la qualité en masse pendant la nuit avec le LLM-as-judge. Détectez la dégradation lente et insidieuse.

③ Surveillance continue en production

Surveillez les sorties en direct et alertez quand la qualité chute. Limitez l'impact sur les vrais utilisateurs.

Les outils ont mûri eux aussi. Pour des exécutions CI légères, DeepEval (qui ressemble à pytest) ou Promptfoo ; pour le RAG en particulier, RAGAS (mesure de la fidélité, de la pertinence, et plus). Pour la revue humaine, les tableaux de bord et la surveillance en production, des plateformes comme Braintrust, LangSmith et Arize. En pratique, associer « un outil CI léger » à « une plateforme de surveillance » est la norme. La même machinerie d'évaluation soutient aussi la qualité dans la construction d'agents IA.

※ Les noms d'outils et les méthodes sont cités à partir de divers guides et publications (à jour en juin 2026). La meilleure configuration varie selon la taille de l'équipe et le cas d'usage.

En résumé

Trois points à retenir sur les AI evals.

  • Ce que c'est : un système qui note les sorties d'un LLM, transformant l'amélioration d'une « intuition » en « chiffres ». Une étape essentielle du développement IA.
  • Deux méthodes : les evals par code pour les éléments déterministes, le LLM-as-judge pour les subjectifs. Mesurez avec du code tout ce que le code peut mesurer.
  • Attention : le LLM-as-judge présente des biais de verbosité, de position et de préférence pour soi. Gérez-les avec un modèle correcteur différent, une échelle grossière et une calibration humaine.

Commencez par rassembler 10 « bonnes sorties » et 10 « mauvaises sorties » de votre propre IA et notez-les selon des critères simples. Cela devient votre premier étalon. Lisez fine-tuning et ingénierie de contexte en parallèle pour avoir une vue complète de l'amélioration de l'IA.

FAQ

Q. Peut-on vraiment faire confiance à une IA qui note une IA ?

R. Pas aveuglément. À cause des biais de verbosité, de position et de préférence pour soi, il est important de noter avec une famille de modèle différente et de calibrer par rapport à un petit échantillon noté par des humains. Une fois calibrée, elle tourne à grande échelle avec une précision proche de l'humain.

Q. Combien d'exemples d'eval me faut-il ?

R. Vous pouvez très bien commencer avec quelques dizaines. L'astuce consiste à rassembler de vrais bons et mauvais exemples et à construire d'abord un petit jeu d'eval. Plutôt que de viser la perfection, faites évoluer les critères au fil du temps — c'est plus pratique.

Q. Evals par code ou LLM-as-judge — lequel utiliser ?

R. Les deux. Utilisez les evals par code pour ce qui est mécaniquement mesurable, comme le format et les mots requis ; utilisez le LLM-as-judge pour les aspects subjectifs comme l'hallucination et le ton. Inutile de faire noter par une IA ce que vous pouvez mesurer de façon déterministe.

Q. Les développeurs solo ont-ils besoin d'evals ?

R. Elles aident quelle que soit l'échelle. Même un petit « standard de bonne sortie » vous permet de savoir si un changement de prompt ou de modèle est une amélioration ou une régression. Noter à la main une poignée d'exemples est déjà un bon début.