Documents à preuve d'altération : patrons et compromis

Pour rendre un document à preuve d’altération, hachez-le avec un algorithme moderne comme SHA-256 et placez ce condensé quelque part que le dépositaire du document ne peut pas réécrire en douce : dans une signature numérique, dans un jeton d’horodatage RFC 3161, dans un journal en ajout seul chaîné par hachage, dans une base de données registre, ou ancré sur une blockchain publique. Toute altération change alors l’empreinte et brise la vérification, de sorte que la modification devient détectable plutôt qu’impossible. Les patrons diffèrent par la classe d’altération qu’ils attrapent, par qui peut vérifier et par leur coût d’exploitation; la plupart des systèmes de production en superposent deux.

Cette page parcourt les cinq patrons par ordre de force croissante, avec les modes de défaillance que chacun ferme réellement. Pour le contexte plus large de ce qu’est la provenance et de quand vous avez besoin de tout cela, commencez par le carrefour de la provenance documentaire.

D’abord, soyez précis sur la menace

« À preuve d’altération » est une propriété face à un adversaire précis. Avant de choisir un patron, nommez le vôtre :

L’attaquant externe qui pénètre le stockage et modifie les fichiers.
L’initié avec un accès en écriture légitime, y compris les DBA et les administrateurs infonuagiques.
L’exploitant lui-même : votre propre organisation, quand le vérificateur est une contrepartie, un tribunal ou un régulateur qui n’a aucune raison de vous croire sur parole.
La falsification temporelle : quelqu’un avec des clés valides qui crée un document aujourd’hui et prétend qu’il existait l’an dernier.

Les patrons plus faibles gèrent le premier cas; seuls les témoins externes gèrent les deux derniers. Une quantité étonnante de marketing de « registre immuable » vend la protection du patron 1 en laissant entendre celle du patron 5. Gardez la distinction en vue; rien ci-dessous n’est inviolable, tout est à preuve d’altération, c’est-à-dire que la modification est détectable par un vérificateur qui exécute les contrôles.

Patron 1 : hacher et stocker le condensé séparément

Calculez SHA-256 (selon le FIPS 180-4 du NIST) sur les octets du document et stockez le condensé dans un domaine de confiance différent de celui du document : une base de données distincte avec des identifiants différents, un stockage objet WORM (écriture unique) ou un registre imprimé. La vérification consiste à recalculer l’empreinte et à comparer.

C’est la preuve d’altération la moins chère possible et elle est réellement utile, mais sa force est exactement l’indépendance du dépôt de condensés. Même base de données, même admin, même chaîne de sauvegarde : aucune protection. Elle ne prouve rien non plus sur le temps ou la paternité par elle-même.

Deux détails d’implémentation causent la plupart des échecs réels. La canonicalisation : vous devez définir exactement quels octets sont hachés. Un PDF réenregistré par un visualiseur, un objet JSON aux clés réordonnées ou un DOCX aux métadonnées mises à jour produiront une nouvelle empreinte sans aucun changement significatif. Hachez l’artefact stocké octet pour octet et ne le régénérez jamais, ou définissez une sérialisation déterministe pour les données structurées et testez-la de façon adversariale. La durée de vie de l’algorithme : le NIST a retiré SHA-1 après des attaques par collision praticables; les dossiers qui doivent rester convaincants pendant des décennies devraient consigner l’algorithme utilisé et être rehachés avec des algorithmes plus récents avant que l’ancien faiblisse.

Patron 2 : les signatures numériques

Une signature numérique chiffre l’empreinte du document avec une clé privée, liant une identité (via un certificat X.509) aux octets exacts. L’altération devient alors détectable par quiconque possède le certificat public, pas seulement par le détenteur du registre de condensés, et vous obtenez en plus l’origine : la preuve de qui s’est engagé sur le contenu. Les signatures PDF, les signatures XML et S/MIME sont les conteneurs standards, et des cadres comme le règlement eIDAS de l’UE leur attachent des effets juridiques gradués.

Ce que les signatures ne vous donnent pas :

Le temps. Une signature porte une heure de signature déclarée, réglée par l’horloge du signataire. Un signataire, ou quiconque vole la clé plus tard, peut antidater à volonté. Correctif : contresigner avec un horodatage (patron 3).
La longévité gratuite. Les certificats expirent et se font révoquer. Vérifier une signature vieille de 12 ans exige la chaîne de certificats et les données de révocation telles qu’elles existaient alors, ce qui explique pourquoi les profils de validation à long terme intègrent ce matériel plus des horodatages d’archivage dans le document. Si vous sautez cette étape, vos signatures pourrissent.
L’historique. Une signature couvre une version. Elle ne dit rien des autres versions existantes ni de laquelle est venue en premier.

