L'essentiel
  • L'AEO consiste à structurer son contenu pour être cité par les IA comme Perplexity ou ChatGPT, pas seulement indexé par Google.
  • Reformuler les H2 comme des vraies questions ('Comment configurer... ?') permet à l'IA d'identifier le bloc comme réponse candidate.
  • Les nuggets de réponse sous 60 mots placés avant l'explication sont extraits tels quels par les IA génératives.
  • Le JSON-LD est lu en priorité par les crawlers pour établir le contexte (auteur, date, sujet) avant même le contenu textuel.
  • Un domaine récent peut être cité par Perplexity si son contenu est plus précis et mieux structuré que les sources établies.

Lecture complète : 6 min

Réponse directe : L’AEO consiste à structurer ton contenu pour qu’il soit extrait comme source de confiance par les IA génératives. Concrètement : des balises HTML5 sémantiques, des réponses condensées sous 60 mots juste après chaque titre, et des données structurées JSON-LD précises. L’objectif n’est plus seulement d’apparaître dans Google, mais d’être cité par Perplexity, Gemini ou ChatGPT quand quelqu’un pose une question dans ton domaine.

Pendant longtemps, j’ai publié des articles sur builtwithbugs.com sans me poser la question de qui les lirait vraiment. Google. Des humains qui cliquent. Le canal classique.

Puis j’ai testé quelques requêtes sur Perplexity. Des requêtes directement liées à ce que j’écris, VPS Hetzner, automatisation Python, prompt engineering pour makers. Et j’ai vu mes articles absents. Les sources citées : Stack Overflow, dev.to, des blogs anglais avec 10 fois plus d’autorité de domaine que moi.

Le problème n’était pas uniquement mon autorité de domaine. C’était aussi ma structure.

Pourquoi l’AEO est devenu une priorité pour un blog comme le mien

Le SEO classique optimisait pour le clic. L’AEO optimise pour la citation.

Dans le modèle traditionnel, tu vises la position 1 pour qu’un utilisateur clique sur ton lien. Dans le modèle des moteurs de réponse, l’IA lit ton contenu, en extrait la partie pertinente, et la restitue à l’utilisateur sans nécessairement générer un clic. Ton intérêt n’est plus d’être cliqué, mais d’être la source que l’IA choisit de citer.

Ce qui détermine ce choix : la clarté structurelle de ton contenu, sa précision sémantique, et les signaux E-E-A-T que ton domaine dégage.

Pour un blog comme builtwithbugs.com, avec un nouveau domaine et peu de backlinks, c’est paradoxalement une opportunité. L’AEO favorise la précision du contenu autant que son autorité. Un nugget de 50 mots qui répond exactement à une question peut être extrait même depuis un domaine récent.

Comment j’ai restructuré mes articles pour les rendre extractibles

Il y a trois changements concrets que j’ai appliqués article par article.

Formuler les H2 comme les questions réelles des utilisateurs

J’avais des H2 comme “Configuration initiale” ou “Stack technique”. Ça ne correspond à aucune requête réelle.

Reformulés en “Comment configurer un VPS Hetzner pour un pipeline Python ?” ou “Quelle stack pour automatiser ses posts LinkedIn sans outil payant ?”, ces titres mappent directement sur ce que quelqu’un taperait dans Perplexity. C’est ce qui permet à l’IA d’identifier ton bloc comme la réponse candidate à une requête donnée.

Ce changement de formulation a un impact immédiat sur l’extractibilité. Aucun outil nécessaire pour le mesurer : tu lis tes H2 à voix haute et tu te demandes si c’est une question que tu poserais toi-même.

Placer le nugget de réponse avant l’explication

La règle la plus contre-intuitive quand on vient de l’écriture longue : mettre la conclusion en premier.

Juste après chaque H2, je mets un paragraphe court de deux à trois phrases qui résume la réponse complète. Le reste de la section développe, nuance, illustre. Mais le nugget doit suffire à quelqu’un qui ne lirait que lui.

C’est exactement ce que font les boîtes “Réponse directe” en tête de cet article. Ce format isole l’information utile dans un bloc délimité et concis, ce que les moteurs de réponse cherchent précisément.

Traiter le JSON-LD comme un signal de confiance, pas une formalité

J’ai longtemps mis le JSON-LD en place sans vraiment comprendre pourquoi. J’avais un schéma BlogPosting généré par le layout Astro, et je me disais que ça suffisait.

Ce qui compte vraiment : les champs author, datePublished, dateModified et description renseignés précisément. Les IA utilisent ces données pour évaluer la fraîcheur et la fiabilité d’une source. Un article sans dateModified récent est perçu comme potentiellement obsolète.

Dans mon layout Astro, ça ressemble à ça :

<script type="application/ld+json" set:html={JSON.stringify(schemaData)} />

La variable schemaData est construite dynamiquement depuis les frontmatter. Chaque article a ses propres métadonnées, et les IA le vérifient.

Ce que j’ai mesuré depuis que j’applique ces changements

Je ne vais pas prétendre avoir des données irréfutables sur un domaine aussi jeune.

Ce que je constate : mes articles EADDRINUSE et VPS commencent à apparaître dans des réponses Perplexity sur des requêtes très spécifiques. Pas sur les requêtes génériques, les requêtes de niche : “double installation Node.js conflit port Ubuntu”, “script Python notion api format paragraphes”.

C’est cohérent avec ce que je comprends de l’AEO : un contenu précis sur une question de niche bat souvent un contenu générique sur un sujet large, même depuis un domaine moins autoritaire.

L’autre signal : Google Search Console montre une légère hausse des featured snippets sur les articles les plus structurés. Ce n’est pas le même canal que Perplexity, mais les critères d’extractibilité se recoupent largement.

La conclusion que j’aurais dû appliquer à mes premiers articles

Toutes les optimisations techniques décrites ici sont nécessaires mais pas suffisantes.

Les IA évaluent la fiabilité d’une source, pas seulement sa lisibilité. Partager de vrais bugs, de vrais chiffres, de vrais délais construit un signal de confiance que le contenu générique ne peut pas imiter. Un article qui dit “j’ai passé 6h à débugger cette erreur de port, voici ce que j’ai trouvé” est perçu comme plus fiable qu’un article qui explique comment “optimiser ton infrastructure serveur”.

C’est ce que j’essaie de faire depuis le début sur builtwithbugs.com. Partager le processus réel, y compris les parties qui ne fonctionnent pas du premier coup.

L’AEO m’a juste aidé à mieux structurer ce que j’avais déjà à dire.

Pour aller plus loin

Trois articles qui complètent directement ce que je décris ici :