Passer au contenu principal
La navigation façonne la manière dont les utilisateurs construisent un modèle mental de votre produit. Une navigation bien conçue aide les utilisateurs à trouver des réponses rapidement, à comprendre comment les différentes parties du produit sont liées et à se sentir confiants qu’ils sont au bon endroit. Une mauvaise navigation envoie les utilisateurs vers les moteurs de recherche, les tickets de support ou la documentation de vos concurrents. Ce guide couvre comment concevoir, valider et maintenir une navigation de documentation qui fonctionne pour de vrais utilisateurs.

Commencez par comprendre vos utilisateurs et votre produit

Avant d’organiser les pages, alignez-vous avec les personnes qui connaissent le mieux votre produit et vos utilisateurs.

Établissez les bases avec les parties prenantes

Discutez avec les fondateurs, les chefs de produit et les responsables techniques avant de prendre des décisions structurelles. L’objectif est de comprendre comment le produit fonctionne réellement, pas seulement comment il est commercialisé. Questions à poser :
  • Quelle est la manière la plus simple d’expliquer comment le produit fonctionne ?
  • Quels sont les composants fondamentaux du produit ?
  • Comment les utilisateurs adoptent-ils généralement le produit ? Où se retrouvent-ils le plus souvent bloqués ?
  • Quelles sont les intégrations ou dépendances les plus importantes ?
  • Si le produit était divisé en différentes couches, quelles seraient-elles ? Serait-il organisé par tâches que les gens effectuent ou par fonctionnalités qu’ils utilisent ?
Ces conversations font émerger la structure naturelle du produit et révèlent souvent où la navigation de la documentation s’est éloignée de la façon dont les utilisateurs pensent réellement.

Sachez pour qui vous écrivez

Les décisions de navigation dépendent de votre audience. Un développeur intégrant une API navigue différemment d’un administrateur configurant des paramètres ou d’un nouvel utilisateur suivant un parcours d’intégration. Si vous avez plusieurs audiences distinctes, demandez-vous si elles ont besoin de structures de navigation séparées ou si une structure unifiée unique peut toutes les servir. Consultez Comprendre votre audience pour en savoir plus sur la définition des personas de documentation.

Choisissez une structure de navigation

Organisez par parcours utilisateur, pas par fonctionnalités du produit

L’erreur de navigation la plus courante est d’organiser la documentation de la manière dont l’équipe produit pense au produit plutôt que de la manière dont les utilisateurs essaient d’atteindre leurs objectifs. Comparez ces deux approches pour un produit d’API :
Centré sur les fonctionnalités (à éviter)Centré sur le parcours (préférable)
API principaleDémarrer
AuthentificationS’authentifier
WebhooksEnvoyer votre première requête
Limitation de débitGérer les erreurs
SDKsPasser en production
La navigation centrée sur le parcours indique aux utilisateurs où ils en sont dans un processus. La navigation centrée sur les fonctionnalités exige que les utilisateurs sachent déjà ce qu’ils cherchent.

Gérez la profondeur et la largeur

La profondeur de navigation désigne le nombre de niveaux que les utilisateurs doivent traverser pour atteindre le contenu. La largeur désigne le nombre d’éléments qui apparaissent à chaque niveau. Quelques principes :
  • Limitez les sections de niveau supérieur à sept éléments ou moins. La charge cognitive augmente lorsque les utilisateurs doivent examiner et évaluer davantage d’options.
  • Préférez la profondeur à la largeur. Une section de niveau supérieur avec cinq sous-sections est plus facile à parcourir que 20 éléments de niveau supérieur.
  • Ne cachez pas le contenu critique en dessous de deux niveaux. Si les utilisateurs doivent cliquer à travers trois niveaux pour atteindre des pages fréquemment consultées, envisagez de promouvoir ce contenu.

Nommez clairement les éléments de navigation

Les libellés de navigation doivent correspondre à la façon dont les utilisateurs décrivent leurs objectifs, pas à la façon dont les ingénieurs décrivent les fonctionnalités.
  • Utilisez des verbes pour les sections orientées tâches (“S’authentifier”, “Déployer”, “Surveiller”)
  • Utilisez des noms pour les sections de référence (“Référence API”, “SDKs”, “Journal des modifications”)
  • Évitez la terminologie interne que les utilisateurs ne reconnaîtront pas
  • Gardez les libellés courts — idéalement moins de 4 mots

Validez vos hypothèses

Votre première structure de navigation est une hypothèse. Validez-la avant de la considérer comme permanente.

Suivez les parcours réels des utilisateurs

Utilisez des outils de relecture de session comme FullStory ou Hotjar et des outils d’analyse comme Mixpanel pour étudier comment les utilisateurs se déplacent réellement dans votre documentation. Recherchez :
  • Points d’entrée : Où les utilisateurs commencent-ils ? Viennent-ils d’une recherche, d’un ticket de support ou directement de votre produit ?
  • Schémas de navigation : Les utilisateurs suivent-ils la structure prévue ou empruntent-ils des chemins inattendus ?
  • Points de friction : Où les utilisateurs s’arrêtent-ils, reviennent-ils en arrière ou abandonnent-ils leur session ?
  • Comportement de recherche : Les utilisateurs recherchent-ils des termes qui n’apparaissent pas dans vos libellés de navigation ? Cela signale un décalage terminologique.

