Blockchain et RGPD : le guide de conformité 2026

Le 7 juillet 2026, le Comité européen de la protection des données a adopté la version définitive de ses lignes directrices 02/2025 sur les traitements de données personnelles opérés au moyen de technologies blockchain. Le message central tient en une phrase : n’inscrivez pas de données personnelles dans une chaîne de blocs. Pour beaucoup de projets déjà en production, c’est une position difficile à entendre.

Je travaille sur ces dossiers depuis les premiers projets de tokenisation français, et le schéma se répète : l’architecture technique est arrêtée d’abord, la question de la protection des données arrive ensuite, et l’on découvre alors qu’une chaîne conçue pour être inaltérable ne sait pas exécuter une demande d’effacement. Le CEPD ne prétend pas que blockchain et RGPD sont incompatibles. Il dit quelque chose de plus exigeant : la compatibilité se décide au moment de la conception, et elle ne se rattrape pas.

Ce que le CEPD a adopté le 7 juillet 2026

Le texte n’est pas une nouveauté absolue. Une première version avait été publiée le 8 avril 2025 et soumise à consultation publique. La version 2.0 adoptée en juillet 2026 conserve l’intégralité de l’architecture du raisonnement, avec deux inflexions notables issues des retours de place.

La première concerne les nœuds. La version d’avril 2025 laissait planer un doute sur la qualification des validateurs. La version définitive précise qu’un nœud qui se borne à une validation purement technique, sans décider des finalités ni des moyens essentiels du traitement, peut se situer hors du rôle de responsable de traitement. Seuls les nœuds exerçant une influence déterminante sur le traitement basculent dans la qualification de responsable, seul ou conjoint. C’est un assouplissement réel, qui rapproche la doctrine européenne du raisonnement français de 2018.

La seconde concerne les architectures. Le CEPD confirme sa préférence pour les blockchains permissionnées, mais ajoute qu’une organisation peut s’en écarter à condition de justifier ce choix et de le documenter. La préférence devient une présomption réfragable, et non une règle absolue. Le CEPD a par ailleurs publié un rapport sur les résultats de la consultation ainsi qu’une version du texte en suivi de modifications, ce qui permet de mesurer précisément ce qui a bougé.

Pour le reste, la ligne est inchangée : éviter l’inscription de données personnelles dans la chaîne, intégrer la protection des données dès la conception au titre de l’Art. 25 du RGPD, et réaliser une analyse d’impact avant tout déploiement.

Pourquoi la blockchain heurte frontalement le RGPD

Trois propriétés font la valeur d’une chaîne de blocs, et ce sont exactement les trois qui posent problème.

L’inaltérabilité. Une transaction validée et intégrée dans un bloc ne peut plus être modifiée sans réécrire l’ensemble de la chaîne postérieure. Le droit de rectification de l’Art. 16 et le droit à l’effacement de l’Art. 17 supposent l’inverse. Sur ce point, le CEPD est catégorique et la formule mérite d’être retenue : l’impossibilité technique n’est pas une justification pour méconnaître les droits des personnes. C’est au responsable de traitement de concevoir des moyens techniques qui permettent le respect du droit, pas au droit de s’adapter à l’architecture choisie.

La décentralisation. Le RGPD raisonne à partir d’un point d’imputation unique : quelqu’un décide des finalités et des moyens, et répond du traitement. Une chaîne publique n’a par construction pas de centre. Identifier le responsable de traitement suppose alors un travail d’analyse que la plupart des projets n’ont jamais mené sérieusement.

La transparence. Sur une chaîne publique, toute donnée inscrite est accessible mondialement, indéfiniment, sans contrôle d’accès. Chaque lecture depuis un pays tiers pose la question du transfert hors UE au sens du chapitre V, et vous n’aurez ni clauses contractuelles types ni décision d’adéquation à opposer à qui que ce soit.

Une clé publique est-elle une donnée personnelle ?

Oui, dans la très grande majorité des cas. C’est le point de départ que trop de porteurs de projet cherchent encore à contourner.

