Cet article explique comment repenser l’extensibilité d’Adobe Commerce via Adobe Developer App Builder et remplacer de grandes parties du langage PHP personnalisé par une architecture plus évolutive peut améliorer l’évolutivité, la stabilité et la maintenabilité, pour une croissance à long terme dans un environnement de production réel.

Introduction

Pendant des années, l’extensibilité du PHP a constitué la clé de voûte de la personnalisation d’Adobe Commerce. Mais à mesure que les architectures natives dans le cloud mûrissent, de meilleures alternatives deviennent disponibles. Lors d’une récente mise en œuvre pour un important fournisseur européen de services financiers et de mobilité, nous avons remplacé une partie importante du développement traditionnel de modules Adobe Commerce par App Builder, la plateforme d’extensibilité native au cloud d’Adobe. Pour ce faire, nous avons exploité des actions d’exécution (fonctions sans serveur), des événements et des API afin de fournir une solution davantage évolutive et plus facile à gérer. Cet article détaille les raisons de cette décision, la structure de l’architecture et les enseignements tirés.

Vue d’ensemble

L’approche axée sur les API avec Adobe Commerce peut être adoptée de manière incrémentielle : évaluer les fonctionnalités les plus bénéfiques s’exécutant en tant qu’applications natives dans le cloud en dehors de la plateforme Adobe Commerce principale, puis migrer ces fonctionnalités en priorité.

Ce processus a permis d’obtenir un résultat clair :

• ~70 % des fonctionnalités ont été mises en œuvre à l’aide d’App Builder.

• ~30 % des fonctionnalités sont des personnalisations natives du format PHP Adobe Commerce.

Cet équilibre nous a permis de garder la logique native et liée aux paiements proche de Commerce, tout en déléguant les intégrations, la validation, le traitement en arrière-plan et l’orchestration à App Builder, où l’évolutivité, l’isolation et la flexibilité de déploiement sont optimales.

L’architecture qui en résulte (voir le diagramme ci-dessous, ne décrivant que les extensions d’App Builder) reflète cette approche hybride : Adobe Commerce reste le cœur transactionnel, tandis qu’App Builder agit comme la clé de voûte de l’intégration et de l’automatisation. Cette stratégie connecte l’identité (SSO), le PIM, l’ERP, les services tiers et une logique commerciale personnalisée par le biais de flux pilotés par les événements et le maillage API (le service d’orchestration des API d’Adobe).

Présentation de l’architecture : fonctionnement du modèle hybride

Au cœur de la solution se trouve Adobe Commerce, qui fait ce qu’il fait de mieux : catalogue, tarification, panier, passage en caisse et placement de commande. Nous avons délibérément maintenu la stabilité et la clarté de ce noyau transactionnel pour éviter toute personnalisation inutile dans l’exécution de Commerce.

Tout ce qui entoure ce noyau (identité, validation des données, logique de disponibilité, traitement en arrière-plan et intégrations tierces) est géré via App Builder et le maillage API d’Adobe.

L’expérience d’achat repose sur le nouveau storefront Commerce (optimisé par Edge Delivery Services).

1. Couche d’entrée : CDN, storefront Commerce et identité

Tout le trafic provenant des personnes qui consultent régulièrement le site web arrive d’abord sur le CDN + Edge Delivery Service, ce qui garantit des performances optimales, la sécurité et la diffusion globale avant qu’une requête atteigne les systèmes back-end.

L’authentification est gérée via l’authentification unique (SSO) Keycloak, intégrée via :

• Une intégration SSO d’App Builder

• Un module PHP Adobe Commerce standard du Marketplace pour la configuration de base de l’authentification unique

• Cette configuration nous permet d’associer la stabilité de la plateforme à une flexibilité native au cloud.

Principaux avantages de cette approche

• Gestion centralisée des identités via un module Marketplace éprouvé

  Nous nous appuyons sur une extension Adobe Commerce bien prise en charge pour la configuration de l’authentification unique, le mappage des utilisateurs et utilisatrices, ainsi que les flux d’authentification principaux, ce qui évite de maintenir une logique d’authentification personnalisée dans l’exécution de Commerce.

