DOM-13 — Sécurité & Droits

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.

EXG-13-001 — Utilisateurs, rôles et authentification renforcé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és res.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.

EXG-13-002 — RBAC par objet et par action (CRUD)

• 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.deactivate et article.delete sont 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.

EXG-13-003 — Permissions par champ

• Priorité : Must
• Livraison : Lot 4 (DEC-0066).
• Domaine : DOM-13
• Énoncé : « Elena doit permettre de restreindre la lecture/écriture de champs sensibles par rôle, qu’ils soient natifs ou personnalisés. »
• Justification : différenciateur d’Odoo et du CRM open-core métadonnées-driven étudié lors de l’analyse (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13). Odoo sécurité par champ (attribut groups) ; permissions par champ observées chez le CRM open-core étudié. Dolibarr n’a pas de permission par champ native (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13).
• Critères d’acceptation :
  • CA-01 — Masquage/lecture seule d’un champ selon le rôle.
  • CA-02 — Application cohérente en UI et en API, pour les champs natifs comme personnalisés.
• Dépendances : EXG-13-002.

EXG-13-004 — Record rules (filtrage par ligne)

• Priorité : Must
• Livraison : Lot 4 (DEC-0066).
• Domaine : DOM-13
• Énoncé : « Elena doit filtrer l’accès aux enregistrements par des règles de ligne (record rules), notamment par équipe, dépôt, affaire ou appartenance, appliquées côté serveur aux objets natifs comme personnalisés. »
• Justification : différenciateur Odoo record rules ir.rule (filtrage company_id, par ligne) ; filtrage par ligne (prédicats) observé chez le CRM open-core métadonnées-driven étudié lors de l’analyse — fonction réservée à son édition Enterprise, donc à réimplémenter librement (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §8).
• Critères d’acceptation :
  • CA-01 — Règles de ligne définissables par objet et par rôle.
  • CA-02 — Application serveur (non contournable via API).
  • CA-03 — Le filtrage par équipe, dépôt, affaire ou appartenance est automatique et non contournable.
• Dépendances : EXG-13-002.

EXG-13-005 — Workflows d’approbation par seuil

• Priorité : Should
• Domaine : DOM-13
• Énoncé : « Elena doit permettre des circuits d’approbation (visa) déclenchés par des conditions (montant, type de document), bloquant la progression jusqu’à validation. »
• Justification : pratique de référence observée chez un ERP propriétaire du marché des PME industrielles : revue de contrat / visa par montant (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13).
• Critères d’acceptation :
  • CA-01 — Conditions de déclenchement paramétrables.
  • CA-02 — Traçabilité du viseur, date, décision.
• Dépendances : EXG-13-002, EXG-15-003 (moteur de workflow).

EXG-13-006 — Journal d’audit conforme (audit trail)

