Pourquoi les évaluations LLM comptent pour la gouvernance de l'IA

Si vous livrez quoi que ce soit bâti sur un grand modèle de langage, vous vivez avec une vérité inconfortable. Vous ne pouvez pas savoir qu'il fonctionne correctement dans chaque cas. L'espace des entrées possibles est de fait infini, et même le fournisseur du modèle ne peut pas garantir la cohérence entre deux prompts presque identiques. Cette incertitude est la raison pour laquelle les équipes gouvernance veulent désormais voir les résultats d'évaluation avant qu'une chose ne soit mise en ligne.

Ce billet est un regard pratique sur ce que mesurent les évaluations, pourquoi les équipes les sautent, et comment elles se rattachent aux cadres de gouvernance IA que les régulateurs appliquent désormais : l'EU AI Act, l'ISO/IEC 42001 et les attentes de documentation qui en découlent.

Les quatre risques que les évaluations sont conçues pour révéler

Quand les équipes demandent « le modèle est-il assez bon ? », elles désignent généralement l'une des quatre choses très différentes. Les évaluations sont la manière de les distinguer.

Hallucination. Le modèle produit une sortie qui sonne plausible mais qui n'est pas vraie. Cela arrive avec des données d'entraînement faibles, mais plus souvent quand une entreprise donne au modèle ses propres données (base de connaissances, bibliothèque de politiques, dossiers clients) et que le modèle les lit mal ou invente autour des lacunes. On teste cela en faisant tourner un jeu de questions connues et en vérifiant que la réponse du modèle correspond bien à ce qui est dans la source.

Biais et équité. C'est la partie qui intéresse le plus les régulateurs. Il n'y a pas beaucoup de réglementation qui impose la précision brute, mais il y a beaucoup de réglementation qui impose un traitement équitable entre groupes. Une évaluation de biais utile pose la même question en faisant varier le genre, le revenu, l'origine, l'âge, la géographie et une vingtaine d'autres axes, puis vérifie si la réponse change d'une manière qu'elle ne devrait pas.

Imprécision liée au fine-tuning. Dès l'instant où vous fine-tunez un modèle de base sur vos propres données, vous changez son comportement. Ce changement peut être utile. Il peut aussi introduire silencieusement des erreurs et des biais. Les évaluations sont la manière d'attraper la régression avant qu'elle ne soit livrée.

Défauts hérités du modèle. Les modèles open-weights plus petits ont des faiblesses connues. Les modèles frontière plus grands d'OpenAI ou Anthropic ont les leurs. Votre évaluation doit faire remonter celles qui touchent votre cas d'usage spécifique.

Si vous livrez du RAG ou un agent, le vocabulaire de métriques s'élargit (fidélité et précision contextuelle pour le retrieval, exactitude des outils et adhésion au plan pour les agents), mais les quatre risques sous-jacents et l'argument de gouvernance ne changent pas.

La revue humaine seule ne tient plus à l'échelle

Il y a quelques années, vous évaluiez un LLM en mettant des humains devant chaque sortie. C'est comme cela que fonctionnait le RLHF dans les grands labos. Les chercheurs lisaient les réponses, les notaient et renvoyaient le signal dans l'entraînement. Ça marche encore. Ça ne suit simplement pas le volume d'évaluations que l'IA en production demande aujourd'hui.

Le standard actuel est LLM-as-a-judge. Vous utilisez un modèle puissant pour évaluer les sorties du modèle que vous livrez. Le juge lit chaque réponse, la note contre une métrique définie (exactitude, hallucination, biais, équité, etc.) et renvoie à la fois le score et un court raisonnement écrit, pour qu'un humain puisse auditer le jugement plutôt que de lui faire aveuglément confiance.

Des méthodes d'évaluation purement mathématiques existent toujours (exact-match, BLEU, ROUGE, similarité d'embeddings) et ont leur place. Mais pour les questions qualitatives qui intéressent la gouvernance (« cette réponse était-elle équitable ? », « était-elle ancrée dans le matériel source ? »), LLM-as-a-judge est devenu la valeur par défaut.

