Faut-il documenter son système d'information ?

La documentation du système d'information : le serpent de mer

La documentation des applicatifs métiers en entreprise est un véritable serpent de mer. Lorsque l'on interroge différents interlocuteurs informatiques ou métier, une phrase revient souvent : "La documentation, c'est important, mais ce n'est pas prioritaire. D'ailleurs il n'est pas sûr que la nôtre soit à jour".
Voici résumé en quelques mots tout le paradoxe d'un chantier perçu comme compliqué à mettre en œuvre - notamment pour la maintenance des documents, mais vu comme essentiel au maintien des connaissances autour du système d'information.

Pas de documentation ? Vous êtes exposés à de nombreux risques

En effet, ne pas avoir de documentation ou de système de maintien des connaissances induit un certain nombre de risques et de coûts liés à la redondance de tâches ou travaux que cela induit :

de nombreux aller-retours entre les populations métier qui expriment leurs besoins de fonctionnement et les populations techniques qui doivent adapter ou coder le logiciel.
du bouche-à-oreille voire téléphone arabe sur ce que sait faire le logiciel entre les utilisateurs, voire les chefs de projet informatiques fraîchement débarqués sur une application. Il n'y a pas de voix officielle sur le "comment ça marche" !
des coûts de support humain pour former et informer les utilisateurs. Demandez aux nombreux chefs de projet qui passent plus de temps à faire du support que du projet.
une perte de connaissances sur ce que sait faire le logiciel. Résultat : les utilisateurs demandent souvent des évolutions du logiciel... qui existent déjà. Ces évolutions viennent gonfler l'enveloppe des prestataires en charge de la Tierce Maintenance Applicative (TMA) : des coûts superflus !
un impact ressources humaines : il est de plus en plus difficile de se séparer de l'expert de tel ou telle application qui a toute la connaissance en tête. Cet expert quant à lui voit sa frustration de ne pas pouvoir changer de poste augmenter au fil des années !

Aujourd'hui, à l'heure de la numérisation de toutes les fonctions de l'entreprise, toutes les règles et procédures métiers en règles de logiciels informatiques sont transcrites à marche forcée en algorithmes automatisés.
Le risque ne porte plus seulement sur l'informatique, mais bien sur le patrimoine et le savoir-faire de l'entreprise.

Et pourtant, elle existe !

Et pourtant, les documents sont nombreux autour des systèmes d'information :

cahier des charges,
spécifications (en tous genres : générales, détaillées, règles de gestion, ...),
documents d'architecture,
cahiers de tests,
documents d'exploitation,
documents de formation,
manuels utilisateurs,
procédures, modes opératoires,
...

Au vu de cette liste, il paraît difficile de dire que cette documentation ne puisse pas être utile et riche.
Des centaines, voire des milliers de pages, du temps humain qui a coûté de l'argent et qui ne sert à rien ?
Pas tout à fait.
Il faut considérer que bien souvent, l'essentiel de cette documentation est générée au moment des projets de mise en œuvre ou de migration de ces nouveaux logiciels. Elle sert de support de communication (et il y en a besoin) entre les populations fonctionnelles et les populations techniques.
Il n'est pas rare de voir en préambule de projets de mise en œuvre de nouvelles applications des travaux de "rétro-documentation" où une équipe de technico-fonctionnels lit le code de logiciels pour les retranscrire en langage compréhensible. Cet exercice louable a cependant ses limites : c'est souvent du "one-shot", un instantané non maintenable dans le temps, et malgré tout la retranscription reste dans une logique applicative voire algorithmique. Dur d'y retrouver par exemple les règles de calcul de votre logiciel de facturation.
D'autre part, la surabondance d'information nuit à son accessibilité. Il y en a trop, donc on ne sait pas comment y rentrer. Même si tout cela est bien organisé et rangé dans des "répertoires sur le serveur partagé" ou sur l'Intranet il manque les 2 ou 3 documents clés qui permettent de guider les différentes personnes dans la forêt d'informations. Bien souvent ces sentiers balisés ne sont pas maintenus ou n'existent pas.
Le gros volume de documentation est également un frein psychologique lorsqu'on aborde le sujet de la maintenance. Et l'on peut aisément comprendre pourquoi.

