SAP Commerce on-premise après le 31 juillet 2026 : ce qui a changé et vos quatre options

La maintenance mainstream de SAP Commerce on-premise, la plateforme que beaucoup d’équipes appellent encore Hybris, a pris fin le 31 juillet 2026 (SAP Help Portal). La release 2205 était la dernière release on-premise, et SAP n’en a pas prévu d’autre. Cet article est notre guide tenu à jour pour tous ceux qui l’utilisent encore : ce qui a changé, quel support reste disponible et comment les options réalistes se comparent.

Rien ne s’est cassé le 1er août. Les boutiques sont restées en ligne et les commandes ont continué d’arriver, et c’est précisément pour cela que cette phase est sous-estimée. Le coût du statu quo ne se manifeste pas par une panne. Il se manifeste par des vulnérabilités ouvertes, par un travail de conformité qui incombe désormais à votre équipe et par une migration de plus en plus difficile à staffer, trimestre après trimestre.

En bref : depuis le 31 juillet 2026, SAP Commerce on-premise (release 2205) est en maintenance spécifique client : les problèmes connus sont toujours résolus, mais il n’y a plus de support packages, de modifications légales ni de mises à jour des bibliothèques, et les nouveaux problèmes peuvent entraîner des frais. Vous avez quatre options : continuer pour une durée limitée, utiliser délibérément la maintenance spécifique client comme passerelle, migrer vers SAP Commerce Cloud (ou, si vous utilisez S/4HANA Public Cloud, vers la nouvelle ERP Edition) ou quitter SAP. Pour la plupart des boutiques B2B intégrées à SAP, la migration au sein de la pile SAP préserve l’intégration ERP et coûte le moins cher au total. Parlez-nous de votre situation.

Ce qui a changé le 1er août 2026

« End of Mainstream Maintenance » est un terme SAP précis. Depuis le 1er août 2026, pour SAP Commerce on-premise :

• Plus de support packages ni de correctifs de sécurité. Lorsque la prochaine vulnérabilité touchera la plateforme ou une bibliothèque embarquée (Spring, Solr, composants Apache), SAP ne livrera pas de correctif pour la 2205. Le système qui gère les comptes clients et touche aux flux de paiement accumule désormais des points ouverts.
• Plus de modifications légales ni fiscales. Changements de taux de TVA, règles de facturation et adaptations liées à la protection des données (RGPD, nLPD) deviennent du développement interne, multiplié par le nombre de pays où vous vendez.
• Plus de mises à jour des bibliothèques tierces ni de nouvelles versions de Java. SAP ne teste ni ne certifie plus de nouvelles releases de la JVM pour l’on-premise. L’environnement d’exécution actuel vieillit sur place.
• Plus de mises à jour technologiques ni d’interfaces. Lorsque vos partenaires de paiement, de logistique et d’ERP modifient leurs API, maintenir les intégrations est votre affaire.
• Plus de nouvelles fonctionnalités de storefront. SAP Composable Storefront (anciennement Spartacus) et les nouvelles capacités comme le merchandising piloté par l’IA sont développés pour SAP Commerce Cloud (SAP Help Portal).

La FAQ de SAP sur la fin de la maintenance mainstream fait référence pour les détails propres au produit ; consultez-la avant d’arrêter un budget.

Ce que couvre encore la maintenance spécifique client

À la fin de la maintenance mainstream, les releases SAP passent automatiquement en maintenance spécifique client. Selon la définition de SAP (SAP Support, customer-specific maintenance) :

• elle se poursuit dans le cadre de votre contrat de support existant ; aucun contrat séparé n’est nécessaire ;
• la résolution couvre les problèmes connus ; la résolution de nouveaux problèmes peut être facturée ;
• il n’y a ni modifications légales, ni nouveaux support packages, ni mises à jour technologiques garanties, comme de nouvelles versions de base de données, de système d’exploitation ou de Java.

Autrement dit, vous gardez un canal de support, mais pas un produit maintenu. Comme passerelle pendant une migration, c’est utile. Comme solution durable, non, et c’est pourquoi nous ne parlons plus de « support étendu » pour la voie on-premise : rien n’est étendu, le service se réduit.

Où se cachent les coûts du statu quo

La facture de licence est la partie visible. L’essentiel du coût de l’on-premise après l’EoMM se trouve dans des postes qui figurent rarement dans le même tableur :

Poste de coût	On-premise après l’EoMM	SAP Commerce Cloud
Infrastructure (production, staging, développement, reprise après sinistre)	Hébergement, réseau et disponibilité à votre charge	Incluse dans l’abonnement
Correctifs de sécurité	Votre équipe développe et teste les correctifs, ou accepte le risque	Livrés par SAP avec les mises à jour de la plateforme
Mises à jour fiscales, légales et Java	Développement interne	Livrées par SAP
Exploitation	Personnel dédié à la plateforme	Réduite, centrée sur la logique métier
Compétences spécialisées	Un vivier de développeurs on-premise qui se réduit	Un vivier plus large sur Commerce Cloud
Backlog fonctionnel	Chaque nouvelle capacité est un projet à part	Releases régulières de la plateforme

