Patterns de Navigation : 9 Mises en Page de Menu pour le Web et le Mobile
Neuf patterns de navigation que tout designer doit connaître, de la barre supérieure à la palette de commandes, avec de vrais exemples et un avis tranché sur quand utiliser chacun.

Patterns de Navigation : 9 Mises en Page de Menu pour le Web et le Mobile
La navigation n'est pas un menu. C'est une promesse sur l'endroit où les choses se trouvent. Quand elle fonctionne, les utilisateurs se déplacent dans un produit sans y penser. Quand elle échoue, ils partent.
Les utilisateurs ne lisent pas la navigation. Ils la parcourent du regard, lui font confiance, et ne la remarquent que quand elle faillit.
C'est là le vrai problème de design. La navigation n'est pas une fonctionnalité à célébrer, c'est une infrastructure à rendre invisible. Choisir le mauvais pattern pour votre architecture d'information ou pour le contexte de vos utilisateurs déclenche une réaction en chaîne : les gens ne trouvent plus les sections, ne s'orientent plus, et ne construisent jamais de modèle mental de votre produit.
Neuf patterns couvrent presque tous les cas. Ce qui suit est un décryptage direct de chacun : ce qu'il fait bien, où il casse, et quand y recourir.
À quoi sert vraiment la navigation
La navigation répond à une seule question pour l'utilisateur : où puis-je aller d'ici ? Répondez clairement et il avance. Forcez-le à chercher et il part.
Le rôle structurel de la navigation est de représenter votre architecture d'information comme un système auquel les utilisateurs peuvent faire confiance. Cela implique cohérence, stabilité et reflet honnête de ce qui se trouve réellement dans le produit. Une navigation qui change entre les pages, affiche des libellés différents des URL, ou enfouit les chemins principaux sous des secondaires est un échec de design, peu importe la finesse de l'animation du dropdown. Amazon conserve exactement la même navigation principale sur chaque page, à travers des centaines de millions de produits, précisément pour cette raison.
L'implication pratique : vous choisissez un pattern de navigation en fonction de deux paramètres. La profondeur et la largeur de votre IA, et le contexte dans lequel les gens utilisent le produit. Tout le reste, style visuel, animation, couleur, découle de ces deux décisions.
La barre de navigation supérieure
La barre supérieure horizontale est le standard du web pour une bonne raison. À l'échelle desktop, elle accueille environ cinq à sept sections principales dans l'en-tête, les maintient visibles en permanence, et reflète la façon dont on lit : de gauche à droite, de haut en bas.

Neon (neon.tech) en donne un exemple parfaitement propre. Logotype à gauche, liens de navigation principaux au centre, connexion et un bouton CTA à droite. Rien de caché, rien d'imbriqué, aucune charge cognitive. Dans sa meilleure version, une barre supérieure raconte toute la structure d'un site en une seule ligne sans nécessiter la moindre interaction.
L'échec vient du bourrage. Une barre supérieure avec neuf liens, deux dropdowns, un menu utilitaire et une icône de recherche n'est pas un pattern de navigation, c'est une crise de panique. Le pattern a un plafond dur d'environ six ou sept éléments avant de nécessiter une restructuration.
Les barres supérieures exigent aussi un fallback mobile planifié. Sur les petits écrans, la mise en page horizontale n'a nulle part où aller. Si vous ne décidez pas de l'expérience petits viewports au moment du design, vous vous retrouverez à coller un menu hamburger en pièce rapportée, ce qui introduit de nouveaux problèmes.
Le menu hamburger
Le menu hamburger (trois lignes empilées, ouvre un drawer ou une superposition au tap) cache la navigation derrière une interaction supplémentaire. Il économise de l'espace écran. Il rend aussi chaque section de votre produit moins découvrable.
La recherche sur ce sujet n'est pas ambiguë. NNGroup a constaté que la navigation par onglets sur mobile surpasse systématiquement les menus hamburger en termes de découvrabilité et de taux de complétion des tâches. Quand vous cachez la navigation, les gens l'utilisent moins. Les éléments derrière le hamburger sont perçus comme moins prioritaires, parce que visuellement, ils le sont.
Cela ne rend pas le hamburger mauvais. Cela en fait un compromis. Pour les sites avec des sections profondes et rarement consultées, le compromis est acceptable. Pour les apps que les gens ouvrent quotidiennement, c'est généralement une erreur.
Instagram a essayé de placer la navigation principale derrière un hamburger, puis a fait marche arrière en déplaçant les sections principales vers une barre d'onglets en bas. La leçon est claire : utilisez un hamburger pour les chemins secondaires, les paramètres et les destinations peu fréquentes. Ne l'utilisez jamais pour les actions qui définissent pourquoi quelqu'un a ouvert le produit.
La sidebar persistante
Une sidebar persistante épingle une colonne de navigation complète à gauche de l'écran et reste visible pendant que l'utilisateur fait défiler le contenu. C'est le pattern dominant pour les dashboards, les outils de design et la documentation approfondie, parce que la permanence spatiale est précisément la fonctionnalité.

