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 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.
Le 11 août 2026, le service Bloctel, qui permettait aux Français de s’opposer au démarchage téléphonique, a définitivement fermé ses portes, remplacé par un régime d’interdiction du démarchage sauf consentement préalable. Cinq jours plus tôt, le 6 août, une fuite de données a exposé environ 3 millions de numéros de téléphone, dont 600 000 issus de la liste Bloctel, après un accès frauduleux à un compte professionnel. La DGCCRF a confirmé l’incident le 12 août, soulignant que la base officielle n’avait pas été piratée, mais que des fichiers échangés avec des professionnels avaient été compromis.
Cette fuite révèle les risques liés à la gestion des données professionnelles et la valeur potentielle d’un simple fichier de numéros pour les escrocs, même sans informations complémentaires. Elle survient dans un contexte où le démarchage téléphonique devient illégal par défaut, sauf preuve de consentement, marquant un tournant dans la protection des consommateurs. Les entreprises doivent désormais adapter leurs pratiques pour se conformer à cette nouvelle réglementation.
L’article détaille les actions concrètes à mener pour les particuliers, comme vérifier leur inscription sur les nouvelles listes de consentement, et pour les entreprises, qui doivent désormais prouver le consentement explicite avant tout appel. Il souligne aussi l’importance de sécuriser les accès aux données professionnelles pour éviter de futures fuites.
Cette chronique humoristique de Grise Bouille, publiée sous le titre Quand est-ce qu'on interdit les lunettes connectées ?, aborde avec satire l'émergence et les dangers des lunettes connectées, ces dispositifs constamment reliés à internet qui captent et transmettent massivement des données personnelles. L'auteur, Gee, y critique leur prétendue "intelligence" tout en soulignant leur impact sur la vie privée, un sujet déjà soulevé lors du lancement des Google Glass en 2011, abandonné en raison de leur rejet massif et de leurs problèmes techniques.
L'article rappelle que Meta (ex-Facebook) a relancé le concept en 2021 avec les Ray-Ban Meta, en collaboration avec EssilorLuxottica, combinant ainsi des acteurs américains et français dans un projet jugé peu innovant et intrusif. Gee insiste sur les risques liés au stockage des données sur les serveurs de Meta, soumis aux lois américaines comme le Patriot Act, qui permettent une surveillance étendue, y compris pour les non-Américains.
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.