10 erreurs de modernisation de l'ERP à éviter

Les erreurs de modernisation ERP qui font le plus mal sont stratégiques, pas techniques : considérer le go-live comme la ligne d'arrivée, copier les processus historiques dans le nouveau système, lancer trop tard les chantiers de données et de changement, tout construire dans l'ERP et signer des licences sans modèle sur cinq ans. Elles se voient rarement en temps réel. Elles apparaissent après le go-live, quand les gains d'efficacité promis n'arrivent pas et que les contournements reviennent.

Ce texte s'adresse aux DSI, aux DAF et aux directeurs de programme qui préparent ou sauvent une modernisation S/4HANA ou d'un autre ERP. Chaque erreur ci-dessous s'accompagne de ce qu'elle donne en pratique et de la parade, puis viennent une checklist d'alerte précoce d'une page et ce que les changements SAP de 2026 impliquent.

J'ai vu des projets bien financés, avec des équipes expérimentées et toute une bande de conseillers, passer à côté de leurs objectifs. La cause est rarement le système. Ce sont des lacunes de responsabilité, de planification de l'intégration et de communication entre des équipes dont les décisions dépendent les unes des autres.

1. Considérer le go-live comme la ligne d'arrivée

Une fois le système en production, beaucoup d'équipes pensent que le gros du travail est fait. C'est là que la vraie pression commence : l'exploitation quotidienne, l'évolution des besoins et le comportement réel des utilisateurs mettent la conception à l'épreuve.

J'ai vu des projets où le comité de pilotage se dissout juste après le go-live. Six mois plus tard, l'adoption stagne et personne ne possède le backlog.

La parade : financez une période de gouvernance de 6 à 12 mois après le go-live. Prolongez le mandat du comité de pilotage. Suivez l'adoption des processus, pas seulement la disponibilité. Fixez des jalons qualité après le go-live, avec des responsables nommés.

2. Migrer les processus historiques sans les repenser

J'ai vu des chaînes d'approbation entières reconstruites à l'identique, alors même que la moitié des personnes impliquées n'avaient rien à voir avec le processus actuel. Personne ne s'était demandé si les étapes étaient encore nécessaires. Résultat : un ERP moderne qui fait tourner d'anciens workflows, une version plus chère de ce qu'on avait déjà.

La version S/4HANA du problème : des jobs batch spécifiques déplacés tels quels depuis ECC, construits sur des structures de tables qui n'existent plus. La migration est techniquement propre. La logique métier est cassée.

La parade : redessinez les processus avant la construction. Passez chaque workflow en revue avec les équipes d'exploitation, de finance et de livraison, ensemble, et remettez en cause chaque étape.

Domaine historique	Ce qui tourne souvent mal	Ce qu'il faut faire à la place
Code spécifique issu d'ECC	Du code spécifique inutilisé déplacé vers S/4HANA	Lancez une analyse d'usage et les contrôles du code spécifique de SAP ; supprimez le code inutilisé
Anciens workflows	Des circuits d'approbation reconstruits alors que l'automatisation est désormais possible	Revoyez-les avec les responsables métier ; utilisez les applications Fiori standard ou SAP Build Process Automation
Données de base non standard	Les configurations historiques souples échouent à la validation S/4HANA	Nettoyez et harmonisez avant la migration, avec SAP MDG quand c'est pertinent
États sur des tables historiques	L'accès direct aux tables ne correspond pas au modèle de données de S/4HANA	Reconstruisez sur des CDS views
Contournements manuels cachés	Des processus parallèles réapparaissent après le go-live	Utilisez le process mining avant la migration et numérisez les écarts

3. Lancer la migration des données trop tard

Migrer de mauvaises données dans un nouvel ERP, c'est déménager sans rien jeter. Le fouillis vous suit, et il est plus difficile à évacuer une fois dans un système structuré.

J'ai vu un jour un go-live échouer parce que personne n'avait remarqué qu'un jeu de données central contenait des entrées de cinq unités opérationnelles, chacune avec sa propre logique de codification. La migration technique était correcte. Les données étaient inutilisables. Les rapports ont cessé de fonctionner, les utilisateurs ont perdu confiance, et le nettoyage sous un système en production a pris des mois.

