Aller au contenu principal

ENG-001.5J — Audit d'ownership de commune_info_sections

MissionENG-001.5J — Préparer la migration des infos pratiques
Rattaché àENG-001.5 — Extraction de Municipal Management ; ENG-001.5 — Recalibrage roadmap ; ENG-001.5I — Rapport d'implémentation
TypeAudit documentaire — aucune implémentation
Dépôtdmv-docs
StatutDécision 13.C documentée — ownership validé pour Municipal Management

Ce document traite explicitement la décision 13.C, désormais résolue : ownership de commune_info_sections par Municipal Management. Il ne modifie aucun code et formalise la décision validée.

1. Constat factuel​

1.1 Structure réelle​

commune_info_sections est une table autonome, sans commune_id, avec les colonnes :

  • id
  • slug
  • label
  • icone
  • description
  • ordre
  • active
  • created_at

Elle n'a :

  • aucun modèle Eloquent dédié ;
  • aucune clé étrangère vers commune_infos ;
  • aucune contrainte SQL reliant slug à commune_infos.section.

1.2 Chemins de lecture et d'écriture confirmés​

Lecture :

  • AdminCommuneInfoController::indexSections() lit la table complète, ordonnée par ordre.
  • AdminCommuneInfoController::fullCommune() relit la même table, puis groupe commune_infos par section.

Écriture :

  • AdminCommuneInfoController::storeSection()
  • AdminCommuneInfoController::updateSection()
  • AdminCommuneInfoController::destroySection()

Aucun autre chemin confirmé n'a été trouvé dans Mairie, Territory, MunicipalManagement, les commandes, les jobs ou les imports.

1.3 Consommateurs confirmés​

Consommateur direct confirmé :

  • dmv-backoffice/src/pages/Communes.jsx :
    • charge /admin/commune-sections ;
    • affiche le catalogue ;
    • mélange ce catalogue avec les sections effectivement présentes dans infos_by_section.

Aucun consommateur direct confirmé :

  • ni dans dmv-workspace ;
  • ni dans dmv-public.

Workspace et Public consomment commune_infos, puis reconstruisent leurs sections côté frontend à partir du champ section et de métadonnées locales.

2. Rôle réel de commune_info_sections​

2.1 Est-ce une simple structure d'affichage ?​

Partiellement oui, mais pas uniquement.

La table porte clairement des métadonnées d'affichage :

  • libellé (label) ;
  • icône (icone) ;
  • description ;
  • ordre ;
  • activation (active).

Mais elle ne sert pas seulement à « peindre » l'UI : elle définit aussi un catalogue partagé de rubriques attendues pour les infos pratiques, utilisé par Admin pour structurer l'édition.

2.2 Porte-t-elle une sémantique métier municipale ?​

Oui, faiblement mais réellement.

Les slugs (mairie, urgences, dechetterie, etc.) classent des informations pratiques municipales. Ce n'est pas une configuration transverse générique de plateforme ; c'est une taxonomie propre au domaine des infos pratiques communales.

2.3 Est-elle utilisée pour regrouper ou ordonner les informations pratiques ?​

Oui.

  • fullCommune() retourne le catalogue de sections ordonné par ordre.
  • fullCommune() retourne séparément infos_by_section, groupé par commune_infos.section.
  • le backoffice reconstruit ensuite l'affichage à partir du catalogue et des sections présentes dans les données.

La relation est donc la suivante :

  • commune_infos.section porte la clé de classement ;
  • commune_info_sections porte la taxonomie partagée et l'ordre d'affichage attendu.

2.4 Peut-elle exister indépendamment de commune_infos ?​

Oui.

Le code Admin gère le catalogue indépendamment du contenu :

  • une section peut être créée avant toute info ;
  • une section peut rester vide ;
  • une section peut être supprimée sans transaction métier conjointe sur commune_infos.

2.5 Est-elle modifiée uniquement par Admin ?​

Oui, dans le code observé.

Aucune écriture n'a été trouvée ailleurs.

2.6 Est-elle consommée par Workspace ou Public ?​

Non, pas directement.

Les frontends dmv-workspace et dmv-public ne lisent pas /admin/commune-sections et ne reçoivent pas commune_info_sections dans leurs endpoints publics/protégés usuels. Ils se basent sur commune_infos.section et sur des tables de correspondance locales.

2.7 Est-elle propre à une commune ou partagée ?​

C'est un référentiel partagé.

La table ne contient aucun commune_id. Le catalogue est global à l'application.

3. Options d'ownership​

Option A — Ownership Municipal Management​

commune_info_sections et commune_infos appartiennent au même Bounded Context.

