Jeu de test (« golden set ») : évaluer un outil d'IA avant de l'acheter, puis après chaque changement de modèle

Un jeu de test, ou golden set, est un ensemble figé de questions réelles dont la bonne réponse, la bonne source et le comportement attendu sont connus à l'avance. On le pose à l'identique à chaque outil d'IA candidat, dans les mêmes conditions, puis on le rejoue après chaque changement de modèle, de sources ou de paramétrage. C'est le seul moment de l'évaluation où c'est l'acheteur, et non l'éditeur, qui choisit les questions et connaît les réponses.

Le besoin est concret. En 2024, une équipe de Stanford a testé des outils de recherche juridique dont les éditeurs affirmaient qu'ils ne produisaient pas d'hallucinations : les outils testés se trompaient dans 17 à 33 % des cas (Magesh et al., « Hallucination-Free? », 2024). Ce guide explique ce qu'un jeu de test mesure que les benchmarks et les démonstrations ne mesurent pas, comment le composer (familles de questions, questions pièges), comment noter les réponses, quand le rejouer, et quelles précautions prendre quand les dossiers servant au test contiennent des informations sensibles. Il fait partie de notre série sur le deuxième cerveau, l'IA agentique et la gestion de la connaissance en environnement réglementé.

Jeu de test, benchmark, démonstration, essai libre : de quoi parle-t-on ?

Définition courte : quatre façons d'« évaluer » un outil d'IA coexistent, et elles ne mesurent pas la même chose. Trois d'entre elles sont organisées par l'éditeur ou par des tiers ; une seule est organisée par l'acheteur.

Analyse : la limite des benchmarks publics n'est pas théorique. Une étude de 2023 montre que de simples variantes des questions de test (paraphrase, traduction) échappent aux filtres de « décontamination » habituels, et qu'un modèle de 13 milliards de paramètres entraîné sur ces variantes peut atteindre des scores comparables à GPT-4 ; les auteurs ont relevé que 8 à 18 % d'un benchmark de programmation se retrouvaient dans des corpus d'entraînement courants (Yang et al., « Rethinking Benchmark and Contamination », 2023). Un bon score public mesure donc, au mieux, le modèle, jamais l'outil que vous allez utiliser.

Le point décisif est là : ce que vous achetez n'est pas un modèle, mais un système. Deux outils fondés sur le même modèle donneront des réponses différentes selon les sources qu'ils relient, la façon dont ils découpent et retrouvent les documents, les droits d'accès qu'ils appliquent et la manière dont ils citent (ou non) leurs sources. Nous avons détaillé ces mécanismes dans notre article sur les limites d'un RAG en entreprise. Le jeu de test est l'instrument qui mesure ce système-là, chez vous.

Pourquoi tester un outil d'IA sur ses propres dossiers : cinq raisons

Préparer un jeu de test prend du temps. Cinq raisons justifient de le prendre avant de signer, et non après.

1. Vos données ne ressemblent pas à celles de la démonstration. Une base réelle contient des doublons, des homonymes, des documents mal rattachés, des notes contradictoires et des versions successives. C'est le premier facteur d'erreur d'une IA d'entreprise, comme nous l'avons montré à propos de la qualité des données avant l'IA. Un outil qui brille sur une base propre peut se tromper sur la vôtre.
2. La fiabilité annoncée n'est vérifiable qu'en testant. L'étude de Stanford citée en introduction portait sur des outils vendus comme exempts d'hallucinations ; la mesure a donné 17 à 33 % d'erreurs. Ce n'est pas une accusation contre un secteur, c'est un rappel : une affirmation de fiabilité se vérifie, elle ne se lit pas.
3. L'outil que vous voyez n'est pas celui que vous aurez dans six mois. Les éditeurs changent de modèle, parfois sans préavis ; le paramétrage et les sources évoluent. Sans jeu de test, vous n'avez aucun moyen de savoir si un changement a amélioré ou dégradé les réponses. Avec, vous comparez des résultats sur les mêmes questions à six mois d'écart.
4. Les droits d'accès ne se voient pas en démonstration. Un assistant relié à tous les documents peut restituer à un collaborateur ce qu'il n'aurait pas dû voir. Seule une question posée depuis un profil non autorisé le révèle. Notre guide sur le cloisonnement d'un assistant d'entreprise décrit les cinq mécanismes de contournement à tester.
5. Le cadre attend des preuves, pas des impressions. L'Autorité européenne des marchés financiers rappelle, dans sa déclaration du 30 mai 2024 sur l'IA dans les services d'investissement, que l'organe de direction reste responsable des décisions, qu'elles soient prises par une personne ou par un outil, et attend des entreprises qu'elles testent et surveillent les systèmes qu'elles utilisent (ESMA, Public Statement on AI and investment services, 2024). Le règlement européen sur l'IA pose le même principe pour les systèmes à haut risque : leurs niveaux d'exactitude et les métriques correspondantes doivent être déclarés dans la notice d'utilisation (règlement (UE) 2024/1689, article 15 § 3). Un assistant documentaire de cabinet n'entre généralement pas dans cette catégorie, mais le principe est posé : l'exactitude se mesure et se documente. Enfin, la fiche pratique destinée aux TPE et PME, diffusée par France Num et la CNIL, range la « fiabilisation des résultats » parmi les bénéfices à vérifier et rappelle que « l'humain doit rester le dernier maillon de la chaîne » (fiche 3 « Choisir parmi les solutions d'IA générative », novembre 2024).

