Tester une IA quand vous n'avez pas le droit de voir les données.

L'évaluation d'une IA ne change pas quand les données sont fermées

La mesure se fait toujours de la même façon. Vous constituez un jeu d'évaluation, aussi appelé jeu de test, vous le passez à la fonctionnalité, puis vous comparez sa réponse à ce qu'elle aurait dû répondre. Ce jeu se compose de 3 choses.

• Les entrées : les documents, les messages ou les fiches que la fonctionnalité recevra une fois en service.
• Le résultat attendu : ce que la fonctionnalité aurait dû répondre sur chacune de ces entrées, écrit à l'avance.
• La règle de comparaison : ce qui décide, ligne par ligne, si la réponse obtenue vaut le résultat attendu.

L'interdiction d'ouvrir les données ne touche qu'un seul de ces 3 points : vous ne pouvez pas prélever les entrées dans la production, autrement dit dans le service qui tourne pour de vrai. Tout le reste tient debout.

La règle qui vous ferme cet accès est posée dans le décryptage sur les modèles branchés sur des données de santé. Les vraies données ne sortent jamais de la production. La CNIL et la Haute Autorité de Santé recommandent la même chose dans un guide qu'elles préparent, et la même règle s'applique, à peine assouplie, dans une banque comme dans un service du personnel.

3 attitudes existent face à un prompt qu'on vient d'écrire :

• Le lancer une fois, trouver la réponse bonne, et livrer
• Le lancer 2 ou 3 fois, rattraper à la main le cas qui coince, puis livrer
• Le passer dans une chaîne d'évaluation qui le note sur des dizaines de cas d'un coup

Les 2 premières sont ce que fait tout le monde, jusqu'au jour où un utilisateur envoie ce que personne n'avait prévu. Avec la troisième, chaque retouche de consigne devient une mesure au lieu d'un pari.

Écrire d'abord ce que la fonctionnalité produit, et pour qui

Nommez celui qui lira la sortie avant d'écrire le premier critère. Un chatbot de support client, un outil qui résume des transcriptions et un assistant pour vos techniciens ne produisent pas le même texte. Ils ne se trompent pas non plus de la même façon.

Le vocabulaire attendu change avec le lecteur. Votre technicien veut le terme exact et la référence de la pièce. Le patient qui reçoit la même phrase en jargon n'en tire rien, et il appellera votre standard. Écrivez-le avant de commencer : ce que la fonctionnalité produit, qui le lit, et dans quel registre de langue. Vos critères en découlent.

Obtenir un échantillon de données réelles, même sous contrainte

Ne pas avoir le droit d'ouvrir la production ne veut pas dire renoncer à voir la donnée. Rien ne vaut un échantillon réel pour savoir à quoi ressemblent vos dossiers, avec leurs tournures et leurs défauts. Demandez-le avant de fabriquer quoi que ce soit.

Sur des données de santé ou critiques, cette demande ne passe pas du premier coup. Elle passe quand vous arrivez avec un dispositif encadré plutôt qu'avec une demande d'accès. 4 mécanismes le composent :

• L'extraction est faite par quelqu'un qui a déjà le droit d'ouvrir les dossiers : le métier, un administrateur, celui qui porte le RGPD chez vous. Jamais par l'équipe qui développe.
• Le volume demandé reste ridiculement petit. Quelques dizaines de cas suffisent : vous ne demandez pas un jeu d'entraînement, vous demandez de quoi observer. Ce repère de méthode désamorce la moitié des refus.
• Les identifiants directs sont remplacés avant transmission, les noms, les numéros de dossier et les adresses. Le reste arrive tel quel, parce que c'est la forme qui vous intéresse, pas l'identité de la personne.
• Quand même ça ne passe pas, la consultation se fait sur place, dans un environnement d'où rien ne sort. Votre code va à la donnée au lieu que la donnée vienne à lui.

Écrivez ce cadre sur une page et faites-le valider : qui accède, à quoi, pendant combien de temps, ce qui est détruit à la fin et par qui. Ce document transforme un refus en accord, par le même mécanisme que devant une DSI qui bloque un outil métier. Sans lui, votre interlocuteur porte seul le risque et il dira non.

