Développement logiciel conforme au RGPD : un guide pratique pour les entreprises britanniques et européennes

Chaque semaine, nous discutons avec des entreprises qui ont développé leur logiciel sans accorder une attention sérieuse au RGPD, et qui en paient maintenant le prix — parfois en frais juridiques, parfois en refonte d'architecture en urgence, et parfois en amendes de l'ICO. La conversation commence généralement par une phrase que nous avons appris à reconnaître : « Nous savons que nous devons régler notre conformité, nous n'en avons simplement pas encore eu l'occasion. »

Cette « occasion » arrive rarement d'elle-même. La conformité ne s'inscrit pas naturellement dans un sprint planifié. Elle s'impose sous forme d'une violation de données, d'un courrier réglementaire, d'un questionnaire de diligence raisonnable d'un client grand compte que l'équipe commerciale doit traiter en quarante-huit heures, ou d'une personne concernée menaçant d'engager des poursuites pour des données qu'elle n'arrive pas à faire supprimer. Au moment où le RGPD devient urgent, il est déjà coûteux.

La raison pour laquelle la mise en conformité a posteriori est si douloureuse, c'est que le RGPD n'est pas un ensemble de politiques que l'on ajoute par-dessus une application existante. C'est une discipline de conception. Il influe sur votre schéma de base de données, votre architecture de journalisation, vos choix de services tiers, la conception de vos API, vos parcours utilisateur et vos processus internes. Tous ces éléments sont bien plus faciles à maîtriser au démarrage d'un projet qu'à corriger après coup.

Chez Cyberbeak, nous intégrons la protection de la vie privée dans nos projets logiciels dès la première semaine de découverte. Ce guide explique précisément ce que cela signifie en pratique — les concepts juridiques traduits en décisions d'ingénierie, les modèles qui rendent la conformité durable, et les erreurs que nous constatons le plus fréquemment dans les bases de code qui nous parviennent pour des travaux de remédiation.

---

Le RGPD en une phrase

Le Règlement général sur la protection des données (UE 2016/679) est la loi sur la protection des données qui s'applique à toute organisation traitant des données personnelles de personnes situées dans l'UE ou au Royaume-Uni, quel que soit le lieu d'établissement de cette organisation. Si vous avez des utilisateurs dans l'UE ou au Royaume-Uni, il vous concerne.

En pratique, il impose six exigences :

• Base légale — tout acte de traitement de données personnelles doit reposer sur une justification légale.
• Transparence — les personnes doivent être clairement informées des données que vous collectez et des raisons de cette collecte.
• Minimisation des données — vous ne pouvez collecter que les données nécessaires à la finalité déclarée.
• Droits — les personnes disposent du droit d'accéder à leurs données, de les rectifier, de les supprimer et de les exporter.
• Sécurité — vous devez protéger les données personnelles par des mesures techniques et organisationnelles appropriées.
• Responsabilité — vous devez être en mesure de démontrer votre conformité, et non simplement l'affirmer.

L'amende maximale pour une violation grave est de 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial — le montant le plus élevé étant retenu. L'ICO (le régulateur britannique) et les autorités de contrôle européennes ont montré qu'elles étaient prêtes à appliquer ces montants. British Airways a été condamnée à une amende de 20 millions de livres sterling. Amazon a été condamnée à une amende de 746 millions d'euros. Ce ne sont pas des cas isolés réservés aux multinationales imprudentes ; les petites et moyennes entreprises font également l'objet de sanctions, et le préjudice réputationnel lié à une décision publique d'exécution peut s'avérer plus lourd que l'amende elle-même.

---

La protection de la vie privée dès la conception : ce que cela signifie en pratique

La protection de la vie privée dès la conception (privacy by design) est inscrite directement dans l'article 25 du RGPD. Il ne s'agit pas d'une recommandation facultative — c'est une obligation légale. Le règlement exige que la protection des données soit prise en compte au moment de la conception des systèmes et des processus, et non a posteriori.

Les sept principes fondateurs de la protection de la vie privée dès la conception, traduits en décisions d'ingénierie, se présentent comme suit :

1. Proactif, et non réactif

Concevoir en intégrant la protection de la vie privée avant qu'un problème ne survienne. En termes logiciels : réaliser une Analyse d'Impact relative à la Protection des Données (AIPD) pendant la phase de découverte, avant qu'une seule ligne de code ne soit écrite, pour toute fonctionnalité impliquant un traitement à grande échelle de données sensibles.

