RGPD et horodatage blockchain : guide de conformité 2026

Vous voulez horodater des contrats, des dossiers RH, des échanges clients pour vous constituer des preuves solides. Excellente idée. Mais une question revient inévitablement : est-ce compatible avec le RGPD ?

La réponse courte : oui, à condition de comprendre quelques principes simples. La réponse longue : il faut distinguer les données qui restent off-chain (protégeables, effaçables, conformes au RGPD) et ce qui est inscrit sur la blockchain (immuable, public, à minimiser).

Le secret de la conformité tient en un mot : hash. Inscrire seulement l'empreinte du document, jamais le contenu, c'est la base d'une stratégie d'horodatage RGPD-compatible.

Le RGPD et la blockchain : le faux débat

Beaucoup pensent que blockchain et RGPD sont incompatibles. C'est faux — à condition de bien architecturer son usage.

Ce que dit la CNIL (rapport "Blockchain et RGPD" de 2018, mis à jour en 2024) :

La blockchain n'est pas illégale au regard du RGPD.
Inscrire des données personnelles brutes sur une blockchain publique est en revanche fortement déconseillé.
Inscrire un hash (empreinte) est acceptable, à condition que les données qui permettent de relier ce hash à une personne soient gérées off-chain dans un environnement conforme.

Ce que dit le CEPD (Comité européen de la protection des données) : les hashes restent des données pseudonymisées au sens du RGPD, pas anonymisées. Cela signifie qu'ils restent soumis au RGPD, mais que la pseudonymisation est un facteur de réduction du risque (considérant 28).

Pseudonymisation ≠ anonymisation

Un hash est une donnée pseudonymisée : impossible à inverser, mais potentiellement ré-identifiable si on a accès aux données sources. Une vraie anonymisation serait irréversible — le hash ne l'est pas.

Les 6 principes RGPD appliqués à l'horodatage

Principe RGPD	Application à l'horodatage
Licéité (art. 6)	Base légale claire (consentement, intérêt légitime, obligation légale)
Minimisation (art. 5.1.c)	Inscrire uniquement le hash, jamais le contenu
Limitation conservation (art. 5.1.e)	Définir une durée de conservation des données off-chain
Intégrité et confidentialité (art. 5.1.f)	Le hash garantit l'intégrité ; le chiffrement off-chain assure la confidentialité
Droit à l'effacement (art. 17)	Détruire les données off-chain rend le hash on-chain inopérant
Responsabilité (art. 5.2)	Documenter les choix d'architecture dans le registre des traitements

Architecture conforme : on-chain vs off-chain

C'est le cœur du sujet. Voici l'architecture recommandée :

1
Stockage off-chain du document
Le contrat, le fichier RH, l'échange client est stocké dans votre système d'information conforme RGPD (serveur chiffré, accès journalisés, durée de conservation définie).
2
Calcul du hash localement
Le hash SHA-256 est calculé sur le fichier source. Cette opération ne nécessite aucun envoi du contenu vers un tiers.
3
Inscription du hash sur la blockchain
Seul le hash (chaîne de 64 caractères hexadécimaux) est envoyé au serveur d'horodatage et inscrit sur la blockchain publique. Aucune donnée identifiante n'est exposée.
4
Conservation de la preuve d'horodatage
Le fichier .ots (ou équivalent) est conservé en local avec le document source. La preuve permet de vérifier l'intégrité ultérieurement.
5
Vérification ponctuelle
Pour vérifier une preuve, on recalcule le hash localement et on compare. Aucun envoi du contenu vers un tiers — la vérification reste confidentielle.

✓

Le hash voyage, le contenu reste

Cette architecture respecte la minimisation (art. 5.1.c RGPD) : on n'envoie jamais plus que strictement nécessaire à la finalité (preuve d'antériorité et intégrité).

Le droit à l'effacement appliqué à la blockchain

L'article 17 du RGPD donne à toute personne le droit de demander l'effacement de ses données. Sur une blockchain publique, on ne peut pas supprimer une transaction. Comment respecter ce droit ?

La doctrine CNIL : effacer ce qui est effaçable

Si seul un hash est inscrit on-chain, et que les données qui permettent de relier ce hash à la personne sont off-chain, alors détruire ces données off-chain rend le hash inopérant pour identifier cette personne. Le hash subsiste sur la blockchain, mais devient une suite de caractères orpheline, sans valeur identifiante.

