Portail de commande B2B : intégration ERP et tarifs

Un portail de commande B2B donne à vos clients agréés la consultation de leur catalogue et de leurs tarifs, la passation et la répétition de leurs commandes et le suivi de leurs documents, le tout synchronisé avec l'ERP. Délimitez-le par phases : comptes, tarifs et commandes d'abord, paiements et validations ensuite — un portail qui veut tout lancer en une fois prend du retard et se voit peu utilisé.

Qu'est-ce qu'un portail de commande B2B ?

Un portail de commande B2B est un canal web à votre image, dans lequel vos distributeurs et clients professionnels agréés se connectent et traitent eux-mêmes leurs affaires : ils parcourent le catalogue visible pour leur compte, consultent les prix convenus avec eux, composent une commande ou rejouent une commande précédente, et retrouvent les documents rattachés à leur compte — devis, bons de commande, factures, avoirs, livraisons. L'ERP reste le système d'enregistrement ; le portail est la fenêtre par laquelle on le consulte, avec des règles définissant ce que chaque compte a le droit de voir et de faire.

Il vaut de distinguer le portail de trois voisins avec lesquels on le confond souvent :

• Une boutique en ligne. Tarifs de détail, inscription ouverte, paiement par carte. Un portail distributeur fonctionne à l'inverse : l'accès se prononce compte par compte, les prix sont contractuels et le paiement suit les conditions convenues, pas un tunnel de paiement.


• Un espace client sur un site vitrine. Utile pour les téléchargements et les demandes de support, mais sans logique de catalogue, de tarification et de commande, il ne supprime pas un seul appel au service commercial.


• Une liste de prix en PDF envoyée par e-mail. L'état dans lequel vivent la plupart des distributeurs avant l'arrivée d'un portail : exact le jour de l'envoi, fausse la semaine suivante, et introuvable compte par compte.

Tableau des fonctionnalités : essentiel, utile, différable

Les pages de fonctionnalités des éditeurs listent tout d'un seul coup. C'est le cadrage par phases qui garde la première version livrable. Le tableau répartit les fonctionnalités récurrentes en ce dont la première version a besoin, ce que la seconde ajoute généralement, et ce qui peut attendre de vraies données d'usage :

Tableau A : fonctionnalité | rôle | phase (1/2/3) | dépendance ERP

La phase 1 est la version qui change les comportements : si un distributeur peut se connecter, voir ses prix, rejouer la commande du mois dernier et l'intégrer dans l'ERP, le canal téléphone-tableur commence à se fermer de lui-même. Les phases 2 et 3 ajoutent les couches financières et de gouvernance, qui exigent que les décisions de crédit, de finances et d'approbation de l'organisation soient tranchées avant que le logiciel puisse les porter.

Intégration ERP et CRM

L'intégration décide si le portail est le miroir de l'activité ou une brochure avec une connexion. Quatre questions doivent recevoir une réponse écrite avant tout choix d'architecture :

1. Sens de synchronisation. Les données maîtresses — comptes, produits, prix, conditions — circulent de l'ERP vers le portail. Les commandes, demandes de prix et paiements remontent. Tout autre flux a besoin d'un responsable explicite : qui peut modifier un prix, et où vit cette modification ?


2. Fréquence de synchronisation. Traitement de nuit, actualisation périodique en journée, ou quasi temps réel. La règle honnête : les prix et les situations de crédit justifient une synchronisation plus fréquente que les images de produits — une stratégie mixte est donc normale, données critiques plus souvent, contenu de catalogue moins souvent.


3. Gestion des pannes. Quand l'ERP est hors service ou qu'un enregistrement échoue à la validation, que fait le portail : met en file, rejette, ou affiche le dernier état connu avec un avis clair ? L'échec silencieux, c'est le distributeur qui commande au prix de la semaine dernière — et le litige devient le vôtre, pas le sien.


4. Rapprochement. Comment savoir que chaque commande du portail est devenue exactement un document ERP — sans doublon, sans trou, sans enregistrement à moitié converti ? La réponse est un rapport opérationnel que quelqu'un lit chaque jour pendant les premiers mois, et il figure parmi les tests de recette ci-dessous.

Catalogues multilingues et multidevises

Les exportateurs butent tôt sur ces deux questions, et il est moins coûteux de les trancher que de les rattraper.

Langues. Le catalogue exige des traductions pour les noms de produits, les catégories et les documents ; la structure de compte prévoit une préférence linguistique par compte pour que le portail n'oblige pas le même acheteur à choisir à chaque visite. Deux points pratiques : décider qui possède les traductions et leur rythme d'actualisation — un catalogue à moitié traduit se lit pire qu'un catalogue uniquement en anglais pour l'acheteur qui s'en aperçoit — et décider si les documents (devis, factures) suivent la langue de l'interface ou restent dans la langue exigée par votre système financier. Cette seconde question n'est pas technique : une facture dans la mauvaise langue est un problème comptable.

