Fin de la maintenance de SAP ECC au 31 décembre 2027 : une marche tarifaire, pas un arrêt

Le 31 décembre 2027, SAP met fin à la maintenance standard de SAP ECC 6.0 et des autres applications cœur de SAP Business Suite 7. Rien ne s'éteint le 1er janvier 2028. Votre système continue de tourner, vos utilisateurs continuent de comptabiliser des factures, et SAP continuera de vous vendre du support. Ce qui change, c'est ce que vous payez pour ce support et ce que vous obtenez en échange.

La distinction compte, car une bonne partie des conseils qui circulent présentent 2027 comme une falaise. Pour la plupart des entreprises encore sur ECC, ce n'en est pas une, et elles le savent : le groupe le plus important d'utilisateurs ECC restants planifie pour 2030. Le vrai risque est ailleurs. Le travail qui décide réellement de la date (ABAP spécifique, interfaces, données) est cadré trop tard, et 2030 se révèle aussi serré que l'était 2027.

Cet article s'adresse aux DSI et aux responsables SAP des entreprises de taille intermédiaire, pour la plupart sur les marchés germanophones, qui font encore tourner ECC et doivent décider à quoi ressembleront les trois prochaines années.

Ce à quoi SAP s'est réellement engagé

Les conditions figurent sur la page de stratégie de maintenance de SAP et ont été annoncées pour la première fois en février 2020 :

• Jusqu'au 31 décembre 2027 : maintenance standard des applications cœur de Business Suite 7, dont SAP ERP 6.0, sur les trois derniers enhancement packages. Si votre système est sur un enhancement package plus ancien, consultez la note SAP 2881788 (accessible depuis cette page) avant de bâtir un plan sur la date de 2027.
• Du 1er janvier 2028 au 31 décembre 2030 : maintenance étendue optionnelle, moyennant « une majoration de deux points de pourcentage sur la base de maintenance ». Pour dire les choses simplement, le taux de maintenance que vous payez aujourd'hui augmente de deux points.
• Si vous ne prenez pas la maintenance étendue : vous passez automatiquement en maintenance spécifique au client (customer-specific maintenance). Ce qu'elle couvre est décrit dans la note SAP 52505, accessible depuis la même page. Lisez-la avant de supposer qu'elle suffit.
• Pour S/4HANA : SAP s'est engagé sur une maintenance jusqu'à fin 2040.

Une voie supplémentaire existe pour un groupe plus restreint. En août 2025, SAP a présenté l'option de transition SAP ERP, private edition : un abonnement limité dans le temps qui prolonge ECC de 2031 à 2033 dans le cloud privé de SAP. Les conditions sont strictes. « Les systèmes doivent être migrés vers SAP ERP, private edition, sur SAP HANA avant le 31 décembre 2030. » HANA est la seule base de données prise en charge, l'option n'est proposée qu'avec le plan max success pour 2031 à 2033, et SAP fixe un minimum de 2 To pour les systèmes souscrits à ce titre. SAP indique qu'elle est destinée à « nos clients SAP ERP les plus grands et les plus complexes ». Les « conditions commercialement équivalentes » proposées par SAP visaient les clients qui s'étaient engagés sur la private edition avant fin 2025.

Quel que soit le niveau choisi, posez par écrit une question à SAP et à votre intégrateur : quelles évolutions légales (fiscalité, paie, formats de facturation électronique) parviendront encore à votre système ECC, et jusqu'à quand. Pour une entreprise allemande, cette réponse peut à elle seule décider si le statu quo est tenable.

Ce que fait le reste du marché

Le DSAG, le groupe d'utilisateurs SAP germanophones, a mené son Investment Report 2026 auprès de 198 répondants entre le 8 décembre 2025 et le 21 janvier 2026. Parmi eux, 54 % font encore tourner ECC ou l'ancienne Business Suite, contre 68 % en 2024.

Côté calendrier, près de la moitié des répondants prévoient de passer à S/4HANA d'ici fin 2030, ce qui, comme le souligne le DSAG, implique de payer la maintenance étendue. Par ailleurs, 37 % veulent basculer d'ici fin 2027, et seulement 4 % visent 2033 et l'option de transition private edition.

Le président du DSAG, Jens Hungershausen, a exposé les raisons sans détour : la pénurie de compétences, les projets de transformation menés en parallèle et les budgets limités repoussent les calendriers, « même si cela entraîne des coûts de maintenance plus élevés ».

Les acheteurs publics bougent aussi. Notre propre décompte des avis de marchés publics de l'UE relève environ 200 procédures de migration vers S/4HANA par semestre en 2025 et 2026, et plus de 300 en 2026 au début d'octobre, la plupart en Allemagne. Le travail se fait. Il s'étale simplement sur une piste plus longue que ne le suggèrent les gros titres sur 2027.