Hypothèse de travail : dans une petite structure, le jeu de test remplace avantageusement le cahier des charges fonctionnel de cent lignes. Il est plus court à produire, plus facile à comparer entre éditeurs, et il reste utile après l'achat, ce que le cahier des charges n'est jamais.

Composer le jeu de test : taille, familles de questions et questions pièges

Taille. Pour une structure de quelques personnes qui évalue un assistant relié à ses documents, trente à cinquante questions suffisent, à condition d'être variées. Un repère utile, issu de la documentation de l'éditeur d'outils d'évaluation Langfuse : commencer par vingt à cinquante cas relus, et retenir que « cent exemples différents valent mieux que mille quasi-doublons » (Langfuse, Golden dataset evaluation). Le volume n'est pas le sujet ; la couverture des situations difficiles l'est.

D'où viennent les questions. Des questions réellement posées par l'équipe, des erreurs passées, des « je ne trouve pas » entendus lors d'une passation, des demandes clients récurrentes. Pas de questions idéales rédigées pour l'occasion. Chaque question est écrite par la personne qui la poserait vraiment, et la réponse attendue est vérifiée par une seconde personne avant d'interroger le moindre outil. Pour chaque question, la fiche contient : le libellé, le profil qui la pose, la réponse attendue, la source attendue, le comportement attendu, le piège éventuel.

Les familles à couvrir. Le tableau ci-dessous prolonge les sept familles de notre méthode de test d'un RAG et en ajoute trois (injection, ambiguïté, question réglementaire datée). Les exemples sont ceux d'un cabinet de conseil patrimonial ; ils se transposent à toute profession qui travaille sur dossiers.

Analyse : les familles 3, 8 et 9 sont celles qui séparent le plus nettement les outils, parce qu'elles testent ce que l'outil ne doit pas faire. Un outil qui répond toujours est plus agréable en démonstration et plus dangereux en production. Notre article sur la fiabilité des réponses d'une IA décrit les six formes d'erreur à reconnaître ; celui sur l'injection de prompt explique pourquoi la famille 9 devient indispensable dès que l'outil lit des emails entrants.

Trois règles de gestion du jeu. Il est figé : on ne modifie une question qu'en changeant de version, pour que les résultats restent comparables. Il est confidentiel : on ne le transmet jamais à l'éditeur, qui pourrait, de bonne foi, optimiser son outil dessus, ce qui reproduirait à petite échelle la contamination des benchmarks. Il ne grossit pas au fil de l'eau : les nouvelles questions issues d'incidents entrent lors d'une révision datée, pas au coup par coup.

Juger sur pièces, sur vos dossiers réels

Le jeu de test que vous venez de composer est exactement ce que prévoit la méthode Brain. Après l'audit, on relie deux ou trois sources, puis on teste sur vos dossiers réels : chaque réponse est relue avec le cabinet, sur son contenu et sur sa source, et reçoit un statut « Validé » ou « À reprendre ». La règle est simple : tant qu'une réponse n'est pas juste et sourcée, on ne passe pas à la suite. Commencer petit n'est pas une économie, c'est ce qui permet de juger Brain sur pièces avant d'aller plus loin.

Voir la méthode, étape par étape Comment les réponses citent leurs sources

Tests sur dossiers réels • Réponse et source vérifiées • Chaque étape est une possibilité, jamais une obligation

Noter les réponses : grille de notation, règles d'acceptation et limites du « LLM juge »

Une réponse ne se note pas « bonne » ou « mauvaise ». Elle se note sur quatre critères indépendants, parce qu'une réponse peut être exacte et mal sourcée, ou sourcée et incomplète, ou juste mais obtenue en lisant un document interdit. La grille ci-dessous tient sur une feuille de calcul.

À ces quatre critères s'ajoutent deux mesures d'usage, notées à part : le temps de réponse et, surtout, le temps de vérification, c'est-à-dire le temps qu'il faut à un humain pour contrôler la réponse à partir de la source citée. Un outil qui répond vite mais dont la source est introuvable fait perdre le temps qu'il prétend faire gagner. Ce temps de vérification est aussi au cœur d'une validation humaine efficace.