Une adresse de portefeuille est un identifiant pseudonyme au sens de l’Art. 4(5) du RGPD. Elle ne porte pas de nom, mais elle singularise un utilisateur et permet de le distinguer des autres. Dès lors que cet identifiant peut être rapproché d’une personne physique par des moyens raisonnablement susceptibles d’être mis en œuvre — un passage par une plateforme d’échange soumise aux obligations de connaissance client, une analyse de graphe de transactions, une corrélation avec une adresse IP — la donnée est personnelle et le RGPD s’applique à l’ensemble de la chaîne de traitement.

Le même raisonnement vaut pour les données chiffrées ou hachées inscrites on-chain. Le CEPD le rappelle sans ambiguïté : le chiffrement et le hachage sont des mesures de pseudonymisation, pas d’anonymisation. Elles réduisent le risque, elles ne font pas sortir la donnée du champ du règlement. Confondre les deux notions est l’erreur la plus coûteuse que je rencontre en audit de projet blockchain, parce qu’elle conduit à sauter toutes les étapes suivantes.

Les lignes directrices sur l’anonymisation adoptées le même jour, le 8 juillet 2026, fournissent d’ailleurs la grille pour trancher : la donnée n’est anonyme que si aucune singularisation, aucune corrélation et aucune inférence ne restent possibles. Une adresse blockchain échoue au premier critère par construction, puisque sa fonction même est de singulariser. Si votre projet repose sur l’hypothèse inverse, la question mérite d’être réexaminée avec la méthode d’anonymisation appropriée.

Qui est responsable de traitement dans une chaîne de blocs ?

La CNIL avait posé la première grille d’analyse française dès le 24 septembre 2018, dans ses « Premiers éléments d’analyse » sur la blockchain. Elle distinguait trois catégories d’acteurs, et cette typologie reste utile.

Les accédants disposent d’un droit de lecture et peuvent obtenir une copie de la chaîne. Les participants disposent d’un droit d’écriture : ils créent des transactions qu’ils soumettent à validation. Les mineurs, ou validateurs, vérifient les transactions et créent les blocs en appliquant les règles du protocole.

La CNIL en tirait que le participant qui décide d’inscrire une transaction détermine les finalités et les moyens du traitement : il est responsable de traitement. Le mineur, lui, ne l’est pas — il applique un protocole sans décider de rien. La CNIL envisageait toutefois de le qualifier de sous-traitant dans certaines configurations, avec les obligations contractuelles de l’Art. 28 que cela emporte.

La position du CEPD de juillet 2026 confirme la première partie du raisonnement et affine la seconde : le critère est l’influence déterminante sur le traitement. Un validateur qui se contente d’appliquer les règles consensuelles n’entre pas dans la qualification. En revanche, dès qu’un consortium définit ensemble les règles d’écriture, les finalités du registre ou les conditions d’accès, ses membres relèvent de la responsabilité conjointe de l’Art. 26 et doivent formaliser un accord répartissant les obligations.

En pratique, pour un projet d’entreprise, l’analyse se fait en trois questions. Qui décide de ce qui entre dans la chaîne ? Qui décide des règles de gouvernance du réseau ? Qui héberge les nœuds et selon quelles instructions ? Les réponses déterminent la cartographie des rôles, qui doit ensuite figurer dans votre registre des activités de traitement au titre de l’Art. 30.

Les décisions d’architecture à trancher — et à documenter

1. Ne rien inscrire on-chain

C’est la recommandation principale, et la seule qui règle réellement le problème. Le schéma cible consiste à conserver les données personnelles dans vos systèmes d’information classiques, hors chaîne, et à n’inscrire dans la blockchain qu’une référence ou une preuve cryptographique — un hachage permettant de vérifier l’intégrité du document sans en révéler le contenu.

Cette architecture n’élimine pas le RGPD : le hachage reste une donnée personnelle. Mais elle rend possible l’effacement effectif de la donnée sous-jacente et ramène l’empreinte on-chain à un résidu dont la valeur informationnelle est faible. C’est la seule configuration dans laquelle j’ai vu des projets passer un contrôle sans difficulté majeure.

2. Privilégier une chaîne permissionnée

Le CEPD recommande les architectures privées ou permissionnées, où les droits de lecture et d’écriture sont attribués selon des règles définies. Trois avantages : les rôles sont identifiables, les transferts vers des pays tiers sont maîtrisables, et une gouvernance contractuelle peut organiser l’exercice des droits. La version définitive autorise un écart vers une chaîne publique, mais exige que la justification soit documentée. Autant considérer que ce choix devra être défendu.