• Modification minimale, sécurité maximale

  Au lieu de réécrire ou de dupliquer le module SSO, nous n’appliquons que de petites extensions ciblées via App Builder, ce qui permet de conserver un module d’origine pouvant être entièrement mis à niveau.

• Modèle d’intégration axé sur les API

  Comme toute communication repose strictement sur les API SSO, nous sommes découplés des détails d’implémentation interne du module PHP. Même si le module change en interne, notre intégration reste stable tant que le contrat d’API est valable.

2. Couche d’orchestration : maillage API d’Adobe

Au cœur de notre architecture d’intégration se trouve le maillage API d’Adobe, qui agit comme le hub central d’orchestration et de communication entre tous les systèmes d’entreprise impliqués dans la plateforme :

• Storefront Commerce (en tant que front-end)

• Adobe Commerce

• PIM

• ERP

• Services de validation externes

• Et toutes les applications App Builder

Au lieu d’établir des intégrations point à point directes entre le front-end EDS ou Adobe Commerce et chacun de ces systèmes, toutes les communications sont acheminées via le maillage API.

Principaux avantages de l’utilisation du maillage API d’Adobe

• Surface d’intégration unique
  Les systèmes n’ont besoin de « connaître » qu’un seul point d’entrée d’intégration back-end : le « maillage ». Chaque dépendance externe est masquée derrière une passerelle API unifiée.

• Contrats d’API cohérents
  Tous les systèmes communiquent par le biais de contrats bien définis et versionnés, ce qui élimine le couplage masqué et réduit considérablement le risque de modifications néfastes.

• Découplage complet entre les systèmes back-end
  Le PIM, l’ERP, les services de validation et les applications App Builder sont totalement isolés les uns des autres. Tout système peut évoluer de manière indépendante sans imposer de changements dans l’ensemble du paysage.

• Sécurité et gouvernance centralisées
  L’authentification, l’autorisation et le contrôle du trafic sont appliqués au niveau du maillage et ne sont pas éparpillés sur plusieurs intégrations personnalisées.

• Base de code Commerce simplifiée
  Adobe Commerce ou le front-end ne contiennent plus de logique d’intégration complexe. Ils utilisent simplement les API exposées par le maillage, ce qui permet de garder la couche PHP légère et orientée transactions.

3. Services App Builder utilisés par le storefront et la couche SSO

Ces services sont directement consommés par le storefront Commerce et la couche SSO, et non par Adobe Commerce, ce qui permet à la logique commerciale critique de fonctionner indépendamment de l’environnement d’exécution de Commerce.

Récepteur de données clientèle (SSO → App Builder)

Ce service reçoit et synchronise les données clientèle de la couche SSO sans affecter les performances du storefront ou de Commerce. L’utilisation d’App Builder garantit un traitement sécurisé, une évolutivité asynchrone et une dépendance nulle vis-à-vis d’Adobe Commerce.

Disponibilité du produit par clientèle (Storefront → App Builder → PIM)

La disponibilité des produits est résolue en temps réel en fonction du contexte clientèle et des données PIM avant que les requêtes n’atteignent Commerce. App Builder permet à cette logique de se mettre à l’échelle indépendamment et protège Commerce d’une charge de dépendance externe élevée.

Validation des données d’entreprise (Dun & Bradstreet) (Storefront → App Builder → Tiers)

La validation est déclenchée directement à partir du storefront via App Builder + maillage API, puis vérifiée à l’aide de services tiers, ce qui isole complètement Adobe Commerce des latences et des échecs de service externe.

Moteur de redirection d’ID externe (Storefront → App Builder)

Le trafic entrant en provenance de systèmes externes est traité et mappé via App Builder avant d’entrer dans le storefront, ce qui permet une normalisation du trafic sûre, des règles de redirection flexibles et un risque nul pour le cœur de Commerce.

4. Pré-rendu du storefront Commerce : le SEO qui ne compromet pas l’expérience d’utilisation.

Le storefront d’AEM Commerce est une application moderne, pilotée par l’interface. En outre, elle repose principalement sur JavaScript pour charger les données des produits dans le navigateur. Bien que cette caractéristique offre une excellente expérience d’utilisation, elle pose aussi un défi classique aux SPA :

