Migrer vers SAP S/4HANA reste l’un des chantiers les plus lourds pour un DSI de grand groupe. Deux voies classiques s’opposent : Greenfield et Brownfield. Une troisième émerge, plus pragmatique : Bluefield. Retour d’expérience sur un programme mené 3 ans chez un opérateur d’infrastructure critique.
Introduction
Le sujet SAP S/4HANA est arrivé au sommet des priorités DSI depuis 2023, poussé par la fin du support étendu SAP ECC en 2027. Les grands groupes qui vivent avec des SAP historiques (parfois 20 ans d’ancienneté, éclatés sur plusieurs instances) doivent trancher : on repart de zéro, on migre l’existant, ou on invente une voie intermédiaire.
Depuis 3 ans, nous avons piloté un programme SAP S/4HANA chez un opérateur d’infrastructure critique française. La trajectoire retenue : Bluefield. Voici pourquoi.
Greenfield : le mythe du redémarrage
L’approche Greenfield consiste à repartir d’une feuille blanche. On implémente S/4HANA from scratch, on reconstruit ses processus, on redéploie ses données. Sur le papier, c’est séduisant : on efface la dette technique, on adopte les meilleures pratiques SAP, on repense l’organisation.
En pratique :
- Le budget explose (multiplié par 2 à 3 vs migration classique)
- La durée dépasse souvent 4 ans, ce qui rend le programme instable
- La reprise de données est massivement sous-estimée, avec des risques de rejet métier
- La conduite du changement devient un projet à part entière
Greenfield fonctionne quand le SI actuel est vraiment obsolète, ou quand l’organisation change fondamentalement (fusion, spin-off, changement de business model).
Brownfield : le poids de l’existant
L’approche Brownfield migre l’instance SAP existante vers S/4HANA, avec ses processus, ses développements custom (Z), ses données. C’est la voie la plus rapide (12-18 mois typiquement) et la moins risquée fonctionnellement.
Mais elle emporte tout : la dette technique, les processus historiques, les développements obsolètes. On modernise la plateforme sans moderniser le SI.
Le piège du Brownfield : migrer en Brownfield sans plan de nettoyage préalable, c’est acheter une dette technique en promo pour 10 ans supplémentaires.
Brownfield convient aux SI SAP relativement propres, avec peu de développements custom, et dont les processus fonctionnent correctement.
Bluefield : le meilleur des deux
Bluefield est une approche modulaire. Pour chaque périmètre fonctionnel (finance, achats, ventes, production), on tranche : Greenfield ou Brownfield.
Concrètement : on garde le module Finance en Brownfield parce qu’il est propre et stable. On refait le module Achats en Greenfield parce que les processus sont obsolètes. On rationalise les flux inter-modules au passage.
« Bluefield n’est pas un compromis mou entre Greenfield et Brownfield. C’est une méthode d’arbitrage éclairé, module par module. » : Marc D. · SAP Solution Architect senior OGESSI
Quand privilégier Bluefield
Nous recommandons Bluefield quand :
- Le SI SAP a plus de 10 ans et couvre plusieurs métiers hétérogènes
- Certains modules fonctionnent bien, d’autres portent une dette lourde
- Le budget et le calendrier interdisent un Greenfield complet
- Il existe une volonté de rationaliser certains processus, sans tout refaire
- L’entreprise a du bandwidth pour arbitrer module par module
Cette dernière condition est déterminante : Bluefield exige une gouvernance fine et un cadrage préalable rigoureux.
En pratique : notre méthode
Sur le programme cité en introduction, nous avons structuré l’approche en quatre étapes.
1. Cartographier l’existant. Six mois d’inventaire : applications, flux, données, développements custom, dépendances. Nous avons utilisé Signavio Process Intelligence pour cartographier les processus AS-IS.
2. Arbitrer module par module. Pour chaque périmètre, une matrice de décision : état de la dette technique, alignement métier, coût de refonte, risque. Résultat : 40% des modules en Brownfield, 35% en Greenfield, 25% en approche mixte (données Brownfield, processus refactorisés).
3. Séquencer la trajectoire. Une roadmap sur 3 ans, phasée par vagues, avec des jalons de continuité de service. Coordination des 300+ interfaces via un plan de bascule progressive.
4. Gouverner et transférer. SAP GRC pour la gouvernance des risques, SAP MDG pour la data quality. En fin de programme, transfert de connaissances structuré aux équipes internes.
Conclusion
Bluefield n’est pas une silver bullet. C’est une méthode qui demande plus de cadrage amont que Greenfield ou Brownfield. En contrepartie, elle produit une trajectoire mieux ajustée à la réalité de votre SI, avec un budget et un calendrier plus tenables.
Si vous cadrez un programme SAP S/4HANA, la question à vous poser n’est pas « Greenfield ou Brownfield ? ». C’est « Quel arbitrage par module ? ». La réponse s’appelle Bluefield.