Octobre 2016. Kelly Goetsch, alors chez commercetools, publie un mince eBook O'Reilly : Microservices for Modern Commerce. 76 pages, sponsorisé par commercetools, avec une préface de Jean-Jacques van Oosten, alors Chief Digital Officer du groupe Rewe. L'argument central : les microservices vont transformer durablement la stack commerce, les monolithes backend vont disparaître, les API deviendront la nouvelle infrastructure.

Dix ans plus tard, cet argument fait consensus. Headless, MACH, Composable, tout le vocabulaire de catégorie que nous utilisons aujourd'hui est né directement de cette pensée. C'est exactement pourquoi ce livre mérite une rétrospective de décennie : quelles prédictions se sont révélées justes ? Lesquelles ont été dépassées par la réalité ? Et quelle lacune Goetsch a-t-il décrite trop légèrement, une lacune devenue depuis le véritable goulot d'étranglement de différenciation ?

Ce que Goetsch a bien vu

1. La loi de Conway est le facteur décisif, pas la technologie

Page 3, Goetsch cite la célèbre observation de Mel Conway datant de 1968 : "Toute organisation qui conçoit un système produira une conception dont la structure est une copie de la structure de communication de l'organisation." Il qualifie ensuite directement les microservices de "Hacking Conway's Law".

En 2016, souligner ce point dans une discussion majoritairement technique était notable. Dix ans plus tard, ce constat est tout simplement indéniable : les projets composable échouent dans la pratique non pas à cause des outils, mais à cause des silos organisationnels. L'équipe frontend d'un côté, l'équipe backend de l'autre, l'équipe content quelque part entre les deux, et la stack composable redevient rapidement un monolithe, simplement avec beaucoup plus de pièces mobiles.

Si vous planifiez aujourd'hui un replatforming avec des équipes encore structurées en couches horizontales (équipe dev, équipe ops, équipe content), vous ne réaliserez pas la flexibilité technique des architectures composable. La structure organisationnelle décide. Toujours.

2. Complexité interne vs externe, le basculement est réel

L'un des concepts les plus incisifs du livre est la distinction entre Inner Architecture et Outer Architecture. Goetsch écrit : "Fondamentalement, les microservices déplacent la complexité vers l'extérieur, échangeant une complexité externe contre une simplicité interne." Chaque microservice pris individuellement devient plus simple. Le réseau qui les relie, service discovery, eventing, API gateways, container orchestration, devient nettement plus complexe.

Ce basculement s'est pleinement concrétisé d'ici 2026. Kubernetes est un outil standard. Le event streaming via Kafka est devenu une discipline à part entière. Les configurations d'API gateway remplissent leurs propres repositories. La simplicité interne s'est matérialisée. Mais la complexité externe a pris un poids que beaucoup d'équipes ont sous-estimé en 2016.

3. L'omnicanal a besoin d'une source unique de vérité par fonction

Goetsch décrit le véritable omnicanal comme : un système unique par capacité métier (pricing, inventory, promotions), et au-dessus, "des UI plus ou moins jetables". L'argument backend s'est révélé entièrement juste. Aucune stack e-commerce sérieuse ne fait aujourd'hui tourner un système monolithique unique gérant simultanément pricing, inventory et promotions.

Shopware, commercetools, SFCC en configuration headless, Algolia pour la recherche, Stripe pour les paiements : la désagrégation du backend est une réalité vécue. Sur ce point, le marché a donné entièrement raison à Goetsch.

Ce que Goetsch a mal vu, ou sous-estimé

4. Les "UI jetables" ont été l'erreur la plus coûteuse de la décennie

C'est ici que cela devient intéressant. Goetsch écrit en 2016 que dans le véritable omnicanal, les UI sont "plus ou moins jetables". Construisez une fois des API backend propres, et de nouvelles interfaces utilisateur, pour Apple Watch, kiosque, chatbot, peuvent être assemblées en quelques jours.

Cette hypothèse s'est révélée fausse. Pas en théorie, mais en pratique.

