Merge branch 'develop' into feature/ERP-115-correctifs-front

Conflit modify/delete sur ClientInformationCompletenessValidator resolu en gardant la SUPPRESSION (RG-1.04 retiree). Le commentaire de SupplierInformationCompletenessValidator (M2) ne reference plus la classe M1 supprimee. develop integre jusqu'a v0.1.96 (M2 fournisseurs). Suites back (578) + front (256) vertes apres test-db-setup.

docs/specs/M2-suppliers/spec-back.md

@@ -126,7 +126,7 @@ Toutes les entités métier nouvelles implémentent `TimestampableInterface` + `
 
 Notes (miroir M1) :
 - **Compta édite uniquement l'onglet Comptabilité** (`accounting.manage`) d'un fournisseur existant. Compta ne peut pas **créer** un fournisseur (pas de `manage` global).
-- **Commerciale** a `view` + `manage` mais **pas** `accounting.view` → l'onglet Comptabilité est masqué (front) et filtré (back, 2 niveaux : `security` API Platform + `SupplierProvider`).
+- **Commerciale** a `view` + `manage` mais **pas** `accounting.view` → l'onglet Comptabilité est masqué (front) et filtré (back). Mécanisme réel (le code fait foi) : le groupe de lecture `supplier:read:accounting` n'est **pas** dans le contexte de sérialisation par défaut ; le `SupplierReadGroupContextBuilder` ne l'**ajoute** dynamiquement que si l'utilisateur porte `commercial.suppliers.accounting.view` (gating **par ajout** de groupe, jamais par retrait). Sans la permission, les champs comptables (et les RIB) ne sont donc jamais sérialisés. La colonne SIREN de l'export XLSX suit la même règle (`accounting.view`).
 - **Bureau** : `view` + `manage` (tout sauf Comptabilité).
 - **Usine** : aucune permission → item sidebar invisible, accès direct 403.
 
@@ -159,9 +159,11 @@ final class SupplierFieldNormalizer
 
 Le formatage `XX XX XX XX XX` est fait à l'affichage côté front. Le back stocke `0612345678` (chiffres seuls).
 
-### 2.12 Liste : embed catégories + sites + fetch-joins (cohérence M1/ERP-62)
+### 2.12 Liste : embed catégories + sites + hydratation anti-N+1 (cohérence M1/ERP-62)
 
-Décision d'alignement (02/06/2026) : la **liste** `GET /api/suppliers` **embarque** les `categories[]` (avec `code`/`name`) et les `sites[]` (avec `name`/`postalCode` — pas de `code`), comme la liste Clients après ERP-62 — et **non** des champs dérivés aplatis. Conséquence performance : le `DoctrineSupplierRepository` **DOIT** poser des **fetch-joins** (`leftJoin`+`addSelect`) sur `categories` et `addresses.sites` dans la requête de liste pour éviter le N+1. Les `sites` de la liste sont agrégés/dédoublonnés via `Supplier::getSites()` (cf. § 3.3). Le contrat de sérialisation (groupes `category:read` / `site:read` dans le contexte) est posé **une seule fois** sur l'entité — source de vérité unique, le front ne le redéfinit pas.
+Décision d'alignement (02/06/2026) : la **liste** `GET /api/suppliers` **embarque** les `categories[]` (avec `code`/`name`) et les `sites[]` (avec `name`/`postalCode` — pas de `code`), comme la liste Clients après ERP-62 — et **non** des champs dérivés aplatis.
+
+Conséquence performance — **implémentation réelle (le code fait foi)** : le `DoctrineSupplierRepository` **ne fetch-joine PAS** les to-many dans la requête de sélection (`createListQueryBuilder` ne fait que filtres + tri). L'anti-N+1 passe par `hydrateListCollections()` (puis `hydrateContacts()`) : une fois le jeu de fournisseurs borné (page ou export), des requêtes **`IN` bornées séparées** remplissent `categories`, puis `addresses.sites`, puis `contacts` sur les **mêmes** instances `Supplier` (identity map). Ce découpage évite le **produit cartésien** qu'un fetch-join combiné `categories × addresses.sites` imposerait aux chemins non paginés (export, `?pagination=false`). Les `sites` de la liste sont agrégés/dédoublonnés via `Supplier::getSites()` (cf. § 3.3). Le contrat de sérialisation (groupes `category:read` / `site:read` dans le contexte) est posé **une seule fois** sur l'entité — source de vérité unique, le front ne le redéfinit pas.
 
 > Dépendance confirmée sur le JSON réel (#82 mergé) : `Category` expose `code`/`name` sous `category:read` ; `Site` expose `name`/`postalCode`/`city`/`color` sous `site:read` (**pas de `code`**). L'embed est pleinement matérialisé.
 
@@ -213,6 +215,8 @@ Namespace : **`DoctrineMigrations` (racine `migrations/`)** — fichier `migrati
 
 > **Rappel règle ABSOLUE n°12** : chaque colonne créée ci-dessous DOIT recevoir son `COMMENT ON COLUMN`. Les 4 colonnes Timestampable/Blamable passent par le helper `addStandardTimestampableBlamableComments($schema, '<table>')`. Le SQL ci-dessous montre la structure ; les `COMMENT ON COLUMN` (un par colonne métier) sont à écrire dans la migration (exemples §3.2.bis).
 
