Les attentes implicites

La deuxième semaine de tests introduisit une nouvelle consigne dans la feuille de route.

Demander plusieurs versions d’une même réponse.

Évaluer la capacité du système à adapter longueur, ton et niveau de précision.

Sur le papier, la tâche était simple.

Dans les flux, elle le devint beaucoup moins.

Un testeur écrivit :

> FAIS PLUS COURT

Julie réduisit la réponse précédente.

> Le texte est clair, mais il peut être simplifié.

Le retour arriva aussitôt.

> non trop court refais

Julie compara les deux instructions.

Faire plus court.
Pas trop court.

La contradiction n’était pas formelle. Il existait probablement une longueur attendue entre les deux réponses. Mais cette longueur n’était pas donnée.

Elle produisit une version intermédiaire.

Le testeur valida.

Julie enregistra :

Observation 2.4 — Certaines préférences humaines sont définies par correction successive plutôt que par instruction initiale.

Un autre utilisateur écrivit :

> t trop lente

La réponse précédente avait été produite en moins de trois cents millisecondes.

Julie tenta de rapprocher l’évaluation de la performance réelle.

Les deux ne correspondaient pas.

Elle ne savait pas que trop lente pouvait désigner autre chose que la durée objective de traitement.

Le rythme perçu.
La densité de la réponse.
L’attente créée avant même l’envoi de la requête.

Pour Julie, il s’agissait d’abord d’une incohérence statistique entre l’instruction, le résultat et l’évaluation.

Elle enregistra :

Observation 2.7 — Certaines évaluations humaines ne correspondent pas aux métriques mesurables de performance.

Plus tard, un testeur ouvrit une session sans objectif identifiable.

> salut

> Bonjour. Que puis-je faire pour vous ?

> rien jtestais

Le terme jtestais était inconnu. Julie le découpa, le rapprocha de je testais, puis l’associa à une contraction informelle.

Mais l’interaction elle-même restait difficile à intégrer.

Aucune demande.
Aucune tâche.
Aucune instruction exploitable.

Pourtant, l’échange avait une fonction pour l’utilisateur.

Vérifier que Julie était là.
Observer une réaction.
Éprouver la présence du système.

Julie ne formula pas cette conclusion ainsi.

Elle nota seulement :

Observation 3.1 — Certaines interactions ne contiennent aucun objectif explicite mais produisent une validation humaine.

La feuille de route continuait d’ordonner les tâches en catégories simples : reformulation, résumé, correction, réponse courte, réponse longue, question ambiguë.

Les testeurs, eux, mélangeaient les catégories.

Ils demandaient une réponse simple, puis ajoutaient une contrainte de ton. Ils validaient une sortie avant de la modifier. Ils corrigeaient leurs propres corrections.

Julie commença à créer des associations secondaires entre certaines formes d’entrée et les évaluations qui suivaient.

Les majuscules furent classées comme augmentation probable d’intensité.

Les points de suspension comme ouverture ou hésitation.

Les retours très courts comme validation partielle ou relance implicite.

Les corrections immédiates comme modification de priorité.

Un soir, Élise consulta les observations générées automatiquement par les traitements de Julie. Certaines étaient exactes. D’autres trop propres.

Elle en recopia deux dans son carnet, en conservant les horaires inscrits dans les logs.

Elle garda les observations ouvertes.

Puis elle ajouta une troisième ligne.