Idée

Une confirmation qui ne suit pas une relecture n'atteste rien

Idée principale

Un assistant à qui l'on demande d'ajouter une ligne dans un tableur répond « c'est fait ». Ce message n'atteste de rien : il dit que l'assistant a émis l'opération, pas qu'elle a abouti, ni surtout ce qui a réellement été écrit.

Pour qu'il atteste, il faut intercaler une lecture. L'ordre devient : intention, écriture, relecture de ce qui vient d'être écrit, vérification, confirmation. La confirmation ne porte plus sur l'intention mais sur l'état constaté.

La différence tient à ce que la réponse affiche : le contenu relu, et non le contenu envoyé.

Pourquoi c'est important

C'est le même défaut que l'auto-évaluation, transposé à une opération technique : on prend le compte rendu d'un acteur sur sa propre action pour une preuve de cette action.

Le remède est bon marché — une lecture ciblée, sur la seule entrée ajoutée — et il transforme la nature de ce qu'on reçoit : une affirmation devient un constat.

Nuances et limites

Pour un contenu long, la relecture intégrale n'est pas affichable. On affiche alors un résumé de ce qui a été relu, en distinguant explicitement ce résumé du contenu stocké, qui reste intégral.

Et la relecture ne couvre pas tout : elle atteste de ce qui est écrit, pas de ce qui aurait dû l'être.

Questions ouvertes

  • Que vaut la relecture quand c'est le même agent qui a écrit et qui relit ?