Une relation a une histoire

Lire une trace — le cycle Marc Bloch, 3 sur 6. La différence entre un état et une trajectoire.

Les systèmes d'information sont bâtis pour le présent. Quelle est l'adresse de cette entreprise, quel fournisseur utilise-t-elle, ce certificat est-il encore valide. Ce sont de bonnes questions, elles suffisent à passer une commande, et elles produisent une représentation où tout ce qui existe semble pouvoir être compris à partir de maintenant.

Le volet précédent s'est arrêté sur cette limite sans la traiter. Le mécanisme qui reconstruit les partenaires d'un grossiste travaille sur une fenêtre glissante de quatre-vingt-dix jours : une relation nouée il y a douze ans et une relation nouée le mois dernier y sont rigoureusement indiscernables. Ce sont pourtant deux objets différents.

Bloch tenait le contraire pour le point de départ du métier. Une situation présente n'est presque jamais seulement présente : elle a commencé, résisté, bifurqué, remplacé quelque chose. L'idée paraît évidente pour un village ou une frontière. Elle l'est moins pour une base de données, où l'usage est d'écraser la valeur précédente sans rien conserver.

Une précision d'emblée, pour ne pas refaire un texte déjà écrit : que la durée ne soit pas un mérite, l'article consacré à North l'a établi — une relation peut durer par dépendance, par contrat ou faute d'alternative locale, et la transformer en note produirait exactement l'objet à ne pas construire. Ce texte-ci pose une question antérieure : avons-nous seulement gardé de quoi la voir ?

La date qui rajeunit tout

Il existe une manière très répandue de prétendre qu'on tient le temps, et c'est la plus trompeuse.

Une fiche affiche « dernière mise à jour : il y a deux jours ». Le lecteur en conclut que ce qu'il lit a deux jours. En réalité, un seul champ a bougé — un horaire d'ouverture, un numéro de téléphone — et la date globale vient de rajeunir d'un coup la certification qui n'a pas été revue depuis onze mois, l'effectif issu d'un millésime administratif, l'adresse reprise d'un registre à l'ouverture de la fiche.

Notre ontologie publique nomme le remède fraîcheur locale, et sa définition dit pourquoi le problème mérite un terme à lui : une date globale de mise à jour n'est pas de la fraîcheur, et c'est l'affirmation la plus trompeuse qu'un annuaire puisse produire — parce qu'elle est fausse dans le sens rassurant.

C'est la formulation qui compte. Une erreur qui inquiète se fait corriger ; une erreur qui rassure s'installe. Chaque donnée significative porte donc sa propre date de dernier contrôle réussi et sa propre péremption. C'est plus coûteux à tenir, moins net à afficher, et c'est la seule forme qui ne ment pas.

Certains états n'existent que si l'on garde le précédent

Le cycle de vie d'une donnée, chez nous, compte six valeurs : active, expirée, révoquée, remplacée, contestée, inaccessible.

Deux de ces six méritent qu'on s'y arrête, parce qu'elles sont d'une autre nature que les autres. « Remplacée » et « contestée » ne décrivent pas une donnée : elles décrivent une relation entre deux états. Une valeur remplacée suppose qu'il existe une valeur qui la remplace, et que l'ancienne soit encore là pour qu'on puisse dire laquelle. Une valeur contestée suppose qu'une observation soit venue en heurter une autre, et que les deux subsistent.

Un système qui écrase à chaque écriture ne peut pas produire ces deux états. Il n'y renonce pas par choix : ils lui sont inaccessibles. Il ne dispose que d'« actif », c'est-à-dire de la dernière chose écrite — et il l'appellera « la vérité », parce qu'il n'a rien d'autre à quoi la comparer.

C'est ici que l'historisation cesse d'être une commodité d'audit. Elle est la condition d'existence d'une partie du vocabulaire.

Fixer un moment, à la demande

Il y a une opération que les propriétaires de fiche peuvent maintenant demander : sceller l'état de leur fiche.