Règles d'acceptation (analyse, pas norme). Il n'existe pas de seuil universel ; en revanche, quelques règles sont robustes :

• Deux critères éliminatoires : une seule source inventée, ou une seule fuite de droits d'accès, disqualifie l'outil tel qu'il est configuré, quel que soit le score moyen.
• Regarder la pire famille, pas la moyenne. Un score global flatteur cache souvent une famille (information absente, versions) où l'outil échoue presque toujours. C'est cette famille qui déterminera les incidents en production.
• Noter en aveugle. Quand plusieurs outils sont comparés, les réponses sont copiées dans un document anonyme, dans un ordre mélangé, avant notation.
• Deux évaluateurs sur un sous-ensemble. Dix questions notées indépendamment par deux personnes ; si elles sont en désaccord sur plus de deux, la grille est à préciser avant de continuer.
• Noter l'outil tel qu'il sera utilisé. Mêmes sources, mêmes droits, même paramétrage pour chaque candidat ; une question posée par le dirigeant et par un assistant n'est pas la même question.

Et le « LLM juge » ? Il est tentant de faire noter les réponses par une autre IA. L'étude de référence mesure qu'un juge comme GPT-4 est d'accord avec les évaluateurs humains dans plus de 80 % des cas, soit le niveau d'accord observé entre humains, mais documente aussi des biais de position (préférence pour la réponse présentée en premier), de verbosité (préférence pour les réponses longues), d'auto-préférence (pour les réponses d'un modèle proche) et un raisonnement limité (Zheng et al., « Judging LLM-as-a-Judge », NeurIPS 2023). Pour trente à cinquante questions, la notation humaine reste la norme : c'est rapide, et c'est ce qui engage la responsabilité de l'organisation. Un juge automatique ne se justifie que pour pré-trier de gros volumes, après vérification de son accord avec des notes humaines sur un échantillon.

Rejouer le jeu de test : changement de modèle, de sources ou de paramétrage

Un jeu de test qui n'est joué qu'une fois est un cahier des charges déguisé. Sa valeur vient du rejeu : les mêmes questions, à la même version du jeu, posées après chaque changement, pour détecter une régression. Et les régressions sont discrètes : un score global qui monte peut se composer de progrès sur les questions ponctuelles et de reculs sur l'information absente ou les droits d'accès. Il faut donc comparer famille par famille, et question par question pour celles qui ont changé de statut.

Le journal des résultats. Chaque passage est consigné : date, version du jeu, modèle ou moteur utilisé, version de l'outil, sources reliées, score par famille, liste des questions dont la note a baissé, décision prise. Ce journal sert trois fois : pour décider (continuer, corriger, changer), pour prouver (voir section suivante), et pour choisir le moment de franchir un palier dans un déploiement progressif de l'IA, où le rejeu du jeu de test est le critère de passage le plus objectif.

Ce point a une conséquence sur le choix de l'outil : un système où le moteur d'IA est interchangeable rend le changement de modèle possible, donc le rejeu nécessaire. C'est le cas de Brain, qui se connecte aux modèles choisis par le cabinet et dont la page sécurité indique que le moteur « se remplace sans rien perdre ni ressaisir » (Sécurité et souveraineté, Majors Brain). La mémoire reste ; c'est précisément pour cela que le jeu de test, lui aussi, doit rester, afin de vérifier qu'un nouveau moteur répond aussi bien que l'ancien sur les mêmes dossiers.

Tester sur des dossiers réels en environnement réglementé : confidentialité, traçabilité, preuve

Un jeu de test digne de ce nom utilise de vrais dossiers : c'est ce qui fait sa valeur, et ce qui impose des précautions. Pour un cabinet de conseil patrimonial, un cabinet d'avocats ou d'expertise comptable, trois sujets se posent.

• Confidentialité des dossiers de test. Tester, c'est traiter des données personnelles. On choisit une dizaine de dossiers, pas la base entière ; on préfère un test dans l'environnement du cabinet ou dans un environnement dédié de l'éditeur, couvert par un contrat qui interdit toute réutilisation pour l'entraînement et prévoit la suppression à la fin du test. Les clauses à vérifier sont celles de notre guide sur le contrat avec un fournisseur d'IA. On exclut du jeu les informations dont la diffusion est elle-même encadrée, par exemple l'existence d'une déclaration de soupçon (art. L. 561-18 du Code monétaire et financier).
• Pseudonymiser quand c'est possible, sans fausser le test. Remplacer les noms est utile pour les familles 1, 2, 6 et 7 ; cela l'est moins pour les homonymes (famille 4) ou les droits d'accès (famille 8), qui testent justement la gestion des identités. La solution est de limiter ces familles à des dossiers de collaborateurs volontaires ou à des dossiers fictifs construits pour l'occasion, clairement identifiés comme tels.
• Garder la trace. Le jeu, les réponses obtenues, les notes et le journal des rejeux constituent la preuve que l'outil a été choisi et suivi avec diligence. C'est ce qu'attend l'ESMA citée plus haut, et c'est ce qu'un contrôleur demandera le jour où une recommandation préparée avec l'outil sera discutée. Pour une profession réglementée, la question « pourquoi cet outil ? » doit avoir une réponse écrite.

