ERP en production : comment gérer les évolutions sans perdre le contrôle ? Votre ERP est en place, le go-live est derrière vous — et pourtant les demandes d’amélioration s’accumulent, les utilisateurs réclament des ajustements, et vous sentez que chaque modification pourrait fragiliser ce que vous avez mis des mois à construire ? Dans la méthode PRISM, vous êtes dans la phase SUPPORT, au cœur de son deuxième pilier : la maintenance applicative et la gestion des évolutions. Dans cet article, découvrez comment transformer ce flux de demandes en un processus maîtrisé — sans déstabiliser votre système, sans freiner vos équipes. 🎯 L’essentielUn ERP en production n’est jamais figé : les besoins évoluent, la réglementation change, les utilisateurs progressent. Ne pas cadrer ce flux, c’est prendre le risque de voir votre système se fragmenter — ou vos équipes le contourner avec des fichiers Excel.La RFC (Request for Change) est l’outil clé : elle transforme une demande informelle en décision documentée, arbitrée et tracée. Toute évolution qui entre dans l’ERP doit passer par ce canal.L’enjeu n’est pas de dire oui ou non à chaque demande, mais de prioriser par la valeur : ce qui protège l’activité, ce qui améliore la productivité, et ce qui peut attendre — ou être refusé. Pourquoi les évolutions sont inévitables… et dangereuses si mal géréesUne fois en production, votre ERP va recevoir des sollicitations de tous côtés. Les utilisateurs trouvent des cas non couverts. La réglementation évolue. Un processus qui fonctionnait bien en théorie s’avère trop rigide en pratique. C’est normal, et c’est même le signe que votre outil est utilisé.Le danger, c’est de tomber dans l’un des deux extrêmes :Tout accepter conduit à la sur-customisation. Chaque développement spécifique ajouté alourdit le système, complique les futures mises à jour et génère une dette technique qui finit par rendre l’ERP impossible à maintenir. Quand plus de 25 à 30 % du budget total du projet est absorbé par des développements spécifiques, les montées de version deviennent un chantier à part entière — coûteux et risqué.Tout refuser ou ignorer conduit au Shadow IT. Si vos équipes ne trouvent pas de réponse dans l’ERP, elles construisent leurs propres outils en dehors : fichiers Excel partagés, outils SaaS non référencés, bases Access maison. Le résultat ? Des données fragmentées, des processus non traçables, et une adoption de l’ERP qui recule silencieusement. Attention : La prolifération de fichiers Excel après le go-live n’est pas un problème de discipline utilisateur — c’est un signal que le système ne répond pas à leurs besoins réels. Avant de sanctionner, interrogez-vous sur ce qui manque dans l’outil. L’équilibre à trouver, c’est celui d’une amélioration continue structurée et arbitrée : évoluer régulièrement, mais de façon contrôlée, en gardant un ERP qui reste maintenable et upgradeable sur le long terme.La RFC : transformer une demande en décisionLa Request for Change (RFC) est la brique de base de votre gouvernance des évolutions. C’est un formulaire standardisé — souvent intégré à votre outil de ticketing — qui formalise toute demande de modification de l’ERP.Son principe est simple : aucune évolution ne part en production sans avoir été documentée, analysée et validée. Cela peut sembler lourd au départ, mais c’est ce qui vous évite les modifications « à chaud » qui déstabilisent le système et personne ne sait qui a fait quoi.Le cycle de vie d’une RFC suit plusieurs étapes clés :Soumission — L’utilisateur ou le Key User décrit son besoin en langage métier, avec l’impact attendu et la justification.Qualification — L’équipe applicative vérifie si le besoin peut être couvert par le standard de l’ERP avant d’envisager un développement. C’est l’étape la plus importante : chercher d’abord dans ce qui existe déjà.Analyse d’impact — Estimation de l’effort, des risques techniques et des impacts sur les autres modules.Arbitrage — La RFC passe devant un comité de décision qui la priorise ou la rejette.Réalisation et tests — Développement en environnement isolé, tests de non-régression, puis validation utilisateur (UAT).Mise en production et suivi — Déploiement contrôlé, avec un plan de retour arrière en cas de problème.📌 N’oubliez pas : Le principe directeur de toute RFC doit être « Standard d’abord ». Si une fonctionnalité standard de l’ERP couvre le besoin à 80 %, la bonne réponse est souvent d’adapter le processus — pas de développer un spécifique pour les 20 % restants.Au cœur de ce processus, le BPO (Business Process Owner) joue un rôle pivot. C’est lui qui porte la responsabilité métier du backlog des évolutions pour son domaine (Finance, Supply Chain, RH…). Il challenge les demandes, évalue leur valeur réelle pour l’activité, et donne l’aval final avant la mise en production. Sans BPO impliqué, la gouvernance des évolutions devient rapidement un catalogue de tickets IT déconnecté des enjeux métier.🔍 Arbitrer intelligemment : valeur, coût, risqueToutes les demandes d’évolution n’ont pas la même valeur. L’enjeu du comité d’arbitrage, c’est précisément de distinguer ce qui est indispensable, ce qui est utile, et ce qui peut attendre — ou être refusé.Une grille de priorisation simple repose sur trois niveaux :Priorité 1 — Killers : Ce qui bloque une mission critique ou répond à une obligation légale. Pas de négociation possible — c’est traité en priorité absolue. Exemple : une évolution de TVA réglementaire.Priorité 2 — Optimisations : Ce qui apporte un gain de productivité significatif, avec un ROI démontrable, mais pour lequel un contournement temporaire est possible. Exemple : l’automatisation de la saisie des temps de production via douchettes — investissement de 15 k€ pour un retour en 10 mois.Priorité 3 — Nice to have : Ce qui améliore le confort utilisateur sans impact opérationnel majeur. Ces demandes entrent dans la file d’attente, et sont souvent les premières sacrifiées en période de forte charge. Exemple concret Une équipe demande la désactivation du blocage automatique des commandes client en cas de dépassement de crédit, jugé « trop rigide ». Avant d’accepter cette RFC, le BPO identifie que le vrai problème est un manque de formation sur le processus de déblocage manuel par le service financier. Résultat : économie du coût de développement, maintien de la sécurité financière, et une session de formation plutôt qu’un spécifique. Trois red flags doivent vous alerter que votre gouvernance des évolutions décroche :La sur-customisation : chaque nouveau besoin déclenche automatiquement un développement, sans exploration du standard. Signe que le processus RFC n’est pas respecté ou que les BPO ne challengent pas suffisamment les demandes.Le backlog explosif : les RFC s’accumulent sans être arbitrées, les utilisateurs ne croient plus que leurs demandes aboutiront, et les contournements se multiplient.Le Shadow IT : vos équipes recréent en dehors de l’ERP ce qu’elles ne trouvent pas dedans. C’est le symptôme ultime d’une gouvernance des évolutions qui ne fonctionne plus.🔍 Gérer le risque de non-régressionC’est l’angle souvent sous-estimé de la gestion des évolutions : toute modification d’un module ERP peut impacter d’autres parties du système. Un ajustement dans le module achats peut perturber la comptabilité. Un changement de paramétrage sur les stocks peut affecter la facturation. C’est ce qu’on appelle le risque de non-régression.La règle d’or est simple : ne jamais tester ni déployer directement en production. Toute évolution doit suivre une chaîne d’environnements séparés :DEV → TEST → UAT → PRODUCTIONChaque étape a son rôle : le développement et les tests techniques se font en DEV et TEST, la validation métier se fait en UAT avec des cas réels, et seulement après validation formelle du BPO la modification passe en production. Mémo Maintenez toujours un plan de retour arrière (rollback) pour chaque déploiement. Si un incident survient après une mise en production, vous devez pouvoir revenir à l’état précédent rapidement — sans avoir à improviser sous pression. Les organisations les plus matures construisent progressivement un catalogue de scénarios de test par processus (Order-to-Cash, Procure-to-Pay, paie…) qui sont rejoués à chaque modification. C’est un investissement initial, mais il évite les mauvaises surprises en cascade.Les KPI pour piloter vos évolutionsSans indicateurs, la gestion des évolutions se fait à l’intuition — et les dérives passent inaperçues. Quatre KPI essentiels suffisent pour avoir une vision claire :Taille du backlog en semaines de capacité : combien de semaines de travail représentent vos RFC en attente ? Un backlog sain se situe entre 2 et 4 semaines. Au-delà de 6 semaines, c’est un signal d’alerte — la demande dépasse la capacité ou la priorisation est insuffisante.Lead time moyen d’une RFC : temps écoulé entre la soumission et la mise en production. Suivez-le par catégorie (correctif, évolutif, réglementaire) pour voir où le pipeline se bloque.Taux de succès des changements : pourcentage de RFC déployées sans incident dans les jours suivant la mise en production. Cible : plus de 95 % pour les changements standardisés.Part de RFC « sur-mesure » : si la proportion de développements spécifiques augmente régulièrement, c’est que votre principe « Standard d’abord » ne tient pas.Sur la question du modèle de gouvernance, deux approches s’opposent — et la réalité des organisations performantes est souvent hybride : Modèle Forces Limites Gouvernance annuelle Stabilité, prévisibilité budgétaire Lent, rigide, effet tunnel Modèle agile (sprints) Réactivité, livraisons fréquentes Nécessite discipline et automatisation des tests La tendance en 2025 : des sprints courts (2-3 semaines) pour les évolutions courantes et les quick wins, avec un comité stratégique trimestriel pour les grandes décisions et les arbitrages budgétaires. Le tout encadré par des BPO qui maintiennent la cohérence d’ensemble. Et ensuite ? Vous avez structuré votre processus d’évolution — les demandes sont canalisées, arbitrées et tracées. La dernière étape de la phase SUPPORT dans la méthode PRISM est celle qui pérennise tout ce que vous avez construit :Capitalisation, documentation et gouvernance long terme : comment maintenir votre base de connaissances à jour, organiser un retour d’expérience global et intégrer votre ERP dans la gouvernance SI de l’entreprise sur le long terme. Contactez-nous pour accéder à l'article complet sur la capitalisation et la gouvernance long terme, ainsi qu'aux templates RFC et aux modèles de matrice de priorisation disponibles en téléchargement. ArticlesMettre en place le processus RFC Structurer la gouvernance des évolutions (BPO & comité) Prioriser les évolutions par la valeur Gérer les développements et le risque de non-régression Piloter la performance des évolutions (KPI)
