Comment concevoir l’architecture d’une plateforme omnicanale qui génère un milliard d’euros de chiffre d’affaires ?

Executive summary

· Les choix de stratégie technologique sont critiques pour concevoir la bonne plateforme — ils permettront de faire évoluer celle-ci régulièrement en s’appuyant en particulier sur les caractéristiques du cloud moderne.

· Les pratiques d’architecture continue sont critiques à l’alignement constant de la construction d’une plateforme à ses enjeux de croissance — au-delà des principes, une organisation adéquate, adaptée à l’organisation de votre delivery, est nécessaire.

· La mise en place du socle technique en début de construction ou refonte est primordial — le temps que vous prendrez à le faire correctement seras rapidement récompensé.

· Les pratiques DevOps et l’observabilité sont vos meilleurs alliés dans la l’amélioration continue de la scalabilité d’une plateforme, en particulier en vous permettant d’identifier les goulots d’étranglement éventuels et de les adresser.

· Les processus qualité et de capacity management sont nécessaires pour une approche empirique des tests de charge, ils vous permettront de valider en amont la capacité à monter en charge de votre plateforme.

· La combinaison de ces pratiques (architecture, pratiques d’engineering, construction de votre infrastructure et modèle devops, industrialisation des tests) vous permettra via une approche pratique de continuer à ‘scaler’ votre plateforme.

Chez Publicis Sapient nous accompagnons depuis plus de 30 ans les grandes organisations dans leur transformation digitale et tout particulièrement dans la grande distribution.
Ainsi, nous avons collaboré avec des organisations aussi prestigieuses que Walmart, Target, Albertsons, ASDA ou TESCO.

En France, nous avons notamment été le partenaire de Carrefour avec qui nous avons pu collaborer étroitement entre 2017 et 2020 pour redévelopper leur plateforme omnicanale : ( Business Transformation at Carrefour) et depuis 2020 nous sommes le partenaire de SONEPAR, le leader Mondial de la distribution électrique B2B (Jérémie Profeta, Chief Digital Enterprise Officer de Sonepar, salue le partenariat noué avec Publicis Sapient) avec qui nous développons une plateforme omnicanale cloud native pour les filiales du groupe.

Nous vous proposons ici quelques éléments de réflexion sur comment nous avons défini et implémenté l’architecture de plateformes cloud native omnicanales qui ont pu supporter une croissance significative.

De l’importance des choix de stratégie technologique

Le choix d’une architecture cloud peut paraitre à la fois une évidence (qui construirait aujourd’hui une plateforme sur du ‘on premises’ en 2023!? ) mais son importance est stratégique. D’abord une architecture cloud doit être cohérente et éviter toute forme de dépendance sur une brique technique ‘ancienne’.
La raison est d’abord que le scaling horizontal sur une architecture cloud est réalisable seulement si tous les composants sont scalables indépendamment les uns des autres. Cette règle, qui peut sembler triviale, est primordiale… sinon on risque d’identifier en chemin un bottleneck (goulot d’étranglement technique) qui ne pourra être adressé que d’une seule manière … par le remplacement du composant incriminé.
Or sur une plateforme à l’échelle, cela peut devenir compliqué, couteux et surtout avec un fort impact client (data migration, rupture de disponibilité de la plateforme).

Cela dit, une nouvelle plateforme e-commerce / omnicanale ne peut s’affranchir de l’intégration aux données backend. Notre recommandation d’approche dans le cadre d’une intégration avec un écosystème IT / back office existant est d’intégrer la nouvelle plateforme via des patterns asynchrones pour s’affranchir de dépendances en termes de qualité logicielle (performance, scalabilité, disponibilité). Cela peut passer par des mécanismes de réplication de données lorsque c’est nécessaire, même sur des volumes importants via des mécanismes évènementiels ou de synchronisation inter cloud ou on-premises vers le cloud (ce qui peut se faire, par exemple, avec une base de données comme Cassandra).

Comment les pratiques d’architecture continue sont critiques à l’alignement constant de la construction d’une plateforme à ses enjeux de croissance

En 2023 l’architecture, en termes de pratiques et d’objectifs, n’est pas si différente de ce qu’elle était en 2003 : anticiper le futur en s’assurant de la mise en œuvre caractéristiques de qualité des logiciels (maintenabilité, performance, scalabilité, haute disponibilité, design for failure, ZeroTrust, etc). Mais avec l’émergence des pratiques agiles, en particulier à l’échelle (SAFE), cette pratique a dû s’aligner au rythme et ‘continuum’ de cette agilité.