Analyse​

  • Cohérence métier : forte. Le catalogue n'a de sens que pour structurer les infos pratiques communales.
  • Simplicité de migration : meilleure option. La taxonomie et les données qu'elle structure migrent ensemble.
  • Dépendances : faibles. Admin devient simple adaptateur vers Municipal Management ; Territory n'a pas à dépendre d'un second contexte.
  • Impacts frontend : nuls attendus si les façades API restent inchangées ; Workspace/Public ne consomment pas ce catalogue aujourd'hui.
  • Impacts Admin : limités à une délégation de CRUD vers le contrat Municipal Management.
  • Risques : le caractère global du catalogue pourrait faire croire à une configuration transverse, mais aucun usage transverse réel n'a été observé.

Avantages​

  • Un seul owner pour la taxonomie et les données classées.
  • Aucun nouveau Bounded Context ou contrat transverse à introduire.
  • Meilleure lisibilité DDD : les rubriques des infos pratiques restent dans le même domaine que les infos pratiques elles-mêmes.

Inconvénients​

  • Le catalogue est partagé globalement, pas par commune.
  • Admin reste probablement le seul écrivain de ce sous-ensemble, ce qui peut donner l'impression d'une donnée « backoffice » plus que « métier ».

Option B — Ownership Settings ou Platform Service​

commune_info_sections devient une configuration transverse séparée, commune_infos restant dans Municipal Management.

Analyse​

  • Cohérence métier : faible à moyenne. Le code observé ne montre aucun réemploi transverse.
  • Simplicité de migration : mauvaise. Il faudrait créer une dépendance inter-contextes juste pour récupérer une taxonomie aujourd'hui locale au besoin Admin.
  • Dépendances : plus fortes. Municipal Management ou Admin devraient lire un autre contexte.
  • Impacts frontend : nuls pour Workspace/Public, mais plus de complexité côté backoffice.
  • Impacts Admin : augmentation du couplage et des points de défaillance.
  • Risques : sur-architecture, dilution de responsabilité, modèle plus théorique que fondé sur le code réel.

Avantages​

  • Sépare explicitement le catalogue partagé du contenu par commune.
  • Pourrait servir de base si une vraie gouvernance transverse des rubriques apparaît plus tard.

Inconvénients​

  • Aucun besoin concret observé aujourd'hui.
  • Ajoute une dépendance transverse sans bénéfice immédiat.
  • Rend ENG-001.5J plus lourde qu'une migration de conservation de comportement.

Option C — Séparation référentiel / affectation​

Un référentiel de sections appartient à Settings, tandis que l'affectation et l'ordre par commune restent dans Municipal Management.

Analyse​

  • Cohérence métier : théorique, mais non reflétée par le schéma actuel.
  • Simplicité de migration : très mauvaise. Le modèle actuel n'a ni affectation par commune, ni ordre par commune au niveau des sections.
  • Dépendances : maximales parmi les trois options.
  • Impacts frontend : potentiellement nuls si tout est masqué derrière les API existantes, mais coût d'implémentation nettement supérieur.
  • Impacts Admin : demande une refonte structurelle supplémentaire.
  • Risques : introduit un design nouveau hors périmètre, donc incompatible avec une mission de migration sans évolution fonctionnelle.

Avantages​

  • Modèle conceptuellement propre si l'on voulait distinguer taxonomie globale et usage local.

Inconvénients​

  • Le code réel ne fournit aucune base pour ce découpage.
  • Nécessiterait des changements de données et de contrats non demandés.
  • Rompt le principe de migration incrémentale à comportement constant.

4. Recommandation​

Recommandation proposée à l'architecte​

Recommander l'Option A : ownership Municipal Management pour commune_info_sections et commune_infos ensemble.

Justification​

  • commune_info_sections n'a aujourd'hui qu'un seul usage réel : structurer les infos pratiques communales.
  • Aucun usage transverse de type Settings/Platform n'a été observé.
  • Aucun frontend public ou workspace ne consomme directement ce catalogue.
  • La migration la plus sûre est celle qui préserve le comportement en changeant seulement l'owner applicatif.
  • L'Option C exigerait une refonte de modèle non compatible avec ENG-001.5J.

5. Décision 13.C à rendre​

5. Décision 13.C rendue​

Décision retenue​

A — Municipal Management possède commune_info_sections et commune_infos.

Motivation validée​

  • commune_info_sections est un référentiel métier propre aux informations municipales ;
  • il porte leur classement, leur présentation et leur ordre ;
  • ce n'est pas une configuration technique transverse ;
  • son caractère global ne change pas son ownership métier ;
  • un déplacement vers Settings créerait une séparation artificielle.

Conséquence pour la suite​

  • ENG-001.5J peut être découpée en J1, J2, J3 sans blocage d'ownership ;
  • les futurs contrats de lecture/écriture des sections relèvent de Municipal Management ;
  • Admin restera une façade d'administration de ce référentiel métier.