Baniere

Knowledge Management en Projet ERP : Comment Éviter d'Être l'Otage d'un Sachant Unique

Caledar Icon Publié le 23/11/2025 | 
Gestion de projets | 
Views Icon Billet vue 47 fois | 
Time Icon Lu en 7,16Mn
Cet article à été également écrit en Eng et accessible ici:Knowledge Management in an ERP Project: Strategies to Outsmart the Single Expert Trap

Image Pexels.com
Le savoir partagé, c'est le pouvoir multiplié
Le savoir partagé, c'est le pouvoir multiplié

Index

Expand


​La gestion d'un projet de système d’information (SI), tel qu'un projet ERP, repose fortement sur la disponibilité des ressources humaines.
La Gestion des Connaissances (Knowledge Management ou KM) est un processus fondamental qui consiste à utiliser les connaissances existantes et à en acquérir de nouvelles pour atteindre les objectifs du projet.
​Dans un environnement de projet informatique, où la démarche requiert une continuité dans l’équipe de maîtrise d’œuvre, le chef de projet doit mettre en place une stratégie active pour garantir la pérennité du savoir et éviter que le projet ne soit compromis.

​Le risque du sachant unique et le vol de connaissances

​La connaissance se divise en deux catégories principales : la connaissance explicite (facilement codifiable par des mots ou des documents) et la connaissance tacite (personnelle, difficile à exprimer, résidant dans l'expérience et le "savoir-faire" des experts).

​Le piège du "sachant unique" se manifeste lorsque le projet dépend excessivement de cette connaissance tacite détenue par un seul individu ou un petit groupe.

Ce risque est considérablement aggravé par plusieurs facteurs inhérents aux projets :

​Renouvellement fréquent du personnel de l'équipe projet:

Une main-d’œuvre de plus en plus mobile et temporaire rend nécessaire un processus plus rigoureux pour le transfert des connaissances. Le chef de projet doit anticiper le risque induit par la fuite du savoir ou du savoir-faire, notamment accentué par l'arrivée à la retraite des générations nombreuses et l'accroissement de la rotation du personnel.

Perception de la connaissance comme pouvoir:

Le savoir est souvent perçu comme une arme de pouvoir ou d'influence. La transmission de cette connaissance peut être assimilée à une perte de capacité d’influence, ce qui génère une réticence au partage au sein des équipes. Si les gens ne sont pas encouragés à partager ce qu’ils savent, même les meilleurs outils de Knowledge Management (KM) ne fonctionneront pas.

Équipe mal définie ou utilisateurs clés non assignés:

L'absence d'une définition claire des rôles, des responsabilités et des compétences nécessaires rend difficile l'identification des détenteurs de connaissances et le transfert ciblé. Le manque d’interlocuteurs ayant pouvoir de décision est un facteur de risque pour le projet.

Dépendance à la connaissance tacite :

Le risque se manifeste lorsque le projet repose trop sur le savoir personnel, l'expérience et le " savoir-faire » d'un seul individu ou d'un petit groupe, car cette connaissance est difficile à formaliser et à partager.

​La gestion des connaissances comme apprentissage organisationnel

​Le processus de gestion des connaissances du projet vise non seulement à exploiter les connaissances organisationnelles préalables, mais aussi à capitaliser les retours d’expérience tirés du projet disponibles pour les futurs travaux.
​Pour cela, le chef de projet doit mettre en œuvre une combinaison d'outils et de techniques de gestion des connaissances (centrés sur les échanges entre les personnes) et de gestion de l'information (codification des connaissances explicites).

Impliquer l'équipe et les métiers pour le partage

​La gestion des connaissances nécessite la création d'une atmosphère de confiance pour favoriser le partage.

  • Désigner les référents fonctionnels (Key Users) : Le client doit désigner et impliquer les experts métier de chaque département dès la phase de cadrage.
  • Encourager la coopération et l'appropriation : Le chef de projet doit dynamiser la coopération et le libre échange, car il ne peut pas tout savoir. L'équipe doit se sentir mobilisée autour de l'appropriation et du développement de ses propres connaissances.
  • Gérer l'implication des métiers (Utilisateurs Clés) : Les utilisateurs finaux sont des acteurs majeurs, force de validation et de proposition. Pour un projet ERP, une maîtrise d'ouvrage (MOA) doit être représentée par une ou plusieurs personnes ayant pouvoir de décision, disponibles et motivées. La participation des utilisateurs à la définition des besoins est cruciale. Le chef de projet (MOE) doit travailler à créer des conditions favorables à la mobilisation de son équipe, car si le projet est vécu comme une contrainte, l'implication en sera réduite.
  • ​Définir clairement les rôles et compétences : Analyser les compétences nécessaires à l’accomplissement des tâches et individualiser les objectifs. S'assurer que les membres de l'équipe possèdent les aptitudes requises; si ce n'est pas le cas, des actions proactives comme la formation ou le mentorat doivent être entreprises.

Formaliser, capitaliser et transférer le savoir

​Pour pallier l'instabilité des équipes et la dépendance au savoir tacite, la formalisation est vitale.
Cette formalisation passe par l’utilisation d’outils spécifiques:

  • ​Le référentiel documentaire unique : Les sources documentaires d'un projet sont nombreuses et variées : elles comprennent, entre autres, les notes prises lors des sessions d'analyse, les documents d'analyse fonctionnelle (Functional Requirements Document ou FRD), les comptes rendus d'atelier, les documents de présentation de maquettes, les supports de formation, ainsi que les cahiers de tests. Pour optimiser le partage et la consultation de ces connaissances explicites, l'utilisation d'une plateforme collaborative comme SharePoint est essentielle. Ce type de logiciel permet d'établir un référentiel unique avec une arborescence structurée et standardisée qui doit être maintenue de manière cohérente d'un projet à l'autre afin de faciliter la recherche et la capitalisation des informations.
  • L'utilisation de Onenote (https://onenote.cloud.microsoft/) en mode partagé au travers de Onedrive peut compléter SharePoint en servant d'espace de travail dynamique et flexible pour la documentation vivante (wikis, gestion des exigences, et notes de réunion). Tandis que SharePoint assure le stockage formel, sécurisé et auditable des documents finaux (spécifications signées et manuels validés), Onenote maximise l'agilité et la collaboration quotidienne de l'équipe projet. Son intégration à Teams et tous les logiciels de la suite office est un plus très intéressant. Ceux qui préféreraient une solution plus complète pour gérer un espace de travail partagé peuvent utiliser Notion (https://www.notion.com/).
  • ​Le registre des Retours d’Expérience : Ce document est malheureusement un outil très peu utilisé, visant à consigner les connaissances acquises (leçons apprises) tout au long du projet, succès comme difficultés, afin qu'elles puissent être exploitées pour améliorer les projets futurs. Il se distingue du Registre des Risques qui, lui, est un document proactif utilisé pour identifier, analyser, planifier des réponses et suivre les menaces et opportunités potentielles susceptibles d'affecter les objectifs du projet avant qu'elles ne se réalisent.

Ces outils ne sont qu'un support pour le stockage et la mise à disposition des informations ; ce sont les membres de l'équipe qui doivent les utiliser et les alimenter. Pour faciliter cette démarche, il est essentiel de mettre en place des événements ou des actions ciblées.

  • ​Les échanges informels structurés : Il est important d'intégrer des moments d'échanges informels comme les quick réunions (stand up meetings) ou les pauses café organisées aux habitudes de l’équipe projet. Ces moments de co présence sont des catalyseurs puissants de la connaissance tacite, permettant aux experts de partager leur "savoir faire" et leurs "astuces" dans un cadre moins contraignant que la réunion formelle.
  • ​Ateliers et retours d'expérience : Pour dégager les Retours d'Expérience et identifier les forces et faiblesses du projet, le recours à des ateliers, des entretiens spécifiques ou des réunions de type " Show & Tell » est un bon moyen de provoquer un échange d’information autour d’un thème du projet.

Leadership et attitude du chef de projet

​L'attitude du chef de projet est un facteur clé du maintien de la motivation et de la gestion des connaissances.

  • ​Être modélisant et délégatif : Le chef de projet doit admettre qu'il n'a pas besoin de tout connaître ni de tout faire. Il doit déléguer pour responsabiliser, transformant le sachant unique en facilitateur.
  • ​Adopter un style de management adapté : Le chef de projet doit adapter son style de leadership en fonction de la compétence de l'équipier pour une tâche donnée (directif, persuasif, participatif ou délégatif). En particulier, si la personne est très compétente (plus experte que le chef de projet), il doit pratiquer le management délégatif pour lui laisser l'autonomie et la créativité nécessaires.
  • ​Ne pas imposer la Knoledge Managment : Il faut éviter d'imposer un référentiel de connaissances par autorité hiérarchique, ce qui entraîne un manque de motivation et des informations élémentaires inutiles. Le chef de projet doit laisser son équipe s'approprier le référentiel.
  • ​Vigilance sur les facteurs d'échec : Le chef de projet doit être vigilant aux facteurs qui mènent à l'échec de la KM, tels que l'assimilation du référentiel à une contrainte ou un manque de stabilité des informations.

​En définitive, pour un projet ERP, la gestion des connaissances est un facteur important de diminution des risques de perte de connaissance. Le chef de projet, en tant que leader et fédérateur, assure la pérennité du savoir en créant un environnement collaboratif et méthodologique qui encourage le partage (tacite, y compris via les échanges informels, et explicite) et neutralise le risque de dépendance au savoir individuel et l'impact négatif du turnover.

Aidez le blogueur en donnant une note à cet article:
x x x x x