Migration de SAP ECC vers SAP S/4HANA en France : guide étape par étape pour les entreprises

Un guide pratique pour choisir la stratégie de migration SAP S/4HANA, préparer les données, gérer le cutover et intégrer les exigences françaises.

SAP ECC accompagne depuis plusieurs décennies les entreprises dans leurs processus clés : finance, logistique, achats, production, ressources humaines et bien d’autres domaines. Pour les organisations qui utilisent encore SAP ERP 6.0, le calendrier de maintenance devient toutefois un enjeu de plus en plus important. SAP assure la maintenance de base des principales applications SAP Business Suite 7 concernées jusqu’à fin 2027. À partir de 2028, les clients éligibles pourront opter pour une maintenance étendue jusqu’à fin 2030. Les clients qui ne choisissent pas cette option, ou qui continuent d’utiliser ces applications au-delà de cette échéance, passeront à une maintenance spécifique au client, soumise à des conditions différentes.

Pour certains grands clients disposant d’environnements particulièrement complexes, SAP a également annoncé SAP ERP, private edition, transition option, un abonnement cloud transitoire limité dans le temps, prévu pour la période 2031-2033 et soumis à des critères d’éligibilité et à des prérequis techniques. Cette offre ne constitue pas une prolongation de la maintenance de SAP Business Suite 7. La maintenance spécifique au client ne doit pas non plus être considérée comme équivalente à la maintenance de base ni comme la poursuite du même cycle d’innovation.

Pour les entreprises présentes en France, la migration vers SAP S/4HANA va bien au-delà d’une simple conversion ERP. Le projet peut également avoir des incidences sur la localisation en France, la TVA, la comptabilité statutaire, la facturation électronique, le traitement des données personnelles, les dispositifs de cybersécurité, les intégrations, les processus métiers, les rôles des collaborateurs et le futur modèle de déploiement.

Le calendrier ajoute une contrainte supplémentaire. La réforme française de la facturation électronique est entrée dans sa première phase obligatoire le 1er septembre 2026. Toutes les entreprises concernées doivent désormais être en mesure de recevoir des factures électroniques. Les grandes entreprises et les ETI doivent également les émettre et respecter les obligations d’e-reporting applicables. Les PME et microentreprises entreront à leur tour dans la phase d’émission obligatoire le 1er septembre 2027.

Repousser une migration SAP ECC peut également accroître la concurrence autour des compétences SAP expérimentées et accentuer la pression sur les équipes internes. Les mêmes spécialistes peuvent devoir gérer simultanément la facturation électronique, l’évolution des intégrations, les nouvelles exigences de gouvernance en cybersécurité et la localisation en France. Il reste alors moins de temps pour tester et corriger les spécificités locales avant que d’autres échéances opérationnelles ou réglementaires ne mobilisent les mêmes ressources.

Ce guide présente les principales approches de migration ainsi que les enjeux techniques, opérationnels et spécifiques au marché français à prendre en compte avant, pendant et après le passage à SAP S/4HANA.

En bref : une migration de SAP ECC vers SAP S/4HANA en France doit associer transformation ERP, localisation en France, finance et fiscalité, facturation électronique, protection des données, cybersécurité, intégration et changements organisationnels. Le choix de la trajectoire dépend de l’environnement existant, du modèle de déploiement cible, des données, du code spécifique et du niveau de transformation des processus recherché par l’entreprise.

Pourquoi migrer vers SAP S/4HANA ?

SAP ECC peut encore prendre en charge des processus métiers matures et fortement intégrés. La difficulté vient souvent de ce qui s’est accumulé autour du système au fil des années : développements spécifiques, interfaces, contournements, données historiques et adaptations locales. SAP S/4HANA donne aux entreprises l’occasion de réexaminer cet environnement plutôt que de le reproduire à l’identique sur une plateforme plus récente.

Pour les entreprises implantées en France, cette analyse peut notamment porter sur la comptabilité multi-entités, le reporting comptable officiel, la détermination et le rapprochement de la TVA, le plan comptable français et son articulation avec les structures comptables du groupe, la facturation électronique et l’e-reporting, Factur-X et les autres formats structurés, la connexion à une plateforme agréée, les interfaces bancaires, les exigences de protection des données ainsi que les rôles et contrôles locaux.

La migration devient ainsi l’occasion de déterminer ce qui doit être conservé, modifié ou supprimé de l’environnement cible. Ce choix est déterminant : la dette technique transférée vers SAP S/4HANA ne disparaît pas simplement parce que la plateforme ERP sous-jacente a changé.

Adoption de SAP S/4HANA et contexte ERP en France

SAP S/4HANA est désormais la plateforme ERP stratégique autour de laquelle SAP poursuit le développement de ses offres cloud, data, analytics et IA. Selon la SAP Corporate Fact Sheet de juillet 2026, 86 des 100 plus grandes entreprises mondiales sont clientes de SAP S/4HANA.

SAP ne publie pas de ventilation détaillée de la base installée de SAP S/4HANA en France. Il serait donc difficile d’étayer de manière fiable un taux d’adoption spécifique au marché français. Les données plus générales d’Eurostat apportent néanmoins un éclairage utile : en 2025, environ 54 % des entreprises françaises appartenant à la population étudiée utilisaient un ERP. La France a également enregistré une hausse de 13,7 points de pourcentage de l’utilisation de services de cloud computing payants entre 2023 et 2025.

Ces chiffres décrivent l’adoption plus large des technologies d’entreprise et non celle de SAP S/4HANA en particulier. Pour les organisations françaises qui utilisent encore SAP ECC, elles apportent un contexte de marché sans laisser entendre un niveau d’adoption de SAP S/4HANA que les données publiques ne permettent pas de confirmer.

Bref historique des ERP SAP

Les plateformes ERP de SAP ont évolué parallèlement aux infrastructures, aux modèles de gestion des données, aux expériences utilisateur et aux modes de fonctionnement des entreprises. Pour les organisations françaises qui préparent aujourd’hui une migration, le calendrier produit recoupe désormais un calendrier réglementaire distinct.

