Une entreprise invite cinquante collaborateurs sur son compte marketplace et donne à tous le rôle « acheteur ». Un chef de chantier commande un équipement hors contrat, une assistante voit les factures d’une autre filiale et le directeur doit néanmoins approuver chaque panier de fournitures courantes. La délégation est à la fois trop large et trop lente.
Le problème vient d’un rôle global qui mélange consulter, préparer, engager, approuver et payer. Les règles réelles dépendent du centre de coût, du montant, de la catégorie, du fournisseur et de la période. Sans policy contextuelle, les équipes compensent par des validations manuelles ou des comptes partagés.
Le vrai enjeu des acheteurs délégués sur une marketplace opérateur B2B est d’autoriser une décision dans un périmètre précis et vérifiable. Contre-intuitivement, davantage de règles explicites accélèrent les commandes courantes : seules les exceptions sollicitent un approbateur.
Vous allez comprendre comment modéliser organisation, rôles, scopes, budgets, encours, approbations et remplacements. Le service d’autorisation retourne un verdict et ses raisons ; chaque délégation expire, tandis que l’audit relie personne, commande et version de policy.
Définir la délégation d’achat
Séparer préparer et engager
Consulter, constituer un panier, demander un devis, passer commande, approuver et payer sont des actions distinctes. Une personne peut préparer sans engager l’entreprise. La délégation nomme l’action autorisée.
Le contrat précise qui devient responsable à chaque étape. Une approbation ne remplace pas l’identité de l’auteur. La commande conserve préparateur, demandeur, approbateur et payeur.
Définir un contexte obligatoire
Organisation, entité légale, établissement, centre de coût, projet et adresse forment le contexte d’achat. La policy ne décide pas sur le seul utilisateur. Un changement de contexte recalcule les droits.
Le parcours exige le contexte avant d’afficher des conditions négociées ou un budget. Une valeur par défaut peut être proposée mais reste visible. Les actions sensibles demandent confirmation.
Le contrat reçoit acteur, organisation, panier, centre de coût et instant ; il retourne capacités, validations requises et raisons. Cette sortie est versionnée avec la policy. Le parcours ne déduit jamais un pouvoir depuis un intitulé de poste ou un groupe d’interface impossible à auditer côté serveur.
Une capacité distingue lecture, préparation, soumission, engagement et administration. Le droit d’engager ne contient pas automatiquement celui de modifier un catalogue ou de nommer un autre acheteur. Cette séparation réduit l’effet d’un compte compromis et rend les revues d’accès compréhensibles par un responsable métier.
Modéliser l’organisation
Représenter entités et groupes
Maison mère, filiales, établissements, équipes et projets forment une hiérarchie ou un graphe. Chaque nœud porte identité, facturation, taxes et responsables. Une adresse ne suffit pas à définir une entité.
Les identifiants restent stables lors d’une réorganisation. Les rattachements sont datés. Une commande historique conserve la structure applicable à son émission.
Gérer les appartenances
Un utilisateur peut appartenir à plusieurs entités avec des rôles différents. L’invitation précise sponsor, périmètre et expiration. Les comptes externes sont distingués des salariés.
Les arrivées, mobilités et départs sont synchronisés ou revus. Une suppression d’appartenance invalide sessions et délégations concernées. Les commandes en cours gardent leur dossier.
Les données d’organisation viennent d’un référentiel avec effective_from, effective_to et owner RH ou client. Un import écrit une nouvelle version, puis une outbox invalide les sessions. Le monitoring détecte utilisateur sans entité, manager en boucle et appartenance expirée encore active avant qu’une commande soit engagée.
Séparer rôles et permissions
Composer des capacités
Demandeur, acheteur, approbateur, administrateur et finance deviennent des rôles lisibles. Chacun référence des capacités atomiques. Une permission interne ne s’affiche pas comme jargon technique.
Les rôles standards couvrent la majorité. Les rôles personnalisés restent rares et versionnés. Une combinaison dangereuse est détectée avant attribution.
L’implémentation prend en entrée identité, capacité, périmètre et version de panier ; sa sortie contient verdict, responsabilités, owner et règle appliquée. L’instrumentation journalise le résultat, le monitoring suit les refus anormaux et le rollback réactive la policy précédente sans toucher aux décisions historiques.
Séparer administration et dépense
Inviter un utilisateur, modifier une policy ou consulter les factures ne donne pas automatiquement le droit d’acheter. L’administration dispose de contrôles renforcés. Les changements sensibles peuvent exiger deux personnes.
Le service reçoit acteur, action, ressource et contexte ; il retourne autorisé, à approuver ou refusé avec motif. Toutes les surfaces utilisent cette décision.
Le compromis oppose simplicité et précision. Dix rôles génériques sont compréhensibles mais trop larges ; mille rôles personnalisés deviennent impossibles à revoir. La plateforme compose quelques capacités stables avec des périmètres et limites contextuels. L’administration montre la règle résultante avant sauvegarde et signale tout cumul qui élargit le pouvoir.
Limiter les périmètres
Borner catégories et fournisseurs
Une délégation peut couvrir catalogue contractuel, fournisseurs approuvés, catégories ou projets. Les identités viennent de référentiels stables. Un nom libre n’est pas un scope.
Les exclusions critiques dominent les inclusions. Une catégorie réglementée nécessite une preuve supplémentaire même si le budget est disponible. La policy explique ce conflit.
Contrôler géographie et livraison
Pays, établissement et adresse autorisée limitent certaines commandes. Une livraison personnelle peut être interdite. Les restrictions suivent la politique de l’entreprise et les capacités du vendeur.
Le changement d’adresse après approbation déclenche un nouveau verdict. Une commande ne conserve pas aveuglément une validation donnée pour un autre site.
Par exemple, un acheteur peut commander du matériel informatique pour Lyon, mais pas des téléphones ni une livraison à domicile. Si une ligne ou une adresse sort du périmètre, alors seule cette décision est refusée ou envoyée en approbation ; le panier explique la règle et permet de retirer l’élément sans recommencer.
Gouverner budgets et encours
Définir montant et période
Plafond par commande, jour, mois ou projet répond à des risques différents. La devise, les taxes, la livraison et les avoirs sont précisés. Le budget ne dépend pas d’un total ambigu.
Les limites peuvent être individuelles ou partagées. Le compteur conserve réservation, engagé, consommé et libéré. Une annulation restitue selon une règle.
Le service budgétaire reçoit en entrée compte, période, montant et clé d’idempotence ; il produit en sortie réservation ou refus. Une file avec retry traite les libérations, tandis que le monitoring alerte au seuil d’ancienneté. Le runbook attribue chaque écart à un owner et précise la réconciliation.
Réserver avant la commande
Un panier soumis à approbation peut réserver une part du budget pour éviter le dépassement concurrent. Le hold possède expiration et clé idempotente. Il n’est pas une dépense acquise.
Scénario : deux équipes consomment le dernier budget simultanément. Si la première réservation gagne, alors la seconde passe en approbation ou refus ; le total ne devient pas négatif.
Le ledger budgétaire enregistre allocation, réservation, consommation, libération et ajustement. Chaque mouvement cite période, centre, devise, commande et événement causal. Une clé idempotente empêche qu’un retry réserve deux fois. Les projections peuvent être reconstruites, et la clôture rapproche budget, commandes et factures.
Lors de deux commandes concurrentes, la réservation utilise une version du solde ou un verrou court. Une demande refusée libère son montant par événement ; une commande annulée suit la règle comptable du client. Le dashboard alerte sur encours expiré, solde négatif et écart entre projection et mouvements.
Déclencher les bonnes validations
Évaluer la policy sur le panier
Montant, catégorie, fournisseur, contrat, projet et risque produisent aucune approbation, une chaîne ou un refus. La règle choisit les approbateurs par rôle et périmètre. Elle est versionnée.
Le panier soumis devient un snapshot. Toute modification matérielle annule la validation ou ne concerne que la ligne ajoutée selon la policy. L’utilisateur voit pourquoi.
Éviter les chaînes inutiles
Les approbations parallèles réduisent le délai lorsque finance et métier sont indépendants. Les seuils évitent de solliciter un directeur pour une fourniture récurrente conforme au contrat.
Les rappels, escalades et expirations sont bornés. Une validation silencieuse après délai n’existe pas. Un suppléant doit posséder une délégation active.
La policy prend montant, risque fournisseur, catégorie, exception et budget puis produit approbateurs en parallèle ou en séquence. Sa version et ses entrées sont stockées avec la demande. Si le panier change matériellement après accord, alors les validations touchées expirent ; les autres sont conservées seulement si une règle le permet.
Fluidifier panier et devis
Afficher les droits avant le dernier clic
Le catalogue signale conditions négociées, catégories autorisées et budget indicatif. Le panier explique les lignes qui nécessitent validation. L’utilisateur ne découvre pas un blocage après une heure de travail.
Les alternatives conformes restent accessibles. Une offre interdite n’est pas simplement cachée si l’acheteur doit comprendre la politique. Le motif guide la correction.
Conserver le dossier de demande
Besoin, pièces, devis, commentaires et approbations restent liés. Un approbateur voit le contexte, pas seulement le total. Une décision comporte motif et éventuelles conditions.
La conversion d’un devis reprend la version acceptée et revalide la policy. Un changement de budget ou de rôle peut demander une nouvelle approbation sans modifier le devis.
Scénario : un panier validé à 4 900 euros reçoit une ligne à 300 euros juste avant paiement. Si le seuil d’approbation est 5 000 euros, alors la version acceptée devient obsolète et une nouvelle demande est créée. Le système n’autorise ni modification silencieuse ni réutilisation du token précédent.
Gérer absence et remplacement
Créer une délégation temporaire
Un approbateur délègue rôle, périmètre, début, fin et motif. Le remplaçant ne reçoit pas tous ses droits. Les incompatibilités de séparation des tâches sont contrôlées.
La délégation est visible aux administrateurs et révocable. Son expiration invalide les décisions futures, pas celles déjà prises. Les sessions sont actualisées.
Prévoir les urgences
Une procédure d’urgence permet une commande critique avec justification, montant borné et revue a posteriori. Elle n’utilise pas un compte partagé. Les catégories admissibles sont limitées.
Les usages d’urgence sont mesurés. Une répétition signale une policy ou un planning défaillant. L’exception ne devient pas une voie normale.
Une délégation temporaire contient délégant, remplaçant, capacité, périmètre, début, fin et motif. Elle ne peut pas créer un pouvoir supérieur à celui du délégant. Une tâche retire automatiquement les sessions actives à l’échéance, tandis qu’une revue quotidienne recherche les délégations sans manager ou sans date de fin.
Tracer les décisions
Conserver la policy évaluée
Chaque verdict garde acteur, action, contexte, entrées, version de policy et raisons. L’audit peut reproduire pourquoi une commande était autorisée. Un changement ultérieur n’altère pas l’histoire.
Les traces sensibles ont une rétention et des droits. Les exports portent période et empreinte. L’accès à l’audit est lui-même journalisé.
Relier commande et responsabilités
Demandeur, acheteur, approbateur et administrateur apparaissent dans le dossier. Les changements de rôle après commande ne remplacent pas ces identités. Les actions de support restent distinctes.
Une correction produit un événement compensatoire. Elle ne réécrit pas l’approbation. Le litige dispose d’une chronologie complète.
Le journal conserve acteur réel, acteur représenté, policy, entrée, verdict et version de panier. Les événements sont immuables et exportables pour l’organisation cliente. Les données sensibles suivent une rétention et un contrôle d’accès ; support peut expliquer sans obtenir le droit de modifier la décision.
Une recherche par commande restitue la chaîne complète : création, changements, évaluations, approbations, délégations et paiement. Les horodatages utilisent une référence unique et les exports portent une empreinte. Si un administrateur corrige une appartenance, alors un nouvel événement apparaît ; l’ancien verdict ne disparaît jamais.
Expliquer les droits
Donner une raison actionnable
« Budget mensuel dépassé » ou « approbation sécurité requise » aide davantage que « accès refusé ». Le message indique qui peut agir et quelle alternative reste possible.
Les raisons publiques ne révèlent pas des informations confidentielles. Un vendeur ne voit pas le budget interne. Support dispose d’un diagnostic plus complet selon ses droits.
Rendre l’administration compréhensible
Les administrateurs prévisualisent les droits d’un utilisateur sur des scénarios. Un diff montre l’effet d’un changement de rôle ou de policy. L’activation évite les surprises.
Les règles expirées et inutilisées sont signalées. Une revue périodique demande aux owners de confirmer. Les délégations orphelines sont retirées.
L’interface annonce dès la sélection d’un compte le budget restant, les catégories autorisées et le circuit probable. Ce choix ajoute un peu d’information mais évite un refus tardif coûteux. Les raisons utilisent des codes stables traduits en message, et proposent une action : changer de compte, demander une extension ou solliciter l’approbateur.
Monitorer les abus et blocages
Détecter les comportements anormaux
Le monitoring suit refus, approbations, urgences, délégations et changements d’administration. Les segments portent entité, action et policy. Une hausse soudaine peut signaler abus ou régression.
Les contrôles détectent fractionnement de commandes, boucle d’approbation et compte dormant réactivé. Un signal ouvre une revue, il ne bloque pas sans règle.
Répondre à une policy défectueuse
Le kill switch restaure une version saine ou force une approbation sur un périmètre. Les commandes déjà autorisées restent identifiées. L’équipe ne change pas toute l’organisation.
Si plus de 2 % des commandes conformes sont bloquées après un déploiement, alors la version est retirée. Le retour exige test régressif et réconciliation des paniers en attente.
Par exemple, si un compte délègue soudainement à douze utilisateurs puis dépense 80 % du budget en une heure, alors le monitoring gèle les engagements nouveaux et alerte le responsable client. Le runbook vérifie import, identité et commandes, puis réactive par cohorte. Les paniers restent visibles pendant l’investigation.
La reprise compare sessions, droits actuels, réservations et commandes exposées. Les actions autorisées à tort sont attribuées à un dossier support et au manager du compte. Le rollback de policy restaure la version précédente pour les décisions futures, mais ne transforme jamais rétroactivement une commande déjà engagée en opération autorisée.
Adapter la méthode et éviter les erreurs
Pour qui les acheteurs délégués conviennent
Ils conviennent aux organisations B2B avec équipes, budgets ou approbations. Un compte simple peut commencer avec demandeur et administrateur, puis ajouter des policies seulement lorsque le besoin existe.
Produit porte les actions ; sécurité la policy ; client B2B l’organisation ; finance les budgets ; plateforme les verdicts ; support l’audit. Chaque owner valide sa sortie.
Erreurs fréquentes avec les acheteurs délégués
Donner un rôle global, mélanger administration et achat, ignorer le contexte, approuver un panier mutable et partager des comptes sont les erreurs majeures. Elles créent du risque et du délai.
Une autre erreur consiste à exprimer chaque client dans le code. Les policies et référentiels doivent porter les variantes contractuelles sans forker le parcours.
Plan d’action pour déployer les acheteurs délégués
Semaines 1 à 4 : organisation et policies
La première semaine analyse deux clients B2B et vingt commandes. L’équipe sépare actions, contextes, rôles et budgets. La deuxième modélise entités, appartenances et délégations avec leurs dates.
Les semaines trois et quatre construisent le service de verdict, les scopes et compteurs. Sécurité teste séparation des tâches ; finance teste encours ; produit affiche les raisons avant soumission.
Semaines 5 à 8 : approbation et run
La cinquième semaine branche snapshots et chaînes d’approbation. La sixième teste remplacement, urgence et devis. L’instrumentation relie policy, commande et décision.
Les semaines sept et huit ouvrent une cohorte puis rejouent budget concurrent, changement de rôle et policy erronée. Le go exige droits explicables, aucune commande hors scope et rollback exécuté.
Le comité examine règles et urgences inutilisées. Toute nouvelle policy doit avoir owner, exemples, expiration et test. Les procédures par email deviennent des workflows ou sont supprimées.
Le dossier de go contient modèle d’organisation, catalogue de capacités, policies versionnées, ledger budgétaire et vingt scénarios de recette. Un administrateur client doit expliquer les droits effectifs ; un approbateur retrouve la version acceptée ; support reconstitue une commande ; sécurité révoque une délégation et vérifie toutes les sessions. Le premier compte reste plafonné tant qu’un changement d’appartenance, un retry de réservation ou un rollback de policy produit un verdict ambigu.
- À faire d’abord : séparer préparer, engager, approuver et administrer.
- À tester ensuite : budget partagé, absence, urgence et changement de contexte.
- À différer : les rôles personnalisés sans besoin récurrent.
- À refuser : tout compte partagé ou panier approuvé puis modifié.
Guides complémentaires pour l’opérateur
Structurer comptes et contrôle
Les écrans du back-office opérateur structurent organisations, policies et audits.
Le catalogue PIM marketplace fournit catégories et identités pour les scopes.
Borner le premier compte
Le MVP marketplace avant ouverture aide à limiter les policies initiales.
La méthode pour ouvrir une première catégorie permet de tester des commandes réelles.
Conclusion : autoriser avec contexte
Les acheteurs délégués accélèrent le B2B lorsque chaque action est autorisée dans une organisation, un scope et un budget précis.
Snapshots, approbations et délégations temporaires évitent les comptes partagés et les validations permanentes.
Le verdict versionné et l’audit rendent chaque commande explicable. Les exceptions restent bornées et mesurées.
Pour concevoir ces comptes B2B, Dawap peut vous accompagner dans votre marketplace opérateur.
