Pourquoi les projets SAP dépassent leur budget, et comment l'éviter

Les projets SAP dépassent leur budget surtout parce que les entreprises cherchent à garder un coût bas au départ, puis encaissent le choc pendant la phase Explore, quand les ateliers fit-to-standard révèlent le périmètre réel. Dans les programmes que j'ai examinés, des dépassements de 40 à 60 % sont courants.

Réponse courte : un budget SAP dérape quand il a été fixé avant que quiconque connaisse le périmètre, et quand c'est le fournisseur, et non le client, qui contrôle ce périmètre. Surveillez le nombre d'objets WRICEF pendant la phase Explore, prenez vous-même la main sur le périmètre et conservez 10 à 20 % de réserve de votre côté.

Les moyennes des enquêtes paraissent plus rassurantes. Le ERP Report 2026 de Panorama Consulting montre que plus d'un quart des organisations ont dépassé leur budget ERP, la première cause étant des besoins technologiques supplémentaires. Les moyennes d'enquête et les programmes qui finissent sur le bureau d'un conseiller sont deux populations différentes : planifiez pour la seconde.

40-60%

de dépassement de budget, fréquent sur les programmes SAP que j'examine

Source: Noel D'Costa, observation publiée

Cet article porte sur le dépassement, pas sur le chiffre de départ. Pour les fourchettes de coût selon la taille de l'entreprise, la répartition des dépenses, les taux journaliers et une formule de budget, lisez mon guide sur le coût d'une mise en œuvre SAP.

Sur les 21 programmes SAP que j'ai dirigés ou redressés, les mêmes causes reviennent. La plupart sont visibles avant la signature du contrat.

1. Le budget est fixé bas, puis Explore révèle le périmètre réel

C'est la raison la plus fréquente que je constate. Les entreprises cherchent à garder un coût bas au départ, souvent parce que le business case a besoin d'un chiffre que le conseil d'administration approuvera. Puis vient la phase Explore.

Dans SAP Activate, Explore est la phase où les ateliers fit-to-standard confrontent les processus standard de SAP à la façon dont l'entreprise travaille réellement (SAP Learning). Chaque écart identifié devient un élément du backlog : un état, une interface, une conversion, une extension, un formulaire ou un workflow. Aucun ne figurait dans le prix initial.

Le budget n'était pas faux à cause d'une erreur de calcul. Il était faux parce qu'il avait été fixé avant que le périmètre existe. Si vous le pouvez, menez une courte évaluation fit-to-standard avant d'approuver le chiffre définitif.

2. Le fournisseur contrôle le périmètre

La plus grosse erreur de coût que je vois avant la signature, c'est de laisser le fournisseur contrôler le périmètre. Quand l'intégrateur rédige le périmètre, celui-ci décrit ce que l'intégrateur prévoit de livrer, pas ce dont l'entreprise a besoin.

Les écarts réapparaissent plus tard sous forme de demandes de modification, et chacune est chiffrée par le même fournisseur. Rédigez le périmètre vous-même, ou faites-le rédiger avec vous par quelqu'un d'indépendant de la mise en œuvre.

3. Des changements de périmètre sans maîtrise des coûts

Une chaîne de distribution avait budgété 5 M$ et a terminé à 12,3 M$. Un recueil des besoins insuffisant a entraîné des changements de périmètre permanents. À mi-parcours, elle a découvert que ses processus de gestion des stocks ne correspondaient pas aux fonctionnalités standard de SAP, et une personnalisation lourde a suivi.

Elle avait aussi sous-estimé la migration des données depuis ses systèmes historiques. Aligner les processus sur le standard dès la conception aurait coûté bien moins cher.

4. Des plannings dictés par la pression de la direction

Un programme industriel mondial a dépassé son budget de 143 % (14 M$ au lieu des 5,8 M$ prévus) et a démarré avec 11 mois de retard. Les causes : une pression irréaliste de la direction sur les délais, une équipe interne en sous-effectif, trop de modules à la fois et un intégrateur choisi parce qu'il était le moins cher, sans expertise sectorielle.

Moins cher ne veut pas dire meilleur. Un client qui avait choisi l'option de mise en œuvre la moins coûteuse a fini par dépenser 30 % de plus pour corriger des problèmes qu'une équipe plus expérimentée aurait évités.

5. Des ressources internes à temps partiel

Les programmes qui désignent des représentants à temps partiel au lieu de responsables de processus dédiés perdent des jours à chaque décision. L'équipe interne en sous-effectif de ce programme industriel mondial a été l'une des raisons de ses 11 mois de retard.

Vos meilleurs collaborateurs seront mobilisés à moitié ou plus sur le programme pendant des mois. Ni leur temps ni le ralentissement autour du go-live n'apparaissent dans le devis d'un fournisseur.

6. Des données découvertes trop tard

Les problèmes de données découverts en préproduction sont les plus coûteux. Le profilage doit se dérouler en parallèle du recueil des besoins, pas après le paramétrage. Trois mois de nettoyage sous la pression d'un système en production comptent systématiquement parmi les plus gros coûts de retard sur les programmes en dépassement.

