Essayez sans attendre l'hébergement proposé par WordPress
-15% sur le premier mois avec le code 2025PRESS15AFF

Essayer maintenant

Créer un plugin WordPress compatible RGPD nativement : gestion du consentement sans dépendance externe

Développer un plugin WordPress, c’est bien… mais s’assurer qu’il respecte le RGPD sans dépendre d’un outil tiers, c’est une autre histoire. Pourtant, c’est tout à fait faisable nativement, en exploitant les mécanismes déjà intégrés dans WordPress. Dans cet article, on va voir comment concevoir un système de consentement solide, de l’architecture technique jusqu’à la checklist de conformité avant publication.

Les bases légales du RGPD appliquées au développement WordPress

Avant d’écrire la moindre ligne de code, il faut comprendre ce que le RGPD impose réellement. Pas besoin d’être juriste, mais ignorer le cadre légal quand on développe un plugin qui touche aux données personnelles, c’est s’exposer à de vrais problèmes. Et franchement, ça arrive plus souvent qu’on ne le croit dans la communauté WordPress.

Ce que la loi impose concrètement à un plugin

Le RGPD repose sur quelques principes fondamentaux que tout développeur doit avoir en tête. L’article 6 du règlement liste les bases légales qui justifient un traitement de données : le consentement, l’exécution d’un contrat, l’intérêt légitime, ou encore une obligation légale. En clair : vous ne pouvez pas collecter des données « parce que c’est pratique ». Il faut une raison valable, clairement identifiée.

Concrètement, votre plugin doit respecter plusieurs obligations :

  • Finalité : les données collectées doivent servir un objectif précis et déclaré (pas question de réutiliser des logs à d’autres fins)
  • Minimisation : on collecte uniquement ce dont on a besoin, rien de plus
  • Durée de conservation : les données ne peuvent pas dormir indéfiniment dans une base MySQL — il faut définir une durée et la respecter
  • Droit à l’oubli : votre plugin doit permettre la suppression des données d’un utilisateur sur demande (l’article 17 du RGPD est explicite là-dessus)

L’article 7, lui, encadre spécifiquement le consentement : il doit être libre, éclairé, spécifique et univoque. Un pré-cochage de case ? Invalide. Un consentement global fourre-tout ? Invalide aussi.

Les données à risque : cookies, logs, formulaires

Tous les plugins ne sont pas logés à la même enseigne. Mais certains types de données déclenchent quasi systématiquement des obligations RGPD. Voici les cas les plus fréquents dans l’écosystème WordPress :

  • Cookies analytiques : dès qu’un cookie permet de suivre le comportement d’un utilisateur (même anonymisé partiellement), il entre dans le périmètre du RGPD et de la directive ePrivacy
  • Adresses IP dans les logs : une IP est une donnée personnelle. Si votre plugin écrit des logs d’accès ou d’erreurs avec des IPs, vous êtes concerné — même pour un simple plugin de sécurité
  • Formulaires de contact : nom, email, message… Ces données sont stockées où ? Combien de temps ? Qui y a accès ? Autant de questions auxquelles votre plugin doit répondre
  • Pixels de tracking : un pixel tiers (Meta, Google, etc.) intégré via votre plugin transmet des données à un tiers. Ça implique une mention dans la politique de confidentialité et, souvent, un consentement préalable

Le point commun de tout ça ? Ces données circulent souvent sans que l’utilisateur final du site en soit vraiment conscient. Et c’est exactement ce que le RGPD veut corriger.

Quand le consentement est-il réellement obligatoire ?

C’est la question que tout le monde se pose, et la réponse est : pas toujours. Le consentement est l’une des six bases légales possibles, pas la seule. Donc non, vous n’avez pas à afficher une popup de consentement pour chaque traitement de données.

Voilà comment distinguer les cas :

Le consentement est obligatoire quand :

  • Vous déposez des cookies non essentiels (analytics, marketing, tracking)
  • Vous collectez des données à des fins publicitaires ou de profilage
  • Le traitement n’entre dans aucune autre base légale valide

