Votre ERP a dix ans. Les utilisateurs se plaignent, la DSI colmate les brèches, et un éditeur vient de vous présenter un projet de migration à 400 000 euros. Avant de signer quoi que ce soit, une question s’impose : votre ERP est-il réellement inadapté, ou est-il simplement sous-exploité ?
La différence entre les deux représente des mois de projet et des centaines de milliers d’euros. Pourtant, selon les retours d’intégrateurs, une proportion significative des projets de migration découvrent en phase de cadrage que l’ERP actuel était sous-configuré plutôt qu’inadapté. La migration était alors la solution la plus coûteuse à un problème qui aurait pu être réglé autrement.
Ce guide propose une méthode de diagnostic structurée en huit étapes, conçue pour un DSI ou responsable SI d’ETI (100 à 1 000 salariés) dont l’ERP est en place depuis cinq ans ou plus. Résultat : une grille de scoring sur 40 points qui objectivera votre décision sans dépendre du biais de votre éditeur ou intégrateur actuel.
Pourquoi un audit avant la décision : éviter la migration par frustration
La migration par frustration est le scénario le plus coûteux et le plus fréquent. Un département se plaint depuis deux ans, la DSI accumule les tickets de support, et la direction arbitre en faveur du changement sans qu’un diagnostic rigoureux ait été mené.
Ce que révèle un audit que les utilisateurs ne disent pas spontanément :
- La plupart des contournements Excel signalent un problème de formation ou de paramétrage, pas une limite de l’ERP.
- Les lenteurs constatées viennent souvent d’une infrastructure vieillissante ou d’une base de données non optimisée, pas du logiciel lui-même.
- Les modules achetés et inutilisés représentent un potentiel inexploité avant d’envisager un remplacement.
La règle des trois ans. Un ERP de moins de trois ans mérite toujours un audit approfondi avant tout projet de remplacement. Le retour sur investissement d’une implémentation ERP se mesure rarement avant le troisième exercice.
Le risque du diagnostic externalisé. Faire conduire cet audit par votre intégrateur actuel ou par un éditeur concurrent crée un biais structurel. L’audit présenté ici est conçu pour être mené en interne, avec trois à cinq jours-homme répartis entre la DSI et les directions métier.
Étape 1 : Cartographier les processus réellement couverts par l’ERP
L’objectif n’est pas de lister ce que votre ERP est capable de faire, mais ce qu’il fait réellement dans votre organisation.
Ce que l’ERP est censé faire vs ce qu’il fait vraiment
Construisez une matrice à quatre quadrants pour chaque domaine fonctionnel (finance, achats, ventes, stock, production, RH) :
- Fonctions actives et satisfaisantes : ce que l’ERP couvre bien, à préserver dans tout futur système.
- Fonctions actives mais contournées : l’ERP couvre officiellement le processus, mais les utilisateurs passent par Excel ou e-mail.
- Fonctions configurées mais inutilisées : modules achetés, paramétrés, jamais adoptés.
- Fonctions absentes : besoins réels non couverts par aucun module.
Identifier les contournements (Excel, e-mail, shadow IT)
Chaque tableur parallèle est un signal diagnostique. Lors des entretiens métier, posez systématiquement : « Sur ce processus, quelle est la dernière étape que vous faites en dehors de l’ERP ? » Les réponses cartographient les lacunes réelles.
Score de l’étape 1 (sur 5 points) : 5 si la couverture est complète et active sur tous les processus clés / 0 si plus de la moitié des processus critiques sont contournés.
Étape 2 : Mesurer le taux d’utilisation réel par module
Un ERP coûte le même prix qu’il soit utilisé à 40 % ou à 90 % de ses capacités. Le taux d’utilisation révèle la valeur réelle que vous en extrayez.
Modules achetés mais inutilisés (coût mort). Listez chaque module ou option actif dans votre contrat de licence. Pour chacun, estimez le taux d’utilisation réel : nombre de transactions mensuelles ou de connexions actives divisé par le nombre théorique attendu. Un module à moins de 20 % d’utilisation après deux ans de déploiement est un coût mort.
Utilisateurs actifs vs licences payées. Comparez le nombre de licences nommées ou concurrent au nombre d’utilisateurs qui se sont connectés au moins une fois dans les 90 derniers jours. Un taux d’utilisation des licences inférieur à 70 % justifie une négociation de votre contrat avant toute décision de migration.
Score de l’étape 2 (sur 5 points) : 5 si le taux d’utilisation des modules dépasse 75 % et si plus de 80 % des licences sont actives / 0 si plus d’un tiers des modules sont inutilisés.
Étape 3 : Évaluer la dette technique (version, personnalisations, intégrations)
Niveau de version et fin de support éditeur
Vérifiez la version installée et comparez-la à la dernière version disponible. Un ERP en retard de deux versions majeures accumule une dette qui rend la mise à jour aussi coûteuse qu’une migration complète. Consultez la feuille de route de votre éditeur pour connaître la date de fin de support de votre version actuelle : si elle est à moins de 18 mois, c’est un signal d’alerte fort.
Nombre et criticité des développements spécifiques
Demandez à votre intégrateur ou à votre équipe interne le nombre de développements spécifiques actifs (rapports personnalisés non comptés). Un volume supérieur à 20 % du périmètre standard signale une dérive qui complique chaque montée de version et alourdit n’importe quel projet de migration.
Intégrations existantes (ERP vers WMS, CRM, BI, e-commerce)
Cartographiez toutes les interfaces actives. Pour chacune, notez : le format d’échange (API REST, fichier plat, EDI, copier-coller manuel), la fréquence, le volume et le taux d’erreur constaté. Les interfaces manuelles sont des candidats prioritaires à l’automatisation dans tout futur système.
Score de l’étape 3 (sur 5 points) : 5 si la version est à jour, les développements spécifiques sous 10 % du périmètre, et toutes les interfaces automatisées / 0 si la version est en fin de support, les spécifiques supérieurs à 30 %, et plusieurs interfaces manuelles critiques.
Étape 4 : Qualifier la qualité des données maîtresses
La migration de données est le premier facteur de dépassement de délais dans les projets ERP, selon le rapport 2024 de Panorama Consulting Group. Un diagnostic de données réalisé avant la décision de migrer évite de prendre conscience du problème en cours de projet, quand il est trop tard pour adapter le budget.
Méthode : score de complétude sur 5 entités clés
| Entité | Indicateur | Seuil acceptable |
|---|---|---|
| Clients | Taux de doublons | Inférieur à 3 % |
| Fournisseurs | Complétude des champs obligatoires | Supérieur à 90 % |
| Articles | Données à jour (moins de 12 mois) | Supérieur à 85 % |
| Plan de comptes | Cohérence avec les exercices clôturés | 0 écart |
| Centres de coûts | Actifs vs. archivés mal classés | Inférieur à 5 % d’anomalies |
Un taux de doublons supérieur à 10 % dans les fiches clients signifie que vous migreriez le chaos dans un système neuf. Ce diagnostic prend une demi-journée avec un export Excel et quelques requêtes simples.
Score de l’étape 4 (sur 5 points) : 5 si toutes les entités sont dans les seuils / 0 si deux entités ou plus présentent des anomalies critiques.
Étape 5 : Recenser les insatisfactions métier par département
Un ERP impopulaire n’est pas nécessairement un ERP inadapté. Cette étape distingue les frustrations liées à un mauvais paramétrage ou à une formation insuffisante, des blocages fonctionnels réels.
Méthode : 5 entretiens structurés de 45 minutes
Ciblez cinq interlocuteurs représentatifs : directeur financier (ou DAF), directeur logistique ou supply chain, directeur commercial, responsable RH, responsable production (si applicable). Posez à chacun les mêmes trois questions :
- Sur vos cinq processus les plus critiques, quelle est votre évaluation de la couverture ERP actuelle (de 1 à 5) ?
- Combien de temps par semaine estimez-vous passer en dehors de l’ERP pour compenser ses lacunes ?
- Quels changements vous feraient recommander cet ERP à un collègue d’une autre entreprise ?
Matrice impact par fréquence. Compilez les frictions identifiées dans une matrice : axe vertical (impact sur le business), axe horizontal (fréquence d’occurrence). Les frictions en haut à droite (fort impact, haute fréquence) sont les seules qui justifient une migration. Les autres relèvent de la formation ou du paramétrage.
Score de l’étape 5 (sur 5 points) : 5 si les frictions identifiées sont toutes dans les quadrants « faible impact » ou « faible fréquence » / 0 si plusieurs frictions critiques sont identifiées comme indépendantes du paramétrage.
Étape 6 : Évaluer les coûts réels de l’ERP actuel (TCO complet)
Avant de comparer le coût d’un nouveau système, il faut connaître le coût réel de l’existant. Le TCO ERP inclut des postes systématiquement sous-estimés dans les comparaisons commerciales.
| Poste | Fréquence d’oubli dans les audits |
|---|---|
| Licences + maintenance annuelle | Rarement oublié |
| Infrastructure on-premise (serveurs, backups, OS) | Parfois |
| ETP DSI mobilisés pour maintenir l’ERP | Souvent |
| Coût annuel des développements spécifiques (TMA) | Souvent |
| Coût des contournements (heures perdues en ressaisie) | Très souvent |
| Coût de non-conformité réglementaire (pénalités potentielles) | Presque toujours |
Estimez le TCO annuel complet de votre ERP actuel. Ce chiffre servira de baseline pour tout calcul de ROI d’une migration.
Score de l’étape 6 (sur 5 points) : 5 si le TCO total est maîtrisé et inférieur aux benchmarks sectoriels / 0 si le TCO dépasse significativement les coûts attendus et que les postes cachés représentent plus de 40 % du total.
Étape 7 : Benchmarker la performance technique
La performance perçue et la performance mesurée divergent souvent. Des temps de réponse dégradés peuvent venir de l’infrastructure, de la base de données non optimisée, ou du réseau, et non du logiciel lui-même.
Temps de réponse sur les requêtes critiques. Mesurez le temps d’affichage des dix écrans les plus utilisés dans votre organisation (saisie de commande, consultation de stock, édition de facture, tableau de bord financier). Au-delà de trois secondes, la productivité chute de façon mesurable. Si les lenteurs se concentrent sur un seul module ou une seule requête complexe, c’est souvent un problème d’indexation ou de requête SQL, pas un problème ERP.
Disponibilité mesurée vs SLA contractuel. Récupérez les logs de disponibilité des 12 derniers mois. Comparez-les au SLA contractuel de votre éditeur ou hébergeur. Un écart récurrent signale un problème de support ou d’infrastructure.
Incidents critiques des 12 derniers mois. Comptez le nombre d’incidents ayant bloqué la production pendant plus d’une heure. Analysez leur distribution : s’ils se concentrent sur un ou deux modules, c’est un signe de dette technique localisée. S’ils sont diffus, c’est le signe d’une instabilité systémique plus grave.
Score de l’étape 7 (sur 5 points) : 5 si les temps de réponse sont sous 2 secondes, la disponibilité conforme au SLA, et les incidents critiques inférieurs à 3 sur l’année / 0 si plusieurs de ces indicateurs sont hors seuil de façon récurrente.
Étape 8 : Décider : upgrade, replace, or extend ?
C’est l’étape de synthèse. Sur la base des sept étapes précédentes et de la grille de scoring ci-dessous, trois scénarios s’offrent à vous.
Critères de décision pour rester sur l’éditeur actuel (upgrade)
- La version actuelle est à moins de deux releases de la dernière version disponible.
- Les frictions métier identifiées à l’étape 5 relèvent du paramétrage ou de la formation.
- Le TCO reste dans les normes et la dette technique est localisée.
- L’éditeur a une feuille de route crédible pour les 5 prochaines années.
Critères de bascule vers un nouvel ERP (replace)
- La version est en fin de support ou à moins de 18 mois de l’EOL (End of Life).
- Plus de 30 % du périmètre est couvert par des développements spécifiques, rendant toute migration de version quasi-impossible.
- Les frictions métier identifiées à l’étape 5 sont structurelles (processus non supportés nativement).
- Le TCO actuel dépasse le coût d’amortissement d’un nouveau système sur 5 ans.
Le cas particulier du “replace and extend”
Une troisième voie consiste à conserver l’ERP actuel pour le socle comptable et financier, tout en ajoutant des solutions best-of-breed sur les processus les plus critiques (WMS dédié, CRM spécialisé, outil de BI, solution e-commerce). Cette approche est particulièrement pertinente quand l’ERP est solide sur la finance mais faible sur la logistique ou le commerce. Elle évite une migration complète tout en résolvant les frictions à fort impact. Pour aller plus loin sur ce sujet, consultez notre article sur le décommissionnement des ERP legacy.
La grille de scoring synthétique sur 40 points
Compilez les scores des huit étapes pour obtenir votre diagnostic global.
| Étape | Dimension auditée | Score (sur 5) |
|---|---|---|
| 1 | Couverture des processus réels | __ / 5 |
| 2 | Taux d’utilisation par module | __ / 5 |
| 3 | Dette technique (version, spécifiques, intégrations) | __ / 5 |
| 4 | Qualité des données maîtresses | __ / 5 |
| 5 | Insatisfactions métier par département | __ / 5 |
| 6 | TCO complet (coûts visibles + cachés) | __ / 5 |
| 7 | Performance technique mesurée | __ / 5 |
| 8 | Clarté de la décision (critères alignés) | __ / 5 |
| Total | __ / 40 |
Interprétation du score
- Score supérieur à 28/40 : votre ERP est encore viable. Un projet d’optimisation ciblé (formation, paramétrage, nettoyage de données, montée de version) sera plus rapide et moins coûteux qu’une migration.
- Score entre 16 et 28/40 : zone d’alerte. Certaines dimensions sont défaillantes mais le système reste opérationnel. Analysez les étapes dont le score est inférieur à 3 : si deux étapes ou plus concernent la dette technique ou la conformité, la migration devient sérieuse à envisager dans les 12 à 18 mois.
- Score inférieur à 16/40 : migration urgente. L’ERP accumule de la dette technique, des coûts cachés élevés et des frictions métier structurelles. Chaque mois de retard augmente le coût de la future migration et le risque opérationnel.
Encadré : quand l’upgrade suffit vs quand il faut migrer
L’upgrade (mise à jour majeure sur le même éditeur) est suffisant si les étapes 1, 2 et 5 sont bien notées et si les problèmes se concentrent sur les étapes 3 et 7 (dette technique et performance). En revanche, la migration vers un nouvel ERP s’impose quand les étapes 1 et 5 révèlent des lacunes fonctionnelles structurelles que l’upgrade ne résoudra pas.
Ce diagnostic doit être mené avant toute consultation externe, avant de demander un budget à votre direction générale, et surtout avant d’inviter un éditeur à faire une démonstration. Une fois qu’un commercial est dans la salle, le biais de confirmation fait le reste.
Pour la suite du processus, deux articles complémentaires :
- Si votre diagnostic pointe vers une migration, notre guide SAP S/4HANA Greenfield vs Brownfield vous aidera à structurer la décision architecturale clé du projet.
- Pour bien choisir le partenaire qui conduira votre projet, lisez notre grille de scoring pour choisir un intégrateur ERP.
Téléchargez notre grille d’évaluation ERP pour benchmark trois éditeurs côte à côte sur 30 critères et 100 points, un complément direct à la grille de diagnostic présentée ici.