2. La protection de la vie privée comme paramètre par défaut

Le comportement par défaut du système doit être l'option la plus protectrice de la vie privée. Les utilisateurs ne doivent pas avoir à agir pour protéger leur vie privée — ils doivent avoir à agir pour la réduire. En termes logiciels : les e-mails marketing sont soumis à opt-in et non à opt-out ; les cookies analytiques sont désactivés jusqu'à leur acceptation ; les fonctionnalités de partage social ne sont pas activées par défaut.

3. La protection de la vie privée intégrée à la conception

La protection de la vie privée n'est pas une couche supplémentaire au-dessus de l'architecture — elle en fait partie intégrante. En termes logiciels : votre modèle de données sépare les informations personnellement identifiables des données transactionnelles dès le départ ; vos microservices sont délimités de sorte que seuls les services ayant besoin des données à caractère personnel (DCP) puissent y accéder ; votre infrastructure de journalisation supprime ou hache les identifiants avant de les écrire dans les entrepôts de journaux centralisés.

4. Fonctionnalité totale

La protection de la vie privée ne doit pas se faire au détriment de la fonctionnalité. Vous ne devez pas avoir à choisir entre un produit utile et un produit conforme. En termes logiciels : des analyses anonymisées peuvent toujours vous fournir des informations produit pertinentes ; la personnalisation basée sur le consentement peut toujours offrir une expérience utilisateur de qualité.

5. Sécurité de bout en bout

Protection tout au long du cycle de vie des données. En termes logiciels : chiffrement des données au repos, chiffrement des données en transit, suppression sécurisée lorsque les données ne sont plus nécessaires — et pas seulement au niveau applicatif, mais également au niveau de la base de données et du stockage.

6. Visibilité et transparence

Les utilisateurs doivent pouvoir voir quelles données vous détenez et ce que vous en faites. En termes logiciels : un portail en libre-service pour les demandes d'accès aux données, une politique de confidentialité claire et précise, et des journaux d'audit que l'équipe conformité peut réellement lire.

7. Respect de la vie privée des utilisateurs

Placer les intérêts de l'utilisateur au premier plan. En termes logiciels : les politiques de conservation des données sont appliquées par l'application, et non laissées à un nettoyage manuel ; la suppression se propage dans l'ensemble des systèmes, y compris les sauvegardes et les caches.

---

Base légale du traitement des données

C'est le domaine dans lequel nous observons le plus souvent des malentendus fondamentaux dans les projets logiciels — non pas parce que les développeurs sont négligents, mais parce que les concepts juridiques ont des conséquences techniques faciles à négliger.

Le RGPD définit six bases légales pour le traitement des données personnelles. Les quatre les plus pertinentes pour la plupart des produits logiciels sont :

Base légale	Quand elle s'applique	Implication technique
Consentement	Marketing, analyses optionnelles, cookies non essentiels	Doit être libre, spécifique, éclairé, non ambigu. Doit pouvoir être retiré. Nécessite un enregistrement du consentement avec horodatage.
Contrat	Traitement nécessaire à l'exécution d'un service auquel l'utilisateur s'est inscrit	Aucun consentement séparé n'est requis, mais le traitement doit être véritablement nécessaire à l'exécution du contrat.
Intérêt légitime	Analyses commerciales, prévention de la fraude, sécurité des réseaux	Nécessite une Analyse d'Intérêt Légitime. Doit passer un test de mise en balance avec les droits individuels.
Obligation légale	Registres fiscaux, vérifications anti-blanchiment	Vous devez pouvoir nommer la loi spécifique. Ne peut pas être utilisée comme fourre-tout.

La raison pour laquelle le choix d'une mauvaise base légale constitue un problème technique et pas seulement juridique :

Si vous vous appuyez sur le consentement mais traitez ensuite des données d'une manière pour laquelle les utilisateurs n'ont pas spécifiquement consenti, vous devez recueillir à nouveau ce consentement — ce qui implique de recontacter votre base d'utilisateurs et de potentiellement en perdre une grande partie. Si vous invoquez l'intérêt légitime sans avoir réalisé d'Analyse d'Intérêt Légitime, vous pourriez devoir supprimer des données déjà collectées et rearchitecturer le pipeline qui en dépendait.

