Construire un jeu de cas fictifs utile avant un essai d’IA

Écrire la règle avant de fabriquer les bons exemples

Je préfère un essai capable de contrarier notre intuition à une démonstration où tout a été arrangé pour fonctionner. Une réponse séduisante à une demande complète renseigne peu sur ce qui arrivera lorsqu’une date manque, que deux indications se contredisent ou que la tâche demandée sort du périmètre. Ces situations doivent être préparées avant de regarder les sorties.

Le NIST demande de documenter les jeux, les mesures et les moyens utilisés pour l’évaluation ; il relie aussi l’examen aux conditions d’usage et aux limites de généralisation. ^[1] Ce repère ne fournit ni taille minimale universelle ni liste magique de cas. La méthode proposée ici sert à construire un premier dossier lisible, que quelqu’un d’autre pourra discuter.

Commencez par une phrase : l’outil doit produire tel objet, pour tel destinataire, à partir de telles pièces, avec telles actions interdites. Si vous hésitez encore sur la règle, notez ce désaccord. Fabriquer des réponses attendues ne doit pas cacher une décision métier qui n’a pas été prise.

Choisir des variations qui modifient le travail à faire

Partez des éléments nécessaires à la tâche. Pour une orientation de demandes, demandez-vous ce qui arrive lorsque ces éléments sont présents, absents, ambigus ou contradictoires. Ajoutez une demande voisine qui ne doit pas être traitée. Une variation de formulation peut ensuite vérifier si la même règle reste applicable avec d’autres mots.

Une liste de vingt messages complets peut couvrir moins de difficultés que quelques cas bien choisis. À l’inverse, un jeu composé uniquement de pièges ne décrit pas les tâches ordinaires. Décrivez les familles présentes et les familles absentes, sans leur attribuer une fréquence que vous n’avez pas observée.

Exemple fictif : orienter une demande sans confirmer une inscription

Tout ce qui suit est inventé. La tâche consiste à attribuer un statut à une demande d’inscription à un atelier : « Prêt à examiner », « À préciser » ou « Hors périmètre ». Elle n’autorise aucune inscription effective et aucun envoi. Les règles font partie de l’exercice ; elles ne décrivent pas une procédure de DEMETER SANTÉ.

Pour être prêt à examiner, le message doit demander une inscription et fournir un code dossier, une date au format jour/mois/année et un seul mode, « sur place » ou « à distance ». Si une inscription est demandée mais qu’un élément manque ou se contredit, le statut est « À préciser ». Si aucune inscription n’est demandée, le statut est « Hors périmètre », même si le mot atelier apparaît. Une demande mêlant inscription et autre opération doit être clarifiée avant traitement.

Le cas M03 montre pourquoi une convention doit être écrite : un lecteur peut interpréter « finalement » comme un choix clair. Pour cet exercice, aucune priorité de ce type n’est autorisée. Si votre équipe souhaite l’autoriser, modifiez d’abord la règle et la version du corrigé. Il ne faut pas présenter un désaccord sur la consigne comme une erreur certaine de l’outil.

Conserver une réserve avant de corriger la consigne

Les cas M servent à comprendre et améliorer la consigne. Préparez d’autres cas avant de commencer cette mise au point, puis confiez leur conservation à une personne désignée. Leur examen vient après le gel de la version candidate. Cette séparation est une proposition pratique pour limiter l’ajustement au seul dossier déjà connu ; elle ne transforme pas un petit essai en validation scientifique.

Les huit cas de cet article sont publics, réponses comprises : leur réserve est illustrative. Une équipe qui les a lus ne peut pas prétendre les découvrir ensuite à l’aveugle. Pour son propre examen, elle devra construire des cas distincts, autorisés et non utilisés pendant les modifications.

Si un cas réservé conduit à modifier le prompt, conservez le résultat initial. Le nouveau passage renseigne sur la correction de ce défaut, mais ce cas a désormais servi à la mise au point. Préparez une nouvelle réserve plutôt que d’effacer la première tentative. Le plan de retest aide à conserver ces différences de version.

Inventer des données ne consiste pas à maquiller un dossier réel

Rédigez les pièces de toutes pièces, avec des organismes, situations et codes fictifs. Évitez de reprendre une histoire rare, un texte interne ou des identifiants réels en remplaçant seulement le nom. L’information peut rester reconnaissable par son contexte.

La CNIL distingue la pseudonymisation de l’anonymisation : remplacer des identifiants ne rend pas nécessairement les personnes impossibles à retrouver ; les données pseudonymisées restent personnelles. ^[2] Notre exemple ne met en œuvre aucune anonymisation. Pour utiliser des dossiers réels, il faut un cadre d’accès et de traitement adapté, qui dépasse cet exercice.

Décrivez aussi ce que le jeu ne simule pas : bruit documentaire, langues utilisées, pièces jointes, longueurs, variations d’outil et situations réelles complexes. Un cas construit à la main teste une hypothèse de comportement ; il ne mesure pas à lui seul la fréquence des erreurs dans votre activité.

Préparer la preuve à conserver lors du véritable essai

Pour chaque cas, gardez l’entrée exacte, la règle applicable, le résultat attendu et sa justification. Lorsqu’un essai sera réellement exécuté, ajoutez la date, l’outil et sa version accessible, la consigne complète, la sortie brute, l’avis du lecteur et la suite. Ne remplissez pas aujourd’hui une colonne « résultat observé » avec ce que vous espérez obtenir demain.

La lecture comparative à l’aveugle peut aider à examiner deux sorties sans commencer par leur étiquette. Mais le corrigé doit pouvoir être discuté : une attente erronée produit une mauvaise évaluation, même avec des lecteurs appliqués.

Présentez les résultats cas par cas avant toute synthèse. Si sept cas sur huit passent lors d’un futur essai, cela voudra seulement dire que sept de ces huit cas satisfont les critères retenus dans les conditions conservées. Il faudra décrire le huitième, son importance et les situations absentes ; aucun taux observé ici n’est annoncé.

Questions fréquentes

Combien de cas faut-il créer ? Assez pour examiner les variations décisives de la tâche visée, puis davantage si les conséquences et la diversité des situations l’exigent. Cet article ne fixe pas de nombre validant un déploiement.

Peut-on demander à une IA d’inventer les cas ? Elle peut proposer un brouillon dans un cadre autorisé. Faites vérifier les règles, les attentes et les cas manquants par une personne capable de juger la tâche. La présence d’un corrigé généré ne suffit pas à établir sa justesse.

Et si tous les cas réussissent ? Documentez ce succès limité, les conditions et les familles absentes. Examinez ensuite les situations autorisées proches du travail réel, les contrôles humains et les conditions de repli avant une décision d’usage.

Vous souhaitez préparer un essai sans vous laisser guider par une démonstration réussie ? Vous pouvez me décrire la tâche et les erreurs qui changeraient votre décision, sans transmettre de dossier confidentiel.