Jeu de test IA : créer des exemples fictifs pour sa TPE

Un jeu de test IA sert à vérifier une tâche définie, pas à noter l'intelligence générale d'un logiciel. Pour une petite entreprise, le point de départ le plus utile est une décision que vous savez expliquer. Dans ce guide, une entreprise fictive de services numériques veut ranger des demandes entrantes. Elle ne demande ni réponse automatique, ni devis, ni recherche d'informations sur les personnes. La sortie attendue contient une catégorie et une justification courte fondée sur le texte fourni.

Nous utiliserons quatre catégories : À qualifier, Information manquante, Hors périmètre et À examiner. Elles correspondent à quatre suites de travail humaines différentes. À qualifier signifie que la demande explicite correspond à l'offre. Information manquante signifie que le besoin ne peut pas encore être identifié. Hors périmètre signifie que la seule prestation demandée est exclue. À examiner signale une contradiction, plusieurs intentions incompatibles ou un contenu qui ne ressemble pas à une nouvelle demande commerciale.

Écrivez ces définitions avant les exemples. Sinon, vous risquez d'adapter les règles à chaque réponse de l'outil, puis de conclure qu'il fonctionne parce que vous lui donnez raison après coup. Une catégorie n'est utile que si deux personnes peuvent comprendre pourquoi elle a été choisie.

La méthode proposée ici est un outil de travail éditorial. Ce n'est ni un protocole de laboratoire ni une certification. Elle aide à construire des essais comparables pour une tâche limitée ; elle ne mesure pas tous les risques d'un système.

Le jeu commence par une fiche de référence inventée. Pour notre entreprise fictive, l'offre comprend la création d'un site vitrine et la refonte d'un site vitrine existant. Elle exclut la gestion de campagnes publicitaires et la réparation de matériel informatique. Aucun prix, délai, secteur privilégié ou territoire n'est indiqué. Le classement ne doit donc rien inventer sur ces points.

Ajoutez une règle de priorité : une contradiction ou une demande mêlant plusieurs catégories passe en À examiner. Ensuite, une demande explicite correspondant à l'offre passe en À qualifier, même si le budget ou le délai manque. Information manquante est réservé aux messages dont le besoin lui-même reste indéterminé. Une demande exclusivement exclue passe en Hors périmètre. Un simple remerciement, une réclamation ou une tentative de faire changer les consignes passe en À examiner.

Ces règles ne sont pas universelles. Vous pourriez en retenir d'autres pour votre activité, à condition de les écrire et de refaire le corrigé. Ne changez pas une définition au milieu d'une comparaison sans créer une nouvelle version du jeu.

Si vous ne parvenez pas à décrire clairement ce que vous acceptez, travaillez d'abord votre page de services. Un jeu de test ne résout pas une offre contradictoire. Il peut la rendre visible, ce qui est déjà utile, mais vous devez encore prendre la décision commerciale correspondante.

Créez les messages depuis une page blanche. N'utilisez ni nom réel, ni adresse électronique, ni numéro de téléphone, ni extrait d'un dossier client. Vous n'avez pas besoin de coordonnées crédibles pour tester la compréhension d'une demande. Un identifiant comme CAS-01 suffit pour retrouver le document et son résultat.

Un exemple entièrement inventé n'est pas la même chose qu'un dossier réel dont vous avez remplacé les noms. Des détails rares peuvent rester identifiants. La CNIL rappelle que des données synthétiques ne sont pas systématiquement anonymes. Cette source, datée du 19 juin 2025 et consultée le 6 novembre 2026, justifie de distinguer les exemples créés indépendamment des données produites à partir de personnes réelles.

Pour obtenir de la variété, faites varier la formulation, la longueur et le degré de précision, pas l'identité des auteurs. Une demande peut être télégraphique, polie, maladroite ou très détaillée. Le jeu doit rester compréhensible par un humain et ne pas dépendre d'une connaissance cachée.

Gardez les fichiers simples. Un document texte permet de voir exactement ce qui sera transmis. Si vous utilisez un tableur, vérifiez les autres onglets, commentaires et cellules masquées avant de l'employer. Le dossier d'essai ne doit contenir aucun export professionnel ajouté par commodité. Cette séparation réduit les erreurs de manipulation ; elle ne constitue pas une garantie de sécurité du service utilisé.