La parade : faites des données un chantier avec une responsabilité métier. Désignez des responsables de processus, pas seulement des consultants techniques. Décidez ce que l'on reprend, archive ou reconstruit avant le début de la migration. Faites au moins deux chargements d'essai complets, avec une carte des dépendances pour l'ordre de chargement et un retour arrière défini pour chacun. Mon article sur pourquoi les migrations de données SAP échouent va plus loin.

4. Traiter la gestion du changement comme une tâche annexe

Le scénario habituel : la gestion du changement est « déjà traitée », ce qui veut dire quelques diapositives, une démo et une session de formation avant le go-live.

Les gens ne résistent pas parce qu'ils n'aiment pas le changement. Ils résistent quand personne n'explique pourquoi les choses changent ni en quoi cela les aide. Ils suivent le système juste assez pour valider la checklist, puis retournent à leurs feuilles de calcul.

Le déclencheur habituel est la pression du calendrier : la formation est comprimée pour rattraper du temps, les utilisateurs sont submergés au go-live, et l'hypercare supplémentaire coûte plus cher que la formation sacrifiée.

La parade : donnez à la gestion du changement son propre budget, son propre calendrier et un responsable senior dès le départ. Cartographiez les rôles tôt, repérez des relais locaux et suivez des KPI d'adoption à côté des jalons techniques. Mon guide du plan de gestion du changement en présente la structure.

5. Planifier en fonction des feuilles de route des éditeurs

J'ai vu des équipes bâtir leur stratégie d'intégration sur une future version d'un éditeur, pour la voir repoussée de 12 mois. Entre-temps, elles se sont retrouvées à construire des contournements provisoires, et ces contournements sont devenus permanents.

Les éditeurs construisent leurs feuilles de route pour de larges groupes de clients. Votre entreprise est rarement au centre de cette conception.

La parade : traitez la feuille de route comme une donnée d'entrée parmi d'autres. Concevez à partir de ce qui est disponible aujourd'hui, testez les nouvelles fonctions dans un sandbox avant de planifier avec elles, et comptez les bénéfices de la feuille de route comme un plus, pas comme du budget.

6. Aucun plan de mise hors service des systèmes historiques

J'ai vu un jour une entreprise payer un montant à six chiffres par an pour maintenir en vie un ancien système au profit de six utilisateurs qui devaient sortir des rapports deux fois par an. Personne n'avait construit de plan de mise hors service.

La parade : inscrivez la mise hors service dans la charte du projet dès le premier jour, avec le juridique, la conformité et la gouvernance des données impliqués, pas seulement l'IT. Convenez des durées de conservation et d'une approche d'archivage avant le go-live, cartographiez et coupez chaque interface vers l'ancien système, et confiez à une équipe la mission de l'éteindre.

7. Sous-estimer la complexité de l'intégration

Quand l'intégration échoue, le métier s'en aperçoit avant l'IT, parce que les workflows s'arrêtent en plein milieu en production, pas dans un système de test.

Le schéma courant : l'IT et le métier supposent chacun que l'autre a défini les exigences d'intégration. Aucun ne l'a fait. Quand les lacunes apparaissent en phase de test, il n'y a plus le temps de refaire la conception.

La parade : démarrez la conception de l'intégration dès le blueprint. Définissez chaque scénario, le middleware, le mapping et les volumes de messages, et précisez avec le métier le temps réel ou le batch pour chaque interface. Nommez un responsable d'interface avec un SLA avant le go-live. Pour les nouveaux programmes SAP, le middleware est SAP Integration Suite ; SAP PI/PO sort de la maintenance standard fin 2027.

8. Croire que l'ERP peut tout gérer

J'ai travaillé sur des projets où les équipes ont forcé des workflows de service complexes (tickets IT, demandes d'actifs, routage des escalades) dans l'ERP parce qu'elles ne voulaient pas impliquer des systèmes externes comme ServiceNow. Résultat : des champs spécifiques partout, des contournements manuels et des utilisateurs coincés dans un processus qui n'a jamais convenu.

L'ERP excelle sur les processus structurés, transactionnels et ancrés dans la finance. Des plateformes dédiées font mieux les demandes de service IT, l'orchestration de workflows et la gestion des connaissances.