La gestion de clés est le coût d’exploitation : HSM ou KMS infonuagique pour les clés privées, rotation et un plan de révocation. Une clé de signature qui fuit convertit silencieusement votre preuve d’altération en trousse de falsification pour l’attaquant, ce qui est pire que de ne rien avoir.

Patron 3 : l’horodatage de confiance (RFC 3161)

Une autorité d’horodatage (TSA) conforme à la RFC 3161 est un service requête-réponse : vous envoyez l’empreinte de vos données (jamais les données elles-mêmes, donc le contenu reste privé), et la TSA retourne un jeton d’horodatage signé liant cette empreinte à une heure tirée de son horloge auditée. Le jeton prouve que le document existait à ce moment ou avant, indépendamment de vos horloges et de vos clés. La RFC 3161 note explicitement l’usage canonique : vérifier qu’une signature a été apposée avant que le certificat correspondant soit révoqué, ce qui permet aux vieilles signatures de rester valides.

En vertu de l’article 41 d’eIDAS, un horodatage électronique qualifié provenant d’un fournisseur inscrit dans l’UE porte une présomption légale d’exactitude de sa date et de son heure et d’intégrité des données liées, reconnue dans chaque État membre. En pratique, les appels TSA coûtent de fractions de cent à quelques cents, répondent en moins d’une seconde et s’intègrent aux chaînes de signature comme contresignature.

Le compromis est un tiers de confiance. Vous faites confiance à l’horloge et à la clé de la TSA, et vous avez besoin que sa chaîne de certificats reste vérifiable pour votre horizon de rétention. Pour une TSA disparue, les jetons peuvent devenir difficiles à valider; les mesures d’atténuation sont le réhorodatage périodique avec une TSA fraîche et l’utilisation de plus d’une. Quand aucune autorité n’est acceptable pour toutes les parties, ou que vous voulez des preuves sans dépendance à la survie d’aucun fournisseur, c’est le vide précis que comble la notarisation blockchain.

Patron 4 : chaînes de hachage et journaux en ajout seul

Les patrons 1-3 protègent des documents individuels. Les flux de travail ont besoin d’un historique protégé : la séquence des versions, des approbations et des accès. L’outil est une chaîne de hachage : chaque entrée du journal inclut l’empreinte de l’entrée précédente, de sorte que réécrire une entrée passée brise chaque maillon subséquent. C’est la construction que Haber et Stornetta ont proposée en 1991 pour les services d’horodatage, et c’est la colonne vertébrale de tout système de transparence moderne.

La version de calibre industriel est le journal en arbre de Merkle de Certificate Transparency (spécification actuelle : RFC 9162) : les entrées sont les feuilles d’un arbre en croissance continue, et le journal peut produire des preuves compactes qu’une entrée est incluse et que le journal d’aujourd’hui est un sur-ensemble strict de celui d’hier. Si le journal montre des historiques différents à des personnes différentes, la comparaison des racines d’arbre l’expose. Trillian de Google implémente cela comme service réutilisable, et Rekor de Sigstore l’exploite en production pour les métadonnées de la chaîne d’approvisionnement logicielle. La même conception se transpose directement aux événements documentaires.

Deux propriétés méritent l’attention :

Un journal chaîné seul détecte la réécriture, pas la troncature ni la bifurcation. L’exploitant peut encore couper la queue, ou maintenir deux versions et montrer à chaque auditeur une version différente (une « vue divisée »). La contre-mesure est de publier l’empreinte racine courante à des endroits que l’exploitant ne contrôle pas : aux parties elles-mêmes, à des témoins indépendants ou à une ancre externe (patron 5). Les preuves de cohérence épinglent alors chaque racine publiée à un seul historique.
Les entrées ne valent que ce que vous y mettez. Journalisez l’empreinte du document, l’acteur, l’action et l’heure; signez les entrées si les acteurs ont des clés. Des déchets en entrée donnent des déchets immuablement préservés en sortie.

Les bases de données registre emballent ce patron derrière du SQL. Les tables de registre (ledger) d’Azure SQL et de SQL Server chaînent par hachage les versions de lignes en condensés de base de données que vous stockez dans un stockage immuable, rendant l’altération par quiconque, y compris les DBA et les opérateurs infonuagiques, détectable par des requêtes de vérification. Un contrepoint de mise en garde : la base de données registre spécialisée QLDB d’AWS a été abandonnée, avec fin du soutien le 31 juillet 2025. Préférez des conceptions dont la preuve (empreintes, condensés, preuves standards) est portable au-delà de tout produit unique.

