AIPD RGPD article 35 : méthode, critères et impact sur l’architecture

L’AIPD (analyse d’impact relative à la protection des données, DPIA ou Data Protection Impact Assessment en anglais) est l’étude qu’on mène avant de lancer un traitement de données personnelles risqué pour les personnes, pas après la plainte. Le RGPD (Règlement général sur la protection des données) l’impose dans son article 35 pour les traitements à risque élevé. Bien conduite, elle est l’endroit où se décident les choix d’architecture qui coûtent le moins cher à faire tôt : ce qu’on collecte, combien de temps on le garde, qui y accède et où ça part.

→ Lire l’explication complète de la marmotte

Quand l’AIPD est obligatoire : article 35, critères WP248 et listes CNIL

Le déclencheur légal tient en une formule de l’article 35.1 : un traitement « susceptible d’engendrer un risque élevé pour les droits et libertés des personnes physiques ». Le texte vise les personnes concernées, pas l’organisation. Tout le reste de la démarche découle de ce choix de point de vue.

L’article 35.3 cite trois cas où l’AIPD est requise d’office :

l’évaluation systématique et approfondie d’aspects personnels fondée sur un traitement automatisé, profilage compris, qui sert de base à des décisions produisant des effets juridiques ou affectant la personne de manière significative ;
le traitement à grande échelle de catégories particulières de données (article 9 : santé, opinions, biométrie, etc.) ou de données relatives aux condamnations pénales (article 10) ;
la surveillance systématique à grande échelle d’une zone accessible au public.

Ces trois cas ne suffisent pas à trier un portefeuille de projets. Les lignes directrices WP248 du G29 (le groupe de travail « article 29 », prédécesseur du CEPD (Comité européen de la protection des données), qui les a reprises en 2018) fournissent neuf critères :

évaluation ou notation (scoring, profilage) ;
décision automatisée avec effet juridique ou similaire ;
surveillance systématique ;
données sensibles ou à caractère hautement personnel ;
traitement à grande échelle ;
croisement ou combinaison d’ensembles de données ;
personnes vulnérables (salariés, patients, mineurs, etc.) ;
usage innovant ou application de nouvelles solutions technologiques ;
traitement qui empêche d’exercer un droit ou de bénéficier d’un service ou d’un contrat.

La règle de lecture du WP248 : deux critères remplis rendent l’AIPD nécessaire dans la plupart des cas, et un seul peut suffire selon le contexte. Le critère 7 coche tout seul pour un grand nombre de traitements RH : la relation employeur/salarié est explicitement citée comme un déséquilibre de pouvoir. Un outil de supervision des postes de travail qui croise journaux de proxy et annuaire coche les critères 3, 6 et 7 sans effort. Quant au critère 8, un traitement qui s’annonce « propulsé par l’IA » sur sa slide de lancement vient de cocher une case de lui-même ; le marketing a au moins ce mérite.

En France, la CNIL (Commission nationale de l’informatique et des libertés) publie, conformément à l’article 35.4 et 35.5, une liste des types d’opérations pour lesquels l’AIPD est requise et une liste de ceux pour lesquels elle ne l’est pas. On consulte les deux listes dans leur version en vigueur sur le site de la CNIL plutôt que dans une copie de tableur qui date du projet précédent. Absence d’un traitement sur la liste « requise » ne vaut pas dispense : les critères WP248 continuent de s’appliquer.

Ignorer l’obligation n’est pas neutre. L’article 83.4 range les manquements aux articles 35 et 36 dans la tranche d’amendes allant jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Pour savoir si un traitement donné y est soumis et ce qu’une organisation précise risque, le texte officiel et un juriste priment sur cette page.

Contenu minimal d’une AIPD selon l’article 35.7

Le texte fixe quatre blocs obligatoires. Une AIPD qui en saute un n’est pas une AIPD incomplète, c’est un autre document.