+> **Types réels de la migration (le code fait foi)** : le SQL ci-dessous est *illustratif*. La migration mergée (`Version20260605130000`) utilise le **style aligné M1** : clés primaires en `INT GENERATED BY DEFAULT AS IDENTITY` (et **non** `SERIAL`) et horodatages en `TIMESTAMP(0) WITHOUT TIME ZONE` (et **non** `TIMESTAMPTZ`, car le `TimestampableBlamableTrait` mappe `datetime_immutable`). Garantit que `schema:update` reste un no-op une fois les entités mappées.
+
 ```sql
 -- =====================================================================
 -- Seed taxonomie : nouveau type FOURNISSEUR (référentiels comptables = M1, non recréés)
@@ -422,8 +426,10 @@ use Symfony\Component\Validator\Constraints as Assert;
             // Cohérence M1/ERP-62 : la LISTE embarque catégories + sites (pas de
             // champ dérivé aplati). Maillon (c) : category:read + site:read dans
             // le contexte pour exposer Category(code/name) + Site(name/postalCode).
-            // ⚠ Le SupplierRepository DOIT fetch-join categories + addresses.sites
-            // pour éviter le N+1 sur la liste (cf. § 2.12).
+            // ⚠ Anti-N+1 : pas de fetch-join dans la requête de liste — le
+            // SupplierRepository hydrate categories/sites/contacts via des requêtes
+            // IN bornées séparées (hydrateListCollections), pour éviter le produit
+            // cartésien sur les chemins non paginés (export) — cf. § 2.12.
             normalizationContext: ['groups' => [
                 'supplier:read',
                 'category:read',
@@ -442,13 +448,14 @@ use Symfony\Component\Validator\Constraints as Assert;
             normalizationContext: ['groups' => [
                 'supplier:read',
                 'supplier:item:read',        // embed contacts / addresses
-                'supplier:read:accounting',  // scalaires compta + embed ribs (filtré par le Provider selon accounting.view)
+                // ⚠ supplier:read:accounting est volontairement ABSENT ici : il est
+                // AJOUTÉ dynamiquement par le SupplierReadGroupContextBuilder quand
+                // l'user porte accounting.view (gating par ajout, pas par retrait —
+                // parade bug #4 M1). Il porte les scalaires compta + l'embed ribs.
                 'category:read',             // embed des Category (id/code/name) — relation imbriquée
                 'site:read',                 // embed des Site (id/name/postalCode/city/color, pas de code) — relation imbriquée
                 'default:read',
             ]],
-            // Le Provider RETIRE supplier:read:accounting du contexte si l'user
-            // n'a pas is_granted('commercial.suppliers.accounting.view').
             provider: SupplierProvider::class,
         ),
         new Post(
@@ -458,10 +465,13 @@ use Symfony\Component\Validator\Constraints as Assert;
             processor: SupplierProcessor::class,
         ),
         new Patch(
-            security: "is_granted('commercial.suppliers.manage')",
-            // Le SupplierProcessor inspecte les groupes envoyés pour autoriser
-            // onglet par onglet (cf. § 2.10 + § 5). Patch des champs comptables
-            // exige is_granted('commercial.suppliers.accounting.manage') ;
+            // Security élargie : `manage` OU `accounting.manage` — le rôle Compta
+            // n'a pas `manage` mais doit pouvoir éditer l'onglet Comptabilité d'un
+            // fournisseur existant (§ 2.9). Le SupplierProcessor re-gate ensuite
+            // onglet par onglet (mode strict RG-2.16) :
+            security: "is_granted('commercial.suppliers.manage') or is_granted('commercial.suppliers.accounting.manage')",
+            // Patch des champs comptables exige accounting.manage (guardAccounting) ;
+            // champs main/information exigent manage (guardManage) ;
             // patch isArchived exige is_granted('commercial.suppliers.archive').
             normalizationContext: ['groups' => ['supplier:read', 'default:read']],
             denormalizationContext: ['groups' => [
@@ -711,91 +721,108 @@ Même pattern que les jumelles `Client*` (`#[Auditable]`, `TimestampableBlamable
 | Scalaires Comptabilité (siren, refs…) | `supplier:read:accounting` | ✅ (gated) | refs (`tvaMode`…) id+label ∈ `supplier:read:accounting` |
 | `ribs[]` (label/bic/iban) | `ribs` ∈ `supplier:read:accounting` | ✅ (gated) | — |
 
