chore: bump version to v0.1.78

## 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 passe désormais exclusivement par l'onglet **Contacts** (`ClientContactBlock`, inchangé).

Dépend du ticket **1/3 (back)** : l'API ne renvoie/n'accepte plus ces 5 champs sur `client`. Contexte : `docs/specs/M1-clients/refonte-contact/README.md`.

## Changements

- **`pages/clients/new.vue`** : bloc principal réduit à Nom entreprise / Catégories / Relation / Triage. Suppression de `main.firstName/lastName/email`, `mainPhones`, `addMainPhone()`, `prefillFirstContact()`. `isMainValid` ne dépend plus que de `companyName` + ≥ 1 catégorie + relation valide. Payload POST et `ClientResponse` nettoyés.
- **`pages/clients/[id]/edit.vue`** : mêmes champs retirés, `isMainValid` simplifié.
- **`pages/clients/[id]/index.vue`** : affichage lecture seule des 5 champs retiré.
- **`utils/clientEdit.ts`** : `MainFormDraft`, `mapMainDraft()`, `buildMainPayload()` débarrassés des 5 champs + `hasSecondaryPhone`.
- **`utils/clientConsultation.ts`** : `ClientDetail` débarrassé des champs inline (`ContactRead` conservé).
- **`i18n/locales/fr.json`** : clés `form.main.firstName/lastName/email/phonePrimary/phoneSecondary/addPhone` supprimées. `form.contact.*` conservé.
- **Tests** : `clientEdit.spec.ts` ajusté (factory, `MAIN_KEYS`, assertions `mapMainDraft`, test téléphone secondaire obsolète retiré).

## Vérifications

- `make nuxt-test` : suites `clientEdit` / `clientConsultation` / `clientFormRules` vertes. Les 2 échecs restants (`useClientReferentials.spec.ts`, libellé de site) sont **pré-existants** sur `develop` (confirmé par `git stash`), sans rapport avec ce ticket.
- `eslint` sur les fichiers touchés : OK, aucun import/variable mort.
- Zéro référence orpheline aux clés `form.main.*` supprimées ; JSON i18n valide.

## Reste à faire

- Golden path navigateur (création → consultation → modification sans bloc inline) à valider manuellement.

Reviewed-on: #57
Co-authored-by: tristan <tristan@yuno.malio.fr>
Co-committed-by: tristan <tristan@yuno.malio.fr>

.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,202 @@
+# 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
+
+## 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)
+
+**Regle** : toute collection API DOIT etre paginee. Aucun retour de collection complete cote serveur.
+
+### Standard global
+
+Pose dans `config/packages/api_platform.yaml` (section `defaults:`) et heritee par toutes les ressources :
+
+| Cle | Valeur | Effet |
+|---|---|---|
+| `pagination_enabled` | `true` | Pagination Hydra active par defaut. |
+| `pagination_items_per_page` | `10` | Taille de page par defaut, aligne sur l'UI `MalioDataTable`. |
+| `pagination_maximum_items_per_page` | `50` | Borne dure : `?itemsPerPage=999` → ramene a 50. Anti deep-fetch. |
+| `pagination_client_items_per_page` | `true` | Le client peut envoyer `?itemsPerPage=25` (bornee par le max). |
+| `pagination_client_enabled` | `true` | Le client peut envoyer `?pagination=false` pour TOUT recuperer (echappatoire selects). |
+
+### Override par ressource (rare)
+
+Si une ressource a besoin d'un autre defaut (ex: payload lourd), utiliser les attributs sur l'operation. **JAMAIS `paginationEnabled: false`** sans whitelist explicite dans `tests/Architecture/CollectionsArePaginatedTest::EXCLUDED`.
+
+```php
+new GetCollection(
+    paginationItemsPerPage: 5,           // override taille par defaut
+    paginationMaximumItemsPerPage: 20,   // override borne max
+)
+```
+
+### Selects et autocompletions
+
+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'echappatoire prevue par `pagination_client_enabled: true`. Sur les ressources a forte volumetrie, preferer une saisie assistee (recherche serveur via `?q=`) — a planifier dans un ticket dedie.
+
+Les tests fonctionnels qui exercent ce comportement doivent egalement 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 supportes :
+
+- **ORM** : injecter `ApiPlatform\State\Pagination\Pagination`, wrap un `Doctrine\ORM\Tools\Pagination\Paginator` dans `ApiPlatform\Doctrine\Orm\Paginator`. Exemple : `CategoryProvider`.
+- **DBAL** : implementer un paginator local conforme a `PaginatorInterface`. Exemple : `DbalPaginator` (Core) + `AuditLogProvider`.
+
+Gerer l'echappatoire `?pagination=false` :
+
+```php
+if (!$this->pagination->isEnabled($operation, $context)) {
+    return $qb->getQuery()->getResult(); // tout retourner
+}
+```
+
+### Garde-fou architecture
+
+`tests/Architecture/CollectionsArePaginatedTest` scanne reflexivement toutes les classes `#[ApiResource]` sous `src/` et echoue si une `GetCollection` pose `paginationEnabled: false` hors whitelist `EXCLUDED`. Ajouter une entree a la whitelist requiert une justification courte + un ticket Lesstime ouvert.
+
+## 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 son libelle 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'entite » de l'audit-log affiche le type technique brut (ex: `commercial.Client`) au lieu d'un libelle lisible.
+
+Pourquoi : le filtre est dynamique (`GET /audit-log-entity-types` renvoie les `entity_type` distincts presents en base) ; des qu'un module audite une entite, son type y apparait. Le front (`formatEntityType`, `audit-log.vue`) construit la cle `audit.entity.<module>_<entity>` et, faute de traduction, **retombe silencieusement** sur le type brut.
+
+Derivation de la cle (emplacement centralise + schema flat — decision ERP-99) :
+
+| FQCN entite | `entity_type` (back) | Cle 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` |
+
+Regle : `strtolower(module)` + `_` + `strtolower(Entity)`. Ajouter sa cle de libelle audit fait partie de la **definition de fini** d'une entite metier auditee.
+
+**Garde-fou** : `tests/Architecture/AuditableEntitiesHaveI18nLabelTest` scanne les entites `#[Auditable]` et echoue si une seule n'a pas sa cle `audit.entity.*`. Conclusion : creer une entite `#[Auditable]` sans son libelle i18n casse `make test`.
+
+## Timestampable + Blamable (obligatoire pour entites metier)
+
+Toute **nouvelle** entite metier sous `src/Module/*/Domain/Entity/` doit porter les 4 colonnes `created_at` / `updated_at` / `created_by` / `updated_by`, remplies automatiquement. Trois lignes a ajouter a l'entite :
+
+```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 metier
+}
+```
+
+- Le `TimestampableBlamableSubscriber` (`Shared/Infrastructure/Doctrine/`) remplit les colonnes au `prePersist` / `preUpdate`. Hors contexte HTTP (CLI, cron, migration), le blame reste `null` (libelle « Systeme » cote front).
+- La migration de l'entite doit creer les 4 colonnes (`created_at` / `updated_at` NOT NULL, `created_by` / `updated_by` nullable `ON DELETE SET NULL`).
+- **Garde-fou CI** : `tests/Architecture/EntitiesAreTimestampableBlamableTest` echoue si une entite oublie le pattern. Un referentiel statique justifie (ex: `CategoryType`) doit etre explicitement whiteliste dans la constante `EXCLUDED` avec un commentaire.
+- Spec complete : @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
+
+### Documentation SQL obligatoire (`COMMENT ON COLUMN`)
+
+**Toute migration qui cree ou modifie une colonne d'une table metier doit poser un `COMMENT ON COLUMN` decrivant le champ.** La description est stockee dans `pg_description` et visible dans tous les outils d'admin BDD (DBeaver, DataGrip, pgAdmin), sans avoir a lire les annotations PHP.
+
+**Format de la description** :
+- En francais
+- ≤ 200 caracteres
+- Semantique du champ — contraintes / lien RG si pertinent
+- Pour les colonnes d'identifiant ou FK, mentionner la cible
+
+Exemples :
+
+```php
+// Migration : creation d'une colonne avec son commentaire dans la meme 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 : preciser 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 booleen : preciser le sens et la valeur par defaut
+$this->addSql("COMMENT ON COLUMN user.is_admin IS 'Drapeau super-administrateur — bypass complet RBAC. Faux par defaut.'");
+
+// Bonus : decrire la table elle-meme
+$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` ajoutees par `TimestampableBlamableTrait` recoivent une description **standardisee** via le helper centralise pour eviter la duplication. Helper a creer ou appeler :
+
+```php
+// Dans la migration, apres avoir ajoute les 4 colonnes :
+$this->addStandardTimestampableBlamableComments($schema, 'client');
+```
+
+L'implementation 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` filtre sur le schema `public` et echoue si **une seule colonne** n'a pas de `col_description`. Seules les tables system (`doctrine_migration_versions`) et la whitelist `EXCLUDED_TABLES` explicite (commentaire de justification + ticket Lesstime ouvert pour le retrofit) sont tolerees.
+
+Conclusion : si tu crees une colonne sans poser son `COMMENT ON COLUMN`, `make test` casse en CI.

.claude/rules/frontend.md

@@ -0,0 +1,116 @@
+# 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.
+
+## 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
+
+## 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/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_type_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_type_active ON category (LOWER(name), category_type_id) 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,264 +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/`
-
-**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
-- 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`
-- 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
-- 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)
+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 (Information obligatoire — RG-1.04)   |
+| `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,7 +24,7 @@
         "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.*",
@@ -32,6 +33,8 @@
         "symfony/runtime": "8.0.*",
         "symfony/security-bundle": "8.0.*",
         "symfony/serializer": "8.0.*",
+        "symfony/twig-bundle": "8.0.*",
+        "symfony/uid": "8.0.*",
         "symfony/validator": "8.0.*",
         "symfony/yaml": "8.0.*"
     },
@@ -90,6 +93,8 @@
     "require-dev": {
         "doctrine/doctrine-fixtures-bundle": "^4.3",
         "friendsofphp/php-cs-fixer": "^3.94",
-        "phpunit/phpunit": "^13.0"
+        "phpunit/phpunit": "^13.0",
+        "symfony/browser-kit": "8.0.*",
+        "symfony/http-client": "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,10 +1,14 @@
 <?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;
 
 return [
     CoreModule::class,
     CommercialModule::class,
+    SitesModule::class,
+    CatalogModule::class,
 ];

config/packages/api_platform.yaml

@@ -1,6 +1,17 @@
 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.
+    # Sans ces paths, le compile pass d'API Platform ne declare pas les
+    # services de filtres annotes (les filtres etaient silencieusement
+    # ignores sur Permission — cf. ticket #344).
+    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'
     formats:
         jsonld: ['application/ld+json']
         json: ['application/json']
@@ -10,3 +21,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,13 +1,46 @@
 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 `audit_log` de toute operation de comparaison de schema
+                # (doctrine:schema:update, schema:validate, diff de migrations...).
+                # Cette table n'a volontairement aucune entite mappee : elle est
+                # append-only via DBAL brut (AuditLogWriter) pour eviter la
+                # recursion du listener Doctrine. Sans ce filtre, schema:update
+                # la considere comme "orpheline" et genere un `DROP TABLE
+                # audit_log` qui casse la base de test apres chaque
+                # `make test-db-setup`. La creation / suppression de la table
+                # reste pilotee par les migrations (cf. Version20260420202749).
+                schema_filter: '~^(?!audit_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
         mappings:
             Core:
                 type: attribute
@@ -15,13 +48,76 @@ doctrine:
                 dir: '%kernel.project_dir%/src/Module/Core/Domain/Entity'
                 prefix: 'App\Module\Core\Domain\Entity'
                 alias: Core
+            # Mapping inconditionnelle du module Sites : la structure DB
+            # existe meme si SitesModule::class est retire de config/modules.php.
+            # L'activation fonctionnelle (ex: exposition des permissions, futurs
+            # endpoints API) passe exclusivement par config/modules.php.
+            Sites:
+                type: attribute
+                is_bundle: false
+                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
         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
+                # module Sites (ticket 4). Le mapping n'est charge qu'en
+                # environnement test, donc aucun impact sur les schemas
+                # dev/prod. La table est creee a la volee par les tests
+                # d'integration (via `SchemaTool::createSchema`) dans le
+                # setUp de SiteScopedQueryExtensionTest.
+                TestFixtures:
+                    type: attribute
+                    is_bundle: false
+                    dir: '%kernel.project_dir%/tests/Fixtures/SiteAware'
+                    prefix: 'App\Tests\Fixtures\SiteAware'
+                    alias: TestFixtures
 
 when@prod:
     doctrine:

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/twig.yaml

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

config/services.yaml

@@ -16,5 +16,20 @@ services:
     App\:
         resource: '../src/'
 
+    App\Module\Core\Domain\Repository\PermissionRepositoryInterface:
+        alias: App\Module\Core\Infrastructure\Doctrine\DoctrinePermissionRepository
+
+    App\Module\Core\Domain\Repository\RoleRepositoryInterface:
+        alias: App\Module\Core\Infrastructure\Doctrine\DoctrineRoleRepository
+
     App\Module\Core\Domain\Repository\UserRepositoryInterface:
         alias: App\Module\Core\Infrastructure\Doctrine\DoctrineUserRepository
+
+    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,37 +6,96 @@ 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.
+ *
+ * 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 "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.general.section',
-        'icon'  => 'mdi:view-dashboard-outline',
+        'label' => 'sidebar.administration.section',
+        'icon'  => 'mdi:cog-outline',
         'items' => [
             [
-                'label'  => 'sidebar.general.dashboard',
-                'to'     => '/',
-                'icon'   => 'mdi:view-dashboard-outline',
-                'module' => 'core',
+                'label'      => 'sidebar.core.roles',
+                'to'         => '/admin/roles',
+                'icon'       => 'mdi:shield-account-outline',
+                'module'     => 'core',
+                'permission' => 'core.roles.view',
             ],
             [
-                'label'  => 'sidebar.general.admin',
-                'to'     => '/admin',
-                'icon'   => 'mdi:cog-outline',
-                'module' => 'core',
+                'label'      => 'sidebar.core.users',
+                'to'         => '/admin/users',
+                'icon'       => 'mdi:account-group-outline',
+                'module'     => 'core',
+                'permission' => 'core.users.view',
             ],
             [
-                'label'  => 'sidebar.general.logout',
-                'to'     => '/logout',
-                'icon'   => 'mdi:logout',
-                'module' => 'core',
+                'label'      => 'sidebar.sites.admin',
+                'to'         => '/admin/sites',
+                'icon'       => 'mdi:domain',
+                'module'     => 'sites',
+                'permission' => 'sites.view',
+            ],
+            [
+                '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',
             ],
         ],
     ],
@@ -44,6 +103,13 @@ return [
         'label' => 'sidebar.commercial.section',
         'icon'  => 'mdi:account-arrow-left-outline',
         'items' => [
+            [
+                'label'      => 'sidebar.commercial.clients',
+                'to'         => '/clients',
+                'icon'       => 'mdi:account-group-outline',
+                'module'     => 'commercial',
+                'permission' => 'commercial.clients.view',
+            ],
             [
                 'label'  => 'sidebar.commercial.suppliers',
                 'to'     => '/suppliers',
@@ -52,4 +118,25 @@ return [
             ],
         ],
     ],
+    // 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',
+            ],
+        ],
+    ],
 ];

config/version.yaml

@@ -1,2 +1,2 @@
 parameters:
-    app.version: '0.1.29'
+    app.version: '0.1.78'

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/modules/site-aware.md

@@ -0,0 +1,287 @@
+# Guide développeur — `SiteAwareInterface` (opt-in)
+
+Ce guide explique comment adopter le pattern **site-aware** sur une entité
+d'un module métier pour que ses données soient automatiquement filtrées
+par le site courant de l'utilisateur connecté, et pour que les créations
+soient rattachées implicitement au site courant.
+
+Ce pattern est **opt-in strict** : aucune entité n'est affectée tant qu'un
+module ne choisit pas explicitement d'implémenter `SiteAwareInterface`.
+
+Livré par le ticket 4/4 du module Sites (cf. `docs/sites/ticket-04-spec.md`).
+
+## 1. Quand adopter ?
+
+Adopte le pattern si :
+
+- Chaque ligne de l'entité appartient à **un et un seul site**.
+- Les utilisateurs du site A ne doivent **jamais** voir les lignes du site B.
+- Créer une ligne sans connaître le site n'a pas de sens métier.
+
+Exemples typiques : `Supplier`, `Order`, `StockEntry`, `Employee` (si chaque
+site a sa propre équipe), `Invoice` (si facturation par site).
+
+## 2. Quand NE PAS adopter ?
+
+**Entités globales** : partagées par tous les sites, pas de notion de
+propriétaire. Ne pas adopter.
+
+- `Role`, `Permission`, `User` (les users sont transverses, rattachés à
+  plusieurs sites via la relation M2M `user_site`).
+- Catalogues mutualisés : produits, catégories, taxes — sauf si chaque
+  site a son propre catalogue.
+- Documents / contrats multi-site (ex: contrat-cadre qui couvre plusieurs
+  sites).
+
+**Entités "par tenant"** : si le scope naturel est plus large que le site
+(ex: un groupe qui possède plusieurs sites comme entités filiales
+juridiquement distinctes), utilise plutôt `TenantAwareInterface` (déjà
+présent dans `src/Shared/Domain/Contract/`).
+
+**Entités hybrides** : certaines lignes globales, d'autres par site. Le
+pattern ne supporte pas ce cas — crée deux entités distinctes si
+nécessaire.
+
+## 3. Comment adopter ? Check-list
+
+### 3.1 Entité
+
+```php
+use App\Module\Sites\Domain\Entity\Site;
+use App\Shared\Domain\Contract\SiteAwareInterface;
+
+class Supplier implements SiteAwareInterface
+{
+    #[ORM\ManyToOne(targetEntity: Site::class)]
+    #[ORM\JoinColumn(name: 'site_id', referencedColumnName: 'id', nullable: false, onDelete: 'CASCADE')]
+    private ?Site $site = null;
+
+    public function getSite(): ?Site
+    {
+        return $this->site;
+    }
+
+    public function setSite(Site $site): void
+    {
+        $this->site = $site;
+    }
+}
+```
+
+Points critiques :
+
+- `nullable: false` au niveau de la `JoinColumn` — la table n'accepte
+  jamais `site_id IS NULL` en régime nominal.
+- `onDelete: 'CASCADE'` — la suppression d'un site entraîne la suppression
+  de toutes les lignes associées. À remplacer par `RESTRICT` (blocage) si
+  ton métier exige d'empêcher la suppression d'un site contenant des
+  données.
+- Le getter retourne `?Site` (nullable) pour permettre des états
+  transitoires pré-persist (entité construite avant injection du site).
+
+### 3.2 Migration
+
+**Cas 1 — Nouvelle table** : ajoute directement `site_id INT NOT NULL`
+avec FK et index.
+
+**Cas 2 — Table existante avec données legacy** : migration en trois étapes
+distinctes.
+
+```php
+// Version1.php
+$this->addSql('ALTER TABLE supplier ADD site_id INT DEFAULT NULL');
+$this->addSql('CREATE INDEX IDX_supplier_site ON supplier (site_id)');
+$this->addSql('ALTER TABLE supplier ADD CONSTRAINT FK_supplier_site FOREIGN KEY (site_id) REFERENCES site (id) ON DELETE CASCADE');
+
+// Backfill (manuellement ou via script custom selon ton métier)
+$this->addSql("UPDATE supplier SET site_id = (SELECT id FROM site WHERE name = 'Chatellerault') WHERE site_id IS NULL");
+
+// Version2.php — après backfill confirmé
+$this->addSql('ALTER TABLE supplier ALTER COLUMN site_id SET NOT NULL');
+```
+
+**Index obligatoire** : le filtre généré par `SiteScopedQueryExtension`
+est `WHERE x.site = :currentSite`. Sans index sur `site_id`, chaque
+requête fait un full-scan de la table. Ajoute-le dans la migration.
+
+### 3.3 Sérialisation API
+
+Expose la relation `site` dans le groupe de lecture de la ressource pour
+que le frontend sache à quel site appartient chaque ligne :
+
+```php
+#[Groups(['supplier:read'])]
+private ?Site $site = null;
+```
+
+Si tu veux aussi permettre à un admin de créer une ligne sur un autre
+site que son `currentSite` (ex: admin multi-site), ajoute aussi le groupe
+d'écriture :
+
+```php
+#[Groups(['supplier:read', 'supplier:write'])]
+```
+
+Dans ce cas, `SiteAwareInjectionProcessor` respecte la valeur explicite
+envoyée par le client (voir §4).
+
+### 3.4 Processor custom
+
+Si le module a déjà un processor custom sur les opérations POST/PATCH,
+assure-toi qu'il délègue à `api_platform.doctrine.orm.state.persist_processor`
+(et non à `$em->persist()` direct) pour que le decorator
+`SiteAwareInjectionProcessor` s'applique.
+
+Pattern aligné sur `UserRbacProcessor` :
+
+```php
+use Symfony\Component\DependencyInjection\Attribute\Autowire;
+
+public function __construct(
+    #[Autowire(service: 'api_platform.doctrine.orm.state.persist_processor')]
+    private readonly ProcessorInterface $persistProcessor,
+) {}
+
+public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
+{
+    // Gardes métier custom ici...
+
+    // Délègue au persist processor décoré : SiteAwareInjectionProcessor
+    // interceptera l'appel et injectera le currentSite si besoin.
+    return $this->persistProcessor->process($data, $operation, $uriVariables, $context);
+}
+```
+
+## 4. Comportement du processor d'injection
+
+Le decorator `SiteAwareInjectionProcessor` s'applique automatiquement à
+**toute** persistance API Platform. Son comportement :
+
+| Cas | Action |
+|---|---|
+| `$data` n'implémente pas `SiteAwareInterface` | Délégation directe (no-op). |
+| `$data` est `SiteAware` avec `$site` déjà positionné (ex: payload POST avec `site` explicite) | Délégation directe, **la valeur explicite est préservée**. |
+| `$data` est `SiteAware` sans site, `CurrentSiteProvider::get()` retourne un `Site` | Injection `$data->setSite($currentSite)` puis délégation. |
+| `$data` est `SiteAware` sans site, `CurrentSiteProvider::get()` retourne `null` | **Throw `BadRequestHttpException`** avec message "aucun site sélectionné". |
+
+Conséquence : un user sans `currentSite` ne peut **pas** créer de ligne
+sur une entité `SiteAware`. C'est intentionnel : mieux vaut un 400 clair
+que persister une ligne incohérente.
+
+## 5. Comportement en mode dégradé
+
+### 5.1 Module Sites désactivé
+
+Si `SitesModule::class` est retiré de `config/modules.php`,
+`CurrentSiteProvider::get()` retourne **toujours `null`** :
+
+- `SiteScopedQueryExtension` → no-op. Toutes les lignes visibles, comme
+  si le filtre n'existait pas.
+- `SiteAwareInjectionProcessor` → **throw 400 sur tout POST/PATCH** sans
+  site explicite. L'écriture d'entités `SiteAware` nécessite que le
+  client envoie systématiquement `site` dans le payload.
+
+**Conséquence** : un module qui adopte le pattern **ne peut pas vivre**
+sans le module Sites actif pour les opérations d'écriture. À documenter
+fortement dans le README du module adopté.
+
+### 5.2 User sans site (sites = [], currentSite = null)
+
+Même comportement qu'un module désactivé : lecture no-op (tout visible),
+écriture bloquée par 400. L'UX doit gérer ce cas (ex: écran d'onboarding
+qui force l'assignation d'un site avant d'accéder aux écrans métier).
+
+### 5.3 Bypass admin via `sites.bypass_scope`
+
+Un utilisateur avec la permission `sites.bypass_scope` (ou admin par
+bypass total via `isAdmin = true`) voit **toutes** les lignes, tous
+sites confondus. Pratique pour audit, reporting, consolidation groupe.
+
+Le processor d'injection ne respecte **pas** ce bypass : même un user
+avec `bypass_scope` verra son `currentSite` injecté à la création s'il
+n'envoie pas de `site` explicite. Le bypass est un droit de lecture,
+pas d'écriture multi-site.
+
+## 6. Anti-patterns et gotchas
+
+### 6.1 Sous-collections (`/api/clients/{id}/contacts`)
+
+Si seul `Client` est `SiteAware` (et `Contact` hérite du scope via son
+parent), le filtre **ne se propage pas automatiquement** aux contacts.
+Deux options :
+
+- Rendre `Contact` aussi `SiteAware` (redondance mais simple).
+- Ajouter un filtre custom qui joint sur `contact.client.site` et compare
+  au `currentSite`.
+
+Ce ticket ne couvre pas le second cas : à implémenter par le module
+concerné.
+
+### 6.2 Repositories custom
+
+Le filtre API Platform ne s'applique **qu'aux requêtes** générées par
+API Platform (via `ItemProvider` / `CollectionProvider` Doctrine). Si un
+repository custom fait une requête DQL manuelle (ex: `findTopRated()`
+appelé depuis un service), **aucun filtre n'est appliqué**.
+
+Responsabilité du développeur du module : injecter `CurrentSiteProvider`
+dans le repository / service et ajouter manuellement la clause WHERE.
+
+### 6.3 Tests d'intégration
+
+Les tests qui persistent des entités `SiteAware` doivent :
+
+- Soit logger un user avec un `currentSite` positionné (cas nominal).
+- Soit utiliser un user avec `sites.bypass_scope` pour voir toutes les
+  lignes (cas reporting).
+- Soit positionner le site **explicitement** sur chaque entité persistée
+  via fixture (bypass du processor d'injection qui n'est pas actif hors
+  contexte HTTP).
+
+### 6.4 Cascade delete d'un site
+
+La migration type du §3.2 déclare `onDelete: 'CASCADE'` sur la FK
+`site_id`. **Conséquence** : supprimer un site détruit **toutes** les
+lignes de **toutes** les tables `SiteAware` rattachées à ce site, en
+cascade. Pour un `Supplier`, ça signifie perte de l'historique fournisseur
+du site supprimé.
+
+Alternatives selon le besoin métier :
+
+- `onDelete: 'RESTRICT'` : bloque la suppression du site tant qu'il reste
+  des lignes. L'admin doit nettoyer manuellement avant delete.
+- `onDelete: 'SET NULL'` : transforme les lignes en "globales" après
+  suppression du site — mais incompatible avec `nullable: false`, donc
+  nécessite de relâcher la contrainte. Généralement à éviter.
+
+## 7. Exemple d'adoption minimale (pseudo-ticket)
+
+Pour un futur ticket qui adopte `SiteAwareInterface` sur `Supplier` du
+module Commercial :
+
+1. Modifier `src/Module/Commercial/Domain/Entity/Supplier.php` : ajouter
+   `implements SiteAwareInterface` + relation `$site`.
+2. Créer migration `Version<timestamp>.php` : `ALTER TABLE supplier ADD
+   site_id ...`, backfill, `SET NOT NULL`, `CREATE INDEX`.
+3. Ajouter `#[Groups(['supplier:read'])]` sur `$site`.
+4. Mettre à jour les fixtures `CommercialFixtures` pour rattacher chaque
+   supplier à un site (`setSite(...)`).
+5. Ajouter un test d'intégration qui vérifie que la collection
+   `/api/suppliers` retourne bien uniquement les suppliers du site
+   courant pour un user donné.
+6. Documenter dans le README du module Commercial que les opérations
+   d'écriture sur Supplier nécessitent le module Sites actif + un user
+   avec `currentSite`.
+
+## 8. Permission `sites.bypass_scope`
+
+Déclarée par `SitesModule::permissions()`, synchronisée automatiquement
+en base par `app:sync-permissions`. Une fois synchronisée, elle est
+assignable :
+
+- Directement à un user via `/admin/users` (drawer RBAC, section
+  "Permissions directes").
+- Via un rôle personnalisé (ex: rôle "Auditeur groupe") qui la porte.
+
+Les admins l'obtiennent automatiquement par bypass total (`isAdmin`), pas
+besoin d'assignation explicite.

docs/rbac/ticket-343-spec.md

@@ -0,0 +1,556 @@
+# Ticket #343 - 1/5 - Entités Permission et Role (Backend)
+
+## 1. Objectif
+
+Ce ticket livre la base RBAC backend de l'epic en 5 tickets en remplacant le stockage historique des roles Symfony dans `User::$roles` par un modele metier explicite `Role` + `Permission` + rattachements utilisateur. Le resultat attendu est un socle de persistance et de synchronisation utilisable par les tickets suivants pour exposer l'API, brancher les voters et alimenter les interfaces. Le ticket couvre aussi la migration de donnees depuis la colonne JSON existante et l'outillage necessaire pour synchroniser les permissions declarees par les modules actifs.
+
+## 2. Périmètre
+
+### IN
+
+- Creer l'entite `Role` avec `id`, `code`, `label`, `description`, `isSystem` et relation ManyToMany vers `Permission`.
+- Creer l'entite `Permission` avec `id`, `code`, `label`, `module`, `orphan` et unicite sur `code`.
+- 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/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`.
+- Ajouter une protection domaine empechant la suppression d'un role systeme via `SystemRoleDeletionException`.
+- Integrer les decisions de hardening demandees: fetch `EAGER`, constantes partagees pour les codes systeme, synchronisation non destructive, commentaires PHP en francais, identifiants anglais, `declare(strict_types=1)`, colonnes PostgreSQL en minuscules.
+
+### OUT
+
+- Ticket `#344` : ressources API Platform, providers, processors et traduction HTTP de `SystemRoleDeletionException` vers `403`.
+- Ticket `#345` : voter / authorisation applicative basee sur les permissions.
+- Ticket `#346` : interfaces d'administration RBAC.
+- Ticket `#347` : couche de traduction / UX des erreurs `403` et integration front complete.
+
+## 3. Fichiers à créer
+
+### Domaine - Entités
+
+- `/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/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/Starseed/src/Module/Core/Domain/Exception/SystemRoleDeletionException.php` : exception domaine levee si une suppression vise un role systeme.
+
+### Infrastructure - Doctrine
+
+- `/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/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/Starseed/src/Module/Core/Infrastructure/Console/SyncPermissionsCommand.php` : commande `app:sync-permissions` qui scanne les modules actifs et synchronise la table `permission`.
+
+### Infrastructure - DataFixtures
+
+- Aucun nouveau fichier necessaire si la logique reste dans le fixture existant.
+
+### Constantes domaine
+
+- `/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/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
+  {
+      return [
+          ['code' => 'core.users.view',        'label' => 'Voir les utilisateurs'],
+          ['code' => 'core.users.manage',      'label' => 'Gerer les utilisateurs (creer, editer, supprimer)'],
+          ['code' => 'core.roles.manage',      'label' => 'Gerer les roles et permissions'],
+          ['code' => 'core.permissions.view',  'label' => 'Voir la liste des permissions'],
+      ];
+  }
+  ```
+  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/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/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
+
+Plutot que de prescrire du SQL verbatim (risque de divergence avec la strategie `#[ORM\GeneratedValue]` par defaut utilisee par `User`, qui genere des sequences PostgreSQL, pas des colonnes `GENERATED IDENTITY`), on decrit le schema cible par les attributs Doctrine. Le SQL effectif sera produit par `bin/console doctrine:migrations:diff` puis augmente manuellement du data-migration step (section 6).
+
+Conventions :
+- `declare(strict_types=1)` en tete de tous les fichiers.
+- Identifiants de classe et proprietes en anglais, commentaires en francais (cf. `CLAUDE.md`).
+- PostgreSQL : noms de colonnes en snake_case minuscules, Doctrine les deduit des proprietes camelCase (ex: `isSystem` → `is_system`).
+- Les tables `user` et `role` sont des mots reserves PostgreSQL ; Doctrine les quote automatiquement via `#[ORM\Table(name: '`role`')]`.
+
+### Entite `Permission`
+
+```php
+#[ORM\Entity(repositoryClass: DoctrinePermissionRepository::class)]
+#[ORM\Table(name: 'permission')]
+#[ORM\UniqueConstraint(name: 'uniq_permission_code', columns: ['code'])]
+#[ORM\Index(name: 'idx_permission_module', columns: ['module'])]
+#[ORM\Index(name: 'idx_permission_orphan', columns: ['orphan'])]
+class Permission
+{
+    #[ORM\Id]
+    #[ORM\GeneratedValue]
+    #[ORM\Column]
+    private ?int $id = null;
+
+    #[ORM\Column(length: 255)]
+    private string $code;
+
+    #[ORM\Column(length: 255)]
+    private string $label;
+
+    #[ORM\Column(length: 100)]
+    private string $module;
+
+    #[ORM\Column(options: ['default' => false])]
+    private bool $orphan = false;
+}
+```
+
+Contraintes fonctionnelles :
+- `code` suit la convention `module.resource[.sub].action` (verifie par le sync command).
+- `module` contient l'identifiant declare dans `*Module::ID`, auto-injecte par le sync.
+- `orphan = true` signifie "permission conservee en base mais absente de la declaration courante".
+
+### Entite `Role`
+
+```php
+#[ORM\Entity(repositoryClass: DoctrineRoleRepository::class)]
+#[ORM\Table(name: '`role`')]
+#[ORM\UniqueConstraint(name: 'uniq_role_code', columns: ['code'])]
+#[ORM\Index(name: 'idx_role_is_system', columns: ['is_system'])]
+class Role
+{
+    #[ORM\Id]
+    #[ORM\GeneratedValue]
+    #[ORM\Column]
+    private ?int $id = null;
+
+    #[ORM\Column(length: 100)]
+    private string $code;
+
+    #[ORM\Column(length: 255)]
+    private string $label;
+
+    #[ORM\Column(type: Types::TEXT, nullable: true)]
+    private ?string $description = null;
+
+    #[ORM\Column(name: 'is_system', options: ['default' => false])]
+    private bool $isSystem = false;
+
+    /** @var Collection<int, Permission> */
+    #[ORM\ManyToMany(targetEntity: Permission::class, fetch: 'EAGER')]
+    #[ORM\JoinTable(name: 'role_permission')]
+    private Collection $permissions;
+}
+```
+
+Contraintes fonctionnelles :
+- `code` porte la cle metier stable du role (`admin`, `user`, ...).
+- `isSystem = true` interdit la suppression via `Role::ensureDeletable()` au niveau domaine.
+- `fetch: EAGER` sur `$permissions` : evite qu'un `User::getEffectivePermissions()` cascade du lazy-loading hors contexte EntityManager (refresh JWT, serialisation asynchrone).
+
+### Evolution de l'entite `User`
+
+- Suppression de la propriete `private array $roles = []` (et donc de la colonne `roles JSON`).
+- Ajout :
+  ```php
+  #[ORM\Column(name: 'is_admin', options: ['default' => false])]
+  private bool $isAdmin = false;
+
+  /** @var Collection<int, Role> */
+  #[ORM\ManyToMany(targetEntity: Role::class, fetch: 'EAGER')]
+  #[ORM\JoinTable(name: 'user_role')]
+  private Collection $roles;
+
+  /** @var Collection<int, Permission> */
+  #[ORM\ManyToMany(targetEntity: Permission::class, fetch: 'EAGER')]
+  #[ORM\JoinTable(name: 'user_permission')]
+  private Collection $directPermissions;
+  ```
+- `$roles` et `$directPermissions` sont initialises en `ArrayCollection` dans le constructeur, comme toute collection Doctrine.
+- `fetch: EAGER` sur les 3 associations : critique pour eviter des `getRoles()` silencieusement tronques pendant un refresh de token JWT (cf. risque section 11).
+
+### Evolution de la table `user` (SQL final apres diff)
+
+La migration introduira :
+- `ALTER TABLE "user" ADD COLUMN is_admin BOOLEAN DEFAULT FALSE NOT NULL;`
+- Creation de `user_role`, `user_permission` avec FKs `ON DELETE CASCADE`.
+- Apres data-migration (section 6), `ALTER TABLE "user" DROP COLUMN roles;`.
+
+Etat final attendu :
+- La colonne historique `roles JSON NOT NULL` est supprimee.
+- La compatibilite Symfony passe par `User::getRoles()` derivee de `$isAdmin`, plus aucune persistence framework.
+- Les 3 associations `User::$roles`, `User::$directPermissions`, `Role::$permissions` sont explicitement EAGER.
+
+## 6. Plan de migration Doctrine
+
+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).
+2. Lancer `bin/console doctrine:migrations:diff` qui genere le squelette SQL de structure (CREATE TABLE + FKs + DROP COLUMN).
+3. Editer **manuellement** le fichier genere pour inserer le data-migration step entre la creation des tables et le `DROP COLUMN roles` — sinon les donnees admin sont perdues.
+4. Le fichier final vit dans le chemin ci-dessus en respectant le namespace configure dans `doctrine_migrations.yaml`.
+
+### `up()` - ordre recommande apres edition manuelle
+
+1. Creer la colonne `"user".is_admin` avec `DEFAULT FALSE`.
+2. Creer les tables `permission`, `"role"`, `role_permission`, `user_role`, `user_permission` et leurs indexes/foreign keys.
+3. Inserer par SQL brut les roles systeme `admin` et `user` en s'appuyant sur les codes centralises dans `SystemRoles`.
+4. Mettre a jour `"user".is_admin` a `TRUE` pour les utilisateurs dont la colonne JSON `roles` contient `ROLE_ADMIN`.
+5. Inserer dans `user_role` le role `admin` pour les utilisateurs dont la colonne JSON `roles` contient `ROLE_ADMIN`.
+6. Inserer dans `user_role` le role `user` pour les utilisateurs qui ne portent pas `ROLE_ADMIN`, y compris si `roles` vaut `NULL`, `[]` ou `["ROLE_USER"]`.
+7. Verifier que les insertions utilisent `ON CONFLICT DO NOTHING` ou l'equivalent applicable afin de rester robustes face a une base deja partiellement migree sur un environnement de dev.
+8. Supprimer la colonne `"user".roles` uniquement apres la migration de donnees.
+
+### SQL de migration de donnees - logique precise
+
+Detection admin :
+
+```sql
+UPDATE "user" u
+SET is_admin = TRUE
+WHERE EXISTS (
+    SELECT 1
+    FROM jsonb_array_elements_text(COALESCE(u.roles::jsonb, '[]'::jsonb)) AS role_code
+    WHERE role_code = 'ROLE_ADMIN'
+);
+```
+
+Rattachement du role systeme `admin` :
+
+```sql
+INSERT INTO user_role (user_id, role_id)
+SELECT u.id, r.id
+FROM "user" u
+CROSS JOIN "role" r
+WHERE r.code = 'admin'
+  AND EXISTS (
+      SELECT 1
+      FROM jsonb_array_elements_text(COALESCE(u.roles::jsonb, '[]'::jsonb)) AS role_code
+      WHERE role_code = 'ROLE_ADMIN'
+  )
+ON CONFLICT DO NOTHING;
+```
+
+Rattachement du role systeme `user` :
+
+```sql
+INSERT INTO user_role (user_id, role_id)
+SELECT u.id, r.id
+FROM "user" u
+CROSS JOIN "role" r
+WHERE r.code = 'user'
+  AND NOT EXISTS (
+      SELECT 1
+      FROM jsonb_array_elements_text(COALESCE(u.roles::jsonb, '[]'::jsonb)) AS role_code
+      WHERE role_code = 'ROLE_ADMIN'
+  )
+ON CONFLICT DO NOTHING;
+```
+
+Cas couverts explicitement :
+
+- `roles = NULL` : traite comme tableau vide, utilisateur non admin, rattache au role `user`.
+- `roles = []` : utilisateur non admin, rattache au role `user`.
+- `roles = ["ROLE_USER"]` : utilisateur non admin, rattache au role `user`.
+- `roles = ["ROLE_ADMIN"]` : `is_admin = true`, rattache au role `admin`, pas de role `user`.
+- `roles = ["ROLE_ADMIN", "ROLE_USER"]` : meme resultat que ci-dessus, sans doublon.
+
+### Caveat : type reel de la colonne `user.roles`
+
+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-starseed psql -U malio -d starseed -c '\d "user"'
+```
+
+- Si `roles | json` : le SQL ci-dessus fonctionne tel quel.
+- Si `roles | text` : remplacer `u.roles::jsonb` par `u.roles::text::jsonb` dans les 3 requetes.
+- Si la colonne est deja `jsonb` (rare) : remplacer `u.roles::jsonb` par `u.roles`.
+
+### `down()` - rollback minimal et coherent
+
+1. Recreer la colonne `"user".roles` en `JSON NOT NULL DEFAULT '[]'`.
+2. Rehydrater `"user".roles` avec `["ROLE_ADMIN"]` si `is_admin = true`, sinon `["ROLE_USER"]`.
+3. Supprimer les foreign keys et tables de jointure `user_permission`, `user_role`, `role_permission`.
+4. Supprimer les tables `permission` et `"role"`.
+5. Supprimer la colonne `"user".is_admin`.
+
+Le rollback ne restitue pas la granularite RBAC complete, ce qui est acceptable pour un `down()` technique, mais il doit restituer une application compatible avec le modele historique base sur `ROLE_ADMIN` / `ROLE_USER`.
+
+## 7. Algorithme sync-permissions
+
+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/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 `[]`.
+
+### Format de declaration attendu
+
+Chaque entree retournee par `*Module::permissions()` contient STRICTEMENT deux cles :
+
+- `code` — string suivant la convention `module.resource[.sub].action`, par exemple `core.users.view` ou `commercial.quote.line.delete`.
+- `label` — string lisible en francais, affichee dans l'UI d'administration des roles.
+
+La cle `module` N'EST PAS dans le payload : elle est **auto-injectee** par la commande de sync a partir de `$moduleClass::ID`. Ainsi on ne peut pas declarer accidentellement une permission d'un autre module.
+
+Garde anti-typo : le sync command verifie que chaque `code` commence obligatoirement par `$moduleClass::ID . '.'`. Si non, la commande echoue avec un message explicite citant la classe module et le code incrimine, sans toucher a la base.
+
+### Pseudocode
+
+```text
+begin transaction
+
+load active module classes from /home/matthieu/dev_malio/Starseed/config/modules.php
+desired_permissions = empty map keyed by code
+
+for each module class:
+    if method permissions() exists:
+        declared_permissions = module class::permissions()
+    else:
+        declared_permissions = []
+
+    for each declared permission in declared_permissions:
+        assert array_keys(permission) == ['code', 'label']  // erreur explicite sinon
+        assert str_starts_with(permission.code, module class::ID + '.')  // erreur explicite sinon
+        normalized = {
+            code:   permission.code,
+            label:  permission.label,
+            module: module class::ID,  // auto-injection
+        }
+        desired_permissions[code] = normalized
+
+load existing permissions from database indexed by code
+
+for each code in desired_permissions:
+    if code exists in database:
+        update label
+        update module
+        set orphan = false
+    else:
+        insert permission with orphan = false
+
+for each database permission code not present in desired_permissions:
+    set orphan = true
+
+flush
+commit transaction
+```
+
+### Propriétés attendues
+
+- Idempotente : deux executions consecutives sans changement de declarations ne doivent produire aucun delta metier.
+- Non destructive : aucune suppression de ligne `permission`; les permissions disparues deviennent `orphan = true`.
+- Reversible metier : une permission orpheline redeclaree repasse a `orphan = false` et voit ses metadonnees mises a jour.
+- Transactionnelle : pas d'etat intermediaire visible si une validation ou un flush echoue.
+
+## 8. Méthodes clés détaillées
+
+### User
+
+Signature :
+
+```text
+public function getRoles(): array
+```
+
+Retourne toujours `ROLE_USER`. Ajoute `ROLE_ADMIN` si `is_admin = true`. Ne lit plus aucune colonne JSON. Le resultat doit etre deduplique et stable pour Symfony Security.
+
+Signature :
+
+```text
+public function getEffectivePermissions(): array
+```
+
+Retourne l'union des codes des permissions issues de `User::$roles[*]->permissions` et de `User::$directPermissions`. Le resultat est un tableau unique de chaines, sans doublon, trie de facon deterministe si possible pour des assertions de test stables.
+
+### Role
+
+Signature :
+
+```text
+public function addPermission(Permission $permission): self
+```
+
+Ajoute la permission a la collection si absente, sans doublon.
+
+Signature :
+
+```text
+public function removePermission(Permission $permission): self
+```
+
+Retire la permission de la collection si presente.
+
+Signature :
+
+```text
+public function ensureDeletable(): void
+```
+
+Leve `SystemRoleDeletionException` si `isSystem = true`. Cette garde doit vivre dans le domaine, meme si la traduction HTTP vers `403` est hors scope de ce ticket.
+
+### Permission
+
+Signature :
+
+```text
+public function markOrphan(): self
+```
+
+Passe `orphan` a `true` sans detruire la permission.
+
+Signature :
+
+```text
+public function revive(string $label, string $module): self
+```
+
+Repasse `orphan` a `false` et remet a jour les metadonnees issues de la declaration modulaire.
+
+## 9. Fixtures mises à jour
+
+Le fichier cible reste `/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/DataFixtures/AppFixtures.php`.
+
+### Principe cle : decouplage via `is_admin`
+
+Le role `admin` n'a **pas besoin** de contenir "toutes les permissions" pour rendre l'admin techniquement tout-puissant : cette capacite vient du bypass `is_admin = true` dans le futur `PermissionVoter` (ticket #345). Le role `admin` est donc un **conteneur metier semantique** (il represente le bundle "administrateur") mais n'est pas fonctionnellement requis pour que l'admin puisse tout faire.
+
+Consequence directe : les fixtures deviennent auto-suffisantes. Elles ne dependent plus d'un passage prealable de `app:sync-permissions`. `make db-reset && make fixtures` reste un one-shot.
+
+### Jeu de donnees attendu
+
+- Role systeme `admin` (`SystemRoles::ADMIN_CODE`)
+  - `code = admin`
+  - `label = Administrateur`
+  - `description = Role administrateur — bypass complet via is_admin`
+  - `isSystem = true`
+  - `permissions = []` — volontairement vide, le bypass fait tout le travail. Une fois `app:sync-permissions` passe, un admin pourra assigner via UI les permissions au role si besoin d'un scenario "quasi-admin sans bypass".
+- Role systeme `user` (`SystemRoles::USER_CODE`)
+  - `code = user`
+  - `label = Utilisateur`
+  - `description = Role de base sans permission specifique`
+  - `isSystem = true`
+  - `permissions = []`
+
+### Assignations utilisateurs
+
+- `admin` (user) : `is_admin = true`, role `admin`
+- `alice` : `is_admin = false`, role `user`
+- `bob` : `is_admin = false`, role `user`
+- Aucune permission directe (`directPermissions`) n'est prechargee dans ce ticket.
+
+### Autonomie du workflow
+
+`make db-reset && make fixtures` fonctionne sans passer par `app:sync-permissions` au prealable, car aucune fixture ne depend du contenu de la table `permission`. Optionnellement, apres chargement des fixtures, l'utilisateur peut executer `bin/console app:sync-permissions` pour peupler la table `permission` avec les declarations de `CoreModule::permissions()`, mais c'est une etape independante et optionnelle a ce stade.
+
+## 10. Plan de tests PHPUnit
+
+### Unitaires - domaine
+
+- `User::getRoles()` retourne `['ROLE_USER']` quand `is_admin = false`.
+- `User::getRoles()` retourne `['ROLE_USER', 'ROLE_ADMIN']` quand `is_admin = true`.
+- `User::getEffectivePermissions()` fusionne permissions de roles et permissions directes sans doublon.
+- `User::getEffectivePermissions()` retourne un tableau vide pour un utilisateur sans role ni permission directe.
+- `Role::addPermission()` n'ajoute pas de doublon.
+- `Role::removePermission()` retire correctement une permission existante.
+- `Role::ensureDeletable()` leve `SystemRoleDeletionException` pour un role systeme.
+- `Permission::markOrphan()` passe `orphan` a `true`.
+- `Permission::revive()` remet `orphan` a `false` et met a jour `label` / `module`.
+
+### Integration - persistence et console
+
+- La commande `app:sync-permissions` cree les permissions declarees par `CoreModule::permissions()`.
+- Deux executions successives de `app:sync-permissions` sur le meme jeu de modules sont idempotentes.
+- Une permission supprimee d'une declaration modulaire n'est pas deletee mais marquee `orphan = true`.
+- Une permission redeclaree apres etat orphelin est revivee avec `orphan = false`.
+- Les repositories Doctrine chargent bien `User::$roles`, `User::$directPermissions` et `Role::$permissions` sans lazy loading hors EntityManager grace a `fetch=EAGER`.
+- Les fixtures chargent les roles systeme et rattachent les utilisateurs attendus.
+
+### Integration - migration
+
+- `up()` sur une base contenant `roles = ["ROLE_ADMIN"]` cree `is_admin = true`, rattache le role `admin` et supprime la colonne JSON.
+- `up()` sur une base contenant `roles = ["ROLE_USER"]` rattache le role `user` et laisse `is_admin = false`.
+- `up()` sur une base contenant `roles = ["ROLE_ADMIN", "ROLE_USER"]` ne cree aucun doublon et conserve le comportement admin.
+- `up()` sur une base contenant `roles = []` ou `NULL` rattache quand meme le role `user`.
+- `down()` recree une colonne `roles` JSON exploitable et restaure `ROLE_ADMIN` ou `ROLE_USER` de facon coherente.
+
+### Prerequis d'infrastructure de test
+
+Les tests d'integration migration up/down exigent une base de test dediee avec un outillage pour jouer/rejouer les migrations. Verifier l'etat de l'infra avant d'ecrire ces tests :
+
+- Si `make test` applique deja les migrations sur une base isolee : les tests peuvent etre ecrits en utilisant `KernelTestCase` + `EntityManager` + `MigrationRepository`.
+- Sinon, ajouter `DAMADoctrineTestBundle` (transactionne chaque test) ou une recipe dediee `make test-migration` qui monte une base jetable puis lance les migrations.
+- **Si l'outillage manque** : ne pas bloquer le ticket. Ecrire a la place un test SQL de bas niveau sur une base transactionnellement reinitialisee (via `BEGIN` / `ROLLBACK` a chaque cas) et poser une TODO explicite dans le ticket suivant pour normaliser l'infra de test migration.
+
+## 11. Risques et points d'attention
+
+- Risque de chargement paresseux pendant refresh JWT, serialisation ou security context hors EntityManager.
+  - Mitigation : imposer `fetch=EAGER` sur `User::$roles`, `User::$directPermissions` et `Role::$permissions`, puis le verifier par tests d'integration.
+- 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/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()`.
+  - Mitigation : traiter l'absence de methode comme `[]` pour la compatibilite immediate et documenter que chaque nouveau module devra ajouter `permissions()` dans les tickets suivants.
+- Risque de cout SQL/ORM du `fetch=EAGER` quand un utilisateur porte beaucoup de roles et permissions.
+  - Mitigation : limiter pour l'instant le perimetre aux trois associations critiques et surveiller les requetes; un ajustement vers des requetes dediees pourra etre etudie si la volumetrie augmente.
+- Risque de semantique confuse entre `is_admin` et role systeme `admin`.
+  - Mitigation : regle gravee a partir de ce ticket. `is_admin` est le SEUL levier technique de bypass — c'est lui qui fait qu'un admin peut tout faire, via le futur `PermissionVoter` (ticket #345). Le role `admin` est un **conteneur metier semantique** : il identifie visuellement les admins dans l'UI et laisse la porte ouverte a un scenario "quasi-admin sans bypass" (admin qui aurait beaucoup de permissions explicites mais pas le bypass). Les fixtures/migrations posent les deux (`is_admin = true` ET rattachement au role `admin`) pour le compte admin, mais la logique d'autorisation ne regarde QUE `is_admin` + les permissions effectives. Ne jamais coder `if ($user->hasRole('admin'))` : toujours `if ($user->isAdmin())` ou `is_granted('permission.code')`.
+
+## 12. Ordre d'exécution recommandé
+
+1. Creer `Permission`, `Role`, `SystemRoleDeletionException` et `SystemRoles`.
+2. Creer `PermissionRepositoryInterface`, `RoleRepositoryInterface` et leurs implementations Doctrine.
+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/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)
+
+- Les entites `Role` et `Permission` existent dans le module Core avec mappings Doctrine valides et identifiants anglais.
+- `User` ne persiste plus de colonne JSON `roles` apres migration, mais expose toujours un `getRoles()` compatible Symfony.
+- `User::getEffectivePermissions()` retourne l'union sans doublon des permissions de roles et des permissions directes.
+- `CoreModule` expose une methode statique `permissions()` servant de reference au mecanisme de sync.
+- La commande `app:sync-permissions` est transactionnelle, idempotente, non destructive et gere correctement `orphan = true` / revival.
+- Les roles systeme `admin` et `user` sont crees par la migration et par les fixtures avec `isSystem = true`.
+- La migration convertit de facon sure les etats historiques `ROLE_ADMIN`, `ROLE_USER`, tableau vide, `NULL` et combinaisons mixtes sans perte de comptes.
+- 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/Starseed/config/modules.php` et n'introduit aucune resource API Platform ni voter dans ce ticket.

docs/rbac/ticket-344-spec.md

@@ -0,0 +1,275 @@
+# Ticket #344 - 2/5 - API CRUD Roles & Permissions (Backend)
+
+## 1. Objectif
+
+Exposer via API Platform le socle RBAC livre par le ticket #343 (entites `Role`, `Permission`, relations `User->roles`/`directPermissions`, flag `isAdmin`). Ce ticket livre la surface HTTP minimale permettant :
+
+- de lister et consulter les permissions synchronisees par `app:sync-permissions`,
+- de gerer le cycle de vie des roles (CRUD) tout en protegeant les roles systeme,
+- d'attribuer `isAdmin`, les roles RBAC et les permissions directes a un utilisateur sans polluer le groupe `user:write` (commit `0fc4e16`).
+
+Le ticket n'introduit **aucune logique d'autorisation metier** : toute la verification `is_granted('module.resource.action')` est traitee par le voter du ticket #345. A ce stade, les operations sont gardees par un simple `is_granted('ROLE_ADMIN')`, remplace au #345.
+
+## 2. Perimetre
+
+### IN
+
+- Exposer l'entite `Permission` en API Platform en lecture seule (`GetCollection`, `Get`), groupe `permission:read`, filtres `module` et `orphan`.
+- Exposer l'entite `Role` en API Platform avec CRUD complet (`GetCollection`, `Get`, `Post`, `Patch`, `Delete`), groupes `role:read` et `role:write`, filtre `isSystem`.
+- Ajouter un processor `RoleProcessor` decorant `PersistProcessor` et `RemoveProcessor` pour :
+  - refuser la suppression d'un role systeme en traduisant `SystemRoleDeletionException` en `403`,
+  - empecher la mutation de `code` et `isSystem` sur un role systeme existant.
+- Ajouter une operation nommee `user_rbac_patch` (`PATCH /api/users/{id}/rbac`) sur l'entite `User` avec son propre groupe `user:rbac:write` exposant `isAdmin`, `roles` et `directPermissions`. Laisser `user:write` propre pour les champs profil (compatible avec la decision de `0fc4e16`). Le nom explicite est indispensable : API Platform 4 identifie les operations par nom, un `new Patch` sans `name:` entrerait en collision avec l'operation profil existante.
+- Ajouter un processor `UserRbacProcessor` qui persiste les mutations RBAC de l'utilisateur sans toucher au password hashing (decorator de `PersistProcessor`, pas du `UserPasswordHasherProcessor`).
+- Ajouter sur `Role` les contraintes Symfony Validator : `UniqueEntity(fields: ['code'])`, `Assert\NotBlank` et `Assert\Regex` sur `code`, `Assert\NotBlank` sur `label` (cf. section 6).
+- Garder toutes les operations sous `is_granted('ROLE_ADMIN')` avec un commentaire `// TODO ticket #345 : remplacer par is_granted('core.roles.manage')`.
+- Tests PHPUnit unitaires (processors) et fonctionnels (`ApiTestCase`) couvrant les chemins nominaux et les cas 403/422.
+
+### OUT
+
+- Ticket `#345` : voter `PermissionVoter`, remplacement du `is_granted('ROLE_ADMIN')` par les codes de permission, composable front `usePermissions`.
+- Ticket `#346` : ecrans d'administration front (liste/edition des roles et permissions).
+- Ticket `#347` : UX des erreurs 403 et integration front de l'ecran de gestion des permissions utilisateur.
+- Endpoint d'ecriture sur `Permission` : la table reste la propriete exclusive de `app:sync-permissions` (source de verite = code).
+- Lecture des permissions effectives d'un `User` via `/api/me` : traitee au #345 en meme temps que le voter.
+- Exposition d'un endpoint de bulk-assign permissions sur plusieurs utilisateurs : hors scope.
+
+## 3. Fichiers a creer
+
+### Infrastructure - Processors
+
+- `/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/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/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/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/Starseed/src/Module/Core/Domain/Entity/Permission.php`
+
+- Ajouter l'attribut `#[ApiResource]` avec operations `GetCollection` + `Get` uniquement.
+- Normalization context : groupe `permission:read` uniquement.
+- Pas de `denormalizationContext` (lecture seule).
+- Security `is_granted('ROLE_ADMIN')` sur les deux operations (TODO #345).
+- Ajouter `#[Groups(['permission:read'])]` sur `$id`, `$code`, `$label`, `$module`, `$orphan`. Pas d'ajout du groupe `role:read` : on laisse API Platform serialiser la relation `Role::$permissions` en IRIs par defaut, le front resoudra les details en 2 appels si necessaire (decision explicite pour garder les payloads petits et les permissions paginable independamment).
+- Ajouter les filtres API Platform `SearchFilter` sur `module` (exact) et `BooleanFilter` sur `orphan`.
+
+Extrait attendu :
+
+```php
+#[ApiResource(
+    operations: [
+        new GetCollection(
+            security: "is_granted('ROLE_ADMIN')",
+            normalizationContext: ['groups' => ['permission:read']],
+        ),
+        new Get(
+            security: "is_granted('ROLE_ADMIN')",
+            normalizationContext: ['groups' => ['permission:read']],
+        ),
+    ],
+)]
+#[ApiFilter(SearchFilter::class, properties: ['module' => 'exact'])]
+#[ApiFilter(BooleanFilter::class, properties: ['orphan'])]
+```
+
+### Entite `Role`
+
+`/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`.
+- Processor `RoleProcessor::class` sur `Post`, `Patch` et `Delete`.
+- Security `is_granted('ROLE_ADMIN')` sur les 5 operations (TODO #345).
+- Groupes :
+  - `$id` : `role:read`.
+  - `$code` : `role:read`, `role:write`. L'immuabilite apres creation est portee par `RoleProcessor` (variante A, cf. section 5), pas par un decoupage de groupes.
+  - `$label` : `role:read`, `role:write`.
+  - `$description` : `role:read`, `role:write`.
+  - `$isSystem` : `role:read` (jamais writable via API).
+  - `$permissions` : `role:read`, `role:write`. Serialise en IRIs (comportement API Platform par defaut sur une relation ManyToMany).
+- Filtre `BooleanFilter` sur `isSystem`.
+- **Important** : le constructeur actuel `public function __construct(string $code, string $label, bool $isSystem = false, ?string $description = null)` doit etre compatible avec la denormalisation API Platform sur `POST`. API Platform 4 resout les arguments du constructeur par nom de propriete denormalise. Verifier (ou adapter) que `isSystem` ne peut pas etre injecte par le POST car il n'est pas dans `role:write`.
+
+### Entite `User`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php`
+
+- Ajouter dans la liste des operations `ApiResource` existantes une operation dediee :
+
+```php
+new Patch(
+    name: 'user_rbac_patch',
+    uriTemplate: '/users/{id}/rbac',
+    security: "is_granted('ROLE_ADMIN')",
+    denormalizationContext: ['groups' => ['user:rbac:write']],
+    processor: UserRbacProcessor::class,
+),
+```
+
+Le `name:` est OBLIGATOIRE : sans lui, API Platform 4 deduit un nom par defaut qui peut collisionner avec la `Patch` profil existante (meme classe, meme methode HTTP) et provoquer un ecrasement silencieux de la route `/api/users/{id}`.
+
+- Ajouter le groupe `user:rbac:write` sur les proprietes :
+  - `$isAdmin`
+  - `$roles`
+  - `$directPermissions`
+- Ne PAS toucher `user:write` : la decision de `0fc4e16` est confirmee par ce ticket.
+
+Raison de l'endpoint dedie (option B) :
+- Separation des preoccupations : un `PATCH /api/users/{id}` reste un endpoint "profil" ; la promotion admin et la gestion des permissions est un acte administratif explicite et tracable.
+- Facilite future l'ajout d'un audit log dedie (`#355` audit log project) sur l'endpoint RBAC sans polluer l'audit profil.
+- Contrat front simple : une seule route, un seul groupe, une seule validation.
+
+## 5. Regles metier et cas limites
+
+### Role
+
+- **Creation (`POST /api/roles`)** :
+  - `code`, `label` obligatoires. `description` optionnel. `permissions` optionnel (tableau d'IRIs).
+  - `isSystem` est toujours `false` pour les roles crees via API (n'est pas dans `role:write`).
+  - Unicite du `code` geree par la contrainte DB `uniq_role_code` → 422 via `UniqueEntity` validator a ajouter sur l'entite (voir section 6).
+
+- **Modification (`PATCH /api/roles/{id}`)** :
+  - `label`, `description`, `permissions` modifiables librement, y compris sur un role systeme (utile pour customiser l'apparence dans l'UI sans casser la relation).
+  - `code` **immuable apres creation** — strategie retenue (variante A) : un seul groupe `role:write` contenant `code`, et une garde centralisee dans `RoleProcessor`. Le processor compare la valeur entrante a l'etat d'origine via `UnitOfWork::getOriginalEntityData($role)['code']` ; si elle differe, leve `BadRequestHttpException` avec un message francais explicite. Regle unique et uniforme : roles systeme ET roles customs sont concernes. Justification : garder la regle metier dans le domaine applicatif plutot que dupliquer les groupes de serialisation.
+
+- **Suppression (`DELETE /api/roles/{id}`)** :
+  - `RoleProcessor` appelle `$role->ensureDeletable()` avant de deleguer au `RemoveProcessor`.
+  - `SystemRoleDeletionException` est catchee et re-levee en `Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException` (403).
+  - Les relations `user_role` et `role_permission` sur ce role sont nettoyees automatiquement par le `ON DELETE CASCADE` des contraintes `FK_2DE8C6A3D60322AC` (`user_role.role_id`) et `FK_6F7DF886D60322AC` (`role_permission.role_id`) posees dans `migrations/Version20260414150034.php`. Aucun nettoyage manuel necessaire dans `RoleProcessor`. Verifier en test fonctionnel par un DELETE d'un role custom attache a un user, puis assert que le user existe toujours et que `user_role` est vide pour ce couple.
+
+### Permission
+
+- Lecture seule via API. Aucun endpoint de mutation.
+- Si un admin veut forcer une permission sur un utilisateur, il passe par `directPermissions` de `User`.
+
+### User (operation RBAC)
+
+- `PATCH /api/users/{id}/rbac` n'accepte que `isAdmin`, `roles`, `directPermissions`. Tout autre champ dans le payload est ignore (comportement par defaut d'API Platform avec un `denormalizationContext` restreint).
+- **Garde minimale auto-suicide** : `UserRbacProcessor` refuse (`BadRequestHttpException` 400) toute requete ou l'user cible est egal a l'user courant du `Security::getUser()` ET `isAdmin` passe de `true` a `false`. Sans cette garde, un admin peut se degrader seul et perdre acces a l'endpoint, creant une situation de recovery penible. C'est une garde locale et pragmatique, volontairement plus stricte que "le dernier admin" : on interdit l'auto-degradation, point. La garde "plus d'un admin restant" reste reportee au #345 ou un inventaire global fera sens avec le voter. TODO a placer dans le processor avec reference a #345.
+- Le password n'est jamais touche par cet endpoint (contrairement a `UserPasswordHasherProcessor` sur `PATCH /api/users/{id}`).
+
+## 6. Validation
+
+- Ajouter sur `Role` une contrainte `#[UniqueEntity(fields: ['code'])]` pour un 422 propre au lieu d'un 500 SQL en cas de conflit.
+- Ajouter sur `Role::$code` un `#[Assert\NotBlank]` et un `#[Assert\Regex('/^[a-z][a-z0-9_]*$/')]` (meme convention que les permissions).
+- Ajouter sur `Role::$label` un `#[Assert\NotBlank]`.
+
+## 7. Plan de tests
+
+### Unitaires
+
+**`RoleProcessorTest`**
+
+- `process()` d'un role non-systeme en DELETE delegue au `RemoveProcessor` sans lever.
+- `process()` d'un role systeme en DELETE leve `AccessDeniedHttpException` (403) et n'appelle pas le decorator.
+- `process()` d'un role systeme en PATCH dont le `code` a change leve `BadRequestHttpException`.
+- `process()` d'un role systeme en PATCH dont seuls `label`/`permissions` changent delegue au `PersistProcessor`.
+- `process()` d'un role non-systeme en POST delegue au `PersistProcessor`.
+
+**`UserRbacProcessorTest`**
+
+- `process()` persiste un user avec `isAdmin = true` via le decorator.
+- `process()` persiste une collection de `roles` mise a jour.
+- `process()` ne declenche jamais le hashing de password (verifier que `UserPasswordHasherProcessor` n'est pas dans la chaine).
+
+### Fonctionnels (`ApiTestCase`)
+
+**`PermissionApiTest`**
+
+- `GET /api/permissions` en tant qu'admin retourne la liste des permissions synchronisees.
+- `GET /api/permissions?module=core` filtre par module.
+- `GET /api/permissions?orphan=true` retourne uniquement les orphelines.
+- `GET /api/permissions/{id}` retourne les champs attendus (groupe `permission:read`).
+- `POST /api/permissions` en tant qu'admin retourne `405 Method Not Allowed`.
+- `GET /api/permissions` non authentifie retourne `401`.
+- `GET /api/permissions` en tant que user standard retourne `403`.
+
+**`RoleApiTest`**
+
+- `POST /api/roles` avec `{code, label, description}` retourne `201` et persiste `isSystem = false`.
+- `POST /api/roles` avec un `code` deja utilise retourne `422`.
+- `POST /api/roles` avec un `code` invalide (`MAJ`, `space`) retourne `422`.
+- `PATCH /api/roles/{id}` sur un role custom modifie `label` et ajoute des permissions via IRIs → `200`.
+- `PATCH /api/roles/{id}` sur le role `admin` (systeme) modifiant seulement `label` → `200`.
+- `PATCH /api/roles/{id}` sur le role `admin` tentant de modifier `code` → `400`.
+- `DELETE /api/roles/{id}` sur un role custom → `204`.
+- `DELETE /api/roles/{id}` sur le role `admin` → `403` avec `SystemRoleDeletionException` traduite.
+- `DELETE /api/roles/{id}` d'un role custom attache a un user : le user reste, la relation `user_role` est nettoyee par le CASCADE.
+- Toute operation sans auth retourne `401`.
+- Toute operation en tant que user standard retourne `403`.
+
+**`UserRbacApiTest`**
+
+- `PATCH /api/users/{id}/rbac` en tant qu'admin avec `{isAdmin: true}` promeut le user.
+- `PATCH /api/users/{id}/rbac` avec `{roles: [IRI...]}` remplace la collection de roles RBAC.
+- `PATCH /api/users/{id}/rbac` avec `{directPermissions: [IRI...]}` remplace les permissions directes.
+- `PATCH /api/users/{id}/rbac` en tant que user standard retourne `403`.
+- `PATCH /api/users/{id}/rbac` non authentifie retourne `401`.
+- `PATCH /api/users/{id}/rbac` avec un champ `username` dans le payload n'est pas persiste (denormalization context restreint).
+- `PATCH /api/users/{id}` sans `/rbac` avec `{isAdmin: true}` ne modifie PAS `isAdmin` (confirme la decision `0fc4e16`).
+
+## 8. Securite et traduction d'exceptions
+
+- `SystemRoleDeletionException` → `AccessDeniedHttpException` (403) dans `RoleProcessor` (pas via un listener global : on garde la traduction locale au perimetre RBAC).
+- `BadRequestHttpException` pour la mutation de `code` sur un role systeme : message explicite en francais, dans le payload Hydra `hydra:description`.
+- Toutes les routes ont pour l'instant `security: "is_granted('ROLE_ADMIN')"`. Un commentaire `// TODO ticket #345` doit etre present sur chaque attribut pour faciliter le remplacement.
+
+## 9. Conventions et architecture
+
+- Respect strict du modular monolith : tous les fichiers crees vivent dans `src/Module/Core/` ou `tests/Module/Core/`. Aucun import depuis un autre module.
+- `declare(strict_types=1)` en tete des nouveaux fichiers.
+- Commentaires PHP en francais, identifiants anglais (`CLAUDE.md`).
+- Processors branches via l'autoconfiguration Symfony ; aucun wiring manuel dans `services.yaml` attendu si le constructeur est injecte proprement.
+- Pattern de decorator : utiliser `#[AsDecorator]` ou `#[Autoconfigure]` pour brancher le processor en tant que decorator du `PersistProcessor` API Platform, selon le pattern deja utilise par `UserPasswordHasherProcessor`.
+- Aucune nouvelle entree necessaire dans `config/modules.php` ni `config/sidebar.php`.
+
+## 10. Ordre d'execution recommande
+
+1. Ajouter l'attribut `#[ApiResource]` et les `#[Groups]` sur `Permission`. Ecrire `PermissionApiTest`.
+2. Ajouter les contraintes Validator sur `Role`. Ajouter `#[ApiResource]` et les `#[Groups]` sur `Role` **sans** processor dans un premier temps pour valider le CRUD nominal.
+3. Creer `RoleProcessor` et le brancher en decorator. Ajouter les gardes systeme. Ecrire `RoleProcessorTest` + cas `RoleApiTest`.
+4. Creer `UserRbacProcessor`. Ajouter l'operation `/users/{id}/rbac` et le groupe `user:rbac:write` sur `User`. Ecrire `UserRbacProcessorTest` + `UserRbacApiTest`.
+5. `make test` complet + `make php-cs-fixer-allow-risky`.
+6. Documentation : referencer ce spec dans `docs/rbac/` et mettre a jour le fil conducteur RBAC si un index existe.
+
+## 11. Risques et points d'attention
+
+- **Constructeur de `Role` et denormalisation POST** : API Platform 4 resout les arguments du constructeur par nom ; `isSystem` est dans la signature mais pas dans `role:write`, donc un client ne peut pas l'injecter — a verifier par un test explicite ("POST avec `isSystem: true` est ignore").
+- **`code` immuable** : strategie retenue (garde dans processor) simple mais demande une lecture de l'etat initial du role avant persistance. Utiliser `UnitOfWork::getOriginalEntityData()` pour recuperer la valeur d'origine proprement.
+- **Cascade de delete role → user_role** : depend de `ON DELETE CASCADE` pose par la migration #343. Verifier explicitement en test fonctionnel qu'aucune `ForeignKeyConstraintViolationException` ne remonte.
+- **`UniqueEntity` sur `code`** : ne couvre pas les conflits en race condition, la DB reste la garde ultime. Acceptable.
+- **Pas de filtre sur le `module` de Permission cote front** au #346 sans le filtre API : s'assurer que le filtre est bien pose ici.
+- **Auto-retrait du dernier admin** : garde d'**auto-suicide** posee dans `UserRbacProcessor` (un admin ne peut pas se degrader lui-meme, cf. section 5). La garde "plus d'un admin restant" au niveau global reste reportee au voter #345.
+- **Infra de test fonctionnel (fixtures et isolation)** : les tests `*ApiTest` dependent de la presence en base des roles systeme `admin` et `user`. L'infra actuelle doit fournir soit un reload des fixtures par classe de test, soit `DAMADoctrineTestBundle` pour transactionner chaque test. A verifier au debut de l'etape 1 de l'ordre d'execution ; si absent, ajouter un trait de bootstrap minimal `RbacFixturesTrait` qui insere les deux roles systeme avant chaque classe de test (pas par test, trop couteux). Ne pas bloquer le ticket sur cette question, adapter au vol.
+
+## 12. Criteres d'acceptation (DoD)
+
+- `GET /api/permissions` et `GET /api/permissions/{id}` fonctionnent, filtres `module` et `orphan` operationnels.
+- CRUD complet sur `/api/roles` operationnel, avec `isSystem` en lecture seule cote API.
+- `DELETE /api/roles/{admin_id}` retourne `403` avec un message metier.
+- `PATCH /api/roles/{admin_id}` autorise la modification de `label`/`permissions` mais refuse la modification de `code` avec `400`.
+- `PATCH /api/users/{id}/rbac` permet de modifier `isAdmin`, `roles` et `directPermissions` ; `PATCH /api/users/{id}` (profil) ne les modifie jamais.
+- Les operations API sont gardees par `is_granted('ROLE_ADMIN')` et commentees avec la TODO pointant vers #345.
+- `make test` passe ; `make php-cs-fixer-allow-risky` ne laisse aucun delta.
+- Aucun import croise entre modules ; tous les fichiers crees vivent dans `Module/Core/` ou `tests/Module/Core/`.
+- Le spec est mergee avec le code (meme PR ou PR precedente) pour rester la reference du ticket.
+
+## 13. Remarques de branche
+
+- Le ticket enonce "Branche a creer : `feat/rbac-api` depuis develop apres merge de #2".
+- Branche courante locale : `feat/rbac-core`. A confirmer avec l'utilisateur si PR #2 est mergee : si oui, se rebaser sur `develop` et creer `feat/rbac-api` propre ; sinon, empiler `feat/rbac-api` sur `feat/rbac-core` en attendant le merge.

docs/rbac/ticket-345-spec.md

@@ -0,0 +1,649 @@
+# Ticket #345 - 3/5 - Voter Symfony + composable usePermissions (Full-stack)
+
+## 1. Objectif
+
+Ce ticket remplace les gardes placeholder `is_granted('ROLE_ADMIN')` posees par le #344 sur les 13 operations API Platform du perimetre RBAC par des verifications metier basees sur les codes de permission livres au #343 (`core.users.view`, `core.roles.manage`, etc.). Il introduit le `PermissionVoter` Symfony qui interprete ces codes, avec un bypass total pour les utilisateurs `isAdmin = true` (decision gravee au #343 section 11). Il ferme la garde "dernier admin global" reportee par le #344 via un service domaine mutualise entre les chemins de mutation (`PATCH /users/{id}/rbac` et `DELETE /users/{id}`). Enfin il expose les permissions effectives de l'utilisateur courant via `/api/me` et livre le composable front `usePermissions()` qui les consomme.
+
+A l'issue de ce ticket, l'application dispose d'un systeme d'autorisation applicatif reel, utilisable par les tickets #346 (ecrans d'admin RBAC) et #347 (UX des erreurs 403). Aucune interface d'administration n'est livree ici : le ticket est un socle full-stack sans ecran dedie.
+
+## 2. Perimetre
+
+### IN
+
+- Ajouter la permission `core.roles.view` au catalogue `CoreModule::permissions()` et la synchroniser via `app:sync-permissions`. Documenter la regle par defaut "view + manage par ressource administrable" qui encadre les declarations futures.
+- Creer `PermissionVoter` Symfony qui :
+  - supporte les attributs au format `module.resource[.sub].action` (regex explicite) sans interferer avec `ROLE_*`,
+  - bypasse a `ACCESS_GRANTED` si `User::isAdmin() === true`,
+  - sinon compare l'attribut a `User::getEffectivePermissions()`.
+- Remplacer les 13 `is_granted('ROLE_ADMIN')` places par le #344 (et les operations User heritees du profil pre-#344) par les codes metier adequats sur les entites `Permission`, `Role` et `User`. Supprimer les commentaires `// TODO ticket #345` en meme temps.
+- Creer un service domaine `AdminHeadcountGuard` dans `src/Module/Core/Domain/Security/` qui encapsule la regle "il doit toujours rester au moins un administrateur sur l'instance" et leve `LastAdminProtectionException` quand l'operation ferait tomber le compteur a zero.
+- Brancher le guard dans `UserRbacProcessor` (apres la garde auto-suicide existante) et dans un nouveau `UserProcessor` decorateur de `RemoveProcessor` qui intercepte `DELETE /api/users/{id}`.
+- Ajouter `UserRepositoryInterface::countAdmins(): int` et son implementation Doctrine.
+- Enrichir `/api/me` en exposant `effectivePermissions: list<string>` via un `#[Groups(['me:read'])]` sur la methode existante `User::getEffectivePermissions()`. Aucun changement de `MeProvider`.
+- Livrer `frontend/shared/composables/usePermissions.ts` consommant `useAuthStore().user` (qui porte deja le payload `/api/me`). API publique : `can(code)`, `canAny(codes)`, `canAll(codes)`.
+- Etendre `frontend/shared/types/user-data.ts` avec les champs `isAdmin: boolean` et `effectivePermissions: string[]`.
+- Tests unitaires PHP : `PermissionVoterTest`, `AdminHeadcountGuardTest`, `UserProcessorTest`, extension de `UserRbacProcessorTest`.
+- Tests fonctionnels API : couverture 403 non-admin / 200 admin sur chaque operation des 3 ressources RBAC, cas "dernier admin global" sur PATCH et DELETE, expo `/api/me` avec `effectivePermissions`.
+- Test Vitest du composable `usePermissions`.
+
+### OUT
+
+- Ticket `#346` : ecrans d'administration RBAC front (liste/edition roles, picker permissions, admin user RBAC).
+- Ticket `#347` : UX des erreurs 403 (toasts, redirections, page 403 dediee), integration front complete des ecrans admin RBAC.
+- Decoration des items sidebar par permission : les items portent aujourd'hui un champ `module` owner ; le filtrage par permission individuelle sera ajoute au #346 quand l'UI en aura besoin.
+- Audit log des mutations RBAC : traite par le futur `#355` audit log project, deliberement independant.
+- Decoupe fine de `core.users.manage` en sous-permissions (`create`, `edit`, `delete`) : YAGNI, aucun use-case metier identifie a ce jour.
+- Cache des voter decisions : la verification est O(1) sur un `in_array` avec des collections deja `fetch=EAGER`, aucun cache necessaire.
+
+## 3. Fichiers a creer
+
+### Domaine - Securite
+
+- `/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/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/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/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/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/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/Starseed/tests/Module/Core/Api/MeApiTest.php` (si absent — sinon extension)
+  Couvre l'enrichissement du payload `/api/me`.
+- `/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/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/Starseed/src/Module/Core/CoreModule.php`
+
+Ajouter une cinquieme entree au catalogue :
+
+```php
+public static function permissions(): array
+{
+    return [
+        ['code' => 'core.users.view',        'label' => 'Voir les utilisateurs'],
+        ['code' => 'core.users.manage',      'label' => 'Gerer les utilisateurs (creer, editer, supprimer)'],
+        ['code' => 'core.roles.view',        'label' => 'Voir les roles RBAC'],
+        ['code' => 'core.roles.manage',      'label' => 'Gerer les roles et permissions'],
+        ['code' => 'core.permissions.view',  'label' => 'Voir le catalogue des permissions'],
+    ];
+}
+```
+
+La commande `app:sync-permissions` creera automatiquement `core.roles.view` a la prochaine execution, sans migration Doctrine necessaire (le catalogue est propriete exclusive de la commande de sync depuis le #343).
+
+### Entite `Permission`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Permission.php`
+
+Remplacer les 2 gardes placeholder :
+
+```php
+new GetCollection(
+    normalizationContext: ['groups' => ['permission:read']],
+    security: "is_granted('core.permissions.view')",
+),
+new Get(
+    normalizationContext: ['groups' => ['permission:read']],
+    security: "is_granted('core.permissions.view')",
+),
+```
+
+Supprimer les commentaires `// TODO ticket #345`.
+
+### Entite `Role`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/Role.php`
+
+Remplacer les 5 gardes placeholder :
+
+- `GetCollection` → `is_granted('core.roles.view')`
+- `Get` → `is_granted('core.roles.view')`
+- `Post` → `is_granted('core.roles.manage')`
+- `Patch` → `is_granted('core.roles.manage')`
+- `Delete` → `is_granted('core.roles.manage')`
+
+Supprimer les commentaires `// TODO ticket #345`.
+
+### Entite `User`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Entity/User.php`
+
+Remplacer les 6 gardes `ROLE_ADMIN` restantes :
+
+- `Get` (item) → `is_granted('core.users.view')`
+- `GetCollection` → `is_granted('core.users.view')`
+- `Post` → `is_granted('core.users.manage')`
+- `Patch` (profil, sans `name:`) → `is_granted('core.users.manage')`
+- `Patch` (`user_rbac_patch`) → `is_granted('core.users.manage')`
+- `Delete` → `is_granted('core.users.manage')`
+
+Note : l'operation `Get /me` n'a aucune garde (seulement `IS_AUTHENTICATED_FULLY` implicite via `security.yaml`). Ce n'est pas une operation RBAC, elle reste inchangee.
+
+Ajouter le processor `UserProcessor::class` sur l'operation `Delete` :
+
+```php
+new Delete(
+    security: "is_granted('core.users.manage')",
+    processor: UserProcessor::class,
+),
+```
+
+Exposer `getEffectivePermissions()` dans le groupe `me:read` — ajouter l'attribut sur la methode existante :
+
+```php
+#[Groups(['me:read'])]
+public function getEffectivePermissions(): array
+{
+    // implementation existante, inchangee
+}
+```
+
+Supprimer tous les commentaires `// TODO ticket #345` rencontres.
+
+### `UserRepositoryInterface`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Domain/Repository/UserRepositoryInterface.php`
+
+Ajouter la methode :
+
+```php
+/**
+ * Compte le nombre d'utilisateurs avec le flag isAdmin = true.
+ * Utilise par AdminHeadcountGuard pour verifier l'invariant
+ * "au moins un administrateur reste sur l'instance".
+ */
+public function countAdmins(): int;
+```
+
+### `DoctrineUserRepository`
+
+`/home/matthieu/dev_malio/Starseed/src/Module/Core/Infrastructure/Doctrine/DoctrineUserRepository.php`
+
+Implementer `countAdmins()` via un `QueryBuilder` simple :
+
+```php
+public function countAdmins(): int
+{
+    return (int) $this->createQueryBuilder('u')
+        ->select('COUNT(u.id)')
+        ->where('u.isAdmin = true')
+        ->getQuery()
+        ->getSingleScalarResult();
+}
+```
+
+### `UserRbacProcessor`
+
+`/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.
+
+Logique :
+
+```text
+1. Garde auto-suicide existante (inchangee).
+2. Si l'operation entraine la perte du flag isAdmin (wasAdmin && !data.isAdmin):
+     AdminHeadcountGuard::ensureAtLeastOneAdminRemainsAfterDemotion($data);
+3. Delegation au persist processor.
+```
+
+La detection "wasAdmin && !data.isAdmin" reutilise le meme `UnitOfWork::getOriginalEntityData()` deja utilise par la garde auto-suicide.
+
+### `frontend/shared/types/user-data.ts`
+
+Ajouter les champs :
+
+```ts
+export interface UserData {
+    id: number
+    username: string
+    isAdmin: boolean
+    effectivePermissions: string[]
+    // ... champs existants
+}
+```
+
+### `frontend/shared/services/auth.ts`
+
+A verifier : si `getCurrentUser()` type deja le retour sur `UserData`, rien a changer — les nouveaux champs arrivent automatiquement car l'API les renvoie. Si un mapping manuel est fait dans le service, l'etendre pour ne pas perdre `isAdmin` et `effectivePermissions`. A valider au debut de la task frontend.
+
+## 5. PermissionVoter - details d'implementation
+
+### Regex de support
+
+```php
+private const string PERMISSION_CODE_PATTERN = '/^[a-z][a-z0-9_]*(\.[a-z][a-z0-9_]*)+$/';
+```
+
+Garantit :
+- premier caractere alphabetique minuscule,
+- au moins un point de separation (ecarte les `ROLE_*`),
+- segments en snake_case minuscules coherents avec les permissions declarees par les modules.
+
+### `supports(string $attribute, mixed $subject): bool`
+
+Retourne `(bool) preg_match(self::PERMISSION_CODE_PATTERN, $attribute)`. Le `$subject` est ignore : les permissions sont portees par l'utilisateur, pas par une ressource ciblee. Pour l'instant l'autorisation est uniquement basee sur l'identite de l'acteur — les scopes ressource (ex. "edit this specific role") seront traites par un voter dedie si un module metier en a besoin.
+
+### `voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token): bool`
+
+```text
+$user = $token->getUser()
+if (!$user instanceof User) return false                                // ACCESS_DENIED
+if ($user->isAdmin())     return true                                   // bypass total
+return in_array($attribute, $user->getEffectivePermissions(), true)
+```
+
+### Interaction avec les autres voters
+
+Strategie par defaut Symfony `affirmative` : des qu'un voter renvoie GRANTED, l'acces est accorde. `PermissionVoter` ne vote **jamais** sur les attributs `ROLE_*` (filtres par `supports()`), donc :
+
+- l'authentification classique `IS_AUTHENTICATED_FULLY` et `ROLE_USER` continue de fonctionner via `AuthenticatedVoter` et `RoleVoter` de Symfony,
+- un eventuel `is_granted('ROLE_ADMIN')` residuel dans le code continuerait de fonctionner via `RoleVoter` sans interference.
+
+Un test fonctionnel `make test` complet verifiera que l'auth standard marche toujours apres ajout du voter.
+
+### Wiring
+
+`autoconfigure: true` dans `services.yaml` (deja active) detecte la classe via l'interface `VoterInterface`. **Aucun** wiring manuel necessaire dans `services.yaml`.
+
+## 6. AdminHeadcountGuard - regles metier
+
+### Invariant global
+
+> Apres toute operation terminee avec succes, `countAdmins() >= 1`.
+
+### API publique
+
+```php
+final class AdminHeadcountGuard
+{
+    public function __construct(
+        private readonly UserRepositoryInterface $userRepository,
+    ) {}
+
+    /**
+     * Leve si retirer le flag isAdmin a $user ferait tomber le total a zero.
+     * A appeler UNIQUEMENT dans la branche "l'operation retire effectivement isAdmin".
+     */
+    public function ensureAtLeastOneAdminRemainsAfterDemotion(User $user): void;
+
+    /**
+     * Leve si supprimer physiquement $user ferait tomber le total a zero.
+     * A appeler UNIQUEMENT dans la branche DELETE sur un user admin.
+     */
+    public function ensureAtLeastOneAdminRemainsAfterDeletion(User $user): void;
+}
+```
+
+Deux methodes semantiques distinctes plutot qu'une methode generique avec un parametre booleen : ca rend les call-sites lisibles et les tests auto-documentes.
+
+### Logique
+
+Pour les deux methodes, la regle effective est identique :
+
+```text
+if ($this->userRepository->countAdmins() <= 1) {
+    throw new LastAdminProtectionException(
+        'Impossible : au moins un administrateur doit rester sur l\'instance.'
+    );
+}
+```
+
+Les appelants ne passent le guard que si l'operation retire reellement un admin — le guard n'a donc pas a raisonner sur l'etat entrant. Cette separation des responsabilites (le processor decide "est-ce qu'on perd un admin ?", le guard applique "si oui, compte") garde les deux composants minimalistes et testables independamment.
+
+### Cas couverts (tests)
+
+1. `countAdmins() > 1` + demotion → OK (pas d'exception)
+2. `countAdmins() == 1` + demotion → LEVE
+3. `countAdmins() > 1` + deletion → OK
+4. `countAdmins() == 1` + deletion → LEVE
+5. `countAdmins() == 2` + demotion → OK (il en reste 1)
+6. `countAdmins() == 0` + demotion → LEVE (cas theorique, garde defensive)
+
+## 7. Garde "dernier admin" - cohabitation avec l'auto-suicide
+
+Les deux gardes sont distinctes et non fusionnables :
+
+- **Auto-suicide (existante, #344)** : "un admin ne peut pas retirer ses PROPRES droits admin". S'applique meme s'il existe d'autres admins. Protege contre le recovery penible d'un admin qui se cliquerait degrade tout seul.
+- **Dernier admin global (nouveau, #345)** : "l'instance doit toujours avoir au moins un admin". S'applique meme si ce n'est pas l'operation d'un admin sur lui-meme (admin A degrade admin B alors qu'ils sont les deux seuls).
+
+Ordre d'evaluation dans `UserRbacProcessor` :
+
+```text
+1. Garde auto-suicide (cas particulier, message dedie)
+2. Garde dernier admin global (cas general, message dedie)
+3. Persist
+```
+
+Les messages d'erreur distincts aident le front a afficher le bon feedback utilisateur. Le test `UserRbacProcessorTest` doit couvrir les deux branches.
+
+### Cas limite : l'admin se degrade lui-meme ET il est le dernier
+
+Les deux gardes s'appliqueraient. Comme auto-suicide est evalue en premier, c'est son message qui est retourne ("Vous ne pouvez pas retirer vos propres droits administrateur."). Comportement acceptable et coherent : le user voit d'abord la regle la plus specifique.
+
+## 8. /api/me enrichi - contrat
+
+Payload avant :
+```json
+{
+  "@context": "/api/contexts/User",
+  "@id": "/api/users/5",
+  "@type": "User",
+  "id": 5,
+  "username": "admin",
+  "isAdmin": true
+}
+```
+
+Payload apres :
+```json
+{
+  "@context": "/api/contexts/User",
+  "@id": "/api/users/5",
+  "@type": "User",
+  "id": 5,
+  "username": "admin",
+  "isAdmin": true,
+  "effectivePermissions": [
+    "core.permissions.view",
+    "core.roles.manage",
+    "core.roles.view",
+    "core.users.manage",
+    "core.users.view"
+  ]
+}
+```
+
+Contrat :
+- `effectivePermissions` est toujours un tableau de strings (jamais `null`).
+- L'ordre est deterministe (trie alphabetique — implementation existante du #343).
+- Aucun doublon.
+- Pour un admin, le tableau contient les permissions effectives (non vides si le role `admin` a des permissions OU si l'user a des directPermissions, vide sinon). **Le bypass ne se refletera PAS dans ce tableau** : `isAdmin: true` reste la source de verite du bypass. Le front l'utilise en priorite dans le composable.
+
+### Pourquoi le bypass n'est pas materialise dans `effectivePermissions`
+
+Mettre "toutes les permissions connues" dans le tableau pour les admins serait tentant mais faux :
+- il faudrait enumerer dynamiquement toutes les permissions de tous les modules actifs, ce qui recouvre la responsabilite de `app:sync-permissions`,
+- le tableau gonflerait inutilement le payload `/api/me` a chaque requete,
+- et surtout il deviendrait faux si un module declare une nouvelle permission apres une execution de sync : l'admin aurait temporairement un tableau incomplet alors que son bypass reste effectif.
+
+La source de verite du bypass est `isAdmin: boolean`. Le composable front regarde ce flag en premier.
+
+## 9. usePermissions - composable front
+
+### API publique
+
+```ts
+export function usePermissions() {
+  const auth = useAuthStore()
+
+  // Verifie si l'utilisateur courant a la permission demandee.
+  // Bypass automatique si isAdmin = true, coherent avec PermissionVoter cote back.
+  const can = (code: string): boolean => {
+    const user = auth.user
+    if (!user) return false
+    if (user.isAdmin) return true
+    return user.effectivePermissions.includes(code)
+  }
+
+  const canAny = (codes: string[]): boolean => codes.some(can)
+  const canAll = (codes: string[]): boolean => codes.every(can)
+
+  return { can, canAny, canAll }
+}
+```
+
+### Proprietes
+
+- **Stateless** : aucun `ref` module-level, aucune reactivite dediee. Tout passe par `useAuthStore().user` qui est deja reactif via Pinia.
+- **Aucun fetch propre** : les permissions arrivent par `/api/me` au login (via `useAuthStore().ensureSession()` ou `.login()`), aucun appel supplementaire n'est necessaire.
+- **Aucun reset** : le logout efface deja `authStore.user`, donc `can()` retombe naturellement a `false`.
+- **Bypass synchrone avec le back** : la regle `if (user.isAdmin) return true` duplique deliberement le bypass du `PermissionVoter` cote back. Commentaire francais dans le composable pour rappeler que les deux doivent bouger ensemble si la regle change un jour.
+
+### Pas de variante `can` reactive (computed)
+
+Utiliser `computed(() => can('core.users.view'))` dans un composant fonctionne automatiquement puisque `auth.user` est reactif Pinia — Vue re-evalue le computed quand `user` change. Pas besoin d'API supplementaire du composable pour ca.
+
+## 10. Validation
+
+Aucune nouvelle contrainte Symfony Validator introduite par ce ticket. Les gardes metier (`AdminHeadcountGuard`, `SystemRoleDeletionException`, auto-suicide) vivent dans les processors et le domaine, pas dans la couche Validator.
+
+## 11. Plan de tests
+
+### Unitaires PHP
+
+**`PermissionVoterTest`**
+
+- `supports('core.users.view')` retourne `true`.
+- `supports('ROLE_ADMIN')` retourne `false` (n'interfere pas avec les voters core).
+- `supports('IS_AUTHENTICATED_FULLY')` retourne `false`.
+- `supports('invalid attribute')` retourne `false` (espace, majuscule).
+- `voteOnAttribute` avec un `User` admin retourne GRANTED quelle que soit la permission.
+- `voteOnAttribute` avec un user portant la permission retourne GRANTED.
+- `voteOnAttribute` avec un user ne portant pas la permission retourne DENIED.
+- `voteOnAttribute` avec un token non-authentifie (user null) retourne DENIED.
+
+**`AdminHeadcountGuardTest`**
+
+- `ensureAtLeastOneAdminRemainsAfterDemotion` : `countAdmins == 2` → OK.
+- Meme methode : `countAdmins == 1` → `LastAdminProtectionException`.
+- Meme methode : `countAdmins == 0` → leve aussi (garde defensive).
+- `ensureAtLeastOneAdminRemainsAfterDeletion` : memes 3 cas, memes resultats.
+- `UserRepositoryInterface::countAdmins()` est mockee avec une valeur fixe pour chaque cas (test unitaire isole, pas d'acces BDD).
+
+**`UserProcessorTest`**
+
+- `process()` sur un user non-admin en DELETE delegue au `RemoveProcessor`.
+- `process()` sur un user admin en DELETE avec `countAdmins() > 1` delegue.
+- `process()` sur un user admin en DELETE avec `countAdmins() == 1` leve `BadRequestHttpException` (traduction de `LastAdminProtectionException`).
+- `process()` avec `$data` non-`User` leve `LogicException` (fail-fast coherent avec `UserRbacProcessor` / `RoleProcessor`).
+
+**`UserRbacProcessorTest` (extension)**
+
+- Cas existants auto-suicide : gardes en l'etat.
+- Nouveau : PATCH RBAC par admin A sur admin B, `isAdmin: false`, `countAdmins() == 1` (apres perte = 0) → `BadRequestHttpException` "dernier admin".
+- Nouveau : meme operation avec `countAdmins() == 2` → delegue au persist processor.
+- Nouveau : PATCH RBAC qui ne touche pas `isAdmin` (change juste `roles` ou `directPermissions`) ne consulte jamais le guard, meme si `countAdmins() == 1`.
+
+### Fonctionnels API PHP (`AbstractApiTestCase`)
+
+Pour les 3 ressources (`Permission`, `Role`, `User`), pour chaque operation, 3 cas :
+
+1. Admin → succes (confirme que le voter bypass fonctionne).
+2. User standard **avec** la permission requise (attachee via fixture dediee) → succes.
+3. User standard **sans** la permission → `403`.
+
+**Fixtures de test** : ajouter des users "portant une permission specifique" n'est pas souhaitable dans `AppFixtures` (fixtures de dev). Creer a la place un trait ou une helper method `AbstractApiTestCase::createUserWithPermission(string $code): User` qui instancie a la volee un user + un role + l'attache dans le test lui-meme, transactionne si `DAMADoctrineTestBundle` est en place.
+
+**Cas specifiques a ajouter** :
+
+- `UserRbacApiTest` : PATCH `/api/users/{lastAdminId}/rbac` avec `isAdmin: false` par un **autre** admin → `400` avec message "dernier admin" (et pas "auto-suicide").
+- `UserApiTest` (nouveau ou extension) : DELETE `/api/users/{lastAdminId}` par un autre admin → `400` avec message "dernier admin".
+- `UserApiTest` : DELETE `/api/users/{nonAdminId}` fonctionne quel que soit le count (la garde ne doit pas etre appelee).
+- `MeApiTest` : `GET /api/me` en tant qu'admin retourne `effectivePermissions` (tableau, meme vide si pas de role populaire).
+- `MeApiTest` : `GET /api/me` en tant que user standard retourne `effectivePermissions` = list triee des codes issus de ses roles et directPermissions.
+
+### Tests frontend (Vitest)
+
+**`usePermissions.test.ts`**
+
+- Utilisateur null → `can()` retourne `false` pour n'importe quel code.
+- Utilisateur admin → `can('core.users.view')` retourne `true` meme si `effectivePermissions` est vide.
+- Utilisateur non-admin avec `['core.users.view']` → `can('core.users.view')` = `true`, `can('core.users.manage')` = `false`.
+- `canAny(['a', 'b'])` retourne `true` si l'un des deux matche, `false` sinon.
+- `canAll(['a', 'b'])` retourne `true` uniquement si les deux matchent.
+
+Convention de test frontend a valider avant : si le projet Nuxt a deja un setup Vitest, on s'y aligne ; sinon on note une TODO pour ajouter la conf (sans bloquer le ticket — le composable est assez simple pour etre revu manuellement).
+
+## 12. Securite et traduction d'exceptions
+
+- `LastAdminProtectionException` (domaine) → `BadRequestHttpException` (400) dans les processors. Message francais : "Impossible : au moins un administrateur doit rester sur l'instance."
+- `SystemRoleDeletionException` (existante) → traduction inchangee par le #344, rien a modifier.
+- Auto-suicide existante → message inchange : "Vous ne pouvez pas retirer vos propres droits administrateur."
+- Pas de listener global : traduction locale dans chaque processor, coherent avec le pattern du #344.
+
+## 13. Conventions et architecture
+
+- Respect strict du modular monolith : tous les fichiers crees vivent dans `src/Module/Core/`, `tests/Module/Core/`, ou `frontend/shared/`. Aucun import inter-modules.
+- `declare(strict_types=1)` en tete de tous les nouveaux fichiers PHP.
+- Commentaires PHP et TS en francais, identifiants en anglais (`CLAUDE.md`).
+- Autoconfigure Symfony detecte `PermissionVoter` via `VoterInterface`. `AdminHeadcountGuard` est autowire via son constructeur standard.
+- Les processors suivent le pattern du #344 : `final class`, `#[Autowire]` sur l'inner, `LogicException` fail-fast sur type invalide.
+- Aucune entree necessaire dans `config/modules.php` ni `config/sidebar.php`.
+- Aucune migration Doctrine : le catalogue de permissions est synchronise par `app:sync-permissions` (commande existante #343), pas par une migration.
+
+## 14. Ordre d'execution recommande (subagent-driven)
+
+1. **Catalogue** — ajouter `core.roles.view` dans `CoreModule::permissions()`. Executer `app:sync-permissions` en local pour verifier l'ajout. Pas de test propre (couvert indirectement par les tests sync existants du #343).
+2. **Guard domaine** — creer `LastAdminProtectionException`, ajouter `UserRepositoryInterface::countAdmins()` + impl Doctrine, creer `AdminHeadcountGuard`. Ecrire `AdminHeadcountGuardTest`.
+3. **PermissionVoter** — implementation + `PermissionVoterTest`. Verifier via `make test` que l'auth standard reste verte (aucune regression sur `ROLE_*`).
+4. **UserProcessor DELETE** — creer le processor, wire sur l'operation `Delete` de `User`. Ecrire `UserProcessorTest`.
+5. **UserRbacProcessor extension** — injecter `AdminHeadcountGuard`, brancher apres la garde auto-suicide. Etendre `UserRbacProcessorTest` avec les nouveaux cas.
+6. **Remplacement des 13 gardes ROLE_ADMIN** — modifier `Permission`, `Role`, `User`. Supprimer tous les `// TODO ticket #345`.
+7. **`/api/me` enrichi** — ajouter `#[Groups(['me:read'])]` sur `getEffectivePermissions()`. Creer ou etendre `MeApiTest`.
+8. **Tests fonctionnels RBAC complets** — helper `createUserWithPermission()` dans `AbstractApiTestCase`, puis couverture 403 non-admin / 200 avec permission sur toutes les operations RBAC des 3 ressources. Cas "dernier admin global" PATCH et DELETE.
+9. **Frontend types + composable** — etendre `UserData`, creer `usePermissions.ts`, ecrire le test Vitest.
+10. **Verification finale** — `make test` vert, `make php-cs-fixer-allow-risky` sans delta, build Nuxt OK si modifie.
+
+Chaque etape doit etre revue (spec compliance + code quality) avant de passer a la suivante, pattern subagent-driven-development retenu pour le #344.
+
+## 15. Risques et points d'attention
+
+- **Ordre des voters Symfony** : `PermissionVoter` ne vote jamais sur `ROLE_*` grace au regex de support. Risque quasi-nul d'interference avec `RoleVoter`/`AuthenticatedVoter`, a valider par un test fonctionnel `/login_check` + `GET /api/me` apres ajout du voter.
+- **Serialisation de `getEffectivePermissions()` via API Platform** : la methode existe depuis le #343 mais n'a jamais ete sous serializer. Risque de rencontrer un `ReflectionException` si le nom de propriete deduit ne matche pas (cas rare, API Platform gere les getters normalement). Mitigation : test fonctionnel `/api/me` en premiere validation.
+- **Cout SQL de `countAdmins()`** : 1 `COUNT(*)` par operation de mutation admin sensible. Index recommande sur `user.is_admin` (`idx_user_is_admin`) — a verifier si la migration #343 l'a deja cree. Si non, c'est un ajustement cosmetique qu'on peut reporter puisque la table `user` d'un CRM PME reste petite (< 1000 lignes).
+- **Bypass front/back desynchronise** : si un jour le bypass admin est affine cote back (ex: seulement sur certains modules), le composable front doit bouger en meme temps. Mitigation : commentaire francais explicite dans `usePermissions.ts` pointant vers cette spec.
+- **Tests fonctionnels et fixtures RBAC** : le #344 a introduit `AbstractApiTestCase`, mais les users de test portant une permission specifique (hors admin/user standard) n'existent pas dans les fixtures. Creer une helper `createUserWithPermission()` transactionnelle dans la classe de test, plutot que polluer `AppFixtures` avec des users de test dedies.
+- **Ordre d'evaluation auto-suicide vs dernier admin** : les deux gardes pourraient etre declenchees simultanement (admin unique qui se degrade lui-meme). L'auto-suicide gagne en premier par design. A couvrir explicitement par un test.
+- **Payload `/api/me` plus gros** : l'ajout de `effectivePermissions` alourdit chaque requete `/api/me`. Pour 5 permissions aujourd'hui c'est negligeable, mais si le catalogue grossit fortement (50+ permissions reparties sur plusieurs modules), il faudra peut-etre filtrer cote serveur (ne retourner que les permissions utiles au contexte front). Hors scope, mais a noter pour suivi.
+- **`UserData` partagee entre auth store et composable** : toute modification future de la shape `UserData` peut impacter `usePermissions`. Rester minimal dans le composable et laisser Pinia porter la verite.
+
+## 16. Criteres d'acceptation (DoD)
+
+- Le catalogue `CoreModule::permissions()` contient 5 entrees incluant `core.roles.view`.
+- `PermissionVoter` existe, supporte uniquement les attributs au format `module.resource.action`, bypass admin effectif, test unitaire complet.
+- Les 13 operations API Platform du perimetre RBAC sont toutes gardees par un code metier `core.*.*` et plus par `ROLE_ADMIN`. Les commentaires `// TODO ticket #345` ont disparu du code.
+- `AdminHeadcountGuard` existe comme service domaine, est consomme par `UserRbacProcessor` ET `UserProcessor`, teste en isolation.
+- `UserRepositoryInterface::countAdmins()` existe et est implementee.
+- `UserProcessor` intercepte `DELETE /api/users/{id}` et bloque la suppression du dernier admin avec un message explicite.
+- `UserRbacProcessor` bloque la demotion du dernier admin global (en plus de la garde auto-suicide existante) avec un message distinct.
+- `GET /api/me` retourne `effectivePermissions: string[]` et `isAdmin: boolean` dans son payload.
+- `frontend/shared/composables/usePermissions.ts` expose `can`, `canAny`, `canAll`, stateless, bypasse si `isAdmin`.
+- `frontend/shared/types/user-data.ts` inclut `isAdmin` et `effectivePermissions`.
+- Tests unitaires PHP : `PermissionVoterTest`, `AdminHeadcountGuardTest`, `UserProcessorTest`, extension `UserRbacProcessorTest` — tous verts.
+- Tests fonctionnels API : couverture 403 non-admin / 200 admin-ou-porteur sur chaque operation RBAC des 3 ressources, cas dernier admin PATCH et DELETE, `/api/me` enrichi.
+- Test Vitest `usePermissions.test.ts` vert (ou TODO documentee si setup Vitest absent du projet).
+- `make test` passe ; `make php-cs-fixer-allow-risky` ne laisse aucun delta.
+- Aucun import croise entre modules ; tous les fichiers PHP crees vivent dans `Module/Core/` ou `tests/Module/Core/`, tous les fichiers front dans `frontend/shared/`.
+- Le spec est mergee avec le code (meme PR #3 empilee sur `feat/rbac-api`) pour rester la reference du ticket.
+
+## 17. Remarques de branche
+
+- 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

@@ -0,0 +1,410 @@
+# Ticket #01 — 1/4 — Brique fondatrice du module Sites (Backend)
+
+## 1. Objectif
+
+Ce ticket livre la couche de donnees du module optionnel Sites. Il cree le bounded context, declare le module a Symfony, enregistre ses permissions RBAC, installe la table `site` en base et seed trois etablissements de demonstration utilises par les tickets suivants.
+
+Le resultat attendu est un socle de persistance activable par tenant via `config/modules.php`, sans UI, sans API publique, sans couplage au module Core, et sur lequel les tickets 2/3/4 pourront greffer : rattachement utilisateurs, selecteur de site dans la navbar, administration CRUD.
+
+## 2. Périmètre
+
+### IN
+
+- 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/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/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.
+
+### 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 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.
+
+## 3. Fichiers à créer
+
+### Domaine — Entité
+
+- `/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/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/Starseed/src/Module/Sites/Infrastructure/Doctrine/DoctrineSiteRepository.php` : implementation Doctrine de `SiteRepositoryInterface` basee sur `ServiceEntityRepository`.
+
+### Infrastructure — Migration
+
+- `/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/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/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/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/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
+
+Comme pour le ticket RBAC (ticket-343), le schema est decrit par les attributs Doctrine plutot que par le SQL brut. Le fichier de migration contient le SQL final (section 6).
+
+### Conventions respectées
+
+- `declare(strict_types=1)` en tete de tous les fichiers PHP.
+- Identifiants de classe et proprietes en anglais, commentaires en francais (cf. `CLAUDE.md`).
+- PostgreSQL : noms de colonnes en snake_case minuscules, Doctrine les deduit des proprietes camelCase (`postalCode` → `postal_code`, `fullAddress` → `full_address`, `createdAt` → `created_at`, `updatedAt` → `updated_at`).
+- Le nom de table `site` n'est pas un mot reserve PostgreSQL : pas de backtick necessaire.
+
+### Entité `Site`
+
+```php
+#[ORM\Entity(repositoryClass: DoctrineSiteRepository::class)]
+#[ORM\Table(name: 'site')]
+#[ORM\UniqueConstraint(name: 'uniq_site_name', columns: ['name'])]
+#[ORM\HasLifecycleCallbacks]
+#[UniqueEntity(fields: ['name'], message: 'Un site avec ce nom existe deja.')]
+class Site
+{
+    #[ORM\Id]
+    #[ORM\GeneratedValue]
+    #[ORM\Column]
+    private ?int $id = null;
+
+    #[ORM\Column(length: 100)]
+    #[Assert\NotBlank(message: 'Le nom du site est requis.')]
+    #[Assert\Length(max: 100, ...)]
+    private string $name;
+
+    #[ORM\Column(length: 100)]
+    #[Assert\NotBlank(message: 'La ville du site est requise.')]
+    #[Assert\Length(max: 100, ...)]
+    private string $city;
+
+    #[ORM\Column(name: 'postal_code', length: 10)]
+    #[Assert\NotBlank(message: 'Le code postal est requis.')]
+    #[Assert\Length(max: 10, ...)]
+    #[Assert\Regex(pattern: '/^\d{5}$/', message: '...')]
+    private string $postalCode;
+
+    #[ORM\Column(length: 7)]
+    #[Assert\NotBlank(message: 'La couleur est requise.')]
+    #[Assert\Regex(pattern: '/^#[0-9A-Fa-f]{6}$/', message: '...')]
+    private string $color;
+
+    #[ORM\Column(name: 'full_address', type: Types::TEXT)]
+    #[Assert\NotBlank(message: 'L\'adresse complete est requise.')]
+    #[Assert\Length(max: 500, ...)]
+    private string $fullAddress;
+
+    #[ORM\Column(name: 'created_at', type: Types::DATETIME_IMMUTABLE)]
+    private DateTimeImmutable $createdAt;
+
+    #[ORM\Column(name: 'updated_at', type: Types::DATETIME_IMMUTABLE)]
+    private DateTimeImmutable $updatedAt;
+}
+```
+
+Contraintes fonctionnelles :
+- `name` est unique en base (`uniq_site_name`) et porte egalement la contrainte applicative `UniqueEntity` pour que le validator remonte une violation lisible avant d'atteindre la violation DB.
+- `color` est contraint par regex a un code hex strict de 7 caracteres `#RRGGBB`, majuscules ou minuscules. La colonne `VARCHAR(7)` est dimensionnee au plus juste car la regex est exhaustive.
+- `postalCode` est contraint a 5 chiffres exacts via regex (format FR). La colonne `VARCHAR(10)` est volontairement plus large que la regex pour laisser marge si le projet etend plus tard la regex a d'autres formats (UK, PT, ...). Choix assume : evite une migration DDL au ticket suivant, cout DB negligeable sur un champ court.
+- `fullAddress` est de type `TEXT` (PostgreSQL) pour permettre une adresse multi-ligne, mais borne cote applicatif a 500 caracteres via `Assert\Length(max: 500)` comme garde DoS basique (une adresse FR complete tient largement dans cette enveloppe).
+- `createdAt` est seede dans le constructeur et **ne change plus jamais** apres persistance.
+- `updatedAt` est seede dans le constructeur a la meme valeur que `createdAt`, puis refresh a chaque update via le callback `#[ORM\PreUpdate]`.
+
+### Mapping Doctrine — `doctrine.yaml`
+
+```yaml
+# Mapping inconditionnelle du module Sites : la structure DB existe meme
+# si SitesModule::class est retire de config/modules.php. L'activation
+# fonctionnelle (ex: exposition des permissions, futurs endpoints API)
+# passe exclusivement par config/modules.php.
+Sites:
+    type: attribute
+    is_bundle: false
+    dir: '%kernel.project_dir%/src/Module/Sites/Domain/Entity'
+    prefix: 'App\Module\Sites\Domain\Entity'
+    alias: Sites
+```
+
+## 6. Plan de migration Doctrine
+
+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
+
+1. Creer la table `site` avec toutes les colonnes NOT NULL :
+   - `id INT GENERATED BY DEFAULT AS IDENTITY NOT NULL`
+   - `name VARCHAR(100) NOT NULL`
+   - `city VARCHAR(100) NOT NULL`
+   - `postal_code VARCHAR(10) NOT NULL`
+   - `color VARCHAR(7) NOT NULL`
+   - `full_address TEXT NOT NULL`
+   - `created_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL`
+   - `updated_at TIMESTAMP(0) WITHOUT TIME ZONE NOT NULL`
+   - `PRIMARY KEY (id)`
+2. Creer l'index unique `uniq_site_name` sur `site(name)` pour garantir l'invariant metier "un site porte un nom unique" au niveau DB. Le validator applicatif `UniqueEntity` s'appuie dessus en lecture avant qu'une tentative d'insertion concurrente ne remonte la violation DB.
+
+### `down()` — rollback
+
+1. `DROP TABLE site`. Aucune FK n'existe depuis ou vers cette table dans ce ticket ; le rollback est donc trivial et safe.
+
+### Precision timestamp
+
+PostgreSQL `TIMESTAMP(0) WITHOUT TIME ZONE` stocke a la seconde pres. Les DateTimeImmutable PHP portent une precision microseconde mais perdent cette precision au round-trip DB. Les tests unitaires de lifecycle doivent en tenir compte (cf. section 10 — usage de reflection plutot qu'un `sleep`).
+
+## 7. Intégration avec sync-permissions
+
+Le ticket ne modifie pas `SyncPermissionsCommand`. Il exploite l'algorithme existant (cf. ticket-343 section 7) en declarant `SitesModule::permissions()` dans un format strictement conforme au contrat attendu par la commande :
+
+```php
+public static function permissions(): array
+{
+    return [
+        ['code' => 'sites.view', 'label' => 'Voir les sites'],
+        ['code' => 'sites.manage', 'label' => 'Gerer les sites (creer, editer, supprimer)'],
+    ];
+}
+```
+
+Regles de validation appliquees par `SyncPermissionsCommand` :
+- Chaque entree doit contenir exactement les cles `code` et `label`.
+- Le prefixe du code doit correspondre a `SitesModule::ID . '.'`, soit `sites.`.
+- Ni `code` ni `label` ne peuvent etre une chaine vide.
+
+Comportement a attendre :
+- Apres `php bin/console app:sync-permissions`, les deux lignes `sites.view` et `sites.manage` sont presentes dans la table `permission` avec `module = 'sites'` et `orphan = false`.
+- Si `SitesModule::class` est retire de `config/modules.php` et la commande relancee, les deux lignes sont marquees `orphan = true` (non supprimees, pour preserver les assignations). Reactiver le module les remet a `orphan = false`.
+- La cle `module` n'est **pas** presente dans le payload : elle est auto-injectee par la commande depuis `SitesModule::ID`.
+
+### Granularité des permissions
+
+`sites.manage` est une permission **composite** couvrant creation, edition et suppression. Ce choix reste simple pour un ticket fondateur, mais le ticket 4 (administration CRUD) devra arbitrer si une granularite plus fine (`sites.create`, `sites.edit`, `sites.delete`) est necessaire pour les besoins UX. Si oui, la migration de permissions se fera naturellement via la commande de sync : ajouter les trois codes dans `permissions()`, retirer `sites.manage` → la sync marque l'ancien orphelin sans casser les roles deja existants.
+
+## 8. Méthodes clés détaillées
+
+### `Site::__construct`
+
+Le constructeur prend les cinq champs metier obligatoires et positionne les deux timestamps a la meme valeur :
+
+```php
+public function __construct(
+    string $name,
+    string $city,
+    string $postalCode,
+    string $color,
+    string $fullAddress,
+) {
+    $this->name        = $name;
+    $this->city        = $city;
+    $this->postalCode  = $postalCode;
+    $this->color       = $color;
+    $this->fullAddress = $fullAddress;
+    $now               = new DateTimeImmutable();
+    $this->createdAt   = $now;
+    $this->updatedAt   = $now;
+}
+```
+
+Justification :
+- Tous les champs sont passes au constructeur pour forcer l'invariant "un Site instancie est toujours complet". L'alternative (setters post-new) autoriserait des etats transitoires invalides.
+- `createdAt` et `updatedAt` partagent la meme valeur a l'instanciation, ce qui garantit `updated_at >= created_at` au niveau base. Le premier appel a `onPreUpdate()` fera avancer uniquement `updatedAt`.
+
+### `Site::onPreUpdate`
+
+```php
+#[ORM\PreUpdate]
+public function onPreUpdate(): void
+{
+    $this->updatedAt = new DateTimeImmutable();
+}
+```
+
+Justification :
+- Callback Doctrine declenche **uniquement** quand Doctrine detecte au moins un changement sur l'entite en session de persistance. Pas de risque de tick silencieux sur un find pur.
+- `createdAt` n'est volontairement jamais touche ici : il est immuable apres persistance.
+- Pas de `#[ORM\PrePersist]` : le constructeur gere deja l'initialisation, inutile de dupliquer la logique dans un callback qui pourrait etre appele a vide.
+
+### `SitesFixtures::ensureSite`
+
+```php
+private function ensureSite(
+    ObjectManager $manager,
+    string $name,
+    string $city,
+    string $postalCode,
+    string $color,
+    string $fullAddress,
+): Site {
+    $site = $this->siteRepository->findByName($name);
+
+    if (null === $site) {
+        $site = new Site($name, $city, $postalCode, $color, $fullAddress);
+        $manager->persist($site);
+
+        return $site;
+    }
+
+    $site->setCity($city);
+    $site->setPostalCode($postalCode);
+    $site->setColor($color);
+    $site->setFullAddress($fullAddress);
+
+    return $site;
+}
+```
+
+Contrat honnete sur l'idempotence (cf. docblock en tete de fixture) :
+- **Supporte** : lookup par nom avec purger Doctrine actif (cas nominal de `doctrine:fixtures:load`).
+- **Supporte** : lookup par nom hors purger si la fixture est rejouee telle quelle sur une base deja seedee → les autres champs sont re-alignes sur les valeurs de reference.
+- **Non supporte** : chargement cumulatif apres qu'une autre fixture ait `persist` (sans `flush`) des Site dans la meme session → `findByName` via `findOneBy` n'inspecte pas l'unit-of-work et peut creer un doublon.
+- **Non supporte** : renommage d'un site dans la fixture → le lookup par `name` rate, un nouveau site est cree, l'ancien reste en base si le purger est desactive.
+
+## 9. Fixtures Sites
+
+Trois sites de demonstration, avec des couleurs distinctes suffisamment contrastees pour un futur affichage visuel (ticket 3 — navbar) :
+
+| Nom | Ville | CP | Couleur | Commentaire |
+|-----|-------|-----|---------|-------------|
+| 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). |
+
+Les adresses completes sont des chaines multi-lignes (voie + CP/ville), cas nominal d'exploitation du type `TEXT` sur `full_address`.
+
+### Ordre d'execution global des fixtures
+
+`SitesFixtures` est une `Fixture` sans dependance : elle peut s'executer dans n'importe quel ordre relatif aux autres fixtures Core (`AppFixtures`). Aucune FK inter-modules dans ce ticket.
+
+Le ticket 2 introduira probablement une relation `User ↔ Site` ; `SitesFixtures` devra alors etre declare comme dependance de `AppFixtures` (ou inversement, selon la direction de la FK) via `DependentFixtureInterface::getDependencies()`.
+
+## 10. Plan de tests PHPUnit
+
+Deux suites separees, motivation :
+- `SiteTest` reste en `TestCase` pur (pas de kernel) pour tester le comportement mecanique de l'entite — rapide, zero dependance DB.
+- `SiteValidationTest` utilise `KernelTestCase` pour avoir acces au validator applicatif, **indispensable** pour tester `UniqueEntity` dont le validator est backed par Doctrine et necessite donc un `ManagerRegistry` reel.
+
+### `SiteTest` — tests unitaires purs
+
+1. `testConstructorInitialState` : verifie que le constructeur positionne correctement les 5 champs metier et les deux timestamps (`DateTimeImmutable`).
+2. `testCreatedAtAndUpdatedAtAreInitiallyEqual` : verifie l'invariant "a l'instanciation, `createdAt == updatedAt`".
+3. `testOnPreUpdateAdvancesUpdatedAtOnly` : utilise `Reflection` pour forcer `updatedAt` a une valeur anterieure (`-1 hour`), appelle `onPreUpdate()`, et verifie que `updatedAt` avance strictement mais que `createdAt` reste immuable.
+   - **Justification reflection** : eviter un `sleep/usleep` flaky en CI et lent.
+4. `testSettersMutateFields` : verifie que les setters publics modifient correctement les champs metier.
+
+### `SiteValidationTest` — tests d'integration validator
+
+Bootstrap : `self::bootKernel()` dans `setUp()`, recuperation de `ValidatorInterface` et `EntityManagerInterface` depuis le container.
+
+Tests de validation scalaire (via `DataProvider` PHPUnit 12+, attribut `#[DataProvider]`) :
+1. `testValidSitePassesValidation` : un Site correct passe sans violation.
+2. `testColorMustBeHexRrggbb` / `testValidColorsAreAccepted` : jeu de donnees invalide (`red`, `#FFF`, `FFFFFF`, `rgb(...)`, `#1234567`, `#12345G`, `""`) vs valide (`#ABCDEF`, `#abcdef`, `#0a1B2c`, `#000000`, `#FFFFFF`).
+3. `testPostalCodeMustMatchFrFormat` / `testValidPostalCodesAreAccepted` : jeu de donnees invalide (`1234`, `123456`, `8610A`, `86-100`, `""`, `86 100`) vs valide (`86100`, `75001`, `97100`, `20000`).
+4. `testBlankNameIsRejected`, `testBlankCityIsRejected`, `testBlankFullAddressIsRejected` : `NotBlank` sur chaque champ obligatoire.
+5. `testNameLongerThan100CharsIsRejected`, `testCityLongerThan100CharsIsRejected` : `Length(max: 100)`.
+
+Test d'unicite :
+6. `testDuplicateNameIsRejected` : **auto-suffisant** — persiste lui-meme un site porteur d'un nom unique (`Test-Duplicate-<uniqid>`), flush, tente de valider un second Site avec le meme nom, verifie qu'au moins une violation porte `UniqueEntity::NOT_UNIQUE_ERROR` sur la property `name`, puis supprime le site en `finally`.
+   - **Justification** : pas de dependance aux fixtures (robustesse, pas de couplage sur `Chatellerault`). Assertion precise sur le `code` de violation + `propertyPath`, pas sur le message (resistant aux traductions).
+
+### Pattern `finally` pour cleanup
+
+```php
+try {
+    $duplicate  = new Site($name, ...);
+    $violations = $this->validator->validate($duplicate);
+    // assertions...
+} finally {
+    $this->em->remove($original);
+    $this->em->flush();
+}
+```
+
+Garantit le cleanup meme si une assertion rate, sans dependre d'une transaction globale de test.
+
+## 11. Risques et points d'attention
+
+### Risque 1 — Mapping Doctrine inconditionnel
+
+Le mapping `Sites:` est declare dans `doctrine.yaml` sans dependance a `config/modules.php`. Consequence : retirer `SitesModule::class` de `modules.php` ne desactive **pas** le mapping Doctrine ni la table `site`.
+
+Decision assumee et alignee avec le traitement du module `Core` :
+- La structure DB est "toujours la" (migrations jouees inconditionnellement).
+- L'activation fonctionnelle (exposition des permissions, futurs endpoints) passe exclusivement par `modules.php`.
+
+Cela doit etre **explicite dans `doctrine.yaml`** via un commentaire en tete du bloc `Sites:` pour eviter qu'un futur reviewer n'interprete le mapping comme un oubli.
+
+### Risque 2 — Migration racine vs migration modulaire
+
+La migration est placee dans `migrations/` et non dans `src/Module/Sites/Infrastructure/Doctrine/Migrations/`. C'est une exception documentee dans `CLAUDE.md` et dans le docblock de la migration elle-meme, motivee par un bug de tri alphabetique des `MigrationsComparator` en Doctrine Migrations 3.x lorsque plusieurs `migrations_paths` sont declares.
+
+Consequence pour les tickets futurs :
+- Tant que le bug n'est pas resolu, **toute nouvelle migration d'initialisation** (creation de table sur base vide) continuera d'aller au namespace racine.
+- Les migrations applicatives (ajout de colonne, backfill) qui supposent un schema deja en place peuvent vivre dans le namespace modulaire, comme prevu.
+- Une fois le bug resolu (comparator custom ou upgrade Doctrine), migrer les fichiers vers le namespace modulaire sera un simple `git mv` + ajustement du namespace PHP.
+
+### Risque 3 — Idempotence des fixtures non cumulative
+
+Le docblock de `SitesFixtures` declare explicitement les cas d'idempotence supportes et non supportes (cf. section 8). Ne pas promettre une robustesse que le pattern ne tient pas : si un futur ticket introduit une fixture persistant des Site **avant** `SitesFixtures` sans flush intermediaire, un doublon peut apparaitre. Le contrat ecrit permet au reviewer de ce futur ticket de reagir.
+
+### Risque 4 — Regex couleur non normalisee
+
+La regex `/^#[0-9A-Fa-f]{6}$/` accepte majuscules et minuscules. Les fixtures utilisent des majuscules ; si l'UI du ticket 4 permet de saisir en minuscules, deux couleurs "visuellement identiques" pourront coexister en base avec casse differente, cassant toute comparaison naive (`$a->color === $b->color`). A decider au ticket 4 : normaliser en uppercase a la persistance, ou assumer le stockage tel quel et normaliser uniquement a la comparaison.
+
+### Risque 5 — Precision timestamp PostgreSQL TIMESTAMP(0)
+
+PostgreSQL `TIMESTAMP(0)` ecrete a la seconde pres. Deux updates espaces de moins d'une seconde produisent le meme `updated_at` en base. Pas un probleme pour les cas d'usage metier de ce ticket (edition manuelle), mais a garder en tete si un ticket futur introduit un `updatedAt` comme cle de tri ou de detection de version optimiste.
+
+## 12. Ordre d'exécution recommandé
+
+1. **Exploration** — Lire le module Core (`CoreModule.php`, `User.php`, `Role.php`) pour aligner le style.
+2. **Module declaration** — Creer `SitesModule.php` avec `permissions()`.
+3. **Entite** — Creer `Site.php` avec tous les attributs Doctrine et contraintes de validation.
+4. **Repository** — Creer `SiteRepositoryInterface.php` puis `DoctrineSiteRepository.php`.
+5. **Configuration** — Enregistrer le mapping dans `doctrine.yaml`, l'alias dans `services.yaml`, le module dans `modules.php`.
+6. **Migration** — Generer le fichier de migration (manuellement ou via `doctrine:migrations:diff` puis ajuster), jouer `make migration-migrate`.
+7. **Fixtures** — Creer `SitesFixtures.php`, jouer `make fixtures` puis `make sync-permissions`.
+8. **Tests unitaires** — Ecrire `SiteTest.php` (TestCase pur).
+9. **Tests validation** — Ecrire `SiteValidationTest.php` (KernelTestCase).
+10. **Validation DoD** — `make test-db-setup && make test` (doit passer 148/148), verifier que designer SitesModule ne casse rien.
+11. **CS fixer** — `make php-cs-fixer-allow-risky FILES="src/Module/Sites tests/Module/Sites migrations/Version<timestamp>.php config/..."`.
+
+## 13. Critères d'acceptation (DoD)
+
+- [ ] `SitesModule.php` existe et declare exactement 2 permissions (`sites.view`, `sites.manage`) prefixees `sites.` conformement au format attendu par `SyncPermissionsCommand`.
+- [ ] `SitesModule::class` est enregistre dans `config/modules.php` et active par defaut.
+- [ ] Entite `Site` creee avec tous les champs, contraintes de validation (`NotBlank`, `Length`, `Regex hex`, `Regex CP FR`, `UniqueEntity`) et timestamps auto.
+- [ ] `SiteRepositoryInterface` expose au minimum `findById`, `findByName`, `findAllOrderedByName`, `save`, `remove` ; `DoctrineSiteRepository` l'implemente.
+- [ ] La migration existe dans `migrations/` (namespace `DoctrineMigrations`), cree la table `site` et l'index unique `uniq_site_name`, est jouable via `make migration-migrate`.
+- [ ] `SitesFixtures` cree les 3 sites avec couleurs distinctes et docblock honnete sur son idempotence.
+- [ ] `make fixtures` charge les 3 sites sans erreur et est rejouable apres purge.
+- [ ] Apres `app:sync-permissions`, la table `permission` contient `sites.view` et `sites.manage` avec `module = 'sites'` et `orphan = false`.
+- [ ] Le mapping `Sites:` est declare dans `doctrine.yaml` avec un commentaire explicite sur son caractere inconditionnel.
+- [ ] L'alias `SiteRepositoryInterface → DoctrineSiteRepository` est declare dans `services.yaml`.
+- [ ] `make test` passe 148/148 tests avec `SitesModule::class` active.
+- [ ] `make test` passe 148/148 tests avec `SitesModule::class` commente dans `config/modules.php`.
+- [ ] `make php-cs-fixer-allow-risky` ne signale aucune correction sur les fichiers du ticket.
+- [ ] Aucun import direct depuis `src/Module/Core/...` vers `src/Module/Sites/...` ni l'inverse (independance des bounded contexts).

docs/sites/ticket-02-spec.md

@@ -0,0 +1,701 @@
+# Ticket #02 — 2/4 — Exposition API, rattachement utilisateurs et admin CRUD
+
+## 1. Objectif
+
+Ce ticket transforme la brique de donnees du ticket 1 en module fonctionnel : il expose la ressource `Site` via API Platform (CRUD admin avec RBAC), introduit la notion de **sites autorises** et de **site courant** sur chaque utilisateur, ouvre un endpoint dedie au basculement du site courant, et livre la page d'administration `/admin/sites` ainsi que l'assignation des sites dans le drawer RBAC d'un user.
+
+Le resultat attendu est un module Sites utilisable de bout en bout cote admin (creer, editer, supprimer des sites et en assigner aux users), avec une API `/api/me` enrichie que le ticket 3 consommera pour alimenter le selecteur de site dans la navbar. Le ticket etablit le couplage Core → Sites **au niveau modele** (la table `user` gagne deux relations vers `site`) tout en conservant le contrat "desactiver Sites dans `config/modules.php` ne casse pas l'app" via des decisions DB/mapping assumees.
+
+## 2. Périmètre
+
+### IN
+
+- Exposer `Site` comme ressource API Platform avec les operations `GetCollection`, `Get`, `Post`, `Patch`, `Delete`, securisees par les permissions `sites.view` (lecture) et `sites.manage` (ecriture).
+- Ajouter deux relations sur `User` (module Core) :
+  - `$sites` (M2M, `user_site`) : sites autorises.
+  - `$currentSite` (M2O nullable) : site actuellement selectionne.
+- Ajouter la relation inverse `$users` sur `Site` (non exposee API).
+- Generer la migration Doctrine creant la table `user_site` et la colonne `user.current_site_id` avec les bonnes strategies `ON DELETE` pour garantir les cascades attendues (suppression d'un site → `user_site` purge, `currentSite` mis a `NULL`).
+- Etendre `/api/me` pour exposer `sites: Site[]` et `currentSite: Site | null` en objets serialises (pas en IRI), via les groupes `me:read` sur `User` **et** sur `Site`.
+- Ajouter un endpoint dedie de switch du site courant, implemente comme une ressource API Platform virtuelle `CurrentSite` avec une operation `Patch uriTemplate: '/me/current-site'` et un processor dedie. Le processor garantit que le site cible fait partie des `sites` de l'utilisateur authentifie, sinon il leve une exception traduite en `403`.
+- Etendre `UserRbacProcessor` et l'operation `PATCH /api/users/{id}/rbac` pour accepter un champ `sites: string[]` (IRIs) en plus des roles et permissions directes. Cas limite : si le `currentSite` du user cible n'est plus dans la liste, le processor le bascule a `NULL`.
+- Etendre l'exception metier Core pour couvrir "site non autorise" via une nouvelle exception domaine `SiteNotAuthorizedException` placee dans le module Sites, traduite en `ForbiddenHttpException` au niveau API.
+- Ajouter l'entree sidebar `sidebar.admin.sites` filtree par `module: 'sites'` + `permission: 'sites.view'` dans `config/sidebar.php`, sous la section admin Core existante.
+- Livrer la page d'administration `/admin/sites` cote front (layer Nuxt `frontend/modules/sites/`) : DataTable + drawer creation/edition + modale suppression, alignee visuellement et structurellement sur `/admin/roles` et `/admin/users`.
+- Etendre le drawer `UserRbacDrawer.vue` (module Core) pour afficher et editer la liste des sites autorises d'un user via un multi-select.
+- Ajouter les fixtures : rattacher les 3 users existants (`admin`, `alice`, `bob`) a au moins un site et positionner un `currentSite` coherent.
+- Couverture de tests PHPUnit : CRUD `/api/sites`, endpoint `/me/current-site` (cas OK + 403), extension `/api/me`, cascade DB a la suppression d'un site, extension `UserRbacProcessor` (ajout/retrait sites, auto-reset currentSite).
+
+### OUT
+
+- Ticket `#03` : selecteur de site dans la navbar, persistance du site actif cote front, integration visuelle avec la couleur du site.
+- Ticket `#04` : filtrage metier par site (ex: bloquer l'acces aux ressources Commercial si l'user n'est pas rattache au site de la ressource).
+- Soft-delete des sites : non introduit.
+- Audit trail des modifications : hors scope.
+- Color picker avance : un input hex simple avec preview de la puce suffit.
+- Recherche / tri server-side sur `/api/sites` : non requis, le volume reste <20 sites par instance.
+- Gestion des site "globaux" ou "par defaut" pour les nouveaux users : non introduite, les users crees via `CreateUserCommand` ou `/api/users` POST auront `sites: []` et `currentSite: null` jusqu'a rattachement explicite.
+
+## 3. Fichiers à créer
+
+### Backend — Module Sites
+
+- `/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/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/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/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/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/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/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/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/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/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/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/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',
+      'to'         => '/admin/sites',
+      'icon'       => 'mdi:domain',
+      'module'     => 'sites',
+      'permission' => 'sites.view',
+  ],
+  ```
+- `/home/m-tristan/workspace/Starseed/config/services.yaml` : aucun changement requis. `CurrentSiteProcessor`, `SiteNotAuthorizedExceptionListener` sont autoconfigures.
+
+### Frontend
+
+- `/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/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}`.
+  - `admin.sites.form.{name, city, postalCode, color, fullAddress}`.
+  - `admin.sites.delete.{title, message}`.
+  - `admin.sites.toast.{created, updated, deleted}`.
+  - `admin.users.drawer.sitesSection` = "Sites autorises".
+  - `errors.sites.notAuthorized` = "Vous n'etes pas autorise a selectionner ce site.".
+
+## 5. Schéma cible — ApiResource et Doctrine
+
+### Entite `Site` — attributs ApiResource
+
+```php
+#[ApiResource(
+    operations: [
+        new GetCollection(
+            security: "is_granted('sites.view')",
+            normalizationContext: ['groups' => ['site:read']],
+        ),
+        new Get(
+            security: "is_granted('sites.view')",
+            normalizationContext: ['groups' => ['site:read']],
+        ),
+        new Post(
+            security: "is_granted('sites.manage')",
+            normalizationContext: ['groups' => ['site:read']],
+            denormalizationContext: ['groups' => ['site:write']],
+        ),
+        new Patch(
+            security: "is_granted('sites.manage')",
+            normalizationContext: ['groups' => ['site:read']],
+            denormalizationContext: ['groups' => ['site:write']],
+        ),
+        new Delete(security: "is_granted('sites.manage')"),
+    ],
+)]
+```
+
+Groupes sur les proprietes de `Site` :
+- `id` : `site:read`, `me:read`.
+- `name`, `city`, `postalCode`, `color`, `fullAddress` : `site:read`, `site:write`, `me:read`.
+- `createdAt`, `updatedAt` : `site:read` uniquement (pas exposes en embed `me:read` pour garder le payload /me leger).
+
+### Evolution de `User` — nouvelles relations
+
+```php
+/** @var Collection<int, Site> */
+#[ORM\ManyToMany(targetEntity: Site::class, fetch: 'EAGER')]
+#[ORM\JoinTable(name: 'user_site')]
+#[Groups(['me:read', 'user:list', 'user:rbac:read', 'user:rbac:write'])]
+private Collection $sites;
+
+#[ORM\ManyToOne(targetEntity: Site::class, fetch: 'EAGER')]
+#[ORM\JoinColumn(name: 'current_site_id', referencedColumnName: 'id', nullable: true, onDelete: 'SET NULL')]
+#[Groups(['me:read'])]
+private ?Site $currentSite = null;
+```
+
+Justification fetch=EAGER :
+- Aligne sur les collections `$rbacRoles` et `$directPermissions` (cf. `User.php:87`).
+- Critique pour eviter un lazy-load silencieux pendant un refresh JWT (cf. ticket 343 section 11 risque 1).
+- Surcout SQL accepte a l'echelle d'un CRM PME (≤20 sites par instance).
+
+### Relation inverse sur `Site`
+
+```php
+/** @var Collection<int, User> */
+#[ORM\ManyToMany(targetEntity: User::class, mappedBy: 'sites')]
+private Collection $users;
+```
+
+Pas de `#[Groups]` : la collection inverse n'est pas exposee dans la reponse API. Sa seule utilite est metier (compter les users d'un site, iterer pour un cascade applicatif si la cascade DB ne suffisait pas).
+
+### Ressource virtuelle `CurrentSite`
+
+```php
+#[ApiResource(
+    shortName: 'CurrentSite',
+    operations: [
+        new Patch(
+            uriTemplate: '/me/current-site',
+            security: "is_granted('ROLE_USER')",
+            normalizationContext: ['groups' => ['me:read']],
+            denormalizationContext: ['groups' => ['current-site:write']],
+            processor: CurrentSiteProcessor::class,
+            read: false,
+        ),
+    ],
+)]
+final class CurrentSiteResource
+{
+    #[Groups(['current-site:write'])]
+    public ?Site $site = null;
+}
+```
+
+- `read: false` : API Platform ne tente pas de charger une entite existante via un Provider — il se contente de denormaliser le body et de passer la ressource au processor.
+- `shortName: 'CurrentSite'` : evite la collision de nommage avec l'entite `Site`.
+- `security: "is_granted('ROLE_USER')"` : tout user authentifie peut tenter un switch ; l'autorisation fine (appartenance du site aux `sites` du user) est verifiee par le processor, pas par la voter RBAC.
+
+## 6. Plan de migration Doctrine
+
+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
+
+1. `ALTER TABLE "user" ADD current_site_id INT DEFAULT NULL` — colonne nullable, pas besoin de backfill.
+2. `CREATE TABLE user_site (user_id INT NOT NULL, site_id INT NOT NULL, PRIMARY KEY (user_id, site_id))`.
+3. `CREATE INDEX IDX_user_site_user ON user_site (user_id)`.
+4. `CREATE INDEX IDX_user_site_site ON user_site (site_id)`.
+5. `ALTER TABLE user_site ADD CONSTRAINT FK_user_site_user FOREIGN KEY (user_id) REFERENCES "user" (id) ON DELETE CASCADE`.
+6. `ALTER TABLE user_site ADD CONSTRAINT FK_user_site_site FOREIGN KEY (site_id) REFERENCES site (id) ON DELETE CASCADE`.
+7. `CREATE INDEX IDX_user_current_site ON "user" (current_site_id)`.
+8. `ALTER TABLE "user" ADD CONSTRAINT FK_user_current_site FOREIGN KEY (current_site_id) REFERENCES site (id) ON DELETE SET NULL`.
+
+### `down()` — rollback
+
+1. `ALTER TABLE "user" DROP CONSTRAINT FK_user_current_site`.
+2. `DROP INDEX IDX_user_current_site`.
+3. `ALTER TABLE "user" DROP current_site_id`.
+4. `ALTER TABLE user_site DROP CONSTRAINT FK_user_site_site`.
+5. `ALTER TABLE user_site DROP CONSTRAINT FK_user_site_user`.
+6. `DROP TABLE user_site`.
+
+### Comportement des cascades
+
+| Action | Effet |
+|--------|-------|
+| `DELETE FROM site WHERE id = X` | Toutes les lignes `user_site` avec `site_id = X` sont supprimees (FK `ON DELETE CASCADE`). Tous les users avec `current_site_id = X` voient leur `current_site_id` passer a `NULL` (FK `ON DELETE SET NULL`). |
+| `DELETE FROM "user" WHERE id = Y` | Toutes les lignes `user_site` avec `user_id = Y` sont supprimees. Pas d'effet sur `site`. |
+| `DELETE FROM user_site WHERE user_id = Y AND site_id = X` | Aucun effet auto sur `user.current_site_id` — si `X` etait le courant de `Y`, c'est le **UserRbacProcessor** qui doit le basculer a `NULL` en Php (cf. section 8). |
+
+**Important** : la derniere ligne du tableau est la raison pour laquelle la logique de "retirer un site qui etait le courant remet currentSite a null" vit dans `UserRbacProcessor` cote applicatif et non dans la DB via un trigger. C'est un compromis assume : la regle est metier ("retirer un droit ne doit pas laisser l'user pointer sur un site interdit"), pas purement DB.
+
+## 7. Algorithme du switch de site courant — `CurrentSiteProcessor`
+
+### Entree
+
+Body JSON envoye par le client :
+```json
+{ "site": "/api/sites/3" }
+```
+
+API Platform denormalise vers `CurrentSiteResource { site: Site }` en resolvant l'IRI via son `IriConverter`.
+
+### Algorithme
+
+1. Recuperer l'user authentifie via `Security::getUser()`. Si absent → `LogicException` (l'operation exige `ROLE_USER`, ne doit pas arriver).
+2. Extraire `$targetSite = $resource->site`. Si `null` → `BadRequestHttpException('Le champ "site" est requis.')`.
+3. Verifier `$user->hasSite($targetSite)` :
+   - Implementation : `$this->sites->contains($targetSite)` (comparaison par reference ; Doctrine garantit l'identite d'objet dans la meme session).
+   - Si `false` → throw `SiteNotAuthorizedException($targetSite->getId())`.
+4. `$user->setCurrentSite($targetSite)`.
+5. `$this->entityManager->flush()`.
+6. Retourner `$user` — API Platform le normalise via les groupes `me:read` definis sur l'operation.
+
+### Mapping d'exception
+
+`SiteNotAuthorizedException` est convertie en `Symfony\Component\HttpKernel\Exception\HttpException` avec statut `403` par `SiteNotAuthorizedExceptionListener` (event `kernel.exception`, priority standard). Le corps de la reponse porte un code i18n-able `errors.sites.notAuthorized` pour le front.
+
+## 8. Évolution du `UserRbacProcessor`
+
+### Nouveau champ en entree
+
+Le payload accepte desormais :
+```json
+{
+  "isAdmin": false,
+  "roles": ["/api/roles/2"],
+  "directPermissions": [],
+  "sites": ["/api/sites/1", "/api/sites/3"]
+}
+```
+
+Le champ `sites` est optionnel : si absent, la collection n'est pas touchee (comportement PATCH standard). Si present, il remplace integralement la collection `$user->sites`.
+
+### Garde "currentSite coherent"
+
+Apres application des champs par le persist processor decore, `UserRbacProcessor` execute un controle final :
+
+```php
+$currentSite = $data->getCurrentSite();
+if ($currentSite !== null && !$data->hasSite($currentSite)) {
+    $data->setCurrentSite(null);
+}
+```
+
+Justification : si un admin retire un site qui etait le `currentSite` de la cible, le modele serait incoherent (currentSite pointant vers un site non autorise). Le processor corrige automatiquement.
+
+**Variante rejetee** : basculer vers "le premier site restant" plutot que `null`. Rejetee car :
+- "Premier restant" n'a pas de semantique metier claire (ordre de la collection non garanti strict).
+- `null` est une valeur deja supportee (user sans site courant) et explicite : le front du ticket 3 devra gerer ce cas de toute facon.
+
+### Ordre d'execution dans le processor
+
+1. Gardes auto-suicide admin + dernier admin global (code existant, inchange).
+2. `$this->persistProcessor->process($data, ...)` — applique tous les champs (roles, permissions directes, **sites**).
+3. Post-persist : controle coherence currentSite (code ajoute par ce ticket), flush si changement.
+4. Retour du user.
+
+## 9. Fixtures — évolution de `AppFixtures`
+
+`AppFixtures` devient dependant de `SitesFixtures` (inversion du "pas de dependance dure" declare au ticket 1 — justifie par le passage fonctionnel a la relation User ↔ Site). 
+
+```php
+class AppFixtures extends Fixture implements DependentFixtureInterface
+{
+    public function getDependencies(): array
+    {
+        return [SitesFixtures::class];
+    }
+    // ...
+}
+```
+
+Dans `load()`, apres la creation des users et avant le `flush` final :
+
+```php
+$chatellerault = $this->siteRepository->findByName('Chatellerault');
+$saintJean = $this->siteRepository->findByName('Saint-Jean');
+$pommevic = $this->siteRepository->findByName('Pommevic');
+
+$admin->addSite($chatellerault);
+$admin->addSite($saintJean);
+$admin->addSite($pommevic);
+$admin->setCurrentSite($chatellerault);
+
+$alice->addSite($chatellerault);
+$alice->setCurrentSite($chatellerault);
+
+$bob->addSite($saintJean);
+$bob->setCurrentSite($saintJean);
+```
+
+Le repository `SiteRepositoryInterface` est injecte dans le constructeur.
+
+**Regle** : les 3 sites sont deja en base au moment ou `AppFixtures::load()` s'execute grace a `getDependencies()`. Si `findByName` retourne `null`, c'est une misconfiguration qui doit faire echouer fort (assertion via `\assert`).
+
+## 10. Frontend — Page `/admin/sites`
+
+### Structure
+
+```
+frontend/modules/sites/
+├── nuxt.config.ts                 # marker layer Nuxt (vide)
+├── pages/
+│   └── admin/
+│       └── sites.vue              # page listing
+└── components/
+    ├── SiteDrawer.vue             # creation/edition
+    └── SiteDeleteModal.vue        # confirmation suppression
+```
+
+### `pages/admin/sites.vue` — pattern
+
+Aligne sur `frontend/modules/core/pages/admin/roles.vue` :
+- En-tete : titre + bouton `Nouveau site` (visible si `can('sites.manage')`).
+- `MalioDataTable` : colonnes `name`, `city`, `postalCode`, `color` (slot custom pour la puce), `fullAddress` (tronque).
+- Row click → ouvre `SiteDrawer` en mode edition si `can('sites.manage')`, sinon pas de clic (row-clickable guard).
+- `SiteDrawer` emet `saved` → reload de la liste, et `delete` → ouvre `SiteDeleteModal`.
+- `SiteDeleteModal` → DELETE `/api/sites/{id}` + reload.
+
+### `components/SiteDrawer.vue`
+
+Formulaire a 5 champs + preview de la couleur. Pattern `RoleDrawer.vue` :
+- `MalioInputText` pour `name`, `city`, `postalCode`.
+- `MalioInputText` pour `color` avec preview : une puce `<span>` 24×24 arrondie affichant la couleur en temps reel a cote du champ. Valider localement via regex avant submit (ne pas envoyer un hex invalide au backend).
+- `MalioInputTextArea` pour `fullAddress`.
+- Bouton save (variant primary), bouton delete (variant danger, visible uniquement en mode edition, **aucune garde system comme pour les roles** — tous les sites sont supprimables), bouton cancel (variant tertiary).
+
+### `components/SiteDeleteModal.vue`
+
+Pattern `RoleDeleteModal.vue` :
+- Modal avec message "Supprimer le site {name} ? Cette action est irreversible et retirera ce site a tous les utilisateurs rattaches."
+- Bouton cancel (secondary) + bouton delete (danger avec icone poubelle).
+- Emet `confirm` au clic delete.
+
+### Extension de `UserRbacDrawer.vue`
+
+Ajout d'une nouvelle section entre "Permissions directes" et "Resume des permissions effectives" :
+
+```vue
+<!-- Section Sites autorises -->
+<div>
+    <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+        {{ t('admin.users.drawer.sitesSection') }}
+    </h4>
+    <div class="flex flex-col gap-2">
+        <MalioCheckbox
+            v-for="site in allSites"
+            :key="site.id"
+            :id="`site-${site.id}`"
+            :label="site.name"
+            :model-value="selectedSiteIds.has(site.id)"
+            label-class="text-sm text-neutral-600"
+            @update:model-value="(val: boolean) => toggleSite(site.id, val)"
+        />
+    </div>
+</div>
+```
+
+Chargement : ajout a `loadData()` d'un `api.get<{ member: Site[] }>('/sites', { itemsPerPage: 999 }, { toast: false })`.
+
+Le `PATCH /api/users/{id}/rbac` envoie desormais `sites: Array.from(selectedSiteIds).map(id => `/api/sites/${id}`)`.
+
+### Types TypeScript
+
+`frontend/shared/types/sites.ts` :
+
+```ts
+export interface Site {
+    id: number
+    name: string
+    city: string
+    postalCode: string
+    color: string
+    fullAddress: string
+}
+
+export interface SiteInput {
+    name: string
+    city: string
+    postalCode: string
+    color: string
+    fullAddress: string
+}
+```
+
+`frontend/shared/types/rbac.ts` : ajouter `sites: string[]` (IRIs) dans `UserListItem`.
+
+`frontend/shared/types/` (fichier utilisateur courant, probablement `user.ts` ou expose dans l'auth store) : ajouter `sites: Site[]` et `currentSite: Site | null` sur le type expose via `/api/me`.
+
+### Sidebar
+
+Entree ajoutee dans `config/sidebar.php` (cf. section 4). Le `SidebarProvider` filtre deja par `module` actif et par `permission`, aucune modification backend nouvelle.
+
+i18n :
+```json
+"sidebar": {
+    "core": {
+        "sites": "Sites"
+    }
+}
+```
+
+## 11. Plan de tests PHPUnit
+
+### `SiteApiTest` — CRUD `/api/sites`
+
+1. `testAdminCanListSites` : admin → 200, 3 sites.
+2. `testUserWithSitesViewCanListSites` : user avec `sites.view` → 200.
+3. `testUserWithoutPermissionGetsForbidden` : user sans `sites.view` → 403.
+4. `testAdminCanCreateSite` : POST → 201, site present en base.
+5. `testAdminCanPatchSite` : PATCH `color` → 200.
+6. `testAdminCanDeleteSite` : DELETE → 204, site absent en base.
+7. `testUserWithViewButNotManageCannotDelete` : user avec `sites.view` mais pas `sites.manage` → 403 sur DELETE.
+8. `testCreateSiteWithDuplicateNameReturns422` : collision `uniq_site_name` → 422 avec message UniqueEntity.
+9. `testCreateSiteWithInvalidColorReturns422` : validation regex → 422.
+
+### `CurrentSiteSwitchApiTest` — PATCH `/me/current-site`
+
+1. `testUserCanSwitchToAuthorizedSite` : alice a `Chatellerault` dans ses sites → PATCH OK, 200, `currentSite.name == 'Chatellerault'`.
+2. `testUserCannotSwitchToUnauthorizedSite` : alice n'a pas `Pommevic` dans ses sites → PATCH → 403, pas de modification en base.
+3. `testSwitchWithMissingSiteFieldReturns400` : body `{}` → 400.
+4. `testSwitchWithInvalidIriReturns400` : body `{"site": "/api/sites/99999"}` (site inexistant) → 400 ou 404 (selon API Platform).
+5. `testAnonymousUserCannotSwitch` : client non authentifie → 401.
+
+### `MeEndpointSitesTest` — extension `/api/me`
+
+1. `testMeExposesSitesAsObjects` : alice → `sites[0]` est un objet avec `id`, `name`, `city`, ... (pas une string IRI).
+2. `testMeExposesCurrentSiteAsObject` : alice → `currentSite` est un objet, pas `null`.
+3. `testUserWithoutSitesHasEmptyArrayAndNullCurrent` : creer un user jetable sans sites → `sites: []`, `currentSite: null`.
+
+### `SiteCascadeTest` — cascade DB a la suppression
+
+1. `testDeletingSitePurgesUserSiteRows` : supprimer `Chatellerault` → les users qui l'avaient dans `sites` ne l'ont plus.
+2. `testDeletingSiteSetsCurrentSiteToNullOnReferencingUsers` : alice.currentSite = `Chatellerault`, supprimer `Chatellerault` → alice.currentSite = `null`.
+
+### `UserRbacSitesApiTest` — extension `/rbac`
+
+1. `testAdminCanAssignSitesToUser` : PATCH `/users/{alice}/rbac` avec `sites: ["/api/sites/2"]` → alice a desormais 1 site (`Saint-Jean`), plus `Chatellerault`.
+2. `testRemovingCurrentSiteResetsCurrentSiteToNull` : alice.currentSite = `Chatellerault`, PATCH avec `sites: []` → alice.currentSite = `null`.
+3. `testEmptySitesPayloadReplacesCollection` : alice avait 1 site, PATCH avec `sites: []` → 0 site.
+4. `testSitesPayloadWithDuplicateIrisIsAccepted` : PATCH avec `sites: ["/api/sites/1", "/api/sites/1"]` → 1 seul site (dedoublonnage via `ArrayCollection::contains`).
+
+### Tests fixtures (sanity check)
+
+Dans `AbstractApiTestCase` ou dans un test dedie `FixturesIntegrityTest` : verifier apres `make test-db-setup` que les 3 users fixtures ont bien leurs sites attendus. Evite qu'un renommage dans la fixture passe inapercu.
+
+## 12. Risques et points d'attention
+
+### Risque 1 — Couplage Core → Sites au niveau code PHP
+
+L'ajout de `use App\Module\Sites\Domain\Entity\Site;` dans `User.php` introduit une dependance directe du module Core vers le module Sites. Consequence :
+
+- **Desactiver `SitesModule::class` dans `config/modules.php` n'empeche pas Doctrine de charger le mapping `Site` ni `User`**, grace au caractere inconditionnel des mappings declares dans `doctrine.yaml` (choix assume ticket 1).
+- En revanche, la contrainte forte introduite ici est que **la table `site` doit exister** pour que la table `user` puisse etre creee (FK `user.current_site_id → site.id`). Si la migration Sites (ticket 1) n'a pas ete jouee, la migration de ce ticket echouera.
+- Conclusion : Sites n'est plus "optionnel au sens strict" apres ce ticket. Le declarer `REQUIRED = false` dans `SitesModule` reste vrai du point de vue de l'activation fonctionnelle (exposer les permissions et la sidebar), mais faux du point de vue DB. **A documenter explicitement dans le docblock de `SitesModule::REQUIRED`** au moment de ce ticket.
+
+### Risque 2 — Cascade DB vs regle applicative
+
+La cascade `user_site` → `ON DELETE CASCADE` gere la suppression d'un site, mais **n'est pas triggered** quand on retire un site d'un user (DELETE d'une ligne `user_site` uniquement). Dans ce cas, `user.current_site_id` peut rester pointe vers un site que l'user n'a plus — etat incoherent qui serait masque au niveau DB mais visible a l'usage.
+
+La correction vit dans `UserRbacProcessor` (cf. section 8). Si un autre chemin applicatif modifie `user.sites` sans passer par ce processor (ex: une commande console custom), il devra dupliquer cette garde. **Point d'attention a consigner dans le docblock de `User::addSite()` / `User::removeSite()`** : "apres modification, verifier la coherence de `currentSite`".
+
+### Risque 3 — Ressource virtuelle et routing API Platform
+
+Le choix d'une ressource virtuelle `CurrentSite` avec `uriTemplate: '/me/current-site'` est fragile : si un futur ticket introduit une autre operation sur une URI qui commence par `/me/`, il faut verifier que le routing API Platform n'entre pas en conflit. Le pattern `priority: 1` (cf. `CLAUDE.md` section Backend) est recommande par prevention sur l'operation Patch. A valider par un test fonctionnel qui appelle explicitement `/api/me` (GET) et `/api/me/current-site` (PATCH) dans le meme scenario.
+
+### Risque 4 — EAGER loading et payload `/api/me`
+
+`User` a deja 3 collections EAGER (`$rbacRoles`, `$directPermissions`, plus les `permissions` de chaque role). Ajouter `$sites` (EAGER M2M) et `$currentSite` (EAGER M2O) augmente la taille du payload `/api/me` et le nombre de requetes SQL a chaque auth.
+
+Mesure : apres implementation, verifier via le profiler Symfony que le nombre de requetes SQL sur `/api/me` reste raisonnable (≤ 6-8). Si >10, envisager une projection custom (cf. ticket 343 discussion `findForSecurity`). Pas bloquant dans ce ticket, mais a reverifier.
+
+### Risque 5 — Tests fixtures-dependents
+
+Les tests API existants (`UserApiTest`, `RoleApiTest`) s'appuient sur les users fixtures. L'evolution de `AppFixtures` (ajout de sites aux 3 users) modifie l'etat initial de la DB de test. Verifier que les tests existants continuent de passer (chaines d'assertions du type "user a 1 role" ne doivent pas casser). En particulier :
+- Les tests qui comptent les lignes d'une collection `member[]` sur `/api/users` peuvent voir le payload grossir (sites et currentSite ajoutes).
+- Les tests qui assertent sur la forme stricte d'un user (snapshot-like) devront etre adapter.
+
+### Risque 6 — Serialisation infinie User ↔ Site
+
+`User::$sites` expose `Site` en `me:read`. `Site::$users` est la collection inverse. Si un jour `Site::$users` recevait le groupe `me:read`, la serialisation entrerait dans une boucle infinie (User → sites → users → sites → ...). **Garde** : `Site::$users` ne doit **jamais** porter de `#[Groups]`. A verifier par un test qui serialise `/api/me` et asserte qu'aucun `Site` renvoye ne contient de cle `users`.
+
+### Risque 7 — Pas de recours si l'utilisateur se retire tous ses sites
+
+Le ticket autorise un user sans sites (`sites: []`, `currentSite: null`). Mais aucune garde ne l'empeche de se retirer tous ses sites via `/api/users/{mon_id}/rbac` si il porte `sites.manage`. Consequence : l'user se retrouve bloque sur l'app si le ticket 3 rend un site actif obligatoire pour naviguer. Compromis assume pour ce ticket : on ne bloque pas l'auto-retrait (coherence avec le pattern du ticket RBAC — l'auto-retrait admin est bloque, mais pas le reste). **A reevaluer au ticket 3** si le selecteur de navbar devient bloquant.
+
+## 13. Ordre d'exécution recommandé
+
+1. **Schema backend** — modifier `User.php` (ajout `$sites`, `$currentSite`, `$users` inverse sur `Site`). Ajouter attributs `ApiResource` sur `Site`.
+2. **Configuration** — aucun changement requis a `doctrine.yaml` ni `services.yaml` ni `modules.php`.
+3. **Migration** — ecrire `Version<timestamp2>.php` racine. Jouer `make migration-migrate`.
+4. **Fixtures** — modifier `AppFixtures` pour dependre de `SitesFixtures` et rattacher les users. Jouer `make fixtures && make sync-permissions`.
+5. **Endpoint CRUD sites** — verifier via `curl`/Postman que `GET /api/sites`, `POST /api/sites` etc. repondent avec les bonnes protections RBAC.
+6. **Endpoint switch** — creer `CurrentSiteResource`, `CurrentSiteProcessor`, `SiteNotAuthorizedException`, `SiteNotAuthorizedExceptionListener`. Tester via `curl`.
+7. **Extension MeProvider** — tester via `curl /api/me` que `sites` et `currentSite` apparaissent comme objets. Aucun code a changer dans `MeProvider` lui-meme, le travail est 100% fait via les groupes.
+8. **Extension UserRbacProcessor** — ajouter le champ `sites` et la garde `currentSite`. Tests d'integration.
+9. **Tests API** — ecrire et faire passer les 5 suites de tests decrites section 11.
+10. **Sidebar** — ajouter l'entree dans `config/sidebar.php` + cle i18n.
+11. **Frontend — types** — creer `shared/types/sites.ts`, etendre `shared/types/rbac.ts` et les types user.
+12. **Frontend — page admin** — creer `modules/sites/nuxt.config.ts`, `pages/admin/sites.vue`, `SiteDrawer.vue`, `SiteDeleteModal.vue`.
+13. **Frontend — extension UserRbacDrawer** — ajouter la section sites.
+14. **Frontend — i18n** — completer `fr.json`.
+15. **Validation end-to-end** — clique-droit sur chaque scenario UX : creer un site, l'editer, le supprimer, assigner sites a un user, switcher le site courant de l'user authentifie.
+16. **Tests front (si Vitest du ticket)** — smoke test du rendu de `/admin/sites`.
+17. **CS fixer** — `make php-cs-fixer-allow-risky` sur tous les fichiers touches.
+18. **DoD** — valider les 10 criteres section 14.
+
+## 14. Critères d'acceptation (DoD)
+
+- [ ] `GET /api/sites`, `GET /api/sites/{id}` retournent 200 pour un user avec `sites.view`, 403 sinon.
+- [ ] `POST /api/sites`, `PATCH /api/sites/{id}`, `DELETE /api/sites/{id}` retournent le code attendu pour un user avec `sites.manage`, 403 sinon.
+- [ ] `GET /api/me` retourne `sites: Site[]` (objets complets) et `currentSite: Site | null`, avec les 3 sites pour `admin`, 1 pour `alice`, 1 pour `bob`.
+- [ ] `PATCH /api/me/current-site` avec un site autorise → 200, `currentSite` mis a jour. Avec un site non autorise → 403.
+- [ ] `DELETE /api/sites/{id}` cascade correctement : les lignes `user_site` sont purgees, les `current_site_id` pointant dessus repassent a `NULL`.
+- [ ] `PATCH /api/users/{id}/rbac` accepte le champ `sites` ; retirer le `currentSite` de la liste le bascule a `null`.
+- [ ] Page `/admin/sites` : liste, creation, edition, suppression fonctionnelles.
+- [ ] `UserRbacDrawer.vue` : section "Sites autorises" visible et fonctionnelle.
+- [ ] Sidebar : entree "Sites" visible pour un user avec `sites.view`, masquee sinon. Disparait si `SitesModule::class` est retire de `config/modules.php`.
+- [ ] `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

@@ -0,0 +1,542 @@
+# Ticket #03 — 3/4 — Barre de sélection de site (navbar horizontale)
+
+## 0. Pivots post-implémentation (2026-04-20)
+
+Écarts assumés entre la spec initiale (écrite avant exploration de la lib) et
+le code livré après implémentation et test visuel. À lire en premier pour
+comprendre les divergences lors de la relecture.
+
+1. **Contraste texte auto supprimé, texte blanc forcé conforme Figma.**
+   La spec (sections 5, 6, 10) prévoyait un calcul de luminance WCAG pour
+   décider entre texte noir et blanc sur chaque tile. Après test visuel, le
+   choix design retenu est d'imposer **texte blanc partout** (default Malio
+   `text-white font-bold uppercase tracking-wide`). Conséquence : charge à
+   l'admin de choisir des couleurs de site suffisamment foncées pour que le
+   blanc reste lisible. Les utilitaires `parseHex`, `getRelativeLuminance`,
+   `getReadableTextColor` ont été supprimés comme code mort. Seul
+   `isValidSiteColor(hex)` reste dans `shared/utils/color.ts` (consommé par
+   `SiteDrawer`).
+
+2. **Taille texte explicite `text-2xl` (24 px) appliquée via `labelClass`.**
+   Malio applique `font-bold uppercase tracking-wide` sans taille explicite.
+   Le wrapper `SiteSelector.vue` passe `labelClass="text-2xl"` pour garantir
+   les 24 px de la maquette Figma.
+
+3. **A11y : `ariaGroupLabel` au niveau radiogroup** au lieu de
+   `ariaLabelActive` / `ariaLabelInactive` par tile. La raison : Malio rend
+   déjà un `role="radio"` avec `aria-checked` par tile — le lecteur d'écran
+   annonce "bouton radio coché/non coché" + le nom visible. Ajouter un
+   `aria-label` par tile aurait dupliqué l'info et alourdi sans bénéfice.
+   Le seul ajout nécessaire était un label au groupe, fait via
+   `:aria-label="t('sites.selector.ariaGroupLabel')"` sur `MalioSiteSelector`.
+
+4. **Auto-détection composables des layers dans `nuxt.config.ts`.**
+   Pas prévu dans la spec. Ajouté car `imports.dirs` explicite override les
+   auto-imports par défaut de Nuxt pour les composables de layer. Sans ça,
+   `useCurrentSite` n'est pas résolu par Nuxt. Scan dynamique aligné sur le
+   pattern `moduleLayers` existant.
+
+5. **Couleurs fixtures finales :** `#056CF2` (Châtellerault), `#F3CB00`
+   (Saint-Jean), `#74BF04` (Pommevic). Choix client post-maquette.
+
+## 1. Objectif
+
+Ce ticket livre l'UI de consommation du module Sites pour l'utilisateur final : une barre horizontale en haut de l'application qui liste les sites autorises de l'utilisateur connecte, met en avant le site courant et permet de basculer d'un site a l'autre en un clic.
+
+Le ticket consomme la donnee posee par le ticket 2 (`/api/me` expose `sites` et `currentSite`, `PATCH /api/me/current-site` permet le switch) et s'appuie sur un nouveau composant `MalioSiteSelector` fourni par la version a jour de `@malio/layer-ui`.
+
+Resultat attendu : apres merge, un user avec ≥ 1 site voit une barre sous la navbar horizontale ; un clic sur un site non actif le rend actif, change l'etat global, et est persiste cote serveur.
+
+## 2. Périmètre
+
+### IN
+
+- **Upgrade** de `@malio/layer-ui` (actuellement `^1.3.0`) vers la version contenant `MalioSiteSelector`. La signature exacte du composant (props, slots, events) doit etre lue dans `node_modules/@malio/layer-ui/COMPONENTS.md` apres installation — la spec decrit le contrat attendu, le developpeur adapte selon l'API reelle (cf. Risque 1).
+- Ajouter les champs `sites: Site[]` et `currentSite: Site | null` dans le type `UserData` (`frontend/shared/types/user-data.ts`) pour refleter le payload `/api/me` enrichi au ticket 2.
+- Ajouter le type partage `Site` dans `frontend/shared/types/sites.ts` (deja cree au ticket 2, sinon a creer).
+- Creer le composable `useCurrentSite()` dans `frontend/modules/sites/composables/` qui expose `currentSite`, `availableSites`, `switchSite(site)`, `resetCurrentSite()`. Pattern aligne sur `useSidebar()`.
+- Creer le composable `useModules()` dans `frontend/shared/composables/` qui consomme `/api/modules` et expose `isModuleActive(id: string)`. Necessaire car `isModuleActive` est requis par le ticket mais n'existe pas encore cote front.
+- Creer `SiteSelector.vue` dans `frontend/modules/sites/components/` : wrapper fin autour de `MalioSiteSelector` qui branche le composable `useCurrentSite()`, gere l'optimistic update avec rollback, emet un toast de succes/erreur.
+- Integrer le selecteur dans `frontend/app/layouts/default.vue` — render conditionnel sur `isModuleActive('sites') && user.sites.length > 0`.
+- Appeler `resetCurrentSite()` au logout (`frontend/modules/core/pages/logout.vue`), aligne sur `resetSidebar()` deja present.
+- Gestion du **contraste automatique** : le texte du bloc passe en noir ou en blanc selon la luminance de `site.color`. Fonction utilitaire `getReadableTextColor(hex: string): 'black' | 'white'` dans `frontend/shared/utils/color.ts` (nouveau fichier utilitaire partage).
+- Accessibilite : chaque bloc est un `<button>` natif avec `aria-pressed` sur le site courant, focus visible (ring Tailwind), navigation clavier Tab + Enter fonctionnelle.
+- Responsive minimal : `flex-1` sur chaque bloc avec `min-w-[200px]` et `overflow-x-auto` sur le conteneur pour les cas 4+ sites sur petits ecrans.
+- Tests Vitest : unite sur `useCurrentSite` (switch, rollback, reset), unite sur `getReadableTextColor`, smoke test sur `SiteSelector.vue` (rendu, emission du PATCH, rollback en cas d'echec).
+
+### OUT
+
+- Ticket `#04` : filtrage metier par site (ex: bloquer l'acces aux ressources Commercial si l'user n'est pas rattache au site cible). Le site courant est simplement un **contexte UX** dans ce ticket, aucune regle d'autorisation ne s'appuie encore dessus.
+- Modification du layout `auth.vue` (login) : le selecteur n'est **jamais** rendu hors session authentifiee. Le layout login reste inchange.
+- Persistance du site actif cote front (localStorage, cookies) : le backend est source de verite, le front ne cache pas independamment.
+- Gestion d'une image / d'un logo par site : les sites sont identifies par nom + couleur uniquement dans ce ticket.
+- Pre-mount du selecteur sans `/api/me` complet : le middleware `auth.global.ts` garantit deja que `auth.user` est resolu avant le rendu — pas besoin de gerer un etat "chargement" specifique dans le selecteur.
+- Validation cote back d'une couleur "trop claire" : non introduite. Le ticket 2 accepte `#FFFFFF`. La compensation est faite cote front via le calcul de contraste ; une contrainte back arrivera si un abus se materialise.
+
+## 3. Fichiers à créer
+
+### Frontend — Module Sites (layer deja cree au ticket 2)
+
+- `/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/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/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/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/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/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": {
+          "switchSuccess": "Site courant change",
+          "switchError": "Impossible de changer de site",
+          "ariaLabelActive": "Site actif : {name}",
+          "ariaLabelInactive": "Basculer sur le site {name}"
+      }
+  }
+  ```
+  Ne **pas** mettre le nom du site en cle i18n : le nom est une donnee metier, pas un label.
+
+## 5. Schéma cible — Composant `SiteSelector.vue`
+
+### Render attendu (conforme Figma)
+
+- Hauteur fixe : `h-[72px]`.
+- `width: 100%` (parent du `<main>` dans `layouts/default.vue`, donc occupe toute la zone a droite de la sidebar).
+- Flex horizontal, chaque bloc = `flex-1` avec `min-w-[200px]`.
+- Conteneur parent : `overflow-x-auto` pour scroll horizontal si 4+ sites sur ecran etroit.
+- Fond de chaque bloc : `site.color` (inline style car dynamique).
+- Texte : centre horizontalement et verticalement, `font-inter font-bold text-[24px] uppercase tracking-wide`, couleur calculee par `getReadableTextColor(site.color)`.
+- Opacite : `opacity-100` pour le site courant, `opacity-40` pour les autres.
+- Hover sur les inactifs : `hover:opacity-70 cursor-pointer transition-opacity`.
+- Focus clavier : `focus:ring-2 focus:ring-offset-2 focus:ring-primary-500 focus:outline-none`.
+- Semantique : chaque bloc est un `<button type="button">` (pas `<div>`), avec :
+  - `aria-pressed="true"` sur le site courant.
+  - `aria-label` dynamique via i18n (`sites.selector.ariaLabelActive` ou `ariaLabelInactive`).
+
+### Contrat du wrapper `SiteSelector.vue`
+
+```vue
+<template>
+    <MalioSiteSelector
+        :sites="availableSites"
+        :current-site-id="currentSite?.id"
+        :disabled="switching"
+        @switch="handleSwitch"
+    />
+</template>
+
+<script setup lang="ts">
+const { availableSites, currentSite, switching, switchSite } = useCurrentSite()
+
+async function handleSwitch(siteId: number) {
+    const target = availableSites.value.find(s => s.id === siteId)
+    if (!target) return
+    await switchSite(target)
+}
+</script>
+```
+
+**Hypothese** : la signature exacte de `MalioSiteSelector` (nom du prop, nom de l'event) doit etre verifiee dans `@malio/layer-ui/COMPONENTS.md` apres upgrade. Si elle differe, adapter le wrapper sans toucher au composable. Le wrapper reste le seul point d'adherence a l'API externe.
+
+Si `MalioSiteSelector` **n'embarque pas** le calcul de contraste texte, le wrapper doit le gerer en passant `:text-color` ou en injectant un style calcule. Si le composant delegue la couleur a un slot ou a un formatteur, ajuster l'appel.
+
+### Composable `useCurrentSite()`
+
+```ts
+import type { Site } from '~/shared/types/sites'
+
+const currentSite = ref<Site | null>(null)
+const availableSites = ref<Site[]>([])
+const switching = ref(false)
+
+export function useCurrentSite() {
+    const auth = useAuthStore()
+    const api = useApi()
+    const { t } = useI18n()
+
+    // Hydratation depuis le store auth — single source of truth
+    function syncFromAuth() {
+        availableSites.value = auth.user?.sites ?? []
+        currentSite.value = auth.user?.currentSite ?? null
+    }
+
+    async function switchSite(site: Site) {
+        if (switching.value) return
+        const previous = currentSite.value
+
+        // Optimistic update
+        currentSite.value = site
+        switching.value = true
+
+        try {
+            await api.patch('/me/current-site', { site: `/api/sites/${site.id}` }, {
+                toastSuccessMessage: t('sites.selector.switchSuccess'),
+            })
+            // Propage au store auth pour que tous les consommateurs soient alignes
+            if (auth.user) {
+                auth.user.currentSite = site
+            }
+        } catch (error) {
+            // Rollback
+            currentSite.value = previous
+            throw error // useApi a deja toast l'erreur si toast est active
+        } finally {
+            switching.value = false
+        }
+    }
+
+    function resetCurrentSite() {
+        currentSite.value = null
+        availableSites.value = []
+        switching.value = false
+    }
+
+    return {
+        currentSite,
+        availableSites,
+        switching,
+        switchSite,
+        resetCurrentSite,
+        syncFromAuth,
+    }
+}
+```
+
+**Pattern** : state singleton au niveau module (refs module-level), meme convention que `useSidebar()`. Le singleton est necessaire pour que le logout + les consommateurs multiples partagent le meme etat. `resetCurrentSite()` est appele explicitement au logout (cf. section 4).
+
+**Hydratation** : `syncFromAuth()` est appele au mount de `SiteSelector.vue` (dans un `onMounted` ou un `watch` sur `auth.user`). Alternative : appeler dans `auth.global.ts` apres `ensureSession()`.
+
+### Composable `useModules()`
+
+Pattern strictement aligne sur `useSidebar()` (cf. `frontend/shared/composables/useSidebar.ts`) :
+
+```ts
+const activeModuleIds = ref<string[]>([])
+const loaded = ref(false)
+
+export function useModules() {
+    async function loadModules() {
+        try {
+            const api = useApi()
+            const data = await api.get<{ modules: string[] }>('/modules', {}, { toast: false })
+            activeModuleIds.value = data.modules ?? []
+            loaded.value = true
+        } catch {
+            activeModuleIds.value = []
+            loaded.value = true
+        }
+    }
+
+    function isModuleActive(id: string): boolean {
+        return activeModuleIds.value.includes(id)
+    }
+
+    function resetModules() {
+        activeModuleIds.value = []
+        loaded.value = false
+    }
+
+    return { activeModuleIds, loaded, loadModules, isModuleActive, resetModules }
+}
+```
+
+**Attention** : verifier la forme exacte de la reponse `/api/modules` via `curl /api/modules`. Les specs RBAC anterieurs suggerent `{ modules: string[] }` mais il faut valider.
+
+## 6. Contraste automatique du texte
+
+### Algorithme
+
+Formule de luminance relative WCAG 2.1 (simplifiee) :
+
+```ts
+function getRelativeLuminance({ r, g, b }: RGB): number {
+    const [R, G, B] = [r, g, b].map(c => {
+        const normalized = c / 255
+        return normalized <= 0.03928
+            ? normalized / 12.92
+            : ((normalized + 0.055) / 1.055) ** 2.4
+    })
+    return 0.2126 * R + 0.7152 * G + 0.0722 * B
+}
+
+export function getReadableTextColor(hex: string): 'black' | 'white' {
+    const rgb = parseHex(hex)
+    return getRelativeLuminance(rgb) > 0.5 ? 'black' : 'white'
+}
+```
+
+Le seuil 0.5 est un compromis pragmatique : simple, lisible, pas parfait WCAG AAA mais suffisant pour distinguer blancs/jaunes pales (→ texte noir) des bleus/verts/rouges saturés (→ texte blanc).
+
+### Integration dans le selecteur
+
+Le composable ou le template calcule la couleur pour chaque site une seule fois :
+
+```ts
+const textColorsBySiteId = computed(() => {
+    const map = new Map<number, string>()
+    for (const site of availableSites.value) {
+        map.set(site.id, getReadableTextColor(site.color))
+    }
+    return map
+})
+```
+
+Le template applique `:style="{ color: textColorsBySiteId.get(site.id) }"` sur chaque bloc, ou passe la map au composant `MalioSiteSelector` si son API l'accepte.
+
+### Cas limite — hex invalide
+
+`parseHex` leve une `Error` si le format ne matche pas `#[0-9A-Fa-f]{6}`. Au niveau du selecteur, le template entoure l'acces dans un try/catch logique : si un site a une couleur invalide (improbable car la regex backend du ticket 1 bloque), fallback a texte blanc.
+
+## 7. Intégration dans `layouts/default.vue`
+
+### Structure actuelle
+
+```
+<div class="h-screen overflow-hidden">
+  <div class="flex h-full">
+    <MalioSidebar ... />
+    <div class="h-full flex-1 flex flex-col min-h-0 min-w-0">
+      <main>...</main>
+    </div>
+  </div>
+</div>
+```
+
+### Structure cible
+
+```
+<div class="h-screen overflow-hidden">
+  <div class="flex h-full">
+    <MalioSidebar ... />
+    <div class="h-full flex-1 flex flex-col min-h-0 min-w-0">
+      <SiteSelector v-if="showSiteSelector" />
+      <main>...</main>
+    </div>
+  </div>
+</div>
+```
+
+Script :
+```ts
+const auth = useAuthStore()
+const { isModuleActive } = useModules()
+
+const showSiteSelector = computed(() =>
+    isModuleActive('sites') && (auth.user?.sites?.length ?? 0) > 0,
+)
+```
+
+### Render conditionnel et flash
+
+Le middleware `auth.global.ts` resout deja `auth.user` (via `ensureSession()`) avant le rendu des pages. Le middleware doit en plus declencher `loadModules()` pour que `isModuleActive` soit resolu au premier render. Sans ca, `showSiteSelector` sera `false` pendant un premier paint, puis `true` apres le chargement de `/api/modules` → flash visuel.
+
+**Solution** : dans `auth.global.ts`, appeler `loadModules()` au meme niveau que `loadSidebar()`.
+
+### Import statique vs dynamique
+
+Deux options :
+- **Import statique** (`SiteSelector.vue` est toujours dans le bundle) : simple, le `v-if` gere l'affichage. Impact bundle minimal.
+- **Import dynamique** (`defineAsyncComponent`) : le composant n'est charge que si le module est actif. Plus propre au sens "desactiver Sites = zero code sites dans le bundle", mais le layer Nuxt rend le composant auto-importable → le code est deja dans le bundle de toute facon.
+
+**Recommandation** : import statique. L'economie de bundle est marginale et le layer Nuxt charge deja tout le module.
+
+## 8. i18n
+
+### Clés ajoutées
+
+```json
+{
+    "sites": {
+        "selector": {
+            "switchSuccess": "Site courant change",
+            "switchError": "Impossible de changer de site",
+            "ariaLabelActive": "Site actif : {name}",
+            "ariaLabelInactive": "Basculer sur le site {name}"
+        }
+    }
+}
+```
+
+### Règles
+
+- **Jamais** traduire le nom d'un site (`site.name`). C'est une donnee metier, affichee telle quelle. L'`uppercase` est applique en CSS (`text-transform: uppercase`), pas dans la donnee.
+- Les `aria-label` interpollent `{name}` directement.
+- `switchError` est consomme par le toast d'erreur de `useApi` si la route serveur renvoie un code non-2xx. Pour une erreur 403 "site non autorise" (cf. ticket 2), le serveur renvoie deja un message traduit ou un code i18n stable — a arbitrer au moment de l'implementation selon la decision prise au ticket 2.
+
+## 9. Accessibilité
+
+- Chaque bloc est un `<button type="button">` (pas un `<div>` avec `role="button"` — preferer la semantique native).
+- `aria-pressed="true"` sur le bloc du site courant, `aria-pressed="false"` sur les autres.
+- `aria-label` : l'uppercase CSS est visuel ; l'aria-label garde la casse originale du nom pour le screen reader (`aria-label="Site actif : Chatellerault"`).
+- Focus visible : `focus:ring-2 focus:ring-offset-2 focus:ring-primary-500 focus:outline-none`.
+- Tab : parcourt les blocs de gauche a droite.
+- Enter / Espace : declenche le switch (comportement natif du `<button>`).
+- `tabindex="0"` n'est pas requis sur un `<button>` (deja focusable natif). Ne pas ajouter `tabindex="-1"` sur le bloc courant : l'user doit pouvoir revenir dessus.
+
+## 10. Plan de tests
+
+### Vitest — `useCurrentSite.spec.ts`
+
+1. `switchSite met a jour currentSite localement immediatement` : avant la resolution de la promise, `currentSite.value` est deja le nouveau site.
+2. `switchSite persiste via /api/me/current-site` : mock `useApi`, verifier que la requete PATCH est appelee avec `site: '/api/sites/{id}'`.
+3. `switchSite rollback en cas d'erreur` : mock `useApi` pour rejeter, verifier que `currentSite.value` repasse a l'ancien site.
+4. `switchSite propagate au store auth apres succes` : `auth.user.currentSite` est mis a jour apres succes.
+5. `resetCurrentSite vide l'etat` : apres appel, `currentSite = null`, `availableSites = []`, `switching = false`.
+6. `switching est vrai pendant la requete, faux apres` : verifier le flag sur tout le cycle.
+7. `double switchSite concurrent est ignore` : si `switching = true`, un second appel retourne immediatement sans effet (garde anti-double-submit).
+
+### Vitest — `useModules.spec.ts`
+
+1. `loadModules charge /api/modules et alimente activeModuleIds`.
+2. `isModuleActive retourne true si l'id est present, false sinon`.
+3. `resetModules vide l'etat`.
+4. `loadModules swallow les erreurs et laisse activeModuleIds vide` (alignement avec `useSidebar`).
+
+### Vitest — `color.spec.ts`
+
+1. `getReadableTextColor('#FFFFFF') === 'black'`.
+2. `getReadableTextColor('#000000') === 'white'`.
+3. `getReadableTextColor('#056CF2') === 'white'` (bleu sature).
+4. `getReadableTextColor('#F59E0B') === 'black'` (ambre clair).
+5. `getReadableTextColor('#10B981') === 'white'` (vert medium-foncé). A verifier a l'implementation ; adapter l'assertion.
+6. `parseHex('red') → throw` (format invalide).
+7. `parseHex('#FFF') → throw` (hex court non supporte).
+8. `parseHex('#abcdef')` et `parseHex('#ABCDEF')` → meme resultat (tolere la casse).
+
+### Vitest — `SiteSelector.spec.ts`
+
+1. `Rendu : 3 sites rendus, bloc du site courant a opacity-100`.
+2. `Bloc inactif a opacity-40 et aria-pressed="false"`.
+3. `Clic sur un bloc inactif appelle switchSite avec le bon site`.
+4. `Si switchSite throw, l'UI affiche toujours l'ancien site courant` (via rollback).
+5. `Texte d'un site avec couleur claire (#FFFFFF) est rendu noir`.
+6. `Texte d'un site avec couleur foncee (#056CF2) est rendu blanc`.
+
+### Tests PHPUnit
+
+Pas de nouveau test backend dans ce ticket — le ticket 2 couvre deja l'endpoint `/api/me/current-site`. Si un comportement nouveau est introduit cote serveur (ce qui ne devrait pas arriver), ajouter les tests en consequence.
+
+### Test visuel manuel
+
+- `make dev-nuxt` (port 3004).
+- Login `admin` / `admin` → selecteur avec 3 blocs (Chatellerault actif, Saint-Jean et Pommevic a 40%).
+- Clic sur `Pommevic` → Pommevic devient actif (100%), Chatellerault passe a 40%, toast "Site courant change".
+- F5 → site actif persiste (Pommevic).
+- Logout puis re-login → Pommevic toujours actif.
+- Login `bob` / `bob` → un seul bloc (Saint-Jean), affiche par coherence (cf. regle metier "afficher meme pour 1 site").
+- Retirer tous les sites a `alice` via `/admin/users` → login alice → selecteur absent.
+- Desactiver `SitesModule::class` dans `config/modules.php`, restart backend, refresh front → selecteur absent, layout identique au comportement d'avant ce ticket.
+
+## 11. Risques et points d'attention
+
+### Risque 1 — Signature de `MalioSiteSelector` inconnue au moment de la spec
+
+La version de `@malio/layer-ui` installee localement (1.3.0) ne contient pas `MalioSiteSelector`. La spec decrit le contrat attendu (props `sites`, `current-site-id`, event `switch`), mais la signature reelle est definie par la lib et peut differer (nom du prop, structure de l'event, slots disponibles, gestion du contraste texte).
+
+**Mitigation** : apres `npm install` de la nouvelle version, consulter `node_modules/@malio/layer-ui/COMPONENTS.md` ou le fichier Vue du composant, adapter `SiteSelector.vue` (wrapper) sans toucher au composable `useCurrentSite()`. Le wrapper est le seul point d'adherence a l'API externe.
+
+### Risque 2 — Flash au premier paint
+
+Si `showSiteSelector` est `false` le temps de resoudre `/api/modules`, l'user voit le layout sans selecteur puis avec → flash desagreable. La solution est de bloquer le rendu sur `loaded.value` du composable modules dans le middleware `auth.global.ts` avant que le layout ne soit instancie.
+
+A verifier apres implementation : ouvrir le devtools "Network throttling" en Slow 3G, login, observer. Si flash : ajouter une garde d'attente avant de rendre le layout ou utiliser un skeleton.
+
+### Risque 3 — `auth.user` muté directement
+
+Le composable `switchSite` mute `auth.user.currentSite = site` pour propager le changement au store auth. Pinia autorise cette mutation mais elle contourne les actions formelles. Alternative plus propre : ajouter une action `auth.setCurrentSite(site)` et l'appeler. Choix pragmatique dans cette spec → privilegier la mutation directe pour rester aligne sur le pattern existant (`auth.user.currentSite` est une propriete simple) ; si un reviewer prefere l'action formelle, c'est un changement localisé sans impact autre.
+
+### Risque 4 — Composable singleton et tests
+
+Les refs `currentSite`, `availableSites`, `switching` sont declarees au niveau module → partagees entre tous les appels a `useCurrentSite()`. En Vitest, cela fuit entre tests si on ne fait pas un `beforeEach(() => resetCurrentSite())`. A documenter en tete du fichier de tests pour eviter des bugs inter-tests.
+
+### Risque 5 — Contraste texte et faux positifs
+
+Le seuil de 0.5 sur la luminance peut donner des rendus sous-optimaux sur des couleurs "limite" (ex: vert emeraude `#10B981` a une luminance qui balance pres du seuil). Si un reviewer trouve le texte peu lisible en usage reel, deux options :
+- Raffiner le calcul : passer a la formule de contraste WCAG complete (ratio entre fond et texte, seuil a 4.5:1).
+- Contraindre la couleur a l'entree : ajouter une validation back (ticket 4 ?) qui rejette les couleurs trop claires si le texte noir donne < 4.5:1 de contraste.
+
+Pour ce ticket, le seuil 0.5 suffit (fixtures testees : `#056CF2` bleu sombre → blanc, `#F59E0B` ambre clair → noir, `#10B981` vert → a voir ; l'admin peut toujours eviter les couleurs pales).
+
+### Risque 6 — Debordement responsive avec 4+ sites
+
+`flex-1` + `min-w-[200px]` + `overflow-x-auto` sur le conteneur gere le debordement de maniere acceptable. Mais sur ecran tres etroit (tablette portrait 768px) avec 4 sites a 200px chacun, le user doit scroller horizontalement — experience sous-optimale.
+
+Alternative : `flex-wrap` + `h-auto` pour laisser les blocs passer a la ligne → le header n'est plus a hauteur fixe 72px. Compromis a trancher selon les usages reels. Ce ticket implemente la solution scroll car la contrainte Figma est "barre de 72px" ; relecture de cette contrainte au ticket 4 si besoin.
+
+### Risque 7 — Auto-selection du currentSite au login si null
+
+Le ticket mentionne : "si currentSite est null et user a ≥1 site, le backend doit avoir auto-selectionne le premier (ou a defaut, faire le switch cote frontend au premier mount du selecteur)".
+
+Le ticket 2 **ne fait pas** d'auto-selection cote backend. Il faut donc gerer cote front : au mount du selecteur, si `currentSite === null && availableSites.length > 0`, appeler `switchSite(availableSites[0])` automatiquement. Cela genere un PATCH au premier chargement d'un user nouvellement rattache — acceptable.
+
+**Alternative** : faire l'auto-selection cote backend au ticket 2. Si cette alternative est choisie en amont, retirer ce comportement cote front. A clarifier au sprint planning.
+
+### Risque 8 — Conflit avec le scroll principal
+
+Le selecteur est dans `flex-1 flex flex-col` au-dessus de `<main>`. `<main>` a `overflow-y-auto` qui permet son propre scroll. Le selecteur est en dehors du `overflow-y-auto` du `<main>` → il reste fige au top quand on scrolle le contenu. Verifier qu'il n'y a pas de collision avec le `sticky top-0 h-8` deja present dans `<main>` (ligne 19-21 de `default.vue`), qui sert de "gradient de lecture" sur le contenu.
+
+## 12. Ordre d'exécution recommandé
+
+1. **Upgrade Malio** — `npm install @malio/layer-ui@<version>`, verifier `node_modules/@malio/layer-ui/COMPONENTS.md` pour la signature de `MalioSiteSelector`.
+2. **Utilitaire couleur** — creer `frontend/shared/utils/color.ts` et ses tests. Isole et rapide a valider.
+3. **Types** — mettre a jour `frontend/shared/types/user-data.ts` et verifier que `frontend/shared/types/sites.ts` existe (sinon le creer).
+4. **Composable modules** — creer `useModules()` et ses tests.
+5. **Composable current site** — creer `useCurrentSite()` et ses tests.
+6. **Middleware** — brancher `loadModules()` dans `auth.global.ts`.
+7. **Composant SiteSelector** — creer `SiteSelector.vue`, implementer wrapper autour de `MalioSiteSelector`, gerer contraste texte.
+8. **Tests composant** — smoke test Vitest sur `SiteSelector.vue`.
+9. **Integration layout** — modifier `frontend/app/layouts/default.vue`, brancher `showSiteSelector`.
+10. **Logout reset** — ajouter `useCurrentSite().resetCurrentSite()` et `useModules().resetModules()` dans `frontend/modules/core/pages/logout.vue`.
+11. **i18n** — completer `frontend/i18n/locales/fr.json`.
+12. **Test visuel** — `make dev-nuxt`, scenarios section 10 "Test visuel manuel".
+13. **Nuxt-lint** — `make nuxt-lint`.
+14. **Vitest full run** — `make nuxt-test`, s'assurer que 100% des tests passent.
+
+## 13. Critères d'acceptation (DoD)
+
+- [ ] `@malio/layer-ui` upgrade vers la version contenant `MalioSiteSelector`. `package-lock.json` committe.
+- [ ] Layer `frontend/modules/sites/` contient bien les dossiers `components/` et `composables/` (layer deja initialise au ticket 2 pour la page admin).
+- [ ] `SiteSelector.vue` : hauteur `h-[72px]`, blocs `flex-1 min-w-[200px]`, text uppercase Inter Bold 24, fond = `site.color`, opacity 100% sur actif / 40% sur inactifs, hover 70% + cursor pointer.
+- [ ] Contraste texte calcule dynamiquement : `#FFFFFF` → noir, `#056CF2` → blanc, `#F59E0B` → noir (tests Vitest verts).
+- [ ] Chaque bloc est un `<button type="button">` avec `aria-pressed` et `aria-label` i18n, focus visible, navigation Tab/Enter fonctionnelle.
+- [ ] Integre dans `layouts/default.vue`, rendu conditionnel `isModuleActive('sites') && user.sites.length > 0`.
+- [ ] Clic sur un bloc inactif → PATCH `/api/me/current-site` via `useApi`, optimistic update, toast succes.
+- [ ] Erreur PATCH → rollback du `currentSite`, toast d'erreur (celui de `useApi` par defaut).
+- [ ] Switch persistant : F5 conserve le nouveau site actif.
+- [ ] Desactiver `SitesModule::class` dans `config/modules.php` → selecteur absent, layout identique a avant ce ticket.
+- [ ] User avec 0 site → selecteur absent (pas de "barre vide").
+- [ ] User avec 1 site → selecteur present (1 bloc unique, bloc actif).
+- [ ] User avec 4+ sites → scroll horizontal fonctionne, pas de debordement casse a 1280px.
+- [ ] `useCurrentSite().resetCurrentSite()` et `useModules().resetModules()` appeles au logout.
+- [ ] `make nuxt-lint` propre.
+- [ ] `make nuxt-test` passe tous les tests (existants + 4 nouveaux suites).
+- [ ] `make dev-nuxt` : aucun warning ni erreur console lors du switch et des cycles login/logout.

docs/sites/ticket-04-spec.md

@@ -0,0 +1,531 @@
+# Ticket #04 — 4/4 — Outillage opt-in « site-scoped » pour modules métier
+
+## 1. Objectif
+
+Ce ticket livre l'outillage qui permettra aux modules metier (Commercial, Stock, Production, etc.) de declarer leurs entites comme **scopees par site** : une fois l'adoption effectuee, un utilisateur ne verra en lecture que les lignes dont `site_id` correspond a son site courant, et les creations/editions injectent automatiquement ce site courant si le payload ne le precise pas.
+
+Le ticket est volontairement **strictement infrastructurel** : il n'adopte le pattern sur aucune entite existante. Aucun module metier n'est modifie, aucune migration n'est jouee sur des tables deja en place. Les tickets futurs (ou des tickets annexes par module) adopteront l'interface au cas par cas apres arbitrage metier.
+
+Le ticket livre aussi une documentation developpeur (`docs/modules/site-aware.md`) qui explique comment et quand adopter le pattern, et quelles entites **ne doivent pas** l'adopter (roles, permissions, users, catalogues globaux, etc.).
+
+## 2. Périmètre
+
+### IN
+
+- Creer le contrat `App\Shared\Domain\Contract\SiteAwareInterface` : interface minimale `getSite(): ?Site` / `setSite(Site $site): void`, place dans `Shared/Domain/Contract/` pour que les modules metier en dependent **sans** importer le module Sites.
+- Creer `CurrentSiteProvider` (module Sites, couche Application) qui resout le site courant a partir de `Security::getUser()` + `User::getCurrentSite()`, et renvoie `null` si : pas d'user authentifie, `currentSite` null, **ou** module Sites inactif dans `config/modules.php`.
+- Creer `SiteScopedQueryExtension` (module Sites, Infrastructure API Platform) implementant `QueryCollectionExtensionInterface` et `QueryItemExtensionInterface` : ajoute la clause `WHERE <alias>.site = :currentSite` quand la resource cible implemente `SiteAwareInterface`, le provider retourne un site, et l'user n'a pas `sites.bypass_scope`.
+- Creer `SiteAwareInjectionProcessor` (module Sites, decorator de `api_platform.doctrine.orm.state.persist_processor`) : avant de deleguer la persistance, si `$data` est une instance de `SiteAwareInterface` et n'a pas deja de site positionne, injecte le `currentSite` fourni par le provider.
+- Declarer la permission `sites.bypass_scope` dans `SitesModule::permissions()`. Admin ou user avec cette permission → le filtre Query Extension saute, visibilite globale.
+- Ecrire `docs/modules/site-aware.md` : guide developpeur complet (cf. section 10).
+- Tests PHPUnit avec une entite fictive `FakeSiteAwareEntity` declaree uniquement dans la suite de tests (jamais en production) pour prouver que le filtrage et l'injection automatique fonctionnent bout en bout.
+- Tests du cas "Sites desactive" : desactiver `SitesModule::class` dans `config/modules.php` avant la suite, re-sync, verifier que l'outillage est no-op et qu'aucun test existant ne casse.
+
+### OUT
+
+- Adoption du pattern sur une entite metier reelle (ex: `Supplier`, `Client`, etc.) : **hors scope**. C'est aux tickets annexes ou aux tickets de feature de l'adopter quand necessaire, en suivant la doc.
+- Migration de donnees "legacy" : ce ticket documente le piege (entites existantes sans `site_id`) mais ne livre aucune migration par module.
+- Support CLI / commandes console : le filtre est uniquement actif dans le contexte API Platform (via les extensions). Une commande batch lira toutes les lignes sans filtre, comportement attendu pour les taches admin. Une eventuelle reimplementation via un Doctrine SQL Filter generique est citee en alternative non retenue (cf. Risque 4).
+- Double-ecriture avec un Doctrine `SQLFilter` : non retenu dans ce ticket. Le filtre via extension API Platform couvre 100% des usages HTTP, qui est le seul contexte ou le site courant a un sens metier (user authentifie). Les commandes CLI doivent gerer la portee explicitement.
+- Changement du comportement cote front : aucun. Le filtrage est transparent, le front continue de faire `GET /api/suppliers` et recoit une collection pre-filtree. Si une entite est adoptee au ticket futur, la page existante continue de fonctionner sans modification.
+- Support d'entites "partiellement site-aware" (colonne site_id nullable, certaines lignes globales partagees) : non retenu. Une entite est soit SiteAware, soit globale. Si un module a besoin de la semantique hybride, il devra creer deux entites distinctes.
+
+## 3. Fichiers à créer
+
+### Shared — Contrat
+
+- `/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/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/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/Starseed/docs/modules/site-aware.md` : guide developpeur (cf. contenu section 10).
+
+### Tests
+
+- `/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/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/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/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/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/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`
+
+```php
+<?php
+
+declare(strict_types=1);
+
+namespace App\Shared\Domain\Contract;
+
+use App\Module\Sites\Domain\Entity\Site;
+
+/**
+ * Contrat opt-in pour les entites dont la visibilite est scopee par site.
+ *
+ * Une entite implementant cette interface sera :
+ *  - filtree en lecture par SiteScopedQueryExtension (collection + item)
+ *    selon le site courant de l'utilisateur authentifie ;
+ *  - alimentee automatiquement en POST/PATCH par SiteAwareInjectionProcessor
+ *    si le payload ne precise pas de site.
+ *
+ * L'implementation concrete doit :
+ *  - Declarer une relation ManyToOne(Site::class) avec colonne `site_id` NOT NULL.
+ *  - Indexer `site_id` en base (sinon le filtre WHERE genere un full-scan).
+ *
+ * Ne PAS implementer cette interface pour :
+ *  - Des entites globales (catalogue partage, roles, permissions, users).
+ *  - Des entites dont le scope est "par tenant" plus large que le site
+ *    (utiliser TenantAwareInterface le cas echeant).
+ *  - Des entites transversales references par plusieurs sites.
+ *
+ * Voir `docs/modules/site-aware.md` pour le guide d'adoption complet.
+ */
+interface SiteAwareInterface
+{
+    public function getSite(): ?Site;
+
+    public function setSite(Site $site): void;
+}
+```
+
+### Remarque sur le typage du getter
+
+`getSite(): ?Site` retourne nullable pour deux raisons :
+- Coherence avec des entites en cours de construction (pre-persist, avant injection).
+- Compat avec des colonnes qui deviendraient nullable lors d'une migration progressive (ex: deploiement en 2 etapes avec backfill).
+
+En regime nominal, apres persistance, `getSite()` ne doit jamais etre null. Un `assert($entity->getSite() !== null)` dans du code sensible est acceptable.
+
+## 6. Service `CurrentSiteProvider`
+
+### Responsabilite
+
+Expose **une seule** methode `get(): ?Site`. Resout le site courant selon la chaine :
+1. Si `SitesModule::class` n'est pas present dans `config/modules.php` → `null`.
+2. Sinon, si `Security::getUser()` est null → `null`.
+3. Sinon, si `$user->getCurrentSite()` est null → `null`.
+4. Sinon → retourne le Site.
+
+### Detection d'activation du module
+
+Deux strategies possibles :
+
+**Strategie A — lire `config/modules.php` au boot du service** (pattern `ModulesProvider`) :
+```php
+public function __construct(
+    private readonly Security $security,
+    #[Autowire(param: 'kernel.project_dir')]
+    string $projectDir,
+) {
+    $moduleClasses       = require $projectDir.'/config/modules.php';
+    $this->sitesActive   = in_array(SitesModule::class, $moduleClasses, true);
+}
+```
+
+**Strategie B — extraire un service `ActiveModulesRegistry`** partage entre `ModulesProvider` et `CurrentSiteProvider` (refactor mineur).
+
+**Recommandation** : strategie A dans ce ticket pour rester minimal. Si un troisieme consommateur apparait (probable), extraire le registry dans un ticket dedie.
+
+### Contrat complet
+
+```php
+<?php
+
+declare(strict_types=1);
+
+namespace App\Module\Sites\Application\Service;
+
+use App\Module\Core\Domain\Entity\User;
+use App\Module\Sites\Domain\Entity\Site;
+use App\Module\Sites\SitesModule;
+use Symfony\Bundle\SecurityBundle\Security;
+use Symfony\Component\DependencyInjection\Attribute\Autowire;
+
+final class CurrentSiteProvider
+{
+    private readonly bool $sitesActive;
+
+    public function __construct(
+        private readonly Security $security,
+        #[Autowire(param: 'kernel.project_dir')]
+        string $projectDir,
+    ) {
+        $moduleClasses     = require $projectDir.'/config/modules.php';
+        $this->sitesActive = in_array(SitesModule::class, $moduleClasses, true);
+    }
+
+    public function get(): ?Site
+    {
+        if (!$this->sitesActive) {
+            return null;
+        }
+
+        $user = $this->security->getUser();
+        if (!$user instanceof User) {
+            return null;
+        }
+
+        return $user->getCurrentSite();
+    }
+}
+```
+
+## 7. Extensions API Platform
+
+### `SiteScopedQueryExtension`
+
+Implemente a la fois `QueryCollectionExtensionInterface` et `QueryItemExtensionInterface`. La logique est commune et factorisee dans une methode privee `applyScope()`.
+
+```php
+public function applyToCollection(
+    QueryBuilder $queryBuilder,
+    QueryNameGeneratorInterface $queryNameGenerator,
+    string $resourceClass,
+    ?Operation $operation = null,
+    array $context = [],
+): void {
+    $this->applyScope($queryBuilder, $queryNameGenerator, $resourceClass);
+}
+
+public function applyToItem(
+    QueryBuilder $queryBuilder,
+    QueryNameGeneratorInterface $queryNameGenerator,
+    string $resourceClass,
+    array $identifiers,
+    ?Operation $operation = null,
+    array $context = [],
+): void {
+    $this->applyScope($queryBuilder, $queryNameGenerator, $resourceClass);
+}
+
+private function applyScope(
+    QueryBuilder $queryBuilder,
+    QueryNameGeneratorInterface $queryNameGenerator,
+    string $resourceClass,
+): void {
+    // 1) Resource SiteAware ?
+    if (!is_subclass_of($resourceClass, SiteAwareInterface::class)) {
+        return;
+    }
+
+    // 2) Bypass admin / permission dediee ?
+    if ($this->security->isGranted('sites.bypass_scope')) {
+        return;
+    }
+
+    // 3) Site courant disponible ?
+    $currentSite = $this->currentSiteProvider->get();
+    if ($currentSite === null) {
+        // Decision assumee : no-op plutot que collection vide (cf. section 11 Risque 1).
+        return;
+    }
+
+    // 4) Applique WHERE site = :currentSite
+    $rootAlias    = $queryBuilder->getRootAliases()[0];
+    $parameterName = $queryNameGenerator->generateParameterName('currentSite');
+    $queryBuilder
+        ->andWhere(sprintf('%s.site = :%s', $rootAlias, $parameterName))
+        ->setParameter($parameterName, $currentSite);
+}
+```
+
+### Ordre de priorite
+
+L'extension doit s'executer **apres** les filtres natifs API Platform (Pagination, Order, Search). Priorite par defaut (0) convient, mais si un autre filtre custom est ajoute plus tard, verifier qu'il ne court-circuite pas. Declarer la priorite explicitement via `#[AsTaggedItem(priority: -100)]` est une option pour s'executer en dernier et etre robuste a l'ordre d'ajout d'autres extensions.
+
+### JSON-LD `totalItems`
+
+API Platform execute un `COUNT(*)` separe pour produire le `totalItems` dans la reponse Hydra. Ce count passe par les memes extensions → le totalItems reflete automatiquement le filtrage. A verifier par un test dedie (cf. section 11).
+
+### `applyToItem` et 404
+
+Quand un GET `/api/suppliers/{id}` cible un supplier qui existe en base mais appartient a un autre site, la requete `SELECT ... WHERE id = :id AND site = :currentSite` retourne `null` → API Platform converti en 404. Comportement desire : l'user ne doit pas pouvoir distinguer "cet item n'existe pas" de "cet item existe mais pas dans mon site" (anti-enumeration).
+
+## 8. Processor d'injection automatique `SiteAwareInjectionProcessor`
+
+### Pattern decorator
+
+Le plus propre en API Platform est de decorer le processor de persistance Doctrine :
+
+```php
+<?php
+
+declare(strict_types=1);
+
+namespace App\Module\Sites\Infrastructure\ApiPlatform\State\Processor;
+
+use ApiPlatform\Metadata\Operation;
+use ApiPlatform\State\ProcessorInterface;
+use App\Module\Sites\Application\Service\CurrentSiteProvider;
+use App\Shared\Domain\Contract\SiteAwareInterface;
+use Symfony\Component\DependencyInjection\Attribute\AsDecorator;
+use Symfony\Component\HttpKernel\Exception\BadRequestHttpException;
+
+#[AsDecorator('api_platform.doctrine.orm.state.persist_processor')]
+final class SiteAwareInjectionProcessor implements ProcessorInterface
+{
+    public function __construct(
+        private readonly ProcessorInterface $inner,
+        private readonly CurrentSiteProvider $currentSiteProvider,
+    ) {}
+
+    public function process(mixed $data, Operation $operation, array $uriVariables = [], array $context = []): mixed
+    {
+        if ($data instanceof SiteAwareInterface && $data->getSite() === null) {
+            $currentSite = $this->currentSiteProvider->get();
+
+            if ($currentSite === null) {
+                throw new BadRequestHttpException(
+                    'Impossible de creer l\'enregistrement : aucun site selectionne.',
+                );
+            }
+
+            $data->setSite($currentSite);
+        }
+
+        return $this->inner->process($data, $operation, $uriVariables, $context);
+    }
+}
+```
+
+### Effets de bord et compatibilite
+
+- **S'applique a TOUS les processors qui heritent du persist processor natif API Platform**. Si un processor custom (ex: `UserRbacProcessor`) delegue a `api_platform.doctrine.orm.state.persist_processor` via autowire, il passe aussi par ce decorator — transparent pour User (non SiteAware).
+- **N'ecrase jamais un site deja positionne** : un admin qui POST un supplier avec `site: '/api/sites/2'` garde cette valeur, meme si son `currentSite` est 1. La regle metier "site different autorise uniquement si l'user a plusieurs sites" du ticket n'est **pas** implementee dans ce decorator : c'est au voter de securite (hors scope de ce ticket) de l'enforcer si necessaire.
+- **Erreur explicite si pas de site** : BadRequestHttpException plutot qu'un `null` silencieux. Le user comprend que l'operation necessite un site actif.
+
+### Alternative rejetee — EventListener Doctrine `prePersist`
+
+Un listener Doctrine intercepterait toutes les persistances, y compris hors HTTP (CLI, fixtures). **Rejetee** car :
+- `CurrentSiteProvider` depend de `Security`, indisponible en CLI.
+- Les fixtures doivent positionner explicitement le site (cf. `AppFixtures` ticket 2), ce qui est plus correct metier.
+- Les commandes batch peuvent vouloir creer des entites sans site actif (backoffice multi-sites) — un listener silencieux les bloquerait.
+
+Le decorator HTTP-only est plus aligne avec le principe "opt-in controle".
+
+## 9. Permission `sites.bypass_scope`
+
+### Déclaration
+
+Dans `SitesModule::permissions()` :
+
+```php
+public static function permissions(): array
+{
+    return [
+        ['code' => 'sites.view', 'label' => 'Voir les sites'],
+        ['code' => 'sites.manage', 'label' => 'Gerer les sites (creer, editer, supprimer)'],
+        ['code' => 'sites.bypass_scope', 'label' => 'Voir les donnees site-scoped de tous les sites (bypass du filtrage)'],
+    ];
+}
+```
+
+### Semantique
+
+- User avec `sites.bypass_scope` → le filtre `WHERE site = :currentSite` n'est pas applique. La collection retournee est **globale** (toutes les lignes).
+- User **admin** (`isAdmin = true`) → `is_granted()` retourne toujours true pour toute permission → le bypass est automatique. Pas besoin d'assignation explicite.
+- Cas typique d'attribution : un admin financier qui veut consolider les suppliers a l'echelle groupe.
+
+### Absence de bypass sur le processor
+
+Le processor d'injection ne respecte **pas** `sites.bypass_scope` : meme un user avec bypass verra son `currentSite` injecte si le payload n'en precise pas. Justification : l'injection n'est pas une restriction, c'est un default value. Le user bypass peut toujours envoyer un site explicite different.
+
+## 10. Documentation développeur — `docs/modules/site-aware.md`
+
+Le fichier livre **5 sections** :
+
+### 10.1 Quand adopter `SiteAwareInterface`
+
+- Entite qui existe "par site" : chaque ligne appartient a un et un seul site, les users ne doivent voir que celles de leur site courant.
+- Exemples : `Supplier` (chaque site a ses fournisseurs), `Order`, `StockEntry`, `Employee` (si chaque site a sa propre equipe).
+
+### 10.2 Quand NE PAS adopter
+
+- Entites globales : `Role`, `Permission`, `User` (les users sont transverses, rattaches a plusieurs sites).
+- Catalogues partages : produits, categories, taxes — s'ils sont mutualises entre sites.
+- Entites transversales : `Invoice` globale, `Contract` multi-site.
+- Entites dont la portee naturelle est "par tenant" plus large que "par site" : utiliser `TenantAwareInterface` (si pertinent pour le projet multi-tenant futur).
+
+### 10.3 Comment adopter (check-list)
+
+1. **Entite** :
+   - Implementer `App\Shared\Domain\Contract\SiteAwareInterface`.
+   - Ajouter la relation `#[ORM\ManyToOne(targetEntity: Site::class)] #[ORM\JoinColumn(name: 'site_id', nullable: false, onDelete: 'CASCADE')] private Site $site`.
+   - Implementer `getSite()` et `setSite()`.
+2. **Migration** :
+   - Creer une migration dediee au module concerne (ou racine si init critique, voir `CLAUDE.md`).
+   - `ALTER TABLE <table> ADD COLUMN site_id INT NOT NULL`.
+   - **Gestion legacy** : si des lignes existent deja, la colonne ne peut pas etre NOT NULL directement. Strategie :
+     1. Ajouter la colonne nullable.
+     2. Backfill manuel ou par script (ex: tout rattacher au site "Chatellerault" par defaut, ou laisser l'admin arbitrer).
+     3. Rendre la colonne NOT NULL via une seconde migration.
+   - **Index** : `CREATE INDEX IDX_<table>_site ON <table> (site_id)`. **Obligatoire** — le filtre `WHERE site_id = ?` genere un full-scan sinon.
+3. **Serialisation** : ajouter `site` au groupe de lecture API (`#[Groups(['<resource>:read'])]`) pour que le front voie a quel site appartient la ligne.
+4. **Processor custom** : si le module a deja un processor sur l'operation POST/PATCH, s'assurer qu'il delegue a `api_platform.doctrine.orm.state.persist_processor` (et non `ObjectManager::persist` direct) pour que le decorator d'injection s'applique.
+
+### 10.4 Comportement en mode degrade
+
+- **Module Sites desactive** (`config/modules.php`) : `CurrentSiteProvider::get()` retourne `null` → le filtre ne s'applique plus → toutes les lignes sont visibles, comme avant l'adoption. L'app reste fonctionnelle, juste sans segmentation. **Mais** : la colonne `site_id` NOT NULL reste en place, et le processor d'injection leve une 400 sur tout POST/PATCH sans site explicite. Consequence : **un module adopte ne peut pas vivre sans Sites active** pour les operations d'ecriture, sauf a envoyer systematiquement un `site` explicite dans le payload. A documenter **fortement**.
+- **User sans site** (sites.length = 0, currentSite = null) : meme comportement → no-op en lecture, 400 en ecriture. Le module doit documenter l'UX degradee.
+
+### 10.5 Gotchas et anti-patterns
+
+- **Sous-collections** (`/api/clients/{id}/contacts`) : l'extension s'applique a la resource chargee, ici `Contact`. Si `Contact` est SiteAware, le filtre passe. Si seul `Client` est SiteAware (et Contact herite du scope via son parent), **le filtre ne se propage pas automatiquement** : il faut soit rendre Contact SiteAware aussi (redondance), soit ajouter un filtre custom qui verifie `contact.client.site == currentSite`. Ce ticket ne couvre pas le second cas.
+- **Jointures** : si un repository custom fait une requete sans passer par API Platform (ex: `findByX()` appele depuis un processor), le filtre ne s'applique pas. Responsabilite du developpeur du module d'ajouter `->andWhere('x.site = :currentSite')` manuellement ou de passer par le `CurrentSiteProvider`.
+- **Tests d'integration** : les tests existants d'un module adopte devront soit logger un user avec un site actif, soit utiliser `sites.bypass_scope` pour voir toute la donnee. La suite de fixtures devra positionner un site coherent sur les entites de test.
+- **Cascade delete d'un site** : le ticket 2 met `user.current_site_id` a NULL si le site est supprime. Si une entite adoptee declare `onDelete: CASCADE` sur sa FK site, elle perdra toutes ses lignes au delete d'un site. Choisir explicitement : cascade (aligne sur l'invariant "une ligne SiteAware a toujours un site") ou blocage (empecher la suppression d'un site s'il reste des lignes adoptees).
+
+## 11. Risques et points d'attention
+
+### Risque 1 — Comportement "no-op si pas de site courant"
+
+La spec choisit **no-op plutot que collection vide** quand `CurrentSiteProvider::get() === null`. Arbitrage :
+
+- **No-op** (retenu) : un user sans site voit tout, un admin sans site aussi. Risque de fuite de donnees d'un site a l'autre, mais l'app reste utilisable.
+- **Collection vide** : un user sans site ne voit rien. Plus strict, mais bloque un admin qui consulterait l'app avant d'avoir configure un site.
+
+Le ticket retient **no-op** car l'app reste utilisable. La permission `sites.bypass_scope` est explicite pour les admins qui veulent voir tout. Si la decision metier evolue, le changement est localise dans `SiteScopedQueryExtension::applyScope()`.
+
+### Risque 2 — Fuite de donnees entre sites
+
+Si un module adopte `SiteAwareInterface` mais qu'un repository custom court-circuite API Platform, le filtre ne s'applique pas. Consequence : un endpoint custom (`GET /api/suppliers/top-rated`) pourrait exposer tous les suppliers sans filtrage.
+
+**Mitigation** : la doc insiste sur la responsabilite du developpeur d'adopter le filtre manuellement dans les repositories custom. Un test d'integration par module adopte est **fortement recommande**.
+
+### Risque 3 — `FakeSiteAwareEntity` en tests
+
+L'entite fictive doit etre mappee par Doctrine pour que le QueryBuilder fonctionne. Trois options :
+
+1. **Declaration via `when@test`** : ajouter `config/packages/doctrine.yaml` dans un bloc `when@test` avec un mapping dedie pointant vers `tests/Fixtures/SiteAware/`. Propre mais ajoute un fichier de config.
+2. **Attribute Doctrine dans le fichier de test** : fonctionne si le kernel de test decouvre le namespace. Pas elegant.
+3. **Mock integral du QueryBuilder** : pas d'entite reelle, on mock Doctrine. Tests plus unitaires mais moins realistes.
+
+**Recommandation** : option 1 (mapping `when@test`). La classe reste dans `tests/` et ne pollue jamais la prod.
+
+### Risque 4 — Pas de Doctrine SQL Filter
+
+Un Doctrine `SQLFilter` appliquerait le filtrage a **toutes** les requetes Doctrine, y compris hors API Platform (CLI, fixtures, cron, reports). Plus defensif mais plus risque :
+
+- Les commandes batch devraient l'activer/desactiver explicitement.
+- Les fixtures devraient le desactiver pour seeder plusieurs sites.
+- Les tests d'integration devraient le gerer.
+
+Le ticket retient la strategie **API Platform only** car le site courant n'a de sens que dans un contexte HTTP authentifie. Si un besoin emerge (rapport automatique scope par site, webhook multi-site, etc.), le refactor vers un SQL filter sera localise.
+
+### Risque 5 — Priorite des extensions
+
+Si un autre module introduit plus tard une extension avec une clause `HAVING` ou un `setMaxResults` qui suppose que le filtre de base n'est pas modifie, il peut y avoir des surprises. Declarer explicitement une priorite negative (`priority: -100`) sur `SiteScopedQueryExtension` via `#[AsTaggedItem]` la fait s'executer apres la plupart des filtres natifs, ce qui est generalement souhaitable pour un filtre applicatif.
+
+### Risque 6 — `UserRbacProcessor` et les autres processors custom
+
+Le decorator `SiteAwareInjectionProcessor` decore `api_platform.doctrine.orm.state.persist_processor`. Si un module declare un processor custom qui **ne delegue pas** au persist processor (ex: fait `$em->persist($data); $em->flush()` directement), l'injection de site n'a **pas** lieu. Le module doit explicitement passer par le persist processor pour beneficier du pattern.
+
+A mitiger par un test qui genere une entite `FakeSiteAwareEntity` via un POST `api_platform.doctrine.orm.state.persist_processor` mocke et verifie que le decorator a bien injecte le site.
+
+### Risque 7 — Performance du `require` au boot
+
+`CurrentSiteProvider` fait un `require 'config/modules.php'` au constructeur. Le fichier est un simple `return [...]` → l'overhead est minimal et le resultat est opcache par PHP. Meme pattern que `ModulesProvider`, sans regression perf documentee.
+
+### Risque 8 — Doc developpeur en francais vs anglais
+
+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
+
+### Tests unitaires (`TestCase` pur)
+
+#### `CurrentSiteProviderTest`
+
+1. `testReturnsNullIfSitesModuleInactive` : config/modules.php de test ne contient pas SitesModule → null meme si user + site fixent.
+2. `testReturnsNullIfNoUser` : Security::getUser() = null → null.
+3. `testReturnsNullIfUserHasNoCurrentSite` : user.currentSite = null → null.
+4. `testReturnsSiteIfAllConditionsMet` : user + currentSite set → retourne le Site.
+
+#### `SiteAwareInjectionProcessorTest`
+
+1. `testInjectsCurrentSiteOnNewSiteAwareData` : $data SiteAware + getSite() = null + provider retourne Site → setSite appele avec le bon site.
+2. `testDoesNotOverrideExistingSite` : $data SiteAware + getSite() non-null → pas d'appel a setSite, delegation directe.
+3. `testSkipsNonSiteAwareData` : $data qui n'implemente pas SiteAwareInterface → aucune modification, delegation.
+4. `testThrowsBadRequestIfNoCurrentSite` : $data SiteAware + getSite() = null + provider retourne null → BadRequestHttpException 400.
+5. `testDelegatesToInnerAlways` : inner->process est appele dans tous les cas (sauf quand 400 throw).
+
+### Tests d'intégration (`KernelTestCase`)
+
+#### `SiteScopedQueryExtensionTest`
+
+Fixture : 2 sites (siteA, siteB), 3 FakeSiteAwareEntity (2 sur siteA, 1 sur siteB), 1 user rattache a siteA.
+
+1. `testCollectionFilteredByCurrentSite` : user avec currentSite=siteA → collection retourne 2 entites (celles de siteA).
+2. `testCollectionNotFilteredIfNoCurrentSite` : user sans currentSite → collection retourne 3 entites (no-op).
+3. `testCollectionNotFilteredIfResourceNotSiteAware` : query sur une entite non SiteAware → aucune clause additionnelle.
+4. `testCollectionNotFilteredIfBypassPermission` : user avec `sites.bypass_scope` → 3 entites.
+5. `testCollectionNotFilteredIfSitesModuleInactive` : desactiver SitesModule → provider null → no-op, 3 entites.
+6. `testItemNotFoundIfWrongSite` : GET sur un id dont le site est siteB alors que user sur siteA → 404 (ou `null` retourne par le QueryBuilder).
+7. `testItemFoundIfCorrectSite` : GET sur un id du site courant → 200.
+8. `testTotalItemsReflectsFilter` : collection Hydra `totalItems: 2` (et non 3) quand le filtre s'applique.
+
+### Tests de non-régression
+
+Apres implementation, **re-jouer toute la suite existante** en mode module Sites active et en mode module desactive. Aucun test existant ne doit changer.
+
+## 13. Ordre d'exécution recommandé
+
+1. **Contrat** — `SiteAwareInterface` dans `Shared/Domain/Contract/`.
+2. **Provider** — `CurrentSiteProvider` + tests unitaires.
+3. **Processor decorator** — `SiteAwareInjectionProcessor` + tests unitaires avec mocks.
+4. **Entite de test** — `FakeSiteAwareEntity` + mapping `when@test` si retenu.
+5. **Query extension** — `SiteScopedQueryExtension` + tests d'integration.
+6. **Permission bypass** — ajout dans `SitesModule::permissions()`, `make sync-permissions`, verifier en base.
+7. **Tests exhaustifs** — faire passer la matrice des 8 cas d'integration.
+8. **Tests non-regression** — `make test` avec SitesModule actif puis inactif.
+9. **Documentation** — rediger `docs/modules/site-aware.md` (5 sections).
+10. **CS fixer** — `make php-cs-fixer-allow-risky`.
+11. **DoD** — valider la check-list section 14.
+
+## 14. Critères d'acceptation (DoD)
+
+- [ ] `App\Shared\Domain\Contract\SiteAwareInterface` existe avec les deux methodes `getSite(): ?Site` et `setSite(Site $site): void`.
+- [ ] `CurrentSiteProvider::get()` retourne `null` dans les 3 cas : pas d'user, pas de currentSite, module inactif. Retourne le Site sinon.
+- [ ] `SiteScopedQueryExtension` applique le WHERE sur les resources SiteAware quand un site courant est resolu et que l'user n'a pas `sites.bypass_scope`.
+- [ ] `SiteAwareInjectionProcessor` injecte automatiquement le site courant sur POST/PATCH d'entites SiteAware sans site explicite.
+- [ ] `SiteAwareInjectionProcessor` leve une 400 si l'entite SiteAware n'a pas de site ET que le provider retourne null.
+- [ ] Permission `sites.bypass_scope` declaree dans `SitesModule::permissions()` et presente en base apres `app:sync-permissions`.
+- [ ] `docs/modules/site-aware.md` livre les 5 sections (quand/comment adopter, anti-patterns, degrade, gotchas).
+- [ ] Tests d'integration : au moins 8 cas couvrant filtrage collection/item, no-op dans les 3 scenarios (pas de site, resource non SiteAware, bypass), et `totalItems` Hydra.
+- [ ] Tests unitaires sur `CurrentSiteProvider` et `SiteAwareInjectionProcessor`.
+- [ ] Aucune migration sur des tables metier existantes (`supplier`, `client`, `user`, ...) — seules les migrations du ticket 1 et 2 sont presentes. Verifier via `make migration-migrate` : aucun SQL attendu sur la suite existante.
+- [ ] `make test` passe avec `SitesModule::class` actif dans `config/modules.php`.
+- [ ] `make test` passe avec `SitesModule::class` desactive dans `config/modules.php`.
+- [ ] `make php-cs-fixer-allow-risky` propre sur les fichiers nouveaux.
+- [ ] Aucun module metier (Commercial, Core hors User, etc.) n'a ete modifie par ce ticket — diff ne touche que `src/Shared/`, `src/Module/Sites/`, `tests/`, et `docs/`.

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/cahier-test-back-M1.md

@@ -0,0 +1,80 @@
+# 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 + RG-1.04
+fonctionnel) 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 | Onglet Information obligatoire pour rôle Commerciale | `ClientProcessorTest::testCommercialeIncompleteInformationIsUnprocessable` ; `::testNonCommercialeSkipsInformationCompleteness` (unit, dormant). **Test fonctionnel + durcissement → ERP-74** | 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** : PATCH onglet Information par une Commerciale avec
+  champs incomplets → 422 ; même PATCH par Admin → 200 (+ durcissement code/spec).
+- 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.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, 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>` | Conditionnel | RG-1.04 (obligatoire pour rôle Commerciale) |
+| **Concurrents** | `<MalioInputText>` | Conditionnel | RG-1.04 |
+| **Date de création** (de l'entreprise) | `<input type="date">` (exception Malio — pas de composant date couvert) | Conditionnel | RG-1.04 |
+| **Nombre de salariés** | `<MalioInputNumber>` | Conditionnel | RG-1.04 |
+| **CA €** | `<MalioInputAmount>` | Conditionnel | RG-1.04 |
+| **Dirigeant** | `<MalioInputText>` | Conditionnel | RG-1.04 |
+| **Résultat €** | `<MalioInputAmount>` | Conditionnel | RG-1.04 |
+
+**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).

frontend/app/layouts/default.vue

@@ -1,9 +1,17 @@
+<!--
+    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])
+      - bande blanche sticky sous la navbar : 47px (h-[47px])
+    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"/>
@@ -14,11 +22,12 @@
             </MalioSidebar>
 
             <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">
+                    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">
                     <div
                         aria-hidden="true"
-                        class="pointer-events-none sticky top-0 z-30 h-8 flex-shrink-0 bg-white sm:h-12"/>
+                        class="pointer-events-none sticky top-0 z-30 h-11 flex-shrink-0 bg-white"/>
                     <slot/>
                 </main>
             </div>
@@ -30,8 +39,21 @@
 const {t} = useI18n()
 const ui = useUiStore()
 const {sections} = useSidebar()
+const {isModuleActive} = useModules()
+const auth = useAuthStore()
 const route = useRoute()
 
+// Le SiteSelector est rendu si :
+//  - le module Sites est actif dans config/modules.php (sinon la feature
+//    n'a pas de sens, cf. ticket 3 spec criteres d'acceptation) ;
+//  - ET l'user connecte a au moins un site autorise (sinon "barre vide"
+//    sans tile cliquable).
+// Les deux flags sont resolus par le middleware auth.global.ts avant
+// que le layout ne soit rendu (plan load parallele), donc pas de flash.
+const showSiteSelector = computed(() =>
+    isModuleActive('sites') && (auth.user?.sites?.length ?? 0) > 0,
+)
+
 const translatedSections = computed(() =>
     sections.value.map(section => ({
         label: t(section.label),
@@ -48,6 +70,6 @@ watch(() => route.path, () => {
 })
 
 useHead({
-    titleTemplate: (title) => title || 'Coltura',
+    titleTemplate: (title) => title || 'Starseed',
 })
 </script>

frontend/app/middleware/auth.global.ts

@@ -15,9 +15,16 @@ export default defineNuxtRouteMiddleware(async (to) => {
     }
 
     if (auth.isAuthenticated) {
-        const { loaded, loadSidebar } = useSidebar()
-        if (!loaded.value) {
-            await loadSidebar()
-        }
+        const { loaded: sidebarLoaded, loadSidebar } = useSidebar()
+        const { loaded: modulesLoaded, loadModules } = useModules()
+
+        // Chargement parallele sidebar + modules actifs : les deux sont
+        // consommes par layouts/default.vue (sidebar pour la nav, modules
+        // pour conditionner le SiteSelector). Charger en parallele evite
+        // le flash au premier paint de la barre.
+        await Promise.all([
+            sidebarLoaded.value ? Promise.resolve() : loadSidebar(),
+            modulesLoaded.value ? Promise.resolve() : loadModules(),
+        ])
     }
 })

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,27 +10,202 @@
         "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"
+        },
+        "core": {
+            "roles": "Gestion des rôles",
+            "users": "Utilisateurs",
+            "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",
+        "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",
+                "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",
+                    "categories": "Catégorie",
+                    "country": "Pays",
+                    "postalCode": "Code postal",
+                    "city": "Ville",
+                    "street": "Adresse",
+                    "streetComplement": "Adresse complémentaire",
+                    "sites": "Sites Starseed",
+                    "contacts": "Contact(s) rattaché(s)",
+                    "billingEmail": "Email de facturation",
+                    "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"
+                }
+            }
+        }
     },
     "auth": {
         "login": "Connexion",
@@ -50,11 +225,211 @@
             "put": "Erreur lors de la mise a jour",
             "patch": "Erreur lors de la modification",
             "delete": "Erreur lors de la suppression"
+        },
+        "sites": {
+            "notAuthorized": "Vous n'êtes pas autorisé à sélectionner ce site."
         }
     },
+    "sites": {
+        "selector": {
+            "ariaGroupLabel": "Sélecteur de site actif",
+            "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"
+        },
+        "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"
         }
+    },
+    "admin": {
+        "roles": {
+            "title": "Gestion des rôles",
+            "newRole": "Nouveau rôle",
+            "editRole": "Modifier le rôle",
+            "createRole": "Créer un rôle",
+            "noRoles": "Aucun rôle configuré",
+            "table": {
+                "label": "Libellé",
+                "code": "Code",
+                "permissions": "Permissions",
+                "system": "Système"
+            },
+            "form": {
+                "label": "Libellé",
+                "code": "Code",
+                "description": "Description",
+                "permissions": "Permissions"
+            },
+            "delete": {
+                "title": "Supprimer le rôle",
+                "message": "Êtes-vous sûr de vouloir supprimer le rôle \"{label}\" ? Cette action est irréversible.",
+                "systemTooltip": "Rôle système non supprimable"
+            },
+            "toast": {
+                "created": "Rôle créé avec succès",
+                "updated": "Rôle mis à jour avec succès",
+                "deleted": "Rôle supprimé avec succès"
+            },
+            "permissions": {
+                "selectAll": "Tout selectionner",
+                "noPermissions": "Aucune permission disponible",
+                "loadFailed": "Impossible de charger le catalogue de permissions. L'enregistrement est désactivé pour éviter tout écrasement accidentel."
+            }
+        },
+        "users": {
+            "title": "Gestion des utilisateurs",
+            "noUsers": "Aucun utilisateur",
+            "table": {
+                "username": "Nom d'utilisateur",
+                "admin": "Administrateur",
+                "roles": "Roles",
+                "directPermissions": "Permissions directes",
+                "sites": "Sites"
+            },
+            "drawer": {
+                "title": "Permissions de {username}",
+                "selfWarning": "Vous modifiez vos propres droits",
+                "adminToggle": "Administrateur (bypass total)",
+                "rolesSection": "Rôles",
+                "directPermissionsSection": "Permissions directes",
+                "sitesSection": "Sites autorisés",
+                "summarySection": "Résumé des permissions effectives",
+                "noEffectivePermissions": "Aucune permission effective",
+                "sourceRole": "via {role}",
+                "sourceDirect": "Direct",
+                "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",
+            "editSite": "Modifier le site",
+            "createSite": "Créer un site",
+            "noSites": "Aucun site configuré",
+            "table": {
+                "name": "Nom",
+                "city": "Ville",
+                "postalCode": "Code postal",
+                "color": "Couleur",
+                "fullAddress": "Adresse complète"
+            },
+            "form": {
+                "name": "Nom",
+                "street": "Rue",
+                "complement": "Complément d'adresse",
+                "complementPlaceholder": "Bâtiment, escalier, BP... (optionnel)",
+                "postalCode": "Code postal",
+                "city": "Ville",
+                "color": "Couleur (format #RRGGBB)",
+                "colorInvalid": "Format attendu : #RRGGBB (6 caractères hexadécimaux)"
+            },
+            "delete": {
+                "title": "Supprimer le site",
+                "message": "Êtes-vous sûr de vouloir supprimer le site \"{name}\" ? Cette action est irréversible et retirera ce site à tous les utilisateurs rattachés."
+            },
+            "toast": {
+                "created": "Site créé avec succès",
+                "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",
+            "viewCategory": "Détail de la catégorie",
+            "noCategories": "Aucune catégorie pour l'instant.",
+            "table": {
+                "name": "Nom",
+                "type": "Type"
+            },
+            "form": {
+                "name": "Nom",
+                "type": "Type de catégorie",
+                "typePlaceholder": "Sélectionner un type"
+            },
+            "validation": {
+                "nameRequired": "Le nom est obligatoire.",
+                "nameLength": "Le nom doit faire entre 2 et 120 caractères.",
+                "typeRequired": "Le type de catégorie est obligatoire."
+            },
+            "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à pour ce type.",
+                "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,178 @@
+<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.value.name"
+                required
+            />
+
+            <!-- Type (RG-1.05 obligatoire). MalioSelect porte la valeur en
+                 number (categoryType id) ; conversion en IRI au moment du save
+                 par le composable useCategoryForm. -->
+            <MalioSelect
+                v-model="form.categoryTypeId.value"
+                :options="typeOptions"
+                :label="t('admin.categories.form.type')"
+                :empty-option-label="t('admin.categories.form.typePlaceholder')"
+                :error="form.errors.value.categoryType"
+                :disabled="loadingTypes"
+            />
+
+            <!-- Erreur transverse (typiquement reseau / 5xx) — separe des
+                 erreurs de validation par champ. -->
+            <p v-if="form.errors.value._global" class="text-sm text-red-600">
+                {{ form.errors.value._global }}
+            </p>
+        </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 (dérivé du composable `useCategoryForm`) :
+ *  - 'create' : pas de category prop, formulaire vide, POST au save.
+ *  - 'view'   : category prop set, formulaire pre-rempli, save MASQUE
+ *               jusqu'a ce que l'utilisateur modifie un champ.
+ *  - 'edit'   : category prop set et formulaire « dirty » (au moins un
+ *               champ different de l'original), PATCH au save.
+ */
+type DrawerMode = 'create' | 'view' | 'edit'
+
+const isCreateMode = computed(() => props.category === null)
+
+const mode = computed<DrawerMode>(() => {
+    if (isCreateMode.value) return 'create'
+    return form.isDirty.value ? 'edit' : 'view'
+})
+
+const headerLabel = computed(() => {
+    if (mode.value === 'create') return t('admin.categories.createCategory')
+    if (mode.value === 'edit') return t('admin.categories.editCategory')
+    return t('admin.categories.viewCategory')
+})
+
+// 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, ou en edition (apres modification d'un champ).
+// Masque en view tant que rien n'a change.
+const canShowSave = computed(
+    () => mode.value === 'create' || mode.value === 'edit',
+)
+
+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 mode create, PATCH en mode
+ * edit). Le toast succes + mapping erreur 409/422 est gere par le composable.
+ * En cas de succes, on ferme le drawer et on previent le parent pour qu'il
+ * refresh la liste.
+ */
+async function handleSave(): Promise<void> {
+    let result: Category | null = null
+    if (mode.value === 'create') {
+        result = await form.submitCreate()
+    } else if (mode.value === 'edit' && props.category) {
+        result = await form.submitUpdate(props.category.id)
+    }
+    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,454 @@
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+import type { Category, CategoryType } from '~/modules/catalog/types/category'
+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,
+}))
+// 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',
+    categoryType: 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', () => {
+            const form = useCategoryForm()
+
+            form.loadFrom(CAT)
+
+            expect(form.name.value).toBe('Vis')
+            expect(form.categoryTypeId.value).toBe(1)
+            expect(form.errors.value).toEqual({ name: '', categoryType: '', _global: '' })
+        })
+
+        it('vide le formulaire en mode creation (null)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'old'
+            form.categoryTypeId.value = 99
+
+            form.loadFrom(null)
+
+            expect(form.name.value).toBe('')
+            expect(form.categoryTypeId.value).toBeNull()
+        })
+
+        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)
+        })
+    })
+
+    describe('validate', () => {
+        it('signale une erreur si name est vide (RG-1.02)', () => {
+            const form = useCategoryForm()
+            form.name.value = ''
+            form.categoryTypeId.value = 1
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.value.name).toBe('admin.categories.validation.nameRequired')
+        })
+
+        it('signale erreur si name est whitespace-only (trim → vide)', () => {
+            const form = useCategoryForm()
+            form.name.value = '   '
+            form.categoryTypeId.value = 1
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.value.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.categoryTypeId.value = 1
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.value.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.categoryTypeId.value = 1
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.value.name).toBe('admin.categories.validation.nameLength')
+        })
+
+        it('signale erreur si categoryTypeId est null (RG-1.05)', () => {
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeId.value = null
+
+            const ok = form.validate()
+
+            expect(ok).toBe(false)
+            expect(form.errors.value.categoryType).toBe('admin.categories.validation.typeRequired')
+        })
+
+        it('passe quand name et categoryType sont valides', () => {
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeId.value = 1
+
+            const ok = form.validate()
+
+            expect(ok).toBe(true)
+            expect(form.errors.value).toEqual({ name: '', categoryType: '', _global: '' })
+        })
+
+        it('reinitialise les erreurs avant chaque validation', () => {
+            const form = useCategoryForm()
+            // Erreur prealable.
+            form.errors.value._global = 'erreur ancienne'
+            form.name.value = 'Vis'
+            form.categoryTypeId.value = 1
+
+            form.validate()
+
+            expect(form.errors.value._global).toBe('')
+        })
+    })
+
+    describe('submitCreate', () => {
+        it('appelle POST /categories avec body { name trimme, categoryType en IRI }', async () => {
+            mockPost.mockResolvedValueOnce(CAT)
+            const form = useCategoryForm()
+            form.name.value = '  Vis  '
+            form.categoryTypeId.value = 1
+
+            const result = await form.submitCreate()
+
+            expect(mockPost).toHaveBeenCalledWith(
+                '/categories',
+                { name: 'Vis', categoryType: '/api/category_types/1' },
+                { 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.categoryTypeId.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.categoryTypeId.value = 1
+
+            await form.submitCreate()
+
+            expect(mockToastSuccess).toHaveBeenCalledWith({
+                title: 'Succès',
+                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.categoryTypeId.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.value.name).toContain('admin.categories.toast.duplicate')
+            expect(form.errors.value.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.categoryTypeId.value = 1
+
+            const result = await form.submitCreate()
+
+            expect(result).toBeNull()
+            expect(form.errors.value.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 aussi hydra:violations (negociation de format alternative)', async () => {
+            mockPost.mockRejectedValueOnce({
+                response: {
+                    status: 422,
+                    _data: {
+                        'hydra:violations': [
+                            { propertyPath: 'categoryType', message: 'Type invalide.' },
+                        ],
+                    },
+                },
+            })
+            const form = useCategoryForm()
+            form.name.value = 'Vis'
+            form.categoryTypeId.value = 1
+
+            await form.submitCreate()
+
+            expect(form.errors.value.categoryType).toBe('Type invalide.')
+        })
+
+        it('fallback en erreur globale + toast 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.categoryTypeId.value = 1
+
+            await form.submitCreate()
+
+            expect(form.errors.value._global).toBe('Boom server')
+            expect(mockToastError).toHaveBeenCalledWith({
+                title: 'Erreur',
+                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.categoryTypeId.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} uniquement avec les champs modifies', async () => {
+            mockPatch.mockResolvedValueOnce({ ...CAT, name: 'Vis V2' })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = 'Vis V2' // categoryTypeId inchange
+
+            await form.submitUpdate(42)
+
+            expect(mockPatch).toHaveBeenCalledWith(
+                '/categories/42',
+                { name: 'Vis V2' }, // pas de categoryType car non modifie
+                { toast: false },
+            )
+        })
+
+        it('envoie categoryType en IRI quand seul le type a change', async () => {
+            mockPatch.mockResolvedValueOnce({ ...CAT, categoryType: TYPE_ACHAT })
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.categoryTypeId.value = 2
+
+            await form.submitUpdate(42)
+
+            expect(mockPatch).toHaveBeenCalledWith(
+                '/categories/42',
+                { categoryType: '/api/category_types/2' },
+                { toast: false },
+            )
+        })
+
+        it('court-circuite l appel API si aucun champ n a change', async () => {
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            // Aucune modification — isDirty=false, patch payload vide.
+
+            const result = await form.submitUpdate(42)
+
+            expect(mockPatch).not.toHaveBeenCalled()
+            expect(result).toBeNull()
+            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: 'Succès',
+                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.value.name).toContain('admin.categories.toast.duplicate')
+            expect(form.errors.value.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: 'Succès',
+                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(form.errors.value._global).toBe('down')
+            expect(mockToastError).toHaveBeenCalled()
+        })
+    })
+
+    describe('reset', () => {
+        it('vide le formulaire et les erreurs', () => {
+            const form = useCategoryForm()
+            form.loadFrom(CAT)
+            form.name.value = 'edit'
+            form.errors.value._global = 'erreur'
+            form.submitting.value = true
+
+            form.reset()
+
+            expect(form.name.value).toBe('')
+            expect(form.categoryTypeId.value).toBeNull()
+            expect(form.errors.value).toEqual({ name: '', categoryType: '', _global: '' })
+            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,319 @@
+/**
+ * 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).
+ *
+ * Mapping erreurs API :
+ *   - 409 (RG-1.07 doublon) → toast + erreur sur le champ `name`
+ *   - 422 (violations API Platform) → mapping sur les champs concernes
+ *   - autre → erreur globale `_global` + toast generique
+ */
+import { computed, ref } from 'vue'
+import type { Category } from '~/modules/catalog/types/category'
+import { extractApiErrorMessage, extractApiViolations } from '~/shared/utils/api'
+
+/**
+ * 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()
+
+    // 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 categoryTypeId = ref<number | null>(null)
+
+    // 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 initialCategoryTypeId = ref<number | null>(null)
+
+    const errors = ref<{
+        name: string
+        categoryType: string
+        _global: string
+    }>({
+        name: '',
+        categoryType: '',
+        _global: '',
+    })
+
+    const submitting = ref(false)
+
+    const isDirty = computed(
+        () =>
+            name.value !== initialName.value
+            || categoryTypeId.value !== initialCategoryTypeId.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 {
+        errors.value = { name: '', categoryType: '', _global: '' }
+        if (category) {
+            name.value = category.name
+            categoryTypeId.value = category.categoryType.id
+            initialName.value = category.name
+            initialCategoryTypeId.value = category.categoryType.id
+        } else {
+            name.value = ''
+            categoryTypeId.value = null
+            initialName.value = ''
+            initialCategoryTypeId.value = null
+        }
+    }
+
+    /**
+     * 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 {
+        errors.value = { name: '', categoryType: '', _global: '' }
+        const trimmedName = name.value.trim()
+
+        // RG-1.02 — name obligatoire (vide / whitespace-only).
+        if (trimmedName === '') {
+            errors.value.name = t('admin.categories.validation.nameRequired')
+        } else if (trimmedName.length < 2 || trimmedName.length > 120) {
+            // RG-1.04 — longueur 2-120 apres trim.
+            errors.value.name = t('admin.categories.validation.nameLength')
+        }
+
+        // RG-1.05 — categoryType obligatoire.
+        if (categoryTypeId.value === null) {
+            errors.value.categoryType = t('admin.categories.validation.typeRequired')
+        }
+
+        return errors.value.name === '' && errors.value.categoryType === ''
+    }
+
+    /**
+     * Construit le payload POST a partir du state. Le `categoryType` est
+     * envoye en IRI Hydra (`/api/category_types/{id}`) — convention API
+     * Platform pour referencer une ressource liee. Retourne un object literal
+     * compatible avec `AnyObject` de `useApi()` (un type nomme strict comme
+     * `CategoryCreateInput` ne serait pas assignable a `Record<string, unknown>`
+     * en TS strict).
+     */
+    function buildCreatePayload(): Record<string, unknown> {
+        return {
+            name: name.value.trim(),
+            categoryType: `/api/category_types/${categoryTypeId.value}`,
+        }
+    }
+
+    /**
+     * Mappe les violations 422 d'API Platform sur les champs du formulaire.
+     * Renvoie true des qu'au moins une violation a ete posee — false sinon
+     * (payload sans violations exploitables, ou tous les `propertyPath` hors
+     * du mapping connu). L'extraction Hydra (`violations` / `hydra:violations`)
+     * est centralisee dans `shared/utils/api.ts` pour rester reutilisable
+     * sur les futurs drawers de formulaire.
+     */
+    function mapServerViolations(data: unknown): boolean {
+        const violations = extractApiViolations(data)
+        if (violations.length === 0) return false
+        let mapped = false
+        for (const v of violations) {
+            if (v.propertyPath === 'name') {
+                errors.value.name = v.message
+                mapped = true
+            } else if (v.propertyPath === 'categoryType') {
+                errors.value.categoryType = v.message
+                mapped = true
+            }
+        }
+        return mapped
+    }
+
+    /**
+     * Traite une erreur API : mappe selon le status, declenche les toasts
+     * appropries. Centralise la logique entre create/update.
+     *
+     * - 409 (RG-1.07) : doublon — toast + errors.name avec libelle qui inclut
+     *   le nom soumis.
+     * - 422 : tentative de mapping fin via les violations API Platform — si au
+     *   moins une violation est mappee, pas de toast (erreur affichee inline
+     *   sous le champ concerne).
+     * - autre : message global + toast generique. Le toast natif d'useApi
+     *   est desactive (`toast: false`) pour permettre ce mapping fin ; il faut
+     *   donc en re-emettre un manuellement ici, sinon une 500 reste silencieuse.
+     *
+     * Retourne true si l'erreur a ete reconnue et traitee (409/422 mappes),
+     * false sinon (fallback generique).
+     */
+    function handleApiError(e: unknown, attemptedName: string): boolean {
+        const status = (e as ApiFetchError)?.response?.status
+        const data = (e as ApiFetchError)?.response?._data
+
+        if (status === 409) {
+            const duplicateMessage = t('admin.categories.toast.duplicate', {
+                name: attemptedName,
+            })
+            errors.value.name = duplicateMessage
+            toast.error({
+                title: 'Erreur',
+                message: duplicateMessage,
+            })
+            return true
+        }
+
+        if (status === 422 && mapServerViolations(data)) {
+            return true
+        }
+
+        const extracted = extractApiErrorMessage(data)
+        errors.value._global = extracted || 'Une erreur est survenue.'
+        toast.error({
+            title: 'Erreur',
+            message: errors.value._global,
+        })
+        return false
+    }
+
+    /**
+     * 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
+        errors.value._global = ''
+        const payload = buildCreatePayload()
+        try {
+            const created = await api.post<Category>('/categories', payload, {
+                toast: false,
+            })
+            toast.success({
+                title: 'Succès',
+                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 uniquement les champs modifies pour
+     * coller a la semantique merge-patch (Content-Type pose par useApi).
+     * 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
+        errors.value._global = ''
+        const payload: Record<string, unknown> = {}
+        if (name.value !== initialName.value) {
+            payload.name = name.value.trim()
+        }
+        if (categoryTypeId.value !== initialCategoryTypeId.value) {
+            payload.categoryType = `/api/category_types/${categoryTypeId.value}`
+        }
+        // Garde-fou : un PATCH sans changement ne sert a rien. Theoriquement
+        // empeche par le drawer (bouton Enregistrer masque si !isDirty) mais
+        // on protege le composable contre un appel direct mal utilise.
+        if (Object.keys(payload).length === 0) {
+            submitting.value = false
+            return null
+        }
+        try {
+            const updated = await api.patch<Category>(`/categories/${id}`, payload, {
+                toast: false,
+            })
+            toast.success({
+                title: 'Succès',
+                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
+        errors.value._global = ''
+        try {
+            await api.delete(`/categories/${id}`, {}, { toast: false })
+            toast.success({
+                title: 'Succès',
+                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 = ''
+        categoryTypeId.value = null
+        initialName.value = ''
+        initialCategoryTypeId.value = null
+        errors.value = { name: '', categoryType: '', _global: '' }
+        submitting.value = false
+    }
+
+    return {
+        // State
+        name,
+        categoryTypeId,
+        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,158 @@
+<template>
+    <div>
+        <PageHeader>
+            {{ t('admin.categories.title') }}
+            <template #actions>
+                <MalioButton
+                    v-if="canManage"
+                    :label="t('admin.categories.newCategory')"
+                    icon-name="mdi:add-bold"
+                    icon-position="left"
+                    @click="openCreateDrawer"
+                />
+            </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"
+        />
+    </div>
+</template>
+
+<script setup lang="ts">
+import type { Category } from '~/modules/catalog/types/category'
+
+const { t } = useI18n()
+const { can } = usePermissions()
+const { 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,
+} = 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. Le type est embarque cote API (cf. spec-back § 3.4) —
+// on aplatit en label lisible pour l'affichage.
+const columns = [
+    { key: 'name', label: t('admin.categories.table.name') },
+    { key: 'typeLabel', label: t('admin.categories.table.type') },
+]
+
+const categoryItems = computed(() =>
+    categories.value.map(cat => ({
+        id: cat.id,
+        name: cat.name,
+        typeLabel: cat.categoryType?.label ?? '',
+    })),
+)
+
+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,71 @@
+/**
+ * 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, categoryType: IRI }
+ *   - PATCH /api/categories/{id}   → body partiel { name?, categoryType?: 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").
+ *   - `categoryType` est embarque (groupe Serializer `category:read` sur les
+ *     proprietes de CategoryType, cf. spec-back § 3.4).
+ *   - `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
+    categoryType: 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. `categoryType` est envoye en
+ * IRI Hydra (ex. `/api/category_types/3`).
+ */
+export interface CategoryCreateInput {
+    name: string
+    categoryType: string
+}
+
+/**
+ * Payload accepte en PATCH /api/categories/{id}. Tous les champs sont
+ * optionnels (modification partielle).
+ */
+export interface CategoryUpdateInput {
+    name?: string
+    categoryType?: string
+}

frontend/modules/commercial/components/ClientAddressBlock.vue

@@ -0,0 +1,328 @@
+<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 : Prospect exclusif de Livraison/Facturation
+             (RG-1.06/07/08). L'exclusivite est appliquee au toggle (cocher l'un
+             decoche l'autre) plutot qu'en masquant les options. -->
+        <MalioCheckbox
+            :model-value="model.isProspect"
+            :label="t('commercial.clients.form.address.prospect')"
+            group-class="self-center"
+            :readonly="readonly"
+            @update:model-value="(v: boolean) => toggleFlag('isProspect', v)"
+        />
+        <MalioCheckbox
+            :model-value="model.isDelivery"
+            :label="t('commercial.clients.form.address.delivery')"
+            group-class="self-center"
+            :readonly="readonly"
+            @update:model-value="(v: boolean) => toggleFlag('isDelivery', v)"
+        />
+        <MalioCheckbox
+            :model-value="model.isBilling"
+            :label="t('commercial.clients.form.address.billing')"
+            group-class="self-center"
+            :readonly="readonly"
+            @update:model-value="(v: boolean) => toggleFlag('isBilling', v)"
+        />
+
+        <!-- Cellule vide : laisse un trou en position 4 (ligne 1) pour que
+             Categorie reparte au debut de la ligne suivante. -->
+        <div aria-hidden="true" />
+
+        <MalioSelectCheckbox
+            :model-value="model.categoryIris"
+            :options="categoryOptions"
+            :label="t('commercial.clients.form.address.categories')"
+            :display-tag="true"
+            :disabled="readonly"
+            @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')"
+            :disabled="readonly"
+            @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"
+            @update:model-value="onPostalCodeChange"
+        />
+
+        <!-- Ville : MalioSelect alimente par le code postal (BAN). En mode
+             degrade (service indisponible), bascule en saisie libre. -->
+        <MalioSelect
+            v-if="!degraded"
+            :model-value="model.city"
+            :options="cityOptions"
+            :label="t('commercial.clients.form.address.city')"
+            :disabled="readonly"
+            empty-option-label=""
+            @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"
+            @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 en
+                 mode degrade OU en lecture seule (MalioInputAutocomplete ne reaffiche
+                 pas sa valeur liee, il n'afficherait rien en readonly). -->
+            <MalioInputAutocomplete
+                v-if="!degraded && !readonly"
+                :model-value="model.street"
+                :options="addressOptions"
+                :loading="addressLoading"
+                :min-search-length="3"
+                :label="t('commercial.clients.form.address.street')"
+                :readonly="readonly"
+                @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"
+                @update:model-value="(v: string) => update('street', v)"
+            />
+        </div>
+
+        <div class="col-span-2">
+            <MalioInputText
+                :model-value="model.streetComplement"
+                :label="t('commercial.clients.form.address.streetComplement')"
+                :readonly="readonly"
+                @update:model-value="(v: string) => update('streetComplement', v)"
+            />
+        </div>
+
+        <!-- Sites Starseed : cases a cocher inline (>= 1 obligatoire, RG-1.10). -->
+        <div class="flex justify-between">
+            <MalioCheckbox
+                v-for="site in siteOptions"
+                :key="site.value"
+                :model-value="model.siteIris.includes(site.value)"
+                :label="site.label"
+                group-class="w-auto self-center"
+                :readonly="readonly"
+                @update:model-value="(v: boolean) => toggleSite(site.value, v)"
+            />
+        </div>
+
+        <MalioSelectCheckbox
+            :model-value="model.contactIris"
+            :options="contactOptions"
+            :label="t('commercial.clients.form.address.contacts')"
+            :display-tag="true"
+            :disabled="readonly"
+            @update:model-value="(v: (string | number)[]) => update('contactIris', v.map(String))"
+        />
+
+        <!-- Email de facturation : visible/obligatoire seulement si Facturation
+             est coche (RG-1.11). -->
+        <MalioInputText
+            v-if="isBillingEmailRequired(model)"
+            :model-value="model.billingEmail"
+            :label="t('commercial.clients.form.address.billingEmail')"
+            :required="true"
+            :readonly="readonly"
+            @update:model-value="(v: string) => update('billingEmail', v)"
+        />
+    </div>
+</template>
+
+<script setup lang="ts">
+import {
+    applyProspectExclusivity,
+    isBillingEmailRequired,
+    type AddressFlagsDraft,
+} from '~/modules/commercial/utils/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
+}>()
+
+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)
+
+// Mode degrade : service BAN indisponible → Ville/Adresse en saisie libre.
+const degraded = ref(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 })
+}
+
+/** Coche/decoche un site Starseed rattache a l'adresse (M2M par IRI, RG-1.10). */
+function toggleSite(siteIri: string, selected: boolean): void {
+    const current = props.modelValue.siteIris
+    const next = selected
+        ? [...current, siteIri]
+        : current.filter(iri => iri !== siteIri)
+    update('siteIris', next)
+}
+
+/** Applique l'exclusivite Prospect / (Livraison|Facturation) au changement. */
+function toggleFlag(field: keyof AddressFlagsDraft, value: boolean): void {
+    const flags = applyProspectExclusivity(
+        { isProspect: model.value.isProspect, isDelivery: model.value.isDelivery, isBilling: model.value.isBilling },
+        field,
+        value,
+    )
+    emit('update:modelValue', { ...props.modelValue, ...flags })
+}
+
+/** Bascule définitivement en mode degrade et previent le parent (toast unique). */
+function enterDegraded(): void {
+    if (!degraded.value) {
+        degraded.value = 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)
+
+    if (degraded.value) {
+        return
+    }
+    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 }))
+    }
+    catch {
+        enterDegraded()
+    }
+}
+
+/** Recherche d'adresse assistee (event de MalioInputAutocomplete). */
+async function onAddressSearch(query: string): Promise<void> {
+    if (degraded.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 {
+        enterDegraded()
+    }
+    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,97 @@
+<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"
+            @update:model-value="(v: string) => update('lastName', v)"
+        />
+        <MalioInputText
+            :model-value="model.firstName"
+            :label="t('commercial.clients.form.contact.firstName')"
+            :readonly="readonly"
+            @update:model-value="(v: string) => update('firstName', v)"
+        />
+        <MalioInputText
+            :model-value="model.jobTitle"
+            :label="t('commercial.clients.form.contact.jobTitle')"
+            :readonly="readonly"
+            @update:model-value="(v: string) => update('jobTitle', v)"
+        />
+        <MalioInputEmail
+            :model-value="model.email"
+            :label="t('commercial.clients.form.contact.email')"
+            :readonly="readonly"
+            @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"
+            :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"
+            @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
+}>()
+
+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/__tests__/ClientAddressBlock.spec.ts

@@ -0,0 +1,76 @@
+import { describe, it, expect, vi } from 'vitest'
+import { mount } from '@vue/test-utils'
+import { defineComponent, h, ref, computed } from 'vue'
+import { emptyAddress } from '~/modules/commercial/types/clientForm'
+import ClientAddressBlock from '../ClientAddressBlock.vue'
+
+// Le composable BAN est mocke : aucun appel reseau, aucune suggestion chargee.
+// On reproduit ainsi l'etat « adresse persistee, mais liste de suggestions
+// vide » (remontage apres validation / edition d'une adresse existante).
+vi.mock('~/shared/composables/useAddressAutocomplete', () => ({
+    useAddressAutocomplete: () => ({
+        searchCity: vi.fn(),
+        searchAddress: vi.fn(),
+    }),
+}))
+
+// Auto-imports Nuxt/Vue utilises sans import explicite par le composant.
+vi.stubGlobal('useI18n', () => ({ t: (key: string) => key }))
+vi.stubGlobal('ref', ref)
+vi.stubGlobal('computed', computed)
+
+// Stub de MalioInputAutocomplete : expose les `value` des options recues, pour
+// verifier que la rue courante figure bien dans la liste (sinon le composant
+// Malio ne peut pas resoudre/afficher la valeur liee -> champ vide).
+const MalioInputAutocompleteStub = defineComponent({
+    name: 'MalioInputAutocomplete',
+    props: {
+        modelValue: { type: [String, Number, null], default: undefined },
+        options: { type: Array as () => { value: string | number, label: string }[], default: () => [] },
+        loading: { type: Boolean, default: false },
+        minSearchLength: { type: Number, default: 0 },
+        label: { type: String, default: '' },
+        readonly: { type: Boolean, default: false },
+    },
+    emits: ['update:modelValue', 'search', 'select'],
+    setup(props) {
+        return () => h('div', {
+            'data-testid': 'addr-autocomplete',
+            'data-options': JSON.stringify(props.options.map(o => o.value)),
+        })
+    },
+})
+
+function mountBlock(street: string | null) {
+    return mount(ClientAddressBlock, {
+        props: {
+            modelValue: { ...emptyAddress(), street },
+            title: 'Adresse',
+            categoryOptions: [],
+            siteOptions: [],
+            contactOptions: [],
+            countryOptions: [],
+        },
+        global: {
+            stubs: {
+                MalioButtonIcon: true,
+                MalioCheckbox: true,
+                MalioSelect: true,
+                MalioSelectCheckbox: true,
+                MalioInputText: true,
+                MalioInputAutocomplete: MalioInputAutocompleteStub,
+            },
+        },
+    })
+}
+
+describe('ClientAddressBlock — affichage de l\'adresse persistee', () => {
+    it('inclut la rue courante dans les options de l\'autocomplete meme sans recherche BAN', () => {
+        const wrapper = mountBlock('8 Boulevard du Port')
+
+        const el = wrapper.find('[data-testid="addr-autocomplete"]')
+        const values = JSON.parse(el.attributes('data-options') ?? '[]')
+
+        expect(values).toContain('8 Boulevard du Port')
+    })
+})

frontend/modules/commercial/composables/__tests__/useClient.spec.ts

@@ -0,0 +1,95 @@
+import { beforeEach, describe, expect, it, vi } from 'vitest'
+
+// Mocks des composables auto-importes par Nuxt (indisponibles sous happy-dom).
+const mockGet = vi.hoisted(() => vi.fn())
+const mockPatch = vi.hoisted(() => vi.fn())
+
+vi.stubGlobal('useApi', () => ({
+    get: mockGet,
+    post: vi.fn(),
+    put: vi.fn(),
+    patch: mockPatch,
+    delete: vi.fn(),
+}))
+
+const { useClient } = await import('../useClient')
+
+const SAMPLE = { '@id': '/api/clients/42', id: 42, companyName: 'ACME', isArchived: false }
+
+describe('useClient', () => {
+    beforeEach(() => {
+        mockGet.mockReset()
+        mockPatch.mockReset()
+        mockGet.mockResolvedValue(SAMPLE)
+        mockPatch.mockResolvedValue({ ...SAMPLE, isArchived: true })
+    })
+
+    it('charge le detail via GET /clients/{id} en Hydra, sans toast', async () => {
+        const { client, load } = useClient(42)
+        await load()
+
+        expect(mockGet).toHaveBeenCalledWith(
+            '/clients/42',
+            {},
+            expect.objectContaining({
+                headers: { Accept: 'application/ld+json' },
+                toast: false,
+            }),
+        )
+        expect(client.value).toEqual(SAMPLE)
+    })
+
+    it('bascule loading pendant le chargement et le retombe a false', async () => {
+        const { loading, load } = useClient(42)
+        const promise = load()
+        expect(loading.value).toBe(true)
+        await promise
+        expect(loading.value).toBe(false)
+    })
+
+    it('marque error et laisse client null si le GET echoue (404...)', async () => {
+        mockGet.mockRejectedValueOnce(new Error('not found'))
+        const { client, error, load } = useClient(99)
+        await load()
+        expect(error.value).toBe(true)
+        expect(client.value).toBeNull()
+    })
+
+    it('archive() PATCHe { isArchived: true } sans toast puis RECHARGE le detail complet', async () => {
+        // 1er GET = chargement initial, 2e GET = rechargement post-archivage.
+        mockGet.mockResolvedValueOnce(SAMPLE)
+        mockGet.mockResolvedValueOnce({ ...SAMPLE, isArchived: true })
+        const { client, load, archive } = useClient(42)
+        await load()
+        await archive()
+
+        expect(mockPatch).toHaveBeenCalledWith(
+            '/clients/42',
+            { isArchived: true },
+            expect.objectContaining({ toast: false }),
+        )
+        // Le detail est re-fetch (le PATCH ne renvoie pas l'embed complet).
+        expect(mockGet).toHaveBeenCalledTimes(2)
+        expect(client.value?.isArchived).toBe(true)
+    })
+
+    it('restore() PATCHe { isArchived: false } (payload isArchived SEUL)', async () => {
+        const { load, restore } = useClient(42)
+        await load()
+        await restore()
+
+        expect(mockPatch).toHaveBeenCalledWith(
+            '/clients/42',
+            { isArchived: false },
+            expect.objectContaining({ toast: false }),
+        )
+    })
+
+    it('propage l\'erreur (ex: 409 conflit homonyme RG-1.23) au lieu de l\'avaler', async () => {
+        const conflict = { response: { status: 409 } }
+        mockPatch.mockRejectedValueOnce(conflict)
+        const { load, restore } = useClient(42)
+        await load()
+        await expect(restore()).rejects.toBe(conflict)
+    })
+})

frontend/modules/commercial/composables/__tests__/useClientReferentials.spec.ts

@@ -0,0 +1,74 @@
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+
+// `useApi` est un auto-import Nuxt : on le stubbe globalement pour intercepter
+// les appels de chargement des referentiels et simuler un endpoint en echec
+// (ex: 403 sur /categories pour un role sans la permission de lecture).
+// Meme pattern que useClientsRepository.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 le stub pour que useApi soit bien resolu au top-level du module.
+const { useClientReferentials } = await import('../useClientReferentials')
+
+describe('useClientReferentials.loadCommon (resilience ERP-102)', () => {
+    beforeEach(() => {
+        mockGet.mockReset()
+    })
+
+    it('un referentiel en echec (403) ne vide QUE son select, pas les autres', async () => {
+        // /categories rejette (simulateur d'un 403), tous les autres repondent.
+        mockGet.mockImplementation((url: string) => {
+            if (url === '/categories') {
+                return Promise.reject(new Error('403 Forbidden'))
+            }
+            if (url === '/sites') {
+                return Promise.resolve({ member: [{ '@id': '/api/sites/1', name: 'Chatellerault', postalCode: '86100' }] })
+            }
+            return Promise.resolve({
+                member: [{ '@id': '/api/x/1', code: 'X', label: 'Libelle X' }],
+            })
+        })
+
+        const refs = useClientReferentials()
+        // loadCommon ne doit JAMAIS rejeter : l'echec d'un referentiel est isole.
+        await refs.loadCommon()
+
+        // Resilience : les referentiels OK sont peuples malgre l'echec de /categories.
+        // Le libelle d'un site est son numero de departement (2 premiers chiffres du code postal).
+        expect(refs.sites.value).toEqual([{ value: '/api/sites/1', label: '86' }])
+        expect(refs.tvaModes.value).toEqual([{ value: '/api/x/1', label: 'Libelle X' }])
+        expect(refs.banks.value).toEqual([{ value: '/api/x/1', label: 'Libelle X' }])
+
+        // Seul le select en echec reste vide.
+        expect(refs.categories.value).toEqual([])
+    })
+
+    it('charge tous les referentiels quand tout repond', async () => {
+        mockGet.mockImplementation((url: string) => {
+            if (url === '/categories') {
+                return Promise.resolve({
+                    member: [{ '@id': '/api/categories/1', code: 'SECTEUR', name: 'Secteur' }],
+                })
+            }
+            if (url === '/sites') {
+                return Promise.resolve({ member: [{ '@id': '/api/sites/1', name: 'Chatellerault', postalCode: '86100' }] })
+            }
+            return Promise.resolve({ member: [] })
+        })
+
+        const refs = useClientReferentials()
+        await refs.loadCommon()
+
+        expect(refs.categories.value).toEqual([
+            { value: '/api/categories/1', label: 'Secteur', code: 'SECTEUR' },
+        ])
+        // Le libelle d'un site est son numero de departement (2 premiers chiffres du code postal).
+        expect(refs.sites.value).toEqual([{ value: '/api/sites/1', label: '86' }])
+    })
+})

frontend/modules/commercial/composables/__tests__/useClientsRepository.spec.ts

@@ -0,0 +1,85 @@
+import { describe, it, expect, vi, beforeEach } from 'vitest'
+import type { HydraCollection } from '~/shared/utils/api'
+import type { Client } from '../useClientsRepository'
+
+// `useApi` est un auto-import Nuxt : on le stubbe globalement pour intercepter
+// les appels declenches par usePaginatedList (que useClientsRepository enveloppe)
+// et controler les reponses. Meme pattern que useCategoriesAdmin.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 le stub pour que useApi soit bien resolu au top-level du module.
+const { useClientsRepository } = await import('../useClientsRepository')
+
+/** Envelope Hydra minimale (la liste reelle des membres importe peu ici). */
+function makeHydra(total: number): HydraCollection<Client> {
+    return { totalItems: total, member: [] }
+}
+
+describe('useClientsRepository', () => {
+    beforeEach(() => {
+        mockGet.mockReset()
+        // 25 items → 3 pages a 10/page : permet de tester la navigation page 2.
+        mockGet.mockResolvedValue(makeHydra(25))
+    })
+
+    it('cible la ressource /clients en page 1 par defaut', async () => {
+        const repo = useClientsRepository()
+        await repo.fetch()
+
+        expect(mockGet).toHaveBeenLastCalledWith(
+            '/clients',
+            { page: 1, itemsPerPage: 10 },
+            expect.objectContaining({ toast: false }),
+        )
+    })
+
+    it('pousse les filtres du drawer (categories multi, sites, archives) et retombe en page 1', async () => {
+        const repo = useClientsRepository()
+        await repo.fetch()
+        await repo.goToPage(2)
+        expect(repo.currentPage.value).toBe(2)
+
+        await repo.setFilters(
+            {
+                search: 'acme',
+                'categoryCode[]': ['DISTRIBUTEUR', 'COURTIER'],
+                'siteId[]': ['1', '2'],
+                archivedOnly: true,
+            },
+            { replace: true },
+        )
+
+        expect(repo.currentPage.value).toBe(1)
+        expect(mockGet).toHaveBeenLastCalledWith(
+            '/clients',
+            {
+                search: 'acme',
+                'categoryCode[]': ['DISTRIBUTEUR', 'COURTIER'],
+                'siteId[]': ['1', '2'],
+                archivedOnly: true,
+                page: 1,
+                itemsPerPage: 10,
+            },
+            expect.objectContaining({ toast: false }),
+        )
+    })
+
+    it('repasse a une query propre apres reinitialisation des filtres', async () => {
+        const repo = useClientsRepository()
+        await repo.setFilters({ search: 'acme', archivedOnly: true }, { replace: true })
+        await repo.setFilters({}, { replace: true })
+
+        expect(mockGet).toHaveBeenLastCalledWith(
+            '/clients',
+            { page: 1, itemsPerPage: 10 },
+            expect.objectContaining({ toast: false }),
+        )
+    })
+})

frontend/modules/commercial/composables/useClient.ts

@@ -0,0 +1,70 @@
+import { ref } from 'vue'
+import type { ClientDetail } from '~/modules/commercial/utils/clientConsultation'
+
+/**
+ * Chargement et actions d'archivage d'un client unique (ecran « Consultation
+ * client », 1.11). Lit le detail embarque via `GET /api/clients/{id}` (contacts /
+ * adresses / ribs sous `client:item:read` / `client:read:accounting`) et expose
+ * les bascules d'archivage (PATCH `isArchived` SEUL — tout autre champ => 422).
+ *
+ * L'en-tete `Accept: application/ld+json` est impose pour obtenir le payload
+ * Hydra complet (sans lui, API Platform 4 renvoie une representation reduite).
+ *
+ * Etat 100 % local a l'instance (refs) — aucune persistance URL. Les erreurs
+ * d'archivage/restauration (notamment le 409 RG-1.23 : homonyme actif a la
+ * restauration) sont PROPAGEES a l'appelant, qui decide du toast a afficher.
+ */
+export function useClient(id: number | string) {
+    const api = useApi()
+
+    const client = ref<ClientDetail | null>(null)
+    const loading = ref(false)
+    const error = ref(false)
+
+    /** Recupere le detail complet (embed contacts/adresses/ribs + comptabilite). */
+    function fetchDetail(): Promise<ClientDetail> {
+        return api.get<ClientDetail>(
+            `/clients/${id}`,
+            {},
+            { headers: { Accept: 'application/ld+json' }, toast: false },
+        )
+    }
+
+    /** Charge le detail du client. En cas d'echec : `error = true`, `client = null`. */
+    async function load(): Promise<void> {
+        loading.value = true
+        error.value = false
+        try {
+            client.value = await fetchDetail()
+        }
+        catch {
+            error.value = true
+            client.value = null
+        }
+        finally {
+            loading.value = false
+        }
+    }
+
+    /**
+     * Bascule l'archivage (PATCH `isArchived` SEUL — tout autre champ => 422),
+     * puis RECHARGE le detail complet : la reponse du PATCH ne porte que le groupe
+     * `client:read` (ni l'embed contacts/adresses/ribs ni les libelles des
+     * referentiels comptables), un simple merge laisserait l'affichage incoherent.
+     * Toute erreur (notamment le 409 d'homonyme actif a la restauration, RG-1.23)
+     * est propagee a l'appelant AVANT le rechargement.
+     */
+    async function setArchived(isArchived: boolean): Promise<void> {
+        await api.patch(`/clients/${id}`, { isArchived }, { toast: false })
+        client.value = await fetchDetail()
+    }
+
+    return {
+        client,
+        loading,
+        error,
+        load,
+        archive: () => setArchived(true),
+        restore: () => setArchived(false),
+    }
+}

frontend/modules/commercial/composables/useClientReferentials.ts

@@ -0,0 +1,151 @@
+import { ref } from 'vue'
+
+/**
+ * Charge les referentiels (listes courtes) alimentant les selects de l'ecran
+ * « Ajouter un client » : categories, sites, modes de TVA, delais et types de
+ * reglement, banques, et les listes distributeurs / courtiers.
+ *
+ * Toutes les collections sont recuperees en entier via l'echappatoire prevue
+ * `?pagination=false` (referentiels de quelques dizaines d'entrees max), avec
+ * l'en-tete `Accept: application/ld+json` impose par API Platform 4 pour obtenir
+ * l'enveloppe Hydra (`member`). Les valeurs d'option sont les IRI Hydra (`@id`)
+ * pour pouvoir etre renvoyees telles quelles dans les payloads POST/PATCH
+ * (relations ManyToOne / ManyToMany).
+ *
+ * Etat 100 % local a l'instance (refs) — aucune persistance URL.
+ */
+
+/** Option generique au format attendu par MalioSelect / MalioSelectCheckbox ({ label, value }). */
+export interface RefOption {
+    value: string
+    label: string
+}
+
+/** Option de type de reglement enrichie de son code stable (RG-1.12 / RG-1.13). */
+export interface PaymentTypeOption extends RefOption {
+    code: string
+}
+
+/** Option de categorie enrichie de son code stable (filtrage RG-1.29 cote adresse). */
+export interface CategoryOption extends RefOption {
+    code: string
+}
+
+/** Option de client (distributeur / courtier) — value = IRI du client lie. */
+export type ClientOption = RefOption
+
+interface HydraMember {
+    '@id': string
+}
+
+interface CategoryMember extends HydraMember {
+    code: string
+    name: string
+}
+
+interface SiteMember extends HydraMember {
+    name: string
+    postalCode: string
+}
+
+interface ReferentialMember extends HydraMember {
+    code: string
+    label: string
+}
+
+interface ClientMember extends HydraMember {
+    companyName: string
+}
+
+const LD_JSON_HEADERS = { Accept: 'application/ld+json' }
+
+export function useClientReferentials() {
+    const api = useApi()
+
+    const categories = ref<CategoryOption[]>([])
+    const sites = ref<RefOption[]>([])
+    const tvaModes = ref<RefOption[]>([])
+    const paymentDelays = ref<RefOption[]>([])
+    const paymentTypes = ref<PaymentTypeOption[]>([])
+    const banks = ref<RefOption[]>([])
+    const distributors = ref<ClientOption[]>([])
+    const brokers = ref<ClientOption[]>([])
+
+    /** Recupere une collection complete (pagination desactivee) en Hydra. */
+    async function fetchAll<T extends HydraMember>(
+        url: string,
+        query: Record<string, string | string[]> = {},
+    ): Promise<T[]> {
+        const res = await api.get<{ member?: T[] }>(
+            url,
+            { pagination: 'false', ...query },
+            { headers: LD_JSON_HEADERS, toast: false },
+        )
+        return res.member ?? []
+    }
+
+    /**
+     * Charge en parallele les referentiels communs (hors distributeurs/courtiers,
+     * charges a la demande selon la relation choisie).
+     *
+     * Chargement RESILIENT (Promise.allSettled) : chaque referentiel est isole.
+     * Necessaire pour les roles metier qui n'ont pas toutes les permissions de
+     * lecture — ex. Compta a `commercial.clients.view` (donc /tva_modes, /banks...
+     * accessibles) mais PAS `catalog.categories.view` ni `sites.view` : sans
+     * isolation, le 403 sur /categories ferait echouer tout le bloc et viderait
+     * les selects comptables dont Compta a besoin sur l'ecran de modification.
+     * Un referentiel en echec reste simplement vide (l'ecran d'edition complete
+     * l'affichage des valeurs courantes depuis l'embed du detail client).
+     */
+    async function loadCommon(): Promise<void> {
+        await Promise.allSettled([
+            fetchAll<CategoryMember>('/categories')
+                .then((cats) => { categories.value = cats.map(c => ({ value: c['@id'], label: c.name, code: c.code })) }),
+            fetchAll<SiteMember>('/sites')
+                // Libelle = numero de departement (2 premiers chiffres du code
+                // postal du site), ex: 86100 -> « 86 ». Le code postal est deja
+                // expose par /sites (groupe site:read) — aucune colonne a ajouter.
+                .then((sitesList) => { sites.value = sitesList.map(s => ({ value: s['@id'], label: (s.postalCode ?? '').slice(0, 2) })) }),
+            fetchAll<ReferentialMember>('/tva_modes')
+                .then((tva) => { tvaModes.value = tva.map(t => ({ value: t['@id'], label: t.label })) }),
+            fetchAll<ReferentialMember>('/payment_delays')
+                .then((delays) => { paymentDelays.value = delays.map(d => ({ value: d['@id'], label: d.label })) }),
+            fetchAll<ReferentialMember>('/payment_types')
+                .then((types) => { paymentTypes.value = types.map(t => ({ value: t['@id'], label: t.label, code: t.code })) }),
+            fetchAll<ReferentialMember>('/banks')
+                .then((banksList) => { banks.value = banksList.map(b => ({ value: b['@id'], label: b.label })) }),
+        ])
+    }
+
+    /** Liste des clients pouvant etre choisis comme distributeur (code DISTRIBUTEUR). */
+    async function loadDistributors(): Promise<void> {
+        if (distributors.value.length > 0) {
+            return
+        }
+        const clients = await fetchAll<ClientMember>('/clients', { categoryCode: 'DISTRIBUTEUR' })
+        distributors.value = clients.map(c => ({ value: c['@id'], label: c.companyName }))
+    }
+
+    /** Liste des clients pouvant etre choisis comme courtier (code COURTIER). */
+    async function loadBrokers(): Promise<void> {
+        if (brokers.value.length > 0) {
+            return
+        }
+        const clients = await fetchAll<ClientMember>('/clients', { categoryCode: 'COURTIER' })
+        brokers.value = clients.map(c => ({ value: c['@id'], label: c.companyName }))
+    }
+
+    return {
+        categories,
+        sites,
+        tvaModes,
+        paymentDelays,
+        paymentTypes,
+        banks,
+        distributors,
+        brokers,
+        loadCommon,
+        loadDistributors,
+        loadBrokers,
+    }
+}

frontend/modules/commercial/composables/useClientsRepository.ts

@@ -0,0 +1,53 @@
+import { usePaginatedList } from '~/shared/composables/usePaginatedList'
+
+/**
+ * Site Starseed rattache a une adresse du client, tel qu'embarque en LISTE
+ * (groupe site:read) pour la colonne « Site(s) » du Repertoire (badges colores).
+ */
+export interface ClientSite {
+    id: number
+    name: string
+    color: string
+}
+
+/**
+ * Categorie rattachee au client, embarquee en LISTE (groupe category:read).
+ * Seul le `code` (stable, MAJUSCULE — ERP-78) est affiche dans la colonne
+ * « Catégories ». Les autres champs sont presents mais non utilises ici.
+ */
+export interface ClientCategory {
+    code: string
+    name?: string
+}
+
+/**
+ * Vue MINIMALE d'un client pour le Repertoire (datatable). Volontairement
+ * partielle : seuls les champs des colonnes + l'id (navigation) sont types ici.
+ * Le detail complet (onglets) est hors perimetre de cet ecran (ERP-62).
+ */
+export interface Client {
+    id: number
+    companyName: string
+    categories: ClientCategory[]
+    sites: ClientSite[]
+    /** Date ISO de derniere modification (default:read) — colonne « Dernière activité ». */
+    updatedAt: string | null
+    isArchived: boolean
+}
+
+/**
+ * Repertoire clients (ERP-62) — simple enveloppe de `usePaginatedList<Client>`
+ * sur la ressource `/clients` (RG-13 : pagination serveur obligatoire ; jamais
+ * de chargement integral en memoire).
+ *
+ * Les filtres (recherche, categories, sites, archives) sont pilotes par la page
+ * via `setFilters` du composable partage — la remise en page 1 est garantie.
+ *
+ * Volontairement PAR INSTANCE (pas de singleton module-level) : l'etat tableau
+ * est propre a l'ecran Repertoire et meurt avec lui, comme tout consommateur de
+ * `usePaginatedList` (cf. sites.vue / categories.vue). Aucun reset au logout a
+ * gerer.
+ */
+export function useClientsRepository() {
+    return usePaginatedList<Client>({ url: '/clients' })
+}

frontend/modules/commercial/pages/clients/[id]/edit.vue

@@ -0,0 +1,879 @@
+<template>
+    <div>
+        <!-- En-tete : retour repertoire + nom du client. -->
+        <div class="flex items-center gap-3">
+            <MalioButtonIcon
+                icon="mdi:arrow-left-bold"
+                icon-size="24"
+                variant="ghost"
+                v-bind="{ ariaLabel: t('commercial.clients.edit.back') }"
+                @click="goBack"
+            />
+            <h1 class="text-[32px] font-bold text-m-primary">{{ headerTitle }}</h1>
+        </div>
+
+        <!-- Etats de chargement / introuvable. -->
+        <p v-if="loading" class="mt-12 text-center text-black/60">{{ t('commercial.clients.edit.loading') }}</p>
+        <p v-else-if="error" class="mt-12 text-center text-m-danger">{{ t('commercial.clients.edit.notFound') }}</p>
+
+        <template v-else-if="client">
+            <!-- ── Bloc principal (pre-rempli, editable si `manage`) ──────────────
+                 Decision Tristan : on conserve le bloc principal en modification
+                 (« pour ne pas tout casser »), edite via son propre PATCH scope
+                 sur le groupe client:write:main. Readonly pour les roles sans
+                 `manage` (ex. Compta). -->
+            <div class="mt-[48px] grid grid-cols-3 xl:grid-cols-4 gap-x-[44px] gap-y-4">
+                <MalioInputText
+                    v-model="main.companyName"
+                    :label="t('commercial.clients.form.main.companyName')"
+                    :required="true"
+                    :readonly="businessReadonly"
+                />
+                <MalioSelectCheckbox
+                    :model-value="main.categoryIris"
+                    :options="mainCategoryOptions"
+                    :label="t('commercial.clients.form.main.categories')"
+                    :display-tag="true"
+                    :disabled="businessReadonly"
+                    @update:model-value="(v: (string | number)[]) => main.categoryIris = v.map(String)"
+                />
+                <MalioSelect
+                    :model-value="main.relationType"
+                    :options="relationOptions"
+                    :label="t('commercial.clients.form.main.relation')"
+                    :empty-option-label="t('commercial.clients.form.main.relationNone')"
+                    :disabled="businessReadonly"
+                    @update:model-value="onRelationChange"
+                />
+                <MalioSelect
+                    v-if="main.relationType === 'courtier'"
+                    :model-value="main.brokerIri"
+                    :options="brokerOptions"
+                    :label="t('commercial.clients.form.main.brokerName')"
+                    :disabled="businessReadonly"
+                    @update:model-value="(v: string | number | null) => main.brokerIri = v === null ? null : String(v)"
+                />
+                <MalioSelect
+                    v-if="main.relationType === 'distributeur'"
+                    :model-value="main.distributorIri"
+                    :options="distributorOptions"
+                    :label="t('commercial.clients.form.main.distributorName')"
+                    :disabled="businessReadonly"
+                    @update:model-value="(v: string | number | null) => main.distributorIri = v === null ? null : String(v)"
+                />
+                <MalioCheckbox
+                    v-model="main.triageService"
+                    :label="t('commercial.clients.form.main.triageService')"
+                    group-class="self-center"
+                    :readonly="businessReadonly"
+                />
+            </div>
+
+            <div v-if="!businessReadonly" class="mt-12 flex justify-center">
+                <MalioButton
+                    variant="primary"
+                    :label="t('commercial.clients.edit.save')"
+                    :disabled="!isMainValid || mainSubmitting"
+                    @click="submitMain"
+                />
+            </div>
+
+            <!-- ── Onglets : navigation LIBRE, edition independante par onglet ──── -->
+            <MalioTabList v-model="activeTab" :tabs="tabs" class="mt-[60px]">
+                <!-- Onglet Information -->
+                <template #information>
+                    <div class="mt-12 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)]">
+                        <MalioInputTextArea
+                            v-model="information.description"
+                            :label="t('commercial.clients.form.information.description')"
+                            resize="none"
+                            group-class="row-span-2 pt-1"
+                            text-input="h-full text-lg"
+                            :disabled="businessReadonly"
+                        />
+                        <MalioInputText
+                            v-model="information.competitors"
+                            :label="t('commercial.clients.form.information.competitors')"
+                            :readonly="businessReadonly"
+                        />
+                        <MalioDate
+                            v-model="information.foundedAt"
+                            :label="t('commercial.clients.form.information.foundedAt')"
+                            :readonly="businessReadonly"
+                        />
+                        <MalioInputText
+                            v-model="information.employeesCount"
+                            :label="t('commercial.clients.form.information.employeesCount')"
+                            :mask="EMPLOYEES_MASK"
+                            :readonly="businessReadonly"
+                        />
+                        <MalioInputAmount
+                            v-model="information.revenueAmount"
+                            :label="t('commercial.clients.form.information.revenueAmount')"
+                            :disabled="businessReadonly"
+                        />
+                        <MalioInputText
+                            v-model="information.directorName"
+                            :label="t('commercial.clients.form.information.directorName')"
+                            :readonly="businessReadonly"
+                        />
+                        <MalioInputAmount
+                            v-model="information.profitAmount"
+                            :label="t('commercial.clients.form.information.profitAmount')"
+                            :disabled="businessReadonly"
+                        />
+                    </div>
+                    <div v-if="!businessReadonly" class="mt-12 flex justify-center">
+                        <MalioButton
+                            variant="primary"
+                            :label="t('commercial.clients.edit.save')"
+                            :disabled="tabSubmitting"
+                            @click="submitInformation"
+                        />
+                    </div>
+                </template>
+
+                <!-- Onglet Contact -->
+                <template #contact>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <ClientContactBlock
+                            v-for="(contact, index) in contacts"
+                            :key="contact.id ?? `new-${index}`"
+                            :model-value="contact"
+                            :title="t('commercial.clients.form.contact.title', { n: index + 1 })"
+                            :removable="contacts.length > 1"
+                            :readonly="businessReadonly"
+                            @update:model-value="(v) => contacts[index] = v"
+                            @remove="askRemoveContact(index)"
+                        />
+                        <div v-if="!businessReadonly" class="flex justify-center gap-6">
+                            <MalioButton
+                                variant="secondary"
+                                icon-name="mdi:add-bold"
+                                icon-position="left"
+                                :label="t('commercial.clients.form.contact.add')"
+                                :disabled="!canAddContact"
+                                @click="addContact"
+                            />
+                            <MalioButton
+                                variant="primary"
+                                :label="t('commercial.clients.edit.save')"
+                                :disabled="!canValidateContacts || tabSubmitting"
+                                @click="submitContacts"
+                            />
+                        </div>
+                    </div>
+                </template>
+
+                <!-- Onglet Adresse -->
+                <template #address>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <ClientAddressBlock
+                            v-for="(address, index) in addresses"
+                            :key="address.id ?? `new-${index}`"
+                            :model-value="address"
+                            :title="t('commercial.clients.form.address.title', { n: index + 1 })"
+                            :category-options="addressCategoryOptions"
+                            :site-options="siteOptions"
+                            :contact-options="contactOptions"
+                            :country-options="countryOptions"
+                            :removable="addresses.length > 1"
+                            :readonly="businessReadonly"
+                            @update:model-value="(v) => addresses[index] = v"
+                            @remove="askRemoveAddress(index)"
+                            @degraded="onAddressDegraded"
+                        />
+                        <div v-if="!businessReadonly" class="flex justify-center gap-6">
+                            <MalioButton
+                                variant="secondary"
+                                icon-name="mdi:add-bold"
+                                icon-position="left"
+                                :label="t('commercial.clients.form.address.add')"
+                                @click="addAddress"
+                            />
+                            <MalioButton
+                                variant="primary"
+                                :label="t('commercial.clients.edit.save')"
+                                :disabled="!canValidateAddresses || tabSubmitting"
+                                @click="submitAddresses"
+                            />
+                        </div>
+                    </div>
+                </template>
+
+                <!-- Onglet Comptabilite (present uniquement si accounting.view ;
+                     editable uniquement si accounting.manage). -->
+                <template v-if="canAccountingView" #accounting>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <div class="bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+                            <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                                <MalioInputText
+                                    v-model="accounting.siren"
+                                    :label="t('commercial.clients.form.accounting.siren')"
+                                    :mask="SIREN_MASK"
+                                    :readonly="accountingReadonly"
+                                />
+                                <MalioInputText
+                                    v-model="accounting.accountNumber"
+                                    :label="t('commercial.clients.form.accounting.accountNumber')"
+                                    :readonly="accountingReadonly"
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.tvaModeIri"
+                                    :options="tvaModeOptions"
+                                    :label="t('commercial.clients.form.accounting.tvaMode')"
+                                    :disabled="accountingReadonly"
+                                    empty-option-label=""
+                                    @update:model-value="(v: string | number | null) => accounting.tvaModeIri = v === null ? null : String(v)"
+                                />
+                                <MalioInputText
+                                    v-model="accounting.nTva"
+                                    :label="t('commercial.clients.form.accounting.nTva')"
+                                    :readonly="accountingReadonly"
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.paymentDelayIri"
+                                    :options="paymentDelayOptions"
+                                    :label="t('commercial.clients.form.accounting.paymentDelay')"
+                                    :disabled="accountingReadonly"
+                                    empty-option-label=""
+                                    @update:model-value="(v: string | number | null) => accounting.paymentDelayIri = v === null ? null : String(v)"
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.paymentTypeIri"
+                                    :options="paymentTypeOptions"
+                                    :label="t('commercial.clients.form.accounting.paymentType')"
+                                    :disabled="accountingReadonly"
+                                    empty-option-label=""
+                                    @update:model-value="onPaymentTypeChange"
+                                />
+                                <MalioSelect
+                                    v-if="isBankRequired"
+                                    :model-value="accounting.bankIri"
+                                    :options="bankOptions"
+                                    :label="t('commercial.clients.form.accounting.bank')"
+                                    :disabled="accountingReadonly"
+                                    empty-option-label=""
+                                    @update:model-value="(v: string | number | null) => accounting.bankIri = v === null ? null : String(v)"
+                                />
+                            </div>
+                        </div>
+
+                        <!-- Blocs RIB (0..n) — obligatoires si type de reglement = LCR (RG-1.13). -->
+                        <div
+                            v-for="(rib, index) in ribs"
+                            :key="rib.id ?? `new-${index}`"
+                            class="relative bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]"
+                        >
+                            <MalioButtonIcon
+                                v-if="!accountingReadonly"
+                                icon="mdi:delete-outline"
+                                variant="ghost"
+                                button-class="absolute top-3 right-3"
+                                v-bind="{ ariaLabel: t('commercial.clients.form.accounting.removeRib') }"
+                                @click="askRemoveRib(index)"
+                            />
+                            <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                                <MalioInputText
+                                    v-model="rib.label"
+                                    :label="t('commercial.clients.form.accounting.ribLabel')"
+                                    :readonly="accountingReadonly"
+                                />
+                                <MalioInputText
+                                    v-model="rib.bic"
+                                    :label="t('commercial.clients.form.accounting.ribBic')"
+                                    :readonly="accountingReadonly"
+                                />
+                                <MalioInputText
+                                    v-model="rib.iban"
+                                    :label="t('commercial.clients.form.accounting.ribIban')"
+                                    :readonly="accountingReadonly"
+                                />
+                            </div>
+                        </div>
+
+                        <div v-if="!accountingReadonly" class="flex justify-center gap-6">
+                            <MalioButton
+                                variant="secondary"
+                                icon-name="mdi:add-bold"
+                                icon-position="left"
+                                :label="t('commercial.clients.form.accounting.addRib')"
+                                @click="addRib"
+                            />
+                            <MalioButton
+                                variant="primary"
+                                :label="t('commercial.clients.edit.save')"
+                                :disabled="!canValidateAccounting || tabSubmitting"
+                                @click="submitAccounting"
+                            />
+                        </div>
+                    </div>
+                </template>
+
+                <!-- Onglets non encore implementes : frame vide (navigation libre). -->
+                <template #transport><ComingSoonPlaceholder /></template>
+                <template #statistics><ComingSoonPlaceholder /></template>
+                <template #reports><ComingSoonPlaceholder /></template>
+                <template #exchanges><ComingSoonPlaceholder /></template>
+            </MalioTabList>
+        </template>
+
+        <!-- Modal de confirmation generique (suppression contact / adresse / RIB). -->
+        <MalioModal v-model="confirmModal.open" modal-class="max-w-md">
+            <template #header>
+                <h2 class="text-[24px] font-bold">{{ t('commercial.clients.form.confirmDelete.title') }}</h2>
+            </template>
+            <p>{{ confirmModal.message }}</p>
+            <template #footer>
+                <MalioButton
+                    variant="secondary"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.cancel')"
+                    @click="confirmModal.open = false"
+                />
+                <MalioButton
+                    variant="danger"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.confirm')"
+                    @click="runConfirm"
+                />
+            </template>
+        </MalioModal>
+    </div>
+</template>
+
+<script setup lang="ts">
+import { computed, onMounted, reactive, ref } from 'vue'
+import { useClient } from '~/modules/commercial/composables/useClient'
+import { useClientReferentials, type CategoryOption, type RefOption } from '~/modules/commercial/composables/useClientReferentials'
+import {
+    canEditClient,
+    categoryOptionsOf,
+    referentialOptionOf,
+    siteOptionsOf,
+    mapContactToDraft,
+    mapAddressToDraft,
+    mapRibToDraft,
+    type ClientDetail,
+} from '~/modules/commercial/utils/clientConsultation'
+import {
+    buildAccountingPayload,
+    buildAddressPayload,
+    buildContactPayload,
+    buildInformationPayload,
+    buildMainPayload,
+    buildRibPayload,
+    mapAccountingFormDraft,
+    mapInformationDraft,
+    mapMainDraft,
+    resolveTabEditability,
+    type AccountingFormDraft,
+    type ClientEditAbilities,
+    type InformationFormDraft,
+    type MainFormDraft,
+} from '~/modules/commercial/utils/clientEdit'
+import {
+    buildClientFormTabKeys,
+    hasAtLeastOneValidContact,
+    isBankRequiredForPaymentType,
+    isBillingEmailRequired,
+    isContactNamed,
+    isRibRequiredForPaymentType,
+} from '~/modules/commercial/utils/clientFormRules'
+import {
+    emptyAddress,
+    emptyContact,
+    emptyRib,
+    type AddressFormDraft,
+    type ContactFormDraft,
+    type RibFormDraft,
+} from '~/modules/commercial/types/clientForm'
+import { extractApiErrorMessage } from '~/shared/utils/api'
+
+// Masques de saisie (la normalisation finale reste serveur).
+const SIREN_MASK = '#########'
+const EMPLOYEES_MASK = '#######'
+
+// Codes de categorie interdits sur une adresse (RG-1.29, ERP-78).
+const FORBIDDEN_ADDRESS_CATEGORY_CODES = ['DISTRIBUTEUR', 'COURTIER']
+
+const { t } = useI18n()
+const api = useApi()
+const toast = useToast()
+const route = useRoute()
+const router = useRouter()
+const { can, canAny } = usePermissions()
+
+// Gating de la route : l'edition exige de pouvoir editer au moins un onglet
+// (`manage` OU `accounting.manage`). Usine et roles en lecture seule sont
+// rediriges vers le repertoire (lui-meme protege).
+if (!canEditClient(canAny)) {
+    await navigateTo('/clients')
+}
+
+const clientId = route.params.id as string
+
+const { client, loading, error, load } = useClient(clientId)
+const referentials = useClientReferentials()
+
+// ── Permissions / editabilite par zone (option 1 ERP-74) ────────────────────
+const abilities = computed<ClientEditAbilities>(() => ({
+    canManage: can('commercial.clients.manage'),
+    canAccountingView: can('commercial.clients.accounting.view'),
+    canAccountingManage: can('commercial.clients.accounting.manage'),
+}))
+const editability = computed(() => resolveTabEditability(abilities.value))
+// Bloc principal + onglets Information / Contact / Adresse.
+const businessReadonly = computed(() => !editability.value.businessEditable)
+const canAccountingView = computed(() => editability.value.accountingVisible)
+const accountingReadonly = computed(() => !editability.value.accountingEditable)
+
+const headerTitle = computed(() => client.value?.companyName ?? t('commercial.clients.edit.title'))
+
+// ── Brouillons editables (pre-remplis depuis le detail) ─────────────────────
+const main = reactive<MainFormDraft>(mapMainDraft({} as ClientDetail))
+const information = reactive<InformationFormDraft>(mapInformationDraft({} as ClientDetail))
+const accounting = reactive<AccountingFormDraft>(mapAccountingFormDraft({} as ClientDetail))
+const contacts = ref<ContactFormDraft[]>([])
+const addresses = ref<AddressFormDraft[]>([])
+const ribs = ref<RibFormDraft[]>([])
+
+// Ids des sous-ressources existantes supprimees (DELETE differe au « Valider »).
+const removedContactIds = ref<number[]>([])
+const removedAddressIds = ref<number[]>([])
+const removedRibIds = ref<number[]>([])
+
+const mainSubmitting = ref(false)
+const tabSubmitting = ref(false)
+const addressDegradedNotified = ref(false)
+
+/** Recopie le detail charge dans les brouillons editables. */
+function hydrate(detail: ClientDetail): void {
+    Object.assign(main, mapMainDraft(detail))
+    Object.assign(information, mapInformationDraft(detail))
+    Object.assign(accounting, mapAccountingFormDraft(detail))
+    contacts.value = (detail.contacts ?? []).map(mapContactToDraft)
+    addresses.value = (detail.addresses ?? []).map(mapAddressToDraft)
+    ribs.value = (detail.ribs ?? []).map(mapRibToDraft)
+    // Chaque bloc reste visible meme vide : si une collection est vide, on amorce
+    // un bloc vierge (non persiste tant qu'incomplet — cf. submit*/canValidate*).
+    if (contacts.value.length === 0) contacts.value.push(emptyContact())
+    if (addresses.value.length === 0) addresses.value.push(emptyAddress())
+    if (ribs.value.length === 0) ribs.value.push(emptyRib())
+    // Charge les listes distributeur / courtier si une relation est deja posee.
+    if (main.relationType === 'distributeur') referentials.loadDistributors().catch(() => {})
+    if (main.relationType === 'courtier') referentials.loadBrokers().catch(() => {})
+}
+
+// ── Options de selects (referentiels UNION valeurs courantes de l'embed) ─────
+// L'union garantit que les valeurs deja posees s'affichent meme quand le
+// referentiel complet n'est pas chargeable (roles metier sans
+// catalog.categories.view / sites.view → 403, cf. matrice § 2.7).
+function mergeOptions<T extends { value: string }>(primary: T[], extra: T[]): T[] {
+    const seen = new Set(primary.map(o => o.value))
+    return [...primary, ...extra.filter(o => !seen.has(o.value))]
+}
+
+const embedCategoryOptions = computed<CategoryOption[]>(() => {
+    const fromClient = categoryOptionsOf(client.value?.categories)
+    const fromAddresses = (client.value?.addresses ?? []).flatMap(a => categoryOptionsOf(a.categories))
+    return mergeOptions(fromClient, fromAddresses)
+})
+const mainCategoryOptions = computed(() => mergeOptions(referentials.categories.value, embedCategoryOptions.value))
+// Categories autorisees sur une adresse : toutes SAUF DISTRIBUTEUR/COURTIER (RG-1.29).
+const addressCategoryOptions = computed(() =>
+    mainCategoryOptions.value.filter(c => !FORBIDDEN_ADDRESS_CATEGORY_CODES.includes(c.code)),
+)
+
+const embedSiteOptions = computed<RefOption[]>(() =>
+    mergeOptions([], (client.value?.addresses ?? []).flatMap(a => siteOptionsOf(a.sites))),
+)
+const siteOptions = computed(() => mergeOptions(referentials.sites.value, embedSiteOptions.value))
+
+// Contacts deja persistes (iri non null), rattachables a une adresse (M2M).
+const contactOptions = computed<RefOption[]>(() =>
+    contacts.value
+        .filter(c => c.iri !== null)
+        .map(c => ({
+            value: c.iri as string,
+            label: [c.firstName, c.lastName].filter(Boolean).join(' ') || (c.email ?? ''),
+        })),
+)
+
+const countryOptions: RefOption[] = [
+    { value: 'France', label: 'France' },
+    { value: 'Espagne', label: 'Espagne' },
+]
+
+const relationOptions = computed<RefOption[]>(() => [
+    { value: 'distributeur', label: t('commercial.clients.form.main.relationDistributor') },
+    { value: 'courtier', label: t('commercial.clients.form.main.relationBroker') },
+])
+
+// Distributeur / courtier : referentiel charge a la demande UNION valeur courante.
+const currentDistributorOption = computed<RefOption[]>(() => {
+    const d = client.value?.distributor
+    return d && typeof d === 'object' ? [{ value: d['@id'], label: d.companyName ?? d['@id'] }] : []
+})
+const currentBrokerOption = computed<RefOption[]>(() => {
+    const b = client.value?.broker
+    return b && typeof b === 'object' ? [{ value: b['@id'], label: b.companyName ?? b['@id'] }] : []
+})
+const distributorOptions = computed(() => mergeOptions(referentials.distributors.value, currentDistributorOption.value))
+const brokerOptions = computed(() => mergeOptions(referentials.brokers.value, currentBrokerOption.value))
+
+// Selects comptables : referentiel UNION valeur courante de l'embed (libelle).
+const tvaModeOptions = computed(() => mergeOptions(referentials.tvaModes.value, referentialOptionOf(client.value?.tvaMode)))
+const paymentDelayOptions = computed(() => mergeOptions(referentials.paymentDelays.value, referentialOptionOf(client.value?.paymentDelay)))
+const paymentTypeOptions = computed(() => mergeOptions(
+    referentials.paymentTypes.value.map(p => ({ value: p.value, label: p.label })),
+    referentialOptionOf(client.value?.paymentType),
+))
+const bankOptions = computed(() => mergeOptions(referentials.banks.value, referentialOptionOf(client.value?.bank)))
+
+// ── Onglets : navigation libre (4 actifs + 4 coquilles, comme la consultation) ─
+const tabKeys = computed(() => buildClientFormTabKeys(canAccountingView.value, { includeEditOnlyTabs: true }))
+
+const TAB_ICONS: Record<string, string> = {
+    information: 'mdi:account-outline',
+    contact: 'mdi:account-box-plus-outline',
+    address: 'mdi:map-marker-outline',
+    transport: 'mdi:truck-delivery-outline',
+    accounting: 'mdi:bank-circle-outline',
+    statistics: 'mdi:finance',
+    reports: 'mdi:file-document-edit-outline',
+    exchanges: 'mdi:account-group-outline',
+}
+
+const tabs = computed(() => tabKeys.value.map(key => ({
+    key,
+    label: t(`commercial.clients.tab.${key}`),
+    icon: TAB_ICONS[key],
+})))
+
+const activeTab = ref('information')
+
+// ── Navigation ──────────────────────────────────────────────────────────────
+function goBack(): void {
+    router.push(`/clients/${clientId}`)
+}
+
+/**
+ * Message d'erreur a afficher : violation 422 / detail renvoye par le serveur,
+ * sinon un libelle generique. Le 409 d'unicite de nom (bloc principal) est
+ * traduit explicitement par l'appelant.
+ */
+function apiErrorMessage(e: unknown): string {
+    const data = (e as { data?: unknown })?.data
+    return extractApiErrorMessage(data) || t('commercial.clients.toast.error')
+}
+
+function showError(e: unknown, opts: { duplicateCompany?: boolean } = {}): void {
+    const status = (e as { response?: { status?: number } })?.response?.status
+    toast.error({
+        title: t('commercial.clients.toast.error'),
+        message: opts.duplicateCompany && status === 409
+            ? t('commercial.clients.form.duplicateCompany')
+            : apiErrorMessage(e),
+    })
+}
+
+// ── Bloc principal ───────────────────────────────────────────────────────────
+const isMainValid = computed(() => {
+    const filled = (v: string | null | undefined) => v !== null && v !== undefined && v.trim() !== ''
+    const relationValid
+        = main.relationType === null
+        || (main.relationType === 'distributeur' && filled(main.distributorIri))
+        || (main.relationType === 'courtier' && filled(main.brokerIri))
+    return filled(main.companyName)
+        && main.categoryIris.length >= 1
+        && relationValid
+})
+
+async function onRelationChange(value: string | number | null): Promise<void> {
+    const relation = (value === null || value === '') ? null : (String(value) as 'distributeur' | 'courtier')
+    main.relationType = relation
+    // Une seule FK remplie a la fois (RG-1.03).
+    if (relation !== 'distributeur') main.distributorIri = null
+    if (relation !== 'courtier') main.brokerIri = null
+
+    if (relation === 'distributeur') await referentials.loadDistributors().catch(() => {})
+    if (relation === 'courtier') await referentials.loadBrokers().catch(() => {})
+}
+
+/** PATCH /clients/{id} — groupe client:write:main UNIQUEMENT (mode strict). */
+async function submitMain(): Promise<void> {
+    if (businessReadonly.value || !isMainValid.value || mainSubmitting.value) return
+    mainSubmitting.value = true
+    try {
+        const updated = await api.patch<ClientDetail>(`/clients/${clientId}`, buildMainPayload(main), {
+            headers: { Accept: 'application/ld+json' },
+            toast: false,
+        })
+        // Reaffiche les valeurs normalisees renvoyees par le serveur.
+        Object.assign(main, mapMainDraft(updated))
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (e) {
+        showError(e, { duplicateCompany: true })
+    }
+    finally {
+        mainSubmitting.value = false
+    }
+}
+
+// ── Onglet Information ───────────────────────────────────────────────────────
+/** PATCH /clients/{id} — groupe client:write:information UNIQUEMENT. */
+async function submitInformation(): Promise<void> {
+    if (businessReadonly.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        await api.patch(`/clients/${clientId}`, buildInformationPayload(information), { toast: false })
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (e) {
+        showError(e)
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Contact ───────────────────────────────────────────────────────────
+const canAddContact = computed(() => {
+    const last = contacts.value[contacts.value.length - 1]
+    return last === undefined || isContactNamed(last)
+})
+// RG-1.14 : au moins un contact nomme pour finaliser l'onglet.
+const canValidateContacts = computed(() => hasAtLeastOneValidContact(contacts.value))
+
+function addContact(): void {
+    if (canAddContact.value) contacts.value.push(emptyContact())
+}
+
+function askRemoveContact(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.contact'), () => {
+        const removed = contacts.value[index]
+        if (removed?.id != null) removedContactIds.value.push(removed.id)
+        contacts.value.splice(index, 1)
+        // Garde au moins un bloc visible (cf. amorce a l'hydratation).
+        if (contacts.value.length === 0) contacts.value.push(emptyContact())
+    })
+}
+
+/**
+ * Valide l'onglet Contact : DELETE des contacts retires (existants), puis
+ * POST/PATCH des blocs restants sur la sous-ressource. Strictement scope a la
+ * collection contacts (endpoints client_contact dedies).
+ */
+async function submitContacts(): Promise<void> {
+    if (businessReadonly.value || !canValidateContacts.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        for (const id of removedContactIds.value) {
+            await api.delete(`/client_contacts/${id}`, {}, { toast: false })
+        }
+        removedContactIds.value = []
+
+        for (const contact of contacts.value) {
+            if (!isContactNamed(contact)) continue
+            const body = buildContactPayload(contact)
+            if (contact.id === null) {
+                const created = await api.post<{ '@id'?: string, id: number }>(
+                    `/clients/${clientId}/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 })
+            }
+        }
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (e) {
+        showError(e)
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Adresse ───────────────────────────────────────────────────────────
+const canValidateAddresses = computed(() =>
+    addresses.value.length > 0
+    && addresses.value.every((a) => {
+        const filledBillingEmail = a.billingEmail !== null && a.billingEmail.trim() !== ''
+        return a.siteIris.length >= 1
+            && a.categoryIris.length >= 1
+            && (!isBillingEmailRequired(a) || filledBillingEmail)
+    }),
+)
+
+function addAddress(): void {
+    addresses.value.push(emptyAddress())
+}
+
+function askRemoveAddress(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.address'), () => {
+        const removed = addresses.value[index]
+        if (removed?.id != null) removedAddressIds.value.push(removed.id)
+        addresses.value.splice(index, 1)
+        // Garde au moins un bloc visible (cf. amorce a l'hydratation).
+        if (addresses.value.length === 0) addresses.value.push(emptyAddress())
+    })
+}
+
+function onAddressDegraded(): void {
+    if (addressDegradedNotified.value) return
+    addressDegradedNotified.value = true
+    toast.warning({
+        title: t('commercial.clients.toast.error'),
+        message: t('commercial.clients.form.address.degraded'),
+    })
+}
+
+/** Valide l'onglet Adresse : DELETE des adresses retirees puis POST/PATCH. */
+async function submitAddresses(): Promise<void> {
+    if (businessReadonly.value || !canValidateAddresses.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        for (const id of removedAddressIds.value) {
+            await api.delete(`/client_addresses/${id}`, {}, { toast: false })
+        }
+        removedAddressIds.value = []
+
+        for (const address of addresses.value) {
+            const body = buildAddressPayload(address, isBillingEmailRequired(address))
+            if (address.id === null) {
+                const created = await api.post<{ id: number }>(
+                    `/clients/${clientId}/addresses`,
+                    body,
+                    { headers: { Accept: 'application/ld+json' }, toast: false },
+                )
+                address.id = created.id
+            }
+            else {
+                await api.patch(`/client_addresses/${address.id}`, body, { toast: false })
+            }
+        }
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (e) {
+        showError(e)
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Comptabilite ──────────────────────────────────────────────────────
+const selectedPaymentTypeCode = computed(() =>
+    referentials.paymentTypes.value.find(p => p.value === accounting.paymentTypeIri)?.code ?? null,
+)
+const isBankRequired = computed(() => isBankRequiredForPaymentType(selectedPaymentTypeCode.value))
+const isRibRequired = computed(() => isRibRequiredForPaymentType(selectedPaymentTypeCode.value))
+
+function onPaymentTypeChange(value: string | number | null): void {
+    accounting.paymentTypeIri = value === null ? null : String(value)
+    if (!isBankRequired.value) accounting.bankIri = null
+}
+
+function ribIsComplete(rib: { label: string | null, bic: string | null, iban: string | null }): boolean {
+    const filled = (v: string | null) => v !== null && v.trim() !== ''
+    return filled(rib.label) && filled(rib.bic) && filled(rib.iban)
+}
+
+const canValidateAccounting = computed(() => {
+    if (isBankRequired.value && accounting.bankIri === null) return false
+    if (isRibRequired.value && !ribs.value.some(ribIsComplete)) return false
+    return true
+})
+
+function addRib(): void {
+    ribs.value.push(emptyRib())
+}
+
+function askRemoveRib(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.rib'), () => {
+        const removed = ribs.value[index]
+        if (removed?.id != null) removedRibIds.value.push(removed.id)
+        ribs.value.splice(index, 1)
+        // Garde au moins un bloc RIB visible (cf. amorce a l'hydratation).
+        if (ribs.value.length === 0) ribs.value.push(emptyRib())
+    })
+}
+
+/**
+ * Valide l'onglet Comptabilite : PATCH des scalaires (groupe client:write:accounting,
+ * exige accounting.manage cote back) PUIS DELETE/POST/PATCH des RIB sur la
+ * sous-ressource. Aucun champ main/information dans le payload (mode strict
+ * RG-1.28 : sinon 403 sur tout le payload).
+ */
+async function submitAccounting(): Promise<void> {
+    if (accountingReadonly.value || !canValidateAccounting.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        await api.patch(`/clients/${clientId}`, buildAccountingPayload(accounting, isBankRequired.value), { toast: false })
+
+        for (const id of removedRibIds.value) {
+            await api.delete(`/client_ribs/${id}`, {}, { toast: false })
+        }
+        removedRibIds.value = []
+
+        for (const rib of ribs.value) {
+            if (!ribIsComplete(rib)) continue
+            const body = buildRibPayload(rib)
+            if (rib.id === null) {
+                const created = await api.post<{ id: number }>(
+                    `/clients/${clientId}/ribs`,
+                    body,
+                    { headers: { Accept: 'application/ld+json' }, toast: false },
+                )
+                rib.id = created.id
+            }
+            else {
+                await api.patch(`/client_ribs/${rib.id}`, body, { toast: false })
+            }
+        }
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (e) {
+        showError(e)
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Modal de confirmation generique ──────────────────────────────────────────
+const confirmModal = reactive({
+    open: false,
+    message: '',
+    action: null as null | (() => void),
+})
+
+function askConfirm(message: string, action: () => void): void {
+    confirmModal.message = message
+    confirmModal.action = action
+    confirmModal.open = true
+}
+
+function runConfirm(): void {
+    confirmModal.action?.()
+    confirmModal.action = null
+    confirmModal.open = false
+}
+
+useHead({ title: headerTitle })
+
+onMounted(async () => {
+    // Referentiels en best-effort (echec non bloquant : l'embed alimente les
+    // libelles des valeurs courantes).
+    referentials.loadCommon().catch(() => {})
+    await load()
+    if (client.value) hydrate(client.value)
+})
+</script>

frontend/modules/commercial/pages/clients/[id]/index.vue

@@ -0,0 +1,471 @@
+<template>
+    <div>
+        <!-- En-tete : retour repertoire + nom du client + actions (Modifier / Archiver|Restaurer). -->
+        <div class="flex items-center gap-3">
+            <MalioButtonIcon
+                icon="mdi:arrow-left-bold"
+                icon-size="24"
+                variant="ghost"
+                v-bind="{ ariaLabel: t('commercial.clients.consultation.back') }"
+                @click="goBack"
+            />
+            <h1 class="text-[32px] font-bold text-m-primary">{{ headerTitle }}</h1>
+
+            <!-- gap-12 = 48px : meme espacement que Ajouter / Filtres du repertoire. -->
+            <div class="ml-auto flex items-center gap-12">
+                <MalioButton
+                    v-if="canEdit"
+                    variant="secondary"
+                    icon-name="mdi:pencil-outline"
+                    icon-position="left"
+                    :label="t('commercial.clients.action.edit')"
+                    @click="goEdit"
+                />
+                <MalioButton
+                    v-if="showArchive"
+                    variant="secondary"
+                    icon-name="mdi:archive-arrow-down-outline"
+                    icon-position="left"
+                    :label="t('commercial.clients.action.archive')"
+                    @click="askToggleArchive"
+                />
+                <MalioButton
+                    v-if="showRestore"
+                    variant="secondary"
+                    icon-name="mdi:archive-arrow-up-outline"
+                    icon-position="left"
+                    :label="t('commercial.clients.action.restore')"
+                    @click="askToggleArchive"
+                />
+            </div>
+        </div>
+
+        <!-- Etats de chargement / introuvable. -->
+        <p v-if="loading" class="mt-12 text-center text-black/60">{{ t('commercial.clients.consultation.loading') }}</p>
+        <p v-else-if="error" class="mt-12 text-center text-m-danger">{{ t('commercial.clients.consultation.notFound') }}</p>
+
+        <template v-else-if="client">
+            <!-- ── Formulaire principal (lecture seule) ──────────────────────── -->
+            <div class="mt-[48px] grid grid-cols-3 xl:grid-cols-4 gap-x-[44px] gap-y-4">
+                <MalioInputText
+                    :model-value="client.companyName"
+                    :label="t('commercial.clients.form.main.companyName')"
+                    readonly
+                />
+                <MalioSelectCheckbox
+                    :model-value="categoryIris"
+                    :options="mainCategoryOptions"
+                    :label="t('commercial.clients.form.main.categories')"
+                    :display-tag="true"
+                    disabled
+                />
+                <!-- Relation toujours affichee (vide = « Aucun »), comme en edition. -->
+                <MalioSelect
+                    :model-value="relation.type"
+                    :options="relationOptions"
+                    :label="t('commercial.clients.form.main.relation')"
+                    :empty-option-label="t('commercial.clients.form.main.relationNone')"
+                    disabled
+                />
+                <!-- Nom du distributeur/courtier : conditionnel (libelle type-dependant,
+                     aucune valeur sans relation — meme comportement qu'en edition). -->
+                <MalioInputText
+                    v-if="relation.type"
+                    :model-value="relation.name"
+                    :label="relation.type === 'distributeur' ? t('commercial.clients.form.main.distributorName') : t('commercial.clients.form.main.brokerName')"
+                    readonly
+                />
+                <MalioCheckbox
+                    :model-value="client.triageService === true"
+                    :label="t('commercial.clients.form.main.triageService')"
+                    group-class="self-center"
+                    readonly
+                />
+            </div>
+
+            <!-- ── Onglets (navigation libre, tout en lecture seule) ─────────── -->
+            <MalioTabList v-model="activeTab" :tabs="tabs" class="mt-[60px]">
+                <!-- Onglet Information -->
+                <template #information>
+                    <div class="mt-12 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)]">
+                        <MalioInputTextArea
+                            :model-value="information.description"
+                            :label="t('commercial.clients.form.information.description')"
+                            resize="none"
+                            group-class="row-span-2 pt-1"
+                            text-input="h-full text-lg"
+                            disabled
+                        />
+                        <MalioInputText
+                            :model-value="information.competitors"
+                            :label="t('commercial.clients.form.information.competitors')"
+                            readonly
+                        />
+                        <MalioDate
+                            :model-value="information.foundedAt"
+                            :label="t('commercial.clients.form.information.foundedAt')"
+                            readonly
+                        />
+                        <MalioInputText
+                            :model-value="information.employeesCount"
+                            :label="t('commercial.clients.form.information.employeesCount')"
+                            readonly
+                        />
+                        <MalioInputAmount
+                            :model-value="information.revenueAmount"
+                            :label="t('commercial.clients.form.information.revenueAmount')"
+                            disabled
+                        />
+                        <MalioInputText
+                            :model-value="information.directorName"
+                            :label="t('commercial.clients.form.information.directorName')"
+                            readonly
+                        />
+                        <MalioInputAmount
+                            :model-value="information.profitAmount"
+                            :label="t('commercial.clients.form.information.profitAmount')"
+                            disabled
+                        />
+                    </div>
+                </template>
+
+                <!-- Onglet Contact -->
+                <template #contact>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <ClientContactBlock
+                            v-for="(contact, index) in contacts"
+                            :key="contact.id ?? index"
+                            :model-value="contact"
+                            :title="t('commercial.clients.form.contact.title', { n: index + 1 })"
+                            readonly
+                        />
+                    </div>
+                </template>
+
+                <!-- Onglet Adresse -->
+                <template #address>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <ClientAddressBlock
+                            v-for="(view, index) in addressViews"
+                            :key="view.draft.id ?? index"
+                            :model-value="view.draft"
+                            :title="t('commercial.clients.form.address.title', { n: index + 1 })"
+                            :category-options="view.categoryOptions"
+                            :site-options="allSiteOptions"
+                            :contact-options="contactOptions"
+                            :country-options="countryOptions"
+                            readonly
+                        />
+                    </div>
+                </template>
+
+                <!-- Onglet Comptabilite (present uniquement si accounting.view). -->
+                <template v-if="canAccountingView" #accounting>
+                    <div class="mt-12 flex flex-col gap-6">
+                        <div class="bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+                            <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                                <MalioInputText
+                                    :model-value="accounting.siren"
+                                    :label="t('commercial.clients.form.accounting.siren')"
+                                    :mask="SIREN_MASK"
+                                    readonly
+                                />
+                                <MalioInputText
+                                    :model-value="accounting.accountNumber"
+                                    :label="t('commercial.clients.form.accounting.accountNumber')"
+                                    readonly
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.tvaModeIri"
+                                    :options="tvaModeOptions"
+                                    :label="t('commercial.clients.form.accounting.tvaMode')"
+                                    empty-option-label=""
+                                    disabled
+                                />
+                                <MalioInputText
+                                    :model-value="accounting.nTva"
+                                    :label="t('commercial.clients.form.accounting.nTva')"
+                                    readonly
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.paymentDelayIri"
+                                    :options="paymentDelayOptions"
+                                    :label="t('commercial.clients.form.accounting.paymentDelay')"
+                                    empty-option-label=""
+                                    disabled
+                                />
+                                <MalioSelect
+                                    :model-value="accounting.paymentTypeIri"
+                                    :options="paymentTypeOptions"
+                                    :label="t('commercial.clients.form.accounting.paymentType')"
+                                    empty-option-label=""
+                                    disabled
+                                />
+                                <MalioSelect
+                                    v-if="accounting.bankIri"
+                                    :model-value="accounting.bankIri"
+                                    :options="bankOptions"
+                                    :label="t('commercial.clients.form.accounting.bank')"
+                                    empty-option-label=""
+                                    disabled
+                                />
+                            </div>
+                        </div>
+
+                        <!-- Blocs RIB (0..n), lecture seule. -->
+                        <div
+                            v-for="(rib, index) in ribs"
+                            :key="rib.id ?? index"
+                            class="bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]"
+                        >
+                            <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                                <MalioInputText
+                                    :model-value="rib.label"
+                                    :label="t('commercial.clients.form.accounting.ribLabel')"
+                                    readonly
+                                />
+                                <MalioInputText
+                                    :model-value="rib.bic"
+                                    :label="t('commercial.clients.form.accounting.ribBic')"
+                                    readonly
+                                />
+                                <MalioInputText
+                                    :model-value="rib.iban"
+                                    :label="t('commercial.clients.form.accounting.ribIban')"
+                                    readonly
+                                />
+                            </div>
+                        </div>
+                    </div>
+                </template>
+
+                <!-- Onglets non encore implementes : frame vide (navigation libre). -->
+                <template #transport><ComingSoonPlaceholder /></template>
+                <template #statistics><ComingSoonPlaceholder /></template>
+                <template #reports><ComingSoonPlaceholder /></template>
+                <template #exchanges><ComingSoonPlaceholder /></template>
+            </MalioTabList>
+        </template>
+
+        <!-- Modal de confirmation Archiver / Restaurer. -->
+        <MalioModal v-model="confirmOpen" modal-class="max-w-md">
+            <template #header>
+                <h2 class="text-[24px] font-bold">
+                    {{ isArchived ? t('commercial.clients.consultation.confirmRestore.title') : t('commercial.clients.consultation.confirmArchive.title') }}
+                </h2>
+            </template>
+            <p>{{ isArchived ? t('commercial.clients.consultation.confirmRestore.message') : t('commercial.clients.consultation.confirmArchive.message') }}</p>
+            <template #footer>
+                <MalioButton
+                    variant="secondary"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.cancel')"
+                    @click="confirmOpen = false"
+                />
+                <MalioButton
+                    :variant="isArchived ? 'primary' : 'danger'"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.confirm')"
+                    :disabled="toggling"
+                    @click="confirmToggleArchive"
+                />
+            </template>
+        </MalioModal>
+    </div>
+</template>
+
+<script setup lang="ts">
+import { computed, onMounted, ref } from 'vue'
+import { useClient } from '~/modules/commercial/composables/useClient'
+import { buildClientFormTabKeys } from '~/modules/commercial/utils/clientFormRules'
+import {
+    canEditClient,
+    categoryOptionsOf,
+    contactOptionsOf,
+    mapAccountingDraft,
+    mapAddressView,
+    mapContactToDraft,
+    mapRibToDraft,
+    referentialOptionOf,
+    relationOf,
+    showArchiveAction,
+    showRestoreAction,
+    type ClientDetail,
+    type SelectOption,
+} from '~/modules/commercial/utils/clientConsultation'
+import { emptyAddress, emptyContact, emptyRib } from '~/modules/commercial/types/clientForm'
+
+// Masque d'affichage (purement visuel, la donnee reste celle du serveur).
+const SIREN_MASK = '#########'
+
+const { t } = useI18n()
+const route = useRoute()
+const router = useRouter()
+const toast = useToast()
+const { can, canAny } = usePermissions()
+const authStore = useAuthStore()
+
+// Gating de la route : la consultation exige `view`. Usine (sans view) est
+// redirige vers le repertoire (lui-meme protege). Cf. matrice § 2.7.
+if (!can('commercial.clients.view')) {
+    await navigateTo('/clients')
+}
+
+const clientId = route.params.id as string
+
+const { client, loading, error, load, archive, restore } = useClient(clientId)
+
+// ── Permissions / visibilite des actions ───────────────────────────────────
+const canAccountingView = computed(() => can('commercial.clients.accounting.view'))
+const canEdit = computed(() => canEditClient(canAny))
+const isArchived = computed(() => client.value?.isArchived === true)
+const showArchive = computed(() => showArchiveAction(can, isArchived.value))
+const showRestore = computed(() => showRestoreAction(can, isArchived.value))
+
+const headerTitle = computed(() => client.value?.companyName ?? t('commercial.clients.consultation.title'))
+
+// ── Donnees derivees du payload (lecture seule) ────────────────────────────
+const relation = computed(() => (client.value ? relationOf(client.value) : { type: null, name: null }))
+const categoryIris = computed(() => (client.value?.categories ?? []).map(c => c['@id']))
+
+const information = computed(() => ({
+    description: client.value?.description ?? null,
+    competitors: client.value?.competitors ?? null,
+    // MalioDate attend strictement YYYY-MM-DD : on tronque l'ISO datetime renvoye.
+    foundedAt: client.value?.foundedAt ? client.value.foundedAt.slice(0, 10) : null,
+    employeesCount: client.value?.employeesCount != null ? String(client.value.employeesCount) : null,
+    revenueAmount: client.value?.revenueAmount ?? null,
+    profitAmount: client.value?.profitAmount ?? null,
+    directorName: client.value?.directorName ?? null,
+}))
+
+// Chaque bloc reste visible meme vide en consultation : si la collection est
+// vide, on affiche un bloc vierge en lecture seule (pas de message « Aucun … »).
+const contacts = computed(() => {
+    const list = (client.value?.contacts ?? []).map(mapContactToDraft)
+    return list.length ? list : [emptyContact()]
+})
+// Vue par adresse : brouillon + options (sites/categories) propres a l'adresse.
+const addressViews = computed(() => {
+    const views = (client.value?.addresses ?? []).map(mapAddressView)
+    return views.length ? views : [{ draft: emptyAddress(), siteOptions: [], categoryOptions: [] }]
+})
+const ribs = computed(() => {
+    const list = (client.value?.ribs ?? []).map(mapRibToDraft)
+    return list.length ? list : [emptyRib()]
+})
+// Draft comptable (tout null si l'utilisateur n'a pas accounting.view).
+const accounting = computed(() => mapAccountingDraft(client.value ?? ({} as ClientDetail)))
+
+// ── Options des selects (construites depuis l'EMBED, jamais via un GET de
+//    referentiel : /categories et /sites sont en 403 pour les roles metier
+//    non-admin, ce qui laisserait les libelles vides). ───────────────────────
+const mainCategoryOptions = computed(() => categoryOptionsOf(client.value?.categories))
+const contactOptions = computed(() => contactOptionsOf(client.value?.contacts))
+
+// Liste COMPLETE des sites disponibles, issue de /api/me (groupe me:read — donc
+// pas de 403 pour les roles metier, contrairement a GET /sites). Libelle = numero
+// de departement (2 premiers chiffres du code postal). Permet d'afficher TOUJOURS
+// toutes les cases « Sites » (86 / 17 / 82) dans le bloc adresse, meme celles non
+// rattachees a l'adresse consultee (les rattachees restent cochees via siteIris).
+const allSiteOptions = computed<SelectOption[]>(() =>
+    (authStore.user?.sites ?? []).map(s => ({
+        value: `/api/sites/${s.id}`,
+        label: (s.postalCode ?? '').slice(0, 2),
+    })),
+)
+
+const relationOptions = computed<SelectOption[]>(() => [
+    { value: 'distributeur', label: t('commercial.clients.form.main.relationDistributor') },
+    { value: 'courtier', label: t('commercial.clients.form.main.relationBroker') },
+])
+
+const countryOptions: SelectOption[] = [
+    { value: 'France', label: 'France' },
+    { value: 'Espagne', label: 'Espagne' },
+]
+
+// Selects comptables : libelle issu de l'embed (option unique ou vide).
+const tvaModeOptions = computed(() => referentialOptionOf(client.value?.tvaMode))
+const paymentDelayOptions = computed(() => referentialOptionOf(client.value?.paymentDelay))
+const paymentTypeOptions = computed(() => referentialOptionOf(client.value?.paymentType))
+const bankOptions = computed(() => referentialOptionOf(client.value?.bank))
+
+// ── Onglets : navigation LIBRE (pas de sequence forcee en consultation) ────
+// 4 onglets actifs (Information, Contact, Adresse, + Comptabilite si droit) et
+// 4 coquilles (Transport, Statistiques, Rapports, Echanges).
+const tabKeys = computed(() => buildClientFormTabKeys(canAccountingView.value, { includeEditOnlyTabs: true }))
+
+const TAB_ICONS: Record<string, string> = {
+    information: 'mdi:account-outline',
+    contact: 'mdi:account-box-plus-outline',
+    address: 'mdi:map-marker-outline',
+    transport: 'mdi:truck-delivery-outline',
+    accounting: 'mdi:bank-circle-outline',
+    statistics: 'mdi:finance',
+    reports: 'mdi:file-document-edit-outline',
+    exchanges: 'mdi:account-group-outline',
+}
+
+const tabs = computed(() => tabKeys.value.map(key => ({
+    key,
+    label: t(`commercial.clients.tab.${key}`),
+    icon: TAB_ICONS[key],
+})))
+
+const activeTab = ref('information')
+
+// ── Navigation ─────────────────────────────────────────────────────────────
+function goBack(): void {
+    router.push('/clients')
+}
+
+function goEdit(): void {
+    router.push(`/clients/${clientId}/edit`)
+}
+
+// ── Archivage / Restauration ────────────────────────────────────────────────
+const confirmOpen = ref(false)
+const toggling = ref(false)
+
+function askToggleArchive(): void {
+    confirmOpen.value = true
+}
+
+/**
+ * Confirme l'archivage ou la restauration (PATCH isArchived seul). Gere le 409
+ * de conflit d'homonyme actif a la restauration (RG-1.23) avec un message dedie.
+ */
+async function confirmToggleArchive(): Promise<void> {
+    if (toggling.value) return
+    toggling.value = true
+    const restoring = isArchived.value
+    try {
+        if (restoring) {
+            await restore()
+            toast.success({ title: t('commercial.clients.toast.restoreSuccess') })
+        }
+        else {
+            await archive()
+            toast.success({ title: t('commercial.clients.toast.archiveSuccess') })
+        }
+        confirmOpen.value = false
+    }
+    catch (e) {
+        const status = (e as { response?: { status?: number } })?.response?.status
+        toast.error({
+            title: t('commercial.clients.toast.error'),
+            message: restoring && status === 409
+                ? t('commercial.clients.toast.restoreConflict')
+                : t('commercial.clients.toast.error'),
+        })
+    }
+    finally {
+        toggling.value = false
+    }
+}
+
+useHead({ title: headerTitle })
+
+onMounted(load)
+</script>

frontend/modules/commercial/pages/clients/index.vue

@@ -0,0 +1,421 @@
+<template>
+    <div>
+        <PageHeader>
+            {{ t('commercial.clients.title') }}
+            <template #actions>
+                <!-- gap-12 = 48px d'espacement entre Ajouter et Filtres. -->
+                <div class="flex items-center gap-12">
+                    <MalioButton
+                        v-if="canManage"
+                        variant="secondary"
+                        :label="t('commercial.clients.add')"
+                        icon-name="mdi:add-bold"
+                        icon-position="left"
+                        @click="goToCreate"
+                    />
+                    <!-- Bouton Filtres a DROITE d'Ajouter : meme design que
+                         l'audit-log. Le compteur reflete les filtres actifs. -->
+                    <MalioButton
+                        v-if="canView"
+                        variant="tertiary"
+                        :label="filterButtonLabel"
+                        icon-name="mdi:tune"
+                        icon-position="left"
+                        icon-size="24"
+                        button-class="w-[184px] justify-start gap-4 text-black"
+                        @click="openFilters"
+                    />
+                </div>
+            </template>
+        </PageHeader>
+
+        <!-- Datatable branchee sur usePaginatedList via useClientsRepository :
+             pagination serveur, tri companyName ASC par defaut (cote back). -->
+        <MalioDataTable
+            :columns="columns"
+            :items="rows"
+            :total-items="totalItems"
+            :page="currentPage"
+            :per-page="itemsPerPage"
+            :per-page-options="itemsPerPageOptions"
+            row-clickable
+            table-class="table-fixed"
+            :empty-message="t('commercial.clients.empty')"
+            @row-click="onRowClick"
+            @update:page="goToPage"
+            @update:per-page="setItemsPerPage"
+        >
+            <!-- Categories : codes stables separes par une virgule (ERP-78). -->
+            <template #cell-categories="{ item }">
+                {{ formatCategories(item) }}
+            </template>
+
+            <!-- Sites : badges colores (name + color), agreges des adresses. -->
+            <template #cell-sites="{ item }">
+                <span class="flex flex-wrap gap-1">
+                    <span
+                        v-for="site in (item.sites as ClientSite[])"
+                        :key="site.id"
+                        class="inline-flex items-center rounded-full px-2 py-0.5 text-xs font-medium text-white"
+                        :style="{ backgroundColor: site.color }"
+                    >
+                        {{ site.name }}
+                    </span>
+                </span>
+            </template>
+
+            <!-- Derniere activite : date de derniere modification (updatedAt). -->
+            <template #cell-lastActivity="{ item }">
+                {{ formatLastActivity(item) }}
+            </template>
+        </MalioDataTable>
+
+        <div class="flex justify-center mt-6">
+            <MalioButton
+                v-if="canView"
+                variant="primary"
+                :label="t('commercial.clients.export')"
+                :disabled="exporting"
+                @click="exportXlsx"
+            />
+        </div>
+
+        <!-- Drawer de filtres : etat BROUILLON, applique uniquement au clic sur
+             « Appliquer ». Meme pattern que l'audit-log. 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('commercial.clients.filters.title') }}</h2>
+            </template>
+
+            <MalioAccordion>
+                <!-- Recherche : nom societe + contact + email (param `search`). -->
+                <MalioAccordionItem :title="t('commercial.clients.filters.search')" value="search">
+                    <MalioInputText
+                        v-model="draftSearch"
+                        icon-name="mdi:magnify"
+                    />
+                </MalioAccordionItem>
+
+                <!-- Categories : cases a cocher (multi). Valeur = code stable. -->
+                <MalioAccordionItem :title="t('commercial.clients.filters.categories')" value="categories">
+                    <div class="flex flex-col">
+                        <MalioCheckbox
+                            v-for="opt in categoryOptions"
+                            :id="`filter-category-${opt.value}`"
+                            :key="opt.value"
+                            :label="opt.label"
+                            :model-value="draftCategoryCodes.includes(opt.value)"
+                            @update:model-value="(val: boolean) => toggleCategory(opt.value, val)"
+                        />
+                    </div>
+                </MalioAccordionItem>
+
+                <!-- Sites : cases a cocher (multi). Valeur = id du site. -->
+                <MalioAccordionItem :title="t('commercial.clients.filters.sites')" value="sites">
+                    <div class="flex flex-col">
+                        <MalioCheckbox
+                            v-for="opt in siteOptions"
+                            :id="`filter-site-${opt.value}`"
+                            :key="opt.value"
+                            :label="opt.label"
+                            :model-value="draftSiteIds.includes(opt.value)"
+                            @update:model-value="(val: boolean) => toggleSite(opt.value, val)"
+                        />
+                    </div>
+                </MalioAccordionItem>
+
+                <!-- Statut : bool unique. Coche = archives uniquement, sinon actifs. -->
+                <MalioAccordionItem :title="t('commercial.clients.filters.status')" value="status">
+                    <MalioCheckbox
+                        id="filter-archived-only"
+                        :label="t('commercial.clients.filters.archivedOnly')"
+                        :model-value="draftArchivedOnly"
+                        @update:model-value="(val: boolean) => draftArchivedOnly = val"
+                    />
+                </MalioAccordionItem>
+            </MalioAccordion>
+
+            <template #footer>
+                <MalioButton
+                    variant="tertiary"
+                    :label="t('commercial.clients.filters.reset')"
+                    button-class="w-m-btn-action"
+                    @click="resetFilters"
+                />
+                <MalioButton
+                    variant="primary"
+                    :label="t('commercial.clients.filters.apply')"
+                    button-class="w-[170px]"
+                    @click="applyFilters"
+                />
+            </template>
+        </MalioDrawer>
+    </div>
+</template>
+
+<script setup lang="ts">
+import { computed, onMounted, ref } from 'vue'
+import type { Client, ClientSite } from '~/modules/commercial/composables/useClientsRepository'
+
+interface FilterOption {
+    value: string
+    label: string
+}
+
+const { t } = useI18n()
+const api = useApi()
+const router = useRouter()
+const toast = useToast()
+const { can } = usePermissions()
+
+useHead({ title: t('commercial.clients.title') })
+
+// Bouton « Ajouter » reserve a `manage` (POST /clients garde manage seul →
+// Compta / Usine ne creent pas). « Exporter » et « Filtres » suivent `view`.
+const canManage = computed(() => can('commercial.clients.manage'))
+const canView = computed(() => can('commercial.clients.view'))
+
+const {
+    items: clients,
+    totalItems,
+    currentPage,
+    itemsPerPage,
+    itemsPerPageOptions,
+    fetch: loadClients,
+    goToPage,
+    setItemsPerPage,
+    setFilters,
+} = useClientsRepository()
+
+// Mappe les clients en objets « plats » pour MalioDataTable (items typees
+// Record<string, unknown>[]) : un objet litteral porte une signature d'index
+// implicite, contrairement a l'interface Client. Meme pattern que sites.vue.
+const rows = computed(() => clients.value.map(client => ({
+    id: client.id,
+    companyName: client.companyName,
+    categories: client.categories,
+    sites: client.sites,
+    updatedAt: client.updatedAt,
+})))
+
+const columns = [
+    { key: 'companyName', label: t('commercial.clients.column.companyName') },
+    { key: 'categories', label: t('commercial.clients.column.categories') },
+    { key: 'sites', label: t('commercial.clients.column.sites') },
+    { key: 'lastActivity', label: t('commercial.clients.column.lastActivity') },
+]
+
+/** Codes des categories du client, separes par une virgule (ERP-78). */
+function formatCategories(item: Record<string, unknown>): string {
+    const categories = (item.categories as Client['categories']) ?? []
+    return categories.map(c => c.code).join(', ')
+}
+
+/**
+ * Derniere activite : faute de suivi d'activite metier au M1, on affiche la
+ * date de derniere modification de la fiche (updatedAt, expose en liste via
+ * default:read). Format court francais jj/mm/aaaa.
+ */
+function formatLastActivity(item: Record<string, unknown>): string {
+    const value = item.updatedAt as string | null | undefined
+    if (!value) {
+        return ''
+    }
+
+    // Garde-fou date invalide : un updatedAt mal forme donnerait « Invalid Date ».
+    const date = new Date(value)
+    if (Number.isNaN(date.getTime())) {
+        return ''
+    }
+
+    return date.toLocaleDateString('fr-FR')
+}
+
+/** Clic sur une ligne → ecran Consultation (route a plat /clients/{id}). */
+function onRowClick(item: Record<string, unknown>): void {
+    router.push(`/clients/${item.id}`)
+}
+
+function goToCreate(): void {
+    router.push('/clients/new')
+}
+
+// ── Filtres (drawer) ────────────────────────────────────────────────────────
+// Deux niveaux d'etat (pattern audit-log) :
+//  - APPLIED : pilote la liste/l'export + 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 draftCategoryCodes = ref<string[]>([])
+const draftSiteIds = ref<string[]>([])
+const draftArchivedOnly = ref(false)
+
+const appliedSearch = ref('')
+const appliedCategoryCodes = ref<string[]>([])
+const appliedSiteIds = ref<string[]>([])
+const appliedArchivedOnly = ref(false)
+
+// Options des selects multi, chargees une fois (referentiels courts).
+const categoryOptions = ref<FilterOption[]>([])
+const siteOptions = ref<FilterOption[]>([])
+
+const activeFilterCount = computed(() => {
+    let count = 0
+    if (appliedSearch.value.trim() !== '') count++
+    if (appliedCategoryCodes.value.length > 0) count++
+    if (appliedSiteIds.value.length > 0) count++
+    if (appliedArchivedOnly.value) count++
+    return count
+})
+
+const filterButtonLabel = computed(() => {
+    const base = t('commercial.clients.filters.title')
+    return activeFilterCount.value > 0 ? `${base} (${activeFilterCount.value})` : base
+})
+
+// Recopie l'etat applique vers le brouillon puis ouvre le drawer : la
+// reouverture reflete les filtres actifs.
+function openFilters(): void {
+    draftSearch.value = appliedSearch.value
+    draftCategoryCodes.value = [...appliedCategoryCodes.value]
+    draftSiteIds.value = [...appliedSiteIds.value]
+    draftArchivedOnly.value = appliedArchivedOnly.value
+    filterDrawerOpen.value = true
+}
+
+function toggleCategory(code: string, selected: boolean): void {
+    draftCategoryCodes.value = selected
+        ? [...draftCategoryCodes.value, code]
+        : draftCategoryCodes.value.filter(c => c !== code)
+}
+
+function toggleSite(id: string, selected: boolean): void {
+    draftSiteIds.value = selected
+        ? [...draftSiteIds.value, id]
+        : draftSiteIds.value.filter(s => s !== id)
+}
+
+/**
+ * Construit le payload de filtres serveur a partir de l'etat applique. Cles
+ * `categoryCode[]` / `siteId[]` pour que PHP les parse en tableaux (OR cote back).
+ * Les filtres vides sont omis pour une query propre.
+ */
+function buildFilterPayload(): Record<string, string | string[] | boolean> {
+    const payload: Record<string, string | string[] | boolean> = {}
+    if (appliedSearch.value.trim() !== '') payload.search = appliedSearch.value.trim()
+    if (appliedCategoryCodes.value.length > 0) payload['categoryCode[]'] = [...appliedCategoryCodes.value]
+    if (appliedSiteIds.value.length > 0) payload['siteId[]'] = [...appliedSiteIds.value]
+    if (appliedArchivedOnly.value) payload.archivedOnly = true
+    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()
+    appliedCategoryCodes.value = [...draftCategoryCodes.value]
+    appliedSiteIds.value = [...draftSiteIds.value]
+    appliedArchivedOnly.value = draftArchivedOnly.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 = ''
+    draftCategoryCodes.value = []
+    draftSiteIds.value = []
+    draftArchivedOnly.value = false
+
+    appliedSearch.value = ''
+    appliedCategoryCodes.value = []
+    appliedSiteIds.value = []
+    appliedArchivedOnly.value = false
+
+    setFilters({}, { replace: true })
+}
+
+/** Charge les referentiels du drawer (categories + sites) via ?pagination=false. */
+async function loadFilterOptions(): Promise<void> {
+    const [cats, sites] = await Promise.all([
+        api.get<{ member?: Array<{ code: string, name: string }> }>(
+            '/categories',
+            { pagination: 'false' },
+            { headers: { Accept: 'application/ld+json' }, toast: false },
+        ),
+        api.get<{ member?: Array<{ id: number, name: string }> }>(
+            '/sites',
+            { pagination: 'false' },
+            { headers: { Accept: 'application/ld+json' }, toast: false },
+        ),
+    ])
+
+    categoryOptions.value = (cats.member ?? []).map(c => ({ value: c.code, label: c.name }))
+    siteOptions.value = (sites.member ?? []).map(s => ({ value: String(s.id), label: s.name }))
+}
+
+// ── Export XLSX ─────────────────────────────────────────────────────────────
+// Memes filtres que la vue. La colonne SIREN n'est dans le fichier que si
+// l'utilisateur a accounting.view (gere cote back).
+const exporting = ref(false)
+
+async function exportXlsx(): Promise<void> {
+    if (exporting.value) {
+        return
+    }
+    exporting.value = true
+    try {
+        // useApi type ses options en JSON ; l'export renvoie un binaire, donc on
+        // force responseType:'blob' (transmis tel quel a ofetch au runtime). Cast
+        // contenu faute d'overload blob sur le client partage — a generaliser via
+        // un ticket dedie si d'autres exports binaires arrivent.
+        const blob = await api.get<Blob>('/clients/export.xlsx', buildFilterPayload(), {
+            responseType: 'blob',
+            toast: false,
+        } as unknown as Parameters<typeof api.get>[2])
+
+        triggerDownload(blob, 'repertoire-clients.xlsx')
+    }
+    catch {
+        toast.error({
+            title: t('commercial.clients.toast.error'),
+            message: t('commercial.clients.toast.exportError'),
+        })
+    }
+    finally {
+        exporting.value = false
+    }
+}
+
+/** Declenche le telechargement d'un blob via un lien temporaire. */
+function triggerDownload(blob: Blob, filename: string): void {
+    const url = URL.createObjectURL(blob)
+    const link = document.createElement('a')
+    link.href = url
+    link.download = filename
+    document.body.appendChild(link)
+    link.click()
+    link.remove()
+    URL.revokeObjectURL(url)
+}
+
+onMounted(() => {
+    loadClients()
+    // Echec du chargement des referentiels non bloquant : la liste s'affiche,
+    // l'utilisateur perd juste les options de filtre.
+    loadFilterOptions().catch(() => {
+        categoryOptions.value = []
+        siteOptions.value = []
+    })
+})
+</script>

frontend/modules/commercial/pages/clients/new.vue

@@ -0,0 +1,892 @@
+<template>
+    <div>
+        <!-- En-tete : retour vers le repertoire + titre. -->
+        <div class="flex items-center gap-3">
+            <MalioButtonIcon
+                icon="mdi:arrow-left-bold"
+                icon-size="24"
+                variant="ghost"
+                v-bind="{ ariaLabel: t('commercial.clients.form.back') }"
+                @click="goBack"
+            />
+            <h1 class="text-[32px] font-bold text-m-primary">{{ t('commercial.clients.form.title') }}</h1>
+        </div>
+
+        <!-- ── Formulaire principal (pre-onglets) ─────────────────────────────
+             Sans validation de ce bloc, les onglets restent inaccessibles. Au
+             succes du POST, les champs passent en lecture seule et on bascule
+             automatiquement sur l'onglet Information. -->
+        <div class="mt-[48px] grid grid-cols-3 xl:grid-cols-4 gap-x-[44px] gap-y-4">
+            <MalioInputText
+                v-model="main.companyName"
+                :label="t('commercial.clients.form.main.companyName')"
+                :required="true"
+                :readonly="mainLocked"
+            />
+            <MalioSelectCheckbox
+                :model-value="main.categoryIris"
+                :options="referentials.categories.value"
+                :label="t('commercial.clients.form.main.categories')"
+                :display-tag="true"
+                :disabled="mainLocked"
+                @update:model-value="(v: (string | number)[]) => main.categoryIris = v.map(String)"
+            />
+            <MalioSelect
+                :model-value="main.relationType"
+                :options="relationOptions"
+                :label="t('commercial.clients.form.main.relation')"
+                :empty-option-label="t('commercial.clients.form.main.relationNone')"
+                :disabled="mainLocked"
+                @update:model-value="onRelationChange"
+            />
+            <MalioSelect
+                v-if="main.relationType === 'courtier'"
+                :model-value="main.brokerIri"
+                :options="referentials.brokers.value"
+                :label="t('commercial.clients.form.main.brokerName')"
+                :disabled="mainLocked"
+                @update:model-value="(v: string | number | null) => main.brokerIri = v === null ? null : String(v)"
+            />
+            <MalioSelect
+                v-if="main.relationType === 'distributeur'"
+                :model-value="main.distributorIri"
+                :options="referentials.distributors.value"
+                :label="t('commercial.clients.form.main.distributorName')"
+                :disabled="mainLocked"
+                @update:model-value="(v: string | number | null) => main.distributorIri = v === null ? null : String(v)"
+            />
+            <MalioCheckbox
+                v-model="main.triageService"
+                :label="t('commercial.clients.form.main.triageService')"
+                group-class="self-center"
+                :readonly="mainLocked"
+            />
+        </div>
+
+        <div v-if="!mainLocked" class="mt-12 flex justify-center">
+            <MalioButton
+                variant="primary"
+                :label="t('commercial.clients.form.submit')"
+                :disabled="!isMainValid || mainSubmitting"
+                @click="submitMain"
+            />
+        </div>
+
+        <!-- ── Onglets a validation incrementale ─────────────────────────────-->
+        <MalioTabList v-model="activeTab" :tabs="tabs" class="mt-[60px]">
+            <!-- Onglet Information -->
+            <template #information>
+                <div class="mt-12 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)]">
+                    <!-- pt-1 : aligne le bord superieur du textarea sur celui des
+                         inputs (centres dans un conteneur h-12, soit ~4px de retrait haut). -->
+                    <MalioInputTextArea
+                        v-model="information.description"
+                        :label="t('commercial.clients.form.information.description')"
+                        resize="none"
+                        group-class="row-span-2 pt-1"
+                        text-input="h-full text-lg"
+                        :disabled="isValidated('information')"
+                    />
+                    <MalioInputText
+                        v-model="information.competitors"
+                        :label="t('commercial.clients.form.information.competitors')"
+                        :readonly="isValidated('information')"
+                    />
+                    <MalioDate
+                        v-model="information.foundedAt"
+                        :label="t('commercial.clients.form.information.foundedAt')"
+                        :readonly="isValidated('information')"
+                    />
+                    <MalioInputText
+                        v-model="information.employeesCount"
+                        :label="t('commercial.clients.form.information.employeesCount')"
+                        :mask="EMPLOYEES_MASK"
+                        :readonly="isValidated('information')"
+                    />
+                    <MalioInputAmount
+                        v-model="information.revenueAmount"
+                        :label="t('commercial.clients.form.information.revenueAmount')"
+                        :disabled="isValidated('information')"
+                    />
+                    <MalioInputText
+                        v-model="information.directorName"
+                        :label="t('commercial.clients.form.information.directorName')"
+                        :readonly="isValidated('information')"
+                    />
+                    <MalioInputAmount
+                        v-model="information.profitAmount"
+                        :label="t('commercial.clients.form.information.profitAmount')"
+                        :disabled="isValidated('information')"
+                    />
+                </div>
+                <div v-if="!isValidated('information')" class="mt-12 flex justify-center">
+                    <!-- Desactive tant que le client n'est pas cree : evite un PATCH
+                         avant le POST si l'utilisateur clique trop tot (le panneau
+                         Information est l'onglet actif par defaut). -->
+                    <MalioButton
+                        variant="primary"
+                        :label="t('commercial.clients.form.submit')"
+                        :disabled="tabSubmitting || clientId === null"
+                        @click="submitInformation"
+                    />
+                </div>
+            </template>
+
+            <!-- Onglet Contact -->
+            <template #contact>
+                <div class="mt-12 flex flex-col gap-6">
+                    <ClientContactBlock
+                        v-for="(contact, index) in contacts"
+                        :key="index"
+                        :model-value="contact"
+                        :title="t('commercial.clients.form.contact.title', { n: index + 1 })"
+                        :removable="index > 0"
+                        :readonly="isValidated('contact')"
+                        @update:model-value="(v) => contacts[index] = v"
+                        @remove="askRemoveContact(index)"
+                    />
+                    <div v-if="!isValidated('contact')" class="flex justify-center gap-6">
+                        <MalioButton
+                            variant="secondary"
+                            icon-name="mdi:add-bold"
+                            icon-position="left"
+                            :label="t('commercial.clients.form.contact.add')"
+                            :disabled="!canAddContact"
+                            @click="addContact"
+                        />
+                        <MalioButton
+                            variant="primary"
+                            :label="t('commercial.clients.form.submit')"
+                            :disabled="!canValidateContacts || tabSubmitting"
+                            @click="submitContacts"
+                        />
+                    </div>
+                </div>
+            </template>
+
+            <!-- Onglet Adresse -->
+            <template #address>
+                <div class="mt-12 flex flex-col gap-6">
+                    <ClientAddressBlock
+                        v-for="(address, index) in addresses"
+                        :key="index"
+                        :model-value="address"
+                        :title="t('commercial.clients.form.address.title', { n: index + 1 })"
+                        :category-options="addressCategoryOptions"
+                        :site-options="referentials.sites.value"
+                        :contact-options="contactOptions"
+                        :country-options="countryOptions"
+                        :removable="index > 0"
+                        :readonly="isValidated('address')"
+                        @update:model-value="(v) => addresses[index] = v"
+                        @remove="askRemoveAddress(index)"
+                        @degraded="onAddressDegraded"
+                    />
+                    <div v-if="!isValidated('address')" class="flex justify-center gap-6">
+                        <MalioButton
+                            variant="secondary"
+                            icon-name="mdi:add-bold"
+                            icon-position="left"
+                            :label="t('commercial.clients.form.address.add')"
+                            @click="addAddress"
+                        />
+                        <MalioButton
+                            variant="primary"
+                            :label="t('commercial.clients.form.submit')"
+                            :disabled="!canValidateAddresses || tabSubmitting"
+                            @click="submitAddresses"
+                        />
+                    </div>
+                </div>
+            </template>
+
+            <!-- Onglet Comptabilite (present uniquement si accounting.view) -->
+            <template v-if="canAccountingView" #accounting>
+                <div class="mt-12 flex flex-col gap-6">
+                    <div class="bg-white py-4 pl-[28px] pr-[60px] shadow-[0_4px_4px_0_rgba(0,0,0,0.25)]">
+                        <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                            <MalioInputText
+                                v-model="accounting.siren"
+                                :label="t('commercial.clients.form.accounting.siren')"
+                                :mask="SIREN_MASK"
+                                :readonly="accountingReadonly"
+                            />
+                            <MalioInputText
+                                v-model="accounting.accountNumber"
+                                :label="t('commercial.clients.form.accounting.accountNumber')"
+                                :readonly="accountingReadonly"
+                            />
+                            <MalioSelect
+                                :model-value="accounting.tvaModeIri"
+                                :options="referentials.tvaModes.value"
+                                :label="t('commercial.clients.form.accounting.tvaMode')"
+                                :disabled="accountingReadonly"
+                                empty-option-label=""
+                                @update:model-value="(v: string | number | null) => accounting.tvaModeIri = v === null ? null : String(v)"
+                            />
+                            <MalioInputText
+                                v-model="accounting.nTva"
+                                :label="t('commercial.clients.form.accounting.nTva')"
+                                :readonly="accountingReadonly"
+                            />
+                            <MalioSelect
+                                :model-value="accounting.paymentDelayIri"
+                                :options="referentials.paymentDelays.value"
+                                :label="t('commercial.clients.form.accounting.paymentDelay')"
+                                :disabled="accountingReadonly"
+                                empty-option-label=""
+                                @update:model-value="(v: string | number | null) => accounting.paymentDelayIri = v === null ? null : String(v)"
+                            />
+                            <MalioSelect
+                                :model-value="accounting.paymentTypeIri"
+                                :options="referentials.paymentTypes.value"
+                                :label="t('commercial.clients.form.accounting.paymentType')"
+                                :disabled="accountingReadonly"
+                                empty-option-label=""
+                                @update:model-value="onPaymentTypeChange"
+                            />
+                            <MalioSelect
+                                v-if="isBankRequired"
+                                :model-value="accounting.bankIri"
+                                :options="referentials.banks.value"
+                                :label="t('commercial.clients.form.accounting.bank')"
+                                :disabled="accountingReadonly"
+                                empty-option-label=""
+                                @update:model-value="(v: string | number | null) => accounting.bankIri = v === null ? null : String(v)"
+                            />
+                        </div>
+                    </div>
+
+                    <!-- Blocs RIB (0..n) — obligatoires si type de reglement = LCR. -->
+                    <div
+                        v-for="(rib, index) in ribs"
+                        :key="index"
+                        class="relative 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="!accountingReadonly"
+                            icon="mdi:delete-outline"
+                            variant="ghost"
+                            button-class="absolute top-3 right-3"
+                            v-bind="{ ariaLabel: t('commercial.clients.form.accounting.removeRib') }"
+                            @click="askRemoveRib(index)"
+                        />
+                        <div class="grid grid-cols-4 gap-x-[44px] gap-y-4">
+                            <MalioInputText
+                                v-model="rib.label"
+                                :label="t('commercial.clients.form.accounting.ribLabel')"
+                                :readonly="accountingReadonly"
+                            />
+                            <MalioInputText
+                                v-model="rib.bic"
+                                :label="t('commercial.clients.form.accounting.ribBic')"
+                                :readonly="accountingReadonly"
+                            />
+                            <MalioInputText
+                                v-model="rib.iban"
+                                :label="t('commercial.clients.form.accounting.ribIban')"
+                                :readonly="accountingReadonly"
+                            />
+                        </div>
+                    </div>
+
+                    <div v-if="!accountingReadonly" class="flex justify-center gap-6">
+                        <MalioButton
+                            variant="secondary"
+                            icon-name="mdi:add-bold"
+                            icon-position="left"
+                            :label="t('commercial.clients.form.accounting.addRib')"
+                            @click="addRib"
+                        />
+                        <MalioButton
+                            variant="primary"
+                            :label="t('commercial.clients.form.submit')"
+                            :disabled="!canValidateAccounting || tabSubmitting"
+                            @click="submitAccounting"
+                        />
+                    </div>
+                </div>
+            </template>
+
+            <!-- Onglet non encore implemente : frame vide, passage automatique.
+                 Statistiques / Rapports / Echanges sont edit-only (absents a la
+                 creation) — cf. buildClientFormTabKeys. -->
+            <template #transport><ComingSoonPlaceholder /></template>
+        </MalioTabList>
+
+        <!-- Modal de confirmation generique (suppression contact/adresse/RIB). -->
+        <MalioModal v-model="confirmModal.open" modal-class="max-w-md">
+            <template #header>
+                <h2 class="text-[24px] font-bold">{{ t('commercial.clients.form.confirmDelete.title') }}</h2>
+            </template>
+            <p>{{ confirmModal.message }}</p>
+            <template #footer>
+                <MalioButton
+                    variant="secondary"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.cancel')"
+                    @click="confirmModal.open = false"
+                />
+                <MalioButton
+                    variant="danger"
+                    button-class="flex-1"
+                    :label="t('commercial.clients.form.confirmDelete.confirm')"
+                    @click="runConfirm"
+                />
+            </template>
+        </MalioModal>
+    </div>
+</template>
+
+<script setup lang="ts">
+import { computed, onMounted, reactive, ref, watch } from 'vue'
+import { useClientReferentials, type RefOption } from '~/modules/commercial/composables/useClientReferentials'
+import {
+    buildClientFormTabKeys,
+    CLIENT_FORM_PLACEHOLDER_TABS,
+    hasAtLeastOneValidContact,
+    isBankRequiredForPaymentType,
+    isBillingEmailRequired,
+    isContactNamed,
+    isRibRequiredForPaymentType,
+} from '~/modules/commercial/utils/clientFormRules'
+import {
+    emptyAddress,
+    emptyContact,
+    emptyRib,
+    type AddressFormDraft,
+    type ContactFormDraft,
+    type RibFormDraft,
+} from '~/modules/commercial/types/clientForm'
+import { extractApiErrorMessage } from '~/shared/utils/api'
+
+// Masques de saisie (la normalisation finale reste serveur).
+const SIREN_MASK = '#########'
+// Masque « nombre » du champ Nombre de salaries : chiffres uniquement (max 7).
+const EMPLOYEES_MASK = '#######'
+
+// Codes de categorie interdits sur une adresse (RG-1.29, ERP-78).
+const FORBIDDEN_ADDRESS_CATEGORY_CODES = ['DISTRIBUTEUR', 'COURTIER']
+
+const { t } = useI18n()
+const api = useApi()
+const toast = useToast()
+const router = useRouter()
+const { can } = usePermissions()
+
+/** Retour vers le repertoire clients (fleche d'en-tete). */
+function goBack(): void {
+    router.push('/clients')
+}
+
+/**
+ * Message d'erreur a afficher dans un toast a partir d'une erreur d'API.
+ * Retourne TOUJOURS une chaine (le composant de toast plante sur `undefined`) :
+ * le message de validation renvoye par le serveur (violations 422 / detail),
+ * sinon un libelle generique.
+ */
+function apiErrorMessage(error: unknown): string {
+    const data = (error as { data?: unknown })?.data
+    return extractApiErrorMessage(data) || t('commercial.clients.toast.error')
+}
+
+useHead({ title: t('commercial.clients.form.title') })
+
+// Gating de la route : la creation est reservee a `manage`. Compta (accounting
+// seul) et Usine sont rediriges vers le repertoire (cf. §0 du ticket).
+if (!can('commercial.clients.manage')) {
+    await navigateTo('/clients')
+}
+
+const canAccountingView = computed(() => can('commercial.clients.accounting.view'))
+const canAccountingManage = computed(() => can('commercial.clients.accounting.manage'))
+
+const referentials = useClientReferentials()
+
+// ── Etat du client cree ────────────────────────────────────────────────────
+const clientId = ref<number | null>(null)
+const mainLocked = ref(false)
+const mainSubmitting = ref(false)
+const tabSubmitting = ref(false)
+
+// ── Formulaire principal ────────────────────────────────────────────────────
+const main = reactive({
+    companyName: null as string | null,
+    categoryIris: [] as string[],
+    relationType: null as 'distributeur' | 'courtier' | null,
+    distributorIri: null as string | null,
+    brokerIri: null as string | null,
+    triageService: false,
+})
+
+// Pas d'option « Aucun » : le select est vide par defaut (relationType = null).
+const relationOptions = computed<RefOption[]>(() => [
+    { value: 'distributeur', label: t('commercial.clients.form.main.relationDistributor') },
+    { value: 'courtier', label: t('commercial.clients.form.main.relationBroker') },
+])
+
+// Validation du formulaire principal (gate le bouton « Valider ») :
+//  - companyName / >= 1 categorie obligatoires ;
+//  - relation Distributeur/Courtier optionnelle, mais le nom correspondant
+//    devient requis si l'un des deux est choisi (spec fonctionnelle).
+// Les coordonnees de contact ne sont plus saisies ici : elles vivent dans
+// l'onglet Contacts (RG-1.05/1.14 garantissent >= 1 contact valide).
+const isMainValid = computed(() => {
+    const filled = (v: string | null | undefined) => v !== null && v !== undefined && v.trim() !== ''
+    // Relation Distributeur/Courtier OPTIONNELLE ; mais si « Depend du
+    // distributeur/courtier » est choisi, le nom correspondant devient requis.
+    const relationValid
+        = main.relationType === null
+        || (main.relationType === 'distributeur' && filled(main.distributorIri))
+        || (main.relationType === 'courtier' && filled(main.brokerIri))
+    return filled(main.companyName)
+        && main.categoryIris.length >= 1
+        && relationValid
+})
+
+async function onRelationChange(value: string | number | null): Promise<void> {
+    const relation = (value === null || value === '')
+        ? null
+        : (String(value) as 'distributeur' | 'courtier')
+    main.relationType = relation
+    // Reinitialise la FK non concernee (une seule remplie a la fois, RG-1.03).
+    if (relation !== 'distributeur') main.distributorIri = null
+    if (relation !== 'courtier') main.brokerIri = null
+
+    if (relation === 'distributeur') await referentials.loadDistributors()
+    if (relation === 'courtier') await referentials.loadBrokers()
+}
+
+/** POST /clients (groupe client:write:main). Au succes : verrouille + bascule Information. */
+async function submitMain(): Promise<void> {
+    if (!isMainValid.value || mainSubmitting.value) return
+    mainSubmitting.value = true
+    try {
+        const payload: Record<string, unknown> = {
+            companyName: main.companyName,
+            categories: main.categoryIris,
+            distributor: main.relationType === 'distributeur' ? main.distributorIri : null,
+            broker: main.relationType === 'courtier' ? main.brokerIri : null,
+            triageService: main.triageService,
+        }
+        const created = await api.post<ClientResponse>('/clients', payload, {
+            headers: { Accept: 'application/ld+json' },
+            toast: false,
+        })
+
+        clientId.value = created.id
+        // Reaffiche la valeur normalisee renvoyee par le serveur.
+        main.companyName = created.companyName ?? main.companyName
+
+        mainLocked.value = true
+        unlockedIndex.value = 0
+        activeTab.value = 'information'
+        toast.success({ title: t('commercial.clients.toast.createSuccess') })
+    }
+    catch (error) {
+        // 409 = doublon nom de societe (RG d'unicite) → message explicite ;
+        // sinon on remonte le message de validation du serveur (ex: 422).
+        const status = (error as { response?: { status?: number } })?.response?.status
+        toast.error({
+            title: t('commercial.clients.toast.error'),
+            message: status === 409
+                ? t('commercial.clients.form.duplicateCompany')
+                : apiErrorMessage(error),
+        })
+    }
+    finally {
+        mainSubmitting.value = false
+    }
+}
+
+// ── Onglets : ordre + gating progressif ─────────────────────────────────────
+const activeTab = ref('information')
+// Index du dernier onglet deverrouille (-1 tant que le client n'est pas cree).
+const unlockedIndex = ref(-1)
+// Onglets valides (passent en lecture seule).
+const validated = reactive<Record<string, boolean>>({})
+
+const tabKeys = computed(() => buildClientFormTabKeys(canAccountingView.value))
+
+// Icone (Iconify) affichee dans l'onglet, par cle. A ajuster librement.
+const TAB_ICONS: Record<string, string> = {
+    information: 'mdi:account-outline',
+    contact: 'mdi:account-box-plus-outline',
+    address: 'mdi:map-marker-outline',
+    transport: 'mdi:truck-delivery-outline',
+    accounting: 'mdi:bank-circle-outline',
+    statistics: 'mdi:finance',
+    reports: 'mdi:file-document-edit-outline',
+    exchanges: 'mdi:account-group-outline',
+}
+
+const tabs = computed(() => tabKeys.value.map((key, index) => ({
+    key,
+    label: t(`commercial.clients.tab.${key}`),
+    icon: TAB_ICONS[key],
+    disabled: index > unlockedIndex.value,
+})))
+
+function isValidated(key: string): boolean {
+    return validated[key] === true
+}
+
+function tabIndex(key: string): number {
+    return tabKeys.value.indexOf(key)
+}
+
+/** Marque l'onglet valide, deverrouille et avance automatiquement au suivant. */
+function completeTab(key: string): void {
+    validated[key] = true
+    const next = tabKeys.value[tabIndex(key) + 1]
+    unlockedIndex.value = Math.max(unlockedIndex.value, tabIndex(key) + 1)
+    if (next) activeTab.value = next
+}
+
+// Passage automatique sur les onglets coquille (Transport, Stats, Rapports, Echanges).
+watch(activeTab, (key) => {
+    if ((CLIENT_FORM_PLACEHOLDER_TABS as readonly string[]).includes(key)) {
+        const next = tabKeys.value[tabIndex(key) + 1]
+        unlockedIndex.value = Math.max(unlockedIndex.value, tabIndex(key) + 1)
+        if (next) activeTab.value = next
+    }
+})
+
+// ── Onglet Information ──────────────────────────────────────────────────────
+const information = reactive({
+    description: null as string | null,
+    competitors: null as string | null,
+    foundedAt: null as string | null,
+    employeesCount: null as string | null,
+    revenueAmount: null as string | null,
+    profitAmount: null as string | null,
+    directorName: null as string | null,
+})
+
+/** PATCH /clients/{id} — mode strict : uniquement les champs du groupe information. */
+async function submitInformation(): Promise<void> {
+    if (clientId.value === null || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        await api.patch(`/clients/${clientId.value}`, {
+            description: information.description || null,
+            competitors: information.competitors || null,
+            foundedAt: information.foundedAt || null,
+            employeesCount: information.employeesCount ? Number(information.employeesCount) : null,
+            revenueAmount: information.revenueAmount || null,
+            profitAmount: information.profitAmount || null,
+            directorName: information.directorName || null,
+        }, { toast: false })
+        completeTab('information')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (error) {
+        toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Contact ──────────────────────────────────────────────────────────
+// Au moins un bloc Contact vide au depart : c'est desormais le seul point de
+// saisie des coordonnees (le bloc principal ne porte plus de contact inline).
+const contacts = ref<ContactFormDraft[]>([emptyContact()])
+
+// « + Nouveau contact » desactive tant que le dernier bloc n'a ni nom ni prenom.
+const canAddContact = computed(() => {
+    const last = contacts.value[contacts.value.length - 1]
+    return last !== undefined && isContactNamed(last)
+})
+
+// RG-1.14 : au moins un contact nomme pour finaliser l'onglet.
+const canValidateContacts = computed(() => hasAtLeastOneValidContact(contacts.value))
+
+function addContact(): void {
+    if (canAddContact.value) contacts.value.push(emptyContact())
+}
+
+function askRemoveContact(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.contact'), () => {
+        contacts.value.splice(index, 1)
+    })
+}
+
+/** POST/PATCH des contacts sur la sous-ressource /clients/{id}/contacts. */
+async function submitContacts(): Promise<void> {
+    if (clientId.value === null || !canValidateContacts.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        for (const contact of contacts.value) {
+            // On ignore les blocs totalement vides (ni nom ni prenom).
+            if (!isContactNamed(contact)) continue
+
+            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 })
+            }
+        }
+        completeTab('contact')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (error) {
+        toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Adresse ──────────────────────────────────────────────────────────
+const addresses = ref<AddressFormDraft[]>([emptyAddress()])
+const addressDegradedNotified = ref(false)
+
+// Categories autorisees sur une adresse : toutes SAUF DISTRIBUTEUR/COURTIER (RG-1.29).
+const addressCategoryOptions = computed(() =>
+    referentials.categories.value.filter(c => !FORBIDDEN_ADDRESS_CATEGORY_CODES.includes(c.code)),
+)
+
+// Contacts deja crees, rattachables a une adresse (M2M, via leur IRI).
+const contactOptions = computed<RefOption[]>(() =>
+    contacts.value
+        .filter(c => c.iri !== null)
+        .map(c => ({
+            value: c.iri as string,
+            label: [c.firstName, c.lastName].filter(Boolean).join(' ') || (c.email ?? ''),
+        })),
+)
+
+// Pays disponibles (France preselectionnee par defaut sur chaque adresse).
+const countryOptions: RefOption[] = [
+    { value: 'France', label: 'France' },
+    { value: 'Espagne', label: 'Espagne' },
+]
+
+// RG-1.10 (>= 1 site) + RG-1.11 (email facturation si Facturation) sur chaque adresse.
+const canValidateAddresses = computed(() =>
+    addresses.value.length > 0
+    && addresses.value.every((a) => {
+        const filledBillingEmail = a.billingEmail !== null && a.billingEmail.trim() !== ''
+        return a.siteIris.length >= 1
+            && a.categoryIris.length >= 1
+            && (!isBillingEmailRequired(a) || filledBillingEmail)
+    }),
+)
+
+function addAddress(): void {
+    addresses.value.push(emptyAddress())
+}
+
+function askRemoveAddress(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.address'), () => {
+        addresses.value.splice(index, 1)
+    })
+}
+
+/** Avertit une seule fois quand l'autocompletion d'adresse bascule en degrade. */
+function onAddressDegraded(): void {
+    if (addressDegradedNotified.value) return
+    addressDegradedNotified.value = true
+    toast.warning({
+        title: t('commercial.clients.toast.error'),
+        message: t('commercial.clients.form.address.degraded'),
+    })
+}
+
+/** POST des adresses sur la sous-ressource /clients/{id}/addresses. */
+async function submitAddresses(): Promise<void> {
+    if (clientId.value === null || !canValidateAddresses.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        for (const address of addresses.value) {
+            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 })
+            }
+        }
+        completeTab('address')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (error) {
+        toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Onglet Comptabilite ─────────────────────────────────────────────────────
+const accounting = reactive({
+    siren: null as string | null,
+    accountNumber: null as string | null,
+    tvaModeIri: null as string | null,
+    nTva: null as string | null,
+    paymentDelayIri: null as string | null,
+    paymentTypeIri: null as string | null,
+    bankIri: null as string | null,
+})
+const ribs = ref<RibFormDraft[]>([])
+
+// L'onglet est editable seulement avec accounting.manage (sinon lecture seule).
+const accountingReadonly = computed(() => isValidated('accounting') || !canAccountingManage.value)
+
+// Code du type de reglement selectionne (pour RG-1.12 / RG-1.13).
+const selectedPaymentTypeCode = computed(() =>
+    referentials.paymentTypes.value.find(p => p.value === accounting.paymentTypeIri)?.code ?? null,
+)
+const isBankRequired = computed(() => isBankRequiredForPaymentType(selectedPaymentTypeCode.value))
+const isRibRequired = computed(() => isRibRequiredForPaymentType(selectedPaymentTypeCode.value))
+
+function onPaymentTypeChange(value: string | number | null): void {
+    accounting.paymentTypeIri = value === null ? null : String(value)
+    // La banque n'a de sens que pour un virement : on la vide sinon (RG-1.12).
+    if (!isBankRequired.value) accounting.bankIri = null
+}
+
+function ribIsComplete(rib: RibFormDraft): boolean {
+    const filled = (v: string | null) => v !== null && v.trim() !== ''
+    return filled(rib.label) && filled(rib.bic) && filled(rib.iban)
+}
+
+// RG-1.12 : banque requise si VIREMENT. RG-1.13 : >= 1 RIB complet si LCR.
+const canValidateAccounting = computed(() => {
+    if (isBankRequired.value && (accounting.bankIri === null)) return false
+    if (isRibRequired.value && !ribs.value.some(ribIsComplete)) return false
+    return true
+})
+
+function addRib(): void {
+    ribs.value.push(emptyRib())
+}
+
+function askRemoveRib(index: number): void {
+    askConfirm(t('commercial.clients.form.confirmDelete.rib'), () => {
+        ribs.value.splice(index, 1)
+        // Garde au moins un bloc RIB visible (cf. amorce au montage).
+        if (ribs.value.length === 0) ribs.value.push(emptyRib())
+    })
+}
+
+/**
+ * Valide l'onglet Comptabilite : PATCH des scalaires (groupe client:write:accounting)
+ * PUIS POST des RIB sur /clients/{id}/ribs. Deux appels distincts (mode strict
+ * RG-1.28 : il n'existe pas d'endpoint /accounting, cf. recon back).
+ */
+async function submitAccounting(): Promise<void> {
+    if (clientId.value === null || !canValidateAccounting.value || tabSubmitting.value) return
+    tabSubmitting.value = true
+    try {
+        await api.patch(`/clients/${clientId.value}`, {
+            siren: accounting.siren || null,
+            accountNumber: accounting.accountNumber || null,
+            tvaMode: accounting.tvaModeIri,
+            nTva: accounting.nTva || null,
+            paymentDelay: accounting.paymentDelayIri,
+            paymentType: accounting.paymentTypeIri,
+            bank: isBankRequired.value ? accounting.bankIri : null,
+        }, { toast: false })
+
+        for (const rib of ribs.value) {
+            if (!ribIsComplete(rib)) continue
+            if (rib.id === null) {
+                const created = await api.post<{ id: number }>(
+                    `/clients/${clientId.value}/ribs`,
+                    { label: rib.label, bic: rib.bic, iban: rib.iban },
+                    { headers: { Accept: 'application/ld+json' }, toast: false },
+                )
+                rib.id = created.id
+            }
+            else {
+                await api.patch(`/client_ribs/${rib.id}`, { label: rib.label, bic: rib.bic, iban: rib.iban }, { toast: false })
+            }
+        }
+
+        completeTab('accounting')
+        toast.success({ title: t('commercial.clients.toast.updateSuccess') })
+    }
+    catch (error) {
+        toast.error({ title: t('commercial.clients.toast.error'), message: apiErrorMessage(error) })
+    }
+    finally {
+        tabSubmitting.value = false
+    }
+}
+
+// ── Modal de confirmation generique ─────────────────────────────────────────
+const confirmModal = reactive({
+    open: false,
+    message: '',
+    action: null as null | (() => void),
+})
+
+function askConfirm(message: string, action: () => void): void {
+    confirmModal.message = message
+    confirmModal.action = action
+    confirmModal.open = true
+}
+
+function runConfirm(): void {
+    confirmModal.action?.()
+    confirmModal.action = null
+    confirmModal.open = false
+}
+
+// ── Types de reponse API ────────────────────────────────────────────────────
+interface ClientResponse {
+    id: number
+    companyName: string | null
+}
+
+interface ContactResponse {
+    '@id'?: string
+    id: number
+}
+
+onMounted(() => {
+    // Echec du chargement des referentiels non bloquant : les selects restent vides.
+    referentials.loadCommon().catch(() => {})
+    // Au moins un bloc RIB toujours visible en creation : on amorce un bloc vide
+    // (non persiste tant qu'incomplet — RG-1.13).
+    if (ribs.value.length === 0) ribs.value.push(emptyRib())
+})
+</script>

frontend/modules/commercial/pages/commercial.vue

@@ -1,7 +1,7 @@
 <template>
     <div>
-        <h1 class="text-xl font-bold text-primary-500 sm:text-2xl">{{ $t('commercial.title') }}</h1>
-        <p class="mt-4 text-neutral-500">{{ $t('commercial.welcome') }}</p>
+        <PageHeader>{{ $t('commercial.title') }}</PageHeader>
+        <p class="text-neutral-500">{{ $t('commercial.welcome') }}</p>
     </div>
 </template>
 

frontend/modules/commercial/types/clientForm.ts

@@ -0,0 +1,98 @@
+/**
+ * Types « brouillon » de l'ecran « Ajouter un client » (M1 Commercial).
+ *
+ * Ces interfaces decrivent l'etat LOCAL du formulaire (refs Vue), distinct des
+ * DTO de l'API : elles portent en plus des champs purement UI (`hasSecondaryPhone`)
+ * et l'`iri` Hydra des entites creees (necessaire pour rattacher une adresse a
+ * des contacts deja persistes, M2M). Partage par la page et les blocs reutilisables
+ * `ClientContactBlock` / `ClientAddressBlock` (reutilises par 1.11/1.12).
+ */
+
+/** Un contact du client (onglet Contact). */
+export interface ContactFormDraft {
+    /** Id serveur une fois le contact cree (null tant que non persiste). */
+    id: number | null
+    /** IRI Hydra du contact cree — utilise pour le rattachement M2M cote adresse. */
+    iri: string | null
+    firstName: string | null
+    lastName: string | null
+    jobTitle: string | null
+    phonePrimary: string | null
+    phoneSecondary: string | null
+    email: string | null
+    /** UI : le 2e numero a ete revele via le bouton « + ». */
+    hasSecondaryPhone: boolean
+}
+
+/** Une adresse du client (onglet Adresse). */
+export interface AddressFormDraft {
+    id: number | null
+    isProspect: boolean
+    isDelivery: boolean
+    isBilling: boolean
+    country: string
+    postalCode: string | null
+    city: string | null
+    street: string | null
+    streetComplement: string | null
+    /** IRI des categories rattachees (hors DISTRIBUTEUR/COURTIER — RG-1.29). */
+    categoryIris: string[]
+    /** IRI des sites Starseed rattaches (>= 1 obligatoire — RG-1.10). */
+    siteIris: string[]
+    /** IRI des contacts rattaches (= blocs Contact deja crees). */
+    contactIris: string[]
+    /** Email de facturation (obligatoire si isBilling — RG-1.11). */
+    billingEmail: string | null
+}
+
+/** Un RIB du client (onglet Comptabilite). */
+export interface RibFormDraft {
+    id: number | null
+    label: string | null
+    bic: string | null
+    iban: string | null
+}
+
+/** Fabrique un contact vierge. */
+export function emptyContact(): ContactFormDraft {
+    return {
+        id: null,
+        iri: null,
+        firstName: null,
+        lastName: null,
+        jobTitle: null,
+        phonePrimary: null,
+        phoneSecondary: null,
+        email: null,
+        hasSecondaryPhone: false,
+    }
+}
+
+/** Fabrique une adresse vierge (pays prerempli « France »). */
+export function emptyAddress(): AddressFormDraft {
+    return {
+        id: null,
+        isProspect: false,
+        isDelivery: false,
+        isBilling: false,
+        country: 'France',
+        postalCode: null,
+        city: null,
+        street: null,
+        streetComplement: null,
+        categoryIris: [],
+        siteIris: [],
+        contactIris: [],
+        billingEmail: null,
+    }
+}
+
+/** Fabrique un RIB vierge. */
+export function emptyRib(): RibFormDraft {
+    return {
+        id: null,
+        label: null,
+        bic: null,
+        iban: null,
+    }
+}

frontend/modules/commercial/utils/__tests__/clientConsultation.spec.ts

@@ -0,0 +1,235 @@
+import { describe, expect, it } from 'vitest'
+import {
+    canEditClient,
+    categoryOptionsOf,
+    contactOptionsOf,
+    iriOf,
+    mapAccountingDraft,
+    mapAddressToDraft,
+    mapAddressView,
+    mapContactToDraft,
+    mapRibToDraft,
+    referentialOptionOf,
+    relationOf,
+    showArchiveAction,
+    showRestoreAction,
+    siteOptionsOf,
+    type ClientDetail,
+} from '../clientConsultation'
+
+describe('iriOf', () => {
+    it('retourne l\'@id d\'une relation embarquee (objet)', () => {
+        expect(iriOf({ '@id': '/api/payment_types/10', code: 'LCR' })).toBe('/api/payment_types/10')
+    })
+
+    it('retourne la chaine telle quelle si la relation est deja un IRI', () => {
+        expect(iriOf('/api/banks/3')).toBe('/api/banks/3')
+    })
+
+    it('retourne null pour une relation absente (null / undefined / skip_null_values)', () => {
+        expect(iriOf(null)).toBeNull()
+        expect(iriOf(undefined)).toBeNull()
+    })
+})
+
+describe('relationOf', () => {
+    it('detecte une relation distributeur et expose son nom', () => {
+        const client = { distributor: { '@id': '/api/clients/15', companyName: 'DISTRIB GRAND SUD-OUEST' } } as ClientDetail
+        expect(relationOf(client)).toEqual({ type: 'distributeur', name: 'DISTRIB GRAND SUD-OUEST' })
+    })
+
+    it('detecte une relation courtier et expose son nom', () => {
+        const client = { broker: { '@id': '/api/clients/16', companyName: 'CABINET LEONARD' } } as ClientDetail
+        expect(relationOf(client)).toEqual({ type: 'courtier', name: 'CABINET LEONARD' })
+    })
+
+    it('retourne type null quand aucune relation n\'est posee (cles omises)', () => {
+        expect(relationOf({} as ClientDetail)).toEqual({ type: null, name: null })
+    })
+})
+
+describe('mapContactToDraft', () => {
+    it('formate les telephones en XX XX XX XX XX et conserve l\'iri', () => {
+        const draft = mapContactToDraft({
+            '@id': '/api/client_contacts/18',
+            id: 18,
+            firstName: 'Sophie',
+            lastName: 'Léonard',
+            jobTitle: 'Gérante',
+            phonePrimary: '0549112233',
+            email: 'sophie@x.fr',
+        })
+        expect(draft.id).toBe(18)
+        expect(draft.iri).toBe('/api/client_contacts/18')
+        expect(draft.phonePrimary).toBe('05 49 11 22 33')
+        expect(draft.hasSecondaryPhone).toBe(false)
+    })
+
+    it('revele le 2e telephone quand phoneSecondary est present', () => {
+        const draft = mapContactToDraft({
+            '@id': '/api/client_contacts/19',
+            id: 19,
+            phonePrimary: '0600000000',
+            phoneSecondary: '0611111111',
+        })
+        expect(draft.hasSecondaryPhone).toBe(true)
+        expect(draft.phoneSecondary).toBe('06 11 11 11 11')
+    })
+})
+
+describe('mapAddressToDraft', () => {
+    it('extrait les iris de sites / categories / contacts (objets ou chaines)', () => {
+        const draft = mapAddressToDraft({
+            '@id': '/api/client_addresses/18',
+            id: 18,
+            country: 'France',
+            postalCode: '86100',
+            city: 'Châtellerault',
+            street: '5 rue des Courtiers',
+            billingEmail: 'factures@x.fr',
+            isProspect: false,
+            isDelivery: false,
+            isBilling: true,
+            sites: [{ '@id': '/api/sites/4', name: 'Chatellerault', color: '#056CF2' }],
+            categories: [{ '@id': '/api/categories/3', code: 'SECTEUR' }],
+            contacts: [{ '@id': '/api/client_contacts/18' }, '/api/client_contacts/20'],
+        })
+        expect(draft.siteIris).toEqual(['/api/sites/4'])
+        expect(draft.categoryIris).toEqual(['/api/categories/3'])
+        expect(draft.contactIris).toEqual(['/api/client_contacts/18', '/api/client_contacts/20'])
+        expect(draft.isBilling).toBe(true)
+        expect(draft.city).toBe('Châtellerault')
+        expect(draft.country).toBe('France')
+    })
+
+    it('tolere les sous-collections absentes (defaut tableau vide, pays France)', () => {
+        const draft = mapAddressToDraft({ '@id': '/api/client_addresses/9', id: 9 })
+        expect(draft.siteIris).toEqual([])
+        expect(draft.categoryIris).toEqual([])
+        expect(draft.contactIris).toEqual([])
+        expect(draft.country).toBe('France')
+        expect(draft.isBilling).toBe(false)
+    })
+})
+
+describe('mapRibToDraft', () => {
+    it('mappe label / bic / iban et l\'id serveur', () => {
+        const draft = mapRibToDraft({ '@id': '/api/client_ribs/3', id: 3, label: 'Compte', bic: 'BNPAFRPPXXX', iban: 'FR14...' })
+        expect(draft).toEqual({ id: 3, label: 'Compte', bic: 'BNPAFRPPXXX', iban: 'FR14...' })
+    })
+})
+
+describe('mapAccountingDraft', () => {
+    it('mappe les scalaires et resout les iris des referentiels embarques', () => {
+        const acc = mapAccountingDraft({
+            '@id': '/api/clients/1',
+            id: 1,
+            siren: '123456789',
+            accountNumber: '411000',
+            nTva: 'FR123',
+            tvaMode: { '@id': '/api/tva_modes/1' },
+            paymentDelay: { '@id': '/api/payment_delays/2' },
+            paymentType: { '@id': '/api/payment_types/10', code: 'LCR' },
+            bank: { '@id': '/api/banks/3' },
+        } as ClientDetail)
+        expect(acc).toEqual({
+            siren: '123456789',
+            accountNumber: '411000',
+            nTva: 'FR123',
+            tvaModeIri: '/api/tva_modes/1',
+            paymentDelayIri: '/api/payment_delays/2',
+            paymentTypeIri: '/api/payment_types/10',
+            bankIri: '/api/banks/3',
+        })
+    })
+
+    it('renvoie des null quand les champs comptables sont absents (sans accounting.view)', () => {
+        const acc = mapAccountingDraft({} as ClientDetail)
+        expect(acc).toEqual({
+            siren: null,
+            accountNumber: null,
+            nTva: null,
+            tvaModeIri: null,
+            paymentDelayIri: null,
+            paymentTypeIri: null,
+            bankIri: null,
+        })
+    })
+})
+
+describe('options construites depuis l\'embed (role-independantes)', () => {
+    it('categoryOptionsOf expose value=IRI, label=nom, code', () => {
+        expect(categoryOptionsOf([{ '@id': '/api/categories/3', name: 'Secteur', code: 'SECTEUR' }])).toEqual([
+            { value: '/api/categories/3', label: 'Secteur', code: 'SECTEUR' },
+        ])
+    })
+
+    it('siteOptionsOf expose value=IRI, label=nom', () => {
+        expect(siteOptionsOf([{ '@id': '/api/sites/4', name: 'Chatellerault', color: '#000' }])).toEqual([
+            { value: '/api/sites/4', label: 'Chatellerault' },
+        ])
+    })
+
+    it('contactOptionsOf compose le libelle (nom complet, sinon email)', () => {
+        expect(contactOptionsOf([
+            { '@id': '/api/client_contacts/1', id: 1, firstName: 'Jean', lastName: 'Dupont' },
+            { '@id': '/api/client_contacts/2', id: 2, email: 'a@b.fr' },
+        ])).toEqual([
+            { value: '/api/client_contacts/1', label: 'Jean Dupont' },
+            { value: '/api/client_contacts/2', label: 'a@b.fr' },
+        ])
+    })
+
+    it('referentialOptionOf : option unique depuis l\'embed, vide pour IRI nu / absent', () => {
+        expect(referentialOptionOf({ '@id': '/api/payment_types/10', label: 'LCR' })).toEqual([
+            { value: '/api/payment_types/10', label: 'LCR' },
+        ])
+        expect(referentialOptionOf('/api/banks/3')).toEqual([])
+        expect(referentialOptionOf(null)).toEqual([])
+    })
+
+    it('mapAddressView assemble brouillon + options propres a l\'adresse', () => {
+        const view = mapAddressView({
+            '@id': '/api/client_addresses/18',
+            id: 18,
+            city: 'Châtellerault',
+            sites: [{ '@id': '/api/sites/4', name: 'Chatellerault' }],
+            categories: [{ '@id': '/api/categories/3', name: 'Secteur', code: 'SECTEUR' }],
+        })
+        expect(view.draft.id).toBe(18)
+        expect(view.siteOptions).toEqual([{ value: '/api/sites/4', label: 'Chatellerault' }])
+        expect(view.categoryOptions).toEqual([{ value: '/api/categories/3', label: 'Secteur', code: 'SECTEUR' }])
+    })
+})
+
+describe('canEditClient', () => {
+    const can = (granted: string[]) => (codes: string[]) => codes.some(c => granted.includes(c))
+
+    it('visible pour manage', () => {
+        expect(canEditClient(can(['commercial.clients.manage']))).toBe(true)
+    })
+
+    it('visible pour accounting.manage (role Compta)', () => {
+        expect(canEditClient(can(['commercial.clients.accounting.manage']))).toBe(true)
+    })
+
+    it('masque sans aucune des deux permissions (role Usine)', () => {
+        expect(canEditClient(can(['commercial.clients.view']))).toBe(false)
+    })
+})
+
+describe('showArchiveAction / showRestoreAction', () => {
+    const can = (granted: string[]) => (code: string) => granted.includes(code)
+
+    it('Archiver : visible avec la permission archive ET client non archive', () => {
+        expect(showArchiveAction(can(['commercial.clients.archive']), false)).toBe(true)
+        expect(showArchiveAction(can(['commercial.clients.archive']), true)).toBe(false)
+        expect(showArchiveAction(can([]), false)).toBe(false)
+    })
+
+    it('Restaurer : visible avec la permission archive ET client archive', () => {
+        expect(showRestoreAction(can(['commercial.clients.archive']), true)).toBe(true)
+        expect(showRestoreAction(can(['commercial.clients.archive']), false)).toBe(false)
+        expect(showRestoreAction(can([]), true)).toBe(false)
+    })
+})

frontend/modules/commercial/utils/__tests__/clientEdit.spec.ts

@@ -0,0 +1,241 @@
+import { describe, expect, it } from 'vitest'
+import {
+    buildAccountingPayload,
+    buildAddressPayload,
+    buildContactPayload,
+    buildInformationPayload,
+    buildMainPayload,
+    buildRibPayload,
+    mapAccountingFormDraft,
+    mapInformationDraft,
+    mapMainDraft,
+    resolveTabEditability,
+    type AccountingFormDraft,
+    type InformationFormDraft,
+    type MainFormDraft,
+} from '../clientEdit'
+import type { ClientDetail } from '../clientConsultation'
+import type { AddressFormDraft, ContactFormDraft, RibFormDraft } from '~/modules/commercial/types/clientForm'
+
+// ── Fabriques de brouillons (valeurs distinctes pour reperer les fuites) ─────
+
+function mainDraft(overrides: Partial<MainFormDraft> = {}): MainFormDraft {
+    return {
+        companyName: 'ACME',
+        categoryIris: ['/api/categories/1'],
+        relationType: null,
+        distributorIri: null,
+        brokerIri: null,
+        triageService: false,
+        ...overrides,
+    }
+}
+
+function informationDraft(overrides: Partial<InformationFormDraft> = {}): InformationFormDraft {
+    return {
+        description: 'desc',
+        competitors: 'concurrents',
+        foundedAt: '2010-05-01',
+        employeesCount: '42',
+        revenueAmount: '1000000',
+        profitAmount: '50000',
+        directorName: 'PDG',
+        ...overrides,
+    }
+}
+
+function accountingDraft(overrides: Partial<AccountingFormDraft> = {}): AccountingFormDraft {
+    return {
+        siren: '123456789',
+        accountNumber: 'C-001',
+        nTva: 'FR123',
+        tvaModeIri: '/api/tva_modes/1',
+        paymentDelayIri: '/api/payment_delays/1',
+        paymentTypeIri: '/api/payment_types/1',
+        bankIri: '/api/banks/1',
+        ...overrides,
+    }
+}
+
+// Champs de chaque groupe de serialisation (miroir back ClientProcessor).
+// Le contact inline (nom/prenom/telephones/email) ne fait plus partie du groupe
+// main : les coordonnees vivent desormais sur la sous-ressource ClientContact.
+const MAIN_KEYS = [
+    'companyName', 'categories', 'distributor', 'broker', 'triageService',
+]
+const INFORMATION_KEYS = [
+    'description', 'competitors', 'foundedAt', 'employeesCount',
+    'revenueAmount', 'profitAmount', 'directorName',
+]
+const ACCOUNTING_KEYS = ['siren', 'accountNumber', 'tvaMode', 'nTva', 'paymentDelay', 'paymentType', 'bank']
+
+describe('buildMainPayload — scoping strict groupe client:write:main', () => {
+    it('n\'expose QUE les champs du groupe main (aucune fuite information/accounting)', () => {
+        expect(Object.keys(buildMainPayload(mainDraft())).sort()).toEqual([...MAIN_KEYS].sort())
+    })
+
+    it('relation distributeur : renseigne distributor, force broker a null (RG-1.03)', () => {
+        const payload = buildMainPayload(mainDraft({
+            relationType: 'distributeur',
+            distributorIri: '/api/clients/9',
+            brokerIri: '/api/clients/7',
+        }))
+        expect(payload.distributor).toBe('/api/clients/9')
+        expect(payload.broker).toBeNull()
+    })
+
+    it('relation courtier : renseigne broker, force distributor a null (RG-1.03)', () => {
+        const payload = buildMainPayload(mainDraft({
+            relationType: 'courtier',
+            distributorIri: '/api/clients/9',
+            brokerIri: '/api/clients/7',
+        }))
+        expect(payload.broker).toBe('/api/clients/7')
+        expect(payload.distributor).toBeNull()
+    })
+
+    it('sans relation : distributor et broker a null', () => {
+        const payload = buildMainPayload(mainDraft({ relationType: null }))
+        expect(payload.distributor).toBeNull()
+        expect(payload.broker).toBeNull()
+    })
+})
+
+describe('buildInformationPayload — scoping strict groupe client:write:information', () => {
+    it('n\'expose QUE les champs du groupe information (aucune fuite main/accounting)', () => {
+        expect(Object.keys(buildInformationPayload(informationDraft())).sort()).toEqual([...INFORMATION_KEYS].sort())
+    })
+
+    it('convertit employeesCount en nombre et vide -> null', () => {
+        expect(buildInformationPayload(informationDraft({ employeesCount: '42' })).employeesCount).toBe(42)
+        expect(buildInformationPayload(informationDraft({ employeesCount: null })).employeesCount).toBeNull()
+        expect(buildInformationPayload(informationDraft({ employeesCount: '' })).employeesCount).toBeNull()
+    })
+
+    it('chaines vides normalisees en null', () => {
+        const payload = buildInformationPayload(informationDraft({ description: '', directorName: '' }))
+        expect(payload.description).toBeNull()
+        expect(payload.directorName).toBeNull()
+    })
+})
+
+describe('buildAccountingPayload — scoping strict groupe client:write:accounting', () => {
+    it('n\'expose QUE les champs du groupe accounting (aucune fuite main/information)', () => {
+        expect(Object.keys(buildAccountingPayload(accountingDraft(), true)).sort()).toEqual([...ACCOUNTING_KEYS].sort())
+    })
+
+    it('banque conservee si requise (Virement), forcee a null sinon (RG-1.12)', () => {
+        expect(buildAccountingPayload(accountingDraft(), true).bank).toBe('/api/banks/1')
+        expect(buildAccountingPayload(accountingDraft(), false).bank).toBeNull()
+    })
+})
+
+describe('buildContactPayload / buildAddressPayload / buildRibPayload', () => {
+    it('contact : telephone secondaire ignore si non revele', () => {
+        const contact: ContactFormDraft = {
+            id: 5, iri: '/api/client_contacts/5', firstName: 'A', lastName: 'B',
+            jobTitle: null, phonePrimary: '0549112233', phoneSecondary: '0600000000',
+            email: null, hasSecondaryPhone: false,
+        }
+        expect(buildContactPayload(contact).phoneSecondary).toBeNull()
+    })
+
+    it('adresse : email facturation conserve uniquement si requis (RG-1.11)', () => {
+        const address: AddressFormDraft = {
+            id: 3, isProspect: false, isDelivery: false, isBilling: true, country: 'France',
+            postalCode: '86100', city: 'Châtellerault', street: '1 rue X', streetComplement: null,
+            categoryIris: ['/api/categories/2'], siteIris: ['/api/sites/1'], contactIris: [],
+            billingEmail: 'facturation@acme.fr',
+        }
+        expect(buildAddressPayload(address, true).billingEmail).toBe('facturation@acme.fr')
+        expect(buildAddressPayload(address, false).billingEmail).toBeNull()
+    })
+
+    it('rib : label / bic / iban transmis tels quels', () => {
+        const rib: RibFormDraft = { id: 1, label: 'Compte principal', bic: 'BNPAFRPP', iban: 'FR76...' }
+        expect(buildRibPayload(rib)).toEqual({ label: 'Compte principal', bic: 'BNPAFRPP', iban: 'FR76...' })
+    })
+})
+
+describe('mapMainDraft — pre-remplissage bloc principal', () => {
+    it('resout la relation et extrait les IRI (sans contact inline)', () => {
+        const client = {
+            '@id': '/api/clients/1', id: 1,
+            companyName: 'ACME', triageService: true,
+            categories: [{ '@id': '/api/categories/1', code: 'SECTEUR' }],
+            distributor: { '@id': '/api/clients/9', companyName: 'DISTRIB' },
+        } as ClientDetail
+
+        const draft = mapMainDraft(client)
+        expect(draft.companyName).toBe('ACME')
+        expect(draft.categoryIris).toEqual(['/api/categories/1'])
+        expect(draft.relationType).toBe('distributeur')
+        expect(draft.distributorIri).toBe('/api/clients/9')
+        expect(draft.brokerIri).toBeNull()
+        expect(draft.triageService).toBe(true)
+    })
+
+    it('gere les cles omises (skip_null_values) sans planter', () => {
+        const draft = mapMainDraft({ '@id': '/api/clients/2', id: 2 } as ClientDetail)
+        expect(draft.companyName).toBeNull()
+        expect(draft.categoryIris).toEqual([])
+        expect(draft.relationType).toBeNull()
+        expect(draft.triageService).toBe(false)
+    })
+})
+
+describe('mapInformationDraft — pre-remplissage onglet Information', () => {
+    it('tronque foundedAt en YYYY-MM-DD et stringifie employeesCount', () => {
+        const draft = mapInformationDraft({
+            '@id': '/api/clients/1', id: 1,
+            foundedAt: '2010-05-01T00:00:00+00:00', employeesCount: 42, revenueAmount: '1000000',
+        } as ClientDetail)
+        expect(draft.foundedAt).toBe('2010-05-01')
+        expect(draft.employeesCount).toBe('42')
+        expect(draft.revenueAmount).toBe('1000000')
+    })
+
+    it('cles omises -> null', () => {
+        const draft = mapInformationDraft({ '@id': '/api/clients/1', id: 1 } as ClientDetail)
+        expect(draft.foundedAt).toBeNull()
+        expect(draft.employeesCount).toBeNull()
+        expect(draft.description).toBeNull()
+    })
+})
+
+describe('mapAccountingFormDraft — pre-remplissage onglet Comptabilite', () => {
+    it('extrait les scalaires et les IRI des referentiels embarques', () => {
+        const draft = mapAccountingFormDraft({
+            '@id': '/api/clients/1', id: 1,
+            siren: '123456789', accountNumber: 'C-001', nTva: 'FR123',
+            tvaMode: { '@id': '/api/tva_modes/2', label: 'Normal' },
+            paymentType: '/api/payment_types/3',
+        } as ClientDetail)
+        expect(draft.siren).toBe('123456789')
+        expect(draft.tvaModeIri).toBe('/api/tva_modes/2')
+        expect(draft.paymentTypeIri).toBe('/api/payment_types/3')
+        expect(draft.bankIri).toBeNull()
+    })
+})
+
+describe('resolveTabEditability — gating par role (matrice § 2.7)', () => {
+    it('Admin : tout editable', () => {
+        expect(resolveTabEditability({ canManage: true, canAccountingView: true, canAccountingManage: true }))
+            .toEqual({ businessEditable: true, accountingVisible: true, accountingEditable: true })
+    })
+
+    it('Bureau / Commerciale (manage seul) : metier editable, Comptabilite masquee', () => {
+        expect(resolveTabEditability({ canManage: true, canAccountingView: false, canAccountingManage: false }))
+            .toEqual({ businessEditable: true, accountingVisible: false, accountingEditable: false })
+    })
+
+    it('Compta (accounting seul) : metier readonly, Comptabilite editable', () => {
+        expect(resolveTabEditability({ canManage: false, canAccountingView: true, canAccountingManage: true }))
+            .toEqual({ businessEditable: false, accountingVisible: true, accountingEditable: true })
+    })
+
+    it('Sans permission d\'edition : rien d\'editable', () => {
+        expect(resolveTabEditability({ canManage: false, canAccountingView: false, canAccountingManage: false }))
+            .toEqual({ businessEditable: false, accountingVisible: false, accountingEditable: false })
+    })
+})

frontend/modules/commercial/utils/__tests__/clientFormRules.spec.ts

@@ -0,0 +1,152 @@
+import { describe, it, expect } from 'vitest'
+import {
+    applyProspectExclusivity,
+    buildClientFormTabKeys,
+    canSelectDeliveryOrBilling,
+    canSelectProspect,
+    hasAtLeastOneValidContact,
+    isBankRequiredForPaymentType,
+    isBillingEmailRequired,
+    isContactNamed,
+    isRibRequiredForPaymentType,
+    type ContactDraft,
+} from '../clientFormRules'
+
+describe('buildClientFormTabKeys (gating onglet Comptabilite + onglets edit-only)', () => {
+    it('inclut l onglet accounting si l utilisateur a accounting.view', () => {
+        expect(buildClientFormTabKeys(true)).toContain('accounting')
+    })
+
+    it('exclut l onglet accounting sinon (Bureau / Commerciale)', () => {
+        expect(buildClientFormTabKeys(false)).not.toContain('accounting')
+    })
+
+    it('a la creation, exclut Statistiques / Rapports / Echanges', () => {
+        const keys = buildClientFormTabKeys(true)
+        expect(keys).toEqual(['information', 'contact', 'address', 'transport', 'accounting'])
+        expect(keys).not.toContain('statistics')
+        expect(keys).not.toContain('reports')
+        expect(keys).not.toContain('exchanges')
+    })
+
+    it('en modification (includeEditOnlyTabs), ajoute les onglets edit-only en fin', () => {
+        const keys = buildClientFormTabKeys(true, { includeEditOnlyTabs: true })
+        expect(keys).toEqual([
+            'information',
+            'contact',
+            'address',
+            'transport',
+            'accounting',
+            'statistics',
+            'reports',
+            'exchanges',
+        ])
+    })
+})
+
+describe('isContactNamed (RG-1.05)', () => {
+    it('vrai si le prenom est renseigne', () => {
+        expect(isContactNamed({ firstName: 'Alice', lastName: null })).toBe(true)
+    })
+
+    it('vrai si le nom est renseigne', () => {
+        expect(isContactNamed({ firstName: null, lastName: 'Martin' })).toBe(true)
+    })
+
+    it('faux si les deux sont vides ou espaces uniquement', () => {
+        expect(isContactNamed({ firstName: null, lastName: null })).toBe(false)
+        expect(isContactNamed({ firstName: '  ', lastName: '' })).toBe(false)
+    })
+})
+
+describe('hasAtLeastOneValidContact (RG-1.14)', () => {
+    it('faux sur une liste vide', () => {
+        expect(hasAtLeastOneValidContact([])).toBe(false)
+    })
+
+    it('faux si aucun contact n a de nom ni prenom', () => {
+        const contacts: ContactDraft[] = [
+            { firstName: null, lastName: null },
+            { firstName: '', lastName: '  ' },
+        ]
+        expect(hasAtLeastOneValidContact(contacts)).toBe(false)
+    })
+
+    it('vrai des qu un contact a un nom ou un prenom', () => {
+        const contacts: ContactDraft[] = [
+            { firstName: null, lastName: null },
+            { firstName: 'Bob', lastName: null },
+        ]
+        expect(hasAtLeastOneValidContact(contacts)).toBe(true)
+    })
+})
+
+describe('exclusivite Prospect / Livraison / Facturation (RG-1.06/07/08)', () => {
+    it('Prospect est selectionnable tant que ni Livraison ni Facturation', () => {
+        expect(canSelectProspect({ isProspect: false, isDelivery: false, isBilling: false })).toBe(true)
+        expect(canSelectProspect({ isProspect: false, isDelivery: true, isBilling: false })).toBe(false)
+        expect(canSelectProspect({ isProspect: false, isDelivery: false, isBilling: true })).toBe(false)
+    })
+
+    it('Livraison / Facturation selectionnables tant que pas Prospect', () => {
+        expect(canSelectDeliveryOrBilling({ isProspect: false, isDelivery: false, isBilling: false })).toBe(true)
+        expect(canSelectDeliveryOrBilling({ isProspect: true, isDelivery: false, isBilling: false })).toBe(false)
+    })
+
+    it('cocher Prospect efface Livraison et Facturation', () => {
+        const next = applyProspectExclusivity(
+            { isProspect: false, isDelivery: true, isBilling: true },
+            'isProspect',
+            true,
+        )
+        expect(next).toEqual({ isProspect: true, isDelivery: false, isBilling: false })
+    })
+
+    it('cocher Livraison efface Prospect', () => {
+        const next = applyProspectExclusivity(
+            { isProspect: true, isDelivery: false, isBilling: false },
+            'isDelivery',
+            true,
+        )
+        expect(next).toEqual({ isProspect: false, isDelivery: true, isBilling: false })
+    })
+
+    it('cocher Facturation efface Prospect mais conserve Livraison', () => {
+        const next = applyProspectExclusivity(
+            { isProspect: true, isDelivery: true, isBilling: false },
+            'isBilling',
+            true,
+        )
+        expect(next).toEqual({ isProspect: false, isDelivery: true, isBilling: true })
+    })
+
+    it('decocher un drapeau ne reactive rien d autre', () => {
+        const next = applyProspectExclusivity(
+            { isProspect: false, isDelivery: true, isBilling: true },
+            'isBilling',
+            false,
+        )
+        expect(next).toEqual({ isProspect: false, isDelivery: true, isBilling: false })
+    })
+})
+
+describe('isBillingEmailRequired (RG-1.11)', () => {
+    it('obligatoire uniquement si Facturation est coche', () => {
+        expect(isBillingEmailRequired({ isProspect: false, isDelivery: false, isBilling: true })).toBe(true)
+        expect(isBillingEmailRequired({ isProspect: false, isDelivery: true, isBilling: false })).toBe(false)
+    })
+})
+
+describe('regles type de reglement (RG-1.12 / RG-1.13)', () => {
+    it('banque obligatoire si VIREMENT', () => {
+        expect(isBankRequiredForPaymentType('VIREMENT')).toBe(true)
+        expect(isBankRequiredForPaymentType('LCR')).toBe(false)
+        expect(isBankRequiredForPaymentType(null)).toBe(false)
+    })
+
+    it('RIB obligatoire si LCR', () => {
+        expect(isRibRequiredForPaymentType('LCR')).toBe(true)
+        expect(isRibRequiredForPaymentType('VIREMENT')).toBe(false)
+        expect(isRibRequiredForPaymentType(null)).toBe(false)
+    })
+})

frontend/modules/commercial/utils/clientConsultation.ts

@@ -0,0 +1,316 @@
+/**
+ * Helpers purs de l'ecran « Consultation client » (M1 Commercial, lecture seule).
+ *
+ * Mappent le payload `GET /api/clients/{id}` (relations embarquees, cf. groupe
+ * `client:item:read` + `client:read:accounting`) vers les brouillons « plats »
+ * partages avec les blocs reutilisables `ClientContactBlock` / `ClientAddressBlock`
+ * et l'onglet Comptabilite. Ne touchent ni a l'API ni a l'etat reactif : testables
+ * unitairement (cf. clientConsultation.spec.ts).
+ *
+ * Rappels de contrat back (verifies sur l'API reelle) :
+ *  - les relations ManyToOne (distributor/broker/tvaMode/paymentType/...) sont
+ *    serialisees en OBJETS embarques (avec @id + companyName/code/label), pas en IRI nu ;
+ *  - les champs nuls sont OMIS du JSON (skip_null_values) → toujours lire avec `?? null` ;
+ *  - les champs comptables et `ribs` sont TOTALEMENT ABSENTS sans permission
+ *    accounting.view (gate serveur via ClientReadGroupContextBuilder).
+ */
+
+import { formatPhoneFR } from '~/shared/utils/phone'
+import type {
+    AddressFormDraft,
+    ContactFormDraft,
+    RibFormDraft,
+} from '~/modules/commercial/types/clientForm'
+
+/** Reference Hydra embarquee minimale (@id toujours present). */
+export interface HydraRef {
+    '@id': string
+    [key: string]: unknown
+}
+
+/** Une relation peut etre embarquee (objet), un IRI nu (chaine) ou absente. */
+export type Relation = HydraRef | string | null | undefined
+
+/** Site embarque dans une adresse (groupe site:read). */
+export interface SiteRead extends HydraRef {
+    name?: string
+    color?: string
+}
+
+/** Categorie embarquee (groupe category:read). */
+export interface CategoryRead extends HydraRef {
+    code?: string
+    name?: string
+}
+
+/** Contact embarque (groupe client_contact:read). */
+export interface ContactRead extends HydraRef {
+    id: number
+    firstName?: string | null
+    lastName?: string | null
+    jobTitle?: string | null
+    phonePrimary?: string | null
+    phoneSecondary?: string | null
+    email?: string | null
+}
+
+/** Adresse embarquee (groupe client_address:read). */
+export interface AddressRead extends HydraRef {
+    id: number
+    country?: string | null
+    postalCode?: string | null
+    city?: string | null
+    street?: string | null
+    streetComplement?: string | null
+    billingEmail?: string | null
+    isProspect?: boolean
+    isDelivery?: boolean
+    isBilling?: boolean
+    sites?: SiteRead[]
+    categories?: CategoryRead[]
+    // L'embed M2M des contacts d'adresse peut etre un objet (partiel) ou un IRI nu.
+    contacts?: Array<HydraRef | string>
+}
+
+/** RIB embarque (groupe client:read:accounting, present ssi accounting.view). */
+export interface RibRead extends HydraRef {
+    id: number
+    label?: string | null
+    bic?: string | null
+    iban?: string | null
+}
+
+/** Client relie (distributeur / courtier) embarque (groupe client:read). */
+export interface RelatedClientRead extends HydraRef {
+    companyName?: string | null
+}
+
+/**
+ * Detail d'un client tel que renvoye par `GET /api/clients/{id}`. Tous les
+ * champs sont optionnels : skip_null_values cote serveur et gating accounting
+ * peuvent omettre n'importe quelle cle.
+ */
+export interface ClientDetail extends HydraRef {
+    id: number
+    companyName?: string | null
+    triageService?: boolean
+    isArchived?: boolean
+    categories?: CategoryRead[]
+    distributor?: RelatedClientRead | string | null
+    broker?: RelatedClientRead | string | null
+    contacts?: ContactRead[]
+    addresses?: AddressRead[]
+    ribs?: RibRead[]
+    // Onglet Information
+    description?: string | null
+    competitors?: string | null
+    foundedAt?: string | null
+    employeesCount?: number | null
+    revenueAmount?: string | null
+    profitAmount?: string | null
+    directorName?: string | null
+    // Onglet Comptabilite (present ssi accounting.view)
+    siren?: string | null
+    accountNumber?: string | null
+    nTva?: string | null
+    tvaMode?: Relation
+    paymentDelay?: Relation
+    paymentType?: Relation
+    bank?: Relation
+}
+
+/** Etat « plat » de l'onglet Comptabilite (miroir lecture du formulaire 1.10). */
+export interface AccountingDraft {
+    siren: string | null
+    accountNumber: string | null
+    nTva: string | null
+    tvaModeIri: string | null
+    paymentDelayIri: string | null
+    paymentTypeIri: string | null
+    bankIri: string | null
+}
+
+/** Relation Distributeur/Courtier resolue pour l'affichage en lecture seule. */
+export interface ClientRelation {
+    type: 'distributeur' | 'courtier' | null
+    name: string | null
+}
+
+/** Option de select ({ value, label }) construite a partir de l'embed. */
+export interface SelectOption {
+    value: string
+    label: string
+}
+
+/** Option de categorie enrichie de son code (compatible CategoryOption des blocs). */
+export interface CategorySelectOption extends SelectOption {
+    code: string
+}
+
+/**
+ * Vue d'une adresse pour la consultation : le brouillon + ses options de select
+ * construites a partir de l'embed (sites/categories propres a CETTE adresse).
+ */
+export interface AddressView {
+    draft: AddressFormDraft
+    siteOptions: SelectOption[]
+    categoryOptions: CategorySelectOption[]
+}
+
+/** Extrait l'IRI d'une relation (objet embarque, IRI nu, ou null si absente). */
+export function iriOf(relation: Relation): string | null {
+    if (relation === null || relation === undefined) {
+        return null
+    }
+    if (typeof relation === 'string') {
+        return relation
+    }
+    return relation['@id'] ?? null
+}
+
+/**
+ * Resout la relation Distributeur/Courtier (RG-1.03 : mutuellement exclusives).
+ * Le nom est lu sur l'objet embarque (`companyName`) ; null si la relation est
+ * un IRI nu ou absente.
+ */
+export function relationOf(client: ClientDetail): ClientRelation {
+    const nameOf = (rel: RelatedClientRead | string | null | undefined): string | null =>
+        rel && typeof rel === 'object' ? (rel.companyName ?? null) : null
+
+    if (client.distributor) {
+        return { type: 'distributeur', name: nameOf(client.distributor) }
+    }
+    if (client.broker) {
+        return { type: 'courtier', name: nameOf(client.broker) }
+    }
+    return { type: null, name: null }
+}
+
+/** Mappe un contact embarque vers un brouillon (telephones formates XX XX XX XX XX). */
+export function mapContactToDraft(contact: ContactRead): ContactFormDraft {
+    const phoneSecondary = contact.phoneSecondary ?? null
+    return {
+        id: contact.id,
+        iri: contact['@id'] ?? null,
+        firstName: contact.firstName ?? null,
+        lastName: contact.lastName ?? null,
+        jobTitle: contact.jobTitle ?? null,
+        phonePrimary: contact.phonePrimary ? formatPhoneFR(contact.phonePrimary) : null,
+        phoneSecondary: phoneSecondary ? formatPhoneFR(phoneSecondary) : null,
+        email: contact.email ?? null,
+        hasSecondaryPhone: phoneSecondary !== null && phoneSecondary !== '',
+    }
+}
+
+/** Mappe une adresse embarquee vers un brouillon (IRI extraits des sous-collections). */
+export function mapAddressToDraft(address: AddressRead): AddressFormDraft {
+    return {
+        id: address.id,
+        isProspect: address.isProspect ?? false,
+        isDelivery: address.isDelivery ?? false,
+        isBilling: address.isBilling ?? false,
+        country: address.country ?? 'France',
+        postalCode: address.postalCode ?? null,
+        city: address.city ?? null,
+        street: address.street ?? null,
+        streetComplement: address.streetComplement ?? null,
+        categoryIris: (address.categories ?? []).map(c => c['@id']),
+        siteIris: (address.sites ?? []).map(s => s['@id']),
+        contactIris: (address.contacts ?? []).map(c => (typeof c === 'string' ? c : c['@id'])),
+        billingEmail: address.billingEmail ?? null,
+    }
+}
+
+/** Mappe un RIB embarque vers un brouillon. */
+export function mapRibToDraft(rib: RibRead): RibFormDraft {
+    return {
+        id: rib.id,
+        label: rib.label ?? null,
+        bic: rib.bic ?? null,
+        iban: rib.iban ?? null,
+    }
+}
+
+/** Mappe les champs comptables du client (scalaires + IRI des referentiels). */
+export function mapAccountingDraft(client: ClientDetail): AccountingDraft {
+    return {
+        siren: client.siren ?? null,
+        accountNumber: client.accountNumber ?? null,
+        nTva: client.nTva ?? null,
+        tvaModeIri: iriOf(client.tvaMode),
+        paymentDelayIri: iriOf(client.paymentDelay),
+        paymentTypeIri: iriOf(client.paymentType),
+        bankIri: iriOf(client.bank),
+    }
+}
+
+/**
+ * Options de categories (value=IRI, label=nom, code) construites depuis l'embed.
+ * Source role-independante : evite de dependre de `GET /categories` (403 pour les
+ * roles metier non-admin), qui laisserait les libelles vides.
+ */
+export function categoryOptionsOf(categories: CategoryRead[] | undefined): CategorySelectOption[] {
+    return (categories ?? []).map(c => ({
+        value: c['@id'],
+        label: c.name ?? c.code ?? c['@id'],
+        code: c.code ?? '',
+    }))
+}
+
+/** Options de sites (value=IRI, label=nom) construites depuis l'embed d'une adresse. */
+export function siteOptionsOf(sites: SiteRead[] | undefined): SelectOption[] {
+    return (sites ?? []).map(s => ({ value: s['@id'], label: s.name ?? s['@id'] }))
+}
+
+/** Options de contacts (value=IRI, label=nom complet ou email) depuis l'embed client. */
+export function contactOptionsOf(contacts: ContactRead[] | undefined): SelectOption[] {
+    return (contacts ?? []).map(c => ({
+        value: c['@id'],
+        label: [c.firstName, c.lastName].filter(Boolean).join(' ') || (c.email ?? c['@id']),
+    }))
+}
+
+/**
+ * Liste a une seule option (ou vide) construite depuis un referentiel embarque
+ * (TvaMode / PaymentDelay / PaymentType / Bank) pour alimenter un MalioSelect en
+ * lecture seule. Le libelle vient de l'embed (`label` ou `name`), jamais d'un
+ * `GET` de referentiel — l'affichage reste correct quel que soit le role.
+ */
+export function referentialOptionOf(relation: Relation): SelectOption[] {
+    if (!relation || typeof relation === 'string') {
+        return []
+    }
+    const label = (relation.label as string | undefined)
+        ?? (relation.name as string | undefined)
+        ?? relation['@id']
+    return [{ value: relation['@id'], label }]
+}
+
+/** Vue d'une adresse (brouillon + options de select propres a l'adresse). */
+export function mapAddressView(address: AddressRead): AddressView {
+    return {
+        draft: mapAddressToDraft(address),
+        siteOptions: siteOptionsOf(address.sites),
+        categoryOptions: categoryOptionsOf(address.categories),
+    }
+}
+
+/**
+ * Bouton « Modifier » : visible si l'utilisateur peut editer au moins un onglet
+ * — `manage` (formulaire/onglets metier) OU `accounting.manage` (le role Compta
+ * doit pouvoir ouvrir l'edition pour son onglet Comptabilite). Le readonly fin
+ * par onglet est gere sur l'ecran d'edition (1.12).
+ */
+export function canEditClient(canAny: (codes: string[]) => boolean): boolean {
+    return canAny(['commercial.clients.manage', 'commercial.clients.accounting.manage'])
+}
+
+/** Bouton « Archiver » : permission archive ET client encore actif. */
+export function showArchiveAction(can: (code: string) => boolean, isArchived: boolean): boolean {
+    return can('commercial.clients.archive') && !isArchived
+}
+
+/** Bouton « Restaurer » : permission archive ET client deja archive. */
+export function showRestoreAction(can: (code: string) => boolean, isArchived: boolean): boolean {
+    return can('commercial.clients.archive') && isArchived
+}

frontend/modules/commercial/utils/clientEdit.ts

@@ -0,0 +1,247 @@
+/**
+ * Helpers purs de l'ecran « Modification client » (M1 Commercial, 1.12).
+ *
+ * Deux responsabilites, toutes deux testables unitairement (cf. clientEdit.spec.ts) :
+ *  1. Pre-remplissage : mapper le payload `GET /api/clients/{id}` (embed
+ *     contacts/adresses/ribs + scalaires) vers les brouillons « plats » edites
+ *     par la page et les blocs reutilisables (mappers contacts/adresses/ribs/
+ *     comptabilite reutilises depuis clientConsultation).
+ *  2. Scoping STRICT des payloads PATCH (mode strict RG-1.28 / ERP-74) : chaque
+ *     onglet n'envoie QUE les champs de SON groupe de serialisation, jamais un
+ *     payload mixte — un champ hors-permission = 403 sur l'integralite cote back.
+ *
+ * Ces helpers ne touchent ni a l'API ni a l'etat reactif.
+ *
+ * NOTE RG-1.04 (Information obligatoire pour la Commerciale) : volontairement NON
+ * miroitee cote front (cf. clientFormRules.ts) — /api/me n'expose pas le code de
+ * role et Bureau partage les permissions de Commerciale. Le back l'applique de
+ * maniere fiable (422) ; on laisse remonter ce 422 en toast.
+ */
+
+import {
+    iriOf,
+    relationOf,
+    type ClientDetail,
+} from '~/modules/commercial/utils/clientConsultation'
+import type { AddressFormDraft, ContactFormDraft, RibFormDraft } from '~/modules/commercial/types/clientForm'
+
+/**
+ * Etat « plat » du bloc principal (groupe client:write:main). Distinct des
+ * brouillons Contact : ces champs vivent sur le Client lui-meme (companyName,
+ * categories, relation, triage), pas sur une sous-ressource ClientContact. Les
+ * coordonnees de contact (nom, prenom, telephones, email) ne sont plus portees
+ * par le Client : elles vivent exclusivement dans l'onglet Contacts.
+ */
+export interface MainFormDraft {
+    companyName: string | null
+    /** IRI des categories rattachees (M2M). */
+    categoryIris: string[]
+    relationType: 'distributeur' | 'courtier' | null
+    distributorIri: string | null
+    brokerIri: string | null
+    triageService: boolean
+}
+
+/** Etat « plat » de l'onglet Information (groupe client:write:information). */
+export interface InformationFormDraft {
+    description: string | null
+    competitors: string | null
+    /** Date de creation de l'entreprise au format YYYY-MM-DD (MalioDate). */
+    foundedAt: string | null
+    /** Nombre de salaries en chaine (saisie masquee), converti en number au PATCH. */
+    employeesCount: string | null
+    revenueAmount: string | null
+    profitAmount: string | null
+    directorName: string | null
+}
+
+/** Etat « plat » de l'onglet Comptabilite (groupe client:write:accounting). */
+export interface AccountingFormDraft {
+    siren: string | null
+    accountNumber: string | null
+    nTva: string | null
+    tvaModeIri: string | null
+    paymentDelayIri: string | null
+    paymentTypeIri: string | null
+    bankIri: string | null
+}
+
+/** Permissions de l'utilisateur courant pertinentes pour l'edition d'un client. */
+export interface ClientEditAbilities {
+    /** `commercial.clients.manage` : bloc principal + onglets metier. */
+    canManage: boolean
+    /** `commercial.clients.accounting.view` : visibilite de l'onglet Comptabilite. */
+    canAccountingView: boolean
+    /** `commercial.clients.accounting.manage` : edition de l'onglet Comptabilite. */
+    canAccountingManage: boolean
+}
+
+/** Editabilite resolue par zone d'onglet (deduite des permissions). */
+export interface TabEditability {
+    /** Bloc principal + onglets Information / Contact / Adresse editables. */
+    businessEditable: boolean
+    /** Onglet Comptabilite present (affiche). */
+    accountingVisible: boolean
+    /** Onglet Comptabilite editable. */
+    accountingEditable: boolean
+}
+
+// ── Pre-remplissage (GET detail -> brouillons) ──────────────────────────────
+
+/**
+ * Mappe le detail client vers le brouillon du bloc principal. La relation
+ * Distributeur/Courtier est resolue par exclusivite (RG-1.03) et son IRI extrait
+ * de l'embed.
+ */
+export function mapMainDraft(client: ClientDetail): MainFormDraft {
+    const relation = relationOf(client)
+
+    return {
+        companyName: client.companyName ?? null,
+        categoryIris: (client.categories ?? []).map(c => c['@id']),
+        relationType: relation.type,
+        distributorIri: iriOf(client.distributor),
+        brokerIri: iriOf(client.broker),
+        triageService: client.triageService === true,
+    }
+}
+
+/** Mappe le detail client vers le brouillon de l'onglet Information. */
+export function mapInformationDraft(client: ClientDetail): InformationFormDraft {
+    return {
+        description: client.description ?? null,
+        competitors: client.competitors ?? null,
+        // MalioDate attend strictement YYYY-MM-DD : on tronque l'ISO datetime.
+        foundedAt: client.foundedAt ? client.foundedAt.slice(0, 10) : null,
+        employeesCount: client.employeesCount != null ? String(client.employeesCount) : null,
+        revenueAmount: client.revenueAmount ?? null,
+        profitAmount: client.profitAmount ?? null,
+        directorName: client.directorName ?? null,
+    }
+}
+
+/** Mappe les champs comptables du detail vers le brouillon de l'onglet (scalaires + IRI). */
+export function mapAccountingFormDraft(client: ClientDetail): AccountingFormDraft {
+    return {
+        siren: client.siren ?? null,
+        accountNumber: client.accountNumber ?? null,
+        nTva: client.nTva ?? null,
+        tvaModeIri: iriOf(client.tvaMode),
+        paymentDelayIri: iriOf(client.paymentDelay),
+        paymentTypeIri: iriOf(client.paymentType),
+        bankIri: iriOf(client.bank),
+    }
+}
+
+// ── Scoping strict des payloads PATCH ────────────────────────────────────────
+
+/**
+ * Payload du bloc principal — groupe client:write:main UNIQUEMENT. La relation
+ * Distributeur/Courtier est mutuellement exclusive (RG-1.03) : on ne renseigne
+ * que la FK correspondant au type choisi, l'autre est forcee a null.
+ */
+export function buildMainPayload(main: MainFormDraft): Record<string, unknown> {
+    return {
+        companyName: main.companyName,
+        categories: main.categoryIris,
+        distributor: main.relationType === 'distributeur' ? main.distributorIri : null,
+        broker: main.relationType === 'courtier' ? main.brokerIri : null,
+        triageService: main.triageService,
+    }
+}
+
+/** Payload de l'onglet Information — groupe client:write:information UNIQUEMENT. */
+export function buildInformationPayload(information: InformationFormDraft): Record<string, unknown> {
+    return {
+        description: information.description || null,
+        competitors: information.competitors || null,
+        foundedAt: information.foundedAt || null,
+        employeesCount: information.employeesCount ? Number(information.employeesCount) : null,
+        revenueAmount: information.revenueAmount || null,
+        profitAmount: information.profitAmount || null,
+        directorName: information.directorName || null,
+    }
+}
+
+/**
+ * Payload des scalaires de l'onglet Comptabilite — groupe client:write:accounting
+ * UNIQUEMENT (les RIB passent par la sous-ressource /clients/{id}/ribs). La banque
+ * n'a de sens que pour un Virement (RG-1.12) : forcee a null sinon.
+ */
+export function buildAccountingPayload(
+    accounting: AccountingFormDraft,
+    isBankRequired: boolean,
+): Record<string, unknown> {
+    return {
+        siren: accounting.siren || null,
+        accountNumber: accounting.accountNumber || null,
+        tvaMode: accounting.tvaModeIri,
+        nTva: accounting.nTva || null,
+        paymentDelay: accounting.paymentDelayIri,
+        paymentType: accounting.paymentTypeIri,
+        bank: isBankRequired ? accounting.bankIri : null,
+    }
+}
+
+/** Payload d'un contact (sous-ressource client_contact). */
+export function buildContactPayload(contact: ContactFormDraft): Record<string, unknown> {
+    return {
+        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,
+    }
+}
+
+/** Payload d'une adresse (sous-ressource client_address). */
+export function buildAddressPayload(
+    address: AddressFormDraft,
+    isBillingEmailRequired: boolean,
+): Record<string, unknown> {
+    return {
+        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.billingEmail || null) : null,
+    }
+}
+
+/** Payload d'un RIB (sous-ressource client_rib). */
+export function buildRibPayload(rib: RibFormDraft): Record<string, unknown> {
+    return {
+        label: rib.label,
+        bic: rib.bic,
+        iban: rib.iban,
+    }
+}
+
+// ── Gating par permission ────────────────────────────────────────────────────
+
+/**
+ * Resout l'editabilite par zone a partir des permissions (option 1 ERP-74,
+ * miroir UI du re-gating champ-par-champ du ClientProcessor) :
+ *  - bloc principal + Information/Contact/Adresse : editables ssi `manage` ;
+ *  - Comptabilite : visible ssi `accounting.view`, editable ssi `accounting.manage`.
+ *
+ * Produit le comportement attendu :
+ *  - Admin : tout editable.
+ *  - Bureau / Commerciale (manage, sans accounting) : metier editable, Compta masquee.
+ *  - Compta (accounting seul, sans manage) : metier readonly, Compta editable.
+ */
+export function resolveTabEditability(abilities: ClientEditAbilities): TabEditability {
+    return {
+        businessEditable: abilities.canManage,
+        accountingVisible: abilities.canAccountingView,
+        accountingEditable: abilities.canAccountingManage,
+    }
+}

frontend/modules/commercial/utils/clientFormRules.ts

@@ -0,0 +1,158 @@
+/**
+ * Regles metier pures de l'ecran « Ajouter un client » (M1 Commercial).
+ *
+ * Centralisees ici (hors composant) pour rester testables unitairement et
+ * partagees entre la page de creation et les futurs ecrans d'edition (1.11/1.12).
+ * Ces helpers ne touchent ni a l'API ni a l'etat reactif : ils prennent des
+ * brouillons « plats » et retournent des booleens / nouveaux objets.
+ *
+ * Le back reste la source de verite (les RG sont re-validees serveur) ; ces
+ * regles ne servent qu'au feedback UI immediat (gating de boutons, visibilite).
+ *
+ * NOTE RG-1.04 (Information obligatoire pour la Commerciale) : volontairement
+ * NON miroite cote front pour l'instant. Le payload /api/me ne porte pas le code
+ * de role (roles = IRIs opaques) et Bureau partage les memes permissions que
+ * Commerciale : aucun signal fiable pour distinguer le role cote front. Le back
+ * (ClientProcessor, via BusinessRoleAware) applique la regle de maniere fiable ;
+ * a rebrancher ici des qu'un code de role sera expose dans /api/me.
+ */
+
+/**
+ * Onglets « coquille » (non encore implementes) : frame vide, passage
+ * automatique a l'onglet suivant (decision Tristan 28/05).
+ */
+export const CLIENT_FORM_PLACEHOLDER_TABS = ['transport', 'statistics', 'reports', 'exchanges'] as const
+
+/**
+ * Onglets affiches uniquement en MODIFICATION (selon le role), jamais a la
+ * creation : Statistiques / Rapports / Echanges. A rebrancher dans les ecrans
+ * d'edition (1.11/1.12) via l'option `includeEditOnlyTabs`.
+ */
+export const CLIENT_FORM_EDIT_ONLY_TABS = ['statistics', 'reports', 'exchanges'] as const
+
+/**
+ * Construit l'ordre des onglets du formulaire client.
+ *  - L'onglet Comptabilite n'est present que si l'utilisateur a `accounting.view`
+ *    (Bureau / Commerciale ne le voient pas).
+ *  - Les onglets edit-only (Statistiques / Rapports / Echanges) sont exclus par
+ *    defaut (creation) ; passer `includeEditOnlyTabs: true` pour les afficher en
+ *    modification.
+ * Ordre aligne sur la spec M1 § Ecran « Ajouter un client ».
+ */
+export function buildClientFormTabKeys(
+    canAccountingView: boolean,
+    options: { includeEditOnlyTabs?: boolean } = {},
+): string[] {
+    const keys = ['information', 'contact', 'address', 'transport']
+    if (canAccountingView) {
+        keys.push('accounting')
+    }
+    if (options.includeEditOnlyTabs) {
+        keys.push(...CLIENT_FORM_EDIT_ONLY_TABS)
+    }
+    return keys
+}
+
+/** Sous-ensemble d'un contact necessaire aux regles de nommage (RG-1.05/1.14). */
+export interface ContactDraft {
+    firstName: string | null
+    lastName: string | null
+}
+
+/** Drapeaux d'usage d'une adresse (RG-1.06/07/08/11). */
+export interface AddressFlagsDraft {
+    isProspect: boolean
+    isDelivery: boolean
+    isBilling: boolean
+}
+
+/** Vrai si une chaine porte au moins un caractere non-espace. */
+function isFilled(value: string | null | undefined): boolean {
+    return value !== null && value !== undefined && value.trim() !== ''
+}
+
+/**
+ * RG-1.05 : un contact est valide des qu'il porte un nom OU un prenom.
+ */
+export function isContactNamed(contact: ContactDraft): boolean {
+    return isFilled(contact.firstName) || isFilled(contact.lastName)
+}
+
+/**
+ * RG-1.14 : l'onglet Contact ne peut etre finalise que s'il reste au moins un
+ * contact nomme (nom ou prenom).
+ */
+export function hasAtLeastOneValidContact(contacts: ContactDraft[]): boolean {
+    return contacts.some(isContactNamed)
+}
+
+/**
+ * RG-1.06/07/08 : une adresse de prospection est exclusive d'une adresse de
+ * livraison/facturation. Prospect n'est selectionnable que si ni Livraison ni
+ * Facturation ne sont coches.
+ */
+export function canSelectProspect(flags: AddressFlagsDraft): boolean {
+    return !flags.isDelivery && !flags.isBilling
+}
+
+/**
+ * RG-1.06/07/08 : Livraison et Facturation ne sont selectionnables que si
+ * Prospect n'est pas coche.
+ */
+export function canSelectDeliveryOrBilling(flags: AddressFlagsDraft): boolean {
+    return !flags.isProspect
+}
+
+/**
+ * Applique l'exclusivite Prospect / (Livraison|Facturation) au changement d'un
+ * drapeau. Cocher Prospect efface Livraison + Facturation ; cocher Livraison ou
+ * Facturation efface Prospect. Decocher n'a aucun effet de bord. Retourne un
+ * nouvel objet (pas de mutation de l'entree).
+ */
+export function applyProspectExclusivity(
+    flags: AddressFlagsDraft,
+    field: keyof AddressFlagsDraft,
+    value: boolean,
+): AddressFlagsDraft {
+    const next: AddressFlagsDraft = { ...flags, [field]: value }
+
+    if (value && field === 'isProspect') {
+        next.isDelivery = false
+        next.isBilling = false
+    }
+    else if (value && (field === 'isDelivery' || field === 'isBilling')) {
+        next.isProspect = false
+    }
+
+    return next
+}
+
+/**
+ * RG-1.11 : l'email de facturation n'est visible/obligatoire que si l'adresse
+ * est une adresse de facturation.
+ */
+export function isBillingEmailRequired(flags: AddressFlagsDraft): boolean {
+    return flags.isBilling
+}
+
+/** Code stable du type de reglement « virement » (cf. PaymentType.code, RG-1.12). */
+const PAYMENT_TYPE_TRANSFER = 'VIREMENT'
+
+/** Code stable du type de reglement « lettre de change » (RG-1.13). */
+const PAYMENT_TYPE_LCR = 'LCR'
+
+/**
+ * RG-1.12 : la banque est obligatoire lorsque le type de reglement est un
+ * virement.
+ */
+export function isBankRequiredForPaymentType(code: string | null | undefined): boolean {
+    return code === PAYMENT_TYPE_TRANSFER
+}
+
+/**
+ * RG-1.13 : au moins un RIB complet est obligatoire lorsque le type de reglement
+ * est une LCR.
+ */
+export function isRibRequiredForPaymentType(code: string | null | undefined): boolean {
+    return code === PAYMENT_TYPE_LCR
+}

frontend/modules/core/components/EffectivePermissions.vue

@@ -0,0 +1,68 @@
+<template>
+    <div>
+        <div v-if="permissions.length === 0" class="text-sm text-neutral-400">
+            {{ t('admin.users.drawer.noEffectivePermissions') }}
+        </div>
+        <div v-else class="divide-y divide-neutral-100 rounded-lg border border-neutral-200">
+            <div
+                v-for="perm in groupedPermissions"
+                :key="perm.module"
+                class="px-4 py-2"
+            >
+                <!-- En-tête du module -->
+                <p class="text-xs font-semibold uppercase text-neutral-400 mb-1">
+                    {{ perm.module }}
+                </p>
+                <div
+                    v-for="item in perm.items"
+                    :key="item.code"
+                    class="flex items-center justify-between py-1"
+                >
+                    <span class="text-sm text-neutral-700">{{ item.label }}</span>
+                    <div class="flex gap-1">
+                        <span
+                            v-for="source in item.sources"
+                            :key="source"
+                            :class="[
+                                'inline-flex items-center rounded-full px-2 py-0.5 text-xs font-medium',
+                                source === t('admin.users.drawer.sourceDirect')
+                                    ? 'bg-green-100 text-green-800'
+                                    : 'bg-blue-100 text-blue-800'
+                            ]"
+                        >
+                            {{ source }}
+                        </span>
+                    </div>
+                </div>
+            </div>
+        </div>
+    </div>
+</template>
+
+<script setup lang="ts">
+import type { EffectivePermission } from '~/shared/types/rbac'
+
+const { t } = useI18n()
+
+const props = defineProps<{
+    permissions: EffectivePermission[]
+}>()
+
+// Grouper par module pour l'affichage
+interface PermissionModuleGroup {
+    module: string
+    items: EffectivePermission[]
+}
+
+const groupedPermissions = computed<PermissionModuleGroup[]>(() => {
+    const groups = new Map<string, EffectivePermission[]>()
+    for (const perm of props.permissions) {
+        const list = groups.get(perm.module) || []
+        list.push(perm)
+        groups.set(perm.module, list)
+    }
+    return Array.from(groups.entries())
+        .map(([module, items]) => ({ module, items }))
+        .sort((a, b) => a.module.localeCompare(b.module))
+})
+</script>

frontend/modules/core/components/PermissionAccordion.vue

@@ -0,0 +1,71 @@
+<template>
+    <!-- Accordeon de permissions groupees par module : un panneau par module,
+         avec compteur (selectionnees/total) dans le titre, case "Tout selectionner"
+         et liste des permissions individuelles. Source unique de cette UX, utilisee
+         par RoleDrawer (permissions du role) et UserRbacDrawer (permissions directes). -->
+    <MalioAccordion v-model="openModules">
+        <MalioAccordionItem
+            v-for="group in groupsByModule"
+            :key="group.module"
+            :value="group.module"
+            :title="`${group.module} (${selectedCountFor(group)}/${group.permissions.length})`"
+            header-class="capitalize"
+        >
+            <div class="flex flex-col">
+                <!-- Tout selectionner pour ce module -->
+                <MalioCheckbox
+                    :id="`${idPrefix}-group-${group.module}`"
+                    :label="t('admin.roles.permissions.selectAll')"
+                    :model-value="allSelectedFor(group)"
+                    label-class="font-semibold text-sm text-neutral-700"
+                    @update:model-value="(val: boolean) => emit('toggle-all', group.module, val)"
+                />
+                <div class="flex flex-col">
+                    <MalioCheckbox
+                        v-for="perm in group.permissions"
+                        :id="`${idPrefix}-perm-${perm.id}`"
+                        :key="perm.id"
+                        :label="perm.label"
+                        :model-value="selectedIds.has(perm.id)"
+                        label-class="text-sm text-neutral-600"
+                        @update:model-value="(val: boolean) => emit('toggle', perm.id, val)"
+                    />
+                </div>
+            </div>
+        </MalioAccordionItem>
+    </MalioAccordion>
+</template>
+
+<script setup lang="ts">
+import type { PermissionModule } from '~/shared/types/rbac'
+
+const { t } = useI18n()
+
+const props = defineProps<{
+    /** Groupes de permissions a afficher, un par module. */
+    groupsByModule: PermissionModule[]
+    /** Ids des permissions actuellement selectionnees. */
+    selectedIds: Set<number>
+    /** Prefixe pour les ids HTML : evite les collisions si plusieurs accordeons coexistent (ex: "role" vs "direct"). */
+    idPrefix: string
+}>()
+
+const emit = defineEmits<{
+    toggle: [permissionId: number, selected: boolean]
+    'toggle-all': [module: string, selected: boolean]
+}>()
+
+// Modules ouverts dans l'accordeon (mode multiple). Etat local : chaque instance
+// du composant garde sa propre liste, pas de partage entre drawers.
+const openModules = ref<string[]>([])
+
+// Nombre de permissions selectionnees pour un module donne.
+function selectedCountFor(group: PermissionModule): number {
+    return group.permissions.filter(p => props.selectedIds.has(p.id)).length
+}
+
+// Vrai si toutes les permissions du module sont selectionnees.
+function allSelectedFor(group: PermissionModule): boolean {
+    return group.permissions.length > 0 && selectedCountFor(group) === group.permissions.length
+}
+</script>

frontend/modules/core/components/RoleDeleteModal.vue

@@ -0,0 +1,79 @@
+<template>
+    <Teleport to="body">
+        <Transition name="fade">
+            <div
+                v-if="modelValue"
+                class="fixed inset-0 z-50 flex items-center justify-center bg-black/50"
+                @click.self="cancel"
+            >
+                <div class="w-full max-w-md rounded-lg bg-white p-6 shadow-xl">
+                    <h3 class="text-lg font-semibold text-neutral-900">
+                        {{ t('admin.roles.delete.title') }}
+                    </h3>
+                    <p class="mt-3 text-sm text-neutral-600">
+                        {{ t('admin.roles.delete.message', { label: roleLabel }) }}
+                    </p>
+                    <div class="mt-6 flex justify-end gap-3">
+                        <MalioButton
+                            :label="t('common.cancel')"
+                            variant="secondary"
+                            @click="cancel"
+                        />
+                        <MalioButton
+                            :label="t('common.delete')"
+                            variant="danger"
+                            icon-name="mdi:delete-outline"
+                            icon-position="left"
+                            :disabled="loading"
+                            @click="confirm"
+                        />
+                    </div>
+                </div>
+            </div>
+        </Transition>
+    </Teleport>
+</template>
+
+<script setup lang="ts">
+const { t } = useI18n()
+
+defineProps<{
+    modelValue: boolean
+    roleLabel: string
+    loading: boolean
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: boolean]
+    confirm: []
+}>()
+
+// Ferme la modale sans confirmer
+function cancel() {
+    emit('update:modelValue', false)
+}
+
+// Emet l'evenement de confirmation de suppression
+function confirm() {
+    emit('confirm')
+}
+
+// Fermer la modale avec la touche Escape
+function onKeydown(e: KeyboardEvent) {
+    if (e.key === 'Escape') cancel()
+}
+
+onMounted(() => document.addEventListener('keydown', onKeydown))
+onUnmounted(() => document.removeEventListener('keydown', onKeydown))
+</script>
+
+<style scoped>
+.fade-enter-active,
+.fade-leave-active {
+    transition: opacity 0.2s ease;
+}
+.fade-enter-from,
+.fade-leave-to {
+    opacity: 0;
+}
+</style>

frontend/modules/core/components/RoleDrawer.vue

@@ -0,0 +1,248 @@
+<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-[24px] font-bold">
+                {{ isEditMode ? t('admin.roles.editRole') : t('admin.roles.createRole') }}
+            </h2>
+        </template>
+        <form class="flex flex-col py-4 gap-2" @submit.prevent="handleSave">
+            <!-- Champs du role -->
+            <MalioInputText
+                v-model="form.label"
+                :label="t('admin.roles.form.label')"
+                input-class="w-full"
+                required
+            />
+
+            <MalioInputText
+                v-model="form.code"
+                :label="t('admin.roles.form.code')"
+                input-class="w-full"
+                required
+                :readonly="isEditMode"
+            />
+
+            <MalioInputTextArea
+                v-model="form.description"
+                :label="t('admin.roles.form.description')"
+                input-class="w-full"
+            />
+
+            <!-- Permissions groupees par module -->
+            <div>
+                <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+                    {{ t('admin.roles.form.permissions') }}
+                </h4>
+                <!-- Etat d'erreur explicite : sans ce message, un drawer vide
+                     ressemblerait a un role legitimement sans permissions. -->
+                <div
+                    v-if="permissionsLoadFailed"
+                    class="rounded border border-red-200 bg-red-50 p-3 text-sm text-red-700"
+                >
+                    {{ t('admin.roles.permissions.loadFailed') }}
+                </div>
+                <div v-else-if="permissionsByModule.length === 0" class="text-sm text-neutral-400">
+                    {{ t('admin.roles.permissions.noPermissions') }}
+                </div>
+                <PermissionAccordion
+                    v-else
+                    :groups-by-module="permissionsByModule"
+                    :selected-ids="selectedPermissionIds"
+                    id-prefix="role"
+                    @toggle="handleTogglePermission"
+                    @toggle-all="handleToggleAll"
+                />
+            </div>
+
+        </form>
+
+        <!-- Footer fixe : depuis la 1.7.1 le slot #footer est un frere du body
+             scrollable (shrink-0), donc reellement fige sans sticky. -->
+        <template #footer>
+            <MalioButton
+                v-if="isEditMode"
+                :label="t('common.delete')"
+                variant="danger"
+                icon-name="mdi:delete-outline"
+                icon-position="left"
+                button-class="w-m-btn-action"
+                :disabled="role?.isSystem"
+                @click="emit('delete')"
+            />
+            <MalioButton
+                v-else
+                :label="t('common.cancel')"
+                variant="tertiary"
+                button-class="w-m-btn-action"
+                @click="emit('update:modelValue', false)"
+            />
+            <MalioButton
+                :label="t('common.save')"
+                variant="primary"
+                button-class="w-m-btn-action"
+                :disabled="saving || permissionsLoadFailed"
+                @click="handleSave"
+            />
+        </template>
+    </MalioDrawer>
+</template>
+
+<script setup lang="ts">
+import type { Permission, PermissionModule, Role } from '~/shared/types/rbac'
+
+const { t } = useI18n()
+const api = useApi()
+
+const props = defineProps<{
+    modelValue: boolean
+    role: Role | null
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: boolean]
+    saved: []
+    delete: []
+}>()
+
+const saving = ref(false)
+const allPermissions = ref<Permission[]>([])
+// Signale un echec de chargement du catalogue de permissions : on bloque
+// alors la sauvegarde pour eviter qu'un drawer ouvert avec zero permission
+// visible (cas d'un 403 ou d'une panne reseau) n'ecrase silencieusement
+// toutes les permissions du role.
+const permissionsLoadFailed = ref(false)
+
+const form = ref({
+    label: '',
+    code: '',
+    description: '',
+})
+
+const selectedPermissionIds = ref(new Set<number>())
+
+const isEditMode = computed(() => props.role !== null)
+
+// Grouper les permissions par module
+const permissionsByModule = computed<PermissionModule[]>(() => {
+    const groups = new Map<string, Permission[]>()
+    for (const perm of allPermissions.value) {
+        if (perm.orphan) continue
+        const list = groups.get(perm.module) || []
+        list.push(perm)
+        groups.set(perm.module, list)
+    }
+    return Array.from(groups.entries())
+        .map(([module, permissions]) => ({ module, permissions }))
+        .sort((a, b) => a.module.localeCompare(b.module))
+})
+
+// Charger les permissions au montage
+async function loadPermissions() {
+    permissionsLoadFailed.value = false
+    try {
+        const data = await api.get<{ member: Permission[] }>(
+            '/permissions',
+            { 'orphan': false, itemsPerPage: 999 },
+            // `toast: true` : en cas d'echec (403, reseau, 500), l'utilisateur
+            // voit l'erreur remonter. Sans ce feedback, un catalogue vide
+            // ressemblerait a un role sans permissions disponibles.
+            { toast: true },
+        )
+        allPermissions.value = data.member
+    } catch {
+        allPermissions.value = []
+        permissionsLoadFailed.value = true
+    }
+}
+
+// Remplir le formulaire quand le role change
+watch(() => props.role, (role) => {
+    if (role) {
+        form.value.label = role.label
+        form.value.code = role.code
+        form.value.description = role.description || ''
+        selectedPermissionIds.value = new Set(role.permissions.map(p => {
+            // L'API peut retourner des objets Permission ou des IRIs string
+            if (typeof p === 'string') {
+                return Number(p.split('/').pop())
+            }
+            return p.id
+        }))
+    } else {
+        form.value.label = ''
+        form.value.code = ''
+        form.value.description = ''
+        selectedPermissionIds.value = new Set()
+    }
+}, { immediate: true })
+
+// Charger les permissions quand le drawer s'ouvre
+watch(() => props.modelValue, (open) => {
+    if (open) loadPermissions()
+})
+
+// Basculer une permission individuelle
+function handleTogglePermission(id: number, selected: boolean) {
+    const ids = new Set(selectedPermissionIds.value)
+    if (selected) {
+        ids.add(id)
+    } else {
+        ids.delete(id)
+    }
+    selectedPermissionIds.value = ids
+}
+
+// Basculer toutes les permissions d'un module
+function handleToggleAll(module: string, selected: boolean) {
+    const ids = new Set(selectedPermissionIds.value)
+    const group = permissionsByModule.value.find(g => g.module === module)
+    if (!group) return
+    for (const perm of group.permissions) {
+        if (selected) {
+            ids.add(perm.id)
+        } else {
+            ids.delete(perm.id)
+        }
+    }
+    selectedPermissionIds.value = ids
+}
+
+// Sauvegarder le role (creation ou edition)
+async function handleSave() {
+    saving.value = true
+    try {
+        const permissions = Array.from(selectedPermissionIds.value).map(id => `/api/permissions/${id}`)
+
+        if (isEditMode.value && props.role) {
+            // Le code est immuable apres creation (garde backend RoleProcessor)
+            await api.patch(`/roles/${props.role.id}`, {
+                label: form.value.label,
+                description: form.value.description || null,
+                permissions,
+            }, {
+                toastSuccessMessage: t('admin.roles.toast.updated'),
+            })
+        } else {
+            await api.post('/roles', {
+                label: form.value.label,
+                code: form.value.code,
+                description: form.value.description || null,
+                permissions,
+            }, {
+                toastSuccessMessage: t('admin.roles.toast.created'),
+            })
+        }
+
+        emit('saved')
+        emit('update:modelValue', false)
+    } finally {
+        saving.value = false
+    }
+}
+</script>

frontend/modules/core/components/UserRbacDrawer.vue

@@ -0,0 +1,330 @@
+<template>
+    <MalioDrawer
+        :model-value="modelValue"
+        drawer-class="w-full max-w-[450px]"
+        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-[24px] font-bold">
+                {{ t('admin.users.drawer.title', { username: user?.username ?? '' }) }}
+            </h2>
+        </template>
+        <div class="flex flex-col space-y-4 py-4">
+            <!-- Etat d'erreur de chargement des referentiels : bloque la
+                 sauvegarde pour empecher un ecrasement silencieux des droits. -->
+            <div
+                v-if="loadFailed"
+                class="flex items-center gap-2 rounded-lg border border-red-300 bg-red-50 px-4 py-3 text-sm text-red-800"
+            >
+                <Icon name="mdi:alert-circle-outline" class="size-5 shrink-0" />
+                {{ t('admin.users.drawer.loadFailed') }}
+            </div>
+
+            <!-- Avertissement auto-edition -->
+            <div
+                v-if="isSelfEdit"
+                class="flex items-center gap-2 rounded-lg border border-yellow-300 bg-yellow-50 px-4 py-3 text-sm text-yellow-800"
+            >
+                <Icon name="mdi:alert-outline" class="size-5 shrink-0" />
+                {{ t('admin.users.drawer.selfWarning') }}
+            </div>
+
+            <!-- Toggle Administrateur -->
+            <MalioCheckbox
+                id="admin-toggle"
+                :label="t('admin.users.drawer.adminToggle')"
+                :model-value="form.isAdmin"
+                label-class="font-semibold text-sm text-neutral-700"
+                @update:model-value="form.isAdmin = $event"
+            />
+
+            <!-- Section Roles -->
+            <!-- !mt-0 : la MalioCheckbox au-dessus expose son slot message (16px),
+                 qui couvre deja l'ecart attendu — pas besoin du space-y-4 ici. -->
+            <div class="!mt-0">
+                <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+                    {{ t('admin.users.drawer.rolesSection') }}
+                </h4>
+                <div class="flex flex-col">
+                    <MalioCheckbox
+                        v-for="role in allRoles"
+                        :key="role.id"
+                        :id="`role-${role.id}`"
+                        :label="role.label"
+                        :model-value="selectedRoleIds.has(role.id)"
+                        label-class="text-sm text-neutral-600"
+                        @update:model-value="(val: boolean) => toggleRole(role.id, val)"
+                    />
+                </div>
+            </div>
+
+            <!-- Section Permissions directes -->
+            <div>
+                <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+                    {{ t('admin.users.drawer.directPermissionsSection') }}
+                </h4>
+                <div v-if="permissionsByModule.length === 0" class="text-sm text-neutral-400">
+                    {{ t('admin.roles.permissions.noPermissions') }}
+                </div>
+                <PermissionAccordion
+                    v-else
+                    :groups-by-module="permissionsByModule"
+                    :selected-ids="selectedDirectPermissionIds"
+                    id-prefix="direct"
+                    @toggle="handleTogglePermission"
+                    @toggle-all="handleToggleAll"
+                />
+            </div>
+
+            <!-- Section Sites autorises (ticket 2 module Sites) -->
+            <div>
+                <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+                    {{ t('admin.users.drawer.sitesSection') }}
+                </h4>
+                <div v-if="allSites.length === 0" class="text-sm text-neutral-400">
+                    {{ t('admin.sites.noSites') }}
+                </div>
+                <div class="flex flex-col">
+                    <MalioCheckbox
+                        v-for="site in allSites"
+                        :id="`site-${site.id}`"
+                        :key="site.id"
+                        :label="site.name"
+                        :model-value="selectedSiteIds.has(site.id)"
+                        label-class="text-sm text-neutral-600"
+                        @update:model-value="(val: boolean) => toggleSite(site.id, val)"
+                    />
+                </div>
+            </div>
+
+            <!-- Section Resume permissions effectives -->
+            <div>
+                <h4 class="mb-3 text-sm font-semibold text-neutral-700">
+                    {{ t('admin.users.drawer.summarySection') }}
+                </h4>
+                <EffectivePermissions :permissions="effectivePermissions" />
+            </div>
+
+        </div>
+
+        <!-- Footer fixe : depuis la 1.7.1 le slot #footer est un frere du body
+             scrollable (shrink-0), donc reellement fige sans sticky. -->
+        <template #footer>
+            <MalioButton
+                :label="t('common.cancel')"
+                variant="tertiary"
+                button-class="w-m-btn-action"
+                @click="emit('update:modelValue', false)"
+            />
+            <MalioButton
+                :label="t('common.save')"
+                variant="primary"
+                button-class="w-m-btn-action"
+                :disabled="saving || loadFailed"
+                @click="handleSave"
+            />
+        </template>
+    </MalioDrawer>
+</template>
+
+<script setup lang="ts">
+import type { Permission, PermissionModule, Role, UserListItem, UserRbacDetail, EffectivePermission } from '~/shared/types/rbac'
+import type { Site } from '~/shared/types/sites'
+
+const { t } = useI18n()
+const api = useApi()
+const auth = useAuthStore()
+
+const props = defineProps<{
+    modelValue: boolean
+    user: UserListItem | null
+}>()
+
+const emit = defineEmits<{
+    'update:modelValue': [value: boolean]
+    saved: []
+}>()
+
+const saving = ref(false)
+const allRoles = ref<Role[]>([])
+const allPermissions = ref<Permission[]>([])
+const allSites = ref<Site[]>([])
+// Signale un echec de chargement des referentiels : on bloque alors la
+// sauvegarde pour eviter qu'un drawer ouvert sans donnees (403, reseau)
+// n'ecrase silencieusement l'etat RBAC du user (vidage roles/permissions/sites).
+const loadFailed = ref(false)
+
+const form = ref({ isAdmin: false })
+const selectedRoleIds = ref(new Set<number>())
+const selectedDirectPermissionIds = ref(new Set<number>())
+const selectedSiteIds = ref(new Set<number>())
+
+// Detecter l'auto-edition
+const isSelfEdit = computed(() => props.user?.id === auth.user?.id)
+
+// Extraire un ID depuis une IRI API Platform
+function iriToId(iri: string): number {
+    return Number(iri.split('/').pop())
+}
+
+// Grouper les permissions par module (pour les checkboxes)
+const permissionsByModule = computed<PermissionModule[]>(() => {
+    const groups = new Map<string, Permission[]>()
+    for (const perm of allPermissions.value) {
+        if (perm.orphan) continue
+        const list = groups.get(perm.module) || []
+        list.push(perm)
+        groups.set(perm.module, list)
+    }
+    return Array.from(groups.entries())
+        .map(([module, permissions]) => ({ module, permissions }))
+        .sort((a, b) => a.module.localeCompare(b.module))
+})
+
+// Calculer les permissions effectives avec leurs sources
+const effectivePermissions = computed<EffectivePermission[]>(() => {
+    const permMap = new Map<number, Permission>()
+    for (const p of allPermissions.value) {
+        if (!p.orphan) permMap.set(p.id, p)
+    }
+
+    // Construire la map permissionId -> sources[]
+    const result = new Map<number, string[]>()
+
+    // Permissions heritees des roles
+    for (const roleId of selectedRoleIds.value) {
+        const role = allRoles.value.find(r => r.id === roleId)
+        if (!role) continue
+        for (const p of role.permissions) {
+            const pid = typeof p === 'string' ? iriToId(p) : p.id
+            const sources = result.get(pid) || []
+            sources.push(t('admin.users.drawer.sourceRole', { role: role.label }))
+            result.set(pid, sources)
+        }
+    }
+
+    // Permissions directes
+    for (const pid of selectedDirectPermissionIds.value) {
+        const sources = result.get(pid) || []
+        sources.push(t('admin.users.drawer.sourceDirect'))
+        result.set(pid, sources)
+    }
+
+    // Construire la liste finale
+    return Array.from(result.entries())
+        .map(([pid, sources]) => {
+            const perm = permMap.get(pid)
+            if (!perm) return null
+            return { code: perm.code, label: perm.label, module: perm.module, sources }
+        })
+        .filter((p): p is EffectivePermission => p !== null)
+        .sort((a, b) => a.code.localeCompare(b.code))
+})
+
+// Charger les referentiels (roles, permissions, sites) + le detail RBAC du user
+// en parallele pour minimiser le TTFB a l'ouverture du drawer.
+// Le detail RBAC est la seule source de verite pour l'etat initial du formulaire :
+// props.user vient de la liste /api/users qui n'expose pas les sites (groupe leger).
+async function loadData(userId: number) {
+    loadFailed.value = false
+    try {
+        const [rolesData, permsData, sitesData, userRbac] = await Promise.all([
+            // `toast: true` : en cas d'echec, l'utilisateur voit un toast
+            // d'erreur. Sans ce feedback, le drawer s'afficherait vide et la
+            // sauvegarde ecraserait silencieusement l'etat RBAC du user.
+            api.get<{ member: Role[] }>('/roles', {}, { toast: true }),
+            api.get<{ member: Permission[] }>('/permissions', { orphan: false, itemsPerPage: 999 }, { toast: true }),
+            api.get<{ member: Site[] }>('/sites', { itemsPerPage: 999 }, { toast: true }),
+            api.get<UserRbacDetail>(`/users/${userId}/rbac`, {}, { toast: true }),
+        ])
+        allRoles.value = rolesData.member
+        allPermissions.value = permsData.member
+        allSites.value = sitesData.member
+
+        form.value.isAdmin = userRbac.isAdmin
+        selectedRoleIds.value = new Set((userRbac.roles ?? []).map(iriToId))
+        selectedDirectPermissionIds.value = new Set((userRbac.directPermissions ?? []).map(iriToId))
+        selectedSiteIds.value = new Set((userRbac.sites ?? []).map(iriToId))
+    } catch {
+        loadFailed.value = true
+        allRoles.value = []
+        allPermissions.value = []
+        allSites.value = []
+        resetForm()
+    }
+}
+
+function resetForm() {
+    form.value.isAdmin = false
+    selectedRoleIds.value = new Set()
+    selectedDirectPermissionIds.value = new Set()
+    selectedSiteIds.value = new Set()
+}
+
+// Recharger a l'ouverture OU quand le user change pendant que le drawer est ouvert.
+// Le watch combine evite un double fetch si les deux changent dans le meme tick.
+watch([() => props.modelValue, () => props.user?.id], ([open, userId]) => {
+    if (open && userId) {
+        loadData(userId)
+    } else if (!open) {
+        resetForm()
+    }
+}, { immediate: true })
+
+function toggleRole(id: number, selected: boolean) {
+    const ids = new Set(selectedRoleIds.value)
+    if (selected) ids.add(id)
+    else ids.delete(id)
+    selectedRoleIds.value = ids
+}
+
+function handleTogglePermission(id: number, selected: boolean) {
+    const ids = new Set(selectedDirectPermissionIds.value)
+    if (selected) ids.add(id)
+    else ids.delete(id)
+    selectedDirectPermissionIds.value = ids
+}
+
+function handleToggleAll(module: string, selected: boolean) {
+    const ids = new Set(selectedDirectPermissionIds.value)
+    const group = permissionsByModule.value.find(g => g.module === module)
+    if (!group) return
+    for (const perm of group.permissions) {
+        if (selected) ids.add(perm.id)
+        else ids.delete(perm.id)
+    }
+    selectedDirectPermissionIds.value = ids
+}
+
+function toggleSite(id: number, selected: boolean) {
+    const ids = new Set(selectedSiteIds.value)
+    if (selected) ids.add(id)
+    else ids.delete(id)
+    selectedSiteIds.value = ids
+}
+
+async function handleSave() {
+    if (!props.user) return
+    saving.value = true
+    try {
+        await api.patch(`/users/${props.user.id}/rbac`, {
+            isAdmin: form.value.isAdmin,
+            roles: Array.from(selectedRoleIds.value).map(id => `/api/roles/${id}`),
+            directPermissions: Array.from(selectedDirectPermissionIds.value).map(id => `/api/permissions/${id}`),
+            sites: Array.from(selectedSiteIds.value).map(id => `/api/sites/${id}`),
+        }, {
+            toastSuccessMessage: t('admin.users.toast.updated'),
+        })
+        // Rafraichir les donnees du user courant si auto-edition
+        if (isSelfEdit.value) {
+            await auth.refreshUser()
+        }
+        emit('saved')
+        emit('update:modelValue', false)
+    } finally {
+        saving.value = false
+    }
+}
+</script>