La correction du composable

92 % des marques américaines exploitent désormais des systèmes de commerce modulaires et pilotés par API. Le gain d'agilité est réel pour les équipes qui réussissent le composable : environ 35 % d'amélioration de la vitesse à laquelle leur architecture peut absorber le changement. Le hic, c'est l'écart entre les 92 % et les 35 %. Beaucoup d'équipes sont passées au composable entre 2022 et 2024 et se sont réveillées en 2025 avec des backlogs d'ingénierie plus longs, et non plus courts. Le code de liaison des intégrations a dévoré le gain de vélocité.

La bonne nouvelle : ce n'est pas un verdict sur le composable. C'est un verdict sur la façon dont les équipes l'ont composé. Au fil de nos onboardings clients, quatre patterns d'ingénierie distinguent de façon fiable les stacks qui restent rapides de ceux qui se noient dans les coutures.

C'est un article en voix de Sebastian, donc les patterns viennent avec les compromis qu'ils impliquent.

Pourquoi la correction se produit maintenant

Trois pressions ont convergé en 2025 :

1. Le nombre de fournisseurs a dépassé la capacité d'intégration. Un stack de commerce modulaire typique couvre aujourd'hui le backend, le CMS, la recherche, la personnalisation, le PIM, l'OMS, l'orchestration des paiements et un ou deux services d'AI. Huit à douze fournisseurs, ce n'est pas inhabituel. Chacun livre des changements cassants à son propre rythme.
2. Le frontend est devenu le percepteur de la taxe d'intégration. Les backends sont devenus plus propres. Les frontends ont absorbé chaque couture : incohérences de format de données, flux d'authentification, situations de concurrence à l'hydratation, état preview par rapport à l'état live, gestion des locales. Ce que le client touche est devenu ce sur quoi chaque équipe doit se coordonner.
3. La promesse de l'expérience éditeur s'est érodée. On a vendu le composable aux équipes marketing avec « plus de flexibilité dans l'éditeur ». Ce qu'elles ont obtenu, c'est quatre identifiants de connexion, trois outils de prévisualisation et un fil Slack pour demander lequel fait foi pour une page donnée.

On peut combattre cela avec de la discipline. Les quatre patterns ci-dessous sont cette discipline.

Pattern 1 : des contrats de frontière de stack sous forme de code

Chaque couture entre deux services est un contrat. La version la moins chère de ce contrat, c'est « le consommateur lit ce que le producteur livre aujourd'hui ». La version coûteuse, c'est « le schéma par la prière ». Vous le payez au troisième changement cassant.

Ce qui fonctionne :

• Traitez chaque format inter-services comme un schéma versionné. GraphQL, JSON Schema ou validation à l'exécution typée avec Zod. Choisissez-en un et appliquez-le à chaque frontière, y compris les plus ennuyeuses (texte de bannière, liens de pied de page, règles de redirection).
• Publiez un test de contrat par consommateur. Si le CMS change un champ, le test de contrat du frontend casse avant le storefront. Traitez ce test comme un gate de CI, pas comme un simple plus.
• Les incompatibilités de version apparaissent comme des avertissements, pas comme des erreurs 500. Un consommateur devrait pouvoir lire un format de champ producteur plus récent et se replier proprement. Le frontend ne sert jamais une page blanche parce que le CMS a livré un attribut optionnel supplémentaire.

Compromis : plus de travail de schéma en amont. Les équipes qui sautent cette étape sont celles qui écrivent le plus de post-mortems au troisième trimestre.

Pattern 2 : une couche d'orchestration qui possède les coutures

C'est la lacune la plus courante. Les équipes choisissent le best-of-breed pour chaque domaine, puis demandent à la couche de données du storefront de tout assembler au moment de la requête. Le storefront devient la couche d'orchestration par défaut, sans que personne ne l'ait conçu ainsi.

Ce qui fonctionne :

• Nommez la couche d'orchestration. C'est son propre déployable, pas un dossier à l'intérieur de l'application Next.js ou Nuxt. La couche d'orchestration normalise les formats, répartit les fetches, gère la stratégie de cache par type de ressource et expose une API propre à la couche de rendu.
• Sortez les préoccupations transversales du frontend. Décisions de personnalisation, branchements A/B, résolution des locales, arrondi des devises. Si deux services doivent s'accorder sur la réponse, c'est la couche d'orchestration qui possède cet accord.
• Laissez la couche de rendu rester ennuyeuse. L'arbre Vue ou React devrait s'occuper de la mise en page et de l'interaction, pas décider quelle variante du CMS récupérer.

C'est le pattern autour duquel nous avons construit notre couche Orchestr. Les équipes qui le sautent finissent avec leurs ingénieurs seniors qui maintiennent la plus grande passerelle GraphQL sur mesure du monde, au lieu de livrer des fonctionnalités.

Pattern 3 : une observabilité qui suit l'utilisateur, pas le service

L'observabilité composable échoue quand chaque fournisseur est observé de façon isolée. Le tableau de bord du CMS dit que le CMS va bien. Le tableau de bord de la recherche dit que la recherche va bien. Le client dit « la page produit est cassée sur mobile en France » et vous n'avez rien.

Ce qui fonctionne :

