De la trace immuable à la preuve opposable

Une trace n'est pas une preuve#

Presque tous les systèmes journalisent. Presque aucun ne produit des preuves. La différence n'apparaît qu'au moment où quelqu'un a intérêt à contester ce que dit le journal — un litige, un contrôle, une enquête interne.

Posons la question autrement. Votre journal résiste-t-il à trois attaques ?

La suppression. Quelqu'un retire la ligne gênante. Un journal ordinaire n'en garde aucune trace : il ne sait pas ce qu'il ne contient plus.

La réécriture. Quelqu'un modifie une valeur — un montant, une décision, une identité. Un journal ordinaire ne distingue pas une ligne écrite hier d'une ligne réécrite ce matin.

L'antidatage. Quelqu'un ajoute une entrée en lui donnant une date passée. C'est l'attaque la plus dangereuse, parce qu'elle fabrique une preuve au lieu d'en détruire une — et parce qu'elle est triviale quand l'horloge appartient à celui qui journalise.

Un journal qui ne résiste pas à ces trois attaques n'est pas une preuve : c'est une déclaration de son propriétaire. Devant un auditeur ou un juge, elle a le poids d'un témoignage intéressé. Ce qui suit décrit les cinq niveaux qui transforment progressivement l'un en l'autre — et le coût de chacun.

Niveau 1 — Le chaînage par empreintes#

Le premier niveau est simple et souvent suffisant en interne : chaque entrée porte l'empreinte de la précédente. Le journal devient une chaîne, et modifier une ligne casse tout ce qui suit.

Ce que cela arrête : la modification discrète d'une entrée isolée, le retrait d'une ligne au milieu. La vérification est immédiate — on recalcule la chaîne, et l'écart apparaît à l'endroit exact de l'altération.

Ce que cela n'arrête pas, et il faut le dire clairement : celui qui détient le journal peut le recalculer entièrement. Rien ne l'empêche de reconstruire une chaîne cohérente à partir d'un contenu modifié. Le chaînage protège contre l'altération opportuniste, pas contre le propriétaire lui-même. Or c'est précisément le propriétaire dont l'auditeur veut se passer.

Niveau 2 — L'arbre et la tête signée#

Le deuxième niveau emprunte à un mécanisme éprouvé depuis plus d'une décennie sur les certificats du web : le journal en ajout seul, avec un arbre de hachage entretenu à chaque insertion.

À chaque ajout, la racine de l'arbre est recalculée, puis signée par l'opérateur du journal. Cette racine signée — la « tête » du journal — est une déclaration engageante : « à cet instant, mon journal contenait exactement ces entrées ». Elle est publiable, et c'est ce qui change tout : deux mécanismes de preuve en découlent, tous deux vérifiables sans télécharger le journal entier.

La preuve d'inclusion démontre qu'une entrée précise appartient bien à l'arbre correspondant à une tête donnée. Un tiers vérifie que sa ligne est dans le journal sans obtenir les lignes des autres — ce qui compte quand le journal contient les décisions de plusieurs clients.

La preuve de cohérence démontre qu'entre deux têtes successives, le journal n'a fait que croître : aucune entrée retirée, aucune réordonnée. C'est la propriété décisive. Elle interdit la réécriture globale que le niveau 1 laissait passer, à une condition : que les têtes intermédiaires aient été publiées et conservées par quelqu'un d'autre que l'opérateur.

D'où la question qui commande la suite : qui garde les têtes ?

Niveau 3 — L'ancrage externe#

Tant que les têtes signées restent chez l'opérateur, un doute demeure : rien n'interdit de fabriquer, après coup, une histoire cohérente et de ne publier que celle-là. Le chaînage et l'arbre garantissent la cohérence interne, pas l'absence de réécriture totale.

La réponse est de faire sortir la preuve du périmètre de l'opérateur. Chaque tête signée est déposée dans des systèmes externes indépendants, dont personne chez nous ne contrôle l'historique. Trois familles sont utilisables, et notre règle de production est d'en satisfaire au moins deux sur trois simultanément.

Un registre de transparence public : le mécanisme éprouvé du monde de la signature logicielle, où les entrées sont publiques et surveillées par des tiers.

Une chaîne de blocs publique : l'empreinte de la tête est inscrite dans une transaction. Ce qui est déposé n'est pas le contenu — seulement une empreinte, donc aucune donnée ne fuit — mais l'inscription est datée par un réseau que nous ne contrôlons pas.

