Onboarding Contentful : assurer la trouvabilité, vue du frontendL'onboarding Contentful, c'e…
Pourquoi les marchands B2B sur Magento dépassent le thème par défaut plus vite que le B2C
Pourquoi les marchands B2B sur Magento dépassent le thème par défaut plus vite que le B2C
Si ta boutique Magento sert des clients B2B, ton thème par défaut atteint ses limites plus vite que pour une boutique purement B2C. Pas parce que ton équipe travaille moins bien, mais parce que les besoins sont structurellement différents : configurateurs, tarifs par palier, catalogues spécifiques par compte et parcours de commande à plusieurs étapes sont une charge de frontend. Luma et Hyva sont conçus pour des vitrines B2C uniformes, pas pour une complexité B2B qui change selon chaque client.
Que signifie concrètement "dépasser le thème" ?
En B2C, le thème reste identique pour la grande majorité des clients : liste de produits, fiche produit, panier, tunnel de commande. En B2B, cette structure de base change selon le compte. Un client voit ses propres listes de prix, un autre son propre catalogue produits, un troisième a besoin d'une intégration punchout vers son système d'achat, un quatrième d'un circuit de validation à plusieurs niveaux avant même que la commande ne soit passée. Chacun de ces besoins casse la logique standard du thème Luma ou Hyva, car les deux sont conçus pour une vitrine unique, pas pour des variantes propres à chaque compte.
Tu connais probablement la suite : ton équipe forke le thème. D'abord un petit bloc custom pour les tarifs par palier, puis un template dédié pour le configurateur, puis un contournement pour le punchout, puis une logique supplémentaire pour le circuit de validation au-dessus d'un certain montant. Deux ans plus tard, plus aucun développeur n'a une vue complète de l'endroit où s'applique le code custom, et chaque patch Magento devient un test à risque plutôt qu'une routine.
Ce phénomène existe aussi côté B2C, mais beaucoup plus lentement, car les besoins de la vitrine varient peu d'un client à l'autre. En B2B, chaque compte important est potentiellement un cas particulier, ce qui pousse le thème plus vite dans la spirale du fork.
Le problème : les besoins B2B sont une charge de frontend, pas de backend
La logique backend de Magento, règles de prix, catalogues, groupes clients, est fondamentalement capable de gérer le B2B. L'édition open source n'a pas de suite B2B native (les hiérarchies de comptes et un circuit de devis complet restent réservés à Adobe Commerce), mais les modèles de données pour les tarifs par palier et les groupes clients existent déjà. Ce qui manque, c'est la capacité d'afficher ces données de façon flexible côté frontend, sans forker le thème à chaque nouveau besoin.
C'est exactement là que beaucoup d'équipes se trompent : elles traitent un problème de frontend comme un problème de backend et lancent un projet de mise à niveau Magento ou une migration vers Adobe Commerce, alors que la couche de présentation est le vrai sujet. Pour vérifier si c'est ton cas, notre audit de préparation au découplage Magento te donne une première évaluation structurée.
Les configurateurs illustrent bien cette charge de frontend. Une fiche produit B2C affiche une image, un prix et un bouton d'ajout au panier. Un configurateur B2B pour un catalogue de machines industrielles a besoin d'une logique conditionnelle (l'option A exclut l'option B), d'un calcul de tarif par palier en direct dans le navigateur, et souvent d'une demande de devis plutôt que d'un achat direct. Luma peut techniquement le faire, mais chaque itération signifie du travail de template PHTML et des correctifs JavaScript à retester au prochain passage de version Magento. Hyva part sur une base plus moderne, mais le problème de fond reste : chaque cas particulier B2B finit dans le thème, pas dans un composant réutilisable.
Comment résoudre ça : découpler le frontend du backend, plutôt que forker le thème encore plus
La voie pragmatique n'est pas d'investir encore davantage dans Hyva ni de basculer vers PWA Studio, mais de traiter la couche d'expérience comme un layer indépendant qui parle à l'API GraphQL de Magento. Avec Laioutr, tu poses ce layer par-dessus sans remplacer Magento comme backend.
Concrètement, les configurateurs, les affichages de tarifs par palier et les catalogues spécifiques par compte deviennent des composants dans une bibliothèque d'interface centrale, plutôt que des forks du thème. Si la logique change pour un client, tu modifies le composant, pas tout le thème. Magento reste le moteur commerce pour les règles de prix, les catalogues et le traitement des commandes, et le frontend devient la partie remplaçable et maintenable, que tu restes sur Magento ou que tu migres vers Adobe Commerce plus tard.
Si tu es un marchand B2B qui construit déjà des parcours de commande en self-service pour des acheteurs récurrents, des gestionnaires de compte ou des acheteurs de filiale, jette un œil à nos modèles de frontend B2B en self-service, qui décrivent exactement ces parcours de commande propres à chaque compte.
Pour les développeurs : Laioutr se connecte à l'API GraphQL de Magento via des connecteurs standard, sans code de liaison custom. Ton équipe garde la logique backend, les règles de prix et les groupes clients inchangés. Le layer frontend fonctionne indépendamment du moteur de rendu du thème, donc un patch Magento ne déclenche pas automatiquement un test de non-régression côté frontend. La compatibilité des extensions, un point de friction classique avec 30 à 80 extensions par boutique, se réduit au contrat d'API plutôt qu'au rendu du thème.
Ce que tu gagnes
- Dimension | Approche fork de thème | Frontend découplé
- Temps par nouvelle fonctionnalité B2B | Semaines (template PHTML, patch JS, tests) | Jours (ajustement de composant)
- Charge de maintenance | Augmente à chaque bloc custom | Centralisée dans une bibliothèque d'interface
- Risque lié aux patches | Chaque patch Magento déclenche un retest frontend | Frontend découplé du moteur de rendu du thème
- Montée en charge par compte | Nouveaux cas particuliers = nouveaux templates | Nouveaux comptes = nouvelle configuration de composant
FAQ
Dois-je passer à Adobe Commerce pour mes besoins frontend B2B ? Non. La complexité du frontend se résout indépendamment de l'édition backend. Si tu manques vraiment de hiérarchies de comptes ou d'un circuit de devis complet, c'est un sujet backend à part, pas une raison de retarder le découplage du frontend.
Combien de temps prend la bascule ? Les migrations accompagnées par les fondateurs se bouclent généralement en quelques semaines pour une boutique mono-store. Pour des configurations multi-comptes ou multi-marques, l'effort évolue linéairement avec le nombre de variantes, pas avec la complexité du thème.
Quel est le coût comparé à une migration Hyva ? Les détails de nos tarifs sont sur laioutr.com/pricing. À titre de comparaison, une migration Hyva seule prend typiquement six semaines à huit mois, selon la pile de modules custom, avant même de construire une nouvelle fonctionnalité B2B.
Que deviennent mes extensions B2B existantes ? Les extensions qui gèrent une logique purement backend (règles de prix, workflows de validation) restent inchangées. Celles qui gèrent le rendu frontend sont remplacées progressivement par des composants dans la bibliothèque d'interface, dans l'ordre qui économise le plus de maintenance à ton équipe en premier.
Prochaines étapes
Si ton équipe Magento débat actuellement entre une migration Hyva, une construction PWA Studio ou un replatforming complet : réserve un appel de 30 minutes et regardons ensemble où se situe précisément ta charge de frontend, et si elle peut se résoudre sans changer de backend.
À propos de l'auteur : Marcel Thiesies, Co-Fondateur de Laioutr, accompagne les marchands B2B sur Magento dans la modernisation de leur frontend indépendamment du backend.