Thèmes multiplateformes, stratégie et tendances du commerce électronique

Un portail de commerce électronique B2B est un système de commande accessible uniquement après connexion, et non un site web doté d'un écran de connexion. Son rôle est de permettre à un compte d'entreprise de consulter les tarifs contractuels, l'historique des commandes, les listes enregistrées et les conditions de paiement, en s'appuyant sur les données stockées dans le système ERP, et non dans la vitrine en ligne. Dès que l'une de ses neuf fonctionnalités renvoie une information erronée, le titulaire du compte décroche son téléphone, et le portail a alors échoué dans sa seule et unique mission.

Pour un directeur du commerce électronique qui doit déterminer comment allouer son prochain budget de développement, cette distinction importe bien plus que n’importe quelle liste de fonctionnalités qu’un fournisseur pourrait vous présenter. Chaque fonctionnalité d’un portail de commerce électronique B2B revient en réalité à se demander d’où provient une donnée, à qui elle appartient et quelles conséquences cela aurait si cette propriété n’était pas respectée. Les pages des fournisseurs vous diront ce que fait le portail. Elles ne vous diront pas de quoi il dépend ni ce que coûte sa mise en place, et ce sont pourtant ces informations qui déterminent réellement comment vous organisez les étapes d’un projet.

Ce guide détaille les neuf fonctionnalités attendues par vos clients, les éléments sur lesquels chacune d’entre elles repose, ainsi qu’une estimation réaliste de l’effort nécessaire, exprimé en jours-développeurs, pour les mettre en œuvre sur Adobe Commerce, Shopify Plus et BigCommerce. Nous avons développé ces systèmes pour des fabricants et des distributeurs à travers l’Amérique du Nord, et la fonctionnalité qui est toujours sous-estimée est justement celle que la plupart des démonstrations des fournisseurs omettent complètement : que se passe-t-il lorsque l’ERP et la vitrine en ligne ne sont pas synchronisés ?

Qu'est-ce qu'un portail de commerce électronique B2B et en quoi diffère-t-il d'une boutique en ligne ?

Une vitrine en ligne dotée d'un écran de connexion affiche le même catalogue et les mêmes prix pour tous les visiteurs, puis enregistre le nom et l'adresse de l'utilisateur une fois qu'il s'est connecté. Un portail de commerce électronique B2B fonctionne de manière fondamentalement différente : il extrait les informations relatives aux prix, aux stocks, aux conditions de paiement et à l'historique des commandes à partir d'un système de référence, généralement l'ERP, et présente une version du catalogue spécifique au compte de cette entreprise.

C'est précisément cette distinction qui constitue le cœur de l'argumentation de cet article. Une vitrine personnalise l'expérience. Un portail personnalise les données. Si votre équipe décrit le projet comme consistant à « ajouter des fonctionnalités B2B au site », la discussion sur la portée du projet part du mauvais pied, car la partie la plus complexe ne réside pas dans l'interface utilisateur, mais dans le pipeline de données qui se cache derrière.

Quelles sont les 9 attentes des clients vis-à-vis d'un portail de commerce électronique B2B ?

Tous les portails de commerce électronique B2B que nous avons développés répondent finalement aux neuf mêmes attentes des acheteurs, quels que soient le secteur d’activité ou la plateforme. Chacun d’entre eux suit le même schéma en quatre parties : ce que fait l’acheteur, quel système contient les données de référence, les conditions à remplir pour que la fonctionnalité fonctionne, et une fourchette d’effort de développement exprimée en jours-développeurs.

