Construire un premier jeu de tests IA en une journée

Un jeu de tests pour un système d’IA générative est un ensemble versionné de scénarios, chacun associé à une réponse attendue, une source et un critère d’acceptation, que l’équipe peut relancer à chaque modification. Il fournit une référence partagée pour comparer les changements.

Une journée peut suffire pour constituer un premier lot de tests sur une tâche bien délimitée. Elle ne suffit pas à démontrer la fiabilité générale d’un système. L’objectif est plus précis : disposer d’un point de départ partagé entre le métier et l’équipe technique.

Je propose de commencer avec quelques dizaines de scénarios représentatifs, sans faire de ce nombre un seuil de validation. Le volume nécessaire dépend de la diversité des tâches, des risques et de la variabilité des réponses. Un premier lot sert à découvrir des défauts et à préparer les mesures suivantes.

Construit avant que le système ne fonctionne, ce lot définit ce que « bon » veut dire ; c’est l’une des parades aux écarts qui font échouer les premiers essais.

La journée de constitution d’un premier jeu de tests s’organise en six étapes, de la délimitation de la tâche au premier rapport, chacune produisant un élément réutilisable. L’ordre permet d’éviter de collecter des questions avant de savoir ce qu’on évalue.

1. Délimiter la tâche et ce que le système ne doit pas faire.
2. Préparer le format : quatre colonnes de base, plus le contexte nécessaire.
3. Collecter des cas réalistes et construits, répartis par familles de risques.
4. Séparer les cas de développement et les cas de vérification.
5. Relire un sous-ensemble à deux avant d’automatiser quoi que ce soit.
6. Livrer un fichier versionné, une grille et un premier rapport avec ses limites.

Les sections suivantes détaillent chaque étape.

Délimiter la tâche d’un jeu de tests consiste à choisir un résultat que le métier sait évaluer et à écrire explicitement ce que le système ne doit pas faire. Sans ce cadrage, les scénarios mesurent des choses différentes et les résultats ne se comparent pas.

Par exemple, définissez une recherche de procédure avec citation vérifiable, en excluant toute invention de référence, consultation interdite ou action extérieure au périmètre.

Précisez les utilisateurs, les sources et les réglages. Si ces éléments changent pendant la comparaison, vous ne saurez plus attribuer les différences observées. Conservez une version du corpus de test et notez les paramètres disponibles. Certaines dépendances du fournisseur peuvent rester hors de votre contrôle ; indiquez-le, car un modèle peut changer sans prévenir.

Le cadre d’évaluation continue permet ensuite d’intégrer ce lot au cycle de modification du système. La première journée produit un point de départ exploitable, pas une preuve définitive ni une garantie de délai pour les décisions futures.

Un jeu de tests lisible repose sur quatre colonnes de base, question, réponse attendue, source et critère d’acceptation, complétées selon l’usage par le profil, les outils et la gravité d’un échec. Elles permettent au métier de relire un scénario sans parcourir un journal technique.

Ces lignes sont fictives et servent de modèle. La réponse attendue ne doit pas forcément être une phrase exacte. Elle peut décrire les informations indispensables, les réserves à conserver et les comportements interdits. Pour une tâche ouverte, une grille de jugement explicite est plus utile qu’une comparaison caractère par caractère.

La source attendue aide à distinguer un défaut de recherche d’un défaut de restitution. Le critère d’acceptation précise ce qui permet de conclure sur le scénario. Un taux global pourra ensuite résumer une famille de cas, mais il ne doit pas masquer une violation critique.

Les cas de test réalistes viennent des questions d’utilisateurs, des tickets et des incidents, complétés par des scénarios construits par l’équipe pour isoler les frontières difficiles à rencontrer. Aucun des deux groupes ne remplace complètement l’autre.

Les questions d’utilisateurs, les tickets et les incidents peuvent fournir des formulations réalistes. Leur réutilisation doit respecter la confidentialité : retirez les informations inutiles et préférez des données fictives lorsque le contenu réel n’apporte rien au test, selon les mêmes règles que pour ce qu’on a le droit de mettre dans un prompt.

Les scénarios rédigés par l’équipe technique restent utiles. Ils peuvent isoler une frontière d’accès ou une condition difficile à rencontrer dans les traces disponibles. Il faut simplement distinguer ces cas construits des exemples observés.

Répartissez les scénarios entre demandes courantes, ambiguïtés, informations absentes, contradictions et comportements interdits. Il n’existe pas de proportion universelle imposant un tiers de cas limites. La répartition doit correspondre à vos risques et rester visible dans le rapport.

Réserver une partie des cas à la vérification évite d’optimiser le système pour le lot de tests lui-même, ce qui donnerait des scores flatteurs sans valeur de prédiction. Si vous modifiez sans cesse le prompt en regardant tous les résultats, vous risquez exactement cela.