• 1979 : SAP R/2 : SAP lance sa plateforme ERP destinée aux environnements mainframe.
• 1992 : SAP R/3 : l’architecture client-serveur et l’interface graphique étendent l’usage de l’ERP à davantage de fonctions métiers.
• 2004 : SAP ECC 5.0 : ECC devient une plateforme centrale pour les processus intégrés de l’entreprise.
• 2005 : SAP ECC 6.0 : cette version devient le socle de nombreux environnements SAP exploités sur le long terme.
• 2015 : SAP S/4HANA : SAP lance sa nouvelle génération d’ERP, fondée sur SAP HANA et un modèle de données simplifié.
• 1er septembre 2026 : première phase de la réforme française de la facturation électronique B2B : toutes les entreprises concernées doivent pouvoir recevoir des factures électroniques ; les grandes entreprises et les ETI sont également soumises aux obligations d’émission et d’e-reporting applicables.
• 1er septembre 2027 : deuxième phase de la réforme : les PME et microentreprises deviennent à leur tour soumises aux obligations d’émission et d’e-reporting applicables.
• 31 décembre 2027 : échéance de maintenance SAP : fin de la maintenance de base pour les principales applications SAP Business Suite 7 concernées.
• 31 décembre 2030 : fin de la maintenance étendue optionnelle : fin de la période de maintenance étendue proposée par SAP pour les principales applications Business Suite 7 concernées.

Ces échéances concentrent plusieurs décisions de transformation sur une même période. La modernisation de l’ERP, la localisation en France et la facturation électronique doivent donc être coordonnées, plutôt que gérées comme des programmes distincts mobilisant les mêmes ressources et les mêmes fenêtres de test.

Principaux bénéfices de SAP S/4HANA

SAP S/4HANA modifie le socle technique de l’environnement ERP et peut faciliter une transformation plus large des processus. La valeur obtenue dépend néanmoins de la manière dont la solution est mise en œuvre et du niveau de complexité existant transféré vers le nouvel environnement.

Performances

SAP S/4HANA s’appuie sur la base de données in-memory SAP HANA afin d’exécuter les traitements transactionnels et l’analytique opérationnelle sur une même plateforme. Cette architecture peut réduire les temps de traitement et accélérer l’accès aux informations opérationnelles.

Les performances réelles restent toutefois tributaires du dimensionnement du système, des volumes de données, du code spécifique, des interfaces, des traitements batch ainsi que de l’infrastructure ou du service cloud retenu. Les objectifs de performance doivent donc être validés à partir de charges de travail représentatives des usages métiers, plutôt que déduits de l’architecture seule.

Modèle de données optimisé

SAP S/4HANA simplifie plusieurs structures de données utilisées dans SAP ECC. En finance, par exemple, le Journal universel et ACDOCA regroupent plusieurs dimensions comptables dans une structure commune et modifient le fonctionnement de certains processus de reporting et de rapprochement.

Pour les entités françaises, les impacts peuvent notamment concerner le reporting financier et les rapprochements, la migration des données historiques, la correspondance entre le plan comptable français et les structures du groupe, l’adaptation des interfaces dépendant des structures de données ECC et la refonte des rapports spécifiques. Le reporting comptable officiel et le reporting fiscal doivent également être réévalués au regard du modèle cible.

Ces dépendances doivent être identifiées avant la conversion. Les découvrir pendant la phase de stabilisation après le go-live peut entraîner des travaux correctifs supplémentaires.

Analytique intégrée et intelligence artificielle

SAP S/4HANA propose des fonctions d’analytique intégrée ainsi qu’un nombre croissant de scénarios d’automatisation et d’IA. Les cas d’usage disponibles dépendent de l’édition, de la version, du périmètre sous licence et des services inclus dans l’architecture cible.

Certaines capacités fonctionnent directement dans SAP S/4HANA, tandis que d’autres peuvent s’appuyer sur les services SAP BTP ou sur des composants d’IA complémentaires. Joule peut également intervenir dans certains scénarios conversationnels, de développement ou d’IA, sans être un prérequis pour chaque cas d’usage SAP S/4HANA. Les modèles de licence et de consommation pouvant varier selon les fonctionnalités, les abonnements, les droits d’usage liés à l’IA et les services connectés nécessaires doivent être confirmés lors de la conception de la solution.

L’accès aux données métiers doit également être analysé au niveau de chaque cas d’usage. Les entreprises françaises et européennes doivent notamment tenir compte de la gouvernance des accès, du traitement des données personnelles, du contrôle humain, des exigences du RGPD et, le cas échéant, des obligations résultant du règlement européen sur l’IA, ou AI Act.

Pour les cas d’usage impliquant des décisions automatisées produisant des effets juridiques ou des effets similaires significatifs sur des personnes, l’applicabilité de l’article 22 du RGPD et les garanties nécessaires doivent être examinées avant le déploiement. Cette question est particulièrement importante lorsqu’un processus utilisant l’IA peut affecter des salariés, des clients ou d’autres personnes sans intervention humaine significative.

Flexibilité des modèles de déploiement

SAP S/4HANA prend en charge plusieurs modèles de déploiement. SAP Cloud ERP privilégie davantage la standardisation des processus et une exploitation cloud gérée par SAP. SAP Cloud ERP Private offre davantage de flexibilité pour les environnements complexes et les scénarios de transformation. Les déploiements on-premises donnent aux clients un contrôle plus important sur l’infrastructure et le calendrier des versions, tandis que les architectures hybrides ou à deux niveaux peuvent combiner plusieurs modèles selon les entités ou les unités opérationnelles.

Pour les organisations françaises, ce choix doit prendre en compte les exigences réglementaires, les attentes en matière de résidence des données, la cybersécurité, la localisation en France, la facturation électronique, les besoins de personnalisation, la maîtrise des montées de version, les intégrations, les compétences SAP disponibles et le coût total de possession. L’importance relative de ces critères varie selon le secteur, le modèle opérationnel et l’architecture existante.

Un déploiement on-premises offre davantage de contrôle opérationnel, mais ne supprime ni les dépendances à SAP, ni les responsabilités de sécurité, ni les obligations réglementaires. De la même manière, le cloud modifie la répartition des responsabilités opérationnelles sans dispenser le client d’évaluer la conformité, la gouvernance des données et les besoins d’intégration.

Expérience utilisateur moderne

SAP Fiori constitue l’expérience utilisateur principale basée sur les rôles dans SAP S/4HANA, même si le maintien de SAP GUI dépend du périmètre fonctionnel et du scénario de migration. Pour les utilisateurs habitués à SAP ECC, la transition peut modifier la manière d’accéder aux transactions, aux validations et aux tâches quotidiennes.

Les projets en France doivent prévoir une analyse des impacts du changement ainsi qu’un dispositif de formation par rôle, en français lorsque cela est nécessaire. Ils doivent également tenir compte des exigences d’accessibilité, de l’adaptation de la terminologie métier locale, de la refonte des autorisations et de la correspondance entre les anciennes transactions et les applications cibles. Les utilisateurs clés locaux doivent participer à la conception et aux tests afin d’identifier les problèmes d’usage et de processus avant la mise en production, plutôt que pendant la phase d’hypercare.

Comprendre les différences entre SAP ECC et SAP S/4HANA

