L'expertise figée: pourquoi un chef de projet ERP senior risque de cesser de progresser

Après dix ou quinze ans de carrière, un chef de projet ERP a généralement tout vu: le client qui ne sait pas formuler son besoin, le go-live qui dérape la veille du week-end, l'utilisateur clé qui sabote discrètement le changement, le sponsor qui change d'avis trois semaines avant la mise en production. Cette accumulation d'expérience est précieuse, mais elle dissimule un risque rarement nommé: le plafond invisible de l'expérience. On continue de bien faire son travail, on ne se trompe plus beaucoup, mais on a cessé d'apprendre. Le danger n'est pas l'échec visible, c'est la routine qui se fait passer pour de l'expertise.

Les signes discrets du point mort de la progression

Cette situation ne s'annonce pas par une crise. Elle s'installe progressivement, et c'est précisément ce qui la rend difficile à détecter.

Un premier signal tient à la vitesse de résolution des problèmes: les arbitrages deviennent plus rapides, mais aussi plus automatiques. Le chef de projet reconnaît un schéma déjà rencontré et applique la solution qui a fonctionné la dernière fois, sans nécessairement vérifier si le contexte est réellement identique. La rapidité d'exécution masque une baisse de la vigilance analytique.

Un deuxième signal se loge dans la délégation. Un chef de projet expérimenté délègue naturellement davantage qu'un junior, c'est sain. Mais il existe une délégation par lassitude, différente de la délégation par confiance: on ne transmet plus un sujet parce qu'on estime que l'équipe est prête, mais parce qu'expliquer une nouvelle fois le même point devient fastidieux. Ce qui se présente comme de la délégation relève en réalité d'un désengagement qui s'installe pas à pas.

Un troisième signal, plus subtil, concerne la curiosité fonctionnelle. Face à une demande client inhabituelle, le réflexe naturel devrait être de chercher à comprendre ce qui rend ce cas particulier. En condition d’expertise figée, le réflexe devient au contraire de ramener le cas à une catégorie connue, quitte à forcer un peu la comparaison, pour éviter l'effort d'une analyse neuve.

Pourquoi ce risque est amplifié dans l'écosystème ERP

Ce phénomène n'est pas propre à la gestion de projet ERP, mais il y prend une intensité particulière, pour une raison simple: l'éditeur continue d'avancer pendant que le chef de projet, lui, peut choisir de s'arrêter.

Microsoft Business Central évolue par vagues semestrielles. De nouvelles fonctionnalités, de nouveaux modules, de nouvelles pratiques de configuration apparaissent régulièrement, et la réglementation qui encadre les implémentations, (fiscale, douanière, comptable) bougent elles aussi sans prévenir. Un chef de projet qui plafonne sur sa méthode de pilotage peut, sans s'en rendre compte, accumuler un retard sur le fond technique et fonctionnel qu'il est censé arbitrer. Le risque n'est pas seulement individuel: un pilotage qui repose sur une compréhension fonctionnelle datée finit par produire des recommandations dépassées, présentées avec l'assurance que donne l'ancienneté.

Cette dynamique est aggravée par le fait que l'expérience senior inspire confiance, y compris à celui qui la détient. Plus on est perçu comme l'expert dans la salle, moins on est challengé, et moins on est challengé, moins on est poussé à se remettre à jour.

Les mécanismes invisibles qui installent la zone de confort

Trois mécanismes entretiennent silencieusement cette stagnation.

Le premier est le statut acquis. Une fois reconnu comme référent sur un domaine, il devient inconfortable d'admettre publiquement une lacune sur ce même domaine. Cet inconfort pousse à éviter les situations où l'ignorance pourrait apparaître, ce qui réduit mécaniquement les occasions d'apprendre.

Le deuxième est la charge de travail elle-même. Un chef de projet senior gère souvent plusieurs dossiers en parallèle, et le temps disponible pour explorer un sujet sans enjeu immédiat, (une nouvelle fonctionnalité, une pratique encore expérimentale) se réduit au profit de l'urgence opérationnelle. La stagnation devient alors une conséquence presque mécanique de la charge, sans qu'aucune décision consciente n'ait été prise.

Le troisième est la nature même du métier de pilotage. Contrairement à un rôle technique pur, la fonction de chef de projet récompense la stabilité, la prévisibilité, la capacité à rassurer. Ces qualités, indispensables pour le client, peuvent involontairement décourager la prise de risque intellectuelle qui permettrait de continuer à progresser.

Relancer délibérément la courbe d'apprentissage

Sortir d'un plateau de compétence ne se produit pas par accident, cela suppose une décision volontaire, et quelques leviers concrets permettent de la mettre en œuvre.

Le premier consiste à sortir périodiquement de son périmètre habituel: accepter une mission sur un secteur d'activité moins familier, un type de projet de taille différente, un contexte géographique ou réglementaire moins connu. Le multilinguisme et le profil multi-pays constituent ici un atout naturel, à condition de ne pas se limiter aux contextes déjà maîtrisés.

Le deuxième levier consiste à se replacer volontairement en position d'apprenant sur un sujet précis et circonscrit (une nouvelle brique de Business Central, une pratique de configuration encore peu répandue, l'usage de l'intelligence artificielle dans le pilotage de projet). L'objectif n'est pas de tout reprendre à zéro, mais de retrouver, sur un point délimité, l'inconfort productif du débutant.

Le troisième levier est le mentorat inversé: organiser, même de manière informelle, des moments où un junior explique au senior une pratique récente, un outil, une fonctionnalité qu'il maîtrise mieux. Ce renversement des rôles, loin de fragiliser l'autorité du chef de projet, la renforce généralement, car il démontre une capacité à apprendre qui rassure davantage qu'une façade de maîtrise totale.

Conclusion

Un point mort de progression n'est pas un échec, c'est une étape naturelle de toute trajectoire professionnelle longue. Le risque ne réside pas dans son existence, mais dans le fait de l'ignorer. Un chef de projet ERP qui identifie consciemment ce moment dispose d'un avantage: il peut choisir de transformer une stagnation silencieuse en point de relance, en redéfinissant volontairement ce qu'il ne maîtrise pas encore. Dans un écosystème comme celui de Business Central, où l'éditeur et la réglementation n'attendent personne, cette capacité à se remettre soi-même en mouvement devient, avec le temps, une compétence à part entière, peut-être la plus stratégique de toutes.