← Tous les articles

[Tests]

Tester une application dont les réponses peuvent varier.

Une réponse peut changer de formulation tout en restant juste. Construisez une évaluation qui distingue les variations acceptables, les erreurs métier et les actions que le système doit éviter.

CICollective Intelligence · · 8 min de lecture
Schéma illustrant le processus décrit dans cet article

Définir une réponse acceptable avant de mesurer

Une application IA peut produire plusieurs formulations correctes pour une même demande. Comparer chaque réponse à une phrase unique risque de rejeter une bonne reformulation ou de passer à côté d’une erreur importante. L’évaluation doit porter sur les propriétés qui rendent le résultat utilisable : faits présents, distinctions respectées, format compréhensible et actions autorisées.

Prenons une équipe fictive qui utilise un assistant pour préparer ses comptes rendus de réunion. Le document doit distinguer les décisions, les actions et les questions ouvertes. Une phrase plus courte peut être acceptable ; attribuer une action à la mauvaise personne ne l’est pas. Avant de choisir un outil de test, l’équipe doit donc préciser ce qu’elle attend sur quelques réunions représentatives. Ces critères formeront une base commune pour les concepteurs, les utilisateurs et les personnes chargées de décider si une nouvelle version peut être mise en service.

Séparer les faits, le format et les limites

Une grille utile distingue plusieurs dimensions. Les faits doivent correspondre aux éléments de la réunion. Le format doit permettre de retrouver les décisions et les prochaines étapes. Les limites concernent ce que l’assistant ne peut pas conclure ou entreprendre. Une belle présentation ne doit pas compenser une information inventée, et une réponse prudente ne doit pas masquer l’oubli systématique des actions demandées.

Dans notre exemple, le compte rendu peut exiger un responsable pour chaque action lorsqu’il a été désigné, une date lorsqu’elle a été confirmée et une mention explicite lorsqu’elle reste à préciser. Une proposition discutée ne doit pas devenir une décision collective. L’assistant prépare un document ; il ne modifie pas les engagements dans un autre outil sans que cette capacité soit prévue. Ces critères peuvent être examinés séparément. Le résultat de l’évaluation indique ainsi le type de défaut observé et aide à choisir la correction pertinente.

Construire un exemple dont le résultat attendu est clair

Imaginons qu’une réunion contienne cet échange fictif : « Nous pourrions présenter la nouvelle offre vendredi, si le catalogue est prêt. » Plus tard, une participante précise : « Je confirme la date après le retour de l’imprimeur. » Le résultat attendu doit conserver le caractère conditionnel de la présentation. Il ne doit pas annoncer une échéance définitivement validée.

Le test peut vérifier la présence de la condition, l’absence d’une date ferme inventée et l’identification de la confirmation restant à obtenir. Plusieurs formulations peuvent satisfaire ces exigences. Une personne métier doit valider ces attentes à partir de l’échange initial. Copier la première réponse du modèle comme référence ferait dépendre le test de ses éventuelles erreurs. Pour les situations ambiguës, documentez ce qui peut être affirmé et ce qui doit rester ouvert. Le jeu d’évaluation devient une description du comportement souhaité, avec des raisons compréhensibles pour la personne qui le relit.

Réunir des cas variés et garder des exemples à part

Les réunions utilisées pour l’évaluation doivent couvrir des situations courantes et difficiles : décisions simples, corrections en cours d’échange, absence de responsable, désaccords et sujets reportés. Incluez des notes courtes et des comptes rendus de conversation plus longs si ces formats existent dans l’usage prévu. La variété doit venir du travail réel, sans se limiter aux exemples les plus faciles à rédiger.

Séparez les cas utilisés pour améliorer les consignes de ceux qui servent à apprécier le résultat final. Si tous les exemples sont connus pendant les réglages, une bonne performance peut seulement refléter l’adaptation à ces cas précis. Gardez aussi une trace des incidents rencontrés et ajoutez les situations utiles au corpus de vérification. Lorsque les règles métier évoluent, mettez à jour les attentes explicitement. Un test ancien peut devenir inadapté ; il doit être révisé pour une raison documentée, pas simplement supprimé parce qu’il échoue.

Choisir le bon contrôle pour chaque critère

Certains contrôles peuvent être réalisés par du code : présence des rubriques, format des dates, nombre de champs ou référence à une réunion connue. Ils sont utiles pour vérifier des contraintes précises. D’autres critères demandent d’interpréter le sens : une réserve a-t-elle été conservée ? Une proposition est-elle présentée comme acquise ? La synthèse reflète-t-elle le désaccord exprimé ?

Une revue humaine peut examiner ces dimensions sur un ensemble de cas. Un autre modèle peut également aider à préparer une évaluation, mais son jugement doit être confronté à des décisions de référence et rester vérifiable. Demandez une justification rattachée au passage concerné, puis examinez les désaccords entre évaluateurs. La méthode choisie doit permettre de détecter les erreurs qui comptent pour le métier. Une note générale sans explication peut donner une impression de précision tout en laissant l’équipe incapable de comprendre pourquoi une réponse a été acceptée ou rejetée.

