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 définir, documenter et afficher l’ordre de priorité entre rôles hérités, droits directs, restrictions de périmètre et exceptions afin de rendre le résultat d’une permission prévisible. »
- Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; la composition de rôles et les record rules observées chez Odoo et le CRM open-core étudié lors de l’analyse (
pirates:analyses/transversales/matrice-fonctionnelle-globale.md §DOM-13) nécessitent une précédence explicite. - Critères d’acceptation :
- CA-01 — L’ordre de résolution des permissions est documenté dans l’administration.
- CA-02 — Une permission effective indique les règles qui l’accordent et celles qui la restreignent.
- CA-03 — Les conflits de règles sont signalés avant activation.
- CA-04 — Une modification de priorité est versionnée et auditée.
- Dépendances : EXG-13-001, EXG-13-002, EXG-13-004, EXG-13-008.