• Priorité : Must
• Domaine : DOM-13
• Énoncé : « Elena doit conserver une preuve inaltérable, attribuable et restituable des créations, modifications et suppressions de tous les objets métier ainsi que des actions sensibles, y compris lorsque l’infrastructure métier est compromise ou indisponible. »
• Justification : différenciateur conformité : Audit Trail FDA/ISO observé chez un ERP propriétaire du marché des PME industrielles (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13) ; convergence RGPD (Dolibarr modDataPolicy, pirates:analyses/erp/dolibarr/fiche.md §6) ; décision DEC-0014 (validée, résorbée dans le chapeau de ce document et le CDC technique).
• Critères d’acceptation :
  • CA-01 — Traçabilité horodatée des événements sur tous les objets métier et actions sensibles, avec niveau de détail configurable par objet, action et type de donnée. Pour une modification des coordonnées ordinaires d’un contact (notamment email ou téléphone), la preuve conserve l’auteur, l’horodatage et le champ modifié, sans enregistrer les valeurs avant/après, y compris dans ses détails ou résumés. La cible, l’action et le résultat restent tracés ; la fiche conserve les coordonnées courantes. L’audit détaillé des autres changements métier, notamment montants et statuts, reste inchangé (DEC-0124).
  • CA-02 — La preuve d’audit reste fiable et vérifiable lorsque l’infrastructure métier est compromise ou indisponible.
  • CA-03 — Un utilisateur habilité peut restituer et exporter le journal ; aucun rôle applicatif ne peut modifier ou supprimer les événements enregistrés. La suppression du Contact relève toutefois de DEC-0123 : anonymisation irréversible de ses données personnelles dans la fiche et l’audit, archives comprises, sans exception nominative ; les faits métier et leur preuve restent à préserver. Après une demande d’effacement fondée, l’accès aux données personnelles encore justifiées en archive exige une habilitation spécifique à leur finalité de conservation ; le droit général sur le journal ne suffit pas (EXG-13-007/CA-02, DEC-0093). Cette exception d’accès ne s’applique pas aux données du Contact supprimé : DEC-0123 exclut tout accès privilégié à ses anciennes valeurs dans la fiche et l’audit.
  • CA-04 — Toute suppression, altération ou réorganisation d’événements enregistrés est détectable et rend la vérification concernée non conforme. La suppression du Contact relève toutefois de DEC-0123 : anonymisation irréversible de ses données personnelles dans la fiche et l’audit, archives comprises, sans exception nominative ; les faits métier et leur preuve restent à préserver.
  • CA-05 — En cas de perte ou d’indisponibilité du support principal, les preuves archivées sont récupérables sans perte d’inaltérabilité ni de vérifiabilité.
  • CA-06 — La conservation est configurable par catégorie, respecte les minima légaux et réglementaires applicables et préserve l’inaltérabilité des archives. La politique personnelle qualifie données nécessaires, durée et événement de départ par finalité ; une simple correction administrative ne prolonge pas automatiquement toutes les preuves. Les durées et effets précis des reprises/corrections restent à qualifier (DEC-0125). Pour un événement contenant des données personnelles, la politique distingue la conservation de l’événement de celle de ces données : la durée de l’événement ne suffit pas à justifier celle de toutes les données qu’il contient. Cette distinction n’autorise aucune modification des archives existantes et ne fixe aucune durée ni modalité d’effacement ; DEC-0123 prescrit désormais l’anonymisation irréversible du Contact supprimé dans sa fiche et tout l’audit sans exception nominative (DEC-0089).
  • CA-07 — Une indisponibilité temporaire du système d’audit n’entraîne aucune perte d’événement ; une opération sensible est bloquée si sa preuve ne peut pas être garantie.
  • CA-08 — Les événements d’audit propres à un tiers ne constituent pas à eux seuls une référence interdisant sa suppression ; les autres références métier ou réglementaires et les droits continuent de déterminer son éligibilité (EXG-01-001/CA-23).
  • CA-09 — Après suppression autorisée d’un tiers, ses événements d’audit antérieurs restent conservés et restituables ; un nouvel événement prouve la suppression. Le refus de CA-07 reste applicable (DEC-0082).
• Conditionne : EXG-05-006 (piste d’audit comptable spécialisée).
• Dépendances : EXG-13-002.

EXG-13-007 — Conformité RGPD (données personnelles)

