Glossaire francophone AEO / SEO / GEO

Glossaire francophone documenté des termes AEO, SEO et GEO — définitions structurées (assertion, preuve, garantie, limites) à 3 niveaux de profondeur, avec transparence sur le statut terminologique de chaque terme (neuf statuts possibles, de la norme formelle au positionnement marketing).

AEO (Answer Engine Optimization)

AEO Convention émergente

Débutant

Assertion: L'AEO consiste à optimiser un contenu pour qu'il soit repris directement comme réponse par un moteur de réponse (Google SGE, Alexa), avant même l'essor des IA génératives grand public.
Exemple: Une page qui répond en une phrase claire à « Quelle est la capitale du Portugal ? » et se retrouve affichée dans l'encart de réponse Google est un exemple d'optimisation AEO.

Intermédiaire

Assertion: L'AEO est le précurseur historique du GEO, centré sur les featured snippets et les assistants vocaux/réponse directe, avant la généralisation des LLMs conversationnels.
Données: Les techniques AEO (réponse en tête de page, structure Question/Réponse, formulation concise et autoporteuse) peuvent faciliter le GEO, qui étend cette logique à des moteurs génératifs plus complexes.
Garantie: Un moteur de réponse (SGE, Alexa) et un moteur génératif (ChatGPT) partagent le même besoin : extraire une réponse courte et non ambiguë — d'où la continuité méthodologique entre AEO et GEO.

Expert

Assertion: L'AEO est la discipline d'optimisation de contenu pour les systèmes de réponse directe (featured snippets, assistants vocaux, SGE), fondée sur l'extraction d'un passage court et autoporteur plutôt que sur le classement d'une page entière.
Données: Les moteurs de réponse historiques utilisent des heuristiques d'extraction de passage (proches du QA extractif) plutôt qu'une génération libre — la performance dépend de la correspondance directe entre la question et la réponse fournie sur la page.
Garantie: Une réponse explicite placée près de la question peut faciliter son repérage et son interprétation, mais aucune longueur universelle de 40 à 60 mots ne garantit ni ne maximise son extraction. Google crée ses snippets automatiquement selon la requête et le contenu ; la formulation doit donc être testée plutôt que traitée comme une recette causale.
Fondement: Cette pratique découle des retours d'expérience SEO sur les featured snippets Google (2015-2023), documentés par l'industrie sans qu'un organisme normatif ne l'ait formalisée.
Portée: L'AEO reste pertinent pour les systèmes d'extraction de passage classiques ; il est un sous-ensemble insuffisant face aux moteurs génératifs qui reformulent et synthétisent plusieurs sources plutôt que d'extraire un passage unique.
Réfutation: S'appuyer uniquement sur les techniques AEO (réponse courte, structure Q/R) ne garantit pas la citation par un moteur génératif — mais pas pour la raison qu'on pourrait croire : Google précise explicitement qu'aucun balisage spécial ni fichier dédié à l'IA n'est requis pour apparaître dans ses fonctionnalités de recherche IA. La vraie limite de l'AEO est ailleurs : il cible l'extraction d'un passage unique, là où un moteur génératif peut synthétiser et citer plusieurs sources simultanément.

Source faisant autorité : https://www.searchenginejournal.com/google-answers-what-to-do-for-aeo-geo/558322/

Voir aussi : GEO (Generative Engine Optimization) · RAG (Retrieval-Augmented Generation)

Pratique émergente visant à structurer des contenus pour qu'un moteur de réponse puisse en extraire une réponse directe et vérifiable. Son périmètre recouvre partiellement le SEO et le GEO et varie encore selon les auteurs.

aeo

AI-READY / AI-First

Transversal Positionnement marketing

Débutant

Assertion: « AI-READY » et « AI-FIRST » sont des expressions qui veulent dire « prêt pour l'IA » — utiles pour expliquer une vision à une direction, mais ce ne sont pas des termes techniques officiels.
Exemple: Dire à un client « votre site doit être AI-READY » est clair et vendeur, mais un développeur préférera qu'on lui dise concrètement « il faut du JSON-LD et un rendu SSR ».

Intermédiaire

Assertion: AI-READY et AI-FIRST sont des termes de positionnement stratégique et marketing, utiles pour communiquer une vision à une direction non technique, mais ne correspondent à aucun standard reconnu par le W3C, l'IETF ou l'écosystème IA.
Données: Le vocabulaire technique équivalent existe déjà et est documenté : GEO/Machine-First Design pour « AI-READY », Agentic SEO/WebMCP-UCP pour « AI-FIRST ».
Garantie: Employer le terme adapté à l'interlocuteur (marketing avec un décideur, technique avec un développeur) évite la confusion et crédibilise le discours.

Expert

