Évaluations des systèmes d'IA
Ce guide référence les pratiques d'évaluation de systèmes d'IA existantes au sein de l'État. Il permet à tout agent public qui souhaite évaluer un système d'IA de s'inspirer de ce qui a déjà été fait, voire de le réutiliser directement, plutôt que de repartir de zéro. Les initiatives référencées ne sont pas toutes portées par la DINUM : elles viennent aussi d'autres ministères et opérateurs. Certaines peuvent ne plus être maintenues, vérifiez leur état avant de les réutiliser.
Pourquoi faire des évaluations ?
Un système d'IA peut se tromper de façon discrète mais lourde de conséquences : dans une transcription, « on doit faire ça » devenu « on ne doit pas faire ça » ne diffère que de deux mots, mais le sens est inversé. Évaluer permet :
de décider : choisir un modèle ou une architecture sur des chiffres plutôt que sur une démo, les benchmarks publics couvrant mal nos cas d'usage,
de fiabiliser : savoir ce que vaut le produit en production et détecter les dérives,
d'améliorer : mesurer l'effet de chaque changement plutôt que piloter à l'intuition.
L'évaluation transforme ainsi un débat d'opinions en décision objectivée.
Principes communs
Un jeu de données de référence d'abord. Sans vérité terrain, on ne compare rien. 20 à 50 cas réels bien choisis valent mieux qu'un gros corpus non vérifié.
Des comparaisons relatives, pas des notes absolues. Un score sert à comparer deux modèles, deux versions ou deux configurations sur le même jeu de données.
Automatique et humain. Les métriques automatiques permettent d'itérer vite. La revue humaine (référents métier) tranche sur la justesse et l'utilité.
Reproductible. Cache des réponses, rapports régénérables sans rappeler l'API, configuration versionnée.
Données sensibles = inférence souveraine obligatoire. Traiter les corpus via Albert API, ne jamais les versionner, publier l'outil mais pas les données.
Le LLM-as-a-judge
Le principe : utiliser un modèle de langage (le « juge ») pour noter les réponses d'un autre système d'IA, à partir d'une consigne d'évaluation et, si possible, d'une réponse de référence. Il permet de passer à l'échelle là où la revue humaine est lente et coûteuse.
Bonnes pratiques :
définir une grille explicite (critères, niveaux de gravité) plutôt que demander « est-ce une bonne réponse ? »,
exiger une justification : le juge cite l'extrait fautif et explique sa note,
recourir à un panel de juges : plusieurs modèles notent séparément et l'on retient les cas où ils s'accordent (méthode utilisée dans eval-transcript),
calibrer le juge sur un échantillon relu par des experts métier avant de lui faire confiance.
Attention aux biais connus du juge : préférence pour les réponses longues , attribution d'une bonne note à une réponse générée par le même modèle et notes qui se tassent vers le haut.
Poser des questions binaires plutôt que demander une note
Le papier Ask, Don't Judge (BINEVAL), publié en juin 2026, propose de remplacer la note globale (« note cette réponse sur 10 ») par une série de questions fermées oui/non, par exemple « La réponse contient-elle une information absente de la source ? » ou « Toutes les entités citées sont-elles correctes ? ».
Ce que ça apporte :
des scores interprétables : on voit quel critère pèche (« 92 % de factualité, 60 % de complétude ») au lieu d'un chiffre opaque,
des notes qui ne se tassent plus vers 8 ou 9 sur 10 et restent plus proches du jugement humain, notamment pour détecter les hallucinations,
aucun entraînement nécessaire : tout repose sur le prompt du juge,
un levier d'amélioration : les réponses question par question indiquent quoi corriger dans le prompt du système évalué.
Limite : la méthode vise les tâches ouvertes (résumé, dialogue, réponse d'assistant). Pour une transcription ou un OCR, les métriques de référence (WER, CER) restent le premier niveau de mesure.
Initiatives existantes au sein de l'administration
Évaluation de modèles spécialisés (STT, OCR & HTR)
eval-transcript (initiative portée par le département IA dans l'État de la DINUM). Banc d'évaluation des modèles de transcription. Plusieurs fournisseurs (AlbertAPI et fournisseurs privés), calcul du WER (Word Error Rate, taux d'erreur mot), un LLM juge et un panel de juges pour qualifier la gravité des erreurs. Éxécution en CI et jeux de données publics sur Hugging Face.
eval-ocr-htr (initiative portée par le département IA dans l'État de la DINUM). Banc d'évaluation OCR et reconnaissance d'écriture manuscrite sur des documents scannés, via Albert API. Deux modes : page entière, et ligne par ligne à partir d'une segmentation XML. Mesure la qualité, détecte les sorties inexploitables (boucles, texte inventé), extrapole durée et coût à l'échelle d'un corpus.
Plateforme d'évaluation de modèles de langage
EvalAP (initiative portée par le département IA dans l'État de la DINUM). Plateforme et API d'évaluation de modèles : jeux de données, métriques, expériences, interface web et notebooks. Pas de développement actif à date.
Arène de comparaison de modèles généraliste
compar:IA (initiative portée par le Ministère de la Culture et la DINUM). Arène ouverte au public : l'usager pose une question, compare les réponses de deux modèles anonymes et vote pour sa préférée. Les votes produisent un classement des modèles et des jeux de données publics de conversations et de préférences en français (Hugging Face). Limite : une préférence reflète souvent le style de la réponse plus que sa justesse, elle complète une évaluation sur jeu de référence sans la remplacer.
Évaluation des outils mis à disposition d'un agent IA (MCP, CLI, etc.)
datagouv-ai-evaluation (initiative portée par les équipes de data.gouv.fr). Évalue la manière dont un agent exploite data.gouv.fr selon le mode d'accès (MCP, API, CLI, skills), le modèle et le prompt système. Chaque combinaison est jouée sur de vraies questions, notée par LLM juge et par des métriques déterministes, puis comparée. Sert aussi de test de non-régression du serveur MCP.
geocontext-test (initiative portée par l'IGN). Tests d'intégration du serveur MCP Géocontexte sur plusieurs modèles : un scénario réel par test, vérification de la réponse attendue et des outils appelés, rapport par modèle.
Évaluer un assistant RAG, un guide complet existe
Nous avons publié un guide de construction d'un assistant RAG qui propose une démarche d'évaluation en cinq étapes :
Évaluations par les référents métier : l'équipe écarte d'abord les réponses manifestement fausses, puis des experts valident la justesse métier, avant des tests utilisateurs élargis.
Jeu de données de référence : 20 à 50 questions, chacune avec une bonne réponse validée, sa source officielle et sa date, maintenu dans la durée.
Évaluations automatisées : pertinence, fidélité aux sources, abstention et rapidité, mesurées séparément sur la recherche documentaire et sur la génération.
Sources de régression en production : usages réels plus variés que prévu, documentation qui évolue, recherche qui se dégrade avec le volume.
Évaluations continues : observer, mesurer, faire relire un échantillon par des humains, décider. Ni revue humaine à chaque itération, ni absence totale.
Autre initiative
Inspect (initiative portée par l'AI Security Institute britannique). Framework Python open source d'évaluation de modèles de langage. Une évaluation s'y décrit en quatre briques :
un jeu de données : entrées et réponses attendues,
un solveur qui produit la réponse : simple appel au modèle ou agent équipé d'outils,
un évaluateur qui la note : comparaison exacte, expression régulière ou LLM juge,
une tâche qui assemble le tout.
Il fournit plus de 200 benchmarks prêts à l'emploi, gère nativement MCP et l'appel d'outils, et propose une interface web pour inspecter chaque échange. Compatible avec une vingtaine de fournisseurs de modèles, dont les API compatibles OpenAI comme Albert API.
Mis à jour
Ce contenu vous a-t-il été utile ?