Documentation utilisateur site web

La documentation utilisateur décrit comment se servir d’un outil : les écrans, les parcours, les actions possibles et leurs conséquences. Elle s’adresse à ceux qui l’utilisent, pas à ceux qui le développent.

Ce qu’elle doit couvrir

Un bon guide suit l’usage, pas l’arborescence du menu. Il répond dans l’ordre à trois besoins.

• Démarrer : créer son compte, se connecter, comprendre à quoi sert l’outil en une page. C’est la partie la plus lue et la plus souvent bâclée.
• Faire les tâches courantes : les cinq ou six actions qui représentent l’essentiel des usages, décrites de bout en bout, avec le résultat attendu.
• Se dépanner : les messages d’erreur fréquents, ce qu’ils signifient, et quoi faire. Cette section réduit directement les sollicitations du support.

Le reste, la description exhaustive de chaque champ de chaque écran, ne se lit pas. Il vaut mieux une page par tâche courante qu’un catalogue de fonctionnalités.

Deux publics, deux documents

Les utilisateurs internes font tourner l’outil au quotidien : saisie, validation, administration. Ils ont besoin des procédures métier et des cas particuliers, y compris ceux qu’on ne rencontre que deux fois par an.

Les utilisateurs externes, clients ou adhérents sur un espace en ligne, ont besoin d’autre chose : des réponses courtes, accessibles au moment du blocage, plutôt qu’un document à télécharger. Sur un extranet ou une application métier, mélanger les deux publics dans un seul manuel garantit qu’aucun des deux ne le lira.

Le format compte autant que le contenu

Un PDF de quatre-vingts pages envoyé à la mise en service est un document mort. Ce qui fonctionne se rapproche davantage de ceci : des pages courtes consultables en ligne, une recherche, et des captures d’écran.

Les captures sont l’élément le plus utile et le plus fragile : elles se périment à la première évolution de l’interface. Deux parades, la seconde étant la plus fiable. Limiter les captures aux écrans qui bougent peu. Ou accepter de les refaire à chaque évolution, et inscrire cette tâche dans le lot de développement plutôt que d’espérer la faire après.

Ce qu’elle ne rattrape pas

Une documentation ne corrige pas une interface confuse. Quand un guide doit expliquer pourquoi le bouton Enregistrer se trouve en bas d’un formulaire à trois onglets, le problème est dans le formulaire.

La bonne façon de lire un manuel volumineux est donc de le prendre pour un diagnostic : chaque passage qui demande un long paragraphe d’explication signale un endroit où l’outil demande un effort inutile. Sur une refonte, ces passages sont les premiers à traiter.

Qui l’écrit

Rarement le développeur, qui connaît trop bien l’outil pour voir ce qui bloque. Le bon auteur est celui qui a vu des utilisateurs s’en servir : le chef de projet, le référent métier, ou le support. La relecture par un utilisateur qui découvre l’outil vaut mieux que trois relectures internes.

Elle se distingue de la documentation technique, destinée à ceux qui modifient le code. Les deux se livrent ensemble et ne se substituent jamais l’une à l’autre.

Le test de la documentation utile

Prenez la tâche la plus courante de votre outil et confiez le guide à quelqu’un qui ne l’a jamais utilisé, sans aide. S’il y arrive, la documentation fait son travail. S’il pose une question, la réponse manque à l’endroit où il a buté : c’est là qu’il faut écrire, et nulle part ailleurs.