Assertion: « AI-READY » et « AI-FIRST » sont des labels de positionnement stratégique (assumés ici, notamment par Jean-Jacques Valognes), désignant respectivement l'objectif de visibilité par les moteurs génératifs (recouvrant GEO/Machine-First Design) et l'architecture priorisant l'interaction agentique (recouvrant Agentic SEO/WebMCP/UCP), sans être eux-mêmes normalisés.
Données: Aucun organisme (W3C, IETF, ni consortium propre à l'IA) ne définit ni ne certifie « AI-READY » ou « AI-FIRST » — contrairement à JSON-LD (recommandation W3C) ou même llms.txt (convention documentée par un auteur identifiable).
Garantie: La valeur de ces termes est communicationnelle (vendre une vision), pas technique (spécifier une implémentation) — les deux usages sont légitimes tant qu'ils ne sont pas confondus.
Fondement: Ce constat rejoint le travail de clarification terminologique mené sur ce projet (tableau de correspondance marketing/technique, Vocabulaire.txt) : nommer explicitement la nature marketing du terme distingue ce glossaire d'un usage non critique du vocabulaire IA.
Portée: AI-READY est un positionnement propriétaire dont la portée dépend des critères publiés et de la version de la méthode Jean-Jacques Valognes. Sans protocole commun d'évaluation, il ne constitue ni une certification interopérable ni une mesure comparable entre prestataires, et ne garantit aucun résultat d'un système IA.
Réfutation: La faiblesse structurelle du terme n'est pas seulement son absence de reconnaissance par un organisme normatif, mais l'absence de critères mesurables, auditables et interopérables qui lui soient attachés : contrairement à JSON-LD (validable syntaxiquement) ou llms.txt (présence vérifiable), rien ne permet de vérifier objectivement si un site est « AI-READY » — ce qui rend le terme structurellement impropre à toute forme de certification, même informelle.

Voir aussi : Machine-First Design · GEO (Generative Engine Optimization)

Positionnement stratégique propriétaire de Jean-Jacques Valognes pour qualifier la préparation d'un contenu, d'un site ou d'une organisation aux usages de l'IA. AI-READY et AI-First ne sont ni des normes W3C/IETF ni des certifications ; leurs critères doivent être explicités dans la méthode Jean-Jacques Valognes.

ai-ready

Discovery Layer

Transversal Taxonomie éditoriale (Jean-Jacques Valognes)

Débutant

Assertion: La Discovery Layer, c'est tout ce qui permet à un agent IA de trouver et comprendre rapidement de quoi parle un site, sans devoir tout lire.
Exemple: Le fichier llms.txt à la racine d'un site, qui résume en quelques lignes ce que fait le site, fait partie de la Discovery Layer.

Intermédiaire

Assertion: La Discovery Layer regroupe des fichiers et balises aux rôles distincts — llms.txt, robots.txt, sitemap.xml, JSON-LD — que ce glossaire rapproche pour aider un agent à situer et interpréter un site, sans qu'aucun d'eux ne couvre à lui seul l'ensemble du contexte.
Données: Ces éléments jouent des rôles distincts et hétérogènes (résumé éditorial pour llms.txt, règles d'exploration proposées aux robots pour robots.txt, inventaire d'URLs pour sitemap.xml, sémantique structurée pour JSON-LD) ; les regrouper en une couche de découverte est une lecture éditoriale de ce glossaire, pas une architecture technique unifiée reconnue comme telle.
Garantie: Lorsqu'un système les prend en charge, ces ressources offrent à un agent des points d'entrée explicites et peu coûteux à analyser, comparés à un parsing complet du site. L'ordre réel dans lequel un agent les consulte, et l'effet exact d'un temps de découverte plus long sur sa décision de poursuivre, dépendent toutefois de chaque système et ne sont généralement pas documentés publiquement.

Expert

Assertion: La Discovery Layer est la première des trois couches d'une taxonomie agentique éditoriale (Discovery / Action / Trust) : l'ensemble des points d'entrée, de statuts hétérogènes, que ce glossaire regroupe parce qu'ils contribuent chacun, selon son rôle propre, à l'exploration, l'orientation, l'interprétation ou aux règles de crawl d'un site par un agent.
Données: Concrètement : llms.txt (résumé éditorial), robots.txt (directives allow/disallow par user-agent, RFC 9309), sitemap.xml (inventaire des URLs), JSON-LD (sémantique par page).
Garantie: En l'absence de points d'entrée structurés publiés par le site, un agent peut devoir s'appuyer sur d'autres voies de traitement ou de récupération — notamment le parsing du HTML brut, le DOM rendu, le texte extrait ou un index de recherche —, dont certaines mobilisent des heuristiques, sans qu'un chiffrage universel de l'écart de coût ou de fiabilité entre ces approches soit documenté publiquement.
Fondement: Cette taxonomie en trois couches est une classification éditoriale proposée par ce glossaire en 2026, sans normalisation formelle — elle rapproche des mécanismes de statuts distincts : llms.txt est une proposition publiée par Jeremy Howard en 2024, JSON-LD 1.1 une recommandation W3C et Sitemaps un protocole documenté.
Portée: La composition exacte de la Discovery Layer évolue vite (nouveaux fichiers proposés régulièrement, ex : agents.md, ai-plugin.json) — la liste de 2026 n'est pas figée.
Réfutation: La taxonomie en trois couches (Discovery/Action/Trust) elle-même est contestable : ce n'est pas une nomenclature validée par un organisme de normalisation, sa frontière avec l'Action Layer est poreuse (certains fichiers de découverte évoluent vers des capacités actionnables), et sa composition évolue trop vite (agents.md, ai-plugin.json...) pour prétendre à l'exhaustivité — c'est un outil pédagogique de ce glossaire, pas une classification stabilisée.

Voir aussi : llms.txt · JSON-LD

Taxonomie éditoriale proposée par Jean-Jacques Valognes pour regrouper les mécanismes qui aident les logiciels et les assistants et agents IA à découvrir les ressources, les infos du site : liens, llms-sitemap, sitemap, robots.txt, métadonnées structurées et conventions émergentes comme llms.txt. Ces mécanismes n'ont ni le même statut ni les mêmes garanties.

discovery-layer

E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness)

SEO Terme établi

Débutant

Assertion: L'E-E-A-T décrit quatre qualités que Google cherche dans un contenu : l'expertise de l'auteur, son expérience vécue, sa reconnaissance, et la fiabilité. Ce n'est pas une note affichable, ni un bouton de classement.
Exemple: Un avis sur un aspirateur écrit par quelqu'un qui l'a vraiment utilisé pendant des semaines montre de l'Experience. Le même texte recopié par un site anonyme n'en montre pas, même s'il est bien rédigé.

Source faisant autorité : https://developers.google.com/search/docs/fundamentals/creating-helpful-content

Voir aussi : Trust Layer

Concept documenté par Google dans les Search Quality Rater Guidelines (E-A-T, puis E-E-A-T en décembre 2022 avec l'ajout d'Experience). Google indique que l'E-E-A-T n'est pas un facteur de classement unique : les systèmes combinent plusieurs signaux pour reconnaître ces qualités. À distinguer de la Trust Layer, taxonomie éditoriale qui s'en inspire dans un contexte agentique.

eeat

GEO (Generative Engine Optimization)

GEO Convention émergente

Débutant

Assertion: Le GEO, c'est l'art de rendre un site assez clair et bien structuré pour qu'une IA comme ChatGPT ou Perplexity le comprenne et le cite dans ses réponses.
Exemple: Si vous cherchez « meilleur atelier vélo Paris » sur Perplexity et que la réponse cite un site précis avec son nom et son adresse, ce site a fait du GEO — pas juste du SEO classique.

Intermédiaire

Assertion: Le GEO est la discipline qui optimise un site pour qu'il soit cité et recommandé par les moteurs génératifs (ChatGPT, Perplexity, Gemini, Claude), en complément du SEO classique orienté classement dans une liste de liens.
Données: Contrairement au SEO où l'utilisateur clique sur un lien parmi dix, en GEO l'IA synthétise une réponse unique et ne cite parfois qu'une poignée de sources — la visibilité se joue sur la citabilité du contenu, pas seulement son classement.
Garantie: Un contenu structuré (JSON-LD, HTML sémantique, réponses directes en tête de page) est mécaniquement plus facile à extraire pour un système de génération augmentée par récupération (RAG), donc plus susceptible d'être cité.

Expert

