Au contraire de l’approche « monolithique », qui consiste à déployer une solution unique totalement intégrée pour vendre en ligne, ces architectures « composable » de type MACH (Micro-Services, API, Cloud Native, Headless) permettent d’assembler et d’ajouter au fur et à mesure des solutions « best of breed » dédiées à chaque besoin spécifique. Ce type d’approche peine encore à s’imposer dans les organisations. Le point sur les malentendus ou idées reçues autour de ce nouveau type d’architectures distribuées pour le commerce en ligne.
Le composable commerce est avant tout un concept
Vrai et faux – Derrière le composable commerce se cache le concept MACH, à savoir des architectures e-commerce distribuées, constituées d’éléments technologiques aujourd’hui matures et capables de s’intégrer facilement entre eux. Ce nouvel acronyme signifie :
- Micro-services : architecture dans laquelle chaque composant (chaque « service ») couvre une fonction spécifique « best of breed », techniquement et fonctionnellement bien délimitée, qui peut être déployée individuellement.
- API-first : architecture dans laquelle chaque solution, composant ou service va exposer ses propres API et consommer les API exposées par les autres solutions, composants ou services.
- Cloud-native : architecture où les composants sont nativement pensés pour être déployés dans un cloud (public ou privé).
- Headless : architecture dans laquelle la partie « visible » (le frontend) est totalement découplée des composants qui exposent les services et les données.
MACH s’oppose diamétralement aux approches monolithiques traditionnelles en matière d’e-commerce. Il n’est toutefois pas possible de réduire le composable commerce à un simple concept : pour gagner en agilité et en innovation, à la fois fonctionnelle et technique, il faut définir une stratégie à mettre en œuvre, sélectionner les technologies adaptées au besoin et les interfacer.
Les solutions d’e-commerce sont un marché de renouvellement, sans besoin d’innovation
Faux – Sur l’aspect expérience client (et donc sur le frontend), c’est même tout le contraire : si le marché de l’e-commerce est clairement mature aujourd’hui, l’innovation en matière de proposition de valeur client demeure un élément différenciateur clé sur le marché.
En backoffice (et donc sur le backend), le besoin d’innovation est tout aussi important. En effet, les solutions monolithiques telles qu’existantes peuvent rencontrer des difficultés de scalabilité, tant sur le plan de la réplication des infrastructures que sur les coûts de déploiement et de maintien en conditions opérationnelles que cela représente. Tandis que les besoins d’adhérence entre les plateformes de commerce et de logistique sont indispensables pour répondre aux attentes des clients.
Le composable commerce nécessite une stratégie et une vision claires en amont
Vrai – Dans une approche monolithique, la stratégie est assez simple : les organisations achètent un package de fonctionnalités, souvent beaucoup trop, pour parer à toute éventualité. Outre un surcoût évident, certains besoins peuvent apparaître plus tard, qui ne sont pas forcément couverts par la solution initialement choisie.
Avec l’approche « Lego™ » du composable commerce, à l’inverse, ne sont déployées que les fonctionnalités strictement nécessaires à l’instant T. Les briques complémentaires sont ensuite mises en œuvre de manière itérative, suivant une roadmap adaptée à chaque organisation. Chaque brique fait l’objet d’une facturation à part et est interfacée aux autres au fil de l’évolution des besoins. L’accompagnement par un intégrateur ayant une vision technologique et fonctionnelle claire sera un atout majeur afin de réduire la complexité potentielle et prévenir les risques d’effet « silos ».
La multiplication des fournisseurs cantonne la DSI à un rôle d’acheteur
Faux – Et même au contraire : par définition, le composable commerce permet à chaque organisation de construire précisément la plateforme dont elle a besoin. Dès lors, la roadmap SI est plus que jamais fondamentale, et la DSI (ou la direction digitale) se retrouve au cœur même de la chaîne de valeur à la fois métier et IT.
Dans ce contexte, cantonner la DSI au rôle d’acheteur est une véritable erreur, d’autant plus que cette construction nécessite des compétences spécifiques pour concevoir, intégrer et faire évoluer la plateforme ainsi créée dans le temps : définition de la stratégie et évolution des pratiques, construction de la roadmap technique, mise en œuvre des composants (FinOps, DevSecOps et urbanisation), ingénierie financière (coût d’acquisition, d’intégration et de MCO des briques, ROI), négociation des prix avec les partenaires de l’écosystème, etc.
Dans une approche composable commerce, la DSI joue un rôle central d’accompagnateur auprès de l’ensemble des autres directions, afin d’offrir l’agilité nécessaire à toute l’organisation. L’usage de solutions « best of breed » et « user friendly » permet aux métiers de jouer pleinement leurs rôles et de gagner en autonomie (par exemple, autonomie pour gérer les promotions par le service commercial).
Des solutions multiples alourdissent les coûts et la complexité du SI
Vrai et faux – Packagées et donc globalement moins chères, les fonctionnalités des solutions monolithiques sont rarement toutes utilisées. Celles qui les sont reviennent donc plus chères, unitairement parlant. Avec le composable commerce, c’est l’inverse : les composants peuvent être individuellement plus chers mais les organisations ne déploient que ceux qui sont strictement nécessaires. De la même façon, les coûts d’intégration et de MCO (internes ou externes) de ces briques peuvent être supérieurs : architecture, intégration, cartographie fonctionnelle et technique, etc.
Dès lors, l’ingénierie financière revêt un aspect majeur en matière de composable commerce, au même titre que FinOps pour le cloud. Le rôle des intégrateurs peut être intéressant à ce titre, avec des possibilités plus importantes de négociation avec les éditeurs.
Le composable commerce favorise le pilotage par la donnée
Vrai – Du côté backend, le composable commerce crée un environnement adaptable et en cohérence avec la stratégie globale de l’organisation, qui peut alors multiplier les frontend (pour répondre aux besoins de son marché) sans risquer de « siloter » les données, tout en évitant d’avoir à personnaliser les applications monolithes, voire à effectuer des développements spécifiques autour de ces applications.
Les organisations gagnent ainsi en suivi et observabilité avec un écosystème de composants qui partagent toutes leurs données, en temps réel. Avec pour conséquence, une meilleure performance technique et économique, et surtout une meilleure capacité à identifier les opportunités, les risques et les axes d’amélioration.
Par Damien Pasquinelli, responsable de l’activité Digital Commerce, Hardis Group.