Provenance documentaire : comment prouver qu'un document est authentique et inaltéré

La provenance documentaire est une preuve vérifiable de l’origine et de l’historique d’un document : qui l’a créé, quand il existait, qui l’a modifié et si la copie devant vous correspond à l’original. Cette preuve se construit à partir de quatre primitives cryptographiques : les empreintes prouvent l’intégrité, les signatures numériques prouvent l’origine, les horodatages de confiance prouvent le temps et les journaux d’audit en ajout seul prouvent l’historique. Pour la plupart des ententes courantes, le certificat intégré d’une plateforme de signature électronique suffit. La provenance cryptographique mérite sa complexité quand on ne peut pas demander au vérificateur de faire confiance à votre plateforme, quand le dossier doit rester vérifiable pendant des décennies ou quand les parties sont adverses.

Cette page est le carrefour du sujet. Elle définit le problème avec précision, passe en revue les blocs de construction et vous donne un cadre de décision honnête. Deux pages compagnes vont plus loin : comment rendre des documents à preuve d’altération couvre les patrons d’ingénierie, et la notarisation blockchain couvre l’ancrage d’empreintes sur une chaîne publique, y compris quand s’en abstenir.

Ce que « provenance » veut vraiment dire pour un document

Quand on parle d’« authenticité d’un document », on mélange au moins quatre affirmations distinctes. Toute conception sérieuse de provenance commence par les séparer, parce que chaque affirmation se prouve par un mécanisme différent et se défait par une attaque différente.

Remarquez ce qui manque au tableau : la vérité. Aucun mécanisme de provenance ne prouve que le contenu d’un document est exact. Une facture signée, horodatée et ancrée par empreinte peut quand même indiquer un montant faux. La provenance prouve qui s’est engagé sur quels octets et quand. C’est exactement ce sur quoi tournent la plupart des litiges, mais il vaut la peine de le dire clairement, parce que les fournisseurs brouillent régulièrement cette ligne.

Les fondations intellectuelles sont anciennes. Stuart Haber et Scott Stornetta ont décrit comment horodater des documents numériques de sorte que ni l’utilisateur ni le service d’horodatage ne puisse les antidater ou les postdater dans un article de 1991 du Journal of Cryptology, travaux cités plus tard par le livre blanc de Bitcoin. L’ingénierie a mûri depuis, mais l’énoncé du problème n’a pas changé : l’objectif est d’horodater les données, pas le support.

Les quatre blocs de construction

1. Le hachage : une empreinte digitale des octets exacts

Une fonction de hachage cryptographique comme SHA-256 (spécifiée dans le FIPS 180-4 du NIST) associe à tout fichier un condensé court de longueur fixe. Changez un seul octet du document et le condensé change complètement, et il est calculatoirement infaisable de fabriquer un document différent avec le même condensé. L’empreinte est l’atome de tout système de provenance : les signatures signent des empreintes, les horodatages estampillent des empreintes, les journaux chaînent des empreintes et les blockchains ancrent des empreintes.

Deux notes pratiques. D’abord, le choix de l’algorithme compte sur de longs horizons : le NIST a officiellement retiré SHA-1 après que les attaques par collision sont devenues praticables, donc tout dossier de provenance bâti dessus constitue aujourd’hui une preuve plus faible. Ensuite, une empreinte ne prouve l’intégrité que par rapport à un condensé de référence auquel vous pouvez vous fier. Stocker l’empreinte d’un document dans la même base de données que le document n’ajoute rien : quiconque peut altérer le document peut altérer l’empreinte. La valeur vient du fait de placer le condensé quelque part que le dépositaire du document ne peut pas réécrire en douce.

2. Les signatures numériques : lier une identité aux octets

Une signature numérique est une empreinte chiffrée avec la clé privée d’un signataire, vérifiable par quiconque détient le certificat de clé publique correspondant. Elle prouve que le détenteur de cette clé s’est engagé sur ces octets exacts. La signature de PDF, S/MIME et la signature de code fonctionnent tous ainsi, et le règlement eIDAS (910/2014) de l’UE donne aux signatures électroniques qualifiées l’équivalent juridique des signatures manuscrites dans tous les États membres, tandis que la loi américaine ESIGN établit qu’on ne peut pas nier l’effet d’une signature du seul fait qu’elle est électronique.