Le juge n'est pas un blanc-seing. Des études ont montré que les juges LLM favorisent leurs propres sorties, notent de manière incohérente d'un run à l'autre, et ratent des erreurs quand une réponse est livrée avec assurance. Le juge lui-même a donc besoin d'un échantillonnage de contrôle : un relecteur humain lit un petit échantillon des sorties jugées et confirme que le juge est d'accord avec sa propre lecture. Le modèle et la version du juge doivent figurer dans la piste d'audit à côté du reste.

Trois stades de maturité d'évaluation

L'évaluation n'est pas binaire. La plupart des équipes traversent trois stades, et savoir dans lequel vous êtes vous dit dans quoi investir ensuite.

Stade 1 : assertions déterministes. Bon marché, rapide, fragile. Vérifications regex, validation de schéma, bornes de longueur, détection de refus. Elles attrapent les échecs évidents et tournent à chaque commit. Une quantité surprenante de valeur de gouvernance vient simplement de faire cela de manière cohérente.

Stade 2 : LLM-as-a-judge sur un jeu de données statique. Un ensemble curé de prompts, un modèle plus fort qui note contre des métriques définies par rubrique, un rapport versionné. C'est le niveau que la plupart des régulateurs supposent implicitement quand ils demandent des « preuves de tests » au titre de l'EU AI Act.

Stade 3 : évaluation continue sur du trafic de production. Échantillonnage des requêtes en direct, juges sans référence appliqués, alertes en cas de dérive des scores. C'est là que vit l'ISO 42001, et le stade où presque personne n'est encore.

Vous ne pouvez pas vraiment sauter un stade. Tenter le stade 3 sans jeu de données de stade 2, c'est juste monitorer du bruit pour lequel vous n'avez pas de référence.

Comment cela se rattache à l'EU AI Act et à l'ISO 42001

Les évaluations sont utiles à la gouvernance parce qu'elles produisent quelque chose que les régulateurs demandent explicitement : la preuve de comment le système se comporte, et pas seulement la preuve de comment il a été construit.

Au titre de l'EU AI Act, les fournisseurs et déployeurs de systèmes IA à haut risque doivent maintenir une documentation technique, conduire des tests et démontrer que les risques du système ont été identifiés et atténués. Un rapport d'évaluation avec des scores en hallucination, biais et équité (avec les échantillons sous-jacents et le raisonnement du juge attaché) est un artefact concret que vous pouvez poser devant un auditeur. Plus difficile à contester que « nous avons utilisé un modèle réputé ».

L'ISO/IEC 42001, la norme système de management de l'IA, demande quelque chose de similaire : une assurance continue et documentée que le système continue de fonctionner à l'intérieur des seuils de risque que vous avez définis. Les évaluations transforment cette exigence abstraite en quelque chose de mesurable. Un seuil par métrique. Un statut pass/fail. Une piste versionnée.

Continue est le mot opératoire. Un seul run d'éval avant le lancement ne satisfait pas l'ISO 42001. La norme attend un rythme récurrent : réévaluation périodique contre le même jeu de données, monitoring échantillonné du trafic en direct, et réponse documentée en cas de dérive des scores. Un test ponctuel valide le lancement mais ne maintient pas le système dans le périmètre par la suite.

Pour plus de comparaison entre les deux cadres et leurs points de divergence, voir notre analyse EU AI Act vs ISO 42001.

Ce qui tient en audit n'est pas le score. C'est la piste qui le précède : qui a testé quoi, contre quel jeu de données, sur quelle version de modèle, avec quel juge, contre quelles métriques, avec quel résultat.

Ce dont une vraie évaluation a besoin

Quatre ingrédients :