Les robots d’indexation des moteurs de recherche et les systèmes sans navigateur reçoivent souvent du HTML presque vide, car ils n’exécutent pas JavaScript de manière fiable.

Pour relever ce défi, nous avons mis en œuvre le pré-rendu AEM Commerce, une solution Adobe officielle reposant sur App Builder.

Fonctionnement du pré-rendu dans notre architecture

L’application de pré-rendu App Builder :

• Lit les données de produit directement à partir du service de catalogue Adobe Commerce.

• Génère des pages HTML complètes à partir de modèles prédéfinis.

• Stocke la sortie pré-rendue dans son propre stockage Blob.

Le storefront Commerce est ensuite configuré pour utiliser ce stockage en tant que source de superposition. Lorsque l’un des cas suivants se produit :

• Un robot d’indexation de moteur de recherche

• Ou tout client sans navigateur demande une URL de produit

Il reçoit immédiatement une réponse HTML entièrement générée avec des données de produit réelles, sans exécuter de JavaScript.

Au même moment :

• Les utilisateurs et utilisatrices réguliers bénéficient toujours de l’expérience SPA standard, avec un rendu PDP en direct dans le navigateur.

Pourquoi App Builder est-il le principal activateur ici ?

App Builder est le plan de contrôle central de l’ensemble du processus de pré-rendu. Il permet de définir :

• La fréquence de récupération des données

• Les produits et paramètres régionaux inclus

• La structure HTML et JSON-LD

• La génération de métadonnées SEO

Tout cela peut être ajusté par de petites modifications de la configuration d’App Builder, sans temps d’arrêt pour le storefront principal ou Adobe Commerce.

Adobe fournit également un kit de démarrage pour le pré-rendu de l’application App Builder, afin de préparer la solution en production dans un délai très court et d’obtenir une amélioration immédiate du SEO.

Avantages clés de cette approche

• Amélioration massive du SEO
  Les robots d’indexation reçoivent des pages de produits entièrement rendues avec des données structurées au lieu de HTML vide.

• Aucun impact sur les performances du storefront
  Les utilisateurs et utilisatrices réguliers conservent une expérience rapide et dynamique des SPA.

• Modèle de déploiement à risque nul
  Toute logique de rendu automatique s’exécute en dehors d’Adobe Commerce et de l’exécution du storefront.

• Contrôle total via App Builder
  Les règles de pré-rendu, les modèles de données et les plannings peuvent être ajustés sans redéploiement de la plateforme.

5. Synchronisation des commandes et de l’ERP : une conception asynchrone

Le passage en caisse et le placement des commandes restent entièrement gérés dans Adobe Commerce, ce qui préserve l’intégrité des données et la cohérence transactionnelle. Une fois une commande créée, le processus d’exportation est pris en charge par un exportateur de commandes planifiées dédié basé sur App Builder.

Cet exportateur synchronise les commandes vers l’ERP de manière asynchrone, en dehors du cycle de vie des demandes du storefront et de Commerce.

Avantages clés de cette approche

• La disponibilité du storefront est totalement découplée de la disponibilité de l’ERP
  Même si l’ERP est lent ou temporairement indisponible, la clientèle peut continuer à passer des commandes sans interruption.

• Pas de blocage des passages en caisse en raison d’échecs en aval
  La création des commandes ne dépend plus des réponses de l’ERP en temps réel, ce qui élimine une source majeure de risque de conversion.

• Reprises sécurisées et flux de données contrôlé
  App Builder permet l’exécution planifiée, des mécanismes de reprise et la gestion des échecs sans affecter les performances de Commerce.

• Mise à l’échelle et déploiement indépendants
  La synchronisation des commandes peut être mise à l’échelle en fonction du volume sans nécessiter de redéploiement ni avoir d’incidence sur les performances d’Adobe Commerce.

Pourquoi ne pas passer complètement à App Builder ?

L’une des premières décisions architecturales incontournables a été de ne pas considérer App Builder comme un remplaçant total des modules PHP et de ne pas tout configurer par défaut sur le langage PHP, juste « parce qu’on a toujours fait comme ça ».

Au lieu de cela, chaque exigence est passée par un filtre simple :