Assertion: Le GEO est l'ensemble des pratiques techniques et éditoriales visant à accroître la probabilité qu'un contenu soit sélectionné et cité par un moteur génératif répondant à une requête utilisateur — un gain de visibilité mesuré empiriquement sur certains systèmes, pas une chaîne causale « récupération → citation » démontrée universellement pour tous les moteurs.
Données: Dans Google Search, les fonctionnalités génératives peuvent lancer plusieurs recherches connexes et afficher des liens vers différentes pages d'appui. Le nombre et la sélection de ces liens varient selon la requête, le modèle et la fonctionnalité ; aucune fenêtre universelle de « 3 à 8 sources » n'est documentée par Google.
Garantie: Des données structurées conformes, un HTML accessible et un contenu explicite peuvent améliorer la lisibilité technique générale, mais aucune source publique n'établit qu'ils causent à eux seuls une citation. Google précise qu'aucun balisage Schema.org spécial n'est requis pour ses fonctions IA : leur effet sur la citation doit rester une hypothèse testée par moteur et par corpus.
Fondement: Ce lien contenu-structuré → citation accrue est cohérent avec la littérature sur le RAG (Lewis et al., 2020) : un système de récupération performe mieux sur des passages autoportants, non ambigus, correctement segmentés — l'étude ne démontre toutefois qu'un gain de visibilité mesuré, pas une garantie mécanique de citation.
Portée: Le GEO n'est pas un standard technique déposé (aucun organisme W3C/IETF ne le définit) — c'est un terme consensuel d'industrie en 2026, susceptible d'évoluer avec les mécanismes de récupération/citation des moteurs.
Réfutation: Un contenu parfaitement structuré peut malgré tout ne jamais être cité si le moteur privilégie d'autres sources selon des critères propres à chaque moteur, non publiés et donc invérifiables de l'extérieur — le GEO améliore une probabilité, il ne garantit aucune citation, et l'ampleur réelle de cet effet reste peu documentée publiquement.

Source faisant autorité : https://arxiv.org/abs/2311.09735

Voir aussi : AEO (Answer Engine Optimization) · LLMO (Large Language Model Optimization) · Machine-First Design

Discipline émergente visant à améliorer la visibilité et la représentation des contenus dans les réponses de moteurs génératifs. Le terme GEO a été introduit par Aggarwal et al. en 2023 dans un cadre expérimental ; il ne désigne ni une norme ni une garantie de citation.

geo

JSON-LD

Transversal Standard normatif

Débutant

Assertion: JSON-LD, c'est un bout de code invisible qu'on ajoute à une page pour dire clairement à une machine « ceci est une recette », « ceci est un événement », etc. — sans changer ce que voit un visiteur humain.
Exemple: Sur une page d'événement, le JSON-LD peut préciser la date, le lieu et le prix dans un format que Google ou une IA comprend instantanément, même si ces infos sont aussi écrites en texte normal sur la page.

Intermédiaire

Assertion: JSON-LD est le format sérialisé recommandé pour intégrer des données structurées Schema.org dans une page web, permettant à une machine d'identifier sans ambiguïté le type d'entité décrite (produit, article, personne, organisation...).
Données: JSON-LD est une recommandation formelle du W3C ; Schema.org, le vocabulaire le plus couramment utilisé avec JSON-LD, est un projet communautaire porté par Google, Microsoft, Yahoo et Yandex — pas un standard W3C au sens strict.
Garantie: Séparer la donnée structurée (dans le head ou en fin de page) du contenu visible permet de baliser sans risque de casser la mise en page, et sans dépendre de l'interprétation visuelle par la machine.

Expert

Assertion: JSON-LD est un format de sérialisation du Linked Data, recommandation W3C, utilisé pour embarquer un graphe de données structurées (le plus souvent en vocabulaire Schema.org) dans une page HTML via une balise <script type="application/ld+json">, indépendamment du rendu visuel.
Données: Un document JSON-LD peut décrire une seule entité ou un @graph de plusieurs entités reliées par des @id (ex : une page liée à son auteur, lui-même lié à son organisation) — pattern utilisé notamment sur alchimiste-ia-home.
Garantie: La normalisation W3C de JSON-LD garantit une syntaxe stable et un support pérenne côté outils ; le vocabulaire Schema.org, bien que non-W3C, bénéficie d'un support de facto par les principaux moteurs qui en définissent l'interprétation pratique.
Fondement: JSON-LD 1.1 est une recommandation W3C publiée en 2020 ; Schema.org est documenté et versionné publiquement par le W3C Community Group dédié, avec plusieurs milliers de types déjà spécifiés.
Portée: La présence de JSON-LD syntaxiquement valide ne garantit ni son exploitation par un moteur donné, ni l'obtention d'un rich result — chaque plateforme choisit quels types/champs elle exploite et comment.
Réfutation: Un JSON-LD incohérent avec le contenu visible de la page (sur-balisage, données inventées) constitue une pratique trompeuse sanctionnable par les moteurs de recherche — la donnée structurée doit rester fidèle au contenu réel.

E3 Vérification empirique (Duval) — niveau E3 : la phrase publiée « Fondateur d'Alchimiste IA » et le balisage JSON-LD de ce site désignent la même personne, vérifié à la fois automatiquement et manuellement sur les fichiers réellement déployés.

Ce contrôle porte uniquement sur la relation « fondateur » (Organization → founder → Person) entre l'organisation Alchimiste IA et Jean-Jacques Valognes. Il ne prouve pas qu'un moteur de recherche affiche un résultat enrichi à partir de ce balisage, ni que deux documents JSON-LD séparés soient nécessairement fusionnés par un consommateur donné, ni la vérité biographique de l'assertion (une égalité d'identifiant peut être valide sans être vraie). Texte validé par JJV le 2026-08-04.

Source faisant autorité : https://www.w3.org/TR/json-ld11/

Voir aussi : Schema.org · Discovery Layer · Trust Layer

Format fondé sur JSON pour sérialiser des données liées. JSON-LD 1.0 est devenu une recommandation W3C en 2014 et JSON-LD 1.1 en 2020. Il peut intégrer des vocabulaires comme Schema.org ou Dublin Core dans des documents web et des services.

json-ld

llms.txt

GEO Convention émergente

Débutant

Assertion: llms.txt est un petit fichier texte à la racine d'un site qui résume, pour une IA, ce qu'il faut savoir sur ce site — un peu comme un robots.txt mais pour donner du contexte plutôt que des interdictions.
Exemple: Un site qui a un fichier /llms.txt listant ses pages principales et son domaine d'expertise en 20 lignes facilite grandement le travail d'un agent qui doit comprendre le site rapidement.

Intermédiaire

Assertion: llms.txt est une convention de fichier markdown à la racine du domaine, fournissant un sommaire et un contexte éditorial directement lisible par un LLM, sans avoir à crawler tout le site.
Données: Initié par Jeremy Howard (Answer.AI), le format n'est adopté par aucun organisme de normalisation, mais des éditeurs techniques significatifs (Vercel, Stripe, Anthropic) l'ont déjà implémenté en 2025-2026.
Garantie: Un format markdown simple, sans dépendance de rendu, est directement consommable par un LLM sans étape de parsing HTML — d'où son adoption rapide malgré l'absence de standard formel.

Expert

