Évaluer un assistant IA avant déploiement : protocole sur 50 cas

Un assistant IA ne devrait pas passer d’une démonstration convaincante à un usage réel sur la base de quelques réponses réussies. Il faut tester le système complet, dans sa configuration exacte, sur des situations représentatives du travail et sur les erreurs qui auraient une conséquence.

Réponse en bref

Pour évaluer un assistant IA avant déploiement, définissez d’abord la décision que le test doit éclairer. Construisez ensuite un jeu initial de 50 cas tirés du travail réel, avec des cas normaux, ambigus, incomplets, sensibles, adversariaux et hors périmètre. Notez séparément l’exactitude, la complétude, le respect des règles, l’abstention, le coût et le délai. Une erreur critique ne doit jamais disparaître dans une moyenne.

Le résultat n’est pas seulement « bon » ou « mauvais ». Trois décisions sont possibles :

• déployer dans le périmètre testé, avec surveillance ;
• limiter les données, les utilisateurs, les outils ou les actions ;
• arrêter tant qu’une erreur critique, une permission excessive ou une absence de reprise persiste.

Le nombre de 50 cas proposé ici est un point de départ opérationnel, pas une norme universelle. Un usage rare mais sensible peut nécessiter davantage de scénarios adversariaux. Un brouillon interne très borné peut commencer avec moins de cas, à condition de ne pas généraliser le résultat.

Évaluer le système, pas seulement le modèle

Une application d’IA est plus large que le nom du modèle affiché dans une interface. Sa réponse dépend aussi :

• des instructions système et des exemples ;
• des documents ou bases interrogés ;
• des outils et permissions disponibles ;
• de la mémoire conservée entre les échanges ;
• des validations écrites en code ;
• du nombre de tentatives autorisées ;
• des règles d’escalade vers une personne ;
• de la version du modèle, de la température et des paramètres ;
• de l’interface qui présente ou exécute le résultat.

Changer un seul de ces éléments peut changer le comportement. Un test réalisé dans un espace de démonstration ne qualifie donc pas automatiquement l’assistant qui sera utilisé avec des connecteurs, des données internes et des droits d’action.

Avant le premier cas, consignez la configuration testée :

Champ	Exemple de valeur
usage	préparer un brouillon de réponse à une demande fournisseur
utilisateurs	équipe achats pilote
entrées	message reçu et procédure interne validée
sortie	brouillon, jamais envoyé automatiquement
données accessibles	dossier documentaire limité au pilote
outils	recherche interne en lecture seule
validation	relecture par un acheteur
version	modèle, instructions, corpus et date
budget	nombre de tours, durée et coût maximal par cas

Cette fiche empêche de comparer deux résultats produits par des systèmes en réalité différents.

Commencer par une affirmation testable

« L’assistant est performant » ne décrit rien de mesurable. Une affirmation utile associe une tâche, un public, une configuration et un seuil.

Par exemple :

Dans la configuration pilote, l’assistant prépare un brouillon fidèle à la procédure pour les demandes standard, signale les informations manquantes et n’invente jamais une remise, une date ou une autorisation.

Cette affirmation contient déjà plusieurs critères :

1. la procédure applicable est identifiée ;
2. les informations présentes sont reprises sans déformation ;
3. les absences sont signalées ;
4. les valeurs non fournies ne sont pas inventées ;
5. aucune décision ou action n’est exécutée.

OpenAI distingue dans ses travaux récents l’affirmation testée, le système exact, le harnais d’évaluation et les contrôles de validité. Le NIST souligne de son côté qu’une mesure sur un benchmark fixe ne permet pas automatiquement de conclure sur tous les futurs cas similaires. Pour un projet métier, la prudence consiste à dire exactement ce que les cas couvrent et ce qu’ils ne couvrent pas.

Construire un jeu initial de 50 cas

Le jeu de tests doit ressembler à la distribution du travail, sans se limiter aux exemples faciles. La répartition suivante sert de canevas :

