Pictoquest
FR
Guide évaluation · 10 min

Construire un jeu de tests pour une IA métier

Une démonstration réussie ne dit pas comment un système répondra aux demandes ordinaires, ambiguës ou difficiles. Un petit jeu de tests bien conçu rend la qualité observable et aide à détecter une régression après un changement.

Mis à jour le 26 septembre 2026Lecture et contrôle éditorial Pictoquest
Une équipe examine des documents, des graphiques et des notes pour évaluer des réponses.
À retenir

Le point de départ

Rassemblez des cas réels anonymisés, ajoutez des cas limites et des demandes auxquelles l’IA doit refuser de répondre. Définissez ce qui rend une sortie acceptable, puis comparez les versions avec la même grille et une revue humaine.

  • Cas représentatifs et difficiles
  • Critères observables
  • Comparaison régulière

Créer un référentiel en six étapes

  1. 1. Délimiter la mission

    Listez les tâches autorisées, les utilisateurs, les formats de réponse et les erreurs les plus coûteuses. Une évaluation de recherche sourcée ne mesure pas les mêmes choses qu’un assistant de support.

  2. 2. Collecter les exemples

    Prenez des demandes fréquentes et des cas rares mais importants. Retirez les données personnelles et conservez la provenance et la date de chaque exemple.

  3. 3. Ajouter des cas adverses

    Incluez les demandes ambiguës, documents contradictoires, entrées vides, langues différentes et instructions malveillantes lorsque ces situations peuvent survenir.

  4. 4. Écrire une grille

    Notez la justesse, les sources, le respect du format, le refus approprié et le temps de correction. Décrivez des niveaux observables pour éviter un simple ressenti.

  5. 5. Établir une référence

    Exécutez tous les cas sur la version actuelle. Faites relire un échantillon par deux personnes et résolvez les désaccords de notation avant de comparer une nouvelle version.

  6. 6. Suivre les régressions

    Relancez les tests après un changement de modèle, de prompt, de corpus ou d’outil. Ajoutez les incidents réels au jeu de tests et retirez les exemples devenus obsolètes.

Mettre la méthode à l’épreuve

Cas pratique

Constituez douze cas anonymisés : six courants, trois ambigus, deux critiques et un que le système doit refuser.

Preuves à conserver

Pour chaque cas, définissez résultat attendu, barème observable, version testée et éventuel désaccord entre évaluateurs.

Décider

Comparez les versions sur ce lot stable ; ajoutez ensuite les incidents réels sans réécrire rétroactivement les résultats de départ.

Quatre qualités d’un bon jeu

Représentativité

Les cas reflètent les usages réels et leurs fréquences.

Couverture des risques

Les erreurs coûteuses et les refus attendus sont présents.

Reproductibilité

Entrées, versions et barème sont conservés.

Actualisation

Les incidents et changements métier alimentent le jeu.

6 repères

Services à comparer sur les mêmes cas

Utilisez une courte liste de services adaptés à la mission ; le jeu de tests permet de voir leurs écarts sur votre contexte.

Comment cette sélection est-elle produite ?

Les services actifs sont répartis entre les catégories liées au guide, puis ordonnés par mise en avant éditoriale et score interne. Ce repère n’évalue ni la sécurité, ni la conformité, ni la performance sur votre cas. Méthodologie.

Explorer toute la catégorie

Familles d’outils liées

Questions fréquentes

Combien de cas faut-il ?

Commencez avec un petit ensemble diversifié et stable, puis ajoutez les incidents et les cas manquants. La couverture compte plus qu’un nombre arbitraire.

Une note automatique suffit-elle ?

Non. Pour les résultats importants, vérifiez un échantillon manuellement et contrôlez les désaccords entre évaluateurs.

Quand relancer les tests ?

Après tout changement de modèle, de consignes, de données ou d’outil, et régulièrement sur les cas critiques.

Poursuivre avec un autre guide