Assertion: llms.txt est une convention communautaire (non-W3C, non-IETF) de fichier /llms.txt à la racine d'un domaine, structurant en Markdown un résumé éditorial et une liste de ressources prioritaires à l'intention des LLMs, en complément de robots.txt et sitemap.xml.
Données: Le format type inclut : titre/résumé du site, liste de liens vers les ressources principales, domaines d'expertise, entité responsable, politique de contenu, date de dernière mise à jour.
Garantie: L'absence de balisage HTML/CSS dans llms.txt élimine tout bruit de mise en page — un LLM peut l'ingérer directement comme contexte système, à un coût de traitement minimal.
Fondement: Documenté par sa proposition initiale (Howard, 2024) et son adoption croissante observée chez des éditeurs techniques de référence, sans qu'aucune spécification formelle contraignante n'existe à ce jour.
Portée: llms.txt n'a aucune valeur contraignante : rien n'oblige un LLM/crawler à le lire, ni à en respecter le contenu — c'est une convention de bonne volonté, pas un mécanisme d'application technique.
Réfutation: Un llms.txt mal maintenu (obsolète, incohérent avec le contenu réel du site) peut induire un agent en erreur plutôt que l'aider, et rien dans le format ne permet à un agent de détecter automatiquement cette dérive. Nuance importante : la validité syntaxique du JSON-LD ne garantit pas non plus la véracité des données qu'il contient — les deux formats partagent cette même limite, une structure valide ne certifie jamais un contenu exact.

Source faisant autorité : https://llmstxt.org/

Voir aussi : Discovery Layer

Proposition communautaire publiée par Jeremy Howard en 2024, sans statut W3C ou IETF. Un fichier Markdown situé à /llms.txt fournit une présentation concise du site et des liens utiles aux usages d'inférence ; la proposition n'impose aucun traitement particulier aux modèles ou aux agents.

llms-txt

Schema.org

Transversal Vocabulaire communautaire

Débutant

Assertion: Schema.org est un vocabulaire partagé : il fournit des noms communs pour décrire ce qu'est une information — une personne, un produit, un événement — et les propriétés qui la caractérisent.
Exemple: Pour un produit, Schema.org permet de nommer de façon explicite son nom, son prix, sa devise et sa disponibilité ; ces termes peuvent ensuite être écrits dans la page au format JSON-LD.

Intermédiaire

Assertion: Schema.org est un vocabulaire communautaire de types et de propriétés pour les données structurées du Web. Il définit le sens de termes comme Product, Person ou Organization, tandis que JSON-LD, Microdata et RDFa sont des syntaxes possibles pour les encoder.
Données: Fondé par Google, Microsoft, Yahoo et Yandex, Schema.org est aujourd'hui utilisé par des millions de domaines à travers le monde, une adoption qui continue de croître.
Garantie: Lorsque producteurs et consommateurs emploient les mêmes types et propriétés, ils réduisent l'ambiguïté lexicale et peuvent échanger une description sémantique sans imposer un format de sérialisation unique.

Expert

Assertion: Schema.org est un ensemble ouvert, collaboratif, versionné et extensible de vocabulaires identifiés par des IRI pour décrire des entités, leurs propriétés et leurs relations. Il est indépendant de JSON-LD, Microdata et RDFa, qui ne sont que des syntaxes d'encodage, et il n'est pas une recommandation W3C.
Données: Le site officiel attribue la fondation du projet à Google, Microsoft, Yahoo et Yandex et documente publiquement ses versions ; l'adoption se compte en millions de domaines à l'échelle mondiale, mais ce volume évolue en continu et n'est pas cité ici avec un chiffre daté qui deviendrait rapidement obsolète.
Garantie: Des identifiants et définitions partagés permettent à des producteurs et à des consommateurs indépendants d'aligner le sens d'une donnée malgré des syntaxes différentes ; cette interopérabilité sémantique ne garantit toutefois ni la vérité de la donnée ni son utilisation par un moteur.
Fondement: Schema.org publie sa documentation, son historique de versions et ses travaux sur GitHub dans le cadre d'un processus communautaire ouvert utilisant notamment une liste de diffusion hébergée par le W3C. Cet hébergement ne lui confère pas le statut de recommandation W3C.
Portée: Schema.org définit un vocabulaire, pas une syntaxe, un protocole d'exploration, un algorithme de classement ni une preuve d'autorité. Chaque consommateur choisit les types et propriétés qu'il prend en charge, et les versions du vocabulaire continuent d'évoluer.
Réfutation: Un balisage Schema.org valide peut être ignoré s'il emploie un type non pris en charge, reste incomplet ou contredit le contenu visible. Il ne garantit donc ni un résultat enrichi, ni un meilleur classement, ni une citation par une IA ; l'effet dépend du consommateur et de la qualité réelle des données.

Source faisant autorité : https://schema.org/

Voir aussi : JSON-LD · Discovery Layer · Trust Layer

Vocabulaire collaboratif fondé par Google, Microsoft, Yahoo et Yandex pour les données structurées sur le Web. Ce n'est pas une recommandation W3C. Il peut être encodé en JSON-LD, Microdata ou RDFa ; son adoption se compte en millions de domaines à l'échelle mondiale, un volume qui évolue en continu et n'est donc pas cité ici avec un chiffre daté.

schema-org

SERP (Search Engine Results Page)

SEO Terme établi

Débutant

Assertion: Une SERP est la page de résultats affichée par un moteur après une requête. Elle peut réunir des liens classés, des extraits, des images, des cartes ou une synthèse générée accompagnée de plusieurs liens vers des sources.
Exemple: Après la requête « meilleur restaurant italien Paris », Google peut afficher des sites, une carte, des avis et parfois une synthèse générée renvoyant vers plusieurs sources : l'ensemble de cette page constitue la SERP.

Intermédiaire

Assertion: La SERP est une interface composite dans laquelle un moteur organise plusieurs types de résultats selon la requête : résultats textuels, médias, fonctionnalités enrichies, modules d'exploration et, selon les cas, réponse générative.
Données: La galerie officielle de Google Search Central distingue notamment les résultats textuels, les rich results, les résultats image et vidéo ainsi que les fonctionnalités d'exploration. Une SERP réelle ne se réduit donc pas à une liste fixe de liens bleus.
Garantie: Puisque plusieurs modules peuvent répondre à une même intention, l'analyse SEO doit observer la visibilité dans l'ensemble de la page, et pas seulement la position d'un lien classique. Cette lecture décrit l'interface ; elle ne garantit l'apparition dans aucun module.

Expert