• Priorité : Must
• Domaine : DOM-13
• Énoncé : « Elena doit fournir les fonctions RGPD de base : registre, gestion des consentements, droit d’accès/rectification/effacement, anonymisation. »
• Justification : réglementaire (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §7). Dolibarr modDataPolicy (RGPD) (pirates:analyses/erp/dolibarr/fiche.md §6) ; fonctions RGPD également observées chez un ERP propriétaire du marché des PME industrielles (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-13).
• Critères d’acceptation :
  • CA-01 — Export des données personnelles d’un tiers/contact. L’export est alimenté par la qualification de l’instance par finalité : son périmètre est celui de la qualification, jamais un contenu réglementaire codé en dur ni un contenu inventé par le produit (DEC-0320).
  • CA-02 — Anonymisation sur demande d’effacement. Pour la suppression autorisée d’un contact, l’enregistrement est conservé sous le libellé « Contact supprimé » ; ses données personnelles sont supprimées ou neutralisées irréversiblement dans sa fiche et toutes leurs occurrences dans l’audit, valeurs avant/après et archives comprises. Aucun rôle ne permet de conserver ou retrouver les anciennes valeurs ; consultations, recherches, exports et restaurations ne doivent pas les réexposer. La preuve de l’opération ne recopie pas les données anonymisées. Les documents déjà émis ne sont pas réécrits par cette opération. Le masquage et le maintien d’identifiants ne prouvent pas l’anonymat ; les risques de réidentification par les liens restent à vérifier. Ce résultat ne supprime pas les droits ni les conditions d’éligibilité à la suppression. Les autres usages d’effacement restent régis par DEC-0093 et ouverts dans QF-0029 (DEC-0123).
  • CA-03 — Journalisation des accès aux données personnelles.
  • CA-04 — Dès le Lot 0, chaque domaine dispose d’une durée de conservation paramétrable initialisée à cinq ans. Cette valeur par défaut n’impose ni de tout conserver cinq ans ni de tout supprimer à ce terme ; les règles légales et d’effacement applicables à chaque catégorie priment sur ce défaut, y compris la suppression Contact définie en CA-02. Les points de départ, actions à échéance et effets d’une modification du réglage restent à qualifier dans QF-0029 ; aucune purge automatique n’est déduite de ce critère (DEC-0220). La qualification par finalité — données nécessaires, base applicable, durée, événement de départ, accès, sort à échéance — est portée par l’instance, confirmée ou ajustée au cas réel et tracée ; le registre RGPD livré et l’export en découlent, sans valeur réglementaire codée (DEC-0320). QF-0029 reste ouverte : ses six réponses relèvent du responsable de traitement avec appui DPO/conseil compétent, cette décision ne les fournissant pas et ne levant pas le blocage de finalisation de la politique, du contenu d’export/registre et des oracles.
• Dépendances : EXG-13-006, EXG-01-001 (partner/contacts).
• Usages au Lot 0 : données personnelles réelles, usages Business uniquement, aucun usage promotionnel prévu (DEC-0184). Les critères RGPD restent applicables aux traitements concernés ; défaut de cinq ans par domaine acté par DEC-0220, sans conformité acquise ni validation des durées particulières ; instruction QF-0029 reprise pour les usages Business, sans report global de livraison.
• Référence de conservation : politique Contacts et référentiel CNIL, intégrés par DEC-0064. Référence documentaire adoptée ; politique d’application à faire valider, QF-0029 maintenue ouverte. Les durées et déclencheurs par usage ne sont pas approuvés par cette intégration ; EXG-13-006 ne fixe pas une durée universelle pour les fiches Contact. DEC-0089 acte uniquement la distinction entre conservation de l’événement et de ses données personnelles, sans approuver les autres propositions de politique. DEC-0093 précise le retrait des usages courants et l’accès restreint aux seules données encore justifiées ; DEC-0123 exclut désormais cette exception pour le Contact supprimé dans sa fiche et l’audit, documents déjà émis exclus. Les autres modalités résiduelles d’effacement restent ouvertes.

EXG-13-008 — Profils métier et séparation des capacités