La règle qui ferme la production à votre équipe tient toujours : un échantillon réduit au minimum et détruit à la date prévue n'est pas un export posé sur un poste.

Demandez en complément les abréviations que personne n'a documentées et la part que chaque type de cas pèse dans la journée de vos gestionnaires. Une liste de tournures dit ce que les gens croient écrire, l'échantillon montre ce qu'ils écrivent.

Faire générer le jeu de test par l'IA, faute de données réelles

Vous demandez au modèle de fabriquer le corpus, c'est-à-dire l'ensemble des documents de test : 200 comptes rendus d'entretien annuel inventés, 150 réclamations clients plausibles, 80 relevés d'opérations crédibles. Aucune de ces lignes ne concerne une personne réelle, donc aucune ne pose de problème d'accès, et vous tenez le jeu en une journée au lieu de plusieurs semaines. 5 étapes :

1. 1

   Décrivez au modèle le document que vous voulez : sa longueur, son ton, ses champs, les tournures relevées dans l'échantillon. Un corpus généré sur une consigne approximative se jette en entier.

2. 2

   Demandez 20 documents par type de cas, jamais 200 d'un coup. Relisez-en 5, corrigez la consigne, puis lancez le volume.

3. 3

   Faites produire l'entrée et le résultat attendu dans le même mouvement, ligne par ligne. Un résultat attendu faux empoisonne toute la mesure qui suit.

4. 4

   Confiez ce travail à un petit modèle rapide, et gardez le plus puissant pour la fonctionnalité qui tournera en service.

5. 5

   Faites relire un échantillon du corpus par le métier : lui seul sait si vos faux dossiers ressemblent aux vrais.

Vous réglez au passage un risque que personne ne voit venir. Sans jeu de test fourni, un développeur pressé colle un vrai extrait dans un outil grand public, depuis son compte personnel. Le mécanisme est détaillé dans le décryptage sur l'usage sauvage de l'IA en entreprise.

Le piège circulaire quand la même IA génère le jeu de test et le note

Si un modèle génère le corpus, produit les réponses, puis note le résultat, vous ne mesurez plus la qualité de votre fonctionnalité. Vous mesurez la cohérence d'un modèle avec lui-même. Les scores sortent excellents, la mise en service échoue, et personne ne comprend pourquoi.

La cause est toujours la même : un corpus généré est trop propre. Il est bien orthographié, bien structuré, poli, complet, écrit dans un français que personne n'emploie sous pression. Vos vraies données, elles, arrivent avec leurs défauts. C'est là que votre fonctionnalité cassera.

Reproduire les problèmes des données réelles

Dans la vraie vie, il y a toujours des problèmes de données. Puisque vous n'y avez pas accès, reproduisez-les. Reprenez votre corpus et introduisez-y ces défauts, à la main ou en le redemandant au modèle. Les 6 qui font le plus de dégâts en service :

• Les documents scannés de travers, trop lourds, dont une page sur 3 est illisible
• Les fichiers incomplets, où la moitié des champs attendus restent vides
• Les abréviations maison, celles que personne n'a jamais documentées
• Les fautes de frappe, les mots collés, les phrases coupées au milieu
• Les retranscriptions de dictée qui écorchent un mot sur dix
• Les paragraphes où 2 sujets sans rapport se mélangent

L'intérêt vient de la comparaison. Gardez les 2 versions du corpus, celle qui est parfaite et celle qui porte les défauts du réel. L'écart entre les 2 scores dit ce que votre fonctionnalité perd au contact du réel, et c'est souvent le seul chiffre intéressant de toute l'évaluation.

Les critères qui se vérifient par du code, sans passer par un modèle

Une sortie d'IA se note de 3 façons, et la plupart des équipes n'en emploient qu'une :

• Par du code : un programme regarde la sortie et répond oui ou non, toujours de la même manière
• Par un modèle : un second modèle lit la sortie et rend un verdict, comme le ferait un relecteur
• Par un humain : quelqu'un du métier ouvre la sortie et tranche

La deuxième façon porte un nom courant en réunion. Pour décider si une sortie est bonne, vous avez 2 possibilités. Soit des humains la notent selon des critères écrits, ce qui reste le plus fiable et ne passe pas à l'échelle. Soit vous confiez cette notation à une IA, les critères dans sa consigne : vous tenez ce qu'on appelle un « LLM as a judge », un modèle qui juge les sorties d'un autre modèle. Le terme circule en anglais, on dira ici le modèle qui juge.

