AIPD : pourquoi l’analyse RGPD doit partir de l’architecture réelle du SI

Une analyse d’impact relative à la protection des données peut être parfaitement documentée et pourtant décrire imparfaitement le système qui traite réellement les données.

Le problème apparaît lorsque l’AIPD est construite principalement à partir de descriptions fonctionnelles : finalité du traitement, catégories de données, personnes concernées, durées de conservation, mesures de sécurité prévues. Ces informations sont indispensables. Mais elles ne disent pas toujours par où passent réellement les données, quelles applications les manipulent, où elles sont stockées et de quels services techniques le traitement dépend.

En avril 2026, le Comité européen de la protection des données (CEPD) a présenté un modèle commun d’AIPD destiné à structurer, harmoniser et documenter la démarche. Son utilisation n’est pas obligatoire et, au 17 septembre 2026, la page officielle indique toujours que le modèle doit être finalisé après la consultation publique.12

Pour les organisations, cela remet en lumière une question très opérationnelle : peut-on analyser correctement les risques d’un traitement si l’on ne connaît pas précisément son architecture ?

Une AIPD n’est pas seulement un document juridique

L’article 35 du RGPD prévoit une analyse d’impact lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés des personnes. Elle doit notamment comporter une description systématique des opérations, une analyse de leur nécessité et de leur proportionnalité, une évaluation des risques et les mesures prévues pour y répondre.4

La CNIL distingue trois composantes : la description détaillée du traitement dans ses aspects techniques et opérationnels, l’analyse de nécessité et de proportionnalité, puis l’étude technique des risques sur la confidentialité, l’intégrité et la disponibilité des données.3

Une formule telle que « les données sont hébergées dans le cloud et accessibles uniquement aux personnes autorisées » reste donc trop abstraite pour comprendre l’exposition technique d’un traitement.

Passer du traitement déclaré au traitement réellement déployé

Prenons un système RH utilisant une solution d’intelligence artificielle pour assister l’analyse de candidatures. Sur le plan fonctionnel : Candidat → données de candidature → analyse → résultat utilisé par les RH.

L’architecture réelle peut être plus longue : Candidat → portail de recrutement → API → service d’IA → base de données → stockage documentaire → outil RH → fournisseur d’identité → journalisation → sauvegarde.

Plusieurs prestataires peuvent intervenir. Certaines données peuvent traverser plusieurs environnements. Une sauvegarde peut se trouver dans une région différente de la base principale. Des journaux techniques peuvent contenir des identifiants ou des informations issues des requêtes. Une API externe peut participer au traitement sans apparaître dans sa description fonctionnelle initiale.

L’AIPD gagne donc à confronter deux représentations : ce que le traitement est censé faire et ce que l’architecture fait réellement.

L’architecture apporte une information que le registre ne contient pas nécessairement

Le registre des traitements et l’AIPD ne remplissent pas la même fonction. Une cartographie technique peut apporter des informations complémentaires : applications participant réellement au traitement, flux, API, systèmes de stockage, services d’identité, prestataires techniques, infrastructures, sauvegardes et dépendances partagées.

L’objectif n’est pas de transformer une cartographie SI en AIPD. Il est de permettre à l’AIPD de s’appuyer sur une représentation vérifiable de la réalité technique.

Approfondir
RGPD : cartographie SI et registre des traitements, deux outils différents mais complémentaires →

Une chaîne utile : de la finalité jusqu’à l’infrastructure

Une façon de structurer cette relation consiste à descendre progressivement vers les composants techniques : Finalité → traitement → données → application → flux → stockage → infrastructure → tiers → mesures de sécurité.

Chaque niveau répond à une question différente : pourquoi les données sont-elles traitées ? quelles opérations sont réalisées ? quels systèmes les manipulent ? où circulent-elles et persistent-elles ? quelles dépendances et quels tiers interviennent ? quels contrôles protègent concrètement l’ensemble ?

Cette chaîne ne remplace pas la méthode d’analyse de risque. Elle aide à tester la cohérence de la description sur laquelle cette analyse repose.

Exemple : l’assistant RH utilisant une IA

L’entreprise indique dans son AIPD que les CV sont utilisés pour assister l’analyse des candidatures. Une première description identifie le traitement, les candidats concernés et les données utilisées.

L’analyse de l’architecture révèle ensuite un portail de recrutement, une application RH, un stockage documentaire, une API d’IA, un fournisseur d’identité, une plateforme de journalisation et une infrastructure de sauvegarde.