• Priorité : Must
• Domaine : DOM-13
• Énoncé : « Elena doit proposer des profils métier prédéfinis et distinguer les droits de données (voir/créer/modifier/supprimer) des actions métier (valider/approuver/annuler/clôturer/exporter). »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; la finesse observée chez Odoo et le CRM open-core étudié lors de l’analyse (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §DOM-13) doit être administrable par des profils métier compréhensibles.
• Critères d’acceptation :
  • CA-01 — Au Lot 0, cinq profils métier prédéfinis sont proposés : Administrateur fonctionnel, Commercial, Responsable commercial, Facturation, Consultation (DEC-0187). Leurs vocations sont respectivement administration, travail commercial, supervision commerciale, facturation/correctifs et consultation sans modification. Le catalogue seul ne fixe pas les droits. DEC-0188 accorde initialement à Administrateur fonctionnel les droits d’administration et tous les droits métier disponibles au Lot 0, sans attribution séparée des autres profils. Les permissions de données et d’actions restent distinctes, explicitement accordées ; toutes les conditions métier/réglementaires, états des documents, isolation et audit restent applicables. Aucun contournement ni droit futur déduit. DEC-0189 accorde au Commercial les droits de préparation (tiers/contacts, offres/commandes avant première validation, duplication des offres, consultation articles/tarifs, forçage selon politique) et les permissions explicites de validation des offres/commandes et conversion des offres, sans responsable obligatoire. Contrôles métier, audit et questions d’éligibilité QF-0047/0048 restent applicables ; aucun autre droit sensible n’est déduit de cette autonomie. DEC-0190 attribue à Responsable commercial exactement les mêmes droits initiaux que Commercial, sans privilège supplémentaire. Les profils restent distincts et administrables, sans synchronisation automatique imposée des personnalisations. DEC-0191 accorde à Facturation la consultation des données/sources nécessaires, création/consultation/modification autorisée/validation des factures, acomptes, avoirs et correctifs, retours brouillon et annulations autorisés, remise à disposition explicite après avoir total validé selon les règles acquises. Aucun droit initial de modification des offres/commandes/expéditions sources, administration des tarifs/utilisateurs/paramètres, suppression ou anonymisation Contact. Contrôles et audit inchangés. DEC-0192 accorde à Consultation la lecture métier large des tiers, contacts, articles, tarifs, offres, commandes, expéditions disponibles au Lot 0, factures, acomptes, avoirs et correctifs, prix et factures compris, sans restriction aux seules affaires de l’utilisateur ni présomption de restrictions fines futures. Protections existantes et isolation maintenues. Aucun droit initial de création, modification, validation, conversion, annulation, suppression ou anonymisation ; aucun accès à l’administration des utilisateurs/paramètres ni à l’audit global ; aucune permission d’export par défaut, notamment listes et données personnelles. L’export reste attribuable explicitement sous les règles existantes. QF-0046 est résolue fonctionnellement ; configuration et recette restent à produire. DEC-0205 complète les droits initiaux : seul Administrateur fonctionnel reçoit par défaut création/révocation des clés API pour soi, autrui et applications ; les autres profils ne les reçoivent pas, même pour soi (EXG-13-001/CA-03). Les profils restent administrables et les rôles personnalisés possibles.
  • CA-02 — Un administrateur peut ajuster séparément les droits de données et les actions métier.
  • CA-03 — Un droit de modification n’accorde pas implicitement le droit de valider ou d’approuver.
  • CA-04 — Un objet standard et un objet personnalisé suivent la même expérience de configuration.
• Dépendances : EXG-13-001, EXG-13-002, EXG-15-001.

EXG-13-009 — Explication des refus et diagnostic d’accès

• Priorité : Must
• Domaine : DOM-13
• Énoncé : « Elena doit expliquer à l’utilisateur et à l’administrateur pourquoi un accès, un champ ou une action est autorisé, masqué, désactivé ou refusé. »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; exigence d’administrabilité et d’application cohérente UI/API issue de EXG-13-003 et EXG-13-004.
• Critères d’acceptation :
  • CA-01 — Un refus indique une cause compréhensible : rôle, permission, périmètre, état du document ou exception.
  • CA-02 — Un diagnostic « pourquoi cet accès ? » restitue la chaîne de décision effective.
  • CA-03 — Le diagnostic distingue un droit absent d’un document filtré ou verrouillé par workflow.
  • CA-04 — Le diagnostic ne révèle aucune donnée que l’utilisateur n’est pas autorisé à connaître.
• Dépendances : EXG-13-003, EXG-13-004, EXG-13-005.

EXG-13-010 — Priorité des règles et permissions effectives

• 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.

EXG-13-011 — Traçabilité des changements de permissions

• Priorité : Must
• Domaine : DOM-13
• Énoncé : « Elena doit journaliser chaque changement de rôle, permission, règle de périmètre ou délégation avec son auteur, sa date, son avant/après et son périmètre d’impact. »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document), en complément de l’audit trail des objets sensibles prévu par EXG-13-006.
• Critères d’acceptation :
  • CA-01 — Toute création, modification, activation, désactivation ou restauration de configuration est tracée.
  • CA-02 — Le journal identifie l’auteur, la date, la configuration concernée et les différences avant/après.
  • CA-03 — Le journal est consultable et exportable par un administrateur autorisé.
  • CA-04 — Le journal des permissions est lui-même non modifiable et hébergé sur l’infrastructure d’audit indépendante.
  • CA-05 — Une modification de permission sensible est bloquée si son événement d’audit ne peut pas être garanti.
