OXID 6 n'est plus un produit courant, c'est une version en cours d'abandon. Dans le plan de releases officiel d'OXID eSales, la série 6 est en statut "legacy" de manière continue depuis 2024 et ne reçoit plus que des corrections importantes sélectionnées, pas de mises à jour de maintenance complètes. La question stratégique n'est donc pas "si", mais "quand" et "dans quel ordre" vous réagissez. Notre réponse : découpler le frontend en premier, faire la mise à niveau du backend séparément ensuite, sans replatforming big-bang.

Que signifie exactement la fin de vie d'OXID 6 ?

OXID ne fonctionne pas avec des dates de fin de vie fixes par version, mais avec un modèle de support glissant : il y a toujours une version de maintenance (qui reçoit la plupart des corrections) et deux versions legacy (qui ne reçoivent que des corrections importantes sélectionnées, typiquement liées à la sécurité et à la conformité). Tout ce qui est plus ancien est considéré comme obsolète et ne reçoit plus tous les patches.

OXID 6.5 est la dernière version mineure de la série 6, il n'y aura pas de 6.6. Dans le plan de releases, 6.5 est en statut legacy pour tous les trimestres de Q2/2024 jusqu'à "TBA". La ligne de maintenance active est désormais la série 7 (7.5 en maintenance au Q2/2026, 7.4 en legacy). En pratique : si vous êtes sur OXID 6, vous faites tourner une version qui ne reçoit que des soins d'urgence et qui sort de plus en plus de la fenêtre de support à chaque nouvelle release de la série 7.

Note sur les dates : OXID communique des statuts (maintenance / legacy / outdated) et des fenêtres trimestrielles, pas de dates de fin de vie précises au jour près par version 6.x. Le tableau ci-dessous reflète ce calendrier de statuts. Vérifiez l'état actuel dans le plan de releases OXID officiel avant de prendre des décisions budgétaires sur cette base.

Le calendrier du cycle de vie OXID 6.x (statuts, pas de dates fixes)

Le calendrier est clair : OXID 6 n'est pas "mort demain", mais c'est une impasse pour tout ce qui nécessite de l'innovation frontend. La performance, l'accessibilité (la loi allemande BFSG sur l'accessibilité est obligatoire depuis le 28 juin 2025), la conversion mobile et l'itération rapide sur les campagnes proviennent d'un core qui ne reçoit que des soins d'urgence.

Le problème que rencontrent la plupart des boutiques OXID actuellement

Chez les opérateurs OXID 6, nous observons presque toujours le même schéma : le frontend n'a pas été touché depuis des années "parce que la mise à niveau de 6 vers 7 est encore devant nous". La mise à niveau est invasive, de nombreuses adaptations doivent être refaites, et elle coûte typiquement 3 à 9 mois d'effort d'implémentation. Alors l'équipe attend, et pendant qu'elle attend, le frontend continue de vieillir.

Cela génère la fausse question du tout ou rien : migrer vers OXID 7 laborieusement, ou replatformer directement vers commercetools / Shopware 6 / Adobe Commerce. Les deux options sont pénibles. La mise à niveau mobilise des mois. Le replatforming abandonne des années d'investissement OXID et coûte typiquement entre le six chiffres et plusieurs millions. Dans les deux cas, le frontend, là où le client achète réellement, ne reçoit rien pendant des mois.

Nous avons décrit ce même schéma pour les opérateurs Magento lorsque la question du patch Magento 2.4.6 s'est transformée en course aux correctifs. La fin de vie d'un vendor déclenche presque toujours le même réflexe, et ce réflexe est presque toujours plus coûteux que nécessaire.

Comment Laioutr résout cela : découpler le frontend, maintenir le backend stable

Vous n'avez pas à porter simultanément la mise à niveau du backend et la modernisation du frontend. Avec la Laioutr Frontend Management Platform (FMP), vous placez un Composable Headless Frontend par-dessus votre backend OXID 6 existant, connecté via l'API OXID. A partir de ce moment, le frontend et le backend sont découplés :

• Vous modernisez le frontend maintenant : Composable Storefront sur Nuxt, Core Web Vitals dès le départ, composants conformes à l'accessibilité par défaut, pages de campagne depuis Studio en quelques heures au lieu de sprints.
• Le backend OXID 6 continue de fonctionner de manière stable, avec le flux de corrections de sécurité et de conformité de la ligne legacy, sans que vous ayez à le toucher pour le travail frontend.
• Vous faites la mise à niveau vers OXID 7 plus tard, séparément. Comme la liaison de données est normalisée via une couche GraphQL (Orchestr), le frontend reste inchangé lors du changement de backend. Vous échangez la connexion, pas le storefront.

C'est le coeur de notre promesse de découplage : chaque backend, un frontend, sans lock-in. L'ordre est frontend-first, pas big-bang. Nous avons décrit en détail ce à quoi cela ressemble techniquement dans OXID 6 vers 7 : découpler le frontend sans replatforming.

Ce que vous gagnez

FAQ

Dois-je faire la mise à niveau immédiatement à cause de la fin de vie d'OXID 6 ? Non, pas immédiatement. OXID 6.5 est legacy, pas éteint, et reçoit encore des corrections sélectives de sécurité et de conformité. La pression est réelle, mais vous pouvez choisir l'ordre : découpler et moderniser le frontend maintenant, faire la mise à niveau du backend comme un projet séparé et planifiable ensuite.

Quel est le coût par rapport au replatforming ? Un découplage frontend avec la FMP est nettement inférieur aux coûts typiques de replatforming (six chiffres à plusieurs millions). Vous trouverez le mappage exact des plans sur notre page de tarification.

Combien de temps prend la connexion du frontend à OXID 6 ? Les migrations avec accompagnement des fondateurs prennent chez nous une médiane de moins de 14 jours. Cela dépend de la complexité de vos données, mais c'est une affaire de semaines, pas de mois.

Pouvons-nous quand même passer à OXID 7 ou une autre plateforme plus tard ? Oui, c'est exactement le but. Le frontend est connecté de manière agnostique au backend. Si vous passez plus tard à OXID 7 ou un autre backend, le storefront reste, vous échangez uniquement la connexion.

Prochaines étapes

Si vous êtes sur OXID 6 et continuez à repousser la mise à niveau 6 vers 7 : passons 20 minutes sur le chemin de découplage que vous pouvez emprunter sans toucher à votre configuration OXID. Les détails du backend sont disponibles sur Headless Frontend pour OXID.

Plus de thèmes depuis la plateforme Laioutr

• Composable Headless Frontend - la couche frontend découplée au-dessus de tout backend commerce
• Composable Visual Page Builder - Studio : pages de campagne en quelques heures au lieu de sprints
• Composable Digital Experience Platform - l'architecture DXP sans lock-in designer
• Agentic Frontend Management Platform - Larry AI et les Frontend Agents sur la couche découplée
• Headless Frontend pour OXID - le chemin de connexion spécifique à OXID

A propos de l'auteur : Marcel Thiesies est Co-Founder de Laioutr. Il accompagne les marchands DACH dans le passage d'une boutique monolithique à un frontend Composable découplé, avec un focus sur le découplage plutôt que le replatforming.