Quand je travaille sur la navigation d’un site, je rencontre souvent la même demande : « Voici toutes les pages, il faut les mettre dans le menu. »
Le problème apparaît vite.
Un menu n’a pas vocation à reproduire toute l’arborescence. Il doit aider quelqu’un qui ne connaît pas encore le site à comprendre où chercher.
Sur un site de cinquante pages, afficher cinquante liens n’améliore pas l’accès à l’information. À l’inverse, réduire la navigation à quatre intitulés très vagues peut rendre le site tout aussi difficile à utiliser.
Il faut donc faire des choix : ce qui reste au premier niveau, ce qui passe dans un sous-menu, ce qui mérite une page d’orientation, ce qui peut être retrouvé par la recherche, le footer ou des liens contextuels.
Je considère le menu comme un système d’orientation, pas comme l’inventaire du site.
Organiser la navigation autour des besoins, pas de l’organigramme
L’organisation interne d’une entreprise n’est pas toujours compréhensible depuis l’extérieur.
Je rencontre par exemple des structures qui veulent afficher dans leur menu :
Direction conseil | Transformation | Opérations | Studio digital | Expertise
Ces termes ont du sens pour les équipes. Un prospect qui cherche à refaire son site ou à réaliser un audit SEO ne sait pas forcément dans quelle rubrique commencer.
Je préfère partir des intentions réelles.
La personne cherche-t-elle une prestation ? Un tarif ? Une référence ? Une documentation ? Un interlocuteur ?
Le menu peut alors utiliser des catégories que l’utilisateur est capable d’identifier sans connaître le fonctionnement de l’entreprise.
On retrouve la même logique dans le parcours utilisateur : l’interface doit partir de la tâche à accomplir.
Choisir des libellés que l’utilisateur peut comprendre
La navigation n’est pas toujours le meilleur endroit pour faire preuve d’originalité éditoriale.
« Nos super-pouvoirs » peut remplacer « Services ». « Nos aventures » peut remplacer « Réalisations ». Cela fonctionne parfois très bien dans un univers de marque assumé.
Mais le bénéfice disparaît dès que l’utilisateur hésite sur la destination.
Je préfère souvent garder des libellés simples dans le menu et exprimer davantage la personnalité de la marque dans les titres, les visuels, les animations ou le ton rédactionnel des pages.
Il y a une différence entre un intitulé original et un intitulé ambigu.
Réalisations indique immédiatement ce que je vais trouver.
Nos histoires peut désigner des projets, des actualités, l’histoire de l’entreprise ou des témoignages clients.
Si je dois cliquer pour comprendre le mot, le libellé ne fait plus correctement son travail.
Un lien doit laisser deviner sa destination
Le Nielsen Norman Group utilise le concept d’information scent pour décrire les indices qui permettent à l’utilisateur d’estimer ce qu’il trouvera après un clic.
Le texte du lien participe directement à cette estimation.
« Découvrir nos prestations UX/UI » donne beaucoup plus d’informations que « En savoir plus » lorsque le lien est lu hors de son contexte.
Dans un menu, le même principe s’applique.
« Solutions » peut être parfaitement clair si ce vocabulaire est celui des utilisateurs du service. Sur un autre site, il peut être trop générique et se confondre avec « Services », « Offres » ou « Expertise ».
Le Nielsen Norman Group détaille cette notion dans Information Scent: How Users Decide Where to Go Next.
Pour tester un libellé, je me pose une question :
Une personne qui découvre le site peut-elle anticiper raisonnablement ce qu’elle trouvera derrière ce lien ?
Déterminer ce qui mérite le premier niveau
Je ne travaille pas avec un nombre fixe d’entrées de menu.
Cinq intitulés peuvent déjà être trop nombreux s’ils sont difficiles à distinguer :
Services | Solutions | Expertise | Conseil | Accompagnement
À l’inverse, sept rubriques très différentes peuvent être parcourues rapidement :
Formations | Logiciels | Tarifs | Ressources | Support | Agence | Contact
Je regarde surtout trois choses : la différence entre les catégories, leur importance et la fréquence probable d’accès.
Une rubrique secondaire peut passer ailleurs.
« Presse », par exemple, n’a pas forcément besoin d’occuper le même niveau que « Produits » ou « Tarifs ». Elle peut rester dans le footer ou dans une rubrique « Entreprise ».
Limiter la profondeur sans aplatir toute l’arborescence
Une navigation comme :
Services → Digital → Acquisition → Référencement → SEO technique
peut parfaitement correspondre à l’arborescence.
La reproduire intégralement dans une série de sous-menus est beaucoup moins confortable.
Je préfère souvent arrêter la navigation plus tôt et utiliser les pages parents pour orienter la suite.
Une page « SEO » peut présenter clairement :
- Audit SEO ;
- SEO technique ;
- Stratégie éditoriale ;
- Netlinking ;
- Accompagnement SEO.
Cette page devient un carrefour.
L’utilisateur voit les différentes possibilités sans devoir maintenir cinq niveaux de menu ouverts.
Gérer correctement les rubriques parentes
Une rubrique comme « Services » peut remplir deux fonctions : ouvrir un sous-menu et mener vers une page générale.
Il faut éviter que ces deux actions deviennent ambiguës.
Une solution consiste à rendre le libellé « Services » cliquable et à réserver une flèche séparée à l’ouverture du sous-menu.
Une autre consiste à faire de « Services » uniquement un déclencheur et à placer « Tous nos services » en première position du sous-menu.
Je préfère la solution qui reste la plus facile à comprendre sur desktop, au clavier et sur tactile.
Ce que j’évite, c’est un composant dont le comportement dépend d’une zone minuscule ou d’une différence visuelle à peine perceptible.
Indiquer où se trouve l’utilisateur
Une fois arrivé dans « Réalisations », l’utilisateur peut voir cette rubrique signalée comme active dans le menu.
Ce repère paraît discret, mais il aide à comprendre la structure du site.
Le W3C recommande d’identifier la page courante dans la navigation et présente notamment l’utilisation de aria-current="page" dans son tutoriel sur la structure des menus.
L’état actif peut utiliser un fond, une couleur, un soulignement ou un changement de graisse.
Je vérifie simplement qu’il reste perceptible sans obliger l’utilisateur à comparer les liens un par un.
Le fil d’Ariane sur les sites réellement hiérarchiques
Un fil d’Ariane devient utile lorsqu’une page appartient à plusieurs niveaux clairement identifiables.
Par exemple :
Accueil → Ressources → Guides → Accessibilité web
L’utilisateur voit où se situe le contenu et peut remonter directement d’un niveau.
Le GOV.UK Design System recommande ce composant lorsqu’il aide réellement à comprendre et parcourir une hiérarchie.
Je ne vois en revanche que peu d’intérêt à afficher :
Accueil → Contact
sur un site constitué de cinq pages principales.
Le composant doit résoudre un problème de profondeur. Il n’est pas obligatoire simplement parce qu’il existe dans beaucoup de design systems.
Recherche et navigation ne remplissent pas le même rôle
La recherche est très efficace lorsque l’utilisateur sait déjà ce qu’il veut.
Quelqu’un qui cherche « facture avril 2026 » dans un espace client ou « chaussures trail imperméables » dans une boutique peut gagner beaucoup de temps.
La navigation sert davantage à explorer.
Une personne qui ne connaît pas encore les prestations proposées par une entreprise ne saura pas forcément quoi taper dans un moteur.
C’est pourquoi je ne considère pas la recherche comme un correctif à une architecture confuse.
Sur les sites volumineux, les deux systèmes fonctionnent très bien ensemble.
Séparer navigation principale et actions utilitaires
Tous les éléments d’un header n’ont pas la même fonction.
Je peux avoir une navigation principale :
Services | Réalisations | Agence | Ressources
et, plus discrètement :
Connexion | Aide | FR / EN
Le bouton « Contact » peut encore avoir un traitement spécifique.
Cette organisation évite de mettre au même niveau une page de présentation, un changement de langue et une action commerciale.
Elle devient particulièrement utile sur les applications, plateformes SaaS et sites multilingues.
Le menu hamburger en 2026
L’icône hamburger est aujourd’hui beaucoup plus familière qu’elle ne l’était au début des interfaces mobiles.
Le Nielsen Norman Group a réévalué sa reconnaissance en 2025 et constate que le symbole est largement identifié comme un accès au menu. Il maintient néanmoins une recommandation importante : lorsqu’il y a suffisamment de place, une navigation visible reste plus facile à découvrir.
Voir : Nielsen Norman Group – The Hamburger-Menu Icon Today: Is it Recognizable?.
Sur mobile, j’utilise donc le hamburger sans difficulté lorsqu’il permet de gérer plusieurs rubriques.
Sur desktop, cacher cinq liens qui pourraient tenir sans problème dans le header me paraît beaucoup moins intéressant.
On ajoute alors un clic sans gagner réellement d’espace utile.
Ce qui doit rester visible sur mobile
Le passage au mobile ne devrait pas consister à mettre tout le header derrière un hamburger.
Une action suffisamment importante peut rester visible.
Un restaurant peut afficher :
Logo | Réserver | Menu
Un e-commerce :
Logo | Recherche | Panier | Menu
La logique dépend du service, pas d’un modèle universel.
Je vérifie également ce que deviennent les niveaux de navigation. Un mega menu de quatre colonnes doit être repensé. Sur téléphone, une progression par niveaux avec un bouton de retour explicite fonctionne souvent mieux.
J’aborde plus largement ces arbitrages dans l’article consacré à l’UX mobile.
Garder les mêmes repères d’une page à l’autre
Une navigation devient plus facile à utiliser au fur et à mesure que l’utilisateur apprend sa structure.
Si le menu change d’ordre sans raison entre deux pages, cet apprentissage disparaît.
WCAG 2.2 demande que les mécanismes de navigation répétés apparaissent dans le même ordre relatif lorsqu’ils sont présents sur plusieurs pages, sauf changement provoqué par l’utilisateur.
Voir : W3C – Consistent Navigation.
Il existe des exceptions légitimes.
Un tunnel de commande peut supprimer une partie de la navigation pour éviter les sorties accidentelles. Une landing page de campagne peut avoir un header simplifié.
Mais le menu principal du site ne devrait pas changer arbitrairement selon les pages.
Prévoir plusieurs chemins vers les contenus importants
Un utilisateur peut atteindre une même page depuis le menu, un lien dans le contenu, le moteur de recherche ou le footer.
C’est souhaitable.
Le critère WCAG 2.4.5 « Multiple Ways » demande, pour un ensemble de pages et hors certaines étapes d’un processus, plus d’un moyen permettant de localiser une page.
Voir : W3C – Multiple Ways.
Sur une page dédiée à l’UX, un lien vers « Audit UX » peut apparaître naturellement dans le contenu.
Obliger l’utilisateur à revenir systématiquement au menu pour continuer son parcours serait inutile.
Rédiger des liens explicites
« En savoir plus » n’est pas interdit.
Mais quinze liens « En savoir plus » dans une même page rendent les destinations difficiles à distinguer.
Lorsque c’est pertinent, je préfère :
Découvrir notre méthode UX/UI
ou :
Voir les réalisations e-commerce
Le W3C demande que le but du lien puisse être déterminé à partir de son texte ou de son contexte dans le critère Link Purpose (In Context).
Dans une carte où le titre du contenu est immédiatement associé au lien, « En savoir plus » peut rester compréhensible. Je regarde donc le composant entier, pas seulement deux mots isolés.
Navigation clavier, focus et menus déroulants
Je teste systématiquement le menu sans souris.
Avec la touche Tab, je dois pouvoir atteindre chaque élément interactif dans un ordre logique. Le focus doit rester visible. Les sous-menus doivent pouvoir être ouverts puis refermés.
Ces vérifications font apparaître des problèmes invisibles dans la maquette.
Un menu au hover peut par exemple sembler très fluide à la souris alors qu’aucun mécanisme n’a été prévu pour l’ouvrir au clavier.
WCAG 2.2 précise notamment les exigences liées au focus visible.
Le W3C propose également un tutoriel complet sur les menus accessibles.
Exemple : revoir le menu d’un site B2B
Prenons cette navigation :
Accueil | Le groupe | Nos activités | Nos expertises | Nos solutions | Nos offres | Secteurs | Innovations | Ressources | Actualités | Carrières | Contact
Douze entrées ne constituent pas à elles seules le problème.
Ce qui m’interpelle surtout, ce sont « Activités », « Expertises », « Solutions » et « Offres ». Un nouveau visiteur peut difficilement anticiper ce qui différencie ces quatre rubriques.
En examinant les contenus, on peut découvrir que « Activités » et « Solutions » présentent en grande partie les mêmes services, que les expertises peuvent être intégrées dans ces pages et que « Innovations » ne contient que quelques publications.
Une nouvelle navigation pourrait devenir :
Solutions | Secteurs | Réalisations | Ressources | L’entreprise | Contact
Chaque entrée répond alors à une question plus nette :
Solutions : qu’est-ce que vous proposez ?
Secteurs : connaissez-vous mon domaine ?
Réalisations : qu’avez-vous déjà fait ?
Ressources : où puis-je approfondir le sujet ?
L’entreprise : qui êtes-vous ?
La simplification vient surtout de la suppression des ambiguïtés.
Exemple : navigation d’un catalogue e-commerce
Un catalogue de plusieurs milliers de produits doit permettre deux comportements très différents.
Le premier utilisateur sait exactement ce qu’il cherche. Il utilise volontiers la recherche.
Le second explore.
Pour une boutique de décoration, le premier niveau peut rester assez simple :
Meubles | Luminaires | Décoration | Textile | Outdoor
Chaque rubrique ouvre ensuite des catégories plus précises.
La recherche reste visible pour quelqu’un qui veut directement une « lampe champignon orange ».
Sur une page catégorie, les filtres prennent ensuite le relais pour réduire la sélection. Le fil d’Ariane aide à remonter dans la hiérarchie.
Menu, recherche, filtres et fil d’Ariane ont donc quatre fonctions différentes. Les réunir dans un seul composant rendrait l’interface moins lisible.
Les erreurs que je rencontre le plus souvent
Reproduire l’organisation interne
Les noms des pôles et départements ne correspondent pas forcément au vocabulaire des clients.
Créer plusieurs rubriques presque synonymes
« Services », « Solutions », « Offres » et « Expertises » demandent un effort inutile lorsqu’ils recouvrent des contenus proches.
Donner des noms trop créatifs aux rubriques
Une identité originale peut parfaitement utiliser un menu explicite.
Mettre toutes les pages dans le header
Une page peut rester accessible par d’autres chemins.
Multiplier les niveaux déroulants
Au-delà d’un certain point, une page d’orientation devient plus pratique.
Cacher inutilement la navigation desktop
Un hamburger n’apporte pas grand-chose lorsque tous les liens principaux tiennent déjà à l’écran.
Oublier d’indiquer la rubrique active
Le menu sert aussi à dire où l’on se trouve.
Concevoir uniquement à la souris
Hover, clavier et tactile doivent être traités dès le départ.
Compter sur la recherche pour réparer une architecture confuse
Un utilisateur qui ne connaît pas le vocabulaire du site ne saura pas forcément quoi saisir.
Tester le menu uniquement avec l’équipe projet
Les personnes qui connaissent déjà l’arborescence comprennent des libellés que les nouveaux utilisateurs trouvent parfois opaques.
Ma méthode pour concevoir une navigation
Je commence par les contenus et les principales tâches. Je veux savoir ce que le site contient et ce que les utilisateurs viennent y faire avant de dessiner le header.
Regrouper les contenus
Je cherche les catégories qui font sens du point de vue de l’utilisateur. Sur les sites volumineux, un tri de cartes peut aider à identifier les regroupements naturels.
Nommer les rubriques
Je travaille ensuite les libellés. Deux catégories qui nécessitent une longue explication pour être distinguées méritent probablement d’être retravaillées.
Définir le premier niveau
Je garde les grandes directions. Les pages plus spécifiques descendent dans la structure ou sont reliées depuis des pages parents.
Prévoir les autres moyens de navigation
Recherche, footer, fil d’Ariane et liens contextuels prennent en charge les besoins que le menu principal n’a pas à résoudre seul.
Travailler desktop et mobile ensemble
Je vérifie assez tôt quelles actions restent visibles et comment les sous-niveaux se transforment sur petit écran.
Passer par le wireframe
Le wireframe permet de tester cette structure avant que les couleurs, images et détails UI ne prennent trop de place dans la discussion.
Tester au clavier
Une navigation qui fonctionne uniquement à la souris n’est pas terminée.
Tester les mots
Je donne quelques tâches à des personnes qui ne connaissent pas l’arborescence.
Le plus intéressant n’est pas toujours le taux de réussite. Une hésitation répétée entre deux rubriques signale souvent un problème de classement ou de vocabulaire.
Ce travail fait partie de notre approche de conception UX/UI chez TooNetCreation.
Tester les libellés et les parcours avant le développement
Un test de navigation peut rester très simple.
Je présente le menu puis je donne quelques tâches :
- trouver des exemples de projets réalisés pour des collectivités ;
- chercher le prix d’une offre ;
- se connecter à son compte ;
- vérifier si l’entreprise travaille pour le secteur de la santé ;
- trouver une documentation technique.
Je regarde d’abord le premier clic.
Si la personne hésite entre « Solutions » et « Services », je lui demande ce qu’elle s’attend à trouver dans chaque rubrique.
La réponse donne souvent plus d’informations que le clic final.
Sur un prototype fonctionnel, je peux ensuite observer les retours en arrière, les entrées jamais utilisées, la manipulation des sous-menus et le comportement sur mobile.
Auditer rapidement la navigation d’un site existant
Je commence par oublier ce que je sais du site.
Je regarde le premier niveau et j’essaie de prévoir le contenu de chaque rubrique uniquement à partir de son nom.
Les zones d’ambiguïté apparaissent assez vite.
Je vérifie ensuite quelques tâches importantes : trouver une prestation, une réalisation, un tarif, une ressource et le contact.
Je regarde le nombre de niveaux nécessaires et les moments où je dois revenir en arrière.
Sur mobile, je vérifie si l’action principale reste accessible et si les sous-menus sont simples à parcourir.
Enfin, je fais un passage au clavier.
Un audit de vingt minutes ne remplace évidemment pas des tests utilisateurs, mais il suffit souvent à identifier des problèmes assez concrets pour commencer à retravailler la navigation.
FAQ sur la navigation UX
Combien d’entrées faut-il mettre dans un menu principal ?
Il n’existe pas de nombre idéal valable pour tous les sites. Des catégories clairement distinctes comptent davantage qu’une limite arbitraire de cinq ou sept entrées.
Faut-il mettre toutes les pages dans le menu ?
Non. Le menu principal montre les grandes directions. Les autres pages peuvent être accessibles depuis les pages parents, le footer, la recherche ou des liens contextuels.
Quand utiliser un mega menu ?
Il devient intéressant lorsqu’une rubrique contient suffisamment de sous-catégories pour qu’une liste déroulante classique soit difficile à parcourir. Sur un site simple, il est généralement inutile.
Le menu hamburger est-il mauvais pour l’UX ?
Non. Il est aujourd’hui bien identifié sur mobile. Il reste moins visible qu’une navigation affichée directement, raison pour laquelle certaines actions prioritaires peuvent rester hors du menu.
Faut-il écrire « Menu » à côté de l’icône hamburger ?
Ce n’est pas obligatoire, mais le libellé peut renforcer la compréhension pour des publics très larges ou peu familiers des interfaces numériques.
À quoi sert le fil d’Ariane ?
Il indique la position d’une page dans une structure hiérarchique et permet de remonter vers les niveaux parents. Son intérêt augmente avec la profondeur du site.
La recherche peut-elle remplacer le menu ?
Rarement. Elle fonctionne surtout lorsque l’utilisateur connaît déjà l’information ou le produit recherché. Le menu sert également à découvrir ce que le site propose.
Quelle différence entre arborescence et navigation ?
L’arborescence décrit la structure complète du site. La navigation regroupe les différents moyens utilisés pour s’y déplacer : menu, recherche, fil d’Ariane, footer ou liens contextuels.
Comment tester les noms des rubriques ?
Il faut les confronter à des utilisateurs qui ne connaissent pas l’organisation interne du site. Des tâches simples ou un tri de cartes font rapidement apparaître les intitulés ambigus.
Sources et ressources
- W3C – Menus Tutorial : structure et fonctionnement des menus accessibles.
- W3C – Menu Structure : structure sémantique et identification de la page active.
- W3C – Fly-out Menus : comportement des sous-menus à la souris et au clavier.
- W3C – Consistent Navigation : cohérence des mécanismes de navigation répétés.
- W3C – Multiple Ways : plusieurs moyens pour localiser les pages d’un site.
- W3C – Link Purpose (In Context) : compréhension de la destination des liens.
- W3C – Focus Visible : visibilité du focus lors de la navigation au clavier.
- Nielsen Norman Group – Information Scent : indices utilisés pour anticiper le contenu d’un lien.
- Nielsen Norman Group – The Hamburger-Menu Icon Today: Is it Recognizable? : reconnaissance actuelle de l’icône hamburger et limites de la navigation cachée.
- GOV.UK Design System – Breadcrumbs : usage du fil d’Ariane dans les structures hiérarchiques.
À lire également sur TooNetCreation
- UX et UI : quelles différences et pourquoi les deux sont indispensables à un site web ?
- Qu’est-ce qu’un wireframe ? Définition, utilité et méthode pour concevoir un site web
- Hiérarchie visuelle : comment organiser une page web pour guider l’utilisateur ?
- Comment construire un parcours utilisateur efficace sur un site web ?
- UX des formulaires web : comment réduire les frictions et les abandons ?
- UX mobile : pourquoi adapter l’expérience et pas seulement réduire la maquette ?
- Pourquoi l’arborescence est un pilier du SEO et de l’expérience utilisateur
- Conception UX/UI et expérience utilisateur