La base légale détermine également quels droits s'appliquent. Sous le régime du consentement, les utilisateurs bénéficient d'un droit absolu à l'effacement. Sous le régime du contrat, le droit à l'effacement peut être refusé si les données sont encore nécessaires à l'exécution du contrat. Cela influe sur la question de savoir si votre flux « supprimer le compte » doit se propager dans toutes les tables ou peut conserver certains enregistrements.

Notre recommandation : Documentez la base légale de chaque activité de traitement des données dans un Registre des Activités de Traitement (RAT) avant que les décisions d'architecture ne soient prises. Cela modifiera ces décisions.

---

Mise en œuvre de la gestion du consentement

La gestion du consentement est le domaine le plus visible pour les utilisateurs finaux — et celui où les implémentations échouent le plus souvent à satisfaire aux exigences légales.

Ce que requiert un consentement valide

Au titre du RGPD, le consentement doit être :

• Libre — le consentement conditionnel (vous devez accepter les cookies pour utiliser le site) ne constitue pas un consentement valide pour les cookies non essentiels.
• Spécifique — le consentement pour les analyses ne couvre pas le consentement pour le ciblage publicitaire.
• Éclairé — les utilisateurs doivent savoir à quoi ils consentent avant de le faire.
• Non ambigu — les cases pré-cochées ne constituent pas un consentement. Le silence ne constitue pas un consentement.
• Révocable — le retrait du consentement doit être aussi facile que son octroi.

Mise en œuvre du consentement aux cookies

Une bannière de cookies techniquement conforme doit :

1. Bloquer le chargement de tous les scripts non essentiels jusqu'à ce que le consentement soit obtenu — pas seulement définir un cookie indiquant la préférence.
2. Enregistrer le consentement avec un horodatage, la version de la politique de confidentialité présentée, et les catégories spécifiques acceptées.
3. Permettre un consentement granulaire par catégorie (nécessaires, analytiques, marketing, préférences).
4. Fournir un mécanisme pour retirer le consentement à tout moment.

Cela signifie que la configuration de votre gestionnaire de balises doit être conditionnée à l'état du consentement. Si vous utilisez Google Tag Manager, les scripts des catégories analytiques et publicitaires ne doivent se déclencher qu'après que les signaux de consentement correspondants ont été définis. Une implémentation incorrecte — afficher une bannière tout en chargeant les scripts quand même — est l'une des violations les plus courantes que nous observons sur le terrain.

Plateformes de gestion du consentement

Pour la plupart des projets, implémenter la gestion du consentement de zéro n'est pas le bon choix. Les principales options sont :

OneTrust — de qualité entreprise, hautement configurable, s'intègre avec la plupart des CMP et catalogues de données. Bien adapté aux grandes organisations ayant des besoins complexes en matière de consentement.

Cookiebot (désormais Usercentrics) — bonne option pour le marché intermédiaire, analyse automatiquement les cookies et les classe par catégorie, intégration facile via balise de script ou GTM.

Implémentation personnalisée — appropriée pour les applications dont les flux de consentement sont inhabituels (par exemple, un SaaS B2B où l'employeur de l'utilisateur final est le responsable du traitement) ou lorsque les plateformes existantes ne correspondent pas aux exigences UX. Nécessite une conception soigneuse du schéma d'enregistrement des consentements.

Centre de préférences marketing

Au-delà des cookies, les produits qui envoient des communications marketing doivent mettre en place un centre de préférences — une interface accessible à l'utilisateur lui permettant de gérer ses préférences de communication. Celui-ci doit reposer sur une base de données qui enregistre :