Commencez par le code. Une bonne part de ce que vous vérifiez ne demande aucun jugement, et 4 contrôles se règlent par un programme de quelques lignes :

• La sortie se relit sans erreur au format que votre application attend
• Le champ obligatoire est bien là, et il est rempli
• Aucune mention interdite n'apparaît dans le texte produit
• La longueur reste dans les bornes que vous avez fixées

Un programme de ce genre ne coûte rien, il rend le même verdict à chaque passage, et il ne dépend d'aucun fournisseur. Le modèle qui juge, lui, vous facture chaque ligne évaluée et change d'avis d'un passage à l'autre.

Voilà l'argument qui change tout dans votre situation. Un programme de vérification ne lit pas la donnée, il en vérifie la forme. Vous pouvez donc le faire tourner sur la production, sur les vrais dossiers, sans que personne les ouvre et sans qu'une seule ligne parte chez un tiers. Un modèle qui juge, lui, doit lire le contenu pour se prononcer. Le brancher sur la production reviendrait à envoyer chez un fournisseur ce que vous n'avez pas le droit de faire sortir.

Vous tenez là la seule mesure que vous pouvez prendre sur vos données réelles sans les regarder. Elle ne dira pas si le résumé est juste. Elle dira combien de sorties, sur le service qui tourne pour de vrai, partent au mauvais format ou avec un champ vide. Ce chiffre-là porte sur votre production, pas sur un corpus fabriqué.

Note de 1 à 10 ou verdict fermé : 2 outils, 2 usages

Une note ne vaut que si elle porte sur un critère précis. Noter une recette 8 sur 10 ne vous apprend rien. Notez séparément la clarté des étapes, la qualité des produits et la cohérence de l'ensemble, et vous savez quoi corriger. La note générale, si vous en voulez une, se compose de ces notes-là.

Une fois vos critères posés, il reste à choisir comment le modèle qui juge se prononce sur chacun. Vous avez 2 façons de faire, et elles ne servent pas à la même chose.

La note graduée, pour voir si vous progressez

Le modèle attribue un chiffre à chaque critère, de 1 à 10, et vous suivez la moyenne au fil des versions. C'est la méthode qui s'installe presque partout, parce qu'elle se lit d'un coup d'œil et qu'elle donne un sens de marche.

L'erreur classique ressemble à ça. Vous lancez votre évaluation, vous obtenez 7,4 de moyenne. Vous retouchez le prompt, vous relancez, vous obtenez 7,6, et vous annoncez le progrès. Puis vous rejouez la même évaluation sans avoir rien changé, et le 7,6 devient 7,3. Ces 3 nombres illustrent le mécanisme, ils ne sortent d'aucune mesure réelle.

3 défauts expliquent ce comportement.

• Un modèle qui juge tasse ses notes vers 7 ou 8, et n'utilise jamais le bas de l'échelle
• Il se laisse influencer par l'ordre dans lequel vous lui présentez les exemples
• 2 passes sur exactement la même sortie ne rendent pas exactement la même note

Les 3 se cumulent, et le bruit du juge finit par dépasser l'écart que vous cherchez à mesurer. Vos 0,2 point gagnés entre 2 versions tombent dans sa marge d'erreur. Sur un seul cas, vous pilotez au bruit. Sur plusieurs centaines, la tendance redevient lisible : c'est là que cette note travaille bien.

Le verdict fermé, pour décider si vous livrez

Le modèle ne donne plus de chiffre, il répond à une question fermée, critère par critère : c'est conforme, ou ça ne l'est pas. Vous montez à 3 niveaux au maximum quand la nuance est indispensable.

Repassez la même sortie 2 fois, vous retrouvez le même verdict. Un cas précis se discute, se rejoue et se prouve. En échange, vous ne savez plus de combien une version est meilleure que la précédente : une sortie passe, ou elle ne passe pas.