Testez avec de vrais utilisateurs

L’analyse révèle des schémas, mais les conversations directes fournissent le contexte qui les sous-tend. Demandez aux utilisateurs de réaliser une tâche spécifique en utilisant uniquement la documentation tout en décrivant leur processus de réflexion. L’endroit où ils cliquent en premier et celui où ils se retrouvent bloqués révèle si votre navigation est intuitive. Les nouvelles recrues de votre propre équipe sont de bons substituts pour les utilisateurs. Avant qu’elles ne se familiarisent trop avec le produit de l’intérieur, demandez-leur de trouver des réponses à des questions spécifiques en utilisant uniquement la documentation. Leurs instincts révèlent les hypothèses que votre navigation fait et qui ne sont pas évidentes pour les nouveaux venus.

Identifiez et corrigez les problèmes courants

Sections de niveau supérieur surchargées

Si votre navigation de niveau supérieur comporte plus de 7 ou 8 éléments, les utilisateurs passent plus de temps à évaluer les options qu’à trouver du contenu. Regroupez les sujets connexes dans des sections avec des noms significatifs.

Contenu essentiel enfoui

Si les pages dont les utilisateurs ont le plus besoin se trouvent à deux ou trois niveaux de profondeur, promouvez-les. Les pages à fort trafic doivent être faciles à atteindre depuis le niveau supérieur ou visibles dans le premier niveau de toute section pertinente.

Noms de section peu clairs

Si les utilisateurs hésitent avant de cliquer sur un élément de navigation, le libellé ne remplit pas son rôle. Testez si les utilisateurs peuvent prédire ce qu’ils trouveront avant de cliquer en décrivant ce qui se trouve à l’intérieur.

Pages manquantes vs. problèmes de navigation

Parfois, ce qui ressemble à un problème de navigation est en réalité un manque de contenu. Si les utilisateurs recherchent des termes qui ne correspondent à aucune page, il vous manque peut-être du contenu plutôt que des libellés incorrects. Distinguez les deux avant de restructurer.

Itérez au fil du temps

La navigation doit évoluer avec votre produit et vos utilisateurs. Vous n’avez pas besoin de tout réussir du premier coup. Une cadence pratique :
  • Révisez la navigation chaque fois que le produit lance des changements majeurs. Les nouvelles fonctionnalités exposent souvent des lacunes structurelles.
  • Consultez les analyses de recherche trimestriellement pour repérer les termes que les utilisateurs recherchent et qui ne sont pas reflétés dans vos libellés de navigation.
  • Réexaminez la structure de niveau supérieur annuellement. À mesure que la documentation grandit, ce qui fonctionnait à 20 pages peut ne plus fonctionner à 200.
Utilisez les workflows pour automatiser les vérifications récurrentes comme identifier les pages avec de faibles scores de retour ou signaler les éléments de navigation qui reçoivent rarement des clics.
Pour configurer la navigation dans Mintlify — onglets, groupes, ancres et ordre des pages — consultez la référence de navigation.

Questions fréquemment posées

Par objectifs utilisateur, dans la plupart des cas. La navigation basée sur les fonctionnalités a du sens pour les équipes produit qui comprennent déjà l’architecture, mais les utilisateurs viennent à la documentation pour accomplir quelque chose — pas pour parcourir les fonctionnalités. Organisez autour de ce que les utilisateurs essaient de faire et regroupez les fonctionnalités sous les tâches qu’elles permettent.
Visez 5 à 7. La recherche sur la charge cognitive suggère que les utilisateurs peuvent confortablement évaluer environ 7 éléments avant que la fatigue décisionnelle ne s’installe. Si vous en avez plus, cherchez des regroupements naturels qui peuvent être combinés en une seule section avec des sous-sections.
D’abord, décidez si vos audiences sont suffisamment différentes pour nécessiter des structures séparées. Si un administrateur et un développeur ont tous deux besoin de démarrer, une section partagée “Démarrer” peut très bien fonctionner avec des sous-sections spécifiques à chaque audience. Si leurs parcours sont fondamentalement différents — produits séparés, personas séparés — envisagez des sites de documentation séparés ou une navigation par onglets qui sépare clairement les deux chemins.
Réorganisez lorsque les données utilisateur montrent des échecs de navigation constants — taux de rebond élevés sur les pages d’index, recherches fréquentes de termes que vous attendriez les utilisateurs à trouver directement par navigation, ou tickets de support indiquant que les utilisateurs ne trouvent pas du contenu évident. Évitez de réorganiser sur la seule base de l’intuition. Le coût de la restructuration (signets cassés, réapprentissage, réécriture des liens internes) est réel, alors assurez-vous que les données le justifient.
Intégrez une révision dans votre flux de travail de contenu. Lors de l’ajout de nouvelles pages, exigez une décision sur leur emplacement dans la navigation avant de commencer à écrire. Il est beaucoup plus facile de maintenir une structure cohérente en prenant des décisions de placement en amont que de réorganiser après que des dizaines de pages se soient accumulées aux mauvais endroits.