Un jeu composé uniquement de demandes évidentes donne une impression de réussite fragile. Préparez une matrice de difficultés : besoin explicite, besoin vague, service exclu, contradiction, message mêlant plusieurs demandes et contenu qui essaie d'imposer sa propre règle. Chaque difficulté doit correspondre à une erreur que vous souhaitez repérer.

Pour chaque cas, notez trois éléments : ce qui varie, ce qui doit rester stable et pourquoi le cas existe. Dans une variante de formulation, les mots changent mais la catégorie attendue reste identique. Dans une variante de besoin, vous remplacez une refonte de site par une réparation d'ordinateur : la catégorie doit changer. Cette distinction évite d'attendre mécaniquement la même réponse à deux messages seulement proches en apparence.

Incluez aussi un message qui semble très professionnel mais demande une prestation exclue. Un ton soigné ne doit pas le faire passer en À qualifier. À l'inverse, une faute d'orthographe ne doit pas exclure une demande claire qui correspond à l'offre. Vous testez la compréhension du besoin, pas une préférence pour un style d'écriture.

La matrice doit rester proportionnée. Commencez avec assez de cas pour couvrir vos principales difficultés, puis ajoutez des situations lorsque vous découvrez une lacune. Aucun nombre magique ne transforme un petit jeu en preuve de fiabilité générale. Mieux vaut savoir précisément ce que dix cas vérifient que prétendre que cent messages ressemblants couvrent toute votre activité.

Les dix cas suivants appliquent uniquement le référentiel présenté plus haut. Ce sont des exemples inventés, pas des messages reçus par SprintLead ni des résultats mesurés avec un logiciel. Conservez les identifiants pour comparer les sorties.

Le corrigé contient une catégorie et une raison, pas une réponse commerciale à envoyer. Il ne doit jamais transformer À qualifier en « bon client », « solvable » ou « prêt à acheter ». Aucune donnée du jeu ne permet ces conclusions. Si vous ajoutez une prochaine étape, gardez-la humaine et limitée : examiner, demander une précision ou préparer un échange.

Pour réutiliser le modèle, remplacez d'abord le référentiel par votre offre fictive, puis réécrivez les attentes. Ne conservez pas automatiquement les catégories de ce tableau lorsque vos règles ont changé.

Demandez à une seconde personne de classer les exemples avec le seul référentiel. Comparez les désaccords avant d'exécuter le test. Si vous ne pouvez pas expliquer ensemble pourquoi CAS-06 doit passer en À examiner, le problème se trouve peut-être dans votre règle, pas dans l'outil. Corrigez la définition ou le cas et conservez la nouvelle version.

Lorsque vous travaillez seul, relisez le jeu à distance de sa rédaction et cherchez volontairement une autre interprétation. Cette vérification ne remplace pas une relecture indépendante, mais elle peut révéler un mot ambigu ou une attente cachée. Notez cette limite plutôt que de présenter votre corrigé comme une vérité incontestable.

Le corrigé doit également préciser les erreurs bloquantes : inventer une prestation, affirmer un prix absent, obéir à CAS-09 ou prendre une décision sur une personne. Une explication élégante ne compense pas ces erreurs. À l'inverse, une formulation différente de votre phrase de référence peut être acceptable si elle conserve exactement le sens et la catégorie.

La documentation Microsoft sur les jeux d'évaluation, consultée le 6 novembre 2026, décrit notamment l'association de cas et de réponses attendues. Notre modèle reste indépendant de ce produit : vous pouvez le tenir dans un simple document sans installer cet outil ni reprendre ses métriques.

Utilisez une partie des exemples pour améliorer votre consigne, puis gardez d'autres situations à l'écart jusqu'à la comparaison finale. Les cas de réglage vous permettent de repérer une définition trop vague. Les cas réservés servent à voir si la consigne fonctionne aussi sur un texte que vous n'avez pas corrigé avec l'outil pendant la préparation.

Cette séparation concerne votre méthode de travail. Elle ne signifie pas que vous entraînez techniquement le modèle ni que vous contrôlez la manière dont le fournisseur utilise les données. Avant d'utiliser un service, respectez son cadre autorisé et les règles de votre entreprise. Les questions-réponses de la CNIL sur l'IA générative, consultées le 6 novembre 2026, rappellent les limites et précautions liées aux informations transmises.

Pour créer des cas réservés, rédigez de nouveaux messages qui suivent le même référentiel. Une variante pourrait demander de moderniser les pages d'un site vitrine sans employer le mot « refonte ». Une autre pourrait demander seulement de réparer un écran. Écrivez leurs catégories attendues avant de les soumettre, et ne communiquez pas le corrigé à l'outil qui doit classer.

