Quand les traces deviennent récit

Lire une trace — après Bloch. Paul Ricœur, et ce qu'une phrase ajoute aux faits qui la fondent.

Une trace peut être parfaitement exacte et rester presque muette. Elle dit qu'un événement a eu lieu : une relation a commencé, une certification a été obtenue, un fournisseur a changé. Elle ne dit pas quelle place cet événement occupe dans une histoire.

Quelque chose apparaît quand plusieurs traces sont rapprochées. Un changement de fournisseur cesse d'être un changement de fournisseur ; il devient peut-être le début d'une réorientation. Une longue période de stabilité devient rétrospectivement une époque.

Paul Ricœur appelle cette opération la mise en intrigue. Entre les traces et l'histoire qu'on en fait, il y a un travail qui ajoute ce qu'aucun document ne contenait : un ordre, une causalité, une signification. Ce travail n'est pas une falsification — sans lui, un fonds d'archives reste une pile. Mais il produit quelque chose de nouveau, et l'oublier revient à prendre pour un fait ce qui était une lecture.

Les neuf textes précédents ont porté sur les traces. Celui-ci porte sur la phrase.

Une phrase que rien ne fondait

Nos fiches d'annuaire portent une mention indiquant si l'entreprise a activé un agent conversationnel chez nous. Une phrase courte, factuelle en apparence : cet acteur n'a pas encore activé d'agent.

Elle a été affichée à tort, et le mécanisme mérite d'être raconté parce qu'il n'a rien d'exotique.

Le pilote qui lit ce genre d'information est fail-soft par défaut : sur une panne réseau, il rend une valeur nulle — exactement ce qu'il rend sur un 404. Du point de vue de l'appelant, « ce service ne répond pas » et « cet objet n'existe pas » sont devenus le même événement. La page a donc rédigé une phrase sur l'entreprise à partir d'un ECONNREFUSED.

Mesuré : 602 millisecondes par visite, sur environ 1,39 million d'adresses.

Le détail qui compte est celui-ci : il n'y avait aucune exception à attraper. Le code était correct, aucun test ne rougissait, aucun journal ne signalait rien. Le système ne s'est pas trompé dans son raisonnement ; il a raisonné juste sur une prémisse qui avait perdu son sens en chemin.

Ricœur dirait qu'on avait affaire à un récit dont la source documentaire n'existait pas — et qu'il n'y avait, dans le récit lui-même, rien qui permette de s'en apercevoir.

Trois présences, et une seule qui autorise une phrase

La correction est plus intéressante que le défaut, parce qu'elle n'est pas un try/catch.

L'information a cessé d'être un booléen. Elle est devenue une présence à trois valeurs : connue, sans objet, indisponible — sur le même axe que celui qui porte la provenance de nos autres données. Et une seule de ces trois autorise à écrire une phrase.

C'est exactement la distinction du premier volet, à un autre étage. Là-bas, « nous ne savons pas sourcer cette valeur » ne devait pas se confondre avec « cette valeur n'existe pas ». Ici, injoignable n'est pas absent. Dans les deux cas, le défaut consistait à écraser une distinction épistémique dans un type trop pauvre pour la porter.

Il y avait une seconde moitié au même défaut, et elle est instructive : les lectures étaient mises en cache, et rien n'invalidait l'entrée à l'écriture. La phrase fausse aurait donc survécu à l'activation — l'entreprise aurait branché son agent, et sa fiche aurait continué à dire qu'elle ne l'avait pas fait.

De qui la phrase parle-t-elle

Une deuxième règle est sortie de cet incident, et c'est celle que je trouve la plus juste.

L'état d'une fiche sans agent se rédige comme un fait sur la plateforme, jamais sur l'entreprise. « Cet acteur n'a pas encore activé d'agent VeraTrace » — et non « cette entreprise n'a pas d'agent », qui se lirait comme un manquement de sa part.

Les deux phrases décrivent le même état du monde. Elles ne mettent pas la même chose en intrigue. La première raconte l'histoire de notre produit, où l'adoption est en cours ; la seconde raconte l'histoire de l'entreprise, où quelque chose manque. Le fait est identique ; le récit désigne un responsable, et il le désigne par sa seule construction.

Une troisième décision est allée plus loin. Sur une fiche que personne n'a revendiquée, la mention n'est plus rédigée du tout. Bien tourner une phrase ne lui donne pas de destinataire : sur une extraction administrative nue, elle porte sur une fonctionnalité dont le visiteur n'a jamais entendu parler, et la seule personne à qui elle pourrait servir n'est pas là pour la lire.

C'est l'aboutissement de Ricœur appliqué à une interface. Un récit suppose un narrateur, un objet et un destinataire. Quand l'un des trois manque, la phrase la mieux écrite n'a rien à faire là.

Ce qui reste ouvert

Je ne veux pas laisser croire que le problème est réglé.

Nos agents savent produire des phrases générales à partir de plusieurs traces, et rien dans nos structures ne conserve encore le lien entre une phrase produite et les traces qui l'ont fondée. Un lecteur qui lirait « cette entreprise entretient des relations durables avec des producteurs locaux » ne peut pas redescendre à ce qui autorise cette affirmation, ni vérifier que quelque chose l'autorise.

Deux dettes plus lourdes sont écrites noir sur blanc dans notre documentation et bloquent la mise en production : la donnée peut porter des instructions à destination du modèle, et la question de qui paie une exécution n'est pas tranchée. La première est un problème de sécurité ; la seconde décide qui peut faire parler la plateforme.

Reste que la phrase produite par une machine à partir de plusieurs faits n'est ni vraie ni fausse au sens où l'est une donnée. C'est une hypothèse, et la question devient de savoir à quelle condition on a le droit de la formuler. C'est le sujet du dernier texte.