Un acheteur se connecte au portail et voit un produit que son contrat exclut. Le prix affiché diffère du devis signé, puis le bon de livraison reste introuvable. Le commercial explique que « l’ERP n’est pas encore à jour » et le support envoie le document par email. Le problème n’est plus cosmétique : le portail publie une promesse que l’entreprise ne sait pas tenir.
Les catalogues, tarifs et pièces client semblent être trois écrans indépendants. Dans les faits, ils dépendent de la même identité : compte, entité juridique, site livré, contrat, période et rôle de l’utilisateur. Si une seule dimension manque, le produit visible, le prix calculé ou le document accessible peut appartenir au mauvais périmètre.
Le vrai enjeu est de construire une lecture contractuelle explicable, pas de recopier l’ERP sur le Web. Le portail doit dire ce que ce client peut commander maintenant, à quelles conditions et avec quelle preuve. Toute donnée en retard ou ambiguë reçoit un comportement sûr, plutôt qu’un écran apparemment complet.
Une démarche de développement web sur mesure relie cette promesse aux systèmes propriétaires, aux contrôles d’accès et au run. La méthode suivante part des décisions avant de choisir les pages.
Définir la promesse du portail B2B
Écrivez les actions que le client doit réaliser sans médiation : rechercher une référence, connaître sa condition, commander, télécharger une preuve ou suivre un dossier. Pour chaque action, précisez source, fraîcheur, responsable et mode dégradé. « Consulter le catalogue » reste trop large si le client ne sait pas si le produit est commandable sur son site.
La promesse distingue information indicative et donnée opposable. Une disponibilité peut être estimée, alors qu’un prix validé dans le panier engage le vendeur selon ses règles commerciales. Un document généré à la volée n’a pas la même valeur qu’une facture émise et archivée. L’interface rend ces nuances lisibles.
Choisir les parcours avant le tableau de bord
Rejouez les dix dernières demandes traitées par email : ajout d’un utilisateur, recherche de tarif, renouvellement de document, litige de livraison. Leur fréquence ne suffit pas ; mesurez aussi délai, risque et nombre d’équipes mobilisées. Le premier lot vise une boucle complète et exploitable.
Fermer comptes, sites et utilisateurs
Un groupe client possède plusieurs comptes de facturation, sites de livraison et contrats. L’utilisateur appartient à une organisation, mais agit dans un ou plusieurs périmètres. Le modèle sépare personne, identité de connexion, compte commercial, entité légale et site. Les aliases externes restent reliés à leur source.
L’invitation part d’un administrateur habilité ou d’un workflow interne. Elle expire, vérifie le domaine lorsque pertinent et impose une authentification proportionnée. Un départ révoque les sessions et délégations. Les comptes partagés empêchent d’attribuer les commandes et doivent disparaître des parcours sensibles.
Ne jamais déduire le périmètre de l’URL
Le serveur recalcule l’autorisation pour chaque ressource à partir de l’identité et du contexte. L’Authorization Cheat Sheet d’OWASP recommande notamment le refus par défaut et la validation des permissions à chaque requête. Masquer un lien ne protège ni un document ni un prix.
Composer le catalogue autorisé
Le catalogue visible résulte de produits actifs, zones, contrats, agréments, canaux et dates. Il ne doit pas être une copie filtrée une fois par nuit sans indication. Le service de lecture reçoit compte, site, rôle et instant ; il retourne les références, variantes et restrictions applicables avec une version.
Distinguez données produit partagées et offre client. Le nom, la fiche technique et les unités appartiennent au produit ; l’assortiment, le minimum de commande et la condition logistique appartiennent à l’offre. Cette séparation évite de dupliquer toute la fiche par contrat.
Traiter recherche et produits retirés
La recherche ne doit pas révéler une référence interdite par suggestion ou compteur. Un produit retiré reste retrouvable depuis une ancienne commande si les droits l’autorisent, mais il n’est plus ajoutable. Une substitution commerciale est explicite et ne réécrit pas l’historique.
Calculer un prix contractuel explicable
Le prix peut dépendre du compte payeur, du site, de la référence, de la quantité, de la devise, de la date et d’une condition négociée. Le moteur retourne montant, taxes ou règles associées, devise, version et explication. Le panier conserve la décision utilisée ; il ne recalcule pas silencieusement une commande déjà confirmée.
Fermez la priorité entre contrat, grille, promotion et exception. Une remise manuelle possède auteur, motif, plafond et durée. Un prix manquant ne devient pas zéro ni « sur demande » sans workflow : le portail bloque la confirmation ou sollicite un devis en expliquant la suite.
Qualifier cache et fraîcheur
Le cache inclut toutes les dimensions de variation et une durée compatible avec la promesse. La RFC 9111 sur la mise en cache HTTP rappelle le rôle des directives et de la revalidation. Un prix personnalisé ne doit jamais être partagé entre comptes par une clé incomplète.
Publier des documents opposables
Classez facture, avoir, bon de livraison, certificat, contrat et documentation produit. Chaque type possède propriétaire, identifiant, version, période, visibilité et durée de conservation. Le portail affiche l’état : provisoire, émis, remplacé ou annulé. Un fichier portant le même nom ne remplace pas une version opposable.
Le téléchargement vérifie le droit au moment de la requête, puis délivre un lien court et signé ou diffuse le flux. Les URLs permanentes devinables sont exclues. Les métadonnées sensibles ne restent pas dans le nom du fichier. Les accès aux pièces financières ou réglementaires sont journalisés.
Prévoir recherche et preuve de provenance
L’utilisateur cherche par numéro métier, période, commande et site, pas par arborescence interne. La fiche indique émetteur, date, référence et document remplacé. Si la génération échoue, le dossier reste en attente avec une action de reprise ; aucun PDF vide n’est présenté comme disponible.
Cas concret : réseau de maintenance
Un fabricant équipe un réseau de cent vingt agences. Chaque agence peut commander les pièces autorisées pour ses équipements, avec prix négocié par groupe et exceptions régionales. Les responsables téléchargent factures ; les techniciens accèdent aux notices et certificats sans voir les conditions financières.
Le pilote porte trois groupes, huit sites et quatre rôles. Il couvre produit hors assortiment, prix expiré, utilisateur multi-site, facture d’un autre compte et certificat remplacé. Le catalogue est calculé par site ; le prix est fixé lors de la confirmation ; les documents héritent du périmètre de leur objet, jamais d’un dossier générique.
Le go local exige zéro fuite sur deux cents tentatives croisées, zéro panier confirmé sans version de prix et une explication support obtenue depuis la commande. Le seuil de fraîcheur du catalogue est fixé à partir du délai réel de retrait des pièces dangereuses. Ces valeurs qualifient ce pilote, pas une promesse universelle.
Synchroniser sans créer plusieurs vérités
Attribuez l’autorité par donnée : PIM pour le produit, moteur tarifaire ou ERP pour les conditions, GED ou facturation pour le document émis. Le portail maintient des projections de lecture avec identifiant canonique, version et fraîcheur. Il ne devient pas maître parce qu’un utilisateur corrige un libellé.
Les événements alimentent les projections par boîte de sortie. Les consommateurs sont idempotents et refusent une version ancienne. Une réconciliation compare comptes, offres, tarifs actifs et documents. Les inconnus rejoignent une file avec motif, propriétaire et délai, plutôt qu’une mise à jour « dernier arrivé gagne ».
Gérer le mode dégradé
Si le tarif est indisponible, alors la recherche peut rester ouverte mais la confirmation attend ou transforme le panier en demande de devis. En revanche, une copie récente du catalogue peut servir la navigation si sa fraîcheur est visible. Le comportement dépend de l’engagement, pas de la seule disponibilité technique.
Implémenter des contrats testables
Les entrées du service d’offre sont compte, site, utilisateur, produit, quantité et date ; les sorties sont autorisation, disponibilité, prix, version et motifs. Chaque responsabilité reste séparée : identité, catalogue, tarification et documents. Les dépendances sont encapsulées par adaptateur et leurs délais ont un seuil explicite.
La commande journalise identité, corrélation, version de prix et décision. Le monitoring suit refus, cache, prix manquants, retard des projections, liens expirés et erreurs de génération. Le retry est idempotent. Le rollback désactive une nouvelle règle ou projection sans effacer les commandes confirmées ni leurs preuves.
Tester les contrats et les frontières
Les tests unitaires couvrent règles d’assortiment et priorité tarifaire. Les tests de contrat vérifient schémas, erreurs et nouvelles valeurs. Les scénarios d’intégration provoquent concurrence, message rejoué, cache mal revalidé et document remplacé. La recette utilise les droits réels de chaque rôle.
Observer le service et préparer la reprise
Mesurez recherche sans résultat, produits masqués, calculs refusés, écarts de panier, téléchargements échoués et demandes transférées au support. Reliez chaque indicateur à une action. Une hausse des « prix indisponibles » doit distinguer contrat absent, dépendance en panne et contexte incomplet.
Contre-intuitivement, un portail qui bloque explicitement peut être plus fiable qu’un portail toujours disponible avec un prix supposé. Le runbook part de l’identifiant métier, retrouve versions et corrélation, puis propose une reprise bornée. Le support ne modifie pas les tarifs ni les droits en base.
Suivez également le coût de la médiation restante. Pour dix demandes transférées, notez la donnée manquante, l’équipe appelée, le délai et la décision finale. Une hausse après ouverture ne prouve pas l’échec : le portail peut révéler des contrats déjà ambigus. En revanche, la répétition du même motif doit produire une correction de source, une règle ou un contenu d’aide. Le tableau sépare ainsi défaut produit, défaut de donnée et accompagnement légitime, afin de ne pas automatiser une incertitude commerciale.
Pour qui ce portail est pertinent
La démarche convient aux industriels, grossistes, réseaux et services B2B où assortiments, conditions et documents varient par compte ou site. Elle mobilise commerce, ADV, produit, finance, sécurité, intégration et support. Le sponsor doit pouvoir trancher la promesse client, pas seulement financer l’interface.
Un simple espace documentaire n’a pas besoin d’un moteur d’offre. Un catalogue public avec demande de devis peut rester plus sobre. Investissez dans le portail contractuel lorsque les décisions répétées et les erreurs de périmètre justifient identité, règles et run.
Erreurs fréquentes des portails B2B
Copier les écrans internes
L’ERP expose des statuts et codes destinés aux opérateurs. Le client a besoin d’une promesse, d’une cause et d’une action. Construire une projection dédiée évite de publier les conventions internes et les données sans droit.
Mettre le prix dans le catalogue
Cette fusion rend le cache dangereux et mélange produit avec contrat. Gardez une offre contextualisée et une décision de prix versionnée. L’affichage peut réunir les deux sans confondre leurs autorités.
Téléverser des documents dans un dossier commun
Une arborescence ne porte ni périmètre ni cycle de vie. Reliez la pièce à l’objet métier, vérifiez le droit à chaque accès et conservez versions, remplacement et rétention.
Décision : prioriser le premier périmètre
Priorisez le parcours où identité, offre et preuve réduisent une friction coûteuse : recommander une pièce, confirmer un panier ou retrouver une facture. Différez les tableaux de bord généraux. Refusez une fonctionnalité si la source ou l’autorité reste inconnue. Acceptez un mode dégradé seulement s’il ne fabrique pas d’engagement faux.
Si une erreur expose marge, droit ou sécurité, alors réduisez le périmètre et renforcez le contrôle. En revanche, une information indicative peut afficher sa fraîcheur. À éviter : promettre le temps réel sans mécanisme de réconciliation.
- Commencer par un compte, un site et un parcours complet.
- Documenter identité, autorité, prix et preuve attendue.
- Tester les accès croisés et les dépendances en panne.
- Élargir après une recette support sur les données réelles.
Plan d’action sur six semaines
Semaines un à trois : fermer la promesse
Choisissez deux comptes, trois sites et quatre rôles. Rejouez trente demandes récentes. Cartographiez identités, contrats, assortiments, prix et documents. Attribuez chaque donnée et mesurez les délais. Écrivez le mode dégradé et les erreurs visibles avant de dessiner les pages.
Construisez la matrice d’accès, la règle d’offre et les contrats d’intégration. Préparez les projections, versions et réconciliation. Sélectionnez les cas hostiles : compte fermé, site partagé, tarif expiré, document remplacé et utilisateur révoqué.
Semaines quatre à six : piloter et perturber
Ouvrez la lecture du catalogue et le calcul en observation. Comparez au traitement ADV. Activez un panier et une famille documentaire. Provoquez doublon, message ancien, cache incomplet, dépendance indisponible et accès direct par URL. Vérifiez chaque refus et l’absence de fuite.
Faites exécuter recherche, confirmation et téléchargement par les clients pilotes, puis diagnostic par le support. Balancez commandes, versions tarifaires et pièces. Le rollback ferme les nouvelles confirmations mais maintient la lecture sûre et les commandes déjà conclues.
Après un cycle représentatif, rapprochez transferts au support, prix manquants, délais et erreurs de périmètre. Étendez si la promesse est explicable et si les projections se réconcilient ; sinon, corrigez identité ou autorité avant d’ajouter des comptes.
La revue de sortie prend cinq commandes déjà livrées et cinq paniers abandonnés. Elle reconstitue pour chacun le catalogue visible, la version de prix, les droits et les documents disponibles au moment de la décision. Toute impossibilité reçoit une cause et un propriétaire. Les clients pilotes confirment les libellés et le comportement dégradé ; les opérations confirment que la reprise ne demande aucun accès hors procédure. Cette recette évite qu’un taux de succès global masque une seule promesse contractuelle impossible à défendre.
- Nommer les décisions et les périmètres.
- Contractualiser catalogue, prix et documents.
- Tester accès, fraîcheur, panne et reprise.
- Ouvrir progressivement depuis les preuves du run.
Approfondir droits et données
Gouverner les versions d’offre
Conservez un catalogue des règles actives par famille, contrat et période. Chaque modification nomme son auteur métier, sa date d’effet, les comptes concernés et le plan de retrait de l’ancienne version. Avant activation, calculez l’écart sur un échantillon de paniers historiques sans modifier les commandes. Les différences attendues sont signées ; les autres bloquent le déploiement. Cette pratique donne aux équipes commerciales une preuve des effets et évite de découvrir un changement de priorité tarifaire depuis une réclamation.
Les documents de vente et les écrans d’administration doivent lire la même décision. Un devis généré depuis une ancienne grille ne devient pas automatiquement une commande au nouveau prix : le produit demande une confirmation ou applique la règle contractuelle prévue. Le journal relie le devis, la version d’offre et la commande. Le support peut ainsi expliquer pourquoi deux paniers créés à des dates différentes produisent des montants distincts, sans supposer une anomalie de synchronisation.
Préparer la montée en charge
Mesurez séparément recherches, calculs de prix et téléchargements, car leurs profils diffèrent. Une campagne peut saturer le catalogue tandis qu’une clôture comptable concentre les factures. Les tests de charge utilisent des distributions réalistes et vérifient surtout l’isolation des comptes dans le cache. Les objectifs de latence sont fixés à partir du parcours et de la dépendance ; une dégradation ne doit jamais remplacer un refus par un prix ou un document d’un autre périmètre.
Conservez enfin un budget de complexité par contrat. Une condition utilisée par un seul compte peut rester une politique locale versionnée ; une règle répétée mérite une capacité du moteur. La revue examine fréquence, marge protégée, incidents et coût de test avant de promouvoir. Elle retire les exceptions expirées et vérifie que les commandes historiques restent interprétables. Cette discipline empêche le portail de devenir l’endroit où toutes les négociations temporaires survivent sans propriétaire.
Fermer les périmètres d’accès
Le guide sur les droits par compte, site ou filiale approfondit rôles, attributs, délégations et tests négatifs.
Réconcilier portail et CRM
Poursuivez avec la cohérence entre espace client et CRM pour définir sources, propositions et conflits.
- Une identité contextualisée.
- Une offre versionnée.
- Une preuve accessible au bon périmètre.
Conclusion : montrer la bonne promesse
Un portail B2B fiable ne reproduit pas toutes les données internes. Il compose une offre pour un compte, un site, un rôle et un instant. Le catalogue, le prix et le document restent reliés à leurs autorités et à leurs versions.
Les contrôles côté serveur, les projections réconciliées et les comportements dégradés protègent l’engagement. L’observabilité donne au support un diagnostic à partir de la commande, sans correction opaque.
Commencez par le parcours qui génère aujourd’hui le plus d’emails ou d’erreurs contractuelles. Fermez son identité et sa preuve, puis testez-le avec quelques comptes. Ce socle vaut davantage qu’un portail large mais contestable.
- La bonne offre.
- Le bon prix.
- La bonne preuve.
Dawap peut accompagner ce produit de développement web sur mesure : cadrage, droits, architecture, intégrations, portail, recette et préparation du run.