Le tableau ci-dessous résume certaines différences concrètes entre les deux environnements. Il évite de présenter SAP ECC comme intrinsèquement inefficace : de nombreux environnements ECC continuent de prendre en charge des processus matures, même lorsque des années de développements spécifiques ont complexifié leur environnement technique.

Stratégies de migration de SAP ECC vers SAP S/4HANA

La stratégie de migration détermine dans quelle mesure la configuration existante, les données, le code spécifique et la conception des processus seront transférés vers l’environnement cible. Pour les entreprises françaises, elle doit également préciser le traitement de la comptabilité locale, de la TVA, de la facturation électronique, du reporting comptable officiel, des intégrations et des données historiques.

Migration Greenfield

Une migration Greenfield consiste à créer un nouvel environnement SAP S/4HANA plutôt qu’à convertir le système SAP ECC existant. Elle laisse davantage de liberté pour repenser les processus, utiliser les fonctions standard, supprimer les développements obsolètes et appliquer les principes Clean Core dès le départ.

Pour les entités françaises, la conception cible doit revalider la localisation en France et le reporting comptable officiel, tout en réexaminant la détermination de la TVA lorsque le nouveau modèle de processus l’exige. Le périmètre de migration doit également couvrir les postes ouverts, les valeurs d’immobilisations, la correspondance des plans comptables, la facturation électronique et l’e-reporting, ainsi que les interfaces reliant SAP aux banques, aux systèmes de paie et de fiscalité, aux plateformes agréées et aux autres applications externes.

Le projet doit aussi définir une stratégie claire pour les données comptables qui ne seront pas transférées vers SAP S/4HANA. Les utilisateurs, les équipes Finance et les auditeurs doivent pouvoir consulter les données historiques requises au moyen d’une solution d’archivage ou d’accès au système historique pendant toute la durée de conservation applicable.

Migration Brownfield

La migration Brownfield consiste à convertir l’environnement SAP ECC existant tout en conservant une part importante de sa configuration, de sa structure organisationnelle, de ses données historiques et de ses processus. Cette approche peut limiter la refonte immédiate des processus métiers, mais elle ne transforme pas pour autant le projet en simple mise à niveau technique.

La préparation comprend généralement SAP Readiness Check, Simplification Item Check, l’analyse du code spécifique, les prérequis liés à Unicode et à SAP HANA lorsque cela s’applique, la préparation de Business Partner et de CVI, la gestion des volumes de données, la vérification de la compatibilité des add-ons, la remédiation des interfaces et la revue des autorisations.

Les développements spécifiques existants ne sont pas automatiquement conservés à l’identique. Certains doivent être adaptés à SAP S/4HANA ; d’autres peuvent être remplacés par des fonctions standard, repensés conformément au modèle d’extensibilité cible ou supprimés s’ils ne répondent plus à un besoin métier.

La localisation en France et la facturation électronique doivent également être évaluées indépendamment de la conversion technique. Le fait qu’un système SAP ECC prenne déjà en charge la comptabilité française ne signifie pas automatiquement que sa configuration, son code spécifique, ses données de base et ses intégrations répondent aux besoins de l’architecture SAP S/4HANA cible ou aux règles françaises actuelles de facturation électronique.

Selective Data Transition

La Selective Data Transition, ou SDT, consiste à transférer uniquement certaines données et structures organisationnelles au lieu de reprendre tout l’historique SAP ECC. Cette approche peut convenir aux consolidations de systèmes, aux opérations de fusion-acquisition, aux carve-outs, aux environnements complexes ou aux transformations dans lesquelles l’entreprise souhaite maîtriser précisément les données transférées.

Les données exclues de SAP S/4HANA peuvent néanmoins devoir rester accessibles au moyen d’une solution d’archivage ou d’accès à l’ancien système. Les règles de sélection doivent donc tenir compte des exigences comptables, fiscales, d’audit et de conservation, plutôt que de la seule facilité de migration.

Déploiement par vagues

Un déploiement par vagues constitue un modèle de mise en œuvre plutôt qu’une stratégie de migration distincte. Une approche Greenfield, Brownfield ou Selective Data Transition peut être déployée progressivement en fonction de l’environnement et du périmètre de transformation.

L’entreprise peut organiser les vagues par pays, entité juridique, code de société, unité opérationnelle, processus ou autre périmètre défini. Cette approche limite le volume de changement introduit simultanément, mais crée aussi une période de coexistence entre les environnements historiques et cibles. La gouvernance des données de base, les rapprochements, les intégrations transitoires, le reporting et la responsabilité des processus réglementaires doivent rester cohérents pendant toute la durée du déploiement.

L’approche LeverX Data Management Platform

Les environnements SAP exploités depuis de nombreuses années contiennent souvent des doublons, des données de base obsolètes, des structures incohérentes ou des informations historiques qui n’ont plus besoin d’être reprises dans le nouvel ERP. LeverX Data Management Platform prend en charge le profilage des données, le nettoyage, la validation, la transformation, l’harmonisation et la migration sélective des données. Les équipes peuvent ainsi décider quelles données doivent être transférées, archivées ou exclues.

La plateforme peut également faciliter la validation des règles de transformation, les rapprochements et l’automatisation de certaines activités de migration. Dans sa candidature aux SAP Innovation Awards 2024, LeverX a indiqué, pour l’approche présentée, une réduction de 40 % de la durée du projet, une amélioration de 50 % de la qualité des données et une réduction de 20 % du temps d’indisponibilité des données.

En 2025, LeverX a présenté Agentic AI: Revolutionizing SAP S/4HANA Data Migration with LeverX's Data Management Platform & SAP Cloud, une initiative centrée sur l’automatisation du mappage, de la validation, des rapprochements et des workflows de migration. Ces exemples correspondent à des projets d’innovation spécifiques et ne constituent pas des références universelles applicables à toutes les migrations.

Comment choisir la bonne stratégie de migration ?

Aucune trajectoire ne convient à tous les environnements SAP ECC. La comparaison la plus utile consiste à examiner la manière dont chaque approche traite la configuration existante, les données historiques, la refonte des processus, le code spécifique et les exigences locales.

Toutes ces approches peuvent être mises en œuvre par vagues, par exemple par pays, entité juridique, code de société, unité opérationnelle, processus ou lot de déploiement.

Le choix doit tenir compte de la maturité des processus, de la qualité des données, de la complexité du code spécifique, des dépendances d’intégration, des besoins d’accès à l’historique, de la structure organisationnelle, du modèle de déploiement cible et des obligations réglementaires en France.

La question centrale consiste à déterminer ce que le futur environnement SAP doit conserver, simplifier, repenser ou supprimer. La stratégie de migration doit découler de cet état cible et non être imposée en amont.

Préparer une migration vers SAP S/4HANA

