Pourquoi dépenser du temps et de l’argent à faire une documentation qui ne servira à personne ?

Documenter un produit que l’on vend, ou une application développée in-house pour ses collaborateurs : une opération à forcément imputer dans la colonne des dépenses. Mais comment alors chiffrer la perte liée à l’absence de documentation ou à une documentation mal faite, qui rebutera les utilisateurs et ternira l’image de votre produit ?  

L’absence de documentation adéquate c’est :

  • un service technique surchargé de questions du type « comment faire pour » ? Parlez-en à vos équipes techniques qui passent plus de temps à faire du support utilisateur que du développement produit…
  • des clients / utilisateurs qui sont livrés à eux-mêmes, et qui associent cela à un abandon plutôt qu’à la confiance que vous mettez en eux sur leur capacité à s’en sortir tous seuls
  • des clients qui n’exploitent qu’une partie des fonctionnalités de vos produits, et en ignorent donc la richesse et le potentiel
  • un service commercial qui n’est pas outillé pour promouvoir le produit
  • un time to market bien plus long pour vos produits, car une documentation ça sert aussi à fluidifier les échanges en interne entre le développement et le service commercial
  • une absence de pérennisation des connaissances (que se passe-t-il quand une ressource phare d’un projet s’en va si rien n’est documenté ?

La documentation technique, c’est comme une ampoule basse consommation…

…autant de conséquences impossibles à chiffrer mais qui pèsent lourd dans la balance. Les coûts cachés (rédaction par des ingénieurs et non par un rédacteur technique compétent, mauvaise exploitation du capital immatériel, diminution de la satisfaction client, augmentation des coûts de support, etc.) peuvent être considérables. Pourtant, les solutions et les compétences existent.

La documentation technique, c’est comme une ampoule : une ampoule basse consommation demande un investissement plus important en début de cycle de vie, mais a rapidement un coût plus faible. Comme une ampoule basse consommation, un processus de rédaction technique industriel diminue les coûts (1).

Alors comment faire de sa documentation un investissement plutôt qu’une dépense ?

  • Eviter de faire une « usine à gaz » en voulant à tout prix documenter tous les menus de l’application. Se mettre à la place de l’utilisateur, prendre du recul, et se demander vraiment ce qu’il est important qu’il comprenne et les fonctionnalités qu’il doit maîtriser pour une utilisation optimale de l’outil.
  • Pour cela, mieux vaut éviter de faire rédiger la documentation par les développeurs à l’origine du produit… à trop vouloir expliquer tout ce qu’il est possible de faire, ils vont noyer l’utilisateur. A chacun son métier.
  • Evidemment les développeurs sont ceux qui connaissent le mieux le produit… mais ce n’est pas ce qui est demandé. En matière de documentation, c’est le recul et le positionnement du point de vue de l’utilisateur qui compte. Des professionnels de la documentation sont les mieux placés pour identifier quelle information mérite d’être transmise et comment elle doit l’être. Ils sont indépendants de la matière traitée (ils traitent l’information, indépendamment du fait qu’elle soit du domaine bancaire, industriel, technique…). Vous avez un doute ? Pour information, aucun de nous n’a été dans une autre vie banquier, ingénieur dans le secteur du gaz, de l’électricité, des télécommunications ou encore médecin…

  • Penser support modulaire et « agile » plutôt que guide papier farci de captures d’écran. Si on veut que la documentation soit disponible en même temps que le produit, elle doit être rédigée au fil de son développement. Les captures d’écran, forcément évolutives, ne doivent donc pas constituer les briques d’une documentation. Il est bien plus intéressant de développer un système de documentation, qui comprenne différents modules, et dont pourront-être issues indifféremment une brochure commerciale, un guide utilisateur, une aide en ligne, un tutoriel vidéo, une FAQ… et répondre ainsi aux besoins d’information technique, commerciale, marketing de cibles variées.
  • Penser à tous vos utilisateurs. Idéalement, une documentation doit pouvoir être utilisée par le large spectre du développeur à l’utilisateur final en passant par le help desk et le service commercial. Elle sert d’interface entre le service R&D et le marketing. Une documentation technique de qualité ne sert pas seulement à vos clients, mais elle constitue aussi LA référence en interne pour parler d’un produit.
  • Un utilisateur qui appelle moins le helpdesk. Rendu autonome par une structure transparente et un choix des titres éclairants, l’utilisateur pourra se repérer et aller chercher la juste information sans se noyer dans des contenus inutiles à son besoin.
  • Le tout est de penser le système de documentation en amont, et de structurer les informations de sorte de répondre aux questions légitimes de l’utilisateur : « Quels concepts / notions techniques dois-je connaître pour comprendre le produit ? », « Comment est-ce que je peux faire telle opération ? », «Comment est-ce que je peux régler ce problème ? », etc. De cette réflexion pourra être déduite la structure de la documentation et son articulation entre les différents sujets à aborder. Chaque sujet devra être autoporté, se suffire à lui-même pour éviter à l’utilisateur de devoir passer d’un chapitre à l’autre pour avoir l’ensemble de sa réponse.

Le succès de votre produit dépend aussi de la façon dont il est documenté…

by Carole Brochard, responsable Touch of Content.