Chez Publicis Sapient nous nous inspirons beaucoup des concepts avancés par Murat Erder et Pierre Pureur dans leur ouvrage de référence : Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World (2015) dans lesquels les auteurs décrivent les principes de l’architecture continue dont l’enjeu majeur est de réduire l’écart entre le développement et la vision globale et stratégique de l’architecture.

¹ Ceci dit c’est un peu plus compliqué que cela — certaines organisations repartant sur du On Premises pour des considérations de couts d’exploitation Cloud.

Nous recommandons donc aux entreprises souhaitant réussir à construire une plateforme hautement scalable d’appliquer les six grands principes décrits dans ce livre :

• Architect products, not just solutions for projects
• Focus on Quality Attributes, not on functional requirements
• Delay design decisions until they are absolutely necessary
• Architect for change — leverage the power of small
• Architect for build, test, and deploy
• Model the organization after the design of the system

De notre expérience, l’application de ces principes est la base de la réussite future d’une implémentation d’architecture complexe.

Pour bien les implémenter, nous recommandons les principes organisationnels suivants :

• Une équipe expérimentée d’architectes doit intervenir dans la définition même de la plateforme et de ses principes d’architecture — en ce sens une architecture doit être ‘bien née’ quelle que soit la solution choisie (architecture microservices custom, utilisation d’un ensemble de briques SaaS).
• La gouvernance ou l’architecture influence les décisions stratégiques de la plateforme — y compris fonctionnels ou d’expérience lorsque cela devient important par rapport aux exigences de qualité.
• L’inclusion des mécanismes de gouvernance d’architecture dans le modèle d’agilité choisi (comme SAFe) est critique pour la mise en œuvre d’une ‘gymnastique’ entre ‘architecture intentionnelle’ et ‘emerging design’ — en d’autres termes, il faut optimiser le travail de l’architecte système ou des architectes et des leads pour que toutes les décisions soient faites en équipe entre ceux portant la vision globale à long terme et ceux qui l’implémentent au jour le jour — ces derniers devront prendre des décisions spécifiques soutenant cette vision globale et les exigences de qualité.

Au-delà de ces principes, nous préférons en général l’utilisation des architectures de type ‘composable commerce’ comme décrites dans notre étude.
Nous recommandons l’implémentation de ce modèle soit en utilisant une solution éditeur SaaS (Salesforce Commerce, Commercetools, Spryker, etc…) soit sur la base d’une architecture custom microservices si cela parait plus adapté.

De l’importance du socle technique, comme fondation des meilleures pratiques et accélérateur de cette croissance

Lorsqu’on construit une nouvelle plateforme et qu’on a l’ambition d’en faire le moteur d’une activité e-commerce, omnicanale représentant des centaines de millions de revenu à court ou moyen terme, il est largement préférable de ne pas se ‘précipiter’.

Quelles que soient les injonctions du senior management (en général pour aller vite / livrer une version MVP à une date arbitrairement choisie), la mise en place du socle technique est un facteur clé de succès dans la mise à l’échelle future de la plateforme. Prendre le temps de construire les fondations techniques d’une plateforme est critique.

De notre expérience le temps passé à la construction du socle technique va permettre l’accélération du build du MVP tout en permettant d’assurer la cohérence technique de la plateforme sur le long terme.

Chez Publicis Sapient nous utilisons souvent une approche ‘steel thread’ (Steel threads) afin de valider les choix techniques, pouvoir anticiper les futures caractéristiques de la plateforme dès le début du projet et de valider le socle technique dès les premiers développements fonctionnels.

Comment les pratiques DevOps et l’observabilité sont vos meilleurs alliés dans la l’amélioration continue de la scalabilité d’une plateforme

En lien avec la mise en œuvre du socle technique, il n’y a pas de plateforme scalable et opérable sans la mise en place des meilleures pratiques DevOps.

