Aller au contenu principal

J'ai pris le contrôle de mes métadonnées

· 9 minutes de lecture
Florence
Florence
Rédactrice Technique Expert

Comment j'ai agis sur les données structurées pour contrôler mon identité numérique

À l'ère où tout est data — nos photos, nos documents, nos publications, nos sites — les métadonnées sont devenues un enjeu stratégique majeur.
Les moteurs de recherche, les moteurs génératifs, les ATS, les plateformes de Freelancing, les IA... tous lisent ces métadonnées avant même de lire le contenu.

Les métadonnées influencent donc la manière dont les moteurs de recherche, les moteurs génératifs, les ATS, les IA et même les outils internes interprètent vos contenus.
Elles deviennent une sorte de carte d'identité numérique, un passeport sémantique.

Contrairement à un PDF* ou à une base de connaissances figée, un site Web offre un avantage décisif : on peut y écrire soi‑même ses métadonnées et donc, les contrôler.

L'identité numérique de CoffeeCup.tech est faite de données structurées

Pour une petite entreprise comme la mienne, définir soigneusement ses métadonnées, c'est vital. La visibilité ne dépend pas seulement du SEO classique, mais aussi du GEO, c'est‑à‑dire la capacité à être compris, cité et utilisé par les moteurs génératifs.

Par ailleurs, je voulais verrouiller mon identité numérique avant que d'autres ne la définissent à ma place.

C'est là que les données structurées entrent en scène. Elles ne sont pas là pour "faire joli". Elles sont là pour décrire, relier, contextualiser. Et surtout : elles parlent aux machines dans leur propre langage.

* Les métadonnées des PDF sont issues du document d'origine. Il est alors très recommandé de renseigner soi-même les informations d'un document Word, par exemple.

Pourquoi les données structurées sont essentielles aujourd'hui​

Les données structurées permettent de décrire précisément une page Web pour les machines. Elles sont définies par le vocabulaire schema.org et intégrées dans les pages via des formats comme JSON‑LD, recommandé par Google.

Un rôle essentiel​

Elles servent à :

  • Clarifier la sémantique : les moteurs comprennent mieux le contexte, les entités, les relations.

  • Renforcer la cohérence de marque : vous contrôlez la façon dont votre entreprise, votre produit ou vous-même êtes décrits.

  • Améliorer la sécurité informationnelle : vous maîtrisez ce qui circule dans les data lakes mondiaux.

  • Optimiser SEO + GEO : les moteurs génératifs semblent s'appuyer sur ces signaux lorsqu'ils sont disponibles.

Les entités de base​

Même si Google ne "l'exige" pas formellement, il recommande fortement dans sa documentation que tout site professionnel déclare au minimum les entités :

  • WebSite
  • Organization

Auxquelles on peut ajouter, pour les marques personnelles ou les auteurs, une entité Person pour contribuer à renforcer le E‑E‑A‑T* : plus vous êtes un expert reconnu et plus vous avez de chances d'être cité par les moteurs génératifs.

* Experience, Expertise, Authoritativeness, and Trustworthiness", en français "Expérience, expertise, autorité et fiabilité".

L'info à la source

La documentation Google Search Central

JSON‑LD : le format recommandé​

JSON-LD : JavaScript Object Notation for Linked Data

Le JSON‑LD est un format léger permettant d'injecter des données structurées dans le <head> d'une page HTML.

Il offre :

  • une syntaxe simple,
  • une séparation claire entre contenu et métadonnées,
  • une compatibilité optimale avec Google.

Types et propriétés : misez sur la qualité​

Google utilise principalement une partie du vocabulaire schema.org.
Il vaut mieux choisir peu de propriétés, mais bien définies, cohérentes et complètes.

Google avertit explicitement que l'utilisation d'un schéma non pertinent peut entraîner l'ignorance de l'intégralité du graphe JSON-LD, en particulier en cas d'erreur de classification sémantique.

Pour ma part, j'ai complété les entités "de base" (WebSite, Organization et Person) avec les définitions de l'auteur, de l'éditeur, de mes pages et de mes articles de blog.
J'ai laissé de côté la propriété Speakable (destinée aux utilisateurs américains disposant d'appareils Google Home configurés en anglais) parce que non pertinente pour mon cas.

L'info à la source

Vocabulaire Schema.org

Soyez précis et descriptifs​

Les propriétés descriptives sont essentielles pour le GEO :

  • descriptions riches
  • mots‑clés naturels
  • images
  • dates
  • liens canoniques
  • et identifiants (@id)

Elles renforcent la compréhension machine et la cohérence globale du site.

👩‍💻
Petit challenge : être précis et descriptif avec un nombre contrôlé de caractères, sans faire de bourrage de mots-clés tout en étant inventif.

Exemple​

Voici la définition de l'auteur du site Web CoffeeCup.tech avec toutes ses propriétés :

      "author": {
        "@type": "Person",
        "name": "Florence Venisse",
        "givenName": "Florence",
        "familyName": "Venisse",
        "jobTitle": "Expert Technical Writer",
        "url": "https://coffeecup.tech/about/",
        "image": "https://coffeecup.tech/img/Florence_CoffeeCup.tech10.png",
        "description": "Florence Venisse is a technical writer with more than 20 years of experience in software documentation xxxxxx.",
        "worksFor": "Coffee.Cup.tech",
        "sameAs": "https://www.linkedin.com/in/florencevenisse/",
        "knowsAbout": [
          "technical writing",
          (...)
        ]
      },

Comment injecter les données structurées dans Docusaurus​

Bon à savoir : Docusaurus injecte automatiquement un BreadcrumbList dans le code HTML <head>, ainsi qu'un hreflang si vous avez activé l'i18N.

