Checklist RGPD avant d’envoyer un contenu WordPress à une API de LLM externe

Quelles données quittent réellement le serveur WordPress au moment où une fonction PHP appelle une API de LLM externe ? C’est la première question qu’un développeur interne chez un annonceur doit se poser avant d’intégrer un tel appel dans un site en production, bien avant de se soucier de la qualité des réponses obtenues.

Le réflexe le plus répandu consiste à tester une intégration en environnement de développement avec des données réelles de production, sans se poser la question du sous-traitant que devient, de fait, le fournisseur de l’API. Cette liste de contrôle vise à éviter les oublis les plus fréquents avant un passage en production.

Identifier le fournisseur comme sous-traitant

Un fournisseur de LLM externe qui reçoit des données personnelles, même indirectement via le contenu d’un article ou d’un formulaire, devient un sous-traitant au sens de l’article 28 du RGPD. Cela implique l’existence d’un contrat de sous-traitance en bonne et due forme, précisant la finalité du traitement, la durée de conservation des données côté fournisseur et les garanties de sécurité appliquées.

Ce point est souvent négligé lorsqu’un développeur souscrit lui-même à une clé d’API sans passer par le service juridique de l’entreprise. Avant tout envoi de données personnelles, il faut vérifier que ce contrat existe et couvre bien l’usage prévu, pas seulement l’usage générique décrit dans les conditions générales du fournisseur.

Les six points à vérifier avant le premier appel

1. La base légale du traitement est-elle identifiée (intérêt légitime, consentement, exécution d’un contrat) avant le premier appel ?
2. Le fournisseur de l’API dispose-t-il d’un contrat de sous-traitance couvrant cet usage précis ?
3. Les données transmises contiennent-elles des noms, adresses, numéros de téléphone ou adresses courriel qui pourraient être filtrés avant l’envoi ?
4. Le contenu transmis peut-il inclure des données de santé, d’orientation ou de croyance, catégories particulièrement sensibles au sens de l’article 9 du RGPD ?
5. Une politique de confidentialité mise à jour mentionne-t-elle explicitement ce traitement auprès des utilisateurs concernés ?
6. Existe-t-il une procédure de suppression des données envoyées, en cas de demande d’effacement d’un utilisateur ?

Le filtrage des données avant transmission

Sur un formulaire de contact traité par un LLM pour catégoriser automatiquement une demande, l’adresse courriel et le numéro de téléphone du visiteur n’ont généralement aucune utilité pour la tâche de classification elle-même. Un filtrage simple, appliqué avant l’appel à l’API, retire ces champs du texte transmis :

function filtrer_donnees_avant_envoi( $message ) {
    $message = preg_replace( '/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}/', '[email masque]', $message );
    $message = preg_replace( '/0[1-9](?:[ .-]?[0-9]{2}){4}/', '[telephone masque]', $message );

    return $message;
}

Ce filtrage reste imparfait : il ne détecte pas un nom propre isolé dans une phrase, ni une adresse postale complète. Il réduit néanmoins significativement le volume de données personnelles transmises, pour un coût de mise en œuvre minime.

Le cas particulier des données de santé

Un site qui traite, même occasionnellement, des demandes mentionnant un état de santé (mutuelle, association de patients, cabinet paramédical) doit traiter cette catégorie de données avec une vigilance renforcée. L’article 9 du RGPD encadre strictement le traitement des données de santé, et leur transmission à un fournisseur de LLM externe sans base légale explicite constitue un risque juridique disproportionné par rapport au gain fonctionnel obtenu.

Dans ce cas précis, la recommandation la plus prudente consiste à ne jamais transmettre le contenu brut d’un message susceptible de contenir une telle donnée, et à privilégier un traitement local, sans appel à un fournisseur externe.

Le RGPD ne vise pas à empêcher l’usage de l’IA, il vise à s’assurer que chaque transmission de données personnelles a une raison identifiée et une durée de vie maîtrisée. Cette liste ne remplace pas un avis juridique, elle évite simplement les oublis les plus fréquents.

Pour aller plus loin

Cette checklist ne couvre volontairement pas la classification du système d’IA au sens du règlement européen sur l’intelligence artificielle, qui relève d’une analyse distincte portant sur le niveau de risque de l’usage prévu, et non sur la seule question de la protection des données personnelles.