La préparation doit réunir au sein d’un même programme les volets techniques, métiers, finance et fiscalité, localisation en France, facturation électronique, juridique, protection des données, cybersécurité, consultation des représentants du personnel lorsqu’elle s’applique et conduite du changement.

Pour les organisations françaises, une feuille de route centrée principalement sur la conversion du système risque de laisser de côté des dépendances réglementaires ou opérationnelles importantes jusqu’à un stade avancé du projet.

Une approche coordonnée facilite également la gestion des dépendances communes aux différents chantiers. Les décisions concernant les données, les intégrations, les autorisations, les tests et le cutover ont souvent des effets sur plusieurs domaines. Traiter séparément la conformité, la sécurité et le changement métier peut donc générer des doublons ou des reprises tardives.

Prérequis à la migration de SAP ECC vers SAP S/4HANA

Avant le début de l’exécution, les équipes doivent examiner la version de SAP ECC et l’Enhancement Package utilisé, les prérequis liés à Unicode et à SAP HANA lorsque cela s’applique, la compatibilité des add-ons, le code spécifique, les Simplification Items, la préparation de Business Partner et de CVI, les volumes de données, les interfaces, les autorisations et le modèle de déploiement cible.

La localisation en France et l’architecture de facturation électronique doivent être évaluées au même moment, car toutes deux peuvent influencer la conception, les intégrations, les données de base et les tests.

Cette analyse précoce vise à identifier les véritables facteurs bloquants et à les distinguer des sujets pouvant être traités lors de phases d’optimisation ultérieures. Elle évite que chaque constat technique ne devienne un élément du chemin critique du projet et permet d’obtenir une estimation plus réaliste de l’effort avant la planification détaillée.

Outils SAP de préparation et d’évaluation

Selon l’environnement et le scénario de migration, les outils et méthodes SAP pertinents peuvent inclure SAP Readiness Check, Simplification Item Check, ABAP Test Cockpit, SAP Signavio, SAP LeanIX, SAP Cloud ALM et SAP Activate. La combinaison retenue doit correspondre au système de départ, à l’architecture cible, au niveau de transformation des processus et à la stratégie de gestion du cycle de vie des applications.

SAP Solution Manager peut encore faire partie de l’environnement existant de certains clients, mais il ne doit pas automatiquement devenir la plateforme ALM de référence pour un nouveau programme de transformation. SAP positionne SAP Cloud ALM comme sa plateforme stratégique de gestion du cycle de vie des applications. Le futur outillage doit donc être choisi en fonction du modèle opérationnel cible plutôt que de reconduire sans réévaluation.

1. Planifier la migration

La planification commence par la définition de l’état cible : objectifs métiers, entités et codes société concernés, modèle de déploiement, processus à conserver ou à repenser, stratégie de reprise de l’historique, principales intégrations et modèle de déploiement par vagues. L’approche de migration doit découler de ces décisions et non être choisie en premier au risque de contraindre ensuite l’architecture à s’y conformer.

En France, le programme doit définir des responsabilités claires pour la finance et la fiscalité, la localisation en France, la facturation électronique, la protection des données, la cybersécurité, la conduite du changement, la revue juridique et contractuelle et la continuité d’activité. Ces volets doivent relever d’une même gouvernance de projet, car leurs exigences convergent souvent autour des données, des contrôles, des intégrations et du cutover.

Selon le périmètre, l’équipe projet peut associer la DSI, la direction Finance, les spécialistes fiscaux, les équipes SAP, le DPO, le RSSI, les équipes juridiques et achats, le contrôle interne, les représentants des principales fonctions métiers et les utilisateurs clés locaux. Lorsque la transformation affecte de manière significative l’organisation du travail, les responsabilités, les technologies utilisées ou les conditions de travail, les parties prenantes liées au CSE doivent également être associées lorsque cela s’applique.

Les éventuelles obligations relatives au CSE doivent être évaluées suffisamment tôt pour être intégrées au planning. Une analyse menée uniquement en fin de projet peut créer des dépendances évitables en matière de communication, de conduite du changement et de calendrier de déploiement.

Le budget doit couvrir davantage que les seuls services d’implémentation. Selon le modèle cible, il peut inclure les licences ou abonnements SAP, l’infrastructure ou les services cloud, les outils de migration, le nettoyage des données, SAP BTP, la facturation électronique, les tests, la sécurité, les audits, les formations en français, l’hypercare et une réserve pour aléas.

Il convient également d’intégrer la charge des équipes internes. Les spécialistes Finance, fiscalité, sécurité, les responsables de processus et les utilisateurs clés locaux peuvent devenir des ressources critiques lorsqu’ils doivent participer au projet tout en assurant les opérations courantes.

2. Analyser l’environnement SAP ECC existant

L’évaluation doit documenter l’usage réel d’ECC et non uniquement la manière dont le système avait été conçu à l’origine. Elle doit couvrir les versions, Enhancement Packages, développements spécifiques, add-ons, interfaces, volumes de données, performances, traitements batch et processus métiers qui en dépendent.

Pour les entités françaises, l’analyse doit également couvrir les codes société, procédures fiscales, structures de plans comptables, rapports comptables officiels, flux de factures, connexions bancaires et SEPA, interfaces de paie, pratiques de conservation des documents, données personnelles et accès privilégiés. Ces dépendances locales peuvent facilement être sous-estimées lorsque la migration est abordée principalement comme une conversion technique.

Le code spécifique doit être analysé au regard de son usage réel, de la responsabilité métier associée, de sa finalité réglementaire lorsqu’elle existe, de sa compatibilité avec SAP S/4HANA, des possibilités de remplacement par des fonctions standard, du modèle Clean Core et de l’extensibilité cible, ainsi que de critères précis de retrait. Chaque développement significatif peut ensuite être conservé, adapté, remplacé, repensé ou supprimé selon sa valeur métier et les exigences de l’architecture cible.

Les statistiques d’utilisation sont particulièrement utiles : un code encore présent dans SAP ECC peut ne plus être utilisé en production. Supprimer les développements obsolètes avant la migration peut réduire les efforts de remédiation et limiter la dette technique transférée dans le nouvel environnement.

La cartographie des intégrations doit aller au-delà d’une simple liste de points de connexion. Pour les interfaces importantes, les équipes doivent documenter les responsables métiers et techniques, la finalité métier ou réglementaire, les catégories de données échangées, la fréquence, la gestion des erreurs, les procédures de reprise et le modèle d’intégration cible.

Cette démarche est particulièrement importante pour les connexions avec les banques, les plateformes de paie, les systèmes fiscaux, les plateformes de facturation, les prestataires logistiques et les applications externes à SAP. Pendant le cutover et la stabilisation, les équipes doivent savoir non seulement comment fonctionne une interface, mais également quel processus métier ou réglementaire elle soutient.