3. Si l’inscription est inévitable, choisir la bonne technique

Trois familles de techniques sont mentionnées par le CEPD : le chiffrement, le hachage avec sel secret, et les engagements cryptographiques. La différence pratique est décisive. Un hachage sans sel est vulnérable à une attaque par dictionnaire dès que l’espace des valeurs possibles est réduit — hacher un numéro de sécurité sociale ou une date de naissance n’apporte quasiment aucune protection. Un hachage avec sel secret, dont le sel est conservé hors chaîne et détruit selon une politique définie, offre une protection substantiellement supérieure.

Ces mesures relèvent de l’Art. 32 et doivent être appréciées au regard de l’état de l’art. Sur une chaîne conçue pour durer, la question de la résistance à long terme des algorithmes n’est pas théorique : une donnée chiffrée aujourd’hui avec un algorithme à courbes elliptiques et inscrite dans un registre immuable reste exposée à un déchiffrement futur. Le CEPD demande d’ailleurs explicitement des plans de contingence en cas de vulnérabilité cryptographique.

4. L’effacement par destruction de clé : une solution à instruire, pas à présumer

L’argument est classique : si la clé de déchiffrement est détruite, la donnée devient inintelligible, donc anonyme, donc effacée. Le CEPD ne le rejette pas, mais ne l’accepte pas non plus par principe. La destruction de clé ne vaut effacement que si elle atteint réellement le seuil de l’anonymisation, apprécié selon les critères de singularisation, de corrélation et d’inférence.

Concrètement, cela suppose de documenter : la robustesse de l’algorithme, les modalités de génération et de conservation de la clé, la procédure de destruction et sa preuve, l’absence de copie de sauvegarde, et l’impossibilité de recoupement avec d’autres sources. C’est un dossier technique, pas une affirmation. Il s’articule avec vos procédures d’effacement sécurisé et avec la procédure d’exercice du droit à l’effacement que vous devez pouvoir opposer à une réclamation.

Un point mérite d’être souligné : lorsque le traitement repose sur le consentement, le retrait doit pouvoir produire ses effets. Une architecture qui rend le retrait inopérant fragilise la base légale elle-même. Les limitations aux droits ne sont admissibles que dans les cas prévus par l’Art. 23, qui suppose une mesure législative — pas un choix technique.

5. Smart contracts et décisions automatisées

Un contrat intelligent qui déclenche une conséquence juridique à partir de données personnelles — refus d’accès, liquidation d’une position, exécution d’une pénalité — constitue une décision automatisée au sens de l’Art. 22 dès lors qu’elle produit des effets juridiques ou affecte significativement la personne.

Les conséquences sont concrètes. Il faut une base d’admissibilité au titre de l’Art. 22(2), une information explicite sur la logique sous-jacente, et surtout la possibilité d’obtenir une intervention humaine. Sur une chaîne, cette dernière exigence impose de prévoir dès la conception un mécanisme de suspension ou de rattrapage : contrat proxy avec fonction de pause, oracle de gouvernance, procédure de gel. Un smart contract irrévocable et sans porte de sortie est structurellement incompatible avec l’Art. 22.

6. Localisation des nœuds et transferts

Chaque nœud situé hors de l’Espace économique européen qui reçoit une copie de la chaîne reçoit un transfert au sens de l’Art. 44. Sur une chaîne publique, ce transfert est incontrôlable et sans encadrement possible. Sur une chaîne permissionnée, la localisation des nœuds devient un paramètre de conformité au même titre que l’hébergement : il se choisit, se contractualise et se documente. C’est un argument décisif en faveur d’une architecture fermée, et l’un des plus faciles à faire comprendre à une direction technique.

L’AIPD est quasi systématique

Le CEPD considère que les traitements blockchain présentent régulièrement un risque élevé, ce qui déclenche l’obligation d’analyse d’impact prévue à l’Art. 35. Il faut y ajouter que la plupart de ces projets cumulent plusieurs critères de la liste CNIL : usage innovant d’une technologie, traitement à grande échelle, croisement de données, empêchement de l’exercice d’un droit — ce dernier critère étant, pour une chaîne inaltérable, presque acquis d’avance.