1. Tarification contractuelle et catalogues spécifiques à chaque compte. L'acheteur se connecte et voit le tarif qui lui a été négocié, et non le prix catalogue. Source des données : le moteur de tarification de l'ERP (barèmes de prix clients, niveaux contractuels). Condition préalable : une mise en correspondance claire entre les clients et les barèmes de prix dans l'ERP. Charge de travail : 15 à 30 jours-développeur pour la couche de synchronisation, charge augmentée par la présence de plusieurs barèmes de prix par client ou par une tarification multidevise.
2. Historique des commandes. L'acheteur consulte l'historique de ses commandes par date, par produit ou par statut. Source des données : la base de données de la boutique en ligne pour les commandes passées en ligne, le progiciel de gestion intégré (ERP) pour les commandes passées par téléphone ou via EDI. Prérequis : une liste définie des canaux de commande devant être pris en charge. Durée : 5 à 15 jours pour l'historique des commandes en ligne uniquement, jusqu'à 25 jours si l'on inclut les canaux provenant de l'ERP.
3. Repasser une commande à partir de l'historique. L'acheteur retrouve une commande passée et reconstitue son panier en un clic. Source des données : historique des commandes, revalidé en fonction des prix et des stocks en temps réel. Condition préalable : les produits de la commande d'origine doivent toujours être disponibles à la vente. Délai : 5 à 10 jours.
4. Listes enregistrées. L'acheteur conserve une liste nommée des articles qu'il commande régulièrement. Source des données : la boutique en ligne pour la liste elle-même, le progiciel de gestion intégré (ERP) pour les prix au moment de l'ajout au panier. Condition préalable : validation des prix en temps réel ou quasi-temps réel. Durée de réalisation : 10 à 25 jours.
5. Devis sur commande. L'acheteur demande un prix ou des quantités sur mesure et transforme un devis validé en commande. Source des données : le processus de création de devis de l'équipe commerciale, les données de coûts provenant de l'ERP. Condition préalable : un processus de validation défini du côté du vendeur. Délai : 20 à 40 jours.
6. Chaînes d'approbation. Une commande est transmise à un responsable avant d'être transmise au vendeur. Source des données : la hiérarchie de l'entreprise configurée dans le portail. Condition préalable : cette hiérarchie et ses limites de dépenses doivent être documentées avant le début du développement. Durée : 25 à 50 jours, prolongée en fonction du nombre de niveaux d'approbation.
7. Saisie du numéro de bon de commande. L'acheteur saisit son numéro de bon de commande interne lors du paiement. Source des données : saisie lors du paiement, enregistrée en association avec la commande dans l'ERP. Condition préalable : l'ERP doit disposer d'un champ prêt à recevoir cette information. Délai de mise en œuvre : 3 à 8 jours.
8. Conditions de crédit et visibilité sur le solde. L'acheteur peut consulter sa limite de crédit et son crédit disponible. Source des données : exclusivement le système ERP. Condition préalable : un calendrier de synchronisation validé par l'équipe financière. Durée de mise en œuvre : 15 à 30 jours.
9. Accès aux factures et paiement sur compte. L'acheteur consulte ses factures en cours et effectue le paiement via son compte. Source des données : l'ERP, qui génère des factures que la boutique en ligne ne voit jamais directement. Prérequis : une passerelle de paiement prenant en charge les virements ACH ou les paiements à échéance. Durée de mise en œuvre : 20 à 35 jours.

La tarification contractuelle et les catalogues spécifiques à chaque compte sont prioritaires

La tarification des contrats constitue le fondement sur lequel reposent les huit autres fonctionnalités, car presque tout le reste, de la commande de réapprovisionnement à la facturation, part du principe que l'acheteur voit déjà le bon prix. Si cette étape est mal gérée, toutes les fonctionnalités en aval en subissent les conséquences.

Sur Adobe Commerce B2B, cette fonctionnalité s'inscrit dans le cadre des comptes d'entreprise et des catalogues partagés : un catalogue partagé, doté de sa propre tarification, est attribué à chaque compte d'entreprise, et cette structure est native à la plateforme. Shopify Plus gère cela via des profils d'entreprise et des catalogues B2B, qui prennent en charge une tarification personnalisée par entreprise, mais nécessitent tout de même une couche de synchronisation pour rester à jour avec l'ERP. BigCommerce utilise des groupes de clients liés à des listes de prix, avec la même dépendance vis-à-vis de l'ERP.

Voici le type d’échec que nous observons le plus souvent, et qu’il convient de nommer concrètement : une modification de prix est enregistrée dans Epicor Prophet 21, personne ne déclenche la synchronisation avec la vitrine en ligne, et le portail continue d’afficher l’ancien tarif pendant un cycle de facturation supplémentaire. L’acheteur passe commande au prix affiché, la facture indique le nouveau tarif, et votre équipe commerciale interne passe l’appel suivant à expliquer cet écart au lieu de prendre la commande. C’est pourquoi nous considérons l’intégration ERP comme une phase de projet à part entière, et non comme un simple élément de la mise en place du portail. Notre analyse des modèles d’architecture d’intégration ERP et de la fréquence de synchronisation aborde l’architecture de synchronisation de manière plus approfondie, et notre analyse de l’intégration d’Epicor Prophet 21 détaille spécifiquement ce que cette synchronisation des prix implique du côté de l’ERP.