3. Préparer les données

La stratégie de données doit définir ce qui sera transféré vers SAP S/4HANA, ce qui doit être transformé, ce qui restera archivé et ce qui pourra à terme être supprimé. Le nettoyage doit éliminer les doublons et corriger les incohérences sans supprimer les documents devant rester disponibles pour des raisons juridiques, comptables, fiscales ou d’audit.

Pour les données comptables françaises, les obligations de conservation doivent être intégrées dès la conception. Les livres et registres comptables ainsi que les pièces justificatives, notamment les factures clients et fournisseurs, doivent en règle générale être conservés pendant dix ans à compter de la clôture de l’exercice concerné.

Le modèle d’archivage cible doit donc préserver les justificatifs comptables nécessaires, la traçabilité des documents et la piste d’audit, tout en garantissant un accès fiable à l’historique après la migration. Le projet doit également définir de quelle manière les utilisateurs, les équipes Finance et les auditeurs pourront consulter les données qui ne seront plus présentes dans le système SAP S/4HANA productif.

Les données personnelles nécessitent une analyse distincte portant sur la minimisation, les accès, la conservation et la suppression, l’exercice des droits des personnes concernées, l’exposition dans les systèmes de test, le masquage lorsque cela est approprié et le recours à des sous-traitants. Copier l’intégralité des données de production dans des environnements non productifs sans analyser leur contenu peut créer un risque inutile au regard de la protection des données.

Les données de test doivent donc être adaptées à la finalité de chaque environnement. Lorsqu’il est réellement nécessaire d’utiliser des données proches de la production, les règles d’accès, de masquage et de conservation doivent être proportionnées à leur sensibilité.

Les migrations à blanc doivent inclure le rapprochement des soldes du grand livre, des postes ouverts clients et fournisseurs, des valeurs d’immobilisations, des quantités et valeurs de stocks, des montants de TVA, du nombre de documents et de tout autre total de contrôle convenu.

Les règles de rapprochement et les seuils de tolérance acceptables doivent être définis avant le cutover final afin que les écarts puissent être classés de manière cohérente, plutôt que discutés dans l’urgence pendant la migration en production.

4. Exécuter la migration

Lorsque la préparation et les cycles de test sont suffisamment avancés, le projet peut passer à la migration contrôlée vers la production. Le plan de cutover doit couvrir le provisionnement du système cible, les périodes de gel, les derniers chargements de données, la séquence des transports, l’arrêt et le redémarrage des interfaces, les accès utilisateurs ainsi que l’ordre de remise en service des processus métiers.

La migration ou conversion proprement dite doit suivre une procédure déjà répétée dans les environnements non productifs. Les critères de repli, les responsabilités décisionnelles ainsi que les conditions permettant de poursuivre ou d’arrêter le cutover doivent être définis avant l’ouverture de la fenêtre de production.

La configuration post-migration doit rester centrée sur le périmètre validé pour la mise en production. Introduire de nouvelles fonctionnalités pendant le cutover augmente les risques et complique l’identification de l’origine des incidents, entre un défaut de migration et un problème lié à une nouvelle fonction ou à un processus insuffisamment testé.

Le plan de migration doit également préciser à quel moment les intégrations, traitements batch, traitements de documents électroniques et connexions externes sont réactivés. Un redémarrage contrôlé de ces composants facilite l’identification des pannes et les opérations de rapprochement.

5. Tester et valider

Les tests doivent couvrir les processus de bout en bout et non uniquement les transactions SAP prises isolément. Ils doivent couvrir les aspects fonctionnels, les intégrations, les performances, l’acceptation utilisateur, les rapprochements financiers, SAP Fiori, les contrôles des autorisations et de la séparation des tâches, la sécurité, la protection des données, la reprise après sinistre et les répétitions du cutover, en reflétant les conditions réelles d’exploitation de l’environnement de production.

Pour les entités françaises, le catalogue de tests doit également couvrir la TVA, la comptabilité et le reporting comptable officiel, les formats bancaires, le reporting local, la facturation électronique et l’e-reporting. Ces processus traversent souvent plusieurs applications et systèmes externes. Les tests de bout en bout apportent donc davantage de valeur qu’une validation isolée des composants SAP.

Les tests financiers doivent reprendre la même logique de rapprochement que celle utilisée lors du cutover et de la stabilisation post-go-live. Les équipes Finance disposent ainsi d’une méthode reproductible pour valider les soldes, les postes ouverts, les immobilisations, les stocks, les montants fiscaux et les autres totaux de contrôle à chaque cycle de migration.

Tests de facturation électronique

La facturation électronique mérite un chantier de tests de bout en bout spécifique, car une défaillance peut interrompre le traitement des factures alors même que le reste de l’environnement ERP fonctionne correctement.

Selon les obligations de l’entreprise et les scénarios de transaction concernés, les tests doivent porter sur les données structurées des factures, les mentions obligatoires, le SIREN du client et les autres données de base requises, les informations de livraison lorsque nécessaire, les catégories d’opérations, le traitement de la TVA, l’indication relative à l’option pour le paiement de la TVA d’après les débits lorsqu’elle s’applique, les statuts du cycle de vie, les scénarios de rejet et de correction, les avoirs, le routage via la plateforme agréée retenue, l’e-reporting et, lorsque cela s’applique, la transmission des données de paiement.

Le processus d’échange est aussi important que le contenu de la facture. Un PDF classique envoyé par e-mail ne répond pas à lui seul au nouveau modèle français de facturation électronique, tandis que les formats structurés tels que Factur-X, UBL et CII font partie du dispositif.

Les tests doivent également couvrir les exceptions et pas uniquement les scénarios nominaux : rejets, corrections, données manquantes, erreurs de routage, changements de statut, indisponibilités de la plateforme et procédures de renvoi doivent faire l’objet de procédures opérationnelles définies avant la mise en production.

Les anomalies critiques ayant un impact sur la finance, la fiscalité, la sécurité, l’intégrité des données ou la facturation doivent être corrigées et retestées avant le go-live. Les traiter comme de simples sujets d’hypercare reviendrait à transférer un risque significatif du projet vers la production.

6. Go-live SAP S/4HANA

La préparation du go-live ne doit pas se limiter à la réussite technique de la migration. Le rapprochement des données et des comptes, l’état des intégrations, les contrôles de sécurité, les accès utilisateurs, la supervision, les mécanismes de reprise, les formations et l’organisation du support doivent tous être validés avant la décision finale de cutover.

