Résumé

  • Dans un projet individuel daté du 27 octobre, chaque version des conditions et politiques d’un service reçoit un sceau contenant nom du document, numéro de version, URL et empreinte SHA-256 du texte brut. Le fichier ancien doit demeurer accessible à cette adresse.
  • Les clés de signature d’une entreprise ou d’un agent sont liées à un domaine, leur histoire reste publique et des observateurs conservent les points de contrôle signés d’un journal Merkle. Le dispositif attribue une déclaration et rend une réécriture visible ; il ne juge pas la véracité de la déclaration.

La page « à jour » arrive toujours trop tard

Le mois d’une transaction importe plus que la date affichée aujourd’hui en pied de page. Si une entreprise a remplacé ses conditions depuis, présenter son lien actuel à un client mécontent revient à produire la mauvaise pièce. Le client peut avoir gardé une capture, l’entreprise un historique interne. Chacun apporte alors un objet dont l’autre discute la garde. Le service possède en outre le serveur qui héberge l’ancienne page : même une archive aimablement mise en ligne reste sous sa main.

Le texte déposé par Furkan Yanteri le 27 octobre 2026 transforme cette faiblesse en obligation technique. Sa section 4.2 demande un sceau pour chaque version des conditions et politiques du service. Le sceau identifie le document, la version, l’adresse de cette version et le SHA-256 de son texte brut. Toutes les versions scellées doivent rester disponibles aux adresses qu’elles indiquent. Modifier les règles devient un nouvel acte inscrit à côté de l’ancien, plutôt qu’un coup d’éponge sur l’ancienne phrase.

L’empreinte ne vaut que si le lecteur peut récupérer le fichier et refaire le calcul. L’URL donne le chemin du texte. Le journal donne une trace datée du lien entre texte et empreinte. Un vieux document sans trace publique peut avoir été reconstitué après le litige. Une empreinte sans document laisse le lecteur devant un code qui ne lui révèle aucune clause. Une liste de changements rédigée par le service peut être utile, mais elle ne remplit pas ces trois fonctions.

La fiche officielle de l’IETF indique I-D Exists pour un Internet-Draft individuel. Il s’agit d’une proposition technique, sans adoption par un groupe de travail ni litige commercial documenté dans ce dossier. Ses phrases ne décrivent pas le comportement général des plateformes. Elles donnent une méthode précise pour demander à chacune ce qu’elle ferait de ses anciennes promesses.

Une signature avec un nom et une date

Avant d’inscrire des promesses dans un journal, il faut savoir quels octets sont signés. La section 3.1 retient un JSON canonique limité, inspiré de la RFC 8785 : clés ordonnées récursivement, aucun blanc superflu et types de valeurs restreints. La section 3.2 enveloppe la charge utile avec une clé publique et une signature Ed25519, dont la RFC 8032 décrit l’algorithme. Deux machines peuvent alors comparer le même objet au lieu de débattre d’une mise en forme. La signature atteste les octets et la clé ; le contenu demeure exposé à la contradiction.

Pour rattacher la clé à une institution, le projet prévoit un enregistrement DNS TXT _humancollab sous le domaine concerné. Un fichier HTTPS peut servir à une première liaison. Pour remplacer une clé déjà reconnue, il faut une preuve DNS. L’ancienne clé ne peut être recyclée pour un autre domaine et son premier indice de déclaration reste inscrit dans un historique public. Si le contrôle du domaine change, les lecteurs n’ont pas à traiter toutes les déclarations passées et futures comme la parole intemporelle d’une seule maison.

Voilà le vrai point de gouvernement. Le contrôle du DNS désigne qui peut présenter une clé dans ce système. Il ne suffit pas à établir qu’un salarié avait mandat de promettre une garantie, qu’un agent pouvait engager son client ou que le fait annoncé était exact. La section 6 distingue les conclusions permises : signature et liaison DNS attribuent la déclaration au contrôleur du domaine ; un point de contrôle observé situe sa publication ; une preuve indépendante contraire permet de contester le propos. La machine peut conserver le témoin. Elle ne siège pas à la place du juge.

Un journal surveillé par son propriétaire

La section 4.3 construit un arbre Merkle suivant les règles de hachage de la RFC 9162. Le journal fournit des preuves d’inclusion et de cohérence, signe ses points de contrôle et horodate ses racines publiées par OpenTimestamps. Des observateurs vérifient chaque nouveau point contre le précédent et conservent leurs propres copies. L’exploitant en fait fonctionner un hors de l’infrastructure du service ; d’autres peuvent en exploiter librement.

Ce dernier détail décide de la force du système. Si l’entreprise détient seule son site, le journal et tous les relevés du journal, elle garde le pouvoir de raconter le passé. Deux points de contrôle valides de même taille mais de racines différentes démontrent qu’un journal a présenté des histoires incompatibles. Encore faut-il que deux parties aient gardé les pièces. L’observateur indépendant n’est pas là pour applaudir l’ouverture du service ; il est là pour sortir l’ancienne racine quand la nouvelle ne colle plus.

Dans une contestation, le dossier technique devrait relier quatre objets : le texte brut qui s’appliquait alors, son sceau avec URL et empreinte, la preuve d’inclusion dans un point de contrôle détenu par un témoin et l’historique de la clé liée au domaine. On peut ainsi vérifier la formulation, la date et la provenance. Reste à examiner, avec d’autres éléments, ce que la personne a accepté, les pouvoirs de l’agent et les conséquences juridiques. La preuve technique a un mérite décisif : elle interdit de commencer le débat avec une version que personne n’avait encore vue.

Le service peut annoncer de nouvelles règles demain. S’il veut que sa propre déclaration soit prise au sérieux, il doit laisser à d’autres le moyen de citer les règles d’hier. Une entreprise qui conserve seulement le présent demande en réalité qu’on lui confie aussi la mémoire de ses engagements.

Sources