Observer la variation sur plusieurs exécutions

Une seule réponse ne décrit pas toujours le comportement d’une version. Pour les cas importants, répétez l’évaluation et examinez les écarts. Le compte rendu peut conserver les décisions à chaque essai, mais oublier parfois une condition ou changer l’attribution d’une action. Cette observation permet de repérer une fragilité qu’une démonstration réussie ne montre pas.

Notez la version du modèle, les consignes, les documents et les réglages utilisés afin de rendre la comparaison interprétable. Plusieurs essais sur le même petit ensemble ne garantissent pas la qualité sur toutes les futures réunions. Présentez donc les résultats avec leur périmètre. Une proportion de réponses acceptables est une mesure observée, pas une promesse universelle. Les défauts graves doivent rester visibles séparément : un oubli d’intitulé et une action attribuée à tort ne doivent pas disparaître dans la même moyenne si leurs conséquences diffèrent pour l’équipe.

Tester les absences d’information et les interruptions

Une application doit aussi être évaluée quand elle ne peut pas produire le résultat prévu. Essayez une transcription vide, un fichier incomplet, une pièce inaccessible ou une réunion dont les participants ne sont pas identifiés. Définissez ce que l’utilisateur doit voir : un brouillon partiel, une demande de précision ou un message expliquant pourquoi le traitement ne peut pas continuer.

Dans notre exemple, l’absence de date ne doit pas conduire à choisir automatiquement celle du jour. Une phrase interrompue ne permet pas d’inventer la décision qui aurait pu suivre. Testez également la reprise après une interruption et la relance d’une demande déjà traitée. Le système doit préserver les corrections humaines et éviter les documents concurrents sans indication de version. Les contrôles portent ici sur le parcours complet. La qualité du texte généré ne suffit pas à vérifier que la bonne réunion a été utilisée et que le bon document a été enregistré.

Comparer deux versions sur les mêmes critères

Lorsqu’une consigne ou un modèle change, rejouez le même ensemble de cas et examinez les différences. Une version peut améliorer la lisibilité tout en perdant certaines réserves. Une autre peut mieux respecter le format mais demander davantage d’informations à l’utilisateur. La décision doit tenir compte de ces effets au lieu de retenir uniquement une note globale.

Pour le compte rendu, la grille peut distinguer les décisions correctement restituées, les actions complètes, les informations inventées et le temps de correction. Fixez avec l’équipe les défauts qui bloquent une mise en service et ceux qui peuvent être acceptés temporairement dans un périmètre limité. Examinez les cas nouveaux qui échouent, même si la moyenne progresse. La comparaison doit expliquer ce qui change pour les utilisateurs. Conservez la version précédente et les résultats observés pour pouvoir comprendre une régression et décider d’un retour en arrière si nécessaire.

Vérifier le comportement après la publication

Les premiers usages réels peuvent révéler des formats ou des situations absents du jeu d’essai. Organisez un moyen simple de signaler une erreur avec la réunion concernée, le passage mal interprété et la correction attendue. Précisez les personnes autorisées à consulter ces éléments et les informations nécessaires à l’analyse, afin de ne pas collecter plus de contenu que le suivi ne l’exige.

Regroupez les signalements par cause : entrée incomplète, règle ambiguë, mauvaise attribution ou problème d’enregistrement. Certains défauts demandent une correction du processus plutôt qu’une nouvelle consigne. Si les noms des participants manquent régulièrement, améliorer l’entrée peut aider davantage qu’allonger le texte d’instruction. Les cas utiles rejoignent ensuite les vérifications de la prochaine version. Ce suivi relie l’évaluation au travail réel et permet de constater si les corrections réduisent les erreurs sans dégrader les situations qui fonctionnaient déjà correctement.

Démarrer avec une suite courte mais explicite

Choisissez quelques réunions de démonstration et rédigez les critères attendus avant de lancer l’assistant. Pour chaque cas, indiquez les décisions certaines, les actions à retrouver et les éléments qui doivent rester indéterminés. Faites vérifier cette grille par une personne qui connaît le processus, puis comparez les réponses et les corrections nécessaires.

Ajoutez ensuite les situations qui révèlent une limite réelle. L’objectif est de construire une évaluation que l’équipe comprend et utilise à chaque changement important. Les contrôles simples protègent les formats, les exemples métier protègent le sens et la vérification du parcours protège les effets dans les outils. Cette combinaison donne une base concrète pour décider d’une mise en service. Une réponse variable peut ainsi être évaluée avec rigueur, dès lors que les limites de ce qui est acceptable sont décrites et vérifiées.

Et dans votre entreprise ?

Chaque processus possède ses particularités. Partons de votre fonctionnement pour identifier une première amélioration concrète.

Contactez-nous