Pourquoi personne n’aime vraiment documenter en entreprise
On explique souvent l’absence de documentation par le manque de temps. Par la pression. Par la flemme. Par l’outillage. Tout ça existe.
Mais ce n’est pas le nœud.
Le vrai problème, c’est que documenter, au sens strict, dérange. Pas parce que c’est difficile d’écrire. Parce que ça rend visible ce que beaucoup préfèrent laisser implicite. Et parce que ça oblige à assumer des décisions qui, dans la vraie vie, ne sont pas toujours propres.
De quelle “documentation” on parle, exactement
Quand on parle de documentation en entreprise, on mélange souvent trois choses.
Il y a la documentation technique, celle qu’on met sur le dos des développeurs. Les README, les schémas, les conventions, les choix d’implémentation. Elle est utile, mais elle sert d’abord à faire tourner le code et à permettre à quelqu’un d’autre de reprendre.
Il y a la documentation utilisateur, celle qu’on produit parce qu’il faut bien expliquer “comment ça marche”. Elle arrive souvent en bout de chaîne, parce que la vérité c’est qu’on n’a pas eu le temps avant, ou qu’on a attendu que le produit se stabilise. Elle devient un livrable, parfois une obligation contractuelle, parfois un pansement.
Et puis il y a celle dont je parle ici, celle qu’on évite le plus : documenter le projet globalement.
Pas la technique. Pas le manuel. Mais la mécanique du projet : les décisions, les arbitrages, les hypothèses, les renoncements, les raisons qui ont conduit à choisir cette option plutôt qu’une autre. Ce qui était vrai à l’instant T. Ce qu’on savait. Ce qu’on ne savait pas. Ce qu’on a ignoré volontairement.
Cette documentation-là ne se fait pas “à la fin”. Elle se fait pendant. Et c’est précisément pour ça qu’elle pose problème.
Documenter un projet, c’est rendre les décisions opposables
Une documentation de projet utile ne cherche pas à être élégante. Elle cherche à être explicite.
Elle permet, des semaines ou des mois plus tard, de répondre sans roman à des questions basiques : pourquoi on a fait ça comme ça, et pas autrement ? Qu’est-ce qu’on a essayé d’éviter ? Qu’est-ce qu’on a accepté de dégrader ? Qui portait l’arbitrage ?
Dès que ces réponses sont écrites, elles deviennent opposables. Pas au sens juridique. Au sens humain.
On ne peut plus se contenter d’un “on avait dit”. On ne peut plus rejouer l’histoire selon l’audience. On ne peut plus prétendre qu’il n’y avait pas d’alternative. On peut revenir au texte, et dire : voilà ce qui a été acté, voilà dans quel contexte.
Et ça, dans beaucoup d’organisations, c’est vécu comme une perte de liberté.
Le flou est souvent un outil, pas une maladresse
Le flou a une mauvaise réputation. On le présente comme un manque de rigueur, une immaturité, un défaut de méthode.
En pratique, le flou est souvent fonctionnel.
Il permet de garder plusieurs options ouvertes sans le dire. Il évite de cristalliser un désaccord. Il offre une porte de sortie si la décision tourne mal. Il protège les relations, les égos, les équilibres internes.
Une phrase volontairement ambigüe en comité a un pouvoir énorme : chacun y met ce qu’il veut. Et si ça dérape, personne n’est clairement responsable. On peut toujours dire que “ce n’est pas ce qui avait été compris”.
Documenter un projet, c’est réduire cette zone de confort. C’est enlever l’amortisseur. Donc c’est normal que ça résiste.
La mémoire sélective réécrit l’organisation en permanence
Il y a aussi un phénomène plus banal, plus humain : la mémoire collective se reconstruit.
Avec le temps, on oublie les contraintes initiales. On gomme les hésitations. On remplace les bricolages par un récit cohérent. On transforme un compromis de circonstances en choix stratégique. On relit le passé avec les lunettes du présent.
Ce n’est pas forcément malveillant. C’est souvent une manière de tenir debout.
Sauf que la documentation de projet, quand elle existe, casse cette réécriture permanente. Elle rappelle que la décision a été prise sous contrainte. Qu’on a tranché sans être sûr. Qu’on a changé d’avis. Que l’alignement n’était pas complet. Que la rationalité est parfois arrivée après.
C’est utile. Mais c’est inconfortable.
Ce que la documentation révèle, au-delà du projet
Documenter un projet, ce n’est pas seulement “capturer de l’information”. C’est aussi rendre visibles des rapports de force.
Quand les décisions sont tracées proprement, on voit qui arbitre réellement. Qui pousse pour aller vite. Qui demande de la qualité sans donner les moyens. Qui bloque sans l’assumer. Qui contourne les processus. Qui est exposé, et qui ne l’est jamais.
Ce n’est pas un procès. C’est un miroir.
Et personne n’aime beaucoup les miroirs quand ils montrent autre chose que l’image qu’on veut donner.
Documenter quand même, mais en acceptant ce que ça implique
Si on comprend que la documentation de projet est un sujet politique et culturel, on arrête de croire qu’un outil ou un template va régler le problème.
Documenter un projet, c’est accepter trois choses simples, et difficiles.
D’abord, accepter l’imperfection des décisions. Une décision écrite ne sera pas “belle”. Elle sera datée, contextualisée, discutable.
Ensuite, accepter que la transparence crée de la responsabilité. Écrire “on a fait ce choix parce qu’on n’avait pas le temps” est sain. Mais ça oblige à assumer la contrainte, et parfois à la nommer.
Enfin, accepter que ça crée une dette. Une trace écrite doit être amendée quand on change de direction. Elle doit être contredite proprement. Elle doit vivre.
Ce n’est pas un idéal. C’est un compromis. Un choix de clarté minimale dans un monde qui fonctionne souvent au flou, à l’implicite, et à la réécriture.
Et c’est probablement pour ça que, malgré les discours, beaucoup d’organisations préfèrent demander une doc technique aux devs, ou une doc utilisateur en bout de chaîne, plutôt que de documenter ce qui compte vraiment : le projet lui-même, pendant qu’il se fait.