L’analyse doit traiter spécifiquement quatre points que la méthodologie AIPD standard ne couvre pas naturellement : l’irréversibilité de l’inscription et son effet sur la durée de conservation exigée par l’Art. 5(1)(e), le risque de transfert lié à la topologie du réseau, les modalités concrètes d’exercice des droits des personnes, et le risque de désanonymisation à l’horizon de vie du registre.

Le CEPD insiste sur un point de méthode : l’AIPD doit être conçue comme un processus vivant. Une infrastructure blockchain évolue — nouveaux nœuds, changement de protocole, fork, montée de version des smart contracts. Chacun de ces événements appelle une réévaluation. C’est exactement le type de travail répétitif et documentaire que Legiscope automatise, en rattachant chaque évolution technique à l’analyse d’impact correspondante.

Le cas français : DEEP, MiCA et la doctrine CNIL

La France a une particularité que peu d’États membres partagent : elle a donné une valeur juridique à l’inscription en chaîne de blocs avant que l’Union ne s’en saisisse. L’ordonnance n° 2017-1674 du 8 décembre 2017 a créé le dispositif d’enregistrement électronique partagé — le DEEP — en conférant à l’inscription d’une émission ou d’une cession de titres financiers dans une chaîne de blocs les mêmes effets que l’inscription en compte-titres. Le décret n° 2018-1226 du 24 décembre 2018 en a fixé les modalités.

L’effet est paradoxal du point de vue du RGPD. Le droit financier français impose la conservation d’un historique de propriété des titres, alors que le droit de la protection des données impose l’effacement une fois la finalité épuisée. La conciliation passe par la base légale : lorsque l’inscription répond à une obligation légale au sens de l’Art. 6(1)©, l’Art. 17(3)(b) écarte le droit à l’effacement pour ce périmètre. Encore faut-il que le périmètre soit délimité et que le reste du traitement ne s’abrite pas derrière l’obligation légale.

Le règlement MiCA, applicable aux prestataires de services sur crypto-actifs depuis le 30 décembre 2024, ajoute une couche d’obligations documentaires et de conservation qui suit la même logique : des données conservées par obligation réglementaire, dans des systèmes qui doivent malgré tout permettre l’exercice des droits sur tout ce qui excède cette obligation. La même articulation se retrouve dans les autres régimes sectoriels européens, du Data Act aux obligations de lutte contre le blanchiment.

Quant à la doctrine française, elle n’a pas bougé depuis 2018. Les « Premiers éléments d’analyse » de la CNIL restent le seul document de référence en langue française, et ils annonçaient eux-mêmes leur caractère provisoire. Les lignes directrices du CEPD viennent combler ce vide, et il est raisonnable d’anticiper que la CNIL alignera sa position sur celle du Comité plutôt que de maintenir une doctrine nationale distincte.

Checklist avant de lancer un projet blockchain

Avant d’écrire la première ligne de smart contract, sept questions doivent avoir une réponse écrite.

1. Une blockchain est-elle nécessaire ? Le CEPD demande de justifier le recours à la technologie au regard de la finalité poursuivie. Une base de données horodatée avec journalisation répond à la majorité des besoins de traçabilité, sans l’irréversibilité. La question paraît triviale ; elle est éliminatoire.
2. Quelles données entrent dans la chaîne, et lesquelles restent hors chaîne ? Une cartographie donnée par donnée, pas une intention générale.
3. Quelle architecture, et sur quelle justification ? Publique, permissionnée ou privée, avec la motivation documentée si le choix s’écarte de la préférence du CEPD.
4. Qui est responsable, conjoint, sous-traitant ? Avec l’accord de l’Art. 26 ou le contrat de l’Art. 28 correspondant.
5. Comment s’exercent l’accès, la rectification et l’effacement ? Une procédure décrite, testée, et qui produit un résultat vérifiable — y compris le droit d’accès de l’Art. 15 et la portabilité de l’Art. 20.
6. Où sont les nœuds ? Et quel mécanisme de transfert couvre ceux qui sont hors EEE.
7. L’AIPD est-elle réalisée et validée ? Avant le déploiement, pas après le premier incident.

