Projet Elena

Cahier des charges · EXG-13-003

EXG-13-003 — Permissions par champ

Dernière modification du document source :

Date déclarée dans le document :

Extrait de l’exigence citée, accompagné du contexte de son document. Le cahier des charges décrit le périmètre prévu ; il ne constitue pas une preuve de recette.

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