Gardez des cas à part pour vérifier les changements. Ils doivent couvrir les mêmes familles de tâches sans être simplement des copies des exemples utilisés pour régler le système.

Pour une première journée, cette séparation peut rester simple. Identifiez les cas de développement et ceux de vérification dans le fichier. Ne mélangez pas les scores sans préciser leur origine. À mesure que le dispositif grandit, formalisez davantage la gestion des versions et des jeux réservés.

Les tests de droits d’accès dans un RAG méritent une série dédiée. Une bonne moyenne de qualité rédactionnelle ne compense pas une divulgation. De même, les injections indirectes demandent des critères portant sur les actions et les autorisations, pas seulement sur le texte produit.

Oui, une revue humaine sur un sous-ensemble doit précéder toute automatisation du jugement, parce qu’elle révèle les critères ambigus avant qu’ils ne produisent des scores trompeurs. Vérifiez que deux personnes comprennent les critères de la même manière.

Les désaccords entre relecteurs révèlent souvent une attente ambiguë ou une source insuffisante. Corrigez la grille avant de traiter le score comme une mesure stable.

Automatisez ensuite ce qui se vérifie correctement : format, présence d’une référence autorisée, résultat d’un calcul déterministe ou appel d’outil interdit. La présence d’une citation ne prouve pas qu’elle soutient la réponse. Un contrôle de syntaxe ne remplace donc pas une vérification de fond.

Un modèle juge peut aider à trier ou à comparer des réponses. Il doit lui aussi être évalué sur des exemples relus. Conservez ses erreurs et les cas où il diverge du jugement humain. Le temps de relecture dépend du domaine ; promettre dix secondes pour toute réponse serait trompeur.

La variabilité et les régressions se mesurent en relançant plusieurs fois les cas sensibles, en conservant chaque défaut corrigé dans le jeu et en vérifiant que les tâches légitimes restent réalisables. Une réussite unique ne suffit pas à caractériser un comportement intermittent.

Présentez le nombre d’exécutions, les versions et les conditions. Les répétitions augmentent le coût de test, mais elles peuvent révéler des défauts absents du premier passage.

Comparez aussi l’utilité. Un changement qui bloque toutes les demandes peut améliorer artificiellement certains indicateurs de sécurité. Conservez donc les tâches légitimes dans la recette et vérifiez qu’elles restent réalisables. La décision doit examiner les deux dimensions.

Une régression corrigée doit rester dans le jeu, avec un scénario reproductible. Cela réduit le risque de la réintroduire ; cela ne le rend pas impossible. Les modèles, les outils et les sources peuvent évoluer. Le suivi doit tenir compte de ces dépendances plutôt que de promettre une stabilité indéfinie.

Le livrable de fin de journée réunit un fichier de scénarios versionné, une grille de jugement comprise par le métier et un premier rapport de résultats qui expose aussi ses limites. Les limites du lot sont des indications pour la suite, pas des détails à cacher.

Ajoutez les familles non couvertes, les cas trop peu nombreux ou les informations encore manquantes.

Attribuez un responsable au maintien du jeu. Les incidents doivent être examinés, anonymisés si nécessaire, puis transformés en scénarios pertinents. Évitez d’ajouter mécaniquement chaque message brut. Un jeu utile conserve des cas distincts et des critères explicites.

Enfin, choisissez les prochaines actions : corriger un défaut, compléter une famille ou élargir le test. Un audit IA peut aider à relier ces résultats à l’architecture et aux décisions de déploiement. Le premier lot rend cette discussion plus précise ; il ne tranche pas tous les risques à lui seul.

Les erreurs fréquentes en construisant un premier jeu de tests consistent à ne retenir que des cas faciles, à juger sur une seule exécution et à confier le jugement à un modèle sans l’avoir vérifié. Chacune produit un score rassurant et peu informatif.

• Ne tester que les demandes courantes, sans informations absentes ni comportements interdits.
• Écrire les réponses attendues après avoir vu les réponses du système, ce qui entérine son comportement.
• Agréger tous les résultats en un seul taux, qui masque une divulgation ou une action interdite.
• Laisser le jeu sans responsable, si bien qu’il cesse de refléter les usages réels.

Pour une recherche documentaire, vérifiez la qualité des passages récupérés selon les principes des embeddings. Pour un système qui agit, le périmètre de l’agent fournit des comportements interdits à tester.

Lectures complémentaires : droits d’accès dans un RAG ; injections indirectes. Ces liens complètent la navigation du site.

Un premier jeu de tests IA sert à explorer un périmètre défini, avec des attentes indépendantes, des critères relus et des limites de couverture explicitement présentées.