La documentation de Tailwind CSS l'utilise exactement comme il faut. La sidebar gauche contient chaque section de la documentation, groupée et défilable, tandis que le contenu occupe la largeur restante. Les utilisateurs savent toujours où ils sont, où ils peuvent aller, et comment l'espace d'information complet est organisé. Cette conscience spatiale est tout l'intérêt dans un matériau de référence approfondi où les gens sautent constamment d'une section à l'autre.
Slack, Notion et Figma utilisent tous des sidebars persistantes à l'échelle applicative pour la même raison. La sidebar est la carte. La supprimer obligerait les utilisateurs à reconstruire ce modèle mental à chaque action de navigation, un coût qu'ils ne devraient pas avoir à payer.
Le coût est l'espace horizontal. Sur un ordinateur portable de 13 pouces, une sidebar persistante utilise 250 à 300 pixels de votre zone de contenu. Sur mobile, il n'y a tout simplement pas de place.
Les sidebars responsives se replient en drawer ou hamburger sur les petits écrans, réintroduisant les mêmes problèmes de découvrabilité que vous cherchiez à éviter. Connectez-la aux tokens qui maintiennent une nav cohérente dès le départ, ou vous la corrègerez plus tard.
La barre d'onglets en bas
La barre d'onglets en bas ancre trois à cinq icônes en bas d'un écran mobile, directement dans la zone du pouce. C'est le standard pour les apps mobiles natives et, depuis 2026, le défaut pour tout produit web que les gens ouvrent quotidiennement sur leur téléphone.

Instagram, Spotify et YouTube utilisent tous ce pattern pour leur navigation mobile principale. Ce ne sont pas des coïncidences. La barre en bas existe parce que le haut d'un écran de téléphone est la zone la plus difficile à atteindre avec un pouce, et la navigation est tapée en permanence. Déplacer les destinations principales vers le bas réduit l'effort physique d'une façon qui se cumule sur des milliers de sessions quotidiennes.
Cinq éléments est le plafond dur. Au-delà, les icônes rétrécissent et les libellés sont tronqués. Si votre produit a plus de cinq sections principales, c'est un problème d'architecture d'information déguisé en problème de navigation. Restructurez avant de choisir un pattern.
En 2026, la barre d'onglets en bas est le défaut pour tout produit que les gens ouvrent au moins quotidiennement sur mobile. Si vous concevez un produit mobile grand public ou une progressive web app mobile-first et que vous n'utilisez pas une barre en bas, il vous faut une raison spécifique. "Nous avons d'abord conçu pour desktop" n'est pas cette raison.
Le mega menu
Un mega menu développe un seul élément de navigation supérieure en un large panneau multi-colonnes de liens, catégories, et parfois tuiles de prévisualisation. Il est conçu pour les sites avec de grands catalogues et des hiérarchies complexes qui ne tiendraient pas dans un simple dropdown sans devenir inutilisables.

Amazon en propose une version extrême sous son menu "Tout". Des dizaines de catégories avec sous-catégories, organisées en colonnes et groupes, tout visible en un seul panneau. Le pattern fonctionne sous pression de catalogue parce qu'il expose la profondeur sans nécessiter plusieurs clics dans une hiérarchie. Tout est scannable en une vue.
Le problème est que les mega menus sont un pattern exclusivement desktop par conception. Un panneau dropdown multi-colonnes ne se traduit pas sur mobile. Les sites qui les utilisent ont besoin d'une stratégie de navigation entièrement séparée pour les petits écrans, ce qui double la surface de design et de maintenance.
Les mega menus échouent aussi sur les sites peu profonds. Douze pages ne justifient pas un mega menu. Le pattern implique une complexité que vous devez avoir gagnée par votre profondeur de contenu réelle, pas par un optimisme sur la croissance future.
Le fil d'Ariane
Le fil d'Ariane montre le chemin de la page d'accueil jusqu'à la page actuelle : Accueil > CSS > Grid. Ce n'est pas une navigation principale. C'est une navigation d'orientation, et elle remplit une fonction précise.