• Dépendances : EXG-13-006, EXG-13-010.

EXG-13-012 — Permissions temporaires et délégation contrôlée

• Priorité : Must
• Livraison : Lot 4 (DEC-0066).
• Domaine : DOM-13
• Énoncé : « Elena doit permettre d’accorder des permissions temporaires et de déléguer certaines actions dans un périmètre défini, avec dates, motif, approbateur et révocation contrôlée. »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; besoin opérationnel de remplacement, renfort ponctuel et intervention externe dans une PME industrielle.
• Critères d’acceptation :
  • CA-01 — Toute permission temporaire possède une date de début et une date de fin obligatoires.
  • CA-02 — La délégation précise les objets, actions et périmètres concernés.
  • CA-03 — L’expiration et la révocation retirent effectivement l’accès dans l’UI et l’API.
  • CA-04 — Le motif, l’approbateur, l’octroi, l’usage et la révocation sont tracés.
• Dépendances : EXG-13-008, EXG-13-011.

EXG-13-013 — Matrice et visualisation du périmètre effectif

• Priorité : Must
• Livraison : matrice obligatoire au Lot 0 (DEC-0065), limitée aux capacités disponibles selon DEC-0186. Dimensions futures entièrement masquées. Les critères ci-dessous sont conservés : la partie des périmètres fins de CA-02 et les droits temporaires/délégués de CA-03 sont vérifiés au Lot 4 avec leurs capacités ; filtres disponibles, droits directs/hérités et diagnostic réel restent au Lot 0. Aucun contrôle futur simulé, aucune protection existante désactivée.
• Domaine : DOM-13
• Énoncé : « Elena doit fournir une matrice graphique filtrable des permissions et visualiser le périmètre d’accès effectif par équipe, dépôt et affaire. »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; la granularité record rules/RBAC objet+champ observée chez Odoo et le CRM open-core étudié lors de l’analyse (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §DOM-13) doit rester lisible pour l’administrateur métier.
• Critères d’acceptation :
  • CA-01 — La matrice peut être filtrée par utilisateur, rôle, objet, action et niveau de permission.
  • CA-02 — La visualisation montre le périmètre par équipe, dépôt et affaire.
  • CA-03 — Les droits directs, hérités, temporaires et délégués sont distingués visuellement.
  • CA-04 — La matrice permet d’ouvrir le diagnostic d’une permission effective.
• Dépendances : EXG-13-009, EXG-13-010, EXG-13-012.

Recette intermédiaire — DEC-0186 : aucune dimension future affichée, même comme indisponible. Les autorisations/refus et leur origine directe ou héritée restent exacts, explicables et sans fuite. EXG-13-009/010 restent applicables aux capacités disponibles, y compris l’obligation existante de changement de priorité versionné et audité ; cela ne livre pas les écrans complets de comparaison/restauration du Lot 4.

EXG-13-014 — Versionnement et restauration de la sécurité

• Priorité : Must
• Livraison : Lot 4 (DEC-0066).
• Domaine : DOM-13
• Énoncé : « Elena doit versionner les configurations de sécurité, présenter leur impact avant activation et permettre la restauration contrôlée d’une version antérieure. »
• Justification : décision produit DEC-0013 (validée, résorbée dans le chapeau de ce document) ; la sécurité doit être réversible et administrable sans intervention technique.
• Critères d’acceptation :
  • CA-01 — Toute publication crée une version identifiable avec auteur, date et commentaire.
  • CA-02 — L’administrateur peut comparer deux versions et visualiser les impacts attendus.
  • CA-03 — Une version antérieure peut être restaurée après confirmation et autorisation.
  • CA-04 — Une restauration est auditée comme un changement de permissions.
• Dépendances : EXG-13-010, EXG-13-011, EXG-13-013.