Description systématique du traitement et des finalités. Données traitées, personnes concernées, flux, supports (applications, bases, réseaux, sous-traitants), durées de conservation, destinataires. Le prérequis réel est l’inscription au registre des traitements (article 30) et une cartographie des flux à jour. Sans elle, la description décrit le traitement tel qu’il a été imaginé en atelier, pas celui qui tourne.

Nécessité et proportionnalité. Base légale, finalité déterminée et légitime, données adéquates et limitées au nécessaire, durées justifiées, information des personnes, modalités d’exercice des droits (accès, rectification, effacement, opposition, portabilité). C’est ici que la minimisation cesse d’être un principe et devient une ligne de tableau qu’il faut défendre champ par champ.

Évaluation des risques pour les droits et libertés. La méthode CNIL structure ce bloc autour de trois événements redoutés : accès illégitime aux données, modification non désirée, disparition. Chacun s’évalue en gravité (impact sur la personne) et en vraisemblance (sources de risque, menaces, vulnérabilités des supports), sur une échelle à quatre niveaux. Le piège classique consiste à remplir la gravité depuis le point de vue de l’organisation (« fuite de données clients : impact image élevé ») au lieu de celui de la personne (« divulgation d’un diagnostic à un employeur : discrimination, perte d’emploi »).

Mesures envisagées. Mesures juridiques (information, contrats de sous-traitance) et mesures techniques et organisationnelles, chacune rattachée au risque qu’elle réduit. Une mesure qui ne réduit aucun risque identifié est du décor ; un risque sans mesure est une décision d’acceptation qui doit être écrite comme telle.

Deux avis complètent le dossier. L’article 35.2 impose de demander conseil au DPO (Data Protection Officer, délégué à la protection des données) quand il en a été désigné un ; son avis est consigné, y compris quand le responsable du traitement ne le suit pas, avec la justification. L’article 35.9 prévoit de recueillir « le cas échéant » l’avis des personnes concernées ou de leurs représentants : pour un traitement RH, les représentants du personnel sont l’interlocuteur naturel, et leur consultation fait souvent remonter des usages détournés que l’équipe projet n’avait pas envisagés.

AIPD et analyse de risques de sécurité : EBIOS RM, ISO 27005

L’AIPD et l’analyse de risques de sécurité utilisent un vocabulaire voisin (sources de risque, vraisemblance, gravité) et c’est précisément ce qui les fait confondre. La différence est l’objet du risque. EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité, Risk Manager, méthode publiée par l’ANSSI, Agence nationale de la sécurité des systèmes d’information) et ISO/IEC 27005 mesurent l’impact sur l’organisation : ses missions, ses valeurs métier, son activité. L’AIPD mesure l’impact sur les personnes dont les données sont traitées.

Les deux évaluations divergent dans des cas très concrets. Une base de prospects volée a un impact faible pour l’entreprise si les données sont publiques par ailleurs ; une base de signalements internes volée peut ruiner la vie d’un lanceur d’alerte tout en n’affectant presque pas l’activité. Inversement, l’indisponibilité d’un ERP (progiciel de gestion intégré) est critique pour l’organisation et souvent anodine pour les personnes. Une matrice unique qui fusionne les deux points de vue écrase systématiquement le second.

Elles se nourrissent pourtant l’une l’autre, et c’est la bonne manière de les faire cohabiter. Le schéma montre le sens des échanges : la sécurité fournit la vraisemblance et les mesures, l’AIPD fournit la gravité côté personnes et des exigences supplémentaires.

Position : on ne mène pas une AIPD sans analyse de sécurité du système qui porte le traitement, et on ne réutilise pas l’analyse de sécurité comme AIPD. La première sans la seconde donne des vraisemblances inventées ; la seconde à la place de la première oublie l’essentiel de l’article 35.7.b, que ni EBIOS RM ni ISO 27005 ne couvrent : la question « a-t-on besoin de cette donnée ? ». Pour une méthode dédiée à la protection de la vie privée, ISO/IEC 29134 fournit des lignes directrices d’évaluation d’impact compatibles avec la démarche.

Ce que l’AIPD change dans l’architecture