• Les identifiants de trace traversent chaque frontière. Un identifiant unique circule depuis l'edge, à travers l'orchestration, jusque dans chaque appel de service, puis revient. Quand quelque chose casse, vous pouvez rejouer toute la requête, pas seulement le symptôme.
• Définissez des signaux clés au niveau de la surface visible par l'utilisateur. LCP, INP, taux d'erreur sur l'ajout au panier, taux de conversion sur les 20 principaux SKU. Pas des SLO internes au service, mais des résultats visibles par l'utilisateur.
• Reliez les alertes au signal utilisateur, pas au signal du service. Une réponse 200 de la recherche qui renvoie zéro résultat reste une session de recherche cassée. Détectez-la.

Compromis : un véritable investissement dans l'infrastructure de traçage. Les équipes qui reportent cela apprennent l'existence des pannes par les tickets du support client, trois jours trop tard.

Pattern 4 : une couche de gestion du frontend qui empêche la fuite de l'éditeur

C'est le pattern qui boucle la boucle avec l'équipe marketing. Sans lui, le reste de la discipline reste coûteux aux yeux des personnes qui font le travail.

Le mode de défaillance, c'est la fuite de l'éditeur : chaque service backend traîne sa propre interface d'administration dans le quotidien du responsable marketing. Quatre identifiants de connexion, quatre outils de prévisualisation, quatre versions de « à quoi ressemble la page live en ce moment ». Le stack composable fonctionne techniquement. L'expérience éditeur est une taxe.

Ce qui fonctionne :

• Une seule surface d'édition pour un seul storefront. Le responsable marketing édite le hero, les textes, les règles de classement de la recherche, les règles de redirection, les variantes de personnalisation et les prompts des agents d'AI au même endroit. Les frontières entre services sont un détail d'implémentation, pas une couture d'UX.
• La prévisualisation est composite, live et fidèle. Pas une prévisualisation du CMS qui ment sur ce que la recherche va classer. Pas une prévisualisation d'outil de personnalisation qui ignore l'état de brouillon du CMS. Une prévisualisation composite qui tire de chaque service dans son état de brouillon actuel.
• La publication est atomique au niveau du storefront. Quand le responsable marketing publie une campagne qui touche le CMS, les règles de recherche et une variante de personnalisation, les trois sont validées ensemble ou aucune ne l'est. Une sous-publication échouée ne laisse pas le storefront dans un demi-état.

C'est la couche que nous appelons une Frontend Management Platform. Ce n'est pas un CMS, pas un outil de personnalisation, pas un optimiseur de recherche. C'est l'endroit où l'expérience éditeur reste saine pendant que le backend reste modulaire.

Ce que la discipline vous apporte

Les équipes qui appliquent les quatre patterns obtiennent deux résultats qui se combinent bien :

• La croissance du backlog ralentit. Le travail sur les fonctionnalités revient à des semaines, pas à des trimestres. Le gain d'agilité de 35 % dont parlaient les analystes commence à se voir dans la vélocité réelle des sprints.
• L'éditeur cesse d'être un otage. Les équipes marketing arrêtent d'ouvrir des fils Slack avec « quel outil dois-je utiliser pour mettre à jour le hero sur le site SE ». Elles ouvrent un seul outil. Le composable leur devient invisible, ce qui est tout l'intérêt.

Les équipes qui sautent des patterns obtiennent un ou deux de ces bénéfices par accident, puis les perdent au prochain changement de fournisseur.

Ce qu'il faut mesurer dans votre stack ce trimestre

Si vous voulez savoir si votre stack composable est dans les 35 % ou dans les 92 % moins 35 %, trois mesures :

1. Le temps moyen entre « le merchandiser demande une campagne » et « la campagne est live ». S'il dépasse une semaine de travail et que la campagne ne nécessite pas de nouveau code, la couche éditeur fuit.
2. Le nombre de services touchés par un seul bug typique. Si « le prix de la PDP a clignoté » exige quatre équipes en cellule de crise, la couche d'orchestration manque.
3. Le pourcentage d'incidents dont la cause racine était une incompatibilité de contrat inter-services. S'il dépasse 20 %, vous n'avez pas de contrats de frontière de stack. Vous avez de l'espoir de frontière de stack.

Aucune de ces mesures ne nécessite un fournisseur. Elles nécessitent un trimestre de mesure honnête.

Où cela laisse le composable en 2026

Le composable a toujours été la bonne direction architecturale. La correction n'est pas un retour au monolithe. C'est la reconnaissance que choisir le best-of-breed pour chaque domaine ne paie que lorsque les coutures sont conçues avec la même rigueur que les services eux-mêmes.

Les quatre patterns sont la rigueur d'ingénierie. La couche de gestion du frontend est ce qui tient l'équipe marketing hors de la cellule de crise de l'ingénierie. Le composable plus la gestion du frontend, c'est ce que nous construisons chez Laioutr, parce que nous avons continué à voir des équipes payer la taxe d'intégration et avons décidé que cette taxe était la mauvaise ligne budgétaire.

Si vous voulez voir comment la couche Orchestr et le Laioutr Editor fonctionnent ensemble sur un stack réel, la page frontend headless composable vous fait le tour. Si vous voulez creuser le côté agentic de tout cela, la page Agentic Frontend Management Platform est là où vivent les patterns d'AI.

La correction est réelle. Le remède, c'est l'ingénierie, pas le changement de fournisseur.

À lire également sur Laioutr

• Composable Digital Experience Platform

À lire également : LLM Buyer Agents on Storefronts : 3 patterns d'ingénierie et 5 patterns d'UX éditeur pour les stacks composables multi-services.