Ce qui s'est réellement passé : la désagrégation du backend a créé une nouvelle complexité frontend massive. Chaque nouveau frontend doit désormais coordonner des appels API vers des dizaines de microservices, implémenter des stratégies de caching par type de donnée, porter la logique de personalization, tenir des budgets de performance, et gérer des déploiements globaux sur plusieurs marchés et langues simultanément. Construire aujourd'hui un storefront composable sur Next.js, commercetools et Algolia signifie écrire nettement plus de code frontend que n'importe quel développement custom Shopware 6, avec une complexité opérationnelle nettement plus élevée.

L'"UI jetable" ne l'était pas dans la pratique. Elle était simplement moins visible dans le discours de 2016, centré sur le backend.

5. Le frontend layer est aujourd'hui le véritable goulot d'étranglement de différenciation

Quand les backends sont standardisables et achetables en SaaS, et c'est le cas, c'est la thèse MACH confirmée, la différenciation concurrentielle se déplace vers le frontend. Celui qui livre de nouvelles expériences plus vite, qui applique la personalization au plus près du rendu, qui lance des A/B testing sans déploiement backend, qui fait du compositing de contenu assisté par IA sans impliquer les développeurs, celui-là gagne.

C'est exactement la couche que Goetsch a sous-estimée en 2016. Et aujourd'hui, c'est elle le goulot d'étranglement.

Ce que Goetsch décrivait comme l'API gateway jouant le rôle de "Backend for your Frontend" a évolué d'ici 2026 vers les Frontend Management Platforms. Une FMP prend en charge l'Outer Architecture du frontend layer, routing, composition, caching, personalization, déploiement, de façon analogue à ce que le container orchestration a fait pour la couche backend.

L'analogie est directe : de même que vous ne voudriez pas faire tourner un déploiement de microservices sans container orchestration en 2016, vous ne voulez pas faire tourner un storefront composable sans un standard de frontend layer en 2026.

Ce que cela signifie pour votre replatforming

Si vous planifiez aujourd'hui une stack composable, la rétrospective de Goetsch soulève trois questions utiles :

Question 1 : votre structure organisationnelle est-elle prête pour la loi de Conway ? Des équipes produit cross-fonctionnelles par capacité métier ne sont pas un simple plus. Sans elles, vous ne réaliserez pas la flexibilité de la stack composable, quels que soient les outils choisis. Plus de détails dans notre article La loi de Conway dans le replatforming composable.

Question 2 : avez-vous un plan pour l'outer architecture de votre frontend ? Les microservices backend avaient besoin d'un plan : container orchestration, API gateways, service discovery. Votre frontend a besoin d'un plan équivalent. Sans un standard de frontend layer, le TCO composable explose. Plus de détails dans Le headless seul ne suffit pas.

Question 3 : qui possède le frontend layer en tant que capacité ? Pas comme "l'équipe frontend" qui traite des tickets, mais comme une capacité métier à part entière, avec son propre ownership, sa propre influence sur la roadmap, ses propres décisions d'outillage. C'est le principe d'ownership que Goetsch décrivait pour les microservices, appliqué au frontend layer.

Conclusion : Goetsch avait raison, et a laissé une lacune

Microservices for Modern Commerce était un livre important en 2016. Il a déclenché un discours qui a mené au mouvement MACH, à la croissance de commercetools, au headless de Shopware et à tout un écosystème d'API commerce spécialisées.

Les thèses backend se sont révélées justes. La loi de Conway tient toujours. La distinction complexité interne vs externe reste un cadre utile.

Mais l'hypothèse des "UI jetables" était l'angle mort du livre, un angle mort qui a occupé le monde du commerce pendant une décennie. Aujourd'hui, le frontend layer est le goulot d'étranglement de différenciation, et la réponse n'est pas un nouveau développement custom, mais un standard de frontend layer.

Chez Laioutr, nous appelons cela l'Agentic Frontend Management Platform, construite à partir du constat que ce que Kubernetes a fait pour les microservices reste à faire pour le frontend layer.

[Réservez une démo et découvrez comment Laioutr résout cela](https://www.laioutr.com/demo)

Source : Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.

Insights associés

• Le Composable Commerce en 2026 : ce que 83 % ont bien fait, et où ils trébuchent encore
• Le parcours client médié par l'IA : ce que les équipes e-commerce doivent faire dès maintenant

Ressources associées : Content Management et Composable Digital Experience Platform.