Vous avez souscrit un ERP SaaS à 200 000 euros par an. Trois ans plus tard, la facture dépasse 350 000 euros et personne dans l’entreprise n’est capable d’expliquer précisément pourquoi. Ce scénario est courant : selon Gartner, 69 % des entreprises constatent des dépassements de leur budget cloud, avec des écarts moyens de 15 à 21 % au-dessus des prévisions initiales (Gartner IT Budget Report).
Le problème n’est pas la migration cloud en elle-même. C’est l’absence de gouvernance financière adaptée aux spécificités d’un ERP SaaS : licences named users, modules activés, environnements de test, intégrations tierces. C’est précisément ce que couvre le FinOps appliqué à l’ERP.
Pourquoi les coûts cloud d’un ERP peuvent doubler en trois ans sans pilotage
La dérive classique : utilisateurs inactifs, snapshots non purgés, modules dormants
Un ERP SaaS facture rarement à l’usage réel. Il facture à la capacité allouée. Ce décalage crée des dérives invisibles, qui s’accumulent sur plusieurs exercices.
Les sources les plus fréquentes de dérapage :
- Licences non désactivées : un collaborateur qui quitte l’entreprise conserve souvent son compte actif pendant plusieurs mois. Multiplié par le turn-over annuel d’une ETI de 300 personnes, cela représente 15 à 30 licences inutiles en permanence.
- Modules activés mais inutilisés : lors de la mise en oeuvre, certains modules sont activés “pour ne pas y revenir”. S’ils ne sont pas adoptés dans les 12 premiers mois, ils ne le seront jamais.
- Snapshots de sauvegarde non purgés : les politiques de rétention par défaut conservent souvent 30 à 90 jours de snapshots quotidiens. Sur un environnement de plusieurs centaines de gigaoctets, le coût de stockage devient significatif.
- Environnements non-productifs actifs 24h/24 : le développement, la recette (UAT) et le bac à sable (sandbox) tournent à pleine charge les week-ends et les nuits, alors qu’ils ne sont utilisés que 40 heures par semaine.
Le FinOps n’est pas réservé aux applications cloud-native
La discipline FinOps a longtemps été associée aux workloads AWS ou Azure : instances EC2, clusters Kubernetes, stockage objet. Mais la réalité des budgets IT a changé.
La FinOps Foundation, qui maintient le cadre de référence de la discipline, a étendu son périmètre officiel en 2025 pour inclure explicitement les dépenses SaaS aux côtés du cloud public et des datacenters (FinOps Foundation Framework 2025). Son rapport d’état 2025 indique que 65 % des praticiens FinOps gèrent ou prévoient de gérer les coûts SaaS (State of FinOps 2025).
Pour de nombreuses ETI, l’ERP SaaS est le premier ou le deuxième poste de dépense logicielle. Le piloter avec la même rigueur que les workloads cloud natifs n’est pas un excès de zèle : c’est une priorité de gouvernance SI.
Les trois catégories de coûts à maîtriser dans un ERP SaaS
Coûts de licences utilisateurs : named users, concurrent, API calls
Le modèle de licence est la première source d’optimisation. Les éditeurs ERP SaaS proposent généralement plusieurs niveaux d’accès aux profils très différents en termes de prix.
Chez Microsoft Dynamics 365 par exemple, la différence entre un Full User (environ 105 dollars par mois) et un Team Member (8 dollars par mois) est considérable (Redress Compliance, Dynamics 365 Licensing 2026). Un utilisateur qui consulte des rapports ou saisit des données simples n’a pas besoin d’un accès Full User. Selon les analyses de cabinets spécialisés, la plupart des organisations peuvent reclasser 20 à 40 % de leurs sièges vers des niveaux inférieurs sans impact fonctionnel.
Les pièges à surveiller :
- Comptes de service : des identifiants techniques créés pour des intégrations ou des automatisations consomment des licences nommées si la politique de nommage n’est pas revue.
- API calls : certains éditeurs facturent les appels API au volume. Une intégration iPaaS mal dimensionnée peut générer des coûts imprévus à la montée en charge.
- Multi-entités : dans un groupe avec plusieurs filiales, les licences peuvent être mutualisées ou au contraire dupliquées selon la structure contractuelle.
Coûts d’infrastructure : storage, compute, environnements non-productifs
Les environnements non-productifs (développement, recette, UAT, sandbox) représentent en moyenne 27 % des coûts cloud totaux selon le rapport Flexera State of the Cloud. Pour un ERP SaaS hébergé en mode IaaS ou dans un cloud privé géré par l’éditeur, ce chiffre est cohérent.
La bonne pratique est d’éteindre automatiquement ces environnements en dehors des plages de travail : soirs, week-ends, jours fériés. Cette seule mesure peut réduire de 28 % les coûts de compute non-productifs selon les benchmarks publiés par les éditeurs spécialisés en gestion cloud.
Les autres leviers infrastructure :
- Revue des politiques de rétention des snapshots (passer de 90 jours à 30 jours par défaut)
- Archivage ou compression des données historiques dépassant 3 à 5 ans
- Suppression des environnements de test créés pour des projets terminés et jamais désactivés
Coûts cachés : intégrations tierces, exports de données, support premium, ISV
La facture visible n’est pas la facture totale. Un audit FinOps ERP complet doit identifier les postes secondaires :
- Extensions ISV (Independent Software Vendors) : modules tiers achetés lors du projet initial et devenus inutiles après une réorganisation fonctionnelle.
- Connecteurs iPaaS : les plateformes d’intégration (Boomi, MuleSoft, Informatica) facturent en général à la transaction ou à la connexion active. Un mapping non purgé après une migration de données continue à consommer.
- Support premium : les niveaux de support “Enterprise” ou “Platinum” coûtent souvent 15 à 25 % du coût de licence annuel. Il faut vérifier si le niveau contracté correspond réellement à la criticité des incidents rencontrés.
- Data egress : dans certains modèles cloud, exporter des données vers un outil BI externe génère des frais de transfert à surveiller.
Méthode FinOps appliquée à l’ERP : trois phases
La FinOps Foundation structure sa méthode en trois phases itératives : Inform (visibilité), Optimize (optimisation), Operate (gouvernance). Appliquée à un ERP SaaS, cette boucle doit être adaptée aux spécificités contractuelles de l’éditeur.
Phase Inform : cartographier et attribuer chaque poste de coût
L’objectif de cette première phase est de construire une vue complète et attribuée de la dépense : par module, par entité juridique, par cas d’usage, par type de licence.
Actions concrètes :
- Extraire le rapport de consommation depuis le portail éditeur (BTP Cockpit pour SAP, Azure Cost Management pour Dynamics 365, portail d’administration NetSuite).
- Croiser les licences actives avec les logs de connexion sur les 90 derniers jours.
- Identifier les environnements non-productifs et leur coût réel.
- Recenser tous les contrats ISV et connecteurs tiers.
Cette cartographie prend généralement deux à quatre semaines pour une ETI de 200 à 500 utilisateurs.
Phase Optimize : rightsizing, suppression des dormants, compression des données
Une fois la visibilité établie, les optimisations peuvent être menées en parallèle sur plusieurs axes.
Le rightsizing des licences est en général le levier le plus rapide à actionner : identifier les comptes inactifs depuis 60 jours, les reclasser ou les désactiver avec validation managériale, renégocier le volume contractuel à l’échéance.
La désactivation des modules non utilisés nécessite une validation métier préalable. Un module “inactif” dans les logs peut avoir des dépendances cachées dans des workflows automatisés.
L’extinction des environnements non-productifs hors des horaires ouvrés est une quick win dont la mise en oeuvre technique est simple, mais qui requiert l’accord des équipes développement et support.
Phase Operate : tableaux de bord mensuels, alertes seuils, gouvernance des demandes
La gouvernance est le seul moyen de ne pas revenir au point de départ dans 18 mois. Sans processus de contrôle continu, les optimisations réalisées sont progressivement érodées par de nouveaux ajouts non pilotés.
Le minimum à mettre en place :
- Un tableau de bord FinOps ERP mis à jour chaque mois : coût par utilisateur actif, coût par transaction traitée, coût de stockage par gigaoctet actif.
- Des alertes automatiques sur les seuils de consommation CPEA ou de credits cloud.
- Un processus de validation croisée DSI/DAF pour tout ajout de module, d’utilisateur ou d’environnement.
- Un comité FinOps ERP trimestriel réunissant DSI, DAF et responsables métiers.
Application par éditeur ERP
SAP RISE with SAP et BTP : comprendre la facturation CPEA
SAP RISE with SAP regroupe dans une souscription unique la licence S/4HANA Cloud, l’infrastructure managée et un crédit BTP (Business Technology Platform). La facturation BTP repose généralement sur le modèle CPEA : Cloud Platform Enterprise Agreement.
Le CPEA fonctionne par engagement annuel prépayé. L’entreprise s’engage sur un volume de crédits, qui sont ensuite consommés par les services BTP activés (intégrations, extensions, analytics). Les crédits non utilisés à la fin de l’année contractuelle sont perdus.
Les points de vigilance spécifiques à SAP :
- Le monitoring de consommation CPEA est disponible dans le BTP Cockpit, rubrique Cost and Usage Management. Il faut configurer des alertes par seuil dès la mise en service.
- Les discounts CPEA varient de 12 % pour les engagements de 50 000 à 150 000 dollars par an jusqu’à 26-28 % pour les engagements supérieurs à 5 millions de dollars (SAP BTP Pricing 2026, Atonement Licensing). La taille de l’engagement a donc un impact direct sur le discount négociable.
- Les environnements de développement et sandbox SAP sont facturés séparément du contrat RISE. Leur volume peut être significatif si plusieurs projets de personnalisation sont en cours en parallèle.
Microsoft Dynamics 365 : Azure Cost Management et optimisation des types de licences
Dynamics 365 s’appuie sur Azure. Les coûts d’infrastructure sont donc visibles via Azure Cost Management, ce qui facilite leur attribution par ressource, par environnement et par période.
L’optimisation des licences passe par une revue systématique des types de droits attribués. La différence entre un Full User Finance and Operations (environ 105 dollars par mois) et un Team Member (8 dollars par mois) justifie une analyse rigoureuse : chaque utilisateur reclassé de Full vers Team Member représente une économie de 97 dollars par mois, soit 1 164 dollars par an (Redress Compliance, Dynamics 365 Licensing 2026).
Pour une organisation avec 180 licences Finance and Operations dont 40 utilisateurs en consultation légère, le potentiel de reclassement vers Team Member représente une économie annuelle comprise entre 40 000 et 55 000 euros.
Oracle NetSuite : contrôle des modules et des environnements sandbox
NetSuite facture par module activé et par nombre d’utilisateurs nommés. Le modèle est relativement lisible, mais les dérives viennent souvent des sandbox et des SuiteApps (extensions partenaires).
Un sandbox NetSuite Standard représente environ 10 % du coût de la souscription annuelle. Un sandbox Premium peut atteindre 20 % selon la configuration contractuelle (Kimberlite Partners, NetSuite Sandbox Best Practices). Vérifier le nombre de sandbox actifs et la fréquence réelle de leur utilisation est l’une des premières actions d’un audit FinOps NetSuite.
La revue des SuiteApps actives et leur taux d’utilisation réel (disponible dans l’outil de monitoring des transactions) complète cette analyse.
Workday et Odoo.sh : mécanismes propres à chaque plateforme
Workday applique un modèle de facturation basé sur le nombre de travailleurs gérés dans le système (headcount), pas uniquement sur les utilisateurs qui se connectent. Toute augmentation d’effectif a donc un impact direct sur la facture, indépendamment de l’adoption réelle. La gouvernance doit inclure une revue de l’alignement entre l’effectif réel et le périmètre contracté.
Odoo.sh, l’offre cloud managée d’Odoo, facture par “worker” de calcul et par espace de stockage. Les branches de développement et les builds de test consomment des workers en continu si elles ne sont pas éteintes. Un nettoyage régulier des branches inactives est la mesure d’optimisation la plus immédiate.
ROI mesuré : résultats observés en pratique
Les réductions de coûts obtenues par une démarche FinOps ERP structurée varient selon la maturité initiale du pilotage.
Sur les licences utilisateurs, les reclassifications de profils et désactivations de comptes inactifs permettent généralement d’économiser 10 à 20 % du coût de licence annuel dans les 90 premiers jours. Cette fourchette est cohérente avec les données publiées sur le gaspillage des licences SaaS : selon plusieurs analyses de 2024-2025, entre 30 et 51 % des licences SaaS vont inutilisées dans les organisations (Cafeto Software, Why 30% of SaaS Licenses Go Unused).
Sur l’infrastructure, la combinaison extinction des environnements non-productifs hors des heures ouvrées, purge des snapshots et archivage des données froides produit des économies de 15 à 30 % sur le poste infrastructure cloud.
KPI FinOps à suivre pour un ERP
Trois indicateurs permettent de piloter la valeur dans le temps :
- Coût par utilisateur actif : coût total ERP SaaS divisé par le nombre d’utilisateurs ayant réalisé au moins une transaction dans le mois. Cet indicateur révèle immédiatement la proportion de licences payées et non utilisées.
- Coût par transaction traitée : pertinent pour les modules à fort volume (facturation, paiements, mouvements de stock). Il permet de comparer l’efficience à chaque exercice.
- Coût de stockage par gigaoctet actif : distingue le stockage des données courantes du stockage d’archives historiques peu consultées.
Ces trois KPI constituent le tableau de bord minimal d’un comité FinOps ERP.
Plan d’action FinOps ERP en 90 jours
Semaines 1 à 4 (Phase Inform) : Extraire les données de consommation depuis le portail éditeur. Croiser licences actives et logs de connexion sur 90 jours. Identifier et chiffrer les 5 plus gros postes de dérive. Produire une cartographie de l’ensemble des environnements et de leur coût.
Semaines 5 à 8 (Phase Optimize) : Lancer les optimisations à faible risque : désactiver les comptes inactifs depuis 60 jours (avec validation managériale), programmer l’extinction automatique des environnements non-productifs hors des horaires ouvrés, initier la revue des modules et SuiteApps/ISV dormants.
Semaines 9 à 12 (Phase Operate) : Mettre en place le tableau de bord FinOps ERP (3 KPI minimum). Configurer les alertes de consommation dans le portail éditeur. Définir et documenter le processus de validation pour tout ajout de licence, de module ou d’environnement. Programmer le premier comité FinOps ERP trimestriel.
Le moment optimal pour démarrer cette démarche : entre 3 et 6 mois avant le renouvellement contractuel, afin de disposer de données chiffrées exploitables lors de la négociation avec l’éditeur.
Pour approfondir le pilotage des coûts après mise en production, consultez notre guide Optimiser les coûts ERP après le go-live, notre méthode pour auditer les licences ERP et réduire les coûts sans risque contractuel et notre guide pour négocier votre contrat ERP avant signature.