Nous ne mettons volontairement pas de montants génériques en CHF dans ce tableau : ils dépendent de votre installation, du nombre de storefronts et de la part d’exploitation que vous assurez vous-même. Lors d’un assessment, nous le remplissons avec vos chiffres. Notre guide des prix et du TCO de SAP Commerce Cloud explique comment l’abonnement est structuré.

Deux coûts méritent une mention à part. Les compétences : de moins en moins de développeurs veulent travailler sur une plateforme qui n’est plus maintenue, et si une seule personne détient la connaissance critique de vos personnalisations, c’est un risque pour l’entreprise. Le coût d’opportunité : chaque fonctionnalité demandée par le métier (un nouveau tunnel de commande, un frontend PWA, le libre-service B2B) devient un développement sur mesure sur une plateforme figée.

Option 1 : continuer et assumer le risque

C’est l’option par défaut, puisqu’elle ne demande aucune décision, et c’est la seule dont le coût augmente chaque mois.

Pour une petite boutique B2B qui évolue peu, derrière un réseau bien protégé, continuer quelques mois pendant la préparation d’une migration peut être un risque calculé et défendable. Continuer sans plan de migration, c’est un incident reporté. L’exposition s’accumule : chaque vulnérabilité non corrigée reste ouverte, le travail de conformité passe à votre équipe et votre position face aux auditeurs et aux assureurs se dégrade. « Nous traitons des paiements sur un logiciel qui n’est plus maintenu » est une phrase que votre RSSI devra un jour prononcer.

Ne choisissez cette option que comme passerelle explicite et limitée dans le temps, avec une analyse de risque validée, pendant qu’une des autres options est déjà engagée.

Option 2 : la maintenance spécifique client comme passerelle planifiée

En pratique, cette option se déroule en parallèle de la première : vous êtes de toute façon en maintenance spécifique client, que vous l’ayez choisi ou non. La différence est de l’utiliser délibérément. Elle vous donne un canal de support pour les problèmes connus et un éditeur que vous pouvez encore appeler. Elle ne vous donne ni nouvelles fonctionnalités, ni correctifs de sécurité, ni feuille de route.

Elle a du sens dans un scénario : une installation vaste et complexe qui ne peut pas migrer en moins de 12 mois (gel réglementaire, fusion-acquisition, programme ERP parallèle) et qui a besoin d’une passerelle documentée. Si c’est votre cas, clarifiez dès maintenant avec SAP comment les nouveaux problèmes seraient traités et facturés dans votre contrat, plutôt qu’après le premier incident, et placez la fin de la passerelle sur la même diapositive que la date de lancement de la migration.

Option 3 : migrer vers SAP Commerce Cloud

C’est la voie naturelle, et celle où votre investissement survit : modèle de données, logique métier, une bonne partie des personnalisations et surtout l’intégration ERP sont conservés. C’est aussi l’option que nous connaissons le mieux ; pondérez notre avis en conséquence et vérifiez-le à l’aune des références.

• Franke : nous avons repris une plateforme commerce héritée et enlisée, puis mis SAP Commerce Cloud en production en 90 jours. Ce lancement commerce a reçu le SAP Quality Award « Rapid Time to Value », et les commandes manuelles ont baissé d’environ 75 %. Le playbook des 90 jours décrit la méthode.
• ANWR Group : une plateforme headless B2B/B2C sur SAP Commerce Cloud qui gère plus de 5 millions de SKU, avec une synchronisation des données produit 80 % plus rapide.
• Distrelec : d’une installation SAP Commerce monolithique à une architecture headless, avec un time-to-market réduit de 70 % et un taux de conversion supérieur de 15 %.

Délais réalistes : 6 à 12 mois pour une migration typique, 4 à 6 mois pour un projet accéléré discipliné, 90 jours à l’extrême le plus rapide avec une préparation complète.

Si vous migrez, préparez-vous ainsi. L’essentiel du temps et du budget d’une migration se décide avant que la première ligne de code ne bouge :

1. Passez en revue chaque personnalisation. Classez-la comme toujours nécessaire, remplaçable par une fonction standard ou obsolète. Cache maison, scripts de montée en charge et pipelines de déploiement sont des contournements on-premise typiques que Commerce Cloud gère nativement.
2. Cartographiez chaque intégration. ERP, PIM, CRM, paiement, logistique : c’est là que se cachent les surprises.
3. Analysez vos données tôt. Des années de doublons, de références orphelines et de structures de catalogue incohérentes ne s’améliorent pas avec un déménagement.
4. Faites le ménage avant de migrer. Supprimez les extensions inutilisées, externalisez la configuration codée en dur, décommissionnez les intégrations mortes et purgez les anciennes données de test.
5. Livrez par itérations. D’abord la plateforme de base, puis les storefronts et les marchés un par un, plutôt qu’un seul week-end de bascule big bang.

