Contexte du document
Odoo et un CRM open-core récent à architecture métadonnées-driven étudié lors de l’analyse
constituent la référence (granularité la plus fine : record rules / RBAC objet+champ) ; un ERP
propriétaire du marché des PME industrielles se différencie par la conformité (Audit Trail
FDA/ISO + revue de contrat) (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13).
Le filtrage par ligne (RLS) du CRM étudié est réservé à son édition Enterprise — à réimplémenter
librement (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §8). Aucune reprise de
code des ERP étudiés.
Ergonomie de la gestion des droits (décision DEC-0013, validée le 2026-08-21 par Yannic Le Marec, résorbée ici) : la finesse des droits (objet, action, champ, ligne ; cloisonnement par équipe, dépôt et affaire) ne doit pas produire une administration réservée aux experts techniques. Garanties livrées avec le socle de sécurité (traduites en EXG-13-008 à 014) : profils métier prédéfinis, séparation explicite droits de données / actions métier, explication des refus et diagnostic « pourquoi cet accès ? », traçabilité de toute modification de permission (auteur, date, avant/après, périmètre), règles de priorité documentées et visibles, permissions temporaires et délégation contrôlée, matrice graphique filtrable, visualisation du périmètre effectif, versionnement et restauration des configurations. Principes d’expérience : mode simple (profils/capacités métier) avec mode avancé accessible ; simulation du point de vue d’un utilisateur sans modifier ses droits ; toute permission effective explicable par sa chaîne de décision ; publication d’une configuration avec aperçu d’impact et retour arrière ; mêmes résultats de sécurité en interface et en API. La sécurité est une capacité administrable du modèle métadonnées-driven, y compris pour les objets et champs personnalisés ; les changements de permissions sont eux-mêmes audités et restaurables.
Audit trail (décision DEC-0014, validée le 2026-08-24 par Lucas, résorbée ici et dans le CDC
technique) : Elena doit conserver une preuve exhaustive, attribuable, inaltérable et restituable des
opérations métier et des changements de sécurité. Cette preuve doit rester fiable lorsque
l’infrastructure métier est compromise ou indisponible ; aucune opération sensible ne peut réussir
si sa preuve d’audit ne peut pas être garantie (EXG-13-006, EXG-13-011). Les mécanismes
d’infrastructure, d’intégrité cryptographique, d’archivage et de reprise sont prescrits dans :
../../../technique/30-securite/audit-trail.md.
Exigence détaillée
- Priorité : Must
- Domaine : DOM-13
- Énoncé : « Elena doit contrôler l’accès par objet et par action (créer/lire/modifier/supprimer), configurable par rôle, avec la même règle d’autorisation pour les objets natifs et personnalisés. »
- Justification : convergence forte (
pirates:analyses/transversales/matrice-fonctionnelle-globale.md §5). Odoo CRUD par modèle (ir.model.access.csv) ; permissions par objet observées chez le CRM open-core métadonnées-driven étudié lors de l’analyse ; Dolibarr RBAC module/action. - Critères d’acceptation :
- CA-01 — Permission CRUD par objet et par rôle.
- CA-02 — Refus par défaut (deny-by-default) hors permission explicite.
- CA-03 — Une même permission produit le même effet sur un objet natif et un objet personnalisé de capacité équivalente.
- CA-04 — Pour Article,
article.update,article.activate,article.deactivateetarticle.deletesont quatre permissions indépendantes : aucune attribution n’en implique une autre et chaque action est refusée par défaut sans sa permission propre.
- Déclinaison facturation directe Lot 0 : EXG-06-001/CA-10 et les règles de facturation directe §3 distinguent les habilitations de création, validation, retour en brouillon, annulation et correction. Cumul permis sans double approbation obligatoire ; aucun droit sensible implicite (DEC-0143).
- Requiert : EXG-13-001.