Procédure recommandée :

La personne exerce son droit à l'effacement.
Vous identifiez les fichiers concernés dans votre stockage off-chain.
Vous détruisez : le fichier source, la clé de correspondance hash↔personne, les sauvegardes (selon votre politique).
Vous documentez l'opération dans votre registre des activités.
Vous informez la personne que le hash on-chain subsiste mais ne permet plus de remonter à elle.

Attention aux backups

Si vous conservez des sauvegardes hors site, vous devez aussi y appliquer la procédure d'effacement (ou prouver qu'elles seront purgées dans un délai raisonnable conforme à votre politique).

Les 4 cas d'usage typiques (et comment les sécuriser)

Contrats clients ou fournisseurs

Off-chain : contrat PDF, identité des parties, clauses, montants.
On-chain : hash du contrat.
Précautions : durée de conservation alignée sur les obligations comptables et commerciales (10 ans en règle générale).

Dossiers RH (contrats de travail, sanctions, fiches de paie)

Off-chain : tout le contenu, dans le SIRH conforme RGPD.
On-chain : hash de chaque document clé.
Précautions : durée de conservation selon le tableau légal (5 ans pour bulletins, durée de la carrière + 5 ans pour le dossier individuel).

Preuves de litige client

Off-chain : échanges email, captures d'écran, factures.
On-chain : hash de chaque pièce.
Précautions : prévoir l'effacement après prescription du litige (5 ans en civil ordinaire).

Œuvres avec données personnelles intégrées

Exemple : un photographe qui horodate un portrait de modèle.

Off-chain : photo originale + autorisation de droit à l'image signée.
On-chain : hash de la photo.
Précautions : si le modèle exerce son droit à l'effacement (rare mais possible), détruire la photo et l'autorisation. Le hash devient inopérant.

Cas particuliers à connaître

eIDAS et RGPD

eIDAS (règlement UE 910/2014, révisé 2024) régit la confiance numérique : signatures électroniques, horodatage qualifié, identité numérique. Le RGPD régit la protection des données personnelles. Les deux s'appliquent en parallèle.

Un horodatage qualifié eIDAS doit être mis en œuvre dans le respect du RGPD : minimisation, base légale, sécurité, etc. Le QTSP a lui-même des obligations RGPD comme sous-traitant ou responsable conjoint selon l'architecture.

Transferts internationaux

Si votre service d'horodatage est hébergé hors UE (par exemple aux USA), examinez :

La base juridique du transfert (DPF, clauses contractuelles types).
Les données réellement transférées (un hash seul est-il un transfert de données personnelles ? sujet à débat).
Les recommandations CNIL sur les transferts post-Schrems II.

Les services européens ou les solutions on-premise minimisent ce risque.

Données sensibles (article 9 RGPD)

Données de santé, opinions politiques, orientation sexuelle, etc. : traitement strictement encadré par l'article 9 RGPD. L'horodatage par hash reste possible, mais la base légale et les mesures de sécurité doivent être renforcées (consentement explicite, chiffrement renforcé, accès restreint).

Le registre des activités de traitement (article 30)

Si vous mettez en place un horodatage régulier, intégrez-le à votre registre RGPD. Mention type :

text

Finalité : Horodatage des documents pour preuve d'antériorité et intégrité
Base légale : Intérêt légitime (sécurisation des preuves contractuelles)
Catégories de données : Hash SHA-256 de documents pouvant contenir des données personnelles
Catégories de personnes : Clients, salariés, fournisseurs (selon le document)
Destinataires : Service d'horodatage [nom], blockchain publique [nom]
Durée de conservation : Hash on-chain (illimité), données off-chain (selon politique métier)
Mesures de sécurité : Hash uniquement on-chain, chiffrement off-chain, accès restreint
Procédure d'effacement : Destruction des données off-chain sur demande

Erreurs à éviter

Inscrire un nom, un email ou un identifiant sur la blockchain → Données personnelles inscrites de manière irréversible. Risque RGPD majeur.

Stocker un fichier complet (même chiffré) sur IPFS publique → Le chiffrement n'est pas l'anonymisation. Une clé compromise rend tout le contenu lisible.

Oublier de mentionner l'horodatage dans la politique de confidentialité → Les personnes doivent être informées des traitements de leurs données.

Croire que le hash anonymise → Le hash pseudonymise. Il reste une donnée personnelle si la ré-identification est possible.

