5 façons pour un commanditaire (sponsor) de challenger des estimations ERP coûteuses sans devenir technique
Si vous êtes commanditaire (sponsor) d’un projet ERP (progiciel de gestion intégré), vous avez probablement déjà vécu cette situation.
Une estimation détaillée arrive sur la table.
Les chiffres sont précis.
Le discours est confiant.
Et pourtant, quelque chose vous gêne.
Pas parce que l’équipe manque d’expérience —
mais parce que les estimations ERP reposent souvent sur des hypothèses implicites, un optimisme non testé et des risques qui n’apparaissent que bien plus tard.
Cette situation est fréquente dans les projets où la gouvernance existe formellement, sans réellement jouer son rôle — un point clé développé dans notre analyse de la gouvernance ERP :
👉 https://www.fitgapfinance.com/lecons-reelles-projets-erp/
Un commanditaire n’a pas besoin de devenir chef de projet ou expert ERP pour challenger (remettre en question) une estimation.
Il doit simplement savoir où elle cache sa fragilité.
Challenger une estimation n’est pas une question de précision, mais de mise en lumière
Les estimations ERP sont rarement « fausses » le premier jour.
Elles le deviennent lorsque la réalité s’écarte de ce qui était supposé.
Le rôle du commanditaire n’est pas de refaire le chiffrage.
Il est de rendre visibles les hypothèses, les arbitrages et les responsabilités.
Les cinq leviers ci-dessous fonctionnent à tout moment du projet et ne nécessitent aucune expertise technique.
1. Rendre explicites les hypothèses et exclusions — et leurs conséquences
Sur quelles hypothèses et exclusions repose cette estimation, et lesquelles entraîneraient immédiatement des coûts supplémentaires si elles s’avéraient fausses ?
Pourquoi c’est critique :
Les exclusions sont le moyen le plus courant de rendre une estimation acceptable… en repoussant le risque.
Ce que le commanditaire doit entendre :
- Hypothèses sur la qualité des données, la stabilité du périmètre, le comportement des utilisateurs
- Exclusions présentées comme « improbables » mais connues comme peu réalistes
- Impact clair en cas d’échec d’une hypothèse
Signaux d’alerte :
- « Ça ne devrait pas arriver »
- « On n’a jamais vu ça »
- « On gérera si ça se produit »
Les exclusions liées à la migration de données sont particulièrement fréquentes — et souvent à l’origine de surcoûts tardifs :
👉 https://www.fitgapfinance.com/migration-de-donnees-dans-dynamics-365-10-bonnes-pratiques-pour-eviter-les-erreurs-couteuses/
Une exclusion sans impact financier associé n’est pas une protection — c’est un futur avenant.
2. Mettre en évidence les conditions de succès supposées
Quelles conditions de succès cette estimation suppose-t-elle, et comment le coût évolue-t-il si nous ne les respectons pas ?
Pourquoi c’est critique :
Beaucoup d’estimations ne tiennent que dans des conditions idéales rarement durables.
Conditions souvent supposées sans être dites :
- Décisions rapides et cohérentes
- Ressources internes très disponibles
- Périmètre stable
- Données propres et utilisateurs disciplinés
Ce que le commanditaire doit forcer :
- L’impact sur le coût et le planning si ces conditions se dégradent
- Les hypothèses les plus fragiles
- L’existence (ou non) de marges de manœuvre réelles
Signaux d’alerte :
- « C’est la responsabilité du client »
- « On ajustera en cours de route »
- « L’estimation suppose un effort raisonnable »
Ces conditions reposent très souvent sur des facteurs humains et organisationnels sous-estimés :
👉 https://www.fitgapfinance.com/dimension-humaine-projets-erp/
Une estimation qui ne tient qu’en situation idéale est une estimation fragile.
3. Distinguer ce qui est réellement spécifique de ce qui devrait être accéléré
Quelles parties de cette estimation sont réellement spécifiques, et lesquelles reposent sur des accélérateurs, des modèles ou de la réutilisation ?
Pourquoi c’est critique :
Des estimations élevées cachent souvent une approche « page blanche » là où l’expérience devrait jouer.
Ce que le commanditaire doit entendre :
- Une distinction claire entre standard et spécifique
- Des exemples concrets d’accélérateurs ou de patterns réutilisés
- Une justification factuelle du caractère spécifique revendiqué
Signaux d’alerte :
- « Chaque client est différent »
- « Nous préférons repartir de zéro »
- Des références vagues à l’expérience, sans preuve de réutilisation
Cette confusion entre standard, spécifique et « meilleures pratiques » est un écueil classique des projets ERP :
👉 https://www.fitgapfinance.com/meilleures-pratiques-erp-nuance-d365-finance/
Le commanditaire ne paie pas pour de la nouveauté.
Il paie pour du discernement.
4. Forcer une discussion sur le périmètre minimum viable
Quelle est la version minimale de cet ERP qui créerait une vraie valeur métier — et quelle part de l’estimation va au-delà ?
Pourquoi c’est critique :
La majorité des dépassements provient de vouloir tout faire, tout de suite.
Ce que le commanditaire doit faire émerger :
- Ce qui est indispensable à la création de valeur
- Ce qui peut être différé sans risque majeur
- Ce qui relève du confort plus que du besoin
Signaux d’alerte :
- « Tout est critique »
- « Ce n’est pas découpable »
- « Autant tout faire maintenant »
Si tout est prioritaire, rien ne l’est vraiment — et les coûts deviennent incontrôlables.
5. Attribuer la responsabilité du premier dépassement probable
Si cette estimation s’avère fausse, d’où viendra le premier dépassement — et qui portera la décision lorsque cela arrivera ?
Pourquoi c’est critique :
Les estimations échouent dans le silence… jusqu’au moment où quelqu’un doit décider.
Ce que le commanditaire doit forcer :
- La source la plus probable de dépassement
- Qui arbitrera entre coût, délai et périmètre
- Ce qui se passera lorsque les compromis deviendront inévitables
Signaux d’alerte :
- « On verra plus tard »
- « Ça dépendra de l’avancement »
- Aucun responsable clairement identifié
Les dépassements ne viennent pas d’un mauvais calcul.
Ils viennent de décisions non assumées.
En conclusion
Les estimations ERP n’ont pas besoin d’être parfaites.
Elles doivent être honnêtes sur leurs zones de fragilité.
Un commanditaire ne protège pas un projet en acceptant une estimation telle quelle.
Il le protège en challengeant les hypothèses, en forçant les arbitrages et en attribuant les responsabilités dès le départ.
Il n’a pas besoin de devenir technique pour cela.
Il doit rendre la réalité inévitable.
Cet article fait partie de la série FitGap™ Finance — une approche pragmatique et orientée métier de la gouvernance ERP, de la prise de décision et du contrôle au-delà du go-live.
🇬🇧 Version anglaise disponible ici : https://www.fitgapfinance.com/challenge-erp-cost-estimates/
