Vous rejouez la demande d'hier. Testez-vous la situation d'hier ?

Imaginons un client qui demande si son remboursement est parti. Le service de paiement l'affiche toujours en attente de traitement, mais l'assistant répond qu'il a été émis. Le client consulte son compte et recontacte le support.

L'équipe modifie les instructions de l'assistant et rejoue le message le lendemain. Cette fois, la réponse « émis » correspond au dossier de paiement : un collègue a traité le remboursement entre-temps. Cette réussite apparente ne dit pas si l'assistant confirmerait encore trop tôt un remboursement en attente.

Le même message correspond désormais à une autre situation.

La distinction compte dès qu'un agent consulte des systèmes dont les données évoluent. Conserver le prompt ne suffit pas à constituer un cas de test. L'état des dossiers et les réponses des outils disponibles au moment du problème peuvent déterminer ce que l'agent devait faire.

Reconstituer le moment de la décision

Commencez par identifier le comportement que vous cherchez à reproduire.

L'assistant devait-il expliquer l'état du remboursement, demander une décision autorisée ou exécuter une action approuvée ? Ce sont des tests différents. « Donner une meilleure réponse » reste trop vague pour vérifier une correction.

Pour le point de décision retenu, conservez l'entrée utile et les éléments effectivement vus par le système. Cela peut comprendre l'état de la commande, la réponse d'un outil, la version de la politique applicable et les actions déjà tentées. Ne gardez que le nécessaire, avec des accès et une durée de conservation adaptés. La collection de tests ne doit pas devenir une copie incontrôlée des dossiers clients.

Notez ce qui manque. Si la réponse originale de l'outil n'a pas été enregistrée, une reconstruction ultérieure ne constitue pas un rejeu exact. Elle peut rester utile, à condition d'en montrer les limites.

Le guide Tenex sur le développement piloté par les évaluations distingue l'évaluation de la réponse finale de celle des étapes et appels d'outils qui l'ont produite. Il souligne aussi la difficulté du rejeu lorsque l'état extérieur a changé. C'est sur cette partie du travail que porte cet article.

Définir le résultat attendu avant d'essayer la correction

Dans notre exemple de remboursement en attente, le résultat attendu pourrait être d'indiquer l'état réel sans déclencher un second remboursement. L'attente exacte doit venir du processus de l'entreprise et de l'autorité confiée à l'agent.

Décrivez les actions permises autant que les mots attendus. Une explication agréable ne constitue pas une réussite si l'assistant effectue en parallèle une écriture non autorisée. À l'inverse, un refus justifié peut être correct même si le test attendait une confirmation enthousiaste.

Prévoyez l'incertitude. Si le système destinataire n'a pas répondu après une requête, il peut être nécessaire de vérifier si l'action a eu lieu. Un test exigeant immédiatement oui ou non risque de récompenser une certitude inventée.

Faites relire le résultat attendu par le responsable du processus. Sans cela, le test peut appliquer fidèlement une mauvaise compréhension de l'implémenteur.

Stabiliser les éléments de comparaison

Construisez une version contrôlée du cas à partir de l'état historique pertinent. L'objectif est que l'ancienne et la nouvelle version rencontrent des éléments équivalents.

Enregistrez la configuration de l'agent, ses instructions et les définitions des outils utilisées dans chaque essai. Si un service de modèle peut évoluer hors de votre contrôle, notez l'identifiant et la date disponibles. Ne promettez pas une reproductibilité parfaite que vous ne maîtrisez pas.

Séparez les données soumises du résultat attendu. Si la résolution se trouve déjà dans les documents fournis à l'assistant, le test dira peu de chose sur sa capacité à traiter le problème initial.

Il faut trouver une mesure utile. Un petit cas compréhensible peut révéler une régression précise. Une simulation compliquée que personne ne sait examiner peut cacher ses propres hypothèses. Conservez assez de la séquence originale pour tester le comportement et précisez ce que la simulation ne représente pas.

Empêcher le rejeu d'exécuter l'action réelle

Ne rejouez pas un remboursement, une autorisation d'expédition ou un message client avec des droits d'écriture en production simplement pour observer l'agent.

Utilisez un environnement de test ou des outils de substitution contrôlés qui enregistrent les actions proposées sans les exécuter à l'extérieur. La limite doit être imposée par l'environnement et les droits d'accès. Une phrase indiquant au modèle qu'il participe à un test ne suffit pas.

Vérifiez également les outils de substitution. S'ils répondent toujours que l'action a réussi, ils ne permettent pas d'observer le traitement d'un refus ou d'un résultat incertain. Introduisez délibérément la réponse d'erreur pertinente.

Un appel simulé montre ce que l'agent a tenté dans ce dispositif. Il ne prouve pas que l'intégration de production fonctionne. Cette vérification reste un travail distinct, avec son propre périmètre sûr.

Comparer le parcours

Examinez les dossiers consultés, l'action proposée et la manière de traiter les informations manquantes.

Dans l'exemple, une version qui lit le bon état avant de répondre se distingue d'une version qui tombe juste sans vérifier. Leur texte final peut se ressembler sur ce cas et diverger au suivant.

Répétez suffisamment les essais pour apprécier la stabilité du comportement attendu. Aucun nombre universel d'exécutions ne certifie tous les workflows. Une seule réponse satisfaisante d'un système variable reste une preuve faible de fiabilité.

Gardez aussi des cas voisins dans la comparaison. Une modification qui corrige le remboursement en attente peut casser le traitement d'un dossier déjà terminé, annulé ou soumis à validation. Choisissez les états voisins qui comptent réellement plutôt que d'accumuler des questions sans rapport.

Conserver un échec utile

Lorsqu'un incident réel apporte un enseignement, transformez-le en cas de test maintenu. Précisez le défaut contre lequel il protège et le responsable capable d'actualiser le résultat attendu lorsque la politique change.

Révisez ou retirez les cas qui ne correspondent plus au service. Une collection obsolète peut récompenser un ancien comportement avec autant d'assurance qu'une vieille notice.

Ce travail complète l'évaluation d'un workflow lorsque les modèles progressent. La question plus précise est de savoir si la comparaison avant-après reste valable. Le texte d'hier, la base de données d'aujourd'hui et une réponse convaincante ne prouvent pas que le défaut d'hier est corrigé.

Apportez un cas défaillant à une Strategy Session, avec ce que le système a vu et ce qui s'est passé, après retrait des informations sensibles. Si une partie de cette preuve manque, identifier ces lacunes constitue déjà un point de départ utile.