Une autorité d'horodatage : le mécanisme classique de l'horodatage tiers, normalisé et déjà reconnu dans les pratiques d'archivage légal.

Chaque dépôt produit un reçu d'ancrage — identifiant de transaction, hauteur de bloc, horodatage — vérifiable indépendamment. C'est ce reçu qui ferme la troisième attaque : l'antidatage devient impossible, puisque la date ne vient plus de notre horloge. Pour antidater une entrée, il faudrait réécrire l'histoire de deux systèmes publics indépendants.

Une remarque sur le « deux sur trois ». Ce n'est pas une précaution décorative : un ancrage unique crée une dépendance à la disponibilité et à la longévité d'un service tiers. Deux ancrages indépendants font qu'une preuve survit à la disparition de l'un d'eux — et une preuve dont la validité dépend d'un service qui peut fermer n'est pas une preuve durable.

Niveau 4 — L'attestation matérielle#

Les trois premiers niveaux prouvent ce qui a été enregistré. Ils ne prouvent pas ce qui a réellement tourné. Un journal parfaitement ancré peut décrire l'exécution d'un binaire qui n'est pas celui qu'on croit.

Le quatrième niveau descend donc jusqu'au matériel. Une attestation produite par un environnement d'exécution isolé contient une mesure du binaire effectivement chargé, un champ qui lie cette attestation à l'artefact — l'empreinte du paquet exécuté —, un horodatage, une chaîne de confiance remontant à une clé publique matérielle, et la signature du fournisseur de l'environnement.

Ce que cela ajoute est considérable : on peut démontrer que cet artefact précis a été exécuté par ce binaire précis, sur une machine dont l'intégrité est attestée par son fabricant. La liaison entre l'attestation et l'empreinte de l'artefact est le détail qui fait la différence — sans elle, on prouverait seulement qu'un environnement sain a tourné, sans savoir ce qu'il exécutait.

C'est le niveau le plus contraignant en exploitation, et il ne se justifie pas partout. Il devient nécessaire quand l'exécution elle-même est l'objet du litige : traitement de données classifiées, calcul dont le résultat engage des tiers, environnement mutualisé où le client doit se protéger de son hébergeur.

Niveau 5 — L'horizon de preuve#

Reste une question que la cryptographie appliquée pose rarement à voix haute : combien de temps cette preuve vaudra-t-elle ?

Une signature vaut ce que vaut l'hypothèse mathématique sur laquelle elle repose. Les signatures sur courbes elliptiques utilisées aujourd'hui sont solides et le resteront face aux calculateurs classiques ; elles sont, en théorie, vulnérables à un calculateur quantique de taille suffisante. Personne ne sait quand — et c'est exactement le problème, car une preuve doit être opposable au moment du litige, qui peut survenir dans dix ans.

Notre réponse est la double signature : chaque charge est signée avec un schéma classique et avec un schéma post-quantique fondé sur les réseaux euclidiens. La vérification exige les deux. Le coût est réel et assumé : des signatures plus lourdes, un peu plus de calcul, une complexité supplémentaire dans le vérificateur.

Le raisonnement est celui de l'archivage légal, pas celui du logiciel. Migrer un parc d'artefacts déjà scellés vers une nouvelle famille cryptographique est extraordinairement coûteux, parfois impossible — les signatures existantes ne se refont pas. Payer maintenant le surcoût de la double signature, c'est acheter la validité future de preuves qu'on ne pourra pas refaire.

Souveraineté : où vivent les clés#

Tout ce qui précède repose sur des signatures. Une signature repose sur une clé privée. La question de la souveraineté se ramène donc à une question très concrète : qui peut signer, et que suffit-il de compromettre pour signer à sa place ?

Dans l'architecture la plus répandue, la réponse est décourageante : une clé, un module matériel, un administrateur. Compromettre ce point unique suffit à produire des artefacts authentiques et des journaux cohérents. Toute la construction probante s'écroule sur un seul secret.

Nous utilisons donc, pour les régimes de scellement les plus engageants, des signatures à seuil : la clé n'existe jamais en un seul endroit. Elle est répartie en parts distribuées lors d'une cérémonie initiale menée hors ligne, et la production d'une signature exige la participation d'un nombre minimal de porteurs. Compromettre un module matériel ne permet plus de signer — il faut une collusion.