Où se trouve réellement le travail

La conversion technique d'ECC vers S/4HANA est bien outillée par SAP et ses partenaires. Si vous faites tourner un ECC peu personnalisé avec une poignée d'interfaces standard, votre intégrateur l'a fait de nombreuses fois et l'essentiel de ce qui suit ne vous concerne pas.

Cela vous concerne en proportion de ce que vous avez construit vous-même.

L'ABAP spécifique : là où les projets dérapent

S/4HANA n'est pas ECC sur une nouvelle base de données. Des pans du modèle de données ont changé. Les clients et les fournisseurs deviennent des partenaires commerciaux (business partners). Les écritures financières et de stocks ont été regroupées dans des tables moins nombreuses et plus larges. Certaines transactions et fonctions ont été supprimées ou remplacées.

Le code spécifique qui lit directement des tables, s'appuie sur un exit qui a été déplacé ou suppose discrètement un ordre de tri (HANA n'en garantit aucun si la requête ne le demande pas) peut passer un contrôle de syntaxe et faire malgré tout la mauvaise chose. C'est cette dernière catégorie qui fait mal, car elle apparaît pendant les tests d'intégration ou après la mise en production, pas lors de l'analyse du code.

La démarche qui fonctionne :

1. Mesurer d'abord l'utilisation. Activez la journalisation de l'utilisation en production (l'ABAP call monitor, transaction SCMON) et laissez-la tourner pendant toute une clôture de fin d'année. Dans les systèmes anciens, une part importante des objets spécifiques ne s'exécute souvent jamais. Le code que personne n'exécute est supprimé, pas migré.
2. Lancer les outils d'analyse sur ce qui reste. Les contrôles de SAP trouvent des problèmes potentiels. Ils ne peuvent pas vous dire lesquels comptent pour le métier.
3. Classer chaque objet. Le retirer, le remplacer par une fonction standard, le corriger sur place, ou le reconstruire hors du cœur. Une décision par objet, avec un responsable métier nommé.
4. Tester par processus, pas par objet. Modifier le code est la partie bon marché. Prouver que le cycle de la commande à l'encaissement et la clôture mensuelle produisent toujours les mêmes chiffres est la partie coûteuse.

Les projets dérapent ici pour une raison banale : personne n'a compté assez tôt. Le volume de code spécifique n'est connu qu'approximativement, ceux qui l'ont écrit sont souvent partis, et les vraies découvertes arrivent au deuxième cycle de tests, une fois la date annoncée en interne.

Les interfaces, et PI/PO sur la même horloge

ECC fonctionne rarement seul. Des IDocs vers l'entrepôt, des appels RFC et BAPI depuis l'atelier, des fichiers plats vers la banque et le conseiller fiscal, un portail client qui lit une vue de base de données créée par quelqu'un en 2011. Chacun doit être trouvé, testé et, dans certains cas, reconstruit.

Si ces interfaces passent par SAP Process Integration ou Process Orchestration, une seconde échéance tombe aux mêmes dates. L'Architecture Center de SAP indique que PI/PO approche de « la fin de la maintenance standard en 2027 », que les clients peuvent prolonger la maintenance jusqu'en 2030 et que le support de SAP s'arrête ensuite. SAP oriente les clients PI/PO vers SAP Integration Suite, qui s'accompagne d'une évaluation de migration et d'outils de migration guidés par assistant.

L'outillage aide pour les objets standard. Il ne vous dit pas quelles interfaces servent encore à quelque chose, et la logique de mapping spécifique demande toujours que quelqu'un la lise. Construisez l'inventaire à partir de la configuration du middleware, des journaux et des tâches planifiées, pas à partir d'un questionnaire. Puis planifiez ensemble la migration de l'ERP et celle du middleware. Menées l'une après l'autre, chaque interface est testée deux fois.

La migration des données

Dans une conversion de système, vos données migrent avec le système, et leur qualité aussi. La conversion en partenaires commerciaux est généralement la première collision : clients en double, fournisseurs qui sont aussi clients, adresses dans des champs de texte libre, numéros fiscaux au mauvais endroit. Tout cela doit être nettoyé avant la conversion, pas pendant.

Dans une nouvelle implémentation, vous extrayez, nettoyez, transformez et chargez, et la partie difficile est le rapprochement. La finance valide quand les soldes et les postes ouverts concordent, pas quand le chargement est terminé. Construisez la migration sous forme de code rejouable, que vous pouvez lancer une douzaine de fois sur des données de plus en plus propres, en comparant automatiquement les résultats à chaque passage.

