Dans un précédent article, nous avons listé l’essentiel pour utiliser Adobe App Builder.
Depuis, Adobe a annoncé 2 nouvelles offres : Adobe Commerce Optimizer (ACO) et Adobe Commerce as a Cloud Service (ACCS). Toutes deux s’appuient très fortement sur les possibilités de l’App Builder.
Je ne ferai pas de différence entre ACO et ACCS, car Adobe Commerce Optimizer part du principe que vous avez un Adobe Commerce disponible quelque part.
ACCS intègre Adobe Commerce et ACO : les préceptes de base sont donc les mêmes.
Comment fonctionne l’intégration d’Adobe Commerce Optimizer (ACO) ?
Adobe Commerce as a Cloud Service n’est autre que Magento dans sa version SaaS. L’expression “Think outside of the box” est donc à appliquer à Adobe Commerce maintenant.
Intégration App Builder dans une architecture Adobe Commerce
Il est nécessaire de reprendre la manière d’imaginer l’extensibilité d’Adobe Commerce.
Dans notre article “Étendre Adobe Commerce avec App Builder”, nous avons vu que la surcharge se passe hors d’Adobe Commerce, dans Adobe Commerce Optimizer. On s’appuie sur les I/O Events qui permettent de faire une remontée des évènements vers l’App Builder et d’effectuer les surcharges nécessaires.
C’est la direction que prend Adobe Commerce : il est essentiel, pour assurer une migration fluide des plateformes actuelles, de migrer progressivement vers Adobe Commerce Optimizer sur les nouvelles features. Les modules de la communauté migrent également petit à petit vers des applications App Builder. On y retrouve les PSP les plus communs ainsi que des gestionnaires de méthodes de livraison. De plus, l’affichage s’appuie dans les représentations les plus complètes des outils Adobe sur Adobe Commerce StoreFront.
StoreFront repose sur Adobe EdgeDelivery, qui se veut être une optimisation du front Magento. Je n’irais pas jusque-là personnellement, il est tout à fait possible d’avoir son propre front headless. Cependant, soyons conscient que la force de StoreFront est d’effectuer la connexion aux différentes API et la retranscription dans un front optimisé pour l’E-Commerce. Mais rien ne nous empêche de créer cette brique nous-même (je suis même personnellement de cette école).
Quelles sont les intégrations possibles ?
Étendre le back office avec de nouvelles sections et fonctionnalités
Cela passe par une extension de type UI et par son chargement dans le back-office (BO).
Il faut alors activer l’utilisation des extensions directement dans le menu Stores > Settings > Configuration > Adobe Services > Admin UI SDK. De là, il faut s’appuyer sur les outils à disposition dans l’App Builder pour l’affichage, le calcul et le stockage. On obtient ainsi une extension du BackOffice via des composants React.
Les fichiers de configuration xml : c’est terminé. L’enregistrement de la configuration se fait côté App Builder soit par fichier soit dans la Base de données à disposition.
Structure des fichiers pour une extension simple
- index.js permet de positionner le nouvel écran dans le menu du BO
- config.jsx permet de gérer la page React (ici une configuration)
- les fichiers dans data/ contiennent les méthodes de l’App Builder pour la gestion de la configuration
Modifier le panier
La manipulation que l’on vient de voir peut aussi s’appliquer au panier. Ajouter une information, créer un affichage dédié, modifier le prix…tout est possible puisque nous avons accès aux API d’Adobe Commerce.
Structure des fichiers pour une application de calcul de prix personnalisés
Prenons par exemple un calcul dynamique de prix basé sur des règles de gestion spécifiques pour le client. Il n’est pas nécessaire de faire plus complexe qu’un fichier pour cette typologie de prix. De ce fait, nous pouvons retrouver le prix personnalisé dans le panier.
Le système peut se complexifier avec un stockage de prix déporté pour des notions de B2B très spécifiques par exemple. L’idée est d’avoir une base de travail et l’extensibilité nécessaire pour faire évoluer ce système de prix dynamique à notre guise (ajout de mercurial, prix négociés, prix planchers, etc.)
L’exemple ci-dessous est une proposition d’architecture pour une gestion plus évoluée de remise dans le panier, qu’il ne serait pas possible de faire directement dans le back-office.
Structure de fichiers pour une extension complexe
Toutes ces actions sont ensuite appelables depuis l’implémentation du front en place, que ce soit via StoreFront ou pas.
La roadmap d’Adobe Commerce
La feuille de route d’Adobe Commerce confirme qu’il y aura toujours le support pour la version actuelle, comme détaillé dans leur politique de cycle de vie des logiciels.
Attention : il ne faut pas se reposer sur nos lauriers ! À l’allure où s’enchaînent les projets, il est important d’anticiper la bascule vers ACCS dès maintenant !
La vraie priorité n’est pas tant la feuille de route d’Adobe, mais plutôt d’adopter de nouvelles méthodes d’implémentation. Je suggère donc de commencer à migrer vers l’App Builder avec une première application simple. Familiarisez-vous avec les processus de déploiement, l’intégration dans vos workflows de développement et la mise en place de l’environnement de développement local. Évitez les projets complexes et les complexités inutiles. Cette partie s’étalera sur plusieurs mois de l’année 2026.
La prochaine étape est la migration des fonctionnalités existantes sur l’App Builder. Celles qui nécessitent une refonte fonctionnelle pour suivre les évolutions du marché sont de très bonnes candidates pour cette exercice
Vers la fin d’année 2026, voire en début 2027, vous pourrez alors commencer à monter en puissance, en apprenant, en itérant sur la technologie et en explorant ses limites. Cette phase initiale vous permettra d’acquérir les connaissances et l’expérience nécessaires pour répondre efficacement aux besoins futurs.
De ce fait, en 2028, si le support se termine réellement, vos projets auront été migrés au fur et à mesure. De plus, si Magento n’est plus la solution préférée des clients, la logique métier que vous aurez déportée sur ACO restera généralement pertinente et pourra resservir pour d’autres projets E-Commerce.
Services intégrés dans l’offre Adobe Commerce Optimizer
N’oubliez pas que l’App Builder (comme tout service dans l’offre ACO) est le plus pertinent avec un Adobe Commerce comme back-end surtout avec I/O Events et qu’il peut en réalité s’interfacer avec n’importe quel back-end E-Commerce.
En conclusion : que retenir ?
Avec l’annonce d’Adobe Commerce Optimizer ou d’Adobe Commerce as a Cloud Service, beaucoup de craintes autour de la possibilité d’étendre Magento ont été levées. Soyons honnête, cela nous demande de sortir de notre zone de confort, d’autant plus que Magento 2.0 est sorti il y a presque 10 ans et que l’on a nos habitudes de développement, d’estimation, de gestion d’impact et de tout ce qui fait notre métier. Ce changement majeur bouscule mais est une évolution nécessaire pour le marché et pour l’outil.
Malgré ses petites imperfections, il est important de commencer à aller dessus, d’essayer, de créer des modules, de sortir de Magento ce qui n’a rien à y faire, puis de basculer tous les updates vers les services cloud.
Il n’est pas nécessaire d’avoir souscrit aux offres ACO ou ACCS pour commencer à les utiliser. La plupart des Adobe Commerce Cloud intègre AppBuilder et API Mesh.
Vous souhaitez aller plus loin sur le sujet d’Adobe Commerce as a Cloud Service ?
Discutons-en ! 👇