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 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). DolibarrmodDataPolicy(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.