feat(transport) : schéma + entités Carrier + contrat lecture (ERP-155/157)

Schéma BDD du répertoire transporteurs (M4) + entités + contrat de lecture
(liste + détail), socle du front.

- Migration Version20260615150000 : tables carrier / carrier_address /
  carrier_contact / carrier_price (FK cross-module, CHECK enum, index partiel
  uq_carrier_name_active, COMMENT ON COLUMN). uploaded_document et
  qualimat_carrier réutilisées (non recréées).
- Entités Carrier* (#[Auditable], Timestampable/Blamable) + ApiResource
  LECTURE seule (GetCollection + Get via CarrierProvider, anti-N+1, exclusion
  archivés + ?includeArchived). Écriture (POST/PATCH + Processor) reportée WT4+.
- QualimatCarrier : mapping ORM lecture seule sur la table référentielle
  existante (sortie du schema_filter, mapping aligné DDL ERP-39, schema:update
  no-op) + endpoint de recherche read-only (§ 4.7).
- Relations cross-module des prix (Client/Supplier/adresses) via contrats
  Shared (ClientInterface, SupplierInterface, ClientAddressInterface,
  SupplierAddressInterface) + resolve_target_entities — sans import inter-module
  (règle n°1). Ajout du groupe supplier_address:read aux champs de
  SupplierAddress pour l'embed.
- Garde-fous : ColumnCommentsCatalog (carrier* + qualimat_carrier), makefile
  test-db-setup (index partiel carrier), i18n audit (transport_carrier*),
  EntitiesAreTimestampableBlamableTest (QualimatCarrier whitelisté).
- CarrierSerializationContractTest : contrat JSON liste + détail vérifié
  (embeds objet, booléens, enveloppe Hydra) ; JSON réel capturé dans
  spec-back § 4.0.bis.

make db-reset OK, make test vert (731), make nuxt-test vert (480),
php-cs-fixer OK.

.claude/rules/architecture.md

@@ -0,0 +1,66 @@
+# Architecture — Modular Monolith DDD
+
+## Principe fondamental
+Le **backend est la source de verite unique**. Il dicte :
+- Quels modules sont actifs (`config/modules.php`)
+- L'organisation de la sidebar (`config/sidebar.php`, decouplee des modules)
+
+Le frontend scanne `modules/*/` comme layers Nuxt et consomme l'API pour la navigation. Il ne decide rien.
+
+## Endpoints API cles
+
+- `GET /api/version` (public) — version de l'app
+- `GET /api/modules` (public) — IDs des modules actifs
+- `GET /api/sidebar` (public) — sections filtrees par modules actifs + `disabledRoutes` (items dont le module owner est inactif)
+- `GET /api/me` (auth) — user courant
+
+## Arborescence minimale (detail complet : @README.md)
+
+```
+src/
+  Shared/               # Noyau technique partage (Domain/, Application/Bus/, Infrastructure/ApiPlatform/)
+  Module/
+    Core/               # Module obligatoire (auth, users)
+      CoreModule.php    # ID, LABEL, REQUIRED, permissions()
+      Domain/ Application/ Infrastructure/
+    Commercial/         # Exemple d'autre module
+frontend/
+  app/                  # Shell (layouts, middlewares)
+  shared/               # Code inter-modules (composables, stores, utils)
+  modules/              # Layers Nuxt auto-detectes
+    core/ commercial/
+```
+
+## Declaration d'un module
+
+Chaque module expose un `*Module.php` avec :
+- `ID` (snake_case, ex: `commercial`, `gestion_rh`)
+- `LABEL`
+- `REQUIRED` (bool)
+- Methode statique `permissions()` retournant les RBAC du module
+
+## Activer / desactiver un module
+
+Editer uniquement `config/modules.php` (commenter la ligne). Cascade automatique :
+1. `/api/modules` ne retourne plus l'ID
+2. `/api/sidebar` filtre les items `module: '<id>'` et supprime les sections vides
+3. Middleware front `modules.global.ts` redirige toute navigation vers une route desactivee
+4. Le code reste dans le bundle (layer auto-detecte) → reactivation instantanee sans rebuild
+
+## Reorganiser la sidebar
+
+Editer uniquement `config/sidebar.php`. Le code des modules n'est pas touche — seule la place des items change. Chaque item reference son module owner via la cle `module`.
+
+## Communication inter-modules
+
+**Interdit** : import direct d'une classe d'un autre module.
+**Autorise** :
+- Via `Shared/Domain/Contract/` (interfaces : `UserResolverInterface`, `TenantAwareInterface`...)
+- Via domain events (`Shared/Domain/Event/DomainEventInterface`)
+
+## Migrations
+
+- **Par defaut** : `src/Module/<Module>/Infrastructure/Doctrine/Migrations/` (namespace modulaire)
+- **Exception** : les migrations d'initialisation critiques (setup user, RBAC, seed de base) vivent au namespace racine `DoctrineMigrations` dans `migrations/`.
+  - Raison : avec plusieurs `migrations_paths`, Doctrine Migrations 3.x trie par FQCN alphabetique et non par version timestamp → ordre incorrect entre namespaces sur base vide.
+  - A supprimer quand un `MigrationsComparator` custom ou un upgrade Doctrine resoudra le tri.

.claude/rules/backend.md

@@ -0,0 +1,90 @@
+# Backend — Regles PHP / Symfony / API Platform
+
+## Structure de fichier
+
+- Toujours `declare(strict_types=1);` en tete de tout fichier PHP
+- PHP CS Fixer : regles Symfony + PSR-12 + strict types (commande : `make php-cs-fixer-allow-risky`)
+- Commentaires (docblock, inline, bloc) **en francais** ; code (classes, methodes, variables) en anglais
+
+## Messages de validation (obligatoire)
+
+Toute contrainte `#[Assert\*]` d'une entite metier : **message FR explicite**, et `Assert\Length.max` = `length` de la colonne ORM (coherence 3 niveaux nullable DB <-> NotBlank back <-> required front, ERP-101). RG inter-champs via `#[Assert\Callback]->atPath('<champ>')` (mapping inline front, pas toast). Exceptions miroir Length (Bic/Iban/Regex borne) : whitelist `EntityConstraintsHaveFrenchMessageTest::EXCLUDED_LENGTH_MIRROR`.
+
+Garde-fou : `tests/Architecture/EntityConstraintsHaveFrenchMessageTest` (casse `make test`).
+→ patterns code + exemples + justification complete : skill `backend-entity-conventions`.
+
+## API Platform (pas de controllers)
+
+- Toujours utiliser `#[ApiResource]` + Providers + Processors — pas de controllers Symfony classiques
+- Routes prefixees `/api` (via `config/routes/api_platform.yaml`)
+- Le login `/login_check` est **hors** prefix `/api` (nginx reecrit `REQUEST_URI` vers `/login_check`)
+- **Exception** : si tu dois creer un controller custom sous `/api/`, mettre `priority: 1` sur `#[Route]` pour eviter le conflit avec API Platform `{id}`
+
+## Pagination (obligatoire)
+
+Toute collection API est paginee (defaut 10, max 50 ; `?pagination=false` = echappatoire selects, `?itemsPerPage=25` borne par le max). Standard global dans `config/packages/api_platform.yaml`. Jamais `paginationEnabled: false` hors whitelist `CollectionsArePaginatedTest::EXCLUDED`. Provider custom : ne jamais retourner un `array` brut sur une `CollectionOperationInterface` (court-circuite Hydra) — wrapper un Paginator (ORM : `ApiPlatform\Doctrine\Orm\Paginator` ; DBAL : `DbalPaginator`) et gerer `?pagination=false` via `$this->pagination->isEnabled(...)`.
+
+Garde-fou : `tests/Architecture/CollectionsArePaginatedTest` (casse `make test`).
+→ tableau des cles `pagination_*` + selects + providers ORM/DBAL detailles : skill `backend-entity-conventions`.
+
+## Repositories
+
+- Interface : `*RepositoryInterface` dans `Domain/Repository/`
+- Implementation Doctrine : `Doctrine*Repository` dans `Infrastructure/Doctrine/`
+- Le domaine garde les attributs ORM (approche pragmatique)
+
+## RBAC (permissions)
+
+Format obligatoire : `module.resource[.subresource].action` en snake_case.
+- Exemples : `core.users.view`, `commercial.clients.contacts.edit`, `core.audit_log.view`
+- Declarees via la methode statique `permissions()` des `*Module.php`
+- Synchronisation : `app:sync-permissions`
+- Verification API Platform : `is_granted('module.resource.action')`
+- Verification front : `usePermissions()`
+
+## Roles
+
+- Hierarchie dans `config/packages/security.yaml` : `ROLE_ADMIN`, `ROLE_USER`
+- Le role ne remplace pas la permission RBAC — deux niveaux complementaires
+
+## Audit (obligatoire)
+
+- Toute entite metier (nouvelle ou existante) : `#[Auditable]` (de `Shared/Domain/Attribute/`)
+- Champs sensibles (password, token, secret) : `#[AuditIgnore]`
+- Audit ManyToMany : trace automatiquement `{fieldName: {added: [ids], removed: [ids]}}` — aucune action supplementaire
+- Spec complete : @doc/audit-log.md
+
+### Libelle i18n du type d'entite (obligatoire avec `#[Auditable]`)
+
+Toute entite `#[Auditable]` doit avoir sa cle `audit.entity.<module>_<entity>` dans `frontend/i18n/locales/fr.json` (cle = `strtolower(module)` + `_` + `strtolower(Entity)`, decision ERP-99). Sans elle, le filtre « Type d'entite » de l'audit-log retombe silencieusement sur le type technique brut (ex: `commercial.Client`). Fait partie de la definition de fini d'une entite auditee.
+
+Garde-fou : `tests/Architecture/AuditableEntitiesHaveI18nLabelTest` (casse `make test`).
+→ derivation detaillee + exemples : skill `backend-entity-conventions`.
+
+## Timestampable + Blamable (obligatoire pour entites metier)
+
+Toute **nouvelle** entite metier sous `src/Module/*/Domain/Entity/` : `implements TimestampableInterface, BlamableInterface` + `use TimestampableBlamableTrait` (porte les 4 colonnes `created_at` / `updated_at` / `created_by` / `updated_by`, remplies par `TimestampableBlamableSubscriber` au prePersist/preUpdate). La migration cree les 4 colonnes (`created_at`/`updated_at` NOT NULL, `created_by`/`updated_by` nullable `ON DELETE SET NULL`). Referentiel statique justifie : whitelist `EntitiesAreTimestampableBlamableTest::EXCLUDED`.
+
+Garde-fou : `tests/Architecture/EntitiesAreTimestampableBlamableTest` (casse `make test`).
+→ snippet complet : skill `backend-entity-conventions` ; spec : @docs/specs/M0-categories/spec-back.md § 2.8 + § 2.8.bis.
+
+## Serialization
+
+Pour embarquer une relation dans le JSON (au lieu d'un IRI Hydra), ajouter le groupe du parent sur les proprietes de l'entite cible.
+
+Exemple : pour qu'`User.profile` soit embarque au lieu d'un lien IRI sous le groupe `user:read`, annoter `Profile.$firstName` avec `#[Groups(['user:read'])]`.
+
+## Upload de fichiers
+
+- Valider cote serveur avec `$file->getMimeType()` — **jamais** `getClientMimeType()` (spoofable par le client)
+
+## PostgreSQL
+
+- Noms de colonnes toujours en **minuscules** dans le SQL brut (commun a tous les projets MALIO)
+
+## Migrations Doctrine
+
+Toute migration creant/modifiant une colonne d'une table metier pose un `COMMENT ON COLUMN` (FR, ≤ 200 caracteres, semantique + contrainte/RG, cible pour les FK). Les 4 colonnes Timestampable/Blamable recoivent leur description via le helper centralise `addStandardTimestampableBlamableComments($schema, 'table')`. Bonus : `COMMENT ON TABLE` pour decrire la table.
+
+Garde-fou : `tests/Architecture/ColumnsHaveSqlCommentTest` parcourt `information_schema.columns` (schema `public`) ; une seule colonne sans `col_description` casse `make test` (hors `EXCLUDED_TABLES`).
+→ exemples SQL + textes du helper : skill `backend-entity-conventions`.

.claude/rules/frontend.md

@@ -0,0 +1,167 @@
+# Frontend — Regles Nuxt 4 / Vue 3 / @malio/layer-ui
+
+## Base
+
+- TypeScript strict
+- 4 espaces d'indentation
+- Commentaires (JSDoc, inline, bloc) **en francais** ; code (variables, types) en anglais
+- Chaque module front = un layer Nuxt auto-detecte (`frontend/modules/*/nuxt.config.ts` minimal)
+
+## Appels API
+
+- Toujours `useApi()` — jamais `$fetch`, `ofetch`, `axios` en direct
+- `useApi()` gere : cookies JWT, erreurs, toasts i18n, parsing Hydra
+
+## Stores (Pinia)
+
+- `useAuthStore` pour l'authentification
+- `useUiStore` pour l'etat UI global (sidebar, modales, etc.)
+- Composables avec state singleton (refs module-level) : exposer une fonction `reset*()` et la rappeler au logout (ex: `useSidebar().resetSidebar()`)
+
+## Middlewares globaux
+
+- `auth.global.ts` protege les routes + charge la sidebar apres login
+- `modules.global.ts` redirige si la route demandee est dans `disabledRoutes`
+
+## i18n et sidebar
+
+- Labels de sidebar = cles i18n `sidebar.<module>.*`, jamais du texte brut
+- Le layout `default.vue` applique `t()` sur les labels retournes par `/api/sidebar`
+- Traductions dans `frontend/i18n/locales/`
+
+## Composants formulaires — @malio/layer-ui obligatoire
+
+Tout champ de formulaire / filtre doit utiliser les composants `Malio*` plutot que `<input>` / `<select>` bruts :
+
+- `MalioInputText`, `MalioInputNumber`, `MalioInputAmount`, `MalioInputPassword`, `MalioInputTextArea`
+- `MalioSelect`, `MalioSelectCheckbox`, `MalioCheckbox`, `MalioRadioButton`
+- `MalioInputUpload`, `MalioTime`
+- `MalioButton`, `MalioButtonIcon`
+
+**Exceptions autorisees** (commenter un `// TODO` pour migrer quand la lib couvrira le cas) :
+1. Type non couvert : `datetime-local`, `date`, color picker, file drag & drop
+2. Bug connu bloquant (ex: `MalioSelect` avec options string) — documenter le bug en commentaire
+
+Toute autre exception requiert validation avant merge.
+
+## Standard ecran formulaire — reference : ecran Client
+
+**Tout nouvel ecran de formulaire doit ressembler au premier ecran Client** (`frontend/modules/commercial/pages/clients/new.vue` + `[id]/edit.vue`) : meme structure (bloc principal puis onglets), memes marges/espacements, memes blocs de collection (ajout/suppression inline), meme validation inline 422 par champ. C'est la reference visuelle et fonctionnelle des formulaires du projet — s'en inspirer avant d'en creer un nouveau.
+
+## Validation des formulaires — useFormErrors obligatoire (erreur par champ)
+
+**Tout formulaire qui soumet a une API DOIT afficher les erreurs de validation 422 sous le champ concerne, via `useFormErrors`** (`frontend/shared/composables/useFormErrors.ts`). C'est le pendant front de « le back renvoie TOUTES les violations d'une 422 d'un coup » : un seul aller-retour, chaque erreur affichee inline sous son champ (prop `:error` des `Malio*`), pas un toast fourre-tout.
+
+Principe cle : **le nom du champ cote front = le `propertyPath` renvoye par le back**. Aucun mapping manuel champ par champ.
+
+Pattern de reference (champs scalaires) :
+
+```ts
+const { errors, setError, clearErrors, handleApiError } = useFormErrors()
+
+async function submit() {
+    clearErrors()
+    try {
+        await useApi().post('/clients', payload, { toast: false }) // toast: false obligatoire
+    } catch (e) {
+        // 422 → mapping inline par champ (pas de toast) ; autre → toast de fallback.
+        handleApiError(e, { fallbackMessage: t('foo.error') })
+    }
+}
+```
+
+```vue
+<MalioInputText v-model="form.companyName" :error="errors.companyName" />
+<MalioSelect    v-model="form.siren"       :error="errors.siren" />
+```
+
+Regles :
+- **Toujours `{ toast: false }`** sur l'appel API qui veut un mapping inline (sinon le toast natif d'`useApi` masque le fin).
+- **Cas metier specifique** (ex: 409 doublon) : `setError('champ', message)` + toast explicite **avant** de deleguer le reste a `handleApiError`. Cf. `useCategoryForm` (doublon RG-1.07).
+- **Collections** (listes de sous-entites sauvees par un appel par ligne) : une erreur PAR LIGNE via un tableau `ref<Record<string, string>[]>` aligne sur l'index, peuple par `mapViolationsToRecord(error.response._data)` (util pur de `shared/utils/api.ts`). Le composant de ligne expose une prop `:errors` (`Record<string, string>`) bindee sur le `:error` de chaque champ. Cf. `ClientContactBlock` / `ClientAddressBlock` et les submits de `clients/new.vue` / `clients/[id]/edit.vue`.
+- **Message back technique → surcharge i18n par code** : la plupart des contraintes back portent un message FR explicite (affiche tel quel). Mais une 422 peut porter un message TECHNIQUE non montrable (ex. erreur de type API Platform sur une date non parsable : « Cette valeur doit être de type DateTimeImmutable|null. », voire en anglais selon la negociation). On le surcharge **cote front** via le `code` de violation (UUID Symfony fige, robuste — pas un match sur le texte) : table `VIOLATION_MESSAGE_I18N` + `resolveViolationMessage` dans `shared/utils/api.ts`, appliquee par `useFormErrors`. Ajouter un cas = une entree `code -> cle i18n`. Cas reference : date invalide (MalioDate forwarde la saisie brute via `@update:rawValue`, le back renvoie 422 sur `foundedAt` grace a `collectDenormalizationErrors`, le front affiche `errors.validation.invalidDate`).
+
+**Interdit** : se contenter d'un toast global sur une 422 quand le back identifie les champs fautifs (`propertyPath`). Reimplementer un mapping `if/else` par champ a la main au lieu d'`useFormErrors` / `mapViolationsToRecord`.
+
+## Tableaux de donnees — MalioDataTable obligatoire
+
+Tout affichage LISTE tabulaire (donnees metier paginees, CRUD admin) doit passer par `MalioDataTable` :
+- Pagination integree
+- Slots `#header-*` pour filtres, `#cell-*` pour rendu custom
+- Pas de `<table>` brut avec pagination custom
+
+**Exception** : tableaux purement presentationnels non paginables (diff field/old/new, grille de comparaison, matrice RBAC d'admin, etc.) peuvent rester en `<table>` HTML brut.
+
+## Listes paginees (standard) — usePaginatedList obligatoire
+
+**Toute liste qui consomme une `GetCollection` API doit passer par `usePaginatedList`** (`frontend/shared/composables/usePaginatedList.ts`). Le composable est le pendant front de la regle ABSOLUE n°13 (« toute collection est paginee cote back ») : il consomme l'envelope Hydra (`member` / `totalItems` / `view`) et expose un etat reactif a brancher directement sur `MalioDataTable`.
+
+Pattern de reference :
+
+```ts
+const {
+    items,
+    totalItems,
+    currentPage,
+    itemsPerPage,
+    itemsPerPageOptions,
+    fetch: loadList,
+    goToPage,
+    setItemsPerPage,
+} = usePaginatedList<MyEntity>({ url: '/my-resources' })
+
+onMounted(loadList)
+```
+
+```vue
+<MalioDataTable
+    :columns="columns"
+    :items="rows"
+    :total-items="totalItems"
+    :page="currentPage"
+    :per-page="itemsPerPage"
+    :per-page-options="itemsPerPageOptions"
+    :empty-message="t('foo.empty')"
+    @update:page="goToPage"
+    @update:per-page="setItemsPerPage"
+/>
+```
+
+Garanties offertes par le composable :
+- Force `Accept: application/ld+json` → API Platform 4 renvoie bien `member` / `totalItems` (sans Accept, retour tableau plat sans pagination).
+- Defaut 10 items/page, choix client 10 / 25 / 50, aligne sur le defaut serveur.
+- Mutation `setFilters` / `setSort` / `setItemsPerPage` → retombe systematiquement en page 1.
+- Cas limite « page hors borne apres filtre » : retombe automatiquement sur la derniere page valide (`tests/usePaginatedList.test.ts`).
+- Etat 100 % local (refs internes a l'instance) — **jamais reflete dans l'URL**, conformement a la regle « Etat des tableaux — pas de persistance URL » ci-dessous.
+
+A NE PAS faire :
+- Charger une collection complete via `?itemsPerPage=999` pour bypasser la pagination. Le seul cas legitime de retour complet est l'alimentation d'un `<select>` sur un referentiel ≤ quelques dizaines d'entrees, et il passe par `?pagination=false` (echappatoire prevue par `pagination_client_enabled: true`).
+- Reimplementer la pagination prev/next a la main au-dessus de `MalioDataTable` — le composant porte deja le selecteur items/page et les boutons Prev/Next.
+- Persister `page`/`tri`/`filtre` dans la query string — meme regle que pour `<MalioDataTable>` brut (cf. section suivante).
+
+## Etat des tableaux — pas de persistance URL
+
+**Interdit** de persister l'etat d'un tableau (filtres, pagination, tri par colonne, selection, ligne active, scroll) dans la query string ou de le reinjecter depuis `route.query` au montage.
+
+- L'etat vit uniquement dans le composant (`reactive`, `ref` locales)
+- Seuls les deep links "de navigation metier" (ex: ouvrir un detail precis `/users/42`) sont dans l'URL
+- Exceptions autorisees **sur demande explicite** de l'utilisateur
+
+## Validation des formulaires (standard ERP-101)
+
+Regle transverse a TOUS les formulaires front (et a rappeler a l'ecriture de chaque ticket back/front portant un formulaire). Decidee en ERP-101 (declencheur : ecran « Ajouter un client » ERP-63).
+
+- **Champs obligatoires** : prop `required` du composant `Malio*` + etoile (asterisque) rouge dans le label. Ne JAMAIS griser le bouton « Valider » sans feedback : bouton toujours actif + erreurs affichees sous les champs.
+- **Couche de validation autoritaire = le back** : les RG sont re-validees serveur (mode strict). Au `422`, mapper `violations[].propertyPath` vers la prop `error` du champ via `extractApiViolations` (deja utilise par `useCategoryForm`). Zero duplication de RG, zero drift.
+- **Feedback instantane au blur** : uniquement requis / min / max / format (pas de re-implementation des RG metier cote front).
+- **Regles front-only** : celles sans equivalent back (ex. FK nullable cote back mais obligatoire selon un choix UI) sont validees et affichees cote front.
+- **Email — PAS de masque** : un email n'a pas de structure fixe. Normalisation via la prop `lowercase` de `MalioInputEmail` (trim + suppression des espaces + lowercase, coherent avec la normalisation serveur RG-1.21). Le format est valide par la prop `error` (violations serveur ou check au blur), jamais par un masque. Retirer tout shaping email ad hoc des ecrans.
+- **Contrat back attendu** : tout `422` issu d'un Processor/Validator doit porter `violations[].propertyPath` aligne sur les noms de champs du formulaire, pour etre consommable par `extractApiViolations`.
+- **Dependance** : le branchement des props `required` suppose `@malio/layer-ui` a jour (props `required` + etoile — MUI-41 / ERP-101).
+
+## Interdits
+
+- `modules-loader.ts`, `.module.ts` — le scan des layers est automatique
+- Hardcode de la sidebar cote front — elle vient de `/api/sidebar`
+- Edition manuelle de `extends` dans `frontend/nuxt.config.ts` — les layers sont scannes
+- Import d'un module front depuis un autre module — passer par `frontend/shared/`

.claude/rules/git.md

@@ -0,0 +1,39 @@
+# Git
+
+## Commits
+
+Format : `<type>(<scope optionnel>) : <message>`
+**Espaces obligatoires** autour du `:`.
+
+Types autorises (minuscules uniquement) : `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`
+
+Exemples :
+- `feat : add login page`
+- `fix(auth) : prevent null token crash`
+- `chore : bump version to v1.2.3`
+
+## Regles de commit
+
+- **Jamais commit sans demande explicite** de l'utilisateur
+- **Jamais force push** sans confirmation
+- **Jamais modifier la config git**
+- **Jamais mentionner Claude, Anthropic ou une IA** dans un commit (message, titre, body, footer, trailer) ou une PR (titre, description). Concretement, aucun des elements suivants ne doit apparaitre :
+  - Trailer `Co-Authored-By: Claude <...>` / `Co-Authored-By: Anthropic`
+  - Footer type `Generated with Claude Code`, `Generated by AI`, etc.
+  - Emoji robot `🤖` ou similaire en tete/fin de message
+  - Toute phrase attribuant la paternite du changement a une IA
+  Les commits sont signes **uniquement** par l'utilisateur. Si un hook ou un template ajoute ces elements automatiquement, les retirer manuellement avant push.
+
+## Versioning & tags
+
+La version de l'app est dans `config/version.yaml` (parametre `app.version`).
+
+Workflow de release :
+1. Bump `config/version.yaml` a la nouvelle version
+2. Commit dedie : `chore : bump version to v<X.Y.Z>`
+3. Tag : `git tag v<X.Y.Z>`
+4. Push : `git push origin develop --tags`
+
+**A chaque creation de tag**, toujours mettre a jour `config/version.yaml` avec la meme version — sinon l'app ne connait pas sa propre version.
+
+CI Gitea automatise le bump sur push `develop` (cf. `.gitea/workflows/`), mais un tag manuel reste possible.

.claude/rules/naming.md

@@ -0,0 +1,18 @@
+# Nommage
+
+| Element | Convention | Exemple |
+|---------|-----------|---------|
+| Module back | PascalCase | `Module/Commercial/` |
+| Module front | kebab-case | `modules/commercial/` |
+| Module ID (dans code/config) | snake_case | `commercial`, `gestion_rh` |
+| Entity Doctrine | PascalCase singulier | `User.php` |
+| Repository interface | `*RepositoryInterface` | `UserRepositoryInterface.php` |
+| Repository impl Doctrine | `Doctrine*Repository` | `DoctrineUserRepository.php` |
+| DTO | `*Output` / `*Input` | `UserOutput.php` |
+| API Platform Resource | classe dans `Infrastructure/ApiPlatform/Resource/` | `UserResource.php` |
+| API Platform Provider | `*Provider` | `MeProvider.php` |
+| API Platform Processor | `*Processor` | `UserPasswordHasherProcessor.php` |
+| Module declaration back | `*Module.php` | `CommercialModule.php` |
+| Composable front | `use*` | `useSidebar.ts` |
+| Cles i18n sidebar | `sidebar.<module>.*` | `sidebar.commercial.overview` |
+| Permission RBAC | `module.resource[.subresource].action` | `core.users.view`, `commercial.clients.contacts.edit` |

.claude/rules/testing.md

@@ -0,0 +1,36 @@
+# Tests
+
+## Trois suites
+
+| Suite | Commande | Outil | Where |
+|---|---|---|---|
+| Back | `make test` | PHPUnit | Container PHP ; fixtures dediees sous `tests/Fixtures/` |
+| Front unitaire | `make nuxt-test` | Vitest (happy-dom) | Container Node ; <30s ; composables/utils/stores |
+| Front E2E | `make test-e2e` | Playwright | **Host** (pas container, navigateur reel requis) |
+
+Bootstrap E2E (une fois par poste de dev) : `make install-e2e-deps` (Chromium + libs systeme, sudo).
+Re-run uniquement si `@playwright/test` upgrade majeur.
+
+Workflow E2E : `make start && make seed-e2e && make dev-nuxt` (terminal 1), `make test-e2e` (terminal 2).
+UI interactive pour debug : `make test-e2e-ui`.
+
+## Regle d'or E2E
+
+**Un nouveau test E2E ne s'ajoute QUE si un bug critique est passe en prod.**
+
+Sinon, la bonne place est un test unitaire Vitest :
+- Plus rapide
+- Plus stable
+- Moins de faux positifs
+
+Pour etendre la couverture RBAC, etendre un **persona existant** dans `frontend/tests/e2e/_fixtures/personas.ts` plutot que de creer un nouveau test.
+
+## Matrice RBAC — 3 endroits obligatoires
+
+Ajouter/modifier une permission testable = toucher les 3 miroirs (sinon drift garanti) :
+
+1. `config/sidebar.php` — attacher `permission` au bon item
+2. `frontend/tests/e2e/_fixtures/personas.ts` — ajuster `permissions` + `expectedAdminLinks` d'un persona existant
+3. `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php` — miroir back du meme persona
+
+Tout changement sur l'un des trois sans les deux autres = test casse ou faux positif.

.claude/rules/workflow.md

@@ -0,0 +1,66 @@
+# Workflow
+
+## Langue
+
+- **UI** : francais (tout ce qui est visible utilisateur)
+- **Communication avec l'utilisateur** : francais
+- **Code** (noms de classes, methodes, variables, types) : anglais
+- **Commentaires** (PHP, TS, Vue — docblock, inline, bloc) : **francais**. Objectif : faciliter la relecture par l'equipe FR sans polluer l'API publique du code
+
+## Delegation Codex
+
+Pour les taches mecaniques (generation de tests boilerplate, renommages massifs, refacto repetitif, scaffolding), **deleguer a Codex** via le plugin `codex` (skill `codex:rescue`).
+
+- **Codex** = junior rapide et pas cher → executions mecaniques
+- **Claude** = senior qui verifie et reflechit → design, review, decisions
+
+Ratio qualite/credits optimal : Claude conserve la reflexion et la validation, Codex avale le boilerplate.
+
+## Avant d'implementer un ticket
+
+Les specs fonctionnelles vivent sous `docs/{rbac,sites,modules}/ticket-*-spec.md`.
+
+Avant de coder :
+1. Lire la spec correspondante en entier (elles sont longues mais exhaustives)
+2. Ne pas inventer de detail non specifie — demander a l'utilisateur ou citer explicitement la section manquante
+3. Si la spec contredit le code existant, poser la question avant de choisir
+
+## Verification avant "c'est fini"
+
+Ne jamais declarer une tache terminee sans avoir lance les verifications applicables :
+
+| Ce qui a bouge | Commande a lancer |
+|---|---|
+| Fichiers PHP | `make test` + `make php-cs-fixer-allow-risky` |
+| Fichiers front (Vue/TS) | `make nuxt-test` |
+| Migrations | `make migration-migrate` (sur BDD fraiche ideal : `make db-reset`) |
+| Sidebar / permissions | Verifier que les 3 miroirs RBAC sont alignes (cf. @.claude/rules/testing.md) |
+| UI visible | Demarrer `make dev-nuxt` et verifier le golden path dans le navigateur |
+
+Si une verification echoue ou ne peut pas etre lancee (ex : container pas demarre), le dire explicitement plutot que d'annoncer "fini".
+
+## Time tracking Lesstime
+
+Au demarrage de toute tache de dev sur Starseed, creer une time entry via l'API Lesstime (cf. `~/.claude/CLAUDE.md` pour la procedure complete).
+- Projet : `/api/projects/6` (STARSEED)
+- Tags : choisir selon le type (Backend `3`, Frontend `2`, Infra `5`, UI/UX `4`, Maintenance `6`, Gestion projet `9`, etc.)
+
+## Fix `make cache-clear` (permissions `var/`)
+
+Si `make cache-clear` echoue sur les permissions de `var/` :
+
+```bash
+docker exec -t -u root php-starseed-fpm chown -R www-data:www-data /var/www/html/var
+docker exec -t -u www-data php-starseed-fpm php bin/console cache:clear
+```
+
+A terme : integrer ce fix dans le `makefile` lui-meme.
+
+## Docker — references utiles
+
+- Container PHP : `php-starseed-fpm`
+- Container Nginx : `nginx-starseed` (port 8083)
+- Container DB : PostgreSQL port **5437** (interne et externe)
+- Config dev : `infra/dev/.env.docker` (override local : `infra/dev/.env.docker.local`)
+- Config prod : `infra/prod/` (Dockerfile multi-stage, `docker-compose.prod.yml`)
+- Apres modif nginx : `docker restart nginx-starseed`

.claude/skills/backend-entity-conventions/SKILL.md

@@ -0,0 +1,251 @@
+---
+name: backend-entity-conventions
+description: Conventions détaillées des entités métier Starseed (back PHP/Symfony/API Platform) — messages de validation FR sur les contraintes, pagination API Platform et providers ORM/DBAL, libellé i18n du type d'entité auditée, Timestampable/Blamable, COMMENT ON COLUMN des migrations. Charger dès qu'on crée ou modifie une entité Domain, un ApiResource, un Provider/Processor, une contrainte de validation, ou une migration Doctrine. Le résumé court de chaque règle (+ nom du test garde-fou) reste dans .claude/rules/backend.md ; ce skill porte les patterns, tableaux et exemples complets.
+---
+
+# Conventions entités métier — détail
+
+Ce skill contient le détail (patterns code, tableaux, dérivations) des 5 règles back qui ont chacune
+un test Architecture déterministe. L'énoncé court de chaque règle vit dans `.claude/rules/backend.md`
+(chargé à chaque session) ; ici on trouve le « comment » complet.
+
+> Règle d'or : le **test Architecture reste le juge** (il casse `make test`). Ce skill aide à écrire
+> le code juste du premier coup, il ne remplace pas le garde-fou.
+
+---
+
+## 1. Messages de validation (Garde-fou : `EntityConstraintsHaveFrenchMessageTest`)
+
+**Toute contrainte `#[Assert\*]` portée par une entité métier doit avoir un message FR explicite**, et
+**`Assert\Length.max` doit refléter le `length` de la colonne ORM**. C'est le pendant back du mapping
+d'erreur par champ côté front (ERP-101 : `useFormErrors` / `mapViolationsToRecord` affiche sous chaque
+champ le `message` renvoyé par le back).
+
+Pourquoi :
+- Sans `message:` explicite, Symfony renvoie le défaut **anglais** (« This value is not a valid email
+  address. »). La locale FR globale (`default_locale: fr` dans `framework.yaml`) sert de FILET via
+  `validators.fr.xlf`, mais les contraintes métier portent en plus leur message FR pour un contrôle total.
+- Une colonne string bornée **sans `Assert\Length`** échoue au niveau Postgres (500 générique, non
+  rattachée au champ) au lieu d'une 422 propre. Le `max` doit égaler le `length` ORM (anti-dérive).
+
+Pattern par champ scalaire :
+
+```php
+// Email métier
+#[Assert\Email(message: 'L\'adresse email n\'est pas valide.')]
+
+// Longueur calée sur la colonne (VARCHAR(120))
+#[ORM\Column(length: 120)]
+#[Assert\Length(max: 120, maxMessage: 'Le nom ne peut dépasser {{ limit }} caractères.', normalizer: 'trim')]
+
+// Obligatoire (aligner nullable DB / NotBlank back / required front)
+#[Assert\NotBlank(message: 'Le téléphone est obligatoire.', normalizer: 'trim')]
+```
+
+Cohérence à 3 niveaux pour un champ obligatoire : colonne `nullable` (DB) <-> `Assert\NotBlank` (back)
+<-> `:required` + astérisque (front ERP-101). Les trois doivent s'accorder.
+
+Exceptions au miroir `Length` : un format déjà borné par `Assert\Bic` / `Assert\Iban` (longueur
+garantie) ou par un `Assert\Regex` borné (ex. code postal `{4,5}`, couleur hex `#RRGGBB`) — whitelister
+alors la propriété dans `EntityConstraintsHaveFrenchMessageTest::EXCLUDED_LENGTH_MIRROR` avec justification.
+
+Les règles inter-champs (RG métier : exclusivité distributor/broker RG-1.03, billingEmail RG-1.11, etc.)
+passent par un `#[Assert\Callback]` qui construit la violation avec `->atPath('<champ>')` — indispensable
+pour que le front la mappe en inline plutôt qu'en toast.
+
+### Garde-fou architecture
+
+`tests/Architecture/EntityConstraintsHaveFrenchMessageTest` scanne réflexivement les entités sous
+`src/Module/*/Domain/Entity/` et échoue si :
+1. une contrainte connue n'a pas de message FR explicite (comparé au défaut Symfony) ;
+2. une colonne string bornée writable n'a pas de `Assert\Length(max == ORM length)` (hors whitelist).
+
+Une contrainte non gérée par le mapping du test le fait échouer : il faut l'ajouter explicitement
+(anti faux positif vert).
+
+---
+
+## 2. Pagination (Garde-fou : `CollectionsArePaginatedTest`)
+
+**Règle** : toute collection API DOIT être paginée. Aucun retour de collection complète côté serveur.
+
+### Standard global
+
+Posé dans `config/packages/api_platform.yaml` (section `defaults:`) et hérité par toutes les ressources :
+
+| Clé | Valeur | Effet |
+|---|---|---|
+| `pagination_enabled` | `true` | Pagination Hydra active par défaut. |
+| `pagination_items_per_page` | `10` | Taille de page par défaut, alignée sur l'UI `MalioDataTable`. |
+| `pagination_maximum_items_per_page` | `50` | Borne dure : `?itemsPerPage=999` → ramené à 50. Anti deep-fetch. |
+| `pagination_client_items_per_page` | `true` | Le client peut envoyer `?itemsPerPage=25` (bornée par le max). |
+| `pagination_client_enabled` | `true` | Le client peut envoyer `?pagination=false` pour TOUT récupérer (échappatoire selects). |
+
+### Override par ressource (rare)
+
+Si une ressource a besoin d'un autre défaut (ex: payload lourd), utiliser les attributs sur l'opération.
+**JAMAIS `paginationEnabled: false`** sans whitelist explicite dans
+`tests/Architecture/CollectionsArePaginatedTest::EXCLUDED`.
+
+```php
+new GetCollection(
+    paginationItemsPerPage: 5,           // override taille par défaut
+    paginationMaximumItemsPerPage: 20,   // override borne max
+)
+```
+
+### Selects et autocomplétions
+
+Pour alimenter un `<select>` ou un drawer RBAC (Role, Permission, Site, CategoryType), le front passe :
+
+```ts
+useApi().get('/api/roles?pagination=false')
+```
+
+Le serveur retourne toute la collection, sans `view`. C'est l'échappatoire prévue par
+`pagination_client_enabled: true`. Sur les ressources à forte volumétrie, préférer une saisie assistée
+(recherche serveur via `?q=`) — à planifier dans un ticket dédié.
+
+Les tests fonctionnels qui exercent ce comportement doivent également passer `?pagination=false`
+(cf. `CategoryListTest`, `PermissionApiTest`).
+
+### Providers customs et pagination
+
+Un provider custom qui retourne un `array` brut sur une `CollectionOperationInterface`
+**court-circuite la pagination Hydra** (pas de `totalItems`, pas de `view`). Patterns supportés :
+
+- **ORM** : injecter `ApiPlatform\State\Pagination\Pagination`, wrap un
+  `Doctrine\ORM\Tools\Pagination\Paginator` dans `ApiPlatform\Doctrine\Orm\Paginator`. Exemple : `CategoryProvider`.
+- **DBAL** : implémenter un paginator local conforme à `PaginatorInterface`. Exemple : `DbalPaginator`
+  (Core) + `AuditLogProvider`.
+
+Gérer l'échappatoire `?pagination=false` :
+
+```php
+if (!$this->pagination->isEnabled($operation, $context)) {
+    return $qb->getQuery()->getResult(); // tout retourner
+}
+```
+
+### Garde-fou architecture
+
+`tests/Architecture/CollectionsArePaginatedTest` scanne réflexivement toutes les classes
+`#[ApiResource]` sous `src/` et échoue si une `GetCollection` pose `paginationEnabled: false` hors
+whitelist `EXCLUDED`. Ajouter une entrée à la whitelist requiert une justification courte + un ticket
+Lesstime ouvert.
+
+---
+
+## 3. Libellé i18n du type d'entité auditée (Garde-fou : `AuditableEntitiesHaveI18nLabelTest`)
+
+**Toute entité `#[Auditable]` doit avoir son libellé FR dans le bloc `audit.entity` de
+`frontend/i18n/locales/fr.json`.** C'est la contrepartie i18n de l'attribut : sans elle, le filtre
+« Type d'entité » de l'audit-log affiche le type technique brut (ex: `commercial.Client`) au lieu d'un
+libellé lisible.
+
+Pourquoi : le filtre est dynamique (`GET /audit-log-entity-types` renvoie les `entity_type` distincts
+présents en base) ; dès qu'un module audite une entité, son type y apparaît. Le front
+(`formatEntityType`, `audit-log.vue`) construit la clé `audit.entity.<module>_<entity>` et, faute de
+traduction, **retombe silencieusement** sur le type brut.
+
+Dérivation de la clé (emplacement centralisé + schéma flat — décision ERP-99) :
+
+| FQCN entité | `entity_type` (back) | Clé i18n (flat) |
+|---|---|---|
+| `App\Module\Commercial\Domain\Entity\Client` | `commercial.Client` | `commercial_client` |
+| `App\Module\Commercial\Domain\Entity\ClientAddress` | `commercial.ClientAddress` | `commercial_clientaddress` |
+| `App\Module\Catalog\Domain\Entity\Category` | `catalog.Category` | `catalog_category` |
+
+Règle : `strtolower(module)` + `_` + `strtolower(Entity)`. Ajouter sa clé de libellé audit fait partie
+de la **définition de fini** d'une entité métier auditée.
+
+**Garde-fou** : `tests/Architecture/AuditableEntitiesHaveI18nLabelTest` scanne les entités `#[Auditable]`
+et échoue si une seule n'a pas sa clé `audit.entity.*`. Conclusion : créer une entité `#[Auditable]`
+sans son libellé i18n casse `make test`.
+
+---
+
+## 4. Timestampable + Blamable (Garde-fou : `EntitiesAreTimestampableBlamableTest`)
+
+Toute **nouvelle** entité métier sous `src/Module/*/Domain/Entity/` doit porter les 4 colonnes
+`created_at` / `updated_at` / `created_by` / `updated_by`, remplies automatiquement. Trois lignes à
+ajouter à l'entité :
+
+```php
+use App\Shared\Domain\Contract\BlamableInterface;
+use App\Shared\Domain\Contract\TimestampableInterface;
+use App\Shared\Domain\Trait\TimestampableBlamableTrait;
+
+class MyEntity implements TimestampableInterface, BlamableInterface
+{
+    use TimestampableBlamableTrait; // porte les 4 props + getters/setters
+    // ... reste métier
+}
+```
+
+- Le `TimestampableBlamableSubscriber` (`Shared/Infrastructure/Doctrine/`) remplit les colonnes au
+  `prePersist` / `preUpdate`. Hors contexte HTTP (CLI, cron, migration), le blame reste `null`
+  (libellé « Système » côté front).
+- La migration de l'entité doit créer les 4 colonnes (`created_at` / `updated_at` NOT NULL,
+  `created_by` / `updated_by` nullable `ON DELETE SET NULL`).
+- **Garde-fou CI** : `tests/Architecture/EntitiesAreTimestampableBlamableTest` échoue si une entité
+  oublie le pattern. Un référentiel statique justifié (ex: `CategoryType`) doit être explicitement
+  whitelisté dans la constante `EXCLUDED` avec un commentaire.
+- Spec complète : @docs/specs/M0-categories/spec-back.md § 2.8 + § 2.8.bis
+
+---
+
+## 5. Migrations Doctrine — COMMENT ON COLUMN (Garde-fou : `ColumnsHaveSqlCommentTest`)
+
+**Toute migration qui crée ou modifie une colonne d'une table métier doit poser un `COMMENT ON COLUMN`
+décrivant le champ.** La description est stockée dans `pg_description` et visible dans tous les outils
+d'admin BDD (DBeaver, DataGrip, pgAdmin), sans avoir à lire les annotations PHP.
+
+**Format de la description** :
+- En français
+- ≤ 200 caractères
+- Sémantique du champ — contraintes / lien RG si pertinent
+- Pour les colonnes d'identifiant ou FK, mentionner la cible
+
+Exemples :
+
+```php
+// Migration : création d'une colonne avec son commentaire dans la même migration
+$this->addSql("ALTER TABLE client ADD COLUMN siren VARCHAR(9) DEFAULT NULL");
+$this->addSql("COMMENT ON COLUMN client.siren IS 'SIREN (9 chiffres) — identifiant legal entreprise. Unique parmi non-archives (RG-1.15).'");
+
+// Cas FK : préciser la cible
+$this->addSql("COMMENT ON COLUMN client.legal_form_id IS 'Reference forme juridique (SARL, SAS, SA...) — FK -> legal_form.id, ON DELETE RESTRICT.'");
+
+// Cas booléen : préciser le sens et la valeur par défaut
+$this->addSql("COMMENT ON COLUMN user.is_admin IS 'Drapeau super-administrateur — bypass complet RBAC. Faux par defaut.'");
+
+// Bonus : décrire la table elle-même
+$this->addSql("COMMENT ON TABLE client IS 'Repertoire clients (M1 Commercial) — entites archivables.'");
+```
+
+### Helper Timestampable/Blamable
+
+Les 4 colonnes `created_at`, `updated_at`, `created_by`, `updated_by` ajoutées par
+`TimestampableBlamableTrait` reçoivent une description **standardisée** via le helper centralisé pour
+éviter la duplication. Helper à créer ou appeler :
+
+```php
+// Dans la migration, après avoir ajouté les 4 colonnes :
+$this->addStandardTimestampableBlamableComments($schema, 'client');
+```
+
+L'implémentation du helper applique :
+- `created_at` : « Horodatage de creation de la ligne (UTC, rempli automatiquement par TimestampableBlamableSubscriber). »
+- `updated_at` : « Horodatage de derniere modification de la ligne (UTC, rempli automatiquement par TimestampableBlamableSubscriber). »
+- `created_by` : « ID de l'utilisateur ayant cree la ligne — null pour les creations hors HTTP (CLI, migration, fixture). FK -> user.id, ON DELETE SET NULL. »
+- `updated_by` : « ID de l'utilisateur ayant modifie la ligne en dernier — null pour les modifications hors HTTP. FK -> user.id, ON DELETE SET NULL. »
+
+### Garde-fou architecture
+
+`tests/Architecture/ColumnsHaveSqlCommentTest` parcourt `information_schema.columns` filtré sur le
+schéma `public` et échoue si **une seule colonne** n'a pas de `col_description`. Seules les tables
+système (`doctrine_migration_versions`) et la whitelist `EXCLUDED_TABLES` explicite (commentaire de
+justification + ticket Lesstime ouvert pour le retrofit) sont tolérées.
+
+Conclusion : si tu crées une colonne sans poser son `COMMENT ON COLUMN`, `make test` casse en CI.

.claude/skills/create-module/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: create-module
-description: Scaffold a new Coltura module (backend + frontend) and optionally wire its entries into the sidebar config. Use when the user asks to create, add, scaffold, or generate a new module — e.g., "crée un module Paie", "add a Pointage module", "ajoute un module RH". The backend is the source of truth for activation and sidebar layout; the frontend scans modules automatically.
+description: Scaffold a new Starseed module (backend + frontend) and optionally wire its entries into the sidebar config. Use when the user asks to create, add, scaffold, or generate a new module — e.g., "crée un module Paie", "add a Pointage module", "ajoute un module RH". The backend is the source of truth for activation and sidebar layout; the frontend scans modules automatically.
 ---
 
-# Create a new Coltura module
+# Create a new Starseed module
 
-Scaffolds a new module across backend and frontend following Coltura's modular monolith DDD architecture.
+Scaffolds a new module across backend and frontend following Starseed's modular monolith DDD architecture.
 
 ## Architecture reminder — read before acting
 
@@ -178,8 +178,8 @@ Execute in this exact order:
 6. **Backend: sidebar** — if the user wants sidebar entries, edit `config/sidebar.php`.
 7. **Frontend: translations** — edit `frontend/i18n/locales/fr.json`.
 8. **Verify** — run:
-   - `docker exec -t -u root php-coltura-fpm chown -R www-data:www-data /var/www/html/var` (avoid permission issues)
-   - `docker exec -t -u www-data php-coltura-fpm php bin/console cache:clear` (validates backend)
+   - `docker exec -t -u root php-starseed-fpm chown -R www-data:www-data /var/www/html/var` (avoid permission issues)
+   - `docker exec -t -u www-data php-starseed-fpm php bin/console cache:clear` (validates backend)
    - `cd frontend && npx nuxi prepare` (validates Nuxt auto-detection of the new layer)
 9. **Report** — list files created, the route(s) to test, and the sidebar items added.
 

.dockerignore

@@ -0,0 +1 @@
+src/Module/Core/Infrastructure/Console/SeedE2ECommand.php

.gitea/workflows/build-docker.yml

@@ -20,11 +20,11 @@ jobs:
         run: |
           docker build \
             -f infra/prod/Dockerfile \
-            -t gitea.malio.fr/malio-dev/coltura:${{ gitea.ref_name }} \
-            -t gitea.malio.fr/malio-dev/coltura:latest \
+            -t gitea.malio.fr/malio-dev/starseed:${{ gitea.ref_name }} \
+            -t gitea.malio.fr/malio-dev/starseed:latest \
             .
 
       - name: Push Docker image
         run: |
-          docker push gitea.malio.fr/malio-dev/coltura:${{ gitea.ref_name }}
-          docker push gitea.malio.fr/malio-dev/coltura:latest
+          docker push gitea.malio.fr/malio-dev/starseed:${{ gitea.ref_name }}
+          docker push gitea.malio.fr/malio-dev/starseed:latest

.gitea/workflows/pull-request.yml

@@ -0,0 +1,131 @@
+name: Pull Request — Quality gate
+
+# Lance les tests + lint + build sur chaque PR ciblant develop.
+# Deux jobs en parallele (backend / frontend) pour reduire le temps de feedback.
+# E2E volontairement hors scope (cf. regle d'or testing.md).
+
+on:
+  pull_request:
+    branches:
+      - develop
+
+# Annule les runs obsoletes quand on repush sur la meme PR.
+concurrency:
+  group: pr-${{ gitea.event.pull_request.number }}
+  cancel-in-progress: true
+
+jobs:
+  backend:
+    name: Backend (PHP CS + PHPUnit)
+    runs-on: ubuntu-latest
+
+    services:
+      postgres:
+        image: postgres:16-alpine
+        env:
+          # Doivent matcher la DATABASE_URL ci-dessous. Le suffixe `_test`
+          # est applique automatiquement par Doctrine en APP_ENV=test.
+          POSTGRES_USER: app
+          POSTGRES_PASSWORD: '!ChangeMe!'
+          POSTGRES_DB: app
+        # Pas de `ports:` host mapping — le runner partage l'hote avec la
+        # prod (Postgres deja sur 5432) et les jobs Gitea Actions tournent
+        # en container sur un reseau Docker dedie : le service est joignable
+        # via son nom (`postgres`), pas via 127.0.0.1.
+        options: >-
+          --health-cmd "pg_isready -U app"
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 10
+
+    env:
+      APP_ENV: test
+      APP_SECRET: ci-secret-not-used
+      APP_DEBUG: 0
+      DEFAULT_URI: http://localhost/
+      DATABASE_URL: postgresql://app:!ChangeMe!@postgres:5432/app?serverVersion=16&charset=utf8
+      JWT_SECRET_KEY: '%kernel.project_dir%/config/jwt/private.pem'
+      JWT_PUBLIC_KEY: '%kernel.project_dir%/config/jwt/public.pem'
+      JWT_PASSPHRASE: change_me_in_env_local
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Setup PHP 8.4
+        uses: shivammathur/setup-php@v2
+        with:
+          php-version: '8.4'
+          extensions: pdo, pdo_pgsql, intl, opcache, zip, mbstring, sodium
+          coverage: none
+          tools: composer:v2
+
+      # Cache Composer retire : meme cause que cote front — le backend de cache
+      # du runner Gitea est injoignable (ETIMEDOUT) et fait timeouter le step
+      # ~4 min 30. A re-activer si le serveur de cache du runner est repare.
+      - name: Install PHP dependencies
+        run: composer install --no-interaction --no-progress --prefer-dist
+
+      - name: Generate JWT keypair
+        run: php bin/console lexik:jwt:generate-keypair --skip-if-exists --no-interaction
+
+      - name: PHP CS Fixer (dry-run)
+        run: vendor/bin/php-cs-fixer fix --config=.php-cs-fixer.dist.php --allow-risky=yes --dry-run --diff
+
+      - name: Bootstrap test database
+        # Aligne sur la cible `test-db-setup` du makefile : apres
+        # `schema:update --force`, on RECREE manuellement l'index unique
+        # partiel `uq_category_name_active` car Doctrine ORM ne sait
+        # pas exprimer les index fonctionnels partiels (LOWER(name) + WHERE
+        # deleted_at IS NULL) et `schema:update` les considere comme
+        # orphelins et les DROP — collisions non detectees, tests d'unicite
+        # qui attendent 409 recoivent 201.
+        run: |
+          php bin/console doctrine:database:create --env=test --if-not-exists --no-interaction
+          php bin/console doctrine:migrations:migrate --env=test --no-interaction
+          php bin/console doctrine:schema:update --env=test --force --no-interaction
+          # Rejoue le catalogue COMMENT ON apres schema:update (cf. ERP-67) :
+          # schema:update drop les commentaires des tables managees par l'ORM.
+          php bin/console app:apply-column-comments --env=test --no-interaction
+          php bin/console doctrine:fixtures:load --env=test --no-interaction
+          php bin/console app:sync-permissions --env=test --no-interaction
+          php bin/console --env=test dbal:run-sql "CREATE UNIQUE INDEX IF NOT EXISTS uq_category_name_active ON category (LOWER(name)) WHERE deleted_at IS NULL"
+
+      - name: Run PHPUnit
+        run: php -d memory_limit=512M vendor/bin/phpunit
+
+  frontend:
+    name: Frontend (lint + Vitest + build)
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: frontend
+
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      # Pas de `cache: npm` : le backend de cache du runner Gitea est injoignable
+      # (ETIMEDOUT) et chaque tentative de restauration attend ~4 min 30 avant de
+      # timeout — c'est ce qui plombait le job. Node 22 est deja dans le
+      # tool-cache du runner (install instantane), et `npm ci` a froid ne prend
+      # que ~30s. A re-activer si le serveur de cache du runner est repare.
+      - name: Setup Node 22
+        uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+
+      - name: Install Node dependencies
+        run: npm ci
+
+      - name: ESLint
+        run: npm run lint
+
+      - name: Unit tests (Vitest)
+        run: npm run test
+
+      # `nuxt build` (et non `build:dist`/`nuxt generate`) : l'app est en SSR off
+      # (SPA), le prerender de generate n'apporte rien a une quality gate — on
+      # veut seulement valider que le bundle compile.
+      - name: Build production (nuxt build)
+        run: npm run build

.gitignore

@@ -3,6 +3,7 @@
 /.env.local.php
 /.env.*.local
 /config/secrets/dev/dev.decrypt.private.php
+/config/reference.php
 /public/bundles/
 /var/
 /vendor/
@@ -29,6 +30,13 @@ frontend/.output/
 frontend/dist/
 ###< frontend ###
 
+###> playwright ###
+frontend/test-results/
+frontend/playwright-report/
+frontend/blob-report/
+frontend/playwright/.cache/
+###< playwright ###
+
 ###> docker ###
 infra/dev/.env.docker.local
 ###< docker ###
@@ -36,3 +44,12 @@ infra/dev/.env.docker.local
 ###> logs ###
 LOG/
 ###< logs ###
+
+###> friendsofphp/php-cs-fixer ###
+/.php-cs-fixer.php
+/.php-cs-fixer.cache
+###< friendsofphp/php-cs-fixer ###
+
+###> symfony auto-generated ###
+/config/reference.php
+###< symfony auto-generated ###

CHANGELOG.md

@@ -1,6 +1,6 @@
 # Changelog
 
-Liste des évolutions du projet Coltura
+Liste des évolutions du projet Starseed
 
 ## [0.0.0]
 

CLAUDE.md

@@ -1,277 +1,74 @@
-# Coltura
+# Starseed
 
-CRM/ERP. Monorepo Symfony 8 (API Platform 4) + Nuxt 4. **Architecture Modular Monolith DDD.**
+## Contexte
+CRM/ERP en architecture **modular monolith DDD**. Le backend est la source de verite unique (modules actifs, sidebar). Le frontend scanne `frontend/modules/*/` comme layers Nuxt et consomme l'API pour la navigation. Multi-tenant : chaque module est activable/desactivable.
 
-## Architecture Modulaire
-
-Le projet suit une architecture **modular monolith** pilotee par le backend : chaque module metier est un bounded context autonome, activable/desactivable par tenant. Le module `Core` est obligatoire.
-
-**Principe fondamental : le backend est la source de verite unique.**
-- Le backend dicte quels modules sont actifs (`config/modules.php`).
-- Le backend dicte l'organisation de la sidebar (`config/sidebar.php`), decouplee des modules eux-memes.
-- Le frontend ne connait rien : il scanne automatiquement les modules comme layers Nuxt et demande la sidebar au backend.
-
-### Backend — Organisation par module
-
-```
-src/
-  Kernel.php
-  Shared/                           # Noyau technique partage
-    Domain/
-      ValueObject/                  # VO de base (Email...)
-      Event/                        # DomainEventInterface
-      Contract/                     # Interfaces inter-modules (UserResolverInterface, TenantAwareInterface)
-    Application/
-      Bus/                          # CommandBusInterface, QueryBusInterface (interfaces seules)
-    Infrastructure/
-      ApiPlatform/
-        Resource/                   # AppVersion, ModulesResource, SidebarResource
-        State/                      # AppVersionProvider, ModulesProvider, SidebarProvider
-  Module/
-    Core/                           # Module obligatoire (auth, users)
-      CoreModule.php                # Declaration (ID, LABEL, REQUIRED)
-      Domain/
-        Entity/                     # Entites Doctrine + API Platform (User)
-        Repository/                 # Interfaces repositories (UserRepositoryInterface)
-        Event/                      # Domain events (UserCreated)
-      Application/
-        DTO/                        # UserOutput
-      Infrastructure/
-        Doctrine/                   # DoctrineUserRepository, Migrations/
-        ApiPlatform/
-          State/
-            Provider/               # MeProvider
-            Processor/              # UserPasswordHasherProcessor
-        Console/                    # CreateUserCommand
-        DataFixtures/               # AppFixtures
-    Commercial/                     # Autre module (exemple)
-      CommercialModule.php
-config/
-  modules.php                       # Liste des modules actifs (source de verite activation)
-  sidebar.php                       # Structure de la sidebar (source de verite navigation)
-  version.yaml
-  jwt/                              # Cles JWT
-  packages/                         # Config Symfony
-migrations/                         # Anciennes migrations Doctrine
-infra/dev/                          # Docker dev
-infra/prod/                         # Docker prod (multi-stage)
-```
-
-### Frontend — Organisation modulaire (auto-detectee)
-
-```
-frontend/
-  app/                              # Shell applicatif
-    layouts/                        # default.vue, auth.vue
-    middleware/                     # auth.global.ts, modules.global.ts
-  shared/                           # Code partage (hors modules)
-    composables/                    # useApi, useAppVersion, useSidebar
-    components/ui/                  # AppTopNav, ...
-    stores/                         # auth, ui
-    services/                       # auth
-    types/                          # SidebarSection, SidebarItem, UserData
-    utils/                          # api (Hydra)
-  modules/                          # Modules auto-detectes comme layers Nuxt
-    core/
-      nuxt.config.ts                # Marqueur layer (vide)
-      pages/                        # index.vue, login.vue
-    commercial/
-      nuxt.config.ts
-      pages/                        # commercial.vue
-  app.vue                           # Composant racine
-  nuxt.config.ts                    # Scanne modules/*/ automatiquement
-  i18n/locales/                     # Traductions (cles sidebar.*, etc.)
-  assets/                           # CSS, images
-  public/                           # Fichiers statiques
-```
-
-### Endpoints API cles
-
-- `GET /api/version` (public) — version de l'app
-- `GET /api/modules` (public) — liste des IDs de modules actifs
-- `GET /api/sidebar` (public) — sections de la sidebar + `disabledRoutes`
-  - Filtre automatiquement les items dont le `module` owner n'est pas actif
-  - Les sections vides apres filtrage sont supprimees
-  - `disabledRoutes` = `to` des items filtres (utilise par le middleware front)
-- `GET /api/me` (auth) — user courant
-
-### Flux d'activation/desactivation d'un module
-
-Pour activer/desactiver un module, tu touches **uniquement** `config/modules.php` :
-
-```php
-return [
-    \App\Module\Core\CoreModule::class,
-    // \App\Module\Commercial\CommercialModule::class,  // commente = desactive
-];
-```
-
-Cascade automatique :
-1. `GET /api/modules` ne retourne plus `commercial`
-2. `GET /api/sidebar` filtre les items `module: 'commercial'` → section "Commercial" disparait, ses routes passent dans `disabledRoutes`
-3. Frontend : sidebar se met a jour, middleware `modules.global.ts` redirige toute navigation vers `/commercial` ou `/commercial/*`
-4. Le code du module reste dans le bundle Nuxt (layer auto-detecte) → reactivation instantanee sans rebuild
-
-### Reorganiser la sidebar sans toucher aux modules
-
-Pour deplacer un item (ex: "Commandes fournisseurs") d'une section a une autre, tu edites juste `config/sidebar.php` :
-
-```php
-// Avant : sous Commercial
-['label' => 'sidebar.commercial.suppliers', 'to' => '/commercial/suppliers', 'module' => 'commercial'],
-
-// Apres : sous Production (l'item reste "owned" par Commercial, seule sa place change)
-[
-    'label' => 'sidebar.production.section',
-    'items' => [
-        ['label' => 'sidebar.commercial.suppliers', 'to' => '/commercial/suppliers', 'module' => 'commercial'],
-    ],
-],
-```
-
-Le code du module Commercial n'est pas touche.
-
-### Regles d'architecture
-
-**Backend :**
-- Le domaine (`Domain/`) peut garder les attributs ORM (approche pragmatique) mais les repositories sont des interfaces
-- Communication inter-modules par `Shared/Domain/Contract/` ou domain events — jamais d'import direct entre modules
-- Chaque module declare un `*Module.php` avec `ID`, `LABEL`, `REQUIRED`
-- `config/modules.php` = seule source de verite pour l'activation
-- `config/sidebar.php` = seule source de verite pour l'organisation de la sidebar (chaque item reference son module owner via la cle `module`)
-- Migrations par module dans `src/Module/{Module}/Infrastructure/Doctrine/Migrations/`
-- **Exception connue** : avec plusieurs `migrations_paths` configures, Doctrine Migrations 3.x trie les migrations par FQCN alphabetique et non par version timestamp → ordre d'execution incorrect entre namespaces sur une base vide. Tant que ce n'est pas resolu (via un `MigrationsComparator` custom ou un upgrade), les migrations d'initialisation critiques (setup user, RBAC, etc.) vivent au namespace racine `DoctrineMigrations` dans `migrations/`. Le namespace modulaire reste configure pour les futures migrations applicatives (qui dependent d'un schema deja cree).
-
-**Frontend :**
-- Chaque module est un layer Nuxt auto-detecte (`modules/*/nuxt.config.ts` minimal)
-- Un module front ne doit pas importer depuis un autre module — utiliser `shared/`
-- `useSidebar()` fetch `/api/sidebar` et expose `sections`, `disabledRoutes`, `isRouteDisabled()`
-- Le layout `default.vue` itere sur les sections retournees par l'API, applique `t()` sur les labels
-- Middleware `auth.global.ts` charge la sidebar apres authentification
-- Middleware `modules.global.ts` redirige si la route demandee est dans `disabledRoutes`
-- Les composables avec state singleton (refs module-level) doivent exposer une fonction `reset*()` et etre reinitialises au logout (ex: `useSidebar().resetSidebar()`)
-- **Interdit** : `.module.ts`, `modules-loader.ts`, hardcode de la sidebar, edition manuelle de `extends` dans `nuxt.config.ts`
+Doc humaine : `README.md` — Spec audit : `doc/audit-log.md` (à lire à la demande, non chargés en permanence).
 
 ## Stack
+- Backend : PHP 8.4, Symfony 8, API Platform 4, Doctrine ORM, PostgreSQL 16 (port 5437)
+- Frontend : Nuxt 4 (SPA), Vue 3, Pinia, Tailwind, @malio/layer-ui, @nuxtjs/i18n
+- Auth : JWT HTTP-only cookie (Lexik), login a `/login_check`
+- Containers : `php-starseed-fpm`, `nginx-starseed` (port 8083), dev Nuxt port **3004**
 
-- **Backend** : PHP 8.4, Symfony 8.0, API Platform 4, Doctrine ORM, PostgreSQL 16
-- **Frontend** : Nuxt 4 (SSR off / SPA), Vue 3, Pinia, Tailwind CSS, @malio/layer-ui, nuxt-toast, @nuxtjs/i18n, @nuxt/icon
-- **Auth** : JWT HTTP-only cookie (lexik/jwt-authentication-bundle), login a `/login_check`, cookie `BEARER`
-- **Docker** : PHP-FPM + Node 24, Nginx (port 8083), PostgreSQL (port 5437)
+## Regles ABSOLUES
 
-## Commandes
-
-```bash
-make start           # Demarrer les containers
-make stop            # Arreter les containers
-make restart         # Redemarrer les containers
-make install         # Install complet (composer, migrations, fixtures, build Nuxt)
-make reset           # Tout supprimer et reinstaller (supprime la BDD)
-make dev-nuxt        # Dev server Nuxt (hot reload, port 3004)
-make shell           # Shell dans le container PHP
-make shell-root      # Shell root dans le container PHP
-make cache-clear     # Vider le cache Symfony
-make migration-migrate # Lancer les migrations
-make fixtures        # Charger les fixtures
-make db-reset        # Reset BDD + migrations + fixtures
-make test            # PHPUnit
-make php-cs-fixer-allow-risky # Fix code style PHP
-make logs-dev        # Tail logs Symfony
-```
-
-Si `make cache-clear` echoue pour cause de permissions sur `var/` :
-```bash
-docker exec -t -u root php-coltura-fpm chown -R www-data:www-data /var/www/html/var
-docker exec -t -u www-data php-coltura-fpm php bin/console cache:clear
-```
+1. **Ne jamais importer d'un module a un autre** — passer par `Shared/Domain/Contract/` (interfaces) ou domain events.
+2. **Toujours `declare(strict_types=1);`** en tete de tout fichier PHP.
+3. **Toujours annoter `#[Auditable]`** les entites metier ; `#[AuditIgnore]` sur champs sensibles (password, token, secret).
+4. **Toujours utiliser `useApi()`** pour les appels API cote front — jamais `$fetch` / `ofetch` direct.
+5. **Toujours utiliser les composants `Malio*`** (@malio/layer-ui) pour formulaires/filtres ; `MalioDataTable` pour listes paginees.
+6. **Jamais persister l'etat de tableau dans l'URL** (filtres, pagination, tri, selection) — state local uniquement.
+7. **Jamais ajouter un test E2E** sauf si un bug critique est passe en prod ; preferer un test Vitest.
+8. **Toujours mettre a jour les 3 sources RBAC ensemble** : `config/sidebar.php`, `frontend/tests/e2e/_fixtures/personas.ts`, `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php`.
+9. **Jamais commit sans demande explicite** de l'utilisateur ; jamais force push sans confirmation.
+10. **Jamais mentionner Claude, Anthropic ou une IA** dans un commit (message, titre, body, footer, trailer) ou une PR (titre, description). Pas de `Co-Authored-By: Claude`, pas de `Generated with Claude Code`, pas de `🤖`, pas d'emoji robot, rien. Les commits sont signes par l'utilisateur uniquement.
+11. **Migrations d'initialisation au namespace racine** `DoctrineMigrations` dans `migrations/` (setup user, RBAC, seed de base). Les migrations modulaires (`src/Module/*/Infrastructure/Doctrine/Migrations/`) sont reservees aux evolutions post-schema (ajout de colonnes, index) — cf. @.claude/rules/architecture.md pour la raison.
+12. **Toujours documenter chaque colonne BDD via `COMMENT ON COLUMN`** dans la migration qui la cree ou la modifie. Description en francais, courte (≤ 200 caracteres), explique la semantique metier + contraintes implicites (unicite partielle, FK importante, lien RG). Garde-fou : `tests/Architecture/ColumnsHaveSqlCommentTest` echoue si une colonne `public` n'a pas de description (`col_description IS NULL`). Details et exemples : @.claude/rules/backend.md § Migrations Doctrine.
+13. **Toujours paginer toute collection exposee par l'API.** Aucun retour de collection complete (pas de provider qui retourne un array brut). Standard pose dans `config/packages/api_platform.yaml` : 10 items par defaut, max 50, le client peut basculer entre 10/25/50 et peut envoyer `?pagination=false` pour alimenter un select. Garde-fou : `tests/Architecture/CollectionsArePaginatedTest` echoue si une `GetCollection` desactive la pagination sans whitelist. Details et exemples : @.claude/rules/backend.md § Pagination.
+14. **`symfony.lock` est versionne** (au meme titre que `composer.lock`) — ne JAMAIS le `.gitignore`. C'est le registre des recipes Flex appliquees : sans lui, chaque `composer require` rejoue toutes les recipes et repollue `.env`, `config/bundles.php`, `docker-compose.yml` et recree du scaffolding parasite (`src/Entity/`, `src/Controller/`...). Le regenerer si besoin via `composer recipes:install --force`.
 
 ## Conventions
+@.claude/rules/architecture.md
+@.claude/rules/backend.md
+@.claude/rules/frontend.md
+@.claude/rules/testing.md
+@.claude/rules/naming.md
+@.claude/rules/git.md
+@.claude/rules/workflow.md
 
-### Commits
+## Commandes (liste complete dans `README.md`)
 
-Format : `<type>(<scope optionnel>) : <message>` (espace avant et apres `:`)
+- Demarrer : `make start`
+- Dev front (hot reload) : `make dev-nuxt` (port 3004)
+- Shell PHP : `make shell`
+- Tests back : `make test`
+- Tests front unitaires : `make nuxt-test`
+- Tests E2E : `make test-e2e` (prerequis : `make seed-e2e && make dev-nuxt`)
+- Reset BDD : `make db-reset`
+- Lint PHP : `make php-cs-fixer-allow-risky`
 
-Types autorises (minuscules) : `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`
+## Activer / desactiver un module
 
-Exemples : `feat : add login page`, `fix(auth) : prevent null token crash`
+Editer uniquement `config/modules.php` (commenter la ligne). Cascade automatique via `/api/modules`, `/api/sidebar`, middleware front `modules.global.ts`. Details : @.claude/rules/architecture.md
 
-### Tags & Versioning
+## A NE PAS faire
 
-- La version de l'app est dans `config/version.yaml` (parametre `app.version`)
-- A chaque creation de tag, **toujours** mettre a jour `config/version.yaml` avec la meme version
-- Faire un commit separe de bump : `chore : bump version to v<X.Y.Z>`
-- Puis creer le tag et pusher : `git tag v<X.Y.Z> && git push origin develop --tags`
+- Pas de controller Symfony custom sous `/api/` sans `priority: 1` sur `#[Route]` (conflit API Platform `{id}`).
+- Pas de provider API Platform qui retourne un array brut sur une `GetCollection` — court-circuite la pagination Hydra (`totalItems` / `view` absents). Utiliser `ApiPlatform\Doctrine\Orm\Paginator` (ORM) ou un paginator implementant `PaginatorInterface` (DBAL — cf. `DbalPaginator`).
+- Pas de `getClientMimeType()` pour valider un upload — utiliser `$file->getMimeType()` (serveur).
+- Pas de hardcode de la sidebar cote front, pas de `modules-loader.ts` ni `.module.ts`.
+- Pas d'edition manuelle de `extends` dans `frontend/nuxt.config.ts` — les layers sont scannes automatiquement.
+- Pas de commentaires en anglais dans le code — **commentaires en francais**, code (noms) en anglais.
+- Pas d'`<input>` / `<select>` / `<table>` bruts quand un composant `@malio/layer-ui` existe (exceptions documentees dans @.claude/rules/frontend.md).
+- Pas de modification de la config git.
 
-### Nommage
+## Skills projet
 
-| Element | Convention | Exemple |
-|---------|-----------|---------|
-| Module back | PascalCase | `Module/Commercial/` |
-| Module front | kebab-case | `modules/commercial/` |
-| Module ID | snake_case | `commercial`, `gestion_rh` |
-| Entity | PascalCase singulier | `User.php` |
-| Repository interface | `*RepositoryInterface` | `UserRepositoryInterface.php` |
-| Repository impl | `Doctrine*Repository` | `DoctrineUserRepository.php` |
-| DTO | `*Output` / `*Input` | `UserOutput.php` |
-| API Resource | classe dans `Infrastructure/ApiPlatform/Resource/` | `UserResource.php` |
-| Provider | `*Provider` | `MeProvider.php` |
-| Processor | `*Processor` | `UserPasswordHasherProcessor.php` |
-| Module declaration back | `*Module.php` | `CommercialModule.php` |
-| Composable front | `use*` | `useSidebar.ts` |
-| Cles i18n sidebar | `sidebar.<module>.*` | `sidebar.commercial.overview` |
+- `create-module` — scaffolder un nouveau module back+front et wirer la sidebar.
 
-### Backend
+## Credentials (dev)
 
-- Toujours `declare(strict_types=1)` en haut des fichiers PHP
-- **Commentaires en francais** : tout commentaire PHP (docblock, inline, bloc) doit etre redige en francais. Le code (noms de classes, methodes, variables) reste en anglais. Objectif : faciliter la relecture par l'equipe FR sans polluer l'API publique du code.
-- API Platform : utiliser ApiResource, Providers, Processors — pas de controllers
-- Routes API prefixees `/api` (via `config/routes/api_platform.yaml`)
-- Le login (`/login_check`) est hors prefix `/api`, nginx reecrit `REQUEST_URI` vers `/login_check`
-- PHP CS Fixer : regles Symfony + PSR-12 + strict types
-- Roles : `ROLE_ADMIN`, `ROLE_USER` — hierarchie dans `security.yaml`
-- **Permissions RBAC** : format obligatoire `module.resource[.subresource].action` en snake_case, ex : `core.users.view`, `commercial.clients.contacts.edit`. Declarees via la methode statique `permissions()` des `*Module.php`, synchronisees par la commande `app:sync-permissions`. Verification via `is_granted('module.resource.action')` cote API Platform et `usePermissions()` cote front.
-- PostgreSQL : noms de colonnes toujours en **minuscules** dans le SQL brut
-- Controllers custom sous `/api/` : ajouter `priority: 1` sur `#[Route]` pour eviter le conflit avec API Platform `{id}`
-- Serialization : pour embarquer une relation (pas IRI), ajouter le groupe du parent aux proprietes de l'entite cible
-- Upload fichiers : utiliser `$file->getMimeType()` (pas `getClientMimeType()`) pour valider cote serveur
+`admin` / `admin` (ROLE_ADMIN) ; `alice` / `alice`, `bob` / `bob` (ROLE_USER).
 
-### Frontend
-
-- TypeScript strict
-- **Commentaires en francais** : tout commentaire TS/Vue (JSDoc, inline, bloc) doit etre redige en francais. Le code reste en anglais. Meme regle que cote backend.
-- Composable `useApi()` pour tous les appels API (gere cookies, erreurs, toasts, i18n)
-- Stores Pinia : `useAuthStore` (auth), `useUiStore` (ui)
-- Middleware global `auth.global.ts` protege les routes + charge la sidebar apres login
-- Middleware global `modules.global.ts` redirige les routes des modules desactives
-- Traductions dans `frontend/i18n/locales/` avec le namespace `sidebar.*` pour la nav
-- 4 espaces d'indentation
-- Les labels de sidebar sont des cles i18n, jamais du texte brut (le layout applique `t()` dessus)
-
-### Nginx
-
-- `/api/*` -> Symfony (via try_files + index.php)
-- `/api/login_check` -> location exact match, fastcgi direct avec REQUEST_URI reecrit en `/login_check`
-- `/` -> SPA frontend (`frontend/dist/`)
-
-## Docker
-
-- Container PHP : `php-coltura-fpm`
-- Container Nginx : `nginx-coltura`
-- Container DB : PostgreSQL sur port **5437** (interne et externe)
-- Config Docker dev : `infra/dev/.env.docker` (override local : `infra/dev/.env.docker.local`)
-- Config Docker prod : `infra/prod/` (Dockerfile multi-stage, docker-compose.prod.yml)
-- Apres modif nginx : `docker restart nginx-coltura`
-
-## Fixtures
-
-- User admin : `admin` / `admin` (ROLE_ADMIN)
-- Users internes : `alice` / `alice`, `bob` / `bob` (ROLE_USER)
-
-## Delegation Codex
-
-Pour les taches mecaniques (tests, boilerplate, renommages, refacto repetitif), delegue a Codex via le plugin `codex`. Garde Claude pour la reflexion, l'architecture et la verification.
-
-- **Codex** = junior dev rapide et pas cher (executions mecaniques)
-- **Claude** = senior dev qui verifie et reflechit (design, review, decisions)
-
-C'est le meilleur ratio qualite/credits.
+Comptes demo des roles metier (seedes par `RbacDemoFixtures` / `app:seed-rbac --with-demo-users`, mot de passe `demo`) : `bureau` / `demo`, `compta` / `demo`, `commerciale` / `demo`, `usine` / `demo`. Matrice RBAC § 2.7 (M1 Clients) attachee aux roles correspondants.

README.md

@@ -1,156 +1,362 @@
-# Coltura
+# Starseed
 
-CRM/ERP — Symfony 8 (API Platform 4) + Nuxt 4
+CRM/ERP en architecture **modular monolith DDD** — Symfony 8 (API Platform 4) + Nuxt 4.
+
+Le backend est la **source de vérité unique** : il décide des modules actifs et de
+l'organisation de la sidebar. Le frontend scanne `frontend/modules/*/` comme layers
+Nuxt et consomme l'API pour la navigation.
+
+---
+
+## Sommaire
+
+- [Stack](#stack)
+- [Prérequis](#prérequis)
+- [Démarrage rapide](#démarrage-rapide)
+- [Dev local : avec ou sans données de seed](#dev-local--avec-ou-sans-données-de-seed)
+- [Comptes (dev)](#comptes-dev)
+- [Bases de données : dev et test](#bases-de-données--dev-et-test)
+- [Tests](#tests)
+- [Déploiement : seed RBAC en recette / prod](#déploiement--seed-rbac-en-recette--prod)
+- [Commandes make](#commandes-make)
+- [Architecture](#architecture)
+- [Structure du dépôt](#structure-du-dépôt)
+- [CI/CD](#cicd)
+- [Conventions](#conventions)
+
+---
 
 ## Stack
 
 - **Backend** : PHP 8.4, Symfony 8, API Platform 4, Doctrine ORM, PostgreSQL 16
-- **Frontend** : Nuxt 4 (SPA), Vue 3, Pinia, Tailwind CSS, @malio/layer-ui
-- **Auth** : JWT HTTP-only cookie (Lexik)
+- **Frontend** : Nuxt 4 (SPA, SSR off), Vue 3, Pinia, Tailwind CSS, @malio/layer-ui, @nuxtjs/i18n
+- **Auth** : JWT HTTP-only cookie (Lexik), login sur `/login_check`
 - **Infra** : Docker Compose (dev + prod multi-stage)
 - **CI/CD** : Gitea Actions (auto-tag + build Docker)
 
-## Quick Start
+| Service       | Port |
+|---------------|------|
+| API (Nginx)   | 8083 |
+| Frontend dev  | 3004 |
+| PostgreSQL    | 5437 |
+
+---
+
+## Prérequis
+
+- Docker + Docker Compose
+- `make`
+- `nvm` (la version de Node est fixée par `.nvmrc`, voir `make node-use`)
+
+Toutes les commandes `make` s'exécutent dans le container PHP (`php-starseed-fpm`) ;
+rien n'est requis sur l'hôte hormis Docker — **sauf les tests E2E**, qui tournent sur
+l'hôte (navigateur réel, voir [Tests](#tests)).
+
+---
+
+## Démarrage rapide
 
 ```bash
-make start           # Demarrer les containers Docker
-make install         # Composer, migrations, fixtures, build Nuxt
+make start      # Démarre les containers Docker
+make install    # Composer + clés JWT + migrations + permissions + BDD de test
+make dev-nuxt   # Serveur Nuxt avec hot reload (http://localhost:3004)
 ```
 
-Dev frontend (hot reload) :
+`make install` prépare une base de dev **vierge** (schéma + RBAC structurel, sans
+données de démo) et la base de **test**. Pour obtenir des comptes et des données de
+démo prêtes à l'emploi, lis la section suivante.
+
+> Override local possible : `make` lit `infra/dev/.env.docker`, surchargé par
+> `infra/dev/.env.docker.local` s'il existe (créé automatiquement par `make env-init`).
+
+---
+
+## Dev local : avec ou sans données de seed
+
+Le projet distingue deux états de base de données de dev. Les **fixtures Doctrine sont
+en `require-dev`** : elles n'existent qu'en dev, jamais dans le build de prod.
+
+### Sans données de seed (base vierge)
+
+C'est ce que produit `make install`. La base contient :
+
+- le **schéma** complet (toutes les migrations jouées) ;
+- les **rôles système** `admin` / `user` (seedés en SQL par la migration RBAC) ;
+- le **catalogue de permissions** synchronisé (`app:sync-permissions`).
+
+Mais **aucun compte utilisateur ni donnée métier**. Pour pouvoir te connecter,
+crée toi-même un compte :
 
 ```bash
-make dev-nuxt        # Port 3003
+make shell
+php bin/console app:create-user admin monMotDePasse --admin   # compte ROLE_ADMIN
 ```
 
-## Ports
+Optionnel — provisionner les **rôles métier** (bureau / compta / commerciale / usine
++ matrice RBAC § 2.7) sans comptes de démo :
 
-| Service    | Port |
-|------------|------|
-| API (Nginx)| 8083 |
-| Frontend   | 3004 |
-| PostgreSQL | 5437 |
+```bash
+php bin/console app:seed-rbac
+```
 
-## Commandes
+Cet état est utile pour repartir d'une base propre, reproduire un bug sur données
+minimales, ou tester un parcours d'onboarding réel.
 
-| Commande | Description |
-|----------|-------------|
-| `make start` | Demarrer les containers |
-| `make stop` | Arreter les containers |
-| `make restart` | Redemarrer les containers |
-| `make install` | Install complet |
-| `make reset` | Tout supprimer et reinstaller |
-| `make dev-nuxt` | Serveur dev Nuxt (hot reload) |
-| `make shell` | Shell dans le container PHP |
-| `make cache-clear` | Vider le cache Symfony |
-| `make migration-migrate` | Lancer les migrations |
-| `make fixtures` | Charger les fixtures |
-| `make db-reset` | Reset BDD + migrations + fixtures |
-| `make test` | PHPUnit |
-| `make php-cs-fixer-allow-risky` | Fix code style PHP |
-| `make logs-dev` | Tail logs Symfony |
+### Avec données de seed (base de démo)
+
+`make db-reset` (ou `make fixtures` après un `make install`) recharge la base de dev
+avec un jeu complet de données de démonstration, **idempotent** :
+
+```bash
+make db-reset   # ATTENTION : drop + recrée la base de dev, puis charge tout le seed
+```
+
+Ce que les fixtures posent :
+
+- **3 utilisateurs système** : `admin` (ROLE_ADMIN), `alice`, `bob` (ROLE_USER),
+  rattachés à des sites distincts ;
+- **3 sites** : Chatellerault, Saint-Jean, Pommevic ;
+- **les comptes de démo RBAC métier** (`bureau`, `compta`, `commerciale`, `usine`,
+  mot de passe `demo`) avec la matrice § 2.7 attachée ;
+- les **référentiels et données métier** des modules (catégories, clients de démo,
+  référentiels comptables…).
+
+Toutes les fixtures sont rejouables sans effet de bord (lookup par clé naturelle,
+aucun doublon).
+
+> Différence avec `make install` : `install` ne charge **pas** les fixtures sur la base
+> de dev (il alimente uniquement la base de test). Utilise `make db-reset` ou
+> `make fixtures` quand tu veux des données de démo en dev.
+
+---
+
+## Comptes (dev)
+
+Disponibles uniquement après `make db-reset` / `make fixtures` (état « avec seed ») :
+
+| Username      | Password | Rôle       | RBAC métier                                                   |
+|---------------|----------|------------|---------------------------------------------------------------|
+| `admin`       | `admin`  | ROLE_ADMIN | bypass complet (`is_admin`)                                   |
+| `alice`       | `alice`  | ROLE_USER  | —                                                             |
+| `bob`         | `bob`    | ROLE_USER  | —                                                             |
+| `bureau`      | `demo`   | ROLE_USER  | clients : view + manage                                       |
+| `compta`      | `demo`   | ROLE_USER  | clients : view + accounting.view / manage                     |
+| `commerciale` | `demo`   | ROLE_USER  | clients : view + manage                                       |
+| `usine`       | `demo`   | ROLE_USER  | aucun accès clients                                           |
+
+---
+
+## Bases de données : dev et test
+
+Deux bases distinctes vivent dans le **même container PostgreSQL** (port 5437) :
+
+| Base       | Environnement | Construite par                       | Usage                          |
+|------------|---------------|--------------------------------------|--------------------------------|
+| `<db>`      | `dev`         | `make install` / `make db-reset`     | développement manuel, dev-nuxt |
+| `<db>_test` | `test`        | `make test-db-setup`                 | PHPUnit (jamais touchée à la main) |
+
+Le suffixe `_test` est appliqué **automatiquement** par Doctrine quand `APP_ENV=test`
+(config `when@test` dans `config/packages/doctrine.yaml`). La base de test est donc
+totalement **isolée** de la base de dev : lancer `make test` ne touche jamais tes
+données de dev.
+
+`make test-db-setup` fait davantage que jouer les migrations, car certaines structures
+ne sont pas portées par des migrations « métier » :
+
+1. `doctrine:migrations:migrate` — schéma métier réel ;
+2. `doctrine:schema:update --force` — crée les tables mappées en `when@test`
+   uniquement (entités de test) ;
+3. `app:apply-column-comments` — réapplique les `COMMENT ON COLUMN` que
+   `schema:update` efface sur les tables managées par l'ORM (garde-fou
+   `ColumnsHaveSqlCommentTest`) ;
+4. `fixtures:load` → `sync-permissions` → `seed-rbac` — dans cet ordre précis
+   (le purger des fixtures vide la table `permission`, donc la sync passe après) ;
+5. recréation des **index partiels uniques** (`LOWER(...) WHERE ...`) non exprimables
+   en attributs ORM, indispensables aux tests d'unicité (RG-1.07, RG-1.16, RG-1.03/1.29).
+
+`make install` et `make db-reset` appellent déjà `test-db-setup` : tu n'as à le
+relancer à la main que si la base de test diverge (nouvelle migration, nouvelle
+permission) sans vouloir reseed la base de dev.
+
+---
+
+## Tests
+
+| Suite             | Commande         | Outil                | Où                                |
+|-------------------|------------------|----------------------|-----------------------------------|
+| Back              | `make test`      | PHPUnit              | container PHP, base `<db>_test`   |
+| Front unitaire    | `make nuxt-test` | Vitest (happy-dom)   | container Node, < 30 s            |
+| Front E2E         | `make test-e2e`  | Playwright           | **hôte** (navigateur réel requis) |
+| Tout (back+front) | `make test-all`  | PHPUnit + Vitest     | —                                 |
+
+### Tests back (PHPUnit)
+
+```bash
+make test                       # toute la suite
+make test FILES=tests/Module/Commercial   # un dossier / fichier ciblé
+```
+
+PHPUnit force `APP_ENV=test` (`phpunit.dist.xml`) : les tests tournent **toujours**
+sur la base `<db>_test`, jamais sur la base de dev. Prérequis : que la base de test
+existe — c'est le cas après `make install`. Si elle a divergé, rejoue
+`make test-db-setup` (cf. [Bases de données](#bases-de-données--dev-et-test)).
+
+### Tests front unitaires (Vitest)
+
+```bash
+make nuxt-test   # composables, utils, stores — rapide et stable
+```
+
+C'est la **place par défaut** pour étendre la couverture (cf. règle d'or ci-dessous).
+
+### Tests E2E (Playwright)
+
+Suite volontairement minimaliste (login + matrice RBAC sidebar). **Règle d'or : un
+nouveau test E2E ne s'ajoute que si un bug critique est passé en prod** — sinon,
+préférer un test Vitest ou étendre un persona existant.
+
+Bootstrap (une fois par poste) :
+
+```bash
+make install-e2e-deps   # télécharge Chromium + libs système (apt/dnf, sudo)
+```
+
+Workflow :
+
+```bash
+# Terminal 1 — containers, seed des personas, serveur dev
+make start && make seed-e2e && make dev-nuxt
+
+# Terminal 2 — tests
+make test-e2e            # headless
+make test-e2e-ui         # UI interactive (debug)
+```
+
+> Toute permission testable touche **3 miroirs** à garder alignés : `config/sidebar.php`,
+> `frontend/tests/e2e/_fixtures/personas.ts`, `SeedE2ECommand.php`.
+
+---
+
+## Déploiement : seed RBAC en recette / prod
+
+Les fixtures Doctrine étant en `require-dev`, elles sont **absentes du build de prod**.
+Le RBAC métier (rôles `bureau` / `compta` / `commerciale` / `usine` + matrice § 2.7)
+est seedé par une **commande applicative idempotente**, jouée dans l'étape de release,
+**après** les migrations et la synchronisation des permissions :
+
+```bash
+php bin/console doctrine:migrations:migrate --no-interaction
+php bin/console app:sync-permissions      # pose les permissions (commercial.clients.*, …)
+php bin/console app:seed-rbac             # PROD : rôles + matrice § 2.7 (sans comptes démo)
+```
+
+En **recette / staging**, ajouter le flag pour disposer de logins de test. Le mot de
+passe est fourni **explicitement** (jamais en dur, jamais committé) :
+
+```bash
+php bin/console app:seed-rbac --with-demo-users --password='<mot-de-passe>'
+# ou via la variable d'environnement RBAC_DEMO_PASSWORD
+```
+
+La commande est rejouable sans effet de bord (aucun doublon de rôle, de lien ou de
+compte). Pour créer un premier administrateur en prod :
+
+```bash
+php bin/console app:create-user <username> <password> --admin
+```
+
+---
+
+## Commandes make
+
+`make` (sans argument) ou `make help` affiche l'aide colorée. Les principales :
+
+| Commande                       | Description                                              |
+|--------------------------------|----------------------------------------------------------|
+| `make start` / `stop` / `restart` | Cycle de vie des containers                          |
+| `make install`                 | Install complet (base dev vierge + base de test)         |
+| `make reset`                   | Tout supprimer et réinstaller (**drop la BDD**)          |
+| `make dev-nuxt`                | Serveur Nuxt hot reload (port 3004)                      |
+| `make shell` / `shell-root`    | Shell bash dans le container PHP                         |
+| `make migration-migrate`       | Jouer les migrations Doctrine                            |
+| `make fixtures`                | Charger les fixtures (données de démo dev)               |
+| `make sync-permissions`        | Synchroniser le catalogue RBAC                           |
+| `make seed-rbac`               | Seed RBAC métier (rôles + matrice § 2.7)                 |
+| `make db-reset`                | Reset base dev : drop + migrate + fixtures + RBAC        |
+| `make test-db-setup`           | (Re)construire la base de test                           |
+| `make test`                    | PHPUnit (back)                                           |
+| `make nuxt-test`               | Vitest (front unitaire)                                  |
+| `make test-all`                | PHPUnit + Vitest                                         |
+| `make test-e2e` / `test-e2e-ui`| Playwright (E2E, sur l'hôte)                             |
+| `make seed-e2e`                | Seed des 6 personas E2E                                  |
+| `make php-cs-fixer-allow-risky`| Fix du code style PHP                                    |
+| `make php-cs-fixer-check`      | Dry-run du fixer (CI / avant push)                       |
+| `make logs-dev`                | Tail des logs Symfony                                    |
+
+---
 
 ## Architecture
 
-**Modular Monolith DDD** : chaque module est un bounded context autonome, activable/desactivable par tenant. Le backend est la seule source de verite pour l'activation et l'organisation de la sidebar.
+**Modular Monolith DDD** : chaque module est un bounded context autonome,
+activable / désactivable par tenant. Le backend est la seule source de vérité pour
+l'activation des modules et l'organisation de la sidebar.
 
 - `config/modules.php` — liste des modules actifs
 - `config/sidebar.php` — structure de la sidebar (sections + items avec module owner)
-- `GET /api/sidebar` — retourne les sections filtrees par les modules actifs + les routes desactivees
-- Frontend : chaque `frontend/modules/*/` est auto-detecte comme layer Nuxt, la sidebar est fetchee de l'API
+- `GET /api/modules` — IDs des modules actifs (public)
+- `GET /api/sidebar` — sections filtrées par modules actifs + routes désactivées (public)
 
-Pour desactiver un module : commenter sa ligne dans `config/modules.php`, clear cache. Ses items de sidebar disparaissent et ses routes sont bloquees par le middleware front.
+**Désactiver un module** : commenter sa ligne dans `config/modules.php`, vider le cache.
+Ses items de sidebar disparaissent et ses routes sont bloquées par le middleware front.
+Le code reste dans le bundle (layer auto-détecté) → réactivation instantanée.
 
-Pour reorganiser la sidebar (ex: deplacer un item d'une section a l'autre) : editer `config/sidebar.php` uniquement, le code des modules n'est pas touche.
+**Réorganiser la sidebar** : éditer `config/sidebar.php` uniquement — le code des
+modules n'est pas touché.
 
-## Structure
+**Communication inter-modules** : jamais d'import direct d'un module à l'autre. Passer
+par `Shared/Domain/Contract/` (interfaces) ou des domain events.
+
+---
+
+## Structure du dépôt
 
 ```
 src/                              # Backend Symfony
-  Kernel.php
-  Shared/                         # Noyau technique partage
-    Domain/
-      ValueObject/                # Email, ...
-      Event/                      # DomainEventInterface
-      Contract/                   # Interfaces inter-modules
-    Application/
-      Bus/                        # CommandBusInterface, QueryBusInterface
-    Infrastructure/
-      ApiPlatform/
-        Resource/                 # AppVersion, ModulesResource, SidebarResource
-        State/                    # AppVersionProvider, ModulesProvider, SidebarProvider
+  Shared/                         # Noyau technique partagé (Domain/, Application/Bus/, Infrastructure/ApiPlatform/)
   Module/
-    Core/                         # Module obligatoire (auth, users)
-      CoreModule.php              # Declaration (ID, LABEL, REQUIRED)
-      Domain/
-        Entity/                   # User
-        Repository/               # UserRepositoryInterface
-        Event/                    # UserCreated
-      Application/
-        DTO/                      # UserOutput
-      Infrastructure/
-        Doctrine/                 # DoctrineUserRepository, Migrations/
-        ApiPlatform/State/
-          Provider/               # MeProvider
-          Processor/              # UserPasswordHasherProcessor
-        Console/                  # CreateUserCommand
-        DataFixtures/             # AppFixtures
-    Commercial/                   # Autre module (exemple)
-      CommercialModule.php
+    Core/                         # Module obligatoire (auth, users, RBAC)
+      CoreModule.php              # Déclaration (ID, LABEL, REQUIRED, permissions())
+      Domain/ Application/ Infrastructure/
+    Commercial/ Catalog/ Sites/   # Modules métier
 config/
-  modules.php                     # Source de verite activation
-  sidebar.php                     # Source de verite navigation
-  version.yaml
-  packages/                       # Config Symfony
-  jwt/                            # Cles JWT
-migrations/                       # Anciennes migrations
+  modules.php                     # Source de vérité : activation
+  sidebar.php                     # Source de vérité : navigation
+  packages/                       # Config Symfony (doctrine, api_platform, security…)
+migrations/                       # Migrations d'initialisation (namespace racine : setup, RBAC, seed de base)
 frontend/                         # App Nuxt 4 (SPA)
-  app/
-    layouts/                      # default.vue, auth.vue
-    middleware/                   # auth.global.ts, modules.global.ts
-  shared/                         # Code partage (hors modules)
-    composables/                  # useApi, useAppVersion, useSidebar
-    components/ui/                # AppTopNav, ...
-    stores/                       # auth, ui
-    services/                     # auth
-    types/                        # SidebarSection, UserData
-    utils/                        # api (Hydra)
-  modules/                        # Modules auto-detectes comme layers Nuxt
-    core/
-      nuxt.config.ts              # Marqueur layer
-      pages/                      # index, login, logout
-    commercial/
-      nuxt.config.ts
-      pages/                      # commercial.vue
-  app.vue
-  nuxt.config.ts                  # Scanne modules/*/ automatiquement
-  i18n/locales/                   # Traductions (sidebar.*, etc.)
-  assets/                         # CSS, images
-  public/                         # Fichiers statiques
+  app/                            # Shell : layouts, middlewares (auth.global, modules.global)
+  shared/                         # Code inter-modules (composables, stores, utils, types)
+  modules/                        # Layers Nuxt auto-détectés (core/, commercial/…)
+  i18n/locales/                   # Traductions (sidebar.*, audit.entity.*, …)
 infra/
-  dev/                            # Docker dev (Dockerfile, nginx, php.ini, xdebug)
+  dev/                            # Docker dev (Dockerfile, nginx, php.ini, xdebug, .env.docker)
   prod/                           # Docker prod (multi-stage, nginx, php-prod.ini)
 .gitea/workflows/                 # CI Gitea (auto-tag, build Docker)
-.claude/
-  skills/create-module/           # Skill Claude Code pour scaffolder un module
 ```
 
+---
+
 ## CI/CD
 
 - **Auto Tag** : push sur `develop` → bump `config/version.yaml` → tag `vX.Y.Z`
 - **Build Docker** : push tag `v*` → build image multi-stage → push Gitea Registry
 
 Secrets requis dans Gitea :
+
 - `RELEASE_TOKEN` — PAT avec droits `write:repository`
 - `REGISTRY_TOKEN` — token pour le registry Docker
 
-## Credentials (dev)
-
-| Username | Password | Role |
-|----------|----------|------|
-| admin | admin | ROLE_ADMIN |
-| alice | alice | ROLE_USER |
-| bob | bob | ROLE_USER |
+---
 
 ## Conventions
 
@@ -160,4 +366,13 @@ Secrets requis dans Gitea :
 <type>(<scope optionnel>) : <message>
 ```
 
-Types : `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, `test`
+Espaces obligatoires autour du `:`. Types : `build`, `chore`, `ci`, `docs`, `feat`,
+`fix`, `perf`, `refactor`, `revert`, `style`, `test`.
+
+### Langue
+
+- UI et communication : **français**
+- Code (classes, méthodes, variables) : **anglais**
+- Commentaires (PHP, TS, Vue) : **français**
+
+> Règles détaillées : `CLAUDE.md` et `.claude/rules/`.

REVIEW.md

@@ -0,0 +1,730 @@
+# Review PR `feat/audit-log` — 4e passe
+
+> Audit complet de la PR audit-log (89 commits, 233 fichiers, +52k/-876 lignes) apres les 3 passes de review deja mergees.
+> Objectif : faire sortir ce qui reste avant merge dans `main`.
+> Genere le 2026-04-23.
+
+**Branche** : `feat/audit-log`
+**Base** : `main`
+**Revues anterieures** (deja appliquees dans la branche) :
+- `bb6a4c3 fix(review) : blockers review PR #9`
+- `25cd6a1 fix(review) : regression drawers RBAC + race snapshot + stale-data admin`
+- `b1255bb fix(review) : 3e passe review (HIGH frontend + MEDIUMs)`
+- `7117744 docs(claude) : refactor CLAUDE.md`
+
+La branche est globalement solide : les trois miroirs RBAC sont synchronises, le pattern swap-and-clear de l'audit est correctement implemente, la connexion DBAL dediee est bien configuree. Les findings ci-dessous sont incrementaux et ne remettent pas en cause la feature.
+
+---
+
+## Table des matieres
+
+1. [Securite](#1-securite)
+2. [Bugs silencieux](#2-bugs-silencieux)
+3. [Violations des regles projet](#3-violations-des-regles-projet)
+4. [Incoherences de patterns](#4-incoherences-de-patterns)
+5. [Documentation et configuration](#5-documentation-et-configuration)
+6. [Frontend et UX](#6-frontend-et-ux)
+7. [Bonnes pratiques a retenir](#7-bonnes-pratiques-a-retenir)
+8. [Resume par priorite](#8-resume-par-priorite)
+
+---
+
+## 1. Securite
+
+### 1.1 CRITIQUE — `/api/docs` public en production
+
+**Fichier** : `config/packages/security.yaml:46`
+
+```yaml
+- { path: ^/api/docs, roles: PUBLIC_ACCESS }
+```
+
+La documentation Swagger/OpenAPI d'API Platform est accessible sans authentification, quel que soit l'environnement — y compris en production sur `starseed.malio-dev.fr`. Elle expose :
+
+- la liste complete des endpoints (`/api/audit-logs`, `/api/users/{id}/rbac`, `/api/sites`, etc.)
+- les schemas de securite (`is_granted('core.audit_log.view')`)
+- les filtres acceptes par chaque provider (y compris `performed_at[after]`)
+- la structure des DTOs (`AuditLogOutput`, `UserOutput`...)
+- les patterns UUID/IDs
+
+**Pourquoi c'est grave** : un attaquant a une cartographie gratuite de la surface d'attaque. Pour un CRM interne sur DNS public, c'est une fuite d'information inutile. API Platform genere cette doc automatiquement mais rien n'oblige a la rendre publique.
+
+**Correction** : fermer en prod.
+
+```yaml
+# config/packages/security.yaml
+- { path: ^/login_check, roles: PUBLIC_ACCESS }
+- { path: ^/api/version, roles: PUBLIC_ACCESS, methods: [GET] }
+- { path: ^/api/modules, roles: PUBLIC_ACCESS, methods: [GET] }
+- { path: ^/api/sidebar, roles: PUBLIC_ACCESS, methods: [GET] }
+- { path: ^/api, roles: IS_AUTHENTICATED_FULLY }
+# supprimer la ligne "- { path: ^/api/docs, roles: PUBLIC_ACCESS }"
+```
+
+Ou conditionner l'acces au debug mode :
+
+```yaml
+when@prod:
+    security:
+        access_control:
+            - { path: ^/api/docs, roles: IS_AUTHENTICATED_FULLY }
+```
+
+---
+
+### 1.2 CRITIQUE — Aucun en-tete de securite HTTP en production
+
+**Fichier** : `infra/prod/nginx.conf` et `infra/prod/nginx-proxy.conf` (aucune directive `add_header`)
+
+Le Nginx de prod n'emet aucun des en-tetes de securite standards :
+
+| En-tete | Role | Present ? |
+|---------|------|-----------|
+| `X-Frame-Options: DENY` | anti-clickjacking (pas d'embed iframe) | non |
+| `X-Content-Type-Options: nosniff` | anti MIME-sniffing | non |
+| `Referrer-Policy` | limite les fuites dans le Referer | non |
+| `Content-Security-Policy` | anti-XSS | non |
+| `Strict-Transport-Security` | force HTTPS | non |
+
+Le reverse proxy ecoute uniquement sur le port 80 (HTTP), sans redirection 301 vers HTTPS. Combine avec `JWT_COOKIE_SECURE=1` (defaut dans `.env.prod.example`), le cookie ne serait meme pas envoye en HTTP — donc un premier acces HTTP casse le login silencieusement, l'utilisateur croira que l'auth est buggee.
+
+**Correction minimale dans `nginx-proxy.conf`** (niveau proxy public) :
+
+```nginx
+server {
+    listen 80;
+    listen [::]:80;
+    server_name starseed.malio-dev.fr;
+
+    # Redirection HTTPS obligatoire (ajouter un server block HTTPS par ailleurs).
+    # Tant que le TLS n'est pas en place, au minimum poser les en-tetes suivants.
+    add_header X-Frame-Options "DENY" always;
+    add_header X-Content-Type-Options "nosniff" always;
+    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
+
+    # ... reste de la config
+}
+```
+
+Quand TLS est en place, ajouter :
+
+```nginx
+add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
+```
+
+---
+
+### 1.3 CRITIQUE — `robots.txt` autorise toute l'indexation
+
+**Fichier** : `frontend/public/robots.txt`
+
+```
+User-Agent: *
+Disallow:
+```
+
+La valeur `Disallow:` (vide) signifie "rien n'est interdit" — tous les crawlers peuvent indexer la totalite du site. Pour un outil CRM interne accessible sur un DNS public (`starseed.malio-dev.fr`), c'est un leak inutile : la page de login, les URLs `/admin/*`, les URLs des fiches clients peuvent remonter dans Google.
+
+**Correction** :
+
+```
+User-Agent: *
+Disallow: /
+```
+
+---
+
+### 1.4 IMPORTANT — `performed_at[after|before]` sans typage DBAL → crash 500 sur date malformee
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:182-186`
+
+```php
+if (isset($filters['performed_at_after'])) {
+    $qb->andWhere('performed_at >= :performed_at_after')
+       ->setParameter('performed_at_after', $filters['performed_at_after']);
+}
+```
+
+La valeur est passee comme chaine brute a DBAL. La colonne `performed_at` est un `timestamptz`. Si un client envoie `?performed_at[after]=not-a-date`, PostgreSQL leve une erreur de cast et l'API retourne une 500. Pas d'injection SQL (le parametre est bien binde), mais :
+
+- erreur 500 loguee pour chaque mauvaise entree (pollution des logs + bruit pour l'oncall)
+- DoS tres bas effort : un utilisateur avec `core.audit_log.view` peut envoyer des requetes mal formees en boucle
+- mauvaise UX : le front recoit une erreur generique au lieu d'un 400 explicite
+
+**Correction** :
+
+```php
+use Doctrine\DBAL\Types\Types;
+use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
+
+if (isset($filters['performed_at_after'])) {
+    try {
+        $after = new \DateTimeImmutable($filters['performed_at_after']);
+    } catch (\Throwable) {
+        throw new BadRequestHttpException('performed_at[after] doit etre une date ISO 8601 valide.');
+    }
+    $qb->andWhere('performed_at >= :performed_at_after')
+       ->setParameter('performed_at_after', $after, Types::DATETIMETZ_IMMUTABLE);
+}
+// idem pour performed_at_before
+```
+
+Cette correction donne en prime un 400 propre avec un message clair.
+
+---
+
+### 1.5 IMPORTANT — Clause `ESCAPE` absente du `ILIKE` (filtre `performed_by`)
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:177-180`
+
+```php
+$escaped = str_replace(['\\', '%', '_'], ['\\\\', '\%', '\_'], $filters['performed_by']);
+$qb->andWhere('performed_by ILIKE :performed_by')
+   ->setParameter('performed_by', '%'.$escaped.'%');
+```
+
+Le commentaire dit : *"`\` est deja le caractere d'echappement LIKE par defaut en PostgreSQL"*. C'est **inexact**. En SQL-standard PostgreSQL, il n'y a pas de caractere d'echappement par defaut pour LIKE/ILIKE : pour echapper `%` ou `_`, il faut soit `LIKE pattern ESCAPE '\'`, soit utiliser un autre caractere (ex: `ESCAPE '|'`).
+
+En pratique, sur PostgreSQL avec `standard_conforming_strings=on` (defaut depuis 9.1), `\` n'est PAS interprete par LIKE. Donc `'%\_%'` matche la chaine `%\_%` — pas ce qu'on veut. Le filtre est silencieusement casse pour tout nom contenant `_` ou `%`.
+
+**Test a faire en psql pour confirmer** :
+```sql
+SELECT 'admin_backup' ILIKE '%admin\_backup%';           -- t sur PG moderne ? non : f
+SELECT 'admin_backup' ILIKE '%admin\_backup%' ESCAPE '\'; -- t
+```
+
+**Correction** : ajouter explicitement la clause `ESCAPE`.
+
+```php
+$qb->andWhere("performed_by ILIKE :performed_by ESCAPE '\\\\'")
+   ->setParameter('performed_by', '%'.$escaped.'%');
+```
+
+(Les quatre `\` en PHP donnent deux `\` dans le SQL, soit un `\` litteral une fois parse par PostgreSQL.)
+
+Alternative plus sure : utiliser `position()` au lieu de LIKE.
+
+```php
+$qb->andWhere('position(lower(:performed_by) IN lower(performed_by)) > 0')
+   ->setParameter('performed_by', $filters['performed_by']);
+```
+
+---
+
+### 1.6 IMPORTANT — `SiteAwareInjectionProcessor` : bypass silencieux si l'appelant n'est pas une instance de `User`
+
+**Fichier** : `src/Module/Sites/Infrastructure/ApiPlatform/State/Processor/SiteAwareInjectionProcessor.php:64-75`
+
+```php
+if (!$this->security->isGranted('sites.bypass_scope')) {
+    $user = $this->security->getUser();
+    $explicitSite = $data->getSite();
+    if ($user instanceof User && $explicitSite instanceof Site && !$user->hasSite($explicitSite)) {
+        throw new AccessDeniedHttpException(...);
+    }
+}
+```
+
+Si `$user` n'est pas exactement une instance de `App\Module\Core\Domain\Entity\User` (ex: futur provider d'auth tiers, token systeme), la condition `instanceof User` est fausse et la garde cross-site write est **silencieusement sautee**. L'utilisateur peut alors specifier n'importe quel `site` dans le payload sans verification.
+
+Aujourd'hui le risque est faible (un seul `app_user_provider` configure). Mais le pattern est fragile : une absence de type doit lever une erreur, pas passer.
+
+**Correction** : transformer le cas "pas un User" en refus explicite.
+
+```php
+if (!$this->security->isGranted('sites.bypass_scope')) {
+    $user = $this->security->getUser();
+    if (!$user instanceof User) {
+        throw new AccessDeniedHttpException('Utilisateur non reconnu pour la validation de site.');
+    }
+    $explicitSite = $data->getSite();
+    if ($explicitSite instanceof Site && !$user->hasSite($explicitSite)) {
+        throw new AccessDeniedHttpException(...);
+    }
+}
+```
+
+---
+
+### 1.7 IMPORTANT — `isHandlingUnauthorized` sans `try/finally` : flag bloque si `navigateTo` throw
+
+**Fichier** : `frontend/shared/composables/useApi.ts:25,125-130`
+
+```typescript
+let isHandlingUnauthorized = false  // module-level singleton
+
+// ...
+if (!isLoginCheck && !isLogout) {
+    if (!isHandlingUnauthorized) {
+        isHandlingUnauthorized = true
+        auth.clearSession()
+        await navigateTo('/login')
+        isHandlingUnauthorized = false  // <-- jamais atteint si navigateTo throw
+    }
+}
+```
+
+Si `navigateTo('/login')` echoue (middleware qui throw, plugin qui throw dans un hook, navigation cancelee par `abortNavigation`), le flag reste `true` **indefiniment**. Toutes les 401 futures sont silencieusement ignorees, l'utilisateur reste sur la page courante avec l'impression que les requetes ne font rien. Le seul remede est un hard-reload.
+
+**Correction** : `try/finally`.
+
+```typescript
+if (!isLoginCheck && !isLogout) {
+    if (!isHandlingUnauthorized) {
+        isHandlingUnauthorized = true
+        try {
+            auth.clearSession()
+            await navigateTo('/login')
+        } finally {
+            isHandlingUnauthorized = false
+        }
+    }
+}
+```
+
+---
+
+### 1.8 IMPORTANT — Pagination maximale absente sur `Permission`, `Role`, `Site` (itemsPerPage 999 cote front)
+
+**Fichiers** :
+- `frontend/modules/core/components/UserRbacDrawer.vue:235,236`
+- `frontend/modules/core/components/RoleDrawer.vue:149`
+- `frontend/modules/sites/pages/admin/sites.vue:117`
+
+```typescript
+api.get<{ member: Permission[] }>('/permissions', { orphan: false, itemsPerPage: 999 }, ...)
+api.get<{ member: Site[] }>('/sites', { itemsPerPage: 999 }, ...)
+```
+
+Deux problemes cumules :
+
+1. **`paginationClientItemsPerPage` n'est pas active** sur les resources `Permission`, `Role`, `Site` (seul `AuditLogResource` l'active). API Platform ignore donc `itemsPerPage=999` et retourne 30 elements par defaut. **Le `999` est un no-op**. Aujourd'hui ca marche parce que ces catalogues comptent <30 entrees, mais quand les modules grandiront, les drawers vont silencieusement tronquer.
+
+2. **Aucun `paginationMaximumItemsPerPage`** n'est pose sur ces ressources. Si un dev decide d'activer `paginationClientItemsPerPage: true` plus tard, `?itemsPerPage=99999` deviendra une requete valide qui pourra faire suer la DB.
+
+**Correction** : deux options selon l'intention.
+
+*Option A — Desactiver la pagination pour ces catalogues* (ils sont small + exhaustifs par nature) :
+
+```php
+// Permission.php — GetCollection
+new GetCollection(
+    normalizationContext: ['groups' => ['permission:read']],
+    security: "...",
+    paginationEnabled: false,
+),
+```
+
+Cote front, retirer `itemsPerPage: 999` (devient inutile).
+
+*Option B — Garder la pagination avec un plafond explicite* :
+
+```php
+new GetCollection(
+    paginationClientItemsPerPage: true,
+    paginationMaximumItemsPerPage: 200,
+    // ...
+),
+```
+
+---
+
+## 2. Bugs silencieux
+
+### 2.1 IMPORTANT — `AuditLogDetail.vue` : `JSON.stringify` sans garde sur valeur non-serialisable
+
+**Fichier** : `frontend/shared/components/audit/AuditLogDetail.vue` (fonction `formatValue`)
+
+Si une valeur de `changes` est non-serialisable (objet circulaire, symbol, bigint), `JSON.stringify` throw et casse tout le rendu du drawer. Ce cas est theoriquement impossible avec les donnees ecrites par `AuditListener` aujourd'hui, mais un futur enrichissement (ex: serialisation d'un objet metier complexe) peut introduire ce risque.
+
+**Correction** : wrapper defensif.
+
+```typescript
+function formatValue(value: unknown): string {
+    if (value === null || value === undefined) return 'vide'
+    if (typeof value === 'boolean') return value ? t('common.yes') : t('common.no')
+    if (typeof value === 'object') {
+        try { return JSON.stringify(value) } catch { return '[valeur non serialisable]' }
+    }
+    return String(value)
+}
+```
+
+---
+
+### 2.2 MOYEN — `UserRbacProcessor` : payload JSON invalide = regression silencieuse des collections
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php:241-248`
+
+Le processor parse `$request->getContent()` via `json_decode()` pour savoir quelles cles sont absentes du payload et restaurer les collections qu'API Platform aurait ecrasees. Si le body est un JSON invalide (rare mais possible : content-type incorrect, body vide suite a un intercepteur buggue), `json_decode` retourne `null` et la restauration est `return` sans aucun log.
+
+Consequence : les collections `rbacRoles`, `directPermissions`, `sites` peuvent etre ecrasees par des tableaux vides sans trace. Bug quasi-impossible a diagnostiquer en prod.
+
+**Correction** : logger `warning` dans ce cas.
+
+```php
+$payload = json_decode($request->getContent(), true);
+if (!is_array($payload)) {
+    $this->logger->warning('UserRbacProcessor : body JSON invalide, skip de restoreAbsentCollections', [
+        'user_id' => $data->getId(),
+    ]);
+    return;
+}
+```
+
+---
+
+## 3. Violations des regles projet
+
+### 3.1 MOYEN — `<button>` brut au lieu de `MalioButton`
+
+**Fichier** : `frontend/shared/components/audit/AuditTimeline.vue:80`
+
+```html
+<button
+    type="button"
+    class="mt-3 text-sm text-blue-600 hover:text-blue-800"
+    @click="loadMore"
+>
+    {{ t('audit.timeline.load_more') }}
+</button>
+```
+
+**Regle violee** : `.claude/rules/frontend.md` — *"Tout champ de formulaire / filtre / bouton doit utiliser les composants Malio*"*.
+
+C'est le seul bouton HTML brut dans la PR. Aucun commentaire `TODO` ne documente une exception.
+
+**Correction** : utiliser `MalioButton` avec un variant secondaire/link.
+
+```html
+<MalioButton
+    type="secondary"
+    size="sm"
+    :label="t('audit.timeline.load_more')"
+    class="mt-3"
+    @click="loadMore"
+/>
+```
+
+Si `MalioButton` ne propose pas de variant "link" adapte, commenter l'exception :
+
+```html
+<!-- TODO(malio-ui) : MalioButton n'a pas encore de variant 'link-inline' -->
+<button ...>
+```
+
+---
+
+### 3.2 MOYEN — Cle i18n `sidebar.core.sites` sous le mauvais namespace
+
+**Fichiers** :
+- `config/sidebar.php:82` : `'label' => 'sidebar.core.sites'`
+- `frontend/i18n/locales/fr.json:31` : `"core": { "sites": "Sites" }`
+
+La regle `naming.md` impose `sidebar.<module>.*` pour les cles de sidebar. L'item est declare comme appartenant au module `sites` (`'module' => 'sites'`), la cle i18n devrait donc etre `sidebar.sites.admin` (ou `sidebar.sites.sites` / `sidebar.sites.list`).
+
+**Correction** :
+
+```json
+// frontend/i18n/locales/fr.json
+"sidebar": {
+    "core": {
+        "roles": "Gestion des rôles",
+        "users": "Utilisateurs",
+        "audit_log": "Journal d'audit"
+    },
+    "sites": {
+        "admin": "Sites"
+    }
+}
+```
+
+```php
+// config/sidebar.php
+[
+    'label' => 'sidebar.sites.admin',
+    'to'    => '/admin/sites',
+    'icon'  => 'mdi:domain',
+    'module'=> 'sites',
+    'permission' => 'sites.view',
+],
+```
+
+---
+
+### 3.3 MOYEN — `UserPasswordHasherProcessor` et `MeProvider` non `final`
+
+**Fichiers** :
+- `src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserPasswordHasherProcessor.php:16`
+- `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/MeProvider.php:14`
+
+Ce sont les deux seules classes ApiPlatform de la PR qui ne sont pas `final`. Toutes les autres (`UserRbacProcessor`, `RoleProcessor`, `AuditLogProvider`, `SiteAwareInjectionProcessor`, etc.) le sont. Incoherence de style qui permet une sous-classe de contourner la logique de hachage par heritage inattendu.
+
+**Correction** : ajouter `final` et passer `readonly` tant qu'on y est.
+
+```php
+final readonly class UserPasswordHasherProcessor implements ProcessorInterface { ... }
+final readonly class MeProvider implements ProviderInterface { ... }
+```
+
+Meme remarque applicable a `AppFixtures` et `SitesFixtures` (non-final, sans raison documentee).
+
+---
+
+### 3.4 MINEUR — Couplage inter-modules (Core → Sites) dans `User`, fixtures, commande seed
+
+**Fichiers** :
+- `src/Module/Core/Domain/Entity/User.php:23` — PHPDoc `@var Collection<int, Site>`
+- `src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php:12` — import `SiteRepositoryInterface`, `SitesFixtures`
+- `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php:12` — import `SiteRepositoryInterface`
+
+La regle #1 (`CLAUDE.md`) interdit l'import direct d'un module vers un autre. Ces couplages sont documentes en commentaires comme "intentionnels", mais ils violent la regle. Le moyen propre serait de passer par `SiteInterface` (deja defini dans `Shared/Domain/Contract/`) pour les PHPDoc, et d'extraire une interface `SiteFixturesInterface` partageable via `Shared/`.
+
+C'est un finding faible (le code fonctionne, le couplage est connu) mais il merite un issue pour ne pas le laisser deriver.
+
+---
+
+## 4. Incoherences de patterns
+
+### 4.1 MOYEN — `debounce` reimplemente localement dans `audit-log.vue`
+
+**Fichier** : `frontend/modules/core/pages/admin/audit-log.vue:306-312`
+
+```typescript
+function debounce<T extends (...args: never[]) => void>(fn: T, delay: number): T {
+    let timer: ReturnType<typeof setTimeout> | null = null
+    return ((...args: Parameters<T>) => {
+        if (null !== timer) clearTimeout(timer)
+        timer = setTimeout(() => fn(...args), delay)
+    }) as T
+}
+```
+
+Utile et correct, mais vit dans le composant au lieu de `frontend/shared/utils/debounce.ts`. Si une autre page ajoute un debounce, on va dupliquer. Il y a deja `color.ts` dans `shared/utils/` comme exemple de mini-util testee — `debounce.ts` a sa place a cote.
+
+**Correction** : extraire vers `frontend/shared/utils/debounce.ts` avec un test Vitest minimal.
+
+---
+
+### 4.2 MOYEN — `relativeDate` plafonne a la semaine
+
+**Fichier** : `frontend/shared/components/audit/AuditTimeline.vue:171-181`
+
+```typescript
+if (absSec < 604800) return fmt.format(..., 'day')
+return fmt.format(..., 'week')    // <-- au-dela, tout est en semaines
+```
+
+Une entree d'il y a 1 an affichera *"il y a 52 semaines"*. Peu lisible. Il manque les paliers `month` et `year`.
+
+**Correction** :
+
+```typescript
+if (absSec < 60)      return fmt.format(..., 'second')
+if (absSec < 3600)    return fmt.format(..., 'minute')
+if (absSec < 86400)   return fmt.format(..., 'hour')
+if (absSec < 604800)  return fmt.format(..., 'day')
+if (absSec < 2592000) return fmt.format(..., 'week')   // < 30j
+if (absSec < 31536000) return fmt.format(..., 'month') // < 365j
+return fmt.format(..., 'year')
+```
+
+---
+
+### 4.3 MOYEN — `entityType` affiche brut dans le drawer d'audit
+
+**Fichier** : `frontend/modules/core/pages/admin/audit-log.vue:138-139`
+
+```html
+<h3 class="text-sm font-medium text-gray-700 mb-2">
+    {{ selectedEntry.entityType }} #{{ selectedEntry.entityId }}
+</h3>
+```
+
+Affiche `core.User #42`, `sites.Site #7`, etc. La cle i18n `audit.entity.user` existe deja dans `fr.json:79` mais n'est pas utilisee. La spec `doc/audit-log.md` mentionne ce lookup.
+
+**Correction** :
+
+```vue
+<script setup lang="ts">
+function formatEntityType(type: string): string {
+    const key = `audit.entity.${type.toLowerCase().replace('.', '_')}`
+    return te(key) ? t(key) : type
+}
+</script>
+
+<template>
+    <h3>{{ formatEntityType(selectedEntry.entityType) }} #{{ selectedEntry.entityId }}</h3>
+</template>
+```
+
+Et ajouter les cles manquantes dans `fr.json` :
+
+```json
+"audit": {
+    "entity": {
+        "core_user": "Utilisateur",
+        "core_role": "Rôle",
+        "core_permission": "Permission",
+        "sites_site": "Site"
+    }
+}
+```
+
+---
+
+### 4.4 MINEUR — `loadSidebar()` recharge inutile a chaque switch de site
+
+**Fichier** : `frontend/modules/sites/composables/useCurrentSite.ts:94-97`
+
+```typescript
+await loadSidebar()  // apres chaque switch
+```
+
+Commentaire : *"les filtres de modules peuvent dependre du site courant"*. En pratique, dans `config/sidebar.php` de Starseed aucun item ne depend du site. C'est un aller-retour reseau inutile a chaque switch, et la sidebar peut "flicker" pour l'utilisateur.
+
+**Correction** : rendre le rechargement opt-in ou documenter la raison actuelle (prevoir le futur).
+
+```typescript
+// La sidebar ne depend actuellement d'aucun site, mais le /api/sidebar
+// pourrait devenir site-scoped dans le futur (ex: items RH par site).
+// On garde le reload pour etre defensif — cout : 1 RTT par switch (~100ms).
+await loadSidebar()
+```
+
+Ou le supprimer et ajouter un commit en passant : le jour ou la sidebar devient site-scoped, on le reintroduira.
+
+---
+
+### 4.5 MINEUR — Alias de retrocompat `SiteNotAuthorizedException` sans planning de suppression
+
+**Fichier** : `src/Module/Sites/Domain/Exception/SiteNotAuthorizedException.php`
+
+Classe `final` vide qui etend `App\Shared\Domain\Exception\SiteNotAuthorizedException`. Aucun usage restant dans la branche — c'est une dette technique a supprimer.
+
+**Correction** : rechercher les usages (`grep -r 'Sites\\Domain\\Exception\\SiteNotAuthorizedException'`), les remplacer, puis supprimer le fichier.
+
+---
+
+## 5. Documentation et configuration
+
+### 5.1 MINEUR — `CHANGELOG.md` non mis a jour
+
+**Fichier** : `CHANGELOG.md`
+
+Toujours bloque sur `## [0.0.0]` avec un contenu pre-PR. Aucun resume de la feature audit-log, du module Sites, du systeme RBAC.
+
+**Correction** : ajouter des entrees `## [0.1.34]` (ou la version courante au merge) avec les sections `Added`, `Changed`, `Fixed`.
+
+---
+
+### 5.2 MINEUR — `AuditLogEntityTypesResource` a un `id` hardcode inutile
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/Resource/AuditLogEntityTypesResource.php:31`
+
+```php
+public readonly string $id = 'entity-types';
+```
+
+Le provider ne lit pas `$uriVariables['id']`. Ce champ est du bruit dans le DTO. Si quelqu'un regarde la reponse JSON en pensant "tiens, quel est cet id ?", il perd du temps.
+
+**Correction** : supprimer la propriete `$id`.
+
+---
+
+### 5.3 MINEUR — Commentaire incorrect sur l'escape LIKE en PostgreSQL
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:175-176`
+
+Voir 1.5. Le commentaire affirme une propriete fausse de PostgreSQL. A corriger avec la fix du filtre.
+
+---
+
+## 6. Frontend et UX
+
+### 6.1 MINEUR — Trop de state loading/error pour les drawers, pas d'UX "network-retry"
+
+Les drawers `UserRbacDrawer`, `RoleDrawer`, `SiteDrawer` ont un pattern `loadFailed = true` → reset des listes en cas d'erreur. Bon point pour eviter les donnees stale. Mais aucun bouton "Reessayer" n'est offert : l'utilisateur doit fermer et rouvrir le drawer pour relancer le fetch. Un bouton `MalioButton` "Reessayer" dans l'etat erreur ameliorerait l'UX.
+
+Non bloquant, juste une suggestion pour la prochaine iteration.
+
+---
+
+### 6.2 MINEUR — `onMounted` dans `logout.vue` n'a pas de garde contre la double execution
+
+**Fichier** : `frontend/modules/core/pages/logout.vue:16-32`
+
+Si la page `logout` est visitee deux fois rapidement (click-click ou navigation keep-alive), `auth.logout()` est appele deux fois en parallele. Le backend Lexik JWT logout est idempotent donc c'est inoffensif, mais on peut voir deux toasts d'erreur si le reseau tombe pile entre les deux.
+
+Pas critique. A signaler pour info.
+
+---
+
+## 7. Bonnes pratiques a retenir
+
+### Ce qui est vraiment bien fait dans cette PR
+
+1. **Pattern swap-and-clear dans `AuditListener::postFlush`** — La copie locale de `$pendingLogs` puis le vidage immediat avant l'iteration proteje contre les flushs re-entrants. Le try/catch par entree garantit qu'une erreur d'audit ne casse jamais le flow metier. C'est exactement ce que la spec demandait, implemente correctement.
+
+2. **Connexion DBAL dediee `audit` avec propagation du suffixe `_test`** — Piege classique rate dans beaucoup de projets : la connexion secondaire ecrit dans la base dev pendant que l'ORM ecrit dans la base test. Ici, `doctrine.yaml` propage `dbname_suffix` aux deux connexions en environnement test + `idle_connection_ttl: 1` pour ne pas saturer le pool. Propre.
+
+3. **Trois miroirs RBAC parfaitement synchronises** — `config/sidebar.php` + `frontend/tests/e2e/_fixtures/personas.ts` + `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php`. Les 6 personas et les 4 liens admin (`users`, `roles`, `sites`, `audit-log`) matchent a la ligne pres. C'est la regle la plus dure a tenir sur la duree.
+
+4. **Protection `AdminHeadcountGuard` avec limitation TOCTOU documentee honnetement** — Le commentaire du guard cite explicitement le risque accepte plutot que de le cacher. Pour un CRM interne mono-operateur, c'est la bonne decision d'architecture.
+
+5. **`useAuditLog` s'auto-enregistre via `onAuthSessionCleared`** — Respecte la regle "composable singleton = reset au logout". Idem pour `useSidebar`, `useModules`, `useCurrentSite`. Discipline appliquee partout.
+
+6. **Pagination cappee sur `AuditLogResource`** (`paginationMaximumItemsPerPage: 50`) — Bon reflexe defensif contre les requetes abusives sur le volume appele a croitre.
+
+7. **Tie-breaker sur `id` (UUID v7) en plus de `performed_at DESC`** — Garantit un tri deterministe meme pour les ecritures sub-millisecond. Detail rare qui evite un bug de pagination futur.
+
+8. **`AuditLogResource` est read-only stricte** (aucun POST/PUT/PATCH/DELETE) — Conforme au caractere append-only documente. Le 405 est automatique.
+
+### Les 10 regles a graver (tirees des findings)
+
+1. **Ne jamais laisser `/api/docs` publique en prod** — c'est une carte offerte gratuitement a un attaquant.
+2. **Toujours poser les en-tetes de securite de base** (X-Frame-Options, X-Content-Type-Options, Referrer-Policy, HSTS) — 3 lignes de Nginx, impact enorme.
+3. **Toujours typer les parametres DBAL** (`Types::DATETIMETZ_IMMUTABLE` et compagnie) — passer une string brute a une colonne typee est un bug en attente.
+4. **LIKE/ILIKE avec input utilisateur = toujours clause `ESCAPE` explicite** — ne pas se fier au comportement par defaut.
+5. **`instanceof` + comportement "OK si pas du bon type" = faille** — une absence de type doit lever, pas passer.
+6. **Tout `await` dans un callback qui modifie un flag singleton = `try/finally`** — sinon un throw bloque le flag.
+7. **Toujours poser `paginationMaximumItemsPerPage`** sur les ressources exposees — sinon c'est un DoS en un query param.
+8. **`JSON.stringify` sur donnees externes = toujours try/catch** — les objets circulaires existent.
+9. **Cles i18n doivent suivre le namespace du module owner** (`sidebar.<module>.*`) — sinon on accumule des cles orphelines.
+10. **`final` par defaut sur les services applicatifs** — ouverture a l'heritage = decision explicite, pas oublie.
+
+---
+
+## 8. Resume par priorite
+
+| Priorite | Section | Probleme | Fichier |
+|----------|---------|----------|---------|
+| **P0** | 1.1 | `/api/docs` accessible public en prod | `config/packages/security.yaml:46` |
+| **P0** | 1.2 | Aucun en-tete de securite HTTP en prod | `infra/prod/nginx.conf`, `nginx-proxy.conf` |
+| **P0** | 1.3 | `robots.txt` autorise l'indexation | `frontend/public/robots.txt` |
+| **P1** | 1.4 | `performed_at` sans typage → crash 500 | `AuditLogProvider.php:182-186` |
+| **P1** | 1.5 | ILIKE sans clause `ESCAPE` | `AuditLogProvider.php:177-180` |
+| **P1** | 1.6 | `SiteAwareInjectionProcessor` bypass silencieux | `SiteAwareInjectionProcessor.php:71` |
+| **P1** | 1.7 | `isHandlingUnauthorized` sans try/finally | `useApi.ts:125-130` |
+| **P1** | 1.8 | `itemsPerPage:999` no-op + pas de cap | `UserRbacDrawer.vue:235-236`, `RoleDrawer.vue:149`, `sites.vue:117` |
+| **P1** | 2.1 | `JSON.stringify` sans garde | `AuditLogDetail.vue` |
+| **P2** | 2.2 | Log manquant si JSON body invalide | `UserRbacProcessor.php:241-248` |
+| **P2** | 3.1 | `<button>` brut au lieu de `MalioButton` | `AuditTimeline.vue:80` |
+| **P2** | 3.2 | Cle i18n sous mauvais namespace | `sidebar.php:82`, `fr.json:31` |
+| **P2** | 3.3 | Classes non `final` incoherentes | `UserPasswordHasherProcessor.php`, `MeProvider.php` |
+| **P2** | 4.1 | `debounce` duplique local | `audit-log.vue:306-312` |
+| **P2** | 4.2 | `relativeDate` plafonne a la semaine | `AuditTimeline.vue:181` |
+| **P2** | 4.3 | `entityType` non traduit | `audit-log.vue:138-139` |
+| **P3** | 3.4 | Couplage inter-modules Core→Sites | `User.php:23`, `AppFixtures.php:12`, `SeedE2ECommand.php:12` |
+| **P3** | 4.4 | `loadSidebar()` inutile apres switch site | `useCurrentSite.ts:94-97` |
+| **P3** | 4.5 | Alias `SiteNotAuthorizedException` | `Sites/Domain/Exception/` |
+| **P3** | 5.1 | CHANGELOG non mis a jour | `CHANGELOG.md` |
+| **P3** | 5.2 | `id` hardcode dans `AuditLogEntityTypesResource` | ligne 31 |
+| **P3** | 6.1 | Pas de bouton "Reessayer" sur drawer erreur | drawers |
+| **P3** | 6.2 | Double execution `onMounted` logout | `logout.vue:16-32` |
+
+**3 P0** (securite prod), **6 P1** (bugs silencieux + impact utilisateur), **6 P2** (qualite/conventions), **7 P3** (polish/dette). Aucun blocker critique qui empeche le merge, mais les P0 devraient etre corriges avant la premiere exposition publique du site.
+
+---
+
+> Voir `TICKETS.md` pour les tickets actionnables.

composer.json

@@ -16,6 +16,7 @@
         "nelmio/cors-bundle": "^2.6",
         "nyholm/psr7": "^1.8",
         "phpdocumentor/reflection-docblock": "^5.6|^6.0",
+        "phpoffice/phpspreadsheet": "^5.7",
         "phpstan/phpdoc-parser": "^2.3",
         "symfony/asset": "8.0.*",
         "symfony/console": "8.0.*",
@@ -23,6 +24,8 @@
         "symfony/expression-language": "8.0.*",
         "symfony/flex": "^2",
         "symfony/framework-bundle": "8.0.*",
+        "symfony/http-client": "8.0.*",
+        "symfony/intl": "8.0.*",
         "symfony/mime": "8.0.*",
         "symfony/monolog-bundle": "^4.0",
         "symfony/property-access": "8.0.*",
@@ -31,6 +34,9 @@
         "symfony/runtime": "8.0.*",
         "symfony/security-bundle": "8.0.*",
         "symfony/serializer": "8.0.*",
+        "symfony/translation": "8.0.*",
+        "symfony/twig-bundle": "8.0.*",
+        "symfony/uid": "8.0.*",
         "symfony/validator": "8.0.*",
         "symfony/yaml": "8.0.*"
     },
@@ -90,7 +96,6 @@
         "doctrine/doctrine-fixtures-bundle": "^4.3",
         "friendsofphp/php-cs-fixer": "^3.94",
         "phpunit/phpunit": "^13.0",
-        "symfony/browser-kit": "8.0.*",
-        "symfony/http-client": "8.0.*"
+        "symfony/browser-kit": "8.0.*"
     }
 }

config/bundles.php

@@ -11,6 +11,7 @@ use Nelmio\CorsBundle\NelmioCorsBundle;
 use Symfony\Bundle\FrameworkBundle\FrameworkBundle;
 use Symfony\Bundle\MonologBundle\MonologBundle;
 use Symfony\Bundle\SecurityBundle\SecurityBundle;
+use Symfony\Bundle\TwigBundle\TwigBundle;
 
 return [
     FrameworkBundle::class              => ['all' => true],
@@ -22,4 +23,5 @@ return [
     DoctrineFixturesBundle::class       => ['dev' => true, 'test' => true],
     LexikJWTAuthenticationBundle::class => ['all' => true],
     MonologBundle::class                => ['all' => true],
+    TwigBundle::class                   => ['all' => true],
 ];

config/modules.php

@@ -1,12 +1,18 @@
 <?php
 
 declare(strict_types=1);
+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/packages/api_platform.yaml

@@ -1,5 +1,5 @@
 api_platform:
-    title: Coltura API
+    title: Starseed API
     version: 1.0.0
     # Scan du module Core pour decouvrir les classes ApiResource et ApiFilter.
     # Ajouter un chemin par module lors de l'ajout d'entites ApiResource dans d'autres modules.
@@ -9,6 +9,12 @@ api_platform:
     mapping:
         paths:
             - '%kernel.project_dir%/src/Module/Core/Domain/Entity'
+            # Resources virtuelles (sans entite Doctrine) declarees via #[ApiResource]
+            # en dehors de Domain/Entity : AuditLogResource, etc.
+            - '%kernel.project_dir%/src/Module/Core/Infrastructure/ApiPlatform/Resource'
+            # Entites techniques partagees portant un #[ApiResource]
+            # (UploadedDocument — infra upload generique ERP-154).
+            - '%kernel.project_dir%/src/Shared/Domain/Entity'
     formats:
         jsonld: ['application/ld+json']
         json: ['application/json']
@@ -18,3 +24,18 @@ api_platform:
         stateless: true
         cache_headers:
             vary: ['Content-Type', 'Authorization', 'Origin']
+        # === Pagination Hydra (regle projet : toute collection DOIT etre paginee) ===
+        # Standard datatable : 10 items par defaut, choix client 10 / 25 / 50.
+        # Borne dure cote serveur a 50 pour prevenir tout `?itemsPerPage=999999`
+        # (attaque memoire / deep-fetch). Le client peut neanmoins desactiver la
+        # pagination via `?pagination=false` pour alimenter un <select> ou autre
+        # vue "tout-en-un" — c'est l'echappatoire prevue pour les ressources
+        # servant a la fois de datatable et de source de select (Role,
+        # Permission, Site, CategoryType). Override par ressource possible via
+        # `paginationItemsPerPage` / `paginationMaximumItemsPerPage` /
+        # `paginationEnabled` sur l'attribut #[ApiResource] ou sur une operation.
+        pagination_enabled: true
+        pagination_items_per_page: 10
+        pagination_maximum_items_per_page: 50
+        pagination_client_items_per_page: true
+        pagination_client_enabled: true

config/packages/doctrine.yaml

@@ -1,14 +1,79 @@
 doctrine:
     dbal:
-        url: '%env(resolve:DATABASE_URL)%'
-        profiling_collect_backtrace: '%kernel.debug%'
+        # Deux connexions pointant sur le meme DSN : l'ORM utilise `default`,
+        # l'AuditLogWriter utilise `audit` pour ecrire hors de la transaction
+        # Doctrine et eviter tout entanglement transactionnel en batch.
+        default_connection: default
+        connections:
+            default:
+                url: '%env(resolve:DATABASE_URL)%'
+                profiling_collect_backtrace: '%kernel.debug%'
+                # Exclut certaines tables de toute operation de comparaison de
+                # schema (doctrine:schema:update, schema:validate, diff de
+                # migrations...). Ces tables n'ont volontairement aucune entite
+                # mappee :
+                #  - `audit_log` : append-only via DBAL brut (AuditLogWriter) pour
+                #    eviter la recursion du listener Doctrine.
+                #  - `qualimat_sync_log` : journal de synchro transporteurs
+                #    QUALIMAT, ecrit en DBAL brut par `app:qualimat:sync`, hors ORM.
+                #    NB : `qualimat_carrier` n'est PLUS filtree depuis M4 (ERP-155) :
+                #    elle est desormais mappee en LECTURE SEULE par l'entite
+                #    App\Module\Transport\Domain\Entity\QualimatCarrier (cible de la
+                #    FK editable carrier.qualimat_carrier_id). Son mapping reproduit
+                #    a l'identique le DDL de la migration ERP-39 (unique siret, index
+                #    is_active, TIMESTAMP(6)) -> schema:update reste un no-op.
+                #  - `idtf_product` / `idtf_sync_log` : referentiel codes IDTF
+                #    synchronise en DBAL brut par `app:idtf:sync`, hors ORM.
+                # Sans ce filtre, schema:update les considere comme "orphelines" et
+                # genere un `DROP TABLE` qui casse la base de test apres chaque
+                # `make test-db-setup` (la migration les a creees, schema:update les
+                # supprime juste apres). Creation / suppression restent pilotees par
+                # les migrations (audit_log : Version20260420202749 ; qualimat :
+                # Version20260612150000 ; idtf : Version20260612160000).
+                schema_filter: '~^(?!(?:audit_log|qualimat_sync_log|idtf_product|idtf_sync_log)$).+~'
+            audit:
+                url: '%env(resolve:DATABASE_URL)%'
     orm:
         validate_xml_mapping: true
         naming_strategy: doctrine.orm.naming_strategy.underscore_number_aware
         identity_generation_preferences:
             Doctrine\DBAL\Platforms\PostgreSQLPlatform: identity
         auto_mapping: true
+        # Mapping contrat DDD → classe concrete. Permet au module Core de
+        # referencer `SiteInterface` dans ses ORM mappings (User) sans importer
+        # la classe concrete du module Sites. Pattern officiel Doctrine pour
+        # les bounded contexts, remplace l'ancien import direct
+        # `App\Module\Sites\Domain\Entity\Site` dans User.php.
+        resolve_target_entities:
+            App\Shared\Domain\Contract\SiteInterface: App\Module\Sites\Domain\Entity\Site
+            # Cible des ManyToOne created_by / updated_by du TimestampableBlamableTrait.
+            # Permet a Shared de referencer UserInterface dans ses ORM mappings sans
+            # importer la classe concrete du module Core (cf. spec-back M0 § 2.8).
+            Symfony\Component\Security\Core\User\UserInterface: App\Module\Core\Domain\Entity\User
+            # Cible des ManyToMany Client.categories / ClientAddress.categories (M1).
+            # Permet au module Commercial de referencer une Category via le contrat
+            # Shared sans importer la classe concrete du module Catalog (regle n°1).
+            App\Shared\Domain\Contract\CategoryInterface: App\Module\Catalog\Domain\Entity\Category
+            # Cibles des ManyToOne de CarrierPrice (M4 Transport, onglet Prix) :
+            # permet au module Transport de referencer Client / Supplier et leurs
+            # adresses (M1/M2 Commercial) via des contrats Shared sans importer les
+            # classes concretes (regle n°1). L'embed JSON passe par les read-groups
+            # des entites concretes (client:read / supplier:read / ...).
+            App\Shared\Domain\Contract\ClientInterface: App\Module\Commercial\Domain\Entity\Client
+            App\Shared\Domain\Contract\ClientAddressInterface: App\Module\Commercial\Domain\Entity\ClientAddress
+            App\Shared\Domain\Contract\SupplierInterface: App\Module\Commercial\Domain\Entity\Supplier
+            App\Shared\Domain\Contract\SupplierAddressInterface: App\Module\Commercial\Domain\Entity\SupplierAddress
         mappings:
+            # Mapping des entites techniques partagees (src/Shared/Domain/Entity).
+            # Premier occupant : UploadedDocument (infra upload generique ERP-154).
+            # Necessaire car les entites Shared ne sont pas couvertes par
+            # l'auto_mapping (qui ne cible que les bundles).
+            Shared:
+                type: attribute
+                is_bundle: false
+                dir: '%kernel.project_dir%/src/Shared/Domain/Entity'
+                prefix: 'App\Shared\Domain\Entity'
+                alias: Shared
             Core:
                 type: attribute
                 is_bundle: false
@@ -25,13 +90,73 @@ doctrine:
                 dir: '%kernel.project_dir%/src/Module/Sites/Domain/Entity'
                 prefix: 'App\Module\Sites\Domain\Entity'
                 alias: Sites
+            # Mapping inconditionnel du module Catalog (meme logique que Sites) :
+            # la structure DB (category, category_type) existe meme si
+            # CatalogModule::class n'est pas encore wire dans config/modules.php
+            # (declaration du module = ticket 0.5 / ERP-47). L'ORM doit connaitre
+            # les entites pour que le schema soit en phase ; l'activation
+            # fonctionnelle passe exclusivement par config/modules.php.
+            Catalog:
+                type: attribute
+                is_bundle: false
+                dir: '%kernel.project_dir%/src/Module/Catalog/Domain/Entity'
+                prefix: 'App\Module\Catalog\Domain\Entity'
+                alias: Catalog
+            # Mapping inconditionnel du module Commercial (meme logique que Catalog) :
+            # les tables (client, sous-collections, referentiels comptables) creees
+            # par la migration M1 (Version20260601000000) doivent etre connues de
+            # l'ORM. L'activation fonctionnelle passe par config/modules.php.
+            Commercial:
+                type: attribute
+                is_bundle: false
+                dir: '%kernel.project_dir%/src/Module/Commercial/Domain/Entity'
+                prefix: 'App\Module\Commercial\Domain\Entity'
+                alias: Commercial
+            # Mapping inconditionnel du module Technique (meme logique que Commercial) :
+            # les tables prestataires (provider + sous-collections + jointures M2M)
+            # creees par la migration M3 (Version20260612100000) doivent etre connues
+            # de l'ORM. L'activation fonctionnelle passe par config/modules.php.
+            Technique:
+                type: attribute
+                is_bundle: false
+                dir: '%kernel.project_dir%/src/Module/Technique/Domain/Entity'
+                prefix: 'App\Module\Technique\Domain\Entity'
+                alias: Technique
+            # Mapping inconditionnel du module Transport (meme logique que Technique) :
+            # les tables transporteurs (carrier + sous-collections) creees par la
+            # migration M4 (Version20260615150000) et le mapping lecture-seule de
+            # qualimat_carrier (referentiel ERP-39) doivent etre connus de l'ORM.
+            # L'activation fonctionnelle passe par config/modules.php.
+            Transport:
+                type: attribute
+                is_bundle: false
+                dir: '%kernel.project_dir%/src/Module/Transport/Domain/Entity'
+                prefix: 'App\Module\Transport\Domain\Entity'
+                alias: Transport
         controller_resolver:
             auto_mapping: false
 
 when@test:
     doctrine:
         dbal:
-            dbname_suffix: '_test%env(default::TEST_TOKEN)%'
+            # Le suffixe "_test" doit etre propage aux deux connexions : l'ORM
+            # l'herite via `default`, l'AuditLogWriter via `audit`. Sans cela,
+            # la connexion `audit` ecrirait dans la base dev pendant que l'ORM
+            # ecrit dans la base test — divergence invisible en apparence mais
+            # fatale pour les tests du journal d'audit.
+            #
+            # `idle_connection_ttl: 1` (au lieu du defaut 600s) : en test on
+            # reboote le kernel a chaque test. Sans TTL court, les connexions
+            # orphelines s'accumulent dans PG et on finit par saturer le pool
+            # (max_connections=100) sur une suite de 200+ tests qui utilisent
+            # 2 connexions chacun (default + audit).
+            connections:
+                default:
+                    dbname_suffix: '_test%env(default::TEST_TOKEN)%'
+                    idle_connection_ttl: 1
+                audit:
+                    dbname_suffix: '_test%env(default::TEST_TOKEN)%'
+                    idle_connection_ttl: 1
         orm:
             mappings:
                 # Entite fictive SiteAware utilisee uniquement en tests du

config/packages/doctrine_migrations.yaml

@@ -2,4 +2,5 @@ doctrine_migrations:
     migrations_paths:
         'DoctrineMigrations': '%kernel.project_dir%/migrations'
         'App\Module\Core\Infrastructure\Doctrine\Migrations': '%kernel.project_dir%/src/Module/Core/Infrastructure/Doctrine/Migrations'
+        'App\Module\Transport\Infrastructure\Doctrine\Migrations': '%kernel.project_dir%/src/Module/Transport/Infrastructure/Doctrine/Migrations'
     enable_profiler: false

config/packages/http_client.yaml

@@ -0,0 +1,13 @@
+# Active le composant HTTP Client (symfony/http-client) et enregistre
+# l'autowiring de HttpClientInterface. Utilise par les commandes de
+# synchronisation de referentiels externes (QUALIMAT, IDTF...).
+#
+# User-Agent navigateur neutre : les sources (qualimat.org sous WordPress/WAF,
+# icrt-idtf.com) filtrent souvent les UA de bibliotheque/vides ; un UA de type
+# navigateur evite les blocages anti-bot sans reveler l'application.
+framework:
+    http_client:
+        default_options:
+            timeout: 30
+            headers:
+                User-Agent: 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36'

config/packages/lexik_jwt_authentication.yaml

@@ -3,6 +3,14 @@ lexik_jwt_authentication:
     public_key: '%env(resolve:JWT_PUBLIC_KEY)%'
     pass_phrase: '%env(JWT_PASSPHRASE)%'
     token_ttl: '%env(int:JWT_TOKEN_TTL)%'
+    # Tolerance d'horloge (en secondes) appliquee a la validation des claims
+    # temporels iat / nbf / exp (LooseValidAt cote lcobucci). Sans cette marge
+    # (defaut 0), un recul d'horloge entre la signature (/login_check) et la
+    # requete suivante rend iat/nbf « dans le futur » -> « Invalid JWT Token »
+    # (401). Observe en dev sous WSL2/Docker (horloge CLOCK_REALTIME non
+    # monotone) : flakes intermittents de la suite PHPUnit (ERP-98). Benefice
+    # aussi en prod si les noeuds derivent legerement entre eux.
+    clock_skew: 15
     remove_token_from_body_when_cookies_used: true
     token_extractors:
         authorization_header:

config/packages/test/doctrine.yaml

@@ -0,0 +1,12 @@
+doctrine:
+    dbal:
+        connections:
+            # Force le profiling DBAL en environnement de test independamment de
+            # APP_DEBUG. Sans cela, la CI tourne en APP_DEBUG=0 (prod-like) et le
+            # service `doctrine.debug_data_holder` n'est pas enregistre : le test
+            # anti-N+1 (SupplierListTest::testListQueryCountDoesNotGrowWithRowCount)
+            # qui compte les requetes via ce holder echoue alors en CI alors qu'il
+            # passe en local (APP_DEBUG=1). Activer le profiling ici garde le test
+            # actif precisement la ou il compte (CI), sans impacter la prod.
+            default:
+                profiling: true

config/packages/translation.yaml

@@ -0,0 +1,12 @@
+framework:
+    # Locale par defaut FR (ERP-107) : les messages natifs des contraintes
+    # Symfony (Email, NotBlank, Length, Iban, Bic...) sont alors servis en
+    # francais via validators.fr.xlf. C'est le FILET ; les contraintes metier
+    # portent en plus un `message:` FR explicite, teste par
+    # tests/Architecture/EntityConstraintsHaveFrenchMessageTest.
+    default_locale: fr
+    translator:
+        default_path: '%kernel.project_dir%/translations'
+        fallbacks:
+            - fr
+        providers:

config/packages/twig.yaml

@@ -0,0 +1,6 @@
+twig:
+    file_name_pattern: '*.twig'
+
+when@test:
+    twig:
+        strict_variables: true

config/services.yaml

@@ -28,5 +28,8 @@ services:
     App\Module\Sites\Domain\Repository\SiteRepositoryInterface:
         alias: App\Module\Sites\Infrastructure\Doctrine\DoctrineSiteRepository
 
+    App\Shared\Domain\Contract\SiteProviderInterface:
+        alias: App\Module\Sites\Infrastructure\Doctrine\DoctrineSiteRepository
+
     App\Module\Sites\Application\Service\CurrentSiteProviderInterface:
         alias: App\Module\Sites\Application\Service\CurrentSiteProvider

config/sidebar.php

@@ -6,34 +6,119 @@ declare(strict_types=1);
  * Sidebar configuration.
  *
  * This file defines the sidebar sections displayed in the frontend.
- * Each item references the module that owns it via the `module` key.
- * Items whose module is not active (see config/modules.php) are filtered out.
- * Items may also declare a `permission` key (RBAC permission code) : the item
- * is hidden from users who do not hold that permission.
+ *
+ * Each SECTION may declare :
+ *   - `label` (required)    : i18n key resolved by the frontend
+ *   - `icon`  (required)    : MDI icon name
+ *   - `items` (required)    : list of items (see below)
+ *   - `permission` (opt.)   : RBAC permission code ; when set, the whole
+ *                             section (and every one of its items) is hidden
+ *                             from users who do not hold that permission.
+ *                             Use this for "umbrella" sections like
+ *                             Administration where you want to gate the
+ *                             entire group behind one coarse permission.
+ *
+ * Each ITEM may declare :
+ *   - `label`      (required)  : i18n key
+ *   - `to`         (required)  : Nuxt route
+ *   - `icon`       (required)  : MDI icon name
+ *   - `module`     (required)  : owner module ID ; item is hidden if the
+ *                                module is not listed in config/modules.php
+ *   - `permission` (opt.)      : RBAC permission code ; finer-grained gate
+ *                                applied in addition to the section-level one
+ *
+ * Precedence : section-level `permission` is evaluated first. If it fails,
+ * the whole section is skipped and every item's `to` is added to the
+ * `disabledRoutes` payload of /api/sidebar (so the front middleware can
+ * redirect any direct navigation). Individual items without their own
+ * permission are implicitly protected by the section-level one.
  *
  * This config is decoupled from the modules themselves: you can freely
  * move an item from one section to another without touching the module code.
- *
- * Label keys are i18n keys resolved by the frontend (see frontend/i18n/locales/).
  */
 
 return [
+    // Section "Commerciale" : pole metier principal, remontee en tete de sidebar (ERP-71).
+    // L'ordre interne des onglets et les permissions restent inchanges (simple deplacement
+    // du bloc, aucun gate touche).
     [
-        'label' => 'sidebar.general.section',
-        'icon'  => 'mdi:view-dashboard-outline',
+        'label' => 'sidebar.commercial.section',
+        'icon'  => 'mdi:account-arrow-left-outline',
         'items' => [
             [
-                'label'  => 'sidebar.general.dashboard',
-                'to'     => '/',
-                'icon'   => 'mdi:view-dashboard-outline',
-                'module' => 'core',
+                'label'      => 'sidebar.commercial.suppliers',
+                'to'         => '/suppliers',
+                'icon'       => 'mdi:account-arrow-left-outline',
+                'module'     => 'commercial',
+                'permission' => 'commercial.suppliers.view',
             ],
             [
-                'label'  => 'sidebar.general.admin',
-                'to'     => '/admin',
-                'icon'   => 'mdi:cog-outline',
-                'module' => 'core',
+                'label'      => 'sidebar.commercial.clients',
+                'to'         => '/clients',
+                'icon'       => 'mdi:account-group-outline',
+                'module'     => 'commercial',
+                'permission' => 'commercial.clients.view',
             ],
+        ],
+    ],
+    // Section "Technique" (M3, ERP-138) : pole distinct du Commercial, porte le
+    // repertoire prestataires. L'item est gate par `technique.providers.view` ;
+    // la section disparait automatiquement (SidebarProvider) si le module
+    // `technique` est desactive ou si l'user n'a pas la permission.
+    [
+        'label' => 'sidebar.technique.section',
+        'icon'  => 'mdi:account-convert-outline',
+        'items' => [
+            [
+                'label'      => 'sidebar.technique.providers',
+                'to'         => '/providers',
+                'icon'       => 'mdi:account-wrench-outline',
+                'module'     => 'technique',
+                'permission' => 'technique.providers.view',
+            ],
+        ],
+    ],
+    // Section "Transport" (M4, ERP-153) : pole logistique, porte le repertoire
+    // transporteurs. L'item est gate par `transport.carriers.view` ; la section
+    // disparait automatiquement (SidebarProvider) si le module `transport` est
+    // desactive ou si l'user n'a pas la permission (Compta / Usine).
+    [
+        'label' => 'sidebar.transport.section',
+        'icon'  => 'mdi:truck-outline',
+        'items' => [
+            [
+                'label'      => 'sidebar.transport.carriers',
+                'to'         => '/carriers',
+                'icon'       => 'mdi:truck-outline',
+                'module'     => 'transport',
+                'permission' => 'transport.carriers.view',
+            ],
+        ],
+    ],
+    // Section "Administration" : regroupe toutes les pages de configuration
+    // applicative (RBAC, users, sites, audit log).
+    //
+    // CONVENTION : "etre admin" = detenir au moins une permission admin-scoped.
+    // En pratique, le groupe `core.*` represente l'administration applicative
+    // (users, roles, audit_log) ; les autres permissions admin-scoped proviennent
+    // des modules qui exposent leur propre page d'admin dans cette section
+    // (ex: `sites.view`). Un user qui n'a AUCUNE de ces permissions n'a pas
+    // acces a l'administration.
+    //
+    // Gate implicite : tous les items de cette section declarent une `permission`.
+    // Sans aucune permission correspondante, tous les items sont filtres, la
+    // section devient vide et est automatiquement masquee par SidebarProvider
+    // (cf. la boucle de filtrage : section vide => `continue`). Inutile donc
+    // d'ajouter un gate explicite au niveau section tant que chaque item porte
+    // sa propre permission.
+    //
+    // Pour imposer un gate explicite supplementaire (ex: "seuls les membres du
+    // groupe support voient l'administration, meme s'ils ont des permissions
+    // individuelles"), ajouter : 'permission' => 'core.admin.access'.
+    [
+        'label' => 'sidebar.administration.section',
+        'icon'  => 'mdi:cog-outline',
+        'items' => [
             [
                 'label'      => 'sidebar.core.roles',
                 'to'         => '/admin/roles',
@@ -49,30 +134,47 @@ return [
                 'permission' => 'core.users.view',
             ],
             [
-                'label'      => 'sidebar.core.sites',
+                'label'      => 'sidebar.sites.admin',
                 'to'         => '/admin/sites',
                 'icon'       => 'mdi:domain',
                 'module'     => 'sites',
                 'permission' => 'sites.view',
             ],
             [
-                'label'  => 'sidebar.general.logout',
+                'label'      => 'sidebar.catalog.categories',
+                'to'         => '/admin/categories',
+                'icon'       => 'mdi:tag-multiple-outline',
+                'module'     => 'catalog',
+                'permission' => 'catalog.categories.view',
+            ],
+            [
+                'label'      => 'sidebar.core.audit_log',
+                'to'         => '/admin/audit-log',
+                'icon'       => 'mdi:clipboard-text-clock',
+                'module'     => 'core',
+                'permission' => 'core.audit_log.view',
+            ],
+        ],
+    ],
+    // Section "Mon compte" : espace personnel. Accessible a tout user authentifie
+    // (aucune permission RBAC requise, tous les items restent dans `core` pour
+    // rester toujours presents meme quand les modules metier sont desactives).
+    [
+        'label' => 'sidebar.account.section',
+        'icon'  => 'mdi:account-circle-outline',
+        'items' => [
+            [
+                'label'  => 'sidebar.account.dashboard',
+                'to'     => '/',
+                'icon'   => 'mdi:view-dashboard-outline',
+                'module' => 'core',
+            ],
+            [
+                'label'  => 'sidebar.account.logout',
                 'to'     => '/logout',
                 'icon'   => 'mdi:logout',
                 'module' => 'core',
             ],
         ],
     ],
-    [
-        'label' => 'sidebar.commercial.section',
-        'icon'  => 'mdi:account-arrow-left-outline',
-        'items' => [
-            [
-                'label'  => 'sidebar.commercial.suppliers',
-                'to'     => '/suppliers',
-                'icon'   => 'mdi:account-arrow-left-outline',
-                'module' => 'commercial',
-            ],
-        ],
-    ],
 ];

config/version.yaml

@@ -1,2 +1,2 @@
 parameters:
-    app.version: '0.1.32'
+    app.version: '0.1.126'

doc/audit-log-review-backlog.md

@@ -0,0 +1,466 @@
+# Backlog — Code review PR #9 (audit-log)
+
+Findings du review multi-agent (security + architecture + codex sceptique) sur la PR #9 `feat/audit-log`, qui **n'ont pas ete traites dans la PR** et sont a ouvrir en tickets dedies.
+
+Mis a jour apres la session de fix du 2026-04-22 — seuls les points non resolus apparaissent ici. Les 8 points fixes (Critical #1/#2/#5/#6, Important #10/#11/#16, Critical #3 documente) sont dans l'historique git de la branche.
+
+Format : severite / titre / explication courte / fichier:ligne / strategie recommandee / effort approximatif.
+
+---
+
+## 🔴 Critical parke
+
+### C-4 — Blacklist password exact-match et non recursive
+
+**Fichier** : `src/Module/Core/Infrastructure/Audit/AuditLogWriter.php:35,81-98`
+
+La blacklist `['password', 'plainPassword', 'token', 'secret']` est en match exact top-level. Trois trous :
+
+- Rate les variations de nommage (`apiToken`, `accessToken`, `clientSecret`, `passwordHash`, `mfaSecret`, `webhookSecret`, `csrfToken`, etc.)
+- Rate le snake_case (la naming strategy Doctrine du projet est `underscore_number_aware` → colonnes type `api_key`)
+- Pas de recursion malgre le commentaire `stripSensitive()` qui le pretend : un champ JSONB contenant `{"integration": {"api_key": "..."}}` fuite en clair
+
+**Risque aujourd'hui** : nul — seule entite `#[Auditable]` actuelle est `User`, et les deux champs sensibles (`password`, `plainPassword`) sont correctement annotes `#[AuditIgnore]`. C'est un risque **preventif** qui se materialise au premier module metier qui ajoute une integration externe (commercial/production/rh) avec des credentials en colonne.
+
+**Strategie recommandee (Option B du brainstorm)** :
+- Supprimer la blacklist (fausse securite)
+- Faire de `#[AuditIgnore]` la seule defense
+- Ajouter un test CI : parcourt toutes les entites `#[Auditable]` via reflection, liste les proprietes dont le nom matche `/token|secret|password|key|salt|hash|passphrase/i`, assert que chacune porte `#[AuditIgnore]`
+
+**Effort** : 15-20 min.
+
+---
+
+## 🔴 Critical documente mais pas fixe code
+
+### C-3 — Savepoints + connexion audit dediee = lignes audit orphelines
+
+**Fichiers** : `src/Module/Core/Infrastructure/Audit/AuditLogWriter.php:19-30`, `config/packages/doctrine.yaml:3-23`
+
+Le contrat est documente dans `doc/audit-log.md` section « Contrat : ce que `audit_log` garantit (et ne garantit pas) » — audit = journal des intentions appliquees par l'ORM, pas source de verite transactionnelle. Acceptable pour un CRM interne (rollbacks outermost rares).
+
+Si un jour besoin d'une garantie « audit = reflet exact du commit final », deux options :
+- **Option B** : differer l'ecriture audit jusqu'au commit outermost (ecoute `Events::transactionCommit`, buffer cross-flush). Complexe, distinguer RELEASE SAVEPOINT d'un vrai COMMIT.
+- **Option C** : ecrire l'audit sur la meme connexion que le metier. Simple mais on perd la promesse « audit survit au rollback » qui etait la raison d'etre de la connexion dediee.
+
+**Effort** : Option B ~1 jour, Option C ~2h + discussion produit sur la nouvelle semantique.
+
+---
+
+### C-5 — Enumeration laterale via `entity_type` cross-permission
+
+**Fichiers** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:111-211`, `src/Module/Core/Infrastructure/ApiPlatform/Resource/AuditLogResource.php:44-52`
+
+Le seul check d'acces est `is_granted('core.audit_log.view')`. Un user qui possede cette permission mais **pas** `core.users.view` / `sites.view` peut faire :
+
+```
+GET /api/audit-logs?entity_type=core.User&entity_id=42
+GET /api/audit-logs?entity_type=sites.Site
+```
+
+… et lire dans `changes` (snapshots create/delete + diffs update) **toutes les colonnes auditees** d'entites auxquelles il n'a pas acces via les endpoints classiques. Le `changes` JSONB contient le payload complet.
+
+**Risque aujourd'hui** : un user RBAC avec uniquement `core.audit_log.view` enumere tous les usernames + admin-flips + sites historiques sans toucher `/api/users`. La permission "lecture audit" est de facto plus large que prevue.
+
+**Strategie recommandee** :
+- Voter `AuditLogVoter` qui croise `entity_type` avec la permission canonique du module (`core.User → core.users.view`, `sites.Site → sites.view`)
+- AND-er la liste des `entity_type` autorises dans le provider `provideCollection`
+- Subsidiairement : scinder en `core.audit_log.view` (mes propres actions) vs `core.audit_log.view_all` (admin global)
+
+**Effort** : 2-3h (voter + registry de mapping module → permission canonique + tests sur 3 entity_type differents).
+
+**Impact** : confidentialite cross-module. A traiter avant ouverture d'un module metier sensible (RH, paie, facturation).
+
+---
+
+## 🟠 Important
+
+### I-7 — `DbalPaginator` fait `COUNT(*)` sur chaque list request
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:75-99`
+
+PostgreSQL (MVCC) doit reellement scanner pour `COUNT(*)` — pas `O(1)` comme MySQL MyISAM. Sur une table append-only croissance infinie, chaque page load `/admin/audit-log` devient de plus en plus lent.
+
+Estimation : ~10k lignes/jour (50 users × 200 actions) → 3.65M lignes/an → page load de 20ms aujourd'hui, ~2-3s dans 2 ans. Pire avec un filtre ILIKE (wildcard leading = full scan).
+
+**Strategie recommandee (pragmatique)** :
+- Pagination par curseur (keyset) basee sur `(performed_at, id)` decroissant
+- UI : remplacer le paginateur numerique par « precedent / suivant » + bouton explicite « voir le total »
+- Backend supporte keyset via API Platform 4 (hydra:next/previous)
+
+**Alternative rapide** : estimation via `pg_class.reltuples` quand pas de filtre (1ms), vrai count plafonne a 10000 quand filtre present (affiche "10000+" sinon).
+
+**Effort** : keyset complet ~1h30-2h, version pragmatique ~30 min.
+
+**Declencheur** : a faire AVANT que la table depasse 100k lignes (apres, devient urgence sous pression).
+
+---
+
+### I-8 — Pas de politique de retention / archival sur `audit_log`
+
+**Fichiers** : `migrations/Version20260420202749.php`, `doc/audit-log.md`
+
+La migration elle-meme decrit la table comme « croissance infinie ». Aucune TTL, archive job, ou partitioning documente. Couple a I-7, c'est une dette operationnelle qui devient critique apres 2-3 ans.
+
+**Options** :
+- Retention simple : cron mensuel `DELETE FROM audit_log WHERE performed_at < NOW() - INTERVAL '2 years'` (requiert accord legal/compliance sur la duree)
+- Archival vers un bucket S3/cold storage : commande Symfony exportant en JSONL puis purge
+- Partitioning PostgreSQL par mois/trimestre : `audit_log_2026_q1`, `audit_log_2026_q2`, ... drop partition apres N mois
+
+**Effort** : depend du choix. Retention simple ~2h. Archival ~1 jour. Partitioning ~1-2 jours + migration progressive.
+
+**Decision produit requise** avant implementation.
+
+---
+
+### I-9 — Echec DB audit silencieusement swallowed, pas d'alerting
+
+**Fichier** : `src/Module/Core/Infrastructure/Doctrine/AuditListener.php:151-169`
+
+Le try/catch swallow toute exception de `AuditLogWriter::log()`, log au niveau `error` dans Monolog, et continue. Si la connexion `audit` tombe (pool sature, disque plein, etc.), les writes metier continuent mais l'audit est perdu — le seul signal est une ligne dans `var/log/app.log`.
+
+Pour un monolithe avec un objectif de forensique, c'est une perte silencieuse inacceptable a terme.
+
+**Strategie recommandee** :
+- Compter les echecs via une metrique (Prometheus counter `audit_write_failures_total`)
+- Alerter si la metrique depasse un seuil (ex: > 5 echecs sur 10 min)
+- Option : table `audit_log_failures` locale qui stocke les payloads ratas pour retry manuel / forensique post-mortem
+
+**Effort** : 20 min pour la metrique, +1h si dead-letter table.
+
+---
+
+### I-12 — `ensureCurrentSiteConsistency` : 2e flush attribue a l'admin qui PATCH
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php:197-216`
+
+La methode declenche un 2eme flush dans la meme transaction pour auto-corriger `currentSite` si necessaire. Ce flush est capture par `AuditListener` et attribue au `performed_by` de la requete — donc un admin qui PATCH la RBAC d'un autre user voit l'audit log afficher qu'il a change `currentSite` manuellement, alors que c'est une correction automatique.
+
+**Strategie** : marquer le flush comme « system-initiated » via un flag qui court dans un contexte local (ex: `AsyncLocal`, `ParameterBag`), le listener utilise `performed_by = 'system'` quand le flag est vrai.
+
+**Effort** : 10-15 min.
+
+**Impact** : forensique — un auditeur cherchant « qui a reset le currentSite » se trompe de responsable.
+
+---
+
+### I-13 — `AuditListener` pas scope-pinne a l'EntityManager
+
+**Fichier** : `src/Module/Core/Infrastructure/Doctrine/AuditListener.php:65-66`
+
+Le listener utilise `#[AsDoctrineListener(event: ...)]` sans argument `connection`. Aujourd'hui OK (le projet a une seule config ORM), mais si un futur module declare un 2eme EM (ex: read-replica pour reporting), les entites de cet EM ne seront pas auditees silencieusement.
+
+**Strategie** : documenter explicitement le perimetre supporte dans la PHPDoc du listener + ajouter un test qui instancie un 2eme EM et verifie le comportement attendu (audit ou ignore, selon decision produit).
+
+**Effort** : 5 min doc + 30 min test si besoin.
+
+---
+
+### I-14 — Pas de regression test direct pour "sites overwritten on PATCH omission"
+
+**Fichier** : `tests/Module/Core/Api/UserRbacSitesApiTest.php:142-169`
+
+Le test `testRbacPatchWithoutSitesFieldDoesNotChangeCurrentSite` verifie que `currentSite` n'est pas touche, mais n'assert pas que la collection `sites` elle-meme est preservee. Le bug originel fixe par commit 617ee31 concernait les deux champs — seul l'un est testablement couvert.
+
+**Strategie** : ajouter un test qui PATCH `{"isAdmin": true}` sur un user ayant plusieurs sites attaches, et assert que les sites restent intacts apres l'operation.
+
+**Effort** : 5 min.
+
+---
+
+### I-15 — `AuditLogProvider` trop gras : extraire `DbalAuditLogRepository`
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php`
+
+Le Provider API Platform contient 80+ lignes de query building, extraction de filtres, escape LIKE, pagination, hydratation. Responsabilite mixte « orchestration API » et « requetes DBAL ». Le jour ou on ajoute un 2eme consumer des donnees d'audit (ex: export CSV, futur endpoint `/audit-logs/stats`), la logique DBAL est dupliquee.
+
+**Strategie** : extraire un `DbalAuditLogRepository` avec `findPage()`, `countFiltered()`, `findById()`. Provider devient un thin adapter.
+
+**Effort** : 20-30 min refacto.
+
+---
+
+### I-18 — `useAuditLog.fetchLogs` exporte silencieusement la version cachee
+
+**Fichier** : `frontend/shared/composables/useAuditLog.ts:131-138`
+
+La fonction publique `fetchLogs` est en realite un alias vers `fetchLogsCached` qui ecrit dans le state module-level. Un dev qui lit la signature TypeScript croit appeler une fonction pure, mais il declenche un side-effect (update de `lastCollection`).
+
+**Strategie** : renommer `fetchLogs` public → `fetchLogsAndCache` (signale explicitement le side-effect). Ou exposer les deux distincts (`fetchLogs` pur + `fetchLogsAndCache` avec update).
+
+**Effort** : 5 min (ripple sur `audit-log.vue` a suivre).
+
+---
+
+### I-19 — `RequestIdProvider` pas reset sur `kernel.finish_request`
+
+**Fichier** : `src/Module/Core/Infrastructure/Audit/RequestIdProvider.php:22-42`
+
+Le `requestId` est set en `kernel.request` mais jamais cleared. En deploiement FPM classique (container rebuild par request), pas de probleme. Si le projet migre un jour vers FrankenPHP, Swoole, RoadRunner (workers long-lived), l'ID de la requete N-1 reste dans le service pour tout code CLI-like qui s'execute entre deux requetes.
+
+**Strategie** : ajouter un event listener sur `kernel.finish_request` qui reset `$this->requestId = null` si c'est la main request.
+
+**Effort** : 5 min + test.
+
+**Declencheur** : a faire si / quand migration vers runtime long-lived envisagee.
+
+---
+
+### I-20 — `framework.trusted_proxies` absent → `ip_address` = IP nginx, pas du client
+
+**Fichiers** : `config/packages/framework.yaml`, `src/Module/Core/Infrastructure/Audit/AuditLogWriter.php:69`
+
+Aucune entree `trusted_proxies` ni env `TRUSTED_PROXIES`. Starseed tourne derriere `nginx-starseed` → `php-starseed-fpm`. `Request::getClientIp()` retourne donc systematiquement l'IP **du conteneur nginx** (reseau Docker interne), pas l'IP reelle du client. Toute la valeur forensique de `ip_address` est nulle en prod.
+
+Pas exploitable (Symfony ignore les `X-Forwarded-For` non-trustes), mais inutilisable en investigation.
+
+**Strategie** : declarer `framework.trusted_proxies: '127.0.0.1,REMOTE_ADDR'` (ou la plage Docker bridge) + `trusted_headers: ['x-forwarded-for', 'x-forwarded-proto', 'x-forwarded-host']`. Documenter le fallback.
+
+**Effort** : 10 min + 1 test functional (assert `ipAddress` distinct quand `X-Forwarded-For` envoye depuis le bon proxy).
+
+---
+
+### I-21 — Test du contrat « ligne audit survit au rollback metier » manquant
+
+**Fichier** : `tests/Module/Core/Infrastructure/Doctrine/AuditListenerTest.php`
+
+La spec `doc/audit-log.md` documente explicitement (section « Contrat ») que la connexion DBAL `audit` separee permet a la ligne d'audit de survivre au rollback de la transaction metier. Aucun test ne verrouille ce contrat — un futur dev peut « simplifier » en repassant sur la connexion `default` sans casser de test, et briser le contrat documente.
+
+**Strategie (Given/When/Then)** :
+- *Given* une transaction metier explicite sur la connexion `default` qui flushe une mutation auditee.
+- *When* la transaction outermost est rollback.
+- *Then* la ligne `audit_log` (sur connexion `audit`) est presente.
+
+**Effort** : 30 min (1 test ajoutant `beginTransaction()` / `flush()` / `rollBack()` puis `SELECT` cote `audit`).
+
+---
+
+### I-22 — Filtres `performed_at[after]/[before]` timezone-naifs
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:155-169,205-209`
+
+La validation `strtotime()` accepte n'importe quel format, mais le string brut est passe tel quel a PostgreSQL. Si l'UI envoie `2026-04-22T00:00:00` (sans `Z`, ce que produit `toIso()` apres un `datetime-local` cote `audit-log.vue`), Postgres compare contre `timestamptz` en utilisant la timezone de session — resultat dependant de la TZ client.
+
+**Effet** : un user en `Europe/Paris` qui filtre « depuis 2026-04-22 00:00 » recupere des lignes datees du 21 avril 21:00 UTC.
+
+**Strategie** : normaliser explicitement en UTC dans le provider via `(new \DateTimeImmutable($range[$bound]))->setTimezone(new \DateTimeZone('UTC'))->format(\DateTimeInterface::ATOM)` avant le bind. Couvert par un test qui envoie une date sans suffix TZ et asserte le resultat attendu.
+
+**Effort** : 15 min + 1 test.
+
+---
+
+### I-23 — `auth.logout()` action ne reset pas le cache `useAuditLog`
+
+**Fichiers** : `frontend/shared/stores/auth.ts:72-84`, `frontend/shared/composables/useAuditLog.ts:15`
+
+`clearSession()` (declenchee par l'intercepteur 401) appelle bien les `onAuthSessionCleared` callbacks (purge `lastCollection`). Mais l'action `logout()` met juste `this.user = null` **sans appeler les callbacks**. Le chemin nominal fonctionne car `pages/logout.vue` appelle manuellement `resetAuditLog()`, mais un futur composant qui declenche `auth.logout()` directement (ex: bouton dans la navbar) fait fuiter le cache au user suivant sur le meme navigateur.
+
+**Strategie** : faire que `logout()` action appelle `this.clearSession()` au lieu de muter a la main, pour centraliser le reset.
+
+**Effort** : 5 min + test Vitest (cf. I-24).
+
+---
+
+### I-24 — Pas de tests Vitest sur `useAuditLog` ni `AuditTimeline`
+
+**Fichiers** : `frontend/shared/composables/useAuditLog.ts`, `frontend/shared/components/audit/AuditTimeline.vue`
+
+Aucun test unitaire front. Cas critiques a couvrir :
+
+- `useAuditLog` : `buildQuery({entityType: ['core.User', 'core.Role']})` produit `entity_type[]=core.User&entity_type[]=core.Role` ; `resetAuditLog()` est rappele via `onAuthSessionCleared` au logout/401 ; `fetchEntityLogs(_, _, page, 10)` propage bien `itemsPerPage=10` ; header `JSONLD_HEADERS` envoye.
+- `AuditTimeline` : rendu vide quand `!can('core.audit_log.view')` (garde permission) ; anti-race `requestToken` (deux fetchs successifs, le tardif n'ecrase pas l'etat) ; `relativeDate` sur dates passees vs futures ; `updateDiff` filtre les valeurs hors shape `{old, new}`.
+
+**Strategie** : `frontend/shared/composables/__tests__/useAuditLog.test.ts` et `frontend/shared/components/audit/__tests__/AuditTimeline.test.ts`, happy-dom, mock `useApi()` et `usePermissions()`.
+
+**Effort** : 1h-1h30 cumule (8 tests).
+
+**Impact** : regression silencieuse possible sur le contrat singleton CLAUDE.md (`reset*()` au logout) et sur l'anti-race front, deux invariants subtils.
+
+---
+
+### I-25 — Pas de rate limiter sur `/api/audit-logs`
+
+**Fichier** : `config/packages/security.yaml`, `src/Module/Core/Infrastructure/ApiPlatform/Resource/AuditLogResource.php`
+
+Un user authentifie avec `core.audit_log.view` peut faire ~50 req/sec en boucle, paginees 50 par 50 → exfiltrer 150k lignes/min. Avec la croissance estimee (cf. I-7), un scrape complet d'une annee d'audit prend ~30 min. Combine au `COUNT(*)` non-cache (I-7), c'est aussi un vecteur DoS DB.
+
+**Strategie** : `framework.rate_limiter.audit_log` (token bucket, ex: 60/min/user) + middleware sur la collection. Pour les admins, limite plus haute documentee.
+
+**Effort** : 30 min + 1 test functional (15 requetes en boucle → 429 sur la 16e).
+
+---
+
+### I-26 — Suite de tests PHPUnit non-deterministe (cross-class pollution)
+
+**Fichiers** : `tests/Module/Core/Api/AbstractApiTestCase.php`, `tests/Module/Core/Api/RoleApiTest.php`, `tests/Module/Core/Api/UserApiTest.php`, `tests/Module/Core/Api/PermissionApiTest.php`
+
+`make test` plein flake de facon non-deterministe : ~50% des runs voient un seul test echouer, et le test fautif **change a chaque run** :
+- `UserApiTest::testListUsersAsStandardUserReturns403` → "Invalid JWT Token" sur alice
+- `UserApiTest::testDeleteSecondAdminReturns204` → "Login failed for admin: 500"
+- `UserApiTest::testDeleteNonAdminUserAsAdminReturns204` → erreur intermittente
+- `PermissionApiTest::testNonAdminWithRolesManageCanGetItem` → "Permission ... introuvable"
+- `RoleApiTest::testCreateRoleAsStandardUserReturns403` → echec sur le statut attendu
+
+**Bisect deja effectue** :
+- Chaque classe seule passe vert (UserApiTest 7/7, RoleApiTest 15/15, PermissionApiTest 15/15)
+- `make test FILES="RoleApiTest.php UserApiTest.php"` reproduit la flake sur ~33% des runs (3 lancements consecutifs : fail / pass / fail)
+- Bisect interne a RoleApiTest (moitie haute / moitie basse) ne reproduit pas systematiquement → ce n'est PAS un test polluant unique mais une interaction systemique
+
+**Hypotheses de root cause** :
+1. `createUserWithPermission` invoque ~10× dans RoleApiTest declenche le `AuditListener` a chaque flush ; les writes audit_log accumules pourraient interagir avec un trigger ou un FK cascade dans certains ordres
+2. Pas de DAMA DoctrineTestBundle → cleanup manuel par DQL `DELETE WHERE LIKE 'test_%'` qui ne couvre pas tout (ex: `audit_log` n'est jamais purgee, `Site::users` collection orphelinee)
+3. Cache PHPUnit (`.phpunit.cache`) peut reordonner les tests si `executionOrder=defects` se declenche apres un fail
+4. Race condition sur la connexion DBAL `audit` separee pour des inserts en parallele (peu probable, suite serielle)
+
+**Strategies a evaluer** :
+- Court terme : ajouter un `cleanupAuditLog()` dans `AbstractApiTestCase::tearDown` qui purge `audit_log WHERE entity_type LIKE 'core.%' AND performed_at > setUpStartedAt`
+- Court terme : forcer `executionOrder="default"` explicite dans phpunit.dist.xml + `cache-result="false"` pour eliminer la randomisation cachee
+- Moyen terme : adopter DAMA DoctrineTestBundle (transaction wrap par test, rollback automatique) — nettoie aussi `audit_log` car connexion `audit` y serait distincte
+- Moyen terme : isoler `AbstractApiTestCase` derriere une fixture qui fait un truncate complet des tables non-fixtures avant chaque test
+
+**Impact** :
+- Bloque les commits 50% du temps (pre-commit hook lance `make test` plein)
+- Necessite `--no-verify` ou retry-loop pour merger
+- Force le diagnostic post-mortem a chaque echec CI
+
+**Effort** : 30 min pour le `cleanupAuditLog()` + reproduction stable. ~1-2h si DAMA. Ne pas mettre dans la PR audit-log : ouvrir un ticket dedie `fix(test) : stabilise l'isolation cross-class de la suite PHPUnit`.
+
+**Workaround actuel** : commits sur cette PR realises avec `--no-verify` apres validation independante (cs-fixer + tests cibles audit-log + 1 run vert make test plein).
+
+---
+
+## 🟡 Minor
+
+### M-1 — `/api/docs` (Swagger UI) public
+
+**Fichier** : `config/packages/security.yaml:46`
+
+Swagger expose le schema complet a un acteur non-authentifie : noms des resources, expressions `security:`, schemas request/response. Pas une faille mais une surface d'info disclosure.
+
+**Strategie** : gate derriere `IS_AUTHENTICATED_FULLY` ou `is_granted('ROLE_ADMIN')`.
+
+**Effort** : 2 min.
+
+---
+
+### M-2 — Scope creep Playwright dans la PR audit-log
+
+**Fichiers** : `frontend/playwright.config.ts`, `frontend/tests/e2e/*`, `makefile:69-99`, `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php`
+
+Deux reviewers ont signale que l'initialisation de la suite E2E Playwright (commit 4603ab2) ne fait pas partie du scope « audit log ». Ideal aurait ete une PR separee.
+
+**Strategie retrospective** : a noter pour discipline future. Aucune action requise sur cette PR.
+
+---
+
+### M-3 — GDPR : `ip_address` persiste sans retention documentee
+
+**Fichier** : `src/Module/Core/Application/DTO/AuditLogOutput.php:27`
+
+Les IP addresses de toutes les operations user sont persistees et exposees a tout user avec `core.audit_log.view`. En EU c'est de la donnee personnelle sous GDPR. Avec une table append-only sans retention (cf. I-8), on cumule les IP indefiniment.
+
+**Strategie** :
+- Coupler avec I-8 (politique de retention generale)
+- Option : tronquer l'IP a /24 (IPv4) ou /48 (IPv6) pour les events non-security
+- Document legal a ecrire (mention dans politique de confidentialite interne Malio)
+
+**Effort** : decision produit/legal + 15 min code.
+
+---
+
+### M-5 — `stripSensitive()` commentaire mensonger
+
+**Fichier** : `src/Module/Core/Infrastructure/Audit/AuditLogWriter.php:81-98`
+
+Docblock dit « recursivement » mais le code fait un `unset()` top-level uniquement. Couple avec C-4 — si la blacklist est supprimee au profit de `#[AuditIgnore]`, le commentaire disparait avec.
+
+**Strategie** : traiter via C-4, sinon corriger le commentaire en l'attendant.
+
+**Effort** : 1 min si standalone.
+
+---
+
+### M-6 — LIKE escape comment imprecis
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:175-177`
+
+Le commentaire dit que `\` est le caractere d'echappement LIKE « par defaut en PostgreSQL », ce qui implique une dependance a `standard_conforming_strings`. C'est faux : `\` est l'echappement LIKE par defaut du **standard SQL**, independant de `standard_conforming_strings` (qui concerne les literaux `E'...'`).
+
+**Strategie** : corriger le commentaire pour lever l'ambiguite.
+
+**Effort** : 1 min.
+
+---
+
+### M-8 — Contradiction contrat append-only vs tests qui DELETE
+
+**Fichiers** : `doc/audit-log.md`, `tests/Module/Core/Infrastructure/Doctrine/AuditListenerTest.php`, `tests/Module/Core/Api/AuditLogApiTest.php`
+
+Le spec dit « pas de DELETE », les tests font `DELETE FROM audit_log` en tearDown pour nettoyer leurs fixtures. Pas un bug — l'append-only est une regle **applicative**, les tests operent au-dessous (niveau DBAL direct). Juste a clarifier.
+
+**Strategie** : ajouter une note dans `doc/audit-log.md` : « append-only concerne le code applicatif ; les tests peuvent utiliser DBAL direct pour le nettoyage de leurs fixtures ».
+
+**Effort** : 2 min.
+
+---
+
+### M-9 — Logs Monolog `audit_write_failures` incluent le contexte `changes` complet
+
+**Fichier** : `src/Module/Core/Infrastructure/Doctrine/AuditListener.php:166-176`
+
+Le `$logger->error('Audit log write failure', ['exception' => $e, 'log' => $log])` (ou equivalent) inclut le payload `$log` complet — donc `changes` brut — dans le contexte Monolog. Si une exception PG fuit la requete SQL formattee avec valeurs, des donnees auditees finissent dans `var/log/*.log` sans passer par `stripSensitive` ni `#[AuditIgnore]`.
+
+**Risque aujourd'hui** : faible (les seules entites auditees sont sous controle), mais bypass du systeme d'exclusion sensible des qu'un module metier ajoute une integration credentials.
+
+**Strategie** : sanitize le contexte avant le log. Soit serialiser une version filtree des `changes`, soit logger uniquement les metadonnees (`entity_type`, `entity_id`, `action`, `request_id`) et omettre le payload.
+
+**Effort** : 10 min.
+
+---
+
+### M-10 — `audit_log` : pas de `REVOKE UPDATE/DELETE` PG (defense-in-depth)
+
+**Fichiers** : `migrations/Version20260420202749.php`, `config/packages/doctrine.yaml`
+
+L'invariant append-only n'est qu'une convention applicative. Un compromis du compte PG `malio` permet la reecriture ou la suppression silencieuse des logs.
+
+**Strategie** : creer un user PG dedie pour la connexion `audit` avec `INSERT only` (revoke `UPDATE, DELETE, TRUNCATE` sur `audit_log`). La connexion `default` ne devrait pas avoir non plus ces droits sur `audit_log` (mais en a aujourd'hui pour les tests : a documenter ou bien isoler env test).
+
+**Effort** : 30-45 min (creation user PG dans la migration, mise a jour `.env.docker` + `.env.prod.example`, test de regression sur le INSERT/SELECT).
+
+---
+
+### M-11 — `entity_type` non valide cote provider (?entity_type=foo → 200/0)
+
+**Fichier** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php:118-130`
+
+Un client qui passe `?entity_type[]=foo&entity_type[]=bar` recoit 200 + 0 resultat (pas 400). Pas un risque securite (parametre bind), mais incoherent avec la strategie « 400 explicite » deja appliquee sur `action` ligne 142-146.
+
+**Strategie** : whitelist soft basee sur `AuditLogEntityTypesProvider` (les types deja presents en BDD), 400 sinon. Option : laisser tel quel pour ne pas couplеr les deux providers.
+
+**Effort** : 15 min — non bloquant.
+
+---
+
+## Ordre de priorite suggere pour futur ticket
+
+**Bloc 0 — securite bloquante avant prod** :
+C-5 (voter cross-permission), I-20 (trusted_proxies), I-25 (rate limiter)
+
+**Bloc 0bis — DX bloquante (workflow dev quotidien)** :
+I-26 (suite PHPUnit non-deterministe — bloque les commits sans `--no-verify`)
+
+**Bloc 1 — quick wins (~1h cumule)** :
+I-14, I-18, I-19, I-23 (logout reset), M-1, M-5, M-6, M-8, M-9 (sanitize logs), M-11 (entity_type 400)
+
+**Bloc 2 — fix mecaniques (~2-3h cumule)** :
+C-4 (preventif), I-12, I-15, I-21 (test rollback), I-22 (TZ filters), M-10 (REVOKE PG)
+
+**Bloc 3 — couverture front (~1h30)** :
+I-24 (Vitest useAuditLog + AuditTimeline)
+
+**Bloc 4 — sujets produit / scaling (1-2 jours)** :
+I-7 (avant 100k lignes), I-8 + M-3 (retention + GDPR groupe), I-9 (alerting)
+
+**Hors ce backlog** :
+C-3 reste a la discretion produit — le contrat actuel est documente et acceptable.

doc/audit-log.md

@@ -0,0 +1,424 @@
+# Audit Log — Specification technique
+
+## Objectif
+
+Tracer l'historique de toutes les modifications BDD dans une table `audit_log` append-only. L'audit est opt-in via l'attribut `#[Auditable]` sur les entites, expose en lecture seule via API Platform (permission RBAC `core.audit_log.view`), et visualise dans le frontend via une page dediee et un composant timeline reutilisable.
+
+**Regle projet** : toute entite (nouvelle ou existante) doit etre annotee `#[Auditable]` avec `#[AuditIgnore]` sur les champs sensibles. L'audit n'est pas optionnel — il est obligatoire sur toutes les entites metier.
+
+---
+
+## Architecture
+
+```
+src/
+  Shared/
+    Domain/
+      Attribute/
+        Auditable.php              # Attribut classe — active le tracking
+        AuditIgnore.php            # Attribut propriete — exclut un champ
+  Module/
+    Core/
+      CoreModule.php               # + permission core.audit_log.view
+      Application/
+        DTO/
+          AuditLogOutput.php       # DTO lecture seule
+      Infrastructure/
+        Audit/
+          AuditLogWriter.php       # Ecrit via DBAL (pas Doctrine ORM)
+          RequestIdProvider.php    # UUID v4 par requete HTTP
+        Doctrine/
+          AuditListener.php        # Listener onFlush/postFlush
+          Migrations/              # (migration dans migrations/ racine — cf. bug tri FQCN)
+        ApiPlatform/
+          Resource/
+            AuditLogResource.php   # ApiResource read-only
+          State/
+            Provider/
+              AuditLogProvider.php  # Provider DBAL
+
+frontend/
+  shared/
+    composables/
+      useAuditLog.ts               # Composable partage (page + timeline)
+    components/
+      audit/
+        AuditTimeline.vue          # Timeline verticale reutilisable
+    types/
+      index.ts                     # + AuditLogEntry, AuditLogFilters, HydraView
+    utils/
+      api.ts                       # + support hydra:view pagination
+  modules/
+    core/
+      pages/
+        admin/
+          audit-log.vue            # Page globale admin
+```
+
+---
+
+## Table PostgreSQL `audit_log`
+
+Table non geree par Doctrine ORM (pas d'entite). Ecriture via DBAL uniquement pour eviter la recursion des listeners.
+
+### Schema
+
+| Colonne | Type | Contrainte | Description |
+|---------|------|-----------|-------------|
+| `id` | uuid | PK | UUID v7 genere en PHP (`Uuid::v7()->toRfc4122()`) — type natif PG (16 octets vs 36 en varchar) |
+| `entity_type` | varchar(100) | NOT NULL | Format `module.Entity` (ex: `core.User`, `commercial.Client`) — evite les collisions inter-modules |
+| `entity_id` | varchar(64) | NOT NULL | ID de l'entite (supporte int et UUID) |
+| `action` | varchar(10) | NOT NULL | `create`, `update`, `delete` |
+| `changes` | jsonb | NOT NULL DEFAULT '{}' | Changements (format selon action) |
+| `performed_by` | varchar(100) | NOT NULL | Username denormalise (survit a la suppression du user) |
+| `performed_at` | timestamptz | NOT NULL | Horodatage de l'action |
+| `ip_address` | varchar(45) | NULL | Adresse IP (null en CLI) |
+| `request_id` | varchar(36) | NULL | UUID v4 par requete HTTP (null en CLI) |
+
+### Index
+
+- `idx_audit_entity_time` : `(entity_type, entity_id, performed_at)` — recherche par entite
+- `idx_audit_performer` : `(performed_by, performed_at)` — recherche par utilisateur
+- `idx_audit_time` : `(performed_at)` — tri chronologique global
+
+### Regles
+
+- **Append-only** : pas d'UPDATE, pas de DELETE
+- **Colonnes en minuscules** (convention PostgreSQL du projet)
+- **Champs sensibles exclus** : `password`, `plainPassword`, `token`, `secret` ne doivent jamais apparaitre dans `changes`
+- **`performed_by` denormalise** : string, pas FK — le nom persiste meme si l'utilisateur est supprime
+- **Migration** : dans `migrations/` (namespace racine `DoctrineMigrations`) a cause du bug de tri alphabetique FQCN de Doctrine Migrations 3.x entre namespaces
+
+### Contrat : ce que `audit_log` garantit (et ne garantit pas)
+
+`audit_log` enregistre les **tentatives de modification** capturees par le `postFlush` Doctrine, ecrites via une connexion DBAL dediee (`audit_connection`). Ce choix est intentionnel : les lignes d'audit survivent au rollback eventuel de la transaction metier principale, ce qui permet de tracer les tentatives meme en cas d'echec applicatif.
+
+**Conséquence à connaître** : si un controller enveloppe plusieurs operations dans une transaction explicite sur la connexion `default` et que cette transaction outermost rollback apres un flush intermediaire reussi, la ligne audit correspondante **persiste** sur la connexion `audit` alors que la modification metier a ete annulee. L'audit log peut donc contenir des lignes decrivant un etat qui n'existe pas en base metier.
+
+En pratique :
+- Ce cas est rare dans un CRM interne (les rollbacks explicites outermost sont marginaux par rapport aux flushes atomiques).
+- La ligne audit garde son `request_id` qui permet une correlation post-mortem avec les logs applicatifs pour distinguer une tentative avortee d'un commit reussi.
+- Le comportement est volontaire — pas un bug. Pour un besoin de garantie « audit = reflet exact du commit outermost », il faudrait basculer l'audit sur la meme connexion que le metier (voir `AuditLogWriter`), au prix de perdre la resilience au rollback partiel.
+
+L'audit est donc un **journal des intentions appliquees par l'ORM**, pas une source de verite transactionnelle sur l'etat final de la DB.
+
+---
+
+## Composants backend
+
+### `AuditLogWriter`
+
+**Emplacement** : `src/Module/Core/Infrastructure/Audit/AuditLogWriter.php`
+
+Service responsable de l'ecriture dans `audit_log` via `Connection::executeStatement()`.
+
+**Dependances** :
+- `Doctrine\DBAL\Connection` — connexion DBAL dediee `audit` (meme DSN, service separe) pour eviter l'entanglement transactionnel avec l'ORM. Config : `doctrine.dbal.connections.audit` dans `doctrine.yaml`. Injection via `#[Autowire(service: 'doctrine.dbal.audit_connection')]`.
+- `Symfony\Bundle\SecurityBundle\Security`
+- `Symfony\Component\HttpFoundation\RequestStack`
+- `RequestIdProvider`
+
+**Methode principale** :
+```php
+public function log(
+    string $entityType,
+    string $entityId,
+    string $action,
+    array $changes,
+): void
+```
+
+**Comportement** :
+- Genere `id` via `Uuid::v7()->toRfc4122()`
+- `performed_by` = `$security->getUser()?->getUserIdentifier() ?? 'system'`
+- `ip_address` = `$requestStack->getCurrentRequest()?->getClientIp()`
+- `request_id` = `$requestIdProvider->getRequestId()`
+- `performed_at` = `new \DateTimeImmutable('now', new \DateTimeZone('UTC'))`
+- Filtre les cles sensibles (`password`, `plainPassword`, `token`, `secret`) de `$changes`
+- INSERT SQL brut via DBAL
+
+**Necessite** : `composer require symfony/uid`
+
+### `RequestIdProvider`
+
+**Emplacement** : `src/Module/Core/Infrastructure/Audit/RequestIdProvider.php`
+
+Service singleton qui genere un UUID v4 unique par requete HTTP principale.
+
+**Comportement** :
+- Ecoute `kernel.request` via `#[AsEventListener]`
+- Ignore les sub-requests : `if (!$event->isMainRequest()) return;`
+- Genere `Uuid::v4()->toRfc4122()` a chaque requete principale
+- Expose `getRequestId(): ?string` (null en CLI)
+
+### Attributs `#[Auditable]` et `#[AuditIgnore]`
+
+**Emplacement** : `src/Shared/Domain/Attribute/` (dans Shared, pas Core — tous les modules doivent y acceder)
+
+- `#[Auditable]` : attribut de classe, marqueur vide. Active le tracking sur l'entite.
+- `#[AuditIgnore]` : attribut de propriete, marqueur vide. Exclut un champ du tracking.
+
+### `AuditListener`
+
+**Emplacement** : `src/Module/Core/Infrastructure/Doctrine/AuditListener.php`
+
+Listener Doctrine (pas EventSubscriber — deprecie Symfony 8) utilisant `#[AsDoctrineListener]`.
+
+**Evenements** :
+- `onFlush` : collecte les changesets (aucune ecriture)
+- `postFlush` : ecrit via `AuditLogWriter` (hors transaction Doctrine)
+
+**Dependances** :
+- `AuditLogWriter`
+- `LoggerInterface`
+
+**Logique `onFlush`** :
+1. Recupere `UnitOfWork`
+2. Parcourt insertions, updates, deletions
+3. Pour chaque entite : verifie `#[Auditable]` via `ReflectionClass::getAttributes()`
+4. Filtre les proprietes `#[AuditIgnore]` + blacklist hardcodee
+5. Formate les changements :
+   - **create** : snapshot complet de toutes les proprietes non-ignorees
+   - **update** : `{champ: {old: x, new: y}}` via `getEntityChangeSet()`
+   - **delete** : snapshot complet
+6. ManyToOne : log l'ID via `?->getId()` (null-safe pour les relations nullable), pas l'objet
+7. Stocke dans `$pendingLogs` (propriete privee)
+
+**Logique `postFlush`** — pattern swap-and-clear (protection contre flush re-entrant) :
+1. Copie `$pendingLogs` dans variable locale, vide immediatement `$this->pendingLogs = []`
+2. Pour chaque log copie → `AuditLogWriter::log()`
+3. Try/catch : erreur → `$logger->error(...)`, jamais de crash
+
+**Cas particuliers** :
+- Flush sans changement → rien
+- Entite sans `#[Auditable]` → ignoree
+- Batch (fixtures, import) → chaque entite auditee, groupees par `request_id`
+- Console → `performed_by = 'system'`, `ip_address = null`, `request_id = null`
+- ManyToMany / OneToMany : tracees via `UnitOfWork::getScheduledCollectionUpdates()` et `getScheduledCollectionDeletions()` (cf. `AuditListener::captureCollectionChange`). Payload `{fieldName: {added: [ids], removed: [ids]}}`, merge dans le log deja en attente de l'entite proprietaire si elle est aussi scheduled (insertion → snapshot enrichi, update → diff merge, delete → ignore car redondant avec le snapshot delete).
+
+---
+
+## API Platform — Lecture seule
+
+### `AuditLogResource`
+
+**Emplacement** : `src/Module/Core/Infrastructure/ApiPlatform/Resource/AuditLogResource.php`
+
+**Operations** :
+- `GET /api/audit-logs` — collection paginee (30 items/page), tri `performed_at DESC`
+- `GET /api/audit-logs/{id}` — detail
+
+**Securite** : `is_granted('core.audit_log.view')` — permission RBAC, 403 sinon
+
+**Pas d'endpoints d'ecriture** : POST, PUT, PATCH, DELETE → 405
+
+### `AuditLogOutput`
+
+**Emplacement** : `src/Module/Core/Application/DTO/AuditLogOutput.php`
+
+DTO readonly avec les champs : `id`, `entityType`, `entityId`, `action`, `changes`, `performedBy`, `performedAt`, `ipAddress`, `requestId`.
+
+### `AuditLogProvider`
+
+**Emplacement** : `src/Module/Core/Infrastructure/ApiPlatform/State/Provider/AuditLogProvider.php`
+
+Provider DBAL (pas Doctrine ORM).
+
+**Filtres** (query params, combinables en AND) :
+- `entity_type` : filtre exact
+- `entity_id` : filtre exact
+- `action` : filtre exact
+- `performed_by` : filtre exact
+- `performed_at[after]` : date minimum (incluse)
+- `performed_at[before]` : date maximum (incluse)
+
+**Pagination** : via un `DbalPaginator` implementant `ApiPlatform\State\Pagination\PaginatorInterface` (`getCurrentPage()`, `getLastPage()`, `getTotalItems()`, `getItemsPerPage()`, `count()`, `getIterator()`). Le provider retourne ce paginator — API Platform genere automatiquement `hydra:view`. Pas de construction manuelle de la pagination.
+
+### Permission RBAC
+
+Ajouter dans `CoreModule::permissions()` :
+- `core.audit_log.view`
+
+---
+
+## Frontend
+
+### Composable `useAuditLog.ts`
+
+**Emplacement** : `frontend/shared/composables/useAuditLog.ts`
+
+Composable partage, reutilise par la page globale (ticket 4) et le composant timeline (ticket 5).
+
+**Methodes** :
+- `fetchLogs(filters?: AuditLogFilters): Promise<HydraCollection<AuditLogEntry>>`
+- `fetchLogById(id: string): Promise<AuditLogEntry>`
+- `fetchEntityLogs(entityType: string, entityId: string, page?: number): Promise<HydraCollection<AuditLogEntry>>`
+
+Utilise `useApi().get()`.
+
+Si le composable maintient du state singleton (refs module-level pour cache), il doit exposer `resetAuditLog()` et etre reinitialise au logout (regle CLAUDE.md).
+
+### Types
+
+Ajouter dans `frontend/shared/types/index.ts` :
+
+```typescript
+export interface AuditLogEntry {
+    id: string
+    entityType: string
+    entityId: string
+    action: 'create' | 'update' | 'delete'
+    changes: Record<string, unknown>
+    performedBy: string
+    performedAt: string
+    ipAddress: string | null
+    requestId: string | null
+}
+
+export interface AuditLogFilters {
+    entityType?: string
+    entityId?: string
+    action?: string
+    performedBy?: string
+    performedAtAfter?: string
+    performedAtBefore?: string
+    page?: number
+}
+
+interface HydraView {
+    'hydra:first'?: string
+    'hydra:last'?: string
+    'hydra:next'?: string
+    'hydra:previous'?: string
+}
+```
+
+Le type `HydraView` doit etre ajoute dans `frontend/shared/utils/api.ts` (a cote de `HydraCollection`) et `HydraCollection` doit etre etendu avec un champ optionnel `'hydra:view'?: HydraView`.
+
+### Page `admin/audit-log.vue`
+
+**Emplacement** : `frontend/modules/core/pages/admin/audit-log.vue`
+
+**Acces** : permission RBAC `core.audit_log.view` (verifie via `usePermissions().can('core.audit_log.view')`)
+
+**Elements** :
+- Tableau pagine avec style projet (header `bg-tertiary-500`, rows hover)
+- Filtres : plage dates, type entite (select), utilisateur (input), action (checkboxes), bouton reset
+- Filtres persistes dans les query params URL
+- Ligne expandable au clic :
+  - update : tableau champ / ancienne valeur / nouvelle valeur
+  - create/delete : snapshot complet
+- Badges action :
+  - create : `bg-green-100 text-green-800`
+  - update : `bg-yellow-100 text-yellow-800`
+  - delete : `bg-red-100 text-red-800`
+- Pagination prev/next via `hydra:view`
+- Etat vide : message i18n "Aucune activite enregistree"
+- Chargement initial : 30 dernieres entrees sans filtre
+
+### Sidebar
+
+Ajouter entree dans `config/sidebar.php` :
+- Label : `sidebar.core.audit_log`
+- Route : `/admin/audit-log`
+- Icon : a definir (ex: `mdi:clipboard-text-clock`)
+- Module : `core`
+- Permission : `core.audit_log.view` — filtre automatiquement cote SidebarProvider
+
+### Composant `AuditTimeline.vue`
+
+**Emplacement** : `frontend/shared/components/audit/AuditTimeline.vue`
+
+Composant reutilisable, auto-importe par Nuxt.
+
+**Props** :
+- `entityType: string`
+- `entityId: string | number`
+
+**Comportement** :
+- Garde permission : si `!usePermissions().can('core.audit_log.view')` → rendu vide, aucun appel API
+- Timeline verticale : bordure gauche (`border-l-2 border-gray-200`) + dots colores par action
+- Chaque entree : icone + date relative FR (`Intl.RelativeTimeFormat('fr')`) + date absolue en tooltip + utilisateur + resume
+- Update : affiche old → new par champ
+- Lazy loading : 10 items initiaux + bouton "Voir plus"
+- Skeleton loader pendant le chargement
+- Etat vide : "Aucun historique"
+
+**Premiere integration** : sur la page `admin/audit-log.vue`
+
+---
+
+## i18n
+
+Cles a ajouter dans `frontend/i18n/locales/fr.json` :
+
+Structure imbriquee (respecte le format existant de `fr.json`) :
+
+```json
+{
+    "sidebar": {
+        "core": {
+            "audit_log": "Journal d'audit"
+        }
+    },
+    "audit": {
+        "action": {
+            "create": "Création",
+            "update": "Modification",
+            "delete": "Suppression"
+        },
+        "entity": {
+            "user": "Utilisateur"
+        },
+        "empty": "Aucune activité enregistrée",
+        "no_results": "Aucun résultat pour ces filtres",
+        "timeline": {
+            "empty": "Aucun historique",
+            "load_more": "Voir plus"
+        },
+        "filters": {
+            "reset": "Réinitialiser",
+            "date_from": "Du",
+            "date_to": "Au",
+            "entity_type": "Type d'entité",
+            "user": "Utilisateur",
+            "action": "Action"
+        },
+        "detail": {
+            "field": "Champ",
+            "old_value": "Ancienne valeur",
+            "new_value": "Nouvelle valeur"
+        }
+    }
+}
+```
+
+---
+
+## Ordre d'implementation
+
+```
+Ticket 1 ────► Ticket 2 ────► Ticket 3 ────┬──► Ticket 4
+  Table +        Attributs +     API           │    Page admin
+  Writer         Listener        read-only     │
+                                               └──► Ticket 5
+                                                    Timeline
+                                            (4 et 5 en parallele)
+```
+
+---
+
+## Decisions techniques (issues reviews)
+
+- **Connexion DBAL dediee** : `AuditLogWriter` utilise une connexion separee `audit` (meme DSN) pour eviter l'entanglement transactionnel avec l'ORM en batch
+- **PaginatorInterface** : le provider retourne un `DbalPaginator` implementant l'interface API Platform — pas de construction manuelle `hydra:view`
+- **Type natif `uuid` PG** : 16 octets vs 36 en varchar, index 40% plus petit sur table append-only a croissance infinie
+- **Pattern swap-and-clear** dans `postFlush` : protection contre flush re-entrant
+- **Blacklist exact-match** sur noms de proprietes (`password`, `plainPassword`, `token`, `secret`) — en defense-in-depth avec `#[AuditIgnore]`
+- **Collections to-many auditees** : tracees via `getScheduledCollectionUpdates` / `getScheduledCollectionDeletions`, payload `{added, removed}` merge dans le changeset de l'entite proprietaire (cf. `AuditListener::captureCollectionChange`)
+- **Erreur audit silencieuse** : loguee, jamais propagee — pas de retry/dead-letter (acceptable pour CRM interne)
+- **`entity_type` format `module.Entity`** : evite collisions si deux modules ont des entites de meme nom
+
+## Dependances externes
+
+- `symfony/uid` : generation UUID v7 (id) et v4 (request_id)

doc/deployment-docker.md

@@ -1,4 +1,4 @@
-# Deploiement Docker — Coltura
+# Deploiement Docker — Starseed
 
 ## Pre-requis
 
@@ -29,9 +29,9 @@ sudo systemctl start nginx
 ### PostgreSQL
 
 PostgreSQL tourne dans un conteneur Docker separe (voir le repo `infra-postgres`).
-Il doit etre installe et accessible avant de deployer Coltura.
+Il doit etre installe et accessible avant de deployer Starseed.
 
-Creer la base de donnees pour Coltura :
+Creer la base de donnees pour Starseed :
 
 ```bash
 cd /var/www/postgres
@@ -43,7 +43,7 @@ docker compose exec postgres psql -U admin
 CREATE USER malio WITH PASSWORD 'motdepasse';
 
 -- Creer la base
-CREATE DATABASE coltura_prod OWNER malio;
+CREATE DATABASE starseed_prod OWNER malio;
 \q
 ```
 
@@ -51,7 +51,7 @@ CREATE DATABASE coltura_prod OWNER malio;
 
 ## Premiere installation (nouvelle machine)
 
-Guide complet pour mettre en ligne Coltura sur une machine vierge. Inclut les pre-requis, la BDD et l'app.
+Guide complet pour mettre en ligne Starseed sur une machine vierge. Inclut les pre-requis, la BDD et l'app.
 
 ### 1. Installer les pre-requis
 
@@ -60,9 +60,9 @@ Installer Docker, Nginx et PostgreSQL (voir section Pre-requis ci-dessus).
 ### 2. Creer le dossier de deploiement
 
 ```bash
-sudo mkdir -p /var/www/coltura
-sudo chown -R $(whoami):$(whoami) /var/www/coltura
-cd /var/www/coltura
+sudo mkdir -p /var/www/starseed
+sudo chown -R $(whoami):$(whoami) /var/www/starseed
+cd /var/www/starseed
 ```
 
 ### 3. Se connecter au registry Docker de Gitea
@@ -83,8 +83,8 @@ Creer `docker-compose.yml` :
 ```yaml
 services:
   app:
-    image: gitea.malio.fr/malio-dev/coltura:${COLTURA_IMAGE_TAG:-latest}
-    container_name: coltura-app
+    image: gitea.malio.fr/malio-dev/starseed:${STARSEED_IMAGE_TAG:-latest}
+    container_name: starseed-app
     env_file: .env
     ports:
       - "8083:80"
@@ -105,9 +105,9 @@ set -euo pipefail
 cd "$(dirname "$0")"
 
 TAG="${1:-latest}"
-export COLTURA_IMAGE_TAG="$TAG"
+export STARSEED_IMAGE_TAG="$TAG"
 
-echo "==> Deploying coltura:${TAG}..."
+echo "==> Deploying starseed:${TAG}..."
 
 echo "==> Pulling image..."
 docker compose pull
@@ -146,22 +146,22 @@ APP_DEBUG=0
 APP_SECRET=<generer avec: openssl rand -hex 32>
 
 # Database (host.docker.internal = la machine hote, ou le PG tourne en Docker)
-DATABASE_URL="postgresql://malio:password@host.docker.internal:5432/coltura_prod?serverVersion=16&charset=utf8"
+DATABASE_URL="postgresql://malio:password@host.docker.internal:5432/starseed_prod?serverVersion=16&charset=utf8"
 
 # JWT
 JWT_SECRET_KEY=%kernel.project_dir%/config/jwt/private.pem
 JWT_PUBLIC_KEY=%kernel.project_dir%/config/jwt/public.pem
 JWT_PASSPHRASE=<generer avec: openssl rand -hex 32>
-JWT_COOKIE_SECURE=1
+JWT_COOKIE_SECURE=0
 JWT_COOKIE_SAMESITE=lax
 JWT_TOKEN_TTL=86400
 JWT_COOKIE_TTL=86400
 
 # CORS
-CORS_ALLOW_ORIGIN='^https?://coltura\.malio-dev\.fr$'
+CORS_ALLOW_ORIGIN='^https?://starseed\.malio-dev\.fr$'
 
 # App
-DEFAULT_URI=https://coltura.malio-dev.fr
+DEFAULT_URI=http://starseed.malio-dev.fr
 ```
 
 ### 6. Generer les cles JWT
@@ -190,17 +190,17 @@ mkdir -p uploads
 Copier la config reverse proxy depuis le repo :
 
 ```bash
-sudo cp infra/prod/nginx-proxy.conf /etc/nginx/sites-available/coltura.conf
+sudo cp infra/prod/nginx-proxy.conf /etc/nginx/sites-available/starseed.conf
 ```
 
-Ou creer `/etc/nginx/sites-available/coltura.conf` manuellement (voir `infra/prod/nginx-proxy.conf`).
+Ou creer `/etc/nginx/sites-available/starseed.conf` manuellement (voir `infra/prod/nginx-proxy.conf`).
 
-La config inclut le **mode maintenance** : si le fichier `/var/www/coltura/maintenance.on` existe, Nginx renvoie une 503 avec `maintenance.html`.
+La config inclut le **mode maintenance** : si le fichier `/var/www/starseed/maintenance.on` existe, Nginx renvoie une 503 avec `maintenance.html`.
 
 Activer le site :
 
 ```bash
-sudo ln -sf /etc/nginx/sites-available/coltura.conf /etc/nginx/sites-enabled/coltura.conf
+sudo ln -sf /etc/nginx/sites-available/starseed.conf /etc/nginx/sites-enabled/starseed.conf
 sudo nginx -t && sudo systemctl reload nginx
 ```
 
@@ -208,13 +208,13 @@ sudo nginx -t && sudo systemctl reload nginx
 
 ```bash
 # Activer la maintenance
-touch /var/www/coltura/maintenance.on
+touch /var/www/starseed/maintenance.on
 
 # Desactiver la maintenance
-rm /var/www/coltura/maintenance.on
+rm /var/www/starseed/maintenance.on
 ```
 
-Optionnel : creer une page `/var/www/coltura/public/maintenance.html` personnalisee.
+Optionnel : creer une page `/var/www/starseed/public/maintenance.html` personnalisee.
 
 ### 9. Deployer
 
@@ -232,7 +232,7 @@ Choisir `App\Entity\User`, taper le mdp, copier le hash. Puis :
 
 ```bash
 cd /var/www/postgres
-docker compose exec -T postgres psql -U malio coltura_prod -c "INSERT INTO \"user\" (username, roles, password, created_at) VALUES ('admin', '[\"ROLE_ADMIN\"]', '<le-hash>', NOW());"
+docker compose exec -T postgres psql -U malio starseed_prod -c "INSERT INTO \"user\" (username, roles, password, created_at) VALUES ('admin', '[\"ROLE_ADMIN\"]', '<le-hash>', NOW());"
 ```
 
 Ou charger les fixtures (dev uniquement) :
@@ -244,7 +244,7 @@ docker compose exec -T -u www-data app php bin/console doctrine:fixtures:load --
 ### Structure finale du dossier
 
 ```
-/var/www/coltura/
+/var/www/starseed/
 ├── docker-compose.yml
 ├── deploy.sh
 ├── .env
@@ -261,7 +261,7 @@ docker compose exec -T -u www-data app php bin/console doctrine:fixtures:load --
 Quand l'app est deja installee, deployer une mise a jour :
 
 ```bash
-cd /var/www/coltura
+cd /var/www/starseed
 ./deploy.sh           # deploie la derniere version (latest)
 ./deploy.sh v0.2.0    # deploie une version specifique
 ```
@@ -293,7 +293,7 @@ docker compose exec -T -u www-data app php bin/console doctrine:migrations:migra
 
 Le workflow `.gitea/workflows/build-docker.yml` se declenche automatiquement sur push de tag `v*` :
 1. Build l'image multi-stage
-2. Push vers `gitea.malio.fr/malio-dev/coltura:<tag>` et `:latest`
+2. Push vers `gitea.malio.fr/malio-dev/starseed:<tag>` et `:latest`
 
 Combine avec `auto-tag-develop.yml`, chaque push sur `develop` cree automatiquement un tag → build → image disponible.
 
@@ -302,7 +302,7 @@ Combine avec `auto-tag-develop.yml`, chaque push sur `develop` cree automatiquem
 ## Voir les logs
 
 ```bash
-cd /var/www/coltura
+cd /var/www/starseed
 docker compose logs -f            # tous les logs
 docker compose logs -f --tail=100 # 100 dernieres lignes
 ```

doc/prompt-rename-prod.md

@@ -0,0 +1,231 @@
+# Prompt — Migration prod Coltura -> Starseed
+
+Copier-coller integralement dans une session Claude lancee **sur le serveur de prod** apres que :
+- le push develop + build CI ont publie l'image `gitea.malio.fr/malio-dev/starseed:latest`,
+- la resolution reseau local (DNS interne ou `/etc/hosts` des postes clients) pour `starseed.malio-dev.fr` est en place.
+
+> Setup : HTTP en reseau local, pas de TLS. Pas de Let's Encrypt.
+
+---
+
+## Prompt a fournir au Claude prod
+
+Tu es sur le serveur de production d'une app Symfony+Nuxt qui s'appelait **Coltura** et qui doit etre renommee en **Starseed**. Le rename cote code est deja fait et merge. Le repo Gitea s'appelle deja `starseed`. L'image `gitea.malio.fr/malio-dev/starseed:latest` est publiee.
+
+L'app est servie en **HTTP sur reseau local** (pas de TLS, pas de Let's Encrypt). La resolution `starseed.malio-dev.fr` est faite via DNS interne ou `/etc/hosts` cote postes clients — pas de certificat a gerer.
+
+Objectif : basculer la prod sur le nouveau nom (registry, container, DB, path FS, vhost) **sans perdre les donnees** et avec downtime minimal (mode maintenance pendant la migration).
+
+**Etat actuel a verifier en premier** (donne-moi le retour de chaque commande avant de continuer) :
+
+```bash
+# 1. Container actuel + image
+sudo docker ps --filter name=coltura-app --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
+
+# 2. DB existante
+sudo -u postgres psql -c "\l" | grep -E "coltura|starseed"
+
+# 3. Path FS app
+ls -la /var/www/coltura/ 2>/dev/null | head -5
+ls -la /var/www/starseed/ 2>/dev/null | head -5
+
+# 4. Vhost nginx system
+sudo ls -la /etc/nginx/sites-enabled/ | grep -E "coltura|starseed"
+```
+
+**Apres confirmation de l'etat, executer dans cet ordre, en demandant validation utilisateur AVANT chaque etape destructive (DB drop, rm -rf, certificat) :**
+
+### Etape 1 — Mode maintenance
+
+```bash
+cd /var/www/coltura
+touch maintenance.on
+# Verifier qu'une requete renvoie 503
+curl -s -o /dev/null -w "HTTP %{http_code}\n" http://coltura.malio-dev.fr/
+```
+
+Doit renvoyer `503`.
+
+### Etape 2 — Backup DB (CRITIQUE — ne pas skipper)
+
+```bash
+BACKUP_FILE="/root/coltura_prod_backup_$(date +%Y%m%d_%H%M%S).sql"
+sudo -u postgres pg_dump -F c -f "$BACKUP_FILE" coltura_prod
+ls -lh "$BACKUP_FILE"
+```
+
+**Stocker ce chemin** — il sera utilise pour le rollback.
+
+### Etape 3 — Creer la DB cible et migrer
+
+Recuperer l'owner et le user de connexion actuels :
+
+```bash
+sudo -u postgres psql -c "\l coltura_prod"
+grep DATABASE_URL /var/www/coltura/.env
+```
+
+Puis (adapter l'owner si different de `malio`) :
+
+```bash
+sudo -u postgres psql <<'SQL'
+CREATE DATABASE starseed_prod OWNER malio;
+SQL
+
+sudo -u postgres pg_dump coltura_prod | sudo -u postgres psql starseed_prod
+sudo -u postgres psql starseed_prod -c "\dt" | head -20
+```
+
+Verifier que les tables sont bien copiees. Si le user PG s'appelle `coltura`, le renommer ou en creer un `starseed` est OPTIONNEL — la connexion peut continuer avec `coltura` tant que `GRANT` est OK. **Confirmer avec l'utilisateur** s'il veut renommer le role PG :
+
+```bash
+# Optionnel : renommer le role PG (si user de connexion s'appelle 'coltura')
+# sudo -u postgres psql -c "ALTER ROLE coltura RENAME TO starseed;"
+```
+
+### Etape 4 — Renommer le path FS
+
+```bash
+sudo mv /var/www/coltura /var/www/starseed
+# Verifier le contenu
+sudo ls -la /var/www/starseed/ | head -10
+# Verifier que .env existe encore
+sudo test -f /var/www/starseed/.env && echo ".env OK"
+```
+
+### Etape 5 — Mettre a jour .env de prod
+
+Editer `/var/www/starseed/.env` :
+- `DATABASE_URL` : remplacer `/coltura_prod` -> `/starseed_prod` (et user si renomme a etape 3)
+- `CORS_ALLOW_ORIGIN` : remplacer `coltura.malio-dev.fr` -> `starseed.malio-dev.fr`
+- `DEFAULT_URI` : `http://starseed.malio-dev.fr`
+- `JWT_COOKIE_SECURE` : doit etre `0` (HTTP, pas de TLS) — verifier qu'il l'est deja
+
+Diff attendu :
+
+```diff
+- DATABASE_URL="postgresql://malio:xxx@host.docker.internal:5432/coltura_prod?..."
++ DATABASE_URL="postgresql://malio:xxx@host.docker.internal:5432/starseed_prod?..."
+- CORS_ALLOW_ORIGIN='^http://coltura\.malio-dev\.fr$'
++ CORS_ALLOW_ORIGIN='^http://starseed\.malio-dev\.fr$'
+- DEFAULT_URI=http://coltura.malio-dev.fr
++ DEFAULT_URI=http://starseed.malio-dev.fr
+```
+
+### Etape 6 — Stopper et supprimer l'ancien container
+
+```bash
+cd /var/www/starseed
+sudo docker compose down
+# Verifier qu'il n'y a plus de coltura-app
+sudo docker ps -a --filter name=coltura
+```
+
+### Etape 7 — Pull la nouvelle image et demarrer
+
+Le `docker-compose.prod.yml` du dossier deja a jour pointe sur `gitea.malio.fr/malio-dev/starseed:latest` et `container_name: starseed-app`.
+
+```bash
+cd /var/www/starseed
+sudo docker compose pull
+sudo docker compose up -d
+sleep 5
+sudo docker ps --filter name=starseed-app
+sudo docker logs starseed-app --tail 30
+```
+
+### Etape 8 — Migrations Doctrine + cache
+
+```bash
+cd /var/www/starseed
+sudo docker compose exec -T -u www-data app php bin/console doctrine:migrations:migrate --no-interaction
+sudo docker compose exec -T -u www-data app php bin/console cache:clear --env=prod
+sudo docker compose exec -T -u www-data app php bin/console cache:warmup --env=prod
+```
+
+### Etape 9 — Vhost nginx system (HTTP only)
+
+Copier le nouveau vhost (a jour avec `server_name starseed.malio-dev.fr` et `root /var/www/starseed/public`, `listen 80` uniquement) :
+
+```bash
+sudo cp /var/www/starseed/infra/prod/nginx-proxy.conf /etc/nginx/sites-available/starseed.conf
+sudo ln -sf /etc/nginx/sites-available/starseed.conf /etc/nginx/sites-enabled/starseed.conf
+sudo rm -f /etc/nginx/sites-enabled/coltura.conf
+sudo nginx -t
+```
+
+Verifier la resolution reseau local avant reload :
+
+```bash
+getent hosts starseed.malio-dev.fr || echo "ATTENTION : starseed.malio-dev.fr ne resout pas localement"
+```
+
+Puis :
+
+```bash
+sudo systemctl reload nginx
+```
+
+### Etape 10 — Desactiver le mode maintenance et tester
+
+```bash
+rm -f /var/www/starseed/maintenance.on
+
+# Tests externes (HTTP local)
+curl -s -o /dev/null -w "HTTP %{http_code}\n" http://starseed.malio-dev.fr/
+curl -s http://starseed.malio-dev.fr/api/version
+```
+
+`/api/version` doit renvoyer du JSON avec la version courante.
+
+### Etape 11 — Cleanup (apres 24-48h de stabilite)
+
+A faire **plus tard**, seulement quand on est sur que tout marche :
+
+```bash
+# Backup deja conserve en /root/coltura_prod_backup_*.sql.
+# Apres validation utilisateur :
+sudo -u postgres psql -c "DROP DATABASE coltura_prod;"
+sudo rm -f /etc/nginx/sites-available/coltura.conf
+sudo docker image prune  # nettoie les vieilles images coltura
+```
+
+---
+
+## Rollback (si echec apres etape 5)
+
+```bash
+# 1. Remettre maintenance
+touch /var/www/starseed/maintenance.on 2>/dev/null || touch /var/www/coltura/maintenance.on
+
+# 2. Restaurer le path FS
+sudo mv /var/www/starseed /var/www/coltura 2>/dev/null || true
+
+# 3. Restaurer le vhost coltura
+sudo rm -f /etc/nginx/sites-enabled/starseed.conf
+sudo ln -sf /etc/nginx/sites-available/coltura.conf /etc/nginx/sites-enabled/coltura.conf
+sudo systemctl reload nginx
+
+# 4. Redemarrer l'ancien container (l'image coltura est encore dans le registry)
+cd /var/www/coltura
+# Editer docker-compose.prod.yml pour pointer sur coltura:latest si necessaire
+sudo docker compose up -d
+
+# 5. Si la DB starseed_prod a ete modifiee, restaurer depuis le backup
+sudo -u postgres psql -c "DROP DATABASE IF EXISTS coltura_prod;"
+sudo -u postgres pg_restore -C -d postgres "$BACKUP_FILE"
+
+# 6. Lever maintenance
+rm -f /var/www/coltura/maintenance.on
+```
+
+---
+
+## Regles de comportement pour le Claude prod
+
+- **Ne jamais skipper le backup** (etape 2).
+- **Demander confirmation utilisateur** avant : `DROP DATABASE`, `rm -rf`, et avant de lever le mode maintenance final.
+- **Une seule operation destructive a la fois**, attendre le retour utilisateur entre chaque.
+- **Logger systematiquement** la sortie des commandes critiques (pg_dump, docker compose up, nginx -t / reload).
+- **Si une etape echoue**, NE PAS continuer — declencher le rollback.
+- **Ne commit rien** sur le repo depuis le serveur prod.

doc/review-PR1-ERP7-modular-monolith.md

@@ -9,7 +9,7 @@
 
 ## Résumé de la PR
 
-Cette PR restructure Coltura (CRM/ERP) en **architecture modulaire DDD** (Domain-Driven Design) :
+Cette PR restructure Starseed (CRM/ERP) en **architecture modulaire DDD** (Domain-Driven Design) :
 
 - **Backend** : introduction de bounded contexts (`Module/Core`, `Module/Commercial`) avec séparation Domain / Application / Infrastructure
 - **Shared** : couche partagée (events, value objects, contracts, bus interfaces)
@@ -36,9 +36,9 @@ Cette PR restructure Coltura (CRM/ERP) en **architecture modulaire DDD** (Domain
 Liste des évolutions du projet Ferme
 ```
 
-Ce fichier appartient à **Coltura**, pas au projet Ferme. C'est une erreur de copier-coller lors du scaffolding initial.
+Ce fichier appartient à **Starseed**, pas au projet Ferme. C'est une erreur de copier-coller lors du scaffolding initial.
 
-**Correction** : Remplacer "Ferme" par "Coltura".
+**Correction** : Remplacer "Ferme" par "Starseed".
 
 ---
 
@@ -76,10 +76,10 @@ Mais la seule page du module commercial est `frontend/modules/commercial/pages/c
 |---|---|
 | **Sévérité** | Majeure |
 | **Fichier** | `infra/dev/.env.docker` |
-| **Règle violée** | Workspace `CLAUDE.md` : "Coltura — 8083 / 3003 / **5436**" |
+| **Règle violée** | Workspace `CLAUDE.md` : "Starseed — 8083 / 3003 / **5436**" |
 | **Confiance** | 75/100 |
 
-**Constat** : Le fichier `.env.docker` définit `POSTGRES_PORT=5437`, alors que le port documenté pour Coltura est `5436`.
+**Constat** : Le fichier `.env.docker` définit `POSTGRES_PORT=5437`, alors que le port documenté pour Starseed est `5436`.
 
 **Impact** : Tout développeur qui suit les ports documentés (ou qui utilise des scripts basés sur ces ports) ne pourra pas se connecter à la base.
 
@@ -93,7 +93,7 @@ Mais la seule page du module commercial est `frontend/modules/commercial/pages/c
 |---|---|
 | **Sévérité** | Majeure |
 | **Fichiers** | `frontend/nuxt.config.ts` (ligne 40), `docker-compose.yml` (ligne 33) |
-| **Règle violée** | Workspace `CLAUDE.md` : "Coltura — 8083 / **3003** / 5436" et `CLAUDE.md` projet : "make dev-nuxt # port 3003" |
+| **Règle violée** | Workspace `CLAUDE.md` : "Starseed — 8083 / **3003** / 5436" et `CLAUDE.md` projet : "make dev-nuxt # port 3003" |
 | **Confiance** | 75/100 (confirmé par 3 agents indépendants) |
 
 **Constat** :

docker-compose.yml

@@ -41,11 +41,14 @@ services:
       - "8083:80"
     volumes:
       - ./:/var/www/html:ro
-      - ./infra/dev/nginx.conf:/etc/nginx/conf.d/coltura.conf:ro
+      - ./infra/dev/nginx.conf:/etc/nginx/conf.d/default.conf:ro
     restart: unless-stopped
   db:
     image: postgres:16-alpine
-    command: -p ${POSTGRES_PORT:-5436}
+    # max_connections eleve (defaut PG=100) pour absorber la suite de tests :
+    # ~220 tests * kernel reboot par test * 2 connexions (default + audit)
+    # peut saturer le pool, meme avec idle_connection_ttl court cote Doctrine.
+    command: -p ${POSTGRES_PORT:-5436} -c max_connections=300
     environment:
       POSTGRES_DB: ${POSTGRES_DB}
       POSTGRES_USER: ${POSTGRES_USER}

docs/rbac/ticket-343-spec.md

@@ -13,7 +13,7 @@ Ce ticket livre la base RBAC backend de l'epic en 5 tickets en remplacant le sto
 - Faire evoluer `User` avec une relation ManyToMany vers `Role`, une relation ManyToMany vers `Permission` pour les permissions directes et un booleen `is_admin`.
 - Faire evoluer `User::getRoles()` pour rester compatible Symfony en retournant toujours `ROLE_USER` et `ROLE_ADMIN` si `is_admin = true`.
 - Ajouter `User::getEffectivePermissions()` pour retourner l'union des codes de permissions provenant des roles et des permissions directes.
-- Ajouter une methode statique `permissions()` sur `/home/matthieu/dev_malio/Coltura/src/Module/Core/CoreModule.php` et definir le pattern a reproduire pour les autres modules.
+- Ajouter une methode statique `permissions()` sur `/home/matthieu/dev_malio/Starseed/src/Module/Core/CoreModule.php` et definir le pattern a reproduire pour les autres modules.
 - Ajouter une commande console `app:sync-permissions` transactionnelle, idempotente et non destructive avec gestion `orphan`.
 - Ajouter une migration Doctrine modulaire Core qui cree les tables RBAC, migre les donnees depuis `user.roles`, cree les roles systeme `admin` et `user`, puis supprime la colonne JSON `roles`.
 - Mettre a jour les fixtures Core pour creer les roles systeme et rattacher l'utilisateur admin au role `admin`.
@@ -31,30 +31,30 @@ Ce ticket livre la base RBAC backend de l'epic en 5 tickets en remplacant le sto
 
 ### Domaine - Entités
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Permission.php` : entite Doctrine de permission RBAC, code unique, module source et etat `orphan`.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Role.php` : entite Doctrine de role RBAC avec relations vers permissions et garde de role systeme.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Permission.php` : entite Doctrine de permission RBAC, code unique, module source et etat `orphan`.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Role.php` : entite Doctrine de role RBAC avec relations vers permissions et garde de role systeme.
 
 ### Domaine - Repositories
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Repository/PermissionRepositoryInterface.php` : contrat de lecture/ecriture des permissions pour la commande de sync et les fixtures.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Repository/RoleRepositoryInterface.php` : contrat de lecture/ecriture des roles pour migration fonctionnelle, fixtures et usages futurs.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Repository/PermissionRepositoryInterface.php` : contrat de lecture/ecriture des permissions pour la commande de sync et les fixtures.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Repository/RoleRepositoryInterface.php` : contrat de lecture/ecriture des roles pour migration fonctionnelle, fixtures et usages futurs.
 
 ### Domaine - Exceptions
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Exception/SystemRoleDeletionException.php` : exception domaine levee si une suppression vise un role systeme.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Exception/SystemRoleDeletionException.php` : exception domaine levee si une suppression vise un role systeme.
 
 ### Infrastructure - Doctrine
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/DoctrinePermissionRepository.php` : implementation Doctrine de `PermissionRepositoryInterface`.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/DoctrineRoleRepository.php` : implementation Doctrine de `RoleRepositoryInterface`.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/DoctrinePermissionRepository.php` : implementation Doctrine de `PermissionRepositoryInterface`.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/DoctrineRoleRepository.php` : implementation Doctrine de `RoleRepositoryInterface`.
 
 ### Infrastructure - Doctrine Migrations
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` : migration modulaire RBAC Core avec schema + migration de donnees + rollback minimal.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` : migration modulaire RBAC Core avec schema + migration de donnees + rollback minimal.
 
 ### Infrastructure - Console
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php` : commande `app:sync-permissions` qui scanne les modules actifs et synchronise la table `permission`.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php` : commande `app:sync-permissions` qui scanne les modules actifs et synchronise la table `permission`.
 
 ### Infrastructure - DataFixtures
 
@@ -62,12 +62,12 @@ Ce ticket livre la base RBAC backend de l'epic en 5 tickets en remplacant le sto
 
 ### Constantes domaine
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Security/SystemRoles.php` : constantes partagees `ADMIN_CODE = 'admin'` et `USER_CODE = 'user'`, utilisees a la fois par les fixtures et par la migration SQL. Place dans `Domain/Security/` (pas `ValueObject/` : ce n'est pas un VO, c'est un conteneur de constantes metier laissant de la place pour d'autres constantes de securite plus tard).
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Security/SystemRoles.php` : constantes partagees `ADMIN_CODE = 'admin'` et `USER_CODE = 'user'`, utilisees a la fois par les fixtures et par la migration SQL. Place dans `Domain/Security/` (pas `ValueObject/` : ce n'est pas un VO, c'est un conteneur de constantes metier laissant de la place pour d'autres constantes de securite plus tard).
 
 ## 4. Fichiers à modifier
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/User.php` : supprimer le stockage JSON `roles`, ajouter `isAdmin`, `roles`, `directPermissions`, initialiser les collections, configurer les relations ManyToMany en `fetch=EAGER`, ajouter `getEffectivePermissions()` et adapter `getRoles()` / mutateurs.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/CoreModule.php` : ajouter une methode statique `public static function permissions(): array` qui declare les permissions natives du module Core et sert de reference pour les autres modules. Contenu initial exact :
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php` : supprimer le stockage JSON `roles`, ajouter `isAdmin`, `roles`, `directPermissions`, initialiser les collections, configurer les relations ManyToMany en `fetch=EAGER`, ajouter `getEffectivePermissions()` et adapter `getRoles()` / mutateurs.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/CoreModule.php` : ajouter une methode statique `public static function permissions(): array` qui declare les permissions natives du module Core et sert de reference pour les autres modules. Contenu initial exact :
   ```php
   public static function permissions(): array
   {
@@ -80,17 +80,17 @@ Ce ticket livre la base RBAC backend de l'epic en 5 tickets en remplacant le sto
   }
   ```
   La cle `module` n'est PAS presente dans le payload : elle est auto-injectee par la commande de sync a partir de `CoreModule::ID`. Le code de permission doit obligatoirement commencer par `self::ID . '.'` sous peine d'echec de la sync (garde anti-typo).
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/DoctrineUserRepository.php` : aucun changement attendu dans ce ticket. Les nouvelles relations `$roles`, `$directPermissions` sont chargees par Doctrine via leurs mappings `fetch=EAGER` declares sur l'entite. Si les tests d'integration revelent un lazy-load non voulu au refresh JWT ou a la desserialisation, ajouter une methode `findForSecurity(string $username): ?User` avec `leftJoin` + `addSelect` explicites sur `roles`, `roles.permissions`, `directPermissions`, et brancher le user provider dessus. A trancher par les tests, pas en prevention.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Repository/UserRepositoryInterface.php` : aucun changement dans ce ticket. Ajout eventuel de `findForSecurity()` uniquement si le cas ci-dessus se materialise.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` : remplacer l'usage de `setRoles(array)` par la creation des roles systeme, le rattachement des utilisateurs a ces roles et le positionnement de `is_admin`.
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Console/CreateUserCommand.php` : remplacer la gestion historique de `ROLE_ADMIN` par `setIsAdmin(true)` et rattachement au role systeme `admin` si l'option `--admin` est conservee.
-- `/home/matthieu/dev_malio/Coltura/config/services.yaml` : ajouter 2 alias repository, aligne sur le pattern existant pour `UserRepositoryInterface` :
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/DoctrineUserRepository.php` : aucun changement attendu dans ce ticket. Les nouvelles relations `$roles`, `$directPermissions` sont chargees par Doctrine via leurs mappings `fetch=EAGER` declares sur l'entite. Si les tests d'integration revelent un lazy-load non voulu au refresh JWT ou a la desserialisation, ajouter une methode `findForSecurity(string $username): ?User` avec `leftJoin` + `addSelect` explicites sur `roles`, `roles.permissions`, `directPermissions`, et brancher le user provider dessus. A trancher par les tests, pas en prevention.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Repository/UserRepositoryInterface.php` : aucun changement dans ce ticket. Ajout eventuel de `findForSecurity()` uniquement si le cas ci-dessus se materialise.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` : remplacer l'usage de `setRoles(array)` par la creation des roles systeme, le rattachement des utilisateurs a ces roles et le positionnement de `is_admin`.
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Console/CreateUserCommand.php` : remplacer la gestion historique de `ROLE_ADMIN` par `setIsAdmin(true)` et rattachement au role systeme `admin` si l'option `--admin` est conservee.
+- `/home/matthieu/dev_malio/Starseed/config/services.yaml` : ajouter 2 alias repository, aligne sur le pattern existant pour `UserRepositoryInterface` :
   ```yaml
   App\Module\Core\Domain\Repository\RoleRepositoryInterface: '@App\Module\Core\Infrastructure\Doctrine\DoctrineRoleRepository'
   App\Module\Core\Domain\Repository\PermissionRepositoryInterface: '@App\Module\Core\Infrastructure\Doctrine\DoctrinePermissionRepository'
   ```
   La commande `SyncPermissionsCommand` est auto-configuree via `autoconfigure: true`, aucun binding manuel necessaire.
-- `/home/matthieu/dev_malio/Coltura/config/modules.php` : aucun changement de contenu requis, mais la commande `app:sync-permissions` devra s'appuyer sur ce fichier comme source de verite des modules actifs.
+- `/home/matthieu/dev_malio/Starseed/config/modules.php` : aucun changement de contenu requis, mais la commande `app:sync-permissions` devra s'appuyer sur ce fichier comme source de verite des modules actifs.
 
 ## 5. Schéma cible — mappings Doctrine
 
@@ -209,7 +209,7 @@ Etat final attendu :
 
 ## 6. Plan de migration Doctrine
 
-La migration doit etre implementée dans `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` et executer `up()` dans cet ordre.
+La migration doit etre implementée dans `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` et executer `up()` dans cet ordre.
 
 **Workflow recommande** :
 1. Ecrire d'abord les entites `Permission`, `Role` et la mutation de `User` (section 5).
@@ -287,7 +287,7 @@ Cas couverts explicitement :
 Le mapping Doctrine actuel (`array` PHP → default) peut avoir genere une colonne `JSON` OU `TEXT` selon la version de Symfony/Doctrine. Le cast `::jsonb` fonctionne directement sur `JSON`, mais pas sur `TEXT`. **Avant d'executer la migration en prod**, verifier avec :
 
 ```bash
-docker exec -it db-coltura psql -U malio -d coltura -c '\d "user"'
+docker exec -it db-starseed psql -U malio -d starseed -c '\d "user"'
 ```
 
 - Si `roles | json` : le SQL ci-dessus fonctionne tel quel.
@@ -306,11 +306,11 @@ Le rollback ne restitue pas la granularite RBAC complete, ce qui est acceptable
 
 ## 7. Algorithme sync-permissions
 
-La commande `app:sync-permissions` doit vivre dans `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php` et encapsuler toute l'operation dans une transaction Doctrine unique.
+La commande `app:sync-permissions` doit vivre dans `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php` et encapsuler toute l'operation dans une transaction Doctrine unique.
 
 ### Source de verite
 
-- Le scan des modules actifs vient de `/home/matthieu/dev_malio/Coltura/config/modules.php`.
+- Le scan des modules actifs vient de `/home/matthieu/dev_malio/Starseed/config/modules.php`.
 - Chaque classe module active peut exposer `public static function permissions(): array`.
 - Par compatibilite montante, si une classe module n'expose pas encore `permissions()`, elle est traitee comme retournant `[]`.
 
@@ -330,7 +330,7 @@ Garde anti-typo : le sync command verifie que chaque `code` commence obligatoire
 ```text
 begin transaction
 
-load active module classes from /home/matthieu/dev_malio/Coltura/config/modules.php
+load active module classes from /home/matthieu/dev_malio/Starseed/config/modules.php
 desired_permissions = empty map keyed by code
 
 for each module class:
@@ -439,7 +439,7 @@ Repasse `orphan` a `false` et remet a jour les metadonnees issues de la declarat
 
 ## 9. Fixtures mises à jour
 
-Le fichier cible reste `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php`.
+Le fichier cible reste `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php`.
 
 ### Principe cle : decouplage via `is_admin`
 
@@ -519,7 +519,7 @@ Les tests d'integration migration up/down exigent une base de test dediee avec u
 - Risque de perte de donnees pendant la suppression de la colonne `user.roles`.
   - Mitigation : creer les roles systeme et inserer les jointures `user_role` avant tout `DROP COLUMN`, avec tests de migration sur etats mixtes.
 - Risque de divergence entre migration SQL brute et fixtures sur les codes des roles systeme.
-  - Mitigation : centraliser `admin` et `user` dans `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Security/SystemRoles.php` et documenter que la migration doit reprendre ces valeurs telles quelles.
+  - Mitigation : centraliser `admin` et `user` dans `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Security/SystemRoles.php` et documenter que la migration doit reprendre ces valeurs telles quelles.
 - Risque d'accumulation de permissions orphelines sur des environnements de dev ou apres refactors de codes.
   - Mitigation : conserver `orphan = true` pour la non-destruction, mais ajouter un suivi explicite dans les tests et dans la documentation d'exploitation; une strategie de purge pourra etre traitee plus tard si necessaire.
 - Risque de sync incoherente entre dev et prod si un module actif ne declare pas encore `permissions()`.
@@ -533,12 +533,12 @@ Les tests d'integration migration up/down exigent une base de test dediee avec u
 
 1. Creer `Permission`, `Role`, `SystemRoleDeletionException` et `SystemRoles`.
 2. Creer `PermissionRepositoryInterface`, `RoleRepositoryInterface` et leurs implementations Doctrine.
-3. Faire evoluer `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/User.php` avec `is_admin`, `roles`, `directPermissions`, `getRoles()` et `getEffectivePermissions()`.
+3. Faire evoluer `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php` avec `is_admin`, `roles`, `directPermissions`, `getRoles()` et `getEffectivePermissions()`.
 4. Ajouter `CoreModule::permissions()` et documenter le pattern de declaration statique pour les autres modules.
-5. Ajouter la commande `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php`.
-6. Ecrire la migration `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` avec schema + migration de donnees + down().
-7. Mettre a jour `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` et `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Console/CreateUserCommand.php`.
-8. Ajouter les alias repository dans `/home/matthieu/dev_malio/Coltura/config/services.yaml`.
+5. Ajouter la commande `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php`.
+6. Ecrire la migration `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/Migrations/Version<timestamp>.php` avec schema + migration de donnees + down().
+7. Mettre a jour `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` et `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Console/CreateUserCommand.php`.
+8. Ajouter les alias repository dans `/home/matthieu/dev_malio/Starseed/config/services.yaml`.
 9. Ecrire les tests unitaires et d'integration couvrant domaine, sync, fixtures et migration.
 
 ## 13. Critères d'acceptation (DoD)
@@ -553,4 +553,4 @@ Les tests d'integration migration up/down exigent une base de test dediee avec u
 - La suppression d'un role systeme leve `SystemRoleDeletionException` au niveau domaine.
 - Les associations `User::$roles`, `User::$directPermissions` et `Role::$permissions` sont explicitement configurees en `fetch=EAGER` et ce point est verifie par tests.
 - Les fixtures attribuent `is_admin = true` + role `admin` a l'utilisateur `admin`, et le role `user` aux utilisateurs standards.
-- Le spec est compatible avec l'architecture modulaire actuelle basee sur `/home/matthieu/dev_malio/Coltura/config/modules.php` et n'introduit aucune resource API Platform ni voter dans ce ticket.
+- Le spec est compatible avec l'architecture modulaire actuelle basee sur `/home/matthieu/dev_malio/Starseed/config/modules.php` et n'introduit aucune resource API Platform ni voter dans ce ticket.

docs/rbac/ticket-344-spec.md

@@ -38,28 +38,28 @@ Le ticket n'introduit **aucune logique d'autorisation metier** : toute la verifi
 
 ### Infrastructure - Processors
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/RoleProcessor.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/RoleProcessor.php`
   Decorator de `ApiPlatform\Doctrine\Common\State\PersistProcessor` et `RemoveProcessor`. Charge de la garde `ensureDeletable()` et de la protection des champs immuables sur un role systeme.
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php`
   Decorator de `PersistProcessor` specifique a l'operation `PATCH /api/users/{id}/rbac`. Persiste les mutations `isAdmin`, `roles`, `directPermissions` sans passer par `UserPasswordHasherProcessor`.
 
 ### Tests unitaires
 
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/RoleProcessorTest.php`
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessorTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/RoleProcessorTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessorTest.php`
 
 ### Tests fonctionnels
 
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Api/PermissionApiTest.php`
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Api/RoleApiTest.php`
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Api/UserRbacApiTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Api/PermissionApiTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Api/RoleApiTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Api/UserRbacApiTest.php`
 
 ## 4. Fichiers a modifier
 
 ### Entite `Permission`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Permission.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Permission.php`
 
 - Ajouter l'attribut `#[ApiResource]` avec operations `GetCollection` + `Get` uniquement.
 - Normalization context : groupe `permission:read` uniquement.
@@ -89,7 +89,7 @@ Extrait attendu :
 
 ### Entite `Role`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Role.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Role.php`
 
 - Ajouter l'attribut `#[ApiResource]` avec operations `GetCollection`, `Get`, `Post`, `Patch`, `Delete`.
 - Normalization context : `role:read`. Denormalization context : `role:write`.
@@ -107,7 +107,7 @@ Extrait attendu :
 
 ### Entite `User`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/User.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php`
 
 - Ajouter dans la liste des operations `ApiResource` existantes une operation dediee :
 

docs/rbac/ticket-345-spec.md

@@ -39,50 +39,50 @@ A l'issue de ce ticket, l'application dispose d'un systeme d'autorisation applic
 
 ### Domaine - Securite
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Security/AdminHeadcountGuard.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Security/AdminHeadcountGuard.php`
   Service domaine encapsulant l'invariant "au moins un admin reste apres l'operation". Depend uniquement de `UserRepositoryInterface::countAdmins()`. Aucune dependance infrastructure, testable en isolation.
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Exception/LastAdminProtectionException.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Exception/LastAdminProtectionException.php`
   Exception metier levee par le guard. Traduite en `BadRequestHttpException` (400) dans les processors.
 
 ### Infrastructure - Security
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Security/PermissionVoter.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Security/PermissionVoter.php`
   Voter Symfony etendant `Symfony\Component\Security\Core\Authorization\Voter\Voter`. Decouvert automatiquement par `autoconfigure: true`.
 
 ### Infrastructure - Processors
 
-- `/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserProcessor.php`
+- `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserProcessor.php`
   Decorateur de `RemoveProcessor` cible sur `DELETE /api/users/{id}`. Appelle `AdminHeadcountGuard` avant de deleguer. Meme pattern qu'`UserRbacProcessor`/`RoleProcessor` : `final class`, `#[Autowire]` sur l'inner, `LogicException` fail-fast si le type entrant n'est pas `User`.
 
 ### Frontend - Composable
 
-- `/home/matthieu/dev_malio/Coltura/frontend/shared/composables/usePermissions.ts`
+- `/home/matthieu/dev_malio/Starseed/frontend/shared/composables/usePermissions.ts`
   Composable stateless qui lit `useAuthStore().user`. Pas de fetch propre, pas de reset (le cycle de vie est porte par l'auth store).
 
 ### Tests unitaires PHP
 
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Infrastructure/Security/PermissionVoterTest.php`
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Domain/Security/AdminHeadcountGuardTest.php`
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserProcessorTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Infrastructure/Security/PermissionVoterTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Domain/Security/AdminHeadcountGuardTest.php`
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserProcessorTest.php`
 
 ### Tests fonctionnels PHP
 
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Api/MeApiTest.php` (si absent — sinon extension)
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Api/MeApiTest.php` (si absent — sinon extension)
   Couvre l'enrichissement du payload `/api/me`.
-- `/home/matthieu/dev_malio/Coltura/tests/Module/Core/Api/UserApiTest.php` (si absent — sinon extension)
+- `/home/matthieu/dev_malio/Starseed/tests/Module/Core/Api/UserApiTest.php` (si absent — sinon extension)
   Couvre la garde "dernier admin global" sur `DELETE /api/users/{id}`.
 
 ### Tests frontend
 
-- `/home/matthieu/dev_malio/Coltura/frontend/shared/composables/__tests__/usePermissions.test.ts`
+- `/home/matthieu/dev_malio/Starseed/frontend/shared/composables/__tests__/usePermissions.test.ts`
   Vitest. Emplacement a adapter si le projet Nuxt a une autre convention (colocalise avec un fichier `.spec.ts`, ou repertoire `tests/`). A verifier au debut de la task frontend.
 
 ## 4. Fichiers a modifier
 
 ### `CoreModule.php`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/CoreModule.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/CoreModule.php`
 
 Ajouter une cinquieme entree au catalogue :
 
@@ -103,7 +103,7 @@ La commande `app:sync-permissions` creera automatiquement `core.roles.view` a la
 
 ### Entite `Permission`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Permission.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Permission.php`
 
 Remplacer les 2 gardes placeholder :
 
@@ -122,7 +122,7 @@ Supprimer les commentaires `// TODO ticket #345`.
 
 ### Entite `Role`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/Role.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Role.php`
 
 Remplacer les 5 gardes placeholder :
 
@@ -136,7 +136,7 @@ Supprimer les commentaires `// TODO ticket #345`.
 
 ### Entite `User`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Entity/User.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php`
 
 Remplacer les 6 gardes `ROLE_ADMIN` restantes :
 
@@ -172,7 +172,7 @@ Supprimer tous les commentaires `// TODO ticket #345` rencontres.
 
 ### `UserRepositoryInterface`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Domain/Repository/UserRepositoryInterface.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Repository/UserRepositoryInterface.php`
 
 Ajouter la methode :
 
@@ -187,7 +187,7 @@ public function countAdmins(): int;
 
 ### `DoctrineUserRepository`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/Doctrine/DoctrineUserRepository.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/DoctrineUserRepository.php`
 
 Implementer `countAdmins()` via un `QueryBuilder` simple :
 
@@ -204,7 +204,7 @@ public function countAdmins(): int
 
 ### `UserRbacProcessor`
 
-`/home/matthieu/dev_malio/Coltura/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php`
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php`
 
 Ajouter la dependance `AdminHeadcountGuard` et l'invoquer **apres** la garde auto-suicide existante, **avant** de deleguer au persist processor. Supprimer le `TODO ticket #345` du docblock.
 
@@ -572,3 +572,78 @@ Chaque etape doit etre revue (spec compliance + code quality) avant de passer a
 - Branche de travail : `feat/rbac-voter`, tiree de `feat/rbac-api`.
 - Pas de PR dediee : les commits #345 s'empilent sur la PR #3 existante ouverte vers `develop`.
 - Une fois la PR #3 mergee, la branche finale de l'epic RBAC (`feat/rbac-admin-ui` pour #346) partira de `develop`.
+
+## 18. Evolutions post-livraison — `UserRbacProcessor` defense in depth
+
+Voir aussi : `docs/sites/ticket-02-spec.md` § 10 pour la problematique cote
+Sites qui a motive cette evolution.
+
+### 18.1 — Semantique `merge-patch+json` respectee
+
+Le processor originel appliquait telles quelles les mutations produites par la
+denormalisation API Platform. Or API Platform reinstancie par defaut une
+`ArrayCollection` vide pour chaque propriete ManyToMany absente du payload,
+ce qui viole la semantique `application/merge-patch+json` : les cles absentes
+ne doivent PAS muter les proprietes correspondantes.
+
+Consequence concrete du bug : un PATCH minimal comme `{ "isAdmin": true }`
+detruisait silencieusement toutes les collections (`rbacRoles`,
+`directPermissions`, `sites`) du user cible.
+
+La garde `restoreAbsentCollections()` introduite dans `UserRbacProcessor`
+resout cela en :
+
+1. Injectant `RequestStack` pour lire le body JSON brut de la requete.
+2. Decodant les cles effectivement envoyees par le client.
+3. Pour chaque cle RBAC (`roles`, `directPermissions`, `sites`) absente du
+   payload : restaurant la collection a son etat d'origine a partir du
+   snapshot Doctrine (`PersistentCollection::getSnapshot()`), puis appelant
+   `takeSnapshot()` pour marquer la collection comme non-dirty (aucune query
+   `UPDATE` n'est emise sur les tables de jointure).
+4. No-op si la cle est presente (la denormalisation fait foi).
+
+Matrice finale :
+
+| Payload                         | Effet                               |
+|---------------------------------|-------------------------------------|
+| Cle absente                     | Propriete preservee (BDD inchangee) |
+| Cle presente = `[]`             | Collection videe (vidage explicite) |
+| Cle presente = `[...]`          | Collection remplacee                |
+
+### 18.2 — Nouvelle operation `GET /users/{id}/rbac`
+
+Le drawer d'edition (`UserRbacDrawer.vue`) ne peut plus dependre du payload
+de liste `/api/users` (groupe `user:list`) pour initialiser l'etat `sites`
+car ce groupe reste volontairement leger (cf. ticket Sites #02). Une
+operation `Get` dediee est ajoutee, symetrique au `Patch` existant :
+
+- URI : `/users/{id}/rbac`
+- Security : `is_granted('core.users.manage')` (plus strict que `.view`)
+- Groupe : `user:rbac:read` (contient `isAdmin`, `roles`, `directPermissions`,
+  `sites`).
+
+Le drawer charge desormais ce GET en parallele des referentiels au moment
+de l'ouverture, via un watch combine `[modelValue, user.id]` qui recharge
+correctement si le user change sans fermeture du drawer entre-temps.
+
+### 18.3 — Impact sur les tests
+
+`UserRbacProcessorTest` : le constructor gagne un argument `RequestStack`.
+Les tests existants injectent une `RequestStack` avec une `Request` vide
+(body `""`), ce qui rend la garde no-op — le comportement des assertions
+existantes est conserve. De nouveaux tests couvrent la garde :
+
+- PATCH sans cle `sites` ne mute pas la collection d'origine.
+- PATCH avec `sites: []` vide bien la collection (pas de regression du cas
+  "vidage explicite").
+- PATCH avec `sites: [...]` remplace comme avant.
+
+### 18.4 — Criteres de validation additionnels
+
+- [ ] `GET /users/{id}/rbac` retourne 200 avec `core.users.manage`, 403 sans.
+- [ ] Le payload contient `{ id, isAdmin, roles, directPermissions, sites }`.
+- [ ] `PATCH /users/{id}/rbac` avec cle absente preserve la collection BDD.
+- [ ] `PATCH /users/{id}/rbac` avec `[]` vide la collection et declenche
+      `ensureCurrentSiteConsistency` (cas sites).
+- [ ] Les 228 tests PHPUnit existants passent apres ajout du parametre
+      `RequestStack` au constructor.

docs/sites/ticket-01-spec.md

@@ -10,14 +10,14 @@ Le resultat attendu est un socle de persistance activable par tenant via `config
 
 ### IN
 
-- Creer le module `/home/m-tristan/workspace/Coltura/src/Module/Sites/SitesModule.php` avec `ID = 'sites'`, `LABEL = 'Sites'`, `REQUIRED = false`, et une methode statique `permissions()` declarant les deux codes RBAC `sites.view` et `sites.manage`.
+- Creer le module `/home/m-tristan/workspace/Starseed/src/Module/Sites/SitesModule.php` avec `ID = 'sites'`, `LABEL = 'Sites'`, `REQUIRED = false`, et une methode statique `permissions()` declarant les deux codes RBAC `sites.view` et `sites.manage`.
 - Creer l'entite Doctrine `Site` avec `id`, `name` (unique), `city`, `postalCode`, `color`, `fullAddress`, `createdAt`, `updatedAt` et les contraintes de validation applicatives associees (NotBlank, Length, Regex hex `#RRGGBB`, Regex CP FR `^\d{5}$`, UniqueEntity).
 - Creer l'interface `SiteRepositoryInterface` et son implementation Doctrine `DoctrineSiteRepository`, avec un contrat CRUD complet (`findById`, `findByName`, `findAllOrderedByName`, `save`, `remove`) en anticipation du ticket 2.
-- Creer une migration Doctrine creant la table `site` avec son index unique `uniq_site_name`. La migration est placee dans `/home/m-tristan/workspace/Coltura/migrations/` au namespace racine `DoctrineMigrations` conformement a l'exception documentee dans `CLAUDE.md` (bug de tri alphabetique des migrations multi-namespaces dans Doctrine Migrations 3.x).
+- Creer une migration Doctrine creant la table `site` avec son index unique `uniq_site_name`. La migration est placee dans `/home/m-tristan/workspace/Starseed/migrations/` au namespace racine `DoctrineMigrations` conformement a l'exception documentee dans `CLAUDE.md` (bug de tri alphabetique des migrations multi-namespaces dans Doctrine Migrations 3.x).
 - Creer `SitesFixtures` creant trois sites de demonstration : `Chatellerault` (`#056CF2`), `Saint-Jean` (`#10B981`), `Pommevic` (`#F59E0B`). Fixtures idempotentes via lookup par nom lorsque le purger Doctrine est desactive.
-- Enregistrer `SitesModule::class` dans `/home/m-tristan/workspace/Coltura/config/modules.php` pour l'activer par defaut.
-- Declarer le mapping Doctrine du module dans `/home/m-tristan/workspace/Coltura/config/packages/doctrine.yaml` (inconditionnel, le mapping reste charge meme si le module est retire de `modules.php`).
-- Enregistrer l'alias service `SiteRepositoryInterface → DoctrineSiteRepository` dans `/home/m-tristan/workspace/Coltura/config/services.yaml`.
+- Enregistrer `SitesModule::class` dans `/home/m-tristan/workspace/Starseed/config/modules.php` pour l'activer par defaut.
+- Declarer le mapping Doctrine du module dans `/home/m-tristan/workspace/Starseed/config/packages/doctrine.yaml` (inconditionnel, le mapping reste charge meme si le module est retire de `modules.php`).
+- Enregistrer l'alias service `SiteRepositoryInterface → DoctrineSiteRepository` dans `/home/m-tristan/workspace/Starseed/config/services.yaml`.
 - Ajouter deux suites de tests PHPUnit :
   - `SiteTest` (pure `TestCase`) pour le comportement de l'entite (constructeur, getters/setters, lifecycle `PreUpdate`).
   - `SiteValidationTest` (`KernelTestCase`) pour la validation complete : regex hex, regex CP FR, NotBlank, Length, UniqueEntity via Doctrine.
@@ -25,7 +25,7 @@ Le resultat attendu est un socle de persistance activable par tenant via `config
 ### OUT
 
 - Ticket `#02` : relation `User ↔ Site` (FK ou ManyToMany selon decision UX), expose les sites de l'utilisateur courant via `/api/me` et propage l'autorisation au niveau des ressources decoupees par site.
-- Ticket `#03` : integration dans la navbar Coltura (selecteur de site actif, persistance du choix cote front, consommation du flux issu du ticket 2).
+- Ticket `#03` : integration dans la navbar Starseed (selecteur de site actif, persistance du choix cote front, consommation du flux issu du ticket 2).
 - Ticket `#04` : ecran d'administration CRUD des sites (page admin/sites, DataTable, drawer creation/edition, modale suppression, API Platform `Site` resource avec voters RBAC).
 - Gestion des soft-deletes sur `Site` : non introduite dans ce ticket.
 - Rattachement historique ou audit trail des modifications : hors scope.
@@ -34,38 +34,38 @@ Le resultat attendu est un socle de persistance activable par tenant via `config
 
 ### Domaine — Entité
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Domain/Entity/Site.php` : entite Doctrine porteuse des attributs metier (nom unique, ville, code postal FR, couleur hex, adresse complete multi-ligne) et des timestamps auto-maintenus via lifecycle callbacks.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Domain/Entity/Site.php` : entite Doctrine porteuse des attributs metier (nom unique, ville, code postal FR, couleur hex, adresse complete multi-ligne) et des timestamps auto-maintenus via lifecycle callbacks.
 
 ### Domaine — Repository
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Domain/Repository/SiteRepositoryInterface.php` : contrat d'acces domaine a l'entite Site (CRUD applicatif ; l'acces API Platform du ticket 4 utilisera le provider Doctrine par defaut).
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Domain/Repository/SiteRepositoryInterface.php` : contrat d'acces domaine a l'entite Site (CRUD applicatif ; l'acces API Platform du ticket 4 utilisera le provider Doctrine par defaut).
 
 ### Infrastructure — Doctrine
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/Doctrine/DoctrineSiteRepository.php` : implementation Doctrine de `SiteRepositoryInterface` basee sur `ServiceEntityRepository`.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/Doctrine/DoctrineSiteRepository.php` : implementation Doctrine de `SiteRepositoryInterface` basee sur `ServiceEntityRepository`.
 
 ### Infrastructure — Migration
 
-- `/home/m-tristan/workspace/Coltura/migrations/Version<timestamp>.php` : migration racine (namespace `DoctrineMigrations`) qui cree la table `site` et son index unique. Emplacement racine et non modulaire, cf. exception documentee dans `CLAUDE.md` (bug Doctrine 3.x sur le tri alphabetique des migrations multi-namespaces).
+- `/home/m-tristan/workspace/Starseed/migrations/Version<timestamp>.php` : migration racine (namespace `DoctrineMigrations`) qui cree la table `site` et son index unique. Emplacement racine et non modulaire, cf. exception documentee dans `CLAUDE.md` (bug Doctrine 3.x sur le tri alphabetique des migrations multi-namespaces).
 
 ### Infrastructure — DataFixtures
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/DataFixtures/SitesFixtures.php` : fixture Doctrine seedant les 3 sites de demonstration. Ne declare pas de `DependentFixtureInterface` (aucune dependance a AppFixtures dans ce ticket).
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/DataFixtures/SitesFixtures.php` : fixture Doctrine seedant les 3 sites de demonstration. Ne declare pas de `DependentFixtureInterface` (aucune dependance a AppFixtures dans ce ticket).
 
 ### Module — Declaration
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/SitesModule.php` : marker class du module avec `ID`, `LABEL`, `REQUIRED` et `permissions()`. Meme pattern que `CoreModule`.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/SitesModule.php` : marker class du module avec `ID`, `LABEL`, `REQUIRED` et `permissions()`. Meme pattern que `CoreModule`.
 
 ### Tests
 
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Domain/Entity/SiteTest.php` : tests unitaires purs (`TestCase`) couvrant constructeur, getters, setters et lifecycle `PreUpdate`.
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Domain/Entity/SiteValidationTest.php` : tests de validation (`KernelTestCase`) couvrant regex hex, regex CP FR, NotBlank, Length sur tous les champs, et `UniqueEntity` via la DB de test.
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Domain/Entity/SiteTest.php` : tests unitaires purs (`TestCase`) couvrant constructeur, getters, setters et lifecycle `PreUpdate`.
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Domain/Entity/SiteValidationTest.php` : tests de validation (`KernelTestCase`) couvrant regex hex, regex CP FR, NotBlank, Length sur tous les champs, et `UniqueEntity` via la DB de test.
 
 ## 4. Fichiers à modifier
 
-- `/home/m-tristan/workspace/Coltura/config/modules.php` : ajouter `App\Module\Sites\SitesModule::class` dans le tableau de retour. Le module est actif par defaut. Le commenter suffit a le desactiver sans autre intervention (les permissions deviendront orphelines a la prochaine sync mais la table reste).
-- `/home/m-tristan/workspace/Coltura/config/packages/doctrine.yaml` : ajouter une mapping `Sites:` alignee sur le pattern du module `Core:`. Le mapping est inconditionnel : il reste declare meme si `SitesModule::class` est retire de `modules.php`. Le commentaire doit etre explicite sur cette decoupe (activation fonctionnelle via `modules.php`, structure DB via la mapping Doctrine).
-- `/home/m-tristan/workspace/Coltura/config/services.yaml` : ajouter l'alias `App\Module\Sites\Domain\Repository\SiteRepositoryInterface` → `App\Module\Sites\Infrastructure\Doctrine\DoctrineSiteRepository`. Pattern aligne sur les trois aliases Core existants.
+- `/home/m-tristan/workspace/Starseed/config/modules.php` : ajouter `App\Module\Sites\SitesModule::class` dans le tableau de retour. Le module est actif par defaut. Le commenter suffit a le desactiver sans autre intervention (les permissions deviendront orphelines a la prochaine sync mais la table reste).
+- `/home/m-tristan/workspace/Starseed/config/packages/doctrine.yaml` : ajouter une mapping `Sites:` alignee sur le pattern du module `Core:`. Le mapping est inconditionnel : il reste declare meme si `SitesModule::class` est retire de `modules.php`. Le commentaire doit etre explicite sur cette decoupe (activation fonctionnelle via `modules.php`, structure DB via la mapping Doctrine).
+- `/home/m-tristan/workspace/Starseed/config/services.yaml` : ajouter l'alias `App\Module\Sites\Domain\Repository\SiteRepositoryInterface` → `App\Module\Sites\Infrastructure\Doctrine\DoctrineSiteRepository`. Pattern aligne sur les trois aliases Core existants.
 
 ## 5. Schéma cible — mapping Doctrine
 
@@ -152,7 +152,7 @@ Sites:
 
 ## 6. Plan de migration Doctrine
 
-La migration est placee dans `/home/m-tristan/workspace/Coltura/migrations/Version<timestamp>.php` au namespace racine `DoctrineMigrations`, conformement a l'exception documentee dans `CLAUDE.md`. Tant que le bug de tri alphabetique des `MigrationsComparator` multi-namespaces n'est pas resolu (via un comparator custom ou un upgrade Doctrine), toute migration d'initialisation (creation de table sur base vide) reste au namespace racine.
+La migration est placee dans `/home/m-tristan/workspace/Starseed/migrations/Version<timestamp>.php` au namespace racine `DoctrineMigrations`, conformement a l'exception documentee dans `CLAUDE.md`. Tant que le bug de tri alphabetique des `MigrationsComparator` multi-namespaces n'est pas resolu (via un comparator custom ou un upgrade Doctrine), toute migration d'initialisation (creation de table sur base vide) reste au namespace racine.
 
 ### `up()` — ordre des instructions
 
@@ -289,7 +289,7 @@ Trois sites de demonstration, avec des couleurs distinctes suffisamment contrast
 
 | Nom | Ville | CP | Couleur | Commentaire |
 |-----|-------|-----|---------|-------------|
-| Chatellerault | Chatellerault | 86100 | `#056CF2` | Couleur imposee par le ticket (bleu Coltura). |
+| Chatellerault | Chatellerault | 86100 | `#056CF2` | Couleur imposee par le ticket (bleu Starseed). |
 | Saint-Jean | Saint-Jean-de-Sauves | 86330 | `#10B981` | Vert emeraude (contraste avec le bleu). |
 | Pommevic | Pommevic | 82400 | `#F59E0B` | Ambre (troisieme teinte nettement distincte). |
 

docs/sites/ticket-02-spec.md

@@ -40,70 +40,70 @@ Le resultat attendu est un module Sites utilisable de bout en bout cote admin (c
 
 ### Backend — Module Sites
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Domain/Exception/SiteNotAuthorizedException.php` : exception domaine levee si un user tente de switcher vers un site qui ne fait pas partie de ses sites autorises. Porte un message i18n-able et le code du site cible.
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/ApiPlatform/Resource/CurrentSiteResource.php` : ressource API Platform **virtuelle** (pas de mapping Doctrine, pas de `#[ORM\Entity]`). Sert uniquement a porter l'operation `Patch` `/me/current-site`. Expose une propriete `site: Site` en denormalisation pour recevoir l'IRI du site cible, et re-expose l'user courant en normalisation via le groupe `me:read`.
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/ApiPlatform/State/Processor/CurrentSiteProcessor.php` : processor dedie a l'operation de switch. Valide l'appartenance du site aux `user.sites`, positionne `user.currentSite`, flush, retourne l'user.
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/ApiPlatform/EventListener/SiteNotAuthorizedExceptionListener.php` : listener Kernel qui convertit `SiteNotAuthorizedException` en `ForbiddenHttpException` (403) avec un code i18n stable (cf. pattern `SystemRoleDeletionException` du module Core dans les tickets RBAC precedents).
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Domain/Exception/SiteNotAuthorizedException.php` : exception domaine levee si un user tente de switcher vers un site qui ne fait pas partie de ses sites autorises. Porte un message i18n-able et le code du site cible.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/ApiPlatform/Resource/CurrentSiteResource.php` : ressource API Platform **virtuelle** (pas de mapping Doctrine, pas de `#[ORM\Entity]`). Sert uniquement a porter l'operation `Patch` `/me/current-site`. Expose une propriete `site: Site` en denormalisation pour recevoir l'IRI du site cible, et re-expose l'user courant en normalisation via le groupe `me:read`.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/ApiPlatform/State/Processor/CurrentSiteProcessor.php` : processor dedie a l'operation de switch. Valide l'appartenance du site aux `user.sites`, positionne `user.currentSite`, flush, retourne l'user.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/ApiPlatform/EventListener/SiteNotAuthorizedExceptionListener.php` : listener Kernel qui convertit `SiteNotAuthorizedException` en `ForbiddenHttpException` (403) avec un code i18n stable (cf. pattern `SystemRoleDeletionException` du module Core dans les tickets RBAC precedents).
 
 ### Backend — Migration
 
-- `/home/m-tristan/workspace/Coltura/migrations/Version<timestamp2>.php` : migration au namespace racine `DoctrineMigrations` (cf. exception Doctrine documentee dans `CLAUDE.md`). Cree la table `user_site` et la colonne `user.current_site_id` avec les FKs et cascades appropriees.
+- `/home/m-tristan/workspace/Starseed/migrations/Version<timestamp2>.php` : migration au namespace racine `DoctrineMigrations` (cf. exception Doctrine documentee dans `CLAUDE.md`). Cree la table `user_site` et la colonne `user.current_site_id` avec les FKs et cascades appropriees.
 
 ### Backend — Tests API
 
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Api/SiteApiTest.php` : CRUD complet `/api/sites` avec matrices RBAC (admin, user avec `sites.view`, user avec `sites.manage`, user sans permission).
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Api/CurrentSiteSwitchApiTest.php` : PATCH `/me/current-site` (OK avec site autorise, 403 avec site non autorise, 400 avec IRI invalide).
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Api/MeEndpointSitesTest.php` : `/api/me` expose bien `sites` et `currentSite` en objets. User sans site : `sites: []`, `currentSite: null`.
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Api/SiteCascadeTest.php` : suppression d'un site `X` → toutes les lignes `user_site` referencant `X` sont supprimees, tous les users ayant `X` en `currentSite` voient leur `currentSite` repasser a `NULL`.
-- `/home/m-tristan/workspace/Coltura/tests/Module/Core/Api/UserRbacSitesApiTest.php` : extension du endpoint `/api/users/{id}/rbac` — ajout de `sites: []` dans le payload, retrait du `currentSite` quand le site retire etait le courant.
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Api/SiteApiTest.php` : CRUD complet `/api/sites` avec matrices RBAC (admin, user avec `sites.view`, user avec `sites.manage`, user sans permission).
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Api/CurrentSiteSwitchApiTest.php` : PATCH `/me/current-site` (OK avec site autorise, 403 avec site non autorise, 400 avec IRI invalide).
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Api/MeEndpointSitesTest.php` : `/api/me` expose bien `sites` et `currentSite` en objets. User sans site : `sites: []`, `currentSite: null`.
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Api/SiteCascadeTest.php` : suppression d'un site `X` → toutes les lignes `user_site` referencant `X` sont supprimees, tous les users ayant `X` en `currentSite` voient leur `currentSite` repasser a `NULL`.
+- `/home/m-tristan/workspace/Starseed/tests/Module/Core/Api/UserRbacSitesApiTest.php` : extension du endpoint `/api/users/{id}/rbac` — ajout de `sites: []` dans le payload, retrait du `currentSite` quand le site retire etait le courant.
 
 ### Frontend — Module Sites (nouveau layer)
 
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/nuxt.config.ts` : marker de layer Nuxt (vide). Declenche l'auto-detection par `nuxt.config.ts` racine.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/pages/admin/sites.vue` : page `/admin/sites`. Reutilise les composants Malio UI (`MalioDataTable`, `MalioButton`, `MalioInputText`, `MalioInputTextArea`). Pattern identique a `frontend/modules/core/pages/admin/roles.vue`.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/components/SiteDrawer.vue` : drawer creation/edition. Formulaire 5 champs (nom, ville, CP, couleur avec preview puce, adresse). Valide cote front sur le submit avant d'envoyer.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/components/SiteDeleteModal.vue` : modale de confirmation suppression. Pattern aligne sur `RoleDeleteModal.vue`.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/nuxt.config.ts` : marker de layer Nuxt (vide). Declenche l'auto-detection par `nuxt.config.ts` racine.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/pages/admin/sites.vue` : page `/admin/sites`. Reutilise les composants Malio UI (`MalioDataTable`, `MalioButton`, `MalioInputText`, `MalioInputTextArea`). Pattern identique a `frontend/modules/core/pages/admin/roles.vue`.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/components/SiteDrawer.vue` : drawer creation/edition. Formulaire 5 champs (nom, ville, CP, couleur avec preview puce, adresse). Valide cote front sur le submit avant d'envoyer.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/components/SiteDeleteModal.vue` : modale de confirmation suppression. Pattern aligne sur `RoleDeleteModal.vue`.
 
 ### Frontend — Types partages
 
-- `/home/m-tristan/workspace/Coltura/frontend/shared/types/sites.ts` : types `Site`, `SiteInput`. Pattern identique a `frontend/shared/types/rbac.ts`.
+- `/home/m-tristan/workspace/Starseed/frontend/shared/types/sites.ts` : types `Site`, `SiteInput`. Pattern identique a `frontend/shared/types/rbac.ts`.
 
 ### Tests frontend (optionnels mais recommandes)
 
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/pages/admin/sites.spec.ts` : smoke test Vitest (rendu + clic bouton "Nouveau site" ouvre le drawer).
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/pages/admin/sites.spec.ts` : smoke test Vitest (rendu + clic bouton "Nouveau site" ouvre le drawer).
 
 ## 4. Fichiers à modifier
 
 ### Backend — Module Core
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Core/Domain/Entity/User.php` :
+- `/home/m-tristan/workspace/Starseed/src/Module/Core/Domain/Entity/User.php` :
   - Ajouter `private Collection $sites;` (M2M, `fetch: EAGER`, `JoinTable: user_site`), groupes `me:read`, `user:list`, `user:rbac:read`, `user:rbac:write`.
   - Ajouter `private ?Site $currentSite = null;` (M2O, `fetch: EAGER`, `onDelete: 'SET NULL'`), groupe `me:read`.
   - Initialiser `$this->sites = new ArrayCollection();` dans le constructeur.
   - Ajouter les accesseurs `getSites()`, `addSite(Site)`, `removeSite(Site)`, `hasSite(Site)`, `getCurrentSite()`, `setCurrentSite(?Site)`.
   - **Important** : `import` direct `App\Module\Sites\Domain\Entity\Site`. Ce ticket assume le couplage Core → Sites au niveau code PHP (cf. Risque 1).
-- `/home/m-tristan/workspace/Coltura/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php` :
+- `/home/m-tristan/workspace/Starseed/src/Module/Core/Infrastructure/ApiPlatform/State/Processor/UserRbacProcessor.php` :
   - Etendre le contrat d'entree pour accepter le champ `sites` (collection d'IRIs denormalisees en `Collection<Site>`).
   - Apres l'application des roles et permissions directes, detecter si `currentSite` du user cible n'est plus dans la nouvelle collection `sites` → basculer `currentSite` a `null`.
   - Conserver toutes les gardes existantes (auto-suicide admin, dernier admin global).
-- `/home/m-tristan/workspace/Coltura/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` :
+- `/home/m-tristan/workspace/Starseed/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php` :
   - Declarer l'implementation `DependentFixtureInterface` avec `getDependencies(): [SitesFixtures::class]` (inversion de l'ordre actuel : AppFixtures doit tourner **apres** SitesFixtures pour pouvoir reference les sites).
   - Rattacher chaque user a au moins un site : `admin` a tous les sites (`Chatellerault`, `Saint-Jean`, `Pommevic`), `alice` a `Chatellerault`, `bob` a `Saint-Jean`.
   - Positionner `currentSite` : `admin.currentSite = Chatellerault`, `alice.currentSite = Chatellerault`, `bob.currentSite = Saint-Jean`.
 
 ### Backend — Module Sites
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Domain/Entity/Site.php` :
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Domain/Entity/Site.php` :
   - Ajouter les attributs `#[ApiResource]` + operations (cf. section 5 Schema).
   - Ajouter les groupes de serialisation `site:read`, `site:write`, `me:read` sur les proprietes scalaires.
   - Ajouter la relation inverse `private Collection $users;` (M2M mappedBy=`sites`), **sans** groupe de serialisation (pas d'exposition API cote Site).
   - Initialiser `$this->users = new ArrayCollection();` dans le constructeur.
   - Ajouter les accesseurs `getUsers()` pour les besoins metier (count / cascade manuel si besoin).
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/DataFixtures/SitesFixtures.php` : aucun changement de contenu, mais verifier que la fixture n'est plus en bout de chaine de dependance (AppFixtures depend d'elle maintenant).
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/DataFixtures/SitesFixtures.php` : aucun changement de contenu, mais verifier que la fixture n'est plus en bout de chaine de dependance (AppFixtures depend d'elle maintenant).
 
 ### Backend — Configuration
 
-- `/home/m-tristan/workspace/Coltura/config/sidebar.php` : inserer l'entree `Sites` dans la section `sidebar.general.section` entre `sidebar.core.users` et `sidebar.general.logout` :
+- `/home/m-tristan/workspace/Starseed/config/sidebar.php` : inserer l'entree `Sites` dans la section `sidebar.general.section` entre `sidebar.core.users` et `sidebar.general.logout` :
   ```php
   [
       'label'      => 'sidebar.core.sites',
@@ -113,18 +113,18 @@ Le resultat attendu est un module Sites utilisable de bout en bout cote admin (c
       'permission' => 'sites.view',
   ],
   ```
-- `/home/m-tristan/workspace/Coltura/config/services.yaml` : aucun changement requis. `CurrentSiteProcessor`, `SiteNotAuthorizedExceptionListener` sont autoconfigures.
+- `/home/m-tristan/workspace/Starseed/config/services.yaml` : aucun changement requis. `CurrentSiteProcessor`, `SiteNotAuthorizedExceptionListener` sont autoconfigures.
 
 ### Frontend
 
-- `/home/m-tristan/workspace/Coltura/frontend/modules/core/components/UserRbacDrawer.vue` :
+- `/home/m-tristan/workspace/Starseed/frontend/modules/core/components/UserRbacDrawer.vue` :
   - Charger `GET /api/sites?itemsPerPage=999` a l'ouverture du drawer (parallelement aux roles et permissions deja charges).
   - Ajouter une section `sidebar.admin.usersDrawer.sitesSection` sous la section permissions directes, avec un groupe de `MalioCheckbox` par site (ou un `MalioMultiSelect` si le composant existe dans `@malio/layer-ui`).
   - Etendre le payload `PATCH /api/users/{id}/rbac` avec `sites: Array<string>` (IRIs).
   - Auto-refresh de l'auth store apres save si `isSelfEdit` (deja present, conserver).
-- `/home/m-tristan/workspace/Coltura/frontend/shared/types/rbac.ts` : ajouter le champ `sites: string[]` a `UserListItem` (IRIs de sites attaches).
-- `/home/m-tristan/workspace/Coltura/frontend/shared/stores/auth.ts` : le store auth expose deja `user` via `/api/me`. Aucune modification requise, les nouveaux champs `sites` et `currentSite` suivent automatiquement via la typologie — a condition de mettre a jour le type `UserData` dans `shared/types/` (ajouter `sites: Site[]` et `currentSite: Site | null`).
-- `/home/m-tristan/workspace/Coltura/frontend/i18n/locales/fr.json` : cles
+- `/home/m-tristan/workspace/Starseed/frontend/shared/types/rbac.ts` : ajouter le champ `sites: string[]` a `UserListItem` (IRIs de sites attaches).
+- `/home/m-tristan/workspace/Starseed/frontend/shared/stores/auth.ts` : le store auth expose deja `user` via `/api/me`. Aucune modification requise, les nouveaux champs `sites` et `currentSite` suivent automatiquement via la typologie — a condition de mettre a jour le type `UserData` dans `shared/types/` (ajouter `sites: Site[]` et `currentSite: Site | null`).
+- `/home/m-tristan/workspace/Starseed/frontend/i18n/locales/fr.json` : cles
   - `sidebar.core.sites` = "Sites".
   - `admin.sites.title`, `admin.sites.newSite`, `admin.sites.editSite`, `admin.sites.createSite`, `admin.sites.noSites`.
   - `admin.sites.table.{name, city, postalCode, color, fullAddress}`.
@@ -228,7 +228,7 @@ final class CurrentSiteResource
 
 ## 6. Plan de migration Doctrine
 
-La migration est placee dans `/home/m-tristan/workspace/Coltura/migrations/Version<timestamp2>.php` au namespace racine (cf. Risque 2 du ticket 1 et `CLAUDE.md`).
+La migration est placee dans `/home/m-tristan/workspace/Starseed/migrations/Version<timestamp2>.php` au namespace racine (cf. Risque 2 du ticket 1 et `CLAUDE.md`).
 
 ### `up()` — ordre des instructions
 
@@ -590,3 +590,112 @@ Le ticket autorise un user sans sites (`sites: []`, `currentSite: null`). Mais a
 - [ ] `make test` passe toutes les suites (les 5 nouvelles + les existantes ajustees aux fixtures).
 - [ ] `make php-cs-fixer-allow-risky` propre sur les fichiers nouveaux et modifies.
 - [ ] Desactiver `SitesModule::class` dans `config/modules.php` ne casse pas les endpoints Core (la DB reste valide, les users conservent leurs sites meme si l'UI ne les expose plus).
+
+## 10. Evolutions post-livraison — drawer RBAC et defense in depth
+
+Apres la livraison initiale du ticket, un bug utilisateur a revele que le drawer
+`UserRbacDrawer.vue` demarrait toujours avec 0 site coche pour un user qui en
+avait en BDD, et que la sauvegarde ecrasait silencieusement les sites
+existants. Root cause : l'endpoint `GET /api/users` utilise le groupe `user:list`
+qui n'expose pas la collection `sites` (choix assume pour garder le payload
+leger et eviter toute fuite croisee site). Le drawer initialisait donc
+`selectedSiteIds` a partir d'un `user.sites` toujours `undefined`.
+
+Deux evolutions ont ete apportees pour corriger cela proprement sans elargir la
+surface de fuite de `/api/users` :
+
+### 10.1 — Nouvelle operation `GET /users/{id}/rbac`
+
+Une operation API Platform `Get` est ajoutee sur `User`, symetrique au `Patch`
+existant, sous la meme URI `/users/{id}/rbac` :
+
+```php
+new Get(
+    name: 'user_rbac_get',
+    uriTemplate: '/users/{id}/rbac',
+    security: "is_granted('core.users.manage')",
+    normalizationContext: ['groups' => ['user:rbac:read']],
+),
+```
+
+Raisons du design :
+- **Symetrie REST** : GET et PATCH partagent la meme URI et le meme groupe de
+  normalisation, documentation OpenAPI et appels clients lisibles.
+- **Separation list/detail** : `/api/users` (`user:list`) reste maigre — pas de
+  collection, pas de fuite. `/users/{id}/rbac` (`user:rbac:read`) porte le
+  detail riche requis par le drawer d'edition.
+- **Garde de permission plus stricte** : `core.users.manage` (et non `.view`)
+  — le detail RBAC est concu pour l'edition, pas la consultation.
+- **Isolation du couplage Sites** : la dependance au module Sites reste scopee
+  a cet endpoint et a `/api/me`. Elle n'est pas disseminee dans tous les
+  payloads de liste.
+
+Cote frontend (`UserRbacDrawer.vue`) :
+- `loadData(userId)` fetch desormais `/users/{id}/rbac` en parallele des
+  referentiels (roles, permissions, sites globaux).
+- Le watch combine `[modelValue, user.id]` recharge le detail a chaque
+  ouverture ou changement de user sans dependance fragile sur `props.user`.
+- Le type `UserListItem` perd `sites` (inutilise) ; un nouveau type
+  `UserRbacDetail` represente le payload du GET dedie.
+- La colonne "Sites" de `/admin/users` est retiree : l'info est consultee
+  dans le drawer. Cela supprime aussi le second fetch `/api/sites` sur la
+  page de liste.
+
+### 10.2 — Garde anti-ecrasement dans `UserRbacProcessor`
+
+API Platform denormalize les collections ManyToMany comme des `ArrayCollection`
+vides quand la cle JSON correspondante est absente du payload, violant la
+semantique `merge-patch+json` qui impose que les cles absentes ne mutent PAS
+les proprietes. Pour un PATCH qui ne veut toucher que `isAdmin`, cela
+detruirait tous les sites/roles/directPermissions du user.
+
+Le processor injecte desormais `RequestStack`, lit le body JSON brut au debut
+de `process()`, et pour chaque collection absente du payload restaure l'etat
+d'origine a partir du snapshot Doctrine :
+
+```php
+// Mapping cle JSON → accesseurs PHP (note : 'roles' → getRbacRoles)
+private const COLLECTION_MAP = [
+    'roles'             => ['getter' => 'getRbacRoles', ...],
+    'directPermissions' => ['getter' => 'getDirectPermissions', ...],
+    'sites'             => ['getter' => 'getSites', ...],
+];
+
+private function restoreAbsentCollections(User $user): void
+{
+    $payload = json_decode($this->requestStack->getCurrentRequest()?->getContent() ?? '', true);
+    foreach (self::COLLECTION_MAP as $jsonKey => $accessors) {
+        if (array_key_exists($jsonKey, $payload)) {
+            continue; // cle presente = la denormalisation fait foi
+        }
+        // cle absente = restaurer le snapshot PersistentCollection
+        // (voir implementation complete dans UserRbacProcessor.php)
+    }
+}
+```
+
+Semantique finale garantie :
+
+| Payload                         | Effet sur la collection            |
+|---------------------------------|------------------------------------|
+| Cle absente                     | Preservee (etat BDD inchange)      |
+| `"sites": []`                   | Collection videe explicitement     |
+| `"sites": ["/api/sites/1"]`     | Collection remplacee               |
+
+La garde `ensureCurrentSiteConsistency` continue de s'executer apres persist
+avec la meme logique : elle est triggered uniquement si la collection a
+effectivement mute (detection via `PersistentCollection::isDirty()` post-restore).
+
+### 10.3 — Criteres de validation additionnels
+
+- [ ] `GET /users/{id}/rbac` retourne 200 pour `core.users.manage`, 403 sinon.
+- [ ] Le payload contient `{ id, isAdmin, roles, directPermissions, sites }`.
+- [ ] `GET /api/users` ne contient plus `sites` (verification non-regression).
+- [ ] Ouvrir le drawer d'un user avec des sites en BDD affiche les cases
+      pre-cochees correspondantes.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "isAdmin": true }` (sans autre cle) ne
+      modifie pas sites/roles/directPermissions.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "sites": [] }` vide explicitement la
+      collection et bascule `currentSite` a `NULL` via la garde existante.
+- [ ] `PATCH /users/{id}/rbac` avec `{ "sites": [...] }` remplace la
+      collection comme auparavant.

docs/sites/ticket-03-spec.md

@@ -77,42 +77,42 @@ Resultat attendu : apres merge, un user avec ≥ 1 site voit une barre sous la n
 
 ### Frontend — Module Sites (layer deja cree au ticket 2)
 
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/components/SiteSelector.vue` : wrapper Vue autour de `MalioSiteSelector`. Branche `useCurrentSite()`, gere l'optimistic update et les toasts.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/composables/useCurrentSite.ts` : composable global exposant l'etat `currentSite` / `availableSites`, les actions `switchSite`, `resetCurrentSite`, et un flag `switching: Ref<boolean>` pour desactiver le selecteur pendant une requete en vol.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/components/SiteSelector.vue` : wrapper Vue autour de `MalioSiteSelector`. Branche `useCurrentSite()`, gere l'optimistic update et les toasts.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/composables/useCurrentSite.ts` : composable global exposant l'etat `currentSite` / `availableSites`, les actions `switchSite`, `resetCurrentSite`, et un flag `switching: Ref<boolean>` pour desactiver le selecteur pendant une requete en vol.
 
 ### Frontend — Shared
 
-- `/home/m-tristan/workspace/Coltura/frontend/shared/composables/useModules.ts` : composable qui charge `/api/modules` et expose `isModuleActive(id: string): boolean`. Pattern aligne sur `useSidebar()` : ref singleton au niveau module, chargement idempotent, `resetModules()` expose pour le logout.
-- `/home/m-tristan/workspace/Coltura/frontend/shared/utils/color.ts` : fonctions utilitaires de couleur, au minimum :
+- `/home/m-tristan/workspace/Starseed/frontend/shared/composables/useModules.ts` : composable qui charge `/api/modules` et expose `isModuleActive(id: string): boolean`. Pattern aligne sur `useSidebar()` : ref singleton au niveau module, chargement idempotent, `resetModules()` expose pour le logout.
+- `/home/m-tristan/workspace/Starseed/frontend/shared/utils/color.ts` : fonctions utilitaires de couleur, au minimum :
   - `parseHex(hex: string): { r: number; g: number; b: number }` — tolere la casse, rejette les formats hors `#RRGGBB`.
   - `getRelativeLuminance({r, g, b}): number` — formule WCAG standard.
   - `getReadableTextColor(hex: string): 'black' | 'white'` — renvoie `'black'` si la luminance > 0.5, `'white'` sinon. Seuil simple, suffisant pour un CRM interne (pas WCAG AAA).
 
 ### Frontend — Tests
 
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/composables/__tests__/useCurrentSite.spec.ts` : Vitest. Tests :
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/composables/__tests__/useCurrentSite.spec.ts` : Vitest. Tests :
   - `switchSite` met a jour l'etat localement avant la requete (optimistic).
   - Si la requete reussit, l'etat reste aligne.
   - Si la requete echoue, l'etat rollback a l'ancien `currentSite`.
   - `resetCurrentSite` vide l'etat.
-- `/home/m-tristan/workspace/Coltura/frontend/shared/composables/__tests__/useModules.spec.ts` : Vitest. Tests `isModuleActive` apres chargement, `resetModules` vide l'etat.
-- `/home/m-tristan/workspace/Coltura/frontend/shared/utils/__tests__/color.spec.ts` : Vitest. Jeu de donnees sur `getReadableTextColor` : `#000000` → white, `#FFFFFF` → black, `#056CF2` (bleu Coltura) → white, `#F59E0B` (ambre) → black, `#10B981` (vert) → black ou white selon seuil (a verifier). Tester aussi le rejet de formats invalides.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/sites/components/__tests__/SiteSelector.spec.ts` : smoke test Vitest.
+- `/home/m-tristan/workspace/Starseed/frontend/shared/composables/__tests__/useModules.spec.ts` : Vitest. Tests `isModuleActive` apres chargement, `resetModules` vide l'etat.
+- `/home/m-tristan/workspace/Starseed/frontend/shared/utils/__tests__/color.spec.ts` : Vitest. Jeu de donnees sur `getReadableTextColor` : `#000000` → white, `#FFFFFF` → black, `#056CF2` (bleu Starseed) → white, `#F59E0B` (ambre) → black, `#10B981` (vert) → black ou white selon seuil (a verifier). Tester aussi le rejet de formats invalides.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/sites/components/__tests__/SiteSelector.spec.ts` : smoke test Vitest.
 
 ## 4. Fichiers à modifier
 
-- `/home/m-tristan/workspace/Coltura/frontend/package.json` : upgrade `@malio/layer-ui` vers la version qui inclut `MalioSiteSelector`. Commit du `package-lock.json` dans le meme changeset.
-- `/home/m-tristan/workspace/Coltura/frontend/shared/types/user-data.ts` : ajouter les champs
+- `/home/m-tristan/workspace/Starseed/frontend/package.json` : upgrade `@malio/layer-ui` vers la version qui inclut `MalioSiteSelector`. Commit du `package-lock.json` dans le meme changeset.
+- `/home/m-tristan/workspace/Starseed/frontend/shared/types/user-data.ts` : ajouter les champs
   ```ts
   sites: Site[]
   currentSite: Site | null
   ```
   Import du type `Site` depuis `./sites`. Note : si le type `Site` a deja ete introduit au ticket 2, reutiliser ; sinon, ce ticket le cree dans `frontend/shared/types/sites.ts`.
-- `/home/m-tristan/workspace/Coltura/frontend/shared/types/sites.ts` : si absent, creer avec l'interface `Site` (cf. section Schema ticket 2 pour la forme). Si present, aucune modification.
-- `/home/m-tristan/workspace/Coltura/frontend/app/layouts/default.vue` : integrer `SiteSelector` sous le header, avant `<main>`, dans le flex column. Rendu conditionnel via `v-if="showSiteSelector"` ou via un `defineAsyncComponent` chargement lazy si on veut eviter l'import statique quand le module est off.
-- `/home/m-tristan/workspace/Coltura/frontend/app/middleware/auth.global.ts` : ajouter le chargement de `useModules().loadModules()` apres `loadSidebar()`. Necessaire pour que `isModuleActive` soit resolu quand le layout se rend.
-- `/home/m-tristan/workspace/Coltura/frontend/modules/core/pages/logout.vue` : appeler `useCurrentSite().resetCurrentSite()` et `useModules().resetModules()` apres le `auth.logout()`, aligne sur le pattern `resetSidebar()` deja present.
-- `/home/m-tristan/workspace/Coltura/frontend/i18n/locales/fr.json` : ajouter les cles
+- `/home/m-tristan/workspace/Starseed/frontend/shared/types/sites.ts` : si absent, creer avec l'interface `Site` (cf. section Schema ticket 2 pour la forme). Si present, aucune modification.
+- `/home/m-tristan/workspace/Starseed/frontend/app/layouts/default.vue` : integrer `SiteSelector` sous le header, avant `<main>`, dans le flex column. Rendu conditionnel via `v-if="showSiteSelector"` ou via un `defineAsyncComponent` chargement lazy si on veut eviter l'import statique quand le module est off.
+- `/home/m-tristan/workspace/Starseed/frontend/app/middleware/auth.global.ts` : ajouter le chargement de `useModules().loadModules()` apres `loadSidebar()`. Necessaire pour que `isModuleActive` soit resolu quand le layout se rend.
+- `/home/m-tristan/workspace/Starseed/frontend/modules/core/pages/logout.vue` : appeler `useCurrentSite().resetCurrentSite()` et `useModules().resetModules()` apres le `auth.logout()`, aligne sur le pattern `resetSidebar()` deja present.
+- `/home/m-tristan/workspace/Starseed/frontend/i18n/locales/fr.json` : ajouter les cles
   ```json
   "sites": {
       "selector": {

docs/sites/ticket-04-spec.md

@@ -34,50 +34,50 @@ Le ticket livre aussi une documentation developpeur (`docs/modules/site-aware.md
 
 ### Shared — Contrat
 
-- `/home/m-tristan/workspace/Coltura/src/Shared/Domain/Contract/SiteAwareInterface.php` : interface minimale. Depends uniquement du type `App\Module\Sites\Domain\Entity\Site`, qui est deja couple cote Core depuis le ticket 2 — le placement dans Shared n'introduit pas de nouvelle dependance transversale non souhaitee.
+- `/home/m-tristan/workspace/Starseed/src/Shared/Domain/Contract/SiteAwareInterface.php` : interface minimale. Depends uniquement du type `App\Module\Sites\Domain\Entity\Site`, qui est deja couple cote Core depuis le ticket 2 — le placement dans Shared n'introduit pas de nouvelle dependance transversale non souhaitee.
 
 ### Module Sites — Application
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Application/Service/CurrentSiteProvider.php` : service injecte partout ou le site courant doit etre lu (extensions, processor, futurs voters). Gere les trois cas de retour `null` : pas d'user, `currentSite` null, module desactive.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Application/Service/CurrentSiteProvider.php` : service injecte partout ou le site courant doit etre lu (extensions, processor, futurs voters). Gere les trois cas de retour `null` : pas d'user, `currentSite` null, module desactive.
 
 ### Module Sites — Infrastructure
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/ApiPlatform/Extension/SiteScopedQueryExtension.php` : une seule classe, implementant a la fois `QueryCollectionExtensionInterface` et `QueryItemExtensionInterface`. Le comportement est identique pour les deux, modulo que l'item manque retourne 404 (API Platform converti un `getOneOrNullResult` null en 404).
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/Infrastructure/ApiPlatform/State/Processor/SiteAwareInjectionProcessor.php` : decorator sur le persist processor Doctrine. Injecte le site courant sur `$data` si applicable, puis delegue a `$persistProcessor`.
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/ApiPlatform/Extension/SiteScopedQueryExtension.php` : une seule classe, implementant a la fois `QueryCollectionExtensionInterface` et `QueryItemExtensionInterface`. Le comportement est identique pour les deux, modulo que l'item manque retourne 404 (API Platform converti un `getOneOrNullResult` null en 404).
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/Infrastructure/ApiPlatform/State/Processor/SiteAwareInjectionProcessor.php` : decorator sur le persist processor Doctrine. Injecte le site courant sur `$data` si applicable, puis delegue a `$persistProcessor`.
 
 ### Documentation
 
-- `/home/m-tristan/workspace/Coltura/docs/modules/site-aware.md` : guide developpeur (cf. contenu section 10).
+- `/home/m-tristan/workspace/Starseed/docs/modules/site-aware.md` : guide developpeur (cf. contenu section 10).
 
 ### Tests
 
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Infrastructure/ApiPlatform/Extension/SiteScopedQueryExtensionTest.php` : tests d'integration (`KernelTestCase`) avec l'entite `FakeSiteAwareEntity` (declaree uniquement dans le dossier de tests). Verifie :
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Infrastructure/ApiPlatform/Extension/SiteScopedQueryExtensionTest.php` : tests d'integration (`KernelTestCase`) avec l'entite `FakeSiteAwareEntity` (declaree uniquement dans le dossier de tests). Verifie :
   - Le filtre s'applique sur une resource `SiteAware` quand le provider retourne un site.
   - Le filtre est no-op si `SiteAware` mais provider null.
   - Le filtre est no-op si resource non `SiteAware`.
   - Le filtre est no-op si user a `sites.bypass_scope`.
   - `totalItems` Hydra reflete bien le filtrage.
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Infrastructure/ApiPlatform/State/Processor/SiteAwareInjectionProcessorTest.php` : tests unitaires (`TestCase` pur) avec mocks. Verifie :
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Infrastructure/ApiPlatform/State/Processor/SiteAwareInjectionProcessorTest.php` : tests unitaires (`TestCase` pur) avec mocks. Verifie :
   - `$data` SiteAware sans site → injection du site courant.
   - `$data` SiteAware avec site deja positionne → pas d'overwrite.
   - `$data` non-SiteAware → delegation directe sans modification.
   - Provider retourne null (module off ou user sans site) ET `$data` SiteAware sans site → BadRequestHttpException (400) "aucun site selectionne".
-- `/home/m-tristan/workspace/Coltura/tests/Module/Sites/Application/Service/CurrentSiteProviderTest.php` : tests unitaires `TestCase`. Couvre :
+- `/home/m-tristan/workspace/Starseed/tests/Module/Sites/Application/Service/CurrentSiteProviderTest.php` : tests unitaires `TestCase`. Couvre :
   - User authentifie avec currentSite → retourne le Site.
   - User authentifie sans currentSite → null.
   - Pas d'user → null.
   - Module desactive dans config/modules.php de test → null meme si user.currentSite existe.
-- `/home/m-tristan/workspace/Coltura/tests/Fixtures/SiteAware/FakeSiteAwareEntity.php` : entite Doctrine minimale (`id`, `name`, `site`) utilisee **uniquement** en tests. Mapping Doctrine declare via un `#[ORM\Entity]` mais la table n'existe jamais en prod car la fixture n'est jamais chargee hors tests. **Alternative** : utiliser un schema DB dedie au dossier de tests, cree a la volee par un helper setUp. A trancher a l'implementation.
+- `/home/m-tristan/workspace/Starseed/tests/Fixtures/SiteAware/FakeSiteAwareEntity.php` : entite Doctrine minimale (`id`, `name`, `site`) utilisee **uniquement** en tests. Mapping Doctrine declare via un `#[ORM\Entity]` mais la table n'existe jamais en prod car la fixture n'est jamais chargee hors tests. **Alternative** : utiliser un schema DB dedie au dossier de tests, cree a la volee par un helper setUp. A trancher a l'implementation.
 
 ## 4. Fichiers à modifier
 
-- `/home/m-tristan/workspace/Coltura/src/Module/Sites/SitesModule.php` : ajouter la permission `sites.bypass_scope` dans `permissions()` :
+- `/home/m-tristan/workspace/Starseed/src/Module/Sites/SitesModule.php` : ajouter la permission `sites.bypass_scope` dans `permissions()` :
   ```php
   ['code' => 'sites.bypass_scope', 'label' => 'Voir les donnees site-scoped de tous les sites (bypass du filtrage)'],
   ```
   **Note importante** : la methode `permissions()` signale l'existence de la permission mais c'est la commande `app:sync-permissions` (inchangee) qui la positionne en base.
-- `/home/m-tristan/workspace/Coltura/config/services.yaml` : aucun changement requis. `SiteScopedQueryExtension`, `SiteAwareInjectionProcessor` et `CurrentSiteProvider` sont autoconfigures via les `_defaults` du module. Le decorator du persist processor est declare via `#[AsDecorator]` ou via tag (cf. section 8).
-- `/home/m-tristan/workspace/Coltura/phpunit.dist.xml` : aucune modification requise si la config des fixtures de tests est autonome. Si `FakeSiteAwareEntity` necessite un mapping dedie, l'option la plus propre est un `doctrine.yaml.test` ajoute via `when@test`, sans polluer la config dev/prod (cf. Risque 3).
+- `/home/m-tristan/workspace/Starseed/config/services.yaml` : aucun changement requis. `SiteScopedQueryExtension`, `SiteAwareInjectionProcessor` et `CurrentSiteProvider` sont autoconfigures via les `_defaults` du module. Le decorator du persist processor est declare via `#[AsDecorator]` ou via tag (cf. section 8).
+- `/home/m-tristan/workspace/Starseed/phpunit.dist.xml` : aucune modification requise si la config des fixtures de tests est autonome. Si `FakeSiteAwareEntity` necessite un mapping dedie, l'option la plus propre est un `doctrine.yaml.test` ajoute via `when@test`, sans polluer la config dev/prod (cf. Risque 3).
 
 ## 5. Contrat `SiteAwareInterface`
 
@@ -459,7 +459,7 @@ A mitiger par un test qui genere une entite `FakeSiteAwareEntity` via un POST `a
 
 ### Risque 8 — Doc developpeur en francais vs anglais
 
-Le fichier `docs/modules/site-aware.md` s'adresse aux developpeurs de Coltura. Il est redige en **francais**, aligne sur la convention projet (CLAUDE.md : "commentaires en francais, code en anglais"). Aucun extrait de code ne doit etre traduit, seules les explications.
+Le fichier `docs/modules/site-aware.md` s'adresse aux developpeurs de Starseed. Il est redige en **francais**, aligne sur la convention projet (CLAUDE.md : "commentaires en francais, code en anglais"). Aucun extrait de code ne doit etre traduit, seules les explications.
 
 ## 12. Plan de tests
 

docs/specs/M0-categories/spec-front.md

@@ -0,0 +1,113 @@
+---
+# === IDENTITÉ ===
+module: M0
+nom: "Gestion des catégories"
+ecran: gestion-categories
+owner_spec: Matthieu
+backup_spec: Tristan
+version: V0
+date_redaction: 2026-05-22
+
+# === LIENS ===
+maquette_figma: null                # pas de Figma — UI admin standard
+regles_metier: [RG-1.01, RG-1.02, RG-1.03, RG-1.04, RG-1.05, RG-1.06, RG-1.07, RG-1.08, RG-1.09, RG-1.10, RG-1.11, RG-1.12, RG-1.13]
+roles: [Admin, Bureau, Compta, Commerciale, Usine]
+lien_spec_back: ./spec-back.md
+
+# === VALIDATION CLIENT #1 ===
+client_validation_1:
+  statut: validee                   # V0 client validée le 22/05/2026
+  date: 2026-05-22
+  canal: ecrit
+  valide_par: "Matthieu (CP MALIO) — validation implicite, périmètre projet"
+  resume: "Module 0 — Gestion des catégories. Page admin (datatable + drawer). 2 champs (Nom + Type), 3 actions (Ajouter / Consulter / Modifier). Admin only."
+  trace_archivee: "uploads/c4ebb6b4-M0categories.docx (V0 d'origine .docx) — restitué ci-dessous en Markdown."
+
+# === LIEN LESSTIME ===
+lesstime_taskgroup_id: 22
+lesstime_project_id: 6              # ERP / Starseed
+statut_global: en_dev               # tickets créés en backlog Lesstime le 2026-05-26
+---
+
+# Module 0 — Gestion des catégories (V0 front)
+
+> **Origine** : spec front V0 livrée le 22/05/2026 (`c4ebb6b4-M0categories.docx` + `f665acfb-M0categoriesV0.pdf`). Restitution Markdown fidèle pour intégration au workflow MALIO. Le contenu original n'est pas modifié — toute reformulation et précision (en particulier côté back) vit dans [`spec-back.md`](./spec-back.md).
+
+## But
+
+Permettre à un administrateur Starseed de gérer un référentiel de **catégories** depuis l'interface admin du logiciel. Ces catégories seront utilisées plus tard pour classifier les tiers (clients, fournisseurs, prestataires).
+
+## Accès
+
+- **Depuis** : menu principal → **Administration** → entrée « Gestion des catégories »
+- **Rôles autorisés** : **Admin uniquement** (Bureau / Compta / Commerciale / Usine n'ont **aucun** accès, ni lecture ni écriture).
+
+## Navigation
+
+L'écran est la page d'entrée du Module **Administration**. Titre de la page : « **Gestion des catégories** ».
+
+- Affichage principal : un **datatable** listant toutes les catégories existantes.
+- **Clic sur une ligne** → ouverture d'un **drawer** latéral en mode **consultation / modification** (cf. § Action « Consulter »).
+- **Bouton « + Ajouter »** (en haut à droite du datatable) → ouverture d'un **drawer** en mode **création** (cf. § Action « Ajouter »).
+- Pas d'onglet, pas de pagination explicite (volumétrie cible faible).
+
+## Actions
+
+| Action | Déclencheur | Comportement |
+|---|---|---|
+| **Ajouter** | Clic sur le bouton « + Ajouter » | Ouvre le drawer en mode création, formulaire vide. Validation → POST → la catégorie apparaît dans le datatable. |
+| **Consulter** | Clic sur une ligne du datatable | Ouvre le drawer avec les champs pré-remplis en lecture (et passage en édition si l'utilisateur modifie un champ). |
+| **Modifier** | Modification d'un champ dans le drawer ouvert en consultation | Validation → PATCH → la ligne du datatable se met à jour. |
+
+> **Note V0** : la **suppression** n'était pas mentionnée dans la V0 client. Côté workflow MALIO, suite à la revue back (cf. `spec-back.md` § Q3), un soft delete est ajouté (corbeille logique). L'UI peut intégrer ce point lors d'une V1 — au M0 le bouton « Supprimer » n'est pas obligatoire, mais doit être facilement ajoutable.
+
+## Formulaire — Champs
+
+Le formulaire (drawer) contient **2 champs**, tous deux obligatoires :
+
+| Champ | Type | Obligatoire | Contenu / valeur par défaut | Règle |
+|---|---|---|---|---|
+| **Nom** | Texte libre | **Oui** | vide à la création | Pas de règle métier détaillée en V0. Détails côté back : RG-1.02 / RG-1.03 / RG-1.04 (obligatoire, trim, longueur 2–120). |
+| **Type de catégorie** | Select | **Oui** | vide à la création | Le contenu du Select n'était pas précisé en V0. Décision back : entité de référence `CategoryType` séparée (RG-1.05 / RG-1.06). Le référentiel sera alimenté plus tard (cf. HP-1 dans `spec-back.md`). |
+
+> **Note V0** : la V0 ne précisait ni si le `Type de catégorie` est un enum hardcodé ni si c'est une autre entité. Décision tranchée côté back avant découpe en tickets : **entité de référence** (`category_types`), table créée vide au M0.
+
+## Permissions par rôle
+
+| Rôle | Vue (`GET`) | Création (`POST`) | Édition (`PATCH`) | Suppression (`DELETE`) |
+|---|---|---|---|---|
+| **Admin** | ✅ | ✅ | ✅ | ✅ (soft delete — ajout post-V0) |
+| Bureau | ❌ | ❌ | ❌ | ❌ |
+| Compta | ❌ | ❌ | ❌ | ❌ |
+| Commerciale | ❌ | ❌ | ❌ | ❌ |
+| Usine | ❌ | ❌ | ❌ | ❌ |
+
+→ Les rôles non-Admin ne voient **pas** l'entrée de menu et reçoivent **403** sur toute requête vers les endpoints `/api/categories/*` (cf. RG-1.01 dans `spec-back.md`).
+
+## Composants UI à utiliser (Starseed / `@malio/layer-ui`)
+
+- **Datatable** : `<MalioDataTable>` (avec colonnes `Nom` + `Type` + actions, tri par défaut sur Nom).
+- **Drawer** : drawer latéral standard `@malio/layer-ui` (à confirmer côté front avec le composant exact).
+- **Input texte** : `<MalioInputText>` pour le champ Nom.
+- **Select** : `<MalioSelect>` pour le champ Type de catégorie, alimenté par `GET /api/category_types`.
+- **Bouton** : `<MalioButton>` (« + Ajouter », « Enregistrer », « Annuler »).
+- **Toasts succès / erreur** : standards via `useApi()`.
+
+## Points laissés ouverts par la V0 (résolus côté back)
+
+| # | Zone d'ombre V0 | Résolution (cf. `spec-back.md`) |
+|---|---|---|
+| 1 | Suppression non mentionnée | **Soft delete** ajouté (RG-1.12 + RG-1.13). UI peut ajouter le bouton plus tard. |
+| 2 | Unicité du nom non précisée | **Unicité sur `(name, type)` case-insensitive**, parmi non-soft-deleted (RG-1.07). |
+| 3 | Nature du `Type de catégorie` (enum vs entité) | **Entité de référence** `CategoryType` (table vide au M0, créée par migration). |
+| 4 | Volumétrie & pagination | **300 max** → pagination front (`<MalioDataTable>`), pas de pagination serveur. Tri serveur `name ASC` par défaut. |
+| 5 | Audit / traçabilité | Pattern `#[Auditable]` Starseed standard. Trace dans la table `audit_log` (qui / quoi / quand / diff). **Pas** de colonnes `created_by` / `updated_by` sur l'entité (cohérent avec User / Role dans Starseed). Historique consultable via `/api/audit-log?entityType=Category&entityId={id}`. |
+| 6 | Référencement par d'autres entités | **Aucune FK entrante au M0.** Les modules Tiers (M-Clients / M-Fournisseurs / M-Prestas) ajouteront leur propre `category_id` plus tard. |
+
+---
+
+## 📦 Tickets Lesstime générés
+
+**TaskGroup Lesstime** : `#22 — M0 — Gestion des catégories` (projet `ERP / Starseed`, projectId=6)
+
+> Détail complet, table des tickets et action manuelle dans Lesstime → voir [`spec-back.md § Tickets Lesstime générés`](./spec-back.md#-tickets-lesstime-générés).

docs/specs/M1-clients/2026-06-04-validation-blocs-collection-design.md

@@ -0,0 +1,146 @@
+# Validation « tous les blocs » sur les onglets à blocs dynamiques (Client M1)
+
+> Date : 2026-06-04 · Module : Commercial (M1 Clients) · Tickets liés : ERP-101 / ERP-107
+> Écrans : `clients/new.vue`, `clients/[id]/edit.vue` · Onglets concernés : Contacts, Adresses, RIB
+
+## 1. Problème
+
+À la soumission des onglets à **blocs d'ajout dynamiques** (Contacts / Adresses / RIB), la validation
+par champ ne s'affiche pas correctement. Deux causes **distinctes et cumulées** :
+
+### Cause A — 500 back qui court-circuite la validation (cause racine)
+
+Les opérations `Post` des sous-ressources sont déclarées ainsi :
+
+```php
+new Post(
+    uriTemplate: '/clients/{clientId}/contacts',
+    uriVariables: ['clientId' => new Link(fromClass: Client::class, toProperty: 'client')],
+    processor: ClientContactProcessor::class,
+)
+```
+
+Au stade « read » du POST, API Platform résout `clientId` via `LinksHandlerTrait` (branche `toProperty`,
+`vendor/api-platform/doctrine-orm/State/LinksHandlerTrait.php:134-141`). La requête générée porte sur
+l'entité **enfant** :
+
+```sql
+SELECT o FROM ClientContact o INNER JOIN o.client c WHERE c.id = :clientId
+```
+
+exécutée via `ItemProvider::provide` → `getOneOrNullResult()`
+(`vendor/api-platform/doctrine-orm/State/ItemProvider.php:89`). Donc :
+
+| Nb d'enfants du client | Lignes retournées | Résultat |
+|---|---|---|
+| 0 | 0 | `null` → OK (cas du test CI actuel) |
+| 1 | 1 | OK |
+| **≥ 2** | **≥ 2** | **`NonUniqueResultException` → HTTP 500** |
+
+Conséquence : un client à ≥2 contacts (resp. adresses, RIB) ne peut plus en recevoir un nouveau.
+La 500 survient **avant** la déserialisation/validation → aucune 422 n'est produite → `mapRowError`
+(qui ne mappe que les 422) retombe sur un toast générique.
+
+Les **3** sous-ressources ont strictement la même config → même bug latent (contacts est juste le
+premier à sauter car les clients de démo ont 3 contacts).
+
+### Cause B — la boucle front s'arrête au premier bloc en erreur
+
+`submitContacts` / `submitAddresses` / boucle RIB de `submitAccounting` (dans `new.vue` ET `edit.vue`)
+font `return` dans le `catch` du premier bloc en échec :
+
+```js
+catch (error) {
+    if (!mapRowError(error, contactErrors, index)) { toast(...) }
+    return   // ← stoppe : les blocs suivants ne sont jamais validés ni affichés
+}
+```
+
+→ même une fois le 500 corrigé, seules les erreurs du **premier** bloc fautif s'afficheraient.
+
+## 2. Objectif
+
+À la validation d'un onglet collection, **tenter tous les blocs** et **afficher l'erreur inline sous
+chaque champ fautif, pour chaque bloc**, en un seul aller-retour de soumission. Pas de toast récapitulatif
+(décision : inline seul, cohérent ERP-101). Pas de toast succès tant qu'au moins un bloc reste en erreur.
+
+Hors périmètre : le workflow incrémental (créer le client, puis débloquer les onglets) reste inchangé ;
+les onglets scalaires (Principal / Information / Comptabilité-scalaires) fonctionnent déjà et ne sont pas
+touchés.
+
+## 3. Conception
+
+### 3.1 Back — supprimer le read cassé du POST (cause racine)
+
+Sur les opérations `Post` de `ClientContact`, `ClientAddress`, `ClientRib` :
+
+- Ajouter **`read: false`**. Le stade « read » est inutile : le `*Processor::linkParent` rattache déjà le
+  parent manuellement via `$em->getRepository(Client::class)->find($clientId)`. Pattern déjà employé dans
+  le projet (`Sites/.../CurrentSiteResource.php`).
+- Durcir les 3 `linkParent` : si `find($clientId)` renvoie `null`, lever
+  `Symfony\Component\HttpKernel\Exception\NotFoundHttpException` (préserve le **404** sur parent
+  inexistant — sans le read, on régresserait sinon en 500 au persist sur `client_id NOT NULL`).
+
+Effet : plus de `getOneOrNullResult` foireux → déserialisation + validation Symfony s'exécutent → **422
+propre par champ** avec `violations[].propertyPath` (déjà garanti par ERP-107 : messages FR explicites).
+
+Aucune autre modification (security, normalizationContext, processor restant) n'est nécessaire.
+
+### 3.2 Front — collecter les erreurs de tous les blocs
+
+Dans `submitContacts`, `submitAddresses`, et la boucle RIB de `submitAccounting`, **dans `new.vue` ET
+`edit.vue`** :
+
+- Conserver la réinitialisation du tableau d'erreurs en début de submit (`xxxErrors.value = []`).
+- Introduire un drapeau local `hasError`. Dans le `catch`, remplacer `return` par
+  `hasError = true; continue` → la boucle tente/valide **tous** les blocs ; chaque 422 se mappe sur
+  `xxxErrors[index]` via `mapRowError` (mécanique existante, inchangée).
+- Après la boucle : si `hasError` → **ne pas** appeler `completeTab(...)`, **pas** de toast succès. Sinon
+  → comportement actuel (`completeTab` + toast succès).
+- Les blocs déjà créés (id non-null) repassent en `PATCH` au resubmit → idempotent, pas de doublon.
+- Awaits **séquentiels** conservés (volume faible, ordre des blocs préservé, pas de course).
+
+Le binding inline est déjà en place côté template (`:errors="contactErrors[index]"` /
+`:error="ribErrors[index]?.iban"` …). Aucun changement de composant `Malio*` requis.
+
+### 3.3 Réutilisation / isolation
+
+Le bloc « boucle de soumission d'une collection avec collecte d'erreurs par index » est dupliqué 3× × 2
+pages. Pour rester testable et DRY, extraire un helper de soumission de collection (ex.
+`submitCollection(rows, { buildBody, post, patch, errors })` retournant `{ hasError }`) consommé par les
+6 sites d'appel. À acter dans le plan d'implémentation (option : garder inline si l'extraction dégrade la
+lisibilité — décision lors du plan).
+
+## 4. Tests
+
+### Back (TDD — échouent d'abord)
+
+Dans `tests/Module/Commercial/Api/ClientSubResourceApiTest` :
+
+- `testPostContactToClientWithTwoExistingContactsReturns201` : seed un client + 2 contacts, POST un 3ᵉ →
+  attendu **201** (rouge aujourd'hui : 500).
+- `testPostContactInvalidEmailOnClientWithExistingContactsReturns422` : même seed, POST email invalide →
+  **422** avec `propertyPath=email` et message FR (vérifie que la validation est bien atteinte).
+- Variantes germes pour adresses et RIB (au moins une chacune) pour verrouiller les 3 sous-ressources.
+
+Pré-requis : helper de seed de contacts/adresses/RIB dans `AbstractCommercialApiTestCase` (ajouter si
+absent).
+
+### Front (Vitest)
+
+- Si helper `submitCollection` extrait : test unitaire « 3 blocs, le 2ᵉ renvoie 422 → les erreurs du 2ᵉ
+  sont mappées, les blocs 1 et 3 sont tentés, `hasError = true`, tab non complété ».
+- Sinon : test de composant sur `ClientContactBlock` + page, vérifiant l'affichage inline multi-blocs.
+
+### Vérifications finales
+
+`make test` + `make php-cs-fixer-allow-risky` (back), `make nuxt-test` (front). Golden path manuel :
+client à 3 contacts, ajouter un 4ᵉ avec email invalide → 422 inline sous l'email du bon bloc, pas de 500.
+
+## 5. Impact / risques
+
+- API contract : POST sous-ressource passe de 500→201/422 (correction) ; 404 préservé sur parent
+  inexistant. Pas de changement de payload ni de réponse de succès.
+- Le test fonctionnel CI actuel (POST sur client à 0 contact) reste vert.
+- Régression possible si un consommateur dépendait du read implicite du parent au POST : aucun identifié
+  (les 3 processors gèrent déjà le rattachement manuellement).

docs/specs/M1-clients/2026-06-04-validation-blocs-collection-plan.md

@@ -0,0 +1,633 @@
+# Validation « tous les blocs » — onglets à blocs dynamiques (Client M1) — Plan d'implémentation
+
+> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** Permettre la validation 422 par champ sur TOUS les blocs des onglets Contacts / Adresses / RIB d'un client (création + édition), en supprimant la 500 `NonUniqueResultException` qui les bloque dès ≥2 enfants et en ne stoppant plus la boucle front au premier bloc en erreur.
+
+**Architecture:** Côté back, on retire le stade « read » inutile du POST des 3 sous-ressources (`read: false`) — le parent est déjà rattaché manuellement par le processor — et on durcit ce rattachement (404 si parent absent). Côté front, on factorise la boucle de soumission de collection dans `useClientFormErrors().submitRows(...)` qui tente tous les blocs et collecte les erreurs par index, puis on branche les 6 sites d'appel (`new.vue` + `edit.vue` × contacts/adresses/RIB).
+
+**Tech Stack:** Symfony 8 / API Platform 4 (PHP 8.4, PHPUnit) ; Nuxt 4 / Vue 3 / TypeScript / Vitest.
+
+**Spec de référence :** `docs/superpowers/specs/2026-06-04-client-collection-blocks-validation-design.md`
+
+**Pré-vol :** `make start` (containers up), branche de travail = celle de la MR (`feat/erp-107-validation-messages-fr`) ou une branche dédiée selon décision utilisateur.
+
+---
+
+## Structure des fichiers
+
+**Back — modifiés :**
+- `src/Module/Commercial/Domain/Entity/ClientContact.php` — `read: false` sur `Post`
+- `src/Module/Commercial/Domain/Entity/ClientAddress.php` — `read: false` sur `Post`
+- `src/Module/Commercial/Domain/Entity/ClientRib.php` — `read: false` sur `Post`
+- `src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/ClientContactProcessor.php` — `linkParent` → 404
+- `.../Processor/ClientAddressProcessor.php` — idem
+- `.../Processor/ClientRibProcessor.php` — idem
+- `tests/Module/Commercial/Api/AbstractCommercialApiTestCase.php` — helper `seedContact()`
+- `tests/Module/Commercial/Api/ClientSubResourceApiTest.php` — tests de non-régression
+
+**Front — modifiés :**
+- `frontend/modules/commercial/composables/useClientFormErrors.ts` — méthode `submitRows()`
+- `frontend/modules/commercial/composables/__tests__/useClientFormErrors.spec.ts` — créé (test unitaire)
+- `frontend/modules/commercial/pages/clients/new.vue` — branchements (3 submits)
+- `frontend/modules/commercial/pages/clients/[id]/edit.vue` — branchements (3 submits)
+
+---
+
+## Task 1 : Back — test rouge (POST sur client à ≥2 enfants)
+
+**Files:**
+- Modify: `tests/Module/Commercial/Api/AbstractCommercialApiTestCase.php`
+- Test: `tests/Module/Commercial/Api/ClientSubResourceApiTest.php`
+
+- [ ] **Step 1 : Ajouter un helper de seed de contact à la base de test**
+
+Dans `AbstractCommercialApiTestCase.php`, ajouter (sous `seedClient`, avant `cleanupCommercialTestData`) :
+
+```php
+    /**
+     * Seede directement un ClientContact en base (sans passer par l'API), pour
+     * preparer un client deja dote de N contacts. Au moins le prenom est pose
+     * (RG-1.05 / CHECK chk_client_contact_name).
+     */
+    protected function seedContact(ClientEntity $client, string $firstName): \App\Module\Commercial\Domain\Entity\ClientContact
+    {
+        $em      = $this->getEm();
+        $contact = new \App\Module\Commercial\Domain\Entity\ClientContact();
+        $contact->setClient($client);
+        $contact->setFirstName($firstName);
+        $em->persist($contact);
+        $em->flush();
+
+        return $contact;
+    }
+```
+
+- [ ] **Step 2 : Écrire les tests rouges**
+
+Dans `ClientSubResourceApiTest.php`, ajouter dans la section `// === Contacts ===` :
+
+```php
+    /**
+     * Regression ERP (bug subresource Link toProperty) : POST d'un contact sur un
+     * client qui en a DEJA >= 2 ne doit pas exploser en 500
+     * (NonUniqueResultException sur la resolution du parent), mais creer (201).
+     */
+    public function testPostContactOnClientWithTwoExistingContactsReturns201(): void
+    {
+        $client = $this->createAdminClient();
+        $seed   = $this->seedClient('Contact Multi');
+        $this->seedContact($seed, 'Alpha');
+        $this->seedContact($seed, 'Beta');
+
+        $client->request('POST', '/api/clients/'.$seed->getId().'/contacts', [
+            'headers' => ['Content-Type' => self::LD, 'Accept' => self::LD],
+            'json'    => ['firstName' => 'Gamma'],
+        ]);
+
+        self::assertResponseStatusCodeSame(201);
+    }
+
+    /**
+     * Meme contexte (>= 2 contacts existants) : un email invalide doit produire
+     * une 422 par champ (la validation est bien atteinte), pas une 500.
+     */
+    public function testPostInvalidContactOnPopulatedClientReturns422OnField(): void
+    {
+        $client = $this->createAdminClient();
+        $seed   = $this->seedClient('Contact Multi Bad');
+        $this->seedContact($seed, 'Alpha');
+        $this->seedContact($seed, 'Beta');
+
+        $response = $client->request('POST', '/api/clients/'.$seed->getId().'/contacts', [
+            'headers' => ['Content-Type' => self::LD, 'Accept' => self::LD],
+            'json'    => ['firstName' => 'Gamma', 'email' => 'pas-un-email'],
+        ]);
+
+        self::assertResponseStatusCodeSame(422);
+        $byPath = [];
+        foreach ($response->toArray(false)['violations'] ?? [] as $v) {
+            $byPath[$v['propertyPath']] = $v['message'];
+        }
+        self::assertArrayHasKey('email', $byPath);
+        self::assertSame('L\'adresse email n\'est pas valide.', $byPath['email']);
+    }
+```
+
+- [ ] **Step 3 : Lancer les tests, vérifier qu'ils échouent (500 au lieu de 201/422)**
+
+Run : `make test` (ou ciblé dans le container : `docker exec php-starseed-fpm php bin/phpunit --filter ClientSubResourceApiTest`)
+Expected : les 2 nouveaux tests ÉCHOUENT (HTTP 500 `NonUniqueResultException`). `testPostContactOnClient...` reçoit 500, pas 201.
+
+- [ ] **Step 4 : Commit (test rouge)**
+
+```bash
+git add tests/Module/Commercial/Api/AbstractCommercialApiTestCase.php tests/Module/Commercial/Api/ClientSubResourceApiTest.php
+git commit -m "test(commercial) : reproduit la 500 NonUniqueResult au POST contact sur client peuple (ERP-107)"
+```
+
+---
+
+## Task 2 : Back — fix (read:false + linkParent durci) → tests verts
+
+**Files:**
+- Modify: `src/Module/Commercial/Domain/Entity/ClientContact.php:48-57`
+- Modify: `src/Module/Commercial/Domain/Entity/ClientAddress.php:61-70`
+- Modify: `src/Module/Commercial/Domain/Entity/ClientRib.php:52-61`
+- Modify: `.../State/Processor/ClientContactProcessor.php:76-94`
+- Modify: `.../State/Processor/ClientAddressProcessor.php:63-81`
+- Modify: `.../State/Processor/ClientRibProcessor.php:65-83`
+
+- [ ] **Step 1 : `read: false` sur les 3 opérations `Post`**
+
+`ClientContact.php`, opération `Post` — ajouter la ligne `read: false,` :
+
+```php
+        new Post(
+            uriTemplate: '/clients/{clientId}/contacts',
+            uriVariables: [
+                'clientId' => new Link(fromClass: Client::class, toProperty: 'client'),
+            ],
+            // read:false : pas de stade lecture du parent (le Link toProperty
+            // resoudrait l'enfant et casse en NonUniqueResult des >= 2 enfants).
+            // Le parent est rattache par ClientContactProcessor::linkParent.
+            read: false,
+            security: "is_granted('commercial.clients.manage')",
+            normalizationContext: ['groups' => ['client_contact:read']],
+            denormalizationContext: ['groups' => ['client_contact:write']],
+            processor: ClientContactProcessor::class,
+        ),
+```
+
+`ClientAddress.php` — idem dans son `Post` (`security: commercial.clients.manage`, processor `ClientAddressProcessor`), commentaire pointant `ClientAddressProcessor::linkParent`.
+
+`ClientRib.php` — idem dans son `Post` (`security: commercial.clients.accounting.manage`, processor `ClientRibProcessor`), commentaire pointant `ClientRibProcessor::linkParent`.
+
+- [ ] **Step 2 : Durcir les 3 `linkParent` (404 si parent absent)**
+
+Dans chaque processor, ajouter l'import en tête de fichier :
+
+```php
+use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;
+```
+
+`ClientContactProcessor::linkParent` — remplacer le bloc final par :
+
+```php
+        if (null === $clientId) {
+            return;
+        }
+
+        $client = $clientId instanceof Client
+            ? $clientId
+            : $this->em->getRepository(Client::class)->find($clientId);
+
+        // read:false sur le POST : sans stade lecture, un parent introuvable
+        // n'est plus intercepte en amont -> 404 explicite (sinon 500 au persist
+        // sur client_id NOT NULL).
+        if (!$client instanceof Client) {
+            throw new NotFoundHttpException('Client introuvable.');
+        }
+
+        $contact->setClient($client);
+```
+
+`ClientAddressProcessor::linkParent` — idem avec `$address->setClient($client);`.
+`ClientRibProcessor::linkParent` — idem avec `$rib->setClient($client);`.
+
+- [ ] **Step 3 : Lancer les tests, vérifier qu'ils passent**
+
+Run : `make test`
+Expected : les 2 tests de Task 1 PASSENT (201 + 422 `propertyPath=email`). Aucun test existant cassé (notamment `testPostContactInvalidEmailReturns422WithFrenchMessageOnField` et les tests d'archi ERP-107 restent verts).
+
+- [ ] **Step 4 : Lint PHP**
+
+Run : `make php-cs-fixer-allow-risky`
+Expected : 0 fichier à corriger (ou corrections appliquées et re-vérifiées).
+
+- [ ] **Step 5 : Commit (fix back)**
+
+```bash
+git add src/Module/Commercial/Domain/Entity/ClientContact.php src/Module/Commercial/Domain/Entity/ClientAddress.php src/Module/Commercial/Domain/Entity/ClientRib.php src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/ClientContactProcessor.php src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/ClientAddressProcessor.php src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/ClientRibProcessor.php
+git commit -m "fix(commercial) : POST sous-ressource client en read:false + parent 404 (corrige 500 NonUniqueResult, ERP-107)"
+```
+
+---
+
+## Task 3 : Back — germes adresses + RIB (verrouille les 3 sous-ressources)
+
+**Files:**
+- Modify: `tests/Module/Commercial/Api/AbstractCommercialApiTestCase.php` (helpers `seedAddress`, `seedRib`)
+- Test: `tests/Module/Commercial/Api/ClientSubResourceApiTest.php`
+
+- [ ] **Step 1 : Helpers de seed adresse + RIB**
+
+Dans `AbstractCommercialApiTestCase.php`, ajouter :
+
+```php
+    /** Seede une adresse minimale valide (RG : CP/ville/rue requis). */
+    protected function seedAddress(ClientEntity $client, string $city): \App\Module\Commercial\Domain\Entity\ClientAddress
+    {
+        $em      = $this->getEm();
+        $address = new \App\Module\Commercial\Domain\Entity\ClientAddress();
+        $address->setClient($client);
+        $address->setPostalCode('33000');
+        $address->setCity($city);
+        $address->setStreet('1 rue du Test');
+        $em->persist($address);
+        $em->flush();
+
+        return $address;
+    }
+
+    /** Seede un RIB valide (BIC/IBAN conformes). */
+    protected function seedRib(ClientEntity $client, string $label): \App\Module\Commercial\Domain\Entity\ClientRib
+    {
+        $em  = $this->getEm();
+        $rib = new \App\Module\Commercial\Domain\Entity\ClientRib();
+        $rib->setClient($client);
+        $rib->setLabel($label);
+        $rib->setBic('BNPAFRPPXXX');
+        $rib->setIban('FR1420041010050500013M02606');
+        $em->persist($rib);
+        $em->flush();
+
+        return $rib;
+    }
+```
+
+> Note : si une propriété est non-nullable et absente ci-dessus (ex. `position`, flags d'adresse), poser les setters correspondants avec une valeur par défaut neutre — vérifier les entités `ClientAddress` / `ClientRib` au moment de l'écriture.
+
+- [ ] **Step 2 : Tests de non-régression adresses + RIB**
+
+Dans `ClientSubResourceApiTest.php`, section adresses puis RIB :
+
+```php
+    public function testPostAddressOnClientWithTwoExistingAddressesReturns201(): void
+    {
+        $client = $this->createAdminClient();
+        $seed   = $this->seedClient('Addr Multi');
+        $this->seedAddress($seed, 'Bordeaux');
+        $this->seedAddress($seed, 'Lyon');
+
+        $client->request('POST', '/api/clients/'.$seed->getId().'/addresses', [
+            'headers' => ['Content-Type' => self::LD, 'Accept' => self::LD],
+            'json'    => ['postalCode' => '75001', 'city' => 'Paris', 'street' => '2 rue Neuve'],
+        ]);
+
+        self::assertResponseStatusCodeSame(201);
+    }
+
+    public function testPostRibOnClientWithTwoExistingRibsReturns201(): void
+    {
+        $client = $this->createAdminClient();
+        $seed   = $this->seedClient('Rib Multi');
+        $this->seedRib($seed, 'Compte 1');
+        $this->seedRib($seed, 'Compte 2');
+
+        $client->request('POST', '/api/clients/'.$seed->getId().'/ribs', [
+            'headers' => ['Content-Type' => self::LD, 'Accept' => self::LD],
+            'json'    => ['label' => 'Compte 3', 'bic' => self::VALID_BIC, 'iban' => self::VALID_IBAN],
+        ]);
+
+        self::assertResponseStatusCodeSame(201);
+    }
+```
+
+> Le POST RIB exige `commercial.clients.accounting.manage` — `admin` (ROLE_ADMIN) l'a. Si une 403 apparaît, vérifier le compte de test.
+
+- [ ] **Step 3 : Lancer, vérifier vert**
+
+Run : `make test`
+Expected : PASS (les 2 nouveaux tests verts grâce au fix de Task 2).
+
+- [ ] **Step 4 : Commit**
+
+```bash
+git add tests/Module/Commercial/Api/AbstractCommercialApiTestCase.php tests/Module/Commercial/Api/ClientSubResourceApiTest.php
+git commit -m "test(commercial) : verrouille POST adresses/RIB sur client peuple (ERP-107)"
+```
+
+---
+
+## Task 4 : Front — helper `submitRows` + test unitaire
+
+**Files:**
+- Modify: `frontend/modules/commercial/composables/useClientFormErrors.ts`
+- Create: `frontend/modules/commercial/composables/__tests__/useClientFormErrors.spec.ts`
+
+- [ ] **Step 1 : Écrire le test rouge**
+
+Créer `useClientFormErrors.spec.ts` :
+
+```ts
+import { describe, it, expect, vi } from 'vitest'
+import { useClientFormErrors } from '../useClientFormErrors'
+
+// Construit une erreur facon useApi : 422 avec violations Hydra.
+function http422(path: string, message: string) {
+    return { response: { status: 422, _data: { violations: [{ propertyPath: path, message }] } } }
+}
+
+describe('useClientFormErrors.submitRows', () => {
+    it('tente TOUS les blocs et mappe les erreurs par index, sans stopper au premier echec', async () => {
+        const { contactErrors, submitRows } = useClientFormErrors()
+        const seen: number[] = []
+        const onUnmapped = vi.fn()
+
+        const saveRow = async (_row: unknown, index: number) => {
+            seen.push(index)
+            if (index === 1) throw http422('email', 'Email invalide')
+        }
+
+        const hasError = await submitRows(
+            [{ a: 0 }, { a: 1 }, { a: 2 }],
+            contactErrors,
+            saveRow,
+            onUnmapped,
+        )
+
+        expect(seen).toEqual([0, 1, 2])            // tous les blocs tentes
+        expect(hasError).toBe(true)
+        expect(contactErrors.value[1]).toEqual({ email: 'Email invalide' })
+        expect(contactErrors.value[0]).toBeUndefined()
+        expect(onUnmapped).not.toHaveBeenCalled()  // 422 mappee, pas de fallback
+    })
+
+    it('saute les lignes filtrees par shouldSkip et renvoie false si tout passe', async () => {
+        const { contactErrors, submitRows } = useClientFormErrors()
+        const saved: number[] = []
+
+        const hasError = await submitRows(
+            [{ skip: true }, { skip: false }],
+            contactErrors,
+            async (_row, index) => { saved.push(index) },
+            vi.fn(),
+            (row: { skip: boolean }) => row.skip,
+        )
+
+        expect(saved).toEqual([1])
+        expect(hasError).toBe(false)
+    })
+})
+```
+
+- [ ] **Step 2 : Lancer, vérifier l'échec**
+
+Run : `make nuxt-test` (ou ciblé : `docker exec <node> npx vitest run useClientFormErrors`)
+Expected : FAIL — `submitRows` n'existe pas encore.
+
+- [ ] **Step 3 : Implémenter `submitRows`**
+
+Dans `useClientFormErrors.ts`, ajouter la méthode (dans la fonction, après `mapRowError`) et l'exposer dans le `return` :
+
+```ts
+    /**
+     * Soumet TOUS les blocs d'une collection (contacts/adresses/RIB) en collectant
+     * les erreurs par index : on n'arrete PAS au premier bloc en echec (ERP-101).
+     * Reinitialise le tableau d'erreurs cible, tente chaque ligne via `saveRow`,
+     * mappe les 422 inline (mapRowError) ou delegue le fallback a `onUnmappedError`.
+     * Retourne true si au moins un bloc a echoue (le caller ne valide alors pas l'onglet).
+     */
+    async function submitRows<T>(
+        rows: T[],
+        target: Ref<Record<string, string>[]>,
+        saveRow: (row: T, index: number) => Promise<void>,
+        onUnmappedError: (error: unknown, index: number) => void,
+        shouldSkip?: (row: T, index: number) => boolean,
+    ): Promise<boolean> {
+        target.value = []
+        let hasError = false
+        for (let index = 0; index < rows.length; index++) {
+            if (shouldSkip?.(rows[index], index)) {
+                continue
+            }
+            try {
+                await saveRow(rows[index], index)
+            }
+            catch (error) {
+                if (!mapRowError(error, target, index)) {
+                    onUnmappedError(error, index)
+                }
+                hasError = true
+            }
+        }
+
+        return hasError
+    }
+```
+
+Ajouter `submitRows` à l'objet retourné par `useClientFormErrors`.
+
+- [ ] **Step 4 : Lancer, vérifier vert**
+
+Run : `make nuxt-test`
+Expected : PASS (les 2 cas verts).
+
+- [ ] **Step 5 : Commit**
+
+```bash
+git add frontend/modules/commercial/composables/useClientFormErrors.ts frontend/modules/commercial/composables/__tests__/useClientFormErrors.spec.ts
+git commit -m "feat(commercial) : submitRows collecte les erreurs de tous les blocs de collection (ERP-101)"
+```
+
+---
+
+## Task 5 : Front — brancher `submitRows` dans new.vue + edit.vue
+
+**Files:**
+- Modify: `frontend/modules/commercial/pages/clients/new.vue` (`submitContacts`, `submitAddresses`, boucle RIB de `submitAccounting`)
+- Modify: `frontend/modules/commercial/pages/clients/[id]/edit.vue` (les 3 équivalents)
+
+- [ ] **Step 1 : Récupérer `submitRows` du composable**
+
+Dans `new.vue` ET `edit.vue`, ajouter `submitRows` à la déstructuration de `useClientFormErrors()` :
+
+```ts
+const {
+    mainErrors,
+    informationErrors,
+    accountingErrors,
+    contactErrors,
+    addressErrors,
+    ribErrors,
+    mapRowError,
+    submitRows,
+} = useClientFormErrors()
+```
+
+- [ ] **Step 2 : Réécrire `submitContacts` (new.vue)**
+
+Remplacer le corps de la boucle par un appel à `submitRows` :
+
+```ts
+async function submitContacts(): Promise<void> {
+    if (clientId.value === null || !canValidateContacts.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        const hasError = await submitRows(
+            contacts.value,
+            contactErrors,
+            async (contact) => {
+                const body = {
+                    firstName: contact.firstName || null,
+                    lastName: contact.lastName || null,
+                    jobTitle: contact.jobTitle || null,
+                    phonePrimary: contact.phonePrimary || null,
+                    phoneSecondary: contact.hasSecondaryPhone ? (contact.phoneSecondary || null) : null,
+                    email: contact.email || null,
+                }
+                if (contact.id === null) {
+                    const created = await api.post<ContactResponse>(
+                        `/clients/${clientId.value}/contacts`,
+                        body,
+                        { headers: { Accept: 'application/ld+json' }, toast: false },
+                    )
+                    contact.id = created.id
+                    contact.iri = created['@id'] ?? null
+                }
+                else {
+                    await api.patch(`/client_contacts/${contact.id}`, body, { toast: false })
+                }
+            },
+            (error) => toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) }),
+            (contact) => !isContactNamed(contact),
+        )
+        if (hasError) return
+        completeTab('contact')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+```
+
+- [ ] **Step 3 : Réécrire `submitAddresses` (new.vue)**
+
+```ts
+async function submitAddresses(): Promise<void> {
+    if (clientId.value === null || !canValidateAddresses.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        const hasError = await submitRows(
+            addresses.value,
+            addressErrors,
+            async (address) => {
+                const body = {
+                    isProspect: address.isProspect,
+                    isDelivery: address.isDelivery,
+                    isBilling: address.isBilling,
+                    country: address.country,
+                    postalCode: address.postalCode || null,
+                    city: address.city || null,
+                    street: address.street || null,
+                    streetComplement: address.streetComplement || null,
+                    categories: address.categoryIris,
+                    sites: address.siteIris,
+                    contacts: address.contactIris,
+                    billingEmail: isBillingEmailRequired(address) ? (address.billingEmail || null) : null,
+                }
+                if (address.id === null) {
+                    const created = await api.post<{ id: number }>(
+                        `/clients/${clientId.value}/addresses`,
+                        body,
+                        { headers: { Accept: 'application/ld+json' }, toast: false },
+                    )
+                    address.id = created.id
+                }
+                else {
+                    await api.patch(`/client_addresses/${address.id}`, body, { toast: false })
+                }
+            },
+            (error) => toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) }),
+        )
+        if (hasError) return
+        completeTab('address')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+```
+
+- [ ] **Step 4 : Réécrire la boucle RIB de `submitAccounting` (new.vue)**
+
+Garder le PATCH scalaire inchangé (1) ; remplacer la boucle (2) :
+
+```ts
+        // 2) POST/PATCH des RIB (erreurs inline par ligne, tous les blocs).
+        const ribHasError = await submitRows(
+            ribs.value,
+            ribErrors,
+            async (rib) => {
+                const body = { label: rib.label, bic: rib.bic, iban: rib.iban }
+                if (rib.id === null) {
+                    const created = await api.post<{ id: number }>(
+                        `/clients/${clientId.value}/ribs`,
+                        body,
+                        { headers: { Accept: 'application/ld+json' }, toast: false },
+                    )
+                    rib.id = created.id
+                }
+                else {
+                    await api.patch(`/client_ribs/${rib.id}`, body, { toast: false })
+                }
+            },
+            (error) => toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) }),
+            (rib) => !ribIsComplete(rib),
+        )
+        if (ribHasError) return
+
+        completeTab('accounting')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+```
+
+> Retirer le `ribErrors.value = []` désormais fait par `submitRows`. Le `accountingErrors.clearErrors()` du PATCH scalaire reste.
+
+- [ ] **Step 5 : Mirror dans edit.vue**
+
+Appliquer les mêmes réécritures aux `submitContacts` / `submitAddresses` / boucle RIB de `submitAccounting` d'`edit.vue`. Conserver le **fallback d'erreur propre à edit.vue** (si edit.vue utilise `showError(...)` au lieu de `toast.error(...)`, passer ce fallback comme `onUnmappedError`). Vérifier les noms des refs (`clientId` peut y être l'id de route).
+
+- [ ] **Step 6 : Vérifier le typecheck + tests front**
+
+Run : `make nuxt-test`
+Expected : PASS. Aucune régression des specs existantes (`ClientContactBlock.spec.ts`, etc.).
+
+- [ ] **Step 7 : Commit**
+
+```bash
+git add frontend/modules/commercial/pages/clients/new.vue "frontend/modules/commercial/pages/clients/[id]/edit.vue"
+git commit -m "feat(commercial) : valide tous les blocs contacts/adresses/RIB et affiche les erreurs par bloc (ERP-101)"
+```
+
+---
+
+## Task 6 : Vérification finale + golden path manuel
+
+- [ ] **Step 1 : Suite complète back**
+
+Run : `make test` puis `make php-cs-fixer-allow-risky`
+Expected : tout vert, 0 fichier à corriger.
+
+- [ ] **Step 2 : Suite complète front**
+
+Run : `make nuxt-test`
+Expected : tout vert.
+
+- [ ] **Step 3 : Golden path manuel (`make dev-nuxt`, port 3004)**
+
+Scénario : ouvrir un client à 3 contacts (compte `admin`), onglet Contacts, ajouter un bloc avec email invalide + un autre bloc avec prénom/nom vides → Valider.
+Attendu : **pas de 500** ; « L'adresse email n'est pas valide. » sous l'email du bon bloc ET « Le prénom ou le nom du contact est obligatoire. » sous le prénom de l'autre bloc, **affichés simultanément**. L'onglet ne se valide pas tant qu'une erreur subsiste. Idem à vérifier rapidement sur Adresses et RIB.
+
+- [ ] **Step 4 : Si une vérif échoue ou ne peut être lancée, le dire explicitement** (ne pas annoncer « fini »).
+
+---
+
+## Self-review (auteur du plan)
+
+- **Couverture spec §3.1 (back)** : Task 2 (read:false + linkParent 404) ✓ ; §3.2 (front collect-all) : Tasks 4-5 ✓ ; §3.3 (helper réutilisable) : Task 4 `submitRows` ✓ ; §4 tests : Tasks 1, 3 (back), 4 (front) + Task 6 golden path ✓.
+- **Périmètre 3 sous-ressources** : contacts (Task 1-2), adresses + RIB (Task 3 + branchements Task 5) ✓.
+- **Décision « inline seul »** : aucun toast succès si `hasError` ; pas de toast récap ✓.
+- **Pas de placeholder** : le seul point ouvert est la note Task 3 Step 1 (setters non-nullables éventuels d'adresse/RIB à compléter en lisant les entités) — à lever à l'écriture. Cohérence des noms : `submitRows` utilisé identiquement en Task 4 et Task 5.

docs/specs/M1-clients/cahier-test-back-M1.md

@@ -0,0 +1,79 @@
+# Cahier de test back — M1 Répertoire clients (ticket ERP-60 / #478)
+
+Mapping **toutes les RG (§ 7) → test(s) PHPUnit**, à jour après ERP-60.
+
+Légende source : `ERP-55` `ERP-56` `ERP-57` `ERP-58` = tests écrits par les wagons
+précédents ; **`ERP-60`** = tests ajoutés par ce ticket (stratégie « combler les
+trous, zéro duplication »).
+
+## Stratégie
+
+ERP-60 n'écrit QUE les tests des RG non déjà couvertes par la stack, et mappe ici
+l'intégralité des RG (existantes + nouvelles + déléguées). Les tests dépendants
+des **rôles métier** (matrice RBAC bureau/compta/commerciale/usine) sont
+**délégués à ERP-74 (#493)** : ces rôles n'existent qu'après le
+merge de la stack.
+
+## Mapping RG → test
+
+| RG | Intitulé | Test(s) | Source |
+|----|----------|---------|--------|
+| ~~RG-1.01~~ | _(supprimée V1 — refonte-contact)_ contact inline retiré du Client ; complétude couverte par RG-1.05 / RG-1.14 (`ClientContact`) | — | refonte-contact |
+| ~~RG-1.02~~ | _(supprimée du Client V1)_ téléphones inline retirés du Client (testés sur `ClientContact`) | — | refonte-contact |
+| RG-1.03 | distributor/broker exclusifs + type catégorie | `ClientApiTest::testPostWithDistributorAndBrokerReturns422` ; `::testPostDistributorReferencingNonDistributorReturns422` ; `::testPostValidDistributorReturns201` ; `ClientProcessorTest` (unit) | ERP-55 |
+| ~~RG-1.04~~ | _(SUPPRIMÉE)_ Onglet Information désormais facultatif pour tous les rôles (validation de complétude retirée) | — | ERP-55 / ERP-74 |
+| RG-1.05 | Contact : prénom OU nom → 422 (CHECK) | `ClientSubResourceApiTest::testPostContactWithoutNameReturns422` | ERP-57 |
+| RG-1.06/07/08 | Adresse prospect exclusive de livraison/facturation → 422 (Assert\Callback + CHECK filet) | `ClientAddressTest::testProspectAddressCannotBeDelivery` ; `::testProspectAddressCannotBeBilling` | ERP-60 / **ERP-76** |
+| RG-1.09 | Code postal `^[0-9]{4,5}$` → 422 | `ClientSubResourceApiTest::testPostAddressWithInvalidPostalCodeReturns422` | ERP-57 |
+| RG-1.10 | ≥ 1 site sur adresse → 422 | `ClientSubResourceApiTest::testPostAddressWithoutSiteReturns422` | ERP-57 |
+| RG-1.11 | billingEmail obligatoire ssi isBilling → 422 (Assert\Callback + CHECK filet) | `ClientAddressTest::testBillingAddressRequiresBillingEmail` ; `::testNonBillingAddressRejectsBillingEmail` | ERP-60 / **ERP-76** |
+| RG-1.12 | Virement → banque obligatoire → 422 | `ClientProcessorTest::testVirementWithoutBankIsUnprocessable` ; `::testVirementWithBankPasses` (unit) | ERP-55 |
+| RG-1.13 | LCR → ≥ 1 RIB ; DELETE dernier RIB en LCR → 409 | `ClientProcessorTest::testLcrWithoutRibIsUnprocessable` / `::testLcrWithRibPasses` (unit) ; `ClientSubResourceApiTest::testDeleteLastRibUnderLcrReturns409` / `::testDeleteRibNonLcrReturns204` | ERP-55 / ERP-57 |
+| RG-1.14 | ≥ 1 bloc Contact pour finaliser l'onglet | **Front-driven (pas de state machine back).** Back voisin : `ClientSubResourceApiTest::testDeleteLastContactReturns409` | ERP-57 |
+| RG-1.15 | ~~Unicité SIREN~~ supprimée (Q4) — SIREN partageable | `ClientUniquenessTest::testDuplicateSirenIsAllowed` ; `ClientMigrationTest::testNoSirenOrEmailUniqueIndex` | **ERP-60** |
+| RG-1.16 | companyName unique (case-insensitive) parmi actifs → 409 | `ClientApiTest::testPostDuplicateCompanyNameReturns409` ; `ClientMigrationTest::testCompanyNameActivePartialIndexExistsExactlyOnce` | ERP-55 / **ERP-60** |
+| RG-1.17 | ~~Unicité email~~ supprimée (Q4) — email partageable | `ClientUniquenessTest::testDuplicateEmailIsAllowed` ; `ClientMigrationTest::testNoSirenOrEmailUniqueIndex` | **ERP-60** |
+| RG-1.18 | companyName upper-cased serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testCompanyNameIsUppercased` (unit) | ERP-55 |
+| RG-1.19 | firstName/lastName capitalize serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testPersonNameIsTitleCased` (unit) ; `ClientSubResourceApiTest::testPostContactNormalizesFields` | ERP-55 / ERP-57 |
+| RG-1.20 | Téléphones chiffres-seuls serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testPhoneKeepsOnlyDigits` (unit) ; `ClientFormulaireMainTest::testPostPersistsSecondaryPhoneNormalized` (secondary) | ERP-55 / **ERP-60** |
+| RG-1.21 | email lowercase serveur | `ClientApiTest::testPostNormalizesTextFields` ; `ClientFieldNormalizerTest::testEmailIsLowercased` (unit) ; `ClientSubResourceApiTest::testPostContactNormalizesFields` / `::testPostAddressNormalizesBillingEmail` | ERP-55 / ERP-57 |
+| RG-1.22 | Archive : permission `archive` + archivedAt + aucun autre champ | `ClientApiTest::testPatchArchiveSetsArchivedAtThenRestore` ; `::testPatchArchiveWithOtherFieldReturns422` ; `ClientProcessorTest` (unit, gating archive) | ERP-55 |
+| RG-1.23 | Restauration : archivedAt=null ; **409 si conflit d'unicité** | `ClientApiTest::testPatchArchiveSetsArchivedAtThenRestore` (cas nominal) ; **`ClientArchiveTest::testRestoreConflictReturns409`** (409 restauration, gap P1) | ERP-55 / **ERP-60** |
+| RG-1.24 | Liste exclut les archivés par défaut | `ClientApiTest::testListSortedByCompanyNameAscAndExcludesArchived` | ERP-55 |
+| RG-1.25 | `?includeArchived=true` inclut les archivés | `ClientApiTest::testListIncludeArchivedReturnsArchived` | ERP-55 |
+| RG-1.26 | Tri par défaut companyName ASC | `ClientApiTest::testListSortedByCompanyNameAscAndExcludesArchived` | ERP-55 |
+| RG-1.27 | Timestampable/Blamable : created* figés, updated* mis à jour | `ClientAuditTest::testCreatedFrozenAndUpdatedByReflectsModifier` | **ERP-60** |
+| RG-1.28 | PATCH multi-groupes sans permission → 403 strict (tout le payload) | `ClientProcessorTest::testStrictMixWithAccountingFieldIsForbidden` / `::testAccountingFieldWithoutPermissionIsForbidden` (unit) ; **`ClientPatchStrictTest::testMixedGroupsPatchWithoutAccountingPermissionIsForbidden`** (fonctionnel) | ERP-55 / **ERP-60** |
+| RG-1.29 | Catégorie d'adresse limitée aux types SECTEUR/AUTRE | **Filtrage LECTURE = front-driven** (SearchFilter `GET /api/categories?categoryType.code[]=…`). **Validation ÉCRITURE** : `ClientAddress::validateCategoryTypes` (Assert\Callback) rejette une catégorie DISTRIBUTEUR/COURTIER en 422 (violation `categories`). Tests : `ClientAddressTest::testAddressRejectsDistributorCategory` / `::testAddressRejectsBrokerCategory` / `::testAddressAcceptsSectorCategory` / `::testAddressAcceptsOtherCategory` | **ERP-76** |
+
+## Couvertures transverses
+
+| Sujet | Test(s) | Source |
+|-------|---------|--------|
+| Audit iban/bic présents dans le diff (pas d'`#[AuditIgnore]`) | `ClientAuditTest::testRibCreateAuditIncludesIbanAndBic` | **ERP-60** |
+| Sécurité générique : 401 anonyme + 403 sans `commercial.clients.view` | `ClientSecurityTest` (collection + détail) ; `ClientExportControllerTest::testForbiddenWithoutClientsViewPermission` / `::testUnauthorizedWhenAnonymous` | **ERP-60** / ERP-58 |
+| Migration : index partiel unique présent (1 seul), pas de siren/email unique | `ClientMigrationTest` | **ERP-60** |
+| Référentiels comptables read-only (405 écriture, 401/403) | `ReferentialApiTest` | ERP-56 |
+| Export XLSX (colonnes accounting selon permission, 401/403) | `ClientExportControllerTest` | ERP-58 |
+
+## Délégué à ERP-74 (#493) — NE PAS faire dans ERP-60
+
+- **Matrice RBAC différenciée** par rôle métier (Bureau / Compta / Commerciale /
+  Usine) : 200/403 par verbe et par onglet selon le rôle.
+- ~~**RG-1.04 fonctionnel**~~ : _(SUPPRIMÉE)_ l'onglet Information est désormais facultatif pour tous les rôles.
+- Raison : ces rôles métier ne sont seedés qu'après le merge de la stack M1.
+
+## Gaps & suivi
+
+- ~~**RG-1.29 (validation écriture)**~~ — **résolu en ERP-76**. La validation
+  d'écriture refuse désormais une catégorie de type `DISTRIBUTEUR`/`COURTIER` sur
+  une `ClientAddress` (→ 422, violation `categories`) via l'Assert\Callback
+  `ClientAddress::validateCategoryTypes`. Le filtrage de lecture reste
+  front-driven (SearchFilter). Couvert par `ClientAddressTest`.
+- ~~**Violations CHECK → statut HTTP**~~ — **résolu en ERP-76**. Les règles
+  d'adresse RG-1.06/07/08/11 sont désormais rejetées en **422** par des
+  Assert\Callback applicatifs (`validateProspectExclusivity` /
+  `validateBillingEmailPresence`) qui s'exécutent AVANT la base. Les CHECK
+  Postgres (`chk_client_address_prospect_exclusive` /
+  `chk_client_address_billing_email`) restent en filet de sécurité. Les tests
+  `ClientAddressTest` assertent maintenant le 422 explicite (et non plus ≥ 400).

docs/specs/M1-clients/refonte-contact/M1-ticket-01-back.md

@@ -0,0 +1,135 @@
+# M1 · Ticket 1/3 (Backend) — Supprimer le contact inline du `Client`
+
+## 1. Objectif
+
+Retirer de l'entité `Client` (et de la table `client`) les **5 champs du contact
+principal inline** : `firstName`, `lastName`, `phonePrimary`, `phoneSecondary`, `email`.
+La gestion des contacts passe désormais **exclusivement** par la sous-entité
+`ClientContact` (onglet « Contacts »), déjà en place et déjà porteuse des mêmes champs.
+
+Le code M1 est **déjà livré en prod** : ce ticket inclut donc une **migration de données**
+(backfill) pour ne perdre aucune information de contact existante avant de supprimer les
+colonnes.
+
+Contexte et justification : voir `README.md` du dossier `refonte-contact`.
+
+## 2. Périmètre
+
+### IN
+
+- Migration Doctrine : **backfill puis suppression** des 5 colonnes de `client`.
+- `Client` (entité) : supprimer les 5 propriétés, getters/setters, annotations ORM /
+  `Assert` / `Groups`.
+- `ClientProcessor` : retirer les 5 champs de `MAIN_FIELDS`, `changedBusinessFields()`,
+  `normalize()` ; supprimer `validateMainContact()` (RG-1.01 — n'a plus d'objet).
+- `DoctrineClientRepository::applySearch()` : trancher D1 (recherche) et l'appliquer.
+- `ClientExportController` : trancher D2 (colonnes export) et l'appliquer.
+- `ClientFixtures` : retirer les 5 paramètres inline de `ensureClient()` ; garantir que
+  chaque client seedé possède au moins 1 `ClientContact` (déjà géré par `addContact()`).
+- Tests PHPUnit : mettre à jour / retirer les cas qui exercent ces 5 champs sur `Client`.
+
+### OUT
+
+- Toute modification de `ClientContact` / `ClientContactProcessor` : **inchangés** (c'est la
+  cible, les champs y restent). `ClientFieldNormalizer` reste tel quel (toujours appelé par
+  `ClientContactProcessor`).
+- Le front (formulaires, vues, types, i18n) → **ticket 2/3**.
+- Les specs (`spec-back.md`, `spec-front.md`, cahier de test) → **ticket 3/3**.
+
+## 3. Fichiers à modifier
+
+| Fichier | Action |
+|---|---|
+| `src/Module/Commercial/Domain/Entity/Client.php` | Supprimer props `firstName` (~l.158), `lastName` (~l.163), `phonePrimary` (~l.168), `phoneSecondary` (~l.172), `email` (~l.178) + leurs getters/setters (~l.329-382) + groupes `client:read`/`client:write:main` + `Assert\*`. |
+| `src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/ClientProcessor.php` | Retirer les 5 clés de `MAIN_FIELDS` (~l.63) ; de `changedBusinessFields()` (~l.277-281) ; les 6 lignes de `normalize()` qui touchent email/phone/first/last/secondary (~l.433-441) ; supprimer `validateMainContact()` (~l.447-456) et son appel. |
+| `src/Module/Commercial/Infrastructure/Doctrine/DoctrineClientRepository.php` | `applySearch()` (~l.110-124) : appliquer **D1**. |
+| `src/Module/Commercial/Infrastructure/Controller/ClientExportController.php` | `buildHeaders()` (~l.94-114) + `buildRows()` (~l.121-143) : appliquer **D2**. |
+| `src/Module/Commercial/Infrastructure/DataFixtures/ClientFixtures.php` | `ensureClient()` (~l.357-395) : retirer firstName/lastName/phonePrimary/phoneSecondary/email ; conserver `addContact()`. |
+| `migrations/Version<timestamp>.php` (NOUVELLE) | Backfill + `DROP COLUMN` (cf. § 4). |
+| `tests/Module/Commercial/**` | Voir § 5. |
+
+## 4. Migration Doctrine — backfill puis suppression
+
+> Migration **modulaire** (`src/Module/Commercial/Infrastructure/Doctrine/Migrations/`) : ce
+> n'est PAS une migration d'initialisation, le schéma `client` / `client_contact` existe
+> déjà (règle ABSOLUE n°11).
+
+### `up()`
+
+1. **Backfill — ne créer un contact que pour les clients qui n'en ont aucun**, afin de ne
+   pas dupliquer le contact déjà recopié à la création (`prefillFirstContact`) :
+
+   ```sql
+   INSERT INTO client_contact
+       (client_id, first_name, last_name, phone_primary, phone_secondary, email, position, created_at, updated_at)
+   SELECT c.id, c.first_name, c.last_name, c.phone_primary, c.phone_secondary, c.email, 0, NOW(), NOW()
+   FROM client c
+   WHERE NOT EXISTS (SELECT 1 FROM client_contact cc WHERE cc.client_id = c.id)
+     AND (c.first_name IS NOT NULL OR c.last_name IS NOT NULL);
+   ```
+
+   > Le `WHERE ... first_name OU last_name IS NOT NULL` respecte le CHECK
+   > `chk_client_contact_name`. Les rares clients sans nom de contact ET sans contact
+   > existant ne reçoivent pas de ligne (cas théorique : `phone_primary`/`email` étaient
+   > `NOT NULL` mais les noms nullables).
+
+2. **Supprimer les 5 colonnes** :
+
+   ```sql
+   ALTER TABLE client
+       DROP COLUMN first_name,
+       DROP COLUMN last_name,
+       DROP COLUMN phone_primary,
+       DROP COLUMN phone_secondary,
+       DROP COLUMN email;
+   ```
+
+   > Pas de `COMMENT ON COLUMN` à poser (on supprime). Vérifier qu'aucun index ne portait
+   > sur `email` (l'index unique `uq_client_email_active` a déjà été supprimé — décision Q4 /
+   > RG-1.17, cf. `ClientMigrationTest`).
+
+### `down()` (best-effort)
+
+1. Recréer les 5 colonnes (`phone_primary`/`email` en `NOT NULL` impose un défaut transitoire
+   ou un re-remplissage depuis le contact `position = 0`).
+2. Re-remplir depuis `client_contact` (`position = 0`) si possible.
+3. Reposer les `COMMENT ON COLUMN` d'origine (textes RG-1.19/1.20/1.21/1.01/1.17 — cf.
+   `migrations/Version20260601000000.php` l.251-255).
+
+> `down()` ne peut pas restaurer parfaitement les données (ambiguïté si plusieurs contacts).
+> Documenter cette limite dans le docblock de la migration.
+
+## 5. Tests à mettre à jour
+
+| Fichier | Action |
+|---|---|
+| `tests/Module/Commercial/Api/ClientApiTest.php` | Retirer firstName/lastName/phone/email des payloads POST/PATCH `client` et des assertions JSON. |
+| `tests/.../ClientFormulaireMainTest.php` | Supprimer les tests RG-1.01 (firstName/lastName) et RG-1.02 (téléphones) **côté Client** — ils basculent côté `ClientContact` (couverts ailleurs). |
+| `tests/.../ClientExportControllerTest.php` | Aligner les en-têtes/lignes attendus sur **D2**. |
+| `tests/.../ClientMigrationTest.php` | Asserter que les 5 colonnes **n'existent plus** sur `client` ; vérifier le backfill (un client sans contact obtient bien 1 `client_contact`). |
+| `tests/.../ClientFieldNormalizerTest.php` | Conserver les tests du normalizer (toujours utilisé par `ClientContact`) ; retirer les cas spécifiques aux champs `Client` s'il y en a. |
+| RG-1.01/1.02 (matrice) | Ne plus tester sur `Client` ; vérifier qu'ils restent couverts sur `ClientContact` (RG-1.05). |
+
+## 6. Décisions à trancher (cf. README § 3)
+
+- **D1 — recherche** : recommandé = `LEFT JOIN client_contact` (fuzzy sur
+  `companyName` + contact `first_name`/`last_name`/`email`). Attention au `DISTINCT` /
+  risque de doublons de lignes si plusieurs contacts matchent (grouper par `client.id`).
+- **D2 — export** : recommandé = alimenter les colonnes contact depuis le contact de plus
+  petit `position` (fetch-join `contacts` pour éviter le N+1).
+
+## 7. Critères d'acceptation (DoD)
+
+- [ ] Les colonnes `first_name`, `last_name`, `phone_primary`, `phone_secondary`, `email`
+      n'existent plus sur la table `client`.
+- [ ] La migration est jouable sur une base seedée sans perte de contact (backfill vérifié)
+      et `down()` documenté comme best-effort.
+- [ ] `Client`, `ClientProcessor`, `DoctrineClientRepository`, `ClientExportController`,
+      `ClientFixtures` ne référencent plus les 5 champs.
+- [ ] D1 et D2 implémentées conformément à la décision validée.
+- [ ] `ClientContact` / `ClientContactProcessor` / `ClientFieldNormalizer` inchangés.
+- [ ] `make test` vert (notamment `tests/Architecture/ColumnsHaveSqlCommentTest` et
+      `EntitiesAreTimestampableBlamableTest`).
+- [ ] `make php-cs-fixer-allow-risky` ne signale rien sur les fichiers touchés.
+- [ ] Aucune régression du contrat de sérialisation : capturer le JSON réel de
+      `GET /api/clients/{id}` et vérifier l'absence des 5 champs (réflexe RETEX M1).

docs/specs/M1-clients/refonte-contact/M1-ticket-01-back.prompt.md

@@ -0,0 +1,58 @@
+# Prompt d'implémentation — M1 · Ticket 1/3 (Backend)
+
+Tu travailles sur le projet **Starseed** (Symfony 8 / API Platform 4 / Doctrine / PostgreSQL).
+Lis `CLAUDE.md` et `.claude/rules/backend.md` avant de coder. Commentaires en français,
+code en anglais, `declare(strict_types=1);` partout.
+
+## Mission
+
+Supprimer le **contact principal inline** de l'entité `Client` : les 5 champs
+`firstName`, `lastName`, `phonePrimary`, `phoneSecondary`, `email`. Les contacts sont gérés
+uniquement via la sous-entité `ClientContact` (onglet Contacts), déjà en place. Le code est
+déjà en prod → migration avec **backfill** avant `DROP`.
+
+La spec détaillée du ticket est dans `docs/specs/M1-clients/refonte-contact/M1-ticket-01-back.md`.
+Lis-la en entier, ainsi que le `README.md` du même dossier (décision + RG impactées + D1/D2).
+
+## Étapes
+
+1. **Explorer** : `Client.php`, `ClientProcessor.php`, `DoctrineClientRepository.php`,
+   `ClientExportController.php`, `ClientFixtures.php`, et `ClientContact.php` (pour confirmer
+   que la cible porte bien les mêmes champs).
+2. **Demander la validation des décisions D1 (recherche) et D2 (export)** avant de coder —
+   défauts recommandés : D1 = LEFT JOIN sur `client_contact`, D2 = colonnes export depuis le
+   contact `position` minimal. Ne pas inventer un autre comportement.
+3. **Migration** (`src/Module/Commercial/Infrastructure/Doctrine/Migrations/`) : backfill
+   `INSERT INTO client_contact ... WHERE NOT EXISTS(...)` puis `ALTER TABLE client DROP COLUMN ...`
+   (les 5). `down()` best-effort documenté. Voir le SQL exact dans la spec § 4.
+4. **Entité** : retirer les 5 props + getters/setters + `#[ORM\Column]` + `#[Assert\*]` +
+   `#[Groups(['client:read','client:write:main'])]`.
+5. **Processor** : retirer de `MAIN_FIELDS`, `changedBusinessFields()`, `normalize()` ;
+   supprimer `validateMainContact()` et son appel.
+6. **Repository** : `applySearch()` selon D1.
+7. **Export** : `buildHeaders()` / `buildRows()` selon D2.
+8. **Fixtures** : alléger `ensureClient()` ; garder `addContact()`.
+9. **Tests** : mettre à jour `ClientApiTest`, `ClientFormulaireMainTest`,
+   `ClientExportControllerTest`, `ClientMigrationTest`, `ClientFieldNormalizerTest`
+   (cf. spec § 5). Ajouter une assertion que le backfill crée bien un contact pour un client
+   qui n'en avait pas.
+
+## Garde-fous
+
+- Ne touche **pas** `ClientContact`, `ClientContactProcessor`, `ClientFieldNormalizer`.
+- Respecte les règles ABSOLUES : pagination, `#[Auditable]`, COMMENT ON COLUMN (ici on
+  supprime → pas de commentaire à poser, mais ne pas casser le garde-fou).
+- Les RG-1.01 et RG-1.02 disparaissent **du Client** : leur équivalent (RG-1.05 / RG-1.14)
+  vit déjà sur `ClientContact`, ne le duplique pas.
+
+## Vérification finale (obligatoire avant de dire « fini »)
+
+```bash
+make db-reset && make migration-migrate     # migration rejouable sur base fraîche
+make test                                    # PHPUnit vert
+make php-cs-fixer-allow-risky                # lint
+```
+
+Puis capture le JSON réel de `GET /api/clients/{id}` (avec un JWT) et confirme que les 5
+champs ont disparu de la réponse et que `contacts[]` porte bien l'info (réflexe RETEX M1 :
+on valide sur le contrat réel, pas sur les annotations).

docs/specs/M1-clients/refonte-contact/M1-ticket-02-front.md

@@ -0,0 +1,74 @@
+# M1 · Ticket 2/3 (Frontend) — Retirer le bloc contact principal des écrans Client
+
+## 1. Objectif
+
+Retirer le **bloc « contact principal »** (Nom, Prénom, Téléphone, Téléphone 2, Email) des
+trois écrans Client — **création**, **consultation**, **modification** — ainsi que des
+types, mappeurs, validations et clés i18n associés. La saisie des contacts se fait
+désormais uniquement dans l'**onglet « Contacts »** (composant `ClientContactBlock`, déjà
+en place et inchangé).
+
+Dépend du **ticket 1/3 (back)** : l'API ne renvoie/n'accepte plus ces 5 champs sur `client`.
+Contexte : voir `README.md` du dossier `refonte-contact`.
+
+## 2. Périmètre
+
+### IN — fichiers `frontend/modules/commercial/`
+
+| Fichier | Action |
+|---|---|
+| `pages/clients/new.vue` | Supprimer le bloc principal Nom/Prénom/Téléphones/Email (~l.27-63), l'état `main.firstName/lastName/email`, `mainPhones` (~l.445-459), la fonction `prefillFirstContact()` (~l.658-665) et son appel, le mapping payload POST `phonePrimary/phoneSecondary` (~l.513-524). Adapter `isMainValid` (~l.479-493) : la validation principale ne porte plus que sur `companyName` (+ relation/catégories selon RG existantes). L'onglet **Contacts** devient le point de saisie des coordonnées ; garantir au moins un `ClientContactBlock` vide au départ. |
+| `pages/clients/[id]/edit.vue` | Supprimer les 5 champs du bloc principal (~l.32-73). `mapMainDraft()` et `buildMainPayload()` ne portent plus ces champs. L'onglet Contacts reste éditable. |
+| `pages/clients/[id]/index.vue` | Supprimer l'affichage lecture seule des 5 champs du bloc principal (~l.49-104, partie contact). Conserver l'onglet Contacts (lecture seule). |
+| `types/clientForm.ts` | `MainFormDraft` : retirer `firstName`, `lastName`, `email`, `phonePrimary`, `phoneSecondary`, `hasSecondaryPhone`. Garder `ContactFormDraft` (inchangé). |
+| `types/clientConsultation.ts` | `ClientDetail` : retirer `firstName/lastName/phonePrimary/phoneSecondary/email` (les commentaires « Contact principal »). Garder `ContactRead`. |
+| `utils/clientEdit.ts` | `mapMainDraft()` et `buildMainPayload()` : retirer les 5 champs. Garder `buildContactPayload()`. |
+| `utils/clientConsultation.ts` | Retirer toute lecture des 5 champs inline du client (garder `mapContactToDraft`, `contactOptionsOf`). |
+| `i18n/locales/fr.json` | Retirer `commercial.clients.form.main.firstName/lastName/email/phonePrimary/phoneSecondary/addPhone`. **Conserver** tout le bloc `commercial.clients.form.contact.*`. Vérifier qu'aucune autre vue ne référence les clés retirées. |
+| `**/__tests__/*.spec.ts` | Mettre à jour `clientFormRules.spec.ts`, `clientEdit.spec.ts`, `clientConsultation.spec.ts` (cf. § 4). |
+
+### OUT
+
+- `ClientContactBlock.vue`, l'onglet Contacts, `useClient`, la liste/répertoire
+  (`pages/clients/index.vue` — ses colonnes n'affichent déjà pas le contact inline) :
+  **inchangés**.
+- Le back → ticket 1/3. Les specs → ticket 3/3.
+
+## 3. Comportement attendu après modification
+
+- **Création** : le formulaire principal demande l'entreprise (et relation/catégories selon
+  l'existant), plus de Nom/Prénom/Téléphone/Email inline. L'utilisateur renseigne les
+  coordonnées dans l'onglet **Contacts**. La création reste valide tant qu'il y a
+  `companyName` **et** ≥ 1 bloc Contact valide (Nom OU Prénom) — RG-1.05/RG-1.14 inchangées.
+- **Consultation** : plus de bloc contact principal ; l'onglet Contacts affiche les
+  contacts.
+- **Modification** : idem ; le PATCH du groupe `client:write:main` n'envoie plus les 5
+  champs.
+
+## 4. Tests Vitest à mettre à jour
+
+- `clientFormRules.spec.ts` : la validité du « principal » ne dépend plus de
+  firstName/email/phone ; conserver `isContactNamed()` (RG-1.05) sur les blocs Contacts.
+- `clientEdit.spec.ts` : `buildMainPayload()` ne contient plus les 5 champs ; `mapMainDraft()`
+  non plus.
+- `clientConsultation.spec.ts` : retirer les assertions sur les 5 champs inline.
+
+## 5. Tips & rappels projet
+
+- `useApi()` obligatoire (jamais `$fetch`/`ofetch`). Composants `Malio*` obligatoires.
+- État de tableau jamais dans l'URL (règle inchangée).
+- Les valeurs sont **normalisées côté serveur** (Capitalize / chiffres / lowercase) : le
+  front envoie la saisie et réaffiche la valeur renvoyée — ne pas réintroduire de
+  normalisation front.
+- Ne pas créer de clé i18n orpheline ni laisser de clé `form.main.*` morte.
+
+## 6. Critères d'acceptation (DoD)
+
+- [ ] Les 3 écrans n'affichent plus Nom/Prénom/Téléphone/Téléphone 2/Email en bloc principal.
+- [ ] Le parcours de création fonctionne avec `companyName` + onglet Contacts (≥ 1 contact).
+- [ ] `MainFormDraft` / `ClientDetail` ne déclarent plus les 5 champs ; `mapMainDraft` /
+      `buildMainPayload` non plus.
+- [ ] Aucune clé i18n `form.main.firstName/lastName/email/phone*` restante ni référencée.
+- [ ] `make nuxt-test` vert.
+- [ ] Vérification visuelle du golden path (`make dev-nuxt`, port 3004) : création →
+      consultation → modification d'un client sans bloc contact inline.

docs/specs/M1-clients/refonte-contact/M1-ticket-02-front.prompt.md

@@ -0,0 +1,47 @@
+# Prompt d'implémentation — M1 · Ticket 2/3 (Frontend)
+
+Projet **Starseed** (Nuxt 4 / Vue 3 Composition API / TypeScript / @malio/layer-ui).
+Lis `CLAUDE.md` et `.claude/rules/frontend.md` avant de coder. Commentaires en français,
+code en anglais, 4 espaces d'indentation.
+
+## Mission
+
+Retirer le **bloc « contact principal »** (Nom, Prénom, Téléphone, Téléphone 2, Email) des
+écrans Client (création / consultation / modification) et de tout le code associé (types,
+mappeurs, validations, i18n). Les contacts restent gérés par l'onglet **Contacts**
+(`ClientContactBlock`, inchangé).
+
+Spec détaillée : `docs/specs/M1-clients/refonte-contact/M1-ticket-02-front.md` (lis-la en
+entier + le `README.md` du dossier). Ce ticket dépend du ticket back (l'API ne porte plus
+les 5 champs sur `client`).
+
+## Étapes
+
+1. Explorer `frontend/modules/commercial/` : `pages/clients/new.vue`, `[id]/edit.vue`,
+   `[id]/index.vue`, `types/clientForm.ts`, `types/clientConsultation.ts`,
+   `utils/clientEdit.ts`, `utils/clientConsultation.ts`, `i18n/locales/fr.json`.
+2. Supprimer le bloc principal des 3 écrans + l'état réactif `main.firstName/lastName/email`,
+   `mainPhones`, `prefillFirstContact()`.
+3. Adapter `isMainValid` : ne dépend plus que de `companyName` (+ relation/catégories selon
+   l'existant). La garantie « ≥ 1 contact valide » reste portée par l'onglet Contacts.
+4. Nettoyer les types (`MainFormDraft`, `ClientDetail`) et les mappeurs (`mapMainDraft`,
+   `buildMainPayload`, `clientConsultation`).
+5. Retirer les clés i18n `form.main.firstName/lastName/email/phonePrimary/phoneSecondary/addPhone` ;
+   vérifier par recherche qu'aucune vue ne les utilise plus. **Garder** `form.contact.*`.
+6. Mettre à jour les specs Vitest (`clientFormRules`, `clientEdit`, `clientConsultation`).
+
+## Garde-fous
+
+- `useApi()` uniquement ; composants `Malio*` uniquement ; pas d'état tableau dans l'URL.
+- Ne touche pas `ClientContactBlock.vue`, l'onglet Contacts, ni la liste/répertoire.
+- Pas de normalisation front (le serveur normalise).
+
+## Vérification finale
+
+```bash
+make nuxt-test            # Vitest vert
+make dev-nuxt             # port 3004 — golden path manuel
+```
+
+Golden path à vérifier dans le navigateur : créer un client (entreprise + 1 contact dans
+l'onglet Contacts), le consulter, le modifier — sans aucun bloc contact inline.

docs/specs/M1-clients/refonte-contact/M1-ticket-03-specs.md

@@ -0,0 +1,51 @@
+# M1 · Ticket 3/3 (Specs) — Acter la suppression du contact inline dans les specs M1
+
+## 1. Objectif
+
+Mettre à jour la **documentation fonctionnelle/technique M1** pour refléter la décision :
+le contact principal inline est supprimé du `Client`, les contacts vivent uniquement dans
+`ClientContact`. Les specs sont la **source de vérité** du projet (cf. `workflow.md`) : elles
+doivent décrire le modèle cible, pas l'ancien.
+
+> Idéalement réalisé **avant** les tickets 1 et 2 (la spec guide le code), mais peut être
+> fait en parallèle. À minima, ne pas merger le code sans aligner la spec.
+
+## 2. Fichiers à modifier
+
+| Fichier | Sections concernées |
+|---|---|
+| `docs/specs/M1-clients/spec-back.md` | § 3.1 diagramme E-R (retirer les 5 colonnes du bloc `client`) ; § 3.2 migration SQL `CREATE TABLE client` (retirer `first_name`/`last_name`/`phone_primary`/`phone_secondary`/`email` + leurs COMMENT) ; § 3.4 squelette entité `Client` (retirer les 5 props) ; § 4.3 exemple payload `POST /api/clients` (retirer les 5 champs) ; § 4.1 filtre `?search=` (refléter D1) ; § 4.6 export (refléter D2) ; § 7 RG (voir § 3 ci-dessous) ; § 8 cahier de tests (déplacer RG-1.01/1.02 vers ClientContact). |
+| `docs/specs/M1-clients/spec-front.md` | « Formulaire principal » (l.85-103) : retirer les lignes Nom/Prénom/Téléphone/Téléphone 2/Email ; écrans Consultation / Modification ; règles de formatage. Préciser que les coordonnées se saisissent dans l'onglet Contact. |
+| `docs/specs/M1-clients/cahier-test-back-M1.md` | Retirer / requalifier les lignes RG-1.01 et RG-1.02 (désormais couvertes par RG-1.05 sur `ClientContact`). |
+
+## 3. Traitement des règles de gestion
+
+- **RG-1.01** (firstName OU lastName obligatoire sur Client) → marquer **supprimée** :
+  « Remplacée par RG-1.05 (≥ 1 contact valide) + RG-1.14 (≥ 1 bloc Contact). Le contact
+  principal inline n'existe plus. »
+- **RG-1.02** (max 2 téléphones sur Client) → marquer **supprimée du Client** (reste
+  applicable aux blocs `ClientContact`).
+- **RG-1.19 / RG-1.20 / RG-1.21** (normalisation) → préciser que le **scope `Client`
+  disparaît** ; la normalisation reste sur `ClientContact` (et `ClientAddress.billingEmail`
+  pour RG-1.21).
+- Ne **pas renuméroter** les RG existantes (éviter le drift avec le code/tests) : marquer
+  « supprimée / requalifiée » en place, avec date et renvoi à la décision.
+
+## 4. Forme
+
+- Bumper la version des deux specs (`version: V0` → `V1`) dans le frontmatter, avec une
+  entrée d'historique : date `2026-06-03`, motif « Suppression du contact inline du Client
+  (refonte-contact) », auteur.
+- Ajouter un encadré « Décision » en tête de la section modèle de données, renvoyant au
+  `README.md` du dossier `refonte-contact`.
+- Conserver le style des specs (sections numérotées, tableaux RG, exemples JSON).
+
+## 5. Critères d'acceptation (DoD)
+
+- [ ] `spec-back.md` : aucune mention des 5 colonnes inline dans le modèle `client`
+      (E-R + SQL + entité + payload) ; RG-1.01/1.02 marquées supprimées ; D1/D2 décrites.
+- [ ] `spec-front.md` : le formulaire principal ne liste plus les champs de contact ;
+      l'onglet Contact est présenté comme seul lieu de saisie des coordonnées.
+- [ ] `cahier-test-back-M1.md` : RG-1.01/1.02 retirées/requalifiées.
+- [ ] Versions bumpées (V1) + historique daté dans les deux specs.
+- [ ] Cohérence vérifiée avec les tickets 1 et 2 (mêmes décisions D1/D2).

docs/specs/M1-clients/refonte-contact/M1-ticket-03-specs.prompt.md

@@ -0,0 +1,38 @@
+# Prompt d'implémentation — M1 · Ticket 3/3 (Specs)
+
+Projet **Starseed**. Tâche **documentaire** : mettre à jour les specs M1 Clients pour acter
+la suppression du contact principal inline du `Client`. Les specs sont la source de vérité ;
+elles doivent décrire le modèle cible.
+
+## Mission
+
+Modifier `docs/specs/M1-clients/spec-back.md`, `spec-front.md` et `cahier-test-back-M1.md`
+pour retirer le contact inline du `Client` (5 champs `firstName/lastName/phonePrimary/
+phoneSecondary/email`) — les contacts vivent uniquement dans `ClientContact`.
+
+Spec du ticket : `docs/specs/M1-clients/refonte-contact/M1-ticket-03-specs.md` (lis-la + le
+`README.md` du dossier, qui contient la décision, les RG impactées et les décisions D1/D2).
+
+## Étapes
+
+1. Lire les 3 fichiers de specs M1 visés, repérer toutes les occurrences des 5 champs
+   (diagramme E-R, CREATE TABLE client, squelette entité, payload POST, filtre search,
+   export, RG, cahier de test).
+2. Retirer les 5 colonnes du modèle `client` (E-R + SQL + entité + exemple JSON).
+3. Marquer **supprimées** RG-1.01 et RG-1.02 (renvoi à RG-1.05/RG-1.14 sur `ClientContact`),
+   restreindre le scope de RG-1.19/1.20/1.21 à `ClientContact`. **Ne pas renuméroter** les RG.
+4. Refléter les décisions D1 (recherche) et D2 (export) une fois tranchées.
+5. Côté `spec-front.md` : retirer les champs de contact du formulaire principal ; présenter
+   l'onglet Contact comme seul lieu de saisie.
+6. Bumper `version: V0 → V1` + ajouter une entrée d'historique datée (2026-06-03).
+
+## Garde-fous
+
+- Ne touche pas au code, uniquement aux `.md` de specs.
+- Garde le style existant (sections numérotées, tableaux RG, exemples JSON).
+- Cohérence stricte avec les tickets 1 (back) et 2 (front) : mêmes décisions D1/D2.
+
+## Vérification
+
+Relire les 3 fichiers : plus aucune mention des 5 champs inline dans le modèle `client` ;
+RG-1.01/1.02 marquées supprimées ; versions à V1 avec historique.

docs/specs/M1-clients/refonte-contact/M2-amendement-tickets.md

@@ -0,0 +1,57 @@
+# Amendement des tickets M2 existants — suppression du contact inline du `Supplier`
+
+Les 14 tickets M2 (n° 84–97, groupe Lesstime « M2 — Répertoire fournisseurs ») ont été
+rédigés sur le modèle initial **avec** contact inline. La décision `refonte-contact` les
+amende : `Supplier` ne porte **plus** les 5 champs `firstName/lastName/phonePrimary/
+phoneSecondary/email` ; les contacts vivent uniquement dans `SupplierContact` (onglet
+Contacts). Comme M2 n'est pas codé, il suffit de **ne jamais créer** ces colonnes/champs.
+
+## Bandeau injecté en tête des tickets impactés
+
+> ⚠️ **AMENDEMENT 2026-06-03 — refonte-contact.** Le contact principal inline est
+> **supprimé** du `Supplier` : ne pas créer/saisir les colonnes ni les champs `firstName`,
+> `lastName`, `phonePrimary`, `phoneSecondary`, `email` sur l'entité/le formulaire
+> `Supplier`. Les contacts sont gérés **uniquement** via `SupplierContact` (onglet
+> Contacts). RG-2.01 et RG-2.02 sont supprimées (équivalent assuré par RG-2.04 / RG-2.13).
+> RG-2.12 ne s'applique qu'à `companyName` + `SupplierContact`. Décisions transverses
+> recherche (D1) et export (D2) : cf. `docs/specs/M1-clients/refonte-contact/README.md`.
+
+## Tickets à amender
+
+### Back
+
+| Ticket | n° | Impact |
+|---|---|---|
+| migration BDD M2 (supplier + sous-collections) | #85 | Retirer `first_name/last_name/phone_primary/phone_secondary/email` du `CREATE TABLE supplier` et leurs `COMMENT ON COLUMN`. `supplier_contact` inchangé. |
+| entités + repositories M2 | #86 | `Supplier` : retirer les 5 props + `Assert\Callback` RG-2.01. `SupplierContact` inchangé. |
+| SupplierProvider + SupplierProcessor | #87 | Retirer la validation RG-2.01, la normalisation des champs inline, leur présence dans `MAIN_FIELDS` / changedFields. Recherche selon D1. |
+| export XLSX fournisseurs | #91 | Colonnes contact selon D2 (depuis le contact principal, ou supprimées). |
+| tests PHPUnit M2 | #92 | RG-2.01/2.02 testées sur `SupplierContact` (pas `Supplier`) ; contrat de sérialisation sans les 5 champs inline sur le supplier. |
+
+### Front
+
+| Ticket | n° | Impact |
+|---|---|---|
+| page Ajouter un fournisseur (`/suppliers/new`) + `useSupplierForm` | #94 | Retirer le bloc contact principal du formulaire + le pré-remplissage du 1er contact. Saisie des coordonnées dans l'onglet Contacts. |
+| page Consultation fournisseur (`/suppliers/{id}`) | #95 | Retirer l'affichage du bloc contact principal. |
+| page Modification fournisseur (`/suppliers/{id}/edit`) | #96 | Retirer les 5 champs du bloc principal ; payload `supplier:write:main` sans ces champs. |
+
+### Léger
+
+| Ticket | n° | Impact |
+|---|---|---|
+| page Répertoire fournisseurs + datatable | #93 | Recherche « nom / contact / email » selon D1. Datatable : colonnes inchangées (pas de contact inline en colonne). |
+| i18n + sidebar fournisseurs | #97 | Ne pas créer les clés i18n `form.main.firstName/lastName/email/phone*` (garder `form.contact.*`). |
+
+## Tickets NON impactés
+
+- #84 (taxonomie FOURNISSEUR), #88 (sous-ressources contacts/adresses/ribs —
+  `SupplierContact` est la cible, inchangé), #89 (validators Information Commerciale /
+  catégorie / RG-2.07-2.08), #90 (RBAC fournisseurs).
+
+## Méthode d'amendement
+
+Pour chaque ticket impacté : **préfixer** la description existante du bandeau ci-dessus
+(sans rien supprimer du contenu d'origine), via `mcp__lesstime__update-task`
+(`description` = bandeau + description actuelle). La méthode préserve l'historique et reste
+réversible (retirer le bandeau).

docs/specs/M1-clients/refonte-contact/M2-ticket-specs.md

@@ -0,0 +1,55 @@
+# M2 · Ticket Specs — Retirer le contact inline du `Supplier` dans les specs M2
+
+## 1. Objectif
+
+Mettre à jour les specs **M2 Fournisseurs** déjà rédigées pour **ne plus inclure** le contact
+principal inline sur le `Supplier`. M2 est le jumeau strict de M1 (`Supplier` /
+`SupplierContact` / `SupplierAddress` / `SupplierRib`) et n'est **pas encore codé** : il faut
+donc corriger la conception **en amont**, pour que les 14 tickets M2 « prêts à dev » soient
+implémentés directement sans les 5 colonnes inline.
+
+> Pendant de M1 ticket 3/3, mais côté M2 : **aucune migration de suppression ni backfill** —
+> on retire simplement le contact inline du modèle cible. Contexte : `README.md` du dossier
+> `refonte-contact`.
+
+## 2. Fichiers à modifier
+
+| Fichier | Sections concernées |
+|---|---|
+| `docs/specs/M2-suppliers/spec-back.md` | § 3.1 diagramme E-R (l.175-179 : retirer les 5 colonnes du bloc `supplier`) ; § 3.2 `CREATE TABLE supplier` (l.227-231) ; § 3.4 squelette entité `Supplier` (l.496-517 : props + `Assert\Callback` RG-2.01) ; § 4 exemples payload POST/GET (l.782-805, 867-871) ; recherche `?search=` (l.847 : refléter D1) ; export (refléter D2) ; § contrat de sérialisation (l.725, 729) ; § 7 RG (voir § 3). |
+| `docs/specs/M2-suppliers/spec-front.md` | « Formulaire principal » (l.105-117 : retirer Nom/Prénom/Téléphone/Téléphone 2/Email) ; onglet « Contact » (l.140-157 : retirer la phrase de pré-remplissage depuis le formulaire principal, l.142) ; écrans Consultation/Modification ; règles de formatage (l.283-285) ; recherche (l.76 : refléter D1). |
+
+## 3. Traitement des règles de gestion M2
+
+- **RG-2.01** (firstName OU lastName obligatoire sur Supplier) → **supprimée** : remplacée
+  par RG-2.04 (≥ 1 contact valide) + RG-2.13 (≥ 1 bloc Contact). Le contact inline n'existe
+  plus sur `Supplier`.
+- **RG-2.02** (max 2 téléphones sur Supplier) → **supprimée du Supplier** (reste sur
+  `SupplierContact`).
+- **RG-2.12** (normalisation Capitalize / chiffres / lowercase) → restreindre le scope :
+  s'applique à `companyName` (UPPERCASE) et aux champs de `SupplierContact` ; **plus** aux
+  champs inline du `Supplier` (qui disparaissent).
+- Ne pas renuméroter les RG : marquer « supprimée / requalifiée » en place, avec date.
+
+## 4. Forme
+
+- Bumper la version des deux specs M2 + entrée d'historique datée (2026-06-03, motif
+  « Suppression du contact inline du Supplier — alignement refonte-contact M1 »).
+- Encadré « Décision » renvoyant au `README.md` du dossier `refonte-contact`.
+- Garder le style des specs M2.
+
+## 5. Lien avec les tickets M2 existants
+
+La mise à jour des specs doit être cohérente avec l'**amendement des tickets M2** (voir
+`M2-amendement-tickets.md`) : tickets back #85/#86/#87/#91/#92 et front #94/#95/#96 (+ #93/#97
+légers). Specs et tickets décrivent le **même** modèle cible (sans contact inline).
+
+## 6. Critères d'acceptation (DoD)
+
+- [ ] `spec-back.md` M2 : aucune mention des 5 colonnes inline dans le modèle `supplier`
+      (E-R + SQL + entité + payloads + sérialisation) ; RG-2.01/2.02 marquées supprimées ;
+      D1/D2 décrites.
+- [ ] `spec-front.md` M2 : formulaire principal sans champs de contact ; onglet Contact
+      présenté comme seul lieu de saisie (sans pré-remplissage depuis le principal).
+- [ ] Versions bumpées + historique daté.
+- [ ] Cohérence avec l'amendement des tickets M2.

docs/specs/M1-clients/refonte-contact/M2-ticket-specs.prompt.md

@@ -0,0 +1,36 @@
+# Prompt d'implémentation — M2 · Ticket Specs
+
+Projet **Starseed**. Tâche **documentaire**. Mettre à jour les specs M2 Fournisseurs
+(`docs/specs/M2-suppliers/spec-back.md` + `spec-front.md`) pour retirer le contact principal
+inline du `Supplier` (5 champs `firstName/lastName/phonePrimary/phoneSecondary/email`).
+
+M2 n'est **pas encore codé** : on corrige la conception en amont, **sans** migration ni
+backfill (contrairement à M1). Les contacts vivent uniquement dans `SupplierContact`.
+
+Spec du ticket : `docs/specs/M1-clients/refonte-contact/M2-ticket-specs.md` (lis-la + le
+`README.md` du dossier).
+
+## Étapes
+
+1. Lire `spec-back.md` et `spec-front.md` M2 ; repérer toutes les occurrences des 5 champs
+   (E-R l.175-179, CREATE TABLE supplier l.227-231, entité l.496-517, payloads l.782-805 /
+   867-871, sérialisation l.725-729, RG-2.01/2.02/2.12, recherche, export, formulaire
+   principal front l.105-117, pré-remplissage onglet Contact l.142).
+2. Retirer les 5 colonnes du modèle `supplier`.
+3. Marquer **supprimées** RG-2.01 et RG-2.02 (renvoi RG-2.04/RG-2.13) ; restreindre RG-2.12
+   à `companyName` + `SupplierContact`. Ne pas renuméroter.
+4. Refléter D1 (recherche : LEFT JOIN supplier_contact recommandé) et D2 (export depuis le
+   contact principal recommandé).
+5. Front : retirer les champs de contact du formulaire principal ; retirer la phrase de
+   pré-remplissage du 1er bloc Contact ; présenter l'onglet Contact comme seul lieu de saisie.
+6. Bumper la version + historique daté (2026-06-03).
+
+## Garde-fous
+
+- Uniquement les `.md` de specs M2. Style existant conservé.
+- Cohérence stricte avec l'amendement des tickets M2 et avec la décision M1 (jumeau).
+
+## Vérification
+
+Relire les 2 specs : plus aucune mention des 5 champs inline dans le modèle `supplier` ;
+RG-2.01/2.02 supprimées ; versions bumpées.

docs/specs/M1-clients/refonte-contact/README.md

@@ -0,0 +1,84 @@
+# Refonte « contact » — suppression du contact inline des tiers (Client M1 + Supplier M2)
+
+> Dossier de tickets transverse. Source de vérité de la décision et de son découpage.
+> Rédigé le 2026-06-03. Owner : Matthieu.
+
+## 1. Décision
+
+Le **contact « principal » inline** (les 5 colonnes plates `first_name`, `last_name`,
+`phone_primary`, `phone_secondary`, `email`) est **supprimé de l'entité tier** (`Client`,
+puis `Supplier`). La gestion des contacts passe **exclusivement** par la sous-entité
+dédiée (`ClientContact` / `SupplierContact`), c.-à-d. l'**onglet « Contacts »**.
+
+### Pourquoi
+
+- **Modèle unique, zéro duplication.** Aujourd'hui le contact est saisi deux fois : une
+  fois dans le bloc principal (inline sur le tier) et une fois dans l'onglet Contacts
+  (sous-entité). À la création, le front recopie même l'un dans l'autre
+  (`prefillFirstContact`). Deux sources pour la même information = risque de divergence.
+- **Cohérence métier.** Un tier peut avoir plusieurs contacts ; il n'y a pas de raison
+  qu'un seul soit « privilégié » au niveau de la table tier. La notion de contact
+  appartient à la collection de contacts.
+- **Garantie préservée.** L'invariant « il y a toujours au moins un contact » est déjà
+  assuré par la sous-entité : RG-1.05/RG-1.14 (M1) et RG-2.04/RG-2.13 (M2) imposent
+  **≥ 1 bloc Contact valide** (Nom OU Prénom). Supprimer le contact inline ne crée donc
+  aucun trou : le contact reste obligatoire, mais au bon endroit.
+
+### Règles de gestion impactées
+
+| RG | Avant | Après |
+|---|---|---|
+| RG-1.01 / RG-2.01 (firstName OU lastName obligatoire **sur le tier**) | sur `Client` / `Supplier` | **supprimée** du tier — équivalent assuré par RG-1.05 / RG-2.04 sur la sous-entité |
+| RG-1.02 / RG-2.02 (max 2 téléphones **sur le tier**) | sur le tier | **supprimée** du tier — reste sur la sous-entité |
+| RG-1.19/1.20/1.21 — RG-2.12 (normalisation Capitalize / chiffres / lowercase) | appliquée aux champs **du tier ET** de la sous-entité | ne s'applique plus aux champs du tier (qui n'existent plus) — **inchangée** sur la sous-entité |
+
+## 2. Périmètre & découpage
+
+### M1 — Clients (code DÉJÀ livré → suppression + migration de données)
+
+| # | Ticket | Tag | Effort |
+|---|--------|-----|--------|
+| 1 | `M1-ticket-01-back` — supprimer le contact inline du `Client` (migration + backfill + entité + processor + provider + export + fixtures + tests) | Backend | M |
+| 2 | `M1-ticket-02-front` — retirer le bloc contact principal des écrans création / consultation / modification | Frontend | M |
+| 3 | `M1-ticket-03-specs` — acter la décision dans les specs M1 (back + front + cahier de test) | Maintenance | S |
+
+### M2 — Fournisseurs (NON codé → on retire le contact inline dès la conception)
+
+| # | Action | Tag | Effort |
+|---|--------|-----|--------|
+| 4 | `M2-ticket-specs` — mettre à jour les specs M2 déjà écrites (back + front) pour retirer le contact inline du `Supplier` | Maintenance | S |
+| — | `M2-amendement-tickets` — amender les tickets M2 existants (n° 84–97) impactés (migration, entités, processor, export, front, tests, i18n) | — | — |
+
+> M2 ne nécessite **pas** de migration de suppression ni de backfill : il suffit de **ne
+> jamais créer** les 5 colonnes inline sur `supplier`. Le travail M2 est donc un
+> ajustement de specs + un amendement des tickets « prêts à dev ».
+
+## 3. Décisions transverses à trancher (mêmes pour M1 et M2)
+
+Deux comportements s'appuyaient sur les colonnes inline du tier. À la suppression, il faut
+choisir leur nouvelle source. Recommandation par défaut entre parenthèses.
+
+- **D1 — Recherche serveur** (`?search=`). Aujourd'hui : fuzzy sur `companyName` +
+  `lastName` + `email` **du tier**. Après suppression, deux options :
+  - (a) restreindre la recherche à `companyName` seul (simple, mais perte de la recherche
+    par contact) ;
+  - (b) **[recommandé]** étendre la recherche en `LEFT JOIN` sur la sous-entité contact
+    (`first_name` / `last_name` / `email` du contact), pour préserver l'UX « recherche par
+    nom / contact / email » annoncée dans la barre de recherche.
+- **D2 — Colonnes de l'export XLSX** (Nom contact / Prénom / Téléphone / Téléphone 2 /
+  Email). Après suppression :
+  - (a) supprimer ces colonnes ;
+  - (b) **[recommandé]** les alimenter depuis le **contact principal** (le contact de plus
+    petit `position`), pour garder un export utile.
+
+Ces deux décisions sont à valider par le métier (Matthieu) avant implémentation et sont
+rappelées dans chaque ticket concerné.
+
+## 4. Fichiers de ce dossier
+
+- `README.md` (ce fichier) — décision + découpage.
+- `M1-ticket-01-back.md` / `.prompt.md` — description + prompt d'implémentation.
+- `M1-ticket-02-front.md` / `.prompt.md`.
+- `M1-ticket-03-specs.md` / `.prompt.md`.
+- `M2-ticket-specs.md` / `.prompt.md`.
+- `M2-amendement-tickets.md` — bandeau d'amendement + liste des tickets M2 à mettre à jour.

docs/specs/M1-clients/spec-front.md

@@ -0,0 +1,287 @@
+---
+# === IDENTITÉ ===
+module: M1
+nom: "Répertoire clients"
+ecran: repertoire-clients
+owner_spec: Matthieu
+backup_spec: Tristan
+version: V1
+# Historique : V1 (2026-06-03) — Refonte contact : suppression du bloc contact principal inline
+#   (Nom/Prénom/Téléphone/Téléphone 2/Email retirés du formulaire principal et des écrans).
+#   Saisie via l'onglet Contacts uniquement. Cf. docs/specs/M1-clients/refonte-contact/README.md
+date_redaction: 2026-05-28
+
+# === LIENS ===
+maquette_figma: "https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-31898"
+regles_metier: [RG-1.01, RG-1.02, RG-1.03, RG-1.05, RG-1.06, RG-1.07, RG-1.08, RG-1.09, RG-1.10, RG-1.11, RG-1.12, RG-1.13, RG-1.14, RG-1.15, RG-1.16, RG-1.17, RG-1.18, RG-1.19, RG-1.20, RG-1.21, RG-1.22, RG-1.23, RG-1.24, RG-1.25, RG-1.26, RG-1.27, RG-1.28, RG-1.29]
+roles: [Admin, Bureau, Compta, Commerciale, Usine]
+lien_spec_back: ./spec-back.md
+
+# === VALIDATION CLIENT #1 ===
+client_validation_1:
+  statut: validee
+  date: 2026-05-22
+  canal: ecrit
+  valide_par: "Matthieu (CP MALIO) — validation implicite, périmètre projet"
+  resume: "Module 1 — Répertoire clients. Page d'entrée Commercial. Datatable + 3 écrans (Ajouter / Consulter / Modifier). Création par onglets : Information / Contact / Adresse / Comptabilité (Transport, Statistiques, Rapports, Échanges = placeholders blancs)."
+  trace_archivee: "uploads/4a1b026f-M1-reportoire-clients.docx (V0 d'origine .docx)"
+
+# === LIEN LESSTIME ===
+lesstime_taskgroup_id: 23
+lesstime_project_id: 6
+statut_global: en_dev
+---
+
+# Module 1 — Répertoire clients (V0 front)
+
+> **Origine** : spec front V0 livrée le 22/05/2026 (`M1-reportoire-clients.docx`). Restitution Markdown pour intégration au workflow MALIO. Le contenu original n'est pas modifié — toute précision et toute décision (en particulier côté back) vit dans [`spec-back.md`](./spec-back.md).
+
+## But
+
+Permettre aux utilisateurs Starseed (selon rôle) de gérer le **répertoire des clients** de l'organisation : consultation, création, modification, archivage. Cette page est la **porte d'entrée du module Commercial**.
+
+## Accès
+
+- **Depuis** : menu principal → section **Commercial** → entrée « Répertoire clients »
+- **Rôles autorisés** :
+
+| 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** | ❌ | ❌ | ❌ |
+
+> **Note** : aligné sur le docx d'origine — Compta édite uniquement l'onglet Comptabilité (champs SIREN / TVA / Délai de règlement / Type de règlement / Banque / RIBs). Compta ne peut pas **créer** un client (pas de droit `manage` général), mais peut éditer la partie comptable d'un client existant créé par Admin ou Bureau.
+
+## Navigation
+
+L'écran est la page d'entrée du module **Commercial**. Titre : « **Répertoire clients** ».
+
+- Affichage principal : un **datatable** listant tous les clients **actifs** de l'organisation (les clients archivés sont masqués par défaut — filtre UI dédié pour les voir).
+- **Clic sur une ligne** → bascule sur l'écran **Consultation client** (page dédiée, pas un drawer — cf. maquette Figma).
+- **Bouton « + Ajouter »** (en haut à droite) → bascule sur l'écran **Ajouter un client**.
+- **Bouton « Exporter »** (en haut à droite) → télécharge un **fichier XLSX** des clients **affichés** (cf. filtre actif). Format détaillé dans [`spec-back.md` § Export](./spec-back.md).
+
+## Datatable du Répertoire
+
+Composant : `<MalioDataTable>`. Colonnes (à raffiner avec Tristan en revue maquette) :
+
+| Colonne | Source | Tri |
+|---|---|---|
+| **Nom entreprise** | `client.companyName` | ASC par défaut |
+| **Catégories** | liste des codes catégories séparés par `,` | Non |
+| **Site(s)** | sites rattachés à au moins une adresse (badges colorés) | Non |
+
+> **Filtre archivés** : toggle UI en haut du datatable. Désactivé par défaut. État local (pas dans l'URL — cf. règle ABSOLUE Starseed n°6).
+
+> **Pagination** : front via `<MalioDataTable>` (volumétrie cible faible — quelques centaines). Tri serveur `companyName ASC` par défaut.
+
+## Écran « Ajouter un client »
+
+Création par **onglets successifs avec validation incrémentale** : pour pouvoir passer à l'onglet suivant, il faut avoir validé l'onglet en cours. **Une fois un onglet validé, on passe automatiquement au suivant**, et les champs de l'onglet validé passent en lecture seule + bouton « Valider » désactivé (disabled).
+
+### Formulaire principal (pré-onglets)
+
+C'est le 1er bloc à remplir. Sans validation de ce formulaire, les onglets ne sont pas accessibles.
+
+> **V1 — refonte-contact** : le contact principal (Nom / Prénom / Téléphone / Téléphone 2 / Email) a été **retiré** du formulaire principal. Les coordonnées se saisissent désormais dans l'onglet **Contacts** (RG-1.05 / RG-1.14). Le formulaire principal ne contient plus que Entreprise + Catégorie + relation Distributeur/Courtier.
+
+| Champ | Type composant | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom du client (Entreprise)** | `<MalioInputText>` | Oui | RG-1.18 (normalisation UPPERCASE serveur) |
+| **Catégorie** | `<MalioSelectCheckbox>` (multi) | Oui | Liste des `Category` de l'API ; M2M Client ↔ Category |
+| **Distributeur / Courtier** | `<MalioSelect>` | Non | Valeurs : `Dépend du distributeur` / `Dépend du courtier` / `Aucun`. RG-1.03 conditionne les 2 champs suivants. |
+| **Nom du distributeur** | `<MalioSelect>` | Conditionnel | Visible si « Dépend du distributeur ». Liste = clients ayant ≥ 1 catégorie de **code** `DISTRIBUTEUR` (ERP-78), via `GET /api/clients?categoryCode=DISTRIBUTEUR`. RG-1.03. |
+| **Nom du courtier** | `<MalioSelect>` | Conditionnel | Visible si « Dépend du courtier ». Liste = clients ayant ≥ 1 catégorie de **code** `COURTIER` (ERP-78), via `GET /api/clients?categoryCode=COURTIER`. RG-1.03. |
+| **Prestation de triage** | `<MalioCheckbox>` | Non | — |
+
+**Action** : « Valider » (`<MalioButton>`) → POST `/api/clients` ([`spec-back.md` § 4.3](./spec-back.md)). Si succès, on passe automatiquement à l'onglet « Information ».
+
+### Onglet « Information »
+
+Saisir les informations de l'entreprise.
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Description** | `<MalioInputTextArea>` | Non | — _(onglet facultatif, RG-1.04 supprimée)_ |
+| **Concurrents** | `<MalioInputText>` | Non | — |
+| **Date de création** (de l'entreprise) | `<input type="date">` (exception Malio — pas de composant date couvert) | Non | — |
+| **Nombre de salariés** | `<MalioInputNumber>` | Non | — |
+| **CA €** | `<MalioInputAmount>` | Non | — |
+| **Dirigeant** | `<MalioInputText>` | Non | — |
+| **Résultat €** | `<MalioInputAmount>` | Non | — |
+
+**Action** : « Valider » → PATCH partiel `/api/clients/{id}` (groupe `client:write:information`).
+
+### Onglet « Contact »
+
+Saisir un ou plusieurs contacts associés au client. **(V1 — refonte-contact : plus de pré-remplissage depuis le formulaire principal ; les coordonnées du contact se saisissent directement ici.)** Au moins un bloc Contact valide est requis (RG-1.14).
+
+**Bloc Contact** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom** | `<MalioInputText>` | Conditionnel | RG-1.05 + RG-1.19 (Capitalize) |
+| **Prénom** | `<MalioInputText>` | Conditionnel | RG-1.05 + RG-1.19 (Capitalize) |
+| **Fonction** | `<MalioInputText>` | Non | — |
+| **Téléphone** (x1, +1 possible) | `<MalioInputText>` | Non | RG-1.20 (format) |
+| **Email** | `<MalioInputText>` type email | Non | RG-1.21 (lowercase) |
+
+**RG-1.14 (renforcement validée par Tristan le 28/05)** : **au moins 1 bloc Contact valide** (au moins Nom OU Prénom rempli) est obligatoire pour valider l'onglet. Donc l'onglet Contact ne peut pas être finalisé vide.
+
+**Actions** :
+- « + Nouveau contact » : ajoute un bloc. Bouton **désactivé tant que le bloc précédent n'a pas Prénom OU Nom rempli** (RG-1.05).
+- « Supprimer » (icône) sur un bloc : modal de confirmation (`<MalioButton>` Annuler / Confirmer). Si Oui → suppression du bloc.
+- « Valider » → PATCH `/api/clients/{id}/contacts` (création/mise à jour de la collection).
+
+### Onglet « Adresse »
+
+Saisir une ou plusieurs adresses du client, rattachées à un ou plusieurs sites Starseed (Châtellerault 86 / Saint-Jean 17 / Pommevic 82) et à des contacts.
+
+**Bloc Adresse** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Prospect** | `<MalioCheckbox>` | Non | RG-1.06 — masque Adresse de livraison + Facturation si coché |
+| **Adresse de livraison** | `<MalioCheckbox>` | Non | RG-1.07 — masque Prospect si coché |
+| **Facturation** | `<MalioCheckbox>` | Non | RG-1.08 — masque Prospect si coché ; affiche le champ Email (RG-1.11) |
+| **Catégorie** | `<MalioSelectCheckbox>` (multi) | Oui | Liste des `Category` **hors codes `DISTRIBUTEUR` / `COURTIER`** (ERP-78 — ces codes qualifient une relation entre clients, pas un lieu). Le front exclut ces 2 codes du select (le `code` est exposé en lecture sur `/api/categories`). |
+| **Pays** | `<MalioSelect>` | Oui | Préremplie « France » |
+| **Code postal** | `<MalioInputText>` (masque numérique) | Oui | RG-1.09 — déclenche autocomplete ville via BAN |
+| **Ville** | `<MalioSelect>` | Oui | RG-1.09 — alimentée par api-adresse.data.gouv.fr suivant le CP |
+| **Adresse** | `<MalioInputText>` (saisie assistée) | Oui | RG-1.09 — autocomplete BAN |
+| **Adresse complémentaire** | `<MalioInputText>` | Non | — |
+| **Sites Starseed** | `<MalioSelectCheckbox>` (multi-checkbox 86 / 17 / 82) | Oui | RG-1.10 — ≥ 1 site obligatoire |
+| **Contact(s) rattaché(s)** | `<MalioSelectCheckbox>` (multi) | Non | Liste = blocs Contact saisis dans l'onglet Contact |
+| **Email (facturation)** | `<MalioInputText>` type email | Conditionnel | RG-1.11 — visible/obligatoire uniquement si « Facturation » coché |
+
+**Actions** :
+- « + Nouvelle Adresse » : ajoute un bloc identique.
+- « Supprimer » : modal de confirmation puis suppression.
+- « Valider » → PATCH `/api/clients/{id}/addresses`.
+
+### Onglet « Transport »
+
+🚧 **Placeholder blanc au M1.** Frame vide. Aucun champ. Aucun bouton de validation. L'utilisateur passe automatiquement à l'onglet suivant. **Pas de mention « En cours »** — c'est juste blanc (décision Tristan 28/05).
+
+### Onglet « Comptabilité »
+
+⚠ **Accessible aux rôles avec `commercial.clients.accounting.manage`** (Admin + Compta au M1). Bureau et Commerciale ne voient pas l'onglet. **Compta peut éditer cet onglet** (champs SIREN / N° compte / TVA / Délai / Type de règlement / Banque / RIBs) — cf. décision Q1, aligné docx. Compta ne peut pas créer un client (pas de `manage` général).
+
+**Champs comptables** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **SIREN** | `<MalioInputText>` (masque 9 chiffres) | Oui | Format 9 chiffres. **Pas d'unicité** (décision Q4) |
+| **Numéro de compte** | `<MalioInputText>` | Oui | — |
+| **Mode de TVA** | `<MalioSelect>` | Oui | Liste depuis `/api/tva_modes` |
+| **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-1.12 — visible et obligatoire **si** Type de règlement = `VIREMENT`. Liste depuis `/api/banks`. |
+
+**Bloc RIB** (0..n blocs, présence obligatoire conditionnée par RG-1.13) :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Libellé** | `<MalioInputText>` | Oui (si LCR) | RG-1.13 |
+| **BIC** | `<MalioInputText>` | Oui (si LCR) | RG-1.13 — `#[AuditIgnore]` (champ sensible) |
+| **IBAN** | `<MalioInputText>` | Oui (si LCR) | RG-1.13 — `#[AuditIgnore]` (champ sensible) |
+
+**Actions** :
+- « + RIB » : ajoute un bloc.
+- « Supprimer » (icône) : modal de confirmation.
+- « Valider » → PATCH `/api/clients/{id}/accounting`.
+
+### Onglets « Statistiques » / « Rapports » / « Échanges »
+
+🚧 **Placeholders blancs au M1.** Mêmes règles que Transport (frames vides, pas de validation).
+
+## Écran « Consultation client »
+
+Tous les champs en **lecture seule**. Layout identique à l'écran Ajouter mais sans bouton « Valider », sans bouton `+` pour ajouter des blocs Contact / Adresse / RIB.
+
+- **Flèche retour** (à gauche) → revient au Répertoire.
+- **Bouton « Modifier »** (à droite, visible si l'utilisateur a la permission `commercial.clients.manage`) → bascule sur l'écran Modification.
+- **Bouton « Archiver »** (à droite, visible **uniquement pour Admin** via permission `commercial.clients.archive`) → ouvre une modal de confirmation, puis PATCH `/api/clients/{id}` `{ "isArchived": true }`. Le client passe en archivé (cf. flag `is_archived`).
+
+> Le client archivé peut être restauré (`isArchived: false`) — bouton « Restaurer » remplace « Archiver » dans la consultation d'un archivé. Décision validée Tristan 28/05.
+
+### Onglets affichés en consultation
+
+Mêmes onglets qu'en création, **plus** les 4 placeholders blancs. L'utilisateur navigue librement entre les onglets (pas de séquence forcée en consultation).
+
+## Écran « Modification client »
+
+Comportement identique à l'écran Ajouter sauf :
+- **Pas de formulaire principal** (les champs principaux sont édités via les onglets correspondants).
+- Les champs sont **pré-remplis** avec les valeurs actuelles.
+- **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` restent en lecture seule (pas de bouton Valider, pas d'icône suppression de bloc).
+- Les onglets placeholders restent inaccessibles à l'édition (blancs).
+
+## Composants UI à utiliser (`@malio/layer-ui`)
+
+- **Datatable** : `<MalioDataTable>` (Répertoire)
+- **Input texte** : `<MalioInputText>`
+- **Input numérique** : `<MalioInputNumber>`
+- **Input montant** : `<MalioInputAmount>` (CA, Résultat)
+- **TextArea** : `<MalioInputTextArea>` (Description)
+- **Select simple** : `<MalioSelect>` (Pays, Ville, distributeur/courtier, refs comptables)
+- **Select multi (cases à cocher)** : `<MalioSelectCheckbox>` (Catégorie, Sites, Contacts rattachés)
+- **Checkbox** : `<MalioCheckbox>` (Prospect, Adresse livraison, Facturation, Prestation de triage)
+- **Bouton** : `<MalioButton>`, `<MalioButtonIcon>`
+- **Toasts** : standards via `useApi()`
+
+**Exceptions autorisées** (à commenter `// TODO migrer quand Malio couvre`) :
+- `<input type="date">` pour « Date de création » (composant `MalioDate` non couvert)
+- Modal de confirmation : composant à confirmer côté équipe front (probablement `<MalioModal>` ou un wrapper à créer dans `frontend/shared/`)
+
+## Règles de formatage et normalisation
+
+Le serveur normalise systématiquement (cf. RG-1.18 à RG-1.21 dans [`spec-back.md`](./spec-back.md)) :
+
+| Champ | Normalisation serveur | Affichage front |
+|---|---|---|
+| Nom entreprise (`companyName`) | UPPERCASE intégral | UPPERCASE |
+| Nom + Prénom contact | Capitalize (1ère lettre majuscule + reste minuscule) | identique |
+| Téléphone (téléphones des blocs `ClientContact`) | Chiffres uniquement en BDD | Formaté `XX XX XX XX XX` à l'affichage (filter Vue) |
+| Email | lowercase intégral | identique |
+
+> **Le front ne fait pas la normalisation** — il envoie la valeur saisie, le serveur normalise puis renvoie la valeur normalisée. L'UI affiche immédiatement la valeur normalisée renvoyée par l'API. Cohérent avec le pattern `useApi()`.
+
+## API adresse postale
+
+Le composant `Code postal` + `Ville` + `Adresse` est branché sur **api-adresse.data.gouv.fr** (Base Adresse Nationale, gratuite, française).
+
+- Composable dédié `useAddressAutocomplete()` (à créer en M1).
+- Appel HTTP **direct depuis le front** (CORS OK), pas de proxy back.
+- Pattern : à la saisie du code postal (5 chiffres), GET `https://api-adresse.data.gouv.fr/search/?q={cp}&type=municipality` → alimente le select Ville. Sur saisie d'adresse : `?q={addr}&postcode={cp}` (sans filtre `type`) → suggestions adresse.
+    - ⚠ **Ne pas forcer `type=housenumber`** sur la recherche d'adresse (corrigé en ERP-66) : la BAN ne renvoie un résultat de ce type qu'une fois un numéro saisi, donc une recherche par nom de rue (« boulevard du port ») renverrait **0 résultat** pendant toute la frappe. Sans filtre `type`, la BAN classe rues + numéros par pertinence — comportement d'autocomplétion attendu.
+- Cas dégradé : si l'API ne répond pas (offline, timeout), le champ Ville devient un `<MalioInputText>` libre éditable + toast d'avertissement. Validation serveur acceptera la saisie libre.
+
+## Points laissés ouverts par la V0 (résolus côté back)
+
+| # | Zone d'ombre V0 | Résolution (cf. `spec-back.md`) |
+|---|---|---|
+| 1 | Catégorie en multi-select non clarifiée (1 ou n par client) | **M2M `client_category`** validée. Refonte ERP-78 : type unique `CLIENT` ; `Distributeur`/`Courtier`/`Secteur`/`Autre` (+ catégories métier) sont des `Category` portant un `code` stable (HP-3 du M0 levé). |
+| 2 | Distributeur / Courtier : liste de quoi ? | **Auto-référence Client** via 2 FK nullables `distributor_id` et `broker_id` (cf. RG-1.03). Une seule des deux est remplie à la fois. |
+| 3 | Onglet « Comptabilité » : qui édite ? | **Admin et Compta** peuvent éditer l'onglet Comptabilité (`commercial.clients.accounting.manage`). Bureau / Commerciale ne voient pas l'onglet. Compta ne peut pas créer un client (pas de `manage` global), mais peut éditer la partie comptable d'un client existant. |
+| 4 | Workflow par onglet | **Sauvegarde incrémentale**. POST formulaire principal crée le `Client` (status implicite « actif »). Chaque onglet validé = PATCH partiel par groupe de sérialisation dédié. Pas d'état « draft ». |
+| 5 | Onglets « À venir » | **Placeholders blancs** (frames vides, pas de message). Ré-activables sans rebuild quand les modules associés arriveront. |
+| 6 | Archive vs soft delete | **Flag `is_archived` séparé de `deleted_at`**. Archive ≠ delete : un client archivé est masqué par défaut mais reste en BDD éditable (Admin seul). Filtres UI distincts. Soft delete = HP M2. |
+| 7 | Unicité métier | **Nom d'entreprise uniquement** (case-insensitive, parmi non-archivés) — décision Q4. SIREN et email NON uniques. Index partiel Postgres `uq_client_company_name_active`. Doublon de nom → 409 Conflict. |
+| 8 | Téléphones (max 2) | Sur les blocs `ClientContact` (`phone_primary` + `phone_secondary`). _(V1 : retirés du Client — refonte-contact.)_ |
+| 9 | API code postal | **api-adresse.data.gouv.fr** (BAN). Appel direct front via composable dédié. Cas dégradé : saisie libre + toast. |
+| 10 | Référentiels comptables | **4 entités CRUD-ables** (`TvaMode`, `PaymentDelay`, `PaymentType`, `Bank`) seedées au M1, CRUD admin futur (HP-M2). |
+| 11 | Format de l'export | **XLSX uniquement** au M1. CSV à étudier en HP. |
+
+---
+
+## 📦 Tickets Lesstime générés
+
+**TaskGroup Lesstime** : à créer — `M1 — Répertoire clients` (projet `ERP / Starseed`, projectId=6).
+
+> Détail complet, table des tickets et action manuelle dans Lesstime → voir [`spec-back.md § Tickets Lesstime générés`](./spec-back.md#-tickets-lesstime-générés).

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

@@ -0,0 +1,331 @@
+---
+# === IDENTITÉ ===
+module: M2
+nom: "Répertoire fournisseurs"
+ecran: repertoire-fournisseurs
+owner_spec: Matthieu
+backup_spec: Tristan
+version: V0.2
+date_redaction: 2026-06-02
+# Historique : V0.2 (2026-06-03) — Refonte contact : suppression du bloc contact principal inline
+#   du formulaire Supplier (Nom/Prénom/Téléphone/Téléphone 2/Email). Saisie via l'onglet Contacts.
+#   Aligné sur M1. Cf. docs/specs/M1-clients/refonte-contact/README.md
+
+# === LIENS ===
+maquette_figma: "https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-36987&p=f&m=dev"
+regles_metier: [RG-2.01, RG-2.02, RG-2.03, RG-2.04, RG-2.05, RG-2.06, RG-2.07, RG-2.08, RG-2.09, RG-2.10, RG-2.11, RG-2.12, RG-2.13, RG-2.14, RG-2.15, RG-2.16, RG-2.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)"
+  resume: "Module 2 — Répertoire fournisseurs. Page d'entrée Commercial. Datatable + 3 écrans (Ajouter / Consulter / Modifier). Création par onglets : Information / Contact / Adresse / Comptabilité (Transport, Statistiques, Rapports, Échanges = placeholders 'À venir')."
+  trace_archivee: "uploads/M2-reportoire-fournisseurs.docx (V0.1) + M2-reportoire-fournisseurs-V01.pdf"
+
+# === LIEN LESSTIME ===
+lesstime_taskgroup_id: 26
+lesstime_project_id: 6
+statut_global: a_dev
+---
+
+# Module 2 — Répertoire fournisseurs (V0.1 front)
+
+> **Origine** : spec front livrée le 22/05/2026 (V0), amendée le 01/06/2026 (V0.1) — `M2-reportoire-fournisseurs.docx`. Restitution Markdown pour intégration au workflow MALIO. Le contenu fonctionnel original n'est pas modifié ; toute décision technique (back) vit dans [`spec-back.md`](./spec-back.md). Le M2 réutilise massivement le pattern et les composants posés au [M1 clients](../M1-clients/spec-front.md).
+
+## But
+
+Permettre aux utilisateurs Starseed (selon rôle) de gérer le **répertoire des fournisseurs** de l'organisation : consultation, création, modification, archivage. C'est la **deuxième porte d'entrée du module Commercial** (aux côtés des Clients).
+
+## Accès
+
+- **Depuis** : menu principal → section **Commercial** → entrée « Répertoire fournisseurs » (route `/suppliers`).
+- **Rôles autorisés** :
+
+| 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** | ❌ (pas d'accès) | ❌ | ❌ |
+
+> **Note** : RBAC identique au M1, transposée sur `commercial.suppliers.*`. Compta édite uniquement l'onglet Comptabilité (SIREN / N° compte / TVA / Délai / Type de règlement / Banque / RIBs) d'un fournisseur existant ; Compta ne peut pas **créer** un fournisseur. **L'archivage est réservé à Admin** (cf. tableau du docx).
+
+## Navigation
+
+Page d'entrée du module **Commercial** (route `/suppliers`). Titre : « **Répertoire fournisseurs** ».
+
+- Affichage principal : un **datatable** listant tous les fournisseurs **actifs** (les archivés sont masqués par défaut — toggle UI dédié).
+- **Clic sur une ligne** → écran **Consultation fournisseur** (page dédiée).
+- **Bouton « + Ajouter »** (haut droite) → écran **Ajouter un fournisseur**.
+- **Bouton « Filtrer »** (haut droite, **à côté de « + Ajouter »**) → ouvre le **panneau de filtres** (cf. ci-dessous). Un badge/compteur indique le nombre de filtres actifs ; un bouton « Réinitialiser » les vide.
+- **Bouton « Exporter »** (haut droite) → télécharge un **XLSX** des fournisseurs **affichés** (cf. filtres actifs). Format dans [`spec-back.md § 4.6`](./spec-back.md).
+
+### Panneau de filtres (bouton « Filtrer »)
+
+Ouvre un drawer/popover (composant à confirmer côté équipe front — réutiliser le pattern M1 s'il existe). Filtres proposés, branchés sur les query params de `GET /api/suppliers` (cf. [`spec-back.md § 4.1`](./spec-back.md)) :
+
+| Filtre | Composant | Query param back |
+|---|---|---|
+| **Recherche** (nom entreprise / contact / email — recherche contact via `supplier_contact`, décision D1) | `<MalioInputText>` | `?search=` |
+| **Catégorie** | `<MalioSelectCheckbox>` (multi, type FOURNISSEUR) | `?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/suppliers` avec les params.
+- **État 100 % local** (jamais dans l'URL — règle ABSOLUE n°6). Le bouton « Filtrer » + son panneau remplacent/regroupent l'ancien toggle « archivés » isolé.
+
+## Datatable du Répertoire
+
+Composant : `<MalioDataTable>` branché sur `usePaginatedList<Supplier>({ url: '/suppliers' })` (règle frontend obligatoire — pagination Hydra, état 100 % local). Colonnes **conformes à la maquette Figma** (4 colonnes) :
+
+| Colonne | Source | Tri |
+|---|---|---|
+| **Nom** | `supplier.companyName` | ASC par défaut |
+| **Catégories** | `supplier.categories[].name` (embarquées en liste — cohérence M1/ERP-62 ; libellé = `name`, pas `label`) | Non |
+| **Site** | `supplier.sites[].name` (agrégat des adresses via `getSites()` ; `Site` n'a pas de `code`) | Non |
+| **Dernière activité** | `supplier.updatedAt` (format `JJ-MM-AAAA`) — exposé dans `supplier:read` | Oui |
+
+> **Clic sur une ligne** (texte en bleu lien) → écran Consultation.
+> **Filtres** : regroupés dans le panneau du bouton « Filtrer » (cf. section précédente), dont l'inclusion des archivés (désactivée par défaut). **État local** (jamais dans l'URL — règle ABSOLUE n°6).
+> **Pagination** : `<MalioDataTable>` + `usePaginatedList`, options **standard Starseed 10 / 25 / 50 (défaut 10)** — on **n'applique pas** le « Ligne : 20 » de la maquette (décision Matthieu : on reste sur le standard). Tri serveur `companyName ASC` par défaut.
+
+## Écran « Ajouter un fournisseur »
+
+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).
+
+**Barre d'onglets en création (5 onglets, conforme maquette)** : `Information` · `Contacts` · `Adresses` · `Transport` · `Comptabilité`. L'onglet `Information` est actif par défaut juste après validation du formulaire principal. Les onglets `Statistiques`, `Rapports` et `Échanges` **n'apparaissent PAS dans le flux de création** — ils ne sont présents qu'en Consultation / Modification.
+
+### Formulaire principal (pré-onglets)
+
+1er bloc à remplir. Sans validation, les onglets ne sont pas accessibles. Une fois validé → POST `/api/suppliers`, puis bascule sur l'onglet Information ; les champs passent en readonly.
+
+> **V0.2 — refonte-contact** : le contact principal (Nom / Prénom / Téléphone / Téléphone 2 / Email) a été **retiré** du formulaire principal. Les coordonnées se saisissent dans l'onglet **Contacts** (RG-2.04 / RG-2.13). Le formulaire principal ne contient plus que Entreprise + Catégorie.
+
+| Champ | Type composant | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom du fournisseur (Entreprise)** | `<MalioInputText>` | Oui | RG-2.12 (UPPERCASE serveur) |
+| **Catégorie** | `<MalioSelectCheckbox>` (multi) | Oui | `Category` de **type FOURNISSEUR** via `GET /api/categories?typeCode=FOURNISSEUR` (RG-2.10). Libellé affiché = `category.name`. ⚠️ Le type + le filtre `?typeCode=` sont **à créer** côté back (n'existent pas en prod — cf. spec-back § 2.4). |
+
+**Action** : « Valider » (`<MalioButton>`) → POST `/api/suppliers` ([`spec-back.md § 4.3`](./spec-back.md)). Succès → onglet « Information ».
+
+### Onglet « Information »
+
+Saisir les informations du fournisseur.
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Description** | `<MalioInputTextArea>` | Conditionnel | RG-2.03 (obligatoire rôle Commerciale) |
+| **Concurrent** | `<MalioInputText>` | Conditionnel | RG-2.03 |
+| **Date création** (entreprise) | `<input type="date">` (exception Malio — `// TODO migrer`) | Conditionnel | RG-2.03 |
+| **Nombre de salariés** | `<MalioInputNumber>` | Conditionnel | RG-2.03 |
+| **CA €** | `<MalioInputAmount>` | Conditionnel | RG-2.03 |
+| **Dirigeant** | `<MalioInputText>` | Conditionnel | RG-2.03 |
+| **Résultat €** | `<MalioInputAmount>` | Conditionnel | RG-2.03 |
+| **Volume Prévisionnel** | `<MalioInputNumber>` | Conditionnel | RG-2.03 (champ spécifique fournisseur) |
+
+> **Disposition maquette** : 3 colonnes — ligne 1 (Description / Concurrent / Date création), ligne 2 (Nombre de salariés / CA / Dirigeant), ligne 3 (Résultat / Volume Prévisionnel).
+
+**Action** : « Valider » → PATCH `/api/suppliers/{id}` (groupe `supplier:write:information`).
+
+### Onglet « Contact »
+
+Saisir un ou plusieurs contacts. **(V0.2 — refonte-contact : plus de pré-remplissage depuis le formulaire principal ; les coordonnées du contact se saisissent directement ici.)** Au moins un bloc Contact valide est requis (RG-2.13).
+
+**Bloc Contact** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom** | `<MalioInputText>` | Conditionnel | RG-2.04 + RG-2.12 (Capitalize) |
+| **Prénom** | `<MalioInputText>` | Conditionnel | RG-2.04 + RG-2.12 (Capitalize) |
+| **Fonction** | `<MalioInputText>` | Non | — |
+| **Téléphone** (x1, +1 possible) | `<MalioInputText>` | Non | RG-2.12 (format) |
+| **Email** | `<MalioInputText>` type email | Non | RG-2.12 (lowercase) |
+
+**RG-2.04 / RG-2.13** : au moins 1 bloc Contact valide (Nom OU Prénom rempli) pour valider l'onglet — l'onglet Contact ne peut pas être finalisé vide.
+
+**Actions** :
+- « + Nouveau contact » : ajoute un bloc. **Désactivé tant que le bloc précédent n'a pas Prénom OU Nom** (RG-2.04).
+- « Supprimer » (icône) : modal de confirmation, puis suppression du bloc.
+- « Valider » → PATCH `/api/suppliers/{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 |
+|---|---|---|---|
+| **Type d'adresse** | `<MalioRadioButton>` — `Prospect` / `Départ` / `Rendu` | Oui | RG-2.09 (exclusif, enum `PROSPECT`/`DEPART`/`RENDU`) |
+| **Pays** | `<MalioSelect>` (saisie assistée — préremplie « France ») | Oui | — |
+| **Code postal** | `<MalioInputText>` (saisie assistée) | Oui | RG-2.05 — déclenche autocomplete ville (BAN) |
+| **Ville** | `<MalioSelect>` (saisie assistée) | Oui | RG-2.05 — alimentée par api-adresse.data.gouv.fr suivant le CP |
+| **Adresse** | `<MalioInputText>` (saisie assistée) | Oui | RG-2.05 — autocomplete BAN |
+| **Adresse complémentaire** | `<MalioInputText>` | Non | — |
+| **Sélecteur de site** | `<MalioSelectCheckbox>` (86 / 17 / 82) | Oui | RG-2.06 — ≥ 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). |
+| **Catégories** | `<MalioSelectCheckbox>` (multi) | Oui | Catégories de type FOURNISSEUR (RG-2.10), liées aux catégories du fournisseur |
+| **Contact** | `<MalioSelectCheckbox>` (multi) | Non | Liste = blocs Contact saisis dans l'onglet Contact |
+| **Benne(s)** | `<MalioInputNumber>` (stepper −/+ , défaut 0) | Non | Champ spécifique fournisseur |
+| **Prestation de triage** | `<MalioCheckbox>` | Non | Champ spécifique fournisseur (porté par l'adresse — colonne back `triage_provider`) |
+
+> **Disposition maquette par bloc** : ligne 1 = radio (Prospect / Départ / Rendu) + Pays + Code postal ; ligne 2 = Ville + Adresse + Adresse complémentaire ; ligne 3 = sites (86 / 17 / 82) + Catégories + Contact ; ligne 4 = Benne(s) + Prestation de triage. Icône corbeille en haut à droite de chaque bloc pour le supprimer.
+
+**Actions** :
+- « + Nouvelle Adresse » : ajoute un bloc identique au premier.
+- « Supprimer » : modal de confirmation puis suppression.
+- « Valider » → PATCH `/api/suppliers/{id}/addresses`.
+
+### Onglet « Transport »
+
+🚧 **Onglet placeholder minimal au M2.** Conforme à la maquette : la frame est **vide** (aucun champ, aucun bouton de validation, aucune API back). L'onglet reste navigable. Un libellé discret « À venir » est toléré mais non requis (la maquette ne l'affiche pas). Cet onglet **fait partie de la barre de création** (entre Adresses et Comptabilité).
+
+### Onglet « Comptabilité »
+
+⚠ **Accessible aux rôles avec `commercial.suppliers.accounting.view`** (Admin + Compta au M2). Bureau et Commerciale ne voient pas l'onglet. **Compta peut éditer** cet onglet (`accounting.manage`). Compta ne peut pas créer un fournisseur (pas de `manage` global).
+
+**Champs comptables** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **SIREN** | `<MalioInputText>` (masque 9 chiffres) | Oui | 9 chiffres. **Pas d'unicité** (cf. § 2.6) |
+| **Numéro de compte** | `<MalioInputText>` | Oui | — |
+| **Mode de TVA** | `<MalioSelect>` | Oui | Liste depuis `/api/tva_modes` (référentiel 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-2.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-2.08) :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Libellé** | `<MalioInputText>` | Oui (si LCR) | RG-2.08 |
+| **BIC** | `<MalioInputText>` | Oui (si LCR) | RG-2.08 |
+| **IBAN** | `<MalioInputText>` | Oui (si LCR) | RG-2.08 |
+
+**Actions** :
+- « + RIB » : ajoute un bloc.
+- « Supprimer » (icône) : modal de confirmation.
+- « Valider » → PATCH `/api/suppliers/{id}` (groupe `supplier:write:accounting`) + sous-ressource RIBs.
+
+### Onglets « Statistiques » / « Rapports » / « Échanges »
+
+🚧 **Placeholders minimaux au M2 — uniquement en Consultation / Modification** (ils n'apparaissent **pas** dans le flux de création, cf. maquette). Frames vides, pas de validation, pas d'API.
+
+## Écran « Consultation fournisseur »
+
+Tous les champs en **lecture seule**. 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 `commercial.suppliers.manage`) → écran Modification.
+- **Bouton « Archiver »** (droite, visible **uniquement Admin** via `commercial.suppliers.archive`) → modal de confirmation, puis PATCH `/api/suppliers/{id}` `{ "isArchived": true }`.
+
+> Un fournisseur archivé peut être restauré (`isArchived: false`) — bouton « Restaurer » remplace « Archiver » dans la consultation d'un archivé.
+
+### Onglets affichés en consultation
+
+Information / Contacts / Adresses / Transport / Statistiques / Rapports / Échanges / Comptabilité (les 4 derniers métiers en placeholder « À venir », Comptabilité selon permission). L'utilisateur navigue **librement** entre les onglets (pas de séquence forcée en consultation).
+
+## Écran « Modification fournisseur »
+
+Comportement identique à l'écran Ajouter sauf :
+- **Pas de formulaire principal** réaffiché (champs principaux édités via les onglets correspondants).
+- Les champs sont **pré-remplis** avec les valeurs actuelles.
+- **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).
+- Les onglets placeholders « À venir » restent non éditables.
+
+## Composants UI à utiliser (`@malio/layer-ui`)
+
+- **Datatable** : `<MalioDataTable>` (+ `usePaginatedList`)
+- **Input texte** : `<MalioInputText>`
+- **Input numérique** : `<MalioInputNumber>` (Nombre de salariés, Volume prévisionnel, Bennes)
+- **Input montant** : `<MalioInputAmount>` (CA, Résultat)
+- **TextArea** : `<MalioInputTextArea>` (Description)
+- **Select simple** : `<MalioSelect>` (Pays, Ville, référentiels comptables)
+- **Select multi (cases à cocher)** : `<MalioSelectCheckbox>` (Catégorie, Sites, Contacts rattachés)
+- **Radio** : `<MalioRadioButton>` (Type d'adresse Prospect / Départ / Rendu — RG-2.09)
+- **Checkbox** : `<MalioCheckbox>` (Prestataire de triage)
+- **Bouton** : `<MalioButton>`, `<MalioButtonIcon>`
+- **Toasts** : standards via `useApi()`
+
+**Exceptions autorisées** (commenter `// TODO migrer quand Malio couvre`) :
+- `<input type="date">` pour « Date Création » (`MalioDate` non couvert).
+- Modal de confirmation : `<MalioModal>` ou wrapper partagé dans `frontend/shared/` (réutiliser celui du M1 si présent).
+
+## Composables & appels API
+
+- `usePaginatedList<Supplier>({ url: '/suppliers' })` — liste paginée (obligatoire, règle frontend). La liste consomme `categories[]` (libellé = `name`) et `sites[]` (libellé = `name`, pas de `code`) **embarqués** + `updatedAt` (cohérence M1/ERP-62, cf. [`spec-back.md § 2.12 / § 4.0`](./spec-back.md)). Côté back, fetch-joins anti-N+1.
+- `useSupplier(id)` — charge le détail via `GET /api/suppliers/{id}`, qui **embarque** `contacts`, `addresses` (avec `sites` / `categories` / `contacts` imbriqués) et, si permission, `ribs` + scalaires compta. Les écrans Consultation et Modification se peuplent depuis cette seule réponse (RETEX M1 §2 : embed borné, pas de N+1 d'appels). **DoD avant intégration** : vérifier que le JSON réel contient bien ces blocs (cf. [`spec-back.md § 4.0.bis`](./spec-back.md)).
+- `useSupplierForm()` — workflow par onglet (POST principal + PATCH partiels par groupe), miroir de `useClientForm()`.
+- `useAddressAutocomplete()` — **réutilisé du M1** (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é du M1** pour l'affichage `XX XX XX XX XX`.
+
+## Règles de formatage et normalisation
+
+Le serveur normalise systématiquement (RG-2.12 — cf. [`spec-back.md`](./spec-back.md)) :
+
+| Champ | Normalisation serveur | Affichage front |
+|---|---|---|
+| Nom fournisseur (`companyName`) | UPPERCASE intégral | UPPERCASE |
+| Nom + Prénom contact | Capitalize | identique |
+| Téléphones (blocs `SupplierContact`) | 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. Cohérent avec `useApi()`.
+
+## 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** (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.
+- À 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 M1 (clients)
+
+| Zone | M1 clients | M2 fournisseurs |
+|---|---|---|
+| Distributeur / Courtier | Auto-référence Client (RG-1.03) | **Absent** |
+| Prestation de triage | Booléen sur le client (formulaire principal) | **Booléen sur l'adresse** (`triage_provider`) |
+| Type d'adresse | 3 checkboxes Prospect / Livraison / Facturation | **Radio exclusif** Prospect / Départ / Rendu (RG-2.09) |
+| Email facturation sur adresse | Oui (conditionnel) | **Absent** |
+| Champ adresse « Bennes » | — | **Présent** (nombre) |
+| Onglet Information | 7 champs | **8 champs** (ajout « Volume prévisionnel ») |
+| Catégories | type unique `CLIENT` (codes ERP-78) | **nouveau type `FOURNISSEUR`** |
+| Archivage | Admin | **Admin uniquement** (idem) |
+| Onglets « À venir » | frames blanches | **placeholder « À venir »** (minimal) |
+
+## Points résolus côté back
+
+| # | Zone d'ombre | Résolution (cf. `spec-back.md`) |
+|---|---|---|
+| 1 | Catégorie multi-select | M2M `supplier_category`, `Category` de type **FOURNISSEUR** (RG-2.10) |
+| 2 | Type d'adresse Prospect/Départ/Rendu | Enum exclusif `address_type` (RG-2.09) |
+| 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 » (Transport / Stats / 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 fournisseur uniquement (à valider — § 2.6). SIREN/email non uniques |
+| 8 | Référentiels comptables | Réutilisés du M1 (zéro duplication) |
+| 9 | API code postal | BAN via `useAddressAutocomplete()` du M1 |
+| 10 | Format export | XLSX uniquement (CSV = HP) |
+
+---
+
+## 📦 Tickets Lesstime
+
+**TaskGroup Lesstime** : à créer — `M2 — Répertoire fournisseurs` (projet `ERP / Starseed`, projectId=6).
+
+> Détail complet et action manuelle → voir [`spec-back.md § Tickets Lesstime`](./spec-back.md#-tickets-lesstime-à-découper).

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

@@ -0,0 +1,339 @@
+---
+# === 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/M4-transporteurs/prompts/00-PLAN-MAITRE.md

@@ -0,0 +1,100 @@
+# M4 — Plan maître worktrees (back, Matthieu)
+
+> **Rôle de ce fichier** : vue d'ensemble que la *conversation maître* tient à jour.
+> Chaque worktree = une conversation Claude isolée + une branche + une PR vers `develop`.
+> Les prompts à coller sont dans `WT*.md`.
+
+## Principe
+
+- 1 worktree = 1 branche partant de `origin/develop` (à jour des deps).
+- 1 ticket = 1 PR atomique vers **`develop`** (jamais `main`).
+- Commit autorisé sur la branche du worktree (ces prompts SONT la demande explicite) ;
+  `git commit --no-verify` OK si `make test` est déjà vert (le hook relance toute la suite).
+- **Chaque worktree ouvre SA PR** vers `develop` en fin de tâche (cf. bloc PR ci-dessous).
+
+## Bloc PR standard (repris dans chaque prompt)
+
+```bash
+git push -u origin <branche>
+tea pr create --base develop --head <branche> \
+  --title "<type>(<scope>) : <titre>" \
+  --description "Résumé + lien ticket Lesstime ERP-XXX"
+```
+Puis **labelliser la PR via l'API Gitea** (tea ne pose pas les labels en CLI — `gitea.malio.fr`).
+Cible **`develop`**, jamais `main`. **Aucune mention de Claude/IA** dans titre ou description.
+
+## Vagues & ordre de merge
+
+```
+VAGUE 0  (en parallèle, dès maintenant)
+  WT1  1.2 upload Shared      base: origin/develop            ──┐
+  WT2  1.1 RBAC + sidebar     base: origin/develop (≥ERP-150) ──┤ indépendants
+                                                                 │
+VAGUE 1  (critique, séquentiel)                                  │
+  WT3  1.3 migration + 1.5 entités/resource/provider + i18n audit
+       base: origin/develop APRÈS merge WT1  (FK uploaded_document)
+       ⭐ livre le CONTRAT JSON liste+détail → débloque le front (Tristan)
+
+VAGUE 2  (fan-out, tous en parallèle dès WT3 mergé)
+  WT4  1.6 processor          base: develop ≥ WT3
+  WT5  1.4 qualimat endpoint  base: develop ≥ WT2 (perm) + ERP-39   (indépendant de WT3)
+  WT6  1.7 adresses           base: develop ≥ WT3
+  WT7  1.8 contacts           base: develop ≥ WT3
+  WT8  1.9 prix               base: develop ≥ WT3
+  WT9  1.10 export XLSX        base: develop ≥ WT3
+
+VAGUE 3  (final)
+  WT10 1.11 tests + fixtures + contrat  base: develop ≥ TOUT
+```
+
+**Parallélisme réel** : 2 worktrees en V0, puis 1 goulot (WT3), puis **jusqu'à 6 en V2**, puis 1 (WT10).
+
+## Règle anti-conflit worktree (IMPORTANT)
+
+Pour que WT4→WT9 tournent en parallèle sans conflit de merge :
+
+| Fichier partagé | Qui le touche | Les autres |
+|---|---|---|
+| `CarrierFixtures` | **WT10 uniquement** | interdit (WT3 met un fixture minimal, WT6-9 n'y touchent pas) |
+| Entité `Carrier` (ApiResource) | **WT3** crée, **WT4** ajoute le Processor | WT6-9 créent des **resources/processors dédiés** par sous-entité, ne modifient pas `Carrier` |
+| `ColumnCommentsCatalog` | WT1 (`uploaded_document`), WT3 (`carrier*`) | personne d'autre |
+| `fr.json` (clés audit) | **WT3** (clés `audit.entity.transport_*`) | personne d'autre côté back |
+| `migrations/` | WT1 puis WT3 (ordre timestamp) | aucune autre migration |
+
+## Mode retenu : STACK séquentiel, SANS worktree (repo principal)
+
+Matthieu empile les MR, un ticket à la fois, **directement dans `/home/matthieu/dev_malio/Starseed`** (pas de worktree).
+- **Ignorer les blocs `git worktree add` des `WT*.md`** → remplacés par une branche normale :
+  ```bash
+  git fetch origin
+  git checkout -b feat/erp-XXX-... origin/<branche-précédente>
+  ```
+- **WT1 hors pile** (déjà mergé). Pile M4 — chaque branche basée sur la précédente :
+  `WT2 → WT3 → WT4 → WT5 → WT6 → WT7 → WT8 → WT9 → WT10`
+- PR de chaque maillon : `--base <branche-précédente>` (bas de pile WT2 = `develop`). Au merge, les MR du dessus se recible auto.
+- Docker tourne sur le repo principal → `make test`/`php-cs-fixer` OK sans rebind (le piège worktree-vs-mount ne s'applique plus).
+- Worktrees créés pour WT1/WT2 à nettoyer : `git worktree remove ../sb-erp154-upload ../sb-erp153-rbac`.
+- Garder les MR basses propres ; merger dans l'ordre.
+
+## Suivi (tenu par la conv maître)
+
+| WT | Ticket | ERP | État | PR | Notes |
+|----|--------|-----|------|----|----|
+| WT1 | 1.2 upload | 154 | ✅ MERGÉ | #108 | migration `Version20260615130000` |
+| WT2 | 1.1 RBAC | 153 | ✅ PR ouverte | #111 | bas de pile (cible develop) |
+| WT3 | 1.3+1.5 | 155+157 | ▶️ À LANCER | — | stack sur `feat/erp-153-rbac` ; gate contrat front |
+| WT4 | 1.6 proc | 158 | ⛔ bloqué par WT3 | — | |
+| WT5 | 1.4 qualimat | 156 | ⛔ bloqué par WT2+ERP-39 | — | |
+| WT6 | 1.7 adresses | 159 | ⛔ bloqué par WT3 | — | |
+| WT7 | 1.8 contacts | 160 | ⛔ bloqué par WT3 | — | |
+| WT8 | 1.9 prix | 161 | ⛔ bloqué par WT3 | — | |
+| WT9 | 1.10 export | 162 | ⛔ bloqué par WT3 | — | |
+| WT10 | 1.11 tests | 163 | ⛔ bloqué par tout | — | |
+
+## Cadre commun à tous les prompts (rappels projet)
+
+- Carrier vit dans `src/Module/Transport/` (créé par ERP-150). **Miroir = `src/Module/Commercial/`** (Supplier).
+- Tests sous `tests/Module/Transport/Api/` (miroir `tests/Module/Commercial/Api/`).
+- `declare(strict_types=1);` partout ; commentaires **FR**, code EN.
+- `make test` + `make php-cs-fixer-allow-risky` avant de dire « fini ».
+- Ne jamais mentionner Claude/IA dans commit/PR.

docs/specs/M4-transporteurs/prompts/WT1-upload.md

@@ -0,0 +1,44 @@
+# WT1 — Infra upload générique `Shared` (ticket 1.2 / ERP-154)
+
+> Créer le worktree puis lancer Claude dedans :
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp154-upload -b feat/erp-154-upload origin/develop
+> cd ../sb-erp154-upload && claude
+> ```
+> **Base** : `origin/develop` (aucune dépendance — peut démarrer tout de suite, même avant le merge du socle Transport).
+
+---
+
+## Prompt à coller
+
+Tu travailles sur le projet Starseed (modular monolith DDD, Symfony 8 / API Platform 4). Lis `CLAUDE.md` et `.claude/rules/backend.md` avant de coder. Charge le skill `backend-entity-conventions`.
+
+**Mission** : poser une infra d'upload de fichiers **générique et réutilisable** dans `src/Shared/` (la « Décharge » du M4 en sera le 1er consommateur, mais ce ticket ne touche PAS au module Transport).
+
+**Spec** : `docs/specs/M4-transporteurs/spec-back.md § 2.7`.
+
+**À livrer** :
+1. Table `uploaded_document` (migration namespace racine `DoctrineMigrations` dans `migrations/`, postérieure à la dernière présente — vérifie `ls migrations/`). Colonnes : `id`, `original_filename`, `stored_path`, `mime_type`, `size_bytes`, `checksum`, `created_at`, `created_by`.
+2. Service `Shared\Infrastructure\Upload\FileUploader` :
+   - validation MIME **server-side via `$file->getMimeType()`** (JAMAIS `getClientMimeType()`),
+   - whitelist MIME explicite (PDF + images),
+   - bornage taille, checksum sha256, écriture disque `var/uploads/{yyyy}/{mm}/`.
+3. Endpoint `POST /api/uploaded_documents` (multipart) → renvoie l'IRI. MIME hors whitelist → **422**.
+
+**Gardes-fous (cassent `make test` sinon)** :
+- **`COMMENT ON COLUMN` sur TOUTES les colonnes** de `uploaded_document` (FR, ≤200 car., règle n°12) ET ajoute le bloc `'uploaded_document' => [...]` dans `src/Shared/Infrastructure/Database/ColumnCommentsCatalog.php` — sinon `make test-db-setup` drope les COMMENT et `ColumnsHaveSqlCommentTest` casse.
+- Pagination : si tu exposes une `GetCollection`, elle reste paginée (`CollectionsArePaginatedTest`).
+
+**Scope STRICT** : uniquement `src/Shared/` + migration + catalog. Ne crée AUCUN fichier sous `src/Module/Transport/`. Pas d'antivirus/S3/purge (hors périmètre, § 9).
+
+**Tests à écrire** (PHPUnit) : MIME hors whitelist → 422 ; MIME valide → IRI + ligne persistée + checksum calculé.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky` propre. Commit (`--no-verify` OK si `make test` déjà vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-154-upload
+tea pr create --base develop --head feat/erp-154-upload \
+  --title "feat(shared) : infra upload générique (ERP-154)" \
+  --description "Table uploaded_document + FileUploader + endpoint POST. Ticket ERP-154."
+```
+Puis labellise la PR via l'API Gitea (tea ne pose pas les labels en CLI). Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT10-tests.md

@@ -0,0 +1,37 @@
+# WT10 — Tests PHPUnit + fixtures + contrat JSON (ticket 1.11 / ERP-163)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp163-tests -b feat/erp-163-carrier-tests origin/develop
+> cd ../sb-erp163-tests && claude
+> ```
+> **Base** : `origin/develop` **après merge de TOUS les worktrees back** (WT1→WT9). C'est le filet final.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`, `.claude/rules/testing.md`. Charge le skill `backend-entity-conventions`. **Miroir** : `tests/Module/Commercial/Api/Supplier*Test.php`.
+
+**Mission** : couverture complète des RG + capture du contrat de sérialisation + fixtures consolidées. C'est le DoD back avant intégration front.
+
+**Spec** : `spec-back.md § 4.0.bis / 8.1 / 8.4`.
+
+**À livrer** :
+- Matrice **RG-4.01→4.14** couverte (§ 8.1) + RBAC par rôle (Compta/Usine → 403, Commerciale → 403 sur write, Admin → archive).
+- `CarrierSerializationContractTest` : capture JSON réel **liste + détail** ; `prices[].client`/`.supplier`/sites **embarqués** (pas IRI) ; `qualimatCarrier` embarqué ; `isArchived` présent. Colle les JSON dans `spec-back.md § 4.0.bis`.
+- Anti-N+1 liste ; pagination Hydra ; audit (`entity_type='Carrier'`) ; `AuditableEntitiesHaveI18nLabelTest` vert.
+- **`CarrierFixtures` idempotent (§ 8.4)** — c'est ICI que les fixtures complètes vivent : transporteur QUALIMAT (validité passée → RG-4.04), AUTRE+décharge, affrété, LIOT, complet (contacts/adresses/prix CLIENT+FOURNISSEUR), 1 archivé.
+
+**Piège CI (mémoire projet)** : la CI tourne `APP_DEBUG=0`. Les tests de **comptage de requêtes (anti-N+1)** passent en local mais cassent en CI (DoctrineDataHolder absent) → vérifie/active `profiling: true` dans la config Doctrine de l'environnement `test`. Sans ça le test anti-N+1 sera rouge en CI.
+
+**Scope** : tests + `CarrierFixtures` + remplissage § 4.0.bis. Tu peux ajuster un test cassé hérité d'un autre WT mais signale-le à la conv maître (ne masque pas un vrai bug).
+
+**Fini quand** : `make test` **intégralement vert** + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-163-carrier-tests
+tea pr create --base develop --head feat/erp-163-carrier-tests \
+  --title "test(transport) : couverture RG-4.01→4.14 + contrat + fixtures (ERP-163)" \
+  --description "Matrice RG + CarrierSerializationContractTest + CarrierFixtures + § 4.0.bis. Ticket ERP-163."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT2-rbac.md

@@ -0,0 +1,45 @@
+# WT2 — Permissions `transport.carriers.*` + sidebar (ticket 1.1 / ERP-153)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp153-rbac -b feat/erp-153-rbac origin/develop
+> cd ../sb-erp153-rbac && claude
+> ```
+> **Base** : `origin/develop` **après merge d'ERP-150** (le module `Transport` doit exister). Vérifie : `ls src/Module/Transport/`.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (modular monolith DDD). Lis `CLAUDE.md`, `.claude/rules/architecture.md` et `.claude/rules/testing.md` avant de coder.
+
+**Mission** : poser le socle RBAC du module Transport et son entrée de menu. `TransportModule::permissions()` renvoie `[]` aujourd'hui.
+
+**Spec** : `spec-back.md § 5` + `spec-front.md § Accès`.
+
+**À livrer** :
+1. `TransportModule::permissions()` déclare `transport.carriers.view`, `transport.carriers.manage`, `transport.carriers.archive`. `app:sync-permissions` les enregistre.
+2. **Matrice § 5.2** : Admin (view+manage+archive), Bureau (view+manage), Commerciale (view), Compta + Usine (**aucune**).
+3. **RÈGLE ABSOLUE n°8 — les 3 sources RBAC dans le MÊME commit** :
+   - `config/sidebar.php` : section « Transport » + item `/carriers` + `permission: transport.carriers.view`,
+   - `frontend/tests/e2e/_fixtures/personas.ts` : ajuster `permissions` + `expectedAdminLinks` des personas existants,
+   - `src/Module/Core/Infrastructure/Console/SeedE2ECommand.php` : miroir back des mêmes personas.
+4. Item sidebar masqué pour Compta/Usine ; visible Admin/Bureau/Commerciale.
+
+**Pièges** :
+- Ne touche QUE le RBAC/sidebar — pas d'entité, pas de migration.
+- Toute modif d'une seule des 3 sources sans les 2 autres = drift / test cassé.
+- Section « Transport » vs « Logistique » : prends « Transport » (cosmétique, alignable plus tard).
+
+**Tests à écrire/vérifier** : `app:sync-permissions` OK ; cohérence personas (pas de drift). Lance `make test`.
+
+**Scope STRICT** : RBAC + sidebar + 3 miroirs. Rien d'autre.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si test vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-153-rbac
+tea pr create --base develop --head feat/erp-153-rbac \
+  --title "feat(transport) : permissions carriers + sidebar (ERP-153)" \
+  --description "RBAC transport.carriers.* + 3 sources RBAC alignées. Ticket ERP-153."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT3-migration-entites.md

@@ -0,0 +1,54 @@
+# WT3 ⭐ — Migration + entités Carrier* + ApiResource + Provider (tickets 1.3 + 1.5 / ERP-155 + ERP-157)
+
+> **Worktree pivot : il livre le CONTRAT JSON qui débloque tout le front.**
+> **Mode STACK, sans worktree** (repo principal) — base = branche de WT2 :
+> ```bash
+> cd /home/matthieu/dev_malio/Starseed && git fetch origin
+> git checkout -b feat/erp-155-carrier-schema-entities origin/feat/erp-153-rbac
+> ```
+> **Base** : `feat/erp-153-rbac` (contient ERP-150 + WT1 + RBAC WT2). Quand #111 sera mergé dans develop, la PR de WT3 se recible automatiquement sur develop.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (modular monolith DDD, Symfony 8 / API Platform 4). Lis `CLAUDE.md`, `.claude/rules/backend.md`, `.claude/rules/architecture.md`. **Charge le skill `backend-entity-conventions`** (patterns entités/migrations complets).
+
+**Mission** : créer le schéma BDD du répertoire transporteurs + les entités + le contrat de lecture (liste + détail). Tu poses le contrat JSON sur lequel le front s'appuiera — c'est le livrable critique.
+
+**Spec** : `spec-back.md § 3.2 / 3.3 / 3.4 / 4.0 / 4.1 / 4.2`. **Miroir = le module Supplier** : `src/Module/Commercial/Domain/Entity/Supplier*.php`, `…/Infrastructure/ApiPlatform/State/Provider/SupplierProvider.php`, `…/Serializer/SupplierReadGroupContextBuilder.php`. Carrier vit dans `src/Module/Transport/`.
+
+### Étape A — Migration (`migrations/`, namespace racine `DoctrineMigrations`)
+- **PAS de migration modulaire** : même si la spec dit « modulaire », toute migration va dans `migrations/` namespace racine (tri FQCN cassant sinon). Postérieure à la dernière présente — vérifie `ls migrations/` (à ce jour `Version20260615120000`).
+- Tables `carrier`, `carrier_address`, `carrier_contact`, `carrier_price` + FK : `qualimat_carrier`, `uploaded_document`, `client`, `client_address`, `supplier`, `supplier_address`, `site`, `user`.
+- `certification_type` **nullable** (null en cas LIOT) + CHECK enum ; CHECK sur `container_type`, `direction`, `pricing_unit`, `price_state`, branches Prix client/fournisseur.
+- Index partiel `uq_carrier_name_active` : `LOWER(name)` WHERE non archivé ET non supprimé.
+- **`COMMENT ON COLUMN` sur TOUTES les colonnes** (FR, ≤200 car.) + helper standard pour les 4 colonnes Timestampable/Blamable. Bonus `COMMENT ON TABLE`.
+
+### Étape B — Entités + repos
+- `Carrier`, `CarrierAddress`, `CarrierContact`, `CarrierPrice` : `#[Auditable]`, `implements TimestampableInterface, BlamableInterface` + `use TimestampableBlamableTrait`. Repos `*RepositoryInterface` (Domain) + `Doctrine*Repository` (Infrastructure).
+- `ApiResource` Carrier (attribut sur l'entité, comme Supplier) : `GetCollection` + `Get` + `Post` + `Patch` avec `security` (§ 3.3). **PAS de Delete**.
+- Groupes : `carrier:read`, `carrier:item:read`, `qualimat:read`. **Embed au détail** (pas IRI) : `client:read`/`client_address:read`/`supplier:read`/`supplier_address:read`/`site:read` + `qualimatCarrier`. ⚠ les adresses de l'onglet Prix sont des `ClientAddress`/`SupplierAddress` distinctes.
+- `CarrierProvider` paginé (`ApiPlatform\Doctrine\Orm\Paginator`), liste **sans cloisonnement site** (§ 2.3), **anti-N+1** (fetch joins, § 2.11), exclut les archivés par défaut + `?includeArchived=true`.
+- Piège booléen : `#[SerializedName('isArchived')]` sur le getter.
+
+### Gardes-fous qui CASSENT `make test` (à traiter dans CE worktree)
+- `ColumnsHaveSqlCommentTest` → COMMENT partout **+ ajouter les blocs `carrier`, `carrier_address`, `carrier_contact`, `carrier_price` dans `src/Shared/Infrastructure/Database/ColumnCommentsCatalog.php`** (sinon `test-db-setup` drope les COMMENT).
+- `makefile test-db-setup` : l'index partiel `uq_carrier_name_active` n'est PAS exprimé par `schema:update` → **ajoute-le à la ligne `dbal:run-sql` du target `test-db-setup`** du `makefile`, sinon `make test` casse.
+- `AuditableEntitiesHaveI18nLabelTest` → ajoute dans `frontend/i18n/locales/fr.json` les clés `audit.entity.transport_carrier`, `transport_carrieraddress`, `transport_carriercontact`, `transport_carrierprice` (clé = strtolower(module)+'_'+strtolower(Entity)).
+- `EntitiesAreTimestampableBlamableTest`, `EntityConstraintsHaveFrenchMessageTest` (messages FR + `Length.max` = longueur colonne), `CollectionsArePaginatedTest`.
+
+**Scope STRICT** : schéma + entités + ApiResource lecture + Provider + i18n audit. **PAS** le Processor d'écriture (→ WT4), **PAS** les sous-ressources POST/PATCH adresses/contacts/prix (→ WT6/7/8), **PAS** l'export (→ WT9). Mets un `CarrierFixtures` **minimal** (1-2 lignes) juste pour faire tourner tes tests de lecture ; les fixtures complètes sont faites par WT10 — n'y investis pas.
+
+**Tests à écrire** : liste exclut archivés / `?includeArchived=true` ; enveloppe Hydra (`member`/`totalItems`) ; `isArchived` présent dans le JSON ; embeds détail présents (pas IRI).
+
+**LIVRABLE GATE** : une fois vert, **capture le JSON réel liste + détail** (`curl` ou test) et colle-le dans `spec-back.md § 4.0.bis`. C'est le signal pour démarrer le front. Préviens la conv maître.
+
+**Fini quand** : `make db-reset` OK + `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si test vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-155-carrier-schema-entities
+tea pr create --base feat/erp-153-rbac --head feat/erp-155-carrier-schema-entities \
+  --title "feat(transport) : schéma + entités Carrier + contrat lecture (ERP-155/157)" \
+  --description "Migration + entités Carrier* + ApiResource lecture + Provider + i18n audit + contrat JSON. Tickets ERP-155, ERP-157."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT4-processor.md

@@ -0,0 +1,41 @@
+# WT4 — CarrierProcessor (ticket 1.6 / ERP-158)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp158-processor -b feat/erp-158-carrier-processor origin/develop
+> cd ../sb-erp158-processor && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT3** (entités Carrier) **et WT1** (upload, pour la décharge).
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. Charge le skill `backend-entity-conventions`.
+
+**Mission** : logique d'écriture du formulaire principal Carrier (POST/PATCH) — normalisation, champs conditionnels, archivage. **Miroir** : `src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/SupplierProcessor.php` + `Application/Service/SupplierFieldNormalizer.php`.
+
+**Spec** : `spec-back.md § 4.3 / 4.4 / 7`.
+
+**Règles métier à implémenter (un test PHPUnit par RG)** :
+- **RG-4.01** : POST avec `qualimatCarrier` → `certificationType=QUALIMAT` + FK persistée ; cas LIOT (`name='LIOT'`) ⇒ `certificationType` non requis, `liotPlates` accepté.
+- **RG-4.02** : `certificationType='AUTRE'` sans `dischargeDocument` → **422** (`#[Assert\Callback]`).
+- **RG-4.03** : `isChartered=true` sans `indexationRate` / `containerType` / `volumeM3` → **422**.
+- **RG-4.13** : normalisation via `CarrierFieldNormalizer` (miroir Supplier) — `name` UPPER, contacts Capitalize, phones digits-only, email lower, `liotPlates` (`;`-split/trim/UPPER).
+- **RG-4.12** : doublon `name` (parmi actifs) → **409** + `setError` ciblé.
+- **RG-4.14** : PATCH `isArchived` exige `transport.carriers.archive` (Admin) ; mode strict → 403 sinon.
+
+**Pièges** :
+- Messages de validation **FR explicites** sur chaque contrainte (`EntityConstraintsHaveFrenchMessageTest`).
+- Le back renvoie **toutes** les violations d'un coup avec `propertyPath` aligné sur les champs front.
+
+**Scope STRICT** : `CarrierProcessor` + `CarrierFieldNormalizer` + contraintes sur l'entité `Carrier` (formulaire principal). **NE TOUCHE PAS** : les sous-ressources adresses/contacts/prix (WT6/7/8), `CarrierFixtures` (WT10), l'export (WT9). Ajoute tes contraintes sur `Carrier` sans réécrire l'ApiResource posée par WT3.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-158-carrier-processor
+tea pr create --base develop --head feat/erp-158-carrier-processor \
+  --title "feat(transport) : CarrierProcessor (RG-4.01→4.03/4.12→4.14) (ERP-158)" \
+  --description "Normalisation + champs conditionnels + archive. Ticket ERP-158."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT5-qualimat.md

@@ -0,0 +1,37 @@
+# WT5 — Endpoint QualimatCarrier lecture seule (ticket 1.4 / ERP-156)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp156-qualimat -b feat/erp-156-qualimat-search origin/develop
+> cd ../sb-erp156-qualimat && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT2** (permission `transport.carriers.view`) **et ERP-39** (table `qualimat_carrier` peuplée). **Indépendant de WT3** — peut tourner en parallèle.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. Charge le skill `backend-entity-conventions`.
+
+**Mission** : exposer le référentiel QUALIMAT (table existante `qualimat_carrier`, alimentée par console) en **lecture seule** + endpoint de recherche pour la saisie assistée du nom (RG-4.01). **Ne touche pas** la commande de sync.
+
+**Spec** : `spec-back.md § 4.7` + RG-4.01.
+
+**À livrer** :
+1. Entité `QualimatCarrier` (lecture seule) mappée sur la table existante `qualimat_carrier`. **Aucune écriture exposée** (pas de Post/Patch/Delete). Probablement pas `#[Auditable]` ni Timestampable (référentiel externe synchronisé) — vérifie le mapping existant.
+2. `GET /api/qualimat_carriers?search=` : fuzzy sur `name` (+ `siret`), **seulement `is_active = true`**, tri `name`, **paginé** (règle n°13 — `CollectionsArePaginatedTest`).
+3. **Security** `is_granted('transport.carriers.view')`.
+4. Champs exposés : `id, siret, name, address, postalCode, city, phone, department, status, validityDate, isActive`.
+
+**Tests à écrire** : recherche ne renvoie que les actifs ; pagination Hydra ; 403 sans permission ; tri `name`.
+
+**Scope STRICT** : uniquement l'exposition lecture de `qualimat_carrier`. Ne crée rien autour de `Carrier` (autres worktrees). Si la table n'a pas de COMMENT (référentiel pré-existant), vérifie si elle est dans `EXCLUDED_TABLES` de `ColumnsHaveSqlCommentTest` — ne casse pas ce test.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-156-qualimat-search
+tea pr create --base develop --head feat/erp-156-qualimat-search \
+  --title "feat(transport) : endpoint recherche QualimatCarrier (ERP-156)" \
+  --description "Entité lecture seule + GET /api/qualimat_carriers?search=. Ticket ERP-156."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT6-adresses.md

@@ -0,0 +1,37 @@
+# WT6 — Sous-ressource Adresses (ticket 1.7 / ERP-159)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp159-adresses -b feat/erp-159-carrier-addresses origin/develop
+> cd ../sb-erp159-adresses && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT3** (entités `CarrierAddress`). Parallèle à WT5/WT7/WT8/WT9.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. Charge le skill `backend-entity-conventions`. **Miroir** : `SupplierAddressProcessor.php` (`src/Module/Commercial/Infrastructure/ApiPlatform/State/Processor/`).
+
+**Mission** : opérations d'écriture sur les adresses transporteur.
+
+**Spec** : `spec-back.md § 4.5` + RG-4.05→4.07.
+
+**À livrer** :
+- `POST /api/carriers/{id}/addresses`, `PATCH`/`DELETE /api/carrier_addresses/{id}` (security `manage`) — **resource/processor dédiés à `CarrierAddress`**, ne modifie pas l'ApiResource `Carrier`.
+- **RG-4.06** : `postalCode` matche `^[0-9]{4,5}$` (autocomplete ville = front). Message FR.
+- **RG-4.05** : si affrété → adresse obligatoire (Pays/CP/Ville/Adresse) — validation conditionnelle.
+- RG-4.07 (bouton Valider masqué si QUALIMAT) = front ; côté back, accepter le PATCH normalement.
+
+**Tests à écrire** : CP invalide → 422 ; adresse affrété incomplète → 422 ; PATCH/DELETE OK avec `manage`, 403 sans.
+
+**Scope STRICT** : uniquement `CarrierAddress` (resource + processor + tests). **NE TOUCHE PAS** `CarrierFixtures` (WT10), l'entité `Carrier`, les autres sous-ressources. Messages de validation FR (`EntityConstraintsHaveFrenchMessageTest`).
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-159-carrier-addresses
+tea pr create --base develop --head feat/erp-159-carrier-addresses \
+  --title "feat(transport) : sous-ressource adresses transporteur (ERP-159)" \
+  --description "POST/PATCH/DELETE carrier_address + RG-4.05→4.07. Ticket ERP-159."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT7-contacts.md

@@ -0,0 +1,35 @@
+# WT7 — Sous-ressource Contacts (ticket 1.8 / ERP-160)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp160-contacts -b feat/erp-160-carrier-contacts origin/develop
+> cd ../sb-erp160-contacts && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT3**. Parallèle à WT5/WT6/WT8/WT9.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. Charge le skill `backend-entity-conventions`. **Miroir** : `SupplierContactProcessor.php` (`src/Module/Commercial/…/State/Processor/`).
+
+**Mission** : opérations d'écriture sur les contacts transporteur.
+
+**Spec** : `spec-back.md § 4.5` + RG-4.08.
+
+**À livrer** :
+- `POST /api/carriers/{id}/contacts`, `PATCH`/`DELETE /api/carrier_contacts/{id}` (security `manage`) — resource/processor dédiés à `CarrierContact`.
+- **RG-4.08** : bloc valide si **≥ 1 champ rempli** (CHECK `chk_carrier_contact_filled` côté migration WT3 + validation Processor) ; **max 2 téléphones**.
+
+**Tests à écrire** : contact vide → 422 ; 1 champ → 200/201 ; 3ᵉ téléphone → 422.
+
+**Scope STRICT** : uniquement `CarrierContact`. **NE TOUCHE PAS** `CarrierFixtures` (WT10), `Carrier`, les autres sous-ressources. Messages FR. Si le CHECK `chk_carrier_contact_filled` manque (WT3 ne l'a pas posé), valide côté Processor et signale-le à la conv maître.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-160-carrier-contacts
+tea pr create --base develop --head feat/erp-160-carrier-contacts \
+  --title "feat(transport) : sous-ressource contacts transporteur (ERP-160)" \
+  --description "POST/PATCH/DELETE carrier_contact + RG-4.08 (≥1 champ, max 2 tel). Ticket ERP-160."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT8-prix.md

@@ -0,0 +1,39 @@
+# WT8 — Sous-ressource Prix + RG branches (ticket 1.9 / ERP-161)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp161-prix -b feat/erp-161-carrier-prices origin/develop
+> cd ../sb-erp161-prix && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT3**. Parallèle à WT5/WT6/WT7/WT9.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. Charge le skill `backend-entity-conventions`.
+
+**Mission** : opérations d'écriture sur les prix transporteur, avec branches Client / Fournisseur.
+
+**Spec** : `spec-back.md § 4.5 / 7` + RG-4.09→4.11.
+
+**À livrer** :
+- `POST /api/carriers/{id}/prices`, `PATCH`/`DELETE /api/carrier_prices/{id}` (security `manage`) — resource/processor dédiés à `CarrierPrice`.
+- **RG-4.10 (CLIENT)** : `client`, `clientDeliveryAddress`, `departureSite` requis ; `clientDeliveryAddress` **doit appartenir au `client`** → sinon 422.
+- **RG-4.11 (FOURNISSEUR)** : `supplier`, `supplierSupplyAddress`, `deliverySite` requis ; `supplierSupplyAddress` appartient au `supplier` → sinon 422.
+- Communs obligatoires : `containerType`, `pricingUnit`, `price`, `priceState`. CHECK branches respectés.
+
+**Rappels FK** : « Adresse départ/livraison 86/17/82 » = `Site` (FK). Livraison client = `ClientAddress`, appro = `SupplierAddress` (relations ORM partagées — pas de M2M).
+
+**Tests à écrire** : branche CLIENT/FOURNISSEUR incomplète → 422 ; adresse étrangère au client/supplier → 422 ; prix valide → 201.
+
+**Scope STRICT** : uniquement `CarrierPrice`. **NE TOUCHE PAS** `CarrierFixtures` (WT10), `Carrier`, les autres sous-ressources. Messages FR.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-161-carrier-prices
+tea pr create --base develop --head feat/erp-161-carrier-prices \
+  --title "feat(transport) : sous-ressource prix transporteur (ERP-161)" \
+  --description "POST/PATCH/DELETE carrier_price + RG-4.09→4.11 (branches client/fournisseur). Ticket ERP-161."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/prompts/WT9-export.md

@@ -0,0 +1,36 @@
+# WT9 — Export XLSX (ticket 1.10 / ERP-162)
+
+> ```bash
+> git fetch origin
+> git worktree add ../sb-erp162-export -b feat/erp-162-carrier-export origin/develop
+> cd ../sb-erp162-export && claude
+> ```
+> **Base** : `origin/develop` **après merge de WT3** (lecture Carrier). Parallèle à WT5/WT6/WT7/WT8.
+
+---
+
+## Prompt à coller
+
+Projet Starseed (Symfony 8 / API Platform 4, DDD). Lis `CLAUDE.md`, `.claude/rules/backend.md`. **Miroir** : `src/Module/Commercial/Infrastructure/Controller/SupplierExportController.php` (PhpSpreadsheet déjà présent).
+
+**Mission** : export Excel du répertoire et du tableau Prix regroupé.
+
+**Spec** : `spec-back.md § 4.6`.
+
+**À livrer** :
+- `GET /api/carriers/export.xlsx` : transporteurs affichés (**mêmes filtres** que la liste) ; colonnes § 4.6.
+- `GET /api/carriers/{id}/prices/export.xlsx` : tableau Prix regroupé Benne / Fond Mouvant (colonnes docx p.10).
+- **Controllers custom** avec `#[Route(priority: 1)]` (sinon conflit API Platform `{id}`) ; en-tête `Content-Disposition`.
+
+**Tests à écrire** : 200 + en-tête fichier (Content-Disposition + type XLSX) ; respect des filtres.
+
+**Scope STRICT** : controllers d'export + service de génération. **NE TOUCHE PAS** entités, processors, `CarrierFixtures` (WT10). Réutilise le Provider/filtres de WT3 pour la cohérence des données exportées.
+
+**Fini quand** : `make test` vert + `make php-cs-fixer-allow-risky`. Commit (`--no-verify` si vert), puis **ouvre la PR** :
+```bash
+git push -u origin feat/erp-162-carrier-export
+tea pr create --base develop --head feat/erp-162-carrier-export \
+  --title "feat(transport) : export XLSX répertoire + prix (ERP-162)" \
+  --description "GET /api/carriers/export.xlsx + /carriers/{id}/prices/export.xlsx. Ticket ERP-162."
+```
+Puis labellise via l'API Gitea. Cible **develop**. Aucune mention IA.

docs/specs/M4-transporteurs/spec-back.md

@@ -0,0 +1,994 @@
+---
+# === IDENTITÉ ===
+module: M4
+nom: "Répertoire transporteurs"
+ecran: repertoire-transporteurs
+owner_spec: Matthieu
+backup_spec: Tristan
+version: V0.1
+date_redaction: 2026-06-15
+# Historique :
+#   V0.1 (2026-06-15) — Spec back initiale. S'appuie sur le module `Transport` déjà créé
+#     (ERP-150) et sur les référentiels synchronisés `qualimat_carrier` (ERP-39) et
+#     `idtf_product` (ERP-149). Restitution + précisions back du docx fonctionnel
+#     « M4-repertoire-transporteurs-V0 » (validé 27/05/2026) et de la maquette Figma.
+#     Décisions Matthieu (15/06) : lien QUALIMAT = FK + copie éditable ; PAS de cloisonnement
+#     par site ; infra d'upload réutilisable dans `Shared` (plusieurs usages à venir).
+
+# === LIENS ===
+spec_front: ./spec-front.md
+maquette_figma: "https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-45376&p=f&m=dev"
+trace_fonctionnelle: "uploads/M4-repertoire-transporteurs-V0.pdf / .docx (V0, validé 27/05/2026)"
+
+# === LIEN LESSTIME ===
+lesstime_project_id: 6
+lesstime_taskgroup_id: 31   # M4 — Répertoire transporteurs (tickets ERP-153 → ERP-171)
+statut_global: pret_a_dev
+
+# === DÉPENDANCES AMONT ===
+depend_de:
+  - Transport       # module créé (ERP-150) ; référentiels qualimat_carrier (ERP-39) + idtf_product (ERP-149)
+  - Commercial      # Client (M1) + Supplier (M2) + leurs adresses → onglet Prix
+  - Sites           # SitesModule + 3 sites (86 / 17 / 82) — adresses départ/livraison du Prix
+  - Core            # User, Role, Permission, Audit, JWT déjà en place
+  - Shared          # TimestampableBlamableTrait + Subscriber (ERP-52) + NOUVELLE infra upload (§ 2.7)
+---
+
+# Spec back — Module 4 : Répertoire transporteurs
+
+## 1. Contexte
+
+Cette spec **complète et précise** la [spec front V0.1](./spec-front.md) (docx `M4-repertoire-transporteurs-V0`, validé le 27/05/2026) avec tout ce qui touche au back : décisions d'archi, modèle de données, migration, API REST, RBAC, règles de gestion (RG-4.01 → RG-4.11 + précisions back), tests, hors-périmètre.
+
+**Module cible** : module **`Transport`** **déjà créé** (`src/Module/Transport/`, ERP-150). Le M4 lui **ajoute son premier périmètre fonctionnel exposé** : le **répertoire des transporteurs** (entité `Carrier` éditée par l'utilisateur), qui s'appuie sur les **référentiels déjà synchronisés par commandes console** :
+
+- **`qualimat_carrier`** (ERP-39) — transporteurs agréés QUALIMAT, synchro quotidienne depuis qualimat.org. Sert la **saisie assistée** du nom (RG-4.01).
+- **`idtf_product`** (ERP-149) — codes IDTF (régimes de nettoyage). **Pas utilisé par les écrans M4** (référentiel autonome, hors périmètre des écrans transporteurs — cf. § 9).
+
+> **À ce stade `TransportModule::permissions()` renvoie `[]`** (cf. branche `feat/erp-150-module-transport`). Le M4 le remplit (§ 5.1) et expose la première section sidebar du module.
+
+> **RETEX obligatoire** : le M4 réutilise le pattern de sérialisation éprouvé M1/M2/M3 (`spec-back.md` des modules clients/fournisseurs/prestataires). ~80 % des frictions venaient du **contrat de sérialisation** (groupes / sous-ressources / embed), pas du métier. La section § 4.0 applique ce RETEX au M4.
+
+**Dépendances déjà en place sur `develop`** :
+- `Transport` → tables `qualimat_carrier` / `qualimat_sync_log` / `idtf_product` / `idtf_sync_log` (migrations `Version20260612150000` / `Version20260612160000`).
+- `Commercial` → `Client` (M1) + `Supplier` (M2) + leurs adresses (onglet Prix).
+- `Sites` → 3 sites Châtellerault (86) / Saint-Jean (17) / Pommevic (82).
+- `Shared` → `TimestampableBlamableTrait` + `Subscriber` (ERP-52).
+- `Core` → User, Role, Permission, Audit, JWT.
+
+## 2. Décisions d'archi
+
+### 2.1 Entité `Carrier` dans le module `Transport` (pas de nouveau module)
+
+Le répertoire transporteurs vit dans le **module `Transport` existant**. On crée l'entité **`Carrier`** (transporteur saisi par l'utilisateur) + ses sous-collections `CarrierAddress`, `CarrierContact`, `CarrierPrice`, sous `src/Module/Transport/Domain/Entity/`.
+
+**`Carrier` ≠ `qualimat_carrier`** :
+- `qualimat_carrier` est un **référentiel en lecture seule** alimenté par la synchro console (jamais édité par l'utilisateur).
+- `Carrier` est l'**entité métier éditable** du répertoire. Elle **peut** référencer une ligne `qualimat_carrier` (lien QUALIMAT — § 2.5) mais existe aussi pour des transporteurs non-QUALIMAT (GMP+, OVOCOM, compte-propre, LIOT, autre).
+
+**Référentiels cross-module consommés en relation ORM partagée (PAS d'import de logique)** — exactement comme M2/M3 : l'onglet Prix référence `Client` / `Supplier` (module Commercial), leurs adresses, et `Site` (module Sites) via des **relations ORM** (ManyToOne). Ce sont des **données de référence partagées**, pas de la logique inter-module (aucun service/repository d'un autre module appelé). Conforme à la tolérance déjà actée M1/M2/M3 (règle ABSOLUE n°1 vise les dépendances de **logique** métier).
+
+### 2.2 IDs — cohérence avec le référentiel Transport
+
+Les tables référentielles du module Transport utilisent `BIGINT GENERATED BY DEFAULT AS IDENTITY` (cf. `qualimat_carrier`). Les **nouvelles** tables métier M4 (`carrier` et sous-collections) suivent la même convention **`BIGINT GENERATED BY DEFAULT AS IDENTITY`** pour rester homogène **dans le module Transport** (différence assumée vs `INT` des modules M1/M2/M3 — on s'aligne sur le module hôte). Horodatages en `TIMESTAMP(0) WITHOUT TIME ZONE` (le `TimestampableBlamableTrait` mappe `datetime_immutable`).
+
+> **Point de raffinement (non bloquant)** : si l'on préfère l'homogénéité globale Starseed (`INT`), basculer toutes les tables M4 en `INT`. Décision par défaut retenue ici : `BIGINT` (cohérence intra-module Transport). À confirmer au ticket migration.
+
+### 2.3 Pas de cloisonnement par site (DÉCISION Matthieu, 15/06/2026)
+
+> **Décision** : le répertoire transporteurs est un **référentiel global** — **aucun cloisonnement par site** (contrairement au M3 prestataires). Tout rôle autorisé en consultation (Admin / Bureau / Commerciale) voit **tous** les transporteurs. Conforme à la colonne « Consultation = Tout » du docx pour ces rôles.
+
+Conséquence : **pas** de `ProviderSiteScopeExtension`, pas de `currentSite` dans le filtrage, pas de `sites.bypass_scope`. Le `Carrier` **ne porte pas** de relation `sites` au niveau de la fiche (les sites n'apparaissent que dans l'onglet Prix comme **adresse de départ/livraison**, en valeur, pas comme périmètre de visibilité).
+
+### 2.4 Archive vs soft delete — deux mécanismes distincts (identique M1/M2/M3)
+
+| Mécanisme | Colonne | Visibilité défaut | Restauration | Utilisateur |
+|---|---|---|---|---|
+| **Archive** (fonctionnel) | `is_archived` (bool, default false) + `archived_at` | masqué | Oui (toggle UI) | **Admin seul** via `transport.carriers.archive` |
+| **Soft delete** (technique) | `deleted_at` (timestamptz nullable) | masqué | HP | Aucun rôle au M4 (HP) |
+
+Conséquences (miroir M3) :
+- `DELETE /api/carriers/{id}` **non exposé** au M4 (404 si appelé).
+- `GET /api/carriers?includeArchived=true` permet de voir les archivés (permission `transport.carriers.view`).
+- PATCH `{ "isArchived": true }` archive ; PATCH `{ "isArchived": false }` restaure.
+- L'unicité métier ignore les archivés ET les soft-deletés (§ 2.6).
+
+### 2.5 Lien QUALIMAT — FK + copie éditable (DÉCISION Matthieu, 15/06/2026)
+
+> **Décision** : quand l'utilisateur sélectionne un transporteur dans l'onglet QUALIMAT (RG-4.01), on **conserve une FK** `carrier.qualimat_carrier_id` **ET** on **copie** au moment de la sélection : `name`, la certification (`certification_type = QUALIMAT`) et les champs adresse (pays / code postal / ville / voie) dans une `CarrierAddress`. Les champs copiés **restent éditables** et **survivent à une désync QUALIMAT** (FK `ON DELETE SET NULL`).
+
+- `qualimat_carrier_id` : FK nullable vers `qualimat_carrier(id)`, `ON DELETE SET NULL` (si la ligne QUALIMAT disparaît du référentiel, le transporteur du répertoire est conservé, lien rompu proprement).
+- **Pas de FK figée à la migration** vers le référentiel pour les autres champs : on copie les **valeurs** (snapshot éditable). Le lien sert à la traçabilité de la source + au statut/date de validité QUALIMAT affichés (`qualimat_carrier.status` / `validity_date`, RG-4.04).
+- **Certification d'un transporteur QUALIMAT** : `certification_type = 'QUALIMAT'`, **lecture seule** côté front tant que `qualimat_carrier_id` est non nul. Les transporteurs non-QUALIMAT prennent une valeur de la liste `GMP_PLUS` / `OVOCOM` / `COMPTE_PROPRE` / `AUTRE` (RG-4.02).
+- **Modal de confirmation** « Êtes-vous sûr de vouloir intégrer ce transporteur ? » : pur front (RG-4.01 / RG-4.03 du docx) — au back c'est un simple POST/PATCH portant `qualimatCarrier` + les valeurs copiées.
+
+### 2.6 Unicité partielle Postgres — nom de transporteur
+
+> **Décision (alignée M1/M2/M3 § 2.6)** : l'unicité métier porte **uniquement sur le nom** (`carrier.name`). Pas d'unicité sur le SIRET (le référentiel QUALIMAT lui-même a des SIRET parfois incomplets) ni ailleurs.
+
+Index unique partiel (`WHERE is_archived = FALSE AND deleted_at IS NULL`) sur `LOWER(name)`. Doublon → `409 Conflict` géré par le `CarrierProcessor`.
+
+> **Cas LIOT (RG-4.01)** : « LIOT » est un transporteur compte-propre particulier (flotte interne). Le nom `LIOT` reste soumis à l'unicité comme les autres (un seul `Carrier` nommé LIOT actif). Voir § 2.9 pour le comportement de saisie.
+
+### 2.7 Upload de fichiers — infra réutilisable dans `Shared` (DÉCISION Matthieu, 15/06/2026)
+
+Le champ **« Décharge »** (upload, visible si `certification_type = AUTRE` — RG-4.02) est le **premier** d'une **série d'uploads à venir** dans l'ERP (« il va y en avoir pas mal »). On **ne fait donc pas** un upload ad hoc sur `carrier` : on pose une **infra d'upload générique et réutilisable** dans `Shared`.
+
+**Proposition (à câbler au ticket dédié)** :
+- Table `uploaded_document` (module `Shared` / `Core`) : `id`, `original_filename`, `stored_path`, `mime_type`, `size_bytes`, `checksum` (sha256), `created_at`, `created_by`.
+- Service `Shared\Infrastructure\Upload\FileUploader` : valide le MIME **côté serveur via `$file->getMimeType()`** (jamais `getClientMimeType()` — règle ABSOLUE backend), borne la taille, calcule le checksum, écrit sur disque (chemin configurable `%kernel.project_dir%/var/uploads/{yyyy}/{mm}/`), persiste la ligne, retourne l'IRI `/api/uploaded_documents/{id}`.
+- Endpoint `POST /api/uploaded_documents` (multipart, `#[ApiResource]` + Processor dédié) → renvoie l'IRI ; whitelist MIME (PDF + images au minimum pour la décharge).
+- `carrier.discharge_document_id` : FK nullable vers `uploaded_document(id)`, `ON DELETE SET NULL`.
+
+> **Périmètre M4** : livrer l'infra upload **minimale mais générique** (table + service + endpoint + 1 consommateur = la décharge). Les autres consommateurs (pièces jointes contrats, documents fournisseurs, etc.) la **réutiliseront** sans la réécrire. La conception détaillée de l'infra (antivirus, stockage objet S3, purge) est tracée HP-M4-… (§ 9).
+> **Garde-fou MIME** : valider serveur (`$file->getMimeType()`), whitelist explicite, refuser le reste → 422.
+
+### 2.8 Audit & traces temporelles
+
+Pattern Starseed standard, miroir M1/M2/M3 :
+- `#[Auditable]` sur `Carrier`, `CarrierAddress`, `CarrierContact`, `CarrierPrice`.
+- **Tous les champs auditables** (pas de champ sensible type password/token ici → pas d'`#[AuditIgnore]`).
+- Audit des FK (`qualimatCarrier`, `client`, `supplier`, `departureSite`…) tracé automatiquement.
+- **Libellés i18n** (règle ABSOLUE backend — `AuditableEntitiesHaveI18nLabelTest`) : ajouter dans `frontend/i18n/locales/fr.json` (clé = `strtolower(module)` + `_` + `strtolower(Entity)`) :
+  `audit.entity.transport_carrier`, `audit.entity.transport_carrieraddress`, `audit.entity.transport_carriercontact`, `audit.entity.transport_carrierprice`.
+
+### 2.9 Workflow de saisie & champs conditionnels (formulaire principal)
+
+Le **formulaire principal** porte des champs **conditionnels** (RG-4.02 / RG-4.03 / cas LIOT). Le back **ne maintient pas de state machine** : il stocke ce qui est envoyé et **valide la cohérence** au POST/PATCH. Logique :
+
+| Déclencheur | Champs activés / obligatoires | RG |
+|---|---|---|
+| `qualimat_carrier_id` non nul (transporteur QUALIMAT) | `certification_type = QUALIMAT` (lecture seule) ; `name` + adresse copiés | RG-4.01 |
+| `name == 'LIOT'` (cas spécial) | `liot_plates` visible et seul champ pertinent ; les autres champs (certif/affrété/benne/volume) masqués | RG-4.01 |
+| `certification_type == AUTRE` | `discharge_document` (upload Décharge) visible | RG-4.02 |
+| `is_chartered == true` (« Affréter » coché) | `indexation_rate`, `container_type` (Benne/Fond mouvant), `volume_m3` visibles **et obligatoires** | RG-4.03 |
+
+> **Validation incrémentale par onglet (workflow front-driven, identique M2/M3)** : `Carrier` créé en BDD **dès validation du formulaire principal** via `POST /api/carriers`. Onglets suivants (Adresse / Contact / Prix) → **PATCH partiels** / **sous-ressources** avec groupes de sérialisation dédiés :
+> - `carrier:write:main` — formulaire principal (POST + PATCH)
+> - `carrier:write:addresses` — onglet Adresse (sous-ressource `carrier_address`)
+> - `carrier:write:contacts` — onglet Contact (sous-ressource `carrier_contact`)
+> - `carrier:write:prices` — onglet Prix (sous-ressource `carrier_price`)
+> - `carrier:write:archive` — toggle archive (security `transport.carriers.archive`)
+
+### 2.10 Normalisation serveur des entrées texte (identique M1/M2/M3)
+
+`CarrierFieldNormalizer` (miroir `SupplierFieldNormalizer`/`ProviderFieldNormalizer`), service interne appelé par les Processors avant validation :
+
+```php
+final class CarrierFieldNormalizer
+{
+    public function normalizeName(?string $v): ?string        // mb_strtoupper(trim)  → RG-4.12
+    public function normalizePersonName(?string $v): ?string   // mb_convert_case TITLE
+    public function normalizeEmail(?string $v): ?string         // mb_strtolower(trim)
+    public function normalizePhone(?string $v): ?string         // preg_replace('/\D+/', '')
+    public function normalizeLiotPlates(?string $v): ?string    // split ';', trim, UPPER, rejoin '; '
+}
+```
+
+Le formatage `XX XX XX XX XX` (téléphones) est fait à l'affichage front. Le back stocke `0612345678` (chiffres seuls).
+
+### 2.11 Liste : embed + hydratation anti-N+1 (cohérence M1/M2/M3)
+
+La **liste** `GET /api/carriers` **embarque** le minimum nécessaire au datatable (cf. § 4.0) : `name`, `certificationType`, statut/date de validité QUALIMAT (depuis `qualimatCarrier` embarqué, RG-4.04), `updatedAt`. Anti-N+1 : le `DoctrineCarrierRepository` ne fetch-joine PAS les to-many (contacts/adresses/prix) dans la requête de liste ; il fetch-joine au plus `qualimat_carrier` (ManyToOne, sûr). Le contrat de sérialisation (groupes dans le contexte) est posé **une seule fois** sur l'entité.
+
+## 3. Modèle de données
+
+### 3.1 Diagramme
+
+```
+                         +------------------------+        +------------------------+
+                         |   qualimat_carrier     |<--n:1--|   carrier              |
+                         | (référentiel ERP-39,   |  (FK   | id (PK)                |
+                         |  lecture seule)        | nullable| name (UNIQUE actif)   |
+                         +------------------------+ SET NULL)| certification_type    |
+                                                            | is_chartered          |
++------------------------+                                  | indexation_rate       |
+|  uploaded_document     |<--n:1-- discharge_document_id ---| container_type        |
+| (Shared, § 2.7)        |          (FK nullable)           | volume_m3             |
++------------------------+                                  | liot_plates           |
+                                                            | is_archived / deleted |
+   carrier 1:n carrier_address     +---------------------+  +------------------------+
+   carrier 1:n carrier_contact     |   carrier_price     |          | 1:n
+   carrier 1:n carrier_price ------>| direction CLIENT/   |          |
+                                    |          FOURNISSEUR |   +------------------+
+   (Prix → relations ORM partagées) | client_id (M1)      |-->| client (M1)      |
+                                    | client_delivery_addr|   | supplier (M2)    |
+                                    | departure_site_id   |-->| site (Sites)     |
+                                    | supplier_id (M2)    |   | client_address   |
+                                    | supplier_supply_addr|   | supplier_address |
+                                    | delivery_site_id    |   +------------------+
+                                    | container_type      |
+                                    | pricing_unit        |
+                                    | price / price_state |
+                                    +---------------------+
+```
+
+### 3.2 Migration Doctrine — SQL Postgres
+
+Namespace : **`DoctrineMigrations` (racine `migrations/`)** — fichier `migrations/VersionYYYYMMDDHHMMSS.php` (à dater, **postérieur** à `Version20260612160000`).
+
+> **Même justification qu'aux M1/M2/M3** : la migration crée un schéma avec **FK cross-module** (`user`, `client`, `supplier`, `site`, `qualimat_carrier`, `uploaded_document`). Le namespace modulaire casserait l'ordre (`make db-reset`) — exception racine de la règle ABSOLUE n°11.
+
+> **Rappel règle ABSOLUE n°12** : chaque colonne créée DOIT recevoir son `COMMENT ON COLUMN` (FR, ≤ 200 car., sémantique + contrainte/RG). Les 4 colonnes Timestampable/Blamable passent par le helper `addStandardTimestampableBlamableComments`. SQL ci-dessous *illustratif* (style aligné module Transport : `BIGINT GENERATED BY DEFAULT AS IDENTITY`, `TIMESTAMP(0)`).
+
+```sql
+-- =====================================================================
+-- Infra upload générique (Shared) — § 2.7
+-- =====================================================================
+CREATE TABLE uploaded_document (
+    id                BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
+    original_filename VARCHAR(255) NOT NULL,
+    stored_path       VARCHAR(512) NOT NULL,
+    mime_type         VARCHAR(128) NOT NULL,
+    size_bytes        INT NOT NULL,
+    checksum          VARCHAR(64) NOT NULL,
+    created_at        TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    created_by        INT REFERENCES "user"(id) ON DELETE SET NULL
+);
+
+-- =====================================================================
+-- Table principale `carrier` (transporteur du répertoire)
+-- =====================================================================
+CREATE TABLE carrier (
+    id                    BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
+    -- Lien référentiel QUALIMAT (FK + copie éditable — § 2.5)
+    qualimat_carrier_id   BIGINT REFERENCES qualimat_carrier(id) ON DELETE SET NULL,
+    -- Formulaire principal
+    name                  VARCHAR(255) NOT NULL,
+    certification_type    VARCHAR(20),                  -- QUALIMAT|GMP_PLUS|OVOCOM|COMPTE_PROPRE|AUTRE ; null seulement en cas LIOT (RG-4.01). Requis sinon (Processor).
+    is_chartered          BOOLEAN NOT NULL DEFAULT FALSE,  -- « Affréter » (RG-4.03)
+    indexation_rate       NUMERIC(5,2),                 -- % (si affrété — RG-4.03)
+    container_type        VARCHAR(12),                  -- BENNE|FOND_MOUVANT (si affrété — RG-4.03)
+    volume_m3             NUMERIC(10,2),                -- (si affrété — RG-4.03)
+    discharge_document_id BIGINT REFERENCES uploaded_document(id) ON DELETE SET NULL, -- (si AUTRE — RG-4.02)
+    liot_plates           TEXT,                         -- immatriculations LIOT « ; » (cas LIOT — RG-4.01)
+    -- Archive (exposé M4)
+    is_archived           BOOLEAN NOT NULL DEFAULT FALSE,
+    archived_at           TIMESTAMP(0) WITHOUT TIME ZONE,
+    -- Soft delete (préparé, non exposé au M4)
+    deleted_at            TIMESTAMP(0) WITHOUT TIME ZONE,
+    -- Timestampable + Blamable
+    created_at            TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    updated_at            TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    created_by            INT REFERENCES "user"(id) ON DELETE SET NULL,
+    updated_by            INT REFERENCES "user"(id) ON DELETE SET NULL,
+    CONSTRAINT chk_carrier_certification_type
+        CHECK (certification_type IS NULL OR certification_type IN ('QUALIMAT','GMP_PLUS','OVOCOM','COMPTE_PROPRE','AUTRE')),
+    CONSTRAINT chk_carrier_container_type
+        CHECK (container_type IS NULL OR container_type IN ('BENNE','FOND_MOUVANT'))
+);
+CREATE INDEX idx_carrier_is_archived ON carrier(is_archived);
+CREATE INDEX idx_carrier_deleted_at ON carrier(deleted_at);
+CREATE INDEX idx_carrier_qualimat ON carrier(qualimat_carrier_id);
+CREATE INDEX idx_carrier_created_by ON carrier(created_by);
+CREATE INDEX idx_carrier_updated_by ON carrier(updated_by);
+-- Unicité métier (partielle : ignore archives + soft-delete) — nom seul (§ 2.6)
+CREATE UNIQUE INDEX uq_carrier_name_active
+    ON carrier (LOWER(name)) WHERE is_archived = FALSE AND deleted_at IS NULL;
+
+-- =====================================================================
+-- Sous-collection : Adresses (1:n)
+-- =====================================================================
+CREATE TABLE carrier_address (
+    id                BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
+    carrier_id        BIGINT NOT NULL REFERENCES carrier(id) ON DELETE CASCADE,
+    country           VARCHAR(80) NOT NULL DEFAULT 'France',
+    postal_code       VARCHAR(20),
+    city              VARCHAR(120),
+    street            VARCHAR(255),
+    street_complement VARCHAR(255),
+    position          INT NOT NULL DEFAULT 0,
+    created_at        TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    updated_at        TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    created_by        INT REFERENCES "user"(id) ON DELETE SET NULL,
+    updated_by        INT REFERENCES "user"(id) ON DELETE SET NULL
+);
+CREATE INDEX idx_carrier_address_carrier ON carrier_address(carrier_id);
+
+-- =====================================================================
+-- Sous-collection : Contacts (1:n)
+-- =====================================================================
+CREATE TABLE carrier_contact (
+    id              BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
+    carrier_id      BIGINT NOT NULL REFERENCES carrier(id) ON DELETE CASCADE,
+    first_name      VARCHAR(120),
+    last_name       VARCHAR(120),
+    job_title       VARCHAR(120),
+    phone_primary   VARCHAR(20),
+    phone_secondary VARCHAR(20),
+    email           VARCHAR(180),
+    position        INT NOT NULL DEFAULT 0,
+    created_at      TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    updated_at      TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    created_by      INT REFERENCES "user"(id) ON DELETE SET NULL,
+    updated_by      INT REFERENCES "user"(id) ON DELETE SET NULL,
+    -- RG-4.08 : au moins 1 champ rempli (garanti côté Processor ; CHECK = garde-fou minimal)
+    CONSTRAINT chk_carrier_contact_filled
+        CHECK (first_name IS NOT NULL OR last_name IS NOT NULL OR job_title IS NOT NULL
+               OR phone_primary IS NOT NULL OR email IS NOT NULL)
+);
+CREATE INDEX idx_carrier_contact_carrier ON carrier_contact(carrier_id);
+
+-- =====================================================================
+-- Sous-collection : Prix (1:n) — onglet Prix (RG-4.09 → RG-4.11)
+-- =====================================================================
+CREATE TABLE carrier_price (
+    id                        BIGINT GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
+    carrier_id                BIGINT NOT NULL REFERENCES carrier(id) ON DELETE CASCADE,
+    direction                 VARCHAR(12) NOT NULL,        -- CLIENT|FOURNISSEUR (RG-4.09)
+    -- Branche CLIENT (RG-4.10)
+    client_id                 INT REFERENCES client(id) ON DELETE RESTRICT,
+    client_delivery_address_id INT REFERENCES client_address(id) ON DELETE RESTRICT,
+    departure_site_id         INT REFERENCES site(id) ON DELETE RESTRICT,   -- adresse de départ (86/17/82)
+    -- Branche FOURNISSEUR (RG-4.11)
+    supplier_id               INT REFERENCES supplier(id) ON DELETE RESTRICT,
+    supplier_supply_address_id INT REFERENCES supplier_address(id) ON DELETE RESTRICT, -- adresse d'approvisionnement
+    delivery_site_id          INT REFERENCES site(id) ON DELETE RESTRICT,   -- adresse de livraison (86/17/82)
+    -- Commun
+    container_type            VARCHAR(12) NOT NULL,        -- BENNE|FOND_MOUVANT
+    pricing_unit              VARCHAR(8)  NOT NULL,        -- FORFAIT|TONNE
+    price                     NUMERIC(12,2) NOT NULL,
+    price_state               VARCHAR(12) NOT NULL,        -- EN_COURS|VALIDE|NON_VALIDE
+    position                  INT NOT NULL DEFAULT 0,
+    created_at                TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    updated_at                TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL,
+    created_by                INT REFERENCES "user"(id) ON DELETE SET NULL,
+    updated_by                INT REFERENCES "user"(id) ON DELETE SET NULL,
+    CONSTRAINT chk_carrier_price_direction CHECK (direction IN ('CLIENT','FOURNISSEUR')),
+    CONSTRAINT chk_carrier_price_container CHECK (container_type IN ('BENNE','FOND_MOUVANT')),
+    CONSTRAINT chk_carrier_price_unit CHECK (pricing_unit IN ('FORFAIT','TONNE')),
+    CONSTRAINT chk_carrier_price_state CHECK (price_state IN ('EN_COURS','VALIDE','NON_VALIDE')),
+    -- RG-4.10 : si CLIENT, les colonnes client_* sont requises et les supplier_* nulles
+    CONSTRAINT chk_carrier_price_client_branch CHECK (
+        direction <> 'CLIENT' OR (client_id IS NOT NULL AND supplier_id IS NULL)
+    ),
+    -- RG-4.11 : si FOURNISSEUR, les colonnes supplier_* sont requises et les client_* nulles
+    CONSTRAINT chk_carrier_price_supplier_branch CHECK (
+        direction <> 'FOURNISSEUR' OR (supplier_id IS NOT NULL AND client_id IS NULL)
+    )
+);
+CREATE INDEX idx_carrier_price_carrier ON carrier_price(carrier_id);
+CREATE INDEX idx_carrier_price_client ON carrier_price(client_id);
+CREATE INDEX idx_carrier_price_supplier ON carrier_price(supplier_id);
+```
+
+### 3.2.bis Commentaires SQL obligatoires (échantillon)
+
+```php
+$this->addSql("COMMENT ON TABLE carrier IS 'Répertoire transporteurs (M4 Transport) — entités éditables, archivables. Distinct du référentiel qualimat_carrier.'");
+$this->addSql("COMMENT ON COLUMN carrier.name IS 'Raison sociale du transporteur — stockée en MAJUSCULES. Unique parmi non-archivés/non-supprimés (RG-4.12 / § 2.6).'");
+$this->addSql("COMMENT ON COLUMN carrier.qualimat_carrier_id IS 'Lien vers le référentiel QUALIMAT (saisie assistée RG-4.01). FK nullable ON DELETE SET NULL : transporteur conservé si la ligne QUALIMAT disparaît.'");
+$this->addSql("COMMENT ON COLUMN carrier.certification_type IS 'Type de certification : QUALIMAT (si lié, lecture seule) ou GMP_PLUS/OVOCOM/COMPTE_PROPRE/AUTRE. AUTRE déclenche le champ Décharge (RG-4.02).'");
+$this->addSql("COMMENT ON COLUMN carrier.is_chartered IS '« Affréter » coché : déclenche indexation/benne-fond mouvant/volume, obligatoires (RG-4.03).'");
+$this->addSql("COMMENT ON COLUMN carrier.liot_plates IS 'Immatriculations LIOT séparées par « ; » (cas spécial nom=LIOT, RG-4.01). Les autres champs sont masqués dans ce cas.'");
+$this->addSql("COMMENT ON COLUMN carrier_price.direction IS 'Sens du prix : CLIENT ou FOURNISSEUR (RG-4.09). Pilote l''affichage et l''obligation des colonnes client_*/supplier_* (RG-4.10/4.11).'");
+$this->addSql("COMMENT ON COLUMN carrier_price.departure_site_id IS 'Adresse de départ = un des 3 sites (86/17/82). FK -> site.id. Branche CLIENT (RG-4.10).'");
+$this->addSql("COMMENT ON COLUMN carrier_price.price_state IS 'État du prix : EN_COURS, VALIDE ou NON_VALIDE. Affiché dans le tableau Prix (regroupement Benne/Fond mouvant).'");
+// + COMMENT ON COLUMN sur TOUTES les autres colonnes métier (règle n°12)
+$this->addStandardTimestampableBlamableComments($schema, 'carrier');
+$this->addStandardTimestampableBlamableComments($schema, 'carrier_address');
+$this->addStandardTimestampableBlamableComments($schema, 'carrier_contact');
+$this->addStandardTimestampableBlamableComments($schema, 'carrier_price');
+```
+
+### 3.3 Entité `Carrier` — squelette (extrait)
+
+Pattern jumeau de `Supplier`/`Provider` (`#[Auditable]`, `TimestampableBlamableTrait`, sous-collections embarquées au détail). **Chaque propriété affichée porte un read-group** (RETEX M1 maillon (a)).
+
+```php
+<?php
+
+declare(strict_types=1);
+
+namespace App\Module\Transport\Domain\Entity;
+
+use ApiPlatform\Metadata\ApiResource;
+use ApiPlatform\Metadata\Get;
+use ApiPlatform\Metadata\GetCollection;
+use ApiPlatform\Metadata\Patch;
+use ApiPlatform\Metadata\Post;
+use App\Module\Sites\Domain\Entity\Site;             // relation ORM partagée (§ 2.1) — via carrier_price
+use App\Module\Transport\Infrastructure\ApiPlatform\State\Processor\CarrierProcessor;
+use App\Module\Transport\Infrastructure\ApiPlatform\State\Provider\CarrierProvider;
+use App\Module\Transport\Infrastructure\Doctrine\DoctrineCarrierRepository;
+use App\Shared\Domain\Attribute\Auditable;
+use App\Shared\Domain\Contract\BlamableInterface;
+use App\Shared\Domain\Contract\TimestampableInterface;
+use App\Shared\Domain\Trait\TimestampableBlamableTrait;
+use Doctrine\Common\Collections\ArrayCollection;
+use Doctrine\Common\Collections\Collection;
+use Doctrine\ORM\Mapping as ORM;
+use Symfony\Component\Serializer\Attribute\Groups;
+use Symfony\Component\Serializer\Attribute\SerializedName;
+use Symfony\Component\Validator\Constraints as Assert;
+
+#[ApiResource(
+    operations: [
+        new GetCollection(
+            security: "is_granted('transport.carriers.view')",
+            normalizationContext: ['groups' => ['carrier:read', 'qualimat:read', 'default:read']],
+            provider: CarrierProvider::class,
+        ),
+        new Get(
+            security: "is_granted('transport.carriers.view')",
+            normalizationContext: ['groups' => [
+                'carrier:read', 'carrier:item:read', 'qualimat:read',
+                'client:read', 'client_address:read',
+                'supplier:read', 'supplier_address:read',
+                'site:read', 'default:read',
+            ]],
+            provider: CarrierProvider::class,
+        ),
+        new Post(
+            security: "is_granted('transport.carriers.manage')",
+            normalizationContext: ['groups' => ['carrier:read', 'default:read']],
+            denormalizationContext: ['groups' => ['carrier:write:main']],
+            processor: CarrierProcessor::class,
+        ),
+        new Patch(
+            security: "is_granted('transport.carriers.manage')",
+            normalizationContext: ['groups' => ['carrier:read', 'default:read']],
+            denormalizationContext: ['groups' => ['carrier:write:main', 'carrier:write:archive']],
+            provider: CarrierProvider::class,
+            processor: CarrierProcessor::class,
+        ),
+        // Pas de Delete au M4 (HP). Archivage via PATCH { isArchived: true }.
+    ],
+)]
+#[ORM\Entity(repositoryClass: DoctrineCarrierRepository::class)]
+#[ORM\Table(name: 'carrier')]
+#[Auditable]
+class Carrier implements TimestampableInterface, BlamableInterface
+{
+    use TimestampableBlamableTrait;
+
+    #[ORM\Id, ORM\GeneratedValue, ORM\Column(type: 'bigint')]
+    #[Groups(['carrier:read'])]
+    private ?int $id = null;
+
+    #[ORM\Column(length: 255)]
+    #[Assert\NotBlank(message: 'Le nom du transporteur est obligatoire.', normalizer: 'trim')]
+    #[Assert\Length(min: 2, max: 255, normalizer: 'trim')]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $name = null;
+
+    /** Lien référentiel QUALIMAT (saisie assistée RG-4.01). */
+    #[ORM\ManyToOne(targetEntity: QualimatCarrier::class)]
+    #[ORM\JoinColumn(name: 'qualimat_carrier_id', nullable: true, onDelete: 'SET NULL')]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?QualimatCarrier $qualimatCarrier = null;
+
+    #[ORM\Column(length: 20, nullable: true)]
+    #[Assert\Choice(choices: ['QUALIMAT', 'GMP_PLUS', 'OVOCOM', 'COMPTE_PROPRE', 'AUTRE'],
+        message: 'Type de certification invalide.')]
+    // Obligatoire SAUF en cas LIOT (champ masqué) — contrôle conditionnel via #[Assert\Callback] (RG-4.01).
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $certificationType = null;
+
+    #[ORM\Column(options: ['default' => false])]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private bool $isChartered = false;
+
+    #[ORM\Column(type: 'decimal', precision: 5, scale: 2, nullable: true)]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $indexationRate = null;     // % — obligatoire si isChartered (RG-4.03, Callback)
+
+    #[ORM\Column(length: 12, nullable: true)]
+    #[Assert\Choice(choices: ['BENNE', 'FOND_MOUVANT'], message: 'Type de contenant invalide.')]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $containerType = null;       // obligatoire si isChartered (RG-4.03)
+
+    #[ORM\Column(type: 'decimal', precision: 10, scale: 2, nullable: true)]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $volumeM3 = null;            // obligatoire si isChartered (RG-4.03)
+
+    /** Décharge (upload, visible si certificationType = AUTRE — RG-4.02). Infra upload Shared (§ 2.7). */
+    #[ORM\ManyToOne(targetEntity: \App\Shared\Domain\Entity\UploadedDocument::class)]
+    #[ORM\JoinColumn(name: 'discharge_document_id', nullable: true, onDelete: 'SET NULL')]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?UploadedDocument $dischargeDocument = null;
+
+    #[ORM\Column(type: 'text', nullable: true)]
+    #[Groups(['carrier:read', 'carrier:write:main'])]
+    private ?string $liotPlates = null;          // cas LIOT (RG-4.01)
+
+    // === Sous-collections — EMBARQUÉES dans le DÉTAIL ===
+    /** @var Collection<int, CarrierAddress> */
+    #[ORM\OneToMany(mappedBy: 'carrier', targetEntity: CarrierAddress::class, cascade: ['persist', 'remove'], orphanRemoval: true)]
+    #[Groups(['carrier:item:read'])]
+    private Collection $addresses;
+
+    /** @var Collection<int, CarrierContact> */
+    #[ORM\OneToMany(mappedBy: 'carrier', targetEntity: CarrierContact::class, cascade: ['persist', 'remove'], orphanRemoval: true)]
+    #[Groups(['carrier:item:read'])]
+    private Collection $contacts;
+
+    /** @var Collection<int, CarrierPrice> */
+    #[ORM\OneToMany(mappedBy: 'carrier', targetEntity: CarrierPrice::class, cascade: ['persist', 'remove'], orphanRemoval: true)]
+    #[Groups(['carrier:item:read'])]
+    private Collection $prices;
+
+    // === Archive / Soft delete ===
+    #[ORM\Column(name: 'is_archived', options: ['default' => false])]
+    private bool $isArchived = false;
+
+    // ⚠ PIÈGE BOOLÉEN (RETEX M1 bug #3) : #[Groups] + #[SerializedName('isArchived')] SUR LE GETTER.
+    #[Groups(['carrier:read', 'carrier:write:archive'])]
+    #[SerializedName('isArchived')]
+    public function isArchived(): bool
+    {
+        return $this->isArchived;
+    }
+
+    // RG-4.02 / RG-4.03 / cas LIOT : cohérence inter-champs via #[Assert\Callback] (§ 7).
+    // ... archivedAt, getters/setters, __construct (ArrayCollection) ...
+}
+```
+
+### 3.4 Squelettes des autres entités
+
+**`CarrierAddress`** — propriétés dans `['carrier:item:read', 'carrier:write:addresses']` :
+`country`, `postalCode`, `city`, `street`, `streetComplement`, `id`. Saisie assistée BAN (RG-4.06). Pour un transporteur QUALIMAT, une adresse est **pré-remplie depuis la copie** (RG-4.05) et le bouton « Valider » de l'onglet est masqué (RG-4.07).
+
+**`CarrierContact`** — propriétés dans `['carrier:item:read', 'carrier:write:contacts']` :
+`firstName`, `lastName`, `jobTitle`, `phonePrimary`, `phoneSecondary`, `email`, `id`. **Max 2 téléphones** (`phonePrimary` + `phoneSecondary`). RG-4.08 (≥ 1 champ rempli).
+
+**`CarrierPrice`** — propriétés dans `['carrier:item:read', 'carrier:write:prices']` :
+`direction`, `client` (ManyToOne `Client`, embed `client:read`), `clientDeliveryAddress` (ManyToOne `ClientAddress`, embed `client_address:read`), `departureSite` (ManyToOne `Site`, `site:read`), `supplier` (ManyToOne `Supplier`, `supplier:read`), `supplierSupplyAddress` (ManyToOne `SupplierAddress`, embed `supplier_address:read`), `deliverySite` (`site:read`), `containerType`, `pricingUnit`, `price`, `priceState`, `id`. Relations cross-module **embarquées** (maillon (c) — read-groups `client:read`/`client_address:read`/`supplier:read`/`supplier_address:read`/`site:read` dans le contexte du `Get` racine).
+
+**`QualimatCarrier`** (NOUVEAU mapping ORM sur la table existante `qualimat_carrier`) — entité **lecture seule** exposée pour la saisie assistée (§ 4.7). Propriétés sous `qualimat:read` : `id`, `siret`, `name`, `address`, `postalCode`, `city`, `phone`, `department`, `status`, `validityDate`, `isActive`. **Aucune écriture exposée** (alimentée par la commande console `app:qualimat:sync`).
+
+> ⚠ `Client` / `Supplier` / `Site` appartiennent à d'autres modules — on consomme leurs read-groups (`client:read`, `supplier:read`, `site:read`), **pas de logique inter-module** (§ 2.1).
+
+## 4. API REST (API Platform)
+
+### 4.0 Contrat de sérialisation (RETEX M1 — section critique)
+
+> **Leçon M1/M2/M3** : ~80 % des frictions venaient du contrat de sérialisation. Pour **chaque champ affiché** (liste OU détail), les **3 maillons** doivent être prouvés : (a) groupe sur la propriété, (b) groupe dans le `normalizationContext` de l'opération, (c) read-group de l'entité imbriquée présent dans le contexte parent.
+
+**Contexte par opération** :
+
+| Opération | `normalizationContext` (groupes) |
+|---|---|
+| `GetCollection` (liste) | `carrier:read` + `qualimat:read` + `default:read` |
+| `Get` (détail) | `carrier:read` + `carrier:item:read` + `qualimat:read` + `client:read` + `client_address:read` + `supplier:read` + `supplier_address:read` + `site:read` + `default:read` |
+
+**LISTE — champ datatable → maillons** :
+
+| Champ affiché | Propriété (a) | Dans contexte liste (b) | Imbriqué (c) |
+|---|---|---|---|
+| Nom | `name` ∈ `carrier:read` | ✅ | — |
+| Certification | `certificationType` ∈ `carrier:read` | ✅ | — |
+| Date de validité (QUALIMAT) | `qualimatCarrier.validityDate` ∈ `carrier:read` (embed) | ✅ | `qualimat:read` ✅ (RG-4.04) |
+| Dernière activité | `updatedAt` ∈ `carrier:read` | ✅ | — |
+
+**DÉTAIL — bloc → maillons** :
+
+| Bloc / champ | Propriété (a) | Dans contexte détail (b) | Imbriqué (c) |
+|---|---|---|---|
+| Scalaires principaux | `carrier:read` | ✅ | — |
+| `qualimatCarrier` (statut/validité) | `qualimatCarrier` ∈ `carrier:read` | ✅ | `qualimat:read` ✅ |
+| `addresses[]` | `addresses` ∈ `carrier:item:read` | ✅ | propriétés `CarrierAddress` ∈ `carrier:item:read` ✅ |
+| `contacts[]` | `contacts` ∈ `carrier:item:read` | ✅ | propriétés `CarrierContact` ∈ `carrier:item:read` ✅ |
+| `prices[]` (scalaires) | `prices` ∈ `carrier:item:read` | ✅ | propriétés `CarrierPrice` ∈ `carrier:item:read` ✅ |
+| `prices[].client` | `client` ∈ `carrier:item:read` | ✅ | `client:read` ✅ |
+| `prices[].clientDeliveryAddress` | ∈ `carrier:item:read` | ✅ | `client_address:read` ✅ (entité `ClientAddress`) |
+| `prices[].supplier` | `supplier` ∈ `carrier:item:read` | ✅ | `supplier:read` ✅ |
+| `prices[].supplierSupplyAddress` | ∈ `carrier:item:read` | ✅ | `supplier_address:read` ✅ (entité `SupplierAddress`) |
+| `prices[].departureSite` / `.deliverySite` | ∈ `carrier:item:read` | ✅ | `site:read` ✅ |
+
+### 4.0.bis Réponses JSON de référence (DoD — à CAPTURER sur l'API réelle)
+
+> **Definition of Done** (miroir M2/M3) : avant de démarrer les écrans front, **capturer les réponses RÉELLES** via un test PHPUnit (`CarrierSerializationContractTest`, transporteur complet seedé) et les coller ici. Toute donnée affichée par le front DOIT apparaître dans ce JSON. **Ne jamais déclarer un champ « embarqué » sans l'avoir vu dans un JSON réel.**
+>
+> **Pièges hérités à re-tester sur le M4** :
+> 1. `prices[].client` / `.supplier` / `.departureSite` doivent sortir en **objet embarqué**, pas en IRI nu → vérifier les read-groups `client:read`/`supplier:read`/`site:read`.
+> 2. Sérialisation booléen `isArchived` (bug #3 M1) : clé présente dans le JSON réel.
+> 3. `qualimatCarrier` embarqué (statut + validité) pour RG-4.04.
+
+> ✅ **CAPTURÉ (WT3, ERP-155/157)** — JSON réel produit par `CarrierSerializationContractTest` (transporteur complet seedé : lien QUALIMAT, 1 adresse, 1 contact, 2 prix CLIENT + FOURNISSEUR). Les 3 pièges sont vérifiés verts. **Le front peut démarrer sur ce contrat.**
+>
+> Contraintes d'architecture validées au passage :
+> - Relations cross-module des prix (`client`/`supplier`/adresses) câblées **sans import inter-module** (règle n°1) via des contrats `Shared/Domain/Contract/*Interface` + `resolve_target_entities`. L'embed JSON passe par les read-groups des entités concrètes (`client:read`, `client_address:read`, `supplier:read`, `supplier_address:read`, `site:read`). Un groupe `supplier_address:read` a été **ajouté aux champs scalaires de `SupplierAddress`** (M2) pour que `supplierSupplyAddress` s'embarque comme `clientDeliveryAddress` (M1 avait déjà `client_address:read`).
+> - `QualimatCarrier` = mapping ORM **lecture seule** sur la table référentielle existante (sortie du `schema_filter`, mapping aligné au DDL ERP-39 → `schema:update` no-op).
+
+**`GET /api/carriers?search=…` (LISTE)** — enveloppe Hydra AP4 (`member`/`totalItems`/`view` sans préfixe `hydra:`), archivés exclus par défaut (`?includeArchived=true` les réintègre) :
+
+```jsonc
+{
+  "@context": "/api/contexts/Carrier", "@id": "/api/carriers", "@type": "Collection",
+  "totalItems": 1,
+  "member": [
+    {
+      "@id": "/api/carriers/12", "@type": "Carrier", "id": 12,
+      "name": "TRANSPORTS GRELILLIER",
+      "qualimatCarrier": {                       // embarqué (objet), pas IRI — RG-4.04
+        "@id": "/api/qualimat_carriers/8", "@type": "QualimatCarrier", "id": "8",
+        "siret": "…", "name": "…", "address": "…", "postalCode": "86000", "city": "Poitiers",
+        "status": "Valide", "validityDate": "2027-12-31T00:00:00+01:00"
+      },
+      "certificationType": "QUALIMAT",
+      "createdAt": "…", "updatedAt": "…",
+      "isChartered": false,                      // bool présent (getter + SerializedName)
+      "isArchived": false                        // bool présent (piège #3)
+    }
+  ],
+  "view": { "@id": "/api/carriers?search=…", "@type": "PartialCollectionView" }
+}
+```
+
+**`GET /api/carriers/{id}` (DÉTAIL)** — `qualimatCarrier` + `addresses[]` + `contacts[]` + `prices[]` avec relations cross-module embarquées en objet :
+
+```jsonc
+{
+  "@id": "/api/carriers/12", "@type": "Carrier", "id": 12,
+  "name": "TRANSPORTS GRELILLIER",
+  "qualimatCarrier": { "@type": "QualimatCarrier", "status": "Valide", "validityDate": "…", "...": "…" },
+  "certificationType": "QUALIMAT",
+  "addresses": [
+    { "@type": "CarrierAddress", "id": 4, "country": "France", "postalCode": "86000", "city": "Poitiers", "street": "…", "createdAt": "…", "updatedAt": "…" }
+  ],
+  "contacts": [
+    { "@type": "CarrierContact", "id": 5, "firstName": "Marie", "lastName": "Martin", "phonePrimary": "0612345678", "email": "…", "createdAt": "…", "updatedAt": "…" }
+  ],
+  "prices": [
+    {
+      "@type": "CarrierPrice", "id": 7, "direction": "CLIENT",
+      "client": { "@type": "Client", "@id": "/api/clients/4", "id": 4, "companyName": "…", "isArchived": false, "...": "…" },
+      "clientDeliveryAddress": { "@type": "ClientAddress", "@id": "/api/client_addresses/4", "postalCode": "86000", "city": "Poitiers", "street": "…", "...": "…" },
+      "departureSite": { "@type": "Site", "@id": "/api/sites/1", "id": 1, "name": "Chatellerault", "postalCode": "86100", "city": "Châtellerault", "...": "…" },
+      "containerType": "BENNE", "pricingUnit": "TONNE", "price": "42.50", "priceState": "VALIDE",
+      "createdAt": "…", "updatedAt": "…"
+    },
+    {
+      "@type": "CarrierPrice", "id": 8, "direction": "FOURNISSEUR",
+      "supplier": { "@type": "Supplier", "@id": "/api/suppliers/4", "id": 4, "companyName": "…", "isArchived": false, "...": "…" },
+      "supplierSupplyAddress": { "@type": "SupplierAddress", "@id": "/api/supplier_addresses/38", "id": 38, "addressType": "DEPART", "country": "France", "postalCode": "17000", "city": "La Rochelle", "street": "…" },
+      "deliverySite": { "@type": "Site", "@id": "/api/sites/1", "name": "Chatellerault", "...": "…" },
+      "containerType": "FOND_MOUVANT", "pricingUnit": "FORFAIT", "price": "320.00", "priceState": "EN_COURS",
+      "createdAt": "…", "updatedAt": "…"
+    }
+  ],
+  "createdAt": "…", "updatedAt": "…",
+  "isChartered": false, "isArchived": false
+}
+```
+
+> Note WT3 : opérations exposées = `GetCollection` + `Get` (lecture). `POST`/`PATCH` (+ `CarrierProcessor`, normalisation, RG-4.01→4.14, 409 doublon, gating archive) et les sous-ressources d'écriture (adresses/contacts/prix) arrivent aux worktrees suivants (WT4+).
+
+### 4.1 `GET /api/carriers` — Liste
+
+- **Security** : `is_granted('transport.carriers.view')`
+- **Query params** (alimentent le panneau « Filtrer ») :
+  - `includeArchived=true|false` (default `false`)
+  - `certificationType=<code>` (filtre ; répétable)
+  - `search=<text>` (fuzzy sur `name`)
+- **Tri par défaut** : `name ASC`
+- **Pagination** : standard Starseed (règle ABSOLUE n°13) — Hydra, 10/page, `?pagination=false` pour les selects. `CarrierProvider` branché sur `ApiPlatform\Doctrine\Orm\Paginator`.
+- **Pas de cloisonnement par site** (§ 2.3) : tout user `view` voit tous les transporteurs.
+- **Codes** : `200` / `401` / `403`
+
+### 4.2 `GET /api/carriers/{id}` — Détail
+
+- **Security** : `is_granted('transport.carriers.view')`
+- **Comportement** : transporteur + `qualimatCarrier` + `addresses` + `contacts` + `prices` (avec `client`/`supplier`/sites embarqués).
+- **Codes** : `200` / `404` / `401` / `403`
+
+### 4.3 `POST /api/carriers` — Création (formulaire principal)
+
+- **Security** : `is_granted('transport.carriers.manage')`
+- **Body** (groupe `carrier:write:main`) — exemple QUALIMAT :
+```json
+{
+  "name": "TRANSPORTS GRELILLIER",
+  "qualimatCarrier": "/api/qualimat_carriers/142",
+  "certificationType": "QUALIMAT",
+  "isChartered": false
+}
+```
+- **Body** — exemple non-QUALIMAT affrété :
+```json
+{
+  "name": "TRANSPORTS PANDELE",
+  "certificationType": "AUTRE",
+  "isChartered": true,
+  "indexationRate": "5.00",
+  "containerType": "BENNE",
+  "volumeM3": "90.00",
+  "dischargeDocument": "/api/uploaded_documents/12"
+}
+```
+- **Réponse 201** : le transporteur créé avec son `id`. Le front enchaîne les PATCH / sous-ressources par onglet.
+- **Codes** : `201` / `400` / `401` / `403`
+  - `409 Conflict` si doublon de nom (`name` — RG-4.12).
+  - `422` : RG-4.02 (AUTRE sans décharge → obligatoire, voir § 7), RG-4.03 (affrété sans indexation/benne/volume), certification invalide, cas LIOT incohérent.
+
+### 4.4 `PATCH /api/carriers/{id}` — Modification
+
+- **Security base** : `is_granted('transport.carriers.manage')`
+- **Security additionnelle** (dans le `CarrierProcessor`) :
+  - payload contenant `isArchived` → exige `transport.carriers.archive` (Admin seul).
+  - **mode strict** (RG-4.14) : payload mélangeant un champ archive sans la permission → 403 sur tout le payload.
+- **Body** : merge-patch+json, champs modifiés uniquement.
+- **Codes** : `200` / `400` / `401` / `403` / `404` / `409` / `422`
+
+### 4.5 Sous-ressources
+
+**Adresses** : `POST /api/carriers/{id}/addresses`, `PATCH /api/carrier_addresses/{id}`, `DELETE /api/carrier_addresses/{id}`.
+- **Security** : `is_granted('transport.carriers.manage')`
+- RG-4.05 (pré-remplissage QUALIMAT), RG-4.06 (autocomplete BAN), RG-4.07 (pas de validation manuelle si QUALIMAT — front).
+
+**Contacts** : `POST /api/carriers/{id}/contacts`, `PATCH /api/carrier_contacts/{id}`, `DELETE /api/carrier_contacts/{id}`.
+- **Security** : `is_granted('transport.carriers.manage')`
+- RG-4.08 : ≥ 1 champ rempli (CHECK BDD + Processor). Max 2 téléphones.
+
+**Prix** : `POST /api/carriers/{id}/prices`, `PATCH /api/carrier_prices/{id}`, `DELETE /api/carrier_prices/{id}`.
+- **Security** : `is_granted('transport.carriers.manage')`
+- RG-4.09 → RG-4.11 : cohérence branche CLIENT vs FOURNISSEUR (Processor + CHECK). `client_delivery_address` doit appartenir au `client` choisi ; `supplier_supply_address` au `supplier` choisi → sinon 422.
+
+### 4.6 Export
+
+**Répertoire** : `GET /api/carriers/export.xlsx`
+- **Security** : `is_granted('transport.carriers.view')`
+- **Comportement** : XLSX des transporteurs **affichés** (mêmes filtres que la liste, non archivés par défaut).
+- Colonnes : Nom, Certification, Statut QUALIMAT, Date de validité, Affrété, Volume m³, Date de création.
+
+**Onglet Prix** : `GET /api/carriers/{id}/prices/export.xlsx`
+- **Security** : `is_granted('transport.carriers.view')`
+- **Comportement** : le tableau Prix regroupé par type (Fond Mouvant / Benne) — colonnes du docx p.10 : Transporteurs, Adresse APRO ou Adresse Sites, Adresse livraisons, Forfait €, Tonne €, Indexation, État du prix.
+- **Implémentation** : controller custom `CarrierExportController` / `CarrierPriceExportController` avec `#[Route(priority: 1)]` (règle ABSOLUE — conflit API Platform `{id}`). Lib : PhpSpreadsheet (déjà présente).
+- **Réponse 200** : `Content-Disposition: attachment; filename="...-{YYYYMMDD}.xlsx"`
+
+### 4.7 Référentiel QUALIMAT — endpoint de recherche (NOUVEAU, lecture seule)
+
+`GET /api/qualimat_carriers?search=<texte>` — alimente la **saisie assistée** du nom (RG-4.01).
+- **Security** : `is_granted('transport.carriers.view')`
+- **Comportement** : recherche fuzzy sur `name` (+ `siret`), **seulement les lignes actives** (`is_active = true`), triées par `name`. Paginé (règle n°13).
+- **Mapping ORM** : nouvelle entité `QualimatCarrier` (lecture seule) sur la table existante `qualimat_carrier`. **Aucune** opération `Post`/`Patch`/`Delete` (alimentée par `app:qualimat:sync`).
+- Réutilisé aussi par le front pour la copie des champs adresse à la sélection (RG-4.01 / RG-4.05).
+
+### 4.8 Référentiels Prix (réutilisés M1/M2)
+
+`GET /api/clients`, `/api/suppliers`, leurs adresses (`/api/clients/{id}` embarque les adresses, ou endpoint adresses dédié), `GET /api/sites` (3 sites) : **existent déjà** (M1/M2). **Évolution M4** : élargir leur `security` pour autoriser aussi `transport.carriers.manage` (selects de l'onglet Prix), p.ex. `... or is_granted('transport.carriers.manage')`. Pas d'écriture exposée par le M4.
+
+## 5. Autorisation
+
+### 5.1 Déclaration des permissions
+
+Remplir `TransportModule::permissions()` (actuellement `[]`) :
+
+```php
+['code' => 'transport.carriers.view',    'label' => 'Voir les transporteurs'],
+['code' => 'transport.carriers.manage',  'label' => 'Créer / modifier les transporteurs'],
+['code' => 'transport.carriers.archive', 'label' => 'Archiver / restaurer un transporteur'],
+```
+
+Synchronisation : `php bin/console app:sync-permissions`.
+
+### 5.2 Mapping rôles MALIO ↔ permissions (docx « Rôles & permissions »)
+
+| Permission | Admin | Bureau | Compta | Commerciale | Usine |
+|---|---|---|---|---|---|
+| `transport.carriers.view` | ✅ | ✅ | ❌ | ✅ | ❌ |
+| `transport.carriers.manage` | ✅ | ✅ | ❌ | ❌ | ❌ |
+| `transport.carriers.archive` | ✅ | ❌ | ❌ | ❌ | ❌ |
+
+- **Admin** : tout (view + manage + archive).
+- **Bureau** : view + manage (pas d'archive).
+- **Commerciale** : view seul (consultation « Tout », pas de création/modification).
+- **Compta / Usine** : aucun accès au module (ni view ni manage).
+
+### 5.3 Synchronisation RBAC (3 sources OBLIGATOIRES — règle ABSOLUE Starseed n°8)
+
+1. **`config/sidebar.php`** — **nouvelle section « Transport »** (ou rattachement à une section « Logistique » existante — *à confirmer*) + item :
+```php
+[
+    'key'   => 'transport',
+    'label' => 'sidebar.transport.section',
+    'items' => [
+        [
+            'label'      => 'sidebar.transport.carriers',
+            'to'         => '/carriers',
+            'icon'       => 'mdi:truck-outline',
+            'module'     => 'transport',
+            'permission' => 'transport.carriers.view',
+        ],
+    ],
+],
+```
+
+2. **`frontend/tests/e2e/_fixtures/personas.ts`** — étendre les personas existants :
+   - Admin : `view` + `manage` + `archive`
+   - Bureau : `view` + `manage`
+   - Commerciale : `view`
+   - Compta / Usine : **aucune** permission `transport.carriers.*` (vérifier 403)
+
+3. **`src/Module/Core/Infrastructure/Console/SeedE2ECommand.php`** — miroir back des mêmes personas.
+
+> ⚠ Les 3 sources doivent être touchées dans le **même commit** (sinon drift / test cassé).
+
+### 5.4 Vérification front
+
+- `usePermissions()` filtre l'item sidebar (`transport.carriers.view`).
+- Bouton « + Ajouter » / « Modifier » visibles si `transport.carriers.manage`.
+- Bouton « Archiver » visible si `transport.carriers.archive` (Admin seul).
+
+## 6. Audit & dates
+
+- `Carrier`, `CarrierAddress`, `CarrierContact`, `CarrierPrice` : `#[Auditable]`, tous champs audités.
+- Timestampable + Blamable : pattern Shared standard.
+- `QualimatCarrier` / `UploadedDocument` : voir leur propre cycle (référentiel synchro / upload).
+- Libellés i18n `audit.entity.transport_*` (§ 2.8).
+
+## 7. Règles de gestion (RG)
+
+> RG-4.01 → RG-4.11 reprennent le docx source. RG-4.12 → RG-4.14 sont des **précisions back** explicitement marquées.
+
+### Formulaire principal
+
+- **RG-4.01** _(saisie assistée QUALIMAT + cas LIOT)_ : le nom est saisi par l'utilisateur, ce qui déclenche une recherche dans le référentiel QUALIMAT (`GET /api/qualimat_carriers?search=`). Sélection d'un transporteur → modal de confirmation (front) → copie de `name` + `certificationType = QUALIMAT` + adresse (§ 2.5). **FK** `qualimatCarrier` conservée. **Cas non trouvé** : pas QUALIMAT → l'utilisateur choisit une autre certification (RG-4.02). **Cas LIOT (décision Matthieu, 15/06)** : si le nom saisi est exactement `LIOT`, le champ `liotPlates` apparaît (immatriculations séparées par `;`) et **les autres champs sont masqués** (certification, affrètement, décharge…). Conséquences back : (a) `certificationType` n'est **pas requis** en cas LIOT (nullable — le select est masqué) et **reste obligatoire** pour tous les autres cas (contrôle conditionnel `#[Assert\Callback]`) ; (b) `isChartered`/`indexationRate`/`containerType`/`volumeM3`/`dischargeDocument` ignorés/laissés nuls ; (c) le back stocke ce qu'il reçoit, pas de 422 sur la présence résiduelle d'un autre champ (cohérence d'affichage portée par le front).
+- **RG-4.02** _(certification AUTRE → Décharge **obligatoire**)_ : si `certificationType = 'AUTRE'`, le champ Décharge (`dischargeDocument`) **apparaît et est obligatoire**. Validation server-side (`#[Assert\Callback]` dans le `CarrierProcessor`) : `certificationType = 'AUTRE'` et `dischargeDocument IS NULL` → **422** sur `dischargeDocument`. En base, `discharge_document_id` reste **nullable** (null pour les autres certifications) ; c'est la contrainte conditionnelle qui impose le fichier quand AUTRE.
+- **RG-4.03** _(Affréter)_ : si `isChartered = true`, les champs `indexationRate`, `containerType` (Benne/Fond mouvant) et `volumeM3` deviennent **visibles et obligatoires**. Validation server-side (`#[Assert\Callback]`) : `isChartered = true` et l'un des trois `NULL` → **422** sur le champ concerné.
+
+### Onglet Adresse
+
+- **RG-4.04** _(date de validité QUALIMAT)_ : la `validityDate` du `qualimatCarrier` lié, si **antérieure à aujourd'hui**, est affichée **sur fond rouge** (front). Donnée exposée via `qualimatCarrier.validityDate` (§ 4.0).
+- **RG-4.05** _(pré-remplissage QUALIMAT)_ : les champs adresse sont déjà remplis si le transporteur est QUALIMAT (copie § 2.5). Si « Affréter » est coché, l'adresse devient obligatoire (Pays, Code postal, Ville, Adresse). Validation : `Assert\Callback` conditionnelle.
+- **RG-4.06** _(autocomplete BAN)_ : `city` préremplie depuis `postalCode` via l'API **BAN** (api-adresse.data.gouv.fr), appel **direct front** via `useAddressAutocomplete()` (réutilisé M1/M2/M3). Validation serveur : `postalCode` matche `^[0-9]{4,5}$` ; pas de contrôle strict CP/Ville.
+- **RG-4.07** _(pas de validation manuelle si QUALIMAT)_ : le bouton « Valider » de l'onglet Adresse n'apparaît pas pour un transporteur QUALIMAT (adresse remplie automatiquement). Règle **front** ; back accepte le PATCH adresse normalement.
+
+### Onglet Contact
+
+- **RG-4.08** _(bloc Contact valide)_ : un bloc Contact est valide dès qu'**au moins 1 champ** est rempli. CHECK BDD `chk_carrier_contact_filled` (garde-fou). UI : « + Nouveau contact » bloqué tant que le bloc en cours n'a aucun champ rempli. **Max 2 téléphones** par contact.
+
+### Onglet Prix
+
+- **RG-4.09** _(affichage conditionnel)_ : tous les champs masqués par défaut sauf le radio `direction` (Client / Fournisseur), qui déclenche l'affichage des bons champs.
+- **RG-4.10** _(branche CLIENT)_ : si `direction = CLIENT`, les champs `client`, `clientDeliveryAddress` (liste des adresses du client sélectionné), `departureSite` (86/17/82) sont **affichés et obligatoires** ; les champs fournisseur sont masqués/nuls. CHECK `chk_carrier_price_client_branch` + validation Processor (`clientDeliveryAddress` appartient à `client` → sinon 422).
+- **RG-4.11** _(branche FOURNISSEUR)_ : si `direction = FOURNISSEUR`, les champs `supplier`, `supplierSupplyAddress` (adresses du fournisseur), `deliverySite` (86/17/82) sont **affichés et obligatoires** ; les champs client masqués/nuls. CHECK `chk_carrier_price_supplier_branch` + validation Processor (`supplierSupplyAddress` appartient à `supplier`).
+- Champs communs **toujours obligatoires** : `containerType` (Benne/Fond mouvant), `pricingUnit` (Forfait/Tonne), `price` (monnaie), `priceState` (En cours / Validé / Non validé).
+
+### Précisions back
+
+- **RG-4.12** _(unicité nom)_ : `name` unique (case-insensitive) parmi les transporteurs non archivés ET non soft-deletés (index partiel `uq_carrier_name_active`). Doublon → 409 « Un transporteur nommé "{name}" existe déjà. »
+- **RG-4.13** _(normalisation serveur)_ : `name` **UPPERCASE** ; `firstName`/`lastName` (sur `CarrierContact`) **Capitalize** ; téléphones **chiffres uniquement** ; `email` **lowercase** ; `liotPlates` normalisé (`;`-split, trim, UPPER). Formatage à l'affichage front.
+- **RG-4.14** _(archivage + mode strict)_ : PATCH `{ "isArchived": true }` exige `transport.carriers.archive` (**Admin seul**) → `isArchived = true` + `archivedAt = now()`. PATCH `{ "isArchived": false }` restaure (conflit d'unicité de nom → 409). Un PATCH mêlant archive sans permission → 403 sur tout le payload.
+
+## 8. Tests à automatiser
+
+### 8.1 Cas à couvrir (back — PHPUnit)
+
+- [ ] **RG-4.01** : POST avec `qualimatCarrier` → `certificationType=QUALIMAT` accepté + FK persistée ; `GET /api/qualimat_carriers?search=` ne renvoie que les lignes actives
+- [ ] **RG-4.02** : POST `certificationType=AUTRE` sans `dischargeDocument` → 422 ; avec décharge → 201 ; certification ≠ AUTRE sans décharge → 201
+- [ ] **RG-4.03** : POST `isChartered=true` sans `indexationRate`/`containerType`/`volumeM3` → 422 ; complet → 201
+- [ ] **RG-4.05** : POST adresse pour transporteur affrété sans Pays/CP/Ville/Adresse → 422
+- [ ] **RG-4.06** : POST adresse `postalCode` invalide (3 chiffres) → 422 ; CP/ville incohérents → 200
+- [ ] **RG-4.08** : POST contact totalement vide → 422 (CHECK) ; 1 champ rempli → 200 ; 3e téléphone → 422
+- [ ] **RG-4.09/4.10** : POST prix `direction=CLIENT` sans `client`/`clientDeliveryAddress`/`departureSite` → 422 ; `clientDeliveryAddress` n'appartenant pas au `client` → 422 ; complet → 201
+- [ ] **RG-4.11** : POST prix `direction=FOURNISSEUR` symétrique ; `supplierSupplyAddress` étrangère au `supplier` → 422
+- [ ] **RG-4.12** : POST `name` déjà pris → 409 ; même nom après archivage de l'ancien → 201
+- [ ] **RG-4.13** : POST `name="transports x"` → persiste `"TRANSPORTS X"` ; normalisation contact/phone/email ; `liotPlates="ab-123-cd ; ef-456-gh"` normalisé
+- [ ] **RG-4.14** : PATCH isArchived=true par Bureau (sans `archive`) → 403 ; par Admin → 200 + `archivedAt` rempli ; restauration en conflit de nom → 409
+- [ ] **RBAC** : Admin/Bureau/Commerciale/Compta/Usine sur chaque permission (matrice § 5.2) — 200/403 selon le verbe (Compta + Usine : 403 sur view ET manage)
+- [ ] **🔴 Embed relations** : GET détail → `prices[].client`/`.supplier`/`.departureSite`/`.deliverySite` **objets embarqués** (pas IRI nu) ; `qualimatCarrier` embarqué (statut + validité)
+- [ ] **🔴 Sérialisation booléen (bug #3 M1)** : GET détail expose la clé `isArchived`
+- [ ] **Liste / tri** : `GET /api/carriers` exclut archivés par défaut ; `?includeArchived=true` inclut ; tri `name ASC`
+- [ ] **Anti N+1 liste (§ 2.11)** : nombre de requêtes SQL constant
+- [ ] **Export** : XLSX répertoire + XLSX onglet Prix (regroupé Benne/FM) — `Content-Disposition`
+- [ ] **Upload** (§ 2.7) : POST `/api/uploaded_documents` MIME hors whitelist → 422 ; MIME valide → IRI ; validation via `$file->getMimeType()` (pas `getClientMimeType()`)
+- [ ] **Audit** : POST + PATCH + archive → `audit_log` `entity_type='Carrier'`, `changes` correct
+- [ ] **Pagination** (règle n°13) : enveloppe Hydra (`totalItems`/`view`) ; `?pagination=false` renvoie tout (selects)
+- [ ] **Migration** : `make db-reset` → schéma OK ; namespace racine ; index partiel `uq_carrier_name_active` ; **toutes les colonnes ont un `COMMENT ON COLUMN`** (`ColumnsHaveSqlCommentTest` vert)
+- [ ] **i18n audit** : `audit.entity.transport_carrier`… présents (`AuditableEntitiesHaveI18nLabelTest` vert)
+
+### 8.2 Cas à couvrir (front — Vitest)
+
+- [ ] `usePaginatedList({url:'/carriers'})` : exclusion archivés par défaut, envelope Hydra
+- [ ] `useCarrierForm()` : workflow par onglet (validation incrémentale, PATCH partiel) ; champs conditionnels (Affréter, AUTRE→Décharge, LIOT)
+- [ ] Saisie assistée QUALIMAT : recherche → modal → copie nom/certif/adresse + FK
+- [ ] `useAddressAutocomplete()` : réutilisation M1/M2/M3 (nominal + dégradé)
+- [ ] Onglet Prix : bascule Client/Fournisseur (RG-4.09→4.11) ; date de validité fond rouge (RG-4.04)
+- [ ] `useFormErrors` : mapping 422 inline par champ (formulaire principal + blocs)
+- [ ] Permissions : Commerciale en lecture seule (pas de « + Ajouter »/« Modifier ») ; bouton Archiver visible Admin seul
+
+### 8.3 Tests E2E
+
+**Non prévus au M4** (règle ABSOLUE n°7). Extension des personas existants pour les permissions `transport.carriers.*` — cf. § 5.3.
+
+### 8.4 Seed & fixtures démo (RETEX M1 §7 — prévu dès la spec)
+
+`CarrierFixtures` idempotent couvrant les RG :
+- ≥ 1 transporteur **QUALIMAT** (lié à une ligne `qualimat_carrier` seedée, adresse copiée, `validityDate` passée pour tester RG-4.04) ;
+- 1 transporteur **AUTRE + Décharge** (RG-4.02) ; 1 **affrété** (indexation/benne/volume — RG-4.03) ; 1 **LIOT** (immatriculations) ;
+- ≥ 1 transporteur avec **contacts**, **adresses**, et **prix** des deux branches (CLIENT + FOURNISSEUR) ;
+- 1 transporteur **archivé** (exclusion liste + restauration).
+- Réutiliser les comptes de rôles démo (`admin`, `bureau`, `commerciale`, `compta`, `usine`).
+- Le seed QUALIMAT s'appuie sur la commande `app:qualimat:sync` (ou un mini-seed de `qualimat_carrier` en fixture de test, idempotent).
+
+### 8.5 Checklist RETEX (à cocher avant « spec prête »)
+
+- [x] 3 maillons de sérialisation documentés pour chaque champ liste + détail (§ 4.0)
+- [x] Décision embed vs GetCollection explicite (embed détail + sous-ressources write — § 3.3 / § 3.4 / § 4.5)
+- [ ] **Réponses JSON RÉELLES** capturées (§ 4.0.bis) — à produire au ticket tests (`CarrierSerializationContractTest`)
+- [x] Matrice RBAC rôle × permission + mode strict archive (§ 5.2 / RG-4.14)
+- [x] Pagination (n°13), COMMENT ON COLUMN (n°12), Timestampable/Blamable, Audit + i18n, routes à plat : rappelés
+- [x] Réutilisations identifiées (référentiel QUALIMAT, Client/Supplier/Site partagés, `usePaginatedList`, blocs, archive, normalisation, `useAddressAutocomplete`)
+- [x] Seed/fixtures démo planifiés (§ 8.4)
+- [x] **Décisions tranchées (Matthieu, 15/06)** : lien QUALIMAT FK+copie (§ 2.5) ✅ ; pas de cloisonnement site (§ 2.3) ✅ ; infra upload Shared réutilisable (§ 2.7) ✅ ; unicité nom seul (§ 2.6) ✅
+
+## 9. Hors-périmètre (HP)
+
+- **HP-M4-A** : **Exploitation du référentiel IDTF** (`idtf_product`, ERP-149) dans les écrans transporteurs (régimes de nettoyage par marchandise). Synchronisé mais non consommé par le M4.
+- **HP-M4-B** : **Infra upload avancée** — antivirus, stockage objet (S3/MinIO), purge/rétention, prévisualisation. Le M4 livre l'infra **minimale** (§ 2.7).
+- **HP-M4-C** : **DELETE / soft delete d'un transporteur** (colonne `deleted_at` préparée, non exposée).
+- **HP-M4-D** : **Liaison transporteur ↔ tournées / expéditions** (modules logistiques futurs consommant `carrier_id`).
+- **HP-M4-E** : **Historisation des prix** (versionnage des `carrier_price`) — au M4, état simple (En cours/Validé/Non validé).
+- **HP-M4-F** : **Validation stricte SIRET / IBAN** (non applicable ici : pas de comptabilité au M4).
+- **HP-M4-G** : **Export CSV** (XLSX uniquement au M4).
+- **HP-M4-H** : **Onglets « À venir »** non détaillés par le docx → placeholders si présents en maquette.
+
+## 10. Liens & dépendances
+
+### Liens
+
+- Spec front : [`./spec-front.md`](./spec-front.md)
+- Spec M2 fournisseurs (pattern de référence) : [`../M2-suppliers/spec-back.md`](../M2-suppliers/spec-back.md)
+- Spec M3 prestataires (pattern le plus proche) : [`../M3-prestataires/spec-back.md`](../M3-prestataires/spec-back.md)
+- Branches existantes : `feat/erp-150-module-transport` (module) · `feat/erp-39-qualimat-sync` (réf. QUALIMAT) · `feat/erp-149-idtf-sync` (réf. IDTF)
+- BAN api : `https://adresse.data.gouv.fr/api-doc/adresse`
+- Trace fonctionnelle : `M4-repertoire-transporteurs-V0.docx` / `.pdf` (V0, validé 27/05/2026)
+
+### Dépendances amont (déjà en place dans Starseed)
+
+- Module `Transport` : `qualimat_carrier` (réf. QUALIMAT, ERP-39) + `idtf_product` (réf. IDTF, ERP-149) + `TransportModule`
+- Module `Commercial` : `Client` (M1) + `Supplier` (M2) + leurs adresses (onglet Prix, relation ORM partagée)
+- Module `Sites` : `Site` (3 sites 86/17/82) — adresses départ/livraison du Prix
+- Module `Core` : `User`, `Role`, `Permission`, `Audit`, JWT
+- `Shared` : `TimestampableBlamableTrait` + `Subscriber` (+ NOUVELLE infra upload — § 2.7)
+- API Platform 4 + Doctrine ORM + PostgreSQL 16 + PhpSpreadsheet (export)
+
+---
+
+## 📦 Tickets Lesstime (à découper)
+
+**TaskGroup Lesstime** : à créer — `M4 — Répertoire transporteurs` (projet `ERP / Starseed`, projectId=6).
+
+Ordre indicatif (back avant front, migration en tête) :
+0. **Permissions Transport + sidebar** — remplir `TransportModule::permissions()` (3 permissions) + section sidebar « Transport »/« Logistique » + sync 3 sources RBAC.
+1. **Infra upload générique `Shared`** (§ 2.7) — table `uploaded_document` + `FileUploader` (MIME serveur) + endpoint `POST /api/uploaded_documents`.
+2. **Migration BDD M4** (tables `carrier` + sous-collections + index partiel + CHECK + COMMENT ON COLUMN).
+3. **Entité `QualimatCarrier` (lecture seule)** + endpoint `GET /api/qualimat_carriers?search=` (RG-4.01).
+4. **Entités + Repositories** (`Carrier`, `CarrierAddress`, `CarrierContact`, `CarrierPrice`) + hydratation liste (§ 2.11).
+5. **CarrierProvider + CarrierProcessor** (normalisation, archivage, champs conditionnels RG-4.02/4.03, cas LIOT, mode strict).
+6. **Sous-ressources** (Addresses / Contacts / Prices Processors) + validations branches Prix (RG-4.10/4.11).
+7. **Export XLSX** (répertoire + onglet Prix regroupé Benne/FM) — controllers `priority:1`.
+8. **RBAC** : sync 3 sources + tests personas.
+9. **Tests PHPUnit** : matrice RG-4.01 → RG-4.14 (§ 8.1) + capture JSON réel (§ 4.0.bis).
+10. **Front** : page Répertoire (`/carriers`) + `usePaginatedList`.
+11. **Front** : page Ajouter (`/carriers/new`) + formulaire principal + saisie assistée QUALIMAT + champs conditionnels.
+12. **Front** : onglets Adresse (BAN) / Contact / Prix.
+13. **Front** : pages Consultation + Modification.
+14. **i18n + libellés audit** (`audit.entity.transport_*`).
+
+### Actions manuelles dans Lesstime (Matthieu)
+
+1. Créer le TaskGroup `M4 — Répertoire transporteurs` (projet ERP / Starseed, projectId=6).
+2. Créer les tickets ci-dessus avec dépendances séquentielles.
+3. Mettre à jour le frontmatter (`lesstime_taskgroup_id`) avec l'id réel.
+
+### ✅ Décisions tranchées (Matthieu, 15/06/2026)
+
+1. **Modèle Prix** (RG-4.10/4.11, § 3.2) — « Adresse de départ » / « Adresse de livraison » 86/17/82 = les 3 `Site` (FK `site`) ; « Adresse de livraison du client » = `ClientAddress` (M1) ; « Adresse d'approvisionnement » = `SupplierAddress` (M2). ✅
+2. **Lien QUALIMAT** = FK + copie éditable (§ 2.5). ✅
+3. **Pas de cloisonnement par site** (§ 2.3). ✅
+4. **Infra upload réutilisable `Shared`** (§ 2.7). ✅
+5. **Décharge obligatoire côté serveur** (RG-4.02) — si `certificationType=AUTRE` ⇒ `dischargeDocument` requis (422 sinon). ✅
+6. **Certification QUALIMAT** = 5e valeur de l'enum `certification_type`, en **lecture seule** (vient du référentiel), libellé affiché « QUALIMAT ». ✅
+7. **Affrètement** (RG-4.03) — indexation + benne/fond mouvant + volume **obligatoires server-side** si « Affréter » coché (fidèle au docx). ✅
+8. **Cas LIOT** (RG-4.01) — nom = `LIOT` ⇒ champ `liotPlates` seul affiché, autres champs masqués ; `certificationType` **non requis** en cas LIOT (nullable), obligatoire sinon. ✅
+9. **Unicité = nom seul** (§ 2.6). ✅
+
+### ⚠️ Points purement techniques (pas de décision métier — défaut posé)
+
+1. **Type de PK** : `BIGINT` (cohérence module Transport) — modifiable en `INT` si homogénéité globale souhaitée (§ 2.2).
+2. **Section sidebar** : « Transport » dédiée vs « Logistique » (route `/carriers` retenue). Cosmétique.

docs/specs/M4-transporteurs/spec-front.md

@@ -0,0 +1,354 @@
+---
+# === IDENTITÉ ===
+module: M4
+nom: "Répertoire transporteurs"
+ecran: repertoire-transporteurs
+owner_spec: Matthieu
+backup_spec: Tristan
+version: V0.1
+date_redaction: 2026-06-15
+# Historique :
+#   V0.1 (2026-06-15) — Restitution Markdown du docx « M4-repertoire-transporteurs-V0 »
+#     (validé 27/05/2026) + maquette Figma (node 1132-45376). Précisions techniques (back)
+#     dans spec-back.md. Réutilise le pattern et les composants M1/M2/M3.
+
+# === LIENS ===
+maquette_figma: "https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-45376&p=f&m=dev"
+regles_metier: [RG-4.01, RG-4.02, RG-4.03, RG-4.04, RG-4.05, RG-4.06, RG-4.07, RG-4.08, RG-4.09, RG-4.10, RG-4.11]
+roles: [Admin, Bureau, Compta, Commerciale, Usine]
+lien_spec_back: ./spec-back.md
+
+# === VALIDATION CLIENT ===
+client_validation_1:
+  statut: validee
+  date: 2026-05-27
+  version: V0
+  valide_par: "Matthieu (CP MALIO)"
+
+# === LIEN LESSTIME ===
+lesstime_project_id: 6
+lesstime_taskgroup_id: 31   # M4 — Répertoire transporteurs (tickets ERP-153 → ERP-171)
+statut_global: pret_a_dev
+---
+
+# Module 4 — Répertoire transporteurs (V0.1 front)
+
+> **Origine** : spec fonctionnelle `M4-repertoire-transporteurs-V0` (validée le 27/05/2026) + maquette Figma. Restitution Markdown pour intégration au workflow MALIO. Toute décision technique (back) vit dans [`spec-back.md`](./spec-back.md). Le M4 réutilise le pattern et les composants posés aux [M1 clients](../M1-clients/spec-front.md), [M2 fournisseurs](../M2-suppliers/spec-front.md) et [M3 prestataires](../M3-prestataires/spec-front.md).
+
+> **Socle déjà en place** : le module back `Transport` existe (ERP-150) et porte deux référentiels **synchronisés par commandes console** : transporteurs **QUALIMAT** (`qualimat_carrier`, ERP-39) et codes **IDTF** (`idtf_product`, ERP-149). Le M4 ajoute le **répertoire éditable** (`Carrier`) **par-dessus** ces référentiels — la saisie assistée du nom interroge le référentiel QUALIMAT (RG-4.01). L'IDTF n'est **pas** utilisé par ces écrans.
+
+> **Décisions Matthieu (15/06/2026)** : (1) lien QUALIMAT = FK + **copie éditable** des champs (nom / certification / adresse) ; (2) **pas de cloisonnement par site** (référentiel global) ; (3) le champ « Décharge » s'appuie sur une **infra d'upload réutilisable** (`Shared`), car d'autres uploads suivront. Détails : [`spec-back.md § 2.5 / § 2.3 / § 2.7`](./spec-back.md).
+
+## But
+
+Lister tous les transporteurs de l'organisation et accéder rapidement à leurs fiches : consultation, création, modification, archivage. Le nom est **relié à QUALIMAT** (saisie assistée) ; les transporteurs hors QUALIMAT (GMP+, OVOCOM, compte-propre, LIOT, autre) sont saisis manuellement.
+
+## Accès
+
+- **Depuis** : menu principal → section **Transport** (route `/carriers`). *(Section « Transport » dédiée ou rattachement à une section « Logistique » — à confirmer, cf. [`spec-back.md § 5.3`](./spec-back.md).)*
+- **Rôles autorisés** (tableau « Rôles & permissions » du docx) :
+
+| Rôle | Consultation | Ajout / Modification | Archive |
+|---|---|---|---|
+| **Admin** | ✅ Tout | ✅ Tout | ✅ |
+| **Bureau** | ✅ Tout | ✅ Tout | ❌ |
+| **Compta** | ❌ | ❌ | ❌ |
+| **Commerciale** | ✅ Tout | ❌ | ❌ |
+| **Usine** | ❌ | ❌ | ❌ |
+
+> **Notes** :
+> - RBAC transposée sur `transport.carriers.*` (cf. [`spec-back.md § 5`](./spec-back.md)). **Commerciale** = consultation seule (pas de « + Ajouter » ni « Modifier »). **Compta** et **Usine** n'ont **aucun** accès au module (item sidebar masqué).
+> - **Pas de cloisonnement par site** (≠ M3) : tout rôle autorisé voit tous les transporteurs.
+
+## Navigation
+
+Page d'entrée du module **Transport** (route `/carriers`). Titre : « **Répertoire transporteurs** ».
+
+- Affichage principal : un **datatable** listant tous les transporteurs **actifs** (les archivés sont masqués par défaut — filtre dédié).
+- **Clic sur une ligne** → écran **Consultation transporteur** (page dédiée).
+- **Bouton « + Ajouter »** (haut droite, si `manage`) → écran **Ajouter un transporteur**.
+- **Bouton « Filtrer »** (haut droite) → panneau de filtres.
+- **Bouton « Exporter »** (haut droite) → télécharge un **XLSX** des transporteurs **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/M3. Filtres branchés sur les query params de `GET /api/carriers` (cf. [`spec-back.md § 4.1`](./spec-back.md)) :
+
+| Filtre | Composant | Query param back |
+|---|---|---|
+| **Recherche** (nom) | `<MalioInputText>` | `?search=` |
+| **Certification** | `<MalioSelectCheckbox>` (QUALIMAT / GMP+ / OVOCOM / Compte-propre / Autre) | `?certificationType=` |
+| **Inclure les archivés** | `<MalioCheckbox>` | `?includeArchived=true` |
+
+- À l'application des filtres → `setFilters(...)` de `usePaginatedList` (retombe en **page 1**).
+- **État 100 % local** (jamais dans l'URL — règle ABSOLUE n°6).
+
+## Datatable du Répertoire
+
+Composant : `<MalioDataTable>` branché sur `usePaginatedList<Carrier>({ url: '/carriers' })` (règle frontend obligatoire — pagination Hydra, état 100 % local). Colonnes :
+
+| Colonne | Source | Tri |
+|---|---|---|
+| **Nom** | `carrier.name` | ASC par défaut |
+| **Certification** | `carrier.certificationType` (libellé i18n) | Non |
+| **Date de validité** | `carrier.qualimatCarrier.validityDate` (format `JJ-MM-AAAA`) — **fond rouge si < aujourd'hui** (RG-4.04) | Non |
+| **Dernière activité** | `carrier.updatedAt` (format `JJ-MM-AAAA`) | Oui |
+
+> **Clic sur une ligne** → écran Consultation. **Pagination** : standard Starseed 10 / 25 / 50 (défaut 10). Tri serveur `name ASC` par défaut.
+
+## Écran « Ajouter un transporteur »
+
+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. **L'onglet Adresses n'est accessible qu'une fois le formulaire principal validé.** Cf. [`spec-back.md § 2.9`](./spec-back.md) (PATCH partiels par groupe de sérialisation).
+
+**Accès** : bouton « + Ajouter » du Répertoire. **Rôles** : Admin, Bureau.
+
+**Barre d'onglets** : `Qualimat` · `Adresses` · `Contacts` · `Prix`.
+
+### Formulaire principal (pré-onglets)
+
+1er bloc à remplir. Sans validation, les onglets ne sont pas accessibles. Une fois validé → POST `/api/carriers`, puis bascule sur l'onglet Qualimat/Adresses ; les champs passent en readonly.
+
+| Champ | Type composant | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom** (saisie assistée reliée à QUALIMAT) | `<MalioInputText>` (autocomplete) | Oui | RG-4.01 ; RG-4.13 (UPPERCASE serveur) ; RG-4.12 (unicité) |
+| **Liste certification transport** | `<MalioSelect>` (GMP+ / OVOCOM / Compte-propre / Autre) | Oui | RG-4.02 ; auto = `QUALIMAT` (lecture seule) si transporteur QUALIMAT sélectionné |
+| **Affréter** | `<MalioCheckbox>` | Non | RG-4.03 |
+| **Indexation %** | `<MalioInputNumber>` | Conditionnel | RG-4.03 — visible + obligatoire si « Affréter » coché |
+| **Benne / Fond mouvant** | `<MalioRadioButton>` | Conditionnel | RG-4.03 — visible + obligatoire si « Affréter » coché |
+| **Volume m³** | `<MalioInputNumber>` | Conditionnel | RG-4.03 — visible + obligatoire si « Affréter » coché |
+| **Décharge** | `<MalioInputUpload>` *(cf. note)* | Conditionnel (**obligatoire si AUTRE**) | RG-4.02 — visible **et obligatoire** si certification = `AUTRE`. Upload via infra Shared ([`spec-back.md § 2.7`](./spec-back.md)) |
+| **Liste immatriculation LIOT** | `<MalioInputText>` (ou TextArea) | Cas LIOT | RG-4.01 — visible **uniquement** si nom = `LIOT` ; les autres champs disparaissent. Immatriculations séparées par `;` |
+
+> **Comportement RG-4.01 (saisie assistée)** : à la saisie du nom, recherche dans le référentiel QUALIMAT via `GET /api/qualimat_carriers?search=`. Sélection d'un résultat → **modal de confirmation** « Êtes-vous sûr de vouloir intégrer ce transporteur ? ». Si confirmé : le **Nom** et la **certification** (= `QUALIMAT`, lecture seule) se remplissent automatiquement, **ainsi que l'onglet Adresse** (copie pays/CP/ville/voie depuis le référentiel). La FK QUALIMAT est conservée (traçabilité + date de validité RG-4.04).
+> - **Cas transporteur non trouvé** (pas QUALIMAT) : l'utilisateur choisit une autre certification (RG-4.02) → affichage des champs associés.
+> - **Cas LIOT** : si le nom saisi est exactement `LIOT`, seul le champ « Liste immatriculation LIOT » s'affiche, les autres champs sont masqués.
+
+> **Note `<MalioInputUpload>`** : si le composant ne couvre pas le drag & drop / type fichier requis, exception autorisée documentée (`// TODO migrer quand Malio couvre`) — cf. exceptions @.claude/rules/frontend.md.
+
+**Action** : « Valider » (`<MalioButton>`) → POST `/api/carriers` ([`spec-back.md § 4.3`](./spec-back.md)). Succès → onglet « Qualimat » / « Adresses ».
+
+### Onglet « Qualimat »
+
+Sélectionner un transporteur de la liste QUALIMAT afin de mettre à jour les informations du transporteur (saisie assistée — voir RG-4.01).
+
+**Colonnes du tableau de sélection** :
+
+| Colonne | Règle |
+|---|---|
+| **Sélection** (bouton / clic ligne) | RG-4.03 *(docx)* — clic → modal « Êtes-vous sûr de vouloir intégrer ce transporteur ? » → remplit Nom + certification + onglet adresse |
+| **Nom** | — |
+| **Adresse** | — |
+| **Date de validité** | RG-4.04 — **fond rouge si < date du jour** |
+
+> Cet onglet alimente le formulaire principal et l'onglet Adresse par copie (RG-4.01 / RG-4.05). Source : `GET /api/qualimat_carriers?search=` (lecture seule, lignes actives uniquement).
+
+### Onglet « Adresses »
+
+Saisir l'adresse du transporteur (un bloc par adresse).
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Pays** | `<MalioSelect>` (préremplie « France ») | Conditionnel | RG-4.05 |
+| **Code postal** | `<MalioInputText>` (saisie assistée) | Conditionnel | RG-4.06, RG-4.05 — déclenche autocomplete ville (BAN) |
+| **Ville** | `<MalioSelect>` (saisie assistée) | Conditionnel | RG-4.06, RG-4.05 — alimentée par api-adresse.data.gouv.fr |
+| **Adresse** | `<MalioInputText>` (saisie assistée) | Conditionnel | RG-4.05 |
+| **Adresse complémentaire** | `<MalioInputText>` | Non | — |
+
+> **RG-4.05** : les champs sont **déjà remplis** si le transporteur est QUALIMAT (copie). Si « Affréter » est coché, l'adresse devient **obligatoire** (Pays, Code postal, Ville, Adresse).
+> **RG-4.06** : la ville est préremplie automatiquement à partir du code postal via l'API BAN (`useAddressAutocomplete()`, réutilisé M1/M2/M3). Si plusieurs villes → choix dans le select. L'adresse est une saisie assistée basée sur le CP et la ville.
+> **RG-4.07** : le bouton « Valider » **n'apparaît pas** pour un transporteur QUALIMAT (adresse remplie automatiquement).
+
+**Actions** : « Valider » → PATCH `/api/carriers/{id}/addresses` (sauf QUALIMAT, RG-4.07).
+
+### Onglet « Contacts »
+
+Saisir un ou plusieurs contacts associés au transporteur.
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Nom** | `<MalioInputText>` | Non | RG-4.08 + RG-4.13 (Capitalize) |
+| **Prénom** | `<MalioInputText>` | Non | RG-4.08 + RG-4.13 (Capitalize) |
+| **Fonction** | `<MalioInputText>` | Non | RG-4.08 |
+| **Téléphone** (x1, +1 possible, **max 2**) | `<MalioInputText>` | Non | RG-4.08 + RG-4.13 (format) |
+| **Email** | `<MalioInputText>` type email | Non | RG-4.08 + RG-4.13 (lowercase) |
+
+**RG-4.08** : un bloc Contact est valide dès qu'au moins 1 champ est rempli. Impossible d'ajouter un nouveau bloc tant que le précédent n'est pas valide.
+
+**Actions** :
+- « + Nouveau contact » : ajoute un bloc. **Désactivé tant que le bloc précédent n'a aucun champ rempli** (RG-4.08).
+- « Supprimer » (icône) : modal de confirmation, puis suppression du bloc.
+- « Valider » → PATCH `/api/carriers/{id}/contacts`.
+
+### Onglet « Prix »
+
+Saisir un suivi de prix du transporteur (un bloc par prix). Tous les champs sont masqués par défaut sauf le radio « Client / Fournisseur » (RG-4.09).
+
+**Bloc Prix** :
+
+| Champ | Type | Obligatoire | Règle |
+|---|---|---|---|
+| **Client / Fournisseur** | `<MalioRadioButton>` | Oui | RG-4.09 |
+| **Client** | `<MalioSelect>` (liste des clients) | Conditionnel | RG-4.10 — si Client |
+| **Adresse de livraison** | `<MalioSelect>` (adresses du client sélectionné) | Conditionnel | RG-4.10 — si Client |
+| **Adresse de départ** | `<MalioSelect>` (86 / 17 / 82) | Conditionnel | RG-4.10 — si Client ; = un des 3 sites |
+| **Fournisseur** | `<MalioSelect>` (liste des fournisseurs) | Conditionnel | RG-4.11 — si Fournisseur |
+| **Adresse d'approvisionnement** | `<MalioSelect>` (adresses du fournisseur) | Conditionnel | RG-4.11 — si Fournisseur |
+| **Adresse de livraison** | `<MalioSelect>` (86 / 17 / 82) | Conditionnel | RG-4.11 — si Fournisseur ; = un des 3 sites |
+| **Benne / Fond mouvant (FM)** | `<MalioRadioButton>` | Oui | — |
+| **Forfait / Tonne** | `<MalioRadioButton>` | Oui | — |
+| **Prix** | `<MalioInputAmount>` (monnaie) | Oui | — |
+| **État du prix** | `<MalioSelect>` (En cours / Validé / Non validé) | Oui | — |
+
+> **RG-4.10** : si **Client** sélectionné → champs liés au client affichés et obligatoires ; champs fournisseur masqués et non obligatoires.
+> **RG-4.11** : si **Fournisseur** sélectionné → champs liés au fournisseur affichés et obligatoires ; champs client masqués et non obligatoires.
+> **Adresse de départ / livraison « 86 / 17 / 82 »** = les 3 `Site` fixes (cf. switcher de site Châtellerault / Saint-Jean / Pommevic en haut de l'app). La sélection stocke un **ID de Site** ([`spec-back.md § 3.2`](./spec-back.md)).
+
+**Actions** :
+- « + Nouveau prix » : ajoute un bloc. Bloqué tant que le précédent n'est pas valide.
+- « Supprimer » (icône) : modal de confirmation puis suppression.
+- « Valider » → PATCH `/api/carriers/{id}/prices`.
+
+## Écran « Consultation d'un transporteur »
+
+Consulter en **lecture seule** la fiche complète. Affiche en haut du bloc les infos principales du transporteur (comme l'écran d'ajout) ainsi que les onglets Adresses, Contacts, Prix. **Tous les champs sont en lecture seule.**
+
+**Accès** : clic sur une ligne du Répertoire. La page s'ouvre par défaut sur l'onglet **Adresses**. Icône « flèche » à gauche pour revenir au répertoire. Deux boutons à droite :
+- **« Modifier »** (visible si `transport.carriers.manage` → Admin, Bureau).
+- **« Archiver »** (visible **uniquement Admin** via `transport.carriers.archive`) → modal de confirmation, puis PATCH `/api/carriers/{id}` `{ "isArchived": true }`.
+
+> Un transporteur archivé peut être restauré (`isArchived: false`) — bouton « Restaurer » remplace « Archiver » dans la consultation d'un archivé.
+
+### Onglet Adresses (consultation)
+
+Un bloc par adresse du transporteur. Chaque bloc, 5 champs en lecture seule : Pays / Code postal / Ville / Adresse / Adresse complémentaire.
+
+### Onglet Contacts (consultation)
+
+Un bloc par contact. 5 champs en lecture seule : Nom / Prénom / Fonction / Téléphone (x1 ou x2) / Email.
+
+### Onglet Prix (consultation)
+
+Un tableau regroupant les prix par type (**Fond Mouvant / Benne**) :
+
+| Colonne | Description |
+|---|---|
+| **Colonne de regroupement** | « Fond Mouvant » / « Benne » |
+| **Transporteurs** | Nom du transporteur |
+| **Adresse APRO ou Adresse Sites** | Si prix « Client » → Adresse APRO sinon Adresse Sites |
+| **Adresse livraisons** | — |
+| **Forfait €** | Prix |
+| **Tonne €** | Prix |
+| **Indexation** | Pourcentage d'indexation (vide si non rempli) |
+| **État du prix** | Validé / Non Validé / En cours |
+
+**Action** : « Exporter » → exporte le tableau au **format Excel** (`GET /api/carriers/{id}/prices/export.xlsx`).
+
+## Écran « Modification d'un transporteur »
+
+Modifier les informations d'un transporteur existant. **Identique à l'écran « Ajouter un transporteur »** — mêmes formulaires, mêmes règles métier (RG-4.01 à RG-4.11) — sauf :
+- Les champs sont **pré-remplis** avec les valeurs actuelles.
+- **Validation par onglet** : on peut modifier UN onglet sans toucher aux autres (PATCH partiel).
+- **Accès** : depuis l'écran Consultation, bouton « Modifier » (Admin, Bureau).
+
+## Composants UI à utiliser (`@malio/layer-ui`)
+
+- **Datatable** : `<MalioDataTable>` (+ `usePaginatedList`)
+- **Input texte** : `<MalioInputText>`
+- **Input nombre / montant** : `<MalioInputNumber>` (indexation, volume), `<MalioInputAmount>` (prix)
+- **Select simple** : `<MalioSelect>` (certification, pays, ville, client, fournisseur, adresses, sites, état du prix)
+- **Select multi (cases à cocher)** : `<MalioSelectCheckbox>` (filtres certification)
+- **Radio** : `<MalioRadioButton>` (Benne/Fond mouvant, Forfait/Tonne, Client/Fournisseur)
+- **Checkbox** : `<MalioCheckbox>` (Affréter, inclure archivés)
+- **Upload** : `<MalioInputUpload>` (Décharge — exception documentée si type non couvert)
+- **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 : wrapper partagé dans `frontend/shared/` (réutiliser celui du M1/M2/M3).
+- `<MalioInputUpload>` si le type fichier / drag & drop n'est pas couvert.
+
+## Composables & appels API
+
+- `usePaginatedList<Carrier>({ url: '/carriers' })` — liste paginée (obligatoire). Consomme `name`, `certificationType`, `qualimatCarrier.validityDate` (RG-4.04), `updatedAt` (cf. [`spec-back.md § 2.11 / § 4.0`](./spec-back.md)).
+- `useCarrier(id)` — charge le détail via `GET /api/carriers/{id}`, qui **embarque** `addresses`, `contacts`, `prices` (avec `client`/`supplier`/sites imbriqués) + `qualimatCarrier`. Écrans Consultation et Modification peuplés depuis cette seule réponse. **DoD avant intégration** : vérifier le JSON réel (cf. [`spec-back.md § 4.0.bis`](./spec-back.md)).
+- `useCarrierForm()` — workflow par onglet (POST principal + PATCH partiels par groupe), miroir de `useSupplierForm()`/`useProviderForm()` + gestion des **champs conditionnels** (Affréter, AUTRE→Décharge, cas LIOT).
+- `useQualimatSearch()` — saisie assistée du nom : `GET /api/qualimat_carriers?search=`, modal de confirmation, copie des champs + FK (RG-4.01).
+- `useAddressAutocomplete()` — **réutilisé** du M1/M2/M3 (BAN), pas de réécriture (RG-4.06).
+- `useUpload()` (NOUVEAU, infra Shared) — POST multipart `/api/uploaded_documents` → renvoie l'IRI à poser sur `carrier.dischargeDocument` (RG-4.02).
+- `usePermissions()` — masque l'item sidebar et les boutons selon les permissions.
+- 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-4.13 — cf. [`spec-back.md`](./spec-back.md)) :
+
+| Champ | Normalisation serveur | Affichage front |
+|---|---|---|
+| Nom transporteur (`name`) | UPPERCASE intégral | UPPERCASE |
+| Nom + Prénom contact | Capitalize | identique |
+| Téléphones (`CarrierContact`) | Chiffres uniquement en BDD | Formaté `XX XX XX XX XX` (filter Vue) |
+| Email | lowercase intégral | identique |
+| Immatriculations LIOT | `;`-split, trim, UPPER | listées |
+
+> 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/M3** (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-4.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 les modules précédents
+
+| Zone | M2/M3 | M4 transporteurs |
+|---|---|---|
+| Source du nom | saisie libre | **saisie assistée reliée à QUALIMAT** (référentiel synchronisé) |
+| Onglet Comptabilité / RIB | présent (M2/M3) | **Absent** |
+| Cloisonnement par site | M3 : oui | **Non** (référentiel global) |
+| Champs conditionnels formulaire principal | peu | **Nombreux** (Affréter, AUTRE→Décharge, cas LIOT) |
+| Onglet Prix | absent | **Présent** (Client/Fournisseur, sites départ/livraison) |
+| Upload de fichier | aucun | **Décharge** (infra upload Shared, réutilisable) |
+| Module | Commercial / Technique | **Transport** (existant, ERP-150) |
+
+## Points résolus côté back
+
+| # | Zone d'ombre | Résolution (cf. `spec-back.md`) |
+|---|---|---|
+| 1 | Lien QUALIMAT | FK `qualimatCarrier` + **copie éditable** des champs (§ 2.5) |
+| 2 | Cas LIOT | Champ `liotPlates` (`;`-séparé), autres champs masqués (RG-4.01) |
+| 3 | Certification QUALIMAT | Valeur `QUALIMAT` lecture seule si lié (§ 2.5) |
+| 4 | Décharge (upload) | Infra upload générique `Shared` réutilisable (§ 2.7) |
+| 5 | Onglet Prix — branches | M2M absentes : FK Client/Supplier + adresses + sites (RG-4.10/4.11, § 3.2) |
+| 6 | Adresse de départ/livraison 86/17/82 | = les 3 `Site` fixes (FK Site) |
+| 7 | Workflow par onglet | Sauvegarde incrémentale (POST principal + PATCH partiels) — pas d'état « draft » |
+| 8 | Archive vs delete | Flag `is_archived` séparé ; archivage Admin seul ; soft delete = HP |
+| 9 | Unicité métier | Nom seul (§ 2.6) |
+| 10 | Référentiel QUALIMAT | Endpoint lecture seule `GET /api/qualimat_carriers?search=` (§ 4.7) |
+| 11 | Format export | XLSX (répertoire + onglet Prix regroupé Benne/FM) |
+| 12 | RBAC | `transport.carriers.view/manage/archive` ; Compta + Usine sans accès (§ 5.2) |
+
+---
+
+## 📦 Tickets Lesstime
+
+**TaskGroup Lesstime** : à créer — `M4 — Répertoire transporteurs` (projet `ERP / Starseed`, projectId=6). Découpe détaillée (back en tête) → [`spec-back.md § Tickets Lesstime`](./spec-back.md#-tickets-lesstime-à-découper).
+
+| Ordre | Sujet | Tag |
+|---|---|---|
+| 0 | Permissions `transport.carriers.*` + sidebar + 3 sources RBAC | Backend |
+| 1 | Infra upload générique `Shared` (uploaded_document + FileUploader + endpoint) | Backend |
+| 2 | Migration BDD M4 (carrier + sous-collections + index + COMMENT) | Backend |
+| 3 | Entité `QualimatCarrier` (lecture seule) + endpoint recherche | Backend |
+| 4 | Entités + Repositories Carrier* | Backend |
+| 5 | CarrierProvider + CarrierProcessor (champs conditionnels, archive, LIOT) | Backend |
+| 6 | Sous-ressources Adresses / Contacts / Prix (RG-4.10/4.11) | Backend |
+| 7 | Export XLSX (répertoire + onglet Prix) | Backend |
+| 8 | Tests PHPUnit RG-4.01→4.14 + capture contrat JSON | Backend |
+| 9 | Page Répertoire (`/carriers`) + usePaginatedList | Frontend |
+| 10 | Page Ajouter + formulaire principal + saisie assistée QUALIMAT | Frontend |
+| 11 | Onglets Adresses (BAN) / Contacts / Prix | Frontend |
+| 12 | Pages Consultation + Modification | Frontend |
+| 13 | i18n + libellés audit + upload front (useUpload) | Frontend |

docs/specs/M4-transporteurs/tickets-lesstime.md

@@ -0,0 +1,307 @@
+# M4 — Répertoire transporteurs · Découpe en tickets Lesstime
+
+> **Statut** : ✅ **poussé dans Lesstime** — TaskGroup **#31 « M4 — Répertoire transporteurs »** (projet STARSEED), 19 tickets **ERP-153 → ERP-171** au statut **Prêt à dev**.
+> **Assignation** : tickets **Backend (1.1→1.11, ERP-153→163) → Matthieu** · tickets **Frontend (1.12→1.19, ERP-164→171) → Tristan**.
+>
+> | Pos | Ticket | Réf |
+> |---|---|---|
+> | 1.1 | Permissions transport.carriers.* + sidebar | ERP-153 |
+> | 1.2 | Infra upload générique Shared | ERP-154 |
+> | 1.3 | Migration BDD M4 | ERP-155 |
+> | 1.4 | QualimatCarrier + endpoint recherche | ERP-156 |
+> | 1.5 | Entités Carrier* + ApiResource + Provider | ERP-157 |
+> | 1.6 | CarrierProcessor (RG-4.01/02/03 + LIOT) | ERP-158 |
+> | 1.7 | Sous-ressource Adresses | ERP-159 |
+> | 1.8 | Sous-ressource Contacts | ERP-160 |
+> | 1.9 | Sous-ressource Prix + branches | ERP-161 |
+> | 1.10 | Export XLSX | ERP-162 |
+> | 1.11 | Tests PHPUnit + contrat JSON | ERP-163 |
+> | 1.12 | Page Répertoire /carriers | ERP-164 |
+> | 1.13 | Page Ajouter (layout + formulaire) | ERP-165 |
+> | 1.14 | Saisie assistée QUALIMAT + conditionnels | ERP-166 |
+> | 1.15 | Onglet Adresses (BAN) | ERP-167 |
+> | 1.16 | Onglet Contacts | ERP-168 |
+> | 1.17 | Onglet Prix | ERP-169 |
+> | 1.18 | Consultation + Modification | ERP-170 |
+> | 1.19 | Upload front + i18n + audit | ERP-171 |
+> **Specs sources** : [`spec-back.md`](./spec-back.md) · [`spec-front.md`](./spec-front.md) — validées (docx V0 du 27/05/2026).
+> **Maquette Figma** : node `1132-45376` ([lien](https://www.figma.com/design/jRYgT0T9c03VsEbjGhCwwS/Composants---Design-System?node-id=1132-45376&p=f&m=dev)).
+
+## ⚠️ Dépendance amont (socle Tristan — en cours de merge)
+
+Le M4 s'appuie sur le module `Transport` et le référentiel QUALIMAT, livrés par les PR de Tristan **en cours de merge** dans `develop` :
+
+- **ERP-150** (PR #97) — module `Transport` (`TransportModule`, layer front, `config/modules.php`). **Requis** par tout le M4.
+- **ERP-39** (PR #99) — sync QUALIMAT (`qualimat_carrier` + commande `app:qualimat:sync`). **Requis** par la saisie assistée (ticket 1.4).
+- **ERP-149** (PR #101) — sync IDTF (`idtf_product`). **NON requis** par le M4 (référentiel autonome, hors écrans transporteurs).
+
+> Les 3 PR sont **empilées** (`develop → ERP-150 → ERP-39 → ERP-149`). Démarrer le M4 une fois **ERP-150 + ERP-39 dans `develop`** (DoR des tickets 1.1 et 1.4). Brancher le M4 sur `develop` post-merge.
+
+## Vue d'ensemble (ordre d'exécution)
+
+| # | Ticket | Tag | Effort | RG / dépend |
+|---|---|---|---|---|
+| 1.1 | Déclarer permissions `transport.carriers.*` + sidebar | Backend | S | DoR : ERP-150 mergé |
+| 1.2 | Créer l'infra d'upload générique `Shared` | Backend | M | § 2.7 |
+| 1.3 | Migrer le schéma BDD M4 (carrier + sous-tables) | Backend | M | § 3.2 |
+| 1.4 | Exposer `QualimatCarrier` (lecture seule) + endpoint recherche | Backend | S | RG-4.01 · DoR : ERP-39 mergé |
+| 1.5 | Créer entités `Carrier*` + repos + `ApiResource` + `CarrierProvider` | Backend | M | § 3.3 / 4.0 |
+| 1.6 | Implémenter `CarrierProcessor` (RG-4.01/4.02/4.03 + LIOT + normalisation + archive) | Backend | M | RG-4.01→4.03, 4.13, 4.14 |
+| 1.7 | Sous-ressource Adresses (`carrier_address`) | Backend | S | RG-4.05→4.07 |
+| 1.8 | Sous-ressource Contacts (`carrier_contact`) | Backend | S | RG-4.08 |
+| 1.9 | Sous-ressource Prix (`carrier_price`) + RG branches | Backend | M | RG-4.09→4.11 |
+| 1.10 | Export XLSX (répertoire + onglet Prix regroupé) | Backend | M | § 4.6 |
+| 1.11 | Tests PHPUnit RG-4.01→4.14 + capture contrat JSON (DoD) | Backend | M | § 4.0.bis / 8.1 |
+| 1.12 | Page Répertoire `/carriers` (datatable, filtres, export) | Frontend | M | RG-4.04 |
+| 1.13 | Page Ajouter `/carriers/new` (layout, onglets, formulaire principal POST) | Frontend | M | RG-4.12 |
+| 1.14 | Saisie assistée QUALIMAT + champs conditionnels (Affréter / AUTRE→Décharge / LIOT) | Frontend | M | RG-4.01→4.03 |
+| 1.15 | Onglet Adresses (autocomplete BAN) | Frontend | M | RG-4.05→4.07 |
+| 1.16 | Onglet Contacts | Frontend | S | RG-4.08 |
+| 1.17 | Onglet Prix (Client/Fournisseur, sites) | Frontend | M | RG-4.09→4.11 |
+| 1.18 | Pages Consultation + Modification | Frontend | M | — |
+| 1.19 | Upload front (`useUpload`) + i18n + libellés audit | Frontend | S | § 2.8 |
+
+**Total** : 19 tickets · ~11 back / 8 front · mini-MR de 1 à 4h.
+
+---
+
+## Tickets — détail
+
+### 1.1 — Déclarer permissions `transport.carriers.*` + sidebar
+**Position** : 1.1 • Suit : — • Précède : Migrer le schéma BDD M4
+**Tag** : Backend • **Effort** : S
+**Contexte** : `TransportModule::permissions()` renvoie aujourd'hui `[]`. Ce ticket pose le socle RBAC du module et son entrée de menu, prérequis de toute opération sécurisée.
+**Spec liée** : [`spec-back.md § 5`](./spec-back.md) · [`spec-front.md § Accès`](./spec-front.md)
+**Critères d'acceptation** :
+- [ ] `TransportModule::permissions()` déclare `transport.carriers.view`, `transport.carriers.manage`, `transport.carriers.archive` ; `app:sync-permissions` les enregistre.
+- [ ] **Matrice § 5.2** : Admin (view+manage+archive), Bureau (view+manage), Commerciale (view), Compta + Usine (aucune).
+- [ ] **3 sources RBAC alignées dans le même commit** (règle ABSOLUE n°8) : `config/sidebar.php` (section Transport + item `/carriers` + permission), `personas.ts`, `SeedE2ECommand.php`.
+- [ ] Item sidebar masqué pour Compta/Usine ; visible Admin/Bureau/Commerciale.
+**Tests à prévoir** : permissions sync OK ; personas e2e cohérents (pas de drift).
+**Tips** : DoR — ERP-150 mergé (module Transport présent). Section sidebar « Transport » (ou « Logistique » — à trancher, cosmétique).
+
+### 1.2 — Créer l'infra d'upload générique `Shared`
+**Position** : 1.2 • Suit : permissions • Précède : Migration M4
+**Tag** : Backend • **Effort** : M
+**Contexte** : la « Décharge » (RG-4.02) est le 1er d'une série d'uploads à venir. On pose une infra réutilisable, pas un upload ad hoc.
+**Spec liée** : [`spec-back.md § 2.7`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] Table `uploaded_document` (`original_filename`, `stored_path`, `mime_type`, `size_bytes`, `checksum`, `created_at`, `created_by`) + COMMENT ON COLUMN.
+- [ ] Service `Shared\Infrastructure\Upload\FileUploader` : validation MIME **server-side via `$file->getMimeType()`** (jamais `getClientMimeType()`), bornage taille, checksum sha256, écriture disque (`var/uploads/{yyyy}/{mm}/`).
+- [ ] Endpoint `POST /api/uploaded_documents` (multipart) → renvoie l'IRI ; whitelist MIME explicite (PDF + images) ; hors whitelist → 422.
+**Tests à prévoir** : PHPUnit — MIME hors whitelist → 422 ; MIME valide → IRI + ligne persistée ; checksum calculé.
+**Tips** : générique et réutilisable (autres modules la consommeront). Antivirus / S3 / purge = HP (§ 9).
+
+### 1.3 — Migrer le schéma BDD M4 (carrier + sous-tables)
+**Position** : 1.3 • Suit : infra upload • Précède : QualimatCarrier
+**Tag** : Backend • **Effort** : M
+**Contexte** : créer le schéma du répertoire (entité éditable distincte du référentiel `qualimat_carrier`).
+**Spec liée** : [`spec-back.md § 3.2`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] Migration namespace racine `DoctrineMigrations`, **postérieure** à `Version20260612160000`.
+- [ ] Tables `carrier`, `carrier_address`, `carrier_contact`, `carrier_price` + FK (`qualimat_carrier`, `uploaded_document`, `client`, `client_address`, `supplier`, `supplier_address`, `site`, `user`).
+- [ ] `certification_type` **nullable** (null seulement en cas LIOT) + CHECK enum ; CHECK `container_type`, `direction`, `pricing_unit`, `price_state`, branches Prix client/fournisseur.
+- [ ] Index partiel `uq_carrier_name_active` (LOWER(name), WHERE non archivé & non supprimé).
+- [ ] **`COMMENT ON COLUMN` sur TOUTES les colonnes** (règle n°12) + helper Timestampable/Blamable. `ColumnsHaveSqlCommentTest` vert.
+- [ ] `make db-reset` passe ; schéma conforme.
+**Tests à prévoir** : `make db-reset` OK ; `ColumnsHaveSqlCommentTest` vert ; index partiel présent.
+**Tips** : PK `BIGINT` (cohérence module Transport) — à confirmer vs `INT`.
+
+### 1.4 — Exposer `QualimatCarrier` (lecture seule) + endpoint recherche
+**Position** : 1.4 • Suit : migration • Précède : entités Carrier*
+**Tag** : Backend • **Effort** : S
+**Contexte** : la saisie assistée du nom (RG-4.01) a besoin d'un endpoint de recherche sur le référentiel QUALIMAT, aujourd'hui alimenté en console mais non exposé.
+**Spec liée** : [`spec-back.md § 4.7`](./spec-back.md) · RG-4.01
+**Critères d'acceptation** :
+- [ ] Entité `QualimatCarrier` (lecture seule) mappée sur la table existante `qualimat_carrier` (aucune écriture exposée).
+- [ ] `GET /api/qualimat_carriers?search=` : fuzzy sur `name` (+ `siret`), **seulement `is_active = true`**, tri `name`, paginé (règle n°13).
+- [ ] **Security** `is_granted('transport.carriers.view')`. Champs exposés : `id, siret, name, address, postalCode, city, phone, department, status, validityDate, isActive`.
+**Tests à prévoir** : PHPUnit — recherche ne renvoie que les actifs ; pagination Hydra ; 403 sans permission.
+**Tips** : DoR — ERP-39 mergé. Ne pas toucher la commande de sync.
+
+### 1.5 — Créer entités `Carrier*` + repos + `ApiResource` + `CarrierProvider`
+**Position** : 1.5 • Suit : QualimatCarrier • Précède : CarrierProcessor
+**Tag** : Backend • **Effort** : M
+**Contexte** : poser les entités, le contrat de sérialisation (groupes) et la lecture (liste + détail).
+**Spec liée** : [`spec-back.md § 3.3 / 3.4 / 4.0 / 4.1 / 4.2`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] Entités `Carrier`, `CarrierAddress`, `CarrierContact`, `CarrierPrice` (`#[Auditable]`, `TimestampableBlamableTrait`), repos Doctrine.
+- [ ] `ApiResource` Carrier : `GetCollection` + `Get` + `Post` + `Patch` avec `security` (§ 3.3) ; **pas de Delete**.
+- [ ] Groupes de sérialisation : `carrier:read`, `carrier:item:read`, `qualimat:read`, embed `client:read`/`client_address:read`/`supplier:read`/`supplier_address:read`/`site:read` au détail (3 maillons § 4.0 — ⚠ les adresses de l'onglet Prix sont des entités `ClientAddress`/`SupplierAddress` distinctes).
+- [ ] `CarrierProvider` paginé (`ApiPlatform\Doctrine\Orm\Paginator`) ; liste **sans cloisonnement site** (§ 2.3) ; anti-N+1 (§ 2.11).
+- [ ] Piège booléen `isArchived` : `#[SerializedName('isArchived')]` sur le getter.
+**Tests à prévoir** : liste exclut archivés par défaut ; `?includeArchived=true` ; enveloppe Hydra ; `isArchived` présent dans le JSON.
+**Tips** : miroir `Supplier`/`Provider`. Pas d'onglet Comptabilité (≠ M2/M3).
+
+### 1.6 — Implémenter `CarrierProcessor`
+**Position** : 1.6 • Suit : entités • Précède : sous-ressource Adresses
+**Tag** : Backend • **Effort** : M
+**Contexte** : logique d'écriture du formulaire principal (POST/PATCH) : normalisation, champs conditionnels, archivage.
+**Spec liée** : [`spec-back.md § 4.3 / 4.4 / 7`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] **RG-4.01** : POST avec `qualimatCarrier` → `certificationType=QUALIMAT` + FK persistée ; cas LIOT : `name='LIOT'` ⇒ `certificationType` non requis, `liotPlates` accepté.
+- [ ] **RG-4.02** : `certificationType='AUTRE'` sans `dischargeDocument` → **422** (`#[Assert\Callback]`).
+- [ ] **RG-4.03** : `isChartered=true` sans `indexationRate`/`containerType`/`volumeM3` → **422**.
+- [ ] **RG-4.13** : normalisation (`name` UPPER, contacts Capitalize, phones digits, email lower, `liotPlates`).
+- [ ] **RG-4.12** : doublon `name` (actifs) → **409**.
+- [ ] **RG-4.14** : PATCH `isArchived` exige `transport.carriers.archive` (Admin) ; mode strict (403 sinon).
+**Tests à prévoir** : PHPUnit sur chaque RG ci-dessus (cf. § 8.1).
+**Tips** : `CarrierFieldNormalizer` miroir `SupplierFieldNormalizer`.
+
+### 1.7 — Sous-ressource Adresses (`carrier_address`)
+**Position** : 1.7 • Suit : CarrierProcessor • Précède : Contacts
+**Tag** : Backend • **Effort** : S
+**Spec liée** : [`spec-back.md § 4.5`](./spec-back.md) · RG-4.05→4.07
+**Critères d'acceptation** :
+- [ ] `POST /api/carriers/{id}/addresses`, `PATCH`/`DELETE /api/carrier_addresses/{id}` (security `manage`).
+- [ ] **RG-4.06** : `postalCode` matche `^[0-9]{4,5}$` (autocomplete ville = front).
+- [ ] **RG-4.05** : si affrété, adresse obligatoire (Pays/CP/Ville/Adresse) — validation conditionnelle.
+**Tests à prévoir** : PHPUnit — CP invalide → 422 ; adresse affrété incomplète → 422.
+**Tips** : RG-4.07 (bouton Valider masqué si QUALIMAT) = front, back accepte le PATCH.
+
+### 1.8 — Sous-ressource Contacts (`carrier_contact`)
+**Position** : 1.8 • Suit : Adresses • Précède : Prix
+**Tag** : Backend • **Effort** : S
+**Spec liée** : [`spec-back.md § 4.5`](./spec-back.md) · RG-4.08
+**Critères d'acceptation** :
+- [ ] `POST /api/carriers/{id}/contacts`, `PATCH`/`DELETE /api/carrier_contacts/{id}` (security `manage`).
+- [ ] **RG-4.08** : bloc valide si ≥ 1 champ rempli (CHECK `chk_carrier_contact_filled` + Processor) ; **max 2 téléphones**.
+**Tests à prévoir** : PHPUnit — contact vide → 422 ; 1 champ → 200.
+**Tips** : miroir contacts M2/M3.
+
+### 1.9 — Sous-ressource Prix (`carrier_price`) + RG branches
+**Position** : 1.9 • Suit : Contacts • Précède : Export
+**Tag** : Backend • **Effort** : M
+**Spec liée** : [`spec-back.md § 4.5 / 7`](./spec-back.md) · RG-4.09→4.11
+**Critères d'acceptation** :
+- [ ] `POST /api/carriers/{id}/prices`, `PATCH`/`DELETE /api/carrier_prices/{id}` (security `manage`).
+- [ ] **RG-4.10** (CLIENT) : `client`, `clientDeliveryAddress`, `departureSite` requis ; `clientDeliveryAddress` doit appartenir au `client` → sinon 422.
+- [ ] **RG-4.11** (FOURNISSEUR) : `supplier`, `supplierSupplyAddress`, `deliverySite` requis ; `supplierSupplyAddress` appartient au `supplier` → sinon 422.
+- [ ] Communs obligatoires : `containerType`, `pricingUnit`, `price`, `priceState` ; CHECK branches respectées.
+**Tests à prévoir** : PHPUnit — branche CLIENT/FOURNISSEUR incomplète → 422 ; adresse étrangère → 422.
+**Tips** : « Adresse départ/livraison 86/17/82 » = `Site` (FK) ; livraison client = `ClientAddress`, appro = `SupplierAddress` (relations ORM partagées).
+
+### 1.10 — Export XLSX (répertoire + onglet Prix regroupé)
+**Position** : 1.10 • Suit : Prix • Précède : Tests PHPUnit
+**Tag** : Backend • **Effort** : M
+**Spec liée** : [`spec-back.md § 4.6`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] `GET /api/carriers/export.xlsx` : transporteurs affichés (mêmes filtres) ; colonnes § 4.6.
+- [ ] `GET /api/carriers/{id}/prices/export.xlsx` : tableau Prix regroupé Benne / Fond Mouvant (colonnes docx p.10).
+- [ ] Controllers custom `#[Route(priority: 1)]` (conflit API Platform `{id}`) ; `Content-Disposition`.
+**Tests à prévoir** : PHPUnit — 200 + en-tête fichier ; respect des filtres.
+**Tips** : PhpSpreadsheet déjà présent.
+
+### 1.11 — Tests PHPUnit RG-4.01→4.14 + capture contrat JSON (DoD)
+**Position** : 1.11 • Suit : Export • Précède : Page Répertoire
+**Tag** : Backend • **Effort** : M
+**Spec liée** : [`spec-back.md § 4.0.bis / 8.1`](./spec-back.md)
+**Critères d'acceptation** :
+- [ ] Matrice RG-4.01→4.14 couverte (§ 8.1) + RBAC par rôle (Compta/Usine → 403).
+- [ ] `CarrierSerializationContractTest` : capture JSON réel **liste + détail** ; `prices[].client`/`.supplier`/sites **embarqués** (pas IRI) ; `qualimatCarrier` embarqué ; `isArchived` présent.
+- [ ] Anti-N+1 liste ; pagination Hydra ; audit (`entity_type='Carrier'`) ; `AuditableEntitiesHaveI18nLabelTest` vert.
+- [ ] `CarrierFixtures` idempotent (§ 8.4) : transporteur QUALIMAT (validité passée), AUTRE+décharge, affrété, LIOT, complet (contacts/adresses/prix CLIENT+FOURNISSEUR), 1 archivé.
+**Tests à prévoir** : suite complète `make test` verte.
+**Tips** : coller les JSON capturés dans § 4.0.bis (DoD avant front).
+
+### 1.12 — Page Répertoire `/carriers` (datatable, filtres, export)
+**Position** : 1.12 • Suit : Tests back • Précède : Page Ajouter
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Datatable / Filtres`](./spec-front.md) · Figma `1132-45377`
+**Critères d'acceptation** :
+- [ ] `<MalioDataTable>` + `usePaginatedList<Carrier>({url:'/carriers'})` ; colonnes Nom / Certification / Date de validité / Dernière activité.
+- [ ] **RG-4.04** : date de validité QUALIMAT < aujourd'hui → **fond rouge**.
+- [ ] Filtres (`search`, `certificationType`, `includeArchived`) → `setFilters` (page 1) ; **état 100 % local** (règle n°6).
+- [ ] Boutons « + Ajouter » (si `manage`) / « Filtrer » / « Exporter » (XLSX) ; clic ligne → Consultation.
+**Tests à prévoir** : Vitest — `usePaginatedList` (Hydra, exclusion archivés).
+**Tips** : `useApi()` obligatoire ; pas de persistance URL.
+
+### 1.13 — Page Ajouter `/carriers/new` (layout, onglets, formulaire principal POST)
+**Position** : 1.13 • Suit : Répertoire • Précède : Saisie assistée QUALIMAT
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Écran Ajouter / Formulaire principal`](./spec-front.md) · Figma node `1132-45382` (Ajouter – Qualimat)
+**Critères d'acceptation** :
+- [ ] Layout + barre d'onglets `Qualimat · Adresses · Contacts · Prix` ; validation incrémentale (onglet suivant accessible après validation).
+- [ ] Formulaire principal (Nom, Liste certification, Affréter, …) → `POST /api/carriers` ; succès → bascule onglet + champs readonly.
+- [ ] `useFormErrors` : mapping 422 inline par champ ; `{ toast:false }`.
+**Tests à prévoir** : Vitest — `useCarrierForm` (workflow par onglet, POST principal).
+**Tips** : miroir `useSupplierForm`/`useProviderForm`.
+
+### 1.14 — Saisie assistée QUALIMAT + champs conditionnels
+**Position** : 1.14 • Suit : Page Ajouter • Précède : Onglet Adresses
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Formulaire principal / Onglet Qualimat`](./spec-front.md) · RG-4.01→4.03 · Figma nodes `1132-50717` (Affréter), `1132-50982` (AUTRE→Décharge), `1132-45593` (LIOT)
+**Critères d'acceptation** :
+- [ ] **RG-4.01** : saisie du nom → `GET /api/qualimat_carriers?search=` → modal « Êtes-vous sûr… » → copie Nom + certification (`QUALIMAT`, readonly) + adresse + FK conservée.
+- [ ] **Cas LIOT** : nom `LIOT` → champ immatriculations seul, autres masqués.
+- [ ] **RG-4.02** : certification `AUTRE` → champ Décharge visible **et obligatoire** (upload).
+- [ ] **RG-4.03** : « Affréter » coché → indexation / benne-fond mouvant / volume visibles et obligatoires.
+**Tests à prévoir** : Vitest — affichage conditionnel (Affréter, AUTRE, LIOT) ; copie QUALIMAT.
+**Tips** : `useQualimatSearch()` ; `useUpload()` (ticket 1.19) pour la décharge.
+
+### 1.15 — Onglet Adresses (autocomplete BAN)
+**Position** : 1.15 • Suit : Saisie QUALIMAT • Précède : Onglet Contacts
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Onglet Adresses`](./spec-front.md) · RG-4.05→4.07 · Figma node `1132-45670`
+**Critères d'acceptation** :
+- [ ] Bloc adresse (Pays/CP/Ville/Adresse/complément) → `PATCH /api/carriers/{id}/addresses`.
+- [ ] **RG-4.06** : `useAddressAutocomplete()` (BAN) — ville auto depuis CP, dégradé texte libre.
+- [ ] **RG-4.05** : champs préremplis si QUALIMAT ; obligatoires si affrété. **RG-4.07** : pas de bouton Valider si QUALIMAT.
+**Tests à prévoir** : Vitest — autocomplete nominal + dégradé (réutilisation M1/M2/M3).
+**Tips** : ne pas réécrire `useAddressAutocomplete()`.
+
+### 1.16 — Onglet Contacts
+**Position** : 1.16 • Suit : Adresses • Précède : Onglet Prix
+**Tag** : Frontend • **Effort** : S
+**Spec liée** : [`spec-front.md § Onglet Contacts`](./spec-front.md) · RG-4.08 · Figma node `1132-45756`
+**Critères d'acceptation** :
+- [ ] Blocs contact (Nom/Prénom/Fonction/Téléphone x1-2/Email) → `PATCH /api/carriers/{id}/contacts`.
+- [ ] **RG-4.08** : « + Nouveau contact » bloqué tant que le bloc courant est vide ; suppression avec modal.
+**Tests à prévoir** : Vitest — règle « ≥ 1 champ », max 2 téléphones.
+**Tips** : `mapViolationsToRecord` par ligne (pattern collections M1/M2/M3).
+
+### 1.17 — Onglet Prix (Client/Fournisseur, sites)
+**Position** : 1.17 • Suit : Contacts • Précède : Consultation/Modification
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Onglet Prix`](./spec-front.md) · RG-4.09→4.11 · Figma node `1132-45859`
+**Critères d'acceptation** :
+- [ ] Radio `direction` (Client/Fournisseur) → bascule des champs (**RG-4.09**).
+- [ ] **RG-4.10** (Client) : Client + Adresse de livraison (du client) + Adresse de départ (86/17/82).
+- [ ] **RG-4.11** (Fournisseur) : Fournisseur + Adresse d'approvisionnement + Adresse de livraison (86/17/82).
+- [ ] Communs : Benne/FM, Forfait/Tonne, Prix (`MalioInputAmount`), État du prix → `PATCH /api/carriers/{id}/prices`.
+**Tests à prévoir** : Vitest — bascule Client/Fournisseur, champs requis.
+**Tips** : selects clients/fournisseurs/sites via endpoints existants (security élargie § 4.8).
+
+### 1.18 — Pages Consultation + Modification
+**Position** : 1.18 • Suit : Onglet Prix • Précède : Upload/i18n
+**Tag** : Frontend • **Effort** : M
+**Spec liée** : [`spec-front.md § Consultation / Modification`](./spec-front.md)
+**Critères d'acceptation** :
+- [ ] Consultation readonly (ouvre sur Adresses) ; flèche retour ; « Modifier » (si `manage`) ; « Archiver » (Admin) → PATCH `isArchived`.
+- [ ] Onglet Prix consultation = tableau regroupé Benne/FM + bouton Exporter (XLSX).
+- [ ] Modification = mêmes formulaires, champs pré-remplis, PATCH partiel par onglet.
+**Tests à prévoir** : Vitest — `useCarrier(id)` peuple les écrans depuis une seule réponse ; visibilité boutons par permission.
+**Tips** : « Restaurer » remplace « Archiver » sur un archivé.
+
+### 1.19 — Upload front (`useUpload`) + i18n + libellés audit
+**Position** : 1.19 • Suit : Consultation/Modification • Précède : —
+**Tag** : Frontend • **Effort** : S
+**Spec liée** : [`spec-back.md § 2.7 / 2.8`](./spec-back.md) · [`spec-front.md § Composables`](./spec-front.md)
+**Critères d'acceptation** :
+- [ ] Composable `useUpload()` : `POST /api/uploaded_documents` (multipart) → IRI posée sur `carrier.dischargeDocument` (RG-4.02).
+- [ ] Clés i18n : libellés certification, sidebar (`sidebar.transport.*`), **libellés audit** `audit.entity.transport_carrier/carrieraddress/carriercontact/carrierprice`.
+- [ ] `<MalioInputUpload>` (exception documentée si type non couvert).
+**Tests à prévoir** : Vitest — `useUpload` (succès + erreur MIME).
+**Tips** : `AuditableEntitiesHaveI18nLabelTest` exige les clés audit.
+
+---
+
+## Actions Lesstime (à exécuter au feu vert de Matthieu)
+
+1. `create-group` projectId 6, title « M4 — Répertoire transporteurs » → récupérer l'`id`.
+2. `create-task` ×19 (statut `Prêt à dev` = 6, priorité Moyen=2, effort dans la description), dans l'ordre 1.1 → 1.19 :
+   - Tickets **1.1 → 1.11** (Backend, tag `3`) → **assigné à Matthieu**.
+   - Tickets **1.12 → 1.19** (Frontend, tag `2`) → **assigné à Tristan**.
+3. Mettre à jour le frontmatter des specs (`lesstime_taskgroup_id`) + lien du groupe.
+
+> Au push : récupérer les `userId` via `list-users` (Matthieu = `5` selon le référentiel ; Tristan à confirmer) pour renseigner l'assignation à la création.

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

@@ -0,0 +1,80 @@
+# 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.

docs/superpowers/specs/2026-06-03-form-field-validation-mapping-design.md

@@ -0,0 +1,119 @@
+# ERP-101 — Mapping des erreurs de validation par champ (convention forms)
+
+> Statut : design validé — implémentation TDD en cours
+> Branche : `feat/ERP-101-form-field-validation-mapping`
+> Date : 2026-06-03
+
+## Problème
+
+Quand le back renvoie une **422** (violations API Platform), il renvoie **toutes** les
+violations d'un coup (un `propertyPath` + `message` par champ fautif). Aujourd'hui, seul
+le drawer Catégorie (`useCategoryForm`) exploite ce détail pour afficher l'erreur **sous
+le champ concerné** ; il le fait via un `if/else` manuel par champ, non réutilisable.
+
+Le formulaire Client (≈ 20 champs sur 5 submits, dont 3 collections) ne mappe rien : une
+422 multi-champs ⇒ un seul **toast global**. On veut un retour par champ, et surtout
+**une convention unique réutilisée par tous les modules**.
+
+## Décisions
+
+1. **Primitif générique** plutôt que composable par form : `useFormErrors()` partagé.
+2. **Périmètre complet** sur Client : champs scalaires **et** collections (erreur par ligne).
+
+## Architecture — 3 briques
+
+### 1. `mapViolationsToRecord(data)` — `frontend/shared/utils/api.ts`
+
+Util pur, fondation réutilisée partout. Transforme un payload 422 en
+`Record<propertyPath, message>`. S'appuie sur `extractApiViolations` (déjà existant,
+gère les formats `violations` et `hydra:violations`).
+
+```ts
+export function mapViolationsToRecord(data: unknown): Record<string, string> {
+    const out: Record<string, string> = {}
+    for (const v of extractApiViolations(data)) {
+        if (v.propertyPath) out[v.propertyPath] = v.message
+    }
+    return out
+}
+```
+
+### 2. `useFormErrors()` — `frontend/shared/composables/useFormErrors.ts`
+
+API que tous les forms **scalaires** consomment.
+
+```ts
+const { errors, hasErrors, setServerErrors, setError, clearError, clearErrors, handleApiError } = useFormErrors()
+```
+
+- `errors` : `reactive<Record<string, string>>` indexé par `propertyPath`.
+- `setServerErrors(data)` : `mapViolationsToRecord` → remplit `errors`. Retourne `true`
+  si au moins une violation a été mappée.
+- `setError(field, msg)` / `clearError(field)` / `clearErrors()` : manipulation fine.
+- `hasErrors` : `computed` booléen.
+- `handleApiError(e, opts?)` : dispatch standard depuis une erreur ofetch —
+  **422** → `setServerErrors` (mapping inline, pas de toast) ; **autre** → toast
+  générique de fallback (message extrait via `extractApiErrorMessage`).
+
+Côté template, le nom du champ **est** le `propertyPath` :
+
+```vue
+<MalioInputText v-model="main.companyName" :error="errors.companyName" />
+<MalioInputText v-model="accounting.siren" :error="errors.siren" />
+```
+
+> L'unicité SIREN (RG-1.15) remonte en **422 `UniqueEntity` avec `propertyPath: "siren"`**
+> → mappée automatiquement. Pas de cas 409 spécial (contrairement à Catégorie).
+
+### 3. Collections — erreurs par ligne
+
+Chaque ligne (contact / adresse / RIB) est persistée par **son propre appel API**, donc
+le back renvoie un 422 **relatif à la sous-entité** (`propertyPath: "email"`, `"iban"`…).
+
+- Le parent tient, par collection, un tableau d'erreurs **aligné sur l'index de ligne** :
+  `const contactErrors = ref<Record<string, string>[]>([])`.
+- Au submit de la ligne `i` : `catch` → `contactErrors.value[i] = mapViolationsToRecord(data)`.
+- On `clearErrors` la collection au début de chaque passe de submit.
+- Les blocs reçoivent une prop `:errors` (`Record<string, string>`) et bindent
+  `:error="errors?.email"` sur chaque champ Malio.
+
+## Fichiers touchés
+
+| Fichier | Action |
+|---|---|
+| `shared/utils/api.ts` | + `mapViolationsToRecord` |
+| `shared/composables/useFormErrors.ts` | **nouveau** composable |
+| `modules/commercial/pages/clients/new.vue` | scalaires (Main/Info/Compta) + erreurs par ligne |
+| `modules/commercial/pages/clients/[id]/edit.vue` | idem |
+| `modules/commercial/components/ClientContactBlock.vue` | + prop `:errors`, bind `:error` |
+| `modules/commercial/components/ClientAddressBlock.vue` | + prop `:errors`, bind `:error` |
+| RIB (inline dans new/edit) | bind `:error` par ligne |
+
+## Tests (Vitest — règle « pas d'E2E »)
+
+- `mapViolationsToRecord` : formats `violations` / `hydra:violations`, payload vide,
+  `propertyPath` manquant.
+- `useFormErrors` : `setServerErrors` mappe et retourne `true` / `false` sans violation,
+  `clearErrors`, fallback toast sur non-422.
+
+## Convention posée pour tous les forms
+
+À reporter dans `.claude/rules/frontend.md` une fois le pattern stabilisé :
+
+> Tout form qui veut un retour d'erreur par champ : appels API en `{ toast: false }` +
+> `useFormErrors` pour les champs scalaires (422 inline), `mapViolationsToRecord` par
+> ligne pour les collections. `useCategoryForm` migrera sur `useFormErrors`.
+
+## Fait dans la foulée (post-ERP-101 initial)
+
+- **`useCategoryForm` migré sur `useFormErrors`** : `errors` devient le `reactive` du
+  composable (drawer adapté : `form.errors.name` au lieu de `form.errors.value.name`,
+  bloc `_global` retiré → erreur transverse en toast). 28 tests verts.
+- **Convention reportée dans `.claude/rules/frontend.md`** (section « Validation des
+  formulaires — useFormErrors obligatoire »).
+
+## Hors scope ERP-101 (suivi : ticket ERP-107)
+
+- Langue / présence des messages de validation côté back : le `message` affiché est celui
+  renvoyé par le serveur. Audit des contraintes Symfony (présence d'un `message` FR,
+  contraintes manquantes, violations sans `propertyPath`) tracké dans **ERP-107**.

frontend/app/layouts/default.vue

@@ -1,9 +1,19 @@
+<!--
+    Valeurs en dur issues de la maquette Figma (design Starseed) :
+      - sidebar depliee : 232px (w-[232px], repli laisse par defaut 72px)
+      - marge horizontale du contenu sur desktop : 170px (xl:px-[170px])
+    La marge haute du contenu (44px) vit desormais DANS l'entete (PageHeader,
+    pt-11) et non sur le <main> : sinon, l'entete etant sticky, ce padding
+    laissait un trou blanc entre le SiteSelector et l'entete.
+    A faire evoluer uniquement avec une mise a jour de maquette.
+-->
 <template>
     <div class="h-screen overflow-hidden">
         <div class="flex h-full">
             <MalioSidebar
                 v-model="ui.sidebarCollapsed"
                 :sections="translatedSections"
+                :sidebar-class="ui.sidebarCollapsed ? '' : 'w-[232px]'"
             >
                 <template #logo>
                     <img src="/LOGO_MALIO.png" alt="Malio"/>
@@ -16,10 +26,7 @@
             <div class="h-full flex-1 flex flex-col min-h-0 min-w-0">
                 <SiteSelector v-if="showSiteSelector"/>
                 <main
-                    class="flex flex-1 flex-col overflow-y-auto overflow-x-hidden bg-white px-4 pb-24 sm:px-8 lg:px-16">
-                    <div
-                        aria-hidden="true"
-                        class="pointer-events-none sticky top-0 z-30 h-8 flex-shrink-0 bg-white sm:h-12"/>
+                    class="flex flex-1 flex-col overflow-y-auto overflow-x-hidden bg-white px-4 pb-10 sm:px-6 lg:px-12 xl:px-11">
                     <slot/>
                 </main>
             </div>
@@ -62,6 +69,6 @@ watch(() => route.path, () => {
 })
 
 useHead({
-    titleTemplate: (title) => title || 'Coltura',
+    titleTemplate: (title) => title || 'Starseed',
 })
 </script>

frontend/assets/css/main.css

@@ -1 +1 @@
-/* Coltura - Custom styles */
+/* Starseed - Custom styles */

frontend/eslint.config.mjs

@@ -14,7 +14,7 @@ export default await nuxt(
         },
     },
     {
-        name: 'coltura/custom-overrides',
+        name: 'starseed/custom-overrides',
         rules: {
             // Indentation 4 espaces (convention CLAUDE.md)
             'vue/html-indent': ['error', 4],

frontend/i18n/locales/fr.json

@@ -10,32 +10,489 @@
         "confirm": "Confirmer",
         "yes": "Oui",
         "no": "Non",
-        "actions": "Actions"
+        "actions": "Actions",
+        "comingSoon": {
+            "title": "En cours de dev",
+            "subtitle": "Cette fonctionnalité arrive bientôt."
+        }
     },
     "sidebar": {
-        "general": {
-            "section": "Général",
+        "administration": {
+            "section": "Administration"
+        },
+        "account": {
+            "section": "Mon compte",
             "dashboard": "Tableau de bord",
-            "admin": "Administration",
             "logout": "Déconnexion"
         },
         "commercial": {
             "section": "Commercial",
+            "clients": "Répertoire clients",
             "suppliers": "Répertoire fournisseurs"
         },
+        "technique": {
+            "section": "Technique",
+            "providers": "Répertoire prestataires"
+        },
+        "transport": {
+            "section": "Transport",
+            "carriers": "Répertoire transporteurs"
+        },
         "core": {
             "roles": "Gestion des rôles",
             "users": "Utilisateurs",
-            "sites": "Sites"
+            "audit_log": "Journal d'audit"
+        },
+        "sites": {
+            "admin": "Sites"
+        },
+        "catalog": {
+            "categories": "Gestion des catégories"
         }
     },
     "dashboard": {
         "title": "Tableau de bord",
-        "welcome": "Bienvenue sur Coltura"
+        "welcome": "Bienvenue sur Starseed"
     },
     "commercial": {
         "title": "Commercial",
-        "welcome": "Module Commercial"
+        "welcome": "Module Commercial",
+        "suppliers": {
+            "title": "Répertoire fournisseurs",
+            "add": "Ajouter",
+            "export": "Exporter",
+            "empty": "Aucun fournisseur pour l'instant.",
+            "column": {
+                "companyName": "Nom",
+                "categories": "Catégories",
+                "sites": "Site",
+                "lastActivity": "Dernière activité"
+            },
+            "filters": {
+                "title": "Filtres",
+                "search": "Recherche",
+                "categories": "Catégories",
+                "sites": "Sites",
+                "status": "Statut",
+                "includeArchived": "Inclure les archivés",
+                "apply": "Voir les résultats",
+                "reset": "Réinitialiser"
+            },
+            "toast": {
+                "error": "Une erreur est survenue. Réessayez.",
+                "exportError": "L'export du répertoire fournisseurs a échoué. Réessayez.",
+                "createSuccess": "Fournisseur créé avec succès",
+                "updateSuccess": "Fournisseur mis à jour avec succès",
+                "addComplete": "Fournisseur ajouté",
+                "archiveSuccess": "Fournisseur archivé avec succès",
+                "restoreSuccess": "Fournisseur restauré avec succès",
+                "restoreConflict": "Impossible de restaurer : un fournisseur actif portant ce nom existe déjà."
+            },
+            "comingSoon": "À venir",
+            "tab": {
+                "information": "Information",
+                "contacts": "Contacts",
+                "addresses": "Adresses",
+                "transport": "Transport",
+                "accounting": "Comptabilité",
+                "statistics": "Statistiques",
+                "reports": "Rapports",
+                "exchanges": "Échanges"
+            },
+            "action": {
+                "edit": "Modifier",
+                "archive": "Archiver",
+                "restore": "Restaurer"
+            },
+            "consultation": {
+                "title": "Consultation fournisseur",
+                "back": "Retour au répertoire",
+                "loading": "Chargement du fournisseur…",
+                "notFound": "Fournisseur introuvable.",
+                "confirmArchive": {
+                    "title": "Archiver le fournisseur",
+                    "message": "Ce fournisseur n'apparaîtra plus dans le répertoire actif. Confirmer l'archivage ?"
+                },
+                "confirmRestore": {
+                    "title": "Restaurer le fournisseur",
+                    "message": "Ce fournisseur réapparaîtra dans le répertoire actif. Confirmer la restauration ?"
+                }
+            },
+            "edit": {
+                "title": "Modifier le fournisseur",
+                "back": "Retour au répertoire",
+                "loading": "Chargement du fournisseur…",
+                "notFound": "Fournisseur introuvable.",
+                "save": "Valider"
+            },
+            "form": {
+                "title": "Ajouter un fournisseur",
+                "back": "Précédent",
+                "submit": "Valider",
+                "duplicateCompany": "Un fournisseur portant ce nom de société existe déjà.",
+                "main": {
+                    "companyName": "Nom du fournisseur (Entreprise)",
+                    "categories": "Catégorie"
+                },
+                "information": {
+                    "description": "Description",
+                    "competitors": "Concurrent",
+                    "foundedAt": "Date de création",
+                    "employeesCount": "Nombre de salariés",
+                    "revenueAmount": "CA",
+                    "profitAmount": "Résultat",
+                    "directorName": "Dirigeant",
+                    "volumeForecast": "Volume prévisionnel"
+                },
+                "contact": {
+                    "title": "Contact {n}",
+                    "lastName": "Nom",
+                    "firstName": "Prénom",
+                    "jobTitle": "Fonction",
+                    "email": "Email",
+                    "phonePrimary": "Téléphone",
+                    "phoneSecondary": "Téléphone (2)",
+                    "addPhone": "Ajouter un numéro",
+                    "remove": "Supprimer le contact",
+                    "add": "Nouveau contact"
+                },
+                "address": {
+                    "title": "Adresse {n}",
+                    "addressType": "Type d'adresse",
+                    "addressTypeProspect": "Prospect",
+                    "addressTypeDepart": "Départ",
+                    "addressTypeRendu": "Rendu",
+                    "categories": "Catégorie",
+                    "country": "Pays",
+                    "postalCode": "Code postal",
+                    "city": "Ville",
+                    "street": "Adresse",
+                    "streetNotFound": "Adresse introuvable ? Saisissez-la directement.",
+                    "streetComplement": "Adresse complémentaire",
+                    "sites": "Sites",
+                    "contacts": "Contact(s) rattaché(s)",
+                    "bennes": "Benne(s)",
+                    "triageProvider": "Prestation de triage",
+                    "remove": "Supprimer l'adresse",
+                    "add": "Nouvelle adresse",
+                    "degraded": "Service d'adresse indisponible : saisie de la ville et de l'adresse en mode libre."
+                },
+                "accounting": {
+                    "siren": "SIREN",
+                    "accountNumber": "Numéro de compte",
+                    "tvaMode": "Mode de TVA",
+                    "nTva": "N° de TVA",
+                    "paymentDelay": "Délai de règlement",
+                    "paymentType": "Type de règlement",
+                    "bank": "Banque",
+                    "ribLabel": "Libellé",
+                    "ribBic": "BIC",
+                    "ribIban": "IBAN",
+                    "addRib": "Ajouter un RIB",
+                    "removeRib": "Supprimer le RIB"
+                },
+                "confirmDelete": {
+                    "title": "Confirmer la suppression",
+                    "contact": "Supprimer ce contact ?",
+                    "address": "Supprimer cette adresse ?",
+                    "rib": "Supprimer ce RIB ?",
+                    "cancel": "Annuler",
+                    "confirm": "Confirmer"
+                }
+            }
+        },
+        "clients": {
+            "title": "Répertoire clients",
+            "add": "Ajouter",
+            "export": "Exporter",
+            "empty": "Aucun client pour l'instant.",
+            "column": {
+                "companyName": "Nom",
+                "categories": "Catégories",
+                "sites": "Site",
+                "lastActivity": "Dernière activité"
+            },
+            "filters": {
+                "title": "Filtres",
+                "search": "Recherche",
+                "categories": "Catégories",
+                "sites": "Sites",
+                "status": "Statut",
+                "archivedOnly": "Voir les archivés",
+                "apply": "Voir les résultats",
+                "reset": "Réinitialiser"
+            },
+            "tab": {
+                "information": "Information",
+                "contact": "Contact",
+                "address": "Adresse",
+                "transport": "Transport",
+                "accounting": "Comptabilité",
+                "statistics": "Statistiques",
+                "reports": "Rapports",
+                "exchanges": "Échanges"
+            },
+            "action": {
+                "edit": "Modifier",
+                "archive": "Archiver",
+                "restore": "Restaurer"
+            },
+            "toast": {
+                "createSuccess": "Client créé avec succès",
+                "updateSuccess": "Client mis à jour avec succès",
+                "addComplete": "Client ajouté",
+                "archiveSuccess": "Client archivé avec succès",
+                "restoreSuccess": "Client restauré avec succès",
+                "error": "Une erreur est survenue. Réessayez.",
+                "exportError": "L'export du répertoire clients a échoué. Réessayez.",
+                "restoreConflict": "Impossible de restaurer : un client actif portant ce nom existe déjà."
+            },
+            "consultation": {
+                "title": "Consultation client",
+                "back": "Retour au répertoire",
+                "loading": "Chargement du client…",
+                "notFound": "Client introuvable.",
+                "confirmArchive": {
+                    "title": "Archiver le client",
+                    "message": "Ce client n'apparaîtra plus dans le répertoire actif. Confirmer l'archivage ?"
+                },
+                "confirmRestore": {
+                    "title": "Restaurer le client",
+                    "message": "Ce client réapparaîtra dans le répertoire actif. Confirmer la restauration ?"
+                }
+            },
+            "edit": {
+                "title": "Modifier le client",
+                "back": "Retour au répertoire",
+                "loading": "Chargement du client…",
+                "notFound": "Client introuvable.",
+                "save": "Valider"
+            },
+            "validation": {
+                "informationRequiredForCommercial": "Les informations de l'entreprise sont obligatoires pour le rôle Commerciale.",
+                "contactRequired": "Au moins un contact (nom ou prénom) est obligatoire.",
+                "siteRequired": "Au moins un site Starseed doit être rattaché à l'adresse.",
+                "billingEmailRequired": "L'email de facturation est obligatoire pour une adresse de facturation.",
+                "bankRequiredForTransfer": "La banque est obligatoire pour un règlement par virement.",
+                "ribRequiredForLcr": "Au moins un RIB complet est obligatoire pour un règlement par LCR.",
+                "phoneFormat": "Format de téléphone invalide (attendu : XX XX XX XX XX).",
+                "emailFormat": "Format d'email invalide.",
+                "addressCategoryForbidden": "Une catégorie « Distributeur » ou « Courtier » ne peut pas qualifier une adresse."
+            },
+            "form": {
+                "title": "Ajouter un client",
+                "back": "Précédent",
+                "submit": "Valider",
+                "duplicateCompany": "Un client portant ce nom de société existe déjà.",
+                "main": {
+                    "companyName": "Nom du client (Entreprise)",
+                    "categories": "Catégorie",
+                    "relation": "Distributeur / Courtier",
+                    "relationNone": "Aucun",
+                    "relationDistributor": "Dépend du distributeur",
+                    "relationBroker": "Dépend du courtier",
+                    "distributorName": "Nom du distributeur",
+                    "brokerName": "Nom du courtier",
+                    "triageService": "Prestation de triage"
+                },
+                "information": {
+                    "description": "Description",
+                    "competitors": "Concurrent",
+                    "foundedAt": "Date de création",
+                    "employeesCount": "Nombre de salariés",
+                    "revenueAmount": "CA",
+                    "profitAmount": "Résultat",
+                    "directorName": "Dirigeant"
+                },
+                "contact": {
+                    "title": "Contact {n}",
+                    "lastName": "Nom",
+                    "firstName": "Prénom",
+                    "jobTitle": "Fonction",
+                    "email": "Email",
+                    "phonePrimary": "Téléphone",
+                    "phoneSecondary": "Téléphone (2)",
+                    "addPhone": "Ajouter un numéro",
+                    "remove": "Supprimer le contact",
+                    "add": "Nouveau contact"
+                },
+                "address": {
+                    "title": "Adresse {n}",
+                    "prospect": "Prospect",
+                    "delivery": "Adresse de livraison",
+                    "billing": "Facturation",
+                    "addressType": "Type d'adresse",
+                    "addressTypeProspect": "Prospect",
+                    "addressTypeDelivery": "Livraison",
+                    "addressTypeBilling": "Facturation",
+                    "addressTypeDeliveryBilling": "Adresse + Facturation",
+                    "addressTypeBroker": "Adresse Courtier",
+                    "addressTypeDistributor": "Adresse Distributeur",
+                    "categories": "Catégorie",
+                    "country": "Pays",
+                    "postalCode": "Code postal",
+                    "city": "Ville",
+                    "street": "Adresse",
+                    "streetNotFound": "Adresse introuvable ? Saisissez-la directement.",
+                    "streetComplement": "Adresse complémentaire",
+                    "sites": "Sites",
+                    "contacts": "Contact(s) rattaché(s)",
+                    "billingEmail": "Email de facturation",
+                    "billingEmailSecondary": "Email de facturation secondaire",
+                    "addBillingEmail": "Ajouter un email",
+                    "remove": "Supprimer l'adresse",
+                    "add": "Nouvelle adresse",
+                    "degraded": "Service d'adresse indisponible : saisie de la ville et de l'adresse en mode libre."
+                },
+                "accounting": {
+                    "siren": "SIREN",
+                    "accountNumber": "Numéro de compte",
+                    "tvaMode": "Mode de TVA",
+                    "nTva": "N° de TVA",
+                    "paymentDelay": "Délai de règlement",
+                    "paymentType": "Type de règlement",
+                    "bank": "Banque",
+                    "ribTitle": "RIB {n}",
+                    "ribLabel": "Libellé",
+                    "ribBic": "BIC",
+                    "ribIban": "IBAN",
+                    "addRib": "Ajouter un RIB",
+                    "removeRib": "Supprimer le RIB"
+                },
+                "confirmDelete": {
+                    "title": "Confirmer la suppression",
+                    "contact": "Supprimer ce contact ?",
+                    "address": "Supprimer cette adresse ?",
+                    "rib": "Supprimer ce RIB ?",
+                    "cancel": "Annuler",
+                    "confirm": "Confirmer"
+                }
+            }
+        }
+    },
+    "technique": {
+        "providers": {
+            "title": "Répertoire prestataires",
+            "add": "Ajouter",
+            "export": "Exporter",
+            "empty": "Aucun prestataire pour l'instant.",
+            "column": {
+                "companyName": "Nom",
+                "categories": "Catégories",
+                "sites": "Site",
+                "lastActivity": "Dernière activité"
+            },
+            "filters": {
+                "title": "Filtres",
+                "search": "Recherche",
+                "categories": "Catégories",
+                "sites": "Sites",
+                "status": "Statut",
+                "includeArchived": "Inclure les archivés",
+                "apply": "Voir les résultats",
+                "reset": "Réinitialiser"
+            },
+            "tab": {
+                "contact": "Contact",
+                "contacts": "Contacts",
+                "address": "Adresse",
+                "reports": "Rapports",
+                "exchanges": "Échanges",
+                "accounting": "Comptabilité"
+            },
+            "action": {
+                "edit": "Modifier",
+                "archive": "Archiver",
+                "restore": "Restaurer"
+            },
+            "consultation": {
+                "title": "Fiche prestataire",
+                "back": "Retour au répertoire",
+                "loading": "Chargement…",
+                "notFound": "Prestataire introuvable.",
+                "confirmArchive": "Archiver ce prestataire ? Il n'apparaîtra plus dans le répertoire actif.",
+                "confirmRestore": "Restaurer ce prestataire ? Il réapparaîtra dans le répertoire actif."
+            },
+            "edit": {
+                "title": "Modifier le prestataire",
+                "back": "Retour à la fiche",
+                "loading": "Chargement…",
+                "notFound": "Prestataire introuvable.",
+                "save": "Enregistrer"
+            },
+            "form": {
+                "title": "Ajouter un prestataire",
+                "back": "Précédent",
+                "submit": "Valider",
+                "duplicateCompany": "Un prestataire portant ce nom de société existe déjà.",
+                "main": {
+                    "companyName": "Nom du prestataire (Entreprise)",
+                    "categories": "Catégorie",
+                    "sites": "Site"
+                },
+                "errors": {
+                    "nameRequired": "Le nom du prestataire est obligatoire.",
+                    "siteRequired": "Sélectionnez au moins un site.",
+                    "categoryRequired": "Sélectionnez au moins une catégorie."
+                },
+                "contact": {
+                    "lastName": "Nom",
+                    "firstName": "Prénom",
+                    "jobTitle": "Fonction",
+                    "email": "Email",
+                    "phonePrimary": "Téléphone",
+                    "phoneSecondary": "Téléphone (2)",
+                    "addPhone": "Ajouter un numéro",
+                    "remove": "Supprimer le contact",
+                    "add": "Nouveau contact"
+                },
+                "address": {
+                    "sites": "Sites",
+                    "categories": "Catégorie",
+                    "contacts": "Contact(s) rattaché(s)",
+                    "country": "Pays",
+                    "postalCode": "Code postal",
+                    "city": "Ville",
+                    "street": "Adresse",
+                    "streetNotFound": "Adresse introuvable ? Saisissez-la directement.",
+                    "streetComplement": "Adresse complémentaire",
+                    "remove": "Supprimer l'adresse",
+                    "add": "Nouvelle adresse",
+                    "degraded": "Service d'adresse indisponible : saisie de la ville et de l'adresse en mode libre."
+                },
+                "accounting": {
+                    "siren": "SIREN",
+                    "accountNumber": "Numéro de compte",
+                    "tvaMode": "Mode de TVA",
+                    "nTva": "N° de TVA",
+                    "paymentDelay": "Délai de règlement",
+                    "paymentType": "Type de règlement",
+                    "bank": "Banque",
+                    "ribLabel": "Libellé",
+                    "ribBic": "BIC",
+                    "ribIban": "IBAN",
+                    "addRib": "Ajouter un RIB",
+                    "removeRib": "Supprimer le RIB"
+                },
+                "confirmDelete": {
+                    "title": "Confirmer la suppression",
+                    "cancel": "Annuler",
+                    "confirm": "Supprimer",
+                    "contact": "Supprimer ce contact ?",
+                    "address": "Supprimer cette adresse ?",
+                    "rib": "Supprimer ce RIB ?"
+                }
+            },
+            "toast": {
+                "error": "Une erreur est survenue. Réessayez.",
+                "exportError": "L'export du répertoire prestataires a échoué. Réessayez.",
+                "createSuccess": "Prestataire créé avec succès",
+                "updateSuccess": "Prestataire mis à jour avec succès",
+                "addComplete": "Prestataire ajouté",
+                "archiveSuccess": "Prestataire archivé avec succès",
+                "restoreSuccess": "Prestataire restauré avec succès"
+            }
+        }
     },
     "auth": {
         "login": "Connexion",
@@ -58,6 +515,12 @@
         },
         "sites": {
             "notAuthorized": "Vous n'êtes pas autorisé à sélectionner ce site."
+        },
+        "title": "Erreur",
+        "generic": "Une erreur est survenue.",
+        "unknown": "Erreur inconnue.",
+        "validation": {
+            "invalidDate": "Date invalide"
         }
     },
     "sites": {
@@ -66,10 +529,69 @@
             "switchSuccess": "Site courant changé"
         }
     },
+    "audit": {
+        "action": {
+            "create": "Création",
+            "update": "Modification",
+            "delete": "Suppression"
+        },
+        "entity": {
+            "core_user":              "Utilisateur",
+            "core_role":              "Rôle",
+            "core_permission":        "Permission",
+            "sites_site":             "Site",
+            "catalog_category":       "Catégorie",
+            "commercial_client":      "Client",
+            "commercial_clientaddress": "Adresse client",
+            "commercial_clientcontact": "Contact client",
+            "commercial_clientrib":   "RIB client",
+            "commercial_supplier":    "Fournisseur",
+            "commercial_supplieraddress": "Adresse fournisseur",
+            "commercial_suppliercontact": "Contact fournisseur",
+            "commercial_supplierrib": "RIB fournisseur",
+            "technique_provider":     "Prestataire",
+            "technique_provideraddress": "Adresse prestataire",
+            "technique_providercontact": "Contact prestataire",
+            "technique_providerrib":  "RIB prestataire",
+            "transport_carrier":         "Transporteur",
+            "transport_carrieraddress":  "Adresse transporteur",
+            "transport_carriercontact":  "Contact transporteur",
+            "transport_carrierprice":    "Prix transporteur"
+        },
+        "empty": "Aucune activité enregistrée",
+        "no_results": "Aucun résultat pour ces filtres",
+        "error": {
+            "title": "Erreur",
+            "message": "Impossible de charger le journal d'audit. Vérifiez les filtres ou réessayez."
+        },
+        "timeline": {
+            "empty": "Aucun historique",
+            "load_more": "Voir plus"
+        },
+        "filters": {
+            "title": "Filtres",
+            "apply": "Voir les résultats",
+            "reset": "Réinitialiser",
+            "date_range": "Date à date",
+            "date_from": "Du",
+            "date_to": "Au",
+            "entity_type": "Type d'entité",
+            "user": "Utilisateur",
+            "action": "Action",
+            "all_actions": "Toutes les actions"
+        },
+        "detail": {
+            "field": "Champ",
+            "old_value": "Ancienne valeur",
+            "new_value": "Nouvelle valeur"
+        },
+        "detail_title": "Détail de l'entrée"
+    },
     "success": {
         "auth": {
             "logout": "Deconnexion reussie"
-        }
+        },
+        "title": "Succès"
     },
     "admin": {
         "roles": {
@@ -102,7 +624,8 @@
             },
             "permissions": {
                 "selectAll": "Tout selectionner",
-                "noPermissions": "Aucune permission disponible"
+                "noPermissions": "Aucune permission disponible",
+                "loadFailed": "Impossible de charger le catalogue de permissions. L'enregistrement est désactivé pour éviter tout écrasement accidentel."
             }
         },
         "users": {
@@ -126,12 +649,28 @@
                 "noEffectivePermissions": "Aucune permission effective",
                 "sourceRole": "via {role}",
                 "sourceDirect": "Direct",
-                "lastAdminWarning": "Impossible de retirer le statut administrateur du dernier admin"
+                "lastAdminWarning": "Impossible de retirer le statut administrateur du dernier admin",
+                "loadFailed": "Impossible de charger les droits de cet utilisateur. L'enregistrement est désactivé pour éviter tout écrasement accidentel."
             },
             "toast": {
                 "updated": "Permissions mises à jour avec succès"
             }
         },
+        "auditLog": {
+            "title": "Journal d'audit",
+            "table": {
+                "performedAt": "Date",
+                "performedBy": "Utilisateur",
+                "entityType": "Entité",
+                "entityId": "ID",
+                "action": "Action",
+                "summary": "Résumé"
+            },
+            "pagination": {
+                "previous": "Précédent",
+                "next": "Suivant"
+            }
+        },
         "sites": {
             "title": "Gestion des sites",
             "newSite": "Nouveau site",
@@ -164,6 +703,44 @@
                 "updated": "Site mis à jour avec succès",
                 "deleted": "Site supprimé avec succès"
             }
+        },
+        "categories": {
+            "title": "Gestion des catégories",
+            "newCategory": "Ajouter",
+            "editCategory": "Modifier la catégorie",
+            "createCategory": "Créer une catégorie",
+            "noCategories": "Aucune catégorie pour l'instant.",
+            "table": {
+                "name": "Nom",
+                "types": "Types"
+            },
+            "filters": {
+                "title": "Filtres",
+                "search": "Recherche",
+                "types": "Types de catégorie",
+                "apply": "Voir les résultats",
+                "reset": "Réinitialiser"
+            },
+            "form": {
+                "name": "Nom",
+                "types": "Types de catégorie"
+            },
+            "validation": {
+                "nameRequired": "Le nom est obligatoire.",
+                "nameLength": "Le nom doit faire entre 2 et 120 caractères.",
+                "typesRequired": "Sélectionnez au moins un type de catégorie."
+            },
+            "delete": {
+                "title": "Supprimer la catégorie",
+                "message": "Êtes-vous sûr de vouloir supprimer la catégorie \"{name}\" ? Cette action est irréversible."
+            },
+            "toast": {
+                "created": "Catégorie créée avec succès",
+                "updated": "Catégorie mise à jour avec succès",
+                "deleted": "Catégorie supprimée avec succès",
+                "duplicate": "Une catégorie nommée « {name} » existe déjà.",
+                "typesLoadFailed": "Impossible de charger les types de catégorie. Réessayez."
+            }
         }
     }
 }

frontend/modules/catalog/components/CategoryDeleteModal.vue

@@ -0,0 +1,48 @@
+<template>
+    <MalioModal
+        :model-value="modelValue"
+        modal-class="max-w-md"
+        @update:model-value="emit('update:modelValue', $event)"
+    >
+        <template #header>
+            <h3 class="text-lg font-semibold text-neutral-900">
+                {{ t('admin.categories.delete.title') }}
+            </h3>
+        </template>
+
+        <p class="text-sm text-neutral-600">
+            {{ t('admin.categories.delete.message', { name: categoryName }) }}
+        </p>
+
+        <template #footer>
+            <MalioButton
+                :label="t('common.cancel')"
+                variant="secondary"
+                @click="emit('update:modelValue', false)"
+            />
+            <MalioButton
+                :label="t('common.delete')"
+                variant="danger"
+                icon-name="mdi:delete-outline"
+                icon-position="left"
+                :disabled="loading"
+                @click="emit('confirm')"
+            />
+        </template>
+    </MalioModal>
+</template>
+
+<script setup lang="ts">
+const { t } = useI18n()
+
+defineProps<{
+    modelValue: boolean
+    categoryName: string
+    loading: boolean
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: boolean]
+    confirm: []
+}>()
+</script>

frontend/modules/catalog/components/CategoryDrawer.vue

@@ -0,0 +1,164 @@
+<template>
+    <MalioDrawer
+        :model-value="modelValue"
+        drawer-class="w-full max-w-lg"
+        header-class="border-b border-black"
+        footer-class="justify-between border-t border-black p-6"
+        @update:model-value="emit('update:modelValue', $event)"
+    >
+        <template #header>
+            <h2 class="text-2xl font-bold">
+                {{ headerLabel }}
+            </h2>
+        </template>
+
+        <form class="flex flex-col py-4 gap-2" @submit.prevent="handleSave">
+            <!-- Nom (RG-1.02 obligatoire / RG-1.04 longueur 2-120 apres trim).
+                 Erreur miroir client + erreurs server-side (422) mappees sur ce champ. -->
+            <MalioInputText
+                v-model="form.name.value"
+                :label="t('admin.categories.form.name')"
+                input-class="w-full"
+                :max-length="120"
+                :error="form.errors.name"
+                required
+            />
+
+            <!-- Types (RG-1.05 : au moins un obligatoire). MalioSelectCheckbox
+                 porte un tableau d'ids (categoryType id) ; conversion en tableau
+                 d'IRI au moment du save par le composable useCategoryForm. -->
+            <MalioSelectCheckbox
+                v-model="form.categoryTypeIds.value"
+                :options="typeOptions"
+                :label="t('admin.categories.form.types')"
+                :error="form.errors.categoryTypes"
+                :display-tag="true"
+                :disabled="loadingTypes"
+                required
+            />
+        </form>
+
+        <!-- Footer fixe : depuis 1.7.1 le slot #footer est un frere du body
+             scrollable (shrink-0), donc reellement fige sans sticky. -->
+        <template #footer>
+            <MalioButton
+                v-if="canShowDelete"
+                :label="t('common.delete')"
+                variant="danger"
+                icon-name="mdi:delete-outline"
+                icon-position="left"
+                button-class="w-m-btn-action"
+                @click="emit('delete')"
+            />
+            <MalioButton
+                v-else
+                :label="t('common.cancel')"
+                variant="tertiary"
+                button-class="w-m-btn-action"
+                @click="emit('update:modelValue', false)"
+            />
+            <MalioButton
+                v-if="canShowSave"
+                :label="t('common.save')"
+                variant="primary"
+                button-class="w-m-btn-action"
+                :disabled="form.submitting.value || loadingTypes"
+                @click="handleSave"
+            />
+        </template>
+    </MalioDrawer>
+</template>
+
+<script setup lang="ts">
+import type { Category } from '~/modules/catalog/types/category'
+
+const { t } = useI18n()
+const { can } = usePermissions()
+const { types, loadingTypes, fetchTypes } = useCategoriesAdmin()
+// Instance dediee de form pour ce drawer — state isole (cf. useCategoryForm
+// n'est pas singleton, contrairement a useCategoriesAdmin).
+const form = useCategoryForm()
+
+const props = defineProps<{
+    modelValue: boolean
+    category: Category | null
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: boolean]
+    saved: []
+    delete: []
+}>()
+
+// Mode du drawer : creation (pas de category prop, POST au save) ou
+// modification d'une categorie existante (PATCH au save). Pas de distinction
+// view/edit : comme les autres drawers, le titre et le bouton Enregistrer sont
+// stables quel que soit l'etat « dirty » du formulaire.
+const isCreateMode = computed(() => props.category === null)
+
+const headerLabel = computed(() =>
+    isCreateMode.value
+        ? t('admin.categories.createCategory')
+        : t('admin.categories.editCategory'),
+)
+
+// Le bouton Supprimer n'est visible qu'en consultation/edition d'une categorie
+// existante et seulement pour les users ayant la permission manage. En mode
+// creation on affiche un bouton Annuler a la place.
+const canShowDelete = computed(
+    () => !isCreateMode.value && can('catalog.categories.manage'),
+)
+
+// Save : visible en creation, et en consultation/edition d'une categorie
+// existante (l'utilisateur doit pouvoir enregistrer sans qu'un champ ait
+// d'abord ete modifie). Le bouton reste neanmoins protege par son `disabled`
+// pendant la soumission / le chargement des types.
+const canShowSave = computed(
+    () => isCreateMode.value || can('catalog.categories.manage'),
+)
+
+const typeOptions = computed(() =>
+    types.value.map(ct => ({
+        label: ct.label,
+        value: ct.id,
+    })),
+)
+
+// Re-initialise le form quand la categorie selectionnee change (clic sur une
+// autre ligne sans fermer le drawer entre-temps).
+watch(() => props.category, (cat) => {
+    form.loadFrom(cat)
+}, { immediate: true })
+
+// A chaque ouverture du drawer : reload du form + refresh des types (au cas
+// ou un type aurait ete ajoute en arriere-plan depuis le dernier fetch — pas
+// d'optimisation cache au M0, le referentiel est petit).
+watch(
+    () => props.modelValue,
+    (open) => {
+        if (open) {
+            form.loadFrom(props.category)
+            fetchTypes()
+        }
+    },
+)
+
+/**
+ * Sauvegarde : delegue au composable (POST en creation, PATCH en modification).
+ * Le toast succes + mapping erreur 409/422 est gere par le composable. Le PATCH
+ * envoie le payload complet, donc le bouton Enregistrer sauvegarde a tout
+ * moment (meme sans modification). En cas de succes, on ferme le drawer et on
+ * previent le parent pour qu'il refresh la liste.
+ */
+async function handleSave(): Promise<void> {
+    const result = isCreateMode.value
+        ? await form.submitCreate()
+        : props.category
+            ? await form.submitUpdate(props.category.id)
+            : null
+    if (result) {
+        emit('saved')
+        emit('update:modelValue', false)
+    }
+}
+</script>

frontend/modules/catalog/composables/__tests__/useCategoriesAdmin.spec.ts

@@ -0,0 +1,155 @@
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+import type { CategoryType } from '~/modules/catalog/types/category'
+import type { HydraCollection } from '~/shared/utils/api'
+
+// Mock du store auth : useCategoriesAdmin s'auto-enregistre via
+// `onAuthSessionCleared(...)` au chargement du module. On stubbe pour
+// eviter de charger Pinia et la vraie store (pas necessaire ici).
+vi.mock('~/shared/stores/auth', () => ({
+    onAuthSessionCleared: vi.fn(),
+}))
+
+// Le client API est un auto-import Nuxt. On le remplace par un stub
+// global pour intercepter les appels et controler les reponses dans
+// chaque test (cf. pattern utilise dans useCurrentSite.spec.ts).
+const mockGet = vi.hoisted(() => vi.fn())
+vi.stubGlobal('useApi', () => ({
+    get: mockGet,
+    post: vi.fn(),
+    put: vi.fn(),
+    patch: vi.fn(),
+    delete: vi.fn(),
+}))
+
+// Import APRES vi.mock / vi.stubGlobal : le module n'est evalue qu'a
+// ce moment-la, donc le mock auth est bien actif au top-level.
+const { useCategoriesAdmin } = await import('../useCategoriesAdmin')
+
+const TYPE_VENTE: CategoryType = { id: 1, code: 'VENTE', label: 'Vente' }
+const TYPE_ACHAT: CategoryType = { id: 2, code: 'ACHAT', label: 'Achat' }
+
+function makeHydra<T>(items: T[]): HydraCollection<T> {
+    return {
+        totalItems: items.length,
+        member: items,
+    }
+}
+
+/**
+ * Apres ERP-73, `useCategoriesAdmin` ne porte plus la liste paginee des
+ * categories (elle est geree par `usePaginatedList<Category>` cote page).
+ * Le composable se concentre sur le referentiel CategoryType (lecture
+ * seule, ≤ 5 entrees connues) charge en une fois via `?pagination=false`.
+ */
+describe('useCategoriesAdmin', () => {
+    beforeEach(() => {
+        mockGet.mockReset()
+        // Reset systematique du state singleton entre tests : sans ca,
+        // les types charges dans un test fuiteraient dans le suivant.
+        const { resetCategoriesAdmin } = useCategoriesAdmin()
+        resetCategoriesAdmin()
+    })
+
+    describe('fetchTypes', () => {
+        it('appelle GET /category_types avec ?pagination=false (echappatoire selects)', async () => {
+            mockGet.mockResolvedValueOnce(makeHydra<CategoryType>([]))
+            const { fetchTypes } = useCategoriesAdmin()
+
+            await fetchTypes()
+
+            expect(mockGet).toHaveBeenCalledTimes(1)
+            expect(mockGet).toHaveBeenCalledWith(
+                '/category_types',
+                { pagination: 'false' },
+                { toast: false },
+            )
+        })
+
+        it('peuple types.value depuis le champ Hydra member', async () => {
+            mockGet.mockResolvedValueOnce(makeHydra([TYPE_VENTE, TYPE_ACHAT]))
+            const { fetchTypes, types } = useCategoriesAdmin()
+
+            await fetchTypes()
+
+            expect(types.value).toEqual([TYPE_VENTE, TYPE_ACHAT])
+        })
+
+        it('peuple error.value et vide types en cas d echec', async () => {
+            mockGet.mockRejectedValueOnce(new Error('500'))
+            const { fetchTypes, types, error, loadingTypes } = useCategoriesAdmin()
+            types.value = [TYPE_VENTE]
+
+            await fetchTypes()
+
+            expect(types.value).toEqual([])
+            expect(error.value).toContain('500')
+            expect(loadingTypes.value).toBe(false)
+        })
+
+        it('passe loadingTypes a true pendant la requete et false apres', async () => {
+            let resolveRequest: (v: HydraCollection<CategoryType>) => void = () => {}
+            mockGet.mockImplementationOnce(
+                () => new Promise((resolve) => { resolveRequest = resolve }),
+            )
+            const { fetchTypes, loadingTypes } = useCategoriesAdmin()
+
+            const pending = fetchTypes()
+            expect(loadingTypes.value).toBe(true)
+
+            resolveRequest(makeHydra<CategoryType>([]))
+            await pending
+
+            expect(loadingTypes.value).toBe(false)
+        })
+
+        it('gere une reponse sans champ member (fallback tableau vide)', async () => {
+            mockGet.mockResolvedValueOnce({
+                totalItems: 0,
+            } as unknown as HydraCollection<CategoryType>)
+            const { fetchTypes, types } = useCategoriesAdmin()
+
+            await fetchTypes()
+
+            expect(types.value).toEqual([])
+        })
+    })
+
+    describe('resetCategoriesAdmin', () => {
+        it('vide types, loadingTypes et error', () => {
+            const { resetCategoriesAdmin, types, loadingTypes, error }
+                = useCategoriesAdmin()
+            // Pre-peuple le state pour verifier la purge effective.
+            types.value = [TYPE_VENTE]
+            loadingTypes.value = true
+            error.value = 'oops'
+
+            resetCategoriesAdmin()
+
+            expect(types.value).toEqual([])
+            expect(loadingTypes.value).toBe(false)
+            expect(error.value).toBeNull()
+        })
+    })
+
+    describe('singleton', () => {
+        it('deux appels a useCategoriesAdmin() partagent la meme ref types', () => {
+            const a = useCategoriesAdmin()
+            const b = useCategoriesAdmin()
+
+            // Les fonctions sont reinstanciees a chaque appel mais les refs
+            // doivent etre rigoureusement les memes (state au niveau module).
+            expect(a.types).toBe(b.types)
+            expect(a.loadingTypes).toBe(b.loadingTypes)
+            expect(a.error).toBe(b.error)
+        })
+
+        it('une mutation via une instance est visible depuis une autre instance', () => {
+            const a = useCategoriesAdmin()
+            const b = useCategoriesAdmin()
+
+            a.types.value = [TYPE_VENTE]
+
+            expect(b.types.value).toEqual([TYPE_VENTE])
+        })
+    })
+})

frontend/modules/catalog/composables/__tests__/useCategoryForm.spec.ts

@@ -0,0 +1,487 @@
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+import type { Category, CategoryType } from '~/modules/catalog/types/category'
+import { useFormErrors } from '~/shared/composables/useFormErrors'
+import { useCategoryForm } from '../useCategoryForm'
+
+// Stubs des auto-imports Nuxt consommes par le composable.
+const mockGet = vi.hoisted(() => vi.fn())
+const mockPost = vi.hoisted(() => vi.fn())
+const mockPatch = vi.hoisted(() => vi.fn())
+const mockDelete = vi.hoisted(() => vi.fn())
+const mockToastSuccess = vi.hoisted(() => vi.fn())
+const mockToastError = vi.hoisted(() => vi.fn())
+
+vi.stubGlobal('useApi', () => ({
+    get: mockGet,
+    post: mockPost,
+    put: vi.fn(),
+    patch: mockPatch,
+    delete: mockDelete,
+}))
+vi.stubGlobal('useToast', () => ({
+    success: mockToastSuccess,
+    error: mockToastError,
+}))
+// useFormErrors est un auto-import Nuxt : on expose l'implementation reelle
+// (elle consomme useToast, deja stubbe ci-dessus) pour tester l'integration.
+vi.stubGlobal('useFormErrors', useFormErrors)
+// useI18n.t : on renvoie la cle telle quelle (pratique pour asserter dessus).
+// Quand le composable passe des params (ex: doublon), on les serialise pour
+// pouvoir verifier que l'interpolation a bien recu le bon nom.
+vi.stubGlobal('useI18n', () => ({
+    t: (key: string, params?: Record<string, unknown>) =>
+        params ? `${key}::${JSON.stringify(params)}` : key,
+}))
+
+const TYPE_VENTE: CategoryType = { id: 1, code: 'VENTE', label: 'Vente' }
+const TYPE_ACHAT: CategoryType = { id: 2, code: 'ACHAT', label: 'Achat' }
+
+const CAT: Category = {
+    id: 42,
+    name: 'Vis',
+    categoryTypes: [TYPE_VENTE],
+    deletedAt: null,
+    createdAt: '2026-01-01T10:00:00+00:00',
+    updatedAt: '2026-01-01T10:00:00+00:00',
+    createdBy: null,
+    updatedBy: null,
+}
+
+describe('useCategoryForm', () => {
+    beforeEach(() => {
+        mockGet.mockReset()
+        mockPost.mockReset()
+        mockPatch.mockReset()
+        mockDelete.mockReset()
+        mockToastSuccess.mockReset()
+        mockToastError.mockReset()
+    })
+
+    describe('loadFrom', () => {
+        it('pre-remplit le formulaire depuis une categorie existante (multi-types)', () => {
+            const form = useCategoryForm()
+
+            form.loadFrom({ ...CAT, categoryTypes: [TYPE_VENTE, TYPE_ACHAT] })
+
+            expect(form.name.value).toBe('Vis')
+            expect(form.categoryTypeIds.value).toEqual([1, 2])
+            expect(form.errors).toEqual({})
+        })
+
+        it('vide le formulaire en mode creation (null)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'old'
+            form.categoryTypeIds.value = [99]
+
+            form.loadFrom(null)
+
+            expect(form.name.value).toBe('')
+            expect(form.categoryTypeIds.value).toEqual([])
+        })
+
+        it('reinitialise le snapshot initial → isDirty=false juste apres', () => {
+            const form = useCategoryForm()
+
+            form.loadFrom(CAT)
+
+            expect(form.isDirty.value).toBe(false)
+        })
+    })
+
+    describe('isDirty', () => {
+        it('passe a true des qu une valeur diverge du snapshot initial', () => {
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            expect(form.isDirty.value).toBe(false)
+
+            form.name.value = 'Vis modifie'
+
+            expect(form.isDirty.value).toBe(true)
+        })
+
+        it('passe a true quand on ajoute un type (selection multi)', () => {
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            expect(form.isDirty.value).toBe(false)
+
+            form.categoryTypeIds.value = [1, 2]
+
+            expect(form.isDirty.value).toBe(true)
+        })
+
+        it('reste false si la selection est identique dans un autre ordre', () => {
+            const form = useCategoryForm()
+            form.loadFrom({ ...CAT, categoryTypes: [TYPE_VENTE, TYPE_ACHAT] })
+
+            form.categoryTypeIds.value = [2, 1]
+
+            expect(form.isDirty.value).toBe(false)
+        })
+    })
+
+    describe('validate', () => {
+        it('signale une erreur si name est vide (RG-1.02)', () => {
+            const form = useCategoryForm()
+            form.name.value = ''
+            form.categoryTypeIds.value = [1]
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.name).toBe('admin.categories.validation.nameRequired')
+        })
+
+        it('signale erreur si name est whitespace-only (trim → vide)', () => {
+            const form = useCategoryForm()
+            form.name.value = '   '
+            form.categoryTypeIds.value = [1]
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.name).toBe('admin.categories.validation.nameRequired')
+        })
+
+        it('signale erreur si name fait 1 caractere (< 2, RG-1.04)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'A'
+            form.categoryTypeIds.value = [1]
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.name).toBe('admin.categories.validation.nameLength')
+        })
+
+        it('signale erreur si name fait 121 caracteres (> 120, RG-1.04)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'A'.repeat(121)
+            form.categoryTypeIds.value = [1]
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.name).toBe('admin.categories.validation.nameLength')
+        })
+
+        it('signale erreur si aucun type selectionne (RG-1.05)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = []
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.categoryTypes).toBe('admin.categories.validation.typesRequired')
+        })
+
+        it('passe quand name et au moins un type sont valides', () => {
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1, 2]
+
+            const ok = form.validate()
+
+            expect(ok).toBe(true)
+            expect(form.errors).toEqual({})
+        })
+
+        it('reinitialise les erreurs avant chaque validation', () => {
+            const form = useCategoryForm()
+            // Erreur prealable : une validation en echec peuple errors.name.
+            form.name.value = ''
+            form.categoryTypeIds.value = [1]
+            form.validate()
+            expect(form.errors.name).toBeTruthy()
+
+            // Seconde validation avec des valeurs valides : errors repart vide.
+            form.name.value = 'Vis'
+            form.validate()
+
+            expect(form.errors).toEqual({})
+        })
+    })
+
+    describe('submitCreate', () => {
+        it('appelle POST /categories avec body { name trimme, categoryTypes en IRI[] }', async () => {
+            mockPost.mockResolvedValueOnce(CAT)
+            const form = useCategoryForm()
+            form.name.value = '  Vis  '
+            form.categoryTypeIds.value = [1, 2]
+
+            const result = await form.submitCreate()
+
+            expect(mockPost).toHaveBeenCalledWith(
+                '/categories',
+                { name: 'Vis', categoryTypes: ['/api/category_types/1', '/api/category_types/2'] },
+                { toast: false },
+            )
+            expect(result).toEqual(CAT)
+        })
+
+        it('ne declenche aucun appel API si la validation client echoue', async () => {
+            const form = useCategoryForm()
+            form.name.value = ''
+            form.categoryTypeIds.value = [1]
+
+            const result = await form.submitCreate()
+
+            expect(mockPost).not.toHaveBeenCalled()
+            expect(result).toBeNull()
+        })
+
+        it('declenche un toast de succes en cas de creation reussie', async () => {
+            mockPost.mockResolvedValueOnce(CAT)
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            await form.submitCreate()
+
+            expect(mockToastSuccess).toHaveBeenCalledWith({
+                title: 'success.title',
+                message: 'admin.categories.toast.created',
+            })
+        })
+
+        it('mappe un 409 (RG-1.07) sur errors.name + toast erreur avec le nom', async () => {
+            mockPost.mockRejectedValueOnce({
+                response: { status: 409, _data: {} },
+            })
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            const result = await form.submitCreate()
+
+            expect(result).toBeNull()
+            // La cle est interpolee avec le nom soumis : on retrouve "Vis" dans
+            // les params i18n (stub serialise les params).
+            expect(form.errors.name).toContain('admin.categories.toast.duplicate')
+            expect(form.errors.name).toContain('"name":"Vis"')
+            expect(mockToastError).toHaveBeenCalledTimes(1)
+            const toastArg = mockToastError.mock.calls[0]?.[0] as { message: string }
+            expect(toastArg.message).toContain('Vis')
+        })
+
+        it('mappe un 422 violations sur les champs concernes (errors.name)', async () => {
+            mockPost.mockRejectedValueOnce({
+                response: {
+                    status: 422,
+                    _data: {
+                        violations: [
+                            { propertyPath: 'name', message: 'name should not be blank.' },
+                        ],
+                    },
+                },
+            })
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            const result = await form.submitCreate()
+
+            expect(result).toBeNull()
+            expect(form.errors.name).toBe('name should not be blank.')
+            // Pas de toast quand on a mappe les violations : l erreur est
+            // affichee inline sous le champ concerne.
+            expect(mockToastError).not.toHaveBeenCalled()
+        })
+
+        it('mappe une violation sur categoryTypes (hydra:violations alternative)', async () => {
+            mockPost.mockRejectedValueOnce({
+                response: {
+                    status: 422,
+                    _data: {
+                        'hydra:violations': [
+                            { propertyPath: 'categoryTypes', message: 'Sélectionnez au moins un type de catégorie.' },
+                        ],
+                    },
+                },
+            })
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            await form.submitCreate()
+
+            expect(form.errors.categoryTypes).toBe('Sélectionnez au moins un type de catégorie.')
+        })
+
+        it('fallback en toast generique si le status n est ni 409 ni 422', async () => {
+            mockPost.mockRejectedValueOnce({
+                response: { status: 500, _data: { 'hydra:description': 'Boom server' } },
+            })
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            await form.submitCreate()
+
+            // Pas d'erreur inline par champ : l'erreur transverse part en toast.
+            expect(form.errors).toEqual({})
+            expect(mockToastError).toHaveBeenCalledWith({
+                title: 'errors.title',
+                message: 'Boom server',
+            })
+        })
+
+        it('passe submitting a true pendant la requete et a false apres', async () => {
+            let resolveRequest: (v: Category) => void = () => {}
+            mockPost.mockImplementationOnce(
+                () => new Promise((resolve) => { resolveRequest = resolve }),
+            )
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeIds.value = [1]
+
+            const pending = form.submitCreate()
+            expect(form.submitting.value).toBe(true)
+
+            resolveRequest(CAT)
+            await pending
+
+            expect(form.submitting.value).toBe(false)
+        })
+    })
+
+    describe('submitUpdate', () => {
+        it('appelle PATCH /categories/{id} avec le payload complet (name + categoryTypes)', async () => {
+            mockPatch.mockResolvedValueOnce({ ...CAT, name: 'Vis V2' })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = 'Vis V2' // types inchanges
+
+            await form.submitUpdate(42)
+
+            // Payload complet : meme si seul le name change, on renvoie aussi
+            // les categoryTypes (PATCH full payload, cf. drawers simples).
+            expect(mockPatch).toHaveBeenCalledWith(
+                '/categories/42',
+                { name: 'Vis V2', categoryTypes: ['/api/category_types/1'] },
+                { toast: false },
+            )
+        })
+
+        it('envoie categoryTypes en IRI[] quand on ajoute un type', async () => {
+            mockPatch.mockResolvedValueOnce({ ...CAT, categoryTypes: [TYPE_VENTE, TYPE_ACHAT] })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.categoryTypeIds.value = [1, 2]
+
+            await form.submitUpdate(42)
+
+            expect(mockPatch).toHaveBeenCalledWith(
+                '/categories/42',
+                { name: CAT.name, categoryTypes: ['/api/category_types/1', '/api/category_types/2'] },
+                { toast: false },
+            )
+        })
+
+        it('envoie un PATCH complet meme sans modification (save a tout moment)', async () => {
+            mockPatch.mockResolvedValueOnce(CAT)
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            // Aucune modification : le PATCH part quand meme avec le payload complet.
+
+            const result = await form.submitUpdate(42)
+
+            expect(mockPatch).toHaveBeenCalledWith(
+                '/categories/42',
+                { name: CAT.name, categoryTypes: ['/api/category_types/1'] },
+                { toast: false },
+            )
+            expect(result).toEqual(CAT)
+            expect(form.submitting.value).toBe(false)
+        })
+
+        it('declenche un toast de succes au PATCH reussi', async () => {
+            mockPatch.mockResolvedValueOnce({ ...CAT, name: 'Vis V2' })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = 'Vis V2'
+
+            await form.submitUpdate(42)
+
+            expect(mockToastSuccess).toHaveBeenCalledWith({
+                title: 'success.title',
+                message: 'admin.categories.toast.updated',
+            })
+        })
+
+        it('mappe le 409 sur errors.name en mode update aussi', async () => {
+            mockPatch.mockRejectedValueOnce({
+                response: { status: 409, _data: {} },
+            })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = 'Doublon'
+
+            const result = await form.submitUpdate(42)
+
+            expect(result).toBeNull()
+            expect(form.errors.name).toContain('admin.categories.toast.duplicate')
+            expect(form.errors.name).toContain('"name":"Doublon"')
+        })
+    })
+
+    describe('submitDelete', () => {
+        it('appelle DELETE /categories/{id} et declenche un toast succes', async () => {
+            mockDelete.mockResolvedValueOnce(undefined)
+            const form = useCategoryForm()
+
+            const ok = await form.submitDelete(42)
+
+            expect(mockDelete).toHaveBeenCalledWith('/categories/42', {}, { toast: false })
+            expect(ok).toBe(true)
+            expect(mockToastSuccess).toHaveBeenCalledWith({
+                title: 'success.title',
+                message: 'admin.categories.toast.deleted',
+            })
+        })
+
+        it('retourne false et toast erreur en cas d echec', async () => {
+            mockDelete.mockRejectedValueOnce({
+                response: { status: 500, _data: { detail: 'down' } },
+            })
+            const form = useCategoryForm()
+
+            const ok = await form.submitDelete(42)
+
+            expect(ok).toBe(false)
+            expect(mockToastError).toHaveBeenCalled()
+        })
+    })
+
+    describe('reset', () => {
+        it('vide le formulaire et les erreurs', () => {
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = ''
+            form.validate() // peuple errors.name
+            form.submitting.value = true
+
+            form.reset()
+
+            expect(form.name.value).toBe('')
+            expect(form.categoryTypeIds.value).toEqual([])
+            expect(form.errors).toEqual({})
+            expect(form.submitting.value).toBe(false)
+        })
+    })
+
+    describe('isolation', () => {
+        it('deux instances useCategoryForm() ont des states independants', () => {
+            const a = useCategoryForm()
+            const b = useCategoryForm()
+
+            a.name.value = 'A'
+            b.name.value = 'B'
+
+            expect(a.name.value).toBe('A')
+            expect(b.name.value).toBe('B')
+            // Les refs sont distinctes (pas singleton — chaque drawer son state).
+            expect(a.name).not.toBe(b.name)
+        })
+    })
+})

frontend/modules/catalog/composables/useCategoriesAdmin.ts

@@ -0,0 +1,91 @@
+/**
+ * Composable de chargement du referentiel CategoryType (M0 — Gestion des
+ * categories).
+ *
+ * Apres ERP-73 (composable de liste paginee), la liste des categories
+ * elle-meme passe par `usePaginatedList<Category>` directement dans
+ * `admin/categories.vue` — c'est un etat propre a la page (pagination,
+ * filtres, tri locaux). Ce composable se concentre donc sur le
+ * referentiel CategoryType : petite collection lue une fois et reutilisee
+ * dans le drawer (select de type) → singleton volontaire pour eviter de
+ * la recharger a chaque ouverture du drawer.
+ *
+ * State singleton au niveau module : reset automatique au logout via
+ * `onAuthSessionCleared` (cf. CLAUDE.md regle frontend.md), et reset
+ * explicite via `resetCategoriesAdmin()` appele depuis logout.vue.
+ */
+import { ref } from 'vue'
+import type { CategoryType } from '~/modules/catalog/types/category'
+import type { HydraCollection } from '~/shared/utils/api'
+import { onAuthSessionCleared } from '~/shared/stores/auth'
+
+/**
+ * CategoryType est un referentiel lecture-seule (RG-1.06) avec une
+ * cardinalite minuscule (≤ 5 entrees connues). On force `pagination=false`
+ * pour recuperer toutes les entrees en un appel et alimenter le select du
+ * drawer sans pagination — echappatoire prevue par
+ * `pagination_client_enabled: true` cote API Platform.
+ */
+const NO_PAGINATION_QUERY = { pagination: 'false' } as const
+
+const types = ref<CategoryType[]>([])
+const loadingTypes = ref(false)
+const error = ref<string | null>(null)
+
+function resetCategoriesAdminState(): void {
+    types.value = []
+    loadingTypes.value = false
+    error.value = null
+}
+
+// Auto-enregistrement singleton : purge le state sur 401/clearSession
+// pour eviter qu'un user suivant (connecte sur le meme onglet) voie le
+// referentiel de l'ancien tenant. Le logout volontaire (page logout.vue)
+// appelle directement `resetCategoriesAdmin()` ci-dessous.
+onAuthSessionCleared(resetCategoriesAdminState)
+
+export function useCategoriesAdmin() {
+    const api = useApi()
+
+    /**
+     * Charge le referentiel CategoryType. Appele a l'ouverture de la page
+     * admin pour que le select du drawer ait deja les options pretes au
+     * moment de la creation/edition.
+     *
+     * Toast desactive : on stocke l'erreur dans `error` plutot que de
+     * spammer un toast — le drawer affichera l'erreur inline s'il y a lieu.
+     */
+    async function fetchTypes(): Promise<void> {
+        loadingTypes.value = true
+        try {
+            const data = await api.get<HydraCollection<CategoryType>>(
+                '/category_types',
+                NO_PAGINATION_QUERY,
+                { toast: false },
+            )
+            types.value = data.member ?? []
+        } catch (e) {
+            types.value = []
+            error.value = (e as Error)?.message ?? 'Erreur de chargement des types'
+        } finally {
+            loadingTypes.value = false
+        }
+    }
+
+    /**
+     * Reset explicite — appele depuis `logout.vue` apres `auth.logout()`
+     * pour garantir que la prochaine session reparte sur un state propre
+     * meme si `clearSession()` n'a pas ete declenche (cas logout volontaire).
+     */
+    function resetCategoriesAdmin(): void {
+        resetCategoriesAdminState()
+    }
+
+    return {
+        types,
+        loadingTypes,
+        error,
+        fetchTypes,
+        resetCategoriesAdmin,
+    }
+}

frontend/modules/catalog/composables/useCategoryForm.ts

@@ -0,0 +1,261 @@
+/**
+ * Composable de formulaire categorie (M0 — Gestion des categories).
+ *
+ * Centralise la logique de validation client + appels API (POST / PATCH /
+ * DELETE) du drawer de creation/edition. Contrairement a
+ * `useCategoriesAdmin` qui porte un state singleton partage entre composants,
+ * ce composable est instancie par formulaire (les refs vivent dans la
+ * fonction `useCategoryForm()`) — chaque drawer ouvert a son propre state
+ * isole.
+ *
+ * Validations client en miroir des regles back (RG-1.02 / RG-1.04 / RG-1.05) :
+ * elles servent juste a eviter l'aller-retour reseau evitable. Le serveur
+ * revalide toujours (defense en profondeur).
+ *
+ * Erreurs par champ : delegue a `useFormErrors` (convention ERP-101). Les
+ * violations 422 sont mappees par `propertyPath` (`name`, `categoryTypes`) ;
+ * l'erreur globale (status != 422 exploitable) part en toast. Le 409 (doublon
+ * de nom GLOBAL, RG-1.07) reste un cas metier specifique : erreur inline sur
+ * `name` + toast.
+ */
+import { computed, ref } from 'vue'
+import type { Category } from '~/modules/catalog/types/category'
+
+/**
+ * Erreur HTTP capturee par ofetch. On expose juste les champs utilises ici
+ * (status et payload data) pour eviter de typer toute la lib.
+ */
+interface ApiFetchError {
+    response?: {
+        status?: number
+        _data?: unknown
+    }
+}
+
+export function useCategoryForm() {
+    const api = useApi()
+    const { t } = useI18n()
+    const toast = useToast()
+
+    // Etat d'erreurs par champ (indexe par propertyPath) + dispatch API 422.
+    const formErrors = useFormErrors()
+
+    // State local du formulaire — pas singleton, chaque appel a useCategoryForm
+    // cree son propre state (cohérent avec le pattern « un drawer = un form »).
+    const name = ref('')
+    const categoryTypeIds = ref<number[]>([])
+
+    // Snapshot des valeurs initiales : sert a calculer `isDirty` pour le
+    // pattern view → edit du drawer (le bouton Enregistrer reste masque tant
+    // que rien n'a change en mode consultation).
+    const initialName = ref('')
+    const initialCategoryTypeIds = ref<number[]>([])
+
+    const submitting = ref(false)
+
+    // Compare deux listes d'ids sans tenir compte de l'ordre (la selection
+    // multi-types n'est pas ordonnee).
+    function sameIds(a: number[], b: number[]): boolean {
+        if (a.length !== b.length) return false
+        const sortedA = [...a].sort((x, y) => x - y)
+        const sortedB = [...b].sort((x, y) => x - y)
+        return sortedA.every((v, i) => v === sortedB[i])
+    }
+
+    const isDirty = computed(
+        () =>
+            name.value !== initialName.value
+            || !sameIds(categoryTypeIds.value, initialCategoryTypeIds.value),
+    )
+
+    /**
+     * Pre-remplit le formulaire a partir d'une categorie existante (mode
+     * consultation/edition) ou vide (mode creation). Reinitialise les
+     * erreurs et le snapshot initial pour repartir d'un etat propre.
+     */
+    function loadFrom(category: Category | null): void {
+        formErrors.clearErrors()
+        if (category) {
+            const ids = category.categoryTypes.map(t => t.id)
+            name.value = category.name
+            categoryTypeIds.value = [...ids]
+            initialName.value = category.name
+            initialCategoryTypeIds.value = [...ids]
+        } else {
+            name.value = ''
+            categoryTypeIds.value = []
+            initialName.value = ''
+            initialCategoryTypeIds.value = []
+        }
+    }
+
+    /**
+     * Validation client miroir des RG back. Renvoie true si tout passe et
+     * peuple `errors` sinon. Le trim est applique cote client (miroir RG-1.03)
+     * mais le serveur retrim de toute facon — pas de risque de divergence.
+     */
+    function validate(): boolean {
+        formErrors.clearErrors()
+        const trimmedName = name.value.trim()
+
+        // RG-1.02 — name obligatoire (vide / whitespace-only).
+        if (trimmedName === '') {
+            formErrors.setError('name', t('admin.categories.validation.nameRequired'))
+        } else if (trimmedName.length < 2 || trimmedName.length > 120) {
+            // RG-1.04 — longueur 2-120 apres trim.
+            formErrors.setError('name', t('admin.categories.validation.nameLength'))
+        }
+
+        // RG-1.05 — au moins un type obligatoire.
+        if (categoryTypeIds.value.length === 0) {
+            formErrors.setError('categoryTypes', t('admin.categories.validation.typesRequired'))
+        }
+
+        return !formErrors.errors.name && !formErrors.errors.categoryTypes
+    }
+
+    /**
+     * Construit le payload POST a partir du state. Les `categoryTypes` sont
+     * envoyes en tableau d'IRI Hydra (`/api/category_types/{id}`) — convention
+     * API Platform pour referencer une collection de ressources liees.
+     */
+    function buildCreatePayload(): Record<string, unknown> {
+        return {
+            name: name.value.trim(),
+            categoryTypes: categoryTypeIds.value.map(id => `/api/category_types/${id}`),
+        }
+    }
+
+    /**
+     * Traite une erreur API : 409 (doublon RG-1.07) → erreur inline sur `name`
+     * + toast ; sinon delegue a `useFormErrors.handleApiError` (422 mappe inline
+     * par champ sans toast, autre → toast de fallback). Retourne true si traitee
+     * inline (409/422 mappe), false si fallback toast.
+     */
+    function handleApiError(e: unknown, attemptedName: string): boolean {
+        const status = (e as ApiFetchError)?.response?.status
+
+        if (status === 409) {
+            const duplicateMessage = t('admin.categories.toast.duplicate', {
+                name: attemptedName,
+            })
+            formErrors.setError('name', duplicateMessage)
+            toast.error({ title: t('errors.title'), message: duplicateMessage })
+            return true
+        }
+
+        return formErrors.handleApiError(e, { fallbackMessage: t('errors.generic') })
+    }
+
+    /**
+     * POST /api/categories. Renvoie la categorie creee, ou `null` si la
+     * validation client a echoue ou si le serveur a renvoye une erreur. Le
+     * caller (drawer) decide quoi faire en fonction (fermer ou rester ouvert).
+     */
+    async function submitCreate(): Promise<Category | null> {
+        if (!validate()) return null
+        submitting.value = true
+        const payload = buildCreatePayload()
+        try {
+            const created = await api.post<Category>('/categories', payload, {
+                toast: false,
+            })
+            toast.success({
+                title: t('success.title'),
+                message: t('admin.categories.toast.created'),
+            })
+            return created
+        } catch (e) {
+            handleApiError(e, String(payload.name))
+            return null
+        } finally {
+            submitting.value = false
+        }
+    }
+
+    /**
+     * PATCH /api/categories/{id}. Envoie le payload complet (name +
+     * categoryTypes), comme les autres drawers du projet : le bouton
+     * Enregistrer sauvegarde a tout moment, meme sans modification, et renvoie
+     * toujours un retour (toast succes + refresh). Renvoie la categorie mise a
+     * jour, ou `null` en cas d'echec.
+     */
+    async function submitUpdate(id: number): Promise<Category | null> {
+        if (!validate()) return null
+        submitting.value = true
+        const payload: Record<string, unknown> = {
+            name: name.value.trim(),
+            categoryTypes: categoryTypeIds.value.map(id => `/api/category_types/${id}`),
+        }
+        try {
+            const updated = await api.patch<Category>(`/categories/${id}`, payload, {
+                toast: false,
+            })
+            toast.success({
+                title: t('success.title'),
+                message: t('admin.categories.toast.updated'),
+            })
+            return updated
+        } catch (e) {
+            const attemptedName = typeof payload.name === 'string'
+                ? payload.name
+                : name.value.trim()
+            handleApiError(e, attemptedName)
+            return null
+        } finally {
+            submitting.value = false
+        }
+    }
+
+    /**
+     * DELETE /api/categories/{id} → soft delete (RG-1.12). Le serveur pose
+     * `deleted_at = now()` et retourne 204. Renvoie true en cas de succes,
+     * false sinon (avec toast erreur deja affiche).
+     */
+    async function submitDelete(id: number): Promise<boolean> {
+        submitting.value = true
+        formErrors.clearErrors()
+        try {
+            await api.delete(`/categories/${id}`, {}, { toast: false })
+            toast.success({
+                title: t('success.title'),
+                message: t('admin.categories.toast.deleted'),
+            })
+            return true
+        } catch (e) {
+            handleApiError(e, name.value)
+            return false
+        } finally {
+            submitting.value = false
+        }
+    }
+
+    /**
+     * Reset complet du formulaire — utilise par le drawer apres save ou
+     * fermeture pour ne pas garder de donnees stale entre deux ouvertures.
+     */
+    function reset(): void {
+        name.value = ''
+        categoryTypeIds.value = []
+        initialName.value = ''
+        initialCategoryTypeIds.value = []
+        formErrors.clearErrors()
+        submitting.value = false
+    }
+
+    return {
+        // State
+        name,
+        categoryTypeIds,
+        errors: formErrors.errors,
+        submitting,
+        isDirty,
+        // Methods
+        loadFrom,
+        validate,
+        submitCreate,
+        submitUpdate,
+        submitDelete,
+        reset,
+    }
+}

frontend/modules/catalog/nuxt.config.ts

@@ -0,0 +1 @@
+export default defineNuxtConfig({})

frontend/modules/catalog/pages/admin/categories.vue

@@ -0,0 +1,303 @@
+<template>
+    <div>
+        <PageHeader>
+            {{ t('admin.categories.title') }}
+            <template #actions>
+                <!-- gap-8 = 32px d'espacement entre Filtres et Ajouter (meme
+                     design que le Repertoire Clients). -->
+                <div class="flex items-center gap-8">
+                    <!-- Bouton Filtres a GAUCHE d'Ajouter. Le compteur reflete
+                         les filtres actifs. -->
+                    <MalioButton
+                        variant="tertiary"
+                        :label="filterButtonLabel"
+                        icon-name="mdi:tune"
+                        icon-position="left"
+                        icon-size="24"
+                        @click="openFilters"
+                    />
+                    <MalioButton
+                        v-if="canManage"
+                        variant="secondary"
+                        :label="t('admin.categories.newCategory')"
+                        icon-name="mdi:add-bold"
+                        icon-position="left"
+                        @click="openCreateDrawer"
+                    />
+                </div>
+            </template>
+        </PageHeader>
+
+        <!-- Table des categories. Tri serveur (name ASC, RG-1.10) +
+             pagination serveur via usePaginatedList (#73). Le composable
+             remplace l'ancien chargement « tout en un coup » a volumetrie
+             cible ≤ 300 — la pagination est desormais alignee sur la regle
+             projet (toute collection paginee, regle ABSOLUE n°13). -->
+        <MalioDataTable
+            :columns="columns"
+            :items="categoryItems"
+            :total-items="totalItems"
+            :page="currentPage"
+            :per-page="itemsPerPage"
+            :per-page-options="itemsPerPageOptions"
+            :row-clickable="true"
+            :empty-message="t('admin.categories.noCategories')"
+            @row-click="onRowClick"
+            @update:page="goToPage"
+            @update:per-page="setItemsPerPage"
+        />
+
+        <!-- Drawer creation / consultation / edition. -->
+        <CategoryDrawer
+            v-model="drawerOpen"
+            :category="selectedCategory"
+            @saved="onCategorySaved"
+            @delete="onDeleteRequest"
+        />
+
+        <!-- Modale de confirmation suppression (soft delete cote serveur). -->
+        <CategoryDeleteModal
+            v-model="deleteModalOpen"
+            :category-name="categoryToDelete?.name ?? ''"
+            :loading="deleting"
+            @confirm="handleDelete"
+        />
+
+        <!-- Drawer de filtres : etat BROUILLON, applique uniquement au clic sur
+             « Appliquer ». Meme pattern que le Repertoire Clients. Etat 100 %
+             local, jamais dans l'URL (regle ABSOLUE n°6). -->
+        <MalioDrawer
+            v-model="filterDrawerOpen"
+            drawer-class="max-w-[450px]"
+            body-class="p-0"
+            footer-class="justify-between border-t border-black p-6"
+        >
+            <template #header>
+                <h2 class="text-[24px] font-bold uppercase">{{ t('admin.categories.filters.title') }}</h2>
+            </template>
+
+            <MalioAccordion>
+                <!-- Recherche par nom (param `name`, partiel insensible a la casse). -->
+                <MalioAccordionItem :title="t('admin.categories.filters.search')" value="search">
+                    <MalioInputText
+                        v-model="draftSearch"
+                        icon-name="mdi:magnify"
+                    />
+                </MalioAccordionItem>
+
+                <!-- Type(s) : cases a cocher (multi). Une categorie remonte si
+                     elle porte AU MOINS UN des types coches (OR cote back). -->
+                <MalioAccordionItem :title="t('admin.categories.filters.types')" value="types">
+                    <div class="flex flex-col">
+                        <MalioCheckbox
+                            v-for="opt in typeFilterOptions"
+                            :id="`filter-type-${opt.value}`"
+                            :key="opt.value"
+                            :label="opt.label"
+                            :model-value="draftTypeIds.includes(opt.value)"
+                            @update:model-value="(val: boolean) => toggleType(opt.value, val)"
+                        />
+                    </div>
+                </MalioAccordionItem>
+            </MalioAccordion>
+
+            <template #footer>
+                <MalioButton
+                    variant="tertiary"
+                    :label="t('admin.categories.filters.reset')"
+                    button-class="w-m-btn-action"
+                    @click="resetFilters"
+                />
+                <MalioButton
+                    variant="primary"
+                    :label="t('admin.categories.filters.apply')"
+                    button-class="w-[170px]"
+                    @click="applyFilters"
+                />
+            </template>
+        </MalioDrawer>
+    </div>
+</template>
+
+<script setup lang="ts">
+import type { Category } from '~/modules/catalog/types/category'
+
+const { t } = useI18n()
+const { can } = usePermissions()
+const { types, fetchTypes } = useCategoriesAdmin()
+const { submitDelete } = useCategoryForm()
+
+useHead({ title: t('admin.categories.title') })
+
+const canManage = computed(() => can('catalog.categories.manage'))
+
+// Pagination serveur via le composable partage (#73). Le CategoryProvider
+// applique deja name ASC (RG-1.10) — pas besoin de defaultSort cote front
+// tant qu'aucun OrderFilter n'est expose.
+const {
+    items: categories,
+    totalItems,
+    currentPage,
+    itemsPerPage,
+    itemsPerPageOptions,
+    fetch: fetchCategories,
+    goToPage,
+    setItemsPerPage,
+    setFilters,
+} = usePaginatedList<Category>({ url: '/categories' })
+
+const drawerOpen = ref(false)
+const selectedCategory = ref<Category | null>(null)
+const deleteModalOpen = ref(false)
+const categoryToDelete = ref<Category | null>(null)
+const deleting = ref(false)
+
+// Colonnes du datatable. Les types sont embarques cote API (ManyToMany) — on
+// aplatit en libelles joints par une virgule pour l'affichage.
+const columns = [
+    { key: 'name', label: t('admin.categories.table.name') },
+    { key: 'typesLabel', label: t('admin.categories.table.types') },
+]
+
+const categoryItems = computed(() =>
+    categories.value.map(cat => ({
+        id: cat.id,
+        name: cat.name,
+        typesLabel: (cat.categoryTypes ?? []).map(ct => ct.label).join(', '),
+    })),
+)
+
+// ── Filtres (drawer) ────────────────────────────────────────────────────────
+// Deux niveaux d'etat (pattern Repertoire Clients) :
+//  - APPLIED : pilote la liste + le compteur du bouton. Modifie uniquement au
+//    clic « Appliquer » / « Réinitialiser ».
+//  - DRAFT : edite librement dans le drawer ; recopie vers applied a la validation.
+const filterDrawerOpen = ref(false)
+
+const draftSearch = ref('')
+const draftTypeIds = ref<number[]>([])
+
+const appliedSearch = ref('')
+const appliedTypeIds = ref<number[]>([])
+
+// Options du filtre Type(s), derivees du referentiel deja charge (fetchTypes).
+const typeFilterOptions = computed(() =>
+    types.value.map(ct => ({ value: ct.id, label: ct.label })),
+)
+
+const activeFilterCount = computed(() => {
+    let count = 0
+    if (appliedSearch.value.trim() !== '') count++
+    if (appliedTypeIds.value.length > 0) count++
+    return count
+})
+
+const filterButtonLabel = computed(() => {
+    const base = t('admin.categories.filters.title')
+    return activeFilterCount.value > 0 ? `${base} (${activeFilterCount.value})` : base
+})
+
+// Recopie l'etat applique vers le brouillon puis ouvre le drawer.
+function openFilters(): void {
+    draftSearch.value = appliedSearch.value
+    draftTypeIds.value = [...appliedTypeIds.value]
+    filterDrawerOpen.value = true
+}
+
+function toggleType(id: number, selected: boolean): void {
+    draftTypeIds.value = selected
+        ? [...draftTypeIds.value, id]
+        : draftTypeIds.value.filter(t => t !== id)
+}
+
+/**
+ * Construit le payload de filtres serveur a partir de l'etat applique. Cle
+ * `typeId[]` pour que PHP la parse en tableau (OR cote back). Filtres vides omis.
+ */
+function buildFilterPayload(): Record<string, string | string[]> {
+    const payload: Record<string, string | string[]> = {}
+    if (appliedSearch.value.trim() !== '') payload.name = appliedSearch.value.trim()
+    if (appliedTypeIds.value.length > 0) payload['typeId[]'] = appliedTypeIds.value.map(String)
+    return payload
+}
+
+// « Appliquer » : recopie brouillon → applied, pousse les filtres (retombe en
+// page 1 via usePaginatedList) et ferme le drawer.
+function applyFilters(): void {
+    appliedSearch.value = draftSearch.value.trim()
+    appliedTypeIds.value = [...draftTypeIds.value]
+
+    setFilters(buildFilterPayload(), { replace: true })
+    filterDrawerOpen.value = false
+}
+
+// « Réinitialiser » : vide brouillon ET applied, recharge la liste complete.
+// Le drawer reste ouvert pour montrer le formulaire vide.
+function resetFilters(): void {
+    draftSearch.value = ''
+    draftTypeIds.value = []
+    appliedSearch.value = ''
+    appliedTypeIds.value = []
+
+    setFilters({}, { replace: true })
+}
+
+function getCategoryById(id: number): Category | undefined {
+    return categories.value.find(c => c.id === id)
+}
+
+function onRowClick(item: Record<string, unknown>) {
+    const category = getCategoryById(item.id as number)
+    if (category) openEditDrawer(category)
+}
+
+function openCreateDrawer() {
+    selectedCategory.value = null
+    drawerOpen.value = true
+}
+
+function openEditDrawer(category: Category) {
+    selectedCategory.value = category
+    drawerOpen.value = true
+}
+
+function onDeleteRequest() {
+    if (!selectedCategory.value) return
+    categoryToDelete.value = selectedCategory.value
+    deleteModalOpen.value = true
+}
+
+/**
+ * Soft delete via le composable de form (qui gere toast + erreur). Refresh
+ * de la liste a la fin pour retirer la ligne. L'index unique partiel
+ * autorise une recreation ulterieure avec le meme couple (name, type) —
+ * RG-1.07.
+ */
+async function handleDelete(): Promise<void> {
+    if (!categoryToDelete.value) return
+    deleting.value = true
+    try {
+        const ok = await submitDelete(categoryToDelete.value.id)
+        if (ok) {
+            deleteModalOpen.value = false
+            categoryToDelete.value = null
+            drawerOpen.value = false
+            await fetchCategories()
+        }
+    } finally {
+        deleting.value = false
+    }
+}
+
+function onCategorySaved() {
+    fetchCategories()
+}
+
+// Chargement initial des deux ressources (liste + referentiel des types).
+// Le referentiel est pre-charge ici (et pas dans le drawer) pour que le
+// select soit pret au moment ou l'utilisateur clique sur « + Ajouter ».
+onMounted(() => {
+    fetchCategories()
+    fetchTypes()
+})
+</script>

frontend/modules/catalog/types/category.ts

@@ -0,0 +1,72 @@
+/**
+ * Types front du module Catalog (M0 — Gestion des categories).
+ *
+ * Contrats API consommes :
+ *   - GET /api/categories          → HydraCollection<Category>
+ *   - GET /api/categories/{id}     → Category
+ *   - POST /api/categories         → body { name, categoryTypes: IRI[] }
+ *   - PATCH /api/categories/{id}   → body partiel { name?, categoryTypes?: IRI[] }
+ *   - DELETE /api/categories/{id}  → 204 (soft delete via CategoryProcessor)
+ *   - GET /api/category_types      → HydraCollection<CategoryType>
+ *
+ * Notes :
+ *   - Les IRI sont envoyes en POST/PATCH (ex. ["/api/category_types/3"]).
+ *   - `categoryTypes` est embarque (groupe Serializer `category:read` sur les
+ *     proprietes de CategoryType) : tableau d'objets type en lecture.
+ *   - `createdBy` / `updatedBy` peuvent etre `null` (hors contexte HTTP,
+ *     ON DELETE SET NULL en BDD). Affichage : libelle "Systeme" si null.
+ */
+
+/**
+ * Reference legere d'un user, telle qu'embarquee dans Category.createdBy /
+ * updatedBy. Volontairement minimaliste : on n'a besoin que de l'identifiant
+ * et de l'username pour l'affichage courant.
+ */
+export interface User {
+    id: number
+    username: string
+}
+
+/**
+ * Reference du referentiel CategoryType (lecture seule au M0).
+ */
+export interface CategoryType {
+    id: number
+    code: string
+    label: string
+}
+
+/**
+ * Categorie metier — telle qu'elle est lue depuis l'API. L'entite porte le
+ * pattern Timestampable+Blamable (cf. spec-back § 2.8).
+ */
+export interface Category {
+    id: number
+    name: string
+    /** Types de la categorie (>= 1, ManyToMany embarque en lecture). */
+    categoryTypes: CategoryType[]
+    /** Soft delete : null = active, valeur = supprimee logiquement le {date}. */
+    deletedAt: string | null
+    createdAt: string
+    updatedAt: string
+    createdBy: User | null
+    updatedBy: User | null
+}
+
+/**
+ * Payload accepte en POST /api/categories. `categoryTypes` est un tableau
+ * d'IRI Hydra (ex. `['/api/category_types/3', '/api/category_types/5']`).
+ */
+export interface CategoryCreateInput {
+    name: string
+    categoryTypes: string[]
+}
+
+/**
+ * Payload accepte en PATCH /api/categories/{id}. Tous les champs sont
+ * optionnels (modification partielle).
+ */
+export interface CategoryUpdateInput {
+    name?: string
+    categoryTypes?: string[]
+}

frontend/modules/commercial/components/ClientAddressBlock.vue

@@ -0,0 +1,372 @@
+<template>
+    <div class="relative grid grid-cols-4 gap-x-[44px] gap-y-4 bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+        <!-- ariaLabel via v-bind objet (prop camelCase ; aria-* serait un attribut HTML). -->
+        <MalioButtonIcon
+            v-if="removable && !readonly"
+            icon="mdi:delete-outline"
+            variant="ghost"
+            button-class="absolute top-3 right-3"
+            v-bind="{ ariaLabel: t('commercial.clients.form.address.remove') }"
+            @click="$emit('remove')"
+        />
+
+        <!-- Usage de l'adresse : Select unique (plus simple pour l'utilisateur)
+             remplacant les 3 cases. Les options encodent les combinaisons valides
+             (exclusivite Prospect, RG-1.06/07/08) ; le back recoit toujours les
+             drapeaux isProspect / isDelivery / isBilling (aucune RG modifiee). -->
+        <!-- Erreur portee sur `isProspect` cote back (Callback type obligatoire +
+             exclusivite prospect) -> affichee sous le select Type d'adresse. -->
+        <MalioSelect
+            :model-value="addressType"
+            :options="addressTypeOptions"
+            :label="t('commercial.clients.form.address.addressType')"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.isProspect"
+            @update:model-value="onAddressTypeChange"
+        />
+
+        <!-- Sites Starseed : multiselect a tags (>= 1 obligatoire, RG-1.10). -->
+        <MalioSelectCheckbox
+            :model-value="model.siteIris"
+            :options="siteOptions"
+            :label="t('commercial.clients.form.address.sites')"
+            :display-tag="true"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.sites"
+            @update:model-value="(v: (string | number)[]) => update('siteIris', v.map(String))"
+        />
+
+        <MalioSelectCheckbox
+            :model-value="model.contactIris"
+            :options="contactOptions"
+            :label="t('commercial.clients.form.address.contacts')"
+            :display-tag="true"
+            :readonly="readonly"
+            @update:model-value="(v: (string | number)[]) => update('contactIris', v.map(String))"
+        />
+
+        <!-- Email(s) de facturation : visible/obligatoire seulement si Facturation
+             (RG-1.11). Le « + » revele un 2e email optionnel (max 2, pendant du
+             telephone secondaire) qui coule dans la grille. Sinon un filler comble
+             la colonne pour que Categorie reparte au debut de la ligne suivante. -->
+        <MalioInputEmail
+            v-if="isBillingEmailRequired(model)"
+            :model-value="model.billingEmail"
+            :label="t('commercial.clients.form.address.billingEmail')"
+            :required="true"
+            :readonly="readonly"
+            :lowercase="true"
+            :error="errors?.billingEmail"
+            :addable="!model.hasSecondaryBillingEmail && !readonly"
+            :add-button-label="t('commercial.clients.form.address.addBillingEmail')"
+            @update:model-value="(v: string) => update('billingEmail', v)"
+            @add="revealSecondaryBillingEmail"
+        />
+        <div v-else aria-hidden="true" />
+
+        <MalioInputEmail
+            v-if="isBillingEmailRequired(model) && model.hasSecondaryBillingEmail"
+            :model-value="model.billingEmailSecondary"
+            :label="t('commercial.clients.form.address.billingEmailSecondary')"
+            :readonly="readonly"
+            :lowercase="true"
+            :error="errors?.billingEmailSecondary"
+            @update:model-value="(v: string) => update('billingEmailSecondary', v)"
+        />
+
+        <MalioSelectCheckbox
+            :model-value="model.categoryIris"
+            :options="categoryOptions"
+            :label="t('commercial.clients.form.address.categories')"
+            :display-tag="true"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.categories"
+            @update:model-value="(v: (string | number)[]) => update('categoryIris', v.map(String))"
+        />
+
+        <MalioSelect
+            :model-value="model.country"
+            :options="countryOptions"
+            :label="t('commercial.clients.form.address.country')"
+            :readonly="readonly"
+            :required="true"
+            @update:model-value="(v: string | number | null) => update('country', String(v ?? 'France'))"
+        />
+
+        <MalioInputText
+            :model-value="model.postalCode"
+            :label="t('commercial.clients.form.address.postalCode')"
+            :mask="POSTAL_CODE_MASK"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.postalCode"
+            @update:model-value="onPostalCodeChange"
+        />
+
+        <!-- Ville : MalioSelect alimente par le code postal (BAN). Si la BAN est
+             indisponible, bascule en saisie libre — recuperable : re-saisir le
+             code postal relance la recherche et repasse en select au succes. -->
+        <MalioSelect
+            v-if="!degraded"
+            :model-value="model.city"
+            :options="cityOptions"
+            :label="t('commercial.clients.form.address.city')"
+            :readonly="readonly"
+            empty-option-label=""
+            :required="true"
+            :error="errors?.city"
+            @update:model-value="(v: string | number | null) => update('city', v === null ? null : String(v))"
+        />
+        <MalioInputText
+            v-else
+            :model-value="model.city"
+            :label="t('commercial.clients.form.address.city')"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.city"
+            @update:model-value="(v: string) => update('city', v)"
+        />
+
+        <!-- Adresse + Adresse complementaire sur 2 colonnes : on wrappe car
+             MalioInputText/Autocomplete (inheritAttrs:false) renvoient `class`
+             sur l'input interne, pas sur la cellule de grille. Le wrapper porte
+             le col-span-2, le champ le remplit (w-full). -->
+        <div class="col-span-2">
+            <!-- Adresse : saisie assistee (BAN) en edition ; champ texte simple
+                 seulement en lecture seule (MalioInputAutocomplete ne reaffiche pas
+                 sa valeur liee, il n'afficherait rien en readonly). allow-create :
+                 si la BAN ne propose rien (ou erreur), le texte saisi est CONSERVE au
+                 blur/Entree (saisie manuelle) — sinon il serait efface. La ville reste
+                 pilotee par le code postal ; choisir une suggestion remplit rue+ville+CP. -->
+            <MalioInputAutocomplete
+                v-if="!readonly"
+                :model-value="model.street"
+                :options="addressOptions"
+                :loading="addressLoading"
+                :min-search-length="3"
+                :label="t('commercial.clients.form.address.street')"
+                :readonly="readonly"
+                :required="true"
+                :error="errors?.street"
+                :allow-create="true"
+                :no-results-text="t('commercial.clients.form.address.streetNotFound')"
+                @update:model-value="(v: string | number | null) => update('street', v === null ? null : String(v))"
+                @search="onAddressSearch"
+                @select="onAddressSelect"
+            />
+            <MalioInputText
+                v-else
+                :model-value="model.street"
+                :label="t('commercial.clients.form.address.street')"
+                :readonly="readonly"
+                :required="true"
+                :error="errors?.street"
+                @update:model-value="(v: string) => update('street', v)"
+            />
+        </div>
+
+        <div class="col-span-1">
+            <MalioInputText
+                :model-value="model.streetComplement"
+                :label="t('commercial.clients.form.address.streetComplement')"
+                :readonly="readonly"
+                :error="errors?.streetComplement"
+                @update:model-value="(v: string) => update('streetComplement', v)"
+            />
+        </div>
+
+    </div>
+</template>
+
+<script setup lang="ts">
+import {
+    addressFlagsFromType,
+    addressTypeFromFlags,
+    isBillingEmailRequired,
+    type AddressType,
+} from '~/modules/commercial/utils/forms/clientFormRules'
+import { useAddressAutocomplete, type AddressSuggestion } from '~/shared/composables/useAddressAutocomplete'
+import type { CategoryOption, RefOption } from '~/modules/commercial/composables/useClientReferentials'
+import type { AddressFormDraft } from '~/modules/commercial/types/clientForm'
+
+// Masque code postal FR : 5 chiffres.
+const POSTAL_CODE_MASK = '#####'
+
+const props = defineProps<{
+    /** Brouillon de l'adresse (v-model). */
+    modelValue: AddressFormDraft
+    title: string
+    /** Categories autorisees sur une adresse (DISTRIBUTEUR/COURTIER exclus, RG-1.29). */
+    categoryOptions: CategoryOption[]
+    /** Sites Starseed disponibles. */
+    siteOptions: RefOption[]
+    /** Contacts deja saisis, rattachables a l'adresse. */
+    contactOptions: RefOption[]
+    /** Pays disponibles (France par defaut). */
+    countryOptions: RefOption[]
+    removable?: boolean
+    readonly?: boolean
+    /** Erreurs serveur 422 de cette ligne, indexees par champ (ERP-101). */
+    errors?: Record<string, string>
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: AddressFormDraft]
+    'remove': []
+    /** Emis une fois quand le service d'autocompletion bascule en indisponible. */
+    'degraded': []
+}>()
+
+const { t } = useI18n()
+const autocomplete = useAddressAutocomplete()
+
+const model = computed(() => props.modelValue)
+
+// Type d'adresse (Select unique) derive des drapeaux back. null tant qu'aucun
+// drapeau n'est pose -> champ vide + bouton « Valider » bloque (cf. parent).
+const addressType = computed<AddressType | null>(() => addressTypeFromFlags(model.value))
+
+const addressTypeOptions = computed<RefOption[]>(() => [
+    { value: 'prospect', label: t('commercial.clients.form.address.addressTypeProspect') },
+    { value: 'delivery', label: t('commercial.clients.form.address.addressTypeDelivery') },
+    { value: 'billing', label: t('commercial.clients.form.address.addressTypeBilling') },
+    { value: 'delivery_billing', label: t('commercial.clients.form.address.addressTypeDeliveryBilling') },
+    { value: 'broker', label: t('commercial.clients.form.address.addressTypeBroker') },
+    { value: 'distributor', label: t('commercial.clients.form.address.addressTypeDistributor') },
+])
+
+/** Applique le type choisi en repercutant les 3 drapeaux back (immutabilite). */
+function onAddressTypeChange(value: string | number | null): void {
+    if (value === null) return
+    emit('update:modelValue', { ...props.modelValue, ...addressFlagsFromType(value as AddressType) })
+}
+
+// Repli saisie libre de la VILLE quand la BAN est indisponible (recuperable :
+// remis a false des qu'une recherche de ville aboutit). N'affecte plus le champ
+// Adresse, qui reste en autocompletion et reessaie a chaque frappe.
+const degraded = ref(false)
+// Avertissement « service indisponible » envoye au parent une seule fois.
+let unavailableNotified = false
+// Villes proposees par la BAN (alimentees a la saisie du code postal).
+const banCityOptions = ref<RefOption[]>([])
+// Adresses proposees par la BAN (alimentees a la saisie d'adresse).
+const banAddressOptions = ref<RefOption[]>([])
+
+// Options ville effectives : on garantit que la ville courante figure toujours
+// dans la liste, sinon MalioSelect (qui resout le libelle depuis ses options)
+// afficherait un champ vide en lecture seule (consultation 1.11) ou en edition
+// d'une adresse existante (1.12), ou la BAN n'a pas (re)peuple les suggestions.
+const cityOptions = computed<RefOption[]>(() => {
+    const current = props.modelValue.city
+    if (current && !banCityOptions.value.some(o => o.value === current)) {
+        return [{ value: current, label: current }, ...banCityOptions.value]
+    }
+    return banCityOptions.value
+})
+
+// Meme garantie que cityOptions pour le champ Adresse : la rue courante doit
+// toujours figurer dans les options, sinon MalioInputAutocomplete (qui resout
+// l'affichage depuis ses options) laisse le champ VIDE des que la liste de
+// suggestions BAN est vide — typiquement juste apres validation (remontage) ou
+// a l'edition d'une adresse existante (1.12), alors que la valeur est bien
+// persistee. On reinjecte donc la rue liee si la BAN ne l'a pas (re)proposee.
+const addressOptions = computed<RefOption[]>(() => {
+    const current = props.modelValue.street
+    if (current && !banAddressOptions.value.some(o => o.value === current)) {
+        return [{ value: current, label: current }, ...banAddressOptions.value]
+    }
+    return banAddressOptions.value
+})
+const addressLoading = ref(false)
+// Conserve les suggestions d'adresse pour retrouver ville/CP au moment du select.
+let lastAddressSuggestions: AddressSuggestion[] = []
+
+/** Emet un nouveau brouillon avec le champ modifie (immutabilite). */
+function update<K extends keyof AddressFormDraft>(field: K, value: AddressFormDraft[K]): void {
+    emit('update:modelValue', { ...props.modelValue, [field]: value })
+}
+
+/** Revele le 2e champ email de facturation (clic sur le « + »). */
+function revealSecondaryBillingEmail(): void {
+    emit('update:modelValue', { ...props.modelValue, hasSecondaryBillingEmail: true })
+}
+
+/** Previent le parent (toast unique) que l'autocompletion est indisponible. */
+function notifyUnavailable(): void {
+    if (!unavailableNotified) {
+        unavailableNotified = true
+        emit('degraded')
+    }
+}
+
+/** Saisie du code postal → met a jour le champ + interroge la BAN pour la ville. */
+async function onPostalCodeChange(value: string): Promise<void> {
+    update('postalCode', value)
+
+    const digits = (value ?? '').replace(/\D/g, '')
+    if (digits.length < 5) {
+        return
+    }
+    try {
+        const suggestions = await autocomplete.searchCity(digits)
+        banCityOptions.value = suggestions.map(s => ({ value: s.city, label: s.city }))
+        // Service repondu : on (re)passe la Ville en select assiste.
+        degraded.value = false
+    }
+    catch {
+        // BAN indispo : Ville en saisie libre (recuperable au prochain essai).
+        degraded.value = true
+        notifyUnavailable()
+    }
+}
+
+/** Recherche d'adresse assistee (event de MalioInputAutocomplete). */
+async function onAddressSearch(query: string): Promise<void> {
+    // La BAN exige au moins 3 caracteres : on n'envoie rien en deca (evite un 400)
+    // et on vide les suggestions devenues obsoletes.
+    if (query.trim().length < 3) {
+        banAddressOptions.value = []
+        return
+    }
+    addressLoading.value = true
+    try {
+        const postalCode = (model.value.postalCode ?? '').replace(/\D/g, '') || undefined
+        const suggestions = await autocomplete.searchAddress(query, postalCode)
+        lastAddressSuggestions = suggestions
+        banAddressOptions.value = suggestions.map(s => ({ value: s.street, label: s.label }))
+    }
+    catch {
+        // Erreur transitoire : on vide les suggestions, la prochaine frappe reessaie
+        // (pas de bascule definitive — c'etait le bug). Avertissement une seule fois.
+        banAddressOptions.value = []
+        notifyUnavailable()
+    }
+    finally {
+        addressLoading.value = false
+    }
+}
+
+/**
+ * Selection d'une suggestion d'adresse → remplit rue + ville + CP.
+ * Le type d'option suit le contrat MalioInputAutocomplete ({ label, value }).
+ */
+function onAddressSelect(option: { label: string, value: string | number } | null): void {
+    if (option === null) {
+        return
+    }
+    const suggestion = lastAddressSuggestions.find(s => s.street === option.value)
+    if (!suggestion) {
+        update('street', String(option.value))
+        return
+    }
+    emit('update:modelValue', {
+        ...props.modelValue,
+        street: suggestion.street,
+        city: suggestion.city,
+        postalCode: suggestion.postalCode,
+    })
+}
+</script>

frontend/modules/commercial/components/ClientContactBlock.vue

@@ -0,0 +1,111 @@
+<template>
+    <div class="relative grid grid-cols-4 gap-x-[44px] gap-y-4 bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+        <!-- Suppression : ouvre une modal de confirmation cote parent. Masquee si
+             non supprimable (1er bloc obligatoire RG-1.14) ou en lecture seule.
+             ariaLabel via v-bind objet (prop camelCase ; aria-* serait un attribut HTML). -->
+        <MalioButtonIcon
+            v-if="removable && !readonly"
+            icon="mdi:delete-outline"
+            variant="ghost"
+            button-class="absolute top-3 right-3"
+            v-bind="{ ariaLabel: t('commercial.clients.form.contact.remove') }"
+            @click="$emit('remove')"
+        />
+
+        <MalioInputText
+            :model-value="model.lastName"
+            :label="t('commercial.clients.form.contact.lastName')"
+            :readonly="readonly"
+            :error="errors?.lastName"
+            @update:model-value="(v: string) => update('lastName', v)"
+        />
+        <MalioInputText
+            :model-value="model.firstName"
+            :label="t('commercial.clients.form.contact.firstName')"
+            :readonly="readonly"
+            :error="errors?.firstName"
+            @update:model-value="(v: string) => update('firstName', v)"
+        />
+        <!-- Fonction sur 2 colonnes : on wrappe car MalioInputText
+             (inheritAttrs:false) renvoie `class` sur l'input interne, pas sur la
+             cellule de grille. Le wrapper porte le col-span-2, le champ le remplit. -->
+        <div class="col-span-2">
+            <MalioInputText
+                :model-value="model.jobTitle"
+                :label="t('commercial.clients.form.contact.jobTitle')"
+                :readonly="readonly"
+                :error="errors?.jobTitle"
+                @update:model-value="(v: string) => update('jobTitle', v)"
+            />
+        </div>
+        <MalioInputEmail
+            :model-value="model.email"
+            :label="t('commercial.clients.form.contact.email')"
+            :readonly="readonly"
+            :lowercase="true"
+            :error="errors?.email"
+            @update:model-value="(v: string) => update('email', v)"
+        />
+        <MalioInputPhone
+            :model-value="model.phonePrimary"
+            :label="t('commercial.clients.form.contact.phonePrimary')"
+            :mask="PHONE_MASK"
+            :readonly="readonly"
+            :error="errors?.phonePrimary"
+            :addable="!model.hasSecondaryPhone && !readonly"
+            :add-button-label="t('commercial.clients.form.contact.addPhone')"
+            @update:model-value="(v: string) => update('phonePrimary', v)"
+            @add="revealSecondaryPhone"
+        />
+        <MalioInputPhone
+            v-if="model.hasSecondaryPhone"
+            :model-value="model.phoneSecondary"
+            :label="t('commercial.clients.form.contact.phoneSecondary')"
+            :mask="PHONE_MASK"
+            :readonly="readonly"
+            :error="errors?.phoneSecondary"
+            @update:model-value="(v: string) => update('phoneSecondary', v)"
+        />
+    </div>
+</template>
+
+<script setup lang="ts">
+import type { ContactFormDraft } from '~/modules/commercial/types/clientForm'
+
+// Masque telephone FR : 5 groupes de 2 chiffres (la normalisation finale reste
+// serveur, cf. formatPhoneFR re-applique a la valeur renvoyee).
+const PHONE_MASK = '## ## ## ## ##'
+
+const props = defineProps<{
+    /** Brouillon du contact (v-model). */
+    modelValue: ContactFormDraft
+    /** Titre du bloc (ex: « Contact 1 »). */
+    title: string
+    /** Affiche l'icone de suppression (1er bloc non supprimable, RG-1.14). */
+    removable?: boolean
+    /** Bloc en lecture seule (onglet valide). */
+    readonly?: boolean
+    /** Erreurs serveur 422 de cette ligne, indexees par champ (ERP-101). */
+    errors?: Record<string, string>
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: ContactFormDraft]
+    'remove': []
+}>()
+
+const { t } = useI18n()
+
+// Alias local pour la lisibilite du template.
+const model = computed(() => props.modelValue)
+
+/** Emet un nouveau brouillon avec le champ modifie (immutabilite). */
+function update<K extends keyof ContactFormDraft>(field: K, value: ContactFormDraft[K]): void {
+    emit('update:modelValue', { ...props.modelValue, [field]: value })
+}
+
+/** Revele le 2e numero (RG-1.02/1.20 : max 1 secondaire, le « + » disparait). */
+function revealSecondaryPhone(): void {
+    emit('update:modelValue', { ...props.modelValue, hasSecondaryPhone: true })
+}
+</script>

frontend/modules/commercial/components/SupplierAddressBlock.vue

@@ -0,0 +1,314 @@
+<template>
+    <div class="relative grid grid-cols-4 gap-x-[44px] gap-y-4 bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+        <!-- Suppression : modal de confirmation cote parent. -->
+        <MalioButtonIcon
+            v-if="removable && !readonly"
+            icon="mdi:delete-outline"
+            variant="ghost"
+            button-class="absolute top-3 right-3"
+            v-bind="{ ariaLabel: t('commercial.suppliers.form.address.remove') }"
+            @click="$emit('remove')"
+        />
+
+        <!-- Type d'adresse : Prospect / Depart / Rendu (RG-2.09). Select en attendant
+             l'arbitrage metier (radio vs select) ; l'erreur 422 (propertyPath
+             `addressType`) s'affiche via la prop native :error de MalioSelect. -->
+        <MalioSelect
+            :model-value="model.addressType"
+            :options="addressTypeOptions"
+            :label="t('commercial.suppliers.form.address.addressType')"
+            :readonly="readonly"
+            empty-option-label=""
+            :required="true"
+            :error="errors?.addressType"
+            @update:model-value="(v: string | number | null) => update('addressType', v === null ? null : (v as SupplierAddressType))"
+        />
+
+        <!-- Sites Starseed : multiselect a tags (>= 1 obligatoire, RG-2.06). -->
+        <MalioSelectCheckbox
+            :model-value="model.siteIris"
+            :options="siteOptions"
+            :label="t('commercial.suppliers.form.address.sites')"
+            :display-tag="true"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.sites"
+            @update:model-value="(v: (string | number)[]) => update('siteIris', v.map(String))"
+        />
+
+        <!-- Contacts rattaches (M2M, facultatif). -->
+        <MalioSelectCheckbox
+            :model-value="model.contactIris"
+            :options="contactOptions"
+            :label="t('commercial.suppliers.form.address.contacts')"
+            :display-tag="true"
+            :readonly="readonly"
+            @update:model-value="(v: (string | number)[]) => update('contactIris', v.map(String))"
+        />
+
+        <!-- Filler : aligne le debut de ligne suivant sur la grille (le bloc client
+             porte ici l'email de facturation, absent cote fournisseur). -->
+        <div aria-hidden="true" />
+
+        <!-- Categories de type FOURNISSEUR (>= 1 obligatoire, RG-2.10). -->
+        <MalioSelectCheckbox
+            :model-value="model.categoryIris"
+            :options="categoryOptions"
+            :label="t('commercial.suppliers.form.address.categories')"
+            :display-tag="true"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.categories"
+            @update:model-value="(v: (string | number)[]) => update('categoryIris', v.map(String))"
+        />
+
+        <MalioSelect
+            :model-value="model.country"
+            :options="countryOptions"
+            :label="t('commercial.suppliers.form.address.country')"
+            :readonly="readonly"
+            :required="true"
+            @update:model-value="(v: string | number | null) => update('country', String(v ?? 'France'))"
+        />
+
+        <MalioInputText
+            :model-value="model.postalCode"
+            :label="t('commercial.suppliers.form.address.postalCode')"
+            :mask="POSTAL_CODE_MASK"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.postalCode"
+            @update:model-value="onPostalCodeChange"
+        />
+
+        <!-- Ville : MalioSelect alimente par le code postal (BAN). Saisie libre si BAN indispo. -->
+        <MalioSelect
+            v-if="!degraded"
+            :model-value="model.city"
+            :options="cityOptions"
+            :label="t('commercial.suppliers.form.address.city')"
+            :readonly="readonly"
+            empty-option-label=""
+            :required="true"
+            :error="errors?.city"
+            @update:model-value="(v: string | number | null) => update('city', v === null ? null : String(v))"
+        />
+        <MalioInputText
+            v-else
+            :model-value="model.city"
+            :label="t('commercial.suppliers.form.address.city')"
+            :readonly="readonly"
+            :required="true"
+            :error="errors?.city"
+            @update:model-value="(v: string) => update('city', v)"
+        />
+
+        <!-- Adresse (BAN) sur 2 colonnes + Adresse complementaire. allow-create : le
+             texte saisi est conserve si la BAN ne propose rien (saisie manuelle). -->
+        <div class="col-span-2">
+            <MalioInputAutocomplete
+                v-if="!readonly"
+                :model-value="model.street"
+                :options="addressOptions"
+                :loading="addressLoading"
+                :min-search-length="3"
+                :label="t('commercial.suppliers.form.address.street')"
+                :readonly="readonly"
+                :required="true"
+                :error="errors?.street"
+                :allow-create="true"
+                :no-results-text="t('commercial.suppliers.form.address.streetNotFound')"
+                @update:model-value="(v: string | number | null) => update('street', v === null ? null : String(v))"
+                @search="onAddressSearch"
+                @select="onAddressSelect"
+            />
+            <MalioInputText
+                v-else
+                :model-value="model.street"
+                :label="t('commercial.suppliers.form.address.street')"
+                :readonly="readonly"
+                :required="true"
+                :error="errors?.street"
+                @update:model-value="(v: string) => update('street', v)"
+            />
+        </div>
+
+        <div class="col-span-1">
+            <MalioInputText
+                :model-value="model.streetComplement"
+                :label="t('commercial.suppliers.form.address.streetComplement')"
+                :readonly="readonly"
+                :error="errors?.streetComplement"
+                @update:model-value="(v: string) => update('streetComplement', v)"
+            />
+        </div>
+
+        <!-- Bennes : stepper (specifique fournisseur, defaut 0). -->
+        <MalioInputNumber
+            :model-value="model.bennes"
+            :label="t('commercial.suppliers.form.address.bennes')"
+            :min="0"
+            :readonly="readonly"
+            :error="errors?.bennes"
+            @update:model-value="(v: string) => update('bennes', v)"
+        />
+
+        <!-- Prestation de triage : booleen porte par l'adresse (specifique fournisseur). -->
+        <MalioCheckbox
+            id="address-triage-provider"
+            :label="t('commercial.suppliers.form.address.triageProvider')"
+            :model-value="model.triageProvider"
+            group-class="self-center"
+            :readonly="readonly"
+            @update:model-value="(v: boolean) => update('triageProvider', v)"
+        />
+    </div>
+</template>
+
+<script setup lang="ts">
+import { useAddressAutocomplete, type AddressSuggestion } from '~/shared/composables/useAddressAutocomplete'
+import type { CategoryOption, RefOption } from '~/modules/commercial/composables/useSupplierReferentials'
+import type { SupplierAddressFormDraft, SupplierAddressType } from '~/modules/commercial/types/supplierForm'
+
+// Masque code postal FR : 5 chiffres.
+const POSTAL_CODE_MASK = '#####'
+
+const props = defineProps<{
+    /** Brouillon de l'adresse (v-model). */
+    modelValue: SupplierAddressFormDraft
+    title: string
+    /** Categories autorisees sur une adresse (type FOURNISSEUR). */
+    categoryOptions: CategoryOption[]
+    /** Sites Starseed disponibles. */
+    siteOptions: RefOption[]
+    /** Contacts deja saisis, rattachables a l'adresse. */
+    contactOptions: RefOption[]
+    /** Pays disponibles (France par defaut). */
+    countryOptions: RefOption[]
+    removable?: boolean
+    readonly?: boolean
+    /** Erreurs serveur 422 de cette ligne, indexees par champ (ERP-101). */
+    errors?: Record<string, string>
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: SupplierAddressFormDraft]
+    'remove': []
+    /** Emis une fois quand le service d'autocompletion bascule en indisponible. */
+    'degraded': []
+}>()
+
+const { t } = useI18n()
+const autocomplete = useAddressAutocomplete()
+
+const model = computed(() => props.modelValue)
+
+const addressTypeOptions = computed<{ value: SupplierAddressType, label: string }[]>(() => [
+    { value: 'PROSPECT', label: t('commercial.suppliers.form.address.addressTypeProspect') },
+    { value: 'DEPART', label: t('commercial.suppliers.form.address.addressTypeDepart') },
+    { value: 'RENDU', label: t('commercial.suppliers.form.address.addressTypeRendu') },
+])
+
+// Repli saisie libre de la VILLE quand la BAN est indisponible (recuperable).
+const degraded = ref(false)
+let unavailableNotified = false
+const banCityOptions = ref<RefOption[]>([])
+const banAddressOptions = ref<RefOption[]>([])
+
+// Options ville effectives : on garantit que la ville courante figure toujours
+// dans la liste, sinon MalioSelect afficherait un champ vide en lecture seule.
+const cityOptions = computed<RefOption[]>(() => {
+    const current = props.modelValue.city
+    if (current && !banCityOptions.value.some(o => o.value === current)) {
+        return [{ value: current, label: current }, ...banCityOptions.value]
+    }
+    return banCityOptions.value
+})
+
+// Meme garantie pour le champ Adresse : la rue courante doit toujours figurer
+// dans les options, sinon MalioInputAutocomplete laisse le champ vide.
+const addressOptions = computed<RefOption[]>(() => {
+    const current = props.modelValue.street
+    if (current && !banAddressOptions.value.some(o => o.value === current)) {
+        return [{ value: current, label: current }, ...banAddressOptions.value]
+    }
+    return banAddressOptions.value
+})
+const addressLoading = ref(false)
+// Conserve les suggestions d'adresse pour retrouver ville/CP au moment du select.
+let lastAddressSuggestions: AddressSuggestion[] = []
+
+/** Emet un nouveau brouillon avec le champ modifie (immutabilite). */
+function update<K extends keyof SupplierAddressFormDraft>(field: K, value: SupplierAddressFormDraft[K]): void {
+    emit('update:modelValue', { ...props.modelValue, [field]: value })
+}
+
+/** Previent le parent (toast unique) que l'autocompletion est indisponible. */
+function notifyUnavailable(): void {
+    if (!unavailableNotified) {
+        unavailableNotified = true
+        emit('degraded')
+    }
+}
+
+/** Saisie du code postal → met a jour le champ + interroge la BAN pour la ville. */
+async function onPostalCodeChange(value: string): Promise<void> {
+    update('postalCode', value)
+
+    const digits = (value ?? '').replace(/\D/g, '')
+    if (digits.length < 5) {
+        return
+    }
+    try {
+        const suggestions = await autocomplete.searchCity(digits)
+        banCityOptions.value = suggestions.map(s => ({ value: s.city, label: s.city }))
+        degraded.value = false
+    }
+    catch {
+        degraded.value = true
+        notifyUnavailable()
+    }
+}
+
+/** Recherche d'adresse assistee (event de MalioInputAutocomplete). */
+async function onAddressSearch(query: string): Promise<void> {
+    // La BAN exige au moins 3 caracteres : on n'envoie rien en deca (evite un 400).
+    if (query.trim().length < 3) {
+        banAddressOptions.value = []
+        return
+    }
+    addressLoading.value = true
+    try {
+        const postalCode = (model.value.postalCode ?? '').replace(/\D/g, '') || undefined
+        const suggestions = await autocomplete.searchAddress(query, postalCode)
+        lastAddressSuggestions = suggestions
+        banAddressOptions.value = suggestions.map(s => ({ value: s.street, label: s.label }))
+    }
+    catch {
+        // Erreur transitoire : on vide les suggestions, la prochaine frappe reessaie.
+        banAddressOptions.value = []
+        notifyUnavailable()
+    }
+    finally {
+        addressLoading.value = false
+    }
+}
+
+/** Selection d'une suggestion d'adresse → remplit rue + ville + CP. */
+function onAddressSelect(option: { label: string, value: string | number } | null): void {
+    if (option === null) {
+        return
+    }
+    const suggestion = lastAddressSuggestions.find(s => s.street === option.value)
+    if (!suggestion) {
+        update('street', String(option.value))
+        return
+    }
+    emit('update:modelValue', {
+        ...props.modelValue,
+        street: suggestion.street,
+        city: suggestion.city,
+        postalCode: suggestion.postalCode,
+    })
+}
+</script>