Ne pas prévoir l'effacement → Sans procédure documentée, vous êtes en infraction au moment du premier exercice du droit à l'effacement.

Confondre conformité technique et conformité juridique → Une architecture techniquement irréprochable ne dispense pas du registre, de l'information, du consentement quand il est requis.

Checklist conformité RGPD pour l'horodatage

Base légale identifiée et documentée (consentement, intérêt légitime, obligation légale)
Architecture on-chain limitée aux hashes (jamais de contenu brut)
Données off-chain stockées dans un environnement RGPD-conforme (chiffrement, accès journalisés)
Durée de conservation off-chain définie et appliquée
Procédure d'effacement documentée (off-chain destruction → hash inopérant)
Mention dans le registre des activités de traitement (art. 30)
Information des personnes dans la politique de confidentialité
DPIA réalisée si traitement à risque élevé (art. 35)
Sous-traitants (QTSP, prestataire d'horodatage) sous contrat conforme art. 28
Transferts internationaux encadrés (clauses contractuelles types, DPF)

FAQ

Oui, à condition de n'inscrire que des hashes (empreintes) et non des données personnelles brutes. Le hash est considéré comme une donnée pseudonymisée selon la doctrine de la CNIL (rapport blockchain 2018, mis à jour 2024).

On ne peut pas effacer une transaction sur une blockchain publique. Mais si vous n'inscrivez qu'un hash, l'effacement effectif consiste à détruire les données off-chain qui permettent de relier ce hash à une personne (clé de correspondance, fichier source).

Selon la CNIL et le CEPD, un hash de données personnelles reste une donnée personnelle s'il permet d'identifier indirectement une personne. La pseudonymisation n'est pas une anonymisation. La conformité repose sur la sécurité des données qui permettent la ré-identification.

Oui, à condition de n'envoyer à la blockchain que le hash du document. Le contrat lui-même reste en local ou dans un système conforme RGPD. La preuve d'horodatage ne révèle rien sur le contenu.

La CNIL a publié un rapport en 2018 (mis à jour en 2024) reconnaissant la blockchain comme outil légitime, à condition de n'y inscrire que des données minimisées (hashes, références). Elle recommande l'horodatage off-chain pour les données personnelles brutes.

Pas systématiquement. Une DPIA est requise si le traitement présente un risque élevé pour les droits et libertés (article 35 RGPD). L'horodatage de hashes seul présente généralement un risque faible et n'impose pas de DPIA spécifique.

Détruire les données off-chain qui permettent de reconstituer le lien hash ↔ personne (fichier source, base de correspondance). Le hash sur la blockchain devient alors inopérant pour identifier la personne. Documenter la procédure dans votre registre des activités.

Non. eIDAS et RGPD sont deux règlements complémentaires. Un horodatage qualifié bénéficie d'une présomption légale, mais doit être mis en œuvre dans le respect du RGPD si des données personnelles sont concernées.

Conclusion

RGPD et horodatage blockchain ne sont pas en opposition, ils sont complémentaires — à condition de respecter une règle de design simple : on-chain seulement les hashes, off-chain tout le reste, et une procédure d'effacement documentée.

Cette architecture, recommandée par la CNIL, vous permet de cumuler les bénéfices : preuves d'antériorité solides, intégrité vérifiable, et conformité RGPD démontrable. Le tout sans renoncer ni à la robustesse de la blockchain ni au droit à l'effacement de vos contacts.

Construire ça soi-même demande du temps : architecture hash-only, registre des traitements, procédure d'effacement, contrats sous-traitants conformes art. 28, encadrement des transferts, journal d'audit. C'est faisable, mais c'est un projet à part entière.

LegalStamp embarque cette conformité by design : seul le hash on-chain, données off-chain chiffrées et hébergées en UE, procédure d'effacement documentée, registre des traitements pré-rempli, sous-traitance conforme art. 28. Vous gardez le bénéfice juridique de la blockchain sans le risque RGPD.

Disclaimer (information générale) : cet article est fourni à des fins pédagogiques et ne constitue pas un avis juridique. La conformité RGPD dépend toujours du contexte précis du traitement et de l'analyse d'un DPO ou d'un avocat spécialisé. Pour les traitements à risque élevé, une DPIA et un accompagnement professionnel restent indispensables.

RGPD et horodatage : ce que vos preuves numériques doivent respecter