Une AIPD qui ne modifie aucun choix technique a été menée trop tard ou trop superficiellement. Les leviers sont connus ; ce qui compte, c’est leur moment d’application.

Minimisation. Chaque champ collecté se justifie par une finalité. Retirer un champ d’un formulaire en conception coûte une ligne ; le retirer après deux ans de production impose une migration, une purge dans les sauvegardes et dans chaque copie analytique. Les pages sur la minimisation des données et sur la classification détaillent la mécanique.

Durées de conservation. Une durée décidée dans l’AIPD n’existe que si un mécanisme la fait respecter : purge planifiée, TTL (Time To Live, durée de vie) sur les objets, politique de cycle de vie du stockage. Le point aveugle habituel reste la sauvegarde et le lac de données : une donnée purgée en base mais conservée trois ans dans un export analytique n’a pas de durée de conservation, elle a un domicile secondaire. Voir le cycle de vie de la donnée et la gouvernance des data lakes.

Contrôle d’accès. L’événement « accès illégitime » inclut l’accès interne abusif, qui est la source de risque la plus fréquente sur les traitements RH. Conséquence d’architecture : des rôles alignés sur la finalité plutôt que sur l’organigramme, un accès aux données de production refusé par défaut aux administrateurs applicatifs, et des comptes à privilèges séparés.

Journalisation. Pour les traitements sensibles, journaliser les consultations et pas seulement les modifications. Le journal est lui-même un traitement de données personnelles (il contient l’identité de l’agent et l’objet consulté) : il entre dans le périmètre de l’AIPD avec sa propre durée de conservation. Un journal que personne ne relit ne sert qu’à dater la fuite après coup, comme le montre la page sur les fuites et journaux d’accès.

Chiffrement. Le chiffrement au repos côté disque ou volume protège contre le vol de support, pas contre un administrateur de base ni contre une injection SQL. Contre l’accès interne abusif, seul le chiffrement au niveau du champ avec des clés détenues hors de la base réduit la vraisemblance, au prix de la recherche et du tri sur les colonnes chiffrées. C’est un arbitrage que l’AIPD doit trancher par écrit, pas découvrir en recette.

Pseudonymisation. Elle réduit la gravité pour les usages secondaires (statistiques, tests, entraînement de modèles) mais les données restent personnelles au sens du RGPD tant que la table de correspondance existe. Sur ce point, la page anonymisation contre pseudonymisation évite une erreur coûteuse : déclarer anonyme un jeu de données qui se réidentifie par croisement.

Sous-traitants et transferts. Chaque sous-traitant (hébergeur, éditeur SaaS, Software as a Service, prestataire de support) est un support supplémentaire dans l’évaluation des risques. Un transfert hors de l’Espace économique européen impose son propre encadrement (chapitre V du RGPD) et pèse sur la vraisemblance d’un accès par une autorité étrangère. La résidence des données se décide ici, pas au renouvellement du contrat.

Le compromis central du sujet est là. Mener l’AIPD tôt coûte des révisions : l’architecture bouge, le document doit suivre. La mener tard coûte zéro révision et ne change rien, puisque chaque mesure proposée bute sur « c’est déjà en production ». Position assumée : une première version dès que les flux et les supports sont connus (choix d’hébergement, schéma de données initial), puis une version consolidée avant la mise en production. Cette recommandation suppose que l’AIPD soit versionnée avec le projet ; sans cela, les révisions se perdent et on retombe dans le document unique écrit à la fin.

Ce que l’AIPD ne garantit pas

Une AIPD validée n’est pas un certificat de conformité. Elle documente une analyse et des décisions à une date donnée ; elle ne prouve pas que les mesures sont implémentées, ni qu’elles fonctionnent. La preuve vient d’ailleurs : audits techniques, tests de restauration, revues d’habilitations, contrôle de la purge effective.

Elle ne couvre pas non plus les obligations voisines. La base légale doit tenir d’elle-même ; l’information des personnes, la gestion du consentement (voir l’architecture de gestion du consentement), la notification des violations (articles 33 et 34) et le registre restent des obligations distinctes. Et elle ne remplace pas l’analyse de sécurité du système : elle s’appuie dessus.

