Un changement de socle de vente se décide presque toujours de la même manière. Quelqu'un constate que la boutique est lente, ou qu'une fonction demandée depuis dix-huit mois n'arrive pas, ou qu'un éditeur annonce la fin du support d'une version. Un projet se monte. Il porte un nom anglais, replatforming, et un budget qui sera dépassé.
Ce texte ne vous dira pas s'il faut le faire. Il propose quatre questions qui tranchent mieux que le débat habituel entre monolithe et architecture composable, et un avertissement sur le poste que ces projets traitent en dernier.
Ce que le débat monolithe contre composable décide réellement
Les deux termes décrivent une répartition de la responsabilité, pas un niveau de qualité.
Un socle monolithique regroupe la vitrine, le catalogue, le panier, le paiement et souvent la gestion des commandes dans un même ensemble, chez un éditeur. Vous avez un fournisseur, un contrat, un interlocuteur quand quelque chose casse, et une feuille de route que vous ne décidez pas. Changer une pièce demande d'attendre que l'éditeur la change.
Une architecture composable assemble des briques spécialisées qui se parlent par interface : une vitrine ici, un référentiel produit là, une gestion des commandes ailleurs, l'exécution entrepôt ailleurs encore. Vous choisissez chaque pièce et vous pouvez en remplacer une sans toucher aux autres. Vous avez aussi cinq fournisseurs, cinq contrats, et la coordination à votre charge.
Ce que la seconde option vous rend, ce n'est pas de la performance : c'est la main. Ce qu'elle vous facture en échange, ce n'est pas une licence : c'est de la coordination.
Et une affirmation à corriger, parce qu'elle circule partout, y compris dans la version anglaise de ce texte : non, une architecture composable ne fait pas qu'une panne d'un composant « ne perturbe pas l'ensemble ». Elle change la façon dont la panne se propage, et elle vous donne la possibilité d'isoler. Si votre gestion des commandes tombe, vous ne prenez plus de commandes, quelle que soit l'élégance du diagramme.
Faites défiler latéralement pour voir toute la figure.
Les quatre questions, dans l'ordre
Aucune ne porte sur la technologie, et c'est volontaire.
1. À quelle fréquence devez-vous changer quelque chose ?
Comptez les changements structurels des deux dernières années : un canal ajouté, un pays ouvert, un mode de livraison nouveau, un modèle de vente différent — abonnement, vente aux professionnels, précommande.
Zéro ou un : un socle monolithique vous conviendra, et sa simplicité contractuelle est un avantage réel que personne ne chiffre. Quatre ou cinq : vous paierez le monolithe en attente, et c'est la dépense la moins visible du lot.
2. Qui tient l'ensemble ?
Une architecture composable suppose quelqu'un, chez vous ou chez un partenaire, dont le travail est de tenir les liens entre les briques. Pas « quelqu'un qui s'y connaît » : quelqu'un dont c'est la fonction.
Si cette personne n'existe pas et n'est pas budgétée, le composable produit un résultat prévisible : chaque brique fonctionne, les liens dérivent, et plus personne ne sait quel système a raison sur une quantité de stock. Un monolithe mal aimé vaut mieux qu'un assemblage dont personne n'est responsable.
3. Combien de canaux, et sont-ils d'accord entre eux ?
C'est ici que la question devient une question de commerce unifié : avez-vous une seule position de stock et une seule file de commandes, ou autant que de canaux ?
Avec un canal, la question ne se pose pas. Avec une boutique, deux places de marché et deux magasins, elle est la question. Et le point important est que les deux architectures peuvent y arriver, et les deux peuvent la rater : ce qui décide n'est pas le socle, c'est de savoir qui détient la position de stock et qui arbitre son affectation entre les canaux. Le mécanisme est décrit sur logiciel de gestion des commandes, et le cas multicanal sur logistique omnicanal.
4. Qu'est-ce qui vous fait le plus mal aujourd'hui ?
La question la plus utile des quatre, parce qu'elle révèle souvent que le replatforming n'est pas la réponse.
Si la douleur est une vitrine lente, un parcours d'achat daté, un référencement en perte, c'est bien le socle de vente. Mais si la douleur est une survente deux fois par semaine, un délai d'expédition qui glisse, un stock dont personne ne connaît la position réelle, alors changer de boutique ne changera rien — et le projet consommera douze mois pendant lesquels le vrai problème continuera.
Il arrive, plus souvent qu'on ne l'avoue, qu'un replatforming soit le symptôme d'un problème d'exécution que personne n'a su nommer.
Le poste que ces projets traitent en dernier
Un projet de changement de socle est piloté par le marketing et la direction e-commerce, et c'est légitime : la vitrine est leur métier. La conséquence, mécanique, est que l'ordre du planning suit l'ordre des préoccupations de la table.
Le catalogue et le référentiel produit passent en premier, parce qu'ils sont visibles. Le paiement vient ensuite, parce qu'il bloque la mise en service. Les transporteurs suivent. Le stock et l'exécution arrivent en dernière ligne, souvent trois semaines avant la bascule, et c'est à ce moment qu'on découvre les questions qui auraient dû être posées au cadrage.
Les quatre que je vois revenir :
Que signifie « disponible » sur le nouveau socle ? Physique, ou physique moins le réservé, ou moins une réserve ? Si la définition change avec le socle, votre taux de survente changera avec lui.
Qui détient le code article après la bascule ? Un replatforming est l'occasion favorite d'une recodification du catalogue. Une recodification sans table de correspondance maintenue, c'est un entrepôt dont les étiquettes d'emplacement ne correspondent plus à rien.
À quel rythme la disponibilité remonte-t-elle ? En continu, ou à la synchronisation ? Sur une place de marché, la différence n'est pas un confort : une survente y dégrade un indicateur de compte, et pas seulement l'humeur d'un client. Le détail est sur places de marché, où les connexions passent par ChannelEngine et Channable.
Qui reprend les commandes en cours le jour de la bascule ? Les commandes prises sur l'ancien socle et non encore expédiées existent, elles sont parfois à moitié prélevées, et elles ne se reprennent pas d'elles-mêmes.
La reprise de données, qui est le vrai chantier
Aucun projet n'échoue sur le choix d'architecture. Ils échouent sur la reprise.
Un référentiel article accumulé sur dix ans contient des unités incohérentes, des articles actifs qui ne se vendent plus, des doublons créés pour contourner une limite du socle sortant, et des champs détournés de leur usage d'origine — le champ « poids » qui porte en réalité un code fournisseur, parce qu'un jour il n'y avait pas d'autre place. Ces détournements ne sont documentés nulle part et la personne qui les a faits est partie.
Trois conseils, et ils valent plus que le choix du socle.
Nettoyez avant de migrer, pas après. Un référentiel sale migré reste sale, avec en plus la fatigue du projet pour empêcher qu'on y revienne.
Migrez l'actif, archivez le reste. Un article qui ne s'est pas vendu depuis deux ans n'a pas besoin d'être sur le nouveau socle. Il a besoin d'être retrouvable, ce qui n'est pas la même chose.
Gardez la table de correspondance des codes, et gardez-la vivante. C'est l'objet que tout le monde construit et que personne ne maintient, et c'est celui dont vous aurez besoin pendant deux ans.
Trois illustrations, et ce qu'elles montrent
La version anglaise de ce texte présente trois cas de détaillants. Ce ne sont pas des clients et aucun résultat n'y est mesuré : ce sont des illustrations, et je les garde comme telles parce que la mécanique qu'elles montrent est juste.
Un distributeur qui n'arrive pas à ouvrir un deuxième entrepôt parce que son socle ne sait tenir qu'un lieu de stock. Ce qui est en cause ici n'est pas la vitrine : c'est que la gestion du stock vit dans le socle de vente. Sortir le stock du socle est précisément ce que fait une architecture composable, et c'est le cas où elle paie le plus vite. Le sujet est traité sur gestion de stock e-commerce.
Un détaillant qui change son exécution d'entrepôt sans toucher à sa vitrine. Possible dans une architecture composable, impossible dans un socle où les deux sont la même chose. C'est l'argument central du composable et il est solide.
Un vendeur de mode qui ajoute la livraison le jour même en raccordant un prestataire. Ce qui compte ici n'est pas le socle mais la question du quatrième point plus haut : qui décide, commande par commande, ce qui part en jour même et ce qui part en standard. C'est une décision d'affectation, et elle se prend là où les commandes sont ordonnancées.
Si vous le faites quand même, l'ordre qui marche
Un. Tranchez le vocabulaire avant la technique : ce que veut dire « disponible », qui détient le code article, qui gagne sur une quantité. Une demi-page, et elle vaut trois semaines de développement.
Deux. Ne changez pas deux systèmes la même semaine. Si la boutique et l'exécution doivent bouger toutes les deux, séquencez, en commençant par celle qui vous fait le plus mal. Un incident pendant une double bascule est un incident dont personne ne peut nommer la cause.
Trois. Branchez la disponibilité avant de brancher le reste. C'est le lien qui supprime la survente, et c'est celui qui rend la bascule visible aux clients pour de bonnes raisons plutôt que pour de mauvaises. Les connexions de boutique, dont Shopify, sont listées sur intégrations e-commerce. L'ordre complet, lien par lien, est sur intégration des systèmes.
Quatre. Décidez du sort des commandes en cours avant la date de bascule, pas la veille.
Pour aller plus loin
BizBloqs tient l'exécution d'entrepôt et l'affectation du stock entre canaux en dehors du socle de vente, ce qui est précisément ce qui permet d'en changer sans refaire l'entrepôt — le détail est sur logiciel WMS. Pour regarder où votre stock vit aujourd'hui et ce qu'un changement de socle lui ferait, réserver une démo. Si votre socle actuel vous convient, ne le changez pas : l'âge d'un logiciel n'est pas un motif de projet.