Trois propriétés rendent ce mécanisme utilisable en pratique. Les parts ne sont jamais réunies : le protocole procède par échanges en deux tours, chaque porteur ne produisant qu'une contribution partielle. La cérémonie initiale se tient une seule fois, hors ligne, ce qui limite l'exposition au moment le plus sensible. Et surtout, la signature finale est indistinguable d'une signature ordinaire : n'importe quel vérificateur standard la contrôle sans rien savoir du dispositif à seuil qui l'a produite.

Cette dernière propriété est ce qui rend l'ensemble déployable. Une garantie de sécurité qui exigerait un vérificateur spécial ne serait vérifiable que par ceux qui possèdent notre outillage — c'est-à-dire par personne d'utile. Ici, la complexité reste du côté de celui qui signe, et la vérification reste universelle.

Le cas des environnements coupés du réseau#

Un lecteur attentif aura relevé une tension : nous exigeons un ancrage sur des systèmes externes, et nous revendiquons de fonctionner dans des environnements sans aucune connexion. Comment ancrer sans réseau ?

La réponse est le dépôt différé. Dans un environnement isolé, le journal est chaîné et ses têtes sont signées localement, sur un support en écriture unique. Les têtes accumulées sont ensuite exportées sur média physique et déposées auprès des systèmes externes depuis une machine connectée. La preuve est complète, avec une précision temporelle dégradée : la date attestée est celle du dépôt, pas celle de l'écriture.

C'est un arbitrage explicite, et il faut le formuler comme tel : dans un environnement coupé du monde, on échange de la précision de datation contre l'isolement. Ce qui reste intact, c'est l'ordre des événements et l'intégrité de la chaîne — l'antidatage devient impossible dès le premier dépôt, pour tout ce qui le précède.

Symétriquement, les artefacts entrent dans ces environnements sous forme de paquets signés remis sur média physique, dont la signature se vérifie sans réseau. Les racines de confiance utilisées pour cette vérification sont conservées dans un module matériel. C'est l'illustration la plus nette de l'intérêt du format : le même artefact, la même vérification, dans un lieu où aucun service en ligne n'est joignable.

La règle du non-stub silencieux#

Un principe d'ingénierie mérite d'être exposé, parce qu'il a plus d'effet sur la fiabilité réelle que n'importe quel choix d'algorithme.

Tous ces mécanismes ont des versions de développement : un ancrage simulé, une attestation factice, un horodatage local. Elles sont indispensables pour tester sans dépendre de systèmes externes. Elles sont aussi le plus grand danger de l'édifice, car un simulateur silencieux produit des objets qui ressemblent à des preuves.

Notre règle est donc catégorique : un composant simulé refuse de démarrer en production. Pas un avertissement dans les journaux, pas une mention dans la documentation — un refus d'exécution. Le raisonnement est asymétrique. Un refus au démarrage coûte une alerte et dix minutes de correction. Un simulateur oublié coûte la découverte, le jour d'un litige, que le dossier de preuve est vide. Ce sont deux ordres de grandeur différents.

C'est l'illustration d'une règle plus générale : un mécanisme de repli qui fonctionne trop bien masque exactement le défaut qu'il est censé gérer. En matière de preuve, l'échec doit être bruyant.

Ce qu'un tiers peut vérifier#

Le test de tout cet édifice est simple : que peut faire un auditeur avec le dossier, sans accès à nos systèmes et sans nous croire ?

Il recalcule la chaîne du journal, et constate que rien n'a été retiré ni modifié. Il vérifie la preuve d'inclusion de chaque entrée qui l'intéresse. Il vérifie la preuve de cohérence entre les têtes signées, et constate que le journal n'a fait que croître. Il contrôle les reçus d'ancrage auprès des systèmes externes eux-mêmes, ce qui date les têtes indépendamment de nous. Il valide l'attestation matérielle quand elle est présente, et constate que l'artefact exécuté est celui du dossier. Il contrôle enfin les deux signatures de chaque charge.

À aucun moment il n'a besoin d'un compte, d'une autorisation, ni de notre coopération. C'est la seule définition utile de l'opposabilité : une preuve qui exige la bonne volonté de celui qu'elle accuse n'en est pas une.

Ce que cela ne prouve pas#

Il faut être précis sur les limites, parce qu'un excès de promesse en matière de preuve se retourne toujours contre celui qui le formule.

Cette architecture prouve l'intégrité et la chronologie : ce qui a été enregistré, quand, par qui, avec quelles entrées, sous quelles règles, avec quel binaire. Elle ne prouve pas que la décision était bonne. Elle ne prouve pas que les données d'entrée étaient exactes — si une source mentait, le journal enregistre fidèlement un mensonge. Elle ne prouve pas l'absence d'un comportement non journalisé, seulement que ce qui l'a été n'a pas bougé.

