AEO — Optimisation pour les moteurs de réponse

Un moteur de réponse — un extrait optimisé Google, un assistant vocal, un assistant IA intégré à un produit — ne lit pas votre page. Il en sélectionne un passage, affiche ce passage à la place de la page, puis passe à autre chose. L’AEO consiste à s’assurer qu’un passage de votre page est celui qui peut être sélectionné, et qu’il reste correct une fois extrait de son contexte.

Docsbook contribue à cela de deux façons. Il génère un balisage lisible par les machines décrivant les questions et les procédures que votre page contient déjà, sur chaque page, sans rien avoir à activer. Et il rédige et applique le contenu selon un ensemble de règles ciblées sur le passage, et non sur la page — ces règles sont la partie qui influence réellement le résultat, et elles se trouvent dans Règles de contenu pour les moteurs de réponse.

Cette page explique ce dont un moteur de réponse a besoin, ce que Docsbook fournit automatiquement et ce qu’il vous reste à faire.

Que faut-il à un moteur de réponses d’une page ?#

Quatre éléments, dans cet ordre. Les deux premiers sont structurels et Docsbook s’en charge ; les deux derniers sont ceux que vous rédigez.

Le balisage ne figure nulle part dans cette liste, et cet ordre est délibéré. Le balisage décrit le contenu ; il ne le crée pas.

Que génère automatiquement Docsbook ?#

Chaque page de documentation contient un bloc <script type="application/ld+json"> regroupant un @graph de schema.org. Trois objets y figurent sur chaque page, quels que soient vos paramètres : un Organization pour le propriétaire du projet, un TechArticle pour la page elle-même, et un BreadcrumbList construit à partir de la même URL canonique que celle utilisée par le <link rel="canonical"> de la page.

Trois autres sont ajoutés automatiquement, uniquement lorsque la page contient réellement le contenu correspondant :

• FAQPage — lorsque la page comporte une section FAQ ou un H3 formulé comme une question. Jusqu’à 20 questions, avec une réponse limitée à 1 000 caractères.
• HowTo — lorsqu’un titre commençant par « How to » (ou par le russe « Как ») est suivi d’une liste numérotée d’au moins trois étapes. Jusqu’à 5 procédures par page, avec 20 étapes chacune.
• speakable — un SpeakableSpecification dans le TechArticle nommant .tldr, le premier paragraphe de l’article et le H1, dans cet ordre de préférence.

Une page sans FAQ n’obtient aucun FAQPage, et une procédure en deux étapes n’obtient aucun HowTo. C’est intentionnel, et non une lacune : la politique de Google relative aux données structurées indique « Ne balisez pas du contenu qui n’est pas visible par les lecteurs de la page », et son non-respect peut entraîner une action manuelle supprimant l’éligibilité aux résultats enrichis (Google). Les déclencheurs, seuils et JSON générés exacts sont décrits dans Réponses structurées.

Le balisage AEO est généré pour chaque projet et chaque forfait, et aucun paramètre ne permet de le désactiver. (Il s’agissait d’une option, et disposait d’un outil MCP update_aeo, jusqu’au 14 septembre 2026.) Les agents qui appliquent les règles rédactionnelles pour vous sont une fonctionnalité payante — consultez les tarifs.

Pourquoi est-ce la bonne méthode (preuves)#

Limites et questions en suspens#