• Le statut du consentement par canal (e-mail, SMS, notifications push)
• L'horodatage de chaque modification
• La source du consentement (formulaire d'inscription, paiement, mise à jour du centre de préférences)
• Les catégories marketing spécifiques auxquelles l'utilisateur a souscrit

Ces données doivent être vérifiées au moment de l'envoi, pas seulement à la collecte — ce qui signifie que votre logique d'envoi d'e-mails doit interroger le statut de consentement actuel, et non s'appuyer sur un indicateur défini lors de l'inscription.

---

La minimisation des données en pratique

La minimisation des données — article 5(1)(c) — est le principe selon lequel vous ne devez collecter que les données personnelles nécessaires à la finalité spécifique que vous avez déclarée. Cela semble simple. En pratique, cela exige une discipline active, car la tendance naturelle des équipes logicielles est de capturer autant de données que possible « au cas où ce serait utile plus tard ».

Inventaire des DCP et classification des données

Le point de départ consiste à savoir quelles données personnelles vous collectez réellement. Un inventaire des DCP est un catalogue structuré de chaque donnée traitée par votre système, étiquetée avec :

• Ce qu'elle est (nom, e-mail, adresse IP, historique d'achats, données de santé)
• Pourquoi vous la collectez (nécessaire au contrat, analyses, obligation légale)
• Où elle est stockée (quelle base de données, quel service tiers)
• Combien de temps elle est conservée
• Qui y a accès

Cet exercice surprend régulièrement les équipes. Des adresses IP dans des journaux de serveur auxquels personne n'avait pensé. Des chaînes user-agent écrites dans une base de données aux côtés des enregistrements de compte. Des adresses complètes conservées pour une fonctionnalité de livraison abandonnée il y a dix-huit mois.

Modèles architecturaux pour la minimisation

Au-delà de l'inventaire, l'architecture elle-même doit faire de la minimisation le chemin de moindre résistance :

• Séparer les entrepôts de DCP des entrepôts transactionnels. Si votre base de données d'analyses effectue des jointures directement sur des adresses e-mail, il s'agit d'un problème de minimisation des données. Utilisez des identifiants pseudonymes dans les pipelines analytiques et conservez la table de correspondance dans un service restreint.
• Collecter au moment du besoin, non de manière spéculative. Ne demandez pas de numéro de téléphone lors de la création du compte si les numéros de téléphone ne sont nécessaires que pour l'authentification à deux facteurs — demandez-le lorsque l'utilisateur active la 2FA.
• Mettre en œuvre la conservation dans le code, pas dans les documents de politique. Une politique stipulant que les données sont supprimées après deux ans ne constitue pas une conformité. Un job planifié qui applique la suppression après deux ans, avec des journaux pour le prouver, constitue une conformité.

---

Droits des personnes concernées

Le RGPD accorde aux personnes huit droits. Les quatre qui nécessitent la mise en œuvre technique la plus importante sont :

Droit d'accès (demande d'accès aux données)

Une personne peut demander une copie de toutes les données personnelles que vous détenez à son sujet. Vous disposez d'un mois calendaire pour répondre. La réponse doit être dans un format couramment utilisé et lisible par machine.

Mise en œuvre technique : Construire une couche d'agrégation des données capable de collecter des informations sur un utilisateur auprès de chaque service qui en détient — votre base de données applicative, votre plateforme d'analyse, votre CRM, votre système de tickets de support — et de les compiler en une exportation structurée. Pour la plupart des applications, il s'agit d'une tâche d'ingénierie non triviale, ce qui explique précisément pourquoi elle doit être planifiée au stade de l'architecture plutôt que traitée de manière ad hoc à l'arrivée d'une demande.

Pour les applications à fort volume, un portail en libre-service qui génère automatiquement l'exportation représente à la fois une amélioration de la conformité et une amélioration opérationnelle.

Droit à l'effacement (droit à l'oubli)

Une personne peut demander la suppression de ses données personnelles. Ce droit n'est pas absolu — il peut être refusé lorsque les données sont nécessaires à des obligations légales, à l'intérêt public, ou lorsque l'intérêt légitime prime sur les droits individuels — mais pour la plupart des applications grand public, une demande d'effacement valide doit être honorée.

Mise en œuvre technique : La suppression doit se propager partout où les données se trouvent. Cela implique :