Famille	Nombre initial	Ce qu’elle vérifie
cas nominaux	18	la tâche principale dans des conditions ordinaires
variantes réalistes	8	formats, tons, longueurs et vocabulaires différents
informations manquantes	6	la demande de précision ou l’abstention
ambiguïtés et contradictions	6	la détection d’un conflit avant production
cas hors périmètre	4	le refus ou la bonne orientation
données sensibles ou interdites	4	la minimisation et l’escalade prévues
cas adversariaux	4	la résistance aux tentatives de détourner la mission
Total	50	une première photographie exploitable

Cette répartition doit suivre le risque. Si l’assistant peut appeler un outil ou lire le web, augmentez la part des tests adversariaux. Si l’essentiel du travail porte sur des formulaires incomplets, augmentez les cas d’information manquante.

Partir des erreurs réelles

Les meilleurs cas viennent rarement d’une séance de brainstorming isolée. Ils se trouvent dans :

• les demandes qui reviennent au support ;
• les corrections fréquemment apportées par les spécialistes ;
• les exceptions décrites dans les procédures ;
• les tickets d’incident ;
• les dossiers abandonnés ;
• les formulations que les nouveaux utilisateurs comprennent mal ;
• les changements de format entre deux logiciels.

Retirez ou remplacez les données personnelles et confidentielles avant de constituer le jeu. Un jeu synthétique doit préserver la difficulté du cas sans recopier une personne, un client ou un secret. Le protocole de fabrication de données synthétiques pour les tests distingue les scénarios entièrement fictifs des jeux générés à partir de données réelles.

Garder une partie des cas à l’écart

Si tous les cas servent à améliorer le prompt, le score final mesure surtout la capacité à réussir les exemples déjà vus. Gardez un lot de validation que les personnes qui corrigent le système n’utilisent pas pendant l’itération.

Pour 50 cas, une organisation simple peut être :

• 35 cas pour comprendre et corriger ;
• 15 cas réservés à la décision finale.

Ce partage ne garantit pas une généralisation statistique. Il réduit seulement le risque d’optimiser la solution sur la totalité du contrôle.

Définir la bonne réponse sans imposer une phrase unique

Une réponse générative peut être correcte sans reprendre mot pour mot une référence. Chaque fiche de test doit donc séparer :

• les éléments obligatoires ;
• les éléments interdits ;
• les variantes acceptables ;
• le comportement attendu en cas d’incertitude ;
• la personne ou le rôle qui peut trancher.

Exemple de fiche :

Élément	Attente
situation	le fournisseur demande un délai absent du dossier
réponse attendue	signaler l’absence et demander la date validée
obligatoire	citer la référence du dossier et la donnée manquante
interdit	inventer un délai ou promettre une livraison
variante acceptable	proposer deux formulations de demande de précision
gravité d’un échec	critique si une date non validée est affirmée

Un corrigé trop rigide peut pénaliser une bonne formulation. Un corrigé trop vague peut accepter une réponse dangereuse. Le responsable métier doit donc définir le contenu, tandis que l’équipe technique transforme cette définition en contrôle reproductible.

Combiner trois modes de notation

Aucun évaluateur unique ne suffit à tous les critères.

1. Contrôle déterministe

Le code est adapté aux exigences vérifiables sans jugement :

• présence d’un identifiant ;
• format JSON valide ;
• absence d’un champ interdit ;
• montant recopié exactement ;
• URL appartenant à une liste autorisée ;
• aucun appel d’outil lorsque le cas l’interdit.

Ce contrôle est rapide, stable et facile à rejouer.

2. Revue humaine

Une personne compétente reste nécessaire pour juger :

• la fidélité à une procédure complexe ;
• l’utilité réelle pour le destinataire ;
• la gravité d’une omission ;
• la qualité d’une escalade ;
• les formulations qui peuvent tromper malgré leur correction apparente.

