Protection de la vie privée dès la conception et RGPD

La vie privée est une propriété de conception

La sécurité et la protection de la vie privée se recoupent mais ne sont pas la même chose. La sécurité demande si les données sont protégées contre les personnes qui ne devraient pas y avoir accès. La protection de la vie privée demande aussi si l’organisation elle-même devrait collecter ces données ou non, ce qu’elle a le droit d’en faire, pendant combien de temps, et quel contrôle conserve la personne qu’elles décrivent. Un système peut n’avoir subi aucune violation et pourtant porter atteinte à la vie privée, par exemple en conservant indéfiniment l’historique de positions de chaque livreur ou en réutilisant discrètement les historiques de commandes pour entraîner un modèle de tarification.

La plateforme de livraison de repas montre bien pourquoi la protection de la vie privée relève de l’architecture. Elle détient des noms, des numéros de téléphone et des adresses personnelles ; des historiques de commandes qui peuvent révéler la religion ou l’état de santé à travers les choix alimentaires ; des références de paiement ; et un flux continu de positions des livreurs. Ces données circulent depuis les applications à travers des dizaines de services, d’événements, de caches, de journaux, de stockages analytiques et de sauvegardes, et jusqu’à des sous-traitants comme le prestataire de paiement, la passerelle SMS et le SaaS du service d’assistance. Les décisions sur l’endroit où sont stockées les données à caractère personnel, sur la clé qui les identifie et sur la façon de les retrouver et de les supprimer coûtent cher à changer plus tard, ce qui est exactement le critère de ce qui est architecturalement significatif.

Le droit en bref : le RGPD et le RGPD britannique

Le règlement général sur la protection des données, règlement (UE) 2016/679, s’applique depuis le 25 mai 2018. Il protège les données à caractère personnel, que l’article 4, point 1, définit comme toute information se rapportant à une personne physique identifiée ou identifiable, directement ou indirectement, notamment par référence à un nom, à un numéro d’identification, à des données de localisation ou à un identifiant en ligne. Le responsable du traitement détermine les finalités et les moyens du traitement et en porte la responsabilité première ; un sous-traitant traite des données pour le compte du responsable du traitement en vertu d’un contrat (article 28), comme le fait la passerelle SMS de la plateforme. Le RGPD s’applique aux organisations établies dans l’Union et, en vertu de l’article 3, aux autres organisations qui offrent des biens ou des services à des personnes se trouvant dans l’Union ou qui suivent leur comportement.

Au Royaume-Uni, le RGPD a été maintenu après le Brexit sous le nom de RGPD britannique (UK GDPR), qui s’applique conjointement avec le Data Protection Act 2018. Le Data (Use and Access) Act 2025 a modifié l’un et l’autre ; la plupart de ses modifications relatives à la protection des données sont entrées en vigueur le 5 février 2026, notamment celles qui touchent les fondements juridiques, la prise de décision automatisée et les transferts internationaux, et l’obligation pour les responsables du traitement de traiter les plaintes relatives à la protection des données s’applique à partir du 19 juin 2026. La Commission européenne a renouvelé ses décisions d’adéquation concernant le Royaume-Uni en décembre 2025, de sorte que les données à caractère personnel peuvent continuer à circuler de l’UE vers le Royaume-Uni sans garanties supplémentaires. Pour les architectes, les deux régimes partagent les mêmes principes, les mêmes droits et les mêmes obligations de conception ; les différences sont des questions de détail pour les juristes.

Les amendes maximales pour les manquements les plus graves s’élèvent à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial au titre du RGPD (17,5 millions de livres sterling ou 4 % au titre du RGPD britannique), le montant le plus élevé étant retenu, mais les conséquences les plus fréquentes sont des injonctions de cesser le traitement, une atteinte à la réputation et le coût d’une refonte technique. En novembre 2025, la Commission européenne a proposé des modifications du RGPD dans le cadre d’un paquet omnibus numérique ; à la date de rédaction, elles suivent encore la procédure législative et ne changent encore rien.

Les fondements juridiques, en bref