La validation métier formelle doit associer les responsables de processus concernés. Les équipes Finance et fiscalité doivent valider le niveau de préparation dans leurs domaines respectifs. Le DPO doit être consulté sur les questions relatives à la protection des données et consigner tout avis ou toute réserve significative. Lorsque cela s’applique, le RSSI et les responsables du contrôle interne doivent également confirmer le niveau de préparation dans leur domaine.

Les accès utilisateurs doivent faire l’objet d’une certification formelle avant l’activation en production, en particulier pour les rôles privilégiés et les processus Finance sensibles.

Pour les entités françaises soumises aux obligations de facturation électronique, la plateforme agréée retenue, les connexions, le routage, les données de base, la gestion des exceptions et la supervision opérationnelle doivent être opérationnels. Les fournisseurs et clients doivent également être informés lorsque la migration modifie les canaux de facturation, les identifiants, les points de contact ou les procédures opérationnelles.

Les dispositifs de continuité d’activité doivent prévoir les mesures à prendre si un processus critique ne peut pas être rétabli pendant la fenêtre de cutover. La finance, la fiscalité, la facturation, les paiements et d’autres processus soumis à des contraintes de délai peuvent nécessiter des procédures de secours ou des modes opératoires manuels spécifiques.

Une cellule de support opérationnel dédiée, dotée des ressources nécessaires, doit fonctionner selon un dispositif d’assistance d’urgence clairement défini, avec des rotations de support, des niveaux de sévérité, une matrice d’escalade, des procédures d’escalade réglementaires et des responsabilités décisionnelles précises. Les équipes techniques et métiers disposent ainsi d’un circuit clair en cas d’incident susceptible d’affecter la Finance, la fiscalité, la facturation, la sécurité ou le reporting réglementaire.

Le modèle d’escalade doit notamment préciser qui peut valider une solution de contournement, une décision de rollback, une exception temporaire à un contrôle ou une modification de la séquence de cutover. Sans ces règles, même des incidents de production relativement limités peuvent entraîner des blocages décisionnels prolongés.

7. Support et optimisation après la migration

Les premières semaines suivant le go-live doivent être consacrées à la stabilisation. Les équipes doivent suivre les incidents critiques, les échecs d’interfaces, les écarts de rapprochement, les problèmes de traitement des factures, les anomalies d’autorisation et le backlog d’anomalies restant pendant la reprise progressive des opérations.

La sortie de la phase d’hypercare doit reposer sur des critères mesurables plutôt que sur une date arbitraire. La stabilité des interfaces, la réussite d’une clôture financière, la baisse des incidents critiques, la résolution des écarts de rapprochement, la régularité du traitement des factures et l’atteinte d’un niveau acceptable d’anomalies restantes constituent des indicateurs plus pertinents que le simple nombre de semaines écoulées depuis le go-live.

Le backlog d’anomalies restant doit ensuite être transféré vers un dispositif de gouvernance défini, avec des responsables, des priorités, des versions cibles et des critères d’escalade. Cette organisation permet de distinguer les risques réels pour la production des améliorations moins urgentes et de conserver une visibilité sur les sujets de migration non résolus lorsque l’équipe projet commence à se réduire.

Après la stabilisation, l’attention se porte sur la gestion des versions, les tests de non-régression, la recertification des autorisations, la supervision des contrôles, la conservation des éléments de preuve de conformité et le suivi des bénéfices.

La documentation issue des tests, validations, rapprochements, revues de sécurité, certifications d’accès et autres activités de contrôle doit rester disponible pour les revues internes ou externes lorsque nécessaire.

Le suivi des bénéfices doit s’appuyer sur des indicateurs définis avant la migration et non sur des métriques génériques ajoutées a posteriori. Selon le programme, les indicateurs pertinents peuvent inclure la durée de la clôture financière, le temps de traitement des factures, le nombre d’écritures manuelles, la précision des stocks, le cycle de traitement des commandes d’achat, le volume d’incidents, l’adoption des applications SAP Fiori concernées, le volume de code spécifique retiré ou encore le taux de rejet des factures électroniques.

Ces indicateurs permettent de distinguer la réussite technique de la migration de l’amélioration effective des opérations. Ils fournissent aussi une base pour prioriser les initiatives d’optimisation après stabilisation du nouvel environnement SAP S/4HANA.

Options de déploiement de SAP S/4HANA

Le modèle de déploiement cible a des répercussions sur l’extensibilité, les intégrations, l’exploitation, la gestion des versions et la trajectoire de migration elle-même. Il doit donc être évalué en parallèle de la stratégie de migration plutôt que traité ultérieurement comme une simple décision d’infrastructure.

SAP Cloud ERP

SAP Cloud ERP utilise SAP S/4HANA Cloud Public Edition comme application ERP centrale et privilégie des processus standardisés ainsi qu’une exploitation cloud gérée par SAP. Pour les clients SAP ECC qui visent SAP Cloud ERP, la transition nécessite une nouvelle implémentation plutôt qu’une conversion directe du système ou une Selective Data Transition.

Les entités françaises doivent vérifier que la localisation, les processus comptables et réglementaires, les intégrations et les scénarios de facturation électronique nécessaires sont pris en charge pour le périmètre prévu. Cette vérification est particulièrement importante lorsque les processus ECC existants reposent largement sur des développements locaux spécifiques ou sur des interfaces historiques.

SAP Cloud ERP Private

SAP Cloud ERP Private offre davantage de flexibilité pour les environnements complexes et peut prendre en charge une conversion de système ainsi que des scénarios de transformation plus larges. Cette option peut convenir aux organisations qui souhaitent préserver une part plus importante de leur configuration actuelle tout en évoluant vers un modèle d’exploitation cloud.

Cette flexibilité doit néanmoins s’accompagner d’une stratégie Clean Core explicite. Dans le cas contraire, une migration vers le cloud privé risque simplement de reproduire une part importante de la dette technique existante dans un autre modèle d’exploitation.

SAP S/4HANA on-premises

Le déploiement on-premises offre davantage de contrôle sur l’exploitation du système, l’infrastructure et le calendrier des versions. Il peut rester pertinent pour les organisations ayant des exigences particulières en matière d’architecture, d’intégration, de sécurité ou d’exploitation.

Ce niveau de contrôle s’accompagne d’une responsabilité opérationnelle plus importante pour l’entreprise. Un déploiement on-premises ne supprime ni les dépendances aux produits SAP, ni les responsabilités de cybersécurité, ni les obligations françaises et européennes en matière de conformité.

Architectures hybrides et two-tier

Les grands groupes peuvent utiliser différents modèles ERP selon les entités. Par exemple, le siège ou des activités industrielles complexes peuvent nécessiter un environnement plus flexible, tandis que de plus petites filiales utilisent un modèle cloud davantage standardisé.