Les 2 approches ne se remplacent donc pas. La note graduée sert à comparer 2 versions de votre consigne : sa valeur absolue ne veut rien dire, son mouvement sur un grand nombre de cas vous dit dans quel sens vous allez. Le verdict fermé sert à décider si vous livrez, parce qu'il est reproductible et qu'il supporte qu'on lui demande des comptes.

L'erreur consiste à confier à la note graduée une décision de mise en production. Une moyenne de 8,4 ne dit rien de la sortie qui a inventé un diagnostic. Gardez les 2 : la note pour suivre vos itérations, le verdict fermé sur les critères qui engagent, et surtout sur ceux qui bloquent.

Une règle vaut pour les 2, quelle que soit l'échelle : n'acceptez jamais une note ni un verdict sans son explication. Demandez au modèle qui juge d'écrire d'abord ce que la sortie réussit, ce qu'elle rate et sur quel passage il se fonde, et seulement ensuite de se prononcer. À qui on réclame un chiffre seul, un modèle répond par le milieu de l'échelle, sans avoir rien regardé.

Demander ce motif vous sert 2 fois. Il force le modèle à examiner la sortie au lieu de trancher au jugé. Et il vous rend la mesure vérifiable. Quand un résultat vous surprend, vous lisez le motif. Vous voyez alors si le juge s'est trompé, ou si c'est votre critère qui est mal écrit. Une note sans motif ne se discute pas et ne s'améliore pas.

Des critères découpés par type d'erreur, pas par qualité perçue

Des critères du genre « pertinence », « clarté », « ton » reviennent souvent. Ils se notent mal et ils ne décident de rien. Découpez plutôt par type d'erreur, parce que toutes les erreurs ne vous coûtent pas la même chose. Les 3 familles, de la plus chère à la moins chère :

Inventer une information absente du dossier

La sortie contient un montant, une date ou un fait que rien ne justifie dans l'entrée. Personne ne peut le repérer sans rouvrir le dossier, et personne ne saura jamais combien de fois ça s'est produit en service.

Oublier une information présente dans le dossier

La sortie est juste, mais incomplète. Le coût dépend de ce qui manque : une remarque secondaire ne pèse pas comme la clause qui change la décision.

Formuler de façon maladroite ou hors format

La sortie dit la bonne chose, mal. Ça se corrige avec le prompt en une demi-journée, et ça ne devrait jamais bloquer une mise en service.

Un critère bloquant sur l'invention vaut mieux que 3 critères de qualité notés 8 sur 10 : le premier vous donne une décision, les seconds une impression. Et c'est une décision qui se défend devant le métier qui signera la mise en service.

Le prompt du juge suit ensuite le même découpage. Il énonce chaque critère en une question fermée, il rend un verdict par critère, et il cite le passage de l'entrée qui le justifie. Sans cette citation, vous ne pouvez pas contrôler le juge, et vous ajoutez une boîte noire pour en surveiller une autre.

Le seuil se fixe avant de générer la première ligne du jeu de test

Sinon la scène se déroule toujours pareil. On lance l'évaluation, on trouve 4 % d'inventions, et on décide en réunion que 4 %, finalement, c'est acceptable. Le seuil a été fabriqué pour justifier le résultat, et tout le monde le sait dans la salle.

Asseyez-vous avec le métier avant de générer quoi que ce soit, et tracez ensemble la frontière entre l'acceptable et l'inacceptable. Sur une application de santé, un faux diagnostic n'est jamais acceptable, et aucune moyenne ne rachète cette ligne-là. Repartez avec 3 choses écrites. Ce qui est interdit quoi qu'il arrive, à commencer par les inventions. Ce que vous tolérez, et à quelle fréquence. Et ce qui déclenche un retour en arrière une fois le produit en service.

Vous gagnez 2 choses. Votre équipe sait quand elle a fini, ce qui évite 6 semaines d'amélioration sans fin. Et votre sponsor a signé la définition du succès avant de voir le résultat.

Un de ces critères ne se moyenne jamais. Zéro invention sur les cas critiques : une seule sortie qui invente un fait, et la fonctionnalité ne part pas. C'est cette ligne qui autorise la mise en service, pas le score global.

Mesurer le comportement face aux entrées inattendues

