DOM-15 — Extensibilité & Personnalisation

Différenciant majeur : la référence est un CRM open-core récent à architecture métadonnées-driven étudié lors de l’analyse (modèle 100 % métadonnées-driven + workflow no-code visuel + API générée), que ni Dolibarr (extrafields en surcouche) ni Odoo Community (Studio = Enterprise) n’égalent (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-15). C’est l’axe d’architecture moderne qu’Elena vise à cumuler avec la profondeur industrielle d’un ERP propriétaire du marché des PME industrielles (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §8). Transverse dès le socle (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §4). Inspiration = concept, jamais reprise de code des produits étudiés (licences AGPL/Enterprise ; gouvernance des sources : dépôt pirates, accès restreint). Aucune reprise de code des ERP étudiés.

Décision d’architecture. Conformément à DEC-0005, Elena adopte une architecture hybride : les objets transactionnels industriels et leur logique métier restent natifs ; la couche d’extension décrit par métadonnées les objets et champs personnalisés, les automatisations et leurs surfaces. Les objets natifs et personnalisés sont soumis au même moteur de permissions, d’audit et d’exposition API ; une extension ne crée donc pas un régime de sécurité, de traçabilité ou d’intégration de second rang.

EXG-15-001 — Modèle de données métadonnées-driven (objets & champs comme données)

• Priorité : Must
• Domaine : DOM-15
• Énoncé : « Elena doit conserver nativement les objets transactionnels industriels et décrire par métadonnées les objets et champs personnalisés ; les objets natifs et personnalisés partagent les mêmes capacités applicables de permissions, d’audit, d’API et d’UI. »
• Justification : différenciateur du CRM open-core métadonnées-driven étudié lors de l’analyse (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §6 « modèle métadonnées-driven ») : modèle 100 % métadonnées-driven où objets et champs sont des données (bibliothèque de types de champs), objet standard et custom traités identiquement. Concept repris, implémentation à concevoir librement.
• Critères d’acceptation :
  • CA-01 — Création d’un objet custom sans développement, exposé en UI + API.
  • CA-02 — Bibliothèque de types de champs (texte, nombre, relation, sélection, etc.).
  • CA-03 — Un objet natif et un objet custom partagent le même moteur de permissions, audit et API pour leurs capacités applicables.
  • CA-04 — Aucun moteur générique ne remplace ou ne contourne les invariants et cycles de vie transactionnels natifs.
• Requiert : aucune (socle transverse).
• Conditionne : EXG-14-003, EXG-13-002.

EXG-15-002 — Champs personnalisés sur tout objet

• Priorité : Must
• Domaine : DOM-15
• Énoncé : « Elena doit permettre d’ajouter des champs personnalisés à tout objet métier, sans fork ni migration manuelle, disponibles en UI, recherche, export et API. »
• Justification : convergence (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §5 « extensibilité par champs personnalisés »). Dolibarr extrafields ; ERPNext Custom Fields ; zones utilisateurs tracées observées chez un ERP propriétaire du marché des PME industrielles. Forme aboutie : les champs définis par métadonnées du CRM open-core étudié lors de l’analyse.
• Critères d’acceptation :
  • CA-01 — Ajout d’un champ custom immédiatement utilisable (UI/API/export).
  • CA-02 — Champs custom tracés par l’audit trail (EXG-13-006).
  • CA-03 — Contraintes de validation configurables (obligatoire, format).
• Dépendances : EXG-15-001.

EXG-15-003 — Moteur de workflow / automatisations no-code visuel

• Priorité : Should
• Domaine : DOM-15
• Énoncé : « Elena doit fournir dès le Lot 0 le runtime d’automatisations configurable sans code ; l’éditeur no-code visuel est livré au Lot 6. Le runtime gère déclencheurs (création/modification/événement/planification), conditions et actions (mise à jour, création d’objet, notification, appel webhook), versionnés et tracés. »
• Justification : différenciateur du CRM open-core métadonnées-driven étudié lors de l’analyse — workflow no-code visuel (déclencheurs multiples, large catalogue d’actions, versionné/tracé) (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-15) ; base libre Odoo base.automation + actions serveur en Community. Concept repris, code non réutilisé.
• Critères d’acceptation :
  • CA-01 — Déclencheurs sur événements métier et planification.
  • CA-02 — Actions composables sans code (update, create, notify, webhook).
  • CA-03 — Historique des exécutions et versionnage des workflows.
  • CA-04 — Le runtime est disponible au Lot 0 sans présumer de la livraison de l’éditeur visuel, réservée au Lot 6.
• Requiert : EXG-14-004 (webhooks).
• Dépendances : EXG-15-001.

