Réduire le risque d'échec d'un projet de déploiement ERP

Depuis 2004, j'alimente mon blog dédié aux projets ERP avec les leçons que j'ai tirées d'une trentaine de déploiements, dans des contextes variés et parfois très contrastés. C'est une forme de mémoire vive de ma pratique, mais aussi un moyen d'exprimer les vérités peu glamour de notre métier. Il y a une chose que l'expérience m'a apprise, que je retrouve dans presque tous les projets en difficulté : ce n'est pas la complexité technique qui fait échouer un ERP, ni même le dépassement budgétaire ou le retard de livraison — ce sont des symptômes. Les vraies causes se nichent ailleurs, dans l'humain, le politique, et surtout, dans la capacité ou non à embarquer les parties prenantes dès le début du projet.

Je vous partage mon expérience sur comment réduire le risque d'échec d'un projet de déploiement ERP, quelles sont les bonnes pratiques

Je me souviens d'un projet en particulier, dans une entreprise de services aux collectivités. L'ambition était forte : rationaliser les processus métiers autour d'un ERP unique, remplacer une constellation d'outils vieillissants, et harmoniser les pratiques d'un groupe récemment issu de plusieurs fusions. Le cahier des charges était structuré, le périmètre bien défini. En apparence, tout était aligné pour démarrer dans de bonnes conditions. Et pourtant, dès les premières semaines, je sentais que quelque chose ne prenait pas.

Le projet était officiellement sponsorisé par le DSI, mais son implication était en pointillés. Lors de nos comités de pilotage, il intervenait peu, souvent distrait, délégant la plupart des décisions à ses adjoints. Le comité de direction avait validé le budget, certes, mais sans réelle appropriation de ce que ce projet allait signifier en termes de transformation. Côté métiers, les interlocuteurs étaient présents, mais rarement moteurs. Chacun semblait attendre que le projet leur “arrive”, comme s'il s'agissait d'une modernisation technique, et non d'un changement de paradigme.

Au lieu de monter en puissance, la dynamique s'est essoufflée. Les ateliers de cadrage se sont vite transformés en discussions confuses, les utilisateurs exprimant des attentes parfois contradictoires, révélant que personne n'avait vraiment pris le temps de comprendre leurs besoins réels. Pire encore, des décisions clés, comme le choix de certains processus cibles ou l'ordre de déploiement des lots, étaient régulièrement repoussées faute de consensus. Je passais mon temps à relancer, à réexpliquer, à clarifier, sans jamais sentir que le projet avançait sur des bases solides.

J'ai alors décidé de mener des entretiens individuels avec les principales parties prenantes. Ce que j'ai découvert ne m'a pas surpris, mais a confirmé ce que je craignais : chacun avait ses propres objectifs, ses priorités, son agenda. Pour certains, le projet représentait une menace pour leur organisation locale. Pour d'autres, un ERP standardisé signifiait perdre l'autonomie sur certains outils développés en interne. Personne n'avait cherché à aligner ces intérêts, à les confronter de manière constructive. Il n'y avait pas eu de travail d'adhésion, ni de réelle charte projet partagée et comprise.

À ce moment-là, il était encore temps de réagir. J'ai pris le risque de mettre le projet en pause pendant trois semaines. Une décision difficile, mais nécessaire. J'ai organisé une série d'ateliers de remobilisation, en commençant par le top management. Nous avons redéfini les objectifs du projet, en les traduisant dans une vision concrète pour chaque département. Puis nous avons rédigé une note d'engagement que chaque directeur a signée, formalisant son soutien et sa participation. Ce n'était pas un simple geste symbolique : il s'agissait de dire, noir sur blanc, que ce projet allait transformer les pratiques de chacun et qu'il fallait l'assumer.

Dans le même temps, j'ai instauré un plan de remontée d'informations précis. Chaque incident, chaque blocage devait être documenté, qualifié, assigné à un responsable, et discuté lors d'un point hebdomadaire. Cela a permis d'éviter les dérives silencieuses, ces petits problèmes non résolus qui deviennent des crises plus tard. Et surtout, j'ai mis en place une communication surabondante. Oui, cela a généré des doublons. Oui, certains se sont plaints de recevoir trop de comptes rendus. Mais cela a permis d'instaurer un rythme, une trace, une lisibilité collective. Quand on intègre un ERP, on navigue dans un brouillard d'incertitudes. Trop d'équipes travaillent en parallèle. Trop de dépendances s'entrecroisent. Sans communication constante, on perd le fil.

