Des projets livrés dans les règles de l’art, adoptés par personne. La conduite du changement reste la variable d’ajustement que personne ne veut financer — jusqu’à ce qu’il soit trop tard.
Le projet a été livré dans les délais. Le budget a été respecté. Toutes les fonctionnalités demandées sont là, testées, validées. Le chef de projet a clôturé son plan, le prestataire technique a rendu ses livrables, la DSI a communiqué sur le go-live. Six mois plus tard, les utilisateurs contournent le nouvel outil, les anciens fichiers Excel circulent encore, et le management s’interroge sur le retour sur investissement. À quel moment a-t-on raté quelque chose ?
La réponse est presque toujours la même : dès le début, quand personne n’a vraiment pris en charge la conduite du changement.
Le syndrome : « outil livré, mission accomplie »
Dans la grande majorité des projets IT, la conduite du changement suit le même destin. Elle est évoquée en phase de cadrage, budgétée en dernier, rognée dès que les premiers arbitrages s’imposent, puis réduite à deux jours de formation la semaine précédant le go-live. Quand elle survit au projet, elle est souvent déléguée à la DRH ou à la communication interne — des équipes de bonne volonté, mais qui n’ont pas toujours la maîtrise des enjeux fonctionnels ni la légitimité pour interpeller les directions métiers.
Le problème de fond est culturel. Dans l’univers des projets IT, ce qui est « soft » est perçu comme moins légitime que ce qui est technique. Un chantier d’architecture ou un plan de tests a une place naturelle dans le planning. Un plan de changement ressemble encore trop souvent à une dépense accessoire, un luxe qu’on s’accorde si le budget le permet.
Ce biais a un coût considérable. Les études les plus sérieuses sur le sujet — notamment celles de Prosci et de McKinsey — convergent vers un chiffre qui devrait faire réfléchir tout décideur : plus de 70 % des projets de transformation échouent non pas pour des raisons techniques, mais à cause d’une résistance humaine mal anticipée. L’outil fonctionne. Les gens ne l’utilisent pas.
Pourquoi ça résiste — vraiment
Il faut en finir avec le cliché selon lequel « les gens ont peur du changement ». C’est une explication commode qui dédouane le projet de ses propres responsabilités. La réalité est plus précise, et plus intéressante.
Quand un utilisateur expérimenté bascule sur un nouvel outil, il ne change pas simplement d’interface. Il perd un statut. Sur l’ancien système, il savait tout faire, formait les nouveaux, était la référence. Sur le nouveau, il redevient novice. C’est une régression symbolique réelle, et elle génère une résistance tout aussi réelle.
Ajoutez à cela l’absence de sens perçu. Les équipes métiers entendent rarement la logique stratégique derrière un projet IT. Elles voient arriver un outil nouveau avec la promesse que « ça va simplifier les choses » — une promesse qu’elles ont déjà entendue, et qui s’est souvent soldée par des mois de galère. La méfiance n’est pas irrationnelle. Elle est le produit d’une histoire.
Enfin, il y a le moment de la consultation. Trop souvent, les futurs utilisateurs sont impliqués en phase de recette — pour valider ce qui a déjà été conçu sans eux. On leur demande de s’approprier des choix qu’ils n’ont pas faits. Dans ces conditions, l’adhésion relève du miracle.
La résistance au changement est toujours un symptôme. Elle indique qu’à un moment du projet, quelqu’un n’a pas été écouté, informé, ou impliqué au bon moment.
Ce que « bien faire » la conduite du changement signifie concrètement
La conduite du changement n’est pas une philosophie. C’est un ensemble d’actions planifiées, pilotées et mesurées. Voici ce que ça implique sur le terrain.
Embarquer tôt, pas juste informer tard. Les utilisateurs clés doivent être identifiés dès la phase de cadrage — pas pour valider, mais pour co-construire. Un « super-utilisateur » impliqué depuis le début comprend les contraintes du projet, connaît les arbitrages qui ont été faits, et devient un ambassadeur naturel auprès de ses collègues au moment du déploiement. C’est le levier le moins coûteux et le plus efficace qui existe.
Cartographier les impacts, pas juste les fonctionnalités. Pour chaque direction métier concernée, il faut répondre à des questions simples : quels processus changent ? Quels rôles évoluent ? Qui perd des habitudes, qui gagne en autonomie ? Cette cartographie d’impacts est le vrai fondement d’un plan de changement. Sans elle, on planifie des formations sans savoir ce qu’on forme vraiment.
Calibrer la communication au bon niveau. Un mail de la DSI le jour du go-live n’est pas une stratégie de communication. Le comité de direction a besoin d’entendre les enjeux stratégiques et de comprendre pourquoi le projet mérite leur soutien visible. Le manager de proximité a besoin de savoir ce qu’il va devoir expliquer à son équipe, et comment gérer les premières semaines. L’utilisateur final a besoin de savoir ce qui change pour lui concrètement, dès demain matin. Ces trois messages sont différents, et ils doivent être portés par des personnes différentes.
Prévoir l’après go-live. Le changement ne s’arrête pas le jour de la mise en production — il commence. Les premières semaines sont les plus critiques : c’est là que les utilisateurs se forgent leur opinion définitive sur l’outil, et que les mauvaises habitudes s’installent si personne n’est là pour accompagner. Un dispositif de support renforcé, des remontées terrain organisées, des ajustements rapides : le plan de stabilisation mérite autant de rigueur que le plan de déploiement.
Le rôle du chef de projet dans tout ça
La conduite du changement n’est pas l’affaire de la DRH. Ce n’est pas non plus une compétence que le chef de projet doit posséder dans ses moindres détails. Mais c’est sa responsabilité de s’assurer que ce chantier existe, qu’il est planifié, financé, et qu’il avance.
Cela signifie l’intégrer dans le plan projet dès le kick-off, au même niveau que les chantiers techniques. Cela signifie nommer un responsable clairement identifié. Et cela signifie savoir reconnaître, sur les projets d’envergure ou à fort impact culturel, quand un spécialiste dédié est nécessaire — et avoir le courage de le recommander, même si ce n’est pas ce que le client a prévu.
C’est ici qu’un consultant externe dispose d’un avantage structurel. Il peut formuler des vérités que personne en interne n’ose dire à voix haute : que les managers de proximité ne portent pas le projet, que le sponsor n’est pas suffisamment visible, que les équipes métiers sont épuisées par une transformation qui s’ajoute à d’autres. Ce regard extérieur, ancré dans l’expérience de nombreux projets similaires, est souvent ce qui fait la différence entre un déploiement qui décolle et un déploiement qui s’enlise.
ire aussi : Chef de Projet ERP – Comprendre son rôle stratégique
3 questions pour savoir si votre projet a besoin d’un plan de changement structuré
- Plus de 20 personnes sont concernées par le changement de pratiques ?
- Le projet modifie des processus métiers au-delà d’un simple changement d’outil ?
- Le contexte de confiance entre la DSI et les directions métiers est fragile ou tendu ?
Si vous répondez oui à au moins deux de ces questions, la conduite du changement n’est pas optionnelle.
Une question de budget — et de priorités
L’objection revient dans presque tous les projets : « on n’a pas le budget pour ça. » Elle mérite une réponse directe.
La conduite du changement représente en moyenne 10 à 15 % du budget d’un projet. C’est la part qui conditionne 100 % de la valeur attendue. Le coût de la non-adoption, lui, est rarement calculé : licences payées pour des outils sous-utilisés, productivité perdue pendant des mois, support surchargé, parfois refonte partielle du projet. Ce coût dépasse presque toujours ce qu’aurait coûté un plan de changement correctement dimensionné.
Si le budget est réellement contraint, la bonne décision est de réduire le périmètre fonctionnel — pas de supprimer le plan de changement. Livrer moins de fonctionnalités bien adoptées vaut infiniment mieux que livrer tout ce qui était prévu, sans que personne ne s’en serve.
Un projet IT n’est pas livré quand le code est en production
Il est livré quand les utilisateurs s’en servent, quand les processus ont réellement changé, quand la valeur promise est au rendez-vous. Tout le reste n’est que de la technique.
La conduite du changement n’est pas le parent pauvre du projet. C’est ce qui fait qu’un projet produit autre chose qu’une belle démonstration en salle de réunion.
A propos de Benoît Vanmosuinck : Fondateur d’Adekia, il accompagne depuis plus de 15 ans les entreprises dans la réussite de leurs projets IT stratégiques. Spécialisé en ERP et transformations complexes, il partage régulièrement ses bonnes pratiques et retours d’expérience autour de la gestion de projets IT et de solutions comme Axelor.
Besoin de gérer le changement dans votre projet ERP ?
Vous projetez de mettre en place une nouvelle solution ERP et vous souhaitez que les utilisateurs adhèrent au nouvel outil ? Notre équipe vous conseil et vous accompagne.