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 agit sur ces deux aspects. Il émet un balisage lisible par les machines décrivant les questions et les procédures que votre page contient déjà, en activant un simple bouton. Et il rédige et impose le contenu selon un ensemble de règles axées sur le passage, et non sur la page — ce sont ces règles qui influencent 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 sans que vous ayez à le demander, et ce qu’il vous reste à faire.

De quoi un moteur de réponses a-t-il besoin d’une page ?#

Quatre éléments, dans cet ordre. Les deux premiers sont structurels et Docsbook s’en charge ; les deux derniers sont ce 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"> qui renferme 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.

L’activation de AEO dans l’onglet d’administration SEO / GEO en ajoute trois autres, chacun 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, chaque réponse étant limitée à 1 000 caractères.
• HowTo — lorsqu’un titre commençant par « How to » (ou 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 à l’intérieur du TechArticle qui nomme .tldr, le premier paragraphe de l’article et le H1, dans cet ordre de préférence.

Une page sans FAQ n’obtient pas de FAQPage, et une procédure en deux étapes n’obtient pas de HowTo. C’est intentionnel, et non une lacune : la politique de Google en matière de données structurées stipule « Ne balisez pas un contenu qui n’est pas visible par les lecteurs de la page », et enfreindre cette règle peut entraîner une action manuelle supprimant l’éligibilité aux résultats enrichis (Google). Les déclencheurs, seuils et données JSON générées sont détaillés dans Réponses structurées.

L’AEO est une option disponible avec chaque forfait. Les agents qui appliquent les règles de rédaction pour vous sont une fonctionnalité payante — consultez la tarification.

Pourquoi c'est la bonne méthode (preuves)#

Limites et questions ouvertes#

• 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, sur ordinateur comme sur mobile » — et a limité les FAQ aux sites gouvernementaux et de santé reconnus au même moment. Les FAQ ont ensuite été entièrement 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 du JSON-LD. Ce qu'ils ne font plus, c'est produire un résultat enrichi Google. Si un fournisseur vous affirme le contraire, demandez-lui la date de sa source.
• Vous ne pouvez pas baliser votre page pour obtenir un extrait optimisé. Interrogé sur la manière de baliser 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, dans ce cas, la mettent en avant » (Google, extraits optimisés). Les extraits optimisés s'obtiennent grâce au texte rédigé. C'est pourquoi Règles de contenu est la page la plus longue des deux.
• speakable est une version bêta soumise à des conditions d'accès 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 dont les appareils Google Home sont 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.
• Point encore incertain : 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 démontrée.
• Point encore incertain : 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 de tiers établissent une corrélation entre le JSON-LD et les citations, mais la corrélation observée 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, mais qu'il n'apporte aucun avantage mesurable que nous puissions vous dé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 — pas de BreadcrumbList, pas de FAQPage, pas de HowTo, pas de speakable, et le bouton AEO n'y a aucun effet. Sur les 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 contient 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 après avoir activé l'AEO — Réponses structurées explique à quoi ressemble un échec.

Références associées#

• 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 — les balises meta, le plan du site, les 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 du site pour les robots d’exploration IA
• Comment Docsbook prouve ce qu’il affirme — la règle de preuve que suivent ces pages