Un projet qui ne peut pas répondre à ces sept questions n’est pas prêt. Le coût de la correction après déploiement, sur une infrastructure immuable, est sans commune mesure avec celui d’une reprise de conception. Et le rappel de l’Art. 83 vaut ici comme ailleurs : les manquements aux droits des personnes relèvent du plafond supérieur, 20 millions d’euros ou 4 % du chiffre d’affaires mondial.

Ce qu’il faut retenir

• Le CEPD a adopté la version définitive de ses lignes directrices 02/2025 le 7 juillet 2026. Deux inflexions par rapport au projet d’avril 2025 : les nœuds purement techniques échappent à la qualification de responsable de traitement, et la préférence pour les chaînes permissionnées admet une dérogation justifiée et documentée.
• La règle par défaut est de ne pas inscrire de données personnelles on-chain. Conserver les données hors chaîne et n’inscrire qu’une preuve cryptographique est la seule architecture qui règle réellement le problème de l’effacement.
• Chiffrement et hachage ne sont pas de l’anonymisation. Une adresse de portefeuille, un hachage, une donnée chiffrée inscrits dans une chaîne restent des données personnelles, et le RGPD continue de s’appliquer intégralement.
• L’impossibilité technique n’est pas une excuse. C’est la formule la plus importante du texte : il appartient au responsable de traitement de concevoir une architecture qui permette l’exercice des droits, pas aux droits de céder devant l’architecture.
• L’AIPD est quasi systématique, et doit être tenue comme un processus vivant réévalué à chaque évolution du réseau : nouveau nœud, fork, montée de version d’un smart contract.

FAQ

Une adresse de portefeuille crypto est-elle une donnée personnelle ?

Dans la très grande majorité des cas, oui. C’est un identifiant pseudonyme qui singularise un utilisateur, et il devient rattachable à une personne physique dès qu’un recoupement raisonnablement accessible existe — passage par une plateforme soumise aux obligations de connaissance client, analyse de graphe de transactions, corrélation avec une adresse IP. Le RGPD s’applique alors à l’ensemble des traitements portant sur cette adresse.

Peut-on effacer une donnée inscrite dans une blockchain ?

Pas au sens littéral, sur une chaîne correctement conçue. La voie praticable consiste à ne pas inscrire la donnée elle-même mais une référence, et à effacer la donnée hors chaîne. La destruction de la clé de déchiffrement peut être envisagée, mais le CEPD ne l’admet comme équivalent d’un effacement que si elle atteint réellement le seuil de l’anonymisation, ce qui suppose un dossier technique documenté et non une simple affirmation.

Faut-il réaliser une AIPD pour un projet blockchain ?

Presque toujours. Le CEPD estime que ces traitements présentent régulièrement un risque élevé, et la plupart des projets cumulent plusieurs critères de la liste CNIL, dont l’usage innovant d’une technologie et l’empêchement de l’exercice d’un droit. L’analyse doit être réalisée avant le déploiement et réévaluée à chaque évolution significative de l’infrastructure.

Les mineurs ou validateurs sont-ils responsables de traitement ?

La version définitive des lignes directrices précise qu’un nœud effectuant une validation purement technique, sans décider des finalités ni des moyens essentiels, se situe hors de la qualification de responsable de traitement. Seuls les acteurs exerçant une influence déterminante — typiquement les membres d’un consortium qui fixent les règles du réseau — sont responsables, le cas échéant conjointement au sens de l’Art. 26.

Une blockchain publique peut-elle être conforme au RGPD ?

C’est possible, mais difficile, et le CEPD demande que le choix soit justifié et documenté. Les deux obstacles principaux sont la diffusion mondiale et incontrôlable des données inscrites, qui rend inopérant l’encadrement des transferts du chapitre V, et l’impossibilité d’identifier un point d’imputation clair. Une architecture permissionnée, où la localisation des nœuds et les droits d’écriture se contractualisent, est nettement plus défendable.

---

Vous instruisez un projet blockchain ou de tokenisation ? Recevez chaque semaine nos analyses de conformité : lignes directrices du CEPD, décisions CNIL et jurisprudence européenne, décryptées pour les praticiens. S’abonner à la newsletter