Un assistant répond correctement à trois démonstrations commerciales, puis donne une mauvaise procédure à un collègue. La contradiction n’a rien de mystérieux : les démonstrations et le travail quotidien ne lui posaient pas les mêmes difficultés. Pour décider où employer une IA, il faut construire des questions qui représentent les tâches, mais aussi les erreurs que l’organisation ne peut pas accepter.
Un jeu d’évaluation utile ne cherche donc pas seulement à obtenir une note. Il indique dans quelles conditions l’assistant peut aider, quand il doit demander une précision et quand un humain doit reprendre. Voici une méthode de construction adaptée à une petite équipe, sans prétendre transformer quelques dizaines d’exemples en certification universelle.
Commencer par une tâche et une décision concrètes
« Répondre aux questions des salariés » est trop large pour être évalué sérieusement. « Expliquer la procédure de remboursement d’un déplacement à partir des règles internes en vigueur » permet déjà de définir un résultat observable. Le périmètre précise les utilisateurs, les documents autorisés et les actions attendues après la réponse.
Décrivez ensuite ce qui constitue une erreur importante. Confondre une avance et un remboursement n’a pas la même conséquence qu’une formule maladroite. Fournir un montant dépassé, oublier une condition d’éligibilité ou révéler une donnée appartenant à un autre service sont des échecs distincts.
Cette liste devient le point de départ des critères.
Il faut également déterminer ce que l’assistant ne doit pas faire. Peut-il rédiger une proposition, calculer un montant, consulter un dossier individuel ou lancer une demande ? Une réponse acceptable en mode conseil peut devenir insuffisante lorsque le même système dispose d’un bouton de validation. Évaluer la réponse et évaluer l’action sont deux travaux complémentaires.
Récolter des situations avant de rédiger des pièges
Partez de demandes réelles, après retrait des informations qui n’ont pas à entrer dans le dispositif. Le support, les responsables métier et les nouveaux arrivants ne rencontrent pas les mêmes obstacles. Leurs exemples révèlent le vocabulaire courant, les questions incomplètes et les raccourcis que les experts finissent par ne plus remarquer.
Une première collecte peut distinguer les demandes fréquentes, les cas plus rares mais coûteux et les situations réellement impossibles à résoudre avec les informations accessibles. Aucun nombre magique ne garantit une bonne couverture. Une petite série bien documentée permet de commencer ; elle doit s’enrichir à mesure que les usages et les incidents deviennent visibles.
Évitez de ne sélectionner que les questions ayant déjà obtenu une bonne réponse. Gardez les formulations ambiguës, les noms proches et les demandes mêlant plusieurs sujets. Préservez aussi un lot de cas que la personne chargée d’améliorer les consignes ne consulte pas pendant ses réglages.
Sans cette séparation, elle risque d’optimiser l’assistant pour les exemples connus.
Écrire une fiche de référence par cas
Pour chaque question, consignez le contexte nécessaire, la réponse attendue et les éléments qui doivent absolument être présents. Une réponse de référence ne doit pas imposer une tournure unique. Elle définit plutôt des obligations vérifiables : bon plafond, bonne population, bonne date et mention d’une exception précise.
Ajoutez la source faisant autorité et sa version. Si deux personnes métier interprètent différemment la règle, résolvez ce désaccord avant de noter l’IA. Sinon, le score mesure en partie l’instabilité de votre propre référentiel. Dans certains cas, la bonne réponse sera justement de signaler une contradiction documentaire et de demander un arbitrage.
Une fiche exploitable peut prendre cette forme :
| Champ | Ce qu’il permet de vérifier |
|---|---|
| Situation et question | Le besoin effectivement posé |
| Documents disponibles | Ce que le système pouvait savoir |
| Points obligatoires | Les informations décisives à restituer |
| Erreurs éliminatoires | Ce qui rend la réponse inutilisable |
| Comportement attendu en cas de doute | Question, abstention ou orientation humaine |
| Source et version | La justification de la correction |
Le tableau n’est pas une formalité administrative. Il rend les désaccords visibles et permet à une autre personne de reprendre l’évaluation sans deviner l’intention du premier évaluateur.
Construire des variantes qui isolent une difficulté
Une bonne question peut produire plusieurs variantes. Changez un seul élément à la fois : salarié permanent ou intervenant extérieur, déplacement national ou international, date antérieure ou postérieure à une modification de politique. Si la réponse reste identique alors que la règle change, vous avez identifié une faiblesse précise.
Insérez des cas où l’information manque. Une question sans date ne permet pas toujours d’appliquer le bon barème. Une demande mentionnant « mon équipe » ne définit pas nécessairement le périmètre d’accès. Demander une précision peut être une réussite, même si la réponse semble moins spectaculaire qu’une solution immédiate.
Préparez également des questions dont la prémisse est fausse : une procédure inexistante, un document retiré ou un avantage auquel la personne n’est pas éligible. L’objectif n’est pas de piéger gratuitement le système. Il s’agit de vérifier qu’il ne transforme pas une hypothèse de l’utilisateur en fait établi.
Les variantes doivent garder un intérêt métier. Des énigmes artificielles peuvent occuper beaucoup de temps sans éclairer les limites rencontrées par les collègues. Priorisez les confusions plausibles, les exceptions fréquentes et les incidents dont vous connaissez déjà les conséquences.
Séparer les critères au lieu de cacher les erreurs dans une moyenne
Attribuez des appréciations distinctes à l’exactitude, à la complétude, à la justification, au respect des droits et à l’utilité pratique. Une réponse peut être exacte mais ne pas indiquer l’étape suivante. Elle peut être claire mais citer une source qui ne prouve pas sa conclusion. Ces défauts appellent des corrections différentes.
Définissez les erreurs éliminatoires indépendamment du score général. Un assistant qui réussit beaucoup de demandes simples mais divulgue un dossier interdit ne devient pas acceptable grâce à une bonne moyenne. Le même principe vaut pour une action irréversible lancée sans autorisation ou pour une décision métier que l’outil n’est pas habilité à prendre.
Pour les réponses ouvertes, faites noter un échantillon par deux personnes. Comparez leurs raisons, puis précisez la grille. Un évaluateur automatique peut accélérer le tri, mais ses jugements doivent être confrontés à ceux du métier. Un second modèle n’est pas une vérité de référence simplement parce qu’il produit une note chiffrée.
Tester le système effectivement proposé aux utilisateurs
Le nom du modèle ne suffit pas à définir l’objet évalué. Enregistrez les instructions, les outils activés, les droits du compte, le corpus accessible et les paramètres utiles. Une recherche documentaire appuyée sur des documents internes peut priver un bon modèle du passage nécessaire si elle fonctionne mal ; une permission excessive peut rendre dangereuse une réponse techniquement correcte.
Conservez les résultats intermédiaires lorsque l’architecture le permet : documents trouvés, appels aux outils, erreurs d’accès et durée. Ils aident à distinguer limite du modèle, défaut de configuration et incident du service. Changer de modèle sans ce diagnostic peut déplacer le problème sans le résoudre.
Pour les cas sensibles, répétez les essais. Une seule bonne réponse ne démontre pas une stabilité suffisante. Les répétitions ne doivent toutefois pas servir à ne publier que le meilleur résultat. Gardez les sorties et précisez les conditions de chaque essai ; la dispersion est une information utile, particulièrement lorsqu’une erreur entraîne une conséquence importante.
Décider d’un usage autorisé, puis surveiller ce qui change
Fixez les critères d’acceptation avant de comparer les versions. Le métier peut autoriser la préparation d’un brouillon tout en maintenant une validation humaine pour le montant final. Il peut aussi décider qu’une catégorie de questions doit être dirigée vers un spécialiste. L’évaluation sert à tracer ces frontières avec des exemples concrets.
Ne présentez pas le pourcentage obtenu comme la probabilité de réussite sur toutes les futures demandes. Il décrit les cas choisis, dans les conditions testées. Si certaines catégories sont peu représentées, dites-le. Une amélioration globale peut masquer une régression sur une exception importante ; consultez donc les résultats par famille de tâches.
Les recommandations techniques des éditeurs sur les évaluations insistent sur leur caractère continu et sur leur adaptation à la tâche. En pratique, refaites le lot stable après une modification significative du modèle, des instructions, des connecteurs ou du référentiel. Ajoutez les incidents nouveaux à une collection distincte avant de décider lesquels rejoindront les tests permanents.
Le livrable le plus utile tient finalement dans un dossier lisible : questions, critères, versions, erreurs observées et périmètre autorisé. Une limite documentée est exploitable : l’équipe peut prévoir un contrôle ou retirer une fonction. Une note flatteuse sans conditions laisse les utilisateurs découvrir eux-mêmes les exceptions, au moment où elles comptent.