MDN utilise des fils d'Ariane sur chaque page de référence. Quand vous atterrissez sur la documentation CSS grid depuis une recherche Google, le fil d'Ariane vous dit instantanément que cette page se trouve dans CSS, qui se trouve dans Références. Ce contexte réduit une hiérarchie de trois niveaux à une seule ligne qui ne nécessite aucune interaction pour être comprise.
Les fils d'Ariane sont inutiles sur les sites plats. Si l'ensemble de votre produit n'a que deux niveaux de profondeur, les fils d'Ariane ajoutent un encombrement visuel sans apporter aucune valeur d'orientation. Ils méritent leur place sur les sites de documentation, les hiérarchies e-commerce du type Accueil > Hommes > Vestes > Imperméables, et tout site où les utilisateurs arrivent régulièrement en profondeur via la recherche.
Ils se combinent avec d'autres patterns plutôt que de les remplacer. Les fils d'Ariane se placent au-dessus du contenu, en complément d'une barre supérieure ou d'une sidebar. Pour d'autres analyses de design web et UI, la même logique s'applique : les éléments de navigation secondaires doivent soutenir le pattern principal, pas lui faire concurrence.
La palette de commandes
La palette de commandes est une superposition déclenchée au clavier, généralement invoquée par Cmd+K ou Ctrl+K, qui accepte une saisie texte et retourne des actions classées, des cibles de navigation et des résultats de recherche. Linear, Raycast, Slack et Figma la proposent tous comme surface de navigation de premier plan.