Les commandes répétées, l'historique des commandes et les listes enregistrées sont les facteurs qui favorisent les connexions répétées

Si la tarification contractuelle constitue la base, ce sont les fonctions de réapprovisionnement, l'historique des commandes et les listes enregistrées qui déterminent si un client revient régulièrement sur l'espace client plutôt que d'appeler votre équipe commerciale interne par habitude. Ces trois fonctionnalités sont liées mais distinctes, et les équipes mettent souvent en place l'une d'entre elles en partant du principe que les deux autres suivront automatiquement. Or, ce n'est pas le cas.

L'historique des commandes correspond aux données. La commande récurrente est l'action effectuée sur ces données. Les listes enregistrées constituent une troisième structure à part entière, conçue pour les acheteurs qui commandent les mêmes 20 références chaque mois et ne souhaitent pas les rechercher à chaque fois. Ces trois éléments reposent sur une expérience de recherche capable de gérer un catalogue comportant un grand nombre de références sans obliger l’acheteur à faire défiler des résultats non pertinents. C’est là que l’infrastructure de recherche d’une plateforme, telle qu’OpenSearch sur Adobe Commerce, prend une importance bien plus grande que ne le pensent la plupart des équipes. Nous abordons cette dépendance plus en détail dans notre article consacré à la manière dont la recherche e-commerce B2B gère les catalogues comportant un grand nombre de références.

Adobe Commerce B2B prend en charge ces trois fonctionnalités de manière native grâce aux listes de demandes d'achat et à la commande rapide. BigCommerce B2B Edition couvre également ces trois fonctionnalités de manière native grâce aux listes d'achats, au bloc-notes de commande rapide et à la fonction « racheter ». Shopify prend en charge de manière native les listes de commande rapide et les réapprovisionnements à partir des comptes clients, mais les listes enregistrées nécessitent toujours une application ou un développement sur mesure, car la plateforme ne dispose pas d'équivalent natif aux listes de demandes d'achat.

Les devis, les validations et les numéros de bon de commande sont les exigences du portail de commande B2B que personne ne présente lors des démonstrations

Ces trois fonctionnalités apparaissent rarement lors d'une démonstration commerciale, car elles sont conçues pour créer des obstacles, et non pour gagner en rapidité. Un portail de commande B2B qui les ignore peut tout de même sembler complet lors d'une présentation. Mais il ne résiste tout simplement pas à l'épreuve d'un véritable service des achats.

Le devis à la commande existe parce que les prix B2B sont négociés, et non fixes. Un acheteur demande un tarif pour une grande quantité, un responsable commercial l’approuve ou propose une contre-offre, et le devis accepté devient une commande. Les chaînes d’approbation existent car la personne qui passe la commande et celle autorisée à engager les dépenses sont souvent différentes ; un portail de commande B2B incapable d’acheminer une commande pour validation sera contourné dès que le responsable des achats s’en rendra compte. La saisie du numéro de bon de commande est la plus simple des trois, mais elle est incontournable pour tout compte disposant de son propre système interne de suivi des achats : le champ doit être présent lors du paiement, et l’ERP doit accepter les données qui y sont saisies.

Adobe Commerce B2B prend en charge de manière native les devis négociables et les validations de bons de commande, ce qui constitue l'un de ses principaux atouts pour les comptes appliquant des processus d'approvisionnement formels. BigCommerce B2B Edition intègre une fonctionnalité native de création de devis, tandis que Shopify propose une solution similaire en permettant de soumettre les commandes sous forme de brouillons pour validation. Les deux plateformes prennent en charge les numéros de bon de commande lors du paiement, mais la mise en place de chaînes de validation hiérarchiques avec des limites de dépenses nécessite généralement une application ou un développement sur mesure sur chacune d'entre elles.

Pourquoi les conditions de crédit, les factures et les paiements sur compte sont-ils importants dans un portail client B2B ?

La gestion des crédits et la facturation sont les fonctionnalités les plus susceptibles d’être reportées à une phase ultérieure, et ce sont aussi celles qui importent le plus aux équipes financières. Un portail client B2B qui affiche des tarifs précis mais masque la situation de crédit du compte ne résout que la moitié du problème pour un acheteur habitué à appeler le service des comptes clients pour vérifier son solde.