Une autre base légale peut suffire quand :

  • L’intérêt légitime s’applique : par exemple, loguer les tentatives de connexion échouées pour sécuriser un site. C’est justifié, proportionné, et l’utilisateur peut s’y attendre raisonnablement.
  • L’exécution d’un contrat couvre le traitement : stocker l’adresse email d’un acheteur pour lui envoyer sa confirmation de commande ne nécessite pas de consentement supplémentaire.
  • Une obligation légale impose la conservation : certaines données de facturation doivent être gardées plusieurs années, peu importe ce que l’utilisateur demande.

Bon, ça semble abstrait dit comme ça — mais dans la pratique, ça change tout dans l’architecture de votre plugin. Si vous pouvez vous appuyer sur l’intérêt légitime, vous n’avez pas besoin de bloquer une fonctionnalité en attendant un clic de l’utilisateur. Par contre, si vous intégrez des cookies analytics tiers, pas le choix : il faudra du consentement explicite avant tout dépôt.

Cette distinction, c’est vraiment la fondation sur laquelle on va construire toute la logique de consentement de notre plugin. Prenez le temps de bien l’intégrer avant de passer au code.

Architecturer un système de consentement natif dans son plugin

C’est ici que ça devient vraiment intéressant. On va construire, brique par brique, un système de gestion du consentement complet — sans installer Cookiebot, sans dépendre de Complianz, sans aucune librairie externe. Juste WordPress, PHP et un peu de rigueur.

Stocker le consentement : options, user meta ou cookie maison ?

Le premier choix architectural, c’est : où est-ce qu’on stocke le consentement ? Il n’y a pas de réponse universelle — ça dépend du contexte. Voici les trois approches principales :

  • wp_options : idéal pour stocker les réglages globaux du plugin (catégories de cookies activées par défaut, durée de conservation, etc.). On y accède via get_option() et update_option(). Pratique, mais pas adapté pour tracer le consentement individuel.
  • user_meta : parfait pour les utilisateurs connectés. On stocke le choix de chaque utilisateur directement dans sa fiche avec update_user_meta() et get_user_meta().
  • Cookie JS côté client : pour les visiteurs anonymes, c’est la seule option viable. On pose un cookie via JavaScript (ou via setcookie() en PHP côté serveur), qu’on relira ensuite à chaque requête.

En pratique, un plugin sérieux combine les trois selon le cas. Voici un exemple pour enregistrer et lire le consentement d’un utilisateur connecté :

// Enregistrer le consentement
function mon_plugin_save_consent( $user_id, $consent_value ) {
    $clean_value = sanitize_text_field( $consent_value ); // 'granted' ou 'denied'
    update_user_meta( $user_id, 'mon_plugin_consent', $clean_value );
}

// Lire le consentement
function mon_plugin_get_consent( $user_id ) {
    $consent = get_user_meta( $user_id, 'mon_plugin_consent', true );
    return ( $consent === 'granted' ) ? 'granted' : 'denied';
}

Pour les visiteurs anonymes, on lit le cookie côté PHP avec $_COOKIE['mon_plugin_consent'] — en prenant soin de le valider avec sanitize_text_field() avant tout usage. Ne faites jamais confiance à une valeur de cookie brute.

Exposer une API interne pour conditionner les scripts

Bon, stocker le consentement c’est bien. Mais si vos scripts se chargent quand même, ça ne sert à rien. L’étape suivante : s’assurer que wp_enqueue_scripts ne charge les ressources concernées qu’après consentement explicite.

L’approche propre consiste à créer un hook personnalisé que les autres parties de votre plugin (ou même des développeurs tiers) pourront utiliser :

// Vérifier le consentement et déclencher un hook
function mon_plugin_check_and_load_scripts() {
    $consent = mon_plugin_is_consent_given(); // true ou false

    // Filtre permettant à d'autres de modifier la valeur
    $consent = apply_filters( 'mon_plugin_consent_given', $consent );

    if ( $consent ) {
        do_action( 'mon_plugin_consent_granted' );
    }
}
add_action( 'wp_enqueue_scripts', 'mon_plugin_check_and_load_scripts', 5 );

