Les éditeurs de logiciels ont de moins en moins de ressources pour créer la documentation orientée utilisateur

Dans l’évolution de la documentation utilisateur :

  • les réductions de coûts ont mené à une diminution de l’effort documentaire
  • la plupart du temps, la documentation s’est révélée être difficile à maintenir
  • le retour sur investissement, et la vraie valeur ajoutée restent flous pour la plupart des (petits) éditeurs
  • recruter des rédacteurs techniques est un problème pour les éditeurs de petite et moyenne taille

D’un autre côté, beaucoup d’utilisateur se passent de documentation. D’après notre expérience, cela ne signifie pas qu’ils peuvent se débrouiller seuls, tout le temps. Souvent, l’absence de documentation est compensée par plus de demandes support et la répétition de tickets.

C’est un paradoxe : il y a surement un besoin, mais il est rarement correctement satisfait, et dans ce cas, la frustration apparaît de chaque côté : utilisateurs et éditeur.

Comment pouvons-nous surmonter ou résoudre ce paradoxe ? Analysons quelques éléments de réponse pour savoir si nous pouvons redonner de la valeur à la documentation et identifier un retour sur investissement plus clair et rapproché dans le temps.

Les logiciels ont-ils toujours besoin d’une documentation complète ?

Non.

L’exhaustivité n’existe plus depuis longtemps. Comment pouvait-on qualifier ce concept ? C’était sujet à interprétations et concernait surtout la relation client – fournisseur dans laquelle l’impression d’un début de retour sur investissement se base  sur le volume. De plus, couvrir chaque aspect d’un logiciel dans sa documentation n’a pas nécessairement de sens.

Quel est l’essentiel ?

Notre réponse est de rendre la documentation aussi contextuelle que possible.

En savoir plus sur la documentation contextuelle

Faut-il externaliser la documentation ?

L’externalisation présente des avantages et des inconvénients. C’est une décision stratégique. Si vous devez prendre des rédacteurs techniques pour votre documentation, nous recommandons de les intégrer dans vos équipes.

Externaliser votre documentation, c’est en quelque sorte fuir les responsabilités. Toute la phase de définition de la stratégie éditoriale est sous al responsabilité du responsable produit ou du chef de projet. Pendant la conception de la documentation, la coordination entre experts, développeurs et rédacteurs est un processus continu. Aujourd’hui, nous gérons ceci via des sprints agile. les rédacteurs peuvent être externalisés s’ils ont facilement accès au travail.

La documentation doit-elle être écrite par des rédacteurs techniques spécialisés ?

Pas toute la documentation. Impliquer d’autres acteurs est essentiel : équipes support, responsables produit / chefs de projet, et même développeurs et chefs d’équipes. la documentation n’est pas une chose abstraite et les rédacteurs ne peuvent pas travailler seuls de leur côté. Ils font partie d’une matrice. Que vous en ayez besoin ou non dépend de la cohérence finale, du style et de la rapidité avec laquelle vous souhaitez obtenir la documentation.

Les équipes de rédacteurs doivent-elles travailler en interne ?

Notre préférence va pour le « oui ».  Les cycles de conception des logiciels sont courts en général. Les méthodes agile contribuent à cela. Travailler en interne ne signifie plus forcément embaucher. Donc oui, obtenir une bonne intégration entre le support, le développement et les rédacteurs, surtout quand on sait qu’une partie de la documentation produite est destinée aux équipes support, est un objectif important.

Comment fournir l’essentiel ?

  1. Concentrez-vous sur les besoins contextuels in-situ. Identifiez les morceaux d’interface qui peuvent réutiliser ce contenu.
  2. Identifiez comment apporter une valeur ajouté en construisant des faqs, des procédures courtes (how-to’s).
  3. Expliquer les concepts.

L’essentiel, c’est le strict minimum, et non pas un corpus détaillé. Testez la documentation et procédez par itération jusqu’à obtenir une bonne adéquation entre les besoins utilisateur et le contenu. Puis arrêtez et attendez les premiers retours.