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 40-60 mots) restent des prérequis techniques du GEO, qui les étend à 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
- Un contenu formaté en Question/Réponse avec une réponse de 40 à 60 mots immédiatement après le titre maximise la probabilité d'extraction correcte par ces systèmes.
- 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.
Voir aussi : GEO (Generative Engine Optimization) · RAG (Retrieval-Augmented Generation)
Précurseur du GEO, centré moteurs de réponse (Google SGE, Alexa).
aeo
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
- Le fait de ne pas être un standard ne rend pas le terme illégitime — un positionnement stratégique assumé et transparent est une pratique saine, tant qu'il n'est pas présenté à tort comme une certification ou un standard technique.
- 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 assumé (Jean-Jacques Valognes), pas un standard technique reconnu W3C/IETF. Cas d'école de transparence terminologique du glossaire — pas de source externe (terme propriétaire).
ai-ready
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 les fichiers et balises qui permettent à un agent de trouver et comprendre le contexte d'un site sans ambiguïté : llms.txt, robots.txt, sitemap.xml, JSON-LD.
- Données
- Ces éléments sont lus en premier par un agent avant toute décision plus coûteuse (crawl complet, appel d'action) — c'est la porte d'entrée de toute interaction agent/site.
- Garantie
- Un agent qui ne trouve pas rapidement cette couche de découverte a un coût de traitement plus élevé et risque d'abandonner le site au profit d'une source plus rapide à interpréter.
Expert
- Assertion
- La Discovery Layer est la première des trois couches d'architecture agentique (Discovery / Action / Trust) : l'ensemble des points d'entrée standardisés qui exposent à un agent le contexte, le périmètre et les règles d'usage d'un site.
- Données
- Concrètement : llms.txt (résumé éditorial), robots.txt (autorisations de crawl par user-agent), sitemap.xml (inventaire des URLs), JSON-LD (sémantique par page).
- Garantie
- Sans cette couche, un agent doit inférer le contexte par heuristique (parsing HTML brut) — plus lent, plus fragile, plus coûteux en tokens pour un LLM.
- Fondement
- Cette taxonomie en trois couches est une synthèse d'usage industrie 2026, sans normalisation formelle unique — elle structure néanmoins la façon dont les protocoles récents (llms.txt, WebMCP, UCP) se répartissent fonctionnellement.
- 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 & Schema.org
Fichiers/balises permettant à un agent de découvrir et comprendre un site sans ambiguïté (llms.txt, robots.txt, sitemap.xml). Taxonomie synthétisée, pas de source externe unique attendue.
discovery-layer
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
- Les moteurs génératifs combinent un index de récupération et un mécanisme de synthèse (LLM) qui sélectionne, résume et cite un sous-ensemble de sources — la fenêtre de citation est étroite (souvent 3 à 8 sources par réponse).
- Garantie
- La probabilité de citation croît avec : la présence de données structurées (Schema.org/JSON-LD) qui lèvent l'ambiguïté sur l'entité décrite, une structure HTML sémantique qui facilite le chunking/l'extraction, et une réponse directe/autoportante en tête de section.
- 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
Terme consensuel industrie 2026, pas d'organisme normatif dédié. Remplace AI-READY en langage stratégique.
geo
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.
Source faisant autorité : https://www.w3.org/TR/json-ld11/
Voir aussi : Discovery Layer · Trust Layer
JSON-LD est une recommandation W3C (lien url_ref_externe). Schema.org est un vocabulaire communautaire (Google/Microsoft/Yahoo/Yandex), pas formellement ratifié W3C — nuance à garder au niveau expert. Voir aussi https://schema.org/.
json-ld
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
Convention communautaire (initiée par Jeremy Howard / Answer.AI), pas de standard W3C/IETF, adoption réelle croissante (Vercel, Stripe, Anthropic).
llms-txt
Débutant
- Assertion
- Le SERP, c'est la page de résultats qu'un moteur de recherche affiche après une requête — la liste de liens classés que le SEO classique cherche à optimiser, par opposition à la réponse unique que vise le GEO.
- Exemple
- Taper « meilleur restaurant italien Paris » dans Google et voir une liste de dix sites classés, c'est le SERP — différent d'une IA qui répondrait directement avec un seul nom de restaurant.
Voir aussi : AEO (Answer Engine Optimization) · GEO (Generative Engine Optimization)
Terme fondateur du SEO classique, permet le contraste direct avec le GEO (réponse synthétisée unique vs liste de résultats classés).
serp
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
- En 2026, l'Action Layer reste peu déployée hors e-commerce (où UCP progresse) — la majorité des sites n'exposent aucune interface actionnable pour un agent.
- Réfutation
- Exposer une Action Layer sans Trust Layer robuste est risqué : un agent (ou son opérateur) n'autorisera pas une transaction automatisée sur un site dont il ne peut vérifier la fiabilité.
Voir aussi : WebMCP · UCP (Universal Commerce Protocol)
Interfaces programmatiques permettant à un agent d'agir sur le site (réserver, acheter, contacter). Taxonomie synthétisée, pas de source externe unique attendue.
action-layer
Débutant
- Assertion
- L'Agentic SEO, c'est préparer son site pour qu'un agent IA autonome (pas juste un humain) puisse y naviguer et agir — chercher un produit, réserver, payer.
- 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.
Voir aussi : Action Layer · UCP (Universal Commerce Protocol) · WebMCP
Terme d'usage instable : recouvre à la fois l'automatisation des workflows SEO par des agents IA (sens dominant en usage sectoriel) et, par extension, la capacité d'un site à être actionné par un agent externe (proche de l'Action Layer).
agentic-seo
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 & Schema.org
Approche d'architecture où la lisibilité machine prime/égalise la lisibilité humaine. Remplace AI-FIRST en langage technique. Concept synthétisé par JJV, pas de source externe unique attendue.
machine-first-design
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
- Un contenu bien segmenté, structuré et accessible (voir LLMO) améliore directement l'étape de récupération ; le GEO vise précisément à optimiser cette probabilité d'être récupéré puis cité en sortie de génération.
- 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.
Source faisant autorité : https://arxiv.org/abs/2005.11401
Voir aussi : GEO (Generative Engine Optimization) · AEO (Answer Engine Optimization)
Technique établie en recherche IA (Lewis et al. 2020, NeurIPS — papier fondateur en url_ref_externe). Le GEO vise à devenir la source de grounding du RAG.
rag
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
- Réduire la pollution structurelle (SSR propre, HTML sémantique, contenu texte autoporteur) améliore mécaniquement la qualité des chunks produits, donc la pertinence de la récupération.
- 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 technique développeur, moins répandu que GEO côté stratégie.
llmo
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 de valider la fiabilité d'une information avant de la citer ou d'agir dessus.
- Données
- Un agent IA croise généralement plusieurs signaux (site + profils tiers + avis) plutôt que de faire confiance à une seule page isolée.
- Garantie
- Une information non attribuable à une entité vérifiable (auteur, organisation) est statistiquement moins susceptible d'être retenue comme source par un système soucieux de limiter les hallucinations.
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
- Ces signaux réduisent le risque perçu par le système générant la réponse : citer une source vérifiable limite sa propre exposition à produire une hallucination attribuée à tort.
- 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 n'a pas de mesure objective unique (contrairement au JSON-LD, vérifiable syntaxiquement) — son évaluation reste largement heuristique et propre à chaque moteur/agent.
- Réfutation
- Une Trust Layer forte ne compense pas un contenu structurellement invisible (pas de SSR, pas de Discovery Layer) : la confiance ne sert que sur du contenu déjà atteint et compris par l'agent.
Voir aussi : JSON-LD & Schema.org
Éléments (Entity Schema, authorship, sources primaires) permettant à un agent de valider la fiabilité d'une information. Taxonomie synthétisée, pas de source externe unique attendue.
trust-layer
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
- Il constitue la brique dominante de l'Action Layer pour le e-commerce en 2026, positionné comme plus mature et plus adopté que les alternatives génériques encore en brouillon (WebMCP).
- Garantie
- Le poids des deux co-développeurs (Shopify, infrastructure e-commerce dominante ; Google, moteur de découverte dominant) crée un effet d'adoption réseau favorable à l'établissement d'UCP comme standard de fait.
- Fondement
- UCP s'inscrit dans la même famille que l'ACP (Agentic Commerce Protocol), terme plus générique englobant UCP et les API privées de transaction agent-à-site.
- 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
Standard ouvert co-développé Shopify/Google (2026) pour l'interaction agent/e-commerce (catalogue, panier, checkout).
ucp
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
- Un protocole standardisé côté W3C bénéficie d'un effet de réseau et d'une pérennité que des intégrations propriétaires site-par-site n'offrent pas.
- 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)
Community Group Draft (explicitement hors Standards Track W3C), porté par Google/Microsoft, initié début 2026, pour connecter LLMs/agents à des outils et données externes via une API JavaScript.
webmcp
Aucun terme ne correspond aux filtres.