Devises. Des prix convenus dans une devise doivent s'afficher dans cette devise, quelle que soit la localisation du visiteur ; mélanger devise d'affichage et devise contractuelle est le début des litiges. Si un compte échange dans plusieurs devises, la règle doit vivre dans les données de l'ERP, pas dans les réglages du portail, et le portail ne doit jamais être l'endroit où l'on invente une conversion.

Les deux sujets dialoguent avec le plan par phases : un exportateur qui vend sur trois marchés peut lancer la phase 1 dans les langues que ces trois marchés utilisent réellement dans leurs commandes, et ajouter d'autres langues de catalogue quand le marché grandit. La règle générale du travail linguistique sur les sites commerciaux — un responsable, un fichier source, une voie d'actualisation — est posée sur la page de marketing sur internet, et s'applique au catalogue d'un portail de la même manière.

Sécurité et rôles

Un portail est une porte ouverte sur vos données commerciales : les questions de design sont donc des questions d'accès :

• L'accès se prononce, il ne s'auto-attribue jamais. Chaque compte est créé par votre équipe et rapproché d'un compte ERP ; l'alternative — inscription ouverte avec une étape d'approbation — attire les indésirables et brouille qui est client.


• Permissions par rôle. Un acheteur peut composer et transmettre des commandes dans la limite prévue ; un approbateur peut les valider ; un simple lecteur ne peut que consulter les documents. Les limites par rôle font partie des conditions commerciales, pas d'un détail technique ajouté après coup — elles encodent qui, dans l'organisation de votre client, peut l'engager.


• Isolation des comptes. La panne la plus grave de cette catégorie de produit, c'est un distributeur qui voit les prix ou les documents d'un autre. La visibilité des données par compte doit être testée explicitement ; elle fait partie des tests de recette ci-dessous.


• Piste d'audit. Qui a passé la commande, qui l'a approuvée, qui a modifié un prix et quand — conservé en données, pas en fichiers de journaux qu'il faut convainre quelqu'un de lire. Dans le commerce, les litiges se règlent plus souvent par cette piste que par la mémoire.


• Identité et authentification unique. Pour les grands distributeurs, le SSO vers leur propre annuaire est une exigence fréquente qu'il vaut mieux circonscrire tard que tôt — la plupart des comptes vivent très bien avec invitations et mots de passe jusqu'à ce qu'un siège social réclame une fédération.


• Protection des données. Les données clients dans le portail relèvent des mêmes obligations que l'entreprise a déjà pour ses fichiers clients ; pour les opérations turques, c'est le cadre de la KVKK, et pour les clients européens le RGPD, sujet traité en détail sur la page d'externalisation dans le contexte du travail avec un partenaire de développement.

Développement sur mesure ou plateforme ?

Le choix n'est pas « sur mesure contre packagé » dans l'abstrait ; il porte sur la couche que vous achetez réellement.

Tableau B : voie | ce que vous obtenez | ce que vous portez | convient quand

La voie du milieu est choisie par la plupart des exportateurs la première fois, et l'erreur à éviter est de la prendre pour la voie bon marché : un connecteur est un produit maintenu, et son coût est récurrent. Le cadre de décision pour cette question — configurer, acheter ou construire — est traité longuement sur la page ERP sur mesure ou packagé ; ce que cette page ajoute, c'est le test propre au portail : quoi que vous choisissiez, la liste de prix par compte et la commande vers l'ERP doivent être prouvées exactes, et la voie retenue doit être celle qui rend cette preuve au coût récurrent le plus bas.

Déploiement par phases et tests de recette

Un lancement de portail échoue en silence quand « ça marche » veut dire « la démo a marché ». Chaque phase doit porter des tests de recette écrits, exécutés avec de vrais comptes et de vraies données :

1. Visibilité du catalogue par compte. Connectez-vous avec deux distributeurs différents ; chacun voit exactement son propre jeu de produits, sans aucune trace de l'autre. Testé délibérément, pas supposé.


2. Exactitude des prix. Pour un échantillon de comptes et d'articles, le prix du portail égale le prix de l'ERP — y compris les règles qui le sous-tendent (groupe de prix, palier, accord). C'est le test qui protège la relation commerciale ; un prix faux dans un portail est pire qu'un prix faux dans un devis, parce que le client l'a lu comme l'accord en vigueur.


3. Intégrité de la commande. Une commande passée dans le portail devient exactement un document ERP, avec les bons articles, quantités, unités et prix — et le rapport de rapprochement le montre. Testez aussi le chemin de la panne : une commande bloquée par une règle doit le dire clairement plutôt que d'échouer silencieusement.


4. Statuts et documents. Une facture et une livraison enregistrées dans l'ERP apparaissent dans la vue du bon compte, avec le bon statut, dans la fenêtre de synchronisation convenue.