Enfin, elle n’est pas opposable à un incident. Une fuite sur un traitement couvert par une AIPD reste une violation à notifier ; l’AIPD sert alors à montrer que le risque avait été identifié et traité de façon raisonnable, ce qui n’a de valeur que si le document décrit le système réel.

Surface d’attaque du traitement et de la démarche

Les attaques connues sur un traitement couvert par une AIPD se rangent dans les trois événements redoutés, avec leurs contre-mesures habituelles :

Accès illégitime : abus de droits internes (contre-mesure : moindre privilège et revue périodique des habilitations, journal des consultations exploité) ; compromission d’un compte de service ou d’un sous-traitant (secrets en coffre, rotation, cloisonnement réseau) ; réidentification d’un jeu prétendument anonyme par croisement (voir réidentification) ; fuite par les environnements de test alimentés avec des copies de production (contre-mesure : masquage dynamique).
Modification non désirée : altération par un compte privilégié ou par une application compromise (contre-mesures : traçabilité des modifications, contrôles d’intégrité, séparation des rôles d’écriture) ; erreurs de qualité qui produisent des décisions fausses sur une personne, risque souvent sous-estimé (voir la qualité des données).
Disparition : rançongiciel, suppression accidentelle, défaillance du fournisseur (contre-mesures : sauvegardes hors ligne et restaurations testées). Paradoxe à documenter : la sauvegarde qui protège contre la disparition rallonge la conservation et complique l’effacement.

La démarche elle-même a une surface d’attaque, au sens organisationnel : une AIPD peut être orientée pour justifier un traitement déjà décidé. Contre-mesure : l’avis du DPO consigné tel quel, et une validation par un responsable qui n’est pas le porteur du projet.

Conditions d’exploitation : outil PIA, versionnement et réexamen

Outillage. La CNIL met à disposition le logiciel PIA (Privacy Impact Assessment), libre, qui suit sa méthode et produit un dossier structuré selon les blocs de l’article 35.7. Il fait gagner du temps sur la forme et n’en fait gagner aucun sur le fond : il ne connaît ni les flux, ni les supports, ni les durées réelles. Les gabarits de traitement fournis servent de point de départ pour les cas courants, à condition de réécrire chaque ligne pour le traitement analysé.

Stockage et sauvegarde. L’AIPD décrit les vulnérabilités d’un traitement sensible : c’est un document à diffusion restreinte, versionné, sauvegardé avec la documentation du projet. Un dépôt versionné rattaché au code du traitement permet de relier une évolution d’architecture à une révision d’AIPD.

Réexamen. L’article 35.11 impose un réexamen au moins quand le risque change. Déclencheurs concrets à brancher sur les processus existants : ajout d’une catégorie de données ou d’une finalité, nouveau sous-traitant ou changement de localisation, nouveau croisement de jeux de données, ajout d’une décision automatisée, incident de sécurité ou violation de données sur le traitement, évolution de la liste CNIL ou des lignes directrices. Le plus fiable consiste à inscrire « impact AIPD ? » comme question obligatoire du processus de gestion des changements, plutôt que de compter sur la mémoire d’une équipe qui aura changé entre-temps.

Supervision. Les mesures promises dans l’AIPD deviennent des indicateurs : taux de purge effective, revues d’habilitations réalisées, alertes sur consultations anormales. Une mesure non supervisée est une hypothèse.

Dérives fréquentes : l’AIPD de façade

Vingt ans de projets apprennent que l’AIPD la plus courante est celle rédigée la semaine de la mise en production, par la personne qui a le moins participé à la conception, à partir du gabarit le plus proche. Ses symptômes se repèrent vite :

