Le RGPD comme discipline d'ingénierie

Le Règlement général sur la protection des données (RGPD) reste la législation sur la vie privée la plus structurante pour les éditeurs de logiciels qui servent des utilisateurs européens. Depuis son entrée en application en mai 2018, les régulateurs ont prononcé plus de 4 milliards d'euros d'amendes, touchant des entreprises de toutes tailles. Pour les équipes d'ingénierie, le RGPD n'est pas qu'un sujet juridique à laisser aux juristes. C'est une discipline d'architecture.

Le consentement doit être recueilli avec précision, conservé durablement et rendu auditable. Un enregistrement de consentement conforme comprend l'identifiant de l'utilisateur, la finalité précise consentie, la version de la notice de consentement présentée, l'horodatage de la collecte, le canal, ainsi que l'adresse IP ou l'empreinte de l'appareil lorsque c'est pertinent.

Chaque champ d'un schéma de base de données est une responsabilité potentielle. Les équipes doivent revoir régulièrement leurs schémas pour justifier la collecte de chaque donnée par une finalité métier ou légale documentée. La pseudonymisation réduit le risque pour une large catégorie de traitements et ouvre des usages analytiques secondaires qui exigeraient autrement un consentement explicite.

Les processus de suppression manuels sont fragiles et, en pratique, non conformes. Les politiques de conservation doivent être implémentées comme un comportement automatisé du système. Cela suppose un calendrier de conservation défini par catégorie de données, un pipeline de suppression déclenché par l'ancienneté ou la clôture du compte, la vérification que les suppressions se propagent à tous les réplicas et sauvegardes, et une journalisation d'audit des événements de suppression.

Le délai de 30 jours pour répondre aux demandes d'accès des personnes concernées impose l'automatisation. Les systèmes doivent pouvoir identifier toutes les données détenues sur une personne dans l'ensemble des bases, les exporter dans un format structuré et les supprimer sur demande.

L'article 33 impose de notifier l'autorité de contrôle dans les 72 heures suivant la prise de connaissance d'une violation. Ce délai suppose une détection automatisée, un workflow de réponse aux incidents établi et des modèles de notification rédigés à l'avance.

Transférer des données personnelles hors de l'EEE exige un mécanisme de transfert valide. Les équipes doivent s'appuyer sur des clauses contractuelles types, des règles d'entreprise contraignantes ou des décisions d'adéquation. Les choix d'infrastructure cloud pèsent directement sur la conformité au RGPD dès la conception.

Nous avons accompagné un studio de jeux vidéo sur la conformité RGPD de son système de comptes joueurs. Notre audit a mis au jour plusieurs problèmes.

Nous avons remplacé le drapeau de consentement binaire par une table de consentements versionnée. Chaque enregistrement stocke l'identifiant du joueur, l'identifiant de la version du consentement (lié à une table contenant le texte complet affiché), l'horodatage de l'acceptation, le canal, et les finalités précises consenties sous forme de colonnes booléennes distinctes. Lorsque le studio met à jour sa politique de confidentialité ou étend ses finalités de traitement, le système signale les joueurs concernés et conditionne la poursuite du jeu à une nouvelle acceptation à la connexion suivante. Les joueurs qui ne renouvellent pas leur consentement sous 30 jours basculent dans un mode restreint qui désactive toute collecte de données au-delà de ce qu'exige l'exécution du contrat.

Nous avons également conçu une séparation entre la base opérationnelle, qui contient les fiches joueurs identifiées, et un environnement analytique dédié qui ne reçoit que des données pseudonymisées ou agrégées. Les événements de jeu sont marqués par un identifiant pseudonyme rotatif plutôt que par l'identifiant du compte. La correspondance entre pseudonyme et compte vit exclusivement dans la base opérationnelle et n'est jamais répliquée côté analytique : même si l'entrepôt analytique était compromis, les données ne pourraient pas être rattachées à des joueurs sans la clé de correspondance.

Pour l'analyse par cohortes, nous appliquons des techniques de confidentialité différentielle qui ajoutent un bruit statistique calibré aux résultats des requêtes agrégées, de sorte que la présence ou l'absence d'un joueur donné ne puisse pas être déduite du résultat. Les tendances agrégées restent parfaitement lisibles, tandis que la réidentification individuelle devient impraticable sur le plan du calcul.

Une application de santé européenne a mandaté Jinka pour moderniser son infrastructure backend. Notre audit a révélé que les données étaient hébergées sur une unique base SQL Server, sans séparation régionale, sans journaux d'audit, sans contrôles de confidentialité et sans chiffrement au repos.

Nous avons conçu un ensemble d'endpoints REST qui centralisent toutes les opérations liées aux droits des personnes concernées, autour de trois axes. Les endpoints de gestion du consentement permettent aux clients d'enregistrer des événements de consentement, d'interroger le statut actuel par finalité et de vérifier la validité avant tout traitement. Tout service qui manipule des données de santé appelle l'endpoint de vérification avant d'agir : c'est un verrou, pas une hypothèse. Les endpoints de demandes des personnes concernées traitent de façon asynchrone les suppressions et les exports structurés, avec journalisation des événements d'achèvement dans une piste d'audit. Des endpoints de reporting interne, protégés par des contrôles d'accès par rôle, permettent à l'équipe conformité de remonter les taux de couverture du consentement, l'état des demandes de suppression et les délais de réponse, sans jamais toucher directement aux données de santé brutes.

Pour la résidence des données, toutes les ressources de production sont déployées dans la région West Europe d'Azure, avec des contraintes de politique appliquées au niveau de l'abonnement qui bloquent la création de ressources hors des régions européennes approuvées. Les données de santé au repos sont chiffrées avec des clés gérées par le client, limitées à cette région via Azure Key Vault, chaque événement de déchiffrement étant journalisé via Azure Monitor. Toutes les communications entre services internes passent par TLS.

Le résultat : une infrastructure dont le client peut démontrer aux régulateurs et aux grands comptes qu'elle est contrôlée, journalisée et auditable à chaque couche.