Documentation projet: éviter le trop et le trop peu

Documenter juste assez, juste à temps: le Minimum Viable Documentation aide les chefs de projet à éviter la sous-documentation comme la bureaucratie inutile.

Deux scénarios se répètent avec une régularité frappante dans les projets mal documentés. Dans le premier, un chef de projet part en congé et personne ne sait où en est le projet, quelles décisions ont été prises ni pourquoi. Dans le second, un dossier SharePoint contient 200 fichiers méticuleusement classés, dont aucun n’a été ouvert depuis six mois. Les deux situations sont des échecs de documentation, et elles sont plus fréquentes qu’on ne le pense.

Trouver le juste milieu entre ces deux extrêmes est une compétence à part entière du chef de projet. Cette compétence porte un nom dans le monde agile: le Minimum Viable Documentation (MVD), c’est-à-dire la documentation minimale viable.

Pourquoi documenter reste indispensable

L’Agile Manifesto de 2001 a popularisé la formule “working software over comprehensive documentation”, souvent interprétée comme une permission de ne rien écrire, ce qui est un contresens: le manifeste ne dit pas que la documentation est inutile, il dit qu’elle ne doit pas se substituer à un produit fonctionnel. Scott Ambler, un des contributeurs du framework Disciplined Agile, a nuancé cette position en parlant de documentation “just barely good enough” (JBGE): suffisante pour remplir son rôle, sans excès. Ce rôle est multiple: la documentation assure le transfert de connaissance lorsqu’un membre de l’équipe est remplacé ou qu’un nouveau collaborateur rejoint le projet. Elle maintient la cohérence entre les différentes parties prenantes (stakeholders) en fixant par écrit les décisions, les hypothèses et les périmètres convenus. Elle satisfait les exigences de traçabilité imposées par certains secteurs réglementés. Elle constitue, enfin, la mémoire institutionnelle de l’organisation, celle qui permet de ne pas reproduire les mêmes erreurs d’un projet à l’autre.

Selon une étude du PMI, les organisations qui formalisent la capture et le partage des connaissances de projet atteignent leurs objectifs plus fréquemment que celles qui s’en remettent à la mémoire informelle. Le mécanisme est simple: les décisions documentées se contestent moins, les risques identifiés par écrit s’oublient moins et les retours d’expérience consignés se transmettent mieux.

Les symptômes de la sous-documentation

Un projet sous-documenté se reconnaît à plusieurs signaux. Les mêmes questions reviennent en réunion parce que les réponses précédentes n’ont été consignées nulle part. Les décisions sont contestées des semaines après avoir été prises, faute de trace écrite validée. La passation de projet, lors d’un changement de chef de projet ou en fin de phase, prend un temps disproportionné parce que tout repose sur la transmission orale. Les audits, internes ou externes, révèlent des lacunes de traçabilité qui auraient pu être évitées avec un minimum de formalisme.

Le coût de la sous-documentation est rarement visible dans l’immédiat. Il se manifeste en différé, sous forme de temps perdu, de conflits évitables et de connaissances perdues. C’est précisément ce qui le rend insidieux: l’absence de documentation ne fait pas échouer un projet du jour au lendemain, elle l’affaiblit progressivement.

Les symptômes de la sur-documentation

L’excès inverse est tout aussi problématique, quoique différemment. La sur-documentation se caractérise par une accumulation de documents que personne ne lit, ne met à jour ni ne consulte. Le registre des risques (risk register) fait 40 pages et date de trois mois. Les comptes-rendus de réunion décrivent des activités plutôt que des décisions. Le plan de projet a été mis à jour pour la dernière fois il y a six semaines.

Le piège de la documentation morte est que sa simple existence rassure. Elle donne l’impression d’un projet bien géré, alors qu’en réalité les documents ne reflètent plus l’état du projet. Un registre des risques obsolète est plus dangereux que l’absence de registre, parce qu’il crée un faux sentiment de maîtrise. L’équipe croit que les risques sont gérés alors qu’ils ne le sont plus.

La sur-documentation consomme aussi un temps considérable. Chaque heure passée à mettre à jour un document que personne ne consulte est une heure retirée à la gestion effective du projet. Le chef de projet qui passe plus de temps à décrire le travail qu’à le piloter a inversé ses priorités.

Comment appliquer le MVD en pratique

Le concept de Minimum Viable Documentation repose sur un test simple: chaque document doit remplir au moins une fonction concrète parmi le transfert de connaissance, la cohérence d’équipe, la conformité réglementaire et la mémoire institutionnelle. Si un document ne remplit aucune de ces fonctions, il ne devrait pas exister.

Trois principes opérationnels en découlent. La source unique de vérité, d’abord: chaque information importante ne doit exister qu’à un seul endroit. Les copies divergentes sont la première cause de documentation peu fiable. Un registre des risques dans un fichier Excel et un autre dans l’outil de gestion de projet garantissent que l’un des deux sera faux.

La convention de nommage ensuite: un format cohérent permet de retrouver un document sans parcourir des arborescences confuses. C’est un investissement de cinq minutes qui en économise des centaines.

La revue régulière, enfin: un document non relu depuis trois mois est probablement obsolète. Intégrer une vérification rapide de la documentation existante à chaque jalon (milestone) du projet garantit que les documents restent utiles et à jour.

Le juste niveau dépend du contexte

Le volume de documentation nécessaire n’est pas le même pour tous les projets. Un projet de trois personnes sur huit semaines peut fonctionner avec une charte de projet d’une page, un tableau de suivi et un registre de décisions. Un programme pluriannuel impliquant plusieurs départements et des obligations réglementaires exigera un corpus documentaire bien plus étoffé.

Les facteurs déterminants sont la taille de l’équipe, le turnover anticipé, la complexité du projet, les exigences contractuelles ou légales et la méthodologie utilisée. Un projet agile produit sa documentation de façon incrémentale, au fil des itérations, tandis qu’un projet en cascade la concentre dans les phases initiales. Dans les deux cas, le principe reste le même: documenter ce qui sert, éliminer ce qui encombre.