Les guides utilisateur ont un problème d'image. La plupart des équipes en rédigent parce qu'il faut bien que quelqu'un s'en charge, personne n'y prend plaisir, et le résultat est un dossier de documents qui décrivent fidèlement l'interface sans aider qui que ce soit.
Les guides qui fonctionnent ont un point commun précis : ils sont organisés autour de ce que l'utilisateur cherche à accomplir, et non de ce que le produit contient. Ce seul changement de perspective explique l'essentiel de l'écart entre la documentation que les gens recherchent et celle qu'ils ignorent.
Ce guide passe en revue les types de guide utilisateur qui valent la peine d'être rédigés, une structure adaptée à chacun, huit exemples de formats à copier, et le moment où la documentation écrite cesse d'être le bon outil.
Toute bonne page de guide repose sur le même squelette, quel que soit le produit.
Points clés
- Organisez par tâche, pas par menu. Les utilisateurs cherchent ce qu'ils veulent faire, jamais le nom de votre fonctionnalité.
- Un guide, un résultat. Une page qui couvre trois tâches ne sera trouvée par personne cherchant l'une d'entre elles.
- Commencez par le résultat et les prérequis. L'utilisateur doit savoir en cinq secondes qu'il est au bon endroit.
- Les captures d'écran coûtent cher. Chacune est une dette de maintenance ; ne les utilisez que là où les mots ne suffisent vraiment pas.
- Pour une première tâche, le guidage in-app bat le guide écrit. La documentation excelle dans la profondeur, la référence et le dépannage.
- Vos tickets de support sont votre feuille de route éditoriale. Les questions que l'on vous pose sont les guides que vous n'avez pas encore écrits.
Qu'est-ce qu'un guide utilisateur ?
Définition du guide utilisateur : un document qui aide une personne à accomplir une tâche précise avec un produit, rédigé du point de vue de l'utilisateur et structuré autour de son objectif plutôt que de l'architecture du logiciel. Dans un SaaS, les guides utilisateur se trouvent généralement dans un centre d'aide et viennent compléter le guidage dans le produit, sans le remplacer.
Les termes se recoupent de façon déroutante, il vaut donc la peine de savoir précisément ce que vous rédigez :
| Format | Répond à | Meilleure structure | Longueur |
|---|---|---|---|
| Guide pratique (how-to) | « Comment faire X ? » | Des étapes numérotées vers un seul résultat | 300–800 mots |
| Guide de démarrage | « Par où commencer ? » | Le chemin le plus court vers une première valeur | 500–1 200 mots |
| Référence | « À quoi sert ce paramètre ? » | Alphabétique ou structurelle ; lisible d'un coup d'œil | Ce qu'il faut |
| Guide conceptuel | « Pourquoi ça fonctionne ainsi ? » | De la prose, des schémas, un exemple concret | 800–2 000 mots |
| Dépannage | « Pourquoi ça ne marche pas ? » | Symptôme → cause → solution | Court, par symptôme |
Mélanger ces types est l'erreur de documentation la plus courante. Un guide pratique qui s'interrompt pour expliquer l'architecture perd la personne pressée ; un guide conceptuel découpé en étapes numérotées perd la personne qui cherche à comprendre. Décidez lequel vous rédigez avant d'écrire la première phrase.
Comment créer un guide utilisateur, étape par étape
Partir de la tâche, avec les mots de l'utilisateur
Écrire d'abord le résultat et les prérequis
Rédiger les étapes en faisant la tâche vous-même
N'ajouter des visuels que là où les mots échouent
Boucler la boucle : vérification, pièges, étape suivante
Tester le guide sur quelqu'un qui n'a jamais fait la tâche
Lui attribuer un responsable et une date de révision
1. Partir de la tâche, avec les mots de l'utilisateur
Votre fonctionnalité s'appelle « Segment Builder ». Vos utilisateurs, eux, cherchent « comment envoyer ça uniquement aux nouveaux clients ». Donnez à la page le titre de la recherche, pas celui de la fonctionnalité ; le nom de la fonctionnalité peut figurer dans le corps du texte, où il sera toujours trouvé.
La meilleure source de ces formulations est gratuite et dort déjà dans votre outil de support : la formulation exacte des tickets, plus les recherches effectuées sur votre site. Les deux vous disent comment les gens nomment les choses quand personne ne les observe.
2. Écrire d'abord le résultat et les prérequis
Avant la première étape, répondez à deux questions : qu'aura l'utilisateur une fois terminé, et de quoi a-t-il besoin avant de commencer (un niveau de permission, une intégration connectée, un objet existant) ? Des prérequis enfouis à l'étape quatre, c'est la raison pour laquelle on abandonne les guides en plein milieu, avec un travail à moitié fait.
3. Rédiger les étapes en faisant la tâche vous-même
Écrivez en réalisant la tâche dans le produit, pas de mémoire ni à partir d'une spécification. La mémoire saute sans prévenir les étapes devenues automatiques pour vous, et ce sont précisément celles sur lesquelles bloque un nouvel utilisateur.
Les règles pour les étapes elles-mêmes : une seule action par étape, le verbe en premier (« Cliquez », « Sélectionnez », « Saisissez »), et le libellé exact de l'interface en gras. Si une étape a besoin d'un « pendant ce temps » ou d'un « notez que », ce sont deux étapes.
4. N'ajouter des visuels que là où les mots échouent
Une capture d'écran par étape donne une impression de rigueur, mais c'est un piège de maintenance : votre interface évolue, et un guide avec quinze captures obsolètes est pire qu'un guide sans aucune, car il induit désormais activement en erreur. Utilisez un visuel quand la cible est vraiment difficile à décrire, quand l'utilisateur doit confirmer qu'il est au bon endroit, ou quand le résultat est visuel. Sinon, décrivez avec des mots.
Quand vous utilisez des images, recadrez serré sur la zone utile et annotez. Une capture de la fenêtre entière oblige le lecteur à chercher le seul contrôle dont parle la phrase.
5. Boucler la boucle : vérification, pièges, étape suivante
Trois courtes sections que la plupart des guides omettent, et qui apportent pourtant l'essentiel de la valeur :
- Comment vérifier que ça a fonctionné : le signe visible de réussite, pour que l'utilisateur n'ait pas à deviner.
- Ce qui coince le plus souvent : les deux ou trois cas d'échec que le support voit le plus, avec leur solution.
- La tâche suivante évidente : là où va généralement un utilisateur qui vient de terminer celle-ci.
6. Tester le guide sur quelqu'un qui n'a jamais fait la tâche
Confiez le brouillon à un collègue extérieur à l'équipe et regardez-le le suivre sans l'aider. Chaque hésitation est un défaut. Cela prend quinze minutes et révèle plus de problèmes que n'importe quelle relecture interne, parce que les relecteurs lisent la documentation alors que les connaissances des auteurs sont encore dans la pièce.
7. Lui attribuer un responsable et une date de révision
La documentation se dégrade en silence. Un guide sans responsable nommé ni date de révision sera faux en deux cycles de release, et personne ne s'en apercevra avant qu'un client ne le fasse. Affichez une date de dernière mise à jour visible sur la page ; elle indique aussi aux utilisateurs s'ils peuvent se fier à ce qu'ils lisent.
8 formats de guide utilisateur à copier
Une page, un résultat : le chemin le plus court possible entre un compte vide et un premier résultat concret. Il ignore volontairement la configuration, les cas particuliers et les alternatives ; tout ce qui n'est pas sur le chemin critique devient un lien, pas un paragraphe.
Un titre formulé comme une tâche, le résultat et les prérequis en haut, cinq à neuf étapes numérotées, une ligne de vérification et deux problèmes fréquents. Rien d'autre.
Des points d'entrée parallèles (« Pour les administrateurs », « Pour les éditeurs », « Pour les lecteurs »), chacun avec son propre parcours court à travers le même produit. Une même fonctionnalité apparaît dans plusieurs guides, décrite différemment.
Entièrement organisé selon ce que l'utilisateur observe, « Mon import s'est terminé mais aucun enregistrement n'apparaît », jamais selon la cause interne. Chaque symptôme renvoie vers une ou plusieurs causes, avec une solution précise.
Toutes les options dans un seul tableau lisible d'un coup d'œil : le nom, ce qu'elle fait, la valeur par défaut et (la colonne que la plupart des équipes oublient) ce qui se passe si on la modifie après la configuration initiale.
Un scénario réaliste de bout en bout, avec des noms et des chiffres concrets, qui montre comment plusieurs fonctionnalités se combinent pour résoudre un vrai problème. Pas une visite des fonctionnalités déguisée en histoire.
Un enregistrement de 60 à 120 secondes, toujours accompagné des mêmes étapes en texte sur la même page.
Le guide s'exécute à l'intérieur de l'application et met en évidence les vrais contrôles, dans l'ordre, pendant que l'utilisateur réalise la tâche sur ses propres données.
Les mêmes instructions qu'un guide utilisateur écrit, présentées sur l'écran réel que l'utilisateur a sous les yeux.
Quand un guide écrit n'est pas le bon outil
La documentation souffre d'un handicap structurel qu'aucune qualité d'écriture ne compense : elle oblige l'utilisateur à quitter le produit, trouver la bonne page, garder les instructions en tête, puis revenir. Pour une première tâche dans une interface inconnue, c'est dans cet écart que la plupart des gens abandonnent.
| Situation | Meilleur outil | Pourquoi |
|---|---|---|
| Tâche de configuration réalisée pour la première fois | Product tour | Guide la vraie interface au lieu de la décrire. |
| Un contrôle dont l'utilité n'est pas claire | Infobulle (tooltip) | Répond à la question là où elle se pose. |
| Une série de premières victoires | Checklist d'onboarding | Suit la progression ; un document en est incapable. |
| Une fonctionnalité méconnue | Hotspot | Personne ne lit un guide sur une fonctionnalité dont il ignore l'existence. |
| Un écran vide | Texte d'état vide | L'instruction a sa place là où se trouve le vide. |
| Référence approfondie, cas particuliers, configuration admin | Un guide écrit | Profondeur, trouvabilité et pérennité sont les vraies forces de la documentation. |
La répartition honnête des rôles : le guidage dans le produit prend en charge la première heure, et la documentation tout ce qui suit. Les équipes qui veulent faire porter l'onboarding à des guides écrits se retrouvent avec une documentation exhaustive et une activation médiocre, et elles en concluent généralement que la documentation doit être plus longue.
Faire vivre vos guides utilisateur
✅ À faire
- Titrer les pages d'après les tâches, avec les mots de l'utilisateur
- Indiquer d'abord le résultat et les prérequis
- Rédiger en réalisant la tâche
- Garder une seule action par étape numérotée
- Ajouter une étape de vérification
- Afficher une date de dernière mise à jour visible
- Exploiter les tickets de support pour repérer les guides manquants
- Créer un lien vers le guide depuis le produit
❌ À éviter
- Calquer la structure de la documentation sur votre menu de navigation
- Couvrir trois tâches sur une même page
- Faire une capture de chaque étape
- Enfouir les prérequis au milieu
- Expliquer l'architecture dans un guide pratique
- Publier une vidéo sans équivalent texte
- Laisser des guides sans responsable
- Attendre de la documentation qu'elle fasse le travail de l'onboarding
Laissez les données vous dire quoi écrire ensuite
Trois signaux, par ordre d'utilité : la formulation exacte des tickets de support récurrents, les recherches dans votre centre d'aide qui ne renvoient rien, et les pages à fort trafic et fort taux de sortie. Le premier vous dit ce qui manque, le deuxième ce que les gens s'attendaient à trouver, et le troisième quel guide existant est en échec.
Associer vos guides au guidage in-app
Le dispositif le plus solide n'est pas la documentation ou l'aide dans le produit : c'est une documentation accessible depuis le produit, au moment où la question se pose, avec un premier parcours géré de façon interactive.
- Transformez la première tâche en tour. Convertissez vos trois principaux guides de démarrage en product tours interactifs et comparez leurs taux de complétion à ceux des versions écrites.
- Répondez aux petites questions sur place. Une infobulle sur un champ déroutant évite la recherche qui mène au guide qui mène au ticket de support.
- Proposez le bon guide selon le contexte au lieu d'envoyer tout le monde vers la page d'accueil du centre d'aide.
- Suivez quel accompagnement est réellement utilisé grâce aux analytics produit, et retirez ce que personne n'ouvre.
- Annoncez les changements de documentation en même temps que les évolutions de fonctionnalités, via le widget d'annonces.
Kompassify est une plateforme d'adoption digitale no-code pour les équipes SaaS : product tours, checklists, infobulles, annonces, sondages in-app et analytics réunis au même endroit. Gratuit jusqu'à 100 utilisateurs actifs mensuels, offres payantes à partir de $129/mois, conforme au RGPD avec hébergement dans l'UE.
Transformez votre meilleur guide en walkthrough interactif
Prenez la page de démarrage la plus lue par vos utilisateurs et faites-la vivre directement dans votre produit : sans code, sans ticket pour l'équipe technique.
Commencer gratuitement →Questions fréquentes
Qu'est-ce qu'un guide utilisateur ?
Un guide utilisateur est un document qui aide une personne à accomplir une tâche précise avec un produit, rédigé du point de vue de l'utilisateur et structuré autour de son objectif plutôt que de l'architecture du logiciel. Dans un SaaS, il se trouve généralement dans un centre d'aide et fonctionne en complément du guidage dans le produit, sans le remplacer. Ce qui définit un bon guide, c'est qu'il est organisé par tâche, et non selon la structure des menus.
Comment rédiger un guide utilisateur ?
Partez de la tâche formulée avec les mots de l'utilisateur, tirés des tickets de support et des recherches sur votre site. Indiquez le résultat attendu et les prérequis avant la première étape. Rédigez les étapes en réalisant réellement la tâche dans le produit plutôt que de mémoire, avec une seule action par étape numérotée et le libellé exact de l'interface en gras. N'ajoutez des visuels que là où les mots ne suffisent vraiment pas à lever l'ambiguïté. Terminez par la façon de vérifier que cela a fonctionné, ce qui coince le plus souvent et la tâche suivante évidente. Puis testez le guide sur quelqu'un qui n'a jamais fait la tâche.
Quels sont les différents types de guide utilisateur ?
Il en existe cinq qui méritent d'être distingués : les guides pratiques (how-to), qui répondent à « comment faire X » avec des étapes numérotées ; les guides de démarrage, qui montrent le chemin le plus court vers une première valeur ; la documentation de référence, qui explique à quoi sert chaque paramètre et doit se parcourir d'un coup d'œil plutôt que se lire comme de la prose ; les guides conceptuels, qui expliquent pourquoi le produit fonctionne d'une certaine façon ; et le dépannage, organisé par symptôme. Mélanger ces types sur une même page est l'erreur de documentation la plus courante.
Quelle longueur doit faire un guide utilisateur ?
Aussi long que la tâche l'exige, pas plus. Un guide pratique sur une seule tâche fait généralement 300 à 800 mots, avec cinq à neuf étapes. Un guide de démarrage compte 500 à 1 200 mots. Un guide conceptuel peut justifier 800 à 2 000 mots. La documentation de référence n'a pas de longueur naturelle. La vraie contrainte n'est pas le nombre de mots mais le périmètre : une page doit couvrir un seul résultat, car une page qui couvre trois tâches ne sera trouvée par personne cherchant l'une d'entre elles.
Faut-il mettre des captures d'écran dans un guide utilisateur ?
Seulement là où les mots ne suffisent pas. Chaque capture d'écran est une dette de maintenance, et un guide rempli d'images obsolètes est pire qu'un guide sans images, car il induit activement en erreur après un changement d'interface. Utilisez un visuel quand la cible est difficile à décrire, quand l'utilisateur doit confirmer qu'il est au bon endroit, ou quand le résultat lui-même est visuel. Recadrez serré et annotez plutôt que de coller toute la fenêtre.
Quand le guidage in-app est-il préférable à un guide utilisateur écrit ?
Pour les tâches réalisées pour la première fois dans une interface inconnue. Un guide écrit oblige l'utilisateur à quitter le produit, trouver la page, garder les étapes en tête puis revenir, et c'est dans cet écart que la plupart des gens abandonnent. Les product tours, les infobulles (tooltips), les checklists, les hotspots et les textes d'états vides suppriment tous cette étape de traduction. La documentation écrite reste le meilleur outil pour la profondeur, la référence, les cas particuliers et le dépannage.
Comment maintenir ses guides utilisateur à jour ?
Attribuez à chaque guide un responsable nommé et une date de révision, et affichez sur la page une date de dernière mise à jour visible pour que les lecteurs sachent s'ils peuvent s'y fier. Liez la révision de la documentation à votre processus de release au lieu d'en faire un projet à part. Puis servez-vous de trois signaux pour décider quoi corriger en premier : les tickets de support récurrents, les recherches dans le centre d'aide qui ne renvoient rien, et les pages à fort trafic et fort taux de sortie.
Comment choisir les prochains guides utilisateur à rédiger ?
Exploitez votre file de support pour repérer les questions qui reviennent, en reprenant la formulation exacte des clients comme titre de page. Regardez ensuite les recherches internes qui ne renvoient aucun résultat : elles vous disent ce que les gens s'attendaient à trouver. Ces deux sources valent mieux que des suppositions tirées d'une liste de fonctionnalités, car elles reflètent ce que les utilisateurs essaient réellement de faire plutôt que ce que le produit se trouve contenir.