Le composable n’est pas une stratégie

Une conviction devenue un réflexe

Il y a dix ans, la question était de savoir quelle plateforme choisir. Aujourd’hui, une partie du marché a tranché à votre place : l’avenir serait composable, découplé, piloté par API, et le monolithe serait une dette en attente. Les éditeurs, les intégrateurs et les analystes répètent le même message, avec des arguments réels : liberté de choix, évolutivité, rapidité de l’interface.

Le problème n’est pas que ces arguments soient faux. C’est qu’ils sont présentés comme universels. Une architecture n’est pas une conviction ; c’est un arbitrage entre ce que l’on gagne en souplesse et ce que l’on paie en complexité. Cet arbitrage dépend de l’entreprise, pas de l’époque.

Ce que le composable promet, et ce qu’il coûte

La promesse est séduisante : chaque fonction (catalogue, panier, recherche, contenu, paiement) devient un composant indépendant, remplaçable sans toucher au reste. L’interface peut changer sans toucher au moteur de commerce. Un nouveau canal se branche sur les mêmes services.

Le coût est moins souvent exposé. Il tient en quatre mots :

• Orchestration. Quelqu’un doit faire fonctionner ensemble des composants qui n’ont pas été conçus pour cela, et maintenir cette cohérence à chaque mise à jour de l’un d’eux.
• Responsabilité. Quand une commande échoue, il faut savoir quel composant est en cause. Dans un monolithe, la réponse est unique. Dans une architecture composable, elle peut impliquer quatre fournisseurs.
• Surveillance. Chaque composant a ses propres journaux, ses propres pannes, ses propres limites. Les rassembler en une vue fiable est un projet en soi.
• Gestion des fournisseurs. Quatre contrats, quatre feuilles de route, quatre politiques de prix qui évoluent indépendamment.

Ce coût n’apparaît pas au lancement. Il s’installe ensuite, chaque mois.

Les trois conditions de rentabilité

Le composable rapporte lorsque ce qu’il fait gagner dépasse durablement ce qu’il coûte à exploiter. En pratique, cela suppose trois conditions réunies.

1. Des canaux réellement différents. Un site web, un portail B2B pour les représentants, une application mobile et un terminal en magasin, chacun avec une expérience propre. Si votre seul canal est un site, le découplage de l’interface apporte peu.

2. Un rythme de changement élevé et inégal. Le bénéfice du composable vient de la possibilité de faire évoluer un domaine sans toucher aux autres. Si votre tarification change chaque semaine mais que votre catalogue est stable, le découplage a un sens. Si tout évolue lentement, il n’en a pas.

3. Une équipe capable d’assumer l’assemblage. Un responsable d’architecture, une pratique d’exploitation mature, des tests automatisés, une gouvernance des API. Sans cette capacité, en interne ou chez un partenaire engagé dans la durée, l’architecture composable se dégrade plus vite qu’un monolithe.

Une seule condition remplie ne suffit pas. Deux sur trois justifient une étude sérieuse. Les trois réunies justifient l’investissement.

Matrice de décision Nuevamed

Le monolithe modulaire, l’option oubliée

Entre le monolithe classique et l’architecture entièrement composable existe une voie rarement mise en avant, parce qu’elle se vend mal : une seule application, organisée en domaines bien séparés (catalogue, prix, commandes, clients), qui communiquent par des interfaces claires.

Elle offre l’essentiel de la clarté du composable sans en supporter le coût d’exploitation. Elle se déploie d’un bloc, se surveille d’un seul endroit et relève d’une seule équipe. Surtout, elle prépare l’avenir : le jour où un domaine justifie réellement d’être extrait, la frontière existe déjà.

Pour une majorité des entreprises de taille moyenne que nous rencontrons, c’est la bonne réponse. Elle n’est simplement pas à la mode.

Migrer par domaine, pas d’un bloc

Lorsque le composable est justifié, la pire approche consiste à tout remplacer en une seule fois. La plus sûre consiste à extraire un domaine à la fois, en commençant par celui qui change le plus souvent et dont le coût de changement est le plus élevé : la tarification ou la recherche, très souvent.

Le reste de la plateforme continue de fonctionner pendant ce temps. Chaque extraction est mesurée avant de décider de la suivante. Si le gain n’est pas au rendez-vous, on s’arrête, sans avoir mis l’entreprise en risque.

Quand nous recommandons Shopflow, et quand nous ne le faisons pas

Shopflow, notre plateforme, est orientée API. Il serait plus simple pour nous de recommander une architecture découplée à chaque client. Nous ne le faisons pas.

Nous recommandons Shopflow lorsque la logique B2B (prix négociés, catalogues par client, intégration étroite avec l’ERP) est au cœur de l’activité et que plusieurs canaux doivent partager cette logique. Nous recommandons autre chose lorsque le modèle d’affaires est proche du standard d’une plateforme SaaS, ou lorsque l’organisation n’a pas encore la capacité d’exploiter une architecture ouverte. Dans ce cas, une solution plus intégrée, même moins souple, coûtera moins cher et livrera plus vite.

En conclusion

Le composable est un outil puissant, pas une destination. Les entreprises qui l’adoptent par conviction en paient le coût sans en obtenir le bénéfice. Celles qui l’adoptent par calcul, domaine par domaine et au moment où leurs trois conditions sont réunies, en tirent exactement ce qu’il promet. La maturité d’une architecture ne se mesure pas à son degré de découplage, mais à l’adéquation entre sa complexité et la capacité de l’organisation qui la fait vivre.

Nuevamed conçoit et fait évoluer des plateformes monolithiques, modulaires et composables, notamment avec Adobe Commerce et nos équipes de développement web et logiciel. Pour estimer le coût réel de chaque option, lisez aussi Le coût d’une plateforme se décide dans l’intégration.