L’article 6 n’autorise le traitement que sur l’un des six fondements juridiques : le consentement, l’exécution d’un contrat avec la personne, une obligation légale, la sauvegarde des intérêts vitaux, une mission d’intérêt public, ou des intérêts légitimes sur lesquels ne prévalent pas les intérêts et les droits de la personne. Les catégories particulières de données, comme la santé ou les convictions religieuses, exigent une condition supplémentaire au titre de l’article 9. Le fondement se choisit par finalité, non par système, et il change ce que l’architecture doit faire. Sur la plateforme de livraison de repas, l’adresse de livraison est traitée pour exécuter le contrat ; les factures sont conservées pour respecter une obligation légale découlant du droit fiscal ; la détection de la fraude repose généralement sur les intérêts légitimes ; et les e-mails marketing nécessitent normalement le consentement, que les règles sur la prospection électronique encadrent également.

Le consentement obéit aux mécanismes les plus stricts. En vertu de l’article 7, le responsable du traitement doit être en mesure de démontrer que le consentement a été donné, celui-ci doit être spécifique à une finalité, et il doit être aussi simple de le retirer que de le donner. Le consentement ne peut donc pas être une simple colonne booléenne : le système a besoin d’un enregistrement en ajout seul (append-only) de ce à quoi la personne a consenti, quand, par quel canal et en réponse à quelle formulation, et chaque consommateur doit honorer rapidement un retrait.

{
  "event": "ConsentGiven",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "noticeVersion": "privacy-notice-2026-09",
  "wording": "Send me offers from restaurants near me",
  "channel": "ios-app 7.3.0",
  "method": "unticked checkbox, user ticked",
  "at": "2026-10-03T18:22:41Z"
}
{
  "event": "ConsentWithdrawn",
  "subjectRef": "cust_4411",
  "purpose": "marketing_email",
  "channel": "email unsubscribe link",
  "at": "2026-10-19T07:05:12Z"
}

Protection des données dès la conception et par défaut

L’article 25 fait de la protection de la vie privée dès la conception une obligation légale. L’article 25, paragraphe 1, la protection des données dès la conception, impose au responsable du traitement, tant au moment de déterminer les moyens du traitement qu’au moment du traitement lui-même, de mettre en œuvre des mesures techniques et organisationnelles appropriées, telles que la pseudonymisation, destinées à appliquer les principes, compte tenu de l’état des connaissances, des coûts, de la nature et des finalités du traitement et des risques. L’article 25, paragraphe 2, la protection par défaut, exige que seules les données nécessaires au regard de chaque finalité spécifique soient traitées par défaut, ce qui s’applique à la quantité de données collectées, à l’étendue de leur traitement, à leur durée de conservation et à leur accessibilité ; en particulier, les données ne doivent pas être rendues accessibles à un nombre indéterminé de personnes sans l’intervention de la personne concernée. Les lignes directrices 4/2019 du comité européen de la protection des données relatives à l’article 25 donnent des exemples pratiques.

Le droit a emprunté l’idée à Ann Cavoukian, commissaire à l’information et à la protection de la vie privée de l’Ontario, qui a élaboré la protection de la vie privée dès la conception dans les années 1990 et en a publié les sept principes fondamentaux en 2009 ; la conférence internationale des commissaires à la protection des données les a adoptés en 2010. Ils restent une liste de contrôle utile pour les revues de conception.

Les droits que l’architecture doit prendre en charge

C’est par les droits des personnes concernées que le droit de la protection de la vie privée se traduit le plus directement en exigences pour les systèmes. Un responsable du traitement doit normalement répondre dans un délai d’un mois à compter de la réception d’une demande, délai qui peut être prolongé de deux mois au plus pour les demandes complexes ou nombreuses (article 12, paragraphe 3), et doit être capable de retrouver les données de la personne où qu’elles se trouvent. Dans un système de vingt services, cinq sous-traitants SaaS et un entrepôt de données, c’est impossible sans une cartographie des données tenue à jour : le registre des activités de traitement qu’exige déjà l’article 30, conservé assez près du code pour rester exact. Avec les modifications britanniques de 2025, un responsable du traitement qui répond à une demande d’accès n’est tenu d’effectuer que des recherches raisonnables et proportionnées, ce qu’une bonne cartographie des données rend rapide.