// Exemple d'enqueue conditionnel accroché sur notre action custom
function mon_plugin_enqueue_tracking_script() {
    wp_enqueue_script(
        'mon-plugin-tracker',
        plugin_dir_url( __FILE__ ) . 'assets/js/tracker.js',
        [],
        '1.0.0',
        true
    );
}
add_action( 'mon_plugin_consent_granted', 'mon_plugin_enqueue_tracking_script' );

Cette architecture est propre et extensible. Si demain vous voulez ajouter un script analytics, vous n’avez qu’à l’accrocher sur mon_plugin_consent_granted. Pas besoin de toucher à la logique de consentement.

Implémenter le retrait du consentement et la suppression des données

C’est souvent la partie qu’on oublie — et pourtant, le droit à l’oubli est au cœur du RGPD. Depuis WordPress 4.9.6, il existe deux hooks natifs pour s’intégrer dans l’outil de confidentialité intégré : wp_privacy_personal_data_exporters et wp_privacy_personal_data_erasers. Autant les utiliser.

// Enregistrer l'exporteur de données
add_filter( 'wp_privacy_personal_data_exporters', 'mon_plugin_register_exporter' );

function mon_plugin_register_exporter( $exporters ) {
    $exporters['mon-plugin'] = [
        'exporter_friendly_name' => __( 'Mon Plugin - Données de consentement', 'mon-plugin' ),
        'callback'               => 'mon_plugin_export_user_data',
    ];
    return $exporters;
}

// Enregistrer l'outil de suppression
add_filter( 'wp_privacy_personal_data_erasers', 'mon_plugin_register_eraser' );

function mon_plugin_register_eraser( $erasers ) {
    $erasers['mon-plugin'] = [
        'eraser_friendly_name' => __( 'Mon Plugin - Suppression du consentement', 'mon-plugin' ),
        'callback'             => 'mon_plugin_erase_user_data',
    ];
    return $erasers;
}

function mon_plugin_erase_user_data( $email_address, $page = 1 ) {
    $user = get_user_by( 'email', $email_address );
    $removed = false;

    if ( $user ) {
        delete_user_meta( $user->ID, 'mon_plugin_consent' );
        $removed = true;
    }

    return [
        'items_removed'  => $removed,
        'items_retained' => false,
        'messages'       => [],
        'done'           => true,
    ];
}

Ainsi, quand un administrateur déclenche une demande d’effacement depuis Outils > Effacer les données personnelles, votre plugin répondra automatiquement. C’est propre, natif, et ça évite de réinventer la roue.

Rendre le système compatible avec les autres plugins RGPD du marché

Dernier point — et pas des moindres. Certains de vos utilisateurs ont déjà installé Complianz ou Cookiebot sur leur site. Votre plugin ne doit pas entrer en conflit avec ces solutions : il doit leur déléguer la gestion du consentement si elles sont présentes.

C’est exactement le rôle du filtre mon_plugin_consent_given qu’on a exposé plus tôt. Un développeur tiers (ou vous-même dans un addon) peut l’utiliser comme ceci :

// Exemple : intégration avec Complianz
add_filter( 'mon_plugin_consent_given', function( $default ) {
    if ( function_exists( 'cmplz_has_consent' ) ) {
        return cmplz_has_consent( 'statistics' ); // retourne true/false
    }
    return $default; // fallback sur votre propre logique
} );

Et pour Cookiebot, même principe :

add_filter( 'mon_plugin_consent_given', function( $default ) {
    if ( isset( $_COOKIE['CookieConsent'] ) ) {
        $consent_data = json_decode( sanitize_text_field( wp_unslash( $_COOKIE['CookieConsent'] ) ), true );
        return ! empty( $consent_data['statistics'] );
    }
    return $default;
} );

En exposant ce filtre dès le départ, vous laissez la porte ouverte à toutes les intégrations possibles — sans coupler votre plugin à une solution tierce spécifique. C’est de l’architecture ouverte, dans le bon sens du terme.

Checklist et bonnes pratiques pour auditer son plugin avant publication

Avant de publier ou distribuer votre plugin, un audit RGPD sérieux s’impose. Ce n’est pas une formalité administrative — c’est une protection concrète pour vous et pour vos utilisateurs. Voici les points de contrôle incontournables à valider, un par un.