Cette approche peut mieux répondre aux besoins des différentes entités, mais elle accroît les exigences de coordination. Une architecture two-tier nécessite des règles claires concernant les données de base, les intégrations, les processus intercompany, le reporting, la sécurité et la conformité locale avant la mise en production des différents niveaux.

Points d’attention spécifiques à la France pour une migration SAP ECC vers SAP S/4HANA

Les exigences françaises doivent influencer l’architecture cible et la conception de la migration dès le départ. Elles ne doivent pas être traitées comme une couche de conformité ajoutée après que les principales décisions ERP ont déjà été prises.

Comptabilité française et reporting comptable officiel

Les équipes Finance doivent valider la conception des ledgers, la correspondance des comptes, les comptes sociaux français, les états financiers, la piste d’audit, la numérotation des pièces et les rapprochements dans l’environnement cible.

Les rapports SAP ECC et les programmes spécifiques existants doivent également être examinés avant d’être reconstruits. Certains peuvent être remplacés par les fonctionnalités standard de SAP S/4HANA, tandis que d’autres répondent toujours à une exigence locale réelle.

L’objectif consiste à préserver la conformité comptable et réglementaire sans reconduire automatiquement chaque solution technique historique. Les développements spécifiques anciens ne doivent être maintenus que lorsqu’ils répondent encore à une finalité métier ou réglementaire clairement identifiée.

TVA

La TVA intervient dans la détermination des prix, la facturation, les achats, la comptabilité et le reporting. La conception cible doit donc préserver la logique fiscale nécessaire dans l’ensemble de ces processus.

Les domaines concernés peuvent inclure les codes de taxe, les règles de détermination, les exonérations, les mécanismes d’autoliquidation, les opérations intracommunautaires, le reporting, les rapprochements ainsi que le traitement de la TVA sur les encaissements ou sur les débits lorsqu’il s’applique.

La réforme française de la facturation électronique modifie la manière dont les données de facture et de transaction sont échangées, mais elle ne remplace pas la logique de TVA sous-jacente. Une transmission correcte ne peut pas compenser une détermination fiscale erronée en amont.

Facturation électronique et e-reporting

Dans le cadre d’une migration SAP S/4HANA, les obligations françaises de facturation électronique et d’e-reporting ont des incidences sur les processus de facturation et de comptabilité, les données de base, les formats de facture, les mentions obligatoires, la génération des documents électroniques, l’intégration avec la plateforme agréée choisie, le traitement des factures entrantes, la gestion des statuts et l’archivage.

Lorsque SAP Document and Reporting Compliance fait partie de la solution cible, son périmètre fonctionnel pour la France ainsi que ses prérequis techniques doivent être validés pour l’environnement sélectionné.

La facturation électronique et la migration ERP doivent donc partager les mêmes décisions d’architecture, de données de base et d’intégration. Les gérer comme des programmes indépendants peut entraîner des doublons de configuration et la répétition de tests de bout en bout.

Protection des données et cybersécurité

Une migration ERP peut modifier les lieux de stockage des données personnelles et métiers, les systèmes qui les traitent ainsi que les utilisateurs internes ou externes qui peuvent y accéder. L’analyse liée à la protection des données doit donc couvrir la finalité des traitements, les accès, la conservation, la suppression, les environnements non productifs, les sous-traitants externes et les transferts internationaux lorsqu’ils sont pertinents.

Le nouvel environnement peut également introduire des services cloud, des API, de nouvelles identités, davantage d’intégrations et de nouveaux prestataires. La gestion des identités et des accès privilégiés, l’authentification, le chiffrement, la journalisation, la gestion des vulnérabilités, la sauvegarde et la reprise, la réponse aux incidents et les risques liés aux tiers doivent être intégrés au modèle de sécurité cible.

Organisation du travail et CSE

Une transformation SAP peut modifier les rôles des salariés, les circuits de validation, les interfaces et les pratiques de travail quotidiennes. Lorsque le projet a un impact significatif sur l’organisation ou les conditions de travail, l’entreprise doit déterminer si les obligations applicables d’information ou de consultation du CSE sont déclenchées.

La conduite du changement doit également prendre en compte les besoins locaux. Des communications en français, des formations adaptées aux rôles, une terminologie locale cohérente et des consignes opérationnelles sur les nouveaux workflows peuvent faciliter l’adoption et limiter les difficultés évitables après le go-live.

Banques, paie et systèmes externes

Les entités françaises peuvent dépendre de processus SEPA, de connexions bancaires, de payment factories, de systèmes de paie, d’applications fiscales, de plateformes de gestion documentaire et d’autres services externes. Ces intégrations soutiennent des processus métiers et réglementaires et doivent faire partie du périmètre de transformation plutôt que d’être considérées comme de simples connexions techniques secondaires.

L’architecture cible doit préciser les responsabilités et les procédures de reprise pour les interfaces critiques. Pendant le cutover et la stabilisation, les équipes doivent pouvoir distinguer les incidents provoquant un simple retard de ceux susceptibles de bloquer les paiements, la paie, la facturation ou les traitements réglementaires.

Groupes multi-entités et internationaux

Les groupes internationaux doivent concilier les standards SAP globaux avec les exigences réglementaires et opérationnelles françaises. Le modèle cible doit préciser quels processus sont harmonisés au niveau du groupe, où la localisation reste nécessaire, comment les données de base sont gouvernées, comment fonctionnent les flux intercompany et comment coexistent le reporting local et le reporting groupe.

Un template global peut réduire la fragmentation, mais il doit toujours intégrer des choix explicites pour la France. À défaut, les entités françaises risquent de recréer des contournements après le go-live et de réintroduire progressivement la complexité que la migration devait précisément réduire.

Combien de temps dure une migration de SAP ECC vers SAP S/4HANA ?

Il n’existe pas de durée standard pour une migration de SAP ECC vers SAP S/4HANA. Un guide de transformation SAP Community applicable à SAP Cloud ERP Private fournit les fourchettes indicatives suivantes pour la planification de bout en bout. Ces chiffres peuvent servir de référence initiale, mais ne doivent pas être considérés comme des benchmarks universels ni comme des engagements de délai pour d’autres modèles de déploiement SAP S/4HANA.

La durée réelle dépend du nombre de systèmes, de pays et d’entités, des intégrations, des volumes de données, du code spécifique, des exigences de test, du modèle de déploiement et des ressources disponibles. Pour les entreprises françaises, la facturation électronique et les travaux de conformité locale doivent être intégrés au même planning afin d’éviter de dupliquer les configurations et les tests.

À titre de comparaison, LeverX a réalisé une migration de SAP ECC vers SAP S/4HANA pour Eurasia Group en 8,5 mois. Ce résultat correspond à un périmètre de projet précis et ne doit pas être utilisé comme référence générale pour toutes les migrations.