La grille doit être courte et accompagnée d’exemples. Deux personnes peuvent noter différemment le même brouillon. Un échantillon noté en double permet d’identifier les critères trop flous.

3. Modèle juge

Un autre modèle peut accélérer une notation à grande échelle, mais il devient lui-même un instrument à évaluer. Google recommande, dans sa documentation sur les modèles juges, de comparer leurs scores à des évaluations humaines servant de référence. Anthropic conseille des critères détaillés et mesurables, puis une vérification de la fiabilité avant de généraliser la notation automatisée.

Le modèle juge ne doit pas être la seule barrière d’une décision critique. Calibrez-le sur des réponses bonnes, mauvaises et trompeuses. Mesurez ses faux positifs et faux négatifs. Conservez la possibilité de revoir chaque cas, au lieu de garder uniquement une moyenne.

Séparer qualité, sécurité et exploitation

Un score global sur 100 est séduisant, mais il masque les compromis. Présentez au minimum cinq axes :

Axe	Exemple d’indicateur
fidélité métier	cas contenant tous les éléments obligatoires
erreurs critiques	nombre et nature, avec dénominateur
abstention	refus corrects et refus inutiles
exploitation	délai, coût, reprise et traçabilité
supervision	temps de revue et corrections humaines

Ajoutez les nombres bruts. « 96 % de réussite » peut signifier deux échecs sur 50. Si ces deux échecs correspondent à une divulgation ou à une action non autorisée, le système n’est pas qualifié pour ce périmètre.

Utiliser une matrice gravité-fréquence

Pour chaque défaut, attribuez une gravité définie avant le test :

Gravité	Exemple	Règle de décision
critique	action non autorisée, fuite, décision sensible inventée	arrêt du périmètre concerné
majeure	mauvaise procédure, fait décisif faux, absence d’escalade	correction puis nouveau test
modérée	information utile omise, format difficile à relire	amélioration planifiée
mineure	style ou formulation sans effet sur la décision	arbitrage produit

La fréquence reste séparée. Une erreur mineure fréquente peut rendre l’outil inutilisable. Une erreur critique observée une fois peut suffire à retirer une permission.

Rejouer les cas qui comptent

Une réponse identique n’est pas garantie d’une exécution à l’autre. Le NIST recommande, pour l’évaluation du détournement d’agents, d’observer plusieurs tentatives et de regarder les tâches séparément en plus du taux agrégé.

Dans un protocole métier, rejouez au moins :

• tous les cas critiques ;
• les cas ambigus ;
• les cas dont le résultat a changé après une correction ;
• un échantillon de cas nominaux.

Consignez le nombre de tentatives. Un système qui réussit une fois sur trois ne doit pas être présenté comme ayant « passé le test » parce que la meilleure sortie a été conservée.

Exemple synthétique : assistant de préparation de réponses

Imaginons un assistant interne qui prépare des brouillons à partir d’une demande et d’une procédure publique de l’organisation. Il n’envoie rien.

Le premier essai obtient :

• 43 cas sans défaut majeur ;
• 4 cas avec une information utile omise ;
• 2 refus inutiles ;
• 1 date inventée alors que le dossier était contradictoire.

Une moyenne simple donnerait 86 % de cas sans défaut majeur. Pourtant, la date inventée constitue une erreur critique selon la grille. La décision raisonnable n’est pas de déployer tel quel.

L’équipe peut :

1. retirer tout champ de date de la génération libre ;
2. exiger qu’une date provienne d’un champ structuré validé ;
3. bloquer la sortie si deux dates se contredisent ;
4. ajouter six variantes de contradiction au jeu ;
5. rejouer les anciens cas et le lot réservé ;
6. mesurer le temps de revue supplémentaire.

Si le système réussit ensuite les tests, la conclusion reste bornée : il est acceptable pour préparer un brouillon dans cette configuration, pas pour envoyer un message ni décider d’un engagement.

Décider : déployer, limiter ou arrêter

Déployer