Malgré cela, tout n'a pas été parfait. Certains modules ont connu des retards. Le périmètre de certains lots a été revu. Mais le projet, lui, a abouti. Et surtout, il a été compris, accepté, et finalement bien accueilli par les utilisateurs. Ce n'était pas un miracle. C'était le résultat d'un effort volontaire pour aligner les attentes, créer des points d'écoute, et donner un cadre où les tensions pouvaient s'exprimer plutôt que s'accumuler en silence.

Aujourd'hui encore, quand on me demande ce qui fait échouer un projet ERP, je réponds que ce n'est jamais un seul facteur. C'est l'enchaînement discret de petits renoncements, de décisions non prises, de messages mal transmis. La technologie n'est jamais le problème central. Ce sont les gens, les relations, l'adhésion. Et cela se construit dès la première réunion, dès la première phrase du kick-off, parfois même avant. Un ERP, c'est un effort collectif, et cet effort ne peut exister que si chaque partie prenante comprend ce qu'elle a à y gagner — et ce qu'elle doit y mettre.

👉 ( ◍•㉦•◍ ) Michel Campillo consultant expert en solutions de gestion écrit et publie régulièrement depuis 2004 des articles sur son site web professionnel dédié aux outils d'entreprise et aux questions du numérique et des technologies. Comme tout blogueur il écrit aussi sur des sujets divers, voir le blog pour un aperçu des thèmes abordés.

Outre l'email, mobile, téléphone, Linkedin, réseaux sociaux, vous pouvez me retrouver également sur Teams. Installé sur mon poste de travail, je reçois instantanément vos messages. Envoyez-moi votre identifiant par SMS ou email.

Pays de Provence, le 19 juillet 2025

Michel Campillo
Consultant chef de projet IT
☎ 06 89 56 58 18  ✉ contact par email

➽ Les articles d'actualité sur les problématiques d'entreprise sont repris chronologiquement sur la page d'accueil du blog. J'aime cet article sur l'informatique: « Qu'est-ce que Zimbra? ».

Ce billet vous a intéressé? Alors partagez-le en cliquant sur les boutons ci-dessous:

Merci de vos partages! 👷🏻‍



🎯 Autres options: Mentions légales, Les modules d'un ERP, Logiciel de gestion de l'innovation, Mise en place d'un ERP dans une entreprise, Process mining, Logiciel de gestion des achats, expérience d'implémentation, L'innovation à Marseille et les startups, Donkey Kong Bananza... Quel voyage dans le temps !, TikTok et les mirages de la finance facile, attention au piège, L'opérateur Orange, cible d'une cyberattaque, Être à jour sur sa veille technologique?, L'IA Act, acte 2 : Google signe... mais pour moi, les doutes persistent, Apple prépare-t-il son propre ChatGPT ? Entre nécessité et doutes, Tchap messagerie sécurisée de l'État, rempart face à la cybercriminalité?, RPA : l'automatisation mal intégrée devient un risque, Fuite d'IBAN chez Bouygues, quels risques pour les clients?, Quand l'IA agentique rencontre l'ERP : l'avenir des portails métiers, Après la fin de Skype, quels outils pour nos échanges numériques?, RELIEF, l'IA agentique qui réinvente le chiffrage industriel, À propos de Michel Campillo, Les logiciels ERP en 2025, Logistique et intelligence artificielle : une transformation inévitable, Quand la Suisse modernise ses logiciels ERP, Quand SAP s'installe au Vietnam, que devons-nous en retenir ?, Quand l'intégration des paiements et de l'ERP change la donne, x, x, x, x, Encore un fiasco en projet ERP : les leçons de DHL.
☀️ Sous le soleil éclatant et la forte chaleur d'un bel été 🏖️

Copyright © 2004-2025 Michel Campillo, tous droits réservés