Quelle que soit la voie, archivez d'abord ce dont vous n'avez plus besoin. Moins de données, ce sont des conversions plus courtes et une fenêtre d'interruption plus courte.

Les extensions clean core

Dans un projet piloté par une échéance, la tentation est d'embarquer toutes les modifications et de promettre de faire le ménage plus tard. Plus tard n'arrive jamais.

Le nom que SAP donne à l'alternative est clean core : laisser le système standard non modifié et construire les extensions sur des interfaces que SAP publie et maintient stables, soit dans S/4HANA, soit à côté, sur SAP Business Technology Platform. Tout ne peut pas être propre dès le premier jour. La règle que l'on peut réellement tenir est plus simple : plus rien de nouveau ne se construit à l'ancienne. Chaque modification évitée aujourd'hui est une modification que vous n'aurez pas à retester à chaque mise à niveau future.

Un cadre de décision

Il existe trois voies réalistes, et une quatrième dont on parle moins.

Démarrer sur S/4HANA d'ici le 31 décembre 2027. Cela convient aux entreprises qui ont déjà commencé, font tourner un système essentiellement standard et ont un intégrateur réservé. À partir d'aujourd'hui, cela fait quinze mois, et peu d'équipes financières accepteront une bascule en pleine clôture annuelle. Si votre analyse du code spécifique n'a pas été faite, ce n'est probablement pas votre voie.

Payer la maintenance étendue et démarrer d'ici 2030. C'est la direction que prend l'essentiel du marché. Le coût, c'est la majoration de deux points ; vérifiez avec SAP comment elle s'applique si vous démarrez en cours de période. Le risque est de traiter 2030 comme on a traité 2027 : comme une date lointaine, jusqu'à ce qu'elle ne le soit plus.

Prendre l'option de transition private edition jusqu'en 2033. Cela signifie un contrat RISE with SAP, HANA, votre système migré vers SAP ERP, private edition, avant le 31 décembre 2030, le plan max success et le minimum de 2 To. Pour une entreprise de taille intermédiaire, c'est rarement la façon la moins chère d'acheter du temps.

Quitter SAP. Pour certains industriels et distributeurs de taille intermédiaire, un ERP plus modeste est une vraie option. Le travail sur les interfaces et les données ne diminue pas. Il devient l'essentiel du projet.

Les six prochains mois, quelle que soit la voie choisie

D'ici fin mars 2027, tout ce qui suit est rentable sur toutes les voies :

1. Confirmez votre point de départ. Enhancement package, base de données, contrat de maintenance. Demandez par écrit à votre interlocuteur commercial SAP les conditions de maintenance étendue qui vous sont applicables.
2. Activez dès maintenant la journalisation de l'utilisation, pour qu'elle couvre la clôture de fin 2026.
3. Lancez une analyse du code spécifique et ressortez-en avec un décompte, pas une impression : combien d'objets, combien sont utilisés, combien touchent aux parties modifiées du modèle de données.
4. Construisez l'inventaire des interfaces, y compris tout ce qui passe par PI/PO, avec un responsable et une décision pour chaque interface.
5. Lancez le nettoyage des données de référence, en commençant par les clients et les fournisseurs.
6. Cessez d'ajouter des modifications. Les nouveaux développements suivent le clean core dès aujourd'hui.
7. Inscrivez la hausse de maintenance de 2028 au budget 2027, comme un coût connu plutôt qu'une surprise.
8. Réservez les capacités : l'intégrateur, votre équipe SAP interne, et les développeurs qui s'occupent des systèmes autour de SAP. La pénurie de compétences fait partie des raisons que donnent les membres du DSAG pour expliquer les glissements de calendrier.

En remontant depuis un démarrage en 2030 : cycles de tests et répétitions de bascule en 2030, développement et corrections en 2029, conception et nettoyage des données en 2028, analyse maintenant. Il y a moins de marge là-dedans qu'il n'y paraît.

Où trouver de l'aide

Nous ne sommes pas un cabinet de conseil fonctionnel SAP et nous ne menons pas de conversions S/4HANA ; nous travaillons aux côtés de l'intégrateur qui le fait, sur l'inventaire et la reconstruction des interfaces, le code de migration des données et son rapprochement, et les applications construites autour d'ECC qui doivent survivre à la migration. Ce travail est décrit sur notre page de modernisation d'ERP, et la maintenance de systèmes anciens couvre les systèmes qui restent en place jusqu'à votre migration. Si vous voulez faire l'inventaire de tout ce qui entoure votre ERP avant de signer un programme, écrivez à office@c9group.dev.