La parade : décidez délibérément ce qu'il ne faut pas construire dans l'ERP. Utilisez des extensions side-by-side sur SAP BTP pour les exceptions, et ServiceNow ou équivalent pour l'orchestration en dehors du cœur transactionnel. Mon article sur la modernisation de l'ERP avec SAP et ServiceNow traite de ce partage.

9. Sous-estimer le coût de licence à long terme

Je connais une équipe qui a doublé ses dépenses de licences dès la deuxième année parce qu'elle avait besoin d'une seule fonction réservée à une licence de niveau supérieur. Le business case n'avait modélisé que le coût du go-live.

Les licences ERP facturent les utilisateurs, les modules, les transactions et l'usage des API, et le coût grandit avec l'entreprise, que vous l'ayez prévu ou non. Chez SAP, le modèle Digital Access signifie que les documents créés par des systèmes tiers peuvent entraîner un coût de licence absent du modèle commercial initial. Sous RISE et SAP GROW, le nombre de Full User Equivalent (FUE) augmente avec l'adoption.

La parade : construisez un modèle de licences sur trois à cinq ans avant de signer. Associez les rôles aux types de licences, modélisez la croissance des FUE sur une courbe d'adoption réaliste, comprenez l'accès indirect avant de connecter des systèmes externes, et auditez les utilisateurs inactifs après le go-live.

10. Traiter l'ERP comme un projet IT

Le schéma le plus courant et le plus dommageable. La planification démarre à l'IT, est pilotée par l'IT et résout des problèmes d'IT.

J'ai vu des équipes atteindre chaque jalon sur le papier alors que le métier se demande toujours pourquoi rien ne va mieux. Cela signifie en général que l'ERP a été construit pour les processus d'hier, sans les responsables des opérations, de la finance ou du commercial dans la conception.

La parade : placez des responsables commerciaux, financiers et opérationnels au comité de pilotage dès le départ. Inscrivez l'alignement stratégique dans la charte, pas seulement le périmètre technique. Confrontez les objectifs du programme aux résultats attendus par le conseil d'administration avant le début de la conception.

À utiliser à chaque comité de pilotage. Si un signal d'alerte est présent, le responsable désigné en rend compte jusqu'à ce qu'il disparaisse.

1. CharteResponsabilités et coûtsAucun responsable des opérations ou de la finance, aucun modèle de licences sur cinq ans, aucune date de retrait
2. BlueprintConception des processus et de l'intégrationProcessus actuel copié, interfaces encore non conçues
3. Premier chargement d'essaiDonnéesAucun rapport de qualité des données pour l'instant
4. Go-liveCe qui se passe ensuiteAucune gouvernance financée pour les 12 mois suivants

Erreur	Signal d'alerte précoce	Responsable
1. Go-live comme ligne d'arrivée	Aucun plan de gouvernance financé pour les 12 mois suivant le go-live	Sponsor
2. Processus historiques copiés	Les ateliers de conception partent d'écrans « comment nous faisons aujourd'hui »	Responsables de processus
3. Données traitées trop tard	Aucun rapport de qualité des données avant le premier chargement d'essai	Responsable de la migration des données
4. Changement traité en tâche annexe	Le plan de changement se résume à un calendrier de formation	Responsable du changement
5. Dépendance à la feuille de route	Une décision de conception attend une fonction qui n'est pas encore sortie	Architecte de solution
6. Aucune mise hors service	Aucune date de retrait pour un système historique dans la charte	PMO
7. Intégration sous-estimée	Interfaces non conçues à la fin du blueprint	Responsable de l'intégration
8. L'ERP pour tout	Objets spécifiques pour des workflows non transactionnels	Architecte d'entreprise
9. Licences	Aucun modèle de licences sur cinq ans dans le business case	DAF
10. Programme purement IT	Le comité de pilotage n'a ni responsable des opérations ni responsable de la finance	Sponsor

Déploiement. Pour les nouveaux programmes SAP, la voie par défaut est RISE with SAP sur SAP Cloud ERP Private, ou SAP GROW sur l'édition publique (SAP Cloud ERP) pour les entreprises de taille intermédiaire. Les nouveaux déploiements sur site sont rares. Les clients ECC font face à la fin de la maintenance standard le 31 décembre 2027, ce qui réduit le temps disponible pour corriger les erreurs 2, 3 et 7.

