Le plan du site HTML reste l’un des mécanismes de navigation les plus sous-exploités, alors qu’il répond à une exigence technique précise : offrir un accès alternatif à l’ensemble des pages d’un site sans dépendre du menu principal ni du moteur de recherche interne.
Plan du site HTML et sitemap XML : deux fichiers, deux fonctions distinctes
Confondre le plan du site visible par les visiteurs avec le fichier sitemap XML destiné aux robots d’indexation est une erreur fréquente, y compris chez des profils techniques. Le sitemap XML déclare des URL aux moteurs de recherche (Google, Bing) pour faciliter le crawl. Il ne contient ni hiérarchie lisible, ni libellés compréhensibles pour un humain.
Le plan du site HTML, lui, présente une arborescence de liens cliquables, organisés par rubriques, sous-rubriques et pages. Son rôle est strictement orienté utilisateur : permettre de localiser une page en quelques secondes, sans naviguer dans les menus déroulants ni deviner la structure du site.
Un bon exemple de cette distinction se retrouve sur le plan du site Habite Ta Terre, qui expose l’intégralité des rubriques accessibles aux visiteurs dans une arborescence lisible, indépendamment du fichier XML soumis aux robots.
Critère WCAG 2.4.5 et audit RGAA : le plan du site comme obligation technique
Le critère de succès 2.4.5 des WCAG 2.2 exige qu’une page web puisse être atteinte par au moins deux moyens distincts : navigation principale, recherche interne, plan du site ou liens contextuels. Les pages qui constituent une étape d’un processus (tunnel de commande, formulaire multi-étapes) sont exemptées.
Le plan du site satisfait cette exigence de manière directe en fournissant un chemin alternatif complet vers chaque page. Sans lui, un site doit compenser par une fonction de recherche performante ou un maillage interne dense, ce qui suppose un effort de conception plus lourd.
En France, le RGAA inclut la page du plan du site dans l’échantillon obligatoire d’un audit d’accessibilité, au même titre que la page d’accueil, les mentions légales ou la page de contact. Autrement dit, cette page n’est pas un bonus : elle est contrôlée et doit elle-même respecter les critères d’accessibilité.

Navigation au clavier et lecteurs d’écran : un plan du site qui ne fonctionne pas est pire que pas de plan
Publier une page intitulée « Plan du site » ne suffit pas. Si les liens ne reçoivent pas le focus clavier dans un ordre logique, ou si leur libellé n’est pas explicite pour les technologies d’assistance, la page devient un obstacle supplémentaire au lieu d’une aide.
Trois vérifications techniques sont à mener sur le plan du site :
- L’ordre de tabulation suit la hiérarchie visuelle de l’arborescence (rubrique principale avant sous-rubrique), sans saut ni retour en arrière inattendu.
- Chaque lien possède un intitulé explicite hors contexte : « Nos formations en alternance » fonctionne, « Cliquez ici » ou « En savoir plus » ne fonctionne pas pour un lecteur d’écran.
- Le focus reste visible sur chaque lien lors de la navigation au clavier, avec un indicateur de focus conforme (contraste suffisant, contour distinct).
Un utilisateur de lecteur d’écran qui arrive sur un plan du site mal balisé perd plus de temps qu’en explorant le menu principal. Nous constatons que la majorité des plans du site générés automatiquement par des CMS ne respectent pas ces trois points sans intervention manuelle.
Contenu du plan du site HTML : quoi inclure, quoi exclure
Un plan du site n’est pas un export brut de toutes les URL. Son utilité repose sur un tri éditorial qui reflète la structure du site sans noyer le visiteur.
Pages à intégrer systématiquement
- Les pages structurantes : accueil, rubriques principales, sous-rubriques de premier niveau.
- Les pages institutionnelles : mentions légales, politique de confidentialité, contact, déclaration d’accessibilité.
- Les pages de service : FAQ, aide, formulaire de demande, espace personnel (lien vers la page de connexion, pas vers le contenu protégé).
Pages à exclure
Les articles de blog paginés, les résultats de recherche interne, les pages de tags ou d’archives par date n’apportent rien dans un plan du site orienté navigation. Un plan du site surchargé perd sa fonction de repère visuel et devient aussi difficile à parcourir que le site lui-même.
Pour les sites avec un volume important de contenus (plusieurs centaines d’articles), regrouper les publications par catégorie en ne listant que les catégories parentes reste la solution la plus lisible.

Génération automatique ou construction manuelle du plan du site HTML
La plupart des CMS proposent des extensions qui génèrent un plan du site HTML à partir de l’arborescence existante. Sur WordPress, des plugins comme WP Sitemap Page ou Simple Sitemap produisent une liste de liens à partir des pages publiées.
Le problème de la génération automatique est double. D’abord, elle inclut par défaut des pages sans intérêt pour la navigation (pages d’auteur, archives mensuelles, pages de médias). Ensuite, la hiérarchie affichée reflète la structure technique du CMS, pas la logique de navigation pensée pour le visiteur.
La construction manuelle, ou semi-manuelle (génération automatique suivie d’un nettoyage éditorial), garantit un plan du site cohérent avec le parcours utilisateur réel. Le surcoût de maintenance est modéré : une mise à jour trimestrielle suffit pour la plupart des sites dont l’arborescence évolue peu.
Accès au plan du site : placement et convention de lien
Le lien vers le plan du site se place dans le pied de page, à proximité des mentions légales et de la déclaration d’accessibilité. Cette convention est suffisamment répandue pour que les utilisateurs sachent où chercher. Placer le lien uniquement dans un menu secondaire ou dans une page « À propos » réduit considérablement sa découvrabilité.
L’intitulé du lien doit être « Plan du site », sans variante créative. Les utilisateurs qui cherchent cette page scannent le footer à la recherche de ce terme exact. « Carte du site », « Index » ou « Navigation » ne correspondent pas à l’attente et réduisent le taux de clic.
Un plan du site bien construit, accessible au clavier et placé dans le footer transforme la navigation d’un site en parcours prévisible. C’est un investissement de quelques heures qui répond simultanément aux exigences RGAA, aux besoins des utilisateurs de technologies d’assistance et à la frustration de tout visiteur confronté à un menu de navigation insuffisant.



