Résumé

  • Cent reçus peuvent être authentiques et la cent-unième opération manquer au dossier. Le projet individuel WEXP Coverage de Mikhail Sergeev, daté du 23 octobre 2026, oblige l'auditeur à examiner qui contrôlait l'entrée des opérations dans le registre.
  • Son exemple PostgreSQL ferme un lot d'écritures validées. Le lecteur peut alors demander qui a accepté la règle selon laquelle aucune écriture ne pouvait passer par une porte dérobée.

Le certificat du dossier vide

Un responsable promet que son registre montre toutes les opérations. Il remet cent reçus signés ; les cent passent le contrôle. Puis quelqu'un découvre une opération effectuée par un accès réservé à l'administrateur, avant l'enregistrement. Cette scène est hypothétique, mais la question qu'elle pose est immédiate : qui avait le pouvoir de garder une opération hors du dossier ? Voilà le ressort du projet WEXP Coverage publié le 23 octobre par Mikhail Sergeev.

Le texte demande d'abord ce qui devait entrer dans le registre, à quel moment le lot a été fermé et quel chemin chaque opération devait suivre. Il demande ensuite de nommer la personne autorisée à croire ce chemin sans vérification directe. Un sceau sur le fichier remis ne règle aucune de ces questions. Le client peut au moins voir la décision de confiance qu'on lui propose de prendre.

Le Datatracker de l'IETF classe ce texte parmi les Internet-Drafts individuels actifs, sans flux RFC. Nous lisons une proposition précise, pas une norme adoptée ni le compte rendu d'un système en production. Ses contraintes montrent néanmoins où se loge le pouvoir dans un audit : dans la définition de ce qui compte comme action et dans la confiance accordée au dispositif qui les recueille.

Le registre n'est pas le monde

On peut suivre l'histoire d'une seule opération avant d'apprendre les lettres du modèle. Elle a eu lieu : c'est l'action, appelée A. Le système a peut-être créé son reçu final, dans le groupe C. Ce reçu a peut-être atteint son destinataire, dans R. L'auditeur ne voit que les extraits qu'on lui remet, Cv et Rv, et le relevé d'origine S. Si l'opération a contourné ce relevé, l'auditeur peut lire toutes les pages disponibles sans la rencontrer. Voilà pourquoi l'authenticité de S ne démontre pas qu'il contient toutes les actions.

Ce découpage évite plusieurs tours de passe-passe. Une requête annulée peut ne pas être une action ; une écriture validée suivie d'une réponse perdue en est une dans un système qui définit l'action par la validation. Le renvoi du même reçu n'en crée pas un second. Un reçu créé et non reçu révèle un défaut de livraison, tandis qu'une action sans reçu révèle un défaut de création. La règle de comptage doit venir du dispositif déclaré, jamais de la colonne la plus facile à additionner.

Le projet donne des noms différents aux conclusions différentes. creation-complete exige un reçu pour chaque action ; creation-sound exige qu'un reçu corresponde à une action ; creation-exact exige la correspondance un à un. La livraison, la source et la concordance des seules vues fournies ont leurs propres catégories. empty-actions est une affirmation distincte. Dix identifiants de revendication empêchent qu'un seul mot, « complet », soit étiré jusqu'à couvrir les trous.

Imaginons deux exports identiques, l'un de la source, l'autre des reçus. Leur égalité peut être établie avec rigueur. Si les deux omettent la même écriture, cette rigueur ne résout rien. Le projet interdit de transformer une requête source échouée en tableau vide. Il distingue le silence d'une source effectivement lue et le silence d'une source indisponible. Un cachet sur un tableau vide authentifie le tableau ; il ne ressuscite pas la requête qui a échoué.

L'hypothèse qui signe la conclusion

Dans WEXP Coverage, une prémisse peut être vérifiée, admise par hypothèse, inconnue ou réfutée. Une hypothèse admise doit indiquer la règle qui l'autorise, l'autorité qui a adopté cette règle, son motif et son périmètre. La formule « la capture est complète » ne peut pas servir de prémisse à elle-même. Il faut décrire les chemins d'écriture, les étapes de vie de l'action, les contournements possibles et les contrôles chargés de les fermer.

Cette exigence touche le gouvernement de l'infrastructure. Un administrateur privilégié peut modifier la source ; un reçu peut être émis hors registre ; une restauration ou une bifurcation peut présenter une seule histoire parmi plusieurs. Le projet souligne que deux sceaux concordants, deux organisations ou deux clés différentes ne prouvent pas à eux seuls la capture de toutes les actions. La séparation des pouvoirs est une propriété réelle des personnes et des systèmes, pas un effet visuel de la cryptographie.

Un cas construit par l'auteur va plus loin. Une conclusion positive repose sur une hypothèse de capture acceptée. Un contre-exemple utilisable montre pourtant une action omise. L'évaluateur doit conserver les deux raisonnements et rendre not-established avec conflit. Une nouvelle politique ne peut pas escamoter le contre-exemple. C'est la phrase la plus politique du dispositif : l'autorité qui accepte une hypothèse ne reçoit pas le droit d'effacer les faits qui la contredisent.

Trois fermetures, une frontière

L'exemple pg-ledger/0.2.0 se garde de promettre l'univers. Il définit l'action comme l'ajout validé d'une ligne dans un registre nommé, au sein d'un lot PostgreSQL 18 à primaire unique. Une opération commerciale extérieure, un transfert de fonds ou une livraison matérielle demanderaient un lien supplémentaire. L'action étudiée ici est l'écriture validée, point.

Chaque ajout et chaque sceau verrouille la même ligne d'époque. Trois barrières validées ferment successivement les actions, la création des reçus et leur admission par le destinataire. La finalisation des reçus attend la première fermeture ; la publication et l'admission attendent la deuxième. Une lecture complète après les trois barrières peut alimenter les vues de source, de finalisation et de réception. Les numéros de séquence et les horodatages ne suffisent pas à prouver l'ordre des validations. Les tentatives doublées et les variantes contradictoires restent consultables.

Cette mécanique donne au mot « toutes » un sens opératoire dans un périmètre étroit. Elle dépend aussi d'une liste franche : fonctionnement correct de PostgreSQL et de l'hôte, stockage intact, rôles séparés, absence de contournement ou d'émission anticipée, export authentifié et complet, clés et politique stables. Un administrateur tout-puissant, une restauration, une bifurcation ou un reçu émis hors livre peuvent renverser ces prémisses. Le cachet du registre ne contrôle pas celui qui tient la presse.

Le brouillon compagnon WEXP Core évalue des affirmations de contenu pour des actions déterminées. Coverage porte sur la population. Le projet donne un exemple logique de 99 évaluations individuelles valides et d'un centième acte établi sans reçu, dans une population fermée de 100. Les 99 résultats gardent leur valeur locale. Il faut une preuve positive de l'appartenance du centième acte et une recherche négative suffisamment exhaustive pour établir le manque ; compter 99 ne suffit pas. Ce sont des cas construits, pas des statistiques d'exploitation.

Sources