Les écouteurs de cycle de vie de Doctrine, bien que pratiques pour gérer des modifications sur les entités, présentent des risques importants lorsqu'il s'agit de la suppression de données personnelles dans le cadre du RGPD. En particulier, les écouteurs de type preUpdate et preRemove ne sont pas toujours déclenchés par des opérations de masse, comme les requêtes DQL en masse pour des mises à jour ou des suppressions.
Lorsque des opérations de mise à jour ou de suppression sont effectuées directement via des requêtes DQL, elles contournent le mécanisme de cycle de vie de Doctrine et l'UnitOfWork. Par conséquent, les écouteurs configurés pour intercepter ces événements ne seront pas exécutés, laissant les données personnelles intactes sans aucun avertissement ni échec de test. Cette absence de déclenchement peut donner une fausse impression de conformité, car les données sensibles ne sont pas effacées comme prévu.
Pour garantir la conformité RGPD, il est préférable de gérer explicitement la suppression des données personnelles au niveau du domaine, plutôt que de s'appuyer sur des mécanismes automatiques potentiellement non déclenchés. Une approche claire et explicite au sein du code métier assure que les données sont correctement traitées, même lors d'opérations de masse.
Une requête d'effacement GDPR, telle que traitée dans une application Symfony/Doctrine, est présentée comme un processus de longue durée et partiellement asynchrone, et non comme une simple opération CRUD. Cette distinction est cruciale car l'effacement des données doit s'étendre à diverses sources, y compris les index de recherche, les caches, et les systèmes externes, qui ne partagent pas une transaction commune avec la base de données principale.
L'approche proposée modélise la requête d'effacement comme une entité de première classe, un "cas" doté d'un cycle de vie. Ce cas suit la progression des différentes étapes d'effacement, chacune étant marquée comme terminée individuellement. L'état de complétion global est déterminé par la vérification que toutes les étapes requises ont été explicitement achevées.
Pour gérer la communication entre la base de données Doctrine et d'autres systèmes, une approche utilisant une machine à états explicite et un mécanisme "Outbox" est recommandée. Cela permet une orchestration fiable, incluant l'idempotence pour chaque étape et une API de statut qui reflète précisément l'état réel du processus, évitant ainsi de signaler une complétion prématurée.
Pour respecter le Règlement Général sur la Protection des Données (RGPD), il est crucial de gérer les requêtes d'effacement des données personnelles avec une extrême prudence. L'envoi d'informations personnelles identifiables (PII) directement dans les messages déclenchant ces requêtes, même avec de bonnes intentions, crée des copies non désirées de ces données. Ces copies peuvent persister dans divers systèmes tels que les brokers de messages, les tables d'envoi, les files de nouvelle tentative, les files de messages échoués, et même dans les journaux, contredisant ainsi l'objectif d'effacement.
La solution proposée consiste à distinguer clairement les différents types de messages impliqués dans le processus d'effacement. Il faut différencier une commande interne, un événement de domaine interne, et un événement d'intégration public. Seul cet événement d'intégration, destiné à être consommé par d'autres services, est le point où les données traversent les frontières du système et doivent être traitées avec le plus de rigueur.
L'approche recommandée est de ne jamais inclure directement les PII dans l'événement d'intégration public. Cet événement ne devrait contenir qu'un identifiant unique du sujet de l'effacement. Les détails des données à effacer doivent être gérés en interne par le service initiateur, sans être exposés dans le message qui voyage à travers différents systèmes, garantissant ainsi que le processus d'effacement ne laisse pas de traces de données personnelles là où elles ne devraient pas être.
Pour répondre aux demandes de droit à l'effacement du RGPD dans une application Symfony utilisant Doctrine, il ne suffit pas de supprimer une entité avec EntityManager::remove(). Cette méthode implique la suppression totale de l'enregistrement, ce qui est souvent impossible pour les données commerciales soumises à des obligations légales de conservation, comme les commandes ou les factures. L'effacement consiste plutôt à "retirer la personne d'un enregistrement qui doit subsister", en anonymisant les informations personnelles tout en conservant la structure essentielle de l'entité.
Les approches courantes comme la suppression directe de l'entité ou la mise à null des champs ne sont pas suffisantes. EntityManager::remove() supprime l'entité entière, ce qui peut entraîner la perte de données essentielles ou des erreurs de contrainte de clé étrangère. La simple nullification des champs dans le code PHP ne garantit pas l'effacement effectif dans la base de données, car Doctrine pourrait ne pas enregistrer ces changements, laissant des données personnelles intactes dans des tables secondaires, des colonnes JSON ou des objets embarqués.
Il est donc recommandé de concevoir l'effacement comme une opération de domaine explicite au sein de l'entité elle-même. Cette méthode, par exemple un forgetPersonalData(), doit être responsable de la suppression de l'identité, de la préservation des enregistrements nécessaires et de la journalisation de l'événement. Cela assure que les données personnelles sont effectivement purgées des champs pertinents tout en maintenant l'intégrité des données commerciales essentielles.
Résumé pour Shaarli :
L'effacement des données RGPD dans Doctrine ne se limite pas à EntityManager::remove(). Pour les données commerciales soumises à conservation, il faut anonymiser les informations personnelles tout en gardant l'enregistrement. Ni la suppression directe ni la nullification des champs ne suffisent à garantir cet effacement. Il faut implémenter des opérations de domaine explicites au sein des entités pour masquer l'identité tout en préservant les données essentielles, et vérifier que Doctrine a bien appliqué les changements.
L'article aborde la modélisation des périodes de rétention des données personnelles dans le cadre du RGPD, en soulignant les limites d'une approche simpliste basée sur une seule colonne deleted_at. Il met en évidence que différentes entités liées à un même individu (client, commande, facture) ont des cycles de vie distincts et des obligations légales de conservation qui ne peuvent être gérés par une seule date de suppression.
La solution proposée consiste à créer des politiques de rétention explicites pour chaque contexte de donnée, dissociant clairement la décision de suppression de la simple inactivité de l'utilisateur. Cela permet de représenter de manière granulaire les raisons pour lesquelles une donnée doit être conservée ou supprimée, offrant ainsi une meilleure traçabilité et conformité.
Cette approche vise à remplacer les requêtes SQL implicites et difficiles à tester par des objets de décision inspectables et testables. Ces objets indiquent le statut de rétention (éligible, bloqué, programmé, déjà oublié), la raison associée et la date d'éligibilité éventuelle, rendant la politique de suppression transparente et gérable.
L'article aborde le conflit entre le principe d'immuabilité de l'event sourcing et le droit à l'effacement du RGPD. Les approches traditionnelles comme la réécriture ou la suppression physique des événements sont jugées destructrices pour l'intégrité du système.
La solution proposée repose sur le concept de "forgettable payloads" : les données personnelles ne sont plus stockées directement dans les événements immuables, mais dans un espace de stockage séparé et mutable. L'événement conserve son identité et une référence vers ces données, mais la suppression du compte utilisateur implique de rendre ces données inaccessibles, sans altérer le flux d'événements.
Cette inaccessibilité est concrètement réalisée par le "crypto-shredding" des données : chaque charge utile est chiffrée avec une clé unique, et le processus d'effacement consiste à détruire cette clé. Si aucune copie de clé ou donnée en clair ne subsiste ailleurs, les données chiffrées deviennent indéchiffrables, honorant ainsi la demande d'effacement sans compromettre l'historique des événements.
L’article explique comment implémenter un chiffrement au niveau des champs dans une application Symfony/Doctrine pour se conformer au RGPD, en évitant de polluer le domaine métier. L’auteur souligne que le chiffrement transparent des données (TDE) ne suffit pas, car il ne protège pas contre les accès internes malveillants ou les failles comme les injections SQL. La solution proposée consiste à chiffrer les données sensibles (emails, numéros de téléphone, etc.) avant leur stockage en base, en utilisant soit un type DBAL personnalisé, soit un lifecycle subscriber, sans modifier les entités.
Le type DBAL personnalisé, comme EncryptedStringType, s’intègre naturellement entre PHP et la base de données, chiffrant les données lors de l’écriture et les déchiffrant à la lecture, sans que le domaine n’ait à gérer cette logique. Cette approche maintient une séparation claire des responsabilités, où le chiffrement reste une préoccupation d’infrastructure. L’article détaille l’implémentation technique, notamment l’injection des dépendances et l’enregistrement du type dans Doctrine.
L’article analyse les hacks récents ayant ciblé des services publics français en 2026, soulignant que trois des quatre attaques ont exploité des comptes légitimes sans nécessiter de compétences techniques avancées. Il met en avant l’importance de la défense en profondeur : pare-feu, cloisonnement, double authentification et contrôle strict des droits d’accès, tout en rappelant que la minimisation des données (RGPD) limite les risques de fuite. L’exemple de la DGFIP illustre un retard de six semaines dans la détection de l’exfiltration de données, malgré une coupure immédiate des accès, soulignant l’importance de surveiller à la fois l’intrusion et la sortie des informations.
Les attaques se divisent en deux catégories : les cibles spécifiques (phishing, mots de passe volés, comptes obsolètes) et les scans automatisés exploitant des failles connues dans des logiciels populaires. L’article cite l’exemple d’une faille de conception (IDOR) sur le portail ANTS, où une simple modification d’URL permettait d’accéder à des dossiers non sécurisés. Les robots malveillants, eux, ciblent indistinctement les serveurs vulnérables, souvent en quelques secondes après l’enregistrement d’un nom de domaine.
Enfin, l’auteur insiste sur la nécessité d’une approche globale, combinant prévention (mises à jour, configuration par défaut restrictive) et détection rapide des intrusions ou fuites. Il rappelle que le RGPD impose une notification rapide des victimes, mais que certains organismes peinent à identifier une exfiltration de données, retardant ainsi les mesures correctives.
L’article de Stéphane Klein aborde la certification Hébergeur de Données de Santé (HDS), un sujet qu’il explore pour aider un ami professionnel de santé souhaitant migrer son application de gestion de patients vers un hébergeur conforme. L’auteur clarifie d’abord le cadre légal : toute structure manipulant des données de santé à caractère personnel (antécédents, diagnostics, ordonnances, etc.) doit être certifiée HDS ou agréée, selon l’article L.1111-8 du Code de la santé publique.
Il détaille ensuite la notion de donnée de santé (DDS), distinguant celles qui le sont par nature, par croisement ou par usage, et soulignant que même des informations indirectes (comme un motif de consultation) peuvent entrer dans ce cadre. Klein insiste sur la difficulté de l’anonymisation : une donnée est considérée comme personnelle dès qu’une ré-identification est raisonnablement possible, même sans identifiant explicite.
Enfin, il établit un lien avec les PII (Personally Identifiable Information) : toute DDS est une PII, mais l’inverse n’est pas systématique. L’article met en lumière les enjeux techniques et juridiques pour les développeurs et hébergeurs, notamment la nécessité de sécuriser les données contre les risques de ré-identification, un défi central pour la conformité RGPD et HDS.
European Alternatives propose une plateforme pour identifier des alternatives européennes à des services et produits numériques courants, comme les solutions cloud ou SaaS. Le site met en avant l'importance de soutenir les entreprises locales, soulignant les retombées économiques (emplois, taxes) et la conformité aux réglementations européennes, notamment le RGPD, la TVA et les normes juridiques harmonisées au sein de l'UE. Il recense des alternatives dans divers domaines (hébergement, messagerie, moteurs de recherche, etc.) et encourage les utilisateurs à contribuer en suggérant de nouveaux services.
Le LocalStorage, bien que différent des cookies, est soumis aux mêmes réglementations que ces derniers en termes de protection des données personnelles selon le RGPD. Le règlement ne mentionne pas de technologies spécifiques, mais encadre toute opération de traitement de données permettant d'identifier un utilisateur, y compris via le LocalStorage. La directive ePrivacy étend ces règles à toutes les technologies de stockage ou d'accès aux informations d'un terminal. Ainsi, le consentement de l'utilisateur est nécessaire pour le stockage de données via le LocalStorage.
Dans cette BD, l'auteur explique que les bannières de cookies, bien que souvent associées au RGPD, ne sont pas imposées par ce règlement. Il détaille les cas où elles ne sont pas nécessaires et critique l'utilisation abusive de ces bannières, souvent liées à la transmission de données à des tiers. L'auteur propose des alternatives moins intrusives et compare la situation à l'expérimentation "Oui Pub". Une lecture éclairante pour comprendre les enjeux des cookies et du consentement en ligne.
Un bundle Symfony pour utiliser les Google Fonts sans enfreindre le RGPD
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Le simple fait de commencer à s'inscrire sur le site de Guerlain provoque la fuite en masse de données vers leurs "partenaires"... L'auteur donne quelques conseils pour se protéger