Clean core. SAP classe désormais les extensions selon quatre niveaux de clean core, de A (API publiées uniquement, side-by-side sur BTP ou dans le système avec ABAP Cloud) à D (non clean). L'édition publique n'autorise que le niveau A, ce qui impose la discussion derrière l'erreur 2. L'édition privée autorise encore les extensions classiques, la discipline doit donc venir de la gouvernance. Le code spécifique classique est ce qui fait de chaque mise à niveau un projet. Mon article sur la stratégie clean core va plus loin.

L'IA dans les outils de mise en œuvre. Joule est désormais présent dans SAP Cloud ALM et dans le SAP Activate Roadmap Viewer, et SAP Build Code utilise Joule pour le développement d'extensions. Demandez aux partenaires comment l'outillage IA se reflète dans leur grille tarifaire. S'il ne s'y reflète pas, soit le prix est élevé, soit l'économie va dans leur marge.

Outils du cycle de vie. SAP Cloud ALM est l'outil de gestion du cycle de vie des programmes cloud. Solution Manager 7.2 sort de la maintenance standard fin 2027 : les environnements qui font tourner les deux ont donc besoin d'un plan pour la transition.

Les dix erreurs n'ont pas changé. Le coût de les commettre, si. Sur un programme RISE, la décision de clean core, le modèle de déploiement et le modèle FUE sont tous fixés pendant les premières semaines de mobilisation. La fenêtre pour les influencer est courte.

Pourquoi les efforts de modernisation ERP déçoivent-ils après le go-live ?

La plupart des équipes planifient jusqu'au go-live, puis s'arrêtent. Personne ne possède les évolutions, les retours, les corrections de processus ni le backlog. La dissolution du comité de pilotage au go-live est le signe de problème le plus fiable. Financez 6 à 12 mois de gouvernance après le go-live dès le premier jour.

Quel est le risque de copier les processus historiques dans un nouvel ERP ?

Le nouveau système hérite des anciennes inefficacités, à un coût plus élevé. Dans les migrations S/4HANA en particulier, le code spécifique et les jobs batch construits pour les tables ECC ne fonctionnent souvent pas : la migration peut donc être techniquement propre alors que la logique métier est cassée.

Comment une mauvaise qualité des données nuit-elle à une modernisation ERP ?

Les fournisseurs en double, les données de base incohérentes, les codes historiques et les enregistrements incomplets passent tous dans le nouveau système si personne ne les nettoie d'abord. Les rapports cessent de fonctionner, les utilisateurs ne font plus confiance aux chiffres, et le nettoyage sous un système en production prend des mois.

Pourquoi la gestion du changement est-elle si souvent sous-estimée dans les projets ERP ?

Parce qu'elle n'apparaît pas dans un planning de projet comme la configuration. Les dirigeants supposent que quelques sessions de formation suffisent. La gestion du changement consiste à préparer les gens à ce qui va réellement changer dans leur travail quotidien, avant le go-live. Les outils d'adoption numérique comme WalkMe, désormais propriété de SAP, aident pour le guidage dans l'application, mais ils ne remplacent pas l'explication du pourquoi.

Pourquoi les systèmes historiques continuent-ils de tourner des années après le go-live de l'ERP ?

Parce que personne n'a prévu de les éteindre. Tout le monde est concentré sur la mise en production du nouvel ERP, et les anciens systèmes restent en place pour la conformité, la consultation ou le confort. La mise hors service doit être dans le périmètre dès le premier jour, avec le juridique et la conformité impliqués.

Comment RISE with SAP et le clean core changent-ils ces erreurs ?

Sur l'édition publique, les règles du clean core rendent impossible la personnalisation poussée, ce qui impose la discussion sur les processus derrière l'erreur 2. Sur l'édition privée, les extensions classiques restent autorisées : le clean core dépend donc de la gouvernance. L'intégration passe à SAP Integration Suite à mesure que la maintenance de PI/PO prend fin. Les licences deviennent une question de croissance des FUE. La mise hors service devient plus urgente, car faire tourner des systèmes historiques en parallèle ajoute du coût à un abonnement pluriannuel.