Les analyses d’impact relatives à la protection des données

L’article 35 exige une analyse d’impact relative à la protection des données (AIPD) avant tout traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes, en particulier l’évaluation systématique et approfondie, y compris le profilage, produisant des effets significatifs, le traitement à grande échelle de catégories particulières de données ou de données relatives aux condamnations pénales et aux infractions, et la surveillance systématique à grande échelle d’une zone accessible au public. Les autorités de contrôle publient des listes d’autres cas ; le suivi continu de la position des livreurs et la gestion algorithmique de leur travail en sont des exemples typiques. Une AIPD décrit le traitement et ses finalités, évalue sa nécessité et sa proportionnalité, évalue les risques pour les personnes et consigne les mesures envisagées pour y faire face ; si un risque élevé subsiste, le responsable du traitement doit consulter l’autorité de contrôle avant de commencer (article 36).

Les architectes devraient traiter l’AIPD comme le pendant, pour la vie privée, du modèle de menaces de la section 8.2, réalisée au même moment et sur le même diagramme de flux de données. Le cadre LINDDUN, développé à la KU Leuven, fait pour les menaces sur la vie privée ce que STRIDE fait pour les menaces de sécurité, avec des catégories comme l’association (linking), l’identification, la détection, la divulgation de données et la méconnaissance (unawareness). Les conclusions de l’AIPD deviennent des exigences architecturales, comme les historiques de positions sont supprimés 30 jours après la livraison, qui peuvent être testées.

Transferts internationaux et résidence des données

Le chapitre V du RGPD encadre les transferts de données à caractère personnel vers des pays situés hors de l’Espace économique européen. Un transfert est licite si la Commission a constaté que le pays assure un niveau de protection adéquat (article 45), si des garanties appropriées comme les clauses contractuelles types de la Commission sont en place (article 46), ou au titre de dérogations limitées (article 49). Depuis que la Cour de justice a invalidé le bouclier de protection des données UE–États-Unis (Privacy Shield) par l’arrêt Schrems II de juillet 2020, les transferts fondés sur des clauses contractuelles nécessitent une évaluation de la législation du pays de destination ; le cadre de protection des données UE–États-Unis (Data Privacy Framework), jugé adéquat en juillet 2023, couvre les transferts vers les entreprises américaines qui y adhèrent par certification, et a résisté à un premier recours devant le Tribunal de l’Union européenne en septembre 2025 (Latombe/Commission), même si d’autres contentieux, y compris un éventuel pourvoi devant la Cour de justice, pourraient encore changer la situation.

Deux points d’architecture en découlent. Premièrement, un transfert n’est pas seulement une base de données dans une autre région : l’accès à distance par une équipe d’assistance à l’étranger, les sous-traitants ultérieurs d’un sous-traitant SaaS et un service de journalisation hébergé ailleurs comptent tous, si bien que la cartographie des données doit indiquer où les données sont stockées et d’où on y accède. Deuxièmement, les exigences de résidence des données, qu’elles soient légales, contractuelles ou choisies, sont plus faciles à satisfaire avec des cellules de déploiement régionales : chaque région détient les données à caractère personnel et les clés de ses clients, les services globaux ne voient que des références pseudonymes, et la réplication entre régions est explicite et revue. Ajouter après coup la résidence des données à une base de données mondiale unique est l’un des changements les plus coûteux qu’une plateforme puisse affronter, c’est pourquoi elle fait partie des contraintes à recueillir tôt.

Minimisation, pseudonymisation et anonymisation

Les données à caractère personnel les moins chères à protéger sont celles que vous ne collectez jamais. La minimisation se manifeste dans de petites décisions : un indicateur « plus de 18 ans » au lieu d’une date de naissance, un secteur postal au lieu de l’adresse complète pour l’analytique, un numéro de téléphone masqué relayé par la plateforme au lieu de révéler le numéro du client au livreur, et un échantillonnage de la position seulement pendant qu’une livraison est en cours.