Principaux risques d’une migration vers SAP S/4HANA

Qualité insuffisante des données

Les données en doublon, incomplètes ou incohérentes peuvent provoquer des erreurs de migration et de rapprochement. Un profilage des données réalisé suffisamment tôt, des responsabilités clairement définies, le nettoyage des données et plusieurs cycles de rapprochement réduisent le risque de transférer ces problèmes vers la production.

Compatibilité du code spécifique

Les développements historiques peuvent dépendre d’objets SAP ECC ou de logiques de processus modifiées dans SAP S/4HANA. Associer l’analyse technique à l’usage réel et à la valeur métier facilite la décision de conserver, adapter, remplacer, repenser ou retirer chaque développement.

Échecs d’intégration

Les systèmes externes peuvent dépendre d’interfaces, de structures, de protocoles ou de cadences modifiés pendant la migration. Un inventaire complet des interfaces et des tests de bout en bout avec les systèmes effectivement interconnectés offrent davantage de fiabilité qu’une validation limitée au seul côté SAP.

Lacunes dans la localisation France ou la fiscalité

Une conversion techniquement réussie peut malgré tout laisser subsister des problèmes de TVA, de reporting comptable officiel ou de processus locaux. Un chantier dédié à la localisation en France et à la finance permet d’identifier ces écarts avant qu’ils n’affectent la clôture financière ou le reporting réglementaire.

Rejet des factures électroniques

Des données de base incorrectes, des mentions obligatoires manquantes, des erreurs de mappage ou des défaillances d’intégration avec la plateforme peuvent interrompre le traitement des factures. Des scénarios représentatifs, les flux de correction, la gestion des exceptions et la supervision des rejets doivent donc être testés avant le go-live.

Cutover et indisponibilité

Un cutover en échec ou trop long peut perturber les opérations critiques. Des répétitions du cutover, des critères de repli clairs et des responsabilités décisionnelles prédéfinies limitent les improvisations pendant la fenêtre de production.

Sécurité et gestion des accès

De nouveaux rôles, interfaces ou services cloud peuvent introduire des accès inappropriés ou des lacunes de contrôle. La gestion des identités, les accès privilégiés, la journalisation et les tests de sécurité doivent faire partie du programme principal de migration et ne pas être repoussés à une revue technique finale.

Difficultés d’adoption

Les nouvelles applications SAP Fiori, les nouveaux rôles et circuits de validation peuvent affecter la productivité même lorsque le système fonctionne correctement. Une implication précoce des utilisateurs, des tests d’acceptation utilisateur (UAT) représentatifs et des formations par rôle réduisent l’écart entre la préparation technique et l’adoption opérationnelle.

Élargissement du périmètre

Les programmes de migration ont souvent tendance à s’élargir lorsque les équipes commencent à repenser les processus et à ajouter des fonctionnalités qui ne figuraient pas dans le périmètre initial. Des règles claires de décision, de gestion des changements et de priorité entre versions permettent d’éviter qu’une migration ne se transforme en programme de transformation sans fin.

Cas client : migration vers SAP S/4HANA chez Eurasia Group

Même si le périmètre d’une migration varie selon l’entreprise et le pays, le projet Eurasia Group illustre concrètement une trajectoire de transformation. Eurasia Group s’est associé à LeverX pour migrer de SAP ECC vers SAP S/4HANA dans le cadre d’une modernisation plus large de son environnement applicatif. L’équipe projet conjointe a réalisé la migration en 8,5 mois en s’appuyant sur les pratiques SAP Activate.

Selon le cas client « Migration vers SAP S/4HANA pour Eurasia Group Kazakhstan », les résultats communiqués comprennent une réduction de 10 % des coûts de maintenance du système et une amélioration de 15 % de la cohérence des données. Le projet a également mis en place des sauvegardes complètes et incrémentales régulières, l’analytique en temps réel, SAP S/4HANA dans le cloud avec une authentification unique (SSO) moderne, SAP Fiori et une intégration avec SAP Cloud for Customer.

La migration a par ailleurs créé un socle pour d’autres initiatives, notamment SAP EWM et des fonctionnalités liées aux programmes de fidélité. Ces résultats correspondent au périmètre et aux conditions spécifiques de ce projet et ne constituent pas des performances standard applicables à toutes les migrations SAP S/4HANA.

Pourquoi choisir LeverX pour une migration de SAP ECC vers SAP S/4HANA ?

LeverX associe une expérience des migrations SAP, des capacités internationales de mise en œuvre et une présence en France. Ses services couvrent l’ensemble du cycle de migration, depuis l’évaluation et la définition de l’architecture cible jusqu’à la préparation des données, la conversion ou l’implémentation, les tests, le cutover et la stabilisation.

LeverX peut réunir stratégie de migration, transformation des données, analyse du code spécifique, Clean Core, intégration, localisation et modernisation des processus métiers au sein d’une même feuille de route. Cette approche permet de traiter les exigences françaises parallèlement au cœur de la transformation ERP, plutôt que de les ajouter une fois l’architecture cible déjà définie.

Conclusion

Passer de SAP ECC à SAP S/4HANA implique des décisions coordonnées concernant la technologie, les données, les processus, les contrôles et le futur modèle opérationnel de l’ERP. Pour les organisations françaises, ces décisions doivent désormais être prises en parallèle de l’échéance de maintenance de base de 2027, de la maintenance étendue optionnelle jusqu’en 2030, de la localisation France, des exigences de sécurité et de protection des données, de la disponibilité des compétences SAP et de la conduite du changement.

La facturation électronique apporte son propre calendrier. Depuis le 1er septembre 2026, toutes les entreprises concernées doivent pouvoir recevoir des factures électroniques. Les grandes entreprises et les ETI sont également soumises aux obligations d’émission et d’e-reporting applicables. Les PME et microentreprises entreront dans cette phase le 1er septembre 2027.

Les approches Greenfield, Brownfield et Selective Data Transition répondent à des objectifs de transformation différents. La bonne trajectoire dépend de ce que l’entreprise souhaite conserver de SAP ECC et de ce qu’elle prévoit de simplifier, repenser ou supprimer dans l’environnement cible.

Une préparation suffisamment en amont donne aux équipes davantage de marge pour séquencer la migration, la conformité, les tests et la conduite du changement, plutôt que de concentrer toutes ces activités dans une même fenêtre de réalisation. Elle permet également de distinguer les exigences qui doivent réellement rester dans le cœur du système cible des personnalisations qui peuvent être simplifiées ou supprimées.

Prêt à évaluer votre trajectoire de migration de SAP ECC vers SAP S/4HANA ?

Demander une évaluation de préparation à la migration

FAQ