Le go-live est derrière vous, le projet est clos, l’équipe projet est dissoute. Et pourtant la facture continue d’arriver, chaque année, pour des montants que personne n’a vraiment budgétés. Le coût de run d’un ERP est la partie du TCO la plus sous-estimée : il est discret, récurrent, réparti entre plusieurs lignes budgétaires et plusieurs propriétaires.
Cet article propose un chiffrage honnête : les 7 postes du coût de run annuel, les variables qui font bouger chacun, des fourchettes par profil d’entreprise (clairement séparées entre données sourcées et estimations terrain à valider), les dérives classiques, 5 leviers d’optimisation et un modèle de budget à copier. Il complète notre comparatif TCO sur 5 ans, centré sur le choix d’éditeur, par une vue d’exploitation année par année.
Pourquoi le run est la partie la moins budgétée du TCO
Pendant le projet, tout est visible : un budget, un sponsor, un planning, un comité de pilotage. Après le go-live, les dépenses se dispersent : l’abonnement chez les achats, le support chez la DSI, l’hébergement dans une enveloppe cloud générale, les évolutions dans les budgets métiers. Aucune ligne ne porte le nom « ERP » et personne ne voit le total.
Trois mécanismes expliquent ce angle mort :
- L’effet de bascule d’attention. Le comité de pilotage s’arrête avec le projet. Plus personne ne challenge les contrats.
- La nature récurrente. Une dépense qui se reconduit tacitement n’est plus arbitrée. Elle est subie.
- L’indexation silencieuse. Les hausses de prix s’appliquent sans décision. Selon une analyste de Gartner citée par The Register (septembre 2025), les éditeurs SaaS ont relevé leurs prix « entre 9 et 25 % cette année », quand les budgets IT des entreprises progressent de 2,8 % par an selon les enquêtes clients de Gartner.
Conséquence : le budget de run dérive mécaniquement plus vite que l’enveloppe qui le finance. Pour cadrer cette enveloppe dans le cycle annuel, voyez aussi notre guide du budget ERP 2027.
Les 7 postes du coût de run
1. Licences et abonnements
C’est le poste le plus visible. En SaaS, il prend la forme d’un abonnement par utilisateur, par module ou par volume de transactions. En on-premise, les licences perpétuelles sont déjà payées : le poste se réduit aux licences complémentaires (nouveaux utilisateurs, nouveaux modules).
Variables de coût :
- type d’utilisateur (complet, limité, self-service) : le mix change la facture de façon importante ;
- modules activés mais peu utilisés ;
- indexation contractuelle (indice, plafond ou hausse libre) ;
- paliers de volume (transactions, entités juridiques, stockage).
2. Maintenance éditeur (on-premise)
En on-premise, la maintenance se calcule en pourcentage de la valeur des licences. Les ordres de grandeur publics les plus connus sont ceux de SAP : le programme Enterprise Support a été fixé à 22 % des frais de licence, contre 17 % pour l’ancien programme (InfoWorld, 2009). Ces pourcentages restent la référence du marché pour les gros éditeurs, mais ils datent : vérifiez-les contrat en main, ils varient selon l’éditeur, le niveau de support et ce que vous avez négocié.
En SaaS, ce poste disparaît en tant que tel : le support est inclus dans l’abonnement. C’est l’une des différences structurelles entre les deux modèles (voir plus bas).
Variables de coût : assiette de calcul (prix catalogue ou prix négocié), niveau de support, clauses d’indexation, périmètre des licences réellement couvertes.
3. Support intégrateur et TMA
Le support applicatif (tierce maintenance applicative) couvre la correction d’anomalies, l’assistance aux utilisateurs clés, les mises à jour et le suivi des interfaces. Il est facturé au forfait, en banque d’heures ou à la demande. Notre guide du contrat de TMA ERP détaille les niveaux de service et les clauses à surveiller.
Variables de coût : niveau de service (heures ouvrées ou 24/7), nombre d’interfaces, volume de personnalisations, qualité de la documentation reprise, turnover côté intégrateur.
4. Infrastructure et hébergement
En SaaS, l’infrastructure est incluse, mais les environnements supplémentaires (test, formation, pré-production), le stockage additionnel et les sauvegardes étendues peuvent être facturés à part. En on-premise ou en cloud privé, ce poste comprend serveurs ou instances, bases de données, sauvegarde, supervision, sécurité et exploitation.
Le sujet cloud est généralement mal piloté : selon le rapport State of the Cloud 2025 de Flexera, 84 % des organisations peinent à maîtriser leurs dépenses cloud et les budgets cloud dépassent déjà leurs limites de 17 %.
Variables de coût : nombre d’environnements, dimensionnement des instances, politique d’arrêt hors heures, volumétrie de données, exigences de continuité (PRA).
5. Évolutions et projets mineurs
Un ERP vivant évolue : nouveaux états, nouveaux workflows, nouvelle entité, nouvel entrepôt, adaptation à une réglementation. Ce poste est le plus souvent oublié du budget de run, alors qu’il est quasi certain. Les réformes réglementaires (facturation électronique, reporting de durabilité) en sont des moteurs récurrents.
Variables de coût : dette de personnalisations, gouvernance des demandes (qui arbitre ?), disponibilité d’une roadmap de l’éditeur couvrant le besoin en standard.
6. Équipe interne (centre de compétences)
C’est le poste le plus sous-estimé, car il n’apparaît dans aucune facture externe. Il comprend le responsable applicatif, les key users, les administrateurs fonctionnels et techniques, et le temps des métiers consacré aux recettes et aux demandes. Une équipe interne trop réduite se paie ensuite en dépendance totale à l’intégrateur et en lenteur de traitement. Voyez notre article sur le centre d’excellence ERP pour le dimensionnement.
Variables de coût : taille et complexité du périmètre, nombre de sites, maturité des key users, part du temps métier non facturée mais bien réelle.
7. Formation continue et conformité
Arrivées de nouveaux collaborateurs, changements de version, nouvelles fonctionnalités, mises à jour réglementaires : la formation ne s’arrête pas au go-live. S’y ajoutent la conformité (audits de licences, revue des droits d’accès, tests de reprise, exigences de sécurité) et le coût des audits externes.
Variables de coût : turnover des utilisateurs, fréquence des montées de version, exposition réglementaire du secteur, audits éditeur.
Fourchettes par profil : ce qui est sourcé, ce qui est estimé
Soyons clairs : il n’existe pas de benchmark public fiable et universel du coût de run d’un ERP. Les chiffres vendus par les cabinets dépendent du périmètre, du secteur et de la méthode. Voici donc ce que nous pouvons affirmer, et ce que nous présentons comme estimation terrain à valider sur votre contexte.
Données sourcées :
- maintenance éditeur on-premise : 22 % ou 17 % de la valeur des licences chez SAP selon le programme (InfoWorld, 2009) ;
- hausses de prix SaaS : de 9 à 25 % constatées en 2025 par Gartner (The Register, 2025).
Estimations terrain (non sourcées publiquement, à valider avec vos contrats) :
| Profil | Répartition indicative du run | Ordre de grandeur annuel (estimation) |
|---|---|---|
| PME (moins de 100 utilisateurs) | Abonnement dominant, support intégrateur ponctuel, peu d’infrastructure | Entre 15 et 25 % du coût du projet initial |
| ETI (100 à 500 utilisateurs) | Abonnement ou maintenance, TMA, équipe interne dédiée | Entre 18 et 30 % du coût du projet initial |
| Groupe (multi-entités) | Équipe interne importante, évolutions continues, conformité | Entre 20 et 35 % du coût du projet initial |
Ces fourchettes sont des repères de cadrage, pas des promesses. Le meilleur indicateur reste votre propre historique : sommez les 7 postes sur les 12 derniers mois, c’est votre vraie base.
Deux précautions de lecture :
- exprimer le run en pourcentage du projet initial pénalise les projets qui ont été très bien négociés (ratio élevé sur un coût de départ bas) ;
- le coût par utilisateur est plus parlant en SaaS, mais il masque le poste « équipe interne » et les évolutions.
SaaS vs on-premise : ce qui bouge dans la structure du run
| Poste | SaaS | On-premise |
|---|---|---|
| Licences / abonnement | Récurrent, poste principal | Perpétuel, déjà payé |
| Maintenance éditeur | Incluse dans l’abonnement | Pourcentage annuel des licences |
| Infrastructure | Incluse (hors environnements et stockage en plus) | À votre charge |
| Mises à jour | Imposées par l’éditeur, tests à prévoir | Planifiées par vous, coûteuses |
| Indexation | Hausses de renouvellement | Indexation de la maintenance |
| Équipe interne | Plus légère sur l’infra, identique sur le fonctionnel | Compétences infra et base de données à conserver |
Le SaaS ne supprime pas le run, il déplace sa structure : moins d’infrastructure et de maintenance, mais un abonnement dont le prix se renégocie chaque année. Le vrai risque devient le renouvellement. Sur ce point, voyez notre guide sur la négociation des renouvellements ERP SaaS et le comparatif TCO sur 5 ans.
5 erreurs classiques sur le coût de run
Chaque erreur suit le même schéma : le piège, sa conséquence, la contre-mesure.
1. Laisser l’indexation courir sans plafond
- Piège : une clause d’indexation libre, jamais relue.
- Conséquence : les hausses se cumulent. Gartner relève des hausses SaaS de 9 à 25 % en 2025 (The Register), très au-dessus des budgets IT (+2,8 % par an) : l’écart se creuse chaque année.
- Contre-mesure : négocier un plafond ou un indice contractuel, et calculer l’effet cumulé sur cinq ans avant de signer.
2. Payer du shelfware
- Piège : des licences ou modules achetés mais non utilisés, reconduits par défaut.
- Conséquence : une dépense récurrente sans valeur. Les audits d’usage révèlent régulièrement des comptes inactifs et des modules non déployés (constat terrain, non chiffré ici faute de source publique ERP).
- Contre-mesure : un audit d’usage annuel avant chaque renouvellement. Voyez l’audit des licences ERP.
3. Oublier les environnements
- Piège : un environnement de test ou de formation créé pour le projet reste allumé des années.
- Conséquence : des instances inactives facturées, dans un contexte où 84 % des organisations peinent à maîtriser leurs dépenses cloud (Flexera, 2025).
- Contre-mesure : un inventaire des environnements avec propriétaire, et une règle d’arrêt hors heures ou de suppression à échéance.
4. Accumuler les personnalisations
- Piège : chaque développement spécifique paraît peu coûteux à construire.
- Conséquence : coûts récurrents de tests à chaque montée de version, de documentation et de compétences rares, qui gonflent la TMA et les évolutions.
- Contre-mesure : revenir au standard quand l’éditeur couvre le besoin, et exiger un chiffrage du coût de maintenance avant tout développement.
5. Reconduire tacitement les contrats
- Piège : support, TMA et hébergement reconduits sans revue.
- Conséquence : des renégociations perdues et des périmètres qui ne correspondent plus à l’usage.
- Contre-mesure : un calendrier des échéances, avec ouverture de la discussion 6 à 9 mois avant le terme.
5 leviers d’optimisation et gains attendus
Les gains dépendent de votre point de départ. Nous ne les chiffrons que lorsqu’une source existe ; sinon, nous indiquons le mécanisme.
- Rightsizing des licences. Réaffecter ou supprimer les comptes inactifs, passer les utilisateurs occasionnels sur des licences limitées. Gain : direct sur le poste 1, mesurable après un audit d’usage.
- Renégociation proactive. Ouvrir la discussion 6 à 9 mois avant l’échéance, avec des alternatives crédibles. Gain : limiter l’indexation, obtenir un plafond ou un engagement pluriannuel.
- Rationalisation des environnements. Éteindre hors heures, supprimer les instances inutiles, arrêter les environnements de projet. Gain : réduction du poste 4, d’autant plus forte que la gouvernance cloud était absente.
- Réduction de la dette de personnalisations. Revenir au standard quand l’éditeur couvre désormais le besoin. Gain : moins de coûts de test, de TMA et de risque lors des montées de version.
- Gouvernance FinOps et pilotage unique. Un propriétaire du budget de run, un tableau de bord trimestriel, un comité de revue. Gain : c’est le levier qui rend les quatre autres durables. Notre guide optimiser les coûts ERP après le go-live en détaille la mise en place.
Exemple de lecture : un run d’ETI, illustration hypothétique
Pour rendre la répartition concrète, prenons une ETI fictive de 200 utilisateurs, ERP en SaaS, projet initial de 1,5 M€. Les montants ci-dessous sont purement illustratifs : ils ne proviennent d’aucune étude et servent uniquement à montrer comment lire un budget de run.
- Abonnement : le poste dominant, souvent plus de la moitié du total.
- Support intégrateur / TMA : un poste de taille moyenne, très dépendant du nombre d’interfaces.
- Évolutions : une enveloppe annuelle du même ordre que la TMA, parfois supérieure l’année d’une réforme réglementaire.
- Équipe interne : deux à quatre personnes à temps plein, poste invisible dans les factures mais souvent aussi lourd que l’abonnement.
- Infrastructure, formation et conformité : des postes plus petits individuellement, mais qui s’additionnent.
Trois enseignements se dégagent, quel que soit le profil :
- Le total réel est presque toujours supérieur à la somme des factures. Tant que le temps interne n’est pas valorisé, le budget de run paraît artificiellement bas, et la comparaison SaaS contre on-premise est faussée.
- Les postes ne sont pas indépendants. Réduire l’équipe interne augmente la TMA ; accumuler des personnalisations augmente la TMA, les évolutions et la formation ; un abonnement sous-dimensionné fait grimper les licences complémentaires.
- La variabilité vient des décisions, pas du marché. Deux entreprises avec le même ERP et le même nombre d’utilisateurs peuvent avoir des coûts de run très différents, selon leur gouvernance des demandes, leur discipline sur les environnements et la qualité de leur négociation.
Pour passer de l’illustration à votre réalité, collectez les factures des 12 derniers mois, valorisez le temps interne (ETP multiplié par le coût complet chargé) et classez chaque ligne dans l’un des 7 postes. Les lignes que vous ne savez pas classer sont, en général, celles qu’il faut examiner en premier.
Modèle de budget de run : tableau à copier
Ce tableau est la base d’un budget de run lisible par le DAF. Remplissez-le avec vos contrats réels et attribuez un propriétaire à chaque ligne.
| Poste | Base de calcul | Indexation | Propriétaire |
|---|---|---|---|
| Licences / abonnements | Nb d’utilisateurs par type x tarif contractuel | Indice ou plafond contractuel | DSI + Achats |
| Maintenance éditeur | % de la valeur des licences | Clause du contrat de maintenance | DSI |
| Support intégrateur / TMA | Forfait ou banque d’heures | Révision annuelle du contrat | Responsable applicatif |
| Infrastructure / hébergement | Instances, stockage, environnements | Tarifs du fournisseur cloud | DSI / Infra |
| Évolutions et projets mineurs | Enveloppe annuelle, arbitrée par un comité | Aucune, révisée annuellement | Responsable applicatif + métiers |
| Équipe interne | ETP x coût complet chargé | Politique salariale | DRH + DSI |
| Formation et conformité | Nb de nouveaux utilisateurs, audits, certifications | Tarifs des organismes | DSI + métiers |
Complétez par trois lignes de pilotage : un total annuel, un ratio run / coût du projet initial et un coût par utilisateur actif. Ces trois indicateurs suffisent à repérer une dérive d’une année sur l’autre.
Pour aller plus loin
Pour comparer votre budget de run à une grille structurée, téléchargez notre grille d’évaluation ERP : 30 critères sur 100 points. Vous pouvez aussi nous contacter pour un benchmark de votre coût de run sur vos 7 postes.