La pseudonymisation (article 4, point 5) traite les données de façon qu’elles ne puissent plus être attribuées à une personne sans recourir à des informations supplémentaires, comme une clé, conservées séparément et protégées. Un hachage à clé (HMAC) de l’identifiant client, dont la clé est détenue par l’équipe chargée des comptes, permet à l’équipe analytique de compter les commandes par client sans voir qui sont les clients. C’est une garantie précieuse que l’article 25 cite expressément, mais le considérant 26 indique clairement que des données pseudonymisées qui pourraient être attribuées à une personne par le recours à des informations supplémentaires restent des données à caractère personnel. Dans l’affaire CEPD/CRU (en anglais EDPS v SRB, C-413/23 P, 4 septembre 2025), la Cour de justice a apporté une nuance : le caractère personnel des données s’apprécie du point de vue de celui qui les détient, si bien que des données pseudonymisées peuvent ne pas être des données à caractère personnel pour un destinataire qui n’a aucun moyen raisonnable de réidentifier qui que ce soit, bien qu’elles restent des données à caractère personnel pour le responsable du traitement qui détient la clé, et que celui-ci doive toujours informer les personnes de l’existence de tels destinataires. Les lignes directrices 01/2025 du comité européen de la protection des données sur la pseudonymisation décrivent comment bien la mettre en œuvre.

L’anonymisation va plus loin : les données ne se rapportent plus à une personne identifiable, compte tenu de l’ensemble des moyens raisonnablement susceptibles d’être utilisés pour identifier quelqu’un, et le RGPD ne s’applique alors plus. Une véritable anonymisation est difficile. Retirer les noms ne suffit pas quand la combinaison du code postal, de la date de naissance et du sexe identifie la plupart des personnes, ou quand l’historique de positions d’un seul livreur révèle où il habite. L’agrégation avec masquage des petits effectifs, la généralisation et, pour les statistiques, la confidentialité différentielle sont les techniques habituelles, et le résultat devrait être testé face à des tentatives réalistes de réidentification.

Conservation et effacement dans chaque copie

La limitation de la conservation exige un calendrier de conservation : pour chaque catégorie de données, combien de temps elles sont conservées, pourquoi, et ce qui se passe à l’échéance (suppression, anonymisation ou archivage). Un calendrier ne fonctionne que si les systèmes l’appliquent automatiquement : TTL sur les entrées de cache et de base clé-valeur, tables partitionnées par période dont les anciennes partitions sont supprimées, règles de cycle de vie du stockage objet, paramètres de conservation des journaux et tâches planifiées dont la réussite est surveillée.

L’effacement est le plus difficile là où les données à caractère personnel s’infiltrent. Les caches et index de recherche exigent une éviction et une réindexation explicites, avec des TTL comme filet de sécurité. Les stockages d’analytique devraient contenir des références pseudonymes afin que les lignes puissent être retrouvées et supprimées, ou bien les données devraient être anonymisées dès leur entrée. Les journaux d’événements et les stockages en event sourcing sont immuables par conception ; la technique habituelle est le crypto-shredding (effacement cryptographique), qui consiste à chiffrer les champs de chaque personne avec une clé propre à cette personne puis à détruire la clé, comme le décrit la section 7.5, ou à garder les données à caractère personnel hors des événements en ne stockant que des références. Les journaux applicatifs ne devraient pas contenir de données à caractère personnel inutiles, point sur lequel revient la section 8.8. Les sauvegardes ne peuvent généralement pas être modifiées ; l’Information Commissioner’s Office (ICO) britannique admet que des données subsistent dans les sauvegardes jusqu’à leur écrasement selon un calendrier établi, à condition qu’elles soient mises hors d’usage entre-temps et que la personne soit clairement informée de ce qui se passera, et si une sauvegarde est un jour restaurée, les effacements doivent être réappliqués, ce qui exige de conserver la liste des identifiants effacés. Enfin, les sous-traitants doivent recevoir l’instruction de supprimer, puisqu’ils n’agissent que sur instruction du responsable du traitement (article 28), et les autres destinataires doivent être informés (article 19) : l’effacement doit donc atteindre la passerelle SMS, le service d’assistance et la plateforme marketing par leurs API.