Les signatures ont deux faiblesses structurelles que toute conception de provenance doit gérer. Les certificats expirent et se font révoquer, donc une signature nue devient difficile à valider des années plus tard, à moins que le matériel de validation soit préservé et que la signature soit elle-même horodatée (c’est ce que font les profils de validation à long terme pour les signatures PDF). Et une signature ne prouve rien sur le temps par elle-même : un signataire dont la clé fuit plus tard pourrait produire de « vieux » documents sur demande. C’est précisément la raison d’être de la RFC 3161 : un horodatage sur une signature prouve que la signature existait avant que le certificat soit révoqué.

3. Les horodatages de confiance : prouver le moment

Une autorité d’horodatage (TSA) conforme à la RFC 3161 ne reçoit que l’empreinte de votre document et retourne un jeton signé liant cette empreinte à une heure tirée de l’horloge de la TSA. N’importe qui peut plus tard vérifier le jeton contre le certificat de la TSA. En vertu de l’article 41 d’eIDAS, un horodatage électronique qualifié bénéficie en plus d’une présomption légale d’exactitude de la date et de l’heure qu’il indique et d’intégrité des données liées, et doit être reconnu dans tous les États membres de l’UE.

Le modèle de confiance est le compromis : vous faites confiance à la clé et à l’horloge de la TSA. Pour la plupart des usages commerciaux, c’est très bien, et c’est peu coûteux et instantané. Quand aucune autorité unique n’est acceptable pour toutes les parties, ou quand vous avez besoin de preuves qui restent vérifiables même si l’autorité disparaît, l’ancrage d’empreintes sur une blockchain publique est l’alternative; nous traitons cela en détail dans la notarisation blockchain.

4. Les journaux d’audit en ajout seul : prouver l’historique

Les artefacts individuels reçoivent empreintes et signatures; les flux de travail ont besoin de journaux. Un journal à preuve d’altération chaîne chaque entrée à la précédente par hachage, de sorte que l’historique ne peut pas être réécrit sans briser chaque maillon subséquent. Le patron a fait ses preuves à l’échelle d’Internet : Certificate Transparency rend l’émission de chaque certificat TLS public auditable au moyen d’un arbre de Merkle en ajout seul, et Rekor de Sigstore fait de même pour les métadonnées de signature logicielle. Les bases de données ont aussi absorbé l’idée : les tables de registre (ledger) d’Azure SQL et de SQL Server rendent des tables ordinaires cryptographiquement à preuve d’altération, protégeant les enregistrements même contre les administrateurs de base de données, avec des condensés périodiques stockés à l’extérieur de la base.

Les patrons d’ingénierie, et les modes de défaillance que chacun attrape réellement, font l’objet de l’analyse approfondie sur les documents à preuve d’altération.

Où s’arrêtent les plateformes de signature électronique et où commence la provenance cryptographique

Les plateformes du type DocuSign regroupent une version fonctionnelle des quatre primitives : elles hachent le document, appliquent une signature de plateforme, consignent une piste d’audit horodatée et émettent un certificat de complétion. Pour une entente courante entre deux parties où chacune accepte la plateforme comme arbitre, c’est réellement suffisant, et en construire davantage serait du gaspillage.

Les limites apparaissent quand vous posez une question plus dure : qui vérifie, et contre qui?

Le motif derrière chaque ligne : un certificat de plateforme est une attestation de la plateforme, et son poids probant est exactement le poids de la parole de la plateforme. La provenance cryptographique déplace la vérification de « demandez à l’exploitant » vers « vérifiez les maths ». Ce déplacement est ce que vous payez avec l’ingénierie supplémentaire.

Conseil honnête : quand une simple base de données ou une signature électronique suffit

La provenance cryptographique a des coûts réels : gestion de clés, casse-têtes de canonicalisation (quels octets exactement avons-nous hachés?), outillage de vérification que vos contreparties doivent exécuter, et des processus qui continuent de fonctionner après le départ de la personne qui les a bâtis. Il vaut la peine de s’en passer quand :