✅ Aucune donnée personnelle collectée sans consentement préalable C’est le point de départ. Si votre plugin enregistre une adresse e-mail, une IP ou n’importe quelle donnée identifiante, il doit s’assurer qu’un consentement explicite a bien été recueilli avant. On ne collecte pas « au cas où » : la finalité doit être définie à l’avance et communiquée clairement. Revoyez chaque appel à $wpdb->insert(), chaque update_user_meta(), et demandez-vous : est-ce que l’utilisateur a vraiment accepté ça ?

✅ Politique de confidentialité mise à jour via le filtre wp_add_privacy_policy_content WordPress fournit un mécanisme natif pour ça. Votre plugin doit utiliser le filtre wp_add_privacy_policy_content pour injecter automatiquement sa propre section dans la page de politique de confidentialité du site. Si vous ne l’avez pas encore implémenté, c’est un oubli critique. L’administrateur du site ne devrait pas avoir à chercher ce que fait votre plugin avec les données — ça doit être documenté et accessible en un clic.

✅ Durée de conservation des données définie et documentée Combien de temps votre plugin conserve-t-il les données ? Six mois ? Un an ? Indéfiniment ? (Ce dernier cas est à proscrire.) La durée de conservation doit être explicitement définie dans votre code — via un mécanisme de purge automatique ou une option de configuration — et documentée dans la politique de confidentialité injectée. Sans ça, vous êtes en infraction potentielle même si le consentement a été bien géré.

✅ Pas de transfert de données hors UE sans garanties adéquates Votre plugin appelle une API externe ? Un service analytics américain ? Un webhook vers un serveur tiers ? Vous devez vérifier où ces données atterrissent. Si elles sortent de l’Union Européenne, des garanties adéquates sont obligatoires : clauses contractuelles types (CCT), Privacy Shield (invalidé, donc à éviter), ou équivalent. Documentez-le. Et si vous ne pouvez pas garantir la conformité de ce service tiers, c’est un vrai problème à régler avant publication.

✅ Tests du flux de retrait de consentement Le retrait du consentement doit être aussi simple que son obtention — c’est une exigence du RGPD, pas une option. Testez concrètement le scénario complet : un utilisateur donne son accord, puis le retire. Est-ce que les données collectées sont bien supprimées ou anonymisées ? Est-ce que les traitements en cours s’arrêtent ? Est-ce que l’eraser enregistré via wp_privacy_personal_data_erasers fonctionne correctement ? Faites ce test avant chaque release, pas seulement à la première mise en place.

✅ Vérification que les cookies tiers sont bloqués par défaut avant accord Si votre plugin charge des ressources tierces (scripts analytics, fonts Google, pixels de suivi…), ils ne doivent pas se déclencher avant que l’utilisateur ait donné son accord. Le bon comportement par défaut : tout est bloqué, et c’est le consentement qui déverrouille. Vérifiez avec les DevTools du navigateur, en mode navigation privée, sans aucun cookie présent. Ce que vous voyez dans les requêtes réseau, c’est ce que voit un nouvel utilisateur.

Deux outils à garder sous la main :

  • Le WordPress Privacy Policy Guide (accessible dans Réglages > Confidentialité de votre back-office) donne un cadre de référence officiel pour rédiger les sections de politique de confidentialité. C’est un bon point de départ pour structurer ce que votre plugin doit documenter.
  • Le plugin Plugin Check (PCP), développé par l’équipe WordPress.org, automatise la vérification de bonnes pratiques sur votre plugin avant soumission dans le répertoire officiel. Il ne couvre pas tout le spectre RGPD, mais il détecte certains problèmes courants (scripts mal enqueués, données non sanitizées, etc.). À utiliser systématiquement avant de pousser une nouvelle version.

Bon, soyons honnêtes : un plugin 100% RGPD-proof, ça ne s’improvise pas en une après-midi. Ça demande du temps, de la rigueur, et quelques itérations. Mais le jeu en vaut largement la chandelle. Vous protégez vos utilisateurs, vous limitez votre responsabilité légale, et vous construisez un outil digne de confiance. Dans un écosystème WordPress où la confidentialité devient un critère de choix pour les clients, c’est aussi un vrai avantage compétitif.