Une mise à niveau SAP S/4HANA et une migration SAP S/4HANA ne sont pas des synonymes. Une mise à niveau concerne une amélioration technique au sein du même système, tandis qu’une migration implique un passage fondamental vers une nouvelle plateforme, de nouvelles structures de données et un nouveau modèle de processus métier. Pour les organisations qui fonctionnent encore sur SAP ECC, la question n’est pas de savoir si elles migrent, mais comment. Les sections ci-dessous répondent aux questions les plus fréquemment posées sur ce parcours.
Lors d’une conversion de système SAP S/4HANA, le système SAP ECC existant est techniquement converti vers S/4HANA. La base de données sous-jacente migre d’une base de données relationnelle traditionnelle vers la base de données en mémoire SAP HANA. Parallèlement, les modèles de données obsolètes sont simplifiés, les tables redondantes sont fusionnées et les modules fonctionnels sont réécrits vers des interfaces Fiori modernes.
Concrètement, cela signifie que le système fonctionne sur une architecture différente après la conversion. Les développements spécifiques construits dans l’environnement ECC ne sont pas automatiquement compatibles avec S/4HANA. Une analyse approfondie du code personnalisé existant, également appelée custom code impact analysis, est une étape obligatoire avant la conversion. Les adaptations non traitées peuvent entraîner des erreurs ou des problèmes de performance après le go-live.
Avec une approche brownfield, une organisation convertit son système SAP existant vers S/4HANA, en conservant les données historiques et les configurations. Avec une implémentation greenfield, on repart de zéro, sur un système vierge, avec la possibilité de repenser les processus depuis la base. Cette différence détermine en grande partie la durée du projet, le profil de risque et le degré de renouvellement des processus.
Il existe également une voie intermédiaire : la selective data transition ou approche hybride, dans laquelle certains processus ou entités sont reconfigurés tandis que d’autres sont convertis. Cela offre aux organisations la flexibilité de définir des priorités sans devoir reconstruire l’intégralité du système.
La bonne approche dépend du degré de personnalisation du système actuel, de l’ambition stratégique en matière d’amélioration des processus et des ressources et du temps disponibles. Les organisations disposant d’un système ECC fortement standardisé et de peu de développements spécifiques bénéficient généralement le plus d’une conversion brownfield. Celles qui souhaitent rompre avec une logique de processus obsolète ou soutenir une stratégie d’entreprise entièrement nouvelle optent plus souvent pour le greenfield.
Une évaluation honnête commence par une analyse fit-gap approfondie : quels processus actuels sont déjà alignés sur les standards SAP, et où se situent les écarts ? Plus l’écart est important, plus l’argument en faveur d’une implémentation greenfield est solide. Des facteurs tels que la capacité interne disponible, l’urgence de la migration et la date de go-live souhaitée jouent également un rôle dans la décision.
Une conversion de système brownfield dure en moyenne six à dix-huit mois, selon la complexité du système existant et la quantité de développements spécifiques. Une implémentation greenfield SAP S/4HANA demande généralement plus de temps : douze à vingt-quatre mois est réaliste pour les organisations de taille moyenne à grande, car les processus sont repensés et reconfigurés.
La durée du projet est fortement influencée par la qualité de la préparation. Les organisations qui investissent tôt dans un périmètre de projet clair, une stratégie de migration des données propre et une capacité interne suffisante atteignent plus souvent le go-live planifié. Les retards sont le plus souvent causés par des problèmes de qualité des données sous-estimés, des tests insuffisants ou un périmètre initial trop large.
Les principaux risques d’une migration SAP S/4HANA sont les problèmes de qualité des données, une adaptation insuffisante du code personnalisé, un manque de capacité interne et une phase de test sous-estimée. Chacun de ces facteurs peut entraîner des retards, des dépassements de budget ou un go-live instable.
Un partenaire d’implémentation SAP expérimenté aide à maîtriser ces risques de manière structurelle, non seulement grâce à une expertise technique, mais aussi grâce à des méthodologies de projet éprouvées et une planification réaliste tenant compte du contexte spécifique de l’organisation.
RISE with SAP est un programme groupé de SAP qui combine infrastructure cloud, SAP S/4HANA Private ou Public Cloud, services managés et outils de transformation dans un seul package contractuel. Il abaisse le seuil pour les organisations souhaitant migrer vers le cloud sans avoir à mettre en place et gérer elles-mêmes une infrastructure cloud complète.
Pour les DSI et les DAF, RISE with SAP est attractif car il rend le coût total de possession plus prévisible via un modèle d’abonnement. Au lieu d’investissements ponctuels importants dans le matériel et les licences, une organisation paie une redevance périodique fixe. Cela simplifie la budgétisation et transfère partiellement le risque opérationnel à SAP en tant que fournisseur.
Il est toutefois important de comprendre que RISE with SAP ne propose pas une implémentation clé en main. La transformation technique et fonctionnelle, y compris la migration des données, la conception des processus et l’adoption par les utilisateurs, reste de la responsabilité de l’organisation et de son partenaire d’implémentation. RISE with SAP facilite la transition vers le cloud ; la transformation de fond nécessite toujours une expertise SAP approfondie.
TheValueChain accompagne les organisations à chaque étape d’une implémentation ou migration SAP S/4HANA, du premier choix stratégique entre greenfield et brownfield jusqu’au go-live et au support continu qui suit. En tant que partenaire SAP certifié et lauréat des SAP BeLux Partner Awards 2025, TheValueChain combine une expertise technique approfondie avec des conseils pragmatiques adaptés à la réalité de votre organisation.
Vous souhaitez savoir quelle approche convient le mieux à votre organisation et ce qu’un parcours réaliste représente pour vous ? Consultez notre offre dans la TheValueChain store ou contactez TheValueChain pour un entretien sans engagement avec l’un de nos spécialistes SAP.
Ce n’est pas toujours nécessaire. Lors d’une conversion de système brownfield, SAP impose des exigences de version minimales, mais une mise à niveau complète vers la dernière version ECC n’est généralement pas une condition préalable. Ce qui est crucial, c’est que votre système soit stable et que vous ayez effectué une custom code impact analysis approfondie avant la conversion. Un partenaire d’implémentation SAP peut vous aider à déterminer si votre version ECC actuelle est un point de départ approprié.
Tous les développements spécifiques ne sont pas automatiquement compatibles avec S/4HANA, car des bibliothèques de fonctions et des modèles de données obsolètes ont été modifiés ou supprimés. Via une custom code impact analysis, il est déterminé pour chaque adaptation si elle doit être réécrite, remplacée par une fonctionnalité SAP standard, ou entièrement abandonnée. C’est l’une des étapes les plus sous-estimées d’un parcours de migration : plus tôt vous commencez, moins vous risquez de retards lors du go-live.
Commencez par un inventaire de vos objets de données de référence critiques, tels que les clients, les fournisseurs, les matériaux et les données de base financières, et évaluez leur complétude et leur cohérence. Utilisez des outils SAP tels que le SAP Data Migration Cockpit ou des outils externes de qualité des données pour identifier rapidement les doublons, les champs manquants et les incohérences. Le nettoyage des données avant la migration est toujours moins coûteux et moins risqué que la correction des problèmes après le go-live.
Oui, dans la plupart des parcours de migration, le système ECC existant reste opérationnel pendant le projet. Le cutover réel, le moment où vous basculez vers S/4HANA, est soigneusement planifié pendant une période à impact minimal pour l’entreprise, souvent un week-end ou une période calme. Un plan de cutover détaillé avec des critères go/no-go clairs est essentiel pour que ce moment se déroule de manière maîtrisée et avec un temps d’arrêt minimal.
SAP S/4HANA Public Cloud convient mieux aux organisations prêtes à aligner étroitement leurs processus sur le standard SAP, avec un besoin limité de développements spécifiques et une préférence pour une implémentation rapide. Le Private Cloud offre plus de flexibilité aux organisations avec des processus complexes ou fortement personnalisés, mais nécessite un investissement plus élevé et une durée plus longue. Le choix dépend fortement du degré de standardisation des processus au sein de votre organisation et de l’équilibre souhaité entre flexibilité et simplicité de gestion.
Un parcours de migration réussi nécessite au minimum une équipe projet dédiée avec un chef de projet interne, des utilisateurs clés fonctionnels par domaine métier (finance, logistique, RH, etc.) et un interlocuteur technique pour le code personnalisé et les intégrations. Ne sous-estimez pas l’investissement en temps de ces personnes : en plus de leurs tâches quotidiennes, elles portent la connaissance de vos processus métier qu’aucun partenaire externe ne peut remplacer. Assurez-vous de définir clairement les disponibilités et les mandats avant le démarrage du projet pour éviter les retards.
L’erreur la plus fréquente est de baser le choix uniquement sur les coûts ou la durée, sans tenir compte de l’ambition stratégique et de l’état réel du système existant. Les organisations choisissent parfois le brownfield pour réduire les coûts, mais reprennent ainsi une logique de processus obsolète et une dette technique qui s’avèrent plus coûteuses à long terme. Une analyse fit-gap honnête et une discussion ouverte sur la maturité des processus future souhaitée constituent la meilleure base pour un choix éclairé.