En 2026, la palette de commandes est passée du statut d'astuce pour utilisateurs avancés à mécanisme de navigation principal dans les logiciels de productivité sérieux. Le Cmd+K de Linear vous emmène à n'importe quel ticket, projet ou action d'espace de travail en moins de deux secondes. Raycast est construit presque entièrement autour de ce pattern. Ces produits traitent l'intention tapée comme un chemin plus direct que toute hiérarchie de menus, parce que pour les gens qui ont des habitudes clavier, c'est le cas.
L'échec vient de l'invisibilité. Les utilisateurs qui ignorent l'existence du raccourci ne le découvriront jamais par l'exploration. Les palettes de commandes ne peuvent pas remplacer la navigation visible pour les nouveaux utilisateurs ou quiconque n'a pas d'habitudes clavier. Les produits qui cachent toute la navigation derrière Cmd+K abandonnent chaque nouvel utilisateur.
La bonne utilisation est l'augmentation, pas le remplacement. Faites tourner une palette de commandes aux côtés de votre sidebar ou barre supérieure. Laissez les utilisateurs natifs du clavier sauter complètement le menu.
Laissez tous les autres naviguer visuellement. Les deux chemins doivent coexister.
Les en-têtes sticky et rétractables
Un en-tête sticky reste fixé en haut du viewport pendant que l'utilisateur fait défiler. Un en-tête rétractable fait la même chose mais réduit sa hauteur une fois que l'utilisateur a dépassé un seuil de défilement, récupérant de l'espace vertical sans sacrifier l'accès à la navigation.
Les deux patterns maintiennent la navigation accessible sur les longues pages sans nécessiter de remonter en haut. Sur les pages riches en contenu, c'est une vraie amélioration d'utilisabilité. GitHub utilise un en-tête sticky sur toutes les pages de dépôt pour que la navigation principale, la recherche et le contexte du dépôt soient toujours visibles pendant le défilement des issues, du code et des discussions.
Le coût est l'espace vertical. Un en-tête sticky de 60 à 70 pixels occupe cette hauteur à chaque position de défilement. Sur une tablette de 768 pixels de haut, c'est près de 10 % du viewport en permanence occupé par la navigation. Les en-têtes rétractables en récupèrent une partie en se réduisant à environ 40 pixels après le défilement, mais ils nécessitent une implémentation soignée pour paraître intentionnels plutôt que cassés.
Évitez les en-têtes sticky sur les pages courtes où l'utilisateur atteint rapidement le bas. Le pattern mérite sa place sur les longues pages denses en contenu où remonter en haut nécessiterait un défilement important.
Le fat footer
Le fat footer est un pied de page large multi-colonnes qui contient la navigation secondaire, les catégories de liens, les pages légales et les informations de contact. Ce n'est pas une navigation principale. C'est une deuxième chance pour les utilisateurs qui ont parcouru le contenu principal sans trouver ce qu'ils cherchaient.
Tailwind CSS, Stripe et la plupart des sites marketing SaaS utilisent des fat footers avec quatre à six colonnes couvrant les liens produit, la documentation, les pages entreprise, le légal et les liens sociaux. Ils ne coûtent rien en hauteur de viewport pendant l'expérience du contenu principal et fournissent une carte utile aux utilisateurs qui arrivent en bas à la recherche d'un élément précis.
Les fat footers comptent davantage pour le SEO que pour la navigation en direct. Chaque lien dans un fat footer est un chemin crawlable. Ce sont l'un des principaux moyens pour les moteurs de recherche de découvrir les pages secondaires et tertiaires d'un site. D'un point de vue purement utilisabilité, la plupart des utilisateurs ne descendent jamais jusqu'au pied de page, mais ceux qui le font sont en recherche délibérée.
Omettez le fat footer dans les expériences produit connectées. Notion ne vous affiche pas un pied de page marketing à l'intérieur de l'éditeur. Le pattern appartient aux sites marketing et aux hubs de documentation où les utilisateurs anonymes et nouveaux naviguent librement.
Comment choisir le bon pattern
Le bon pattern de navigation découle de deux paramètres : la profondeur de votre architecture d'information et le contexte dans lequel les gens utilisent le produit. Tout le reste est une conséquence de ces deux facteurs.
| Type de produit | Profondeur IA | Plateforme principale | Pattern recommandé |
|---|---|---|---|
| Site marketing | Peu profonde | Desktop + mobile | Barre supérieure + fat footer |
| Marketing SaaS, grand catalogue | Moyenne à profonde | Desktop + mobile | Barre supérieure + mega menu (desktop), hamburger (mobile) |
| Documentation | Profonde | Desktop | Sidebar persistante + fil d'Ariane |
| Dashboard ou outil de design | Moyenne à profonde | Desktop | Sidebar persistante |
| E-commerce | Profonde | Desktop + mobile | Mega menu (desktop), barre en bas ou hamburger (mobile) |
| App mobile grand public | Moyenne | Mobile | Barre d'onglets en bas |
| Outil de productivité ou pour développeurs | Profonde | Desktop + clavier | Sidebar persistante + palette de commandes |
| Éditorial ou blog | Peu profonde | Desktop + mobile | Barre supérieure + en-tête sticky sur les longs articles |
Combiner des patterns est normal et attendu. La plupart des produits sérieux en utilisent deux ou trois. La documentation Tailwind CSS utilise une barre supérieure pour la navigation au niveau du site, une sidebar persistante pour la navigation dans la documentation, et des fils d'Ariane pour l'orientation au niveau de la page. Ces trois patterns adressent simultanément trois niveaux distincts de la hiérarchie de navigation sans se chevaucher.
Brainy aide les designers à prendre des décisions plus tranchées, plus vite, sur le travail qui est réellement mis en production. Découvrez ce que nous construisons pour les créateurs.
Les erreurs de navigation qui sabotent silencieusement l'utilisabilité
Cacher les actions principales dans un menu hamburger. Si les utilisateurs ont besoin d'une fonctionnalité quotidiennement, elle ne peut pas se trouver derrière un tap supplémentaire. Mesurez le taux de clic sur le hamburger lui-même. S'il est inférieur à 30 %, les chemins à l'intérieur sont invisibles pour la majorité de vos utilisateurs.
Des libellés incohérents entre les surfaces. "Insights" sur le dashboard, "Rapports" dans l'email d'onboarding, "Analytiques" dans la documentation d'aide, tous pointant vers la même destination. La navigation est un vocabulaire. Chaque synonyme est un point d'interrogation dans le modèle mental d'un utilisateur.
Aucun état actif sur la position actuelle. Les utilisateurs ont besoin de savoir où ils sont. Un état actif sur l'élément de navigation actuel est le signal d'orientation le plus basique qui soit. L'omettre oblige les utilisateurs à lire l'URL, ce qui est un mode d'échec que vous avez conçu dans le produit.
Une navigation qui change selon la page ou la section. Si la sidebar se réorganise en fonction de la section dans laquelle l'utilisateur se trouve, vous avez brisé la mémoire spatiale qu'il avait construite. La navigation doit être une carte fixe. Les produits où la carte change en fonction de la position ne construisent pas la confiance des utilisateurs, ils la détruisent.
L'abus d'imbrication. Un dropdown à trois niveaux de profondeur est presque toujours un problème d'architecture d'information mal exprimé dans l'UI. Aplatissez d'abord la structure. Les menus imbriqués sont lents à scanner, impossibles à utiliser au toucher, et nécessitent un contrôle précis de la souris pour rester ouverts au survol.
Pour les patterns de mise en page conçus pour être scannés, le même principe s'applique : structure et orientation passent avant la décoration. Une navigation qui n'oriente pas est, au mieux, de la décoration, au pire, de la friction.
FAQ
Quel est le pattern de navigation le plus couramment utilisé sur le web ?
La barre de navigation supérieure horizontale est le pattern le plus courant pour les sites desktop. Pour les apps mobiles et les produits à usage quotidien, la barre d'onglets en bas est devenue le standard. La plupart des produits réels utilisent les deux, une barre supérieure sur desktop et une barre en bas sur mobile, sur une architecture d'information cohérente.
Quand utiliser un menu hamburger ?
Utilisez un menu hamburger pour la navigation secondaire ou peu fréquente sur mobile, pas pour les sections principales. Si un utilisateur doit ouvrir le hamburger pour faire la chose principale que votre produit propose, l'architecture a besoin d'être restructurée, pas d'une meilleure icône.
Combien d'éléments doit avoir une barre de navigation ?
Cinq à sept éléments est le plafond accepté pour une barre supérieure horizontale, et cinq pour une barre d'onglets en bas sur mobile. Au-delà de ces nombres, le pattern commence à échouer : les éléments se serrent, les libellés sont tronqués, et le coût du scan dépasse ce qu'il rapporte.
Puis-je utiliser plusieurs patterns de navigation sur un seul site ?
Non seulement vous le pouvez, mais vous le devriez. La plupart des vrais produits utilisent deux ou trois patterns qui adressent différents niveaux de la hiérarchie de navigation. Les sites de documentation combinent couramment une barre supérieure pour la navigation du site, une sidebar persistante pour la navigation de section, et des fils d'Ariane pour la localisation de la page.
Chaque pattern gère une couche distincte sans se chevaucher. L'erreur est d'utiliser plusieurs patterns qui se concurrencent plutôt que de collaborer.
Comment la navigation affecte-t-elle le SEO ?
Les liens dans votre barre supérieure, sidebar et fat footer transmettent l'autorité de page et aident les moteurs de recherche à découvrir et indexer les pages. Les fils d'Ariane ajoutent des données structurées qui peuvent faire apparaître les informations de chemin directement dans les résultats de recherche. La navigation fait partie de votre architecture SEO et doit être traitée comme telle dès le premier jour, pas corrigée après coup.
Arrêtez de faire chercher les gens
La navigation est invisible quand elle fonctionne et exaspérante quand elle ne fonctionne pas. L'objectif n'est jamais un beau menu. L'objectif est des utilisateurs qui arrivent, s'orientent, avancent et reviennent sans un seul moment de friction.
Neuf patterns couvrent presque tout : la barre supérieure pour les sites marketing et les références larges, la sidebar persistante pour les outils profonds et la documentation, la barre d'onglets en bas pour le mobile à usage quotidien, le mega menu pour la profondeur de catalogue, les fils d'Ariane pour l'orientation hiérarchique, la palette de commandes pour les outils de productivité axés sur la rapidité, les en-têtes sticky pour le contenu long format, le hamburger comme fallback pour les chemins secondaires, et le fat footer comme carte de deuxième chance pour les sites marketing.
Choisissez en fonction de la profondeur de l'IA et du contexte d'utilisation. Superposez deux ou trois patterns quand votre produit a plusieurs niveaux de hiérarchie de navigation. Évitez les erreurs qui se cumulent silencieusement : actions principales cachées, libellés incohérents, états actifs manquants, structures de navigation changeantes et imbrication excessive.
Explorez d'autres analyses de design web et UI sur Brainy Papers, ou construisez aux côtés de la communauté créative Brainy et affûtez le métier avec plus de 2M de designers qui tiennent aux fondamentaux.
Brainy helps designers make sharper calls, faster, on the work that actually ships. See what we are building for creators.
Get Started