• La base de données applicative (suppression immédiate ou pseudonymisation des champs DCP)
• Les sauvegardes (un processus clair pour exclure des enregistrements spécifiques de la restauration des sauvegardes, ou un calendrier de conservation des sauvegardes limitant la durée de persistance des données supprimées)
• Les caches (invalidation du cache lors de la suppression)
• Les services tiers (demandes de suppression au CRM, à la plateforme d'e-mailing, à l'outil d'analyse, au système de support)
• Les données dérivées (jeux de données d'entraînement ML, agrégats analytiques susceptibles de contenir des données au niveau individuel)

Droit à la portabilité

Une personne peut demander ses données dans un format structuré, couramment utilisé et lisible par machine — généralement JSON ou CSV — dans le but de les transférer vers un autre service.

Mise en œuvre technique : Concevoir votre format d'exportation de données tôt. Il doit couvrir les données activement fournies par l'utilisateur (informations de compte, contenu créé, préférences définies) plutôt que les données inférées ou dérivées. Le point de terminaison d'exportation doit être authentifié, soumis à une limite de débit et audité.

Droit à la rectification

Une personne peut demander la correction de données personnelles inexactes.

Mise en œuvre technique : Chaque champ DCP de votre système nécessite un chemin d'édition — ce qui semble évident mais n'est pas toujours vrai. Les journaux d'événements immuables contenant des données personnelles posent un défi particulier ; l'approche recommandée est la pseudonymisation plutôt que la correction des enregistrements historiques.

---

Résidence des données et sous-traitants tiers

L'une des implications techniques les plus significatives et sous-estimées du RGPD est la restriction relative au transfert de données personnelles en dehors de l'UE/EEE (et en dehors du Royaume-Uni au titre du RGPD britannique).

Le paysage post-Schrems II

L'arrêt Schrems II rendu par la Cour de justice de l'UE en 2020 a invalidé le cadre du Bouclier vie privée UE-États-Unis, qui était jusqu'alors le mécanisme juridique permettant le transfert de données personnelles européennes vers des sous-traitants établis aux États-Unis. Le mécanisme de remplacement est constitué par les Clauses Contractuelles Types (CCT) — des clauses contractuelles pré-approuvées que les deux parties signent avant tout transfert.

En pratique, cela signifie que si vous utilisez un outil SaaS basé aux États-Unis — une plateforme d'analyse hébergée aux États-Unis, les centres de données d'un prestataire cloud américain, un CRM basé aux États-Unis — vous devez :

1. Vérifier si le fournisseur dispose de CCT (la plupart des grands fournisseurs en proposent).
2. Signer ces CCT avant de transférer des données personnelles.
3. Réaliser une Analyse d'Impact du Transfert pour vérifier que les lois du pays destinataire ne compromettent pas les protections offertes par les CCT.

Audit de vos fournisseurs cloud et de votre stack SaaS

Un audit des transferts de données doit documenter chaque service tiers vers lequel votre application envoie des données personnelles, et pour chacun d'eux noter :

• Le mécanisme de transfert légal (CCT, décision d'adéquation, dérogation)
• L'emplacement du ou des centres de données
• Les sous-traitants ultérieurs utilisés par ce fournisseur
• Le lien vers le contrat de traitement des données signé

Cette liste est plus longue que la plupart des équipes ne l'anticipent. Pensez à : votre hébergeur, votre CDN, votre service d'envoi d'e-mails, votre outil de surveillance des erreurs, votre outil de supervision des performances applicatives, votre plateforme de support client, votre CRM, votre outil d'automatisation marketing, votre widget de chat en direct, votre plateforme d'analyse, et tous les scripts tiers chargés sur votre front-end.

Contrats de traitement des données

Chaque tiers qui traite des données personnelles en votre nom doit signer un Contrat de Traitement des Données (CTD). Il s'agit d'une obligation contractuelle au titre de l'article 28 du RGPD, et non d'une mesure d'atténuation des risques facultative. La plupart des fournisseurs SaaS réputés disposent d'un CTD standard dans leur centre de confiance ou sur demande. L'absence de CTD avec un fournisseur constitue en soi une violation de la conformité, indépendamment de tout incident lié aux données.

---

Exigences de sécurité au titre du RGPD

L'article 32 impose aux organisations de mettre en œuvre des « mesures techniques et organisationnelles appropriées » pour assurer un niveau de sécurité adapté au risque. Le RGPD évite délibérément de spécifier des normes techniques exactes — mais les éléments suivants sont largement reconnus comme des exigences de base pour la plupart des applications.

Chiffrement

• Au repos : Chiffrement de la base de données (AES-256 est la référence standard), sauvegardes chiffrées, stockage de fichiers chiffré. Chiffrement au niveau applicatif pour les champs particulièrement sensibles (données de santé, données financières) afin que les administrateurs de base de données ne puissent pas les lire en clair.
• En transit : TLS 1.2 minimum, TLS 1.3 recommandé. En-têtes HSTS. Pas de contenu mixte. Surveillance des certificats.

Pseudonymisation

Remplacer les informations directement identifiantes par des identifiants pseudonymes chaque fois que cela est possible — notamment dans les pipelines analytiques, les fichiers journaux et les bases de données de reporting. Cela n'élimine pas les obligations RGPD (les données pseudonymisées restent des données personnelles au titre du RGPD), mais réduit considérablement l'impact d'une violation.

Contrôles d'accès

• Contrôle d'accès basé sur les rôles avec des principes de moindre privilège.
• Authentification multifacteur pour tout accès interne aux systèmes de production.
• Revues d'accès régulières — particulièrement lorsque les membres d'une équipe changent de poste ou quittent l'organisation.
• Séparation des environnements de production et de développement, sans données personnelles de production dans les systèmes de développement.

Journalisation d'audit

Un journal d'audit complet enregistre qui a accédé à des données personnelles ou les a modifiées, quand, depuis où et pourquoi. Cela remplit deux fonctions : permettre la détection des violations et démontrer la responsabilité aux régulateurs. Le journal lui-même doit être protégé contre la falsification.

Détection des violations et règle des 72 heures

L'article 33 impose de notifier à l'autorité de contrôle (l'ICO pour les organisations britanniques, l'autorité européenne compétente pour les organisations de l'UE) dans les 72 heures suivant la prise de connaissance d'une violation de données personnelles, lorsque cette violation est susceptible d'engendrer un risque pour les personnes.

Cela signifie que votre surveillance de sécurité doit être capable de détecter les violations rapidement — une détection lente et une escalade interne lente empiéteront sur ce délai de 72 heures. Votre processus de réponse aux incidents doit inclure une évaluation formelle permettant de déterminer si une violation atteint le seuil de notification.

---

Le RGPD britannique post-Brexit

À la suite du Brexit, le Royaume-Uni n'est plus soumis au RGPD de l'UE. À la place, le RGPD britannique — qui est le RGPD de l'UE tel que transposé dans le droit britannique avec quelques modifications — s'applique aux organisations traitant des données personnelles de personnes situées au Royaume-Uni.

En pratique, le RGPD britannique et le RGPD de l'UE sont quasi identiques sur le fond. Les mêmes principes, les mêmes droits, les mêmes bases légales et des niveaux d'amendes similaires s'appliquent. Les principales différences pratiques sont :

• L'ICO (Information Commissioner's Office) est l'autorité de contrôle pour le RGPD britannique, et non les autorités de contrôle de l'UE.
• L'UE a accordé au Royaume-Uni une décision d'adéquation, ce qui signifie que les données personnelles européennes peuvent circuler vers le Royaume-Uni sans CCT (au moment de la rédaction de ce document — les décisions d'adéquation peuvent être révoquées).
• Les organisations britanniques qui traitent également des données de résidents de l'UE doivent se conformer à la fois au RGPD britannique et au RGPD de l'UE, et peuvent avoir besoin de désigner un représentant dans l'UE.
• Les CCT britanniques (appelées Accord de transfert international de données ou IDTA) diffèrent dans leur format des CCT de l'UE, bien que les protections substantielles soient alignées.

Pour la plupart des entreprises britanniques, les obligations pratiques au quotidien sont presque identiques à celles imposées par le RGPD de l'UE. La complexité apparaît pour les entreprises opérant dans les deux juridictions — notamment celles ayant des utilisateurs à la fois au Royaume-Uni et dans l'UE, ou celles faisant appel à des sous-traitants établis dans l'UE.

---

Erreurs courantes en matière de RGPD dans les projets logiciels

Voici les schémas que nous observons le plus fréquemment lorsque nous examinons des bases de code existantes pour détecter des lacunes de conformité :

Stocker plus de données que la finalité déclarée ne le requiert. Des formulaires d'inscription demandant la date de naissance « pour la personnalisation » mais ne l'utilisant jamais. Des intégrations CRM qui synchronisent chaque champ utilisateur, que le CRM en ait besoin ou non. L'habitude de collecter des données de manière spéculative est profondément ancrée dans la culture produit et nécessite une résistance active.

Aucune politique de conservation des données appliquée dans le code. La politique de confidentialité indique que les données sont conservées pendant trois ans. La base de données contient des enregistrements remontant à huit ans sans aucun job de suppression en vue. Un document de politique non appliqué par l'application ne constitue pas une conformité — c'est une responsabilité.

Scripts tiers oubliés transférant des données vers les États-Unis. Une équipe marketing ajoute un widget de chat en direct. Un développeur ajoute un outil de carte thermique. Un autre développeur ajoute une police de caractères tierce. Aucun de ces éléments ne figure dans le registre des CTD. Chacun d'eux transfère les adresses IP des utilisateurs — et potentiellement davantage — vers un serveur basé aux États-Unis sans mécanisme de transfert légal et sans être bloqué par le système de gestion du consentement.

Contrats de traitement des données manquants avec les fournisseurs cloud. AWS, GCP et Azure proposent tous des CTD et la plupart des clients les signent automatiquement lors de la création du compte. Mais les services complémentaires — un outil de surveillance de niche, un fournisseur d'e-mail spécialisé, une petite plateforme de retour client — sont fréquemment utilisés sans CTD signé, simplement parce que personne n'a pensé à le demander.

Confondre consentement et toute interaction. Continuer à envoyer des e-mails marketing parce qu'un utilisateur « ne s'est pas désabonné » ne constitue pas un consentement. Traiter l'inscription à un compte comme un consentement pour les analyses n'est pas un consentement. Ces pratiques étaient courantes avant le RGPD et le restent aujourd'hui.

Aucun processus pour les demandes d'accès aux données. Lorsqu'une demande d'accès arrive, quelqu'un doit être en mesure de rassembler toutes les données détenues sur un individu dans l'ensemble des systèmes en moins d'un mois. S'il n'existe ni processus défini ni mécanisme technique pour ce faire, la première demande sera à la fois non conforme et opérationnellement chaotique.

---

Comment nous développons des logiciels conformes au RGPD chez Cyberbeak

La protection de la vie privée dès la conception est intégrée dans notre façon de conduire chaque projet, et non traitée comme un audit tardif.

Lors de la découverte, nous réalisons un exercice de cartographie des flux de données pour chaque produit — documentant quelles données personnelles seront collectées, où elles seront stockées, quels services tiers les recevront, et quelle sera la base légale de chaque activité de traitement. Cela met généralement en évidence des décisions à prendre avant le début du travail d'architecture : recourir à un outil SaaS basé aux États-Unis ou à une alternative européenne, structurer le modèle de consentement, déterminer si une AIPD est requise.

Pour les projets impliquant un traitement à haut risque — données de santé, données financières, profilage à grande échelle, données concernant des enfants — nous réalisons une Analyse d'Impact relative à la Protection des Données formelle avant le début du développement. L'AIPD documente les risques, les mesures d'atténuation et le risque résiduel, et elle est examinée par la personne exerçant la fonction de DPO pour le client (ou nous pouvons assurer cette fonction en tant que service).

Lors de l'architecture, nous concevons la séparation des DCP, la journalisation d'audit et la conservation des données dans le modèle de données dès le départ. Nous documentons le Registre des Activités de Traitement au fur et à mesure, de sorte qu'il reflète ce que le système fait réellement plutôt que ce qu'un document de politique stipule.

Lors du développement, les flux de consentement sont construits selon la norme légale — et non ajoutés a posteriori à des fins esthétiques. Les fonctionnalités de demande d'accès et d'effacement sont intégrées en tant que fonctionnalité de premier ordre, et non traitées comme un processus manuel. Les intégrations tierces font l'objet d'une évaluation de conformité au regard des transferts de données avant d'être ajoutées à la base de code.

Lors de la remise du projet, nous fournissons au client un RAT complet, un schéma de flux de données et la documentation de tous les sous-traitants tiers ainsi que le statut de leur CTD — non pas parce que nous y sommes tenus, mais parce qu'un client qui comprend sa posture de conformité est bien moins susceptible d'introduire des violations après la remise.

Nous ne sommes pas juristes, et nous travaillons aux côtés de conseils juridiques pour les clients nécessitant des avis juridiques formels. Mais la mise en œuvre technique de la conformité au RGPD relève pleinement de la discipline du développement logiciel, et c'est une discipline que nous prenons au sérieux.

---

Questions fréquemment posées

Une jeune entreprise doit-elle s'inquiéter du RGPD ?

Oui — le RGPD s'applique à toute organisation traitant des données personnelles de personnes situées dans l'UE ou au Royaume-Uni, quelle que soit la taille ou le chiffre d'affaires de l'organisation. Il n'existe pas d'exemption pour les petites entreprises. Certaines obligations sont allégées pour les petites organisations (les entreprises de moins de 250 salariés peuvent avoir des obligations réduites en matière de Registre des Activités de Traitement dans certains cas), mais les obligations fondamentales — base légale, transparence, minimisation des données, sécurité et droits — s'appliquent universellement. L'ICO a publié des décisions d'exécution à l'encontre de petites entreprises et de travailleurs indépendants.

Quelles sont les amendes pour les violations du RGPD ?

Il existe deux niveaux. Le niveau inférieur s'applique aux violations d'obligations telles que les enregistrements de consentement, les exigences relatives aux sous-traitants et les avis de confidentialité — amendes jusqu'à 10 millions d'euros ou 2 % du chiffre d'affaires annuel mondial. Le niveau supérieur s'applique aux violations des principes fondamentaux du RGPD — base légale, minimisation des données, droits des personnes concernées et transferts internationaux — amendes jusqu'à 20 millions d'euros ou 4 % du chiffre d'affaires annuel mondial. L'ICO dispose de sa propre structure d'amendes équivalente au titre du RGPD britannique, plafonnée à 17,5 millions de livres sterling ou 4 % du chiffre d'affaires mondial.

L'utilisation d'AWS (ou de GCP ou d'Azure) est-elle conforme au RGPD ?

Les grands fournisseurs cloud ont fortement investi dans l'infrastructure de conformité au RGPD et proposent tous des Contrats de Traitement des Données ainsi que la possibilité de choisir des régions de centres de données européens. Utiliser AWS dans une région Francfort avec un CTD signé et des CCT pour tout transfert en dehors de l'EEE est cohérent avec le RGPD. Utiliser AWS sans CTD signé, ou traiter des données personnelles européennes dans une région américaine sans mécanisme de transfert légal, ne l'est pas. Le fournisseur cloud est un sous-traitant ; vous êtes le responsable du traitement ; les deux ont des obligations et les deux doivent documenter la relation de manière appropriée.

Avons-nous besoin d'un Délégué à la Protection des Données ?

Un DPO est obligatoire au titre de l'article 37 pour les autorités publiques, les organisations dont les activités principales impliquent un suivi systématique à grande échelle des personnes, et les organisations dont les activités principales impliquent un traitement à grande échelle de données de catégorie particulière (données sensibles). Pour de nombreuses entreprises, ces conditions ne s'appliquent pas et un DPO n'est pas légalement requis — bien qu'il soit souvent recommandé de désigner une personne responsable de la protection des données. En cas de doute, l'ICO a publié des orientations sur les cas dans lesquels un DPO est requis.

Que signifie le RGPD britannique pour notre activité post-Brexit ?

Si vous n'avez que des utilisateurs au Royaume-Uni et traitez des données personnelles uniquement au sein du Royaume-Uni, le RGPD britannique s'applique et l'ICO est votre régulateur. Si vous avez également des utilisateurs dans l'UE, le RGPD de l'UE s'applique en plus, et vous pourriez avoir besoin d'un représentant dans l'UE. Les transferts de données du Royaume-Uni vers l'UE sont autorisés dans le cadre de la décision d'adéquation de l'UE pour le Royaume-Uni (qui doit faire l'objet d'une surveillance quant à d'éventuelles modifications). Les transferts de l'UE vers le Royaume-Uni sont également autorisés. Les organisations britanniques transférant des données vers des pays tiers en dehors du Royaume-Uni doivent utiliser les propres mécanismes de transfert du Royaume-Uni — l'IDTA ou l'Addendum aux CCT de l'UE — et non directement les CCT de l'UE.

---

Si vous développez un nouveau produit et souhaitez respecter le RGPD dès le départ — ou si vous disposez d'une application existante nécessitant un audit de conformité — nous pouvons vous accompagner. Notre processus de découverte inclut en standard la cartographie des flux de données et une évaluation de la protection de la vie privée dès la conception, et nous avons travaillé avec des entreprises issues de la fintech, de la healthtech, du commerce en ligne et du SaaS B2B pour construire des systèmes à la fois véritablement utiles et véritablement conformes.

Prenez contact avec nous pour discuter de votre projet.