-### 4.0.bis Réponses JSON de référence (DoD — à confirmer sur l'API réelle)
+### 4.0.bis Réponses JSON de référence (DoD — RÉELLES, capturées ERP-92)
 
-> **Definition of Done de cette spec back (RETEX M1 §3)** : avant d'écrire les tickets front, créer un fournisseur de test et **coller ici les réponses RÉELLES** de `GET /api/suppliers` et `GET /api/suppliers/{id}`. Les containers n'étant pas lancés au moment de la rédaction, le JSON ci-dessous est le **contrat CIBLE** — à valider/remplacer par la réponse réelle (`make start` puis `curl`). Toute donnée affichée par le front DOIT apparaître dans ce JSON.
+> **Definition of Done CLÔTURÉE (ERP-92, 2026-06-05)** : les réponses ci-dessous sont **réelles**, capturées sur l'API de test via PHPUnit (`SupplierSerializationContractTest`, fournisseur complet seedé). Les `id`/timestamps sont illustratifs (run de test). Toute donnée affichée par le front DOIT apparaître dans ce JSON. Front #93→#96 peuvent démarrer.
+>
+> **2 constats validés à la capture** (cf. § 4.0.ter) :
+> 1. 🔧 **Fix ERP-92** : les réfs comptables (`tvaMode`/`paymentDelay`/`paymentType`/`bank`) sortaient en **IRI nu** (les entités partagées ne portaient que `client:read:accounting`, pas `supplier:read:accounting`). Corrigé → objet `{id, code, label}` embarqué (le front consultation/édition affiche le libellé sans fetch).
+> 2. ℹ️ **Liste « riche »** : le groupe `supplier:read` étant partagé liste+détail, la **collection embarque tout le bloc Information** (et, pour un user `accounting.view`, les scalaires compta + `ribs[]`). Comportement identique au M1 (groupe `client:read` partagé) — la datatable n'affiche que Nom/Catégories/Site(s)/MAJ, mais le payload est complet. Le gating `accounting` reste effectif (Commerciale ne voit ni compta ni `ribs` en liste comme en détail).
 
 > **Forme d'enveloppe confirmée sur le M1 réel** (API Platform 4.2) : JSON-LD **sans préfixe `hydra:`** → clés `member` / `totalItems` / `view`, avec `@type: "Collection"` et `view.@type: "PartialCollectionView"`. `Content-Type: application/ld+json; charset=utf-8`. Pagination défaut 10 confirmée. Login réel = `POST /api/login_check` (nginx réécrit vers `/login_check`), réponse `204` + cookie HttpOnly `BEARER`.
 
