Le délicat sujet de l'estimation budgétaire dans les projets ERP

L'une des erreurs les plus sournoises que j'ai rencontrées dans les projets ERP, c'est celle de l'estimation budgétaire sous-évaluée, ou tout simplement irréaliste. Depuis 2004, sur mon blog ERP, j'essaie de partager les enseignements de terrain, ceux qu'on ne trouve pas toujours dans les méthodologies ou les référentiels. Et parmi ces enseignements, l'un des plus récurrents reste le décalage entre les budgets affichés et les réalités opérationnelles. Je pourrais citer plusieurs exemples, mais l'un d'eux reste gravé dans ma mémoire pour la manière dont une estimation mal construite a faussé les fondations du projet dès le départ.

Je vous partage mon expérience sur le délicat sujet de l'estimation budgétaire dans les projets ERP

L'entreprise en question était une PME industrielle familiale qui s'était lancée dans une transformation numérique en décidant de remplacer son système de gestion vieillissant par un ERP moderne. Le comité de direction était enthousiaste, les attentes fortes, et un budget avait été validé sur la base d'un benchmark rapide mené par un cabinet externe. À ce moment-là, je suis intervenu comme chef de projet ERP externe, avec une mission d'accompagnement AMOA sur toute la phase de cadrage et de déploiement.

Dès les premières réunions, j'ai identifié un problème : le budget avait été validé avant même que les besoins ne soient précisément définis. Il reposait sur une moyenne des coûts observés dans d'autres entreprises du même secteur, sans prise en compte de la complexité spécifique du système existant, ni du changement organisationnel à venir. À peine entré dans le vif du sujet, il est apparu que de nombreuses interfaces devaient être conservées, que la logistique était partiellement externalisée, et que les pratiques de gestion commerciale variaient fortement entre les sites. Tout cela aurait dû alerter sur la nécessité d'un budget plus robuste, plus nuancé, et surtout, étayé.

J'ai alors proposé un exercice d'estimation plus rigoureux. D'abord en repartant du travail réel à produire : le nombre de jours nécessaires pour les ateliers de cadrage, la charge de configuration, les développements spécifiques, les phases de recette, la formation, la conduite du changement, le support post go-live. J'ai impliqué toutes les parties prenantes, IT, métiers, fournisseurs, en organisant des sessions d'évaluation croisée. Nous avons utilisé les données historiques de projets similaires que j'avais documentés au fil des années. Très vite, il est apparu que le budget initialement validé couvrait à peine 60% de la charge réelle.

J'ai présenté ce constat au comité de pilotage, chiffres à l'appui, en expliquant que deux options s'offraient à eux : soit revoir le périmètre à la baisse, soit réévaluer le budget. J'ai aussi souligné que le budget initial ne prévoyait aucun coût pour la conduite du changement, ni pour le support à la reprise de données, deux postes souvent sous-estimés et pourtant déterminants pour un ERP. La réaction ne s'est pas fait attendre : certains membres du comité ont contesté les écarts, avançant que « les intégrateurs gonflent toujours les charges », ou que « certains postes peuvent être internalisés sans coût ». Ce genre de débat est courant, surtout lorsque le sujet du budget touche à la crédibilité de ceux qui l'ont validé en amont.

Ce projet m'a rappelé combien il est essentiel de dissocier l'estimation budgétaire de la pression politique. L'estimation n'est pas un acte de persuasion, c'est un outil de maîtrise. Elle ne doit pas répondre à ce qu'on espère dépenser, mais refléter honnêtement ce qu'il faudra réellement engager pour réussir. La difficulté vient souvent du fait que l'entreprise attend du chef de projet qu'il “tienne le budget” plus qu'il ne tienne le projet.

Une bonne estimation repose sur trois piliers : la transparence, la méthode et l'expérience. La transparence, c'est exposer les hypothèses de départ, les postes inclus et exclus, et les incertitudes identifiées. La méthode, c'est structurer le chiffrage par poste, par phase, en croisant les sources : expérience interne, benchmarks, ratios historiques. L'expérience, c'est savoir où les projets dérapent généralement : reprise de données plus complexe que prévue, tests mal anticipés, formations négligées ou support sous-dimensionné.

Dans les projets récents, j'ai systématisé l'inclusion d'une marge de sécurité de 15 à 20 %, que je présente comme une “enveloppe de résilience”. Cette marge n'est pas un luxe, c'est une assurance de viabilité. Elle permet de couvrir les écarts liés aux aléas techniques, aux imprévus organisationnels ou aux besoins émergents. Trop souvent, ces postes ne trouvent leur place qu'en urgence, via des avenants budgétaires, souvent mal vécus par la direction.

L'autre enseignement de ce projet est que l'estimation budgétaire doit être un processus collaboratif. Ce n'est pas au chef de projet seul de produire un chiffre figé. C'est une démarche partagée avec les experts métier, les équipes IT, les partenaires externes. Et cette démarche doit commencer tôt, idéalement dès la phase de cadrage. Attendre la réponse de l'intégrateur pour “voir combien ça va coûter” revient à déléguer sa stratégie à un fournisseur.

Finalement, malgré les réticences initiales, le comité a accepté une révision du budget, en segmentant les phases du projet pour lisser les investissements. Le projet s'est étalé sur un an au lieu de neuf mois, mais il a pu aller jusqu'à son terme, avec un périmètre fonctionnel complet, une adoption correcte, et un système stable dès la première clôture. L'acceptation de revoir le budget a été la clé du redressement.

L'estimation budgétaire est un art difficile, car elle confronte le rationnel de l'analyse au politique de la décision. Mais elle est aussi un moment de vérité : c'est là que l'on pose les bases de la confiance entre les acteurs du projet. Un budget réaliste n'est pas une contrainte, c'est un facteur de succès. Et comme tout facteur de succès, il mérite qu'on y consacre l'énergie, la méthode et l'expérience qu'il requiert.

👉 ( ◍•㉦•◍ ) 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 12 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: « La société française Mistral AI lève 105 millions d'euros ».

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

Merci de vos partages! 👷🏻‍



🎯 À consulter : Mentions légales. Derniers articles : x, x, x, x, x, x, x, Openbravo, Implémentation d'un logiciel : les différentes phases, Plushtodon, un éléphant en peluche résume les paradoxes de Mastodon, Le pilotage de projet ERP, 3 règles de mise en œuvre, La reprise de données, étape importante d'un projet ERP, Sécurité informatique pour les néophytes : protégez vos données.
⛅ L'automne est arrivé, un temps propice au travail non? ☂️

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