Navigation web : pourquoi un menu n’est pas un plan du site

Navigation web : pourquoi un menu n’est pas un plan du site

Un site peut contenir des informations parfaitement organisées et rester difficile à utiliser. Le problème vient parfois moins de l’arborescence que de la manière dont elle est présentée : un menu trop long, des intitulés vagues, plusieurs niveaux qui s’ouvrent au survol ou une navigation mobile qui masque les repères essentiels.

Une interface de navigation n’a pas pour mission de montrer tout ce que contient un site. Elle doit surtout aider une personne à comprendre où elle se trouve, ce qu’elle peut faire ensuite et comment atteindre son objectif avec un effort raisonnable.

Cette distinction devient particulièrement importante pour les sites institutionnels, les extranets et les applications métier. Un menu peut accompagner l’exploration d’un contenu. Il peut aussi gêner un utilisateur qui cherche simplement à effectuer une démarche.

Commencer par le parcours, pas par le menu

Avant de dessiner une barre de navigation, il faut identifier les principales tâches des utilisateurs.

Sur un site d’entreprise, une personne peut vouloir comprendre une offre, consulter une réalisation ou demander un devis. Dans un extranet, elle peut chercher une facture, déposer un document ou suivre une demande. Dans un intranet, elle peut consulter une procédure, trouver un contact ou déclarer une absence.

Ces objectifs ne demandent pas nécessairement le même type de navigation. Une structure conçue autour des services internes de l’organisation — « Direction », « Pôle », « Ressources » — peut être logique pour l’équipe qui administre le site, sans l’être pour l’utilisateur qui cherche une information.

Le premier travail consiste donc à relier :

• les publics concernés ;
• leurs questions ou tâches principales ;
• les informations nécessaires pour réussir ;
• le chemin le plus direct vers le résultat attendu.

Cette étape peut conduire à supprimer des entrées du menu plutôt qu’à en ajouter. Les recommandations du GOV.UK Design System invitent d’ailleurs à simplifier le parcours avant d’introduire des liens de navigation.

Un menu n’est pas un inventaire exhaustif

Un menu principal n’a pas besoin de présenter toutes les pages du site. Il doit donner une représentation suffisamment claire des grandes possibilités offertes.

Ajouter une rubrique pour chaque type de contenu produit par l’organisation conduit rapidement à une navigation illisible : actualités, événements, ressources, publications, témoignages, projets, documents, partenaires, communiqués… Ces contenus peuvent être utiles sans mériter chacun une place dans le menu principal.

La navigation doit privilégier les sections qui aident réellement les utilisateurs à s’orienter ou à agir. Les contenus secondaires peuvent être accessibles depuis les pages, une recherche interne, des liens contextuels ou des regroupements éditoriaux.

Cette hiérarchie est aussi une décision de communication. Une rubrique placée dans le menu paraît importante. À l’inverse, un contenu absent de la navigation principale n’est pas forcément invisible, à condition que les autres chemins d’accès soient compréhensibles.

Distinguer exploration et réalisation d’une tâche

Tous les sites ne se naviguent pas de la même manière.

Un site éditorial ou institutionnel peut laisser l’utilisateur explorer plusieurs rubriques. Il doit alors offrir des repères stables : nom du site, catégories principales, fil d’Ariane lorsque l’arborescence est profonde, titres de pages explicites et liens cohérents.

Une application ou un service en ligne peut poursuivre un objectif plus précis. Si l’utilisateur doit accomplir une série d’étapes dans un ordre défini, un menu général n’est pas toujours la meilleure solution. Une liste de tâches, une page de démarrage ou une progression étape par étape peuvent mieux expliquer ce qui doit être fait et ce qui est déjà terminé.

Le GOV.UK Design System recommande ainsi d’éviter les liens de navigation lorsqu’un service suit un parcours de bout en bout clairement défini. Dans ce cas, une liste de tâches peut être plus utile qu’un menu qui donne l’impression que toutes les directions sont possibles.

Choisir des intitulés que les utilisateurs comprennent

Les intitulés de navigation sont des éléments d’interface, mais aussi des éléments éditoriaux. « Nos solutions » peut sembler élégant, tandis que « Services » ou « Accompagnement » sera parfois plus immédiatement compréhensible. Le bon choix dépend du vocabulaire réellement utilisé par les publics concernés.

Un intitulé doit aider à anticiper le contenu de la page suivante. Les formulations trop générales, les jeux de mots et les termes internes à l’organisation peuvent créer une hésitation au moment du clic.

Il faut également vérifier la cohérence des niveaux : une rubrique doit être formulée comme une rubrique, un lien vers une action comme une action et un lien vers une ressource comme une ressource. Mélanger « Nos métiers », « Demander un devis », « Documentation » et « Qui sommes-nous ? » n’est pas nécessairement un problème, mais cette diversité doit correspondre à une logique compréhensible.

Les titres de pages et les liens internes doivent prolonger cette clarté. Le W3C rappelle que les titres, les en-têtes et les libellés sont des mécanismes importants d’orientation, notamment pour les personnes qui naviguent avec un lecteur d’écran ou parcourent rapidement les titres d’une page.