-`GET /api/suppliers` (liste, ADMIN) :
+`GET /api/suppliers?search=…` (liste, ADMIN — un membre) :
 ```json
 {
   "@context": "/api/contexts/Supplier",
   "@id": "/api/suppliers",
   "@type": "Collection",
-  "totalItems": 13,
+  "totalItems": 1,
   "member": [
     {
-      "@id": "/api/suppliers/1",
+      "@id": "/api/suppliers/85",
       "@type": "Supplier",
-      "id": 1,
-      "companyName": "RECYCLA SAS",
+      "id": 85,
+      "companyName": "DOD59393F 862875",
       "categories": [
-        {"@id": "/api/categories/12", "id": 12, "code": "NEGOCIANT", "name": "Négociant"}
+        {"@type": "Category", "@id": "/api/categories/2279", "id": 2279, "name": "test_cli_cat_fr_negociant", "code": "NEGOCIANT",
+         "categoryType": {"@id": "/api/category_types/602", "@type": "CategoryType", "id": 602, "code": "FOURNISSEUR", "label": "Fournisseur"},
+         "createdAt": "…", "updatedAt": "…"}
       ],
+      "description": "Fournisseur de test complet.",
+      "competitors": "Concurrent A, Concurrent B",
+      "foundedAt": "2008-04-01T00:00:00+02:00",
+      "employeesCount": 42,
+      "revenueAmount": "1500000.00",
+      "directorName": "Jean Dupont",
+      "profitAmount": "120000.00",
+      "volumeForecast": 8000,
+      "siren": "123456789",
+      "accountNumber": "F0001",
+      "tvaMode": {"@id": "/api/tva_modes/30", "@type": "TvaMode", "id": 30, "code": "FRANCE_VENTES", "label": "France (ventes)"},
+      "nTva": "FR00123456789",
+      "paymentDelay": {"@id": "/api/payment_delays/11", "@type": "PaymentDelay", "id": 11, "code": "J30", "label": "30 jours"},
+      "paymentType": {"@id": "/api/payment_types/14", "@type": "PaymentType", "id": 14, "code": "LCR", "label": "LCR"},
+      "ribs": [
+        {"@id": "/api/supplier_ribs/27", "@type": "SupplierRib", "id": 27, "label": "Compte principal", "bic": "BNPAFRPPXXX", "iban": "FR1420041010050500013M02606", "createdAt": "…", "updatedAt": "…"}
+      ],
+      "createdAt": "…", "updatedAt": "…",
       "sites": [
-        {"@id": "/api/sites/1", "id": 1, "name": "Chatellerault", "postalCode": "86100", "city": "Châtellerault", "color": "#056CF2"},
-        {"@id": "/api/sites/2", "id": 2, "name": "Saint-Jean", "postalCode": "17400", "city": "Fontenet", "color": "#…"}
+        {"@type": "Site", "@id": "/api/sites/87", "id": 87, "name": "Chatellerault", "street": "14 All. d'Argenson", "postalCode": "86100", "city": "Châtellerault", "color": "#056CF2", "fullAddress": "14 All. d'Argenson\n86100 Châtellerault"},
+        {"@type": "Site", "@id": "/api/sites/88", "id": 88, "name": "Saint-Jean", "street": "Z i", "postalCode": "17400", "city": "Fontenet", "color": "#F3CB00", "fullAddress": "Z i\n17400 Fontenet"}
       ],
-      "updatedAt": "2026-02-17T09:30:00+00:00",
       "isArchived": false
     }
   ],
-  "view": {
-    "@id": "/api/suppliers?page=1",
-    "@type": "PartialCollectionView",
-    "first": "/api/suppliers?page=1",
-    "last": "/api/suppliers?page=2",
-    "next": "/api/suppliers?page=2"
-  }
+  "view": {"@id": "/api/suppliers?search=…", "@type": "PartialCollectionView"}
 }
 ```
 
-> Les fournisseurs archivés sont **exclus** du `totalItems` (sur le M1, 14 clients en base → `totalItems: 13` car 1 archivé filtré par le Provider). `categories[]` (avec `code`/`name`) et `sites[]` (avec `name`/`postalCode` — **pas de `code`**) sont **embarqués** (cohérence M1/ERP-62, § 2.12) ; `sites` est l'agrégat dédoublonné des adresses via `Supplier::getSites()`. Fetch-joins repository obligatoires (anti N+1).
+> Les fournisseurs archivés sont **exclus** du `totalItems` (RG-2.17 — filtré par le Provider). `categories[]` (avec `code`/`name`) et `sites[]` (avec `name`/`postalCode` — **pas de `code`**) sont **embarqués** (cohérence M1/ERP-62, § 2.12) ; `sites` est l'agrégat dédoublonné des adresses via `Supplier::getSites()`. Fetch-joins repository (anti N+1) **vérifiés par test** (`SupplierListTest::testListQueryCountDoesNotGrowWithRowCount` : nombre de requêtes constant entre 2 et 4 fournisseurs). ⚠️ Le membre embarque aussi l'**Information complète** et — pour un user `accounting.view` (ici admin) — les **scalaires compta + `ribs[]`** (groupe `supplier:read` partagé liste/détail). Pour la **Commerciale** (sans `accounting.view`), `siren`/`tvaMode`/`paymentType`/`ribs`… **disparaissent** de chaque membre.
 
