Celui-ci est d’ailleurs disponible en open source, même s' il est nécessaire de disposer d’une boutique shopify payante pour pouvoir l’utiliser….
L’objectif de l’article d'aujourd'hui est de faire le point, en cette fin d’année 2024, sur la plateforme Magento afin de répondre à la question : Est-ce que l’on peut faire du eCommerce headless en open source aujourd’hui ?
.webp)
Rappelons d’abord, pour ceux qui ne le savent pas encore, que Magento (dans sa version 2) est une solution de référence dans le monde de l’eCommerce éprouvée depuis plus de 15 ans. Elle existe en open-source (CE Community Edition) et en version Enterprise (Adobe commerce maintenu par… Adobe).
Solution hyper malléable et très puissante fonctionnellement, elle peut répondre à tous les besoins eCommerce même le headless. Nous nous intéressons ici à la solution Community Edition.
Une application “headless” (sans tête) est une solution fonctionnelle découpée en 2 applications TECHNIQUES distinctes. Pour faire simple, une première application technique avec des web services généralement GraphQL, en lieu et place d’une interface graphique. Ces Web Services peuvent être consommés par une seconde application, qui permettent de mettre en forme le “front” l’interface utilisateur. Cela veut donc dire 2 codes sources différents à maintenir et tout ce qui va avec. A première vue, on se dit pourquoi une telle complexité ? Eh bien simplement pour 3 raisons majeurs:
Dans la presse technique, on parle de FaaS (Frontend As A Service).
Vous avez les idées claires ? Eh bien c’est parti pour un petit tour des solutions headless open-sources compatibles avec Magento en cette fin d’année 2024
Créée en 2017, cette solution headless open-source a été à l’origine spécifiquement pensée pour Magento. Se basant sur une stack Nuxtjs/Vuejs elle permet d’avoir un développement front plus efficace et plus performant.
Cette solution constituait une bonne opportunité mais la solution a été rachetée 2023, et, sous le nom Alokai elle n’existe désormais plus qu’en version commerciale…
La version officielle bénéficie de l’intégration dans la MACH Alliance pour faciliter la connexion avec différentes applications (SAP, Salesforce, Algolia, Content-full, Stripe…). La solution Open Source n’est par contre plus maintenue ce qui la rend désormais difficile a envisager : Version de NodeJs déprécié (Node 16), plus de 200 failles de sécurité dont une dizaine critiques et une cinquantaine majeures… En open source, elle est donc à éviter. Je vous rassure, la version Enterprise est bien maintenue (logo troll à mettre)
Créée en 2021, cette solution headless open-source a été créée spécifiquement pour Magento. Elle se base aussi sur une technologie qui se base sur Nuxtjs/VueJs.
Cette technologie existe en différents modes :
A date, la solution ne nous semble pas à conseiller de par le manque de visibilité sur son bon fonctionnement.
PWA Studio est une solution headless open-source directement maintenue par Adobe, l’éditeur de Magento. Elle se base sur une stack ReactJs. Attention, la version de React est ici une version customisée par Adobe…
Cette technologie est maintenue en termes de patch de sécurité et de montée de version magento mais malheureusement, certaines fonctionnalités de Magento ne sont pas implémentées côté Front.
Le site Adobe Commerce présente la couverture fonctionnelle de l’implémentation Venia (Thème de base de PWA Studio)
Certaines fonctionnalités “standards” d’Adobe ne sont pas encore totalement couverte côté front : Bundle & grouped product, product with custom option, reorder, review, third party payment,...Pour ces fonctionnalités 100% de l’UX/UI est a développer en s’appuyant sur les API GraphQL disponibles.
Ainsi, si vous souhaitez vraiment présenter un produit bundle en PWA, c’est à vous de l’implémenter.
Cela veut dire qu’il vous faut:
Donc la charge d’intégration pour une fonctionnalité comme la gestion des bundles est conséquente. Et c’est la même chose pour les autres fonctionnalités non couvertes.
A date, c’est la seule solution headless open-source maintenue pour Magento mais comme vous le constater elle est incomplète graphiquement.
La nécessité de devoir développer une bonne partie du front nécessaire pour la mise en œuvre de la solution e commerce n’est pas le seul souci d’un projet magento headless !
.jpg)
Une des richesses de Magento est son écosystème de modules développés par des éditeurs tiers. Dans le cadre d’un projet Headless avec Magento, il y a une très grosse cure d’amaigrissement dans cet écosystème.
Chez Zento, on estime que seulement 15 à 20 % des modules ayant un impact sur le front sont compatibles avec un fonctionnement headless. Quand on dit compatible, cela signifie qu’il y a tout au plus des web services consommables.
Dans certains cas, des éditeurs publient des modules add-on PWA qui portent sur Venia les fonctionnalités de leur module. A titre d’exemple le module RMA (gestion des retours) d’Amasty dispose d’un add-on PWA qui doit être acheté en complément du module standard et qui alourdit le coût récurrent des modules complémentaires.
Dans le cas où la portabilité PWA n’est pas prise en charge par l’éditeur du module, l’implémentation est à faire de manière spécifique…avec les problèmes associés. Nous pouvons illustrer le sujet avec le cas des PSP.
Initialement, la phase de paiement suit un protocole de sécurité entre le back office Magento et le PSP. Cela est implémenté par le module fourni par le PSP et classiquement l’implémentation suit l’un des 2 fonctionnement suivants :
En headless, le front dissocié change tout car le front ne peut pas disposer des éléments de sécurité nécessaires pour la communication avec les API du PSP. Ce souci de sécurité ne peut être résolu qu’en utilisant des API spécifiques fournies par le module PSP pour permettre cette communication (encapsulation de la sécurité par le back office Magento).
Par ailleurs, le PSP doit aussi fournir des web components intégrables sur le front.
Ce type d’intégration, s' il est toujours possible techniquement, implique de mettre en place des solutions “custom” et/ou pas forcément supportées par le PSP et donc pouvant poser des soucis de sécurité et de maintenabilité (montée de version).
Dans tous les cas, cela limite considérablement le choix du PSP pour un client puisque les seuls PSP qui proposent cette implémentation sont ceux édités par Magento (Braintree, Adobe Payment) et Adyen.
En l’état, et même si l’approche headless prend tout son sens dans des contextes de sites web multimarques (comme le montre notre mise en place avec la solution Wordpress), la mise en place d’une solution headless avec Magento Community pose question.
Si cette mise en place n’est pas impossible, elle est à la fois risquée, complexe et pose des questions de pérennité et de coûts.
En alternative, l’approche Zento est plutôt de s’orienter sur une mise en œuvre “classique” (Qui dit classique, ne veut pas dire vieux) sur la base, notamment du template Hyvä.
N’hésitez pas à contacter nos experts pour en savoir plus sur ces questions.
.webp)
Découvrez l'actu tech et digitale de la semaine : investissements d'Amazon dans Anthropic, Black Friday, chi
Un aperçu des points intéressants de la tech et du digital que nous avons vu cette semaine.
Les utilisateurs jugent un site en quelques secondes : un design de qualité capte leur attention...
