Demandez à une équipe vie privée où se trouvent les données personnelles et vous obtiendrez un tableur. Demandez à l'ingénierie et vous obtiendrez un diagramme d'architecture qui ne mentionne jamais les données personnelles. Les deux sont incomplets : le tableur ne peut pas montrer comment les données circulent, et le diagramme d'architecture ne dit pas ce qui circule ni pourquoi.
Le diagramme de cartographie des données RGPD est l'endroit où les deux se rejoignent. Ce guide présente ce qu'une cartographie doit consigner, une méthode pour la construire et une cartographie complète pour un produit SaaS typique. Il ne s'agit pas d'un conseil juridique : c'est votre référent vie privée ou votre avocat qui décide des bases légales, des mécanismes de transfert et des durées de conservation.
Cartographie des données et registre des activités de traitement
L'article 30 du RGPD impose à chaque responsable du traitement de tenir un registre des activités de traitement qui contient :
- le nom et les coordonnées du responsable du traitement et, le cas échéant, de son représentant et du délégué à la protection des données ;
- les finalités du traitement ;
- les catégories de personnes concernées et de données personnelles ;
- les catégories de destinataires, y compris les destinataires dans des pays tiers ;
- les transferts vers des pays tiers et, pour certains, les documents attestant des garanties ;
- dans la mesure du possible, les délais d'effacement ;
- dans la mesure du possible, une description générale des mesures de sécurité.
Les sous-traitants tiennent un registre similaire des traitements qu'ils effectuent pour chaque responsable. L'article 30, paragraphe 5, exempte les organisations de moins de 250 salariés, mais seulement si le traitement n'est pas susceptible de comporter un risque pour les droits des personnes, s'il est occasionnel et s'il ne porte ni sur des catégories particulières de données ni sur des données relatives aux condamnations pénales. Une entreprise SaaS qui traite des données clients tous les jours remplit rarement ces conditions. Le législateur européen a débattu d'un relèvement de ce seuil : vérifiez donc le texte en vigueur avant de vous y fier.
Le registre est un tableau. La cartographie des données est la façon de découvrir ce qui doit y figurer, puis de vérifier que c'est toujours exact.
Ce qu'il faut consigner pour chaque flux
| Élément | Exemple tiré d'un produit SaaS |
|---|---|
| Personnes concernées | Utilisateurs clients, administrateurs de compte, prospects, contacts du support |
| Catégories de données personnelles | Données de compte, contacts de facturation, événements d'usage, messages au support |
| Catégories particulières | Données de santé, biométriques ou autres données de l'article 9 ; signalez-les clairement s'il y en a |
| Finalité | Fournir le service, facturer, analyser l'usage du produit, envoyer des e-mails de service |
| Base légale | Décidée par l'équipe vie privée pour chaque finalité : contrat, intérêts légitimes, consentement |
| Systèmes | Où les données sont stockées ou traitées |
| Destinataires | Les sous-traitants qui agissent pour votre compte, et les autres responsables du traitement |
| Transferts | Destination hors de l'EEE et garantie utilisée |
| Conservation | Combien de temps chaque stockage garde les données, et comment elles sont supprimées |
Une méthode qui fonctionne
- Inventoriez les systèmes. Partez de ce que vous pouvez lister : comptes cloud, bases de données, outils SaaS issus de l'authentification unique (SSO) et des paiements fournisseurs de l'équipe finance. C'est là qu'apparaissent les outils fantômes.
- Suivez un parcours utilisateur à la fois. Inscription, facturation, usage quotidien du produit, un ticket de support, un e-mail marketing. Dessinez où les données entrent, où elles sont stockées et où elles vont ensuite.
- Interrogez les propriétaires des systèmes. Pour chaque système : quels champs, pour quoi faire, qui les reçoit et combien de temps ils sont conservés.
- Repérez les sous-traitants et les transferts. Notez où chaque fournisseur traite les données, si un accord de sous-traitance (DPA) est en place et quelle garantie couvre chaque transfert hors de l'EEE.
- Ajoutez la conservation et la suppression. Un stockage sans durée de conservation constitue en soi un constat.
- Relisez avec l'équipe vie privée et tirez le registre de l'article 30 de la cartographie.
Transferts hors de l'EEE
Le chapitre V du RGPD, articles 44 à 49, n'autorise les transferts vers des pays tiers que sur certains fondements. Les plus courants pour une entreprise SaaS :
- Une décision d'adéquation. La Commission européenne publie la liste des pays dont elle juge la protection adéquate. Pour les États-Unis, la décision de juillet 2023 couvre les entreprises qui participent au Data Privacy Framework UE–États-Unis (DPF). Le Tribunal de l'Union européenne l'a confirmée en septembre 2025, et un pourvoi a été formé devant la Cour de justice en octobre 2025 : vérifiez donc son statut avant de vous y fier.
- Les clauses contractuelles types. Les clauses contractuelles types (CCT) adoptées par la Commission en 2021 sont la garantie contractuelle habituelle lorsqu'aucune décision d'adéquation ne s'applique.
- D'autres garanties et dérogations, comme les règles d'entreprise contraignantes ou le consentement explicite, pour des cas plus restreints.
Sur la cartographie, un transfert est un lien qui quitte votre région, étiqueté avec la destination et la garantie.
L'exemple complet : un produit SaaS B2B
Le produit tourne dans une région cloud de l'UE : une application web, une base de données PostgreSQL et un entrepôt de données analytique. Cinq fournisseurs reçoivent des données personnelles : l'envoi d'e-mails et les paiements dans l'EEE, et l'analytique produit, un service d'assistance et un CRM aux États-Unis.
Contenu du diagramme
- Customer user
- Our systems · EU region
- Web app
- App database
- Analytics warehouse
- Processors in the EEA
- Email delivery
- Payment provider
- Processors in the US · transfers
- Product analytics
- Support desk
- CRM
- account, billing, usage
- account, workspace, billing status
- usage events, pseudonymous IDs
- name, email, message
- billing contact, invoices
- pseudonymous ID, events · DPF
- name, email, tickets · SCCs
- admin contacts, plan · DPF
Comment le lire :
- Entrée. Les utilisateurs clients créent des comptes, paient, utilisent le produit et écrivent au support. Chaque flux qui part de l'application web est étiqueté avec les catégories de données qu'il transporte.
- Vos systèmes, région UE. La base de données de l'application contient les données de compte et d'espace de travail. L'entrepôt reçoit les événements d'usage avec des identifiants pseudonymes, pas des noms.
- Sous-traitants dans l'EEE. L'envoi d'e-mails reçoit des noms, des adresses e-mail et le contenu des messages ; les paiements reçoivent les contacts de facturation et les factures. Aucun transfert n'est en jeu.
- Sous-traitants aux États-Unis. Chaque lien qui entre dans ce cadre est un transfert et porte sa garantie : DPF pour les fournisseurs certifiés au titre du framework, CCT (SCCs sur le diagramme) pour celui qui ne l'est pas.
- La légende explique les étiquettes et donne des exemples de durées de conservation par stockage.
Des conventions de dessin qui aident
- Étiquetez les liens avec des catégories de données, pas avec des technologies. « Nom, e-mail, contenu du ticket » aide un relecteur ; « API REST » non.
- Tracez une frontière autour de vos propres systèmes, et placez les sous-traitants à l'extérieur, regroupés par région.
- Signalez chaque transfert avec la destination et la garantie.
- Mettez en évidence les catégories particulières de données avec une seule couleur, toujours la même, et indiquez sa signification dans la légende.
- Écrivez la durée de conservation sur chaque stockage. C'est l'élément qui manque le plus souvent dans les registres des traitements.
- Gardez les finalités et les bases légales dans le registre, à côté du diagramme. Le diagramme montre où ; le registre dit pourquoi.
La garder à jour
Une cartographie des données est périmée le jour où quelqu'un ajoute un fournisseur. Liez les mises à jour aux événements qui la modifient : l'arrivée d'un nouveau fournisseur, les nouvelles fonctionnalités qui collectent de nouvelles données et les analyses d'impact relatives à la protection des données. En vertu de l'article 35, un responsable du traitement doit évaluer un traitement susceptible d'engendrer un risque élevé avant de le mettre en œuvre, et la cartographie est le point de départ naturel de cette analyse. Revoyez l'ensemble de la cartographie une fois par an et conservez la version précédente. Des diagrammes d'architecture qui ne se périment pas décrit un workflow pour exactement cela, et intégrer le diagramme en direct dans le wiki vie privée garde tout le monde sur la même version.
Comment la cartographie aide pour les demandes des personnes concernées
Une demande d'accès ou d'effacement doit couvrir tous les endroits où se trouvent les données d'une personne : la base de données de l'application, l'entrepôt, les sauvegardes et chaque sous-traitant. Avec une cartographie à jour, répondre devient une checklist plutôt qu'une recherche. Les sous-traitants sont contractuellement tenus d'aider à traiter ces demandes, et la cartographie vous dit lesquels solliciter.
Pour une vue sécurité des mêmes flux, voyez les diagrammes de flux de données pour la modélisation des menaces.
Le construire dans Archboard
- Connectez-vous avec Google ou GitHub et créez un diagramme.
- Ajoutez une Personne du pack Modèle C4 pour l'utilisateur client.
- Ajoutez un Cadre du pack Base pour vos systèmes de la région UE, avec un Conteneur du pack Modèle C4 pour l'application web, un Postgres du pack Données pour la base de l'application et un Entrepôt de données du pack Données pour l'analytique.
- Ajoutez deux autres nœuds Cadre du pack Base pour les sous-traitants, un pour l'EEE et un pour les États-Unis, avec un nœud Système externe du pack Modèle C4 pour chaque rôle de fournisseur.
- Étiquetez chaque lien avec les catégories de données qu'il transporte, et ajoutez la garantie sur chaque lien qui entre dans le cadre États-Unis.
- Ajoutez un bloc Markdown du pack Base avec la légende et les durées de conservation.
L'exemple utilise 13 nœuds de diagramme et reste dans les limites de l'offre Free. Le cas d'usage de la cartographie des données RGPD montre d'autres façons d'organiser une cartographie.
FAQ
Le RGPD impose-t-il une cartographie des données ? Le RGPD impose le registre des activités de traitement de l'article 30, pas un diagramme. La plupart des équipes constatent qu'elles ne peuvent ni construire ni tenir à jour un registre exact sans cartographier d'abord les flux.
Qui doit être propriétaire de la cartographie des données ? L'équipe vie privée possède le registre et les décisions qu'il contient ; l'ingénierie possède les systèmes. Donnez au diagramme un propriétaire de chaque côté et relisez-le ensemble.
La cartographie doit-elle montrer chaque table de base de données ? Non. Montrez les stockages et les catégories de données qu'ils contiennent. Le détail au niveau des tables a sa place dans un catalogue de données.
Comment représenter un fournisseur à la fois sous-traitant et responsable du traitement ? Dessinez-le une seule fois et étiquetez son rôle pour chaque flux. Certains prestataires, comme les prestataires de paiement, agissent en tant que responsables du traitement pour une partie de leurs traitements ; leurs contrats précisent lesquelles.
Le diagramme peut-il remplacer le registre de l'article 30 ? Non. Le registre doit contenir par écrit des informations précises, dont les finalités et les mesures de sécurité. Utilisez le diagramme pour construire et vérifier le registre.