Les balises sémantiques sont des éléments du langage HTML dont le nom indique la fonction du contenu qu’ils encadrent, comme l’en-tête, la navigation, le contenu principal ou le pied de page, et non son apparence.
Elles ont été généralisées par HTML5. Les principales délimitent les grandes zones d’une page : « header » pour l’en-tête, « nav » pour un bloc de navigation, « main » pour le contenu principal, « article » pour un contenu autonome, « section » pour une partie thématique, « aside » pour un contenu complémentaire et « footer » pour le pied de page. Les navigateurs et les technologies d’assistance identifient ces zones ; les lecteurs d’écran permettent d’y accéder directement. Un document ne doit compter qu’un seul élément « main » visible. Un « header » ou un « footer » placé dans un article ou une section décrit cette partie, et non le site entier.
D’autres éléments portent aussi un sens : les titres de h1 à h6, appelés balises Hn, les listes, les tableaux, les citations ou la mise en valeur d’un passage important. Ils s’opposent aux conteneurs génériques, « div » et « span », qui regroupent du contenu sans rien dire de son rôle.
Les balises sémantiques se distinguent du balisage sémantique, notion plus large qui inclut aussi les données structurées. Celles-ci décrivent la nature de ce dont parle la page, une organisation ou un produit par exemple, et non le rôle de ses zones. Le sujet intervient lors de la conception des gabarits d’un site, d’une refonte et des audits d’accessibilité ou de SEO technique.
On présente souvent les balises sémantiques comme un moyen d’améliorer son classement. Nous ne partageons pas cette lecture : leur bénéfice documenté concerne l’accessibilité. Le tutoriel du W3C sur les régions de page (mise à jour en mars 2026) les rattache notamment à deux critères des règles internationales d’accessibilité : le contournement des blocs répétés et la transmission de l’information et des relations entre éléments. Un utilisateur de lecteur d’écran peut sauter la navigation et aller droit au contenu principal.
Pour le référencement, notre position est prudente. Un code qui désigne clairement le contenu principal est plus simple à lire pour tout programme, robots compris. Nous n’en faisons pas pour autant un levier de position. C’est une qualité de fabrication du site, à exiger dès la conception.
Nous recommandons d’inscrire ces règles dans le cahier des charges de la refonte. Ajoutées après coup, elles touchent tous les gabarits et coûtent davantage.
Nous proposons quatre repères de contrôle, gabarit par gabarit : la présence d’un « main » unique, le nombre de navigations non nommées, la part de zones structurées par de simples « div » et le nombre d’anomalies relevées par un outil d’audit d’accessibilité. Ces relevés automatiques se complètent par un test manuel au lecteur d’écran sur les deux ou trois gabarits les plus visités.
Advalians pilote pour vous les prestataires de votre site, du cadrage à l’adoption : besoin formalisé, critères de choix explicites, budget tenu et usage mesuré.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
Une balise sémantique dit ce qu’est le contenu ; une « div » le regroupe sans rien en dire. Visuellement, les deux peuvent produire le même rendu, car l’apparence relève des feuilles de style.
La différence apparaît pour les programmes qui lisent la page. Un « nav » est reconnu comme une navigation et un « main » comme le contenu principal, auquel un lecteur d’écran permet d’accéder directement. Règle pratique : utilisez l’élément sémantique dès qu’une zone a un rôle identifiable, et réservez la « div » aux regroupements purement graphiques.
Inscrivez-les dans le cahier des charges, gabarit par gabarit, avant le développement. Pour chaque modèle de page, listez les zones attendues : en-tête, navigation, contenu principal, contenus annexes, pied de page.
Demandez à l’équipe de développement une maquette annotée qui associe chaque zone à son élément HTML. Prévoyez un contrôle à la recette : un seul « main » visible, des navigations nommées, des sections titrées. Faites tester les gabarits principaux au lecteur d’écran par une personne formée. Corriger à ce stade coûte bien moins qu’après la mise en ligne.
Combinez un outil automatique et un test manuel. Un outil d’audit d’accessibilité intégré au navigateur signale l’absence de « main », les doublons et les navigations sans nom.
Ouvrez ensuite l’arbre d’accessibilité dans les outils de développement du navigateur. Il montre les zones reconnues, comme la navigation ou le contenu principal. Terminez par un parcours au lecteur d’écran : la liste des zones doit permettre d’atteindre le contenu principal en une action. Consignez les écarts par gabarit, puisque c’est là qu’ils se corrigent.
L’absence de zone de contenu principal, ou sa duplication, est l’erreur la plus gênante. L’utilisateur perd le moyen le plus direct d’atteindre le contenu et doit souvent parcourir l’en-tête et la navigation à chaque page.
Viennent ensuite les navigations multiples sans nom, impossibles à distinguer, et les sections sans titre, qui fragmentent la page sans repère. Vérifiez ces trois points en priorité sur les gabarits les plus visités. Un balisage approximatif peut être pire qu’aucun balisage : il annonce une structure qui ne correspond pas à ce que l’utilisateur découvre.
Pas toujours dans un chantier dédié. Si le site doit être refondu dans l’année, intégrez ces exigences au cahier des charges de la refonte. Sinon, corrigez en priorité les gabarits les plus visités, car une correction de gabarit s’applique à toutes les pages qui l’utilisent.
Critère de décision : si un audit d’accessibilité révèle des blocages pour les utilisateurs de technologies d’assistance, la correction est urgente. Si le site fonctionne mais avec un code peu explicite, traitez le sujet au fil des évolutions. N’attendez pas de cette seule reprise une hausse de trafic.
Modèles, grilles et guides prêts à l’emploi pour vos projets marketing et communication.