• Les litiges sont internes et à faibles enjeux. Un accusé de réception d’une politique RH n’a pas besoin d’un arbre de Merkle. Une ligne de base de données normale avec un journal d’audit applicatif répond à toutes les questions qu’on posera de façon réaliste.
• Un seul exploitant de confiance est acceptable pour tout le monde. Si un régulateur accepte explicitement le certificat de votre fournisseur de signature électronique, la preuve du fournisseur est la réponse conforme la moins chère.
• Les horizons de rétention sont courts. Si les dossiers expirent dans deux ans, le risque de longévité du fournisseur est négligeable.
• Vous ne pouvez pas vous engager sur la gestion de clés. Une clé de signature qui fuit, ou une chaîne de hachage que personne n’a canonicalisée correctement, produit une preuve pire que rien parce qu’elle crée une fausse confiance. Le retrait par AWS de sa base de données registre spécialisée QLDB, avec fin du soutien le 31 juillet 2025, est aussi une mise en garde utile dans l’autre sens : même une infrastructure choisie pour sa permanence finit par être abandonnée, alors concevez la provenance autour de primitives portables (empreintes, signatures standards, horodatages standards), pas autour d’un produit unique.

À l’inverse, investissez dans la provenance cryptographique quand les documents sont contestés par nature (appels d’offres, antériorité de propriété intellectuelle, chaîne de possession, artefacts d’audit financier), quand la vérification doit être possible sans votre coopération, ou quand le modèle de menace inclut vos propres utilisateurs privilégiés.

Une architecture de provenance minimale qui passe à l’échelle

La plupart des systèmes réels convergent vers la même conception en couches, et vous pouvez l’adopter progressivement :

1. Canonicaliser et hacher chaque version de document à sa création (SHA-256, condensé stocké, sérialisation déterministe pour le contenu structuré).
2. Signer là où l’origine compte : la clé de l’auteur ou du système sur le condensé, avec des certificats d’une PKI que vous pouvez exploiter ou acheter.
3. Journaliser chaque événement (création, consultation, signature, modification) dans un magasin en ajout seul chaîné par hachage, que ce soit une conception de journal de transparence comme Trillian ou des tables de registre natives de la base de données.
4. Ancrer à l’externe le condensé racine périodique du journal : une TSA RFC 3161 pour un témoin de confiance peu coûteux, ou une blockchain publique via un schéma comme OpenTimestamps quand vous avez besoin de témoins que personne ne contrôle.
5. Préserver le matériel de vérification : certificats, données de révocation, jetons d’horodatage et fichiers de preuve, conservés aussi longtemps que les documents eux-mêmes.

Chaque couche ne fait que renforcer celles d’en dessous. Une équipe qui s’arrête aux étapes 1 et 3 a déjà un système où l’altération silencieuse est détectable, ce qui est plus que ce que la plupart des dépôts de documents peuvent prétendre. Vérifier la provenance du côté du consommateur est une discipline en soi, couverte dans comment vérifier la provenance d’un contenu.

Souvent confondus : la provenance et les termes voisins

• Provenance vs légalité de la signature électronique. ESIGN et eIDAS rendent les signatures électroniques juridiquement effectives; ils ne rendent aucun enregistrement particulier techniquement fiable. L’admissibilité juridique et la vérifiabilité cryptographique sont des axes distincts.
• Provenance vs filigrane. Les filigranes intègrent une marque à l’intérieur du contenu et peuvent survivre au réencodage, mais peuvent être attaqués; les métadonnées de provenance voyagent aux côtés du contenu et se brisent bruyamment au lieu de se dégrader. Pour les médias, la norme C2PA combine des manifestes de provenance signés avec le contenu; pour les documents, la pile signatures et journaux décrite ici joue le même rôle.
• Inviolable vs à preuve d’altération. Rien n’est inviolable. Chaque mécanisme de cette page est à preuve d’altération : il rend l’altération détectable, pas impossible. Quiconque vend du stockage « immuable » vend de la détectabilité plus du marketing.

Choisir votre niveau

Une auto-évaluation rapide. Comptez un point pour chacun : vérificateurs externes, contreparties adverses, rétention au-delà de 10 ans, menace interne dans le périmètre, exposition à des audits réglementaires. À 0-1, utilisez votre plateforme de signature électronique et un journal d’audit de base de données discipliné. À 2-3, ajoutez le hachage, les signatures et un journal chaîné par hachage avec horodatages TSA. À 4-5, ajoutez l’ancrage externe et des procédures de vérification formelles, et traitez le système de provenance comme une infrastructure de production avec un responsable.

Webisoft conçoit et construit des systèmes de provenance documentaire, des journaux d’audit chaînés par hachage jusqu’à la notarisation ancrée sur blockchain, dans le cadre de sa pratique d’ingénierie.