Intégrations en un clic : App Store, pas de ticket devLe time-to-market se joue rarement dans le dia…
Modular Commerce : le goulot est passé au frontend
Le modular commerce règle le problème du replatforming là où il est né, c'est-à-dire côté backend. Et ce faisant, il met en lumière l'endroit où se situe réellement le goulot du time to market : le frontend. Si tu déploies ton core commerce en huit semaines mais que tu fais construire une interface dédiée pour chaque module, tu as déplacé le goulot, tu ne l'as pas supprimé.
Notre lecture : c'est le déplacement architectural le plus important de l'année, et la plupart des feuilles de route ne le chiffrent toujours pas.
Ce qui a bougé sur le marché
Depuis juillet 2026, commercetools commercialise son offre sous forme de modules. Core Commerce d'un côté, avec panier, commande, checkout, client et B2B. Product Catalog de l'autre, avec modélisation produit, pricing, stock et recherche. Les deux s'achètent séparément, et plus uniquement sous forme de plateforme complète. Le détail se trouve dans l'annonce du modular commerce.
Doug McNary, CEO de commercetools, résume la logique ainsi :
"As the pace of commerce innovation accelerates, companies can no longer afford to wait years to modernize. Enterprises want to solve immediate business problems, prove value quickly and evolve over time."
Sur le fond, il n'y a rien à contester. C'est juste. Et il faut regarder qui le dit : un éditeur avec plus de 600 marques sur sa plateforme et environ 120 milliards d'euros de GMV annualisé. Quand la référence du composable découpe le projet de replatforming en briques achetables, ce n'est pas un détail produit, c'est un signal de marché. Le message est clair : la modernisation se fait par incréments, pas en big bang.
La direction est sans ambiguïté. La seule question ouverte, c'est de savoir si le calcul est complet.
Pourquoi le goulot se déplace au lieu de disparaître
Un module livre une API. Une API ne livre pas de valeur métier. La valeur apparaît là où un client voit quelque chose, le comprend et l'achète, donc sur la couche de restitution.
C'est exactement pour cela que le calcul se déplace au lieu de se réduire. Avant, le budget portait un grand projet de replatforming, avec un début et une fin nets. Aujourd'hui, il porte plusieurs déploiements backend courts, et à côté, le plus souvent non chiffré, un projet frontend par module.
- Déploiement backend Replatforming classique: un grand projet. Modular commerce sans couche frontend: plusieurs étapes courtes et planifiables.
- Effort frontend Replatforming classique: une fois, mais lourd. Modular commerce sans couche frontend: répété par module, plus lourd au total.
- Valeur client visible Replatforming classique: à la fin du projet. Modular commerce sans couche frontend: seulement après l'interface correspondante.
- Risque Replatforming classique: concentré sur la mise en ligne. Modular commerce sans couche frontend: réparti, mais permanent.
Le schéma n'est pas nouveau. Nous l'avons déjà vu quand la vitesse est devenue le premier moteur des décisions composable, comme détaillé dans notre analyse du speed to market comme moteur du composable. Le modular commerce ne fait que le rendre beaucoup plus visible, parce que le côté backend est désormais bien cadencé et que le côté frontend ne l'est pas.
La ligne qui manque au calcul des modules
Fais le calcul pour toi. Tu achètes Product Catalog parce que ton pricing doit devenir plus souple, vite. Quatre semaines plus tard, le module est connecté. Puis quelqu'un pose la question qui décide de tout : où exactement un client voit-il le nouveau prix, sur quels marchés, sous quelle marque, sur quel canal, et qui construit cela ?
À partir de là, le chronomètre repart, mais côté équipe frontend. Et cela recommence au module suivant. Dans nos échanges projets, nous voyons régulièrement des programmes composable qui dépassent neuf mois alors que le backend était prêt depuis longtemps. La raison est presque toujours la même : frontend, intégration et déploiement ont été reconstruits en parallèle, chacun traité comme un cas particulier.
Le point n'est pas que la modularisation du backend serait une erreur. Elle est juste, et elle était attendue. Le point, c'est que la modularité ne produit du time to market que si elle existe des deux côtés de l'API. Sinon, tu achètes de la vitesse côté backend et tu la rembourses côté frontend. Nous avons déroulé ce que doit être cette couche d'expérience sur la stack commercetools dans enterprise commerce en jours plutôt qu'en mois.
Ce que cela change pour toi, côté décision
Trois conséquences que je donnerais à tout dirigeant ou responsable commerce :
Premièrement, mesure le bon indicateur. Pas le délai jusqu'à la mise en ligne du module, mais le délai jusqu'au premier chiffre d'affaires qui passe réellement par ce module. L'écart entre les deux, c'est ton frontend gap.
Deuxièmement, découple la couche frontend avant d'acheter le deuxième module. Tant que la couche de restitution est soudée à un seul backend, elle hérite de chaque décision backend. Une couche frontend autonome posée sur une Composable Digital Experience Platform inverse la logique : le backend devient remplaçable et l'interface reste en place.
Troisièmement, pense la restitution en modules elle aussi. Si panier, recherche et pricing arrivent en modules, alors composants, pages et campagnes doivent s'assembler de la même manière. C'est le rôle de la composabilité et de l'orchestration côté frontend, et la raison pour laquelle nous avons construit Laioutr comme une Frontend Management Platform et non comme un jeu de templates de plus.
Concrètement, cela signifie une connexion standard à plus de 50 backends, dont commercetools derrière un frontend découplé, un studio où le marketing construit ses pages au lieu d'attendre un sprint, et une bibliothèque de composants valable pour toutes les marques et tous les marchés à la fois. Les chiffres viennent de nos propres projets : 65 pour cent de time-to-launch en moins pour de nouvelles landing pages face à un setup headless classique, et une médiane inférieure à 14 jours pour une migration accompagnée par les fondateurs.
Rien de tout cela ne s'oppose au modular commerce. C'est la moitié manquante du calcul. Garde les deux côtés modulaires et tu obtiens exactement ce que décrit McNary : des preuves de valeur rapides plutôt que des programmes pluriannuels. Ne modularise que le backend et tu obtiens des projets backend plus rapides, puis tu attends aussi longtemps qu'avant.
FAQ
Le modular commerce remplace-t-il le composable commerce ? Non. C'est un modèle d'achat et de déploiement à l'intérieur d'une architecture composable. Tu n'achètes plus toute la plateforme d'un coup, mais les capacités dont tu as besoin en premier.
Pourquoi un backend moderne ne suffit-il pas au time to market ? Parce qu'un module livre une interface technique, pas une interface utilisateur. Le client ne voit jamais l'API. Seule la couche de restitution transforme une capacité en chiffre d'affaires, et c'est précisément là que se trouve l'effort que le calcul des modules oublie le plus souvent.
Faut-il changer de backend pour cela ? Non, au contraire. L'approche frontend-first fonctionne surtout quand le backend reste en place. Tu découples la couche de restitution, puis tu adoptes les modules à ton rythme sans reconstruire l'interface une deuxième fois.
En combien de temps une couche frontend est-elle productive ? Pour un setup mono-marque, la médiane de nos migrations accompagnées est inférieure à 14 jours. Les scénarios multi-marques et multi-marchés prennent plus de temps, logiquement, car tokens de marque, locales et droits doivent être planifiés.
Quelle est la première étape utile ? Prends le module prévu sur ta feuille de route et chiffre honnêtement ce que coûtera l'interface associée. Si ce montant dépasse le déploiement du module lui-même, tu tiens ton business case pour une couche frontend autonome.
Prochaines étapes
Si une feuille de route par modules se dessine chez toi, cela vaut la peine de regarder l'autre côté de l'API avant la mise en ligne du premier module. Réserve une démo de 30 minutes : nous parcourons ta feuille de route et chiffrons la part frontend.
Autres sujets de la plateforme Laioutr
À propos de l'auteur : Marcel Thiesies est CEO et cofondateur de Laioutr. Il accompagne distributeurs et marques de la région DACH pour sortir la couche frontend du projet de replatforming.