Ne pas sacrifier les repères sur mobile

Sur mobile, le menu est souvent regroupé derrière une icône. Cette solution libère de l’espace, mais elle peut aussi faire disparaître des informations importantes : nom du service, section courante, accès au compte ou moyen de revenir en arrière.

Un menu mobile utile doit répondre à plusieurs questions :

• l’utilisateur sait-il sur quel site ou dans quel service il se trouve ?
• comprend-il que le bouton ouvre la navigation ?
• voit-il clairement la rubrique actuellement active ?
• peut-il fermer le menu sans perdre son contexte ?
• les liens sont-ils suffisamment espacés et lisibles ?
• le fonctionnement reste-t-il compréhensible au clavier ou avec une technologie d’assistance ?

La navigation ne se résume pas à l’ouverture d’un panneau. Il faut aussi prendre en compte le focus, l’ordre de lecture, les intitulés accessibles et le comportement lorsque le menu est ouvert ou fermé.

Utiliser le fil d’Ariane avec discernement

Le fil d’Ariane aide à comprendre la position d’une page dans une hiérarchie. Il est particulièrement utile pour un catalogue, une documentation, un intranet ou un site comportant plusieurs niveaux de contenu.

Il ne doit cependant pas devenir le seul moyen de se repérer. Un fil d’Ariane peu visible, construit à partir d’une arborescence administrative ou absent sur mobile peut apporter moins d’aide qu’attendu.

Il faut aussi distinguer le chemin hiérarchique du chemin réellement suivi par l’utilisateur. Une personne peut arriver directement sur une page depuis un moteur de recherche, un lien partagé ou une réponse générée par une IA. La page doit donc rester compréhensible sans supposer qu’elle a été visitée depuis la page d’accueil.

Organiser la recherche sans cacher une mauvaise navigation

Une recherche interne est utile lorsque le volume de contenus est important ou lorsque les utilisateurs connaissent les termes qu’ils recherchent. Elle ne doit pas servir à compenser une navigation incompréhensible.

Avant d’ajouter un champ de recherche, il faut vérifier :

• ce qui est réellement indexé ;
• les synonymes utilisés par les différents publics ;
• la qualité des résultats ;
• la possibilité de filtrer ou de préciser la recherche ;
• le comportement lorsqu’aucun résultat n’est trouvé.

Sur un service spécialisé, le champ doit indiquer clairement son périmètre : recherche dans les documents, dans le catalogue, dans l’espace client ou dans l’ensemble du site. Une simple loupe sans libellé peut être comprise par certains utilisateurs, mais rester ambiguë pour d’autres.

Tester la navigation avec des tâches réelles

Une navigation peut sembler évidente à l’équipe qui l’a conçue parce qu’elle connaît déjà le contenu. Les tests doivent donc partir de tâches et non d’une demande générale comme « trouvez-vous le site facile à utiliser ? ».

Demandez par exemple à une personne de :

• trouver le service adapté à sa situation ;
• retrouver une facture dans un extranet ;
• localiser une procédure interne ;
• comparer deux offres ;
• revenir à la page d’accueil du service ;
• comprendre ce qui lui reste à faire.

Observez les hésitations, les ouvertures et fermetures de menus, les retours en arrière et les termes utilisés spontanément. Une navigation peut être techniquement fonctionnelle tout en demandant trop d’efforts pour trouver une information courante.

Les tests doivent également inclure le mobile, le clavier et, lorsque cela est pertinent, une technologie d’assistance. Le W3C souligne que les personnes naviguent selon des stratégies différentes : hiérarchie des menus, recherche, titres, repères visuels ou raccourcis. Une interface robuste ne dépend pas d’un seul chemin.

Une méthode de conception en cinq étapes

Pour un nouveau site ou une refonte, la navigation peut être travaillée de manière progressive :

1. identifier les publics et leurs tâches prioritaires ;
2. regrouper les contenus selon la compréhension des utilisateurs, pas uniquement selon l’organisation interne ;
3. rédiger plusieurs variantes d’intitulés et les tester ;
4. concevoir le parcours mobile et les états d’interface dès le début ;
5. vérifier les tâches réelles avant de finaliser le design graphique.

Cette méthode évite de traiter la navigation comme un élément décoratif ajouté à la fin du webdesign. Elle relie architecture de l’information, UX, contenus et interface.

À retenir

Une bonne navigation ne montre pas tout. Elle donne les bons repères au bon moment et laisse l’utilisateur accomplir sa tâche sans lui demander de comprendre l’organisation interne de l’entreprise.

Pour un site éditorial, cela peut signifier une hiérarchie plus claire et des liens mieux nommés. Pour un intranet ou une application métier, cela peut conduire à remplacer une partie du menu par une liste de tâches ou une page de démarrage.

Le design UI intervient ensuite pour rendre cette logique visible, cohérente et utilisable sur chaque support. Le meilleur menu n’est pas celui qui contient le plus de rubriques : c’est celui qui aide les utilisateurs à savoir où aller et quoi faire ensuite.