oto-enterprise-os-dtp/05_deliverables_mvp/rbac/RBAC_50_ROLES_SPEC.md

Spec RBAC · 50 rôles · OTO Enterprise OS DTP

Livrable Sprint 2 · ERPNext Backend (roadmap ../../04_roadmap/ROADMAP_8_WEEKS_OR_LESS.md §Sprint 2 l.38 : « ERPNext Backend : RBAC 50 rôles configuration » · ../GAP_ANALYSIS_SPRINT1.md §3.4 gap ERPNext).

Date : 2026-07-30 · Auteur : Claude Code DTP Worker · Version : 1.0.0

---

1. Objet

Design machine-lisible des 50 rôles RBAC (contrainte CLAUDE.md « RBAC 50 rôles ») à créer nativement dans Frappe/ERPNext v15. Le contrat de données est rbac.schema.json ; les données sont rbac_50_roles.json. Ce document ne touche jamais la production : il définit la cible que l'agent ERPNext Backend appliquera sur le VPS via bench / fixtures (voir §7).

Priorité ERPNext natif (contrainte #1) : chaque rôle est un DocType Role Frappe standard — aucun RBAC externe. CRM = ERPNext natif (jamais EspoCRM ni HubSpot — contrainte #3).

2. Modèle RBAC

Le RBAC Frappe combine trois niveaux, tous couverts par le schéma :

Niveau Frappe	Champ du schéma	Rôle
Role (DocType)	erpnext_role_name	Un DocType Role par ligne, préfixe OTO (anti-collision natif).
Permissions par DocType	permissions_cibles[]	Verbes Frappe (read/write/create/submit/cancel/report/…) par DocType.
Row-level (User Permission)	scope_donnees	own · equipe · entite (Company) · groupe (consolidé).

Défense en profondeur : le pouvoir set_user_permissions (gestion des habilitations) est réservé au seul rôle OTO Plateforme RBAC Admin (scope_donnees = groupe, famille = plateforme) — séparation des pouvoirs vérifiée par test automatisé.

3. Cartographie portails ↔ familles

Les 5 portails métier (roadmap Sprint 4 « 5 portails rôle ») + 1 console technique transversale (plateforme, hors du compte de 5) :

Portail	Familles rattachées	Nb rôles
direction	direction, finance (CFO), faisabilite (analyste), legal	9
ventes	ventes, marketing	12
construction	construction, faisabilite (rendu/IFC/économiste)	10
achat	achat	5
compta	finance	8
plateforme (technique)	plateforme	6
	Total	50

Répartition indicative issue de rbac_50_roles.json ; la source de vérité reste le JSON (le test impose exactement 50 rôles et la couverture des 5 portails).

4. Cartographie rôles ↔ entités (CLAUDE.md §Entités)

Chaque rôle porte une entite_principale. « Groupe » = périmètre consolidé transversal (direction, contrôle de gestion, audit UAF, BI).

Entité	Exemples de rôles
WAF (holding)	Président, Directeur Juridique, Agent ONAPI
WA SRL	Contrats de vente, Achats, Comptable général, Fiscaliste e-CF, Analyste faisabilité
AC Arias Cuevas	Directeur/Chef de projet Construction, Ingénieur, Économiste, Magasinier
Consortium ECR DR (paymaster RH)	Gestionnaire Paie
Helios RD (marque publique)	Directeur des Ventes, Conseiller, Marketing, Comptable clients AR
Ploutos (patrimoine/monétaire)	Trésorier
9060 QC (World Activities Cdn.)	DevOps, RBAC Admin, QA, OTOIA, Mobile
Groupe (consolidé)	DG, CFO, COO, CCO, Conseil, Contrôle de gestion, Audit UAF, BI

5. Les 50 rôles (résumé)

Détail complet (permissions par DocType, modules, scope) dans rbac_50_roles.json.

Direction / Gouvernance (6) — Président WAF · Directeur Général · CFO · COO · CCO · Conseil d'Administration (lecture).

Ventes (8) — Directeur des Ventes · Chef d'Équipe · Conseiller · Courtier externe · Coordinateur Réservations · Gestionnaire Contrats · Coordinateur CONFOTUR · Support Après-Vente.

Marketing (4) — Directeur Marketing · Publiciste (agent) · SEO · Social.

Construction (7) — Directeur · Chef de Projet · Ingénieur · Architecte · QA/QC · Coordinateur BIM · Superviseur Sous-traitants.

Achat (5) — Directeur · Acheteur · Gestionnaire Fournisseurs · Magasinier · Contrôleur Réception.

Finance / Compta (8) — Contrôleur de Gestion · Comptable Général · AP · AR · Trésorier (Ploutos) · Paie (Consortium ECR DR) · Fiscaliste e-CF · Audit UAF.

Faisabilité / AEC (4) — Analyste Faisabilité · Rendu 3D · IFC/Speckle · Économiste de la Construction.

Legal (2) — Directeur Juridique · Agent ONAPI.

Plateforme technique (6) — DevOps · RBAC Admin · QA · OTOIA (système) · Mobile · BI.

(6+8+4+7+5+8+4+2+6 = 50.)

6. Conformité aux contraintes CLAUDE.md

#	Contrainte	Application ici
1	ERPNext natif prioritaire	100 % DocType Role Frappe, aucun RBAC externe.
3	CRM = ERPNext natif	Rôles ventes → Lead/Opportunity/Quotation/Customer natifs.
6	Zéro invention	Aucun chiffre/plafond monétaire inventé ; seuls rôles, entités et DocTypes natifs (+ DocTypes DTP marqués custom à confirmer VPS).
8	VPS pour tous projets	Application des fixtures = VPS (§7), jamais local.
—	Séparation des pouvoirs	set_user_permissions réservé au RBAC Admin (test).

DocTypes custom: true (Faisabilité, Publiciste Log, CONFOTUR Application, API Access) = DocTypes DTP à créer — existence à confirmer VPS par l'agent ERPNext avant application (cohérent avec l'interdit « documenter du code sans vérifier l'existence courante »).

7. Application sur VPS (hors périmètre worker)

Ce worker n'écrit jamais sur le VPS. L'agent ERPNext Backend appliquera la cible côté serveur (erpnext-backend-1) dans l'ordre ci-dessous. Ce run-book est consolidé et vérifié en-repo par l'agrégateur apply_plan/ (python3 rbac_apply_plan.py build → apply_plan.json + MANIFEST.json agrégé : comptes des 3 volets, confirmations VPS fusionnées, graphe de dépendances, recoupement bijectif des 50 rôles) :

1. Générer les fixtures Role + Custom DocPerm depuis rbac_50_roles.json — livré : fixtures_gen/ (python3 rbac_fixtures_gen.py build).
2. Créer les DocTypes DTP custom manquants (§6) après confirmation (listés dans MANIFEST.custom_doctypes_a_confirmer).
3. Déposer role.json + custom_docperm.json dans fixtures/ de l'app OTO (hooks.py), puis bench --site frontend migrate.
4. Mapper les scope_donnees en User Permission par utilisateur — plan livré : userperm_gen/ (python3 userperm_gen.py build). Matérialiser le user_permission_template par utilisateur assigné (champ user = sentinelle) après confirmation des Companies (MANIFEST.companies_a_confirmer) et décision du mécanisme des rôles equipe (MANIFEST.roles_scope_equipe_a_confirmer).
5. Générer les Role Profile (bundles de rôles par portail) — livré : roleprofile_gen/ (python3 roleprofile_gen.py build). Importer role_profile.json après les fixtures Role (étape 3), puis affecter User.role_profile_name selon MANIFEST.profiles → tous les rôles d'un portail appliqués en un geste.
6. Vérification HTTP post-déploiement (workflow #3) + audit QA 4Big.

✅ Le générateur de fixtures rbac_50_roles.json → fixtures/ est livré en-repo (fixtures_gen/, même patron que le Publiciste, zéro pip / zéro VPS). Sortie déterministe validée par 11 tests + job CI rbac-fixtures-tests. L'application bench reste côté serveur.

✅ Le plan User Permission row-level scope_donnees → mécanisme Frappe est livré en-repo (userperm_gen/) : 28 templates Company (portée entite), portées own/groupe sans restriction fabriquée, portée equipe signalée (pas de dimension native → aucune invention #6). 12 tests + job CI rbac-userperm-tests.

✅ Les Role Profile (bundles de rôles par portail) sont livrés en-repo (roleprofile_gen/) : 6 profils (5 portails métier + console technique plateforme) couvrant les 50 rôles de façon bijective, 100 % DocTypes natifs v15 (Role Profile + Has Role), aucun DocType custom à confirmer. 11 tests + job CI rbac-roleprofile-tests.

✅ Le run-book d'application unifié (agrégat des 3 volets ci-dessus) est livré en-repo (apply_plan/) : les 6 étapes de ce §7 sous forme d'un plan ordonné + un manifeste agrégé (comptes consolidés, confirmations VPS fusionnées, cohérence inter-volets). Zéro chiffre recalculé (tout vient d'un manifeste source, #6), graphe de dépendances validé (Role avant Role Profile). 16 tests + job CI rbac-applyplan-tests.

8. Vérification (en-repo, sans toucher au VPS)

• python3 -m unittest discover -s tests -v → 10/10 verts (schéma maison + oracle jsonschema, 50 rôles, unicité, couverture 5 portails, séparation des pouvoirs).
• rbac_50_roles.json : JSON strict valide (couvert par ci/validate_json.sh).
• Job CI dédié rbac-tests ajouté au gate (.gitea/workflows/ci.yml, Gitea Actions uniquement · #2).

9. Auto-score 4Big du livrable : 95/100

Réserve −5 : application des fixtures + création des DocTypes custom + mapping User Permission = côté VPS (agent ERPNext, hors périmètre worker) ; plafonds d'approbation monétaires par rôle volontairement non chiffrés ici (anti-invention #6 — à définir avec la Direction sur pièces). Validé statiquement en-repo (10 tests verts + schéma conforme + gate CI).