Assertion: La SERP est la couche de présentation d'un système de recherche : elle assemble des résultats classés et des fonctionnalités déclenchées selon la requête. Une synthèse générative peut faire partie de cette page et citer plusieurs documents ; elle ne constitue donc pas l'opposé conceptuel de la SERP.
Données: Google indique que ses AI Overviews et son AI Mode peuvent lancer plusieurs recherches connexes, puis afficher des liens vers différentes pages d'appui. La composition et les liens varient selon les modèles, les techniques employées et la requête ; aucune liste universelle de modules n'est garantie.
Garantie: Distinguer le classement de documents de la synthèse générée évite une fausse opposition entre SEO et GEO : une même page peut être classée comme résultat, servir de source à une synthèse, remplir les deux rôles ou n'en remplir aucun.
Fondement: Cette définition s'appuie sur la galerie des éléments visuels de Google Search Central et sur sa documentation « AI features and your website », mise à jour le 10 décembre 2025, qui décrit des réponses générées accompagnées de liens d'appui multiples.
Portée: Le terme SERP décrit ce qui est présenté à l'utilisateur, pas à lui seul les algorithmes de récupération, de classement ou de génération. Sa composition varie selon le moteur, la langue, le pays, l'appareil, la requête et la date d'observation.
Réfutation: Prendre la SERP comme unité unique d'analyse devient insuffisant lorsque la réponse est fournie dans un assistant, une API ou une autre interface sans page de résultats classique. L'étude des SERP ne couvre donc pas, à elle seule, tous les contextes du GEO.

Source faisant autorité : https://developers.google.com/search/docs/appearance/visual-elements-gallery

Voir aussi : AEO (Answer Engine Optimization) · GEO (Generative Engine Optimization)

Terme établi du SEO désignant une page de résultats produite par un moteur de recherche. Une SERP peut combiner liens, extraits, médias, fonctionnalités enrichies et réponses génératives ; elle ne se réduit donc pas à une liste de liens et ne s'oppose pas mécaniquement au GEO.

serp

Action Layer

Transversal Taxonomie éditoriale (Jean-Jacques Valognes)

Débutant

Assertion: L'Action Layer, ce sont les portes qu'un site ouvre pour qu'un agent IA puisse agir dessus — pas juste lire, mais réserver, acheter, remplir un formulaire.
Exemple: Un agent qui ajoute un article au panier et passe commande via une interface dédiée (pas en cliquant comme un humain) utilise l'Action Layer du site.

Intermédiaire

Assertion: L'Action Layer regroupe les interfaces programmatiques (API, endpoints) qui permettent à un agent d'interagir avec le site plutôt que de simplement le lire.
Données: Contrairement à la Discovery Layer (lecture), l'Action Layer engage une transaction ou une modification d'état côté site (panier, réservation, contact).
Garantie: Une action fiable par un agent nécessite un contrat d'interface explicite (schéma d'entrée/sortie défini) — un agent ne peut pas deviner un formulaire web aussi fiablement qu'il ne peut appeler une fonction typée.

Expert

Assertion: L'Action Layer est la couche d'architecture agentique exposant des interfaces programmatiques structurées (API REST, tool/function calling, protocoles comme UCP/WebMCP) permettant à un agent d'exécuter une action transactionnelle sur le site.
Données: Les protocoles 2026 structurants sont UCP (Universal Commerce Protocol, e-commerce) et WebMCP (brouillon W3C porté par Google/Microsoft, connexion générique agent/outils/données), tous deux construits sur le tool/function calling.
Garantie: Une interface structurée réduit le taux d'erreur d'un agent lors d'une action par rapport à une automatisation qui doit interpréter un DOM HTML pensé pour un humain.
Fondement: Le tool calling est documenté depuis les premières architectures d'agents LLM (function calling OpenAI, 2023) — WebMCP et UCP en sont des extensions web-natives et sectorielles.
Portée: Le support d'une Action Layer varie selon les secteurs, les plateformes et les agents. Une interface actionnable exige aussi des mécanismes de confiance, d'authentification, d'autorisation et de confirmation : sa présence ne signifie pas qu'un agent pourra ou devra l'utiliser.
Réfutation: L'idée qu'une couche dédiée soit toujours nécessaire est contestée par les agents capables d'utiliser une API existante ou une interface web accessible sans protocole agentique spécifique. Inversement, une Action Layer n'apporte aucun bénéfice à un agent incompatible, non autorisé ou dont la tâche n'exige aucune action.

Voir aussi : WebMCP · UCP (Universal Commerce Protocol)

Taxonomie éditoriale proposée par Jean-Jacques Valognes pour regrouper les interfaces qui permettent à un agent d'exécuter des actions sur un service web, par exemple rechercher, réserver, acheter ou soumettre un formulaire. Elle peut inclure des API classiques et des spécifications émergentes comme WebMCP ou UCP.

action-layer

Agentic SEO

GEO Convention émergente

Débutant

Assertion: L'Agentic SEO désigne d'abord l'utilisation d'agents IA pour automatiser ou assister des tâches SEO, comme le crawl, l'audit ou la préparation de recommandations. Certains auteurs emploient aussi ce terme pour l'adaptation d'un site aux agents capables d'y agir ; ce second sens recoupe l'Action Layer.
Exemple: Un agent IA à qui on demande « réserve-moi une table pour 2 ce soir » et qui remplit directement le formulaire de réservation d'un restaurant fait de l'Agentic SEO côté site visité.

Intermédiaire

Assertion: L'Agentic SEO est un terme d'usage encore instable : selon les auteurs, il désigne soit l'automatisation adaptative des workflows SEO eux-mêmes par des agents IA (sens le plus répandu en usage sectoriel), soit — par extension — la capacité d'un site à être actionné par un agent IA externe (recherche, réservation, achat), auquel cas il recoupe largement l'Action Layer.
Données: Contrairement au GEO qui vise la citation dans une réponse, le second sens vise l'action effective de l'agent sur le site (remplir un panier, initier un paiement) ; le premier sens vise l'optimisation en boucle du travail SEO lui-même (audits, ajustements de contenu automatisés).
Garantie: Aucun consensus terminologique n'est encore établi en 2026 — les deux usages coexistent dans la littérature sectorielle sans qu'un organisme ou une convention dominante ne tranche.

Expert

