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 gérer utilisateurs et rôles (hiérarchisables), avec authentification renforcée (LDAP/AD, SSO/OAuth, clés d’API, 2FA). »
- Justification : convergence (
pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13). Odoo groupes hiérarchisésres.groups(implied_ids) ; Dolibarr LDAP/OAuth ; AD/LDAP + clé d’API observés chez un ERP propriétaire du marché des PME industrielles. - Critères d’acceptation :
- CA-01 — Rôles composables (héritage de permissions).
- CA-02 — Connecteurs LDAP/AD et OAuth/SSO.
- CA-03 — Clés d’API par utilisateur/application. Au Lot 0, création et révocation réservées par défaut à l’Administrateur fonctionnel, pour lui-même, les autres utilisateurs et les applications ; autres profils sans ces permissions initiales, même pour leurs propres clés. Profils administrables/composables, sans interdiction de configuration explicite différente. Droits du titulaire, propriétaire explicite, acteur admissible/actif, périmètre société, refus immédiat des clés révoquées et audit sans secret maintenus ; les droits de l’émetteur ne sont pas transférés au destinataire. L’émission propose une date d’expiration optionnelle pour les deux types de clés : sans date, aucune échéance implicite ni expiration automatique ; avec date, refus dès l’instant d’expiration atteint, sans attendre un traitement différé. Aucun renouvellement automatique n’est introduit. Le secret est affiché une seule fois au créateur autorisé immédiatement après création, avec action Copier et avertissement de non-consultation ultérieure. Pour un tiers, le créateur assure la transmission par canal sécurisé externe ; Elena ne transmet le secret ni par courriel ni par notification. Aucun rejeu ne réexpose le secret. Pour remplacer une clé perdue ou compromise, révoquer explicitement l’ancienne puis créer explicitement une nouvelle, remise selon DEC-0207. Aucun bouton de récupération ni remplacement automatique ; interruption assumée jusqu’à configuration de la nouvelle clé. Un échec de création ne réactive pas l’ancienne ; après perte de remise, révoquer la nouvelle avant une nouvelle création explicite. Aucun chevauchement dans ce parcours, sans limiter globalement le nombre de clés par titulaire. QF-0051 résolue fonctionnellement par DEC-0208 ; remise actée par DEC-0207 (DEC-0205, DEC-0206).
- Dépendances : aucune.