Nous signons alors ce que nous avons lu, à cet instant, par cette version du résolveur, et l'attestation est vérifiable publiquement. Deux décisions de conception disent ce que cette opération est et ce qu'elle n'est pas.

D'abord, elle se fait à la demande, jamais en balayage. Une passe sur l'ensemble du corpus produirait autant de signatures et d'écritures pour un lien que presque personne n'a réclamé ; ici, il n'y a d'attestation que là où quelqu'un en voulait une, et le coût suit l'usage.

Ensuite — et c'est le point que le premier volet annonçait — le sceau ne relève pas les données au statut d'attestées. Il porte un lien de preuve sur les chemins couverts, et rien de plus. Le propriétaire obtient la preuve que sa fiche disait ceci à cette date ; il n'obtient pas que ses données soient vérifiées. La distinction n'est pas rhétorique : c'est elle qui décide de ce que la fiche affiche ensuite, et le garde qui vérifie qu'aucune donnée n'est attestée reste vert après un scellement.

Un instantané atteste un fait sur notre observation, que nous sommes en droit de signer parce que nous l'avons produit. Il n'atteste pas que le monde est ainsi.

Ce que nous avons perdu une fois

Il serait malhonnête de finir sur la théorie, parce que nous avons cassé notre propre chaîne, et que l'épisode enseigne mieux que l'intention.

Ce blog revendique publiquement que l'historique de chaque article est sa chaîne de preuve — une branche par texte, un commit par version réellement écrite, y compris les versions abandonnées, qui restent visibles au lieu d'être effacées par celle qui a survécu. Cela suppose que la fusion ne réécrive pas l'historique. La consigne était écrite ; elle a été enfreinte trois fois sur trois, dont une fois alors que la demande de fusion l'annonçait en toutes lettres.

La leçon n'est pas qu'il fallait mieux se souvenir. C'est qu'une règle demandant de ne pas prendre le chemin le plus court, sur un dépôt qui fusionne en quelques minutes, sera enfreinte — il fallait un mécanisme, pas une quatrième formulation. La fusion par écrasement a donc été désactivée au niveau du dépôt, et il n'y a plus rien à retenir.

Le second incident est plus instructif encore, parce qu'il est silencieux. En changeant le format des articles, les fichiers ont été renommés et réécrits ; la similarité entre l'ancienne et la nouvelle forme a été mesurée à environ 0,1 %, quand la détection de renommage exige 50 %. Résultat : la commande qui remonte l'historique d'un fichier s'arrête à la migration sans rien signaler. Elle ne dit pas « je ne sais pas ». Elle rend un historique plus court, d'apparence parfaitement normale.

Voilà ce que ressemble une histoire perdue dans un système : pas une erreur, pas une alerte. Une réponse plausible et amputée. C'est très exactement ce que Bloch redoutait d'une archive lacunaire dont on ignore qu'elle l'est.

Conserver aujourd'hui pour pouvoir demander demain

Un registre qui se construit pendant que les événements ont lieu occupe une position particulière. L'historien travaille sur une archive constituée par d'autres, longtemps avant lui, et fait avec ses trous. Nous décidons des nôtres en ce moment même, à chaque écriture.

Cela ne se traduit pas par une injonction à tout garder — un registre qui conserverait tout garderait aussi ce que les gens ont le droit de voir disparaître, et le volet précédent a dit qu'une donnée dérivée n'appartient pas à celui qui la déduit. Cela se traduit par une question à poser avant chaque écrasement : cette valeur que je remplace, quelqu'un pourrait-il légitimement vouloir la retrouver ?

Le plus souvent la réponse est non, et l'écrasement est le bon geste. Quand elle est oui, garder coûte peu aujourd'hui et devient impossible demain.

Reste un problème que ces trois volets ont contourné. Nous avons parlé de provenance, de traces involontaires, d'états et de dates — en supposant à chaque fois que les mots servant à nommer tout cela allaient de soi. « Producteur », « fournisseur », « relation », « local » : ce sont des décisions, pas des propriétés du monde. C'est le sujet du prochain texte.