Sur quatorze champs synchronisés automatiquement entre le formulaire d’adhésion d’une association et son CRM HubSpot, deux d’entre eux n’avaient jamais fait l’objet d’un consentement explicite couvrant leur transmission à ce service tiers : la date de naissance complète de l’adhérent, et un champ de situation familiale ajouté initialement pour un usage strictement interne de calcul de cotisation. Ce constat est ressorti d’une revue de conformité menée par l’association elle-même, en amont d’un contrôle de routine qu’elle anticipait sur ses pratiques de traitement de données.
L’origine du problème ne relevait d’aucune intention de contournement : l’extension de synchronisation CRM utilisée par l’association exportait, par défaut, l’intégralité des champs personnalisés du formulaire d’adhésion vers HubSpot, sans distinction entre les champs nécessaires à la gestion de la relation adhérent côté CRM et les champs purement internes à la gestion associative locale.
Une synchronisation par défaut trop généreuse
L’extension de synchronisation, une fois connectée au compte HubSpot de l’association, proposait une correspondance automatique entre les champs du formulaire WordPress et les propriétés de contact correspondantes côté HubSpot, créées à la volée si elles n’existaient pas encore :
add_action( 'gform_after_submission', function( $entry, $form ) {
$contact_hubspot = array();
foreach ( $form['fields'] as $champ ) {
// synchronisation automatique de tous les champs du formulaire, sans distinction
$contact_hubspot[ $champ['hubspotFieldName'] ] = rgar( $entry, (string) $champ['id'] );
}
synchroniser_contact_hubspot( $contact_hubspot );
}, 10, 2 );Ce comportement, pratique au moment de la configuration initiale puisqu’il évite de reconfigurer manuellement chaque champ un par un, transmettait en réalité tout ce que contenait le formulaire d’adhésion, y compris des champs ajoutés ultérieurement pour un tout autre usage que la relation adhérent gérée par le CRM. La date de naissance complète, par exemple, avait été ajoutée au formulaire pour vérifier l’éligibilité à un tarif jeune, un usage purement interne à l’association qui ne justifiait aucune transmission vers HubSpot.
Le filtrage explicite retenu par champ
La correction remplace la synchronisation automatique de tous les champs par une liste explicite des champs autorisés à la transmission, construite en concertation avec le bureau de l’association sur la base légale réelle de chaque transmission envisagée :
function champs_autorises_hubspot() {
return array( 'nom', 'prenom', 'email', 'telephone', 'ville', 'date_adhesion' );
}
add_action( 'gform_after_submission', function( $entry, $form ) {
$champs_autorises = champs_autorises_hubspot();
$contact_hubspot = array();
foreach ( $form['fields'] as $champ ) {
if ( ! in_array( $champ['hubspotFieldName'], $champs_autorises, true ) ) {
continue; // champ exclu explicitement de la synchronisation
}
$contact_hubspot[ $champ['hubspotFieldName'] ] = rgar( $entry, (string) $champ['id'] );
}
synchroniser_contact_hubspot( $contact_hubspot );
}, 10, 2 );Cette liste blanche explicite garantit qu’un nouveau champ ajouté ultérieurement au formulaire d’adhésion, pour un usage interne quelconque, n’est jamais transmis vers HubSpot par défaut : il faut une décision explicite d’ajout à la liste champs_autorises_hubspot() pour qu’un champ supplémentaire rejoigne la synchronisation, ce qui inverse la logique par défaut initialement en place.
Faire correspondre le consentement au filtrage technique
Le filtrage technique seul ne suffit pas à assurer la conformité : la mention de consentement affichée sur le formulaire d’adhésion a été réécrite pour lister précisément les champs transmis à HubSpot, plutôt qu’une formule générique évoquant une transmission « à des fins de gestion de la relation adhérent » qui ne permettait pas à la personne concernée de savoir réellement ce qui était partagé.
Vérifier a posteriori ce qui avait déjà été transmis
Au-delà du correctif appliqué aux nouvelles adhésions, l’association a dû traiter le passif : les contacts HubSpot déjà créés avec les deux champs concernés ont fait l’objet d’une purge ciblée de ces propriétés précises, sans suppression du contact dans son ensemble, préservant ainsi l’historique de relation légitimement constitué par ailleurs. Cette purge a été effectuée via l’API HubSpot, en ciblant uniquement les propriétés date_naissance et situation_familiale sur l’ensemble des contacts existants.
- Identifier tous les champs actuellement synchronisés vers le CRM, sans se fier à la documentation initiale du projet qui peut être obsolète.
- Pour chacun, vérifier explicitement l’existence d’une base légale couvrant précisément cette transmission.
- Retirer de la synchronisation, et purger côté CRM, tout champ qui ne remplit pas cette condition.
Une synchronisation technique facile à mettre en place n’est jamais une justification suffisante pour transmettre une donnée : la question du consentement se pose champ par champ, pas au niveau de l’intégration dans son ensemble.
Ce qu’on retient
Ce cas ne concerne pas une faille de sécurité au sens strict, mais un défaut de conception qui produit le même type de conséquence : une donnée qui circule au-delà de ce que la personne concernée a réellement accepté. Toute intégration de synchronisation CRM installée sur un site WordPress mérite une revue explicite, champ par champ, avant sa mise en production, plutôt qu’une confiance dans le comportement par défaut proposé par l’extension.
