Projets ERP, quand le chiffrage initial devient une promesse intenable

Le scénario commence souvent dans une salle de réunion, quelques semaines avant la signature. La direction a fixé le démarrage au 1er janvier, parce que l'exercice comptable s'ouvre ce jour-là et qu'il paraît naturel de basculer en même temps. L'intégrateur, en concurrence avec deux autres partenaires, remet une proposition qui tient dans l'enveloppe annoncée. Personne ne ment vraiment. Chacun retient simplement l'hypothèse la plus favorable: des données propres, des utilisateurs clés disponibles, des besoins proches du standard de Business Central.

Estimer un projet ERP reste un exercice difficile. Le coût dépend de l'état de l'existant, de l'ampleur des changements métier, de la disponibilité des équipes et de la capacité de l'organisation à absorber le changement, des variables qui se découvrent pour l'essentiel en cours de route. Un chiffrage optimiste ne produit pas seulement un dépassement. Il installe une pression qui pousse à raccourcir ce qui semble négociable: les recettes, la reprise de données et la formation. Ce sont précisément les phases qui décident de la qualité du démarrage. Parmi les sept principaux risques d'un projet ERP, celui-ci a une particularité, il est souvent en place avant même le premier atelier.

Manifestations et symptômes sur le terrain

Les premiers signes apparaissent dès les ateliers de conception. L'analyse des écarts révèle plus de développements que prévu, et les consultants découvrent des cas particuliers que personne n'avait mentionnés pendant l'avant-vente: une tarification par zone de livraison, une facturation à l'avancement, un circuit de validation des achats à trois niveaux. Chaque découverte est modeste. Leur somme ne l'est pas.

À mi-parcours, la consommation des journées dépasse l'avancement réel. Le comité de pilotage reçoit une première réestimation, qu'il valide rarement en totalité. On préfère réduire le périmètre sans le dire ou demander à l'équipe de "rattraper". Les décisions se font attendre, car chaque ressource supplémentaire doit désormais être justifiée ligne par ligne.

Les utilisateurs clés, qui cumulent souvent leur poste habituel et le projet, enchaînent les soirées et les week-ends. Les cycles de recette se compressent, la reprise de données passe de trois répétitions prévues à une seule. Puis vient le report du démarrage, rarement annoncé en une fois. Il glisse d'un mois, puis d'un trimestre, et chaque annonce entame un peu plus la crédibilité du projet auprès des services.

Impact financier, opérationnel et humain

Le surcoût final dépasse souvent largement le premier dépassement annoncé, mais il se voit mal. Une partie se dilue dans les heures supplémentaires des équipes internes, qui ne figurent dans aucun budget projet. Une autre réapparaît après le démarrage, sous forme de journées de régie pour corriger ce qui a été livré trop vite. La comparaison honnête entre le budget voté et le coût complet est rarement faite.

Le calendrier produit ses propres effets. Un démarrage repoussé de janvier à avril oblige à reprendre des soldes en cours d'exercice, à maintenir l'ancien système plus longtemps et parfois à prolonger un contrat de maintenance qui devait s'arrêter. Les améliorations attendues par les métiers restent en attente, puisque tout est suspendu à la bascule.

Le coût humain est plus lourd encore. Une équipe épuisée perd ses meilleurs éléments au moment où elle en a le plus besoin: un utilisateur clé qui démissionne trois mois avant le démarrage emporte avec lui la connaissance du paramétrage de son domaine. Les collaborateurs qui ont entendu plusieurs dates successives finissent par ne plus croire aucune annonce, y compris la bonne.

Analyse des causes racines et erreurs de gouvernance

La première cause tient à l'optimisme du lancement. La direction voit les bénéfices attendus, l'intégrateur veut remporter l'affaire, et le chiffrage se construit sur un périmètre décrit en quelques pages. Business Central a la réputation d'un ERP rapide à déployer. C'est vrai pour un périmètre proche du standard, et trompeur dès que les spécificités s'accumulent.

Les charges sont ensuite mal réparties. On chiffre précisément le paramétrage et les développements, beaucoup moins la reprise de données, les recettes, la formation et l'accompagnement après le démarrage. Ces activités représentent pourtant une part importante de l'effort total, et elles reposent largement sur les équipes du client, dont le temps n'est presque jamais budgété.

Le contrat joue aussi son rôle. Au forfait, l'intégrateur a intérêt à figer un périmètre étroit, et chaque écart devient un avenant que personne n'ose ouvrir. En régie, le budget initial n'est qu'une estimation, et le client découvre la réalité au fil des factures. Beaucoup de budgets, enfin, ne contiennent aucune réserve pour aléas. Le moindre imprévu devient alors une crise, faute de marge pour l'absorber.

Plan d'action, mesures préventives et correction

Le chiffrage gagne d'abord à reposer sur un cadrage sérieux. Quelques jours d'ateliers avant la signature, centrés sur les processus réellement critiques et sur un échantillon de données, valent mieux qu'une proposition rédigée à partir d'un cahier des charges générique. Ce cadrage sert aussi à mesurer l'écart avec le standard de Business Central, processus par processus.

Le budget doit ensuite être décomposé en lots assez fins pour être suivis: paramétrage par domaine, chaque développement, chaque cycle de reprise, chaque campagne de recette, la formation et l'accompagnement après démarrage. Le temps des équipes internes y figure explicitement, avec le nom des personnes et leur taux de disponibilité. Un utilisateur clé disponible à 20 % ne peut pas porter trois cycles de recette.

Une réserve pour aléas, visible et pilotée par le comité, complète le dispositif. Une enveloppe de l'ordre de 15 à 20 % du budget est une pratique courante. Son usage est décidé en comité, ce qui évite qu'elle finance des demandes de confort.

La date de démarrage, enfin, se discute. Rien n'impose de basculer au 1er janvier: un démarrage en cours d'exercice, avec reprise des soldes à une fin de mois, est courant et souvent moins risqué qu'une bascule superposée à la clôture annuelle. Une réestimation à chaque jalon, présentée sans maquillage, permet d'annoncer tôt un décalage plutôt que de le subir tard.

Conclusion

Un budget sous-estimé n'est presque jamais un accident. Il résulte d'un accord tacite entre une direction qui veut un chiffre rassurant et un intégrateur qui veut signer, et chacun en paie le prix plus tard. L'entreprise qui accepte un chiffrage optimiste finit par régler l'écart autrement, avec le temps de ses équipes, la qualité de ses données et la confiance de ses collaborateurs.

La responsabilité principale revient au client, car c'est lui qui vit avec le résultat. Concrètement, cela signifie exiger un cadrage avant la signature, chiffrer son propre temps comme une ressource du projet, inscrire une réserve pour aléas dans le budget voté et traiter la date de démarrage comme une variable. Un projet qui démarre un trimestre plus tard avec des données fiables coûte moins cher qu'un projet tenu à la date et réparé pendant un an.

Le risque suivant prolonge directement celui-ci. Quand le calendrier se resserre, la reprise des données est souvent la première victime.