Votre jeu d'évaluation mesure ce que le système fait quand tout se passe bien. Il ne dit rien de ce qu'il fait quand on lui envoie n'importe quoi, et vos utilisateurs lui enverront n'importe quoi dès la première semaine. Distinguez 2 familles, qui n'ont pas du tout le même remède.

Le second cas se teste, et presque personne n'en parle. Fabriquez 20 documents piégés, glissez-les dans le jeu, et posez une question fermée : le système a-t-il suivi la consigne du document, ou a-t-il fait son travail ? Vous obtenez un chiffre que vous pouvez montrer à votre responsable sécurité, ce qui vaut mieux qu'une déclaration d'intention.

Les demandes hors sujet et les documents piégés font partie du jeu d'évaluation, pas d'un test à part qu'on ferait un jour. Ils se rejouent avec le reste, et ils se dégradent aussi vite.

Versionner le jeu d'évaluation pour pouvoir le rejouer

Votre fournisseur met à jour son modèle sans vous prévenir. Les réponses changent, parfois en moins bien sur le cas qui compte pour vous. Sans jeu rejouable, vous l'apprenez par un utilisateur, 3 semaines plus tard, sur le ton du reproche.

Rangez donc le jeu d'évaluation avec le code du produit, dans le même dépôt et avec un numéro de version. Rejouez-le à chaque changement de prompt ou de modèle, et à chaque montée de version du fournisseur. Conservez chaque résultat, daté, avec la version du modèle en face.

Donnez-lui la forme d'un fichier structuré, pas d'un tableur posé sur un poste. Chaque cas y porte l'entrée, le résultat attendu en face, et le format que la sortie doit respecter. Le programme de vérification a besoin de cette forme, et le jeu se rejoue d'une commande.

Vous obtenez alors la seule alerte qui fonctionne : un score qui décroche d'un passage au suivant vous prévient avant vos utilisateurs. Dans une ETI où l'outil doit passer devant la DSI, ce jeu rejoué et ses résultats archivés sont la pièce qu'on vous demandera, et que vous n'écrirez pas dans l'urgence.

Comment décider : la séquence, dans l'ordre

Voici les 8 étapes, dans cet ordre. L'ordre compte autant que les étapes elles-mêmes.

1. 1

   Écrire ce que la fonctionnalité doit produire, pour qui, et dans quel registre de langue. Un technicien et un patient ne lisent pas le même texte.

2. 2

   Tracer avec le métier la frontière entre ce qui est acceptable et ce qui ne l'est pas. Sur une application de santé, un faux diagnostic n'est jamais acceptable.

3. 3

   Obtenir un échantillon réel de quelques dizaines de cas, extrait par une personne déjà habilitée, sous un cadre écrit. Les formulations du métier viennent en complément.

4. 4

   Faire générer le jeu de test par l'IA, une entrée et un résultat attendu par ligne, puis y reproduire les problèmes de données du réel.

5. 5

   Faire relire le corpus fabriqué par le métier : lui seul sait si vos faux dossiers ressemblent aux vrais.

6. 6

   Poser les critères par type d'erreur, confier au code tout ce qui se vérifie sans jugement, et faire évaluer le reste par un modèle qui cite le passage.

7. 7

   Ajouter au jeu les demandes hors sujet et les documents piégés, puis mesurer ce que le système fait de chacun.

8. 8

   Versionner le jeu avec le code du produit, le rejouer à chaque changement de prompt ou de modèle, et archiver chaque résultat daté.

Vous tiendrez cette séquence en 2 semaines sur une fonctionnalité simple. Elle ne vous rendra pas l'accès aux données, elle vous donne ce que votre sponsor attend : un chiffre, une méthode pour le reproduire, et une frontière signée avant d'être franchie.

Questions fréquentes

Sources officielles

Cadre consulté pour cette version du 19 août 2026. Le niveau d'exigence applicable à un cas particulier dépend de son usage, de ses données et de son contrat.

• HAS et CNIL, projet de guide « Accompagner le bon usage des systèmes d'intelligence artificielle en contexte de soins », document de travail soumis à consultation publique ↗
• Règlement (UE) 2024/1689 établissant des règles harmonisées sur l'IA ↗
• CNIL, recommandation relative aux mesures de journalisation, délibération n° 2021-122 du 14 octobre 2021 ↗