
En résumé
Le menu organise des accès aux pages ; il ne remplace ni l’arborescence du site ni l’examen complet de son accessibilité. Ce guide relie tâches, destinations, libellés et comportements à une décision de navigation.
Choisissez le menu à partir de ce que le visiteur doit trouver, puis vérifiez des parcours précis.
Six critères structurent la décision : tâches, destinations, regroupements, libellés, comportements et preuves de vérification. Deux solutions pour un même site fictif rendent les arbitrages concrets.
Quatre scénarios éprouvent l’accès à une offre, le retour depuis une page profonde, la recherche d’une preuve et le contact. L’arborescence du site définit le rôle des pages ; le menu choisit leurs accès.
Partir de ce que le visiteur doit trouver
Un menu de navigation est un ensemble d’accès organisés vers les pages du site. Sa qualité ne dépend pas d’un nombre universel d’entrées ni d’une animation particulière. Elle se vérifie sur des tâches : trouver une offre, comprendre où l’on se situe, accéder à une preuve et atteindre le contact.
Ce guide propose six critères de décision, deux solutions commentées pour un même cas fictif et quatre scénarios reproductibles. Il ne rapporte aucun test utilisateur réalisé ni gain de conversion mesuré. Les exemples servent à préparer un choix, puis à définir ce qu’il faudra réellement vérifier.
Relier tâche et destination
Formulez la tâche avec les mots du visiteur : « savoir si cette offre répond à mon besoin » est plus utile que « consulter la rubrique Solutions ». Associez-lui une destination qui apporte effectivement la réponse. Si cette page manque, un nouveau libellé ne répare pas le contenu.
L’arborescence de site web sert à définir le rôle des pages avant le menu. Le menu sélectionne et organise des accès dans cette structure. Un user flow décrit plutôt l’enchaînement d’une tâche. Ces trois niveaux se complètent sans produire trois copies du même plan.
Donner un rôle à chaque famille de liens
Le menu principal rend accessibles les destinations importantes dans plusieurs contextes. Les liens du corps accompagnent la lecture d’une page particulière. Le pied de page peut réunir des accès de référence ou pratiques. Une page utile n’a pas forcément besoin d’apparaître partout ; son accès doit correspondre au parcours qui la rend nécessaire.
Une fiche de décision en six critères
Critère 1 — Les tâches prioritaires
Entrée : les questions et actions que le site doit servir. Décision : choisir celles que la navigation doit soutenir en premier. À consigner : une formulation de tâche et le public concerné. Ne déduisez pas une priorité du seul souhait interne de mettre une rubrique en avant.
Critère 2 — Les destinations utiles
Entrée : les pages disponibles et leur contenu. Décision : associer chaque tâche à une destination réelle, avec une suite compréhensible. À consigner : la page, sa réponse et les éventuels manques. Un lien vers une page générique peut être insuffisant pour une question précise.
Critère 3 — Les regroupements
Entrée : les relations entre offres, preuves et ressources. Décision : laisser des accès visibles ou réunir des destinations dans un groupe explicite. À consigner : la raison du regroupement et ce qu’il rend plus facile ou plus difficile. Aucun seuil de pages ne rend automatiquement un méga-menu nécessaire.
Critère 4 — Les libellés
Entrée : les mots que les publics comprennent pour décrire leur besoin. Décision : choisir des intitulés qui annoncent honnêtement la destination. À consigner : le libellé, son sens et une éventuelle ambiguïté à vérifier. Renommer toutes les pages « Solutions » n’explique pas ce qu’elles contiennent.
Critère 5 — Les comportements
Entrée : les écrans, commandes et contextes d’usage à prendre en charge. Décision : distinguer lien vers une page, bouton d’ouverture, fermeture du panneau et indication de page courante. À consigner : ce que chaque commande fait et ce qui se passe au clavier, sur petit écran et avec un libellé long.
Critère 6 — La preuve de vérification
Entrée : la solution proposée et les tâches retenues. Décision : définir un attendu observable et les conditions de vérification. À consigner : version, scénario, observation, défaut ou réserve et responsable. Un dessin validé peut approuver une intention ; il ne prouve pas le comportement du site intégré.
Choisir une forme de menu selon le contexte
Une navigation visible et simple peut rendre les destinations directement lisibles. Un regroupement avec ouverture peut mieux présenter des offres liées, au prix d’un comportement supplémentaire à comprendre et à tester. Une recherche peut compléter les accès d’un corpus important ; elle ne remplace pas une organisation utile. Le choix dépend du contenu et des tâches, pas d’un catalogue de marques présenté comme audit actuel.
Ce qu’un menu caché ou animé ajoute au projet
Une ouverture doit être identifiable, utilisable et réversible. Une animation ne doit pas être le seul indice de l’état ou empêcher l’accès au contenu. Les états ouvert, fermé et page courante doivent rester compréhensibles. Un menu fixe peut aider à garder un accès, mais sa place doit être vérifiée sur les petits écrans et les pages longues.
Un lien et un bouton d’ouverture ont des rôles différents
Un lien mène à une destination ; un bouton peut afficher des options. Si une rubrique doit à la fois présenter une page et ouvrir un groupe, rendez ces deux actions distinctes et compréhensibles. Ne présumez pas qu’un comportement au survol sera utilisable au clavier ou sur écran tactile.
L’exemple W3C de navigation à divulgation distingue une navigation de site ordinaire du rôle ARIA « menu ». Ce rôle ne doit pas être ajouté par simple ressemblance visuelle. Son exemple de code est pédagogique : il ne certifie pas votre composant et n’est pas un code prêt à reprendre sans vérification.
Deux solutions pour le même site fictif
Noro Conseil est une entreprise entièrement fictive. Elle présente trois offres — Diagnostic, Accompagnement et Formation — ainsi que des réalisations autorisées, des ressources et un contact. Deux publics sont retenus dans ce cas : une personne qui décide du périmètre et une personne métier qui cherche les conditions d’application. Aucun comportement réel de ces publics n’est déclaré observé.
Solution A — Des destinations directement visibles
Tâches : comprendre une offre, examiner une réalisation puis contacter. Destinations : les trois pages d’offre, Réalisations, Ressources et Contact. Regroupements : aucune ouverture intermédiaire pour les offres dans la présentation large proposée.
Libellés : Diagnostic, Accompagnement, Formation, Réalisations, Ressources, Contact. Ils privilégient la destination, sous réserve que ces mots soient compris. Comportements : chaque entrée est un lien ; la page courante est indiquée par un signal identifiable au-delà de la couleur seule. Sur petit écran, les mêmes destinations restent accessibles dans une présentation à vérifier.
Preuve prévue : les quatre scénarios ci-dessous. Arbitrage : accès direct aux offres, mais davantage de libellés visibles et un risque de manque de place avec des intitulés longs. Responsable : la personne chargée du contenu valide les mots ; l’intégrateur vérifie les états et la disposition. Statut : proposition non testée.
Solution B — Un groupe d’offres explicite
Tâches : identiques à la solution A. Destinations : les mêmes trois offres, Réalisations, Ressources et Contact. Regroupements : un bouton « Nos offres » ouvre les liens Diagnostic, Accompagnement et Formation ; les autres accès restent distincts.
Libellés : Nos offres pour la commande ; noms d’offres pour les liens internes au groupe. Comportements : l’ouverture et la fermeture doivent fonctionner avec les commandes retenues, l’état doit être perceptible et le contenu rester atteignable. Si une page d’ensemble des offres est nécessaire, elle possède un lien identifiable, au lieu de donner deux effets ambigus au même contrôle.
Preuve prévue : les mêmes quatre scénarios, avec vérification de l’ouverture et de la sortie du groupe. Arbitrage : le regroupement explicite la famille des offres, mais ajoute une action et un risque d’options ignorées. Responsable : les mêmes rôles que pour A. Statut : proposition non testée.
Décision provisoire pour ce cas
Pour ce périmètre fictif, retenir A comme première proposition si les libellés restent lisibles et permettent de comprendre les offres. Choisir B si un regroupement aide réellement à les comparer et si son comportement est vérifié. Cette préférence repose sur le cas décrit, pas sur une règle de nombre d’entrées. Si les deux échouent sur une tâche, réexaminer les libellés ou les destinations avant de choisir une animation différente.
Quatre scénarios reproductibles
Utilisez la même version du site et les mêmes tâches pour comparer les solutions. Notez les dimensions réellement affichées et le mode de commande. Les observations ci-dessous sont à produire pendant vos contrôles ; aucun résultat n’est prérempli comme succès.
Scénario 1 — Trouver l’offre adaptée depuis l’accueil
Précondition : partir de l’accueil, sans panneau ouvert. Étapes : chercher l’offre qui décrit un diagnostic, ouvrir sa destination puis retrouver son périmètre. Pour B, ouvrir d’abord le groupe et choisir son lien. Attendu : le libellé conduit à la page prévue et son contenu permet d’identifier ce qui est proposé. À relever : version, libellés hésitants, mauvais choix ou absence de contenu. Limite : la réussite du contrôleur ne mesure pas la compréhension de tous les acheteurs.
Scénario 2 — Se repérer depuis une page profonde
Précondition : entrer directement sur une ressource. Étapes : identifier la page courante, retrouver les offres puis revenir à la ressource par un parcours compréhensible. Refaire la tâche au clavier. Attendu : position et accès restent identifiables ; aucun contrôle ne devient inaccessible ou ne retient involontairement la navigation. À relever : commande utilisée, état courant et perte de repère. Limite : ce scénario ne constitue pas un audit complet d’accessibilité.
Scénario 3 — Rejoindre une preuve utile sur petit écran
Précondition : ouvrir la page Accompagnement avec un écran étroit et les contenus les plus longs prévus. Étapes : ouvrir la navigation si nécessaire, rejoindre Réalisations, puis retrouver l’offre. Vérifier fermeture, défilement et visibilité des liens. Attendu : les destinations restent atteignables, sans texte coupé ni chevauchement qui empêche l’action. À relever : largeur réelle, libellé, état du panneau et anomalie. Limite : une largeur contrôlée ne couvre pas tous les appareils et contenus.
Scénario 4 — Atteindre le contact après une preuve
Précondition : partir d’une réalisation autorisée. Étapes : chercher le contact avec le menu ou le lien contextuel prévu, puis identifier l’action attendue sur la page d’arrivée. Ne soumettre aucun formulaire sans autorisation de test. Attendu : la destination est correcte et la suite compréhensible ; réception du formulaire non testée par ce seul scénario. À relever : ancre, destination, hésitation et contrôle restant. Limite : atteindre Contact ne prouve ni envoi ni conversion.
Après ces parcours, documenter les conditions d’acceptation permet de conserver les écarts et les réserves. Pour vérifier les parcours au clavier et leurs limites dans un périmètre plus large, utilisez le guide spécialisé ; ne déduisez pas une conformité générale de quatre scénarios.
Conserver des destinations découvrables et une décision claire
Des liens descriptifs vers les bonnes pages aident les personnes et les moteurs à parcourir le site. Ne remplacez pas systématiquement les liens de destination par des actions sans adresse. Évitez l’accumulation artificielle de mots-clés et vérifiez les liens sur la version réellement publiée. La place d’une page dans un menu ne garantit ni son indexation ni une position Google.
Le choix final doit conserver les six critères, les raisons de l’arbitrage et les résultats réellement obtenus. Un défaut de composant, un libellé mal compris et une page de destination insuffisante n’appellent pas la même correction. L’implémentation détaillée d’un panneau relève d’un autre travail ; le guide du menu burger complète cette décision sans la remplacer.
Si le besoin dépasse le composant et concerne les offres, les preuves et la remise du projet, Gemme Studio peut vous aider à cadrer un site B2B et ses parcours. Les contenus et contraintes permettent de décider du périmètre ; aucun changement du menu n’assure à lui seul un gain commercial.
Sources et portée
La checklist de conception des menus de NN/G éclaire la lisibilité et le repérage. L’exemple de navigation à divulgation du W3C précise les limites de son pattern. Ces sources ont été consultées le 20 octobre 2026. La fiche en six critères, le cas Noro et ses scénarios sont développés ici ; ils ne reproduisent pas une mesure ni une certification de ces organismes.

FAISONS DE VOTRE SITE UNE GEMME
Parlons de votre projet. Si votre site ne reflète plus votre niveau d’exigence, votre offre ou vos objectifs SEO et conversion, c’est probablement le bon moment pour le reprendre sérieusement.



.avif)
.avif)
