Une architecture modulaire, en commerce en ligne, veut dire une chose simple : chaque fonction est un composant à part, choisi pour ce qu'il fait, et raccordé aux autres. Le catalogue, le paiement, le stock, l'exécution dans le magasin, l'expédition. À l'opposé, une plateforme unique propose tout cela comme des options d'un même produit, où les fonctions sont soudées entre elles.
Les deux approches marchent. Ce qui les distingue n'est pas la qualité des fonctions, c'est ce qu'il faut faire le jour où l'une d'elles ne convient plus.
L'avantage réel, et il n'est pas celui qu'on annonce
On présente d'habitude la modularité comme une liberté de choix : prendre le meilleur de chaque catégorie. C'est vrai, et c'est secondaire.
L'avantage qui compte se mesure au moment du remplacement. Dans un ensemble modulaire, changer la brique de paiement ou de catalogue est un chantier borné : on débranche, on rebranche, le reste ne bouge pas. Dans une plateforme unique, la même décision est une migration, avec sa phase de gel et son risque.
Autrement dit : la modularité ne rend pas le quotidien plus facile, elle rend le changement moins cher. Si vous n'avez rien à changer, elle ne vous rapporte rien.
Faites défiler latéralement pour voir toute la figure.
Le coût, qui est au même endroit
Chaque frontière entre deux briques est un endroit où les données peuvent se contredire. Non pas parce que le raccordement est mauvais, mais parce que deux systèmes bien raccordés peuvent ne pas donner le même sens aux mêmes mots : « disponible » avec ou sans le stock réservé, « expédié » au colis fermé ou à la remise au transporteur. Ce que la frontière doit transporter, message par message, est détaillé sur api logistique.
Un ensemble modulaire mal gouverné est donc pire qu'une plateforme unique : vous avez payé la souplesse et vous héritez des désaccords. Trois décisions l'évitent, et aucune n'est technique.
- Un système de référence par donnée : qui a raison pour le stock, qui a raison pour la facture.
- Un propriétaire par événement : qui déclare qu'une commande est exécutable, qui déclare qu'elle est partie.
- Un modèle de données identique d'une brique à l'autre, au nom de champ près.
Les quatre bénéfices habituellement cités, relus honnêtement
L'évolutivité. Ajouter ou remplacer un composant sans refonte. Vrai, à condition que les frontières aient été posées avant, pas pendant.
La souplesse. Choisir le meilleur outil de chaque catégorie. Vrai, avec une limite : le meilleur outil d'une catégorie n'est pas forcément celui qui se raccorde le mieux au reste de votre ensemble.
Le coût. Ne payer que ce qu'on utilise. Vrai sur les licences, à nuancer sur l'exploitation : il faut surveiller les raccordements, et cela a un prix.
La personnalisation. Construire un ensemble taillé pour son métier. Vrai, et c'est l'argument le plus solide des quatre pour une opération dont les processus ne ressemblent pas à la moyenne.
Côté logistique : deux briques, pas trois
C'est le point où il faut être précis, parce que la confusion est fréquente.
La première brique est l'exécution dans le magasin. Un logiciel WMS tient la réception, la gestion des emplacements, la préparation et l'expédition. C'est lui qui fait référence sur le stock physique.
La seconde est l'orchestration des commandes. Un logiciel de gestion des commandes reçoit les commandes de tous les canaux, les normalise, affecte le stock et décide d'où part chaque ligne. C'est lui qui fait référence sur l'état d'une commande.
Le transport, lui, n'est pas une brique que nous fournissons. L'édition d'étiquette et le choix du transporteur passent par une plateforme d'expédition raccordée au WMS ; la planification et l'optimisation de tournées passent par des outils partenaires. C'est précisément l'intérêt d'une architecture modulaire : nous ne prétendons pas remplacer ce que d'autres font mieux.
En amont, les canaux de vente se branchent par les intégrations e-commerce et les intégrations places de marché ; la gestion se branche par un connecteur ERP.
Un scénario, et pas une référence
Prenons un vendeur d'articles de maison dont les volumes doublent sur novembre et décembre. Les symptômes classiques : du stock annoncé qui n'existe plus, un traitement qui ralentit, des livraisons en retard.
Dans un ensemble modulaire, la réponse se décompose. Le WMS prend l'exécution et la justesse du stock sur plusieurs sites. L'orchestration prend les règles de période de pointe : d'où part quoi, dans quel ordre, avec quelle priorité. Le catalogue et le paiement ne bougent pas, parce qu'ils ne sont pas le problème.
Ce raisonnement est un scénario, pas un client. La page anglaise le présente comme un exemple réel ; il n'y a derrière ni nom ni mesure, et nous préférons le dire.
Comment décider, concrètement
Posez-vous une seule question, et pas « modulaire ou monolithe » : quelle brique voulez-vous pouvoir remplacer dans deux ans ?
Si la réponse est « aucune », restez où vous êtes. Si la réponse est « l'exécution, parce que le magasin nous freine », découpez celle-là et laissez le reste tranquille. Les particularités du secteur sont décrites sur notre page logistique e-commerce.
<!-- La FAQ est générée depuis le bloc `faq` de l'en-tête -->
BizBloqs fournit deux briques — l'exécution du magasin et l'orchestration des commandes — et se raccorde au reste de votre ensemble par API. Pour voir où elles se placeraient chez vous, réserver une démo. Si votre plateforme actuelle vous convient et que rien n'est à remplacer, la modularité est une dépense sans contrepartie.
