Menu de navigation d’un site web : organiser les pages

9 min de lecture

Le menu de navigation d’un site web doit aider votre visiteur à choisir une destination, pas exposer votre organisation interne. Pour un site de services, partez des demandes : identifier une prestation, vérifier un domaine d’intervention, comprendre une notion ou candidater. Vous pourrez ensuite sélectionner les pages du menu, nommer les rubriques et vérifier le parcours sur mobile comme au clavier.

Un menu utile associe des intitulés compréhensibles, une arborescence cohérente et des commandes utilisables. Validez les destinations par des tâches concrètes, sans imposer une règle universelle de nombre de clics.

Commencer par les demandes, pas par l’organigramme

Avant de dessiner le menu, constituez un inventaire des pages et des besoins. Pour chaque destination, notez son adresse si elle existe, son contenu réel, la demande à laquelle elle répond, le public concerné et la personne capable de valider sa description. Repérez les doublons, les pages obsolètes et les destinations encore absentes.

Réunissez ensuite les questions adressées aux équipes commerciales, techniques et de recrutement, sans les transformer en statistiques. Les formulations employées par vos visiteurs sont plus utiles pour nommer une rubrique que les abréviations internes. Distinguez une demande de prestation, une recherche documentaire et une candidature : elles n’appellent pas le même parcours.

Classez enfin les pages selon leur rôle : entrée principale, page de rubrique, détail ou ressource complémentaire. Une page importante n’a pas nécessairement sa place dans le menu global. Elle doit en revanche être accessible depuis une page pertinente : Google recommande que chaque page jugée importante reçoive un lien depuis au moins une autre page du site ^[17].

Organiser le menu de navigation du site web

L’exemple suivant est fictif : un bureau d’ingénierie présente ses prestations, ses secteurs, ses ressources et ses possibilités de recrutement. Il ne s’agit pas d’un client de 4SYSTEM. Nous proposons cette arborescence comme hypothèse de travail :

• Prestations : diagnostic de structures, études de renforcement, assistance à maîtrise d’ouvrage.
• Secteurs : bâtiments tertiaires, sites industriels, équipements publics.
• Ressources : guides techniques, glossaire structure.
• Le bureau : méthode de travail, équipe.
• Recrutement : offres d’emploi, candidature spontanée.
• Contact : présenter un projet ou poser une question.

La taxonomie, c’est la logique de classement : les prestations décrivent une intervention ; les secteurs décrivent le contexte où elle s’exerce. « Solutions » brouillerait cette distinction. Une page de rubrique doit expliquer ce qu’elle rassemble et orienter vers ses détails, plutôt que reproduire le sous-menu sans contexte.

Ajoutez un niveau seulement lorsqu’il correspond à une distinction utile au visiteur. Si une branche devient difficile à comprendre, examinez ses regroupements avant de tout ramener au premier niveau. Le bon arbitrage porte sur la compréhension des choix, pas sur un seuil universel de clics.

Des intitulés qui annoncent une destination

Un intitulé doit permettre d’anticiper la page suivante. Google recommande un texte de lien descriptif, raisonnablement concis et pertinent pour la page de départ comme pour la destination ^[17]. Lisez vos libellés seuls : si leur sens disparaît hors de la maquette, reformulez-les.

Voici une grille de diagnostic remplie pour le bureau fictif. Les propositions sont à tester, pas des résultats observés.

Gardez une même forme grammaticale entre rubriques comparables. Évitez les sigles sans explication et les intitulés si longs qu’ils deviennent difficiles à parcourir sur mobile. Le contenu doit tenir la promesse du libellé : renommer « Documentation » en « Guides techniques » impose de vérifier les documents réellement proposés.

Séparer les liens des commandes de sous-menu

Pour cette maquette, séparons les destinations et les commandes. « Prestations » peut être un lien vers la page de rubrique ; un bouton voisin, nommé « Afficher les prestations », commande le sous-menu. Son nom accessible et son état doivent permettre de comprendre s’il est ouvert ou fermé. Nous retenons ici une navigation de liens, pas un comportement de menu d’application.

Les destinations utilisent des liens HTML a avec un attribut href contenant une adresse réelle. C’est le format que Google peut généralement explorer ; une action de script seule ne remplace pas ce lien ^[17].

Le WAI demande que les sous-menus déroulants soient utilisables à la souris et au clavier ^[14]. Notre scénario de contrôle vérifie donc, dans cet ordre :

• atteindre chaque lien et bouton avec Tab, en voyant le focus ;
• ouvrir le sous-menu au clavier et accéder à ses destinations ;
• le fermer avec Échap ou sa commande de fermeture ;
• retrouver le bouton déclencheur après fermeture, sans perdre le focus ;
• revenir à la page précédente sans état de menu incohérent.

Sur mobile, testez également l’ouverture tactile, le défilement et la fermeture. Aucune destination ne doit dépendre du survol. Vérifiez que des liens masqués ne restent pas parcourables au clavier. Si le panneau mobile masque la page, contrôlez aussi que le focus ne se déplace pas vers des éléments invisibles derrière lui. À la souris, le sous-menu ne devrait pas disparaître immédiatement lorsque le pointeur quitte sa zone cliquable ^[14].

Situer la page et permettre de revenir

Le menu principal sert à choisir une grande destination. Le fil d’Ariane situe la page dans une hiérarchie : par exemple « Accueil > Prestations > Études de renforcement ». Il ne reproduit pas forcément les pages visitées auparavant. Le bouton de retour du navigateur répond à cette autre fonction.

