Fr
Voici l'erreur de structure la plus fréquente sur un site B2B. Une page intitulée « Notre approche de la migration CMS » commence par trois paragraphes sur l'évolution du marché, enchaîne sur l'historique de l'entreprise, et livre enfin, au cinquième paragraphe, ce que le visiteur était venu chercher.
Un lecteur qui scanne part avant le cinquième paragraphe. Un utilisateur de lecteur d'écran qui navigue par titres ne trouve aucun point d'entrée utile. Et un système qui assemble une réponse à partir de passages ira chercher celui qui correspond le mieux à la question, qui sera celui d'un concurrent.
La conception answer-first règle les trois problèmes d'un coup. Ce n'est pas une technique IA. C'est de la bonne rédaction technique appliquée aux pages web, avec pour effet secondaire que les machines l'extraient proprement.
Placez la réponse directe juste après le titre qui pose la question, en deux ou trois phrases, avant tout contexte ou nuance. Écrivez des titres qui décrivent le contenu de la section plutôt que de courir après un mot-clé. Rendez chaque section lisible isolément. Gardez un seul H1 et une séquence H2 et H3 logique, non pas parce que les moteurs l'exigent, mais parce que les humains et les technologies d'assistance en ont besoin. Ajoutez une preuve qu'un modèle de langage n'aurait pas pu produire.
Tout ce qui suit développe ce paragraphe, qui est lui-même un exemple du principe.
À clarifier d'abord, parce que le discours SEO et les spécifications se contredisent, et que ce sont les spécifications qui ont raison.
Pour Google Search, l'ordre des titres n'est pas un enjeu de classement. Le SEO Starter Guide de Google indique que l'ordre sémantique des titres est excellent pour les lecteurs d'écran, mais que du point de vue de Google Search, un ordre non respecté n'a pas d'importance. Gary Illyes a confirmé en 2024 que cette recommandation est à jour. John Mueller répète depuis 2019 que plusieurs H1 sur une page constituent un schéma courant et ne posent pas de problème. Le guide IA générative de mai 2026 dit la même chose : un HTML parfaitement sémantique n'est pas requis, même si c'est généralement une bonne idée parce que cela aide les lecteurs d'écran à analyser et parcourir la page.
Pour l'accessibilité, la structure des titres est une obligation. Le critère WCAG 2.4.6 (niveau AA) exige que les titres et les libellés décrivent le sujet ou la fonction. Le critère 1.3.1 (niveau A) exige que la structure soit déterminable par programme, ce qui signifie qu'un titre doit être un véritable élément de titre et non du texte stylé. Les utilisateurs de lecteurs d'écran naviguent couramment en sautant de titre en titre : une page sans structure de titres, ou dont les titres annoncent « Introduction » et « En savoir plus », est réellement plus difficile à utiliser.
Pour l'extraction, la structure compte de façon indirecte mais réelle. Une réponse générée est assemblée à partir de passages. Un passage dont le sens dépend de trois paragraphes précédents est plus difficile à prélever qu'un passage autonome. Les titres restent le signal le plus fiable dont dispose une machine pour délimiter un passage.
Conclusion : construisez une hiérarchie propre pour le lecteur et pour l'accessibilité. L'extractibilité vient en prime. Ne la construisez pas parce qu'un outil a signalé un H3 sauté.
L'unité d'une page answer-first n'est pas la page. C'est le bloc : un titre, une réponse, une explication, une preuve.
1. Un titre qui pose la vraie question, dans les mots du lecteur, pas sous forme de mot-clé.
2. Une réponse directe de deux à quatre phrases, juste en dessous. Sans préambule. Sans « cela dépend » en ouverture. Si cela dépend réellement, dites de quoi dans la même phrase : « Deux langues, oui. Quatre, non, et la raison est la tarification par locale. »
3. L'explication. Le raisonnement, les nuances, les exceptions. C'est ici que « cela dépend » a sa place.
4. La preuve. Un chiffre, un exemple, une source, un cas. C'est la partie qui rend le bloc digne d'être récupéré plutôt que reformulé à partir du savoir commun.
La plupart des pages B2B possèdent les parties 1 et 3. Il leur manque les parties 2 et 4, c'est-à-dire les deux qui comptent.
Deux à quatre phrases, soit environ quarante à quatre-vingts mots. Assez pour être complète seule, assez courte pour être vue sans défilement.
La contrainte qui compte est l'autonomie, pas la longueur. Testez en lisant la réponse après avoir supprimé tout ce qui la précède. Si elle tient debout, elle fonctionne. Si elle commence par « C'est pourquoi nous recommandons la seconde option », elle échoue, parce que « la seconde option » renvoie à quelque chose que le lecteur n'a peut-être jamais vu.
Quand une page introduit un terme, définissez-le une fois, tôt, dans une phrase autonome de la forme « X est un Y qui fait Z ».
Le grounding est une technique de récupération, également appelée retrieval-augmented generation, dans laquelle un système va chercher des documents pertinents dans un index et génère sa réponse à partir des informations précises de ces documents plutôt qu'à partir de la seule mémoire du modèle.
Trois propriétés la rendent efficace. Elle nomme la catégorie (« une technique de récupération »). Elle donne le comportement distinctif (« va chercher des documents... génère à partir des informations précises »). Et elle ne contient aucun pronom pointant vers l'extérieur.
Comparez avec une définition ratée : « C'est ce qui rend tout cela possible, et c'est pourquoi la technique est devenue si importante. » Cette phrase ne peut être ni prélevée, ni comprise seule, et n'apprend rien.
Chacun mérite sa place sous une condition précise, et chacun est surutilisé.
Une liste convient quand les éléments sont réellement parallèles et que l'ordre est indifférent ou strictement séquentiel. Elle ne convient pas pour aérer une prose porteuse d'un raisonnement, car la liste supprime les articulations logiques.
Un tableau convient quand vous avez au moins deux sujets évalués selon les mêmes critères. C'est le seul cas. Si une colonne est majoritairement vide, ou si les critères diffèrent selon le sujet, ce ne sont pas des données tabulaires et le tableau induira en erreur.
Un bloc comparatif convient quand la décision du lecteur est binaire ou presque, et il doit porter un verdict. Une comparaison qui se termine sans dire à qui convient quoi n'a fait que la moitié du travail.
Gardez des tableaux simples, avec une ligne d'en-tête et des unités cohérentes. Un tableau à cellules fusionnées et balisage imbriqué est plus difficile à lire pour les technologies d'assistance et plus difficile à analyser pour tout le reste. Un tableau large exige aussi un conteneur à défilement horizontal sur mobile, sinon il casse la mise en page.
Une section FAQ se justifie quand il existe de vraies questions récurrentes qui n'entrent pas dans l'argumentation principale : objections, cas limites, questions connexes. Trois à six, chacune traitée en cinquante à cent cinquante mots.
Elle ne se justifie pas comme reformulation de l'article sous forme de questions, ce qui en est l'abus le plus courant. Si une question trouve déjà sa réponse dans un H2 plus haut, elle n'a rien à faire dans la FAQ.
Sur le balisage : Google a déprécié les résultats enrichis FAQ le 7 mai 2026. FAQPage reste un type Schema.org valide et sans effet négatif, mais ne produit plus aucune apparence de recherche chez Google, et aucune plateforme ne le documente comme facteur de citation IA. Écrivez la FAQ parce que vos lecteurs s'en servent. Considérez le balisage comme facultatif.
Le terme recouvre deux pratiques, et une seule tient.
La version saine consiste à écrire des sections autonomes aux frontières nettes, pour qu'un lecteur puisse entrer par n'importe quel titre et comprendre ce qu'il trouve. C'est simplement une bonne structure.
La version douteuse consiste à découper le contenu en fragments volontairement courts parce qu'un modèle les analyserait mieux. Google traite le sujet directement : il n'est pas nécessaire de fractionner le contenu en petits morceaux, ses systèmes comprennent plusieurs sujets sur une même page, et il n'existe pas de longueur idéale. Des pages plus courtes ou plus longues peuvent fonctionner selon l'audience et le sujet.
Écrivez des sections autonomes. Ne déchiquetez pas la page.
Nommez les choses en entier à la première occurrence de chaque section importante, puis utilisez la forme courte. Un lecteur qui arrive en milieu de page depuis un résultat de recherche, ou un système qui prélève une seule section, n'a pas lu votre premier paragraphe.
Les liens internes se placent dans le corps du texte, là où la référence se produit réellement, avec une ancre qui décrit la destination. « Cliquez ici » n'apprend rien au lecteur et encore moins à une machine. Deux à cinq liens internes contextuels sur une page longue constituent une fourchette raisonnable. Au-delà, ils cessent d'être de la navigation pour devenir du bruit.
Utilisez les éléments qui signifient ce que vous voulez dire. <article> pour le contenu, <section> pour les grandes divisions, <nav> pour la navigation, de vrais éléments de titre pour les titres, <table> avec <th> pour les données tabulaires, <dl> pour les listes de définitions quand elles s'y prêtent.
Deux règles comptent plus que l'inventaire des balises :
Ne stylez jamais un titre de niveau inférieur pour qu'il paraisse plus grand qu'un titre supérieur. Si un H4 doit ressembler à un H2, le problème est dans le CSS, pas dans le balisage. C'est la première cause de hiérarchie cassée en production, et elle vient de designers et de rédacteurs qui choisissent le niveau de titre selon la taille visuelle.
Ne sautez jamais un niveau pour des raisons visuelles. Passer de H2 à H4 pour éviter une taille de police est la même erreur en sens inverse.
Google s'en accommodera dans les deux cas. Les utilisateurs de lecteurs d'écran non, et le critère WCAG 1.3.1 exige que la structure soit déterminable par programme et non seulement visuelle.
L'expression vient d'un brevet Google : US 11 354 342 B2, « Contextual estimation of link information gain », déposé en octobre 2018 et délivré en juin 2022. Il décrit l'attribution d'un score à un document selon l'information supplémentaire qu'il apporte au-delà des documents déjà consultés par l'utilisateur, et l'usage de ce score dans la présentation des résultats.
Deux réserves que le secteur oublie généralement. Le brevet décrit un mécanisme relatif à ce qu'un utilisateur donné a déjà vu, ce qui relève davantage d'une déduplication au niveau de la session que d'un score global de nouveauté. Et Google n'a jamais confirmé que ce mécanisme fonctionne ainsi dans Search. Un brevet délivré prouve une idée, pas un système en production.
Ce qui survit à ces réserves mérite malgré tout d'être appliqué, parce que cela recoupe des recommandations que Google publie réellement. Son guide IA générative de mai 2026 indique qu'un contenu unique, convaincant et utile influencera probablement la présence dans la recherche générative davantage que tout le reste du guide, et oppose explicitement le contenu générique au contenu porteur d'expertise ou d'expérience réelle.
Traduction pratique : pour chaque page, demandez-vous ce qu'elle contient qu'un modèle de langage n'aurait pas pu produire à partir du savoir commun. Si la réponse est « rien », la structure ne la sauvera pas. La structure rend un bon contenu extractible. Elle ne rend pas un contenu creux digne d'être extrait.
Exemple travaillé pour une page comparative B2B. Chaque titre est descriptif, chaque H2 ouvre sur une réponse directe, et le plan se lit seul.
H1 CMS headless ou traditionnel : lequel pour une PME B2B ?
[Réponse directe, 3 phrases, avant tout titre]
H2 Réponse courte
[Verdict, 4 phrases]
H2 Ce que « headless » signifie réellement
H3 La définition technique
[Bloc de définition]
H3 Ce qui change pour l'équipe éditoriale
H3 Ce qui change pour l'équipe technique
H2 Les cinq critères qui tranchent
[Tableau de critères : traditionnel vs headless]
H3 Autonomie éditoriale
H3 Liberté du front-end
H3 Délai avant la première page
H3 Coût total sur trois ans
H4 Coût de construction
H4 Coût de fonctionnement
H4 Le coût que personne ne budgète : la friction éditoriale
H3 Compétences requises dans l'équipe
H2 Là où le CMS traditionnel garde l'avantage
[Réponse directe, puis trois scénarios nommés]
H2 Là où le headless s'impose
[Réponse directe, puis trois scénarios nommés]
H2 Ce qu'implique réellement une migration
H3 Modélisation du contenu
H3 La migration elle-même
H3 Ce qui casse, et à quel moment
H2 Comment décider en une réunion
[Une règle de décision en quatre questions]
H2 Questions fréquentes
[3 à 5 vraies questions non traitées plus haut]
H2 Sources et lectures complémentaires
Observez ce que fait ce plan. Le H1 est une question. Le premier H2 y répond. Les H2 du milieu portent l'argumentation. Les deux derniers indiquent la suite. Lisez les seuls titres et vous suivez tout le raisonnement : c'est le test.
Observez aussi ce qu'il ne fait pas. Aucun H5 ni H6. Aucun titre présent uniquement pour loger un mot-clé. Pas d'« Introduction ». Pas de « Conclusion », parce qu'un titre nommé « Conclusion » décrit sa position et non son contenu.
Raté : la réponse enterrée.H1 « Notre service de migration CMS », puis quatre paragraphes de contexte, avec le périmètre réel du service sous un H3 en bas de page.Correction : remonter le périmètre en réponse de deux phrases directement sous le H1, et reléguer le contexte dans une section que le lecteur peut sauter.
Raté : les titres comme emplacements à mots-clés.H2 « Services de migration CMS pour entreprises », H2 « Migration CMS professionnelle », H2 « Meilleurs services de migration CMS 2026 ».Correction : un H2 par sujet réel. « Ce que comprend une migration », « Ce que cela coûte », « Combien de temps cela prend », « Ce qui peut mal tourner ».
Raté : la hiérarchie visuelle qui pilote la hiérarchie sémantique.H1, puis H4 pour les sections principales parce que le H2 paraissait trop gros dans la maquette, puis H2 pour un encart secondaire parce qu'il fallait le mettre en avant.Correction : rétablir H1, H2, H3 dans le balisage, puis corriger le CSS pour que chaque niveau ait la bonne apparence. Une demi-heure de travail que la plupart des sites ne font jamais parce que personne n'en est propriétaire.
.png){kind=small}
<title>, ce qui déroute le lecteur venu de la rechercheRien de tout cela n'est nouveau, et rien n'est propre à l'IA. C'est précisément l'enjeu. Les pages que les machines extraient le plus proprement sont celles qui ont d'abord été bien écrites pour des humains.
Sources consultées le 21 septembre 2026.
Vous avez une idée ou un projet à concrétiser ? Décrivez-nous vos attentes en matière de création web, de design ou de solutions IA, et recevez une proposition personnalisée dédiée à votre croissance.