Aucune des trois plateformes sur lesquelles nous nous appuyons n'affiche nativement les données de crédit issues de l'ERP. Ces données (limites de crédit, soldes impayés, crédit disponible) sont, par nature, stockées dans l'ERP, et un portail client B2B doit les récupérer via une intégration plutôt que d'en stocker une copie localement. La fonctionnalité « Paiement sur compte » d’Adobe Commerce B2B gère bien cet aspect des conditions de paiement, en permettant à un compte d’entreprise d’effectuer des achats à crédit, mais la liste des factures en temps réel nécessite tout de même une synchronisation avec des systèmes tels que NetSuite OneWorld, SAP Business One ou Sage Intacct. Si la fréquence de synchronisation n’est pas correctement définie, le portail client B2B affiche un solde qui est déjà obsolète au moment où l’acheteur le consulte.

Combien coûte la mise en place d'un portail en libre-service B2B sur Adobe Commerce, Shopify Plus et BigCommerce ?

C'est sur la question du coût que la plupart des discussions concernant un portail en libre-service B2B deviennent floues, car « ça dépend » n'est pas un chiffre qu'un directeur du commerce électronique peut inscrire dans une demande de budget. Voici comment les neuf fonctionnalités se répartissent concrètement entre les trois plateformes sur lesquelles nous nous appuyons :

