Qu’est-ce qui distingue une donnée personnelle affichée sur une page HTML classique d’une donnée personnelle encodée dans un bloc JSON-LD ? Rien du point de vue de la protection des données, et pourtant les deux ne reçoivent pas le même traitement en pratique : un champ visible à l’écran attire l’attention d’un relecteur, tandis qu’un champ injecté silencieusement dans un balisage structuré généré automatiquement passe souvent inaperçu, alors qu’il reste tout aussi indexable, extractible et copiable par un moteur de recherche ou un outil tiers.
Définition : un balisage pensé pour être lu par des machines
Le balisage Schema.org, sous sa forme JSON-LD, a précisément pour vocation de rendre une information structurée facilement lisible par des systèmes automatisés — moteurs de recherche, agrégateurs, assistants vocaux. Cette qualité devient un risque dès lors que le champ balisé contient une donnée à caractère personnel au sens du RGPD : nom complet associé à une adresse, e-mail, numéro de téléphone direct, ou toute information suffisamment précise pour identifier une personne physique sans son consentement explicite à cette exposition.
Fonctionnement interne : où ces données s’infiltrent le plus souvent
Sur un site WordPress, ces données personnelles s’infiltrent typiquement dans le balisage via des champs Advanced Custom Fields liés à une fiche auteur, un profil de commercial ou de praticien, ou via les métadonnées d’un article rédigé par un contributeur externe dont l’adresse e-mail professionnelle est utilisée comme identifiant unique dans la base WordPress. Les types Schema.org les plus concernés sont ceux qui admettent nativement des propriétés de contact directes :
Person: propriétésemail,telephone,address.LocalBusiness: parfois associé par erreur à un numéro de téléphone personnel plutôt que professionnel générique.ReviewetComment: l’auteur d’un avis client, s’il est identifié par son nom complet réel plutôt qu’un pseudonyme choisi.JobPosting: les offres d’emploi qui incluent par erreur l’e-mail direct d’un recruteur plutôt qu’une adresse générique de candidature.
Le point de génération le plus fréquent reste une boucle automatique qui associe un champ ACF directement à une propriété Schema.org sans filtre intermédiaire, un schéma que l’on retrouve régulièrement sur des sites qui exposent, par exemple, le numéro de téléphone personnel d’un intervenant plutôt que le standard général de l’entreprise.
Cas d’usage : une fiche « auteur » qui expose un e-mail personnel
Un cas rencontré concernait une fiche auteur de blog, où le champ e-mail WordPress natif (utilisé en interne pour les notifications de commentaires) se retrouvait injecté tel quel dans la propriété email du type Person, généré pour chaque page d’archive d’auteur. Cette adresse, jamais destinée à être publique, se retrouvait indexée et exploitable dans les résultats enrichis, exposant potentiellement l’auteur à une collecte automatisée à des fins de prospection non sollicitée.
{
"@type": "Person",
"name": "Camille Vasseur",
"email": "camille.vasseur@exemple-interne.test"
}Pièges : les champs qui semblent anodins mais ne le sont pas
Certains champs paraissent inoffensifs mais méritent une vigilance équivalente : une adresse postale complète associée à un nom, même dans un contexte professionnel, peut suffire à géolocaliser précisément une personne à son domicile si l’activité est exercée depuis un lieu privé (praticien libéral, artisan à domicile). De même, un numéro de téléphone mobile personnel utilisé faute d’un numéro professionnel dédié doit systématiquement être remplacé par une ligne générique avant toute génération de balisage.
function filtrer_donnees_sensibles( array $donnees ) {
$champs_interdits = [ 'email', 'telephone', 'address' ];
foreach ( $champs_interdits as $champ ) {
if ( isset( $donnees[ $champ ] ) && ! est_coordonnee_professionnelle_validee( $donnees[ $champ ] ) ) {
unset( $donnees[ $champ ] );
}
}
return $donnees;
}Une donnée personnelle balisée en JSON-LD n’est pas moins sensible qu’une donnée affichée à l’écran : elle est simplement plus facile à extraire en masse, ce qui aggrave le risque plutôt que de l’atténuer.
En résumé
La génération automatique de balisage Schema.org doit intégrer, dès sa conception, un filtre explicite sur les propriétés susceptibles de contenir des données à caractère personnel non validées pour une exposition publique. Une liste de blocage couvrant les types Person, LocalBusiness, Review et JobPosting, associée à une vérification que seules des coordonnées professionnelles génériques sont exposées, permet d’éviter l’essentiel des expositions accidentelles.
