Séparer le droit de commander de l’accès aux prix B2B
Une personne autorisée à voir les prix de l’entreprise et à préparer un achat n’a pas forcément besoin de pouvoir envoyer la commande.
Pour définir les droits d’un portail B2B, partez des activités : consulter les prix de l’entreprise, rassembler les besoins, envoyer une commande. Une même personne peut remplir ces tâches. La simple connexion ne doit toutefois pas signifier que ces droits sont équivalents.
Je recommande de décider explicitement de l’accès aux prix et du droit de commander avant de créer un rôle général de « client professionnel ». Sinon, une personne chargée uniquement de chiffrer un projet risque aussi d’obtenir la possibilité d’envoyer des commandes.
Un compte d’entreprise, des tâches différentes
Une entreprise événementielle fictive souhaite acheter des fournitures pour ses stands de salon sur un portail. L’équipe de planification doit voir les prix convenus et préparer un panier. Le service achats doit examiner les besoins et envoyer la commande. Le tableau décrit la règle souhaitée pour cet exemple, sans garantir qu’un logiciel de boutique la propose en standard.
Affectation | Voir les prix de l’entreprise | Préparer un panier | Envoyer une commande |
|---|---|---|---|
Planification des projets de l’entreprise | oui | oui | non |
Service achats de l’entreprise | oui | oui | oui |
Sans affectation à l’entreprise | non | non | non |
La planification a besoin d’un moyen de transmission clair, par exemple un brouillon enregistré que le service achats autorisé peut ouvrir. Partager un mot de passe ne remplace pas cette transmission. Avant l’envoi, les achats doivent voir la sélection actuelle et les prix applicables.
La plateforme doit couvrir les actions nécessaires
Les noms des rôles ne suffisent pas pour choisir un système. Shopify décrit par exemple deux rôles clients B2B de portée différente, qui peuvent tous deux passer commande. On ne peut pas en déduire l’existence d’un rôle limité à la consultation des prix pour notre exemple. Vérifiez les droits réels et le mode de transmission pris en charge par le système envisagé ; toute extension nécessaire fait partie du périmètre du projet.
La décision doit aussi être appliquée sur le serveur. L’absence de bouton de commande n’empêche pas une requête directe. OWASP recommande de contrôler les droits à chaque requête. Le test prévu doit donc aussi montrer que la planification ne peut pas envoyer de commande et ne peut plus obtenir les prix protégés après révocation de son accès à l’entreprise. Une page déjà ouverte ne prouve pas, à elle seule, que les droits restent valables.
Quand un rôle commun suffit
Si une seule personne achète pour l’entreprise cliente et peut aussi vérifier les prix, préparer les besoins et commander, un rôle commun peut convenir. Des étapes de concertation sans raison opérationnelle compliqueraient les achats. Le critère est la répartition réelle des tâches : établissez-la avant de choisir l’attribution des droits.
Sources
À lire aussi
Tous les articles
E-commerce avec ASES
Boutiques en ligne, marketplaces et portails B2B