Capacité	Adobe Commerce	Shopify Plus	BigCommerce	Avertissement
Tarifs contractuels et catalogues	Natif	Natif	Natif	Pour ces trois éléments, la synchronisation avec l'ERP doit encore être mise en place séparément.
Historique des commandes	Natif	Natif	Natif	Commandes en ligne uniquement ; l'historique issu du système ERP nécessite une synchronisation personnalisée sur les trois plateformes.
Réorganiser	Natif	Natif	Natif	Shopify via les comptes clients ; BigCommerce via l'édition B2B (nouvel achat)
Listes enregistrées	Native (listes de demandes d'achat)	Personnalisé	Natif	Il n'existe pas d'équivalent natif sur Shopify Plus
Devis sur demande	En langue maternelle (devis négociables)	Personnalisé	Native (édition B2B)	La fonctionnalité de devis de BigCommerce nécessite spécifiquement l'application « B2B Edition »
Chaînes de validation	Natif (bons de commande)	Personnalisé	Personnalisé	Adobe est la seule option native parmi les trois
Saisie du numéro de bon de commande	Natif	Natif	Natif	Intégré d'origine sur les trois ; pour rendre ce champ obligatoire sur Shopify, une personnalisation est nécessaire.
Visibilité sur le crédit et le solde	Personnalisé	Personnalisé	Personnalisé	Une intégration ERP indépendante de la plateforme
Accès aux factures et paiement par compte client	Native (paiement sur compte) + synchronisation avec un ERP personnalisé	Personnalisé	Personnalisé	Même la fonctionnalité native d'Adobe nécessite une synchronisation des factures côté ERP

Le coût réel d’un portail B2B en libre-service réside dans les modules « personnalisés », et non dans la licence ou le thème. Les choix en matière de front-end ont également leur importance : les équipes qui développent sur Adobe Commerce l’associent souvent à Hyvä pour garantir des performances front-end gérables à grande échelle, et la couche de synchronisation avec l’ERP est fréquemment construite sur une plateforme iPaaS telle qu’Alumio plutôt que sur un connecteur entièrement personnalisé, ce qui réduit les délais de mise en œuvre des fonctionnalités liées aux crédits et aux factures. Pour une comparaison plus complète des avantages offerts par chaque plateforme dans le cadre d’un projet B2B, consultez notre comparatif des plateformes de e-commerce B2B.

Laquelle de ces 9 capacités ne devriez-vous pas développer au cours de la première phase ?

Toutes les fonctionnalités ne doivent pas nécessairement faire partie du périmètre de lancement, et la réponse honnête pour trois d'entre elles est la suivante : ne les développez pas pour l'instant.

1. Devis à la commande. Mettre en place le processus de devis à la commande avant celui de réapprovisionnement est l'erreur de séquencement la plus courante que nous observons, car le devis s'inscrit dans le flux de travail de l'équipe commerciale, tandis que le réapprovisionnement s'adresse directement à l'acheteur. Lancez le service sans cette fonctionnalité, observez à quelle fréquence les comptes demandent réellement des tarifs personnalisés, puis évaluez-en la portée par rapport à la demande réelle.
2. Chaînes d'approbation. Il s'agit de la fonctionnalité la plus coûteuse de la liste, et elle n'est pertinente que pour les comptes dotés d'une hiérarchie d'achat interne formelle. La plupart des lancements de portails de commerce électronique B2B s'adressent à des comptes de tailles variées, et la mise en place d'un circuit d'approbation pour chaque compte pénalise les plus petits en leur imposant des obstacles inutiles.
3. Accès aux factures et paiement sur compte. Cela suppose avant tout que la synchronisation des données de crédit et des factures soit fiable ; se précipiter avant que ce processus ne fasse ses preuves risque justement de mettre en évidence les divergences de prix et de soldes contre lesquelles ce guide met en garde.

Lancez le service avec les tarifs contractuels, l'historique des commandes, le réapprovisionnement, les listes enregistrées et la saisie des numéros de bon de commande. Toutes les autres fonctionnalités seront intégrées lors de la deuxième phase, en fonction des données d'utilisation réelles recueillies au cours de la première phase.

Comment évaluer si votre portail de commerce électronique B2B remplace les commandes par téléphone ?

Un portail de commerce électronique B2B mis en ligne mais que personne n'utilise est pire que l'absence totale de portail, car il s'agit d'un coût irrécupérable qui nécessite tout de même une maintenance. Trois indicateurs vous permettent de déterminer si le portail remplace réellement les commandes passées par téléphone ou par e-mail, ou s'il ne fait que venir s'ajouter à celles-ci.

1. Part des lignes de commande passées en ligne. Objectif : 55 à 65 % dans les 12 mois suivant le lancement, ce qui correspond aux 63,5 % de commandes enregistrées par voie numérique via le commerce électronique chez les grossistes dont le chiffre d’affaires est supérieur à 15 millions de dollars (rapport de référence WizCommerce 2026 sur le commerce électronique B2B). Il s’agit également de l’indicateur le plus facile à manipuler, car le fait de faire transiter les commandes téléphoniques par le portail au nom de l’acheteur gonfle ce chiffre sans modifier en rien le comportement de ce dernier.
2. Part des comptes connectés par rapport au nombre total de comptes actifs. Objectif : 65 à 75 % à 12 mois. Les deux tiers des responsables des achats B2B effectuent déjà au moins la moitié de leurs achats en ligne (enquête B2B Online Insights et OroCommerce, 2025).
3. Durée moyenne des ventes internes par commande. Objectif : une réduction de 40 à 50 % d'ici 12 mois. Les fournisseurs interrogés par Hobson & Company ont fait état d'une réduction de 80 % du temps consacré à la gestion des bons de commande après être passés à un système de commande B2B intégré.

Si vous souhaitez connaître le modèle de coûts sous-jacent à ces objectifs, notamment la manière dont les frais de traitement par commande sont pris en compte dans le calcul du retour sur investissement, notre article consacré au portail en libre-service B2B explique ce calcul plus en détail.

Par où commencer avec un portail B2B si vos clients continuent d'envoyer leurs commandes par e-mail ?

Si vos comptes continuent d'envoyer leurs bons de commande par e-mail vers une boîte de réception vérifiée manuellement, la première étape à envisager n'est pas la mise en place d'un portail B2B complet. Il s'agit plutôt de réaliser un audit des fonctionnalités en fonction des neuf points présentés dans ce guide : lesquelles vos comptes attendent-ils déjà de la part d'autres fournisseurs, lesquelles votre ERP prend-il réellement en charge aujourd'hui, et laquelle génère le plus d'appels téléphoniques à l'heure actuelle ?

Cet audit met généralement en évidence le même schéma : la tarification des contrats et l’historique des commandes sont les deux fonctionnalités dont l’absence est la plus rapidement remarquée par les clients, et ce sont aussi celles qui sont les plus rapides à mettre en place. Un portail B2B justifie son budget en supprimant les appels que votre équipe traite aujourd’hui, et non en reproduisant la liste des fonctionnalités d’un concurrent. Nous réalisons ce type d’audit auprès des fabricants et des distributeurs avant de définir le périmètre du projet, car cela nous permet de déterminer laquelle des neuf fonctionnalités doit être mise en place en priorité, ce qui modifie généralement le plan d’action.

Assistance