Une extension qui envoie des adresses e-mail, des noms ou des numéros de téléphone vers une API tierce déclenche, techniquement, un transfert de données personnelles. Que ce transfert reste dans l’Union européenne ou en sorte change radicalement les obligations qui pèsent sur l’agence qui livre l’intégration. Trop souvent, cette question n’est posée qu’après coup, quand le client demande où sont hébergées ses données.
Cette checklist s’adresse à une équipe qui développe une intégration sortante — un connecteur vers un service de facturation, un outil d’analyse comportementale ou une plateforme d’e-mailing — et qui doit livrer quelque chose de défendable devant un client ou, le cas échéant, une autorité de contrôle. Elle ne traite pas du stockage local des données : uniquement de ce qui part vers l’extérieur.
Identifier précisément ce qui sort du serveur
Avant d’écrire la moindre ligne d’appel HTTP, dressez la liste exhaustive des champs transmis. Il ne suffit pas de dire « on envoie le formulaire de contact » : il faut lister chaque clé du tableau envoyé, y compris les métadonnées ajoutées automatiquement par certains SDK (adresse IP, user-agent, identifiant de session). Une extension qui utilise wp_remote_post() pour transmettre un tableau construit à la volée doit documenter ce tableau ligne par ligne, pas seulement son intention générale.
- Champs directement identifiants : nom, prénom, e-mail, téléphone.
- Champs indirectement identifiants : adresse IP, identifiant de session, empreinte de navigateur.
- Champs sensibles au sens de l’article 9 du RGPD : santé, origine, opinions — à isoler en priorité.
Vérifier le mécanisme de transfert utilisé par le prestataire tiers
Un transfert hors Union européenne n’est licite que s’il repose sur un mécanisme reconnu : décision d’adéquation de la Commission européenne pour le pays destinataire, clauses contractuelles types (CCT) signées avec le sous-traitant, ou règles d’entreprise contraignantes pour un groupe international. Le simple fait qu’un prestataire affirme être « conforme RGPD » sur sa page marketing ne constitue pas une preuve juridique suffisante : demandez le document contractuel qui encadre le transfert, pas une promesse commerciale.
Documenter la base légale et le consentement
Chaque transfert doit reposer sur une base légale précise : exécution d’un contrat, intérêt légitime documenté, ou consentement explicite. Si votre extension déclenche l’envoi dès la soumission d’un formulaire, la case à cocher de consentement doit exister avant l’appel réseau, pas après. Un piège classique : une case pré-cochée, ou une formulation qui mélange plusieurs finalités dans un seul consentement générique. Le consentement doit être spécifique à chaque finalité de traitement.
if ( empty( $_POST['consentement_transfert'] ) ) {
return new WP_Error(
'consentement_manquant',
'Le consentement au transfert de données est requis avant envoi.'
);
}
// L'appel sortant n'a lieu qu'après validation explicite.
wp_remote_post( $endpoint, [ 'body' => $donnees_filtrees ] );Minimiser avant de transmettre
Le principe de minimisation impose de ne transmettre que ce qui est strictement nécessaire à la finalité annoncée. Concrètement, cela veut dire filtrer le tableau de données juste avant l’appel réseau, plutôt que de transmettre l’objet complet récupéré depuis la base. Une fonction dédiée, appelée systématiquement avant tout envoi, évite qu’un futur ajout de champ ne parte accidentellement vers le tiers :
function preparer_export_minimal( array $donnees ) : array {
$champs_autorises = [ 'email', 'prenom', 'date_inscription' ];
return array_intersect_key( $donnees, array_flip( $champs_autorises ) );
}Tenir à jour le registre des sous-traitants
Chaque service tiers destinataire de données doit apparaître dans le registre des activités de traitement du client, avec la finalité, la nature des données, la durée de conservation et le mécanisme de transfert. Ce registre n’est pas un document théorique : en cas de contrôle, c’est la première pièce demandée. Une agence qui livre l’intégration a intérêt à fournir une fiche synthétique au client au moment de la mise en production, plutôt que de laisser cette tâche à sa charge une fois le projet clos.
| Point de contrôle | Preuve attendue |
|---|---|
| Mécanisme de transfert | Clauses contractuelles types signées ou décision d’adéquation citée |
| Base légale | Case de consentement horodatée ou contrat identifié |
| Minimisation | Liste des champs effectivement transmis, à jour |
| Durée de conservation | Politique de purge documentée côté tiers |
Prévoir le droit à l’effacement en aval
Une donnée transmise à un tiers reste soumise au droit à l’effacement. Si un utilisateur exerce ce droit, l’extension doit savoir déclencher, ou au minimum documenter, la demande de suppression correspondante côté prestataire. Un simple champ dans l’interface d’administration listant les services tiers ayant reçu une donnée personnelle donnée facilite grandement cette traçabilité, plutôt que de devoir fouiller le code pour retrouver tous les points d’envoi.
En résumé
Six vérifications suffisent à couvrir l’essentiel : nature exacte des données transmises, mécanisme juridique du transfert, base légale documentée, minimisation effective, registre des sous-traitants à jour, et procédure d’effacement en aval. Aucune de ces étapes ne relève de la sur-qualité : elles correspondent à des obligations concrètes, et leur absence expose directement le client final, pas seulement l’agence qui a écrit le code.