5. Conditions et limites. Crédit et conditions de paiement par compte s'affichent correctement, et là où les règles disent qu'une commande doit être bloquée ou signalée, elle l'est — testé à la frontière, pas dans le confort du milieu.


6. Les gestes du quotidien. Commande répétée, commande rapide par référence et recherche — avec les listes de produits de deux de vos vrais distributeurs, pas le catalogue de démonstration. L'adoption vit ou meurt sur ces trois chemins, et ils coûtent une fraction du développement à bien tester.

Questions fréquentes

Faut-il d'abord un ERP ?

Pas forcément un neuf — mais il faut des données maîtresses quelque part de confiance : comptes, produits, listes de prix et conditions. Si elles ne vivent que dans des tableurs, le portail automatisera les erreurs du tableur compte par compte, ce qui est pire que de rester au téléphone. Dans ce cas, la séquence honnête est d'abord de stabiliser les données (souvent dans un ERP existant sous-utilisé), puis le portail ensuite ; la page Odoo pour les entreprises de commerce traite ce choix côté ERP.

Les clients peuvent-ils avoir leurs propres listes de prix ?

Oui — la tarification par compte est le cœur de cette catégorie de produit, pas une option : groupes de prix, tarifs dégressifs ou accords individuels, tous tenus dans l'ERP et affichés par compte. La règle à laquelle s'accrocher : le portail ne calcule jamais lui-même un prix ; il affiche ce que l'ERP détient, et chaque prix qu'un distributeur voit se rattache à un accord que votre équipe a conclu.

Comment les commandes sont-elles approuvées ?

Deux couches, en général. Dans l'organisation de votre client, l'approbation lui appartient : un acheteur propose, un approbateur valide, éventuellement dans des limites — le portail peut porter ces rôles en phase 3. Dans votre propre organisation, la commande arrive dans l'ERP et suit votre traitement habituel ; le portail ne remplace pas les contrôles de votre service commercial, il supprime la ressaisie et l'appel qui les entourent.

Le portail peut-il gérer plusieurs langues ?

Oui, et il le devrait — mais décidez du périmètre phase par phase. Traductions de catalogue, préférence linguistique par compte et documents traduits sont trois métiers distincts ; lancez la phase 1 avec les langues que vos marchés actifs utilisent dans leurs commandes et ajoutez le reste à la demande réelle. Les points de gouvernance — un responsable pour les traductions, une voie d'actualisation — figurent dans la section multilingue ci-dessus.

À qui appartiennent les données ?

À vous — comptes, prix, commandes, documents et historique restent les enregistrements de l'entreprise, dans l'ERP. Cela mérite d'être écrit dans le contrat avec qui construit le portail : accès à l'hébergement, code source ou configuration, et export de vos données à la sortie, le tout nommé. La page d'externalisation couvre la propriété intellectuelle et les clauses de sortie dans le contexte plus large du contrat de développement.

Comment intégrer les nouveaux distributeurs ?

Commencez par les comptes qui commandent le plus, invitez-les personnellement, et donnez-leur trois choses dans le premier message : leur identifiant, leur liste de prix visible à l'écran, et une personne à appeler. Puis observez le signal d'adoption qui compte vraiment — pas les connexions, mais la part du volume de commande répétée qui arrive par le portail. Le fonctionnement en parallèle (commande passée dans le portail, puis confirmée par téléphone) est normal pendant des semaines ; il s'arrête quand le portail est prouvablement exact sur les prix et les documents, c'est à quoi servent les tests de recette ci-dessus.

Sources et normes

• L'ensemble de fonctionnalités typique décrit ici (comptes, listes de prix par compte, commande répétée, factures et avoirs, visibilité par compte, rôles avec limites, conditions nettes, passerelles de paiement) suit les listes de capacités décrites par les éditeurs pour les portails de commande B2B en général ; aucun résultat de performance, coût ni calendrier n'est revendiqué sur cette page.
• Les schémas de déploiement (portail natif ERP ; plateforme de commerce telle que Shopify synchronisée à l'ERP par de la middleware ou des connecteurs) sont décrits comme les deux routes récurrentes ; aucune partenariat avec un éditeur de plateforme n'est revendiqué.
• Les énoncés de processus et de gouvernance suivent les pages de ce site : ERP sur mesure ou packagé, liste de contrôle d'appel d'offres pour prestataires, Odoo pour les entreprises de commerce et externalisation informatique depuis la Türkiye (obligations de protection des données, propriété intellectuelle et clauses de sortie, conception du pilote).
• Aucun exemple de client, budget de portail ni durée de projet n'apparaît sur cette page ; le périmètre, les phases et les conditions commerciales se fixent projet par projet dans le devis.

Pages associées

Développement logiciel · ERP sur mesure ou packagé · Liste de contrôle d'appel d'offres pour prestataires · Odoo ERP pour les entreprises de commerce · Marketing sur internet · Demander un devis