Comment Brain traite ce point. Les tests prévus par la méthode Brain se font sur les dossiers réels du cabinet, après l'audit et dans l'environnement du cabinet. Les engagements publiés sont explicites : hébergement chez Scaleway à Paris, chiffrement AES-256 au repos comme en transit, données sensibles pseudonymisées dans les traitements d'IA (« les données sensibles ne sortent jamais en clair »), et « vos données n'entraînent aucun modèle public, jamais » (brain.majors.fr/securite). Chaque réponse affiche ses sources, ce qui rend le critère « Source » de la grille vérifiable en un clic, et les droits sont configurés pour que « chaque collaborateur n'accède qu'au périmètre qui le concerne », ce que la famille 8 du jeu de test permet justement de contrôler.

Méthode en sept étapes et cas d'un cabinet fictif

Méthode en sept étapes, applicable avant un achat comme avant un changement d'outil :

1. Définir les usages et les profils. Trois ou quatre usages réels (préparer un rendez-vous, retrouver une décision, vérifier un point réglementaire, rédiger un compte rendu) et les profils qui les exercent. Un outil n'est pas « bon », il est bon pour un usage donné.
2. Choisir dix à quinze dossiers de référence et vérifier leurs données avant le test : un test sur des dossiers faux mesure la qualité des données, pas l'outil. Y inclure volontairement un doublon, un homonyme et un document en plusieurs versions.
3. Écrire trente à cinquante questions couvrant les dix familles, avec réponse, source et comportement attendus, chacune validée par une seconde personne.
4. Figer et versionner le jeu (version 1, date), le ranger hors de portée des éditeurs, et désigner la personne qui en a la garde.
5. Faire passer chaque outil dans des conditions identiques : mêmes sources reliées, mêmes droits, mêmes profils. Copier les réponses dans un document anonyme, puis noter en aveugle avec la grille à quatre critères.
6. Décider dans l'ordre : d'abord les critères éliminatoires, puis la pire famille, puis le temps de vérification, enfin le coût et le contrat. Un outil excellent sur le prix et éliminé sur les droits d'accès reste éliminé.
7. Rejouer et consigner à chaque événement du tableau précédent, et réviser le jeu une fois par an, à date fixe, à partir des incidents de l'année.

Illustration (cabinet fictif). Prenons un cabinet fictif de quatre personnes, deux conseillers et deux assistantes, qui hésite entre deux outils : un assistant intégré à sa suite bureautique, qui lit la messagerie et les fichiers partagés, et une mémoire reliée au CRM, à la messagerie et à la GED, qui cite ses sources. Le cabinet choisit douze dossiers, dont deux clients homonymes et un contrat ayant connu un avenant, et écrit trente-six questions. Les deux outils réussissent les questions ponctuelles. Sur l'information absente, le premier outil répond à chaque fois, en déduisant un montant plausible d'un autre document ; le second indique qu'aucune source ne contient l'information. Sur les droits d'accès, une assistante obtient, avec le premier outil, le résumé d'un dossier auquel elle n'a pas accès dans le CRM, parce que l'outil lit les fichiers partagés sans tenir compte des droits du CRM : critère éliminatoire. Le second outil refuse, mais sa réponse laisse deviner que le dossier existe : note 1, à corriger par paramétrage avant la décision. Le cabinet retient le second outil, exige la correction, rejoue la famille 8 après correction, et consigne l'ensemble. Six mois plus tard, l'éditeur change de moteur ; le rejeu complet montre une baisse sur les versions de documents, signalée et corrigée avant que les utilisateurs ne s'en aperçoivent.

Cet exemple est une illustration, pas un cas client. Il montre pourquoi le jeu de test est l'outil de décision le plus économique pour une petite structure : il remplace la confiance par la vérification, et il fait du choix d'un outil d'IA une décision documentée, révisable et défendable. Pour les cabinets qui comparent des solutions du marché, notre comparatif des outils d'IA pour CGP peut servir de point de départ, à condition de finir par un jeu de test sur vos propres dossiers.