Pourquoi les soumissions Webform tombent souvent hors du périmètre RGPD
La conformité RGPD se construit habituellement autour des bases structurées: le CRM, la plateforme emailing, le système RH. Webform stocke des soumissions dans des tables spécifiques à Drupal. Elles ne remontent pas automatiquement dans les inventaires de traitements si personne ne les y a inscrites au moment de créer le formulaire.
Trois raisons expliquent cet angle mort. D'abord, Webform stocke les données sous une forme hybride: les champs définis au niveau du formulaire créent des colonnes dédiées, mais les valeurs restent dans un format JSON sérialisé que les outils d'inventaire standards ne parcourent pas. Ensuite, les responsables RGPD interviennent souvent après la mise en ligne. Enfin, les soumissions s'accumulent comme tampon de travail temporaire et deviennent, par inaction, un traitement de fait sans durée de conservation définie.
Comment configurer une durée de conservation dans Webform
Webform permet de configurer une durée de conservation des soumissions directement dans les réglages du formulaire, sans module supplémentaire. Le paramètre Purge prend trois valeurs: None, Draft ou All. Combiné au paramètre Purge days, il fixe la durée au-delà de laquelle les soumissions sont supprimées lors du passage du cron.
La durée doit correspondre à la finalité déclarée dans le registre de traitements, pas à une valeur choisie arbitrairement. La durée renseignée dans Webform n'est pas un registre de traitement: c'est l'outil d'exécution d'une décision qui doit exister ailleurs, par écrit, validée par le DPO.
Planifier les purges automatiques avec le cron Drupal
La purge Webform s'exécute lors des passages du cron Drupal. Si le cron ne tourne pas régulièrement, les durées de conservation configurées ne produisent aucun effet. La page /admin/config/system/cron affiche la dernière exécution et l'intervalle configuré. Pour les installations à fort volume, il vaut mieux piloter le cron depuis le système d'exploitation via drush cron dans une tâche crontab.
La suppression intervient dans le hook webform_cron(). Il n'existe pas de corbeille: une soumission purgée disparaît définitivement. C'est précisément ce point qui rend la preuve d'effacement nécessaire.
Tracer les exports: journalisation des accès aux soumissions
Un export de soumissions Webform vers CSV ou Excel constitue une opération d'accès à des données personnelles. Drupal ne journalise pas ces exports par défaut. La journalisation doit être ajoutée par code personnalisé, via hook_webform_submission_access_alter() pour Watchdog ou hook_webform_results_export_preprocess() pour une table dédiée.
L'entrée de journal doit comporter: l'identifiant du formulaire, l'utilisateur ayant déclenché l'export, la date et l'heure, et la plage de filtrage utilisée. Le module Webform Access restreint les accès par rôle: c'est un prérequis, pas une alternative à la journalisation.
Conserver les preuves d'effacement: le paradoxe documentaire du RGPD
Le RGPD exige de pouvoir prouver qu'une donnée a été effacée. Mais si la donnée est supprimée, comment prouver l'effacement sans conserver une trace qui identifie la personne? La réponse: on conserve l'événement de suppression, pas la donnée.
L'entrée de journal d'effacement doit contenir l'identifiant interne de la soumission, la date et l'heure, le mécanisme de déclenchement (purge cron, suppression manuelle, droit à l'oubli) et l'identifiant de la demande si applicable. Cette entrée ne contient aucune donnée personnelle. Il faut implémenter hook_webform_submission_predelete() pour déclencher cette journalisation.
Traiter les demandes de droit à l'oubli
Une demande de droit à l'oubli (article 17 du RGPD) déclenche une obligation de suppression dans un délai d'un mois. Pour les soumissions Webform, cela implique de retrouver toutes les soumissions associées à la personne concernée. La difficulté: une soumission Webform n'est pas liée à un compte utilisateur si le formulaire n'exige pas de connexion. Il faut chercher par email via webform_get_submissions() avec filtres.
Le processus documenté doit préciser qui reçoit la demande, les étapes de recherche, la procédure de suppression et sa journalisation, et la confirmation envoyée à la personne concernée.
Répartir les responsabilités entre IT et métier
La configuration technique appartient à l'équipe IT. La définition des durées et des finalités appartient au métier et au DPO. Trois points de friction reviennent: IT configure une durée sans validation du DPO, le DPO définit une politique sans la communiquer à l'équipe technique, ou personne n'a couvert les formulaires existants.
La solution: une revue périodique tous les six mois, qui réunit IT et DPO pour vérifier que la configuration Webform correspond au registre de traitements.
Checklist: politique de données praticable pour Webform
Avant la mise en production: finalité inscrite dans le registre, durée de conservation validée par le DPO, durée de purge Webform correspondante, accès restreints par rôle, journalisation des exports activée.
Après le déploiement: cron à intervalle compatible, hook predelete actif, processus droit à l'oubli documenté, revue périodique planifiée.
Pour les formulaires existants: audit des formulaires sans configuration de purge, vérification de la conformité des soumissions anciennes, suppression des soumissions hors périmètre.
Construire une politique de données qui tient dans la durée
Configurer Webform pour la conformité RGPD demande de coordonner trois niveaux: le paramétrage du module, le code personnalisé pour la journalisation, et le processus organisationnel entre IT et DPO. DrupaLabs accompagne les organisations sur ce chantier: audit des formulaires existants, mise en place de la journalisation, configuration des durées de purge en lien avec le registre de traitements, et documentation du processus pour les équipes.
Si vous souhaitez faire le point sur l'état de conformité de votre parc de formulaires Drupal, demandez un diagnostic.