feat(transport) : créer le module Transport (ERP-150)

Module Transport (ID transport, non requis) destiné à héberger les référentiels externes synchronisés par commandes console (codes IDTF ERP-149, transporteurs QUALIMAT ERP-39).

- TransportModule.php avec permissions() vide à ce stade
- activation dans config/modules.php
- layer Nuxt front minimal (pas d'écran ni d'item sidebar)

config/modules.php

@@ -5,12 +5,12 @@ use App\Module\Catalog\CatalogModule;
 use App\Module\Commercial\CommercialModule;
 use App\Module\Core\CoreModule;
 use App\Module\Sites\SitesModule;
-use App\Module\Technique\TechniqueModule;
+use App\Module\Transport\TransportModule;
 
 return [
     CoreModule::class,
     CommercialModule::class,
     SitesModule::class,
     CatalogModule::class,
-    TechniqueModule::class,
+    TransportModule::class,
 ];

config/version.yaml

@@ -1,2 +1,2 @@
 parameters:
-    app.version: '0.1.112'
+    app.version: '0.1.110'

docs/specs/M3-prestataires/spec-front.md

@@ -1,339 +0,0 @@
----
-# === IDENTITÉ ===
-module: M3
-nom: "Répertoire prestataires"
-ecran: repertoire-prestataires
-owner_spec: Matthieu
-backup_spec: Tristan
-version: V0.2
-date_redaction: 2026-06-11
-# Historique :
-#   V0.2 (2026-06-11) — Restitution Markdown du docx « M3-reportoire-prestataires.docx » (04/06/2026).
-#     Alignement refonte-contact (comme M1/M2) : le contact principal inline du formulaire principal
-#     du PDF V0.1 (Nom contact / Prénom contact / Téléphone + / Email) est RETIRÉ — saisie via
-#     l'onglet Contacts uniquement (décision Matthieu, 11/06 : « oublie le contact inline, comme client »).
-#     RG-3.01 / RG-3.02 (contact inline + max 2 tél sur le formulaire principal) supprimées en conséquence.
-#   V0.1 (PDF) — version fonctionnelle plus ancienne, NON retenue (contact inline sur le formulaire principal).
-
-# === LIENS ===
-maquette_figma: "https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-42090&p=f&m=dev"
-regles_metier: [RG-3.03, RG-3.04, RG-3.05, RG-3.06, RG-3.07, RG-3.08, RG-3.09, RG-3.10, RG-3.11, RG-3.12, RG-3.13, RG-3.14, RG-3.15, RG-3.16, RG-3.17]
-roles: [Admin, Bureau, Compta, Commerciale, Usine]
-lien_spec_back: ./spec-back.md
-
-# === VALIDATION CLIENT ===
-client_validation_1:
-  statut: validee
-  date: 2026-05-22
-  version: V0
-  valide_par: "Matthieu (CP MALIO)"
-client_validation_2:
-  statut: validee
-  date: 2026-06-01
-  version: V0.1
-  valide_par: "Matthieu (CP MALIO)"
-client_validation_3:
-  statut: a_valider
-  date: 2026-06-04
-  version: V0.2
-  resume: "Module 3 — Répertoire prestataires. Pôle Technique (nouvelle section sidebar). Datatable + 3 écrans (Ajouter / Consulter / Modifier). Création par onglets : Contact / Adresse / Comptabilité (Rapports, Échanges = placeholders 'À venir'). PAS d'onglet Information. Sélecteur de site aussi sur le formulaire principal."
-  trace_archivee: "uploads/M3-reportoire-prestataires.docx (V0.2) + M3-reportoire-prestataires-V01.pdf (V0.1, obsolète)"
-
-# === LIEN LESSTIME ===
-lesstime_taskgroup_id: 29   # M3 — Répertoire prestataires (projet STARSEED #6)
-lesstime_project_id: 6
-statut_global: en_dev
----
-
-# Module 3 — Répertoire prestataires (V0.2 front)
-
-> **Origine** : spec fonctionnelle `M3-reportoire-prestataires.docx` (V0.2 du 04/06/2026 ; historique V0 22/05 → V0.1 01/06). Restitution Markdown pour intégration au workflow MALIO. Le contenu fonctionnel original n'est pas modifié, **sauf** l'alignement refonte-contact (cf. ci-dessous). Toute décision technique (back) vit dans [`spec-back.md`](./spec-back.md). Le M3 réutilise massivement le pattern et les composants posés au [M1 clients](../M1-clients/spec-front.md) et au [M2 fournisseurs](../M2-suppliers/spec-front.md).
-
-> **⚠️ Alignement refonte-contact (décision Matthieu, 11/06/2026)** : le PDF V0.1 portait un **contact principal inline** sur le formulaire principal (Nom du contact / Prénom du contact / Téléphone + bouton + / Email) avec RG-3.01 (Nom OU Prénom) et RG-3.02 (max 2 téléphones). Ce contact inline est **retiré**, exactement comme l'a fait M1/M2 (refonte-contact). Les coordonnées du contact se saisissent **uniquement dans l'onglet Contacts**. **RG-3.01 et RG-3.02 sont donc supprimées du formulaire principal** ; la garantie « au moins un contact nommé » est portée par RG-3.04 + RG-3.12, et le « maximum 2 téléphones » s'applique aux blocs Contact.
-
-> **⚠️ Décision d'architecture (à confirmer) — pôle « Technique »** : le docx place le répertoire prestataires dans un **Module « Technique »**. Confirmé par Matthieu (11/06) : c'est bien un **nouveau pôle Technique**, distinct du Commercial. Côté front cela se traduit par une **nouvelle section sidebar « Technique »** (route `/providers`). Côté back, voir [`spec-back.md § 2.1`](./spec-back.md) (nouveau module `Technique`, entités jumelles du fournisseur, référentiels comptables consommés en relation ORM partagée).
-
-## But
-
-Lister tous les prestataires de l'organisation et accéder rapidement à leurs fiches : consultation, création, modification, archivage. C'est la **porte d'entrée du pôle Technique**.
-
-## Accès
-
-- **Depuis** : menu principal → section **Technique** → entrée « Répertoire prestataires » (route `/providers`).
-- **Rôles autorisés** (tableau « Rôles & permissions » du docx) :
-
-| Rôle | Consultation | Création / Modification | Archivage |
-|---|---|---|---|
-| **Admin** | ✅ Tout | ✅ Tout | ✅ |
-| **Bureau** | ✅ Tout | ✅ Tout sauf onglet Comptabilité | ❌ |
-| **Compta** | ✅ Tout | ✅ Onglet Comptabilité uniquement | ❌ |
-| **Commerciale** | ✅ Tout sauf Comptabilité | ✅ Tout sauf Comptabilité | ❌ |
-| **Usine** | ✅ Son site uniquement | — | ❌ |
-
-> **Notes** :
-> - RBAC transposée sur `technique.providers.*` (cf. [`spec-back.md § 2.9 / § 5`](./spec-back.md)). Compta édite uniquement l'onglet Comptabilité d'un prestataire existant ; Compta ne peut pas **créer** un prestataire. **L'archivage est réservé à Admin**.
-> - **Cloisonnement par site (décision 11/06 — DANS LE PÉRIMÈTRE M3)** : « Tout » vs « son site uniquement » n'est **pas porté par le rôle** mais par l'**utilisateur**. Chaque user a un site courant ; **par défaut il ne voit que les prestataires rattachés à son site**. Les profils qui doivent voir tous les sites (Admin, et par défaut Bureau / Compta / Commerciale) ont la permission `sites.bypass_scope` (Admin l'a automatiquement). **Usine** n'a pas le bypass → cloisonnée à son site. Filtrage **automatique côté back** (cf. [`spec-back.md § 2.13`](./spec-back.md)) — aucun filtre à coder côté front.
-
-## Navigation
-
-Page d'entrée du pôle **Technique** (route `/providers`). Titre : « **Répertoire prestataires** ».
-
-- Affichage principal : un **datatable** listant tous les prestataires **actifs** (les archivés sont masqués par défaut — toggle/filtre dédié).
-- **Clic sur une ligne** → écran **Consultation prestataire** (page dédiée).
-- **Bouton « + Ajouter »** (haut droite) → écran **Ajouter un prestataire**.
-- **Bouton « Filtrer »** (haut droite) → panneau de filtres (cf. ci-dessous).
-- **Bouton « Exporter »** (haut droite) → télécharge un **XLSX** des prestataires **affichés** (cf. filtres actifs). Format dans [`spec-back.md § 4.6`](./spec-back.md).
-
-### Panneau de filtres (bouton « Filtrer »)
-
-Réutilise le pattern M1/M2. Filtres branchés sur les query params de `GET /api/providers` (cf. [`spec-back.md § 4.1`](./spec-back.md)) :
-
-| Filtre | Composant | Query param back |
-|---|---|---|
-| **Recherche** (nom entreprise / contact / email) | `<MalioInputText>` | `?search=` |
-| **Catégorie** | `<MalioSelectCheckbox>` (multi, type PRESTATAIRE) | `?categoryCode=` |
-| **Site** | `<MalioSelectCheckbox>` (86 / 17 / 82) | `?siteId=` |
-| **Inclure les archivés** | `<MalioCheckbox>` | `?includeArchived=true` |
-
-- À l'application des filtres → `setFilters(...)` de `usePaginatedList` (retombe en **page 1**), qui relance `GET /api/providers`.
-- **État 100 % local** (jamais dans l'URL — règle ABSOLUE n°6).
-
-## Datatable du Répertoire
-
-Composant : `<MalioDataTable>` branché sur `usePaginatedList<Provider>({ url: '/providers' })` (règle frontend obligatoire — pagination Hydra, état 100 % local). Colonnes (alignées M2) :
-
-| Colonne | Source | Tri |
-|---|---|---|
-| **Nom** | `provider.companyName` | ASC par défaut |
-| **Catégories** | `provider.categories[].name` (embarquées en liste — cohérence M1/M2 ; libellé = `name`, pas `label`) | Non |
-| **Site** | `provider.sites[].name` (sites du prestataire — cf. note ci-dessous) | Non |
-| **Dernière activité** | `provider.updatedAt` (format `JJ-MM-AAAA`) — exposé dans `provider:read` | Oui |
-
-> **Source de la colonne « Site »** : le M3 porte un sélecteur de site **sur le formulaire principal** (RG-3.03) — donc `provider.sites[]` est une relation **directe** du prestataire (≠ M2 où les sites venaient de l'agrégat des adresses). La colonne liste affiche ces sites directs. Voir [`spec-back.md § 2.12`](./spec-back.md).
-> **Clic sur une ligne** → écran Consultation. **Pagination** : standard Starseed 10 / 25 / 50 (défaut 10). Tri serveur `companyName ASC` par défaut.
-
-## Écran « Ajouter un prestataire »
-
-Création par **onglets successifs avec validation incrémentale** : pour passer à l'onglet suivant, il faut avoir validé l'onglet en cours. **Une fois un onglet validé, on passe automatiquement au suivant** ; les champs validés passent en lecture seule + bouton « Valider » désactivé (disabled). Cf. [`spec-back.md § 2.10`](./spec-back.md) (PATCH partiels par groupe de sérialisation).
-
-**Accès** : bouton « + Ajouter » du Répertoire. **Rôles** : Admin, Bureau.
-
-**Barre d'onglets en création (3 onglets)** : `Contact` · `Adresse` · `Comptabilité`. Les onglets `Rapports` et `Échanges` **n'apparaissent PAS dans le flux de création** — ils ne sont présents qu'en Consultation / Modification (placeholders « À venir »).
-
-> **Différence majeure avec M2 : PAS d'onglet « Information ».** Le M3 n'a aucun champ Description / Concurrent / Date création / Salariés / CA / Dirigeant / Résultat / Volume. Le formulaire principal est minimal (3 champs).
-
-> **Règle « placeholder par défaut » (convention MALIO)** : tout onglet ou écran que la spec ne détaille pas explicitement (ici **Rapports** et **Échanges**) est livré en **placeholder « À venir »** (frame vide, navigable, pas de validation ni d'API), à l'identique des autres modules (M1/M2). Aucun champ inventé hors spec.
-
-### Formulaire principal (pré-onglets)
-
-1er bloc à remplir. Sans validation, les onglets ne sont pas accessibles. Une fois validé → POST `/api/providers`, puis bascule sur l'onglet Contact ; les champs passent en readonly.
-
-| Champ | Type composant | Obligatoire | Règle |
-|---|---|---|---|
-| **Nom du prestataire (Entreprise)** | `<MalioInputText>` | Oui | RG-3.11 (UPPERCASE serveur) ; RG-3.10 (unicité) |
-| **Catégorie** | `<MalioSelectCheckbox>` (multi) | Oui | `Category` de **type PRESTATAIRE** via `GET /api/categories?typeCode=PRESTATAIRE` (RG-3.09). Libellé affiché = `category.name`. |
-| **Sélecteur de site** | `<MalioSelectCheckbox>` (86 / 17 / 82) | Oui | RG-3.03 — ≥ 1 site. Les 3 cases = les 3 `Site` fixes ; libellés « 86/17/82 » = **préfixe du `postalCode`** (86100 / 17400 / 82400), pas un `Site.code` (qui n'existe pas). La sélection stocke des **IDs de Site** (M2M `provider_site`). |
-
-**Action** : « Valider » (`<MalioButton>`) → POST `/api/providers` ([`spec-back.md § 4.3`](./spec-back.md)). Succès → onglet « Contact ».
-
-### Onglet « Contact »
-
-Saisir un ou plusieurs contacts. Au moins un bloc Contact valide est requis (RG-3.12). **(Refonte-contact : pas de pré-remplissage depuis le formulaire principal ; les coordonnées du contact se saisissent directement ici.)**
-
-**Bloc Contact** :
-
-| Champ | Type | Obligatoire | Règle |
-|---|---|---|---|
-| **Nom** | `<MalioInputText>` | Conditionnel | RG-3.04 + RG-3.11 (Capitalize) |
-| **Prénom** | `<MalioInputText>` | Conditionnel | RG-3.04 + RG-3.11 (Capitalize) |
-| **Fonction** | `<MalioInputText>` | Non | — |
-| **Téléphone** (x1, +1 possible, **max 2**) | `<MalioInputText>` | Non | RG-3.11 (format) ; max 2 téléphones par contact |
-| **Email** | `<MalioInputText>` type email | Non | RG-3.11 (lowercase) |
-
-**RG-3.04 / RG-3.12** : un bloc Contact est valide dès qu'au moins 1 champ est rempli ; au moins 1 bloc Contact valide pour finaliser l'onglet — l'onglet Contact ne peut pas être validé vide.
-
-**Actions** :
-- « + Nouveau contact » : ajoute un bloc. **Désactivé tant que le bloc précédent n'a pas au moins 1 champ rempli** (RG-3.04).
-- « Supprimer » (icône) : modal de confirmation, puis suppression du bloc.
-- « Valider » → PATCH `/api/providers/{id}/contacts`.
-
-### Onglet « Adresse »
-
-Saisir une ou plusieurs adresses, rattachées à un ou plusieurs sites (86 / 17 / 82) et à des contacts.
-
-**Bloc Adresse** :
-
-| Champ | Type | Obligatoire | Règle |
-|---|---|---|---|
-| **Sélecteur de site** | `<MalioSelectCheckbox>` (86 / 17 / 82) | Oui | RG-3.05 — ≥ 1 site. Stocke des IDs de Site (M2M `provider_address_site`). |
-| **Adresse** | `<MalioInputText>` (saisie assistée) | Oui | RG-3.06 — autocomplete BAN |
-| **Adresse complémentaire** | `<MalioInputText>` | Non | — |
-| **Code postal** | `<MalioInputText>` (saisie assistée) | Oui | RG-3.06 — déclenche autocomplete ville (BAN) |
-| **Ville** | `<MalioSelect>` (saisie assistée) | Oui | RG-3.06 — alimentée par api-adresse.data.gouv.fr suivant le CP ; si plusieurs villes, choix dans le select |
-| **Pays** | `<MalioSelect>` (préremplie « France ») | Oui | — |
-| **Catégories** | `<MalioSelectCheckbox>` (multi) | Oui | Catégories de type PRESTATAIRE (RG-3.09) |
-| **Contact** | `<MalioSelectCheckbox>` (multi) | Non | Liste = blocs Contact saisis dans l'onglet Contact |
-
-> **Différence avec M2** : l'adresse prestataire n'a **PAS** de Type d'adresse (Prospect/Départ/Rendu), **PAS** de Bennes, **PAS** de Prestation de triage. C'est une adresse « simple » (site + adresse postale + catégories + contacts).
-
-**Actions** :
-- « + Nouvelle Adresse » : ajoute un bloc identique au premier.
-- « Supprimer » (icône) : modal de confirmation puis suppression.
-- « Valider » → PATCH `/api/providers/{id}/addresses`.
-
-### Onglet « Comptabilité »
-
-⚠ **Accessible aux rôles avec `technique.providers.accounting.view`** (Admin + Compta). Bureau et Commerciale ne voient pas l'onglet. **Compta peut éditer** cet onglet (`accounting.manage`). Compta ne peut pas créer un prestataire (pas de `manage` global).
-
-**Champs comptables** :
-
-| Champ | Type | Obligatoire | Règle |
-|---|---|---|---|
-| **SIREN** | `<MalioInputText>` (masque 9 chiffres) | Oui | 9 chiffres. **Pas d'unicité** (cf. [`spec-back.md § 2.6`](./spec-back.md)) |
-| **Numéro de compte** | `<MalioInputText>` | Oui | — |
-| **Mode de TVA** | `<MalioSelect>` | Oui | Liste depuis `/api/tva_modes` (référentiel partagé M1) |
-| **N° de TVA** | `<MalioInputText>` | Oui | — |
-| **Délai de règlement** | `<MalioSelect>` | Oui | Liste depuis `/api/payment_delays` |
-| **Type de règlement** | `<MalioSelect>` | Oui | Liste depuis `/api/payment_types` |
-| **Banque** | `<MalioSelect>` | Conditionnel | RG-3.07 — visible et obligatoire **si** Type de règlement = `VIREMENT`. Liste depuis `/api/banks` (SG / CIC / CA). |
-
-**Bloc RIB** (0..n, présence obligatoire conditionnée par RG-3.08) :
-
-| Champ | Type | Obligatoire | Règle |
-|---|---|---|---|
-| **Libellé** | `<MalioInputText>` | Oui (si LCR) | RG-3.08 |
-| **BIC** | `<MalioInputText>` | Oui (si LCR) | RG-3.08 |
-| **IBAN** | `<MalioInputText>` | Oui (si LCR) | RG-3.08 |
-
-**Actions** :
-- « + RIB » : ajoute un bloc.
-- « Supprimer » (icône) : modal de confirmation.
-- « Valider » → PATCH `/api/providers/{id}` (groupe `provider:write:accounting`) + sous-ressource RIBs.
-
-## Écran « Consultation prestataire »
-
-Tous les champs en **lecture seule**. La page s'ouvre par défaut sur l'onglet **Contacts**. Layout identique à l'écran Ajouter mais sans bouton « Valider », sans `+` pour ajouter des blocs.
-
-- **Flèche retour** (gauche) → revient au Répertoire.
-- **Bouton « Modifier »** (droite, visible si `technique.providers.manage`) → écran Modification.
-- **Bouton « Archiver »** (droite, visible **uniquement Admin** via `technique.providers.archive`) → modal de confirmation, puis PATCH `/api/providers/{id}` `{ "isArchived": true }`.
-
-> Un prestataire archivé peut être restauré (`isArchived: false`) — bouton « Restaurer » remplace « Archiver » dans la consultation d'un archivé.
-
-### Onglets affichés en consultation
-
-`Contacts` · `Adresse` · `Rapports` · `Échanges` · `Comptabilité`. Navigation **libre** entre onglets (pas de séquence forcée). `Rapports` et `Échanges` = placeholders « À venir ». `Comptabilité` selon permission.
-
-- **Onglet Contacts** : un bloc par contact, 5 champs en lecture seule (Nom / Prénom / Fonction / Téléphone / Email).
-- **Onglet Adresse** : un bloc par adresse, en lecture seule (Sélecteur de site / Adresse / Adresse complémentaire / Code postal / Ville / Pays / Catégorie / Contact).
-- **Onglet Comptabilité** : bloc principal (champs comptables) + un bloc par RIB. Le champ **Banque** n'apparaît que si Type de règlement = Virement (RG-3.07).
-
-## Écran « Modification prestataire »
-
-Comportement identique à l'écran Ajouter (mêmes formulaires, mêmes RG-3.03 → RG-3.08) sauf :
-- **Pas de formulaire principal** réaffiché (champs principaux édités via l'onglet correspondant / pré-remplis).
-- Les champs sont **pré-remplis** avec les valeurs actuelles du prestataire.
-- **Validation par onglet** : on peut modifier UN onglet sans toucher aux autres (PATCH partiel).
-- Les onglets pour lesquels l'utilisateur n'a **pas** la permission `manage` (ou `accounting.manage`) restent en **lecture seule** (pas de bouton Valider, pas d'icône suppression).
-- **Accès** : Admin, Bureau (Compta pour l'onglet Comptabilité uniquement).
-
-## Composants UI à utiliser (`@malio/layer-ui`)
-
-- **Datatable** : `<MalioDataTable>` (+ `usePaginatedList`)
-- **Input texte** : `<MalioInputText>`
-- **Select simple** : `<MalioSelect>` (Pays, Ville, référentiels comptables)
-- **Select multi (cases à cocher)** : `<MalioSelectCheckbox>` (Catégorie, Sites, Contacts rattachés)
-- **Bouton** : `<MalioButton>`, `<MalioButtonIcon>`
-- **Toasts** : standards via `useApi()`
-- **Validation par champ** : `useFormErrors` (mapping 422 inline — règle frontend obligatoire)
-
-**Exceptions autorisées** (commenter `// TODO migrer quand Malio couvre`) :
-- Modal de confirmation : `<MalioModal>` ou wrapper partagé dans `frontend/shared/` (réutiliser celui du M1/M2).
-
-## Composables & appels API
-
-- `usePaginatedList<Provider>({ url: '/providers' })` — liste paginée (obligatoire). La liste consomme `categories[]` (libellé = `name`) et `sites[]` (libellé = `name`, pas de `code`) **embarqués** + `updatedAt` (cf. [`spec-back.md § 2.12 / § 4.0`](./spec-back.md)).
-- `useProvider(id)` — charge le détail via `GET /api/providers/{id}`, qui **embarque** `contacts`, `addresses` (avec `sites` / `categories` / `contacts` imbriqués) et, si permission, `ribs` + scalaires compta. Écrans Consultation et Modification peuplés depuis cette seule réponse (RETEX M1 §2 : embed borné, pas de N+1). **DoD avant intégration** : vérifier que le JSON réel contient ces blocs (cf. [`spec-back.md § 4.0.bis`](./spec-back.md)).
-- `useProviderForm()` — workflow par onglet (POST principal + PATCH partiels par groupe), miroir de `useSupplierForm()`.
-- `useAddressAutocomplete()` — **réutilisé du M1/M2** (BAN), pas de réécriture.
-- `usePermissions()` — masque l'onglet Comptabilité et le bouton Archiver.
-- Tous les appels passent par `useApi()` (jamais `$fetch` direct — règle ABSOLUE n°4).
-- Filter `formatPhoneFR()` — **réutilisé** pour l'affichage `XX XX XX XX XX`.
-
-## Règles de formatage et normalisation
-
-Le serveur normalise systématiquement (RG-3.11 — cf. [`spec-back.md`](./spec-back.md)) :
-
-| Champ | Normalisation serveur | Affichage front |
-|---|---|---|
-| Nom prestataire (`companyName`) | UPPERCASE intégral | UPPERCASE |
-| Nom + Prénom contact | Capitalize | identique |
-| Téléphones (blocs `ProviderContact`) | Chiffres uniquement en BDD | Formaté `XX XX XX XX XX` (filter Vue) |
-| Email | lowercase intégral | identique |
-
-> Le front **ne normalise pas** : il envoie la valeur saisie, le serveur normalise et renvoie la valeur normalisée que l'UI affiche.
-
-## API adresse postale
-
-Code postal + Ville + Adresse branchés sur **api-adresse.data.gouv.fr** (BAN) via le composable `useAddressAutocomplete()` **déjà créé au M1/M2** (réutilisé tel quel) :
-- À la saisie du CP (5 chiffres) : `GET https://api-adresse.data.gouv.fr/search/?q={cp}&type=municipality` → alimente le select Ville (RG-3.06 : si plusieurs villes, choix dans le select).
-- À la saisie d'adresse : `?q={addr}&postcode={cp}&type=housenumber` → suggestions.
-- Cas dégradé (timeout / offline) : Ville en `<MalioInputText>` libre + toast d'avertissement.
-
-## Différences notables avec le M2 (fournisseurs)
-
-| Zone | M2 fournisseurs | M3 prestataires |
-|---|---|---|
-| Onglet Information | 8 champs (Description … Volume) | **Absent** (aucun champ Information) |
-| Sélecteur de site sur formulaire principal | Non (sites uniquement via adresses) | **Oui** (RG-3.03 — relation directe `provider.sites`) |
-| Type d'adresse | Radio Prospect / Départ / Rendu (RG-2.09) | **Absent** |
-| Bennes / Prestation de triage (adresse) | Présents | **Absents** |
-| Onglet Transport | Placeholder | **Absent** |
-| Onglet Statistiques | Placeholder | **Absent** |
-| Onglets « À venir » | Transport / Stats / Rapports / Échanges | **Rapports / Échanges** uniquement |
-| Catégories | type `FOURNISSEUR` | **nouveau type `PRESTATAIRE`** |
-| Pôle / module | Commercial | **Technique** (nouvelle section sidebar + module back) |
-| Cloisonnement par site | aucun | **Visibilité par site, pilotée par l'utilisateur** (bypass via `sites.bypass_scope`) — § 2.13 |
-
-## Points résolus côté back
-
-| # | Zone d'ombre | Résolution (cf. `spec-back.md`) |
-|---|---|---|
-| 1 | Catégorie multi-select | M2M `provider_category`, `Category` de type **PRESTATAIRE** (RG-3.09) |
-| 2 | Site sur le formulaire principal | M2M `provider_site` (≥ 1 — RG-3.03), distinct de `provider_address_site` (RG-3.05) |
-| 3 | Onglet Comptabilité : qui édite ? | Admin + Compta (`accounting.manage`) ; Bureau/Commerciale ne le voient pas |
-| 4 | Workflow par onglet | Sauvegarde incrémentale (POST principal + PATCH partiels) — pas d'état « draft » |
-| 5 | Onglets « À venir » | Placeholder minimal « À venir » (Rapports / Échanges) |
-| 6 | Archive vs delete | Flag `is_archived` séparé de `deleted_at` ; archivage Admin seul ; soft delete = HP |
-| 7 | Unicité métier | Nom de prestataire uniquement (à valider — § 2.6). SIREN/email non uniques |
-| 8 | Référentiels comptables | Réutilisés M1/M2 (zéro duplication) ; relation ORM partagée |
-| 9 | API code postal | BAN via `useAddressAutocomplete()` du M1/M2 (RG-3.06) |
-| 10 | Format export | XLSX uniquement (CSV = HP) |
-| 11 | Cloisonnement par site (Usine « son site ») | Filtre back automatique par `currentSite` + bypass `sites.bypass_scope` (§ 2.13 / RG-3.17) |
-
----
-
-## 📦 Tickets Lesstime
-
-**TaskGroup Lesstime** : **#29 — M3 — Répertoire prestataires** (projet `ERP / Starseed`, projectId=6) — créé le 11/06/2026, 16 tickets `ERP-131` → `ERP-146`, statut « Prêt à dev », assignés à **Tristan**.
-
-| # | Ticket | Réf | Tag |
-|---|---|---|---|
-| 1.1 | Créer module Technique + taxonomie PRESTATAIRE | ERP-131 | Backend |
-| 1.2 | Migrer le schéma BDD M3 (provider + sous-collections) | ERP-132 | Backend |
-| 1.3 | Créer entités + repositories Provider* | ERP-133 | Backend |
-| 1.4 | ProviderProvider + ProviderProcessor + cloisonnement site | ERP-134 | Backend |
-| 1.5 | Sous-ressources Contacts / Adresses / RIBs | ERP-135 | Backend |
-| 1.6 | Valider les RG métier server-side (RG-3.03→3.09) | ERP-136 | Backend |
-| 1.7 | Export XLSX des prestataires | ERP-137 | Backend |
-| 1.8 | RBAC technique.providers.* (3 sources) | ERP-138 | Backend |
-| 1.9 | PHPUnit RG-3.x + capture contrat JSON | ERP-139 | Backend |
-| 1.10 | Page Répertoire (/providers) | ERP-140 | Frontend |
-| 1.11 | Page Ajouter (/providers/new) + formulaire principal | ERP-141 | Frontend |
-| 1.12 | Onglet Contact | ERP-142 | Frontend |
-| 1.13 | Onglet Adresse (autocomplete BAN) | ERP-143 | Frontend |
-| 1.14 | Onglet Comptabilité + RIB | ERP-144 | Frontend |
-| 1.15 | Pages Consultation + Modification | ERP-145 | Frontend |
-| 1.16 | i18n + sidebar Technique + libellés audit | ERP-146 | Frontend |
-
-> Détail back complet → voir [`spec-back.md § Tickets Lesstime`](./spec-back.md#-tickets-lesstime-à-découper).

docs/specs/_RETEX-M1-pour-M2.md

@@ -1,80 +0,0 @@
-# RETEX M1 (Clients) → à appliquer pour M2 (Fournisseurs)
-
-> But : éviter de reproduire en M2 les erreurs de **contrat de sérialisation** qui ont bloqué M1.
-> ~80 % des frictions M1 venaient du contrat API (sérialisation / groupes / sous-ressources), **pas** du métier.
-> À lire AVANT de rédiger `spec-back.md` et `spec-front.md` du M2, et à garder ouvert pendant la rédaction.
-
----
-
-## 0. TL;DR (les 3 erreurs à ne jamais refaire)
-
-1. **Affirmer qu'un champ est « embarqué » sans vérifier les 3 maillons de sérialisation.** En M1 : `Category.code` annoncé dans `client:read`, détail annoncé embarquant contacts/adresses/ribs → **faux dans le code**. Résultat : colonnes liste vides, onglets détail impossibles à peupler.
-2. **Livrer des sous-ressources en POST-only** (pas de `GetCollection`, pas d'embed) → le front ne peut pas lister les enfants de l'agrégat.
-3. **Écrire la spec/les tickets sur une intention, pas sur le contrat réel.** Le docblock `Client` décrivait un embed jamais implémenté.
-
----
-
-## 1. Contrat de sérialisation : les 3 maillons obligatoires
-
-Pour **chaque champ affiché** (liste OU détail), la spec back doit prouver les trois maillons. Si un seul manque → le champ sort en quasi-IRI (`@id`/`@type` seulement) ou pas du tout.
-
-| Maillon | Question | Exemple M1 raté |
-|---|---|---|
-| (a) Groupe sur la **propriété** | `#[Groups([...])]` contient-il un read-group ? | `Supplier::$addresses` sans groupe → jamais sérialisé |
-| (b) Groupe dans le **`normalizationContext` de l'opération** | l'opération (`GetCollection`/`Get`) liste-t-elle ce groupe ? | `GetCollection` en `['client:read','default:read']` |
-| (c) Read-group de l'**entité imbriquée** dans le contexte parent | pour embarquer les champs d'une relation (catégorie, site…), le contexte parent inclut-il `category:read` / `site:read` ? | `Category.code` ∈ `category:read`, absent du contexte client → pas de `code` |
-
-**Règle de rédaction** : dans `spec-back.md`, faire un tableau « champ → groupe propriété → groupe(s) à ajouter au contexte de chaque opération » pour la liste ET le détail. Inclure explicitement les **relations imbriquées** (ex. catégories d'une adresse, sites d'une adresse).
-
-## 2. Collections enfant d'un agrégat : décider embed vs GetCollection, et câbler en ENTIER
-
-Décision à acter dès la spec back pour chaque sous-collection (contacts, adresses, RIB, lignes…) :
-
-- **Embed dans le détail (recommandé pour un agrégat DDD)** : poser `#[Groups(['<root>:item:read'])]` sur la propriété + ajouter au `normalizationContext` du `Get` racine les read-groups des entités enfant **et** de leurs relations imbriquées. 1 requête, cohérent avec un composable `useX(id)`. Réservé aux ensembles **bornés** (ne viole pas la règle n°13 : elle vise les collections exposées, pas un embed borné d'item).
-- **GetCollection sous-ressource** : `/<root>/{id}/children` paginé. À réserver aux collections potentiellement volumineuses. Si choisi, **créer l'opération** (pas seulement POST).
-
-❌ Anti-pattern M1 : sous-ressources avec `POST` + `Get` unitaire seulement → **aucun moyen de lister** (ids non découvrables). Interdit.
-
-## 3. Vérifier le contrat sur l'API RÉELLE avant d'écrire les tickets front
-
-Le blocage M1 (codes/sites/sous-collections) aurait été vu en 5 min. À mettre dans la **definition of done de la spec back** :
-
-> Créer un enregistrement de test, appeler `GET /api/<resource>` (liste) ET `GET /api/<resource>/{id}` (détail), **coller la réponse JSON réelle** dans la spec. Toute donnée affichée par le front doit apparaître dans ce JSON collé.
-
-## 4. La spec décrit le RÉEL, pas l'intention
-
-- Bannir les « devrait être embarqué », « est exposé » non vérifiés. Décrire ce qui existe (ou ce qui sera livré dans le ticket, en le marquant clairement « à livrer »).
-- Si un docblock/commentaire existant contredit le code, le **corriger**, pas le recopier.
-
-## 5. Réutiliser les acquis M1 (ne pas réinventer)
-
-- **Taxonomie ERP-78** : si M2 catégorise les fournisseurs, repartir du modèle **type unique + `code` stable** (slug MAJUSCULE auto-généré, NOT NULL, figé, **lecture seule** `category:read`), filtrage métier via `?categoryCode=`. Réutiliser le contrat partagé `CategoryInterface` (pas d'import inter-module).
-- **Front** : `usePaginatedList` (listes), composants `Malio*`, `useApi()`, `formatPhoneFR`, blocs réutilisables (Contact/Adresse), pattern de blocs dynamiques + modal de confirmation.
-- **Archive** : flag `is_archived` **distinct** de `deleted_at` (soft delete). Restauration → gérer le 409 homonyme.
-- **Normalisation = serveur** (UPPERCASE nom société, Capitalize noms, lowercase email, téléphone en chiffres). Le front envoie la saisie, réaffiche la valeur normalisée renvoyée. À documenter dans la spec.
-- **Gating fin + mode strict PATCH** : PATCH par groupe de sérialisation ; tout champ hors-permission dans le payload = **403 sur l'intégralité** (pas de filtrage silencieux). Spécifier la matrice rôle × onglet.
-
-## 6. Règles ABSOLUES transverses à rappeler dans la spec M2
-
-- **Pagination obligatoire** (règle n°13) sur toute `GetCollection` ; échappatoire `?pagination=false` réservée aux selects de référentiels bornés.
-- **`COMMENT ON COLUMN`** (règle n°12) sur chaque colonne créée/modifiée (sinon `make test` casse). Helper standard pour les colonnes Timestampable/Blamable.
-- **Timestampable + Blamable** sur toute nouvelle entité métier (4 colonnes + trait) ; garde-fou archi.
-- **`#[Auditable]`** sur les entités métier ; **`#[AuditIgnore]`** sur les champs sensibles (équivalents BIC/IBAN/secret).
-- **`declare(strict_types=1);`** partout ; commentaires FR, code EN.
-- **Routes front à plat** (pas de préfixe module), état tableau **jamais** dans l'URL.
-- **3 miroirs RBAC** à toucher ensemble : `config/sidebar.php`, `frontend/tests/e2e/_fixtures/personas.ts`, `SeedE2ECommand.php`.
-- **Communication inter-module** uniquement via `Shared/Domain/Contract/` ou domain events — jamais d'import direct.
-
-## 7. Fixtures & seed dès le départ
-
-M1 a subi un aller-retour (ERP-68) faute de fixtures alignées. Pour M2 : prévoir dès la spec un seed de fournisseurs démo **couvrant tous les cas des règles métier** (relations, catégories codées, archivés, cas comptables) + comptes de rôles démo, pour vérifier le gating et le golden path sans bricolage.
-
-## 8. Mini-checklist de relecture de la spec M2 (avant de la déclarer prête)
-
-- [ ] Chaque champ affiché (liste + détail) a ses 3 maillons de sérialisation documentés (propriété, contexte opération, relations imbriquées).
-- [ ] Chaque sous-collection a une décision **embed vs GetCollection** explicite et **complètement câblée** (pas de POST-only).
-- [ ] Réponses JSON réelles (liste + détail) collées dans la spec back.
-- [ ] Matrice RBAC rôle × écran × onglet + mode strict PATCH spécifiés.
-- [ ] Pagination, COMMENT ON COLUMN, Timestampable/Blamable, Audit, routes à plat : rappelés.
-- [ ] Réutilisations M1 identifiées (taxonomie code, usePaginatedList, blocs, archive, normalisation).
-- [ ] Seed/fixtures démo planifiés.

migrations/Version20260612080000.php

@@ -1,121 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace DoctrineMigrations;
-
-use Doctrine\DBAL\ArrayParameterType;
-use Doctrine\DBAL\Schema\Schema;
-use Doctrine\Migrations\AbstractMigration;
-
-/**
- * M3 (ticket 1.1) — Taxonomie PRESTATAIRE (module Catalog, prerequis du module Technique).
- *
- * Contexte : le M3 (repertoire prestataires) a besoin d'une taxonomie distincte
- * des types CLIENT (M1) et FOURNISSEUR (M2). Decision Matthieu (11/06) : types
- * distincts CLIENT / FOURNISSEUR / PRESTATAIRE, chacun avec sa taxonomie. Le
- * multi-select « Categorie » du prestataire (formulaire principal + adresse)
- * ne reference que des `Category` rattachees au type PRESTATAIRE (RG-3.09).
- *
- * Cette migration :
- *  1. cree le `category_type` PRESTATAIRE (code PRESTATAIRE, label « Prestataire ») ;
- *  2. seede 3 `Category` de demonstration rattachees a ce type via la jonction
- *     ManyToMany `category_category_type` (modele courant depuis Version20260608120000 ;
- *     la colonne ManyToOne `category.category_type_id` n'existe plus).
- *
- * Aucune colonne creee/modifiee -> pas de `COMMENT ON COLUMN` (regle ABSOLUE n°12) :
- * la migration ne fait que des INSERT de donnees de reference.
- *
- * Namespace racine `DoctrineMigrations` (regle ABSOLUE n°11) et NON modulaire :
- * avec plusieurs migrations_paths, Doctrine Migrations 3.x trie par FQCN
- * alphabetique -> une migration `App\Module\...` passerait avant les
- * `DoctrineMigrations\...` sur base vide, donc avant la creation des tables
- * `category` / `category_type` / `category_category_type`. Le namespace racine
- * garantit l'ordre par timestamp.
- *
- * Idempotence : `INSERT ... ON CONFLICT (code) DO NOTHING` pour le type,
- * `INSERT ... SELECT ... WHERE NOT EXISTS` pour chaque categorie et chaque ligne
- * de jonction (aligne sur le pattern ERP-84 / Version20260605120000). En prod la
- * table `category` est vide (aucune fixture metier). En dev/test, le purger
- * Doctrine vide `category` / `category_type` avant les fixtures qui reproduisent
- * le meme etat final (CategoryTypeFixtures / CategoryFixtures etendus a PRESTATAIRE).
- */
-final class Version20260612080000 extends AbstractMigration
-{
-    /**
-     * Categories de demonstration du type PRESTATAIRE : nom => code stable. Le
-     * code est la cle metier (slug MAJUSCULE du nom, miroir du
-     * CategoryCodeGenerator) et reste unique parmi les actifs (uq_category_code,
-     * partage avec les codes CLIENT / FOURNISSEUR — aucune collision ici). Le nom
-     * est unique GLOBALEMENT parmi les actifs (uq_category_name_active) : les
-     * libelles ci-dessous n'entrent en collision avec aucune categorie seedee.
-     */
-    private const array PROVIDER_CATEGORIES = [
-        'Maintenance industrielle' => 'MAINTENANCE_INDUSTRIELLE',
-        'Nettoyage'                => 'NETTOYAGE',
-        'Transport'                => 'TRANSPORT',
-    ];
-
-    public function getDescription(): string
-    {
-        return 'M3 1.1 : cree le CategoryType PRESTATAIRE + seed des categories prestataires (Maintenance industrielle, Nettoyage, Transport).';
-    }
-
-    public function up(Schema $schema): void
-    {
-        // 1. Type PRESTATAIRE (idempotent via l'index unique uq_category_type_code).
-        $this->addSql(<<<'SQL'
-            INSERT INTO category_type (code, label) VALUES ('PRESTATAIRE', 'Prestataire')
-            ON CONFLICT (code) DO NOTHING
-            SQL);
-
-        foreach (self::PROVIDER_CATEGORIES as $name => $code) {
-            // 2a. Categorie sous PRESTATAIRE (si le code est libre parmi les
-            //     actifs). created_at/updated_at NOT NULL -> NOW() ; le blame
-            //     reste null (seed hors contexte HTTP, libelle « Systeme » cote front).
-            $this->addSql(<<<'SQL'
-                INSERT INTO category (name, code, created_at, updated_at)
-                SELECT :name, :code, NOW(), NOW()
-                WHERE NOT EXISTS (
-                    SELECT 1 FROM category c WHERE c.code = :code AND c.deleted_at IS NULL
-                )
-                SQL, ['name' => $name, 'code' => $code]);
-
-            // 2b. Jonction M2M categorie <-> type PRESTATAIRE (modele courant).
-            $this->addSql(<<<'SQL'
-                INSERT INTO category_category_type (category_id, category_type_id)
-                SELECT c.id, ct.id
-                FROM category c
-                CROSS JOIN category_type ct
-                WHERE c.code = :code AND c.deleted_at IS NULL
-                  AND ct.code = 'PRESTATAIRE'
-                  AND NOT EXISTS (
-                      SELECT 1 FROM category_category_type cct
-                      WHERE cct.category_id = c.id AND cct.category_type_id = ct.id
-                  )
-                SQL, ['code' => $code]);
-        }
-    }
-
-    public function down(Schema $schema): void
-    {
-        // Best-effort : on retire d'abord les categories seedees (par code) — la FK
-        // category_category_type est ON DELETE CASCADE cote category, donc les
-        // lignes de jonction partent avec —, puis le type s'il n'est plus reference.
-        $this->addSql(
-            'DELETE FROM category WHERE code IN (:codes) '
-            ."AND id IN (SELECT category_id FROM category_category_type cct "
-            ."JOIN category_type ct ON ct.id = cct.category_type_id WHERE ct.code = 'PRESTATAIRE')",
-            ['codes' => array_values(self::PROVIDER_CATEGORIES)],
-            ['codes' => ArrayParameterType::STRING],
-        );
-
-        $this->addSql(<<<'SQL'
-            DELETE FROM category_type
-            WHERE code = 'PRESTATAIRE'
-              AND NOT EXISTS (
-                  SELECT 1 FROM category_category_type cct WHERE cct.category_type_id = category_type.id
-              )
-            SQL);
-    }
-}

migrations/Version20260612100000.php

@@ -1,451 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace DoctrineMigrations;
-
-use App\Shared\Infrastructure\Database\ColumnCommentsCatalog;
-use Doctrine\DBAL\Schema\Schema;
-use Doctrine\Migrations\AbstractMigration;
-
-/**
- * M3 — Repertoire prestataires (ERP-132) : creation de toute la structure BDD
- * des prestataires sous le nouveau module Technique (jumeau du M2 fournisseur).
- *
- * Tables creees :
- *  - Table principale : provider (formulaire principal + Comptabilite + archive
- *    + soft-delete + Timestampable/Blamable). PAS d onglet Information.
- *  - M2M du formulaire principal : provider_category (RG-3.09),
- *    provider_site (sites du prestataire, RG-3.03 — NOUVEAU vs supplier).
- *  - Sous-collections : provider_contact (1:n), provider_address (1:n),
- *    provider_rib (1:n).
- *  - Jointures de provider_address : provider_address_site (RG-3.05),
- *    provider_address_contact, provider_address_category.
- *
- * Differences vs le M2 `supplier` (cf. spec M3 § 3.1) :
- *  - PAS d onglet Information : aucun champ description / competitors /
- *    founded_at / employees_count / revenue_amount / director_name /
- *    profit_amount / volume_forecast. Le provider est minimal : nom + compta.
- *  - AJOUT de provider_site (M2M) : sites rattaches au prestataire directement
- *    sur le formulaire principal (RG-3.03, >= 1). Sert aussi le cloisonnement
- *    par site (idx_provider_site_site, § 2.13).
- *  - provider_address SIMPLIFIEE : pas de address_type / bennes /
- *    triage_provider (specifiques fournisseur). Champs : country / postal_code
- *    / city / street / street_complement / position + M2M sites/contacts/categories.
- *
- * Referentiels comptables NON recrees : tva_mode / payment_delay / payment_type
- * / bank sont ceux du M1 (FK partagees, zero duplication — spec § 2.3).
- *
- * CategoryType PRESTATAIRE NON re-seede : il est cree par ERP-131
- * (Version20260612080000) avec ses categories de demonstration. Le M2M
- * provider_category / provider_address_category s appuie sur ce type existant.
- *
- * Namespace racine `DoctrineMigrations` (regle ABSOLUE Starseed n°11) et NON
- * `App\Module\Technique\...` : la migration cree un schema avec FK cross-module
- * (user, category, site, et les referentiels comptables M1). Avec plusieurs
- * migrations_paths, Doctrine Migrations 3.x trie par FQCN alphabetique — un
- * namespace modulaire s executerait avant la creation de user/category/site sur
- * base vide -> echec des FK. Le namespace racine garantit l ordre par timestamp.
- *
- * Style DDL aligne sur le M1/M2 (Version20260605130000) : `INT GENERATED BY
- * DEFAULT AS IDENTITY` (et non SERIAL), `TIMESTAMP(0) WITHOUT TIME ZONE` (et non
- * TIMESTAMPTZ, car le TimestampableBlamableTrait mappe `datetime_immutable`).
- * Garantit que `schema:update` restera un no-op quand les entites arriveront
- * (ticket ERP-133).
- *
- * Decision unicite (alignee Q4 M1 / § 2.6 M2) : unicite metier sur le NOM DE
- * SOCIETE uniquement (uq_provider_company_name_active, partiel). Pas d index
- * unique sur siren ni email.
- *
- * COMMENT ON COLUMN inline (regle ABSOLUE n°12) : chaque colonne metier porte sa
- * description ici-meme. Volontairement NON ajoutees a `ColumnCommentsCatalog` /
- * `makefile test-db-setup` a ce stade : tant que les entites Provider* n existent
- * pas (ERP-133), `schema:update --force` du setup de test droppe ces tables non
- * mappees — les referencer dans le catalogue ferait planter
- * `app:apply-column-comments`. Le catalogue + la ligne `dbal:run-sql`
- * (uq_provider_company_name_active) seront ajoutes au ticket entites (ERP-133),
- * exactement comme supplier (ERP-86) apres sa migration (ERP-85). Les 4 colonnes
- * Timestampable/Blamable reutilisent les textes standardises du catalogue
- * (`timestampableBlamableComments()`, simple tableau statique sans dependance DB).
- */
-final class Version20260612100000 extends AbstractMigration
-{
-    public function getDescription(): string
-    {
-        return 'ERP-132 (M3) : tables provider + sous-collections + jointures M2M (referentiels comptables et CategoryType PRESTATAIRE reutilises).';
-    }
-
-    public function up(Schema $schema): void
-    {
-        $this->createProviderTable();
-        $this->createProviderCategory();
-        $this->createProviderSite();
-        $this->createProviderContact();
-        $this->createProviderAddress();
-        $this->createProviderAddressJoinTables();
-        $this->createProviderRib();
-    }
-
-    public function down(Schema $schema): void
-    {
-        // Ordre inverse des dependances FK : jointures et sous-collections
-        // d abord, puis provider. Les referentiels comptables et le
-        // CategoryType PRESTATAIRE ne sont pas touches (crees ailleurs).
-        $this->addSql('DROP TABLE IF EXISTS provider_address_category');
-        $this->addSql('DROP TABLE IF EXISTS provider_address_contact');
-        $this->addSql('DROP TABLE IF EXISTS provider_address_site');
-        $this->addSql('DROP TABLE IF EXISTS provider_rib');
-        $this->addSql('DROP TABLE IF EXISTS provider_address');
-        $this->addSql('DROP TABLE IF EXISTS provider_contact');
-        $this->addSql('DROP TABLE IF EXISTS provider_site');
-        $this->addSql('DROP TABLE IF EXISTS provider_category');
-        $this->addSql('DROP TABLE IF EXISTS provider');
-    }
-
-    // =================================================================
-    // Table principale `provider`
-    // =================================================================
-
-    private function createProviderTable(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider (
-                id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
-                company_name VARCHAR(180) NOT NULL,
-                siren VARCHAR(20) DEFAULT NULL,
-                account_number VARCHAR(40) DEFAULT NULL,
-                tva_mode_id INT DEFAULT NULL,
-                n_tva VARCHAR(40) DEFAULT NULL,
-                payment_delay_id INT DEFAULT NULL,
-                payment_type_id INT DEFAULT NULL,
-                bank_id INT DEFAULT NULL,
-                is_archived BOOLEAN DEFAULT FALSE NOT NULL,
-                archived_at TIMESTAMP(0) WITHOUT TIME ZONE DEFAULT NULL,
-                deleted_at TIMESTAMP(0) WITHOUT TIME ZONE DEFAULT NULL,
-                created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                created_by INT DEFAULT NULL,
-                updated_by INT DEFAULT NULL,
-                PRIMARY KEY (id),
-                CONSTRAINT fk_provider_tva_mode
-                    FOREIGN KEY (tva_mode_id) REFERENCES tva_mode (id) ON DELETE RESTRICT,
-                CONSTRAINT fk_provider_payment_delay
-                    FOREIGN KEY (payment_delay_id) REFERENCES payment_delay (id) ON DELETE RESTRICT,
-                CONSTRAINT fk_provider_payment_type
-                    FOREIGN KEY (payment_type_id) REFERENCES payment_type (id) ON DELETE RESTRICT,
-                CONSTRAINT fk_provider_bank
-                    FOREIGN KEY (bank_id) REFERENCES bank (id) ON DELETE RESTRICT,
-                CONSTRAINT fk_provider_created_by
-                    FOREIGN KEY (created_by) REFERENCES "user" (id) ON DELETE SET NULL,
-                CONSTRAINT fk_provider_updated_by
-                    FOREIGN KEY (updated_by) REFERENCES "user" (id) ON DELETE SET NULL
-            )
-            SQL);
-
-        $this->addSql('CREATE INDEX idx_provider_is_archived ON provider (is_archived)');
-        $this->addSql('CREATE INDEX idx_provider_deleted_at ON provider (deleted_at)');
-        $this->addSql('CREATE INDEX idx_provider_created_by ON provider (created_by)');
-        $this->addSql('CREATE INDEX idx_provider_updated_by ON provider (updated_by)');
-
-        // Index sur les FK des referentiels comptables (Postgres n indexe pas
-        // automatiquement les colonnes portant une FOREIGN KEY).
-        $this->addSql('CREATE INDEX idx_provider_tva_mode_id ON provider (tva_mode_id)');
-        $this->addSql('CREATE INDEX idx_provider_payment_delay_id ON provider (payment_delay_id)');
-        $this->addSql('CREATE INDEX idx_provider_payment_type_id ON provider (payment_type_id)');
-        $this->addSql('CREATE INDEX idx_provider_bank_id ON provider (bank_id)');
-
-        // Unicite metier partielle : nom de societe insensible a la casse, parmi
-        // les non-archives ET non soft-deletes uniquement (RG-3.10). Pas d index
-        // unique sur siren ni email.
-        $this->addSql(<<<'SQL'
-            CREATE UNIQUE INDEX uq_provider_company_name_active
-            ON provider (LOWER(company_name))
-            WHERE is_archived = FALSE AND deleted_at IS NULL
-            SQL);
-
-        $this->comment('provider', '_table', 'Repertoire prestataires (M3 Technique) — entites archivables (is_archived) et soft-deletables (deleted_at, HP M4). Pas d onglet Information (≠ supplier).');
-        $this->comment('provider', 'id', 'Identifiant interne auto-incremente.');
-        $this->comment('provider', 'company_name', 'Raison sociale du prestataire (stockee en MAJUSCULES). Unique case-insensitive parmi les actifs non archives/non supprimes (uq_provider_company_name_active, RG-3.10).');
-        $this->comment('provider', 'siren', 'Onglet Comptabilite : SIREN (9 chiffres attendus). NON unique — peut etre partage entre etablissements (RG-3.10).');
-        $this->comment('provider', 'account_number', 'Onglet Comptabilite : numero de compte comptable du prestataire.');
-        $this->comment('provider', 'tva_mode_id', 'Onglet Comptabilite : mode de TVA applique — FK -> tva_mode.id (referentiel partage M1), ON DELETE RESTRICT.');
-        $this->comment('provider', 'n_tva', 'Onglet Comptabilite : numero de TVA intracommunautaire.');
-        $this->comment('provider', 'payment_delay_id', 'Onglet Comptabilite : delai de reglement — FK -> payment_delay.id (M1), ON DELETE RESTRICT.');
-        $this->comment('provider', 'payment_type_id', 'Onglet Comptabilite : type de reglement — FK -> payment_type.id (M1), ON DELETE RESTRICT. Pilote RG-3.07 (Banque si VIREMENT) et RG-3.08 (RIB).');
-        $this->comment('provider', 'bank_id', 'Onglet Comptabilite : banque — FK -> bank.id (M1), ON DELETE RESTRICT. Obligatoire ssi payment_type = VIREMENT (RG-3.07), null sinon.');
-        $this->comment('provider', 'is_archived', 'Drapeau fonctionnel d archivage — masque par defaut dans la liste. Bascule via permission technique.providers.archive.');
-        $this->comment('provider', 'archived_at', 'Horodatage de l archivage — pose quand is_archived passe a vrai, remis a null a la restauration.');
-        $this->comment('provider', 'deleted_at', 'Horodatage du soft-delete technique (HP M4) — non expose par l API au M3. Null = ligne active.');
-        $this->addTimestampableBlamableComments('provider');
-    }
-
-    // =================================================================
-    // M2M provider <-> category (type PRESTATAIRE — RG-3.09)
-    // =================================================================
-
-    private function createProviderCategory(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_category (
-                provider_id INT NOT NULL,
-                category_id INT NOT NULL,
-                PRIMARY KEY (provider_id, category_id),
-                CONSTRAINT fk_provider_category_provider
-                    FOREIGN KEY (provider_id) REFERENCES provider (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_category_category
-                    FOREIGN KEY (category_id) REFERENCES category (id) ON DELETE RESTRICT
-            )
-            SQL);
-        $this->addSql('CREATE INDEX idx_provider_category_category ON provider_category (category_id)');
-
-        $this->comment('provider_category', '_table', 'Jointure M2M provider <-> category (Catalog) — categories de type PRESTATAIRE du prestataire, au moins une obligatoire (RG-3.09).');
-        $this->comment('provider_category', 'provider_id', 'FK -> provider.id, ON DELETE CASCADE — prestataire porteur de la categorie.');
-        $this->comment('provider_category', 'category_id', 'FK -> category.id, ON DELETE RESTRICT — categorie de type PRESTATAIRE rattachee au prestataire (RG-3.09).');
-    }
-
-    // =================================================================
-    // M2M provider <-> site (formulaire principal — RG-3.03)
-    // =================================================================
-
-    private function createProviderSite(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_site (
-                provider_id INT NOT NULL,
-                site_id INT NOT NULL,
-                PRIMARY KEY (provider_id, site_id),
-                CONSTRAINT fk_provider_site_provider
-                    FOREIGN KEY (provider_id) REFERENCES provider (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_site_site
-                    FOREIGN KEY (site_id) REFERENCES site (id) ON DELETE RESTRICT
-            )
-            SQL);
-        // Index sur site_id : sert le filtre de cloisonnement par site
-        // (WHERE site = :currentSite, § 2.13).
-        $this->addSql('CREATE INDEX idx_provider_site_site ON provider_site (site_id)');
-
-        $this->comment('provider_site', '_table', 'Jointure M2M provider <-> site (Sites) — sites du prestataire, selecteur du formulaire principal, au moins un obligatoire (RG-3.03). Sert le cloisonnement par site (§ 2.13).');
-        $this->comment('provider_site', 'provider_id', 'FK -> provider.id, ON DELETE CASCADE — prestataire porteur du site.');
-        $this->comment('provider_site', 'site_id', 'FK -> site.id, ON DELETE RESTRICT — site rattache au prestataire (RG-3.03, idx_provider_site_site).');
-    }
-
-    // =================================================================
-    // Sous-collection : contacts (1:n)
-    // =================================================================
-
-    private function createProviderContact(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_contact (
-                id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
-                provider_id INT NOT NULL,
-                first_name VARCHAR(120) DEFAULT NULL,
-                last_name VARCHAR(120) DEFAULT NULL,
-                job_title VARCHAR(120) DEFAULT NULL,
-                phone_primary VARCHAR(20) DEFAULT NULL,
-                phone_secondary VARCHAR(20) DEFAULT NULL,
-                email VARCHAR(180) DEFAULT NULL,
-                position INT DEFAULT 0 NOT NULL,
-                created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                created_by INT DEFAULT NULL,
-                updated_by INT DEFAULT NULL,
-                PRIMARY KEY (id),
-                CONSTRAINT chk_provider_contact_name
-                    CHECK (first_name IS NOT NULL OR last_name IS NOT NULL OR phone_primary IS NOT NULL OR email IS NOT NULL),
-                CONSTRAINT fk_provider_contact_provider
-                    FOREIGN KEY (provider_id) REFERENCES provider (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_contact_created_by
-                    FOREIGN KEY (created_by) REFERENCES "user" (id) ON DELETE SET NULL,
-                CONSTRAINT fk_provider_contact_updated_by
-                    FOREIGN KEY (updated_by) REFERENCES "user" (id) ON DELETE SET NULL
-            )
-            SQL);
-        $this->addSql('CREATE INDEX idx_provider_contact_provider ON provider_contact (provider_id)');
-
-        $this->comment('provider_contact', '_table', 'Contacts d un prestataire (1:n) — au moins un champ rempli parmi prenom/nom/telephone/email (RG-3.04, chk_provider_contact_name).');
-        $this->comment('provider_contact', 'id', 'Identifiant interne auto-incremente.');
-        $this->comment('provider_contact', 'provider_id', 'FK -> provider.id, ON DELETE CASCADE — prestataire proprietaire du contact.');
-        $this->comment('provider_contact', 'first_name', 'Prenom du contact (capitalise serveur). Au moins un champ du contact requis (RG-3.04, chk_provider_contact_name).');
-        $this->comment('provider_contact', 'last_name', 'Nom du contact (capitalise serveur). Au moins un champ du contact requis (RG-3.04, chk_provider_contact_name).');
-        $this->comment('provider_contact', 'job_title', 'Fonction / intitule de poste du contact (≤ 120 caracteres).');
-        $this->comment('provider_contact', 'phone_primary', 'Telephone principal du contact — chiffres uniquement (normalisation serveur).');
-        $this->comment('provider_contact', 'phone_secondary', 'Telephone secondaire du contact — chiffres uniquement (normalisation serveur).');
-        $this->comment('provider_contact', 'email', 'Email du contact (lowercase serveur).');
-        $this->comment('provider_contact', 'position', 'Ordre d affichage du contact dans la liste du prestataire (croissant).');
-        $this->addTimestampableBlamableComments('provider_contact');
-    }
-
-    // =================================================================
-    // Sous-collection : adresses (1:n) — SANS address_type / bennes / triage
-    // =================================================================
-
-    private function createProviderAddress(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_address (
-                id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
-                provider_id INT NOT NULL,
-                country VARCHAR(80) DEFAULT 'France' NOT NULL,
-                postal_code VARCHAR(20) NOT NULL,
-                city VARCHAR(120) NOT NULL,
-                street VARCHAR(255) NOT NULL,
-                street_complement VARCHAR(255) DEFAULT NULL,
-                position INT DEFAULT 0 NOT NULL,
-                created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                created_by INT DEFAULT NULL,
-                updated_by INT DEFAULT NULL,
-                PRIMARY KEY (id),
-                CONSTRAINT fk_provider_address_provider
-                    FOREIGN KEY (provider_id) REFERENCES provider (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_address_created_by
-                    FOREIGN KEY (created_by) REFERENCES "user" (id) ON DELETE SET NULL,
-                CONSTRAINT fk_provider_address_updated_by
-                    FOREIGN KEY (updated_by) REFERENCES "user" (id) ON DELETE SET NULL
-            )
-            SQL);
-        $this->addSql('CREATE INDEX idx_provider_address_provider ON provider_address (provider_id)');
-
-        $this->comment('provider_address', '_table', 'Adresses d un prestataire (1:n) — >= 1 site rattache (RG-3.05). SANS address_type / bennes / triage_provider (specifiques fournisseur).');
-        $this->comment('provider_address', 'id', 'Identifiant interne auto-incremente.');
-        $this->comment('provider_address', 'provider_id', 'FK -> provider.id, ON DELETE CASCADE — prestataire proprietaire de l adresse.');
-        $this->comment('provider_address', 'country', 'Pays de l adresse — defaut France.');
-        $this->comment('provider_address', 'postal_code', 'Code postal (4-5 chiffres attendus) — declenche l autocompletion ville via l API BAN cote front (RG-3.06).');
-        $this->comment('provider_address', 'city', 'Ville — preremplie depuis le code postal via API BAN cote front.');
-        $this->comment('provider_address', 'street', 'Numero et voie de l adresse.');
-        $this->comment('provider_address', 'street_complement', 'Complement d adresse (etage, batiment...) — optionnel.');
-        $this->comment('provider_address', 'position', 'Ordre d affichage de l adresse dans la liste du prestataire (croissant).');
-        $this->addTimestampableBlamableComments('provider_address');
-    }
-
-    // =================================================================
-    // Jointures de provider_address (M2M)
-    // =================================================================
-
-    private function createProviderAddressJoinTables(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_address_site (
-                provider_address_id INT NOT NULL,
-                site_id INT NOT NULL,
-                PRIMARY KEY (provider_address_id, site_id),
-                CONSTRAINT fk_provider_address_site_address
-                    FOREIGN KEY (provider_address_id) REFERENCES provider_address (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_address_site_site
-                    FOREIGN KEY (site_id) REFERENCES site (id) ON DELETE RESTRICT
-            )
-            SQL);
-        $this->comment('provider_address_site', '_table', 'Jointure M2M provider_address <-> site (Sites) — sites rattaches a l adresse (>= 1 obligatoire, RG-3.05).');
-        $this->comment('provider_address_site', 'provider_address_id', 'FK -> provider_address.id, ON DELETE CASCADE — adresse concernee.');
-        $this->comment('provider_address_site', 'site_id', 'FK -> site.id, ON DELETE RESTRICT — site rattache a l adresse.');
-
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_address_contact (
-                provider_address_id INT NOT NULL,
-                provider_contact_id INT NOT NULL,
-                PRIMARY KEY (provider_address_id, provider_contact_id),
-                CONSTRAINT fk_provider_address_contact_address
-                    FOREIGN KEY (provider_address_id) REFERENCES provider_address (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_address_contact_contact
-                    FOREIGN KEY (provider_contact_id) REFERENCES provider_contact (id) ON DELETE CASCADE
-            )
-            SQL);
-        $this->comment('provider_address_contact', '_table', 'Jointure M2M provider_address <-> provider_contact — contacts associes a une adresse.');
-        $this->comment('provider_address_contact', 'provider_address_id', 'FK -> provider_address.id, ON DELETE CASCADE — adresse concernee.');
-        $this->comment('provider_address_contact', 'provider_contact_id', 'FK -> provider_contact.id, ON DELETE CASCADE — contact associe a l adresse.');
-
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_address_category (
-                provider_address_id INT NOT NULL,
-                category_id INT NOT NULL,
-                PRIMARY KEY (provider_address_id, category_id),
-                CONSTRAINT fk_provider_address_category_address
-                    FOREIGN KEY (provider_address_id) REFERENCES provider_address (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_address_category_category
-                    FOREIGN KEY (category_id) REFERENCES category (id) ON DELETE RESTRICT
-            )
-            SQL);
-        $this->comment('provider_address_category', '_table', 'Jointure M2M provider_address <-> category — categories d adresse de type PRESTATAIRE (RG-3.09).');
-        $this->comment('provider_address_category', 'provider_address_id', 'FK -> provider_address.id, ON DELETE CASCADE — adresse concernee.');
-        $this->comment('provider_address_category', 'category_id', 'FK -> category.id, ON DELETE RESTRICT — categorie d adresse de type PRESTATAIRE (RG-3.09).');
-    }
-
-    // =================================================================
-    // Sous-collection : RIB (1:n)
-    // =================================================================
-
-    private function createProviderRib(): void
-    {
-        $this->addSql(<<<'SQL'
-            CREATE TABLE provider_rib (
-                id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL,
-                provider_id INT NOT NULL,
-                label VARCHAR(120) NOT NULL,
-                bic VARCHAR(20) NOT NULL,
-                iban VARCHAR(34) NOT NULL,
-                position INT DEFAULT 0 NOT NULL,
-                created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
-                created_by INT DEFAULT NULL,
-                updated_by INT DEFAULT NULL,
-                PRIMARY KEY (id),
-                CONSTRAINT fk_provider_rib_provider
-                    FOREIGN KEY (provider_id) REFERENCES provider (id) ON DELETE CASCADE,
-                CONSTRAINT fk_provider_rib_created_by
-                    FOREIGN KEY (created_by) REFERENCES "user" (id) ON DELETE SET NULL,
-                CONSTRAINT fk_provider_rib_updated_by
-                    FOREIGN KEY (updated_by) REFERENCES "user" (id) ON DELETE SET NULL
-            )
-            SQL);
-        $this->addSql('CREATE INDEX idx_provider_rib_provider ON provider_rib (provider_id)');
-
-        $this->comment('provider_rib', '_table', 'Coordonnees bancaires d un prestataire (1:n) — >= 1 RIB attendu selon le type de reglement (RG-3.08). Tous les champs audites (pas d AuditIgnore).');
-        $this->comment('provider_rib', 'id', 'Identifiant interne auto-incremente.');
-        $this->comment('provider_rib', 'provider_id', 'FK -> provider.id, ON DELETE CASCADE — prestataire proprietaire du RIB.');
-        $this->comment('provider_rib', 'label', 'Libelle du RIB (ex: compte principal).');
-        $this->comment('provider_rib', 'bic', 'Code BIC/SWIFT de la banque (8 ou 11 caracteres).');
-        $this->comment('provider_rib', 'iban', 'IBAN du compte (≤ 34 caracteres).');
-        $this->comment('provider_rib', 'position', 'Ordre d affichage du RIB dans la liste du prestataire (croissant).');
-        $this->addTimestampableBlamableComments('provider_rib');
-    }
-
-    // =================================================================
-    // Helpers
-    // =================================================================
-
-    /**
-     * Pose les 4 commentaires standardises Timestampable/Blamable sur une table,
-     * en reutilisant le catalogue partage (source unique, cf. ERP-67). Seul le
-     * tableau statique des textes est reutilise — aucune dependance a l etat DB.
-     */
-    private function addTimestampableBlamableComments(string $table): void
-    {
-        foreach (ColumnCommentsCatalog::timestampableBlamableComments() as $column => $description) {
-            $this->comment($table, $column, $description);
-        }
-    }
-
-    /**
-     * Emet un `COMMENT ON TABLE` (colonne speciale `_table`) ou
-     * `COMMENT ON COLUMN` en dollar-quoting Postgres ($_$...$_$) pour eviter
-     * tout echappement d apostrophe.
-     */
-    private function comment(string $table, string $column, string $description): void
-    {
-        $quotedTable = '"'.str_replace('"', '""', $table).'"';
-
-        if ('_table' === $column) {
-            $this->addSql(sprintf('COMMENT ON TABLE %s IS $_$%s$_$', $quotedTable, $description));
-
-            return;
-        }
-
-        $this->addSql(sprintf(
-            'COMMENT ON COLUMN %s.%s IS $_$%s$_$',
-            $quotedTable,
-            '"'.str_replace('"', '""', $column).'"',
-            $description,
-        ));
-    }
-}

src/Module/Catalog/Infrastructure/DataFixtures/CategoryFixtures.php

@@ -17,9 +17,7 @@ use Symfony\Component\DependencyInjection\Attribute\Autowire;
  * Fixtures dev/test du module Catalog : categories de demonstration rattachees
  * a leur CategoryType. Le type CLIENT porte ~11 categories clients (refonte
  * taxonomie ERP-78) ; le type FOURNISSEUR porte les categories fournisseurs
- * (ERP-84 : Negociant, Cooperative...) ; le type PRESTATAIRE porte les categories
- * prestataires (M3 1.1 : Maintenance industrielle, Nettoyage, Transport). Chaque
- * categorie porte un `code` stable.
+ * (ERP-84 : Negociant, Cooperative...). Chaque categorie porte un `code` stable.
  * Alimente le repertoire clients (ClientFixtures, module Commercial) avec des
  * donnees realistes couvrant RG-1.03 (codes DISTRIBUTEUR / COURTIER) et RG-1.29
  * (codes interdits sur adresse), et le multi-select Categorie fournisseur (M2).
@@ -73,11 +71,6 @@ class CategoryFixtures extends Fixture implements DependentFixtureInterface
             'Grossiste'   => 'GROSSISTE',
             'Importateur' => 'IMPORTATEUR',
         ],
-        'PRESTATAIRE' => [
-            'Maintenance industrielle' => 'MAINTENANCE_INDUSTRIELLE',
-            'Nettoyage'                => 'NETTOYAGE',
-            'Transport'                => 'TRANSPORT',
-        ],
     ];
 
     public function __construct(

src/Module/Catalog/Infrastructure/DataFixtures/CategoryTypeFixtures.php

@@ -21,10 +21,6 @@ use Doctrine\Persistence\ObjectManager;
  * taxonomie distincte des fournisseurs (Negociant, Cooperative...). Mirroir de
  * la migration Version20260605120000.
  *
- * M3 1.1 : ajout du type PRESTATAIRE (code PRESTATAIRE, label « Prestataire »),
- * taxonomie distincte des prestataires (Maintenance industrielle, Nettoyage,
- * Transport). Mirroir de la migration Version20260612080000.
- *
  * Pourquoi une fixture EN PLUS du seed de la migration : `category_type` est une
  * entite managee par l ORM, donc le purger Doctrine la vide avant chaque
  * `doctrine:fixtures:load`. Sans cette fixture, le type CLIENT seede par la
@@ -40,13 +36,12 @@ class CategoryTypeFixtures extends Fixture
 {
     /**
      * Source unique des types : code technique => libelle FR. Doit rester aligne
-     * sur le seed des migrations Version20260602100000 (CLIENT),
-     * Version20260605120000 (FOURNISSEUR) et Version20260612080000 (PRESTATAIRE).
+     * sur le seed des migrations Version20260602100000 (CLIENT) et
+     * Version20260605120000 (FOURNISSEUR).
      */
     private const TYPES = [
         'CLIENT'      => 'Client',
         'FOURNISSEUR' => 'Fournisseur',
-        'PRESTATAIRE' => 'Prestataire',
     ];
 
     public function __construct(

src/Module/Technique/TechniqueModule.php

@@ -1,58 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace App\Module\Technique;
-
-/**
- * Module Technique (M3) — pole distinct du Commercial qui porte le repertoire
- * prestataires (entites Provider* livrees par les tickets suivants du M3).
- *
- * Decision Matthieu (11/06/2026) : le repertoire prestataires vit dans un
- * module a part entiere « Technique » (et non sous Commercial), conformement au
- * docx source. Ce module est activable/desactivable comme les autres
- * (cf. config/modules.php), non requis au boot.
- *
- * Au ticket 1.1, le module ne porte encore aucune entite : il declare seulement
- * son identite et son jeu de permissions (cf. spec-back M3 § 2.1 + § 5.1). Le
- * cablage de la section sidebar « Technique » et l'attribution des permissions
- * aux roles interviennent avec l'ecran prestataires (tickets ulterieurs).
- */
-final class TechniqueModule
-{
-    public const string ID     = 'technique';
-    public const string LABEL  = 'Technique';
-    public const bool REQUIRED = false;
-
-    /**
-     * Liste declarative des permissions RBAC exposees par le module Technique.
-     *
-     * Consommee par la commande `app:sync-permissions` (SyncPermissionsCommand)
-     * qui se charge d'upserter ces entrees dans la table `permission`, de
-     * reactiver les codes precedemment marques orphelins et de marquer comme
-     * orphelins ceux qui ont disparu du code source.
-     *
-     * La cle `module` est auto-injectee par le sync command a partir de
-     * `self::ID`, il est donc inutile de la repeter dans chaque entree.
-     *
-     * Convention de nommage des codes : `module.resource[.sub].action` en
-     * snake_case, le prefixe module devant correspondre exactement a
-     * `self::ID` (verifie par la commande de synchronisation).
-     *
-     * Granularite alignee sur Commercial (les prestataires sont le jumeau des
-     * fournisseurs) : view + manage, plus deux permissions dediees a l'onglet
-     * Comptabilite et une a l'archivage (cf. spec-back M3 § 2.9 + § 5.1).
-     *
-     * @return array<int, array{code: string, label: string}>
-     */
-    public static function permissions(): array
-    {
-        return [
-            ['code' => 'technique.providers.view', 'label' => 'Voir les prestataires'],
-            ['code' => 'technique.providers.manage', 'label' => 'Créer / modifier les prestataires (hors onglet Comptabilité)'],
-            ['code' => 'technique.providers.accounting.view', 'label' => 'Voir l\'onglet Comptabilité d\'un prestataire'],
-            ['code' => 'technique.providers.accounting.manage', 'label' => 'Modifier l\'onglet Comptabilité d\'un prestataire'],
-            ['code' => 'technique.providers.archive', 'label' => 'Archiver / restaurer un prestataire'],
-        ];
-    }
-}

src/Module/Transport/TransportModule.php

@@ -0,0 +1,29 @@
+<?php
+
+declare(strict_types=1);
+
+namespace App\Module\Transport;
+
+final class TransportModule
+{
+    public const string ID     = 'transport';
+    public const string LABEL  = 'Transport';
+    public const bool REQUIRED = false;
+
+    /**
+     * Liste declarative des permissions RBAC exposees par le module Transport.
+     *
+     * Vide a ce stade : le module ne porte que des referentiels externes
+     * synchronises par commandes console (codes IDTF - ERP-149, transporteurs
+     * QUALIMAT - ERP-39), sans ecran ni action protegee. Les permissions seront
+     * ajoutees quand une page de consultation sera exposee.
+     *
+     * Consommee par `app:sync-permissions` (un tableau vide est valide).
+     *
+     * @return array<int, array{code: string, label: string}>
+     */
+    public static function permissions(): array
+    {
+        return [];
+    }
+}

src/Shared/Infrastructure/Database/ColumnCommentsCatalog.php

@@ -361,14 +361,6 @@ final class ColumnCommentsCatalog
                 'iban'        => 'IBAN du compte (≤ 34 caracteres).',
                 'position'    => 'Ordre d affichage du RIB dans la liste du fournisseur (croissant).',
             ] + self::timestampableBlamableComments(),
-
-            // NB : les tables provider* (M3 Technique) NE SONT PAS encore au
-            // catalogue. Tant que les entites Provider* n existent pas (ERP-133),
-            // `schema:update --force` du setup de test droppe ces tables non
-            // mappees ; les referencer ici ferait planter `app:apply-column-comments`
-            // (table absente en test). La migration ERP-132 porte ses COMMENT inline
-            // (dev/prod). Le catalogue sera etendu au ticket entites (ERP-133),
-            // comme l a fait supplier (ERP-86) apres sa migration (ERP-85).
         ];
     }
 

tests/Module/Catalog/Api/CategoryPrestataireSeedTest.php

@@ -1,107 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace App\Tests\Module\Catalog\Api;
-
-use App\Module\Catalog\Domain\Entity\CategoryType;
-
-/**
- * Tests du seed de la taxonomie PRESTATAIRE (M3 1.1) cote API.
- *
- * Le multi-select « Categorie » du prestataire (formulaire principal + adresse)
- * consomme `GET /api/categories?typeCode=PRESTATAIRE`. Ce test prouve que :
- *  - le filtre `?typeCode=PRESTATAIRE` ne renvoie QUE les categories du type
- *    PRESTATAIRE (aucune fuite de categorie d'un autre type) ;
- *  - chaque membre renvoye porte bien le type PRESTATAIRE dans `categoryTypes`.
- *
- * NB : la base de test est purgee de toute categorie / type entre chaque test
- * (cf. AbstractCatalogApiTestCase::cleanupCatalogTestData), donc le type et les
- * categories PRESTATAIRE sont materialises ici (et non lus depuis le seed de la
- * migration / fixture, qui ne survit pas a la purge). On valide ainsi le contrat
- * du filtre sur le code reel `PRESTATAIRE`. La presence du seed apres un
- * `make db-reset` reel est, elle, verifiee par l'idempotence des fixtures.
- *
- * @internal
- */
-final class CategoryPrestataireSeedTest extends AbstractCatalogApiTestCase
-{
-    /**
-     * Categories de demonstration seedees par la migration / fixture PRESTATAIRE.
-     */
-    private const array PROVIDER_CATEGORIES = [
-        'Maintenance industrielle',
-        'Nettoyage',
-        'Transport',
-    ];
-
-    public function testTypeCodePrestataireReturnsOnlyProviderCategories(): void
-    {
-        $providerType = $this->getOrCreatePrestataireType();
-        foreach (self::PROVIDER_CATEGORIES as $name) {
-            $this->createCategory($name, $providerType);
-        }
-
-        // Bruit : un type + une categorie d'un autre type ne doivent PAS fuiter.
-        $noiseType = $this->createCategoryType('TEST_FOURNISSEUR', 'Test Fournisseur');
-        $this->createCategory(self::TEST_CATEGORY_PREFIX.'noise', $noiseType);
-
-        $client   = $this->createAdminClient();
-        $response = $client->request('GET', '/api/categories?typeCode=PRESTATAIRE&pagination=false');
-        self::assertSame(200, $response->getStatusCode());
-
-        $members = $response->toArray()['member'];
-        $names   = array_map(static fn (array $m): string => $m['name'], $members);
-        sort($names);
-
-        $expected = self::PROVIDER_CATEGORIES;
-        sort($expected);
-        self::assertSame(
-            $expected,
-            $names,
-            'Le filtre ?typeCode=PRESTATAIRE doit ne renvoyer QUE les categories du type PRESTATAIRE.',
-        );
-
-        // Chaque categorie remontee doit PORTER le type PRESTATAIRE.
-        foreach ($members as $member) {
-            self::assertContains('PRESTATAIRE', array_column($member['categoryTypes'], 'code'));
-        }
-    }
-
-    public function testTypeCodePrestataireKeepsHydraPagination(): void
-    {
-        $providerType = $this->getOrCreatePrestataireType();
-        $this->createCategory('Maintenance industrielle', $providerType);
-
-        $client   = $this->createAdminClient();
-        $response = $client->request('GET', '/api/categories?typeCode=PRESTATAIRE');
-        self::assertSame(200, $response->getStatusCode());
-
-        $data = $response->toArray();
-        self::assertArrayHasKey('totalItems', $data, 'Le filtre ne doit pas casser la pagination Hydra.');
-        self::assertArrayHasKey('member', $data);
-
-        foreach ($data['member'] as $member) {
-            self::assertContains('PRESTATAIRE', array_column($member['categoryTypes'], 'code'));
-        }
-    }
-
-    /**
-     * Recupere le type PRESTATAIRE reel, ou le cree s'il est absent. Le code
-     * `PRESTATAIRE` est seede par CategoryTypeFixtures (present en debut de suite),
-     * mais le cleanup purge tous les `category_type` entre les tests : selon
-     * l'ordre d'execution, le type peut donc exister ou non. Le get-or-create rend
-     * le test robuste sans dependre du seed ni le dupliquer.
-     */
-    private function getOrCreatePrestataireType(): CategoryType
-    {
-        $em       = $this->getEm();
-        $existing = $em->getRepository(CategoryType::class)->findOneBy(['code' => 'PRESTATAIRE']);
-
-        if ($existing instanceof CategoryType) {
-            return $existing;
-        }
-
-        return $this->createCategoryType('PRESTATAIRE', 'Prestataire');
-    }
-}

tests/Module/Technique/TechniqueModuleTest.php

@@ -1,59 +0,0 @@
-<?php
-
-declare(strict_types=1);
-
-namespace App\Tests\Module\Technique;
-
-use App\Module\Technique\TechniqueModule;
-use PHPUnit\Framework\TestCase;
-
-/**
- * Tests structurels du module Technique (M3) : identite et contrat
- * `permissions()`.
- *
- * @internal
- */
-final class TechniqueModuleTest extends TestCase
-{
-    public function testModuleIdentity(): void
-    {
-        self::assertSame('technique', TechniqueModule::ID);
-        self::assertSame('Technique', TechniqueModule::LABEL);
-        self::assertFalse(TechniqueModule::REQUIRED);
-    }
-
-    public function testPermissionsSetContainsExactlyFiveCodes(): void
-    {
-        // Garde-fou : le jeu de permissions du module est fige par ce test. Si
-        // quelqu'un ajoute / retire une permission sans ajuster la spec (§ 5.1)
-        // ni la matrice RBAC, le test casse explicitement.
-        $codes = array_column(TechniqueModule::permissions(), 'code');
-        sort($codes);
-
-        self::assertSame(
-            [
-                'technique.providers.accounting.manage',
-                'technique.providers.accounting.view',
-                'technique.providers.archive',
-                'technique.providers.manage',
-                'technique.providers.view',
-            ],
-            $codes,
-        );
-    }
-
-    public function testEveryPermissionCodeIsPrefixedByModuleId(): void
-    {
-        // Convention de nommage `module.resource[.sub].action` : le prefixe doit
-        // correspondre exactement a l'ID du module (verifie aussi par
-        // app:sync-permissions).
-        foreach (TechniqueModule::permissions() as $permission) {
-            self::assertStringStartsWith(
-                TechniqueModule::ID.'.',
-                $permission['code'],
-                'Chaque code de permission doit etre prefixe par l\'ID du module.',
-            );
-            self::assertNotSame('', $permission['label'], 'Chaque permission doit porter un label.');
-        }
-    }
-}