ADR-0025 — Quatre relations, trois mecanismes : un mandat n'est pas une commission
Demande, a plusieurs reprises, que « chaque acces puisse gerer : user platform, affiliate platform, revendeur platform, partner platform, admin platform ». La formulation suggere cinq portes du meme type, et c'est ce…
Statut
Accepté · 2026-09-19
Piliers : security-identity, billing, app-shell
Contexte
Demande, a plusieurs reprises, que « chaque acces puisse gerer : user platform, affiliate platform, revendeur platform, partner platform, admin platform ». La formulation suggere cinq portes du meme type, et c'est ce qui rendait la chose floue : elles ne sont pas de la meme nature, et les traiter pareil produirait soit une fuite, soit un ecran qui ment.
L'etat du depot au moment de decider :
- un mandat (
AccessGrant) porte une porteeplatform,orgoustore, une liste de permissions derivee de presets, une echeance, et il est revocable et journalise. Il dit qui peut ouvrir quoi ; - une affiliation (
AffiliateCode,AffiliateRedemption,AffiliateCommission) dit qui touche de l'argent sur les factures d'un filleul. Elle n'ouvre aucune surface ; - un partenariat (
/network/partners, ADR 0014) n'echange aucune commission : il donne une fiche d'annuaire, les demandes entrantes, et un acces delegue que le client accorde, pas nous ; - un revendeur n'existe nulle part. Ni table, ni permission, ni page.
Melanger les trois dans un seul systeme de permissions est l'erreur que
cet ADR existe pour empecher. Donner une platform.* a un affilie
reviendrait a transformer une relation de revenu en droit de lecture sur
des donnees de tiers.
Décision
Trois mecanismes, et on ne les croise pas.
| Relation | Mecanisme | Ce qu'elle donne | Qui l'accorde |
|---|---|---|---|
| Collaborateur d'un pole | AccessGrant portee platform | des surfaces /ops | un admin plateforme |
| Prestataire sur une marque | AccessGrant portee org / store | des surfaces de cette marque | l'organisation cliente |
| Partenaire (agence, freelance) | fiche d'annuaire plus un mandat d'org | une visibilite, puis un acces que le client accorde | nous pour la fiche, le client pour l'acces |
| Affilie | AffiliateCode et son ledger | de l'argent, jamais une surface | l'inscription au programme |
Le revendeur n'est pas tranche ici. Revendre suppose de facturer ses propres clients a son propre prix : c'est un modele de facturation, pas une permission. Aucun agent ne peut l'inventer, et lui donner une permission en attendant creerait une porte sans contrat derriere. Il reste un item de decision de gouvernance.
Ce qu'un affilie voit de ses filleuls
Ses gains, le terme de chaque filleul, et rien qui l'identifie.
Le tableau de /account/settings/referrals affichait le nom de
l'organisation filleule. C'est une donnee de tiers : un lien
d'affiliation public est clique par des inconnus, et l'affilie n'a aucun
titre a apprendre qui ils sont. Il n'est pas responsable de traitement
sur cette donnee, et le filleul n'a consenti a rien vis-a-vis de lui.
Un affilie a besoin de reconcilier ce qu'on lui doit, pas d'identifier un client. Les lignes gardent donc le montant, l'avancement dans les douze factures et la date, sous un libelle stable et opaque. L'affilie qui sait deja qui il a parraine ne perd rien ; l'inconnu qui a clique un lien public ne devient pas une ligne nominative dans le tableau d'un tiers.
Alternatives écartées
Un preset platform par relation (pole_affiliate,
pole_partner). Ecarte : la permission serait vide, et createGrant
refuse un mandat vide. Deux cases a cocher qui echouent au clic sont
pires qu'une absence, parce qu'elles promettent une porte.
Un role utilisateur supplementaire (AFFILIATE, PARTNER) a cote
de USER et ADMIN. Ecarte : un role est global et durable, alors que
ces relations sont multiples et simultanees — une meme personne peut
etre affiliee, partenaire d'un client et collaboratrice d'un pole. Un
role unique l'obligerait a choisir, ou nous a empiler des roles jusqu'a
ce que plus personne ne sache ce qu'un compte ouvre.
Laisser le nom de l'organisation dans le tableau d'affiliation, au motif que l'affilie « connait deja » son filleul. Ecarte : c'est vrai du parrainage direct et faux du lien public, et une regle de confidentialite qui depend de la facon dont le lien a circule est une regle que personne ne peut verifier.
Conséquences
- L'ecran d'octroi (
/admin/people/access) ne gerera jamais les affilies : il n'y a rien a y accorder. Il peut les montrer, et c'est ce que la page fait, parce que la question « qui a acces a quoi chez nous » inclut honnetement « et qui touche de l'argent ». - Le programme partenaires reste une surface marketing plus un mandat
d'org. Aucune
platform.*ne lui est attachee. - Le tableau d'affiliation perd le nom de l'organisation. C'est une regression visible et assumee : elle retire une donnee que personne n'aurait du voir.
- Un futur revendeur devra d'abord avoir un modele de facturation. Tant qu'il n'en a pas, il n'a pas de permission.