• Google n'affiche plus de résultats enrichis FAQ ou How-to, et nous ne prétendrons pas le contraire. Google a supprimé le résultat enrichi How-to en septembre 2023 — « n'est plus affiché dans les résultats de recherche, ni sur ordinateur ni sur les appareils mobiles » — et a simultanément limité les FAQ aux sites gouvernementaux et de santé reconnus. Les FAQ ont ensuite été complètement abandonnées : le propre journal des mises à jour de Google indique que « cette fonctionnalité n'apparaîtra plus dans Google Search à partir du 7 mai 2026 » et la documentation a été supprimée le 15 juin 2026 (mises à jour de la documentation Google). Aucun de ces deux types n'apparaît dans la galerie actuelle des résultats enrichis pris en charge. Ce que FAQPage et HowTo font encore, c'est rendre les questions-réponses et la procédure explicites pour tout ce qui analyse le JSON-LD. Ce qu'ils ne font plus, c'est produire un résultat enrichi Google. Si un fournisseur vous dit le contraire, demandez-lui la date de sa source.
• Vous ne pouvez pas obtenir un extrait optimisé grâce au balisage. À la question de savoir comment marquer une page comme extrait optimisé, Google répond : « Vous ne pouvez pas. Les systèmes de Google déterminent si une page constituerait un bon extrait optimisé pour la requête d'un utilisateur et, le cas échéant, la mettent en avant » (Google, extraits optimisés). Les extraits optimisés s'obtiennent grâce au texte rédactionnel. C'est pourquoi les règles de contenu constituent la page la plus longue des deux.
• speakable est une fonctionnalité bêta soumise à des conditions strictes. L'implémentation de Google est « en version bêta et susceptible d'être modifiée », limitée aux éditeurs d'actualités, et s'adresse aux « utilisateurs aux États-Unis qui disposent d'appareils Google Home configurés en anglais » (Google, speakable). Un site de documentation n'est pas un éditeur d'actualités : considérez donc ce balisage comme une déclaration correcte de la partie de la page qui constitue le résumé, et non comme un moyen d'accéder à une enceinte connectée.
• Question en suspens : les autres assistants vocaux. Les versions précédentes de cette page indiquaient qu'Amazon Alexa lisait le balisage speakable. Nous n'avons pas trouvé de source Amazon primaire l'affirmant, et schema.org ne publie aucune liste de consommateurs. Ce qui est vérifiable : speakable est une propriété schema.org, Google en documente une utilisation bêta, et rien d'autre n'est documenté par son fournisseur. Considérez toute affirmation concernant Alexa et speakable comme non étayée.
• Question en suspens : les moteurs de réponse IA lisent-ils réellement le JSON-LD. Aucun fournisseur de modèles — OpenAI, Anthropic, Google, Perplexity — ne publie de déclaration indiquant que son pipeline de récupération analyse le balisage schema.org. Des analyses tierces établissent une corrélation entre le JSON-LD et les citations, mais la corrélation sur des pages explorées ne permet pas de distinguer le balisage de la qualité du site qui l'accompagne généralement. Tant qu'un fournisseur ne le documente pas, la position honnête est que le JSON-LD supprime l'ambiguïté pour tout ce qui choisit de l'analyser, et qu'il n'apporte aucun avantage mesurable que nous puissions vous montrer.
• Les domaines personnalisés ne bénéficient pas du balisage AEO. Un espace de travail diffusé sur son propre domaine est rendu via un chemin différent qui n'émet qu'un TechArticle minimal — ni BreadcrumbList, ni FAQPage, ni HowTo, ni speakable. Aux adresses *.docsbook.io, le graphe complet est émis. Il s'agit d'une lacune connue, et non d'une configuration que vous pouvez modifier.
• Docsbook ne valide aucunement le balisage qu'il émet. Le pipeline ne comporte aucun linter de schéma et audit_geo n'inspecte pas le JSON-LD. Vérifiez une page avec le test des résultats enrichis de Google ou le validateur de balisage Schema — la page réponses structurées explique à quoi ressemble un échec.

Articles associés#

• Réponses structurées — les types émis, les déclencheurs et le véritable JSON-LD
• Règles de contenu pour les moteurs de réponse — les règles qui influencent réellement le résultat
• SEO — balises meta, sitemap, URL canoniques et noindex
• GEO — le bloc TL;DR que le sélecteur speakable préfère, et les citations par les assistants
• llms.txt — l’index au niveau du site pour les robots d’exploration IA
• Comment Docsbook prouve ses affirmations — la règle de preuve que ces pages suivent