En particulier nous encourageons la mise en place dès le début du projet d’un processus de livraison continue sur tous les composants d’une architecture distribuée. Cela parait être une évidence, mais plus la plateforme sera complexe, plus le nombre d’équipes et de développeurs augmentera et plus l’effet positif ou négatif liés à la maturité du processus de livraison sera important. Si le processus de release est solide, fluide et maitrisé, le processus de livraison en production sera rapide, et l’agilité globale du programme sera maintenue. A l’inverse plus le processus est mal maitrisé, plus le risque d’avoir un processus lent et demandant une attention soutenue des personnes les plus expérimentées est fort, des risques d’interruptions de service ou des incidents sont également à prévoir.

Au-delà du processus de release, il est important d’automatiser au mieux le processus de construction des environnements afin d’affiner progressivement cette stratégie pour soutenir le processus de release continue tout en ajustant son modèle de qualité (en particulier performance et load testing, voir paragraphe suivant).

Pour pouvoir anticiper une stratégie d’environnements souple, il est important qu’un effort continu soit appliqué à la mise en place des environnements. Sans forcément appliquer à la lettre la notion de ‘one click deployment’, le processus de déploiement des environnements doit être le plus automatisable et automatisé (et du coup les choix d’architecture doivent être réalisés en conséquence).D’un point de vue organisationnel, il n’y a pas de formule magique mais 2 modèles principaux se dégagent :

• la mise en place dans les équipes de spécialistes devops avec un chapter lead / cloud architect
• une équipe resserrée en management transverse ou la mise en place d’une équipe dédiée plateforme engineering (voir : https://about.gitlab.com/blog/2022/03/08/key-organizational-models-for-devops-teams/) avec pourquoi pas l’ambition de développer une Internal Developer Platform (IDP).

Nous avons implémenté les deux modèles et ils portent chacun leurs propres complexités. L’équipe DevOps est aussi critique pour opérationnaliser l’observabilité de la plateforme qui via le ou les bons outils (APM, gestion des logs, observabilité cloud) vont permettre de suivre le comportement et la performance service par service.

Comment les processus qualité et de capacity management sont nécessaires pour une approche empirique des tests de charge

La réussite de la mise en œuvre d’une plateforme omnicanale se situe aussi dans les processus qualité.

Quel que soit le talent des architectes et des développeurs, performance et scalabilité sont mieux assurés lorsqu’un processus de qualité est mis en place de manière industrialisé.

Il est plus intéressant de détecter les goulots d’étranglement dans le cadre d’un processus maitrisé de tests plutôt que lors d’un incident de production ! Cela évite à la fois des discussions difficiles avec le business et des situations de crise.

Notre expérience est d’industrialiser le processus de load/performance testing pour pouvoir répéter — sur un environnement le plus proche de la production — les tests, afin de s’assurer continuellement du scaling de la plateforme et d’anticiper ainsi ces mêmes goulots d’étranglement.

Cela peut encore une fois paraitre évident mais une planification adéquate est nécessaire (jeux de données, dépendances logiciels tiers, outillage, environnement permanent ou on demand) pour pouvoir maitriser son processus tests, évolutions, re-tests pour pouvoir continuer de scaler sa plateforme de manière appropriée.

En conclusion, une approche systématique et un modèle d’évaluation régulier de votre capacité à monter en charge sont nécessaires pour réussir à accompagner la croissance de votre plateforme.

Il n’y a pas de ‘martingale’ pour développer une plateforme e-commerce qui “scale” progressivement pour supporter un revenu supérieur à 1 milliard d’euros sans ‘douleurs’ et souvent des ajustements sont nécessaires.

Certainement la formule de Nicolas Boileau en 1674 ‘Hâtez-vous lentement, et sans perdre courage, Vingt fois sur le métier remettez votre ouvrage’ s’applique-t ’elle au processus progressif du scaling d’une plateforme omnicanale.

Cependant, il est nécessaire de mettre au cœur du processus d’architecture continue et d’engineering, certaines des meilleures pratiques qui permettront de supporter la croissance de votre business sur la base d’une approche de scaling horizontal de votre architecture.

Auteurs : Marc Guerin, Mohamed El Habib et Damien Salvador.

Références

• Steel threads : Software engineering constructs for defining, designing and developing software system architecture
  Journal of Computational Methods in Sciences and EngineeringVolume 12Issue s1January 2012 pp 63–77
• Continuous Architecture : Sustainable Architecture in an Agile and Cloud-Centric World Paperback — Illustrated, 5 Nov. 2015
• “Demystifying Composable Commerce” White Paper
• Multi-datacenter Replication in Cassandra. November 5, 2012