Patron 5 : l’ancrage externe

Tout ce qui précède peut être renforcé par un seul geste : prendre périodiquement le condensé courant de votre système (une empreinte de document, une racine de Merkle d’un journal, un condensé de base de données) et le confier à un témoin hors de votre contrôle. Les options, par indépendance croissante :

Envoyer le condensé aux contreparties elles-mêmes (le courriel est un témoin étonnamment efficace).
L’horodater auprès d’une ou plusieurs TSA RFC 3161.
L’ancrer sur une blockchain publique, par exemple via OpenTimestamps, qui agrège un nombre illimité de condensés dans un arbre de Merkle et n’engage qu’une racine par transaction Bitcoin.

L’ancrage convertit « faites confiance à notre journal » en « vérifiez l’ancre », et c’est le seul patron qui traite pleinement les menaces de l’exploitant-adversaire et de la falsification temporelle. Il est couvert en profondeur, y compris quand il n’en vaut pas la peine, dans la notarisation blockchain.

Choisir : le tableau comparatif

Patron	Altération détectée	Qui peut vérifier	Prouve le temps?	Coût/effort typique	Point faible
Empreinte + dépôt de condensés séparé	Modifications des documents stockés	Quiconque fait confiance au dépôt de condensés	Non	Trivial	Le dépôt de condensés partage le sort des documents s’il n’est pas isolé
Signature numérique	Tout changement après signature; falsifier l’origine impossible sans la clé	Quiconque possède la chaîne de certificats	Heure déclarée par le signataire seulement	Modéré (PKI, gestion de clés)	Antidatage; expiration des certificats sans LTV
Horodatage RFC 3161	Tout changement après estampillage; antidatage	Quiconque possède le certificat de la TSA	Oui (tiers de confiance)	Faible (quelques cents par jeton)	Confiance et longévité de la TSA
Journal chaîné / Merkle, base registre	Réécriture de l’historique, y compris par des initiés	Auditeurs détenant des racines passées	Ordonne les événements; heure murale seulement telle que journalisée	Modéré (infra, procédures)	Troncature et vues divisées sans racines externes
Ancrage blockchain	Tout ce qui précède, y compris l’exploitant falsifiant son propre passé	N’importe qui, de façon indépendante, indéfiniment	Oui (heure de bloc, granularité d’environ une heure)	Faible par ancre; exploitation pour les preuves	Horodatages grossiers; garde des preuves; dépendance à l’écosystème

Une conception de référence en couches

Pour un système documentaire de référence qui doit résister à un examen externe, combinez trois couches; chacune est utile indépendamment et elles se composent sans retouches :

Par document : octets canoniques, condensé SHA-256 consigné à l’ingestion; signatures là où la paternité ou l’approbation compte, horodatées à la signature.
Par événement : chaque événement de création/version/signature/accès ajouté à un journal en arbre de Merkle (service de type Trillian ou tables de registre de base de données), l’entrée incluant le condensé du document.
Périodique : la racine du journal ancrée selon un calendrier (horaire ou quotidien) auprès d’une TSA RFC 3161 et, si le modèle de menace le justifie, sur une chaîne publique via OpenTimestamps; ancres et preuves archivées selon la politique de rétention des documents eux-mêmes.

Les procédures de vérification comptent autant que les mécanismes : un système à preuve d’altération que personne ne vérifie jamais est indiscernable d’une base de données normale. Planifiez la vérification (rehacher des échantillons, contrôler la cohérence du journal, valider les ancres) et traitez un contrôle échoué comme un incident, pas comme une curiosité.

Ce que la preuve d’altération ne peut pas faire

Cela vaut la peine de le redire, parce que survendre cette technologie est la façon dont elle perd sa crédibilité devant un juge ou un auditeur. La preuve d’altération ne peut pas prouver que le contenu d’un document est vrai, ne peut pas empêcher la suppression du système entier (seulement rendre le trou visible si les racines ont été publiées), ne peut pas identifier qui a altéré (seulement que quelque chose a changé), et ne peut pas protéger rétroactivement des documents ingérés après avoir déjà été modifiés. La provenance commence à l’ingestion; tout ce qui précède relève du témoignage.

Webisoft conçoit des systèmes documentaires à preuve d’altération de bout en bout, des journaux d’audit chaînés par hachage et bases de données registre jusqu’aux chaînes de signature et à l’ancrage externe.