J’aborde aussi ce sujet dans une vidéo sur ma chaîne YouTube (en anglais).

Le signal d'alerte le plus clair, c'est la phase Explore elle-même. Surveillez le nombre d'objets WRICEF : états, interfaces, conversions, extensions, formulaires et workflows. Si cette liste continue de s'allonger d'un atelier à l'autre, le budget est déjà en retard sur le périmètre.

Chacun des signaux ci-dessous renvoie à l'une des causes précédentes. La plupart peuvent être vérifiés lors d'une revue hebdomadaire du programme.

Signal d'alerte	Ce qu'il signifie généralement	Que faire
Le nombre de WRICEF augmente pendant Explore	Le périmètre réel est plus large que le périmètre chiffré	Recaler le budget à la fin d'Explore, avant le début de Realize
Les écarts sont comblés par défaut par « on le développe »	Les processus standard ne sont pas remis en question	Demander au responsable métier de justifier chaque écart par rapport au standard
Documents de périmètre rédigés par l'intégrateur	Le fournisseur contrôle ce qui est chiffré	Reprendre la main sur le périmètre et le revoir avec une personne indépendante
Demandes de modification examinées chaque mois ou non chiffrées	Les petits changements s'accumulent sans être vus	Chiffrer chaque demande de modification et les examiner chaque semaine
Profilage des données non démarré à la fin d'Explore	Les problèmes de données apparaîtront en test ou à la bascule	Lancer le profilage maintenant, en parallèle des besoins
Utilisateurs clés toujours à temps partiel	Les décisions ralentissent et les reprises augmentent	Remplacer leur travail quotidien ou décaler le planning

Chacun de ces contrôles traite l'une des causes ci-dessus. Les exemples viennent de programmes sur lesquels j'ai travaillé ou que j'ai examinés.

1. Prenez la main sur le périmètre. Rédigez-le côté client, figez-le à la fin d'Explore et traitez chaque changement ultérieur comme une décision chiffrée, pas comme une note d'atelier.
2. Adoptez les processus standard. Chaque personnalisation coûte deux fois : à la réalisation, puis à chaque mise à niveau. Un client industriel a économisé plus de 800 K$ en adaptant ses processus aux standards SAP plutôt qu'en personnalisant. Ce fut douloureux pour certains services, mais l'écart financier a été considérable.
3. Déployez par phases. Un client de la distribution a économisé 1,2 M$ en découpant son déploiement en trois phases sur 18 mois au lieu de tout faire d'un coup. L'investissement initial a baissé de 40 %, et les enseignements de la phase 1 ont accéléré les phases suivantes.
4. Payez l'expertise, pas un taux journalier bas. Un client de la chimie est passé d'un intégrateur SAP généraliste à un spécialiste du secteur et a dépensé 20 % de moins au total malgré des taux horaires plus élevés. Les spécialistes ont travaillé plus vite et commis moins d'erreurs.
5. Gardez la réserve de votre côté. Conservez 10 à 20 % en plus du budget, débloqués uniquement pour des risques identifiés. Une réserve intégrée au prix de l'intégrateur est dépensée selon les priorités de l'intégrateur.
6. Examinez les demandes de modification chaque semaine. Chiffrez l'impact de chacune sur le budget et le planning avant de l'approuver, pas en fin de mois.
7. Automatisez les tests de non-régression. Des outils comme Tricentis Tosca ou l'automatisation des tests de SAP elle-même sont rentables sur tout programme qui compte plus de deux cycles de test, et chaque mise à niveau après le go-live est un cycle de plus.

Pour le volet commercial, ma check-list de négociation des licences SAP et ma revue des coûts contractuels pour les CFO détaillent sur quoi insister avant de signer.

Le modèle par abonnement fait passer la dépense de l'investissement aux charges d'exploitation. Il ne supprime pas le risque de dépassement, mais il déplace l'endroit où ce risque se trouve.

GROW with SAP repose sur S/4HANA Cloud Public Edition, qui n'autorise les extensions que par des interfaces publiées. Cela limite la croissance de la liste WRICEF, et les programmes GROW durent souvent environ 6 à 9 mois. La contrepartie, c'est moins de liberté pour adapter SAP à des processus atypiques.

RISE with SAP repose sur S/4HANA Cloud Private Edition, où vous pouvez encore modifier le cœur. Le Clean Core y est une décision de gouvernance, pas une limite technique : le risque de la phase Explore est donc le même qu'en on-premise. Les programmes RISE durent généralement 9 à 18 mois, et la durée d'abonnement pluriannuelle doit apparaître dans le business case.

L'AI est un nouveau poste budgétaire, pas une économie à encaisser. Certaines fonctionnalités de Joule sont incluses dans les abonnements cloud SAP, tandis que les fonctionnalités d'AI premium sont facturées séparément. Demandez l'hypothèse de productivité derrière toute grille tarifaire d'intégrateur qui promet des économies grâce à l'AI.

