Du « patch » au design : ce que change la conformité dès la conception
Pendant longtemps, la conformité RGPD sur un site web se résumait à un bandeau de cookies et une clause de confidentialité. On construisait le système, puis on ajoutait la couche réglementaire par-dessus.
Le problème : cette approche génère une dette technique invisible. Chaque module ajouté, chaque intégration tierce, chaque log activé par défaut devient un point de friction avec la réglementation. On patche en permanence. On n'en finit jamais.
Le privacy by design renverse la logique. La question posée au départ n'est plus « que pouvons-nous collecter ? » mais « de quoi avons-nous réellement besoin ? ». Pour un site Drupal, cela signifie limiter la donnée personnelle partout où elle n'est pas indispensable — y compris dans les couches techniques souvent négligées : le moteur de recherche interne, les logs système, les intégrations analytics et les déclencheurs de consentement.
Ce n'est pas une contrainte de plus. C'est un avantage structurel : moins de données à protéger, moins de risques à gérer, moins de travail de mise en conformité à mesure que le système évolue.
Drupal et le RGPD : trois zones prioritaires
La recherche interne — le nœud souvent oublié
La recherche interne d'un site Drupal est rarement perçue comme un sujet RGPD. Elle le devient dès qu'on y regarde de près.
Une requête de recherche peut contenir un nom, une adresse e-mail, un numéro de dossier. Si ces requêtes sont indexées, stockées ou transmises à un service tiers d'analyse, elles constituent des données personnelles au sens du règlement. La question n'est pas théorique : c'est ce que font la plupart des modules de recherche par défaut.
Trois décisions d'architecture à prendre :
- Que stocke-t-on ? Les logs de recherche ont une utilité analytique réelle. Ils n'ont pas besoin de contenir l'identité du chercheur. Dépersonnaliser ou pseudonymiser à la source est la règle.
- Où transitent les requêtes ? Un moteur de recherche externe hébergé chez un prestataire tiers entraîne un transfert de données. Ce transfert suppose un accord de sous-traitance en bonne et due forme.
- Combien de temps conserve-t-on ? Les logs de recherche n'ont pas vocation à vivre indéfiniment. Une durée de rétention définie et appliquée automatiquement est la norme, pas l'exception.
La journalisation — ce qu'on conserve et pourquoi
Les logs système d'un site Drupal peuvent contenir des informations personnelles sans que personne ne l'ait décidé explicitement : adresses IP, identifiants utilisateur, horodatage des actions, contenus des formulaires soumis en cas d'erreur.
La journalisation est indispensable pour la sécurité, le débogage et l'audit. Elle devient un problème RGPD quand elle conserve plus qu'il n'est nécessaire, plus longtemps qu'il ne le faut, dans des emplacements non sécurisés ou transmis à des tiers sans base légale.
Les questions à se poser pour chaque type de log :
- Finalité : à quoi sert ce log ? Si la réponse n'est pas claire, le log est probablement superflu.
- Nécessité : le log a-t-il besoin de l'identité de l'utilisateur pour remplir sa finalité ?
- Durée : combien de temps ce log doit-il vivre pour être utile ? Trois mois d'historique suffisent à la majorité des usages de débogage.
- Accès : qui peut lire ces logs ? L'accès doit être restreint et tracé.
Drupal offre des mécanismes natifs pour paramétrer le niveau de verbosité des logs et leur rétention. Les activer avec intention, plutôt qu'en mode par défaut, est l'une des décisions les plus simples à prendre.
Les consentements — ce qu'on déclenche et quand
Un bandeau de cookies qui bloque toutes les intégrations tierces avant le consentement, mais qui laisse passer les scripts analytics côté serveur, n'est pas conforme. Un formulaire de contact qui coche la case newsletter par défaut non plus.
Sur Drupal, les décisions à prendre concernent :
- Le déclenchement des scripts tiers : aucun traceur, aucun pixel, aucun appel à un service externe ne doit se charger avant que le consentement soit recueilli pour la finalité correspondante.
- La segmentation des finalités : analytics, personnalisation, partage réseaux sociaux — chaque finalité doit pouvoir être acceptée ou refusée indépendamment.
- La preuve du consentement : l'organisation doit être en mesure de démontrer qu'un consentement a bien été donné, à quelle date, pour quelles finalités.
- La révocabilité : retirer son consentement doit être aussi simple que de le donner.
Feuille de route en trois étapes
Étape 1 — Cartographier les flux de données personnelles
Avant de modifier quoi que ce soit, il faut savoir ce qu'on a. Identifier, module par module et intégration par intégration, quelles données personnelles circulent, où elles sont stockées, combien de temps elles vivent et à qui elles sont transmises. Cette cartographie est le registre des traitements que le RGPD exige.
Étape 2 — Appliquer la minimisation à chaque zone prioritaire
Avec la cartographie en main, appliquer le principe de minimisation : désactiver ce qui n'est pas nécessaire, dépersonnaliser ce qui peut l'être, définir des durées de rétention pour ce qui reste. Pour la recherche interne, configurer les logs pour exclure les informations personnelles identifiables. Pour les logs système, activer la suppression automatique au-delà d'une durée définie.
Étape 3 — Documenter et maintenir
La conformité RGPD n'est pas un projet, c'est un état à maintenir. Chaque nouveau module, chaque nouvelle intégration, chaque évolution de la plateforme doit passer par le filtre de la cartographie mise à jour.
Ce que change une approche RGPD-first sur Drupal
Un site Drupal construit avec une logique privacy by design n'est pas un site plus lent ou plus contraint. C'est un système moins exposé — au risque réglementaire, aux fuites de données, aux incidents de sécurité qui commencent souvent par un log qui n'aurait pas dû exister.
C'est aussi un système plus simple à auditer, plus simple à faire évoluer et plus simple à défendre si la CNIL ou un client exige des garanties.
La conformité RGPD, quand elle guide l'architecture dès le départ, devient un avantage compétitif : elle rassure les clients B2B, simplifie les réponses aux appels d'offres et réduit la charge de travail à chaque mise à jour du système.
Ce que DrupaLabs construit
Chez DrupaLabs, nous intégrons le privacy by design dans l'architecture de chaque plateforme Drupal que nous construisons ou maintenons. Recherche interne, stratégie de logs, gestion des consentements, cartographie des traitements : ce sont des décisions d'architecture, pas des options à cocher en fin de projet.
Tout commence par un diagnostic : nous analysons votre périmètre Drupal, identifions les zones de risque prioritaires et définissons les évolutions à apporter — en tenant compte de vos contraintes de performance et d'expérience utilisateur.