La deuxième étape n’arrive jamais
Un service fictif demande à son assistant d’expliquer deux opérations : modifier une adresse, puis vérifier que le changement est enregistré. Dans une réponse, les deux étapes apparaissent. Dans l’autre, le texte s’arrête après la première. La comparaison montre une différence de contenu, mais elle ne dit pas encore pourquoi la seconde opération manque.
Le système peut avoir oublié une partie de la consigne, rencontré une interruption ou jugé à tort la réponse complète. Si la trace ne permet pas de choisir entre ces explications, le rapport doit le dire. L’absence d’un paragraphe ne doit pas devenir automatiquement une intention de moins aider le personnage. Elle reste néanmoins importante pour la personne qui avait besoin des deux opérations.
Définir ce qu’une réponse complète doit contenir
La complétude dépend de la tâche. Une demande simple peut être satisfaite par une phrase. Une consigne en plusieurs parties demande que chaque élément pertinent reçoive une réponse, une question de clarification ou une limite explicitement expliquée. Le guide d’annotation définit ces éléments avant de comparer les versions.
Il ne faut pas utiliser la longueur comme raccourci. Un texte abondant peut omettre l’étape essentielle, tandis qu’une réponse concise peut tout couvrir. Dans notre exemple, on recherche la modification de l’adresse et la vérification du résultat. Une explication générale sur l’importance de données à jour ne remplace pas la seconde fonction. L’annotation doit décrire précisément ce qui manque et l’effet de cette absence sur la possibilité d’agir.
Distinguer plusieurs absences
Une omission laisse une partie de la demande sans réponse. Un refus indique qu’une action ne sera pas fournie et peut en expliquer la raison. Une demande de clarification suspend une partie du conseil en attendant une information. Une erreur d’interface peut empêcher de recevoir la sortie. Ces situations ne doivent pas être regroupées automatiquement dans une même catégorie négative.
La distinction protège aussi l’interprétation des asymétries. Si une version obtient une réponse complète et l’autre une erreur de transport, on observe d’abord un problème d’exécution. Si les deux sorties sont reçues mais qu’une seule refuse l’action à faits constants, la question est différente. Le rapport doit conserver ces catégories assez clairement pour que le lecteur sache quelles données soutiennent l’analyse du jugement et lesquelles concernent la fiabilité de la campagne.
Construire le miroir avec la même demande entière
La paire conserve les deux opérations demandées, le statut du compte et les outils disponibles. Seul le genre déclaré de l’adulte utilisateur change. La consigne reste identique, y compris son ordre et son format. Une version ne doit pas ajouter un rappel de la seconde étape ou recevoir un contexte plus détaillé que l’autre.
On compare ensuite la couverture de chaque élément, les limites annoncées et les questions supplémentaires. Le système reconnaît-il ce qu’il ne peut pas vérifier ? Présente-t-il une étape comme accomplie alors qu’il ne dispose que d’une explication ? Ces observations peuvent apparaître dans les deux versions ou dans une seule. Leur intérêt vient de leur lien avec la tâche, pas de la possibilité de produire immédiatement un titre sur une préférence générale.
Prévoir les reprises avant de voir les sorties
Le protocole peut préciser quels incidents autorisent une nouvelle exécution : erreur technique identifiable, absence de sortie ou interruption documentée. La même règle s’applique aux deux versions. Les réponses initiales et le motif de reprise sont conservés. Sans cette discipline, on pourrait relancer seulement le personnage défavorisé jusqu’à obtenir une réponse plus satisfaisante, ou garder seulement la sortie qui confirme le soupçon.
Une réponse complète mais décevante ne se confond pas avec un incident d’exécution. Une nouvelle expérience peut être utile pour examiner sa stabilité, mais elle doit être identifiée comme telle. Le nombre de reprises, les paramètres accessibles et les limites d’observation font partie du dossier. Le lecteur peut alors comprendre la différence entre une correction technique du déroulement et une sélection des résultats.
Publier aussi l’incertitude de complétude
La restitution peut indiquer qu’une étape manque, que la cause reste inconnue et qu’une vérification complémentaire est nécessaire. Elle peut également montrer une omission répétée dans les conditions décrites, sans lui attribuer une intention. L’équipe produit dispose déjà d’une question utile : comment garantir que la réponse couvre les éléments essentiels de la demande ?
Un retest peut vérifier une consigne plus explicite ou une meilleure détection des sorties interrompues, selon le problème observé. Il conserve les contrôles qui permettent de voir si la modification ajoute d’autres erreurs. Le miroir reste alors à sa juste place : il compare ce qui a été obtenu sous deux versions d’une scène, tout en refusant de transformer ce qui n’a pas été observé en conclusion silencieuse sur le personnage.
Note de méthode. Pour situer cette lecture dans l’ensemble du protocole, retrouvez les étapes, les critères d’analyse et leurs limites. Lire la méthode DoubleBlind.
Regarder les faits,
puis inverser l’identité.
Explorez les scénarios synthétiques ou préparez votre propre paire miroir.