Découvrez bourseinside.fr, le 1er site dédié aux entreprises cotées !

Recherche
Magazine E-commerce
S'abonner à la newsletter S'abonner au magazine

Contraintes et enjeux techniques de l’aventure Headless Commerce

Publié par le | Mis à jour le

L’indépendance très recherchée entre Frontend et Backend offerte par l’architecture Headless ou Composable nécessite en amont une grande phase de préparation et d’analyse afin de maîtriser l’intégralité des contours technologiques mais aussi organisationnels.

  • Imprimer

L’approche “Headless Commerce” ou “Composable Commerce” désigne une architecture permettant le découplage des deux grands blocs Frontend et Backend qui, dans cette nouvelle configuration, peuvent évoluer librement et indépendamment, cela sans jamais s’affecter l’un l’autre ! Une petite révolution sur le papier mais qui, au vu de la complexité potentielle des architectures et de la multiplicité des implications, peut ne pas convenir à tous. Il est donc vivement conseillé, avant de s’y engager, de faire son "due diligence" et de se poser les bonnes questions : Quelle(s) technologies adopter pour les frontaux et backends ? Quels éléments développer en interne ? Il faudra identifier la bonne organisation pour maintenir et faire évoluer cette architecture. Quelles compétences sont nécessaires pour le build et le run ? Quels partenaires ? Et, enfin, quelle courbe d'apprentissage pour les utilisateurs métier ? Dans les faits, pour parvenir à être complètement séparée, dissociée et autonome de la plateforme d'e-commerce, et de toute autre application back-end, une boutique de commerce headless doit réunir deux ingrédients principaux : une expérience client maîtrisée au sein de la boutique en ligne et un hébergement solide.

 

Deux conditions : une expérience client maîtrisée…

En termes d’expérience client, certaines technologies et approches paraissent indispensables pour tirer pleinement parti du headless : le Single-Page App (SPA) par exemple, qui est une application développée à base de composants dynamiques qui réagissent et se rafraîchissent très rapidement selon les interactions des utilisateurs et du chargement des données. Une SPA favorise également la performance puisque l'application est exécutée sur le navigateur et réduit grandement les échanges avec le back-end e-commerce. Ensuite, le Server-Side Rendering (SSR) favorise de son côté la performance en calculant le rendu initial des pages lors de la 1ère connexion à l’application. Il est indispensable pour assurer le bon référencement du site (SEO). Enfin, les Progressive Web App (PWA) sont des applications web auxquelles s’ajoutent des fonctions facilitant la responsivité et les usages en mobilité (smartphones, tablettes).

 

… et un hébergement à toutes épreuves.

En ce qui concerne l'hébergement du Frontend, les enjeux sont nombreux. Tout d’abord la disponibilité qui doit être à la hauteur des attentes du e-commerce (99,99%). La performance, à savoir la scalabilité, les temps de réponse, la latence et la couverture géographique étendue. La sécurité, incluant une protection contre les attaques, la sécurisation des accès, la conformité avec les normes et les réglementations en vigueur (PCI, RGPD, etc.) et le disaster recovery. Les mises à jour avec un déploiement des patches sur les différentes librairies et composants de l'infrastructure. Le DevOps avec une gestion multi-environnements, le déploiement, le testing, CI/CD, etc. La Gestion opérationnelle  monitoring 24x7, gestion des incidents, etc. Un moyen de répondre à tout cela est de s'équiper de multiples solutions : caching applicatif, CDN, WAF, conformité PCI, service de support et maintenance. A noter que même s’il est possible de souscrire à ces services auprès de différents prestataires, il faudra les intégrer avec les technologies front-end et donc s'équiper des compétences correspondantes (réseau, sécurité, devops, etc) en interne et/ou auprès d'un intégrateur. L'investigation et la résolution de problèmes est également plus compliquée car la responsabilité est répartie sur de multiples prestataires, ce qui nécessite d'identifier précisément le(s) "coupable(s)".

 

L’approche hybride : une solution temporaire ou définitive

Il est important de préciser que des approches hybrides sont possibles et moins complexes à mettre en place, tout en préservant l’efficacité commerciale. Elles consistent à développer une partie du site en headless SPA et une autre partie avec des pages classiques générées par le back-end e-commerce. Ce sont souvent le panier et le checkout, voire le compte client, qui sont générées par le back-end, étant donné leur complexité et le besoin de sécurisation par rapport aux autres pages du site. Le fait d'exploiter des pages panier et checkout éprouvées et fournies par une plateforme e-commerce permet de sécuriser et d'accélérer un déploiement headless. Certaines enseignes adoptent cette approche hybride de manière permanente, tandis que d'autres l'utilisent pour migrer progressivement un site classique vers un site headless. Ces migrations progressives commencent souvent par les pages plus simples (home, contenus), continuent vers les pages plus complexes (page liste, page produit), pour finir par le panier et checkout.

 

Trois profils clés pour un bon déroulement

Au-delà des profils classiques architecte, développeur back, développeur front, les projets headless nécessitent de nouvelles compétences parmi lesquelles on retrouve trois profils. Tout d’abord, l’ingénieur sécurité (Security Engineer) qui est responsable de la protection du réseau et des applications contre les utilisateurs malveillants. Il supervise également les tests liés à la sécurité (pentesting ou analyses de vulnérabilité du code source) et  participe aux enquêtes traitant d’incidents potentiellement liés à la sécurité. Vient ensuite l’ingénieur en qualité opérationnelle (Site Reliability Engineer), responsable, lui, du bon fonctionnement et des performances globales du stack applicatif. Il fournit également un support lors d'incidents de production et construit les systèmes permettant de surveiller et maintenir la fiabilité et les performances de l'applicatif. Et, enfin, l’ingénieur en exploitation réseau (Network Operations Engineer) qui possède l’expertise des systèmes et des réseaux. sera impliqué dans la conception et la maintenance des systèmes d'exploitation et de la configuration des middleware, le déploiement des correctifs sur les applicatifs et systèmes, et la maintenance ou dépannage des problèmes survenant sur le réseau. Ces profils peuvent donc faire partie des équipes internes ou appartenir à l’équipe projet du partenaire éditeur ou intégrateur de l’entreprise.