Autrement dit, elle déplace le débat au bon endroit. Sans elle, la discussion porte sur ce qui s'est passé et devient un affrontement de récits. Avec elle, ce point est établi, et la discussion porte sur le fond : la décision était-elle raisonnable au vu de ce qui était connu ? C'est une conversation infiniment plus productive — et c'est celle qu'un dirigeant veut avoir.

Questions fréquentes#

Quelle est la différence entre une trace et une preuve ?#

Une trace enregistre ; une preuve résiste. La trace suffit pour comprendre un incident quand tout le monde est de bonne foi. La preuve est ce qui reste quand quelqu'un a intérêt à contester : elle doit résister au retrait d'une ligne, à la réécriture de l'ensemble et à l'antidatage. Techniquement, cela signifie un chaînage, un arbre de hachage avec tête signée, et un ancrage hors du périmètre de celui qui journalise. Sans le dernier point, on reste dans la déclaration.

Faut-il une chaîne de blocs pour prouver quelque chose ?#

Non, et c'est un malentendu répandu. La chaîne de blocs n'est utilisée ici que pour une chose très précise : publier une empreinte à une date que nous ne contrôlons pas. Rien du contenu n'y est écrit, aucune donnée ne circule, aucun jeton n'est nécessaire. Une autorité d'horodatage classique ou un registre de transparence public rendent le même service. L'important n'est pas la technologie du tiers, c'est son indépendance — et le fait d'en avoir plusieurs.

Combien de temps une preuve reste-t-elle valable ?#

Aussi longtemps que les hypothèses cryptographiques qui la fondent. C'est pourquoi nous signons chaque charge deux fois, avec un schéma classique et un schéma post-quantique : si l'une des deux familles cède, la preuve tient encore. Pour un artefact conservé dix ans — un contrat, une décision engageante, un actif cédé — cette précaution est du même ordre que le choix d'un support d'archivage : on ne la prend pas au moment où on en a besoin.

Ces mécanismes ralentissent-ils le système ?#

Le chaînage et l'arbre de hachage sont négligeables : quelques calculs d'empreinte par entrée. L'ancrage externe, lui, est asynchrone par nature — on ne bloque pas une exécution en attendant la confirmation d'un réseau public. En pratique, les têtes sont déposées par lots, à intervalle régulier, ce qui borne la précision temporelle de la preuve à cet intervalle. C'est le seul arbitrage réel : une fréquence d'ancrage plus élevée coûte plus cher et resserre la datation.

L'attestation matérielle est-elle indispensable ?#

Non, dans la plupart des cas. Elle répond à une menace précise : celle où l'exécution elle-même est contestée, ou bien où le client doit se protéger de son propre hébergeur. Pour un usage interne où l'infrastructure est de confiance, les trois premiers niveaux suffisent et sont déjà très au-dessus de la pratique courante. La règle est de calibrer le niveau de preuve sur la nature du litige redouté, pas sur l'envie d'afficher une technologie.

Peut-on ajouter ces garanties à un système existant ?#

Partiellement, et il faut être honnête sur ce qui ne se rattrape pas. On peut instrumenter dès aujourd'hui : chaîner les nouvelles entrées, signer les têtes, ancrer à l'extérieur. Ce qui ne se reconstitue jamais, c'est le passé : les journaux déjà écrits sans chaînage ni ancrage restent des déclarations, quoi qu'on fasse. La date de mise en place devient donc la date de début de votre capacité probante — raison suffisante pour ne pas la reporter.

À retenir#

Cinq niveaux, chacun fermant une attaque précise. Le chaînage empêche l'altération d'une ligne. L'arbre et la tête signée permettent de prouver l'inclusion et la croissance du journal. L'ancrage externe supprime la dépendance à notre horloge et à notre bonne foi. L'attestation matérielle lie l'exécution à l'artefact. La double signature donne à l'ensemble un horizon de validité qui dépasse la mode cryptographique du moment.

Le but n'est pas de collectionner les mécanismes : c'est d'atteindre un état précis, où plus rien ne repose sur la confiance qu'on nous accorde. Un auditeur, un juge, un acquéreur ou un concurrent doit pouvoir vérifier seul. Tant qu'il faut nous croire, il n'y a pas de preuve.

Pour la suite : l'architecture institutionnelle qui porte ces registres, et ce que le règlement européen attend en matière d'enregistrements.