1. Le modèle sous test. Le modèle exact et la version que vous comptez livrer, avec la même configuration qu'en production.
2. Un jeu de données. Prompts d'entrée et, pour les métriques mesurables, sorties attendues. Le jeu de données doit refléter la distribution réelle des questions que votre système verra, pas seulement les faciles. Certaines métriques ont besoin de sorties de référence (exactitude, exact-match). D'autres (fidélité, utilité, toxicité) sont sans référence et notent la réponse directement. L'évaluation de stade 3 sur le trafic de production est principalement de la seconde sorte, puisque vous avez rarement la vérité terrain pour les requêtes en direct.
3. Un juge. Soit un modèle plus fort, soit, pour certaines métriques, une vérification déterministe. Le juge a besoin d'une rubrique de notation claire et doit être obligé de donner un raisonnement, pas seulement un chiffre.
4. Métriques et seuils. Une définition numérique de « assez bon ». Un point de départ courant est autour de 0,5 à 0,6 par métrique, tout ce qui est en dessous étant routé vers un relecteur humain. Là où vous placez la barre est une décision produit et risque, pas technique, et vous devez documenter cette décision à côté du score. Les auditeurs demanderont pourquoi vous avez choisi 0,6 et pas 0,8, et « la métrique avait ce défaut » n'est pas une réponse.

La sortie est un détail par échantillon : chaque prompt, la réponse du modèle, le score du juge, le raisonnement du juge. Pour les cas d'usage à faible volume, vous pouvez lire chaque échantillon. Pour les systèmes à fort volume, les résumés de raisonnement sont la manière dont la gouvernance et l'ingénierie examinent les échecs sans patauger dans des milliers de réponses. Les clusters d'échec sont d'où viennent les travaux du prochain sprint. Un schéma d'hallucination récurrent est un correctif prompt ou RAG. Un schéma de biais récurrent est une escalade équité. Une erreur d'outil récurrente est un problème de design d'agent. Une évaluation qui ne change rien au sprint suivant est un rapport d'état, pas un contrôle.

Pourquoi les équipes sous-investissent encore là-dessus

Deux raisons, surtout.

La première : les évaluations ressemblent à du surcoût jusqu'à ce que quelque chose tourne mal. Il n'y a pas de ticket urgent demandant un audit de biais, jusqu'au jour où il y a un ticket très urgent demandant pourquoi le modèle a traité deux cohortes clients différemment.

La seconde : l'outillage est fragmenté depuis des années. Bibliothèques séparées pour les métriques, tableaux de bord séparés pour les résultats, feuilles de calcul séparées pour la documentation que veulent les régulateurs. Les équipes se retrouvent avec une logique d'évaluation répartie à trois endroits et aucun artefact unique à remettre à un auditeur ou au juridique.

Combler cet écart est précisément à quoi sert un bon outillage d'évaluation. Un endroit pour définir le modèle, le jeu de données, le juge, les métriques et le seuil. Un endroit pour voir les résultats par échantillon. Une piste à tendre à quiconque le demande.

Ce qu'il faut faire ce trimestre

Si vous livrez quelque chose basé sur du LLM et que vous n'avez pas encore de pipeline d'évaluation, le plus petit pas utile est celui-ci.

• Choisissez le cas d'usage où une mauvaise réponse vous coûterait le plus, juridiquement, en réputation ou commercialement.
• Construisez un jeu de données de 50 à 100 prompts réels pour ce cas d'usage (tirés des logs de production quand possible, complétés par des cas limites synthétiques générés par un modèle plus fort), avec des réponses attendues quand applicable.
• Lancez une évaluation LLM-as-a-judge contre exactitude, hallucination et biais. Trois métriques, pas trente.
• Fixez un seuil. Faites du bruit quand vous le franchissez.
• Sauvegardez le rapport. Versionnez-le à côté de votre modèle.

C'est le niveau de rigueur que les régulateurs attendent des systèmes à haut risque au titre de l'EU AI Act, et le niveau de preuve que les audits ISO 42001 demanderont de plus en plus. Indépendamment de la conformité, c'est aussi le moyen le moins cher de découvrir que votre modèle a tort avant que vos clients ne le découvrent.

Les évaluations ne sont pas un exercice académique. C'est ainsi que vous prouvez, sur le papier, que votre système IA a fait ce que vous aviez dit qu'il ferait.

La plateforme de VerifyWise réunit inventaire de modèles, évaluations, risque et preuves dans un même espace de travail, de sorte que la piste d'audit se construit d'elle-même au fil du travail de votre équipe. Si votre logique d'évaluation est éparpillée entre bibliothèques, dashboards et feuilles de calcul en ce moment, cela vaut un coup d'œil.