Cela détermine la façon dont un grand programme pèse sur le compte de résultat. En IFRS comme en US GAAP, les coûts de construction d'un actif que vous contrôlez peuvent être immobilisés ; les coûts d'exploitation, de formation et de préparation, non. Le cloud change la réponse pour une grande partie du budget.

Élément de coût	Licence on-premise	Abonnement cloud (RISE / GROW)
Redevances de licence ou d'abonnement	Immobiliser en actif incorporel	Charge étalée sur la durée (contrat de service)
Services de paramétrage et de réalisation	Immobiliser s'ils sont directement attribuables	IFRS : souvent en charges, sauf s'ils créent un actif distinct que vous contrôlez. US GAAP : immobiliser les coûts de mise en œuvre et les amortir sur la durée d'hébergement
Main-d'œuvre interne affectée à la réalisation	Immobiliser si directement attribuable	Même répartition que ci-dessus
Formation et conduite du changement	Charge	Charge
Nettoyage des données	Charge	Charge
Outils de conversion de données que vous conservez	Immobiliser s'ils sont réutilisables	À évaluer au cas par cas
Hypercare et support	Charge	Charge

La position IFRS provient de la décision d'agenda 2021 de l'IFRS Interpretations Committee sur les coûts de paramétrage et de personnalisation dans les contrats de cloud computing. La position US GAAP provient de l'ASU 2018-15. En IFRS surtout, un business case RISE qui suppose une immobilisation comme en on-premise peut surestimer sensiblement le résultat de la première année.

La documentation détermine ce que vous conservez. Un client industriel a économisé 2,3 M$ de charges sur l'exercice en immobilisant correctement, parce qu'il avait suivi les activités des consultants avec assez de rigueur pour défendre son approche. Un autre client a dû passer par un douloureux retraitement de ses comptes parce qu'il ne pouvait pas justifier ses décisions d'immobilisation.

Les auditeurs examinent de près les grands projets immobilisés. Validez la politique comptable avec eux avant le démarrage du programme, pas à la clôture de l'exercice.

La plupart des programmes en dépassement n'ont pas connu d'échec de planification. Ils ont connu un défaut d'honnêteté au moment de la planification. Un CFO qui approuve un plan réaliste avec une réserve suffisante dépense moins que celui qui approuve un plan optimiste sans réserve.

Ce guide fait partie de mon dossier sur la mise en œuvre de SAP, qui relie tous les sujets, du business case au démarrage.

Pourquoi les mises en œuvre SAP dépassent-elles leur budget ?

Le plus souvent parce que le budget est maintenu bas au départ, puis la phase Explore révèle le périmètre réel. Les ateliers fit-to-standard transforment les écarts en états, interfaces, conversions, extensions, formulaires et workflows qui n'ont jamais été chiffrés. Un périmètre contrôlé par le fournisseur, des équipes internes à temps partiel et un travail tardif sur les données aggravent la situation.

De combien les projets SAP dépassent-ils généralement leur budget ?

Dans les programmes que j'ai examinés, des dépassements de 40 à 60 % sont courants. L'enquête 2026 de Panorama Consulting montre que plus d'un quart des organisations ont dépassé leur budget ERP. Les programmes qui arrivent jusqu'à un conseiller représentent généralement la frange en difficulté de cette population.

Quels sont les signaux d'alerte précoces d'un dépassement de budget SAP ?

Le signal le plus clair est un nombre de WRICEF qui ne cesse d'augmenter pendant la phase Explore. Les autres : des documents de périmètre rédigés par le fournisseur, des demandes de modification qui ne sont pas chiffrées chaque semaine, un profilage des données pas encore démarré et des utilisateurs clés toujours à temps partiel. Recalez le budget à la fin d'Explore si la liste s'est allongée.

Comment stopper la dérive du périmètre sur un projet SAP ?

Prenez la main sur le périmètre côté client au lieu de laisser l'intégrateur le rédiger. Figez-le à la fin d'Explore, confrontez chaque écart au standard SAP et chiffrez chaque demande de modification avant de l'approuver. Examinez les demandes de modification chaque semaine, pas en fin de mois.

RISE with SAP réduit-il le risque de dépassement de budget ?

Pas à lui seul. RISE repose sur la Private Edition, où le cœur peut encore être modifié : le risque de la phase Explore est donc le même qu'en on-premise. GROW with SAP, sur la Public Edition, limite les extensions aux interfaces publiées, ce qui restreint la croissance du périmètre.

Peut-on immobiliser les coûts de mise en œuvre de RISE with SAP ?

En partie, et cela dépend de votre référentiel comptable. L'abonnement lui-même est normalement passé en charges. En IFRS, les services de paramétrage et de personnalisation dans un contrat SaaS sont souvent eux aussi passés en charges, sauf s'ils créent un actif distinct que vous contrôlez ; en US GAAP (ASU 2018-15), les coûts de mise en œuvre sont immobilisés et amortis sur la durée d'hébergement.