Le 14 avril 2026, le Comité européen de la protection des données a ouvert à consultation son premier template DPIA harmonisé à l’échelle de l’UE. Derrière la promesse de simplification administrative, une bascule méthodologique plus silencieuse : la séparation entre les risques de conception et les risques d’incident. Une distinction qui redistribue les cartes entre les plateformes qui protègent les données, et celles qui conçoivent l’absence de risque.
L’harmonisation que les DPO attendaient depuis 2018
Le 14 avril 2026, l’EDPB a rendu public son premier template harmonisé de Data Protection Impact Assessment, adopté en version 1.0 dès le 10 mars par procédure écrite. Le document est ouvert à consultation publique jusqu’au 9 juin 2026. Après cette date, toutes les autorités européennes (CNIL incluse) devront l’adopter comme modèle unique, ou comme méta-modèle avec lequel leurs templates nationaux devront rester compatibles.
Pour les DPO qui gèrent des traitements transfrontaliers, c’est la fin d’une fragmentation qui durait depuis sept ans. Jusqu’ici, une DPIA structurée selon une approche nationale n’était pas nécessairement reconnue par une autre autorité. Le template EDPB met fin à cette asymétrie.
C’est la lecture consensuelle du texte. Elle est juste, mais elle passe à côté de l’essentiel.
Deux risques, deux sections, deux logiques
La vraie innovation du template 2026 n’est pas formelle. Elle est méthodologique. Pour la première fois dans un document opposable à l’échelle européenne, le template distingue deux natures de risques que la plupart des méthodologies DPIA de la première génération mélangeaient dans une matrice unique.
Dans la section 3, le contrôleur documente les risques inhérents au traitement lui-même. Ceux qui existent même si tout fonctionne parfaitement, si aucune configuration ne dérape, si aucun attaquant n’entre dans le système. Centralisation des données, durées de conservation étendues, identifiants persistants, combinaison de jeux hétérogènes. Ces risques sont des conséquences de choix architecturaux, pas d’événements.
Dans la section 4, séparément, on documente les risques opérationnels. Bugs, mauvaises configurations, erreurs humaines, accès abusifs, attaques externes. Ce sont les risques d’incident.
Cette séparation paraît technique. Elle est en réalité politique. Elle force une question que les DPIA de la première génération éludaient régulièrement : cette architecture est-elle compatible avec les droits et libertés des personnes, même quand elle fonctionne comme prévu ?
Autrement dit, avant même de parler de sécurité, est-ce que le design lui-même pose problème ? La réponse à cette question ne se trouve pas dans la qualité des pare-feux. Elle se trouve dans le plan d’architecture.
Quand la sécurité ne répare pas la conception
La réponse, pour un grand nombre d’architectures actuelles, est inconfortable. Un data lake construit autour d’un stockage centralisé long-durée, même parfaitement opéré, porte des risques structurels qui se documentent désormais dans une section à part, sans que l’ajout de mesures opérationnelles n’y réponde.
Le chiffrement ne transforme pas une rétention de dix ans en une absence de rétention. Le contrôle d’accès ne rend pas anodin le fait de concentrer en un endroit unique les données sensibles de millions de personnes. La section 3 du template obligera à documenter ces choix pour eux-mêmes.
Les plateformes qui ont grandi sur le modèle « collecter largement, stocker durablement, protéger intensivement » vont devoir affronter ce miroir. Ce n’est pas une accusation, c’est un constat. Le template EDPB n’invente rien : il rend explicite ce que l’article 25 du RGPD demandait depuis 2018. Mais il le rend explicite dans une section dédiée, traçable, comparable d’un dossier à l’autre.
L’autre miroir : les architectures qui n’ont rien à stocker
Le miroir renvoie une image très différente quand on regarde des architectures conçues autrement.
Une plateforme qui traite les données pendant leur transport, sans les déplacer ni les stocker, compresse par conception la section 3 du template. Il n’y a pas de centralisation à documenter, parce qu’il n’y a pas de centralisation. Il n’y a pas de durée de rétention à justifier, parce que le traitement est in-transit. Les jeux combinés ne laissent pas de trace persistante, parce que la combinaison se dissout avec le contexte d’usage. Les identifiants persistants disparaissent, parce que la plateforme n’en fabrique pas.
C’est le principe de la technologie DataCell d’iD4Connect : chaque unité de traitement agit sur la donnée pendant son transit, puis la libère. Rien ne persiste côté plateforme. DataGraph assure l’intelligence contextuelle, qui se dissout avec le contexte d’usage. L’architecture n’est pas une couche de protection ajoutée sur une topologie classique. C’est une autre topologie (voir l’architecture complète).
Et la section 4, sur les incidents ? Elle reste à remplir, bien sûr. Aucune architecture ne dispense d’analyser ses propres défaillances. Mais quand l’actif à défendre n’inclut ni data lake ni warehouse, la question « que se passe-t-il si un attaquant entre » change de nature. Il n’y a pas de patrimoine à exfiltrer hors des sources, qui restent dans le périmètre du contrôleur d’origine avec leurs propres mesures.
Une architecture qui n’a rien à perdre ne se défend pas comme une architecture qui a tout à protéger.
Cinq questions pour tester votre DPIA actuelle
Avant la finalisation du template en juin, il peut être utile de passer votre DPIA actuelle, ou votre dernière revue, au filtre de cinq questions. Elles ne remplacent pas une analyse de conformité, mais elles donnent un signal rapide.
- Votre section sur les risques distingue-t-elle clairement ceux qui viennent de la conception du traitement et ceux qui viennent d’incidents opérationnels, ou les deux sont-ils traités dans une matrice unique ?
- Quand vous décrivez vos mesures au titre de l’article 25 (data protection by design), s’agit-il de paramétrages ajoutés sur une architecture existante, ou de propriétés intrinsèques de l’architecture elle-même ?
- Si une autorité vous demandait demain : « que se passerait-il pour les personnes concernées si toute l’architecture fonctionnait parfaitement, sans incident aucun », votre réponse serait-elle courte ou longue ?
- Votre inventaire d’actifs (section 1.3 du template) comprend-il des composants de stockage long-durée qui existent principalement pour des raisons d’historique, et dont la valeur métier serait dure à défendre aujourd’hui ?
- Si vous recommenciez l’architecture à zéro, avec les standards 2026 en tête, choisiriez-vous la même topologie de données, ou une autre ?
Ces questions ne se posaient pas dans les mêmes termes il y a un an. Elles vont se poser dans ces termes pendant les cinq prochaines.
Selon votre rôle, ce que cela change
Pour un DPO : à mission égale, le volume de documentation nécessaire dépend désormais du type d’architecture. Défendre une DPIA devant l’autorité devient mécaniquement plus simple quand l’architecture sous-jacente n’oblige pas à justifier chaque risque structurel par une mesure compensatoire.
Pour un RSSI : un nouveau type d’outil entre dans la conversation. Non pas un produit de sécurité additionnel, mais une architecture de données qui réduit mécaniquement la surface à défendre. « Une donnée qu’on ne peut pas voler n’a pas besoin d’être défendue » cesse d’être un aphorisme pour devenir une catégorie documentaire.
Pour un DSI ou un CTO : un arbitrage économique se formalise. Les plateformes d’analytique centralisée ont un coût d’opération et un coût de conformité. Jusqu’ici, le second restait diffus, inégal, difficile à chiffrer. Le template EDPB le rend visible section par section. Dans les secteurs régulés (finance & banque, santé, énergie, secteur public), où chaque DPIA est documentée, auditée et revue, cet arbitrage cesse d’être théorique.
Pour une autorité de régulation : un critère de différenciation gagne en lisibilité. Les architectures qui incarnent l’article 25 par conception et non par paramétrage ont désormais un langage commun pour le démontrer, et un langage pour les autorités pour le reconnaître.
Contribuer à la consultation, pendant qu’elle est ouverte
La consultation EDPB est ouverte jusqu’au 9 juin. Toute contribution sera publiée sur le site de l’autorité.
Nous pensons que le template gagnerait à reconnaître explicitement, dans sa section sur le data protection by design, la catégorie des architectures data-at-source et stateless. Non pas parce qu’elles seraient meilleures en soi (ce jugement appartient aux contrôleurs et à leurs autorités), mais parce qu’elles transforment qualitativement, et non quantitativement, le profil de risque d’un traitement.
C’est pourquoi nous invitons les DPO, juristes, intégrateurs et éditeurs qui ont une expérience concrète de ces architectures à participer à la consultation. Une consultation publique n’est utile que si ceux qui font le travail prennent la peine d’écrire.
Dans six semaines, le template sera finalisé. Dans quelques mois, il sera la référence opposable à tous les éditeurs de plateformes de données présents en Europe. Deux questions se posent à ce moment-là, une technique et une stratégique. La première, nous venons de la poser.
La seconde est plus simple : et si vous recommenciez l’architecture demain, choisiriez-vous la même ?
Le template DPIA de l’EDPB n’invente aucune obligation nouvelle. Il rend simplement lisible ce que l’article 25 du RGPD demandait depuis 2018 : séparer ce qui relève de la conception du traitement et ce qui relève de l’incident. Dans cette grille de lecture, les architectures qui ne stockent pas les données n’ont pas à compenser leur design par des mesures : elles réduisent mécaniquement le périmètre à documenter. D’ici juin, ce ne sera plus une intuition. Ce sera un format opposable.