Introduction : la migration S/4HANA, un projet a haut risque
La fin du support mainstream d'ECC 6.0 approche a grands pas. En 2026, la plupart des grandes entreprises françaises sont soit en cours de migration vers S/4HANA, soit en phase avancee de planification. Pourtant, les échecs et les dépassements budgetaires restent alarmants : selon les dernières études du secteur, plus de 60% des projets de migration S/4HANA depassent leur budget initial, et 45% ne respectent pas les délais prévus.
Au cours de vingt années passées sur des programmes SAP en France — incluant des missions chez Safran, GRDF, RTE, ENGIE et VINCI Construction — j'ai pu observer des patterns récurrents dans l'industrie. Cet article identifie sept erreurs fréquemment rencontrées sur des projets de migration ECC vers S/4HANA, indépendamment du secteur ou de la taille du groupe. Cet article les detaille une par une, avec des exemples concrets et des recommandations actionables.
Erreur n°1 : un cadrage initial trop superficiel
Le symptome
Le projet démarré avec un périmètre vaguement défini : "on migré notre ECC vers S/4HANA". Les ateliers de cadrage se limitent a quelques reunions avec la DSI, sans implication reelle des directions métier. Le budget est estime sur la base de ratios generiques fournis par l'integrateur.
Pourquoi c'est grave
Un cadrage superficiel entraine des découvertes tardives qui font exploser le budget. Chez un industriel du BTP, nous avons ete appeles en renfort sur un projet déjà démarré depuis huit mois. Le budget initial de 4 millions d'euros avait déjà ete depasse de 60%, principalement parce que personne n'avait anticipe la complexité de la migration des processus de gestion de projet (PS/PPM) et de l'intercompany.
La bonne approche
Consacrez 8 à 12 semaines a un cadrage serieux. Cela inclut :
- Un inventaire exhaustif des processus métier couverts par ECC
- Une cartographie des interfaces entrantes et sortantes (j'en ai vu jusqu'à 350 sur un seul système)
- Une analyse des données : volumes, qualité, spécificités
- Des ateliers de découverte avec chaque direction métier, pas seulement l'IT
- Un POC (Proof of Concept) sur les zones de risque identifiees
Oui, ce cadrage coûte de l'argent. Mais il coûte 10 fois moins cher que les dépassements qu'il permet d'éviter.
Erreur n°2 : sous-estimer la migration des données
Le symptome
La migration des données est traitee comme un chantier technique secondaire, confie a une petite equipe en fin de projet. Les tests de migration sont repousses au dernier moment.
Pourquoi c'est grave
La migration des données est souvent le chemin critique du projet. Le passage de ECC à S/4HANA implique des changements structurels majeurs : la fusion des tables BSEG/BSAD/BSAK en ACDOCA, la nouvelle gestion du stock avec MATDOC, la refonte des partenaires commerciaux (Business Partners), la migration des immobilisations vers le nouveau ledger.
Chez un gestionnaire de reseau d'énergie, la migration des 15 millions de postes d'immobilisations a nécessité a elle seule six mois de travail, trois cycles de test complets, et la resolution de 2 400 anomalies de données historiques. Si nous n'avions pas commence ce chantier des le debut du projet, le go-live aurait ete reporte d'au moins six mois.
La bonne approche
- Lancez le chantier données des le premier mois du projet
- Prevoyez au minimum 3 cycles complets de migration à blanc (dry run)
- Nommez un responsable données dedie, avec autorité sur les arbitrages
- Nettoyez les données AVANT la migration, pas pendant
- Documentez chaque règle de transformation et faites-la valider par le métier
Erreur n°3 : ignorer la revolution Fiori
Le symptome
L'equipe projet considéré Fiori comme un simple "relooking" de l'interface, et repousse les sujets UX a la fin du projet. Les utilisateurs découvrent la nouvelle interface lors de la recette, soit quelques semaines avant le go-live.
Pourquoi c'est grave
Fiori n'est pas un thème graphique applique sur SAP GUI. C'est un changement de paradigme dans la manière dont les utilisateurs interagissent avec SAP. Les Launchpads, les applications analytiques, les tuiles de navigation, les espaces de travail -- tout cela nécessité une reflexion UX serieuse et une conduite du changement adaptee.
J'ai vu des projets ou le go-live technique etait un succès, mais ou la productivite des utilisateurs s'effondrait pendant six mois parce que personne n'avait pense a l'ergonomie des postes de travail Fiori. Les comptables qui faisaient leurs clotures en 3 jours mettaient soudain 5 jours, simplement parce que la navigation entre applications n'avait pas ete optimisee.
La bonne approche
- Integrez un designer UX ou un expert Fiori des le cadrage
- Construisez les espaces de travail Fiori (Spaces & Pages) en co-création avec les utilisateurs clés
- Testez l'ergonomie en continu, pas uniquement en recette
- Formez les utilisateurs sur le nouveau paradigme, pas seulement sur les transactions migrées
- Mesurez la satisfaction utilisateur avant et après le go-live
Erreur n°4 : faire l'impasse sur l'environnement sandbox
Le symptome
Pour economiser sur les coûts d'infrastructure, l'equipe projet travaille avec un nombre minimum d'environnements. La sandbox est considérée comme un luxe superflu.
Pourquoi c'est grave
La sandbox est votre filet de sécurité. C'est l'environnement ou vous pouvez expérimenter, vous tromper, recommencer, sans impacter le projet. Sans sandbox, chaque erreur de configuration se propage dans la chaine de développement et peut coûter des semaines de retravail.
Dans un projet chez un acteur majeur de l'énergie, l'absence de sandbox à conduit à une contamination de l'environnement de développement par des tests de migration de données mal maîtrisés. Il a fallu reconstruire l'environnement à partir de zero, ce qui a coûte trois semaines de retard et une mobilisation d'urgence de l'equipe Basis.
La bonne approche
Prevoyez au minimum quatre environnements :
- Sandbox : exploration libre, POC, formation de l'equipe
- Développement : construction de la solution, protege par des règles de transport strictes
- Qualité : tests d'integration et recette utilisateur
- Pre-production : repetition générale du go-live, tests de performance
Avec les solutions cloud de SAP (BTP, RISE), le coût de ces environnements a considérablement baisse. Il n'y a plus d'excuse pour faire l'economie d'une sandbox.
Erreur n°5 : negliger la conduite du changement
Le symptome
La conduite du changement se resume a quelques sessions de formation de deux heures, planifiees deux semaines avant le go-live. Le support post-go-live est sous-dimensionne.
Pourquoi c'est grave
Une migration S/4HANA n'est pas une simple mise à jour technique. Pour les utilisateurs, c'est un bouleversement de leurs habitudes quotidiennes. Les transactions qu'ils connaissaient par coeur n'existent plus ou ont change de nom. L'interface est complètement différente. Certains processus ont ete redesignes.
Chez VINCI Construction, nous avons investi 15% du budget total du projet dans la conduite du changement. Certains trouvaient cela excessif. Pourtant, le retour a la productivite nominale a ete atteint en 4 semaines post-go-live, là où la moyenne du secteur est de 3 à 4 mois.
La bonne approche
- Demarrez la communication sur le projet des le cadrage
- Identifiez des ambassadeurs dans chaque direction métier
- Formez en plusieurs vagues : découverte, prise en main, perfectionnement
- Prevoyez un support renforcé pendant les 8 premières semaines post-go-live
- Mesurez l'adoption avec des indicateurs concrets (temps de traitement, nombre de tickets support)
Erreur n°6 : ne pas avoir d'expert Basis dedie
Le symptome
L'administration système est confiee a l'equipe d'exploitation existante, qui géré déjà vingt autres systèmes. Personne dans l'equipe projet n'a une expertise profonde de l'architecture technique S/4HANA.
Pourquoi c'est grave
S/4HANA introduit des changements architecturaux majeurs par rapport a ECC : base de données HANA avec ses spécificités de dimensionnement et de monitoring, Fiori Launchpad avec ses couches Gateway et Front-End Server, embedded BW, integration CDS views, gestion des certificats pour les connexions cloud.
J'ai vu un projet ou des problèmes de performance HANA non diagnostiques ont retarde le go-live de deux mois. La cause ? Des index manquants et un dimensionnement memoire inadequat que personne dans l'equipe n'avait la compétence de diagnostiquer.
La bonne approche
- Recrutez ou missionnez un expert Basis S/4HANA dedie au projet
- Assurez-vous qu'il maîtrise specifiquement HANA (pas seulement les bases Oracle ou DB2 d'avant)
- Planifiez des tests de performance des le milieu du projet, pas a la fin
- Documentez l'architecture technique cible et faites-la valider par SAP
Erreur n°7 : un planning irealiste
Le symptome
La direction impose un go-live a une date fixe, souvent alignee sur un exercice fiscal ou une échéance contractuelle. Le planning est construit en partant de cette date et en comprimant toutes les phases pour que "ca rentre".
Pourquoi c'est grave
Un planning irealiste créé une pression permanente qui degrade la qualité a tous les niveaux : les specifications sont baclees, les tests sont raccourcis, la conduite du changement est sacrifiee. Le go-live a lieu a la date prévue, mais les mois qui suivent sont un enfer de corrections et de contournements.
Chez un energeticien, j'ai ete temoin d'un go-live force qui a genere plus de 3 000 tickets de support en un mois. L'equipe projet, déjà epuisee par des mois de pression, a du enchainer avec un marathon de corrections d'urgence. Plusieurs profils clés ont quitte l'entreprise dans les mois suivants.
La bonne approche
- Construisez le planning de bas en haut, a partir des estimations reelles de chaque chantier
- Prevoyez des marges de sécurité explicites (15 à 20% du planning total)
- Definissez des critères de go/no-go objectifs et mesurables
- Acceptez de reporter le go-live si les critères ne sont pas remplis -- c'est toujours moins coûteux qu'un go-live raté
Pour donner un ordre de grandeur, voici des durees typiques que j'observe sur le terrain :
- Migration brownfield simple (PME, peu de custom) : 9 à 12 mois
- Migration brownfield complexe (ETI, custom significatif) : 14 à 20 mois
- Transformation greenfield (grande entreprise, redesign des processus) : 18 à 30 mois
Conclusion : la migration comme opportunité
Malgre ces sept pièges, la migration vers S/4HANA reste une formidable opportunité de modernisation. Les entreprises qui reussissent leur migration ne sont pas celles qui ont le plus gros budget ou le meilleur integrateur. Ce sont celles qui prennent le temps de bien cadrer, qui respectent leurs utilisateurs, et qui acceptent que la transformation prend du temps.
Mon dernier conseil : entourez-vous de personnes qui ont déjà vecu cette migration. Pas des consultants qui ont lu la documentation, mais des praticiens qui ont transpire les go-lives, géré les crises de recette à 23h, et appris de leurs erreurs. C'est cette expérience terrain qui fait la différence entre un projet qui aboutit et un projet qui s'enlise.
La fin de vie d'ECC approche. Il est temps d'agir, mais d'agir intelligemment.