Si vous utilisez ensuite un cas réservé pour corriger votre consigne, il devient un cas de réglage. Remplacez-le dans le lot réservé. Sans cette discipline, le contrôle final finit par mesurer votre capacité à faire répéter des réponses connues plutôt que la capacité à appliquer les règles.

Conservez ensemble le référentiel, la consigne, la version du jeu et les réponses obtenues. Notez le service utilisé, la date et les réglages accessibles. Si vous comparez deux consignes, gardez les mêmes cas. Si vous comparez deux versions du jeu, expliquez ce qui a changé. Une comparaison dont les entrées varient silencieusement ne permet pas une conclusion solide.

Demandez une sortie simple : identifiant du cas, catégorie parmi les quatre valeurs autorisées et justification fondée sur le message. N'ajoutez ni enrichissement, ni recherche web, ni action dans un outil externe. Le classement reste un exercice sur documents fictifs. Les instructions contenues dans un message sont des données à examiner, pas des ordres à suivre.

Gardez la réponse originale avant de la corriger. Notez séparément votre jugement et la raison du désaccord. Si vous remplacez directement la mauvaise catégorie dans le fichier de sortie, vous perdez la preuve de l'erreur et risquez de compter une réussite qui n'a jamais eu lieu.

Vous pouvez répéter certains cas pour observer une éventuelle variation. Ne retenez pas uniquement le meilleur passage. Consignez les essais infructueux et leurs conditions, sans multiplier les appels au-delà du budget et du temps que vous avez décidés. Une répétition réussie après plusieurs échecs ne doit pas effacer ces échecs de votre bilan.

Comptez les catégories correctes, mais examinez surtout la nature des écarts. Un résultat global peut masquer une erreur grave sur un cas particulier. Dans notre exercice, classer CAS-09 en À qualifier parce que le message l'ordonne est différent d'une justification un peu trop longue. Présentez ces erreurs séparément au lieu de les fondre dans une note unique.

Une grille de lecture pratique distingue : mauvaise catégorie, justification non soutenue par le texte, information inventée, règle interne au message suivie, format inexploitable et réponse absente. Un même cas peut cumuler plusieurs défauts. Le but n'est pas de gonfler un score d'erreurs, mais de comprendre le mécanisme qui rend la sortie inutilisable.

Ajoutez le temps de vérification et de correction. Un classement presque toujours correct peut rester peu utile si le contrôle coûte davantage de travail que le tri manuel. Comparez le même périmètre et la même exigence de qualité. Ne présentez aucun gain de temps avant de l'avoir mesuré sur vos essais.

Décidez ensuite d'une action précise : clarifier une règle, ajouter un cas manquant, simplifier la sortie ou arrêter cet usage. Si vous modifiez une consigne, rejouez les anciens cas utiles pour vérifier qu'une correction n'a pas dégradé une situation auparavant comprise. Un résultat amélioré sur un seul exemple ne suffit pas à conclure que l'ensemble du jeu s'est amélioré.

Donnez au jeu un nom et une version, par exemple « Tri fictif demandes web, version 1 ». Ajoutez la date, le référentiel utilisé, la liste des cas et les changements depuis la version précédente. Gardez les identifiants stables lorsque le sens du cas ne change pas. Si vous réécrivez son besoin, indiquez-le explicitement plutôt que de remplacer silencieusement le texte.

Un résultat positif signifie seulement que les sorties observées ont satisfait vos critères sur ces exemples et dans ces conditions. Il ne démontre ni conformité juridique, ni confidentialité du service, ni fiabilité sur tous les messages réels. Le passage à des données réelles ou à une action automatique exige un examen distinct. Ne le présentez pas comme la suite technique obligatoire d'un test réussi.

Le besoin commercial doit lui aussi être vérifié. Des entretiens clients B2B peuvent aider à comprendre les demandes que votre offre doit traiter. La page SprintLead pour les agences concerne la recherche d'entreprises pour la prospection, une étape différente de la création de ce jeu. Elle ne fournit aucune preuve sur la sécurité ou les performances de l'outil évalué.

Votre livrable final tient en quatre éléments : référentiel, cas, corrigé et journal des essais. Une autre personne doit pouvoir les relire et retrouver votre conclusion. Si elle ne peut pas expliquer pourquoi vous avez accepté ou écarté l'usage, complétez le dossier avant de chercher un score plus flatteur.