Voici donc le paradoxe : il existe bien des documents, mais :

les acteurs du SI ont souvent l'impression qu'il n'y en a pas car ils ne savent pas y naviguer,
les documents ne sont pas adaptés à ceux qui les lisent
le volume de documentation fait peur et a un impact sur sa maintenance.

Repenser la forme et l'usage de la documentation

Face à ces constats, pourquoi ne pas envisager de repenser cette documentation ?
A côté de cela, d'autres facteurs rentrent en ligne de compte :

à l'heure des e-mails, des tweets, et du tout numérique, faut-il conserver des documents de centaines de pages ? La consommation d'information doit être rapide. Le temps est devenu précieux en entreprise. Les messages courts sont à privilégier.
les pratiques collaboratives (la fameuse Entreprise 2.0, 3.0, 4.0...) font que la connaissance ne doit peut être plus reposer sur certains experts mais plutôt sur une communauté de personnes (d'utilisateurs ?).

Il s'agit de formidables opportunités pour aborder le sujet de la documentation sous un autre angle :

penser information et connaissance plutôt que document. Un document n'est qu'un contenant. L'important reste le contenu ! Peu importe qu'il soit diffusé dans un Word, un pdf, un e-mail, un tweet... car il faut que l'information soit accessible par n'importe quel moyen d'accès et n'importe quand : Intranet, PC, mobile, tablette...
se demander qui consomme cette information et quand. A quoi sert-elle ? A qui sert-elle ? Quand sert-elle ? Il s'agit bien de dire : quels sont mes cas d'usage de la documentation ?
Et non pas "Nous allons documenter toutes les fonctions et règles du logiciel"
Dans la liste de documents informatiques cités plus haut certains ne sont utiles qu'en début de projet, d'autres à la fin. Les spécifications sont destinées aux développeurs, les manuels de formation aux utilisateurs, etc.
Nous pouvons même descendre plus finement dans cette analyse : quelle information est nécessaire pour un chef de service qui crée une commande d'achat dans son ERP ? Quels documents pour aider un commercial en mobilité afin qu'il utilise plus efficacement son CRM ?
mettre en place un système de feedback sur la documentation entre celui qui la produit et celui qui la consomme. Il faut en quelque sorte la "tester" afin de vérifier qu'elle est bien adaptée en terme de fond et de forme à celui qui va la consulter. C'est particulièrement vrai pour les non informaticiens : les utilisateurs ! Dans leur cas la documentation doit leur servir à effectuer leur travail (procédures) plutôt que de se concentrer uniquement sur l'applicatif (modes opératoires).
ouvrir le contenu au collaboratif. A travers les outils (portails collaboratifs, wiki, réseaux sociaux d'entreprise), mais aussi en changeant les mentalités : ce n'est plus celui qui écrit qui est propriétaire de l'information. Mais également celui qui la consommer. Alors pourquoi ne pas lui donner le droit de la modifier ou à minima de la commenter ? Il s'agit de créer une(des) communauté(s) autour de votre documentation.
faciliter la maintenance en identifiant un noyau limité de documents (règle des 80/20 : 20 % des documents peuvent couvrir 80 % des besoins) et en se forçant à ne maintenir que ceux-là. Le reste peut être géré à la demande par exemple sous forme de FAQ, questions/réponses ou sur un réseau social d'entreprise.

Ainsi, la question n'est peut être pas "Faut-il documenter son système d'information ?"
L'enjeu ne serait-il pas plutôt "Comment organiser un système collaboratif d'information autour de mon système d'information ?"