Quand un projet ERP glisse, la question posée au comité de pilotage est presque toujours la même : « Combien de semaines de plus ? ». La question qui devrait être posée est différente : « Combien nous coûte chaque mois de plus, et que pouvons-nous acheter avec ce montant ? ». Tant que le retard reste exprimé en semaines, il reste abstrait. Exprimé en euros par mois, il devient un paramètre d’arbitrage au même titre que le périmètre et le budget.
Cet article propose un modèle de calcul que vous pouvez remplir en une heure avec votre chef de projet et votre contrôleur de gestion, puis présenter en COPIL. Il ne prétend pas donner « le » coût d’un retard : ce coût dépend de votre contrat, de votre organisation et de votre business case. Il fournit une méthode pour ne rien oublier et pour comparer honnêtement les options.
Pourquoi le retard est presque toujours sous-chiffré dans les COPIL
Dans la plupart des comités, le coût du retard se résume à une ligne : « l’intégrateur demande un avenant de X jours ». C’est le seul poste facile à lire, car il arrive sous forme de devis. Tout le reste reste diffus.
Trois mécanismes expliquent ce biais.
Le coût interne est invisible. Les collaborateurs métier et DSI mobilisés sur le projet sont déjà payés. Leur temps ne génère aucune facture supplémentaire, donc personne ne le compte. Pourtant, chaque mois de prolongation les retient sur un projet au lieu de leur activité habituelle, ou les pousse à faire les deux en même temps.
Les bénéfices différés ne sont pas dans le budget projet. Le business case promettait des gains (réduction de stocks, clôture accélérée, suppression de ressaisies). Un mois de retard repousse ces gains d’un mois. Cette perte n’apparaît dans aucun tableau de bord du projet, car elle correspond à de l’argent qu’on n’a pas encore gagné.
Les coûts de coexistence s’additionnent en silence. Tant que l’ancien système vit, ses licences, son hébergement, sa maintenance et les doubles saisies continuent. Ces lignes sont réparties dans des budgets différents (infrastructure, finance, métiers) et personne ne les consolide.
Résultat : le COPIL compare un « petit retard » à un « gros coût de réduction de périmètre » alors qu’il compare deux ensembles de coûts dont un seul est chiffré. Le déséquilibre pousse systématiquement à accepter le report, puis un deuxième, puis un troisième. Pour le rituel qui cadre ces décisions, voyez notre template de comité de pilotage hebdomadaire.
Les 6 postes de coût d’un mois de retard
Voici les six postes à passer en revue. Pour chacun, la méthode est de partir d’un coût mensuel et de se demander : « Ce coût continue-t-il si le go-live glisse d’un mois ? ».
1. L’équipe projet interne
Il s’agit du coût chargé des personnes mobilisées sur le projet : chef de projet, key users, architectes, DSI, finance, achats. Le calcul : nombre d’équivalents temps plein (ETP) mobilisés multiplié par le coût mensuel chargé moyen.
Deux précisions. D’abord, ne comptez que le temps réellement consacré au projet, pas les effectifs nominalement « impliqués ». Ensuite, ajoutez le coût de remplacement ou de surcharge : si les key users sont backfillés par des intérimaires ou des heures supplémentaires, ces coûts sont réels.
2. L’intégrateur : régie ou forfait
Le traitement dépend du contrat. En régie, chaque mois de prolongation est facturé : nombre de consultants multiplié par jours ouvrés multiplié par taux journalier. En forfait, le coût direct n’est pas automatiquement à votre charge, mais deux risques existent : l’avenant (si le retard est imputable à des changements de votre côté) et la dégradation de la qualité (un intégrateur qui perd de l’argent réaffecte ses meilleurs profils). Pour approfondir la différence, lisez notre article sur le forfait, la régie et l’engagement de résultat.
3. Le double run et les licences legacy
Tant que l’ancien système tourne, vous payez : licences et maintenance, hébergement, support, et surtout les doubles saisies ou rapprochements manuels si une partie des flux est déjà basculée. Ajoutez les renégociations : certains éditeurs facturent plus cher une prolongation de dernière minute qu’un contrat annuel planifié. Vérifiez vos dates de préavis et de fin de contrat : un go-live qui dépasse la date de fin de maintenance de l’ancien ERP change complètement la nature du retard.
4. Les bénéfices différés
C’est le poste le plus sensible politiquement, car il repose sur le business case. Méthode : prenez les gains annuels récurrents que le projet doit générer (économies de ressaisie, baisse de stocks, réduction des délais de clôture, évitement de coûts legacy), divisez par douze, et appliquez uniquement à ce qui est réellement activé par le go-live.
Soyez prudent : un bénéfice qui n’était pas sérieusement chiffré avant le projet ne doit pas être inventé au moment de justifier un arbitrage. Si le business case est fragile, signalez-le et affichez ce poste séparément, en précisant son niveau de confiance. Le DAF acceptera plus facilement un modèle qui distingue le coût cash (postes 1 à 3) du coût d’opportunité (poste 4).
5. Le risque réglementaire ou d’échéance fixe
Certains projets ont une date non négociable : fin de support éditeur, obligation de facturation électronique, clôture d’exercice, fusion, ouverture d’un site. Si le go-live dépasse cette date, vous payez soit un contournement (saisies manuelles, outil provisoire, prestataire de conformité), soit un risque de sanction ou de perturbation d’activité.
Ne chiffrez pas ce poste avec un montant d’amende théorique que vous ne pouvez pas sourcer. Chiffrez le coût du plan B : combien coûte la solution provisoire, pendant combien de mois ? C’est un coût que vous pouvez faire valider par un devis.
6. La fatigue de l’équipe et le turnover
C’est le poste que personne n’ose chiffrer, et pourtant il pèse lourd : un projet qui s’étire épuise les key users, qui sont aussi vos meilleurs experts métier. Le départ d’un seul d’entre eux peut retarder un lot entier.
Une méthode simple, à afficher comme provision : estimez la probabilité qu’un profil clé quitte le projet ou l’entreprise si le retard dépasse un seuil (par exemple un trimestre), multipliez par le coût de remplacement et de remontée en compétence. C’est une estimation, présentez-la comme telle, avec l’hypothèse écrite.
Modèle de calcul pas à pas
Étape 1 : poser le périmètre du calcul
Définissez la période de référence (un mois de retard) et la date de go-live actuelle. Précisez si le retard est supposé linéaire : les coûts de l’intégrateur et du double run le sont souvent, ceux du risque réglementaire ne le sont pas (ils basculent d’un coup à une date seuil).
Étape 2 : remplir le tableau
| Poste | Formule | Valeur à remplir | Source de la donnée |
|---|---|---|---|
| 1. Équipe interne | ETP mobilisés × coût mensuel chargé | … € | RH / contrôle de gestion |
| 2. Intégrateur | Consultants × jours × TJM (régie) ou avenant probable (forfait) | … € | Contrat, planning |
| 3. Double run | Licences + hébergement + maintenance + ETP de double saisie | … € | Achats, DSI, finance |
| 4. Bénéfices différés | Gains annuels du business case ÷ 12 (part activée au go-live) | … € | Business case validé |
| 5. Échéance fixe | Coût mensuel du plan B ou du contournement | … € | Devis, DSI |
| 6. Fatigue et turnover | Probabilité × coût de remplacement | … € | RH, estimation |
| Total mensuel | Somme des postes 1 à 6 | … € |
Ajoutez deux colonnes utiles : « cash / opportunité » et « niveau de confiance » (élevé, moyen, faible). Le COPIL doit voir ce qui est certain et ce qui est estimé.
Étape 3 : un exemple illustratif
Attention : l’exemple ci-dessous est entièrement fictif. Les montants sont des hypothèses choisies pour illustrer la méthode, pas des références de marché. Ils décrivent une ETI de 400 personnes qui remplace son ERP.
| Poste | Hypothèses fictives | Coût mensuel |
|---|---|---|
| 1. Équipe interne | 12 ETP × 7 000 € chargés | 84 000 € |
| 2. Intégrateur (régie) | 8 consultants × 20 jours × 850 € | 136 000 € |
| 3. Double run | Licences legacy 18 000 € + hébergement et maintenance 7 000 € + 3 ETP de double saisie × 5 500 € | 41 500 € |
| 4. Bénéfices différés | 1,2 M€ de gains annuels attendus ÷ 12 | 100 000 € |
| 5. Échéance fixe | Outil provisoire et saisies manuelles pour une obligation de conformité | 25 000 € |
| 6. Fatigue et turnover | 10 % de probabilité de perdre un profil clé × 150 000 € | 15 000 € |
| Total mensuel | 401 500 € |
Lecture : dans ce scénario fictif, un mois de retard coûte environ 400 000 €, dont 261 500 € de cash (postes 1 à 3) et 140 000 € de coût d’opportunité et de risque (postes 4 à 6). Un retard de deux mois, à hypothèses constantes, approche 800 000 €.
Le message au COPIL n’est pas « le retard est grave ». C’est : « chaque mois de glissement équivaut à X euros, et toute option qui coûte moins que X par mois gagné mérite d’être examinée ». Cette phrase change la nature de la discussion.
Étape 4 : tester la sensibilité
Refaites le calcul avec une hypothèse basse et une hypothèse haute sur les deux postes les plus incertains (souvent le 4 et le 6). Si le résultat reste dans une fourchette où la décision ne change pas, l’incertitude n’est pas un obstacle. Si la décision bascule, vous savez quelle hypothèse il faut consolider avant le COPIL.
Retard vs réduction de périmètre vs renfort : l’arbre de décision
Une fois le coût mensuel connu, le COPIL compare trois leviers, en sachant que le triangle délai, périmètre, budget ne permet pas de tout tenir.
Les trois options
Option A : accepter le report. Vous payez le coût mensuel du retard pour chaque mois gagné sur la qualité. Pertinent si la cause du retard est une préparation insuffisante (données, tests) qui menace la bascule.
Option B : réduire le périmètre au go-live. Vous reportez certains modules ou processus à une phase 2. Vous économisez du temps projet, mais vous payez : des interfaces provisoires, un double run partiel plus long, et des bénéfices différés sur les processus décalés.
Option C : renforcer l’équipe. Vous ajoutez des consultants ou des key users pour tenir la date. Le coût du renfort est direct, et son efficacité est limitée : ajouter des ressources à une équipe en retard ralentit souvent le projet à court terme (onboarding, coordination), surtout sur les lots où le goulot est la décision métier plutôt que la capacité de production.
L’arbre de décision
Posez ces questions dans cet ordre :
- Le go-live est-il bloqué par un critère de qualité (tests, données, cutover) ? Si oui, aucun renfort ne remplace le temps de correction : privilégiez A, ou B si le défaut est localisé à un périmètre isolable.
- Le goulot est-il la capacité (volume de développements, de recette, de migration) ? Si oui, C est pertinent, à condition que le renfort soit opérationnel en moins de quelques semaines et que les tâches soient parallélisables.
- Le goulot est-il la décision (arbitrages métier non pris, design non validé) ? Dans ce cas, ni A ni C ne règlent le problème : il faut une décision du sponsor, donc un arbitrage de gouvernance.
- Existe-t-il un bloc de périmètre à faible valeur au go-live ? Si oui, B est probablement l’option la moins chère : on décale ce qui rapporte le moins.
- Y a-t-il une date non négociable (poste 5) ? Si oui, comparez le coût du plan B de conformité avec le coût de B ou C pour tenir la date.
Comparer les options en euros
Pour chaque option, estimez trois grandeurs : le coût direct de l’option, le nombre de mois de retard évité ou subi, et les coûts induits. Reprenons l’exemple fictif :
| Option | Hypothèses fictives | Effet sur le coût |
|---|---|---|
| A : 2 mois de report | 2 × 401 500 € | environ 803 000 € |
| B : report de 3 modules en phase 2, go-live tenu | 30 000 € de développements provisoires + 30 000 € par mois de bénéfices différés sur 6 mois + 10 000 € par mois de double run partiel sur 6 mois | environ 270 000 € |
| C : renfort de 4 consultants pendant 2 mois pour gagner 1 mois | 4 × 20 jours × 850 € × 2 mois, plus 1 mois de retard restant | environ 136 000 € + 401 500 € = 537 500 € |
Dans cet exemple fictif, la réduction de périmètre est l’option la moins coûteuse, car le périmètre décalé porte peu de valeur. Dans une autre situation, avec un périmètre décalé qui concentre l’essentiel des bénéfices, le classement s’inverserait. C’est le but du modèle : la bonne réponse dépend des chiffres de votre projet, pas d’une règle générale.
Quand reporter le go-live est la bonne décision
Le modèle de coût ne doit jamais devenir un argument pour forcer un go-live prématuré. Un retard coûte cher, mais une bascule ratée coûte généralement plus : arrêt de facturation, ruptures de livraison, clôture comptable compromise, perte de confiance des utilisateurs. Le report est la bonne décision quand les critères de qualité ne sont pas atteints.
Critères go/no-go à formaliser
Définissez-les avant la période critique, pas la veille du go-live :
- Tests : les scénarios bout en bout couvrant les processus critiques (commande à encaissement, achat à paiement, clôture) sont passés, et aucune anomalie bloquante ou majeure n’est ouverte.
- Données : la migration a été répétée au moins une fois à blanc, les écarts de réconciliation (stocks, soldes comptables, encours) sont expliqués et acceptés par les propriétaires de données.
- Utilisateurs : les key users et les utilisateurs critiques sont formés et ont validé leurs scénarios en recette.
- Cutover : le plan de bascule a fait l’objet d’une répétition, avec timing mesuré, plan de retour arrière et équipe de support identifiée. Le détail se trouve dans notre checklist opérationnelle de cutover de J-30 à J-3.
- Exploitation : l’hypercare est staffé, les circuits d’escalade sont connus.
Comment utiliser le modèle de coût dans cette décision
Le calcul sert à rendre le report explicite et borné, pas à le justifier a posteriori. Un bon COPIL de décision go/no-go regarde deux colonnes : le coût du report d’un mois (votre total mensuel) et le coût estimé d’un incident de bascule (arrêt de l’activité, rattrapage manuel, correction en production). Si vous ne savez pas chiffrer le second, demandez à chaque propriétaire de processus : « Si ce flux est indisponible pendant trois jours, que se passe-t-il ? ». Les réponses, même qualitatives, remettent le report en perspective.
Un point de vigilance : un report doit toujours s’accompagner d’une condition de sortie. « On reporte d’un mois » sans critère clair équivaut à reporter indéfiniment. Écrivez : « nous basculons si les critères X, Y, Z sont atteints à la date D, sinon nous reconvoquons le COPIL ».
Si vos signaux d’alerte s’accumulent et que vous hésitez, relisez notre article sur les signaux d’alerte d’un projet ERP en difficulté.
Contractualiser : pénalités, jalons, clauses de report
Le coût d’un retard doit aussi se traiter dans le contrat avec l’intégrateur et l’éditeur, idéalement avant la signature.
Jalons de paiement liés à des livrables. Reliez les paiements à des livrables vérifiables (spécifications validées, recette réussie, migration à blanc validée) plutôt qu’à des dates. Un jalon payé à la date, sans livrable accepté, ne protège de rien.
Pénalités de retard. Elles sont courantes mais souvent mal conçues : plafond trop bas pour être dissuasif, déclenchement soumis à des exclusions si larges qu’elles s’appliquent rarement. Négociez la définition du retard imputable, le plafond et le mode de calcul. Gardez en tête qu’une pénalité n’indemnise presque jamais le coût réel : elle sert surtout à aligner les priorités.
Clauses de report. Prévoyez le mécanisme : qui peut demander un report, avec quel préavis, quelles conséquences sur la facturation, qui supporte les coûts si le report est demandé par le client pour cause de non-préparation de ses équipes.
Clause de gouvernance des changements. Toute demande de changement doit avoir son impact délai et coût visible avant validation. Cela évite que le périmètre gonfle sans que le retard soit imputé.
Clauses de réversibilité et d’assistance. Elles protègent votre capacité à poursuivre si la relation se dégrade.
Ces points sont détaillés dans notre guide sur les clauses à vérifier avant de signer un contrat ERP. Pour toute rédaction contractuelle, faites relire le texte par votre conseil juridique : les clauses ci-dessus sont des repères de négociation, pas un modèle de contrat.
Gabarit d’une slide « coût du retard » pour le COPIL
Une seule slide suffit si elle est structurée. Voici le gabarit.
Titre : une phrase qui contient la décision. Exemple : « Chaque mois de retard coûte environ 400 k€ : nous demandons un arbitrage sur trois options ».
Bloc 1 (gauche) : le coût mensuel du retard. Le tableau à six postes, avec deux sous-totaux (cash, opportunité et risque) et le niveau de confiance de chaque ligne.
Bloc 2 (centre) : les trois options. Report, réduction de périmètre, renfort : coût direct, effet sur la date de go-live, risque principal.
Bloc 3 (droite) : la recommandation. Une option, la condition de sortie (critères go/no-go et date de revue) et le prochain point de décision.
Pied de slide : les hypothèses. Trois ou quatre hypothèses clés écrites en toutes lettres : TJM retenu, part des bénéfices activée, probabilité de turnover. Un COPIL qui voit les hypothèses discute des hypothèses plutôt que de contester le total.
Conseils d’usage : envoyez le tableau au contrôle de gestion avant la séance pour qu’il valide les chiffres, présentez toujours une fourchette quand une hypothèse est fragile, et consignez la décision dans le compte rendu avec son coût estimé. Ce suivi permet de comparer, au COPIL suivant, le coût prévu et le coût réel.
Pour aller plus loin
Le coût du retard n’est qu’une face de l’équation : l’autre est le budget initial. Pour comprendre comment il se construit, lisez notre analyse sur le budget d’implémentation d’un ERP et son coût réel. Pour structurer vos évaluations d’éditeurs et d’intégrateurs en amont, téléchargez notre grille d’évaluation ERP afin de comparer les offres sur des critères chiffrés.