Assertion: Agentic SEO est un terme d'usage encore instable, employé selon deux acceptions distinctes : (1) l'automatisation adaptative des workflows SEO eux-mêmes par des agents IA (audits, optimisation de contenu en boucle) — le sens dominant en usage sectoriel actuel ; (2) par extension chez certains auteurs, la capacité d'un site à être actionné par un agent IA externe — usage qui recoupe alors largement l'Action Layer. Ce glossaire ne tranche pas entre les deux, faute de consensus établi.
Données: Les protocoles émergents 2026 (UCP pour l'e-commerce, WebMCP pour la connexion outils/données) définissent des contrats d'interaction structurés entre agent et site — pertinents pour le sens (2), sans rapport direct avec le sens (1).
Garantie: Un site exposant ces interfaces (sens 2) réduit drastiquement le taux d'échec/hallucination de l'agent lors d'une tâche transactionnelle, comparé à un agent devant deviner l'action via le DOM.
Fondement: Le sens (2) prolonge le tool/function calling (capacité d'un LLM à appeler une fonction externe selon un schéma défini), brique technique de base sous WebMCP/UCP ; le sens (1) relève plutôt de la littérature sectorielle SEO sur l'automatisation par agents (ex. Ahrefs, 2026).
Portée: Discipline naissante en 2026, aux deux sens : peu de sites implémentent des interfaces actionnables (sens 2), et les workflows SEO agentiques (sens 1) restent majoritairement expérimentaux — à ne pas confondre avec l'Action Layer, qui est le nom de la couche technique, pas de la discipline.
Réfutation: Présenter l'Agentic SEO (sens 2) comme une discipline autonome distincte de l'Action Layer est contestable : sans Trust Layer solide, un agent peut refuser d'agir même si l'interface technique est présente, et la définition elle-même chevauche largement celle de l'Action Layer — la distinction reste éditoriale plus que technique.

Source faisant autorité : https://www.searchenginejournal.com/agentic-ai-in-seo-ai-agents-workflows-ideation/540206/

Voir aussi : Action Layer · UCP (Universal Commerce Protocol) · WebMCP

Terme employé principalement pour l'automatisation, autonome ou semi-autonome, de workflows SEO par des agents IA : idéation, crawl, audit, analyse et recommandations. Un second usage, distinct et moins stabilisé, désigne l'adaptation des sites aux agents capables d'agir ; ce second sens rejoint l'Action Layer.

agentic-seo

Machine-First Design

Transversal Taxonomie éditoriale (Jean-Jacques Valognes)

Débutant

Assertion: Le Machine-First Design, c'est construire un site en pensant d'abord à ce qu'une machine doit comprendre, pas seulement à ce qui est joli pour un humain.
Exemple: Ajouter du code invisible (JSON-LD) qui dit explicitement « ceci est une recette, avec ces ingrédients » en plus du texte visible, c'est du Machine-First Design.

Intermédiaire

Assertion: Le Machine-First Design est une approche d'architecture web où la lisibilité par une machine (JSON-LD, DOM sémantique) prime ou égalise la lisibilité humaine, en remplacement du positionnement marketing « AI-First ».
Données: Un site Machine-First expose systématiquement une couche sémantique explicite (Schema.org) en parallèle du rendu visuel, plutôt que de compter sur l'IA pour « deviner » le sens depuis le HTML/CSS visuel.
Garantie: Une machine ne perçoit ni la mise en page ni les intentions visuelles — seule une structure explicite (balisage, hiérarchie sémantique) élimine l'ambiguïté qu'une mise en page seule ne peut lever pour un parseur.

Expert

Assertion: Le Machine-First Design est un principe d'architecture logicielle selon lequel toute information significative d'une page doit être accessible et non ambiguë pour un parseur automatisé (crawler, agent, LLM) indépendamment de son rendu visuel.
Données: Ce principe se traduit par : SSR ou contenu statique (pas de dépendance JS pour le contenu principal), JSON-LD systématique, HTML sémantique, hiérarchie de titres cohérente.
Garantie: Un rendu uniquement client-side (JS) est invisible pour une part significative des crawlers IA qui n'exécutent pas JavaScript — le Machine-First Design élimine ce point de défaillance par construction.
Fondement: Constat empirique documenté dans ce projet même : un dashboard rendu uniquement en JS (avant refactor SSR) livre un DOM vide au premier chargement, invisible à tout crawler non-JS.
Portée: Le Machine-First Design ne s'oppose pas à une bonne expérience humaine — il ajoute une exigence supplémentaire, il ne la remplace pas.
Réfutation: Pousser le Machine-First Design à l'extrême (sur-balisage, JSON-LD dupliquant mal le contenu visible) peut créer des incohérences entre ce qu'une machine lit et ce qu'un humain voit — risque de pénalité pour contenu trompeur.

Voir aussi : JSON-LD

Taxonomie éditoriale proposée par Jean-Jacques Valognes pour une architecture informationnelle qui traite conjointement la compréhension humaine et la lisibilité machine : structure sémantique, métadonnées, formats explicites et interfaces documentées. Ce n'est ni une norme ni un terme stabilisé du secteur.

machine-first-design

RAG (Retrieval-Augmented Generation)

Transversal Technique établie

Débutant

Assertion: Le RAG, c'est quand une IA va chercher des informations fraîches sur internet ou dans une base de données avant de répondre, au lieu de se fier uniquement à ce qu'elle a appris pendant son entraînement.
Exemple: Quand ChatGPT recherche sur le web pour répondre à une question d'actualité récente et cite ses sources, il utilise du RAG.

Intermédiaire

Assertion: Le RAG (Retrieval-Augmented Generation) est une technique combinant un système de récupération d'information (retrieval) et un modèle génératif (LLM), permettant d'ancrer une réponse sur des sources externes plutôt que sur la seule mémoire paramétrique du modèle.
Données: Le RAG réduit le risque d'hallucination en donnant au LLM un contexte factuel récupéré au moment de la requête, que le modèle n'avait pas nécessairement mémorisé pendant son entraînement.
Garantie: Un contenu correctement structuré et indexable augmente la probabilité d'être sélectionné par l'étape de récupération, donc d'influencer la réponse générée — c'est le lien direct entre RAG et GEO.

Expert

Assertion: Le RAG est une architecture en deux étapes — récupération de passages pertinents depuis un corpus externe (souvent via recherche vectorielle/dense retrieval), puis génération d'une réponse par un LLM conditionné sur ces passages — formalisée notamment par Lewis et al. (2020).
Données: L'étape de récupération dépend de la qualité de l'indexation (embeddings, chunking) et de la disponibilité du contenu (crawlable, non bloqué, non uniquement JS) ; l'étape de génération dépend de la capacité du LLM à synthétiser fidèlement les passages fournis.
Garantie: Dans un système RAG contrôlé, la segmentation, les métadonnées et l'indexation peuvent influencer la récupération, mais leur effet dépend du corpus, du découpage, des représentations, de la requête et du classement. Il doit être vérifié par des mesures de retrieval ; le GEO public ne peut pas supposer qu'un moteur reprend le découpage choisi par l'éditeur.
Fondement: Référence académique fondatrice : Lewis, P. et al., « Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks », NeurIPS 2020 — la technique est depuis largement industrialisée.
Portée: Tous les moteurs génératifs n'utilisent pas du RAG classique (certains combinent recherche web temps réel, cache, et RAG interne) — le terme désigne une famille de techniques, pas une implémentation unique.
Réfutation: Le RAG réduit mais n'élimine pas les hallucinations : un LLM peut mal interpréter ou mal attribuer un passage correctement récupéré — la qualité de la récupération est nécessaire mais non suffisante pour une réponse fiable.

E2 Vérification empirique (Duval) — niveau E2 : l'étape de calcul de similarité (TF-IDF + cosinus, une fois les vecteurs construits) qui illustre cette page suit la formule mathématique standard et produit un résultat reproductible, vérifié deux fois de façon indépendante.

Ce contrôle porte sur cette seule étape de calcul, pas sur la construction des vecteurs en amont (tokenisation, pondération) ni sur la fiabilité en usage réel : en moyenne sur 8 requêtes testées, 56 % des passages attendus sont retrouvés dans les 3 premiers résultats (88 % dans les 5 premiers) — ce n'est PAS 56 % des requêtes qui obtiennent leurs 2 passages (seules 25 % y parviennent dans les 3 premiers résultats, 75 % dans les 5 premiers). L'effet de la segmentation, des métadonnées et de l'indexation sur la récupération — pourtant l'objet même de cette garantie — reste non testé indépendamment. Texte validé par JJV le 2026-08-04.

Source faisant autorité : https://arxiv.org/abs/2005.11401

Voir aussi : GEO (Generative Engine Optimization) · AEO (Answer Engine Optimization)

Technique d'IA établie à partir des travaux de Lewis et al. présentés à NeurIPS 2020. Elle combine une mémoire paramétrique avec une mémoire externe récupérée pour conditionner la génération. Son application au GEO/AEO est un usage ultérieur et ne transforme pas le RAG en norme.

rag

LLMO (Large Language Model Optimization)

GEO Convention émergente

Débutant

Assertion: Le LLMO désigne les techniques qui rendent un contenu plus facile à « avaler » et réutiliser pour un LLM — un terme plus technique, moins utilisé côté stratégie que GEO.
Exemple: Découper un article en paragraphes courts et autoporteurs plutôt qu'en un seul bloc de 2000 mots est une pratique LLMO.

Intermédiaire

Assertion: Le LLMO est le pendant technique/développeur du GEO : l'optimisation de l'ingestion d'un contenu par un LLM (segmentation, formatage, absence de bruit visuel), plutôt que la stratégie de visibilité globale.
Données: Les développeurs utilisent LLMO pour désigner des choix d'implémentation précis (taille de chunk, structure Markdown/HTML propre) quand GEO désigne plutôt l'objectif business (être cité).
Garantie: Un contenu mal segmenté ou surchargé de JS force le LLM (ou son pipeline RAG) à un traitement dégradé — le LLMO cible directement cette étape mécanique.

Expert

Assertion: Le LLMO regroupe les pratiques d'ingénierie de contenu optimisant le découpage, le nettoyage et le formatage d'une page pour les étapes de chunking/embedding d'un pipeline RAG.
Données: Un pipeline RAG segmente le texte en chunks (souvent 200-800 tokens) avant de les vectoriser ; un HTML bruyant (menus, pubs, JS non rendu) pollue ce découpage.
Garantie: Un rendu accessible, du texte disponible et une structure sémantique facilitent l'exploration et l'analyse du contenu. Leur effet sur le découpage en chunks et la récupération dépend toutefois du système cible, dont les méthodes sont souvent non publiées ; il doit être mesuré, pas présenté comme mécanique.
Fondement: Ceci découle des pratiques documentées de préparation de corpus pour la vectorisation en RAG, communes en ingénierie ML, sans être un standard formalisé sous ce nom.
Portée: LLMO est un terme d'usage, à la diffusion plus restreinte que GEO/AEO — son périmètre exact varie selon qui l'emploie (développeur vs marketeur).
Réfutation: Un contenu parfaitement « LLMO-friendly » techniquement peut rester non cité s'il manque d'autorité (Trust Layer) — le LLMO optimise l'ingestion, pas la confiance accordée à la source.

Voir aussi : GEO (Generative Engine Optimization) · RAG (Retrieval-Augmented Generation)

Terme émergent et non normalisé désignant, selon les auteurs, l'optimisation de contenus, de données ou de systèmes pour leur utilisation par des modèles de langage. Son périmètre chevauche le GEO, l'AEO et l'ingénierie RAG.

llmo

Trust Layer

Transversal Taxonomie éditoriale (Jean-Jacques Valognes)

Débutant

Assertion: La Trust Layer, ce sont les preuves qu'un site montre à une IA pour dire « tu peux me faire confiance » — qui je suis, qui l'a écrit, si l'info est vérifiable.
Exemple: Indiquer clairement l'auteur d'un article avec sa fiche d'expertise (au lieu d'un article anonyme) renforce la Trust Layer d'une page.

Intermédiaire

Assertion: La Trust Layer regroupe les éléments (Entity Schema, marquage d'auteur, sources primaires citées) permettant à un agent d'évaluer la vérifiabilité d'une information avant de la citer ou d'agir dessus.
Données: Un agent IA peut croiser plusieurs signaux (site + profils tiers + avis) plutôt que de faire confiance à une seule page isolée, mais ce comportement dépend du système et n'est pas documenté de façon universelle.
Garantie: Une attribution explicite (auteur, organisation) facilite la vérification de l'origine d'une information. Son influence réelle sur la sélection ou la citation par un système donné dépend toutefois de ce système et n'est démontrée par aucune documentation publique généralisable.

Expert

Assertion: La Trust Layer est la couche d'architecture agentique fournissant les signaux de vérifiabilité et d'autorité (Entity Schema, authorship, sources primaires, cohérence inter-plateformes) permettant à un agent d'évaluer la fiabilité éditoriale d'un contenu avant citation ou action — le DNSSEC en fait partie à un niveau différent : il authentifie l'origine et l'intégrité des données DNS, pas la fiabilité du contenu qui y est publié.
Données: Concrètement : balisage Person/Organization Schema.org, cohérence NAP (nom/adresse/téléphone) entre le site et les annuaires tiers, avis clients agrégés, ancienneté et fraîcheur du contenu, sécurité du transport (HTTPS) et de la résolution de domaine (DNSSEC, sans lien avec la fiabilité éditoriale).
Garantie: L'attribution, les sources primaires et la fraîcheur rendent une information plus facile à contrôler. En l'absence de documentation publique propre au système étudié, on ne peut toutefois pas affirmer que ces signaux réduisent mécaniquement ses hallucinations ou garantissent une citation ; ils constituent des indices d'auditabilité à tester.
Fondement: Ce principe prolonge les critères E-E-A-T (Expertise, Experience, Authoritativeness, Trustworthiness) déjà documentés en SEO classique par Google, étendus au contexte agentique.
Portée: La Trust Layer ne possède pas de mesure objective unique : son évaluation dépend du moteur ou de l'agent. Ses signaux ne peuvent en outre être examinés que si le contenu est accessible ; elle ne compense ni une ressource introuvable ni une information que le système ne peut pas interpréter.
Réfutation: Une identité clairement déclarée, des citations et un balisage techniquement correct peuvent accompagner un contenu faux, obsolète ou manipulé. L'accumulation de signaux de confiance ne prouve donc pas la vérité d'une affirmation et peut elle-même être mise en scène.

Voir aussi : JSON-LD

Taxonomie éditoriale proposée par Jean-Jacques Valognes pour regrouper les signaux de provenance, d'attribution, de citation, d'identité et de fraîcheur qu'un système peut examiner. Ces signaux facilitent la vérification mais ne prouvent pas, à eux seuls, la fiabilité d'une information.

trust-layer

UCP (Universal Commerce Protocol)

GEO Spécification ouverte

Débutant

Assertion: UCP est un langage commun qui permet à une IA d'acheter dans n'importe quelle boutique en ligne de la même façon, sans que le développeur du site ait à tout réinventer.
Exemple: Avec UCP, un agent IA pourrait chercher un produit, le mettre au panier et payer sur n'importe quelle boutique compatible, avec les mêmes étapes à chaque fois.

Intermédiaire

Assertion: UCP (Universal Commerce Protocol) est un standard ouvert co-développé par Shopify et Google (2026), permettant à des agents IA d'interagir avec n'importe quel magasin e-commerce (recherche catalogue, panier, checkout) de façon unifiée.
Données: Avant UCP, chaque site e-commerce exposait (ou pas) sa propre logique d'intégration agent — UCP vise à en faire un contrat unique, quel que soit le site.
Garantie: Une interface transactionnelle unifiée réduit le coût d'intégration pour les développeurs d'agents (un seul protocole à supporter) et augmente la couverture d'e-commerce réellement actionnable par un agent.

Expert

Assertion: UCP est un protocole ouvert et standardisé (co-développé Shopify/Google, 2026) définissant les opérations e-commerce actionnables par un agent IA — recherche de catalogue, gestion de panier, checkout — indépendamment de la plateforme e-commerce sous-jacente.
Données: UCP et ACP proposent des contrats distincts pour le commerce agentique. Leurs périmètres et intégrations évoluent encore ; les documents publics disponibles ne permettent pas d'établir qu'un protocole domine durablement l'autre dans l'ensemble du marché.
Garantie: La participation d'acteurs établis peut faciliter les intégrations initiales d'UCP, mais elle ne démontre ni un effet de réseau durable ni sa future position de standard de fait. Cette issue dépendra des implémentations interopérables, du soutien des plateformes et de l'usage réel face à des spécifications concurrentes comme ACP.
Fondement: UCP et l'ACP (Agentic Commerce Protocol) sont deux spécifications ouvertes distinctes et concurrentes du commerce agentique. L'ACP, co-développé par OpenAI et Stripe et publié en 2025, définit notamment une interface de checkout entre applications compatibles et marchands ; il n'englobe pas UCP. Leur adoption relative reste une question empirique non tranchée.
Portée: Standard sectoriel (e-commerce) et non généraliste : il ne couvre pas les cas d'usage hors transaction marchande (réservation de service, formulaire de contact).
Réfutation: L'adoption d'UCP dépend de son intégration effective par les plateformes e-commerce tierces (au-delà de Shopify) — un site sur une plateforme non compatible ne peut pas en bénéficier malgré le statut de standard ouvert.

Source faisant autorité : https://ucp.dev/

Voir aussi : WebMCP · Action Layer

Spécification ouverte de commerce agentique co-développée par un écosystème incluant notamment Google, Shopify et d'autres acteurs du commerce. UCP décrit des capacités allant de la découverte au panier, au checkout et au suivi de commande. Sa jeunesse impose de distinguer spécification publiée et adoption réelle.

ucp

WebMCP

GEO Proposition en incubation

Débutant

Assertion: WebMCP est un projet en discussion qui doit permettre à une IA de se connecter facilement aux outils et données d'un site, un peu comme une prise électrique universelle entre agents IA et sites web — ce n'est pas encore un standard officiel.
Exemple: Grâce à WebMCP, un agent IA pourrait interroger directement le stock d'une boutique en ligne sans avoir à deviner l'information en lisant la page produit.

Intermédiaire

Assertion: WebMCP est un brouillon (Community Group Draft, explicitement hors Standards Track) discuté dans un groupe communautaire W3C (avec la participation de Google et Microsoft, initié début 2026), visant à définir une API JavaScript standardisant la connexion entre LLMs/agents et outils/données externes — l'évolution web-native du protocole MCP d'Anthropic (fin 2024).
Données: MCP (Model Context Protocol) a d'abord été conçu pour connecter un LLM à des outils locaux/serveurs ; WebMCP en transpose le principe au contexte web (site à site, agent à site).
Garantie: Standardiser cette connexion évite à chaque site de définir son propre protocole ad hoc, et à chaque agent de développer une intégration spécifique par site.

Expert

Assertion: WebMCP est un Community Group Draft (explicitement hors Standards Track W3C, donc pas une proposition de standard au sens strict) discuté au sein d'un groupe communautaire W3C (avec la participation de Google et Microsoft, initié début 2026), définissant une API JavaScript — pas un protocole réseau générique — permettant à un agent/LLM de découvrir et invoquer des outils exposés par une page web, en filiation directe avec le Model Context Protocol d'Anthropic (2024).
Données: Le protocole vise à définir : la découverte des outils disponibles sur un site, leur schéma d'invocation (entrées/sorties typées), et le mécanisme d'appel — au même niveau d'abstraction que le tool/function calling, mais standardisé inter-sites.
Garantie: L'incubation de WebMCP dans un groupe communautaire de l'écosystème W3C peut favoriser une terminologie commune et l'interopérabilité, mais seulement si la proposition converge, reçoit des implémentations indépendantes et est adoptée. Son statut hors Standards Track au 3 août 2026 ne garantit ni pérennité ni effet de réseau.
Fondement: La filiation avec MCP (spécification publiée par Anthropic fin 2024, largement adoptée côté outils de développement IA) donne une base technique éprouvée à cette extension web.
Portée: Statut de brouillon (draft) au moment de la rédaction (2026) : la spécification n'est pas figée, l'implémentation réelle par les navigateurs/sites reste marginale — à traiter comme une direction, pas un standard opérationnel.
Réfutation: Un brouillon de standard peut être abandonné ou substantiellement modifié avant ratification — s'appuyer aujourd'hui sur WebMCP comme socle de production comporte un risque d'obsolescence rapide, contrairement à JSON-LD (recommandation W3C stable).

Source faisant autorité : https://webmachinelearning.github.io/webmcp/

Voir aussi : Action Layer · UCP (Universal Commerce Protocol)

Draft Community Group Report du W3C Web Machine Learning Community Group, hors Standards Track. Le rapport du 28 juillet 2026, édité par des contributeurs de Microsoft et Google, décrit une API JavaScript permettant aux applications web d'exposer des outils à des agents IA. L'incubation a commencé en 2025.

webmcp