EXG-15-004 — Points d’extension code (hooks/événements) et modules/plug-ins

• Priorité : Should
• Livraison : Lot 6 pour les hooks et modules/plug-ins génériques. Les capacités MCU sont individualisées dans EXG-15-007 à EXG-15-010, Must au Lot 0 selon DEC-0219, sans avancer le reste de cette exigence.
• Domaine : DOM-15
• Énoncé : « Elena doit exposer des points d’extension (hooks/événements) et un mécanisme de modules/plug-ins permettant d’étendre le comportement sans modifier le cœur. »
• Justification : convergence (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-15). Dolibarr triggers/hooks + ModuleBuilder (pirates:analyses/erp/dolibarr/fiche.md §9) ; ERPNext hooks.py ; Odoo héritage _inherit.
• Critères d’acceptation :
  • CA-01 — Événements applicatifs observables par des extensions.
  • CA-02 — Installation/désinstallation de modules sans fork du cœur.
  • CA-03 — Contrat d’API d’extension documenté et stable.
• Dépendances : EXG-15-001, EXG-14-003.

EXG-15-005 — Formules et champs calculés

• Priorité : Could
• Domaine : DOM-15
• Énoncé : « Elena devrait permettre des champs calculés par formules paramétrables (conditions, agrégats) sans développement. »
• Justification : langage de formules (conditionnelles, requêtes) + zones utilisateurs, pratique de référence observée chez un ERP propriétaire du marché des PME industrielles (pirates:analyses/transversales/matrice-fonctionnelle-globale.md §2, DOM-15) ; Dolibarr formules du module Workflow.
• Critères d’acceptation :
  • CA-01 — Formule évaluée à la lecture ou à l’enregistrement.
  • CA-02 — Fonctions conditionnelles et agrégats disponibles.
• Dépendances : EXG-15-002.

EXG-15-006 — Personnalisation multilingue (libellés objets/champs)

• Priorité : Must
• Livraison : Lot 1, selon DEC-0217, priorité et critères conservés.
• Domaine : DOM-15
• Énoncé : « Elena doit permettre la traduction des libellés d’objets, de champs et de valeurs de référence, l’implémentation restant en anglais (identifiants techniques EN, libellés localisables). » Au Lot 1, le périmètre traduisible est celui des libellés apportés ou paramétrés par le client — objets et champs custom, valeurs de référence qu’il compose — les libellés standard restant traduits par l’éditeur dans les langues supportées (DEC-0277). Au Lot 1, les langues gérées sont celles que le produit livre traduites — français et anglais ; un libellé personnalisé sans traduction s’affiche dans la langue par défaut de l’organisation, à défaut dans sa langue de saisie, jamais comme identifiant technique ni libellé vide ; l’ajout d’une langue relève d’une livraison de l’éditeur (DEC-0278).
• Justification : cadrage produit Elena (multilingue, base d’implémentation EN, prose/libellés FR) ; convergence multi-langue observée (Dolibarr htdocs/langs/, pirates:analyses/transversales/matrice-fonctionnelle-globale.md §3 « identifiant technique EN / libellé FR »).
• Critères d’acceptation :
  • CA-01 — Libellés d’objets/champs custom traduisibles par langue. Sont également traduisibles par langue les valeurs de référence paramétrées par le client — options de champs custom et listes qu’il compose ; les libellés des objets, champs et valeurs de référence standard sont traduits par l’éditeur dans les langues supportées et ne sont pas éditables par le client (DEC-0277).
  • CA-02 — Identifiants techniques stables en anglais, indépendants de la langue d’affichage.
• Dépendances : EXG-15-001, EXG-12-001.

MCU — capacités individualisées du Lot 0

Le périmètre de DEC-0219 reprend les comportements acquis de la console éditeur, de l’administration d’instance et du socle fonctionnel qualifié. La priorité MCU est Must au Lot 0 sur confirmation explicite de Yannic, sans hériter par analogie de celle des extensions génériques. Ni les constats historiques de parité ni ces exigences ne constituent une recette actuelle de toute la plateforme. Isolation des sociétés et absence de remontée des données métier restent imposées par DEC-0032 ; journal éditeur et audit métier sont distincts. Droits, accessibilité et langues acquis sont conservés. Aucun quota nouveau, politique de reprise ou rapport de revalidation futur n’est ajouté par cette formalisation.

EXG-15-007 — MCU : console éditeur, registre, droits et quotas