Il ne s’agit plus uniquement de savoir si l’entreprise protège les CV. Il faut comprendre tous les endroits où les informations issues des CV peuvent être présentes : l’API conserve-t-elle les requêtes ? les journaux contiennent-ils des données ? les sauvegardes suivent-elles les mêmes règles de conservation ? quels administrateurs peuvent accéder au stockage ? comment une demande d’effacement se propage-t-elle ?

L’architecture ne répond pas seule à ces questions. Mais elle permet de savoir où les poser.

Le flux de données devient un objet central de l’AIPD

Une donnée personnelle est collectée, transmise, transformée, copiée, stockée, sauvegardée puis éventuellement supprimée. Pour certains traitements, il est donc utile de suivre le parcours collecte → transfert → traitement → stockage → réutilisation → archivage ou suppression.

Une donnée peut être correctement protégée dans l’application principale mais apparaître dans un export temporaire ; être chiffrée dans une base mais copiée dans un journal ; être supprimée du système opérationnel mais subsister dans certaines sauvegardes.

L’analyse des flux complète ainsi l’analyse du traitement.

Les dépendances invisibles peuvent modifier le risque

Une application peut dépendre d’un fournisseur d’identité, d’un gestionnaire de secrets, d’un service DNS, d’un stockage objet, d’un service de sauvegarde, d’une API tierce, d’un outil de supervision ou d’une plateforme cloud.

Une défaillance ou une compromission de l’un de ces composants peut affecter la confidentialité, l’intégrité ou la disponibilité des données sans que le composant soit visible dans la description métier initiale. Une représentation d’architecture sert précisément à faire apparaître les dépendances qui ne sont pas évidentes depuis le traitement lui-même.

Une mesure de sécurité doit pouvoir être reliée à quelque chose de concret

« Chiffrement des données », « contrôle des accès », « sauvegardes régulières » ou « journalisation » sont des mesures pertinentes, mais leur formulation générique ne dit pas toujours ce qu’elles couvrent.

Le chiffrement concerne-t-il également les sauvegardes ? L’authentification multifacteur protège-t-elle utilisateurs métier, administrateurs et comptes techniques ? La journalisation couvre-t-elle les accès aux données sensibles ?

Une mesure devient plus exploitable lorsqu’elle peut être reliée aux composants qu’elle protège : mesure → composant → donnée → risque.

Le changement d’architecture doit déclencher une question RGPD

La CNIL présente l’AIPD comme une démarche utile avant la mise en œuvre d’un traitement, mais également pour assurer le suivi des risques dans le temps.5

Or le SI évolue : changement d’hébergeur, remplacement d’une API, nouveau fournisseur d’IA, migration de base, ajout d’une réplication ou passage d’un service interne en SaaS.

La gouvernance peut donc fonctionner dans l’autre sens : changement d’architecture → identification des traitements concernés → vérification de l’impact RGPD → révision éventuelle de l’AIPD.

Six changements techniques constituent de bons déclencheurs de revue : ajout d’un fournisseur, modification du lieu d’hébergement, nouveau flux de données personnelles, nouvelle application ou API, modification significative des mécanismes d’accès, nouvelle copie ou sauvegarde des données.

Ils ne conduisent pas automatiquement à modifier l’AIPD. Ils justifient en revanche une vérification.

Les cinq questions à poser à l’architecture avant de valider une AIPD

1. Pouvons-nous identifier toutes les applications qui manipulent les données ?
2. Savons-nous où les données circulent et où elles persistent ?
3. Connaissons-nous les dépendances et prestataires nécessaires au traitement ?
4. Les mesures de sécurité documentées couvrent-elles réellement tous ces composants ?
5. Sommes-nous capables de détecter lorsqu’un changement technique rend l’analyse obsolète ?

L’AIPD et la cartographie répondent à deux questions complémentaires

L’AIPD cherche à déterminer si un traitement présentant des risques élevés est conçu et maîtrisé de manière à protéger les droits et libertés des personnes. L’architecture décrit comment les systèmes nécessaires à ce traitement sont réellement organisés.

L’une ne remplace pas l’autre. Mais lorsqu’une AIPD repose sur une représentation technique trop abstraite, l’analyse risque de porter sur le système que l’organisation pense avoir, plutôt que sur celui qui traite effectivement les données.

Le modèle européen présenté en 2026 fournit une occasion de revoir cette articulation. La question à ajouter aux ateliers RGPD pourrait finalement être simple : « Montrez-nous maintenant par où passent réellement les données. »