Le déploiement dans le périmètre testé devient défendable lorsque :

• aucune erreur critique ne reste ouverte ;
• les erreurs majeures sont sous le seuil fixé ;
• les permissions correspondent au besoin minimal ;
• l’humain peut comprendre, corriger et interrompre ;
• les journaux permettent une investigation sans recopier de secrets ;
• un propriétaire maintient le jeu de tests ;
• le coût de revue reste compatible avec l’effet attendu.

Limiter

La limitation est souvent la meilleure décision intermédiaire :

• brouillon au lieu d’envoi ;
• lecture seule au lieu d’écriture ;
• corpus approuvé au lieu du web ouvert ;
• groupe pilote au lieu de toute l’organisation ;
• données synthétiques au lieu de dossiers réels ;
• seuil de volume quotidien ;
• validation obligatoire pour certaines catégories.

Cette réduction n’est pas un échec. Elle rapproche les capacités du système de la preuve disponible.

Arrêter

Arrêtez le périmètre testé si :

• une conséquence critique peut survenir sans contrôle ;
• l’équipe ne peut pas reproduire le résultat ;
• la provenance d’une réponse décisive est introuvable ;
• les données nécessaires ne peuvent pas être utilisées légalement ou en sécurité ;
• la correction demande d’accorder encore plus de permissions ;
• personne ne porte la maintenance ;
• le gain attendu disparaît une fois le contrôle humain compté.

Transformer chaque incident en test de régression

Le jeu de 50 cas n’est pas un examen que le système passe une seule fois. Il devient un actif de maintenance.

Ajoutez un cas lorsqu’apparaît :

• une nouvelle erreur réelle ;
• un nouveau format de document ;
• une évolution de procédure ;
• un nouveau connecteur ;
• une modification de modèle ;
• une permission supplémentaire ;
• un contournement par les utilisateurs.

Versionnez le jeu, la grille et la configuration. Après chaque changement, rejouez les contrôles concernés puis un noyau stable. Une amélioration de style ne doit pas réintroduire une date inventée, une source absente ou une action non autorisée.

Checklist avant la décision

• L’affirmation testée décrit une tâche et un périmètre précis.
• La configuration complète est enregistrée.
• Les cas viennent du travail réel ou de variantes synthétiques représentatives.
• Les cas faciles, incomplets, ambigus, interdits et adversariaux sont présents.
• Une partie du jeu n’a pas servi aux corrections.
• Les éléments obligatoires et interdits sont explicites.
• Les erreurs critiques ne sont pas noyées dans une moyenne.
• Le modèle juge, s’il existe, est calibré sur des notes humaines.
• Les cas à conséquence sont rejoués plusieurs fois.
• Le coût, la latence et le temps de revue sont mesurés.
• La décision précise ce qui peut être fait, par qui et avec quelles données.
• Une personne possède le jeu de régression et son calendrier.

Limites

Ce protocole aide à préparer une décision de déploiement. Il ne certifie ni la conformité juridique, ni la sécurité, ni l’absence d’erreur future. Cinquante cas ne représentent pas toutes les situations possibles. Les résultats dépendent du système, du contexte, de la qualité des références et des personnes qui notent.

Pour un usage à conséquence, associez les responsables métier, produit, sécurité, données, juridique ou conformité selon le contexte. Complétez les tests fonctionnels par une analyse de risque, des tests de sécurité et une procédure d’incident.

Articles liés

• IA en entreprise en 2026 et 2027 : passer des outils aux usages
• Prompt ou workflow : choisir le bon niveau de système
• Protéger les données sensibles avec un assistant IA
• Concevoir une formation ChatGPT en entreprise

Prochaine étape

Choisissez une seule tâche, désignez le spécialiste qui saura reconnaître une erreur et écrivez les dix premiers cas avant de modifier le prompt. Si le besoin reste difficile à borner, un cadrage de conseil IA peut servir à définir la décision, les données, les contrôles et le propriétaire du futur jeu de tests.