Nous détaillons ces points dans les cinq erreurs les plus fréquentes lors d’une migration SAP Commerce et dans la checklist pas à pas de migration SAP Hybris.

L’angle de l’ERP Edition. Une objection fréquente des boutiques on-premise de taille moyenne était que la Commerce Cloud complète était dimensionnée et tarifée pour les grands groupes. SAP Commerce Cloud, ERP Edition, annoncée en mai 2026, change ce calcul pour les entreprises sous SAP S/4HANA Public Cloud : une couche de commerce B2B packagée, utilisée via des écrans natifs de l’ERP, SAP prenant en charge une grande partie de l’intégration (DSAG impulsant, en allemand). Spadoom est l’un des premiers partenaires pilotes, avec un client B2B suisse de taille moyenne ; nous décrivons ce que l’ERP Edition change pour les PME ici. Si votre ERP est encore ECC, la décision commerce et la décision ERP vont de pair, et notre évaluation de préparation S/4HANA est la première étape sensée. Le guide Commerce Cloud et S/4HANA Public Cloud en B2B montre comment les deux s’articulent.

Option 4 : quitter SAP par un replatforming

Quitter SAP Commerce est une option légitime et, pour certaines entreprises, la bonne. Si vos besoins se sont simplifiés à ce que Shopify Plus offre en standard, ou si votre stratégie d’architecture est réellement composable et que vous disposez de l’organisation de développement pour l’assumer, un replatforming mérite une véritable évaluation. Notre analyse sur quand le composable commerce a du sens en B2B en passe les critères en revue.

Chiffrez les postes que les présentations de replatforming ont tendance à omettre :

• Reconstruction de l’intégration ERP. Prix, contrôle de disponibilité, contrôle de crédit, orchestration des commandes et données de base sont la partie la plus précieuse et la moins visible de votre plateforme actuelle. Avec un replatforming, vous les reconstruisez, généralement via un middleware qui devient un projet à part entière.
• Profondeur B2B. Prix contractuels, punch-out, workflows d’approbation et structures de comptes à plusieurs niveaux sont matures dans SAP Commerce et souvent des add-ons ou des développements sur mesure ailleurs.
• Le travail sur les données ne diminue pas. Les données de catalogue, de clients et de commandes doivent quand même migrer ; le chantier d’intégration s’y ajoute.
• Délais. Les projets de replatforming pour une installation intégrée à SAP durent généralement de 6 à 12 mois ou plus, la même fenêtre qu’une migration de SAP à SAP, sans rien conserver.

Si vous utilisez SAP ERP et avez de réels besoins B2B, le coût total de possession plaide généralement pour rester dans la pile SAP. Sinon, menez l’évaluation et demandez à chaque éditeur les postes d’intégration, pas seulement des comparaisons de licences.

Les délais comparés

Voie	Délai jusqu’à un état maintenu	Exposition en attendant	Ce que vous avez à la fin
Continuer	Jamais	Croît indéfiniment	La même plateforme, plus ancienne
Maintenance spécifique client comme passerelle	Immédiat, mais couverture réduite	Problèmes connus couverts, nouveaux éventuellement facturés	Un canal de support, aucune feuille de route
Migration vers Commerce Cloud ou ERP Edition	3 à 12 mois	Limitée à la durée du projet	Une plateforme maintenue et évolutive ; investissement conservé
Replatforming hors SAP	6 à 12 mois ou plus	Limitée au projet, généralement plus longue	Une nouvelle plateforme, des intégrations reconstruites, une nouvelle courbe d’apprentissage

Trois voies sur quatre impliquent des mois sur une plateforme qui ne reçoit plus de correctifs. Cette exposition a commencé le 1er août, que vous ayez décidé quelque chose ou non. Ce que vous maîtrisez encore, c’est sa durée.

Ce que nous ferions à votre place

Première semaine : une analyse de risque de deux pages sur l’installation actuelle, couvrant les versions, le périmètre des personnalisations, l’inventaire des intégrations et les obligations de conformité. Premier mois : une décision entre la maintenance spécifique client comme passerelle, la migration et le replatforming, avec de vraies offres sur la table plutôt que des estimations indicatives. L’ordre compte, car la disponibilité des partenaires d’intégration diminue à mesure que les entreprises restées en attente se lancent en même temps. Si vous comparez encore les partenaires, notre aperçu des partenaires SAP Commerce Cloud en Suisse indique ce qu’il faut vérifier.

Nous menons cet assessment sous forme de mandat à périmètre fixe. Le support a pris fin, pas vos options. Elles ont simplement désormais une horloge.

Demandez un assessment de migration, découvrez notre page solution SAP Commerce Cloud ou commencez par la page de décision on-premise.