Le go-live est passé, les équipes utilisent l’ERP au quotidien, et le projet est officiellement “terminé”. C’est précisément le moment où les coûts commencent à dériver. Licences inutilisées, modules déployés mais jamais adoptés, infrastructure cloud surdimensionnée, contrats de maintenance reconduits sans analyse : le budget ERP augmente en silence pendant que l’attention se porte sur d’autres priorités.
Ce guide propose une méthode en quatre étapes pour reprendre le contrôle : auditer l’usage réel, rationaliser les licences et les modules, optimiser l’infrastructure, et instaurer une gouvernance FinOps durable. L’objectif n’est pas de tailler à l’aveugle, mais d’aligner les coûts sur la valeur réellement consommée.
Le paradoxe post go-live : les coûts qui augmentent quand le projet est “fini”
La phase projet mobilise l’attention sur le périmètre fonctionnel, les délais et le budget d’intégration. Une fois l’ERP en production, cette vigilance budgétaire se relâche. Les coûts récurrents (licences, maintenance, infrastructure) passent en mode “renouvellement automatique” sans revue critique.
Licences achetées mais jamais activées (shelfware)
Le shelfware reste un problème massif dans les entreprises. Selon le rapport State of ITAM 2025 de Flexera, 93 % des organisations déclarent payer pour du logiciel qui reste sur l’étagère, et 30 % des répondants estiment qu’au moins un cinquième de leur budget logiciel est associé à du shelfware.
En contexte ERP, le mécanisme est classique : les licences sont dimensionnées pour le pic d’usage prévu au moment du déploiement. Six mois plus tard, certains utilisateurs ont changé de poste, d’autres n’ont jamais terminé leur formation, et des équipes entières continuent à travailler avec leurs anciens outils en parallèle.
Modules déployés puis abandonnés par les métiers
Un module CRM activé mais jamais alimenté. Un workflow de validation des achats contourné par email. Un portail fournisseur déployé mais dont aucun fournisseur ne s’est inscrit. Ces investissements représentent non seulement un coût de licence direct, mais aussi un coût de maintenance : chaque module actif doit être mis à jour, testé lors des montées de version et supporté par l’équipe IT.
Infrastructure cloud surdimensionnée (right-sizing ignoré)
Les environnements cloud ERP sont souvent dimensionnés pour absorber les pics de charge de la migration et des premiers mois de production. Une fois le rythme de croisière atteint, personne ne revient ajuster les ressources. Selon le rapport State of FinOps 2026 de la FinOps Foundation, les organisations gaspillent en moyenne 25 à 35 % de leur dépense cloud sur des ressources inactives, des instances surprovisionnées et du stockage orphelin. Le right-sizing seul peut générer 15 à 25 % d’économies sur les coûts d’infrastructure.
Étape 1 : auditer l’usage réel de l’ERP
Avant de couper quoi que ce soit, il faut mesurer. Un audit d’usage factuel est la base de toute décision de rationalisation.
Mesurer les connexions actives vs licences payées
Extrayez de l’ERP la liste complète des comptes utilisateurs, puis croisez-la avec les logs de connexion sur les 90 derniers jours. Les catégories à identifier sont les suivantes :
- Utilisateurs actifs quotidiens : connexion et transactions chaque jour ouvré.
- Utilisateurs occasionnels : connexion moins d’une fois par semaine.
- Comptes dormants : aucune connexion depuis plus de 60 jours.
- Comptes fantômes : utilisateurs ayant quitté l’entreprise mais dont le compte reste actif.
La plupart des ERP (SAP, Oracle, Microsoft Dynamics, Sage, Cegid) disposent de rapports d’usage natifs ou via des outils tiers de Software Asset Management (SAM).
Cartographier les modules réellement utilisés
Au-delà des connexions, analysez les transactions métier par module. Un utilisateur peut se connecter chaque jour à la comptabilité sans jamais utiliser le module achats pour lequel il dispose d’une licence. Les indicateurs à suivre sont les suivants :
- Nombre de transactions par module et par mois.
- Nombre de rapports générés par module.
- Flux d’intégration actifs vs configurés.
- Fonctionnalités avancées activées mais jamais utilisées (planification capacitaire, gestion de projets, CRM intégré).
Identifier les customisations orphelines
Les développements spécifiques réalisés pendant le projet d’implémentation ont chacun un coût de maintenance récurrent. À chaque montée de version, chaque customisation doit être testée, adaptée et revalidée. Identifiez celles qui n’ont plus de sponsor métier : le responsable qui les avait demandées a changé de poste, le processus a évolué, ou la fonctionnalité est devenue standard dans les nouvelles versions de l’ERP.
Étape 2 : rationaliser les licences et les modules
L’audit produit des données. Cette étape les transforme en actions concrètes de réduction de coûts.
Reclasser les utilisateurs (full vs limited vs read-only)
La majorité des éditeurs ERP proposent plusieurs niveaux de licence, du plus complet (utilisateur nommé avec accès transactionnel complet) au plus léger (consultation seule). Reclasser un utilisateur qui ne fait que consulter des tableaux de bord d’un profil “Professional” vers un profil “Team Member” ou “Read-Only” peut diviser le coût unitaire par trois à cinq selon l’éditeur.
La démarche est la suivante :
- Croiser le profil de licence actuel avec l’usage réel mesuré à l’étape 1.
- Identifier les utilisateurs dont les transactions ne justifient pas leur niveau de licence.
- Proposer un reclassement aux responsables métiers avec les données d’usage à l’appui.
- Appliquer le changement après validation et mesurer l’économie.
Désactiver ou rendre les modules non utilisés
Un module activé mais non utilisé coûte de trois façons : licence directe, maintenance technique et charge cognitive pour l’équipe support. La décision de désactivation doit être documentée et réversible, mais elle doit être prise.
Pour chaque module identifié comme sous-utilisé, posez trois questions :
- Ce module est-il utilisé par au moins un processus métier critique ?
- Son retrait aurait-il un impact sur d’autres modules actifs (dépendances techniques) ?
- Le métier a-t-il un plan concret d’adoption dans les six prochains mois ?
Si les trois réponses sont négatives, le module doit être désactivé et la licence rendue à l’éditeur ou mise en réserve pour le prochain renouvellement.
Renégocier le contrat éditeur avec des données d’usage à l’appui
Le renouvellement du contrat de maintenance est un moment de levier trop souvent négligé. Les frais de maintenance annuels représentent généralement 18 à 22 % du coût de licence initial pour les ERP on-premise, un poste récurrent qui se cumule année après année.
Arriver à la table de négociation avec un audit d’usage documenté change la dynamique. Vous pouvez demander :
- Une réduction du volume de licences couvertes.
- Un ajustement du périmètre de maintenance aux seuls modules utilisés.
- Des conditions de sortie ou de gel sur les modules en attente d’adoption.
- Un alignement du contrat sur les profils d’usage réels plutôt que sur les profils historiques.
Étape 3 : optimiser l’infrastructure (cloud et on-premise)
Les coûts d’infrastructure représentent un levier d’économie souvent sous-exploité car ils relèvent d’une équipe différente de celle qui gère les licences.
Right-sizing des instances cloud (CPU, RAM, stockage)
Le right-sizing consiste à adapter les ressources allouées (CPU, mémoire, stockage) à la consommation réelle mesurée sur une période représentative (idéalement 30 à 90 jours incluant les pics de fin de mois).
Les étapes concrètes sont les suivantes :
- Activer le monitoring détaillé sur les instances ERP (CloudWatch pour AWS, Azure Monitor, ou les outils natifs de l’hébergeur).
- Identifier les instances dont l’utilisation CPU moyenne est inférieure à 20 % et la mémoire utilisée inférieure à 40 %.
- Proposer un redimensionnement à la taille inférieure ou un passage en instances réservées pour les charges prévisibles.
- Séparer les environnements de développement et de test (qui peuvent être éteints en dehors des heures ouvrées) des environnements de production.
Archivage des données anciennes pour réduire les volumes
Les bases de données ERP grossissent mécaniquement : transactions historiques, logs, pièces jointes, versions de documents. Au-delà de trois à cinq ans, la valeur opérationnelle de ces données diminue fortement, mais leur coût de stockage et leur impact sur les performances de l’ERP restent constants.
Mettez en place une politique d’archivage structurée :
- Définir les règles de rétention par type de données (réglementaire vs opérationnel).
- Archiver les données au-delà de la période de rétention active vers un stockage moins coûteux (stockage froid, stockage objet).
- Vérifier que les données archivées restent consultables pour les besoins réglementaires (FEC, contrôle fiscal, audit).
Planification des montées de version (coût du retard technique)
Reporter les montées de version ERP semble économiser de l’argent à court terme. En réalité, chaque version sautée accumule de la dette technique : les customisations deviennent plus complexes à migrer, le support éditeur se dégrade (voire s’arrête), et les vulnérabilités de sécurité s’accumulent.
Le coût d’une montée de version retardée de trois ans est typiquement deux à trois fois supérieur à celui de montées incrémentales régulières. Planifiez un budget annuel dédié aux montées de version et intégrez-le dans le TCO prévisionnel.
Étape 4 : instaurer une gouvernance FinOps ERP durable
Les trois premières étapes produisent des économies ponctuelles. Sans gouvernance, les coûts dérivent à nouveau en 12 à 18 mois.
Tableau de bord coût/usage mensuel
Construisez un tableau de bord synthétique qui croise les coûts ERP (licences, maintenance, infrastructure, support interne) avec les indicateurs d’usage (utilisateurs actifs, transactions par module, consommation cloud). Ce tableau doit être partagé mensuellement avec le DSI et le DAF.
Les indicateurs clés à suivre sont les suivants :
- Coût par utilisateur actif (pas par licence achetée).
- Taux d’utilisation par module (transactions réelles / capacité contractuelle).
- Coût d’infrastructure par transaction métier.
- Ratio customisations actives / customisations totales.
Revue trimestrielle licences avec les métiers
Chaque trimestre, réunissez les responsables métiers, le DSI et les achats pour une revue de 90 minutes couvrant les points suivants :
- Écart entre licences payées et licences utilisées.
- Modules à désactiver ou à réactiver.
- Demandes de nouvelles fonctionnalités vs modules existants sous-exploités.
- Préparation du prochain renouvellement éditeur.
Cette revue transforme la gestion des licences ERP d’un exercice annuel subi en un pilotage continu partagé.
Budget prévisionnel ERP glissant sur 3 ans
Le budget ERP ne peut pas être un exercice annuel figé. Construisez un modèle de coût glissant sur trois ans intégrant :
- L’évolution prévisible du nombre d’utilisateurs (croissance, acquisitions, réorganisations).
- Le calendrier des montées de version et leur coût estimé.
- Les renouvellements de contrats éditeur et les fenêtres de renégociation.
- Les projets d’extension fonctionnelle et leur impact sur les licences.
- L’évolution des coûts d’infrastructure (indexation cloud, migration éventuelle).
Ce modèle permet au DAF de provisionner correctement et au DSI de négocier en position de force.
Matrice récapitulative : les 8 leviers et leur potentiel d’économie
| Levier | Effort | Économie potentielle | Délai |
|---|---|---|---|
| Reclassement des profils de licence | Faible | 10 à 25 % sur le poste licences | 30 jours |
| Désactivation des modules non utilisés | Moyen | 5 à 15 % sur le poste licences | 60 jours |
| Suppression des comptes dormants/fantômes | Faible | 5 à 10 % sur le poste licences | 15 jours |
| Renégociation du contrat de maintenance | Moyen | 10 à 20 % sur le poste maintenance | 3 à 6 mois (calé sur le renouvellement) |
| Right-sizing cloud | Moyen | 15 à 25 % sur le poste infrastructure | 30 à 60 jours |
| Archivage des données anciennes | Moyen | 5 à 15 % sur le poste stockage | 3 à 6 mois |
| Retrait des customisations orphelines | Élevé | Réduction du coût de montée de version | 6 à 12 mois |
| Gouvernance FinOps trimestrielle | Faible (récurrent) | Prévention de la dérive (effet cumulé) | Continu |
Les quick wins (reclassement de licences, suppression de comptes dormants, premiers ajustements cloud) peuvent être réalisés en 30 jours et générer des économies visibles dès le trimestre suivant. Les actions structurelles (renégociation éditeur, retrait de customisations, gouvernance FinOps) demandent 6 à 12 mois mais sécurisent les gains sur la durée.
Pour aller plus loin sur le pilotage financier de votre ERP, consultez notre guide sur le coût total de possession et les postes cachés et notre méthode d’audit des licences ERP. Si vous structurez une gouvernance post-déploiement, notre article sur les centres d’excellence ERP et les KPI de pilotage complète la démarche FinOps présentée ici.