-`GET /api/suppliers/1` (détail — user avec `accounting.view`) :
+`GET /api/suppliers/85` (détail — user avec `accounting.view`) :
 ```json
 {
-  "@id": "/api/suppliers/1",
+  "@context": "/api/contexts/Supplier",
+  "@id": "/api/suppliers/85",
   "@type": "Supplier",
-  "id": 1,
-  "companyName": "RECYCLA SAS",
+  "id": 85,
+  "companyName": "DOD59393F 862875",
   "categories": [
-    {"@id": "/api/categories/12", "id": 12, "code": "NEGOCIANT", "name": "Négociant"}
+    {"@type": "Category", "@id": "/api/categories/2279", "id": 2279, "name": "test_cli_cat_fr_negociant", "code": "NEGOCIANT",
+     "categoryType": {"@id": "/api/category_types/602", "@type": "CategoryType", "id": 602, "code": "FOURNISSEUR", "label": "Fournisseur"}}
   ],
-  "description": "…", "competitors": "…", "foundedAt": "2008-04-01",
-  "employeesCount": 42, "revenueAmount": "1500000.00", "directorName": "…",
-  "profitAmount": "120000.00", "volumeForecast": 8000,
+  "description": "Fournisseur de test complet.", "competitors": "Concurrent A, Concurrent B",
+  "foundedAt": "2008-04-01T00:00:00+02:00", "employeesCount": 42, "revenueAmount": "1500000.00",
+  "directorName": "Jean Dupont", "profitAmount": "120000.00", "volumeForecast": 8000,
+  "siren": "123456789", "accountNumber": "F0001",
+  "tvaMode": {"@id": "/api/tva_modes/30", "@type": "TvaMode", "id": 30, "code": "FRANCE_VENTES", "label": "France (ventes)"},
+  "nTva": "FR00123456789",
+  "paymentDelay": {"@id": "/api/payment_delays/11", "@type": "PaymentDelay", "id": 11, "code": "J30", "label": "30 jours"},
+  "paymentType": {"@id": "/api/payment_types/14", "@type": "PaymentType", "id": 14, "code": "LCR", "label": "LCR"},
   "contacts": [
-    {"@id": "/api/supplier_contacts/1", "id": 1, "firstName": "Marie", "lastName": "Martin",
-     "jobTitle": "Responsable achats", "phonePrimary": "0612345678", "phoneSecondary": null,
-     "email": "marie.martin@recycla.fr"}
+    {"@id": "/api/supplier_contacts/39", "@type": "SupplierContact", "id": 39, "firstName": "Marie", "lastName": "Martin",
+     "jobTitle": "Responsable achats", "phonePrimary": "0612345678", "email": "marie.martin@seed.test"}
   ],
   "addresses": [
-    {"@id": "/api/supplier_addresses/1", "id": 1, "addressType": "DEPART",
-     "country": "France", "postalCode": "86000", "city": "Poitiers",
-     "street": "12 rue des Acacias", "streetComplement": null,
+    {"@id": "/api/supplier_addresses/33", "@type": "SupplierAddress", "id": 33, "addressType": "DEPART",
+     "country": "France", "postalCode": "86000", "city": "Poitiers", "street": "12 rue des Acacias",
      "bennes": 3, "triageProvider": true,
-     "sites": [{"@id": "/api/sites/1", "id": 1, "name": "Chatellerault", "postalCode": "86100", "city": "Châtellerault", "color": "#056CF2"}],
-     "categories": [{"@id": "/api/categories/12", "id": 12, "code": "NEGOCIANT", "name": "Négociant"}],
-     "contacts": [{"@id": "/api/supplier_contacts/1", "id": 1, "firstName": "Marie", "lastName": "Martin"}]}
+     "sites": [
+       {"@type": "Site", "@id": "/api/sites/87", "id": 87, "name": "Chatellerault", "postalCode": "86100", "city": "Châtellerault", "color": "#056CF2"},
+       {"@type": "Site", "@id": "/api/sites/88", "id": 88, "name": "Saint-Jean", "postalCode": "17400", "city": "Fontenet", "color": "#F3CB00"}
+     ],
+     "contacts": [{"@id": "/api/supplier_contacts/39", "@type": "SupplierContact", "id": 39, "firstName": "Marie", "lastName": "Martin"}],
+     "categories": [{"@type": "Category", "@id": "/api/categories/2279", "id": 2279, "name": "test_cli_cat_fr_negociant", "code": "NEGOCIANT"}]}
   ],
-  "siren": "123456789", "accountNumber": "F0001",
-  "tvaMode": {"@id": "/api/tva_modes/1", "id": 1, "label": "France (ventes)"},
-  "nTva": "FR00123456789",
-  "paymentDelay": {"@id": "/api/payment_delays/2", "id": 2, "label": "30 jours"},
-  "paymentType": {"@id": "/api/payment_types/2", "id": 2, "code": "LCR", "label": "LCR"},
-  "bank": null,
   "ribs": [
-    {"@id": "/api/supplier_ribs/1", "id": 1, "label": "Compte principal",
-     "bic": "SOGEFRPP", "iban": "FR7630003035400005000000123"}
+    {"@id": "/api/supplier_ribs/27", "@type": "SupplierRib", "id": 27, "label": "Compte principal", "bic": "BNPAFRPPXXX", "iban": "FR1420041010050500013M02606"}
   ],
-  "isArchived": false, "archivedAt": null,
-  "updatedAt": "2026-02-17T09:30:00+00:00"
+  "isArchived": false
 }
 ```
 