• Priorité : Must
• Livraison : Lot 0 (DEC-0219).
• Domaine : DOM-15
• Énoncé : « Elena doit fournir une console éditeur distincte de l’administration des instances pour consulter registre et quotas et gérer les habilitations des consultants. »
• Justification : parité MCU et socle acquis de la qualification MCU.
• Critères d’acceptation :
  • CA-01 — L’administrateur éditeur consulte registre des instances/consultants et quotas en lecture seule ; politique et consommation sont distinguées. Ces vues ne donnent pas accès aux données métier des sociétés.
  • CA-02 — Un octroi identifie consultant, opération et portée ; les droits globaux inertes sont distingués des droits effectifs. Un octroi déjà présent est signalé ; la révocation exige confirmation. Un échec d’audit de mutation n’est pas annoncé comme une modification réussie.
  • CA-03 — Le rôle administrateur éditeur ne donne pas à lui seul le droit de dépôt consultant ; les parcours et autorisations sont distincts de ceux de l’instance métier.
• Requiert : aucune exigence métier d’instance (authentification et droits éditeur propres à ce périmètre).
• Conditionne : EXG-15-008 (parcours consultant), EXG-15-009 (journal éditeur).
• Co-requis : aucun.

EXG-15-008 — MCU : kit, dépôt et révocation des surcharges

• Priorité : Must
• Livraison : Lot 0 (DEC-0219).
• Domaine : DOM-15
• Énoncé : « Elena doit permettre au consultant habilité de télécharger le kit, déposer une surcharge et demander sa révocation, avec restitution fidèle du résultat du canal. »
• Justification : parcours consultant de la référence de parité MCU, sans nouvelle politique d’exploitation.
• Critères d’acceptation :
  • CA-01 — Le consultant autorisé accède au kit et aux actions de dépôt/révocation dans la portée de ses habilitations ; l’administration éditeur seule ne suffit pas.
  • CA-02 — Les rapports de dépôt et révocation restituent le verdict du canal sans le recalculer ; refus, dépassement de quota, panne et absence de réponse sont distingués, sans faux succès.
  • CA-03 — Une révocation effectuée mais suivie d’un échec de resynchronisation indique distinctement les deux résultats, sans les transformer en réussite complète ni prescrire de nouvelle reprise automatique.
• Requiert : EXG-15-007 (habilitations éditeur).
• Conditionne : aucune.
• Co-requis : aucun.

EXG-15-009 — MCU : journal éditeur et contrôle explicite d’intégrité

• Priorité : Must
• Livraison : Lot 0 (DEC-0219).
• Domaine : DOM-15
• Énoncé : « Elena doit permettre à l’acteur éditeur habilité de consulter un journal filtrable et paginé et d’en demander explicitement la vérification d’intégrité. »
• Justification : journal de la référence MCU ; il ne remonte pas l’audit métier des instances.
• Critères d’acceptation :
  • CA-01 — Le journal permet les filtres et la pagination de la référence ; la vérification d’intégrité est déclenchée sur action explicite et restitue son résultat, sans certifier une portée supérieure à celle contrôlée.
  • CA-02 — Les contextes absent, présent, effacé et illisible sont distingués ; la limitation de preuve de troncature reste visible, sans être présentée comme une preuve cryptographique complète.
  • CA-03 — L’accès au journal éditeur ne donne pas accès aux identités et à l’audit métier des sociétés ; leur isolation reste conservée.
• Requiert : EXG-15-007 (accès éditeur).
• Conditionne : aucune.
• Co-requis : aucun.

EXG-15-010 — MCU : consultation et gestion des surcharges dans l’instance

• Priorité : Must
• Livraison : Lot 0 (DEC-0219).
• Domaine : DOM-15
• Énoncé : « Elena doit permettre de consulter les surcharges de l’instance et, avec un droit de gestion distinct, de les désactiver ou réactiver en conservant le repli sur la page standard. »
• Justification : parité Foundation D-bis/H et arbitrage ELENA-813, sans réarbitrage des droits acquis.
• Critères d’acceptation :
  • CA-01 — mcu_override.view permet la consultation ; mcu_override.manage inclut la lecture et autorise les actions de gestion. L’accès général administrateur déjà acquis n’est pas supprimé ; un utilisateur lecture seule n’obtient pas les actions de gestion.
  • CA-02 — Une surcharge incompatible laisse la page standard. Désactiver remet le standard sans supprimer le fichier ; réactiver remet la surcharge en service sous les contrôles applicables. Les actions requièrent confirmation et audit.
  • CA-03 — La liste distingue états vide, injoignable et invalide, affiche le nombre de surcharges et l’auteur de désactivation lorsqu’il existe. Les diagnostics de droits suivent le périmètre Lot 0 sans avancer les dimensions de sécurité fine du Lot 4 (DEC-0186).
• Requiert : EXG-13-002 (droits d’instance), EXG-13-006 (audit d’instance).
• Conditionne : aucune.
• Co-requis : aucun.