Le go-live n’est pas une ligne d’arrivée. C’est la ligne de départ d’une phase plus longue, plus exigeante et moins bien documentée : faire en sorte que l’ERP tienne ses promesses dans la durée.
La majorité des organisations mettent fin à la phase projet dès que le système est en production. L’équipe se disperse, le budget est consommé, et personne ne mesure plus rien de façon rigoureuse. Résultat prévisible : les modules secondaires sont abandonnés, les Excel parallèles ressurgissent, et deux ans après le go-live, le COMEX demande pourquoi l’ERP n’a toujours pas livré les gains attendus.
Ce guide donne au DSI les 15 KPI structurants pour piloter la performance ERP dès J+1, organisés en trois groupes : stabilité technique, adoption réelle, et valeur métier mesurable.
Pourquoi mesurer après le go-live, et pas seulement pendant le projet
Pendant la phase projet, les KPI se concentrent sur la livraison : respect des délais, budget consommé, couverture des cas de test. Ces indicateurs sont utiles mais insuffisants. Ils mesurent si vous avez déployé le système, pas si le système fonctionne.
La valeur d’un ERP se construit dans les 12 à 36 mois qui suivent le go-live, pas pendant les semaines de paramétrage. Les retours sur investissement se matérialisent en moyenne entre 2 et 3 ans après la mise en production, à condition que le système soit bien utilisé, que les données soient fiables, et que les processus aient effectivement évolué.
Un tableau de bord post go-live a trois objectifs distincts :
- Détecter les dérives tôt : un taux d’adoption qui stagne à 60 % après 3 mois est un signal d’alarme, pas une anomalie temporaire.
- Quantifier la valeur créée : sans mesure, l’ERP reste un coût. Avec des KPI métier, il devient un investissement dont on peut démontrer le ROI.
- Piloter les arbitrages : le CoE (centre d’excellence ERP) priorise son backlog d’évolutions sur la base de faits, pas d’intuitions.
Groupe 1, KPI de stabilité technique (5 indicateurs)
Les KPI techniques sont les premiers à mettre en place. Ils mesurent la fiabilité du socle sur lequel repose l’ensemble du système.
KPI 1, Taux de disponibilité (uptime)
Définition : pourcentage de temps pendant lequel le système est accessible aux utilisateurs, hors fenêtres de maintenance planifiées.
Comment mesurer : via les outils de monitoring applicatif (Dynatrace, Datadog, New Relic, ou le tableau de bord de votre hébergeur cloud). La plupart des éditeurs SaaS publient leur uptime sur une page de statut publique.
Seuils recommandés :
- Cible minimum : 99,5 % (équivalent à moins de 44 heures d’indisponibilité non planifiée par an)
- Cible pour un ERP critique en mode SaaS : 99,9 %
Fréquence : mensuelle, avec un rapport trimestriel d’historique.
Point d’attention : distinguer l’uptime de la disponibilité fonctionnelle. Un système techniquement “disponible” peut être inutilisable si une interface critique est en erreur. Incluez dans votre mesure les flux d’intégration (API, EDI, connecteurs bancaires).
KPI 2, Temps de réponse des transactions critiques
Définition : durée d’exécution des transactions à fort volume ou à fort impact métier (validation d’une commande, clôture d’un lot de production, génération d’un état financier).
Comment mesurer : via les logs applicatifs ou les outils de monitoring des performances (APM). Identifiez les 10 à 15 transactions les plus utilisées et mesurez leur P95 (le temps que 95 % des appels respectent).
Seuils recommandés :
- Transactions standard : < 3 secondes
- Etats et rapports : < 15 secondes
- Traitements batch nocturnes : < 4 heures (à adapter selon le volume)
Fréquence : hebdomadaire en phase hypercare (J+0 à J+90), mensuelle ensuite.
KPI 3, Taux d’erreur applicative
Définition : proportion de transactions qui se terminent en erreur (exception non gérée, timeout, échec de validation technique) par rapport au volume total.
Comment mesurer : via les logs d’erreur du serveur applicatif et les alertes du système de monitoring.
Seuils recommandés :
- Cible : < 0,5 % des transactions
- Seuil d’alerte immédiate : > 2 % sur une période de 15 minutes
Fréquence : temps réel en phase hypercare, mensuelle ensuite.
KPI 4, Délai moyen de résolution des incidents
Définition : temps écoulé entre l’ouverture d’un ticket de support et sa résolution effective (not sa fermeture administrative, sa résolution réelle pour l’utilisateur).
Comment mesurer : via l’outil de ticketing (Jira Service Management, ServiceNow, ou le portail support de l’intégrateur). Mesurez séparément les incidents critiques (blocage d’un processus métier) et les incidents standard.
Seuils recommandés :
- Incident critique (P1, blocage production) : résolution < 4 heures
- Incident majeur (P2, contournement possible) : résolution < 48 heures
- Incident mineur (P3, gêne sans blocage) : résolution < 5 jours ouvrés
Fréquence : mensuelle, avec revue systématique des P1 en comité opérationnel.
KPI 5, Évolution du volume de tickets de support
Définition : nombre de tickets ouverts par semaine ou par mois, suivi en tendance depuis le go-live.
Interprétation : un volume élevé les premières semaines est normal (phase d’apprentissage). La trajectoire compte plus que le chiffre absolu. Un volume qui reste stable ou augmente après 3 mois indique un problème de formation, de paramétrage ou de qualité de données, pas une anomalie transitoire.
Seuil d’alerte : volume en hausse de plus de 20 % deux mois consécutifs après la phase hypercare.
Fréquence : hebdomadaire en phase hypercare, mensuelle ensuite.
Groupe 2, KPI d’adoption et d’usage réel (5 indicateurs)
La stabilité technique est nécessaire, mais insuffisante. Un système disponible à 99,9 % et que personne n’utilise correctement ne crée aucune valeur.
KPI 6, Taux d’adoption par utilisateur licencié
Définition : proportion d’utilisateurs ayant effectué au moins une session active dans l’ERP au cours des 30 derniers jours, rapportée au nombre total d’utilisateurs sous licence.
Comment mesurer : via les logs de connexion de l’ERP (la plupart des systèmes modernes exposent ce rapport nativement dans leur console d’administration).
Seuils recommandés :
- J+30 : > 70 % (les retardataires ont des raisons légitimes, congés, pic de charge)
- J+90 : > 85 %
- J+180 : > 90 %
Point d’attention : une connexion ne suffit pas. Croisez ce KPI avec le KPI 7 pour distinguer les utilisateurs réels des utilisateurs qui se connectent mais continuent à travailler hors système.
KPI 7, Taux de saisie directe vs contournements détectés
Définition : proportion des transactions métier effectuées directement dans l’ERP, par rapport aux transactions qui font l’objet d’un retraitement manuel ou d’un contournement identifié (saisie en double dans un Excel, mail pour compenser un workflow non utilisé, etc.).
Comment mesurer : c’est le KPI le plus difficile à automatiser. Deux approches :
- Audit par sondage : questionner les key users de chaque métier sur leurs pratiques réelles (enquête trimestrielle, 15 minutes).
- Analyse des données : comparer le volume de commandes dans l’ERP avec le volume de bons de commande papier ou de validations par email sortantes. Tout écart révèle un contournement.
Seuil d’alerte : plus de 15 % de transactions contournant le workflow ERP après 6 mois.
KPI 8, Taux de complétion des workflows intégrés
Définition : proportion des flux de validation configurés dans l’ERP (approbation de commande, validation facture, clôture de bon de travail) qui sont effectivement complétés dans le système, sans sortie manuelle.
Comment mesurer : via les rapports de workflow de l’ERP (SAP, Oracle, Microsoft Dynamics exposent ces rapports dans leurs outils analytiques natifs).
Processus prioritaires à suivre :
- Circuit de validation des achats (purchase order approval)
- Validation des notes de frais
- Cycle order-to-cash complet (commande → expédition → facture → encaissement)
- Rapprochement bancaire automatisé
Cible : > 90 % de complétion dans le système après 6 mois de production.
KPI 9, Taux d’utilisation des modules secondaires
Définition : pourcentage des modules déployés (CRM, gestion de projets, qualité, maintenance) qui sont activement utilisés par les équipes cibles.
Pourquoi c’est critique : les modules secondaires sont souvent les premiers abandonnés après le go-live. Leur non-utilisation représente un coût double, licence payée pour rien, et processus opérationnel qui repart sur l’ancien système (souvent Excel ou email).
Comment mesurer : nombre de transactions saisies par module sur les 30 derniers jours. Comparez avec les objectifs définis en phase de cadrage.
Seuil d’alerte : un module avec moins de 20 % du volume de transactions prévu en phase de conception après 3 mois est un module en décrochage.
KPI 10, Score de satisfaction utilisateur (CSAT interne)
Définition : note de satisfaction des utilisateurs vis-à-vis de l’ERP, collectée via une enquête courte et régulière (3 à 5 questions, notation sur 5 ou 10).
Comment mesurer : enquête trimestrielle diffusée par email ou via un outil interne (Microsoft Forms, Typeform). Questions recommandées :
- “L’ERP vous permet-il de réaliser votre travail plus efficacement qu’avant ?” (1-5)
- “Avez-vous eu recours à des contournements pour compléter vos tâches cette semaine ?” (oui/non)
- “Recommanderiez-vous l’ERP actuel à un collègue dans la même situation ?” (NPS 0-10)
Interprétation : une baisse du score sur deux trimestres consécutifs est un signal d’alerte sérieux, souvent révélateur d’un problème de formation, de performance ou d’un module mal configuré.
Groupe 3, KPI de valeur métier et ROI (5 indicateurs)
C’est le groupe le plus difficile à mesurer, mais le plus important pour justifier l’investissement ERP devant le COMEX.
KPI 11, Délai de clôture mensuelle comptable
Définition : nombre de jours ouvrés entre la fin du mois et la disponibilité des états financiers définitifs (compte de résultat, bilan intermédiaire, reporting de gestion).
Pourquoi le suivre : réduire le délai de clôture est l’un des gains ERP les plus faciles à quantifier et les plus visibles pour la direction financière. Un ERP mal intégré augmente ce délai ; un ERP bien paramétré le réduit significativement.
Mesure de référence : établissez la baseline pré-ERP (combien de jours en moyenne avant le projet ?), puis suivez l’évolution mensuelle.
Cible typique : passer de 10-15 jours ouvrés (sans ERP ou avec ERP mal utilisé) à 4-6 jours ouvrés après 12 mois de stabilisation.
KPI 12, Taux d’exactitude des stocks
Définition : écart entre les stocks affichés dans l’ERP et les stocks physiquement constatés lors d’inventaires tournants ou de comptages ponctuels.
Comment mesurer : (stocks ERP - stocks physiques) / stocks ERP × 100. À mesurer par catégorie de produit et par entrepôt.
Cible : < 2 % d’écart pour les références à forte rotation, < 5 % pour les références à faible rotation.
Indicateur proxy : si votre taux d’écart est stable ou augmente après 6 mois, c’est souvent le signe de saisies manuelles non conformes ou de flux d’entrée/sortie non enregistrés dans l’ERP.
KPI 13, Durée du cycle order-to-cash
Définition : temps moyen entre la réception d’une commande client et l’encaissement effectif du paiement correspondant.
Pourquoi c’est stratégique : ce cycle intègre la prise de commande, la préparation, l’expédition, la facturation et le recouvrement. Chaque étape non automatisée dans l’ERP rallonge le cycle et impacte directement le BFR (besoin en fonds de roulement).
Comment mesurer : dans les ERP modernes, ce rapport est natif (SAP, Oracle, Microsoft Dynamics). Pour les systèmes plus anciens, croisez les dates de commande, expédition, facturation et encaissement depuis les tables de données.
Cible d’amélioration : réduction de 20 à 30 % du cycle moyen dans les 18 mois post go-live, à calibrer selon votre baseline et votre secteur.
KPI 14, Taux d’automatisation des processus
Définition : proportion de tâches répétitives (rapprochement bancaire, relances clients automatiques, génération de commandes de réapprovisionnement, calcul de paie) exécutées sans intervention manuelle, via les automatisations configurées dans l’ERP.
Comment mesurer : recensez les processus automatisables identifiés en phase de conception. Pour chacun, vérifiez s’il est effectivement automatisé et mesurez le volume de cas traités automatiquement vs manuellement.
Cible progressive :
- J+6 mois : > 60 % des processus automatisables actifs
- J+12 mois : > 80 %
- J+24 mois : > 90 % (les 10 % restants correspondent aux cas d’exception légitimes)
KPI 15, ROI cumulé (gains documentés / coût total de possession)
Définition : rapport entre les économies et gains documentés depuis le go-live (réduction des effectifs administratifs, diminution des erreurs de facturation, stock optimisé, délais de recouvrement raccourcis) et le coût total de possession de l’ERP (licences, intégration, maintenance, formation continue).
Comment mesurer : construisez un tableau de bord financier avec :
- Colonne coûts : licences annuelles + coûts de maintenance + coûts internes (temps passé par l’équipe CoE)
- Colonne gains : économies mesurées par rapport à la baseline pré-ERP, trimestriellement
Fréquence : revue semestrielle, présentée au COMEX.
Réalité terrain : les études de marché situent le ROI moyen d’un ERP à environ 1,5 fois l’investissement sur 3 ans (Panorama Consulting, ERP Report), mais ce chiffre n’a de sens que si vous mesurez réellement vos gains. Sans mesure rigoureuse, le ROI est invérifiable, et la prochaine négociation de budget sera difficile.
Mettre en place ce tableau de bord : organisation et outillage
Avoir ces 15 KPI sur papier ne suffit pas. Il faut une structure pour les collecter, les analyser et les utiliser.
Étape 1, Désigner un propriétaire : chaque KPI doit avoir un propriétaire identifié (responsable CoE pour les KPI techniques, DAF pour les KPI financiers, directeur métier pour l’adoption). Sans propriétaire, les KPI ne sont pas renseignés.
Étape 2, Automatiser la collecte : les KPI techniques (uptime, temps de réponse, tickets) doivent être automatisés. Les KPI d’adoption et de valeur métier peuvent nécessiter des extractions manuelles les premiers mois, mais l’objectif est de les automatiser progressivement.
Étape 3, Construire le dashboard : la plupart des éditeurs proposent des outils de reporting natifs (SAP Analytics Cloud, Oracle Analytics, Power BI connecté à Dynamics). Commencez simple, un tableau avec 15 lignes suffit. La sophistication vient ensuite.
Étape 4, Cadencer les revues : un comité opérationnel mensuel sur les KPI techniques et d’adoption, un comité stratégique trimestriel sur la valeur métier. Sans revue formelle, les données s’accumulent sans décision.
Pour la mise en place du cadre de gouvernance associé à ce tableau de bord, consultez notre guide complet sur le centre d’excellence ERP et notre checklist de stabilisation J+90.
À retenir
Un ERP post go-live sans tableau de bord, c’est un investissement sans pilotage. Ces 15 KPI ne sont pas une liste exhaustive, ce sont les indicateurs qui permettent de détecter 80 % des problèmes avant qu’ils deviennent des crises.
La règle d’or : mesurer ce qui peut être amélioré, améliorer ce qui est mesuré. Un KPI non suivi d’action n’est qu’un chiffre. Un KPI suivi d’une décision est un levier de pilotage.
Pour aller plus loin : téléchargez notre grille d’évaluation ERP, 30 critères sur 100 points pour benchmark votre implémentation actuelle face aux meilleures pratiques du marché.