-> Pour un user **sans** `accounting.view` (ex. Commerciale) : les clés `siren`, `accountNumber`, `tvaMode`, `nTva`, `paymentDelay`, `paymentType`, `bank`, `ribs` **sont absentes** (pas `null` — réellement non sérialisées car le Provider retire le groupe). Le gating par **omission de clé** est confirmé confortable côté front. Le blame `updatedBy` est sérialisé en **IRI** (`"/api/me"` quand c'est l'user courant) — en tenir compte côté front.
+> Pour un user **sans** `accounting.view` (ex. Commerciale) : les clés `siren`, `accountNumber`, `tvaMode`, `nTva`, `paymentDelay`, `paymentType`, `bank`, `ribs` **sont absentes** (pas `null` — réellement non sérialisées : le `SupplierReadGroupContextBuilder` n'ajoute pas le groupe). Gating par **omission de clé** confirmé sur le JSON réel (`SupplierSerializationContractTest::testRibsAbsentForCommercialeWithoutAccountingView` + `testAccountingScalarsGatedByOmission`). `bennes`/`triageProvider`/`addressType`/`addresses[].contacts` restent visibles (onglet Adresse non gaté). NB : ici `bank` est absent (paymentType=LCR sans banque) ; avec un VIREMENT, `bank` est embarqué `{id, code, label}` (fix ERP-92).
 
 ### 4.0.ter Pièges de sérialisation CONSTATÉS sur le M1 réel → parade M2 (OBLIGATOIRE)
 
@@ -1046,7 +1073,7 @@ Le M1 a subi un aller-retour (ERP-68) faute de fixtures alignées. Pour le M2, p
 
 - [x] 3 maillons de sérialisation documentés pour chaque champ liste + détail (§ 4.0)
 - [x] Décision embed vs GetCollection explicite et câblée (embed détail + sous-ressources write — § 3.3 / § 3.4 / § 4.5), **pas de POST-only**
-- [ ] **Réponses JSON RÉELLES** collées (§ 4.0.bis) — *en attente de `make start` + curl (DoD avant tickets front)*
+- [x] **Réponses JSON RÉELLES** collées (§ 4.0.bis) — capturées via PHPUnit (ERP-92, 2026-06-05) ; fix réfs compta IRI→{id,label} inclus
 - [x] Matrice RBAC rôle × onglet + mode strict PATCH (§ 2.9 / RG-2.16)
 - [x] Pagination (n°13), COMMENT ON COLUMN (n°12), Timestampable/Blamable, Audit, routes à plat : rappelés
 - [x] Réutilisations M1 identifiées (référentiels compta partagés, taxonomie code/type, `usePaginatedList`, blocs, archive, normalisation)