Chaque projet génère un volume considérable de connaissances: décisions techniques, arbitrages de périmètre, retours d’expérience, solutions à des problèmes imprévus. La majeure partie de ces connaissances disparaît à la fin du projet. Les membres de l’équipe changent d’affectation, les documents sont archivés dans des répertoires que personne ne consultera et les leçons apprises restent dans la mémoire de ceux qui les ont vécues, jusqu’à ce qu’ils quittent l’organisation.
Un problème reconnu mais rarement traité
Le PMBOK du PMI identifie la gestion des connaissances comme un processus formel du management de projet. Le principe est explicite: les organisations doivent capitaliser les connaissances générées par leurs projets pour améliorer les suivants. Dans la pratique, ce processus est l’un des plus négligés. La pression pour démarrer le projet suivant, le manque de temps en fin de projet et l’absence de système structuré font que la capitalisation reste une intention plutôt qu’une réalité.
Le coût de cette perte est difficilement mesurable mais réel. Les mêmes erreurs se répètent d’un projet à l’autre. Les estimations restent approximatives parce que les données des projets précédents ne sont pas exploitables. Les nouveaux membres d’équipe passent des semaines à reconstituer un contexte que leurs prédécesseurs maîtrisaient.
Le savoir qui part avec les personnes
La distinction entre connaissances explicites et tacites, formalisée par Nonaka et Takeuchi dans leur modèle SECI, éclaire la nature du problème. Les procédures, modèles et registres de décisions peuvent être documentés. En revanche, savoir qu’un fournisseur nécessite un suivi hebdomadaire, que tel processus de validation prend systématiquement deux fois le temps annoncé ou que la vraie décision se prend en aparté plutôt qu’en comité: ces connaissances résident dans l’expérience des individus et aucun document ne peut les capturer intégralement.
C’est précisément ce type de savoir qui a le plus de valeur en projet et qui est le plus vulnérable. Quand un membre clé de l’équipe part, la question “quelles connaissances critiques devons-nous transférer avant son départ?” devrait figurer au même niveau de priorité que “quels livrables doit-il terminer?”.
Quatre pratiques concrètes de capitalisation
La capitalisation des connaissances projet ne nécessite pas d’outil sophistiqué. Elle demande de la discipline et quelques pratiques intégrées au déroulement normal du projet.
Le registre des décisions (decision log) consigne chaque décision significative avec son contexte, ses alternatives envisagées et la justification du choix retenu. Six mois plus tard, quand quelqu’un demande “pourquoi a-t-on choisi cette option?”, la réponse existe dans un document consultable plutôt que dans la mémoire d’un chef de projet qui a peut-être changé de poste.
Les rétrospectives régulières, pratiquées en agilité mais tout aussi pertinentes en approche prédictive, capturent les leçons apprises pendant le projet plutôt qu’à sa clôture. Une rétrospective mensuelle de trente minutes produit des enseignements bien plus riches qu’un bilan de projet rédigé sous pression après la livraison.
L’onboarding structuré des nouveaux membres d’équipe formalise le transfert de connaissances tacites. Un guide d’intégration projet (contexte, parties prenantes clés, décisions passées, pièges connus) réduit de plusieurs semaines le temps nécessaire à un nouvel arrivant pour devenir opérationnel.
La documentation des solutions techniques, même minimale (un paragraphe expliquant pourquoi telle approche a été choisie et quelles alternatives ont été écartées), évite de résoudre deux fois le même problème.
Le piège de la documentation exhaustive
La tentation naturelle est de tout documenter. Une documentation exhaustive que personne ne maintient ni ne consulte est pire qu’une documentation sommaire mais vivante. Le critère pertinent n’est pas le volume mais l’accessibilité: la bonne connaissance doit être trouvable par la bonne personne au bon moment.
Les approches modernes de gestion des connaissances (bases de connaissances avec liens bidirectionnels, wikis internes, graphes de connaissances) tentent de résoudre ce problème d’accessibilité en reliant les informations par leur sens plutôt que par leur emplacement dans une arborescence de dossiers. L’outil importe moins que le principe: une connaissance non retrouvable est une connaissance perdue.
Protéger le savoir critique
Le risque le plus sérieux en gestion des connaissances projet est la concentration du savoir chez un nombre restreint d’individus. Quand une seule personne maîtrise un aspect technique, un processus métier ou une relation fournisseur, le projet est exposé à un risque de personne (key person risk) qui devrait figurer dans le registre des risques.
La réponse n’est pas uniquement documentaire. Le binômage (pair working), la rotation des responsabilités et les revues croisées sont des mécanismes de transfert de connaissances tacites qui fonctionnent là où la documentation seule ne suffit pas. Ces pratiques ont un coût apparent (deux personnes sur une même tâche), mais elles construisent une résilience organisationnelle dont la valeur se révèle le jour où un départ imprévu menace la continuité du projet.