Remplie après coup : les mesures décrivent l’existant, aucune n’a été ajoutée ; le risque résiduel est toujours « limité ». Une AIPD qui n’a jamais rien changé n’a jamais rien analysé.
Copiée d’un projet à l’autre : les sous-traitants cités ne sont pas ceux du projet, les durées de conservation sont celles d’un autre traitement, et parfois le nom de l’application précédente traîne en page quatre. Le logiciel PIA exporte très bien le travail des autres.
Jamais relue : la version validée décrit une architecture abandonnée depuis deux migrations ; aucun déclencheur de réexamen n’a été branché.
Écrite pour l’organisation : gravités exprimées en image de marque et en sanctions plutôt qu’en conséquences pour les personnes.

La remédiation est la même pour toutes : rattacher l’AIPD au cycle du projet (une version par jalon d’architecture), faire signer l’avis du DPO sur la version finale et non sur un brouillon, et contrôler par sondage que les mesures décrites existent dans le système.

Exemple : déroulé d’une AIPD, de la décision à la consultation préalable

Le schéma suit une AIPD de bout en bout. Les branches importantes sont au début (faut-il la mener ?) et à la fin (le risque résiduel est-il acceptable ?).

Trois points à lire dans ce flux. La décision de ne pas mener d’AIPD est elle-même tracée : en cas de contrôle, c’est elle qu’on demandera de justifier. La boucle entre mesures et évaluation est le cœur de la démarche : chaque mesure qui modifie l’architecture (chiffrement de champ, réduction de la conservation, retrait d’un sous-traitant) relance l’évaluation des risques concernés. Enfin, la consultation préalable de l’article 36 n’est pas une sanction : quand le risque résiduel reste élevé, le traitement ne démarre pas avant l’avis de l’autorité, qui dispose de huit semaines pour répondre, délai prolongeable de six semaines selon la complexité (article 36.2). Prévoir ce délai dans le planning évite de découvrir l’article 36 la veille du lancement.

🐝 Ce qui arrive si on s’en passe

Sans AIPD, aucun document ne fixe à l’avance la gravité d’une violation pour les personnes concernées. Le jour d’un incident, il faut reconstruire cette évaluation dans le délai de 72 heures de l’article 33. Or c’est elle qui détermine l’obligation d’informer les personnes (article 34). Sans description préalable des flux et des supports, il devient difficile d’établir quelles catégories de données ont fui et combien de personnes sont touchées. Il est tout aussi difficile de savoir quelles copies sont concernées : exports, sauvegardes, environnements de test, sous-traitants. Le périmètre notifié risque alors d’être sous-estimé, puis corrigé par notifications successives. Les risques jamais évalués restent par ailleurs acceptés sans décision écrite : aucune trace ne permet de distinguer un choix assumé d’un oubli, ni de rattacher une mesure au danger qu’elle devait réduire.

🦫 Explication de la marmotte 🍫

Quand une entreprise ou une administration veut utiliser des informations sur des personnes (leurs déplacements, leur travail, leurs achats), la loi européenne sur les données personnelles l’oblige parfois à faire une étude avant de commencer. On la fait quand l’usage peut sérieusement nuire aux gens : surveiller beaucoup de monde, noter des personnes, mélanger plusieurs fichiers, traiter des personnes fragiles.

L’étude se déroule dans un ordre précis. D’abord, on décrit ce qu’on veut faire : quelles informations, pour quoi faire, combien de temps, qui les voit. Ensuite, on vérifie que chaque information est vraiment nécessaire. Puis on cherche ce qui pourrait mal tourner pour les personnes : quelqu’un lit leurs données sans droit, les données sont modifiées par erreur, ou elles disparaissent. Pour chaque danger, on choisit des protections : collecter moins, effacer plus tôt, limiter qui peut regarder, garder une trace des consultations, rendre les données illisibles sans clé.

Le responsable de la protection des données donne son avis par écrit. Si, malgré les protections, le danger reste grand, il faut demander l’avis de l’autorité publique avant de démarrer.

Ça échoue quand l’étude est écrite une fois tout construit, recopiée d’un autre projet ou jamais mise à jour : elle ne change alors rien, et les personnes restent exposées.

Pages voisines

La citent

AIPD RGPD article 35 : méthode, critères et impact sur l'architecture

Elle cite

: les deux pages se citent l’une l’autre.