Les liens contextuels accompagnent une question née pendant la lecture : depuis une prestation, consulter un guide sur les investigations préalables ou ouvrir le formulaire de contact. Pour organiser ces passages, consultez notre guide du maillage interne entre pages utiles.

Signalez aussi la page active dans la navigation. Le WAI souligne l’intérêt de menus distincts et d’états facilement identifiables, notamment la page courante ^[14]. Le fil d’Ariane ne remplace donc ni le menu ni les liens placés dans le contenu.

Dans les tests, regardez comment une personne revient d’un détail vers sa rubrique, puis change de secteur. Un chemin court mais ambigu mérite une correction ; une étape supplémentaire clairement nommée peut rester pertinente.

Un protocole de test fondé sur des tâches

Préparez une version identifiable de l’arborescence, puis une maquette interactive. Définissez avant la séance la destination attendue et ce qui prouvera qu’elle répond à la demande. Choisissez des personnes correspondant aux publics visés ; faites varier les conditions entre ordinateur, mobile et clavier, sans supposer qu’un essai couvre tous les usages.

Voici des consignes utilisables pour le bureau fictif :

• « Vous préparez le renforcement d’un bâtiment existant. Trouvez l’intervention adaptée et expliquez ce qu’elle couvre. » Cible : Études de renforcement.
• « Vous représentez un exploitant industriel. Où vérifier que le bureau intervient dans votre contexte ? » Cible : Sites industriels.
• « Vous cherchez la définition d’un terme de structure. Où la consulter ? » Cible : Glossaire structure.
• « Vous souhaitez candidater sans offre correspondante. Où trouver la marche à suivre ? » Cible : Candidature spontanée.

Lisez seulement la consigne, pas la cible. Demandez à la personne de dire ce qu’elle attend derrière son premier choix. Observez ensuite le parcours sans indiquer la bonne rubrique. Consignez l’intitulé choisi, les hésitations, les retours, la destination atteinte et une courte formulation de son raisonnement.

À l’arrivée, demandez de montrer l’information qui répond au besoin. Un clic sur la page prévue ne suffit pas si son contenu ne permet pas de confirmer le choix. Terminez par un retour vers la rubrique, puis un changement de destination. Notez les incidents techniques séparément des incompréhensions de classement.

Décider des corrections et conserver la preuve

Corrigez d’abord les destinations cassées et les commandes inutilisables. Traitez ensuite les ambiguïtés de nommage, puis les regroupements. Si un libellé est compris mais mène vers un contenu inadéquat, corrigez la page plutôt que le menu. Ne changez pas simultanément tous les paramètres : vous perdrez la possibilité d’interpréter le nouvel essai.

Fiche de validation préparée, non testée : tâche « renforcement d’un bâtiment » ; cible « Études de renforcement » ; entrée proposée « Prestations » ; risque à examiner « confusion avec Secteurs » ; preuve attendue « parcours noté et information pertinente désignée sur la page ».

Après correction, rejouez la tâche et les contrôles techniques. Conservez la version de la maquette, les notes anonymisées, la décision motivée et une capture de l’état corrigé. La validation exige une destination comprise et un retour utilisable, pas une impression générale favorable.

Ce périmètre ne constitue pas un audit réglementaire du site. Le tutoriel WAI fournit des bonnes pratiques ^[14] ; les formulaires, documents et autres composants restent à examiner selon le référentiel applicable à votre organisme.

Questions fréquentes

Une prestation peut-elle apparaître dans plusieurs secteurs ?

Oui, si chaque lien conduit vers la même page de prestation et si le contexte sectoriel reste explicite. Dans la page « Sites industriels », présentez pourquoi cette intervention peut être pertinente, puis liez sa description. Gardez un rattachement principal stable pour le fil d’Ariane. Évitez de créer plusieurs pages identiques uniquement pour reproduire toutes les branches du menu.

Comment traiter un recrutement hébergé sur une autre plateforme ?

Conservez une entrée « Recrutement » qui explique les métiers et les modalités de candidature sur votre site. Depuis cette page, nommez le lien externe selon son usage, par exemple « Consulter les offres sur la plateforme de recrutement ». Signalez le changement de site. Vérifiez aussi le retour à votre site et la solution proposée si la plateforme devient indisponible.

Un menu généré en JavaScript est-il acceptable ?

Oui : Google indique que des liens insérés dynamiquement restent explorables lorsqu’ils utilisent le balisage attendu, notamment un élément a avec un attribut href ^[17]. Cela ne garantit ni leur indexation ni leur utilisabilité. Vérifiez leur présence dans le HTML rendu, puis testez séparément l’ouverture, la fermeture et le parcours au clavier sur la version réellement servie aux visiteurs.

Passer de l’arborescence au contrôle

Prenez une tâche prioritaire et préparez sa fiche : destination attendue, intitulé proposé, conditions de test et preuve de validation. Faites ensuite parcourir la maquette sans expliquer son classement. Corrigez le premier obstacle identifié, puis rejouez le scénario.

Pour faire examiner votre arborescence et les contraintes de sa mise en œuvre, consultez nos services web, SEO et marketing digital et échangez avec 4SYSTEM sur le périmètre de votre projet.

Sources

• Menus Tutorial | Web Accessibility Initiative (WAI) | W3C (consulté le 2026-10-08)
• SEO Link Best Practices for Google | Google Search Central  |  Documentation  |  Google for Developers (consulté le 2026-10-08)