Qu’a-t-on laissé au format PHP ? (Les 30 %)

Nous avons gardé les personnalisations PHP uniquement là où elles ont vraiment leur place :

• Réglages du passage en caisse et du placement de la commande

• Logique de tarification, de panier et de devis

• GraphQL avancé et hooks sensibles à la performance

• Zones où la latence doit être proche de zéro et entièrement synchrone.

En somme, les endroits où l’accès direct aux bases de données, le couplage étroit aux éléments internes de Commerce et le contrôle du cycle de vie des demandes sont toujours absolument justifiés.

Qu’a-t-on déplacé vers App Builder ? (les 70 %)

Tout le reste a été déplacé :

• Orchestration des identités et du SSO

• Validation de la clientèle et des entreprises

• Résolution de la disponibilité des produits

• Coordination du système externe

• Intégrations ERP et tierces

• Moteurs de redirection et automatisation

• Traitements et planificateurs en arrière-plan

En somme, tous sont des domaines dans lesquels les modules PHP rencontrent historiquement des difficultés :

• dépendance forte

• déploiements complexes

• mauvaise isolation des pannes

• et évolutivité limitée

Principaux avantages obtenus

En transférant environ 70 % de la logique commerciale et d’intégration à App Builder, nous avons fondamentalement changé la manière dont la plateforme est créée, déployée et exploitée. L’impact est visible non seulement en termes de qualité de l’architecture, mais également de vitesse de diffusion, de stabilité du système et de contrôle des coûts à long terme.

Déploiements indépendants

App Builder gérant la plupart des intégrations et des workflows métier, la majorité des modifications ne nécessitent plus le redéploiement complet d’Adobe Commerce. Les mises à jour d’intégration, les validations et les processus en arrière-plan peuvent être déployés indépendamment, ce qui réduit considérablement :

• le risque lié aux versions multiples

• les fenêtres de déploiement

• les frais généraux de coordination entre les équipes

Ce seul facteur est devenu l’un des plus grands gains de productivité dans les opérations quotidiennes.

Une meilleure évolutivité, là où cela compte le plus.

Auparavant, les pics de trafic se produisaient dans les domaines suivants :

• contrôles de disponibilité

• validation d’entreprise

• ou appels API externes

et avaient un impact direct sur les performances de Commerce.

Désormais, ces charges de travail évoluent indépendamment dans App Builder. Par conséquent :

• Les performances de passage en caisse restent stables.

• Les ressources Commerce sont réservées aux charges de travail transactionnelles uniquement.

• Le trafic tiers imprévisible ne menace plus les taux de conversion.

Une véritable isolation des pannes

L’une des améliorations les plus importantes est le confinement des pannes. Lorsque des systèmes tiers sont confrontés à une latence, une dégradation ou des pannes :

• App Builder absorbe l’impact.

• La logique de reprise et de secours est appliquée.

• Adobe Commerce reste entièrement opérationnel.

Ainsi, toute une catégorie de scénarios d’incidents qui entraînaient des temps d’arrêt partiels ou complets du storefront ont été éliminés.

Une propriété du code épurée et des responsabilités claires

La plateforme a désormais des limites architecturales claires :

• Adobe Commerce → Logique transactionnelle, passage en caisse, tarification, panier

• App Builder → Intégrations, orchestration, validation, traitements en arrière-plan

Cette séparation :

• Simplifie l’intégration des nouveaux développeurs et développeuses.

• Réduit les dépendances entre les équipes.

• Empêche l’érosion progressive du cœur d’Adobe Commerce par un code personnalisé lourd en termes d’intégration.

Conçu pour durer

Cette architecture hybride SaaS axée sur les API composable est entièrement alignée sur la stratégie commerciale à long terme d’Adobe. En externalisant la plupart des logiques personnalisées :

• Les mises à niveau de la plateforme deviennent plus sûres.

• L’enfermement propriétaire au niveau du code est réduit.

• La solution est déjà prête pour une migration vers Adobe Commerce as a Cloud Service.

Nous n’avons pas seulement résolu les exigences d’aujourd’hui : nous avons également créé une plateforme structurellement prête à répondre à ce qu’Adobe Commerce est en train de devenir.