Exemple de BreadcrumbList dans le head du code HTML

La capacité de personnalisation de Docusaurus permet de compléter cette propriété par défaut avec vos propres schémas.

L'info à la source

La documentation Docusaurus sur le SEO.

Deux approches sont alors possibles.

Injection globale via docusaurus.config.js​

Fichier où l'on définit à peu près tout (sinon c'est dans src 😁), docusaurus.config.js est la cible logique pour y placer le JSON-LD, notamment s'il ne contient que quelques entités "de base".

  • Avantages : simple et centralisé.
  • Limite : le même JSON‑LD est injecté partout, même sur les pages qui nécessitent un schéma spécifique.

Injection via un composant React​

Autre approche : l'injection page par page via un composant React (fichier Root.js).

C'est l'approche que j'ai choisie.
Il faut dire que mon site Web comporte beaucoup de pages, et que la répétition d'un même contenu un peu sommaire n'avait pas d'intérêt au regard de mes objectifs.

Cette méthode permet :

  • une centralisation du code (un seul fichier gère tout),
  • une évolutivité (ajouter une page = ajouter une entrée dans un tableau),
  • un balisage adapté à chaque page,
  • une cohérence SEO + GEO.

C'est une architecture propre, maintenable et parfaitement adaptée à un site de documentation.

Exemple​

Voici le début et la fin de mon fichier Root.js :

// src/theme/Root.js
import React from 'react';
import { useLocation } from '@docusaurus/router';

export default function Root({ children }) {
  const location = useLocation();

  // Définition des JSON-LD par page
  const schemas = {

    // Home page
    '/': {
      "@context": "https://schema.org",
      "@graph": [
        {
          "@type": "Organization",
          "@id": "https://coffeecup.tech/#organization",
          "name": "CoffeeCup.tech",
          "legalName": "Florence Venisse EI",
          "legalRepresentative": {
            "@id": "https://coffeecup.tech/#person"
          },
          "location": "France",
          "url": "https://coffeecup.tech/",
          "logo": "https://coffeecup.tech/img/logo/coffeecup_logo_small.webp",
          "description": "CoffeeCup.tech provides expert technical writing, API and SDK documentation, docs-as-code xxxxxx",
          "sameAs": "https://www.linkedin.com/in/florencevenisse/",
          "founder": { "@id": "https://coffeecup.tech/#person" },
        }
      ],
      (...)
    }
  };

  const schema = schemas[location.pathname];

  return (
    <>
      {children}
      {schema && (
        <script type="application/ld+json">
          {JSON.stringify(schema)}
        </script>
      )}
    </>
  );
}

👩‍💻
Au final, j'ai un fichier JSON-LD de 2799 lignes, et ce juste pour une langue (l'anglais) !
Or, mon site est bilingue anglais-français : petit teasing sur la méthode 3 qui a succédé à la méthode 2 et dont je vous parlerai dans mon prochain article.

La validation : une étape indispensable​

J'ai passé beaucoup de temps dans les outils de test :

Google recommande de tester systématiquement ses données structurées.

J'ai validé chaque bloc indépendamment, puis l'ensemble du schéma.
Cela permet de détecter :

  • les incohérences,
  • les propriétés obsolètes,
  • les erreurs de syntaxe,
  • les conflits entre schémas.

Au final, on est content lorsque Google PageSpeed Insights valide votre travail :

Diagnostic de performance Google PageSpeed Insights

L'intérêt des données structurées pour un site de documentation​

On pourrait croire qu'un site de documentation n'a pas besoin de tout ça.
Qu'il suffit qu'il contienne les infos concernant le produit et qu'il soit exploitable par les utilisateurs.

Mais un site de documentation, c'est plus que ça : c'est une source de vérité sur le produit et le porte-voix de l'entreprise, un élément à part entière de sa communication, interne ou externe.

Site avec accès restreint​

Même si le site n'est pas indexé, les données structurées restent utiles :

  • pour un LLM interne
  • pour un chatbot privé
  • pour des agents automatisés qui consomment le HTML

À condition, bien sûr, que ces systèmes aient accès au contenu.

Site public​

Un site de documentation contribue à la notoriété globale de l'entreprise.
Il devient une source de données parmi d'autres, consultée par :

  • les moteurs de recherche
  • les moteurs génératifs
  • les assistants IA
  • les outils d'analyse

Les données structurées renforcent :

  • la cohérence de marque
  • l'E‑E‑A‑T (Experience, Expertise, Authoritativeness, and Trustworthiness)
  • la compréhension machine
  • la visibilité globale

Bonus : quelques bonnes pratiques​

Voici quelques bonnes pratiques, et quelques erreurs fréquentes à éviter :

Do ✅Don't ❌
Déclarer WebSite + Organization.Ajouter trop de propriétés inutiles.
Ajouter Person si marque personnelle.Oublier les @id ou les URLs canoniques.
Rédiger des descriptions riches et cohérentes.Décrire différemment la même entité selon les pages.
Injecter JSON‑LD page par page.Mélanger les formats (JSON‑LD + microdata).
Tester avec Rich Results + schema.org.Oublier de tester régulièrement.
Vérifier la cohérence entre :
- contenu
- OpenGraph
- JSON‑LD
- titres et paragraphes.		Copier/coller des schémas sans les adapter.

Conclusion​

Les données structurées ne sont plus un simple bonus SEO. Elles sont devenues un pilier de la compréhension machine, un levier de visibilité pour les moteurs génératifs, et un outil stratégique pour maîtriser son identité numérique.

Pour une petite entreprise, c'est une opportunité : avec un travail propre, cohérent et bien pensé, on peut rivaliser avec des acteurs beaucoup plus grands.