Un cabinet d’expertise comptable présent en France et en Belgique francophone et néerlandophone nous a signalé un problème lors d’un contrôle interne de conformité : la bannière de consentement aux cookies, gérée par une extension de gestion du consentement (CMP), restait affichée intégralement en anglais sur la version néerlandaise du site, alors que le reste du contenu était bien traduit. Un détail en apparence mineur, mais qui pose un vrai problème juridique : un consentement recueilli dans une langue que le visiteur ne maîtrise pas nécessairement n’est pas un consentement valablement éclairé au sens du RGPD.
Cet incident a été l’occasion de construire une checklist de contrôle RGPD propre aux sites multilingues, distincte des mentions légales elles-mêmes, déjà traitées par ailleurs, et centrée sur les points spécifiquement liés à la coexistence de plusieurs langues sur un même site.
1. La bannière de consentement est-elle traduite dans toutes les langues actives ?
Ce premier point semble évident, mais de nombreuses extensions de gestion du consentement ne sont pas nativement compatibles avec WPML ou Polylang : leurs textes par défaut sont parfois codés en dur dans le plugin, hors du système de chaînes traduisibles standard de WordPress. Sur ce projet, la CMP utilisée exposait bien un filtre cmplz_banner_text permettant de surcharger les textes, mais ce filtre n’était tout simplement pas branché sur la langue courante détectée par WPML.
2. Les finalités de cookies sont-elles configurées par langue, ou seulement les libellés ?
Un point souvent négligé : traduire les libellés des catégories de cookies (« Marketing », « Statistiques ») ne suffit pas si les finalités elles-mêmes diffèrent d’un pays à l’autre pour des raisons réglementaires locales. Sur ce projet, la Belgique impose des règles légèrement différentes de la France concernant certains cookies de mesure d’audience exemptés de consentement préalable. La configuration technique des finalités doit donc être vérifiée pays par pays, pas seulement traduite mot à mot.
3. Le registre des consentements trace-t-il la langue affichée au moment du recueil ?
C’est le point qui a le plus surpris le client lors de notre audit. En cas de contrôle par une autorité de protection des données, il faut pouvoir démontrer que le consentement recueilli l’a été dans une langue compréhensible par la personne concernée. La plupart des extensions de CMP journalisent l’horodatage et l’adresse IP anonymisée du consentement, mais pas systématiquement la langue affichée à ce moment précis. Un correctif simple consiste à enrichir l’enregistrement du consentement avec la langue courante :
add_action( 'cmplz_before_store_consent', function ( $donnees_consentement ) {
$donnees_consentement['langue_affichee'] = apply_filters( 'wpml_current_language', null );
return $donnees_consentement;
} );4. Les liens vers la politique de confidentialité pointent-ils vers la bonne langue ?
Un classique : le lien « En savoir plus » de la bannière de consentement pointe systématiquement vers l’URL française de la politique de confidentialité, quelle que soit la langue affichée. Ce lien doit être généré dynamiquement via wpml_object_id plutôt que codé en dur dans les réglages de la CMP.
5. Les préférences enregistrées sont-elles conservées lors d’un changement de langue en cours de visite ?
Si un visiteur accepte les cookies statistiques en français puis bascule vers la version anglaise du site, ses préférences doivent rester valables : elles concernent le domaine et le navigateur, pas la langue affichée. Un défaut fréquent est qu’une CMP mal configurée redemande le consentement à chaque changement de langue, ce qui dégrade l’expérience sans bénéfice juridique, le consentement portant sur le traitement de données, pas sur la langue d’affichage.
6. Les formulaires de contact traduits respectent-ils les mêmes mentions d’information ?
Enfin, chaque formulaire traduit doit reprendre l’intégralité des mentions d’information sur le traitement des données (finalité, durée de conservation, droits de la personne), pas un résumé allégé. Sur ce projet, le formulaire de contact anglais ne comportait qu’une case à cocher générique « I agree to the terms », sans lien ni mention détaillée, alors que la version française comportait bien le texte complet requis.
- Vérifier la traduction complète de la bannière et du centre de préférences ;
- Vérifier la configuration des finalités par pays, pas seulement des libellés ;
- Ajouter la langue affichée dans le registre des consentements ;
- Corriger les liens de politique de confidentialité pour qu’ils suivent la langue courante ;
- Vérifier la persistance des préférences lors d’un changement de langue ;
- Auditer chaque formulaire traduit pour la complétude des mentions d’information.
Un site multilingue conforme en français ne l’est pas automatiquement dans les autres langues : la conformité RGPD doit être vérifiée langue par langue, pas déduite par extension.
Pour aller plus loin
Cette checklist ne remplace pas un avis juridique formel, mais elle permet de repérer, en une revue technique d’une heure, la majorité des écarts les plus fréquents sur les sites multilingues que nous auditons. Sur ce projet précis, quatre des six points ont nécessité une correction, ce qui donne une idée de la fréquence réelle de ce type d’oubli, même sur des sites par ailleurs bien construits sur le plan éditorial.
