chore: bump version to v0.1.74

docs(commercial) : refonte contact — suppression du contact inline (specs M1 + M2) (#54 )
Acte la décision refonte-contact dans les specs : le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email) est retiré des entités tiers (Client, Supplier). Les contacts vivent uniquement dans ClientContact / SupplierContact (onglet Contacts). Garantie « >=1 contact nommé » préservée par RG-1.05/1.14 (M1) et RG-2.04/2.13 (M2). - M1 (spec-back/spec-front/cahier) : modèle Client sans contact inline ; RG-1.01/1.02 supprimées ; D1 (recherche) / D2 (export) décrites ; version V1. - M2 (spec-back/spec-front) : FICHIERS NOUVEAUX (non versionnés sur develop), introduits déjà corrigés (Supplier sans contact inline, RG-2.01/2.02 supprimées) ; version V0.2. - docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/specs, M2 specs) + prompts + amendement des tickets M2. Lesstime : tâches #103 (M1 back), #104 (M1 front), #105 (M1 specs), #106 (M2 specs) ; tickets M2 #85-#97 amendés. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #54 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
2026-06-03 13:16:17 +00:00 · 2026-06-03 13:16:11 +00:00 · 2026-06-03 12:56:58 +00:00 · 2026-06-03 12:56:46 +00:00
25 changed files with 2295 additions and 75 deletions
@@ -1,2 +1,2 @@
 parameters:
-    app.version: '0.1.72'
+    app.version: '0.1.74'
@@ -18,8 +18,8 @@ merge de la stack.

 | RG | Intitulé | Test(s) | Source |
 |----|----------|---------|--------|
-| RG-1.01 | Prénom OU nom obligatoire → 422 | `ClientApiTest::testPostWithoutFirstOrLastNameReturns422` ; `ClientProcessorTest` (unit) | ERP-55 |
-| RG-1.02 | phoneSecondary persisté ; max 2 téléphones | `ClientFormulaireMainTest::testPostPersistsSecondaryPhoneNormalized` ; `::testThirdPhoneFieldIsIgnored` | **ERP-60** |
+| ~~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 |
@@ -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).
@@ -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).
@@ -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.
@@ -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.
@@ -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).
@@ -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.
@@ -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).
@@ -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.
@@ -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.
@@ -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.
@@ -5,8 +5,11 @@ nom: "Répertoire clients"
 ecran: repertoire-clients
 owner_spec: Matthieu
 backup_spec: Tristan
-version: V0
+version: V1
 date_redaction: 2026-05-28
+# Historique : V1 (2026-06-03) — Refonte contact : suppression du contact principal inline
+#   du Client (firstName/lastName/phonePrimary/phoneSecondary/email retirés de la table client).
+#   Les contacts vivent uniquement dans ClientContact. Cf. docs/specs/M1-clients/refonte-contact/README.md

 # === LIENS ===
 spec_front: ./spec-front.md
@@ -203,11 +206,11 @@ Le **formatage `XX XX XX XX XX`** est fait à l'affichage côté front (filter V
 |                   |        +-----------------------+        |  (Catalog)   |
 | id (PK)           |                                         +--------------+
 | company_name      |
-| first_name        |        +-----------------------+        +--------------+
-| last_name         |--1:n-->|    client_contact     |        |   site       |
-| phone_primary     |        +-----------------------+        |  (Sites)     |
-| phone_secondary   |                                         +--------------+
-| email             |        +-----------------------+              ^
+| (contact inline   |        +-----------------------+        +--------------+
+|  retiré V1 —      |--1:n-->|    client_contact     |        |   site       |
+|  firstName,       |        +-----------------------+        |  (Sites)     |
+|  lastName, phones,|                                         +--------------+
+|  email)           |        +-----------------------+              ^
 | distributor_id    |--1:n-->|    client_address     |--n:m---------+
 | broker_id         |        +-----------------------+
 | triage_service    |                  |
@@ -302,11 +305,8 @@ CREATE TABLE client (
    id                  SERIAL PRIMARY KEY,
    -- Formulaire principal
    company_name        VARCHAR(180) NOT NULL,
-    first_name          VARCHAR(120),
-    last_name           VARCHAR(120),
-    phone_primary       VARCHAR(20) NOT NULL,
-    phone_secondary     VARCHAR(20),
-    email               VARCHAR(180) NOT NULL,
+    -- Contact inline retiré (V1, refonte-contact) : first_name / last_name / phone_primary /
+    -- phone_secondary / email vivent désormais uniquement dans client_contact (onglet Contacts).
    distributor_id      INT REFERENCES client(id) ON DELETE SET NULL,
    broker_id           INT REFERENCES client(id) ON DELETE SET NULL,
    triage_service      BOOLEAN NOT NULL DEFAULT FALSE,
@@ -580,32 +580,9 @@ class Client implements TimestampableInterface, BlamableInterface
    #[Groups(['client:read', 'client:write:main'])]
    private ?string $companyName = null;

-    // RG-1.01 — first_name OU last_name obligatoire (validation Assert\Callback
-    // au niveau de l'entite, levee dans le Processor).
-    #[ORM\Column(length: 120, nullable: true)]
-    #[Assert\Length(max: 120, normalizer: 'trim')]
-    #[Groups(['client:read', 'client:write:main'])]
-    private ?string $firstName = null;
-
-    #[ORM\Column(length: 120, nullable: true)]
-    #[Assert\Length(max: 120, normalizer: 'trim')]
-    #[Groups(['client:read', 'client:write:main'])]
-    private ?string $lastName = null;
-
-    #[ORM\Column(length: 20)]
-    #[Assert\NotBlank]
-    #[Groups(['client:read', 'client:write:main'])]
-    private ?string $phonePrimary = null;
-
-    #[ORM\Column(length: 20, nullable: true)]
-    #[Groups(['client:read', 'client:write:main'])]
-    private ?string $phoneSecondary = null;
-
-    #[ORM\Column(length: 180)]
-    #[Assert\NotBlank]
-    #[Assert\Email]
-    #[Groups(['client:read', 'client:write:main'])]
-    private ?string $email = null;
+    // Contact inline retiré (V1, refonte-contact) : firstName / lastName / phonePrimary /
+    // phoneSecondary / email ne sont plus portés par Client — ils vivent dans ClientContact
+    // (onglet Contacts). La garantie « ≥ 1 contact nommé » est portée par RG-1.05 + RG-1.14.

    // RG-1.03 — distributor / broker auto-references (mutuellement exclusives,
    // contrainte CHECK en base).
@@ -749,7 +726,7 @@ class Client implements TimestampableInterface, BlamableInterface
 - **Query params** :
  - `includeArchived=true|false` (default `false`)
  - `categoryCode=<code>` (filtre les clients ayant ≥ 1 `Category` de ce code stable — ERP-78 ; ex. `DISTRIBUTEUR`, `COURTIER`)
-  - `search=<text>` (recherche fuzzy sur companyName + lastName + email)
+  - `search=<text>` (recherche fuzzy sur companyName + contacts liés `client_contact` (firstName / lastName / email) via LEFT JOIN groupé par `client.id` — décision D1, refonte-contact)
 - **Tri par défaut** : `companyName ASC`
 - **Pagination** : front via `<MalioDataTable>` (volumétrie cible faible). Pas de pagination serveur au M1.
 - **Réponse 200** (JSON-LD Hydra) : items avec champs `client:read` UNIQUEMENT (pas les champs `client:read:accounting` sauf si l'user a la permission `accounting.view`).
@@ -768,10 +745,6 @@ class Client implements TimestampableInterface, BlamableInterface
 ```json
 {
  "companyName": "ACME SAS",
-  "firstName": "Jean",
-  "lastName": "Dupont",
-  "phonePrimary": "0612345678",
-  "email": "jean.dupont@acme.fr",
  "categories": ["/api/categories/3", "/api/categories/7"],
  "distributor": null,
  "broker": null,
@@ -783,7 +756,7 @@ class Client implements TimestampableInterface, BlamableInterface
  - `201` / `400` / `401` / `403`
  - `409 Conflict` si doublon de nom de société (`companyName` — RG-1.16). SIREN et email ne sont pas uniques (cf. Q4, § 2.4).
  - `422 Unprocessable Entity` :
-    - RG-1.01 : ni firstName ni lastName
+    - (RG-1.01 supprimée V1 — la complétude du contact est portée par l'onglet Contacts : RG-1.05 / RG-1.14)
    - RG-1.03 : distributor + broker remplis simultanément
    - Catégories vides (Assert\Count min=1)

@@ -885,8 +858,8 @@ Cf. § 2.6. Pattern Shared standard.

 ### Formulaire principal

- **RG-1.01** : Au moins l'un des champs `firstName` (Prénom du contact principal) ou `lastName` (Nom du contact principal) doit être renseigné. Sinon → 422.
- **RG-1.02** : Le champ `phoneSecondary` est optionnel et apparaît au clic sur un bouton `+` côté front. Maximum 2 téléphones (primary + secondary). Comportement purement front au niveau UI ; côté serveur, les 2 colonnes existent et sont distinctes.
+- ~~**RG-1.01**~~ _(SUPPRIMÉE — V1, 2026-06-03, refonte-contact)_ : le contact principal inline est retiré du `Client`. La garantie « au moins un contact nommé » est désormais portée par **RG-1.05** (bloc Contact valide) + **RG-1.14** (≥ 1 bloc Contact) sur `ClientContact`.
+- ~~**RG-1.02**~~ _(SUPPRIMÉE du Client — V1, refonte-contact)_ : plus de téléphones inline sur le `Client`. Le « maximum 2 téléphones » reste applicable aux blocs `ClientContact` (normalisation RG-1.20).
 - **RG-1.03** : Les champs `distributor` et `broker` sont **mutuellement exclusifs** (au plus une seule des deux est renseignée). Tentative d'envoyer les deux → 422. Contrainte CHECK en base également : `NOT (distributor_id IS NOT NULL AND broker_id IS NOT NULL)`. Un `distributor` référencé doit porter une **`Category` de code `DISTRIBUTEUR`** ; un `broker` une **`Category` de code `COURTIER`** — sinon 422. _(Refonte ERP-78 : le filtrage se fait sur le `code` de la `Category`, plus sur le type — `ClientProcessor::hasCategoryCode`.)_ La liste front de `distributor` = clients ayant une catégorie de code `DISTRIBUTEUR`, via `GET /api/clients?categoryCode=DISTRIBUTEUR` ; idem `broker` avec `COURTIER`.

 ### Onglet Information
@@ -929,9 +902,9 @@ Cf. § 2.6. Pattern Shared standard.
 ### Normalisation serveur (formatage)

 - **RG-1.18** : `companyName` est **upper-cased** intégralement côté serveur avant validation et persistance (`mb_strtoupper(trim($v), 'UTF-8')`). Le client n'a pas besoin de saisir en majuscules ; la BDD stocke en majuscules.
- **RG-1.19** : `firstName`, `lastName` (sur `Client` et `ClientContact`) sont **capitalize**-és serveur (`mb_convert_case(trim($v), MB_CASE_TITLE, 'UTF-8')`). Exemple : `JEAN dupont` → `Jean Dupont`.
- **RG-1.20** : Les champs téléphone (`phonePrimary`, `phoneSecondary` sur `Client`, et idem sur `ClientContact`) sont **normalisés à chiffres uniquement** côté serveur (`preg_replace('/\D+/', '', $v)`). Stockage : `0612345678`. Le **format affichage `XX XX XX XX XX`** est de la responsabilité du front via un filter Vue dédié (cf. spec-front).
- **RG-1.21** : `email` (`Client.email`, `ClientAddress.billingEmail`, `ClientContact.email`) est **lowercase** intégralement côté serveur (`mb_strtolower(trim($v), 'UTF-8')`).
+- **RG-1.19** : `firstName`, `lastName` (sur `ClientContact` ; scope `Client` retiré en V1) sont **capitalize**-és serveur (`mb_convert_case(trim($v), MB_CASE_TITLE, 'UTF-8')`). Exemple : `JEAN dupont` → `Jean Dupont`.
+- **RG-1.20** : Les champs téléphone (`phonePrimary`, `phoneSecondary` sur `ClientContact` ; scope `Client` retiré en V1) sont **normalisés à chiffres uniquement** côté serveur (`preg_replace('/\D+/', '', $v)`). Stockage : `0612345678`. Le **format affichage `XX XX XX XX XX`** est de la responsabilité du front via un filter Vue dédié (cf. spec-front).
+- **RG-1.21** : `email` (`ClientAddress.billingEmail`, `ClientContact.email` ; `Client.email` retiré en V1) est **lowercase** intégralement côté serveur (`mb_strtolower(trim($v), 'UTF-8')`).

 ### Archivage

@@ -960,8 +933,8 @@ Cf. § 2.6. Pattern Shared standard.

 ### 8.1 Cas à couvrir (back — PHPUnit)

- [ ] **RG-1.01** : POST sans firstName ni lastName → 422
- [ ] **RG-1.02** : POST avec phoneSecondary rempli → persistance OK ; PATCH ajoutant un 3e téléphone → côté API, 2 colonnes uniquement (test que le payload ne peut pas créer un 3e)
+- [ ] ~~RG-1.01~~ _(supprimée V1)_ : la complétude du contact est couverte par RG-1.05 / RG-1.14 sur `ClientContact`
+- [ ] ~~RG-1.02~~ _(supprimée du Client V1)_ : plus de téléphones inline sur le Client (téléphones testés sur `ClientContact`)
 - [ ] **RG-1.03** : POST avec distributor ET broker → 422 ; POST distributor seul → 201
 - [ ] **RG-1.03** : POST distributor référençant un client SANS catégorie de code DISTRIBUTEUR → 422 (validation custom `ClientProcessor::hasCategoryCode`)
 - [ ] **RG-1.04** : PATCH onglet Information par un user Commerciale avec champs incomplets → 422 ; même PATCH par Admin → 200
@@ -975,9 +948,9 @@ Cf. § 2.6. Pattern Shared standard.
 - [ ] **RG-1.14** : front-driven uniquement, pas de test back
 - [ ] **RG-1.16** : POST avec `companyName` déjà pris → 409 ; POST avec même `companyName` après archivage de l'ancien → 201. SIREN et email dupliqués → 201 (plus d'unicité — RG-1.15/1.17 supprimées, Q4).
 - [ ] **RG-1.18** : POST `companyName="acme sas"` → BDD persiste `"ACME SAS"`
- [ ] **RG-1.19** : POST `firstName="JEAN"`, `lastName="dupont"` → persiste `"Jean"`, `"Dupont"`
- [ ] **RG-1.20** : POST `phonePrimary="06.12.34.56.78"` → persiste `"0612345678"`
- [ ] **RG-1.21** : POST `email="Jean.DUPONT@ACME.FR"` → persiste `"jean.dupont@acme.fr"`
+- [ ] **RG-1.19** : POST `firstName="JEAN"`, `lastName="dupont"` (via un bloc `ClientContact`) → persiste `"Jean"`, `"Dupont"`
+- [ ] **RG-1.20** : POST `phonePrimary="06.12.34.56.78"` (via un bloc `ClientContact`) → persiste `"0612345678"`
+- [ ] **RG-1.21** : POST `email="Jean.DUPONT@ACME.FR"` (via `ClientContact` ou `ClientAddress.billingEmail`) → persiste `"jean.dupont@acme.fr"`
 - [ ] **RG-1.22/23** : PATCH isArchived=true par Bureau (sans `archive`) → 403 ; par Admin → 200 + archivedAt rempli ; PATCH isArchived=false sur un client archivé dont le SIREN a été repris → 409
 - [ ] **RG-1.24/25** : GET liste sans flag → exclut archivés ; avec `?includeArchived=true` → inclut
 - [ ] **RG-1.26** : GET liste → tri companyName ASC
@@ -5,7 +5,10 @@ nom: "Répertoire clients"
 ecran: repertoire-clients
 owner_spec: Matthieu
 backup_spec: Tristan
-version: V0
+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 ===
@@ -68,9 +71,6 @@ Composant : `<MalioDataTable>`. Colonnes (à raffiner avec Tristan en revue maqu
 | Colonne | Source | Tri |
 |---|---|---|
 | **Nom entreprise** | `client.companyName` | ASC par défaut |
-| **Contact principal** | `firstName + lastName` | Oui |
-| **Téléphone principal** | `phonePrimary` (formaté `XX XX XX XX XX`) | Non |
-| **Email principal** | `email` | Oui |
 | **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 |

@@ -86,15 +86,12 @@ Création par **onglets successifs avec validation incrémentale** : pour pouvoi

 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) |
-| **Nom du contact principal** | `<MalioInputText>` | Conditionnel | RG-1.01 + RG-1.19 (Capitalize) |
-| **Prénom du contact principal** | `<MalioInputText>` | Conditionnel | RG-1.01 + RG-1.19 (Capitalize) |
 | **Catégorie** | `<MalioSelectCheckbox>` (multi) | Oui | Liste des `Category` de l'API ; M2M Client ↔ Category |
-| **Téléphone principal** | `<MalioInputText>` (masque tel) | Oui | RG-1.02 + RG-1.20 (format `XX XX XX XX XX`) |
-| **Téléphone secondaire** | `<MalioInputText>` (masque tel) | Non | Apparaît au clic sur le bouton `+` (RG-1.02). Max 2 — bouton `+` disparaît une fois rempli. |
-| **Email** | `<MalioInputText>` type email | Oui | RG-1.21 (lowercase) |
 | **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. |
@@ -120,7 +117,7 @@ Saisir les informations de l'entreprise.

 ### Onglet « Contact »

-Saisir un ou plusieurs contacts associés au client. Le 1er bloc est **pré-rempli** depuis les champs du formulaire principal (Nom, Prénom, Téléphone, Email — édition autorisée).
+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** :

@@ -250,7 +247,7 @@ Le serveur normalise systématiquement (cf. RG-1.18 à RG-1.21 dans [`spec-back.
 |---|---|---|
 | Nom entreprise (`companyName`) | UPPERCASE intégral | UPPERCASE |
 | Nom + Prénom contact | Capitalize (1ère lettre majuscule + reste minuscule) | identique |
-| Téléphone (`phonePrimary`, `phoneSecondary`, contact phones) | Chiffres uniquement en BDD | Formaté `XX XX XX XX XX` à l'affichage (filter Vue) |
+| 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()`.
@@ -275,7 +272,7 @@ Le composant `Code postal` + `Ville` + `Adresse` est branché sur **api-adresse.
 | 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) | **2 colonnes plates** `phone_primary` + `phone_secondary`. Pas de table séparée. |
+| 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. |
@@ -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).
@@ -0,0 +1,72 @@
+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' }] })
+            }
+            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.
+        expect(refs.sites.value).toEqual([{ value: '/api/sites/1', label: 'Chatellerault' }])
+        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' }] })
+            }
+            return Promise.resolve({ member: [] })
+        })
+
+        const refs = useClientReferentials()
+        await refs.loadCommon()
+
+        expect(refs.categories.value).toEqual([
+            { value: '/api/categories/1', label: 'Secteur', code: 'SECTEUR' },
+        ])
+        expect(refs.sites.value).toEqual([{ value: '/api/sites/1', label: 'Chatellerault' }])
+    })
+})
@@ -38,6 +38,11 @@ final class CatalogModule
        return [
            ['code' => 'catalog.categories.view', 'label' => 'Voir les categories'],
            ['code' => 'catalog.categories.manage', 'label' => 'Gerer les categories (creer, editer, supprimer)'],
+            // Lecture-referentiel transverse (ERP-102) : permet de LISTER les categories
+            // pour alimenter les selects des modules Tiers (clients, fournisseurs...),
+            // sans donner l'acces d'administration `.view` (qui ouvre la page Catalogue
+            // dans la sidebar). Accordee aux roles metier via la matrice RBAC § 2.7.
+            ['code' => 'catalog.categories.read_ref', 'label' => 'Lire le referentiel categories (transverse, lecture seule)'],
        ];
    }
 }
@@ -42,13 +42,19 @@ use Symfony\Component\Validator\Constraints as Assert;
 */
 #[ApiResource(
    operations: [
+        // Lecture (liste + item) : permission d'administration `view` OU permission
+        // de lecture-referentiel transverse `read_ref` (ERP-102). Les referentiels
+        // categories sont consommes par les modules Tiers (selects creation/filtre
+        // client) : tout role qui gere des tiers doit pouvoir les lire sans porter
+        // l'acces admin du Catalogue. `read_ref` est une permission Catalog (pas un
+        // code d'un autre module) -> isolement inter-module preserve.
        new GetCollection(
-            security: "is_granted('catalog.categories.view')",
+            security: "is_granted('catalog.categories.view') or is_granted('catalog.categories.read_ref')",
            normalizationContext: ['groups' => ['category:read', 'default:read']],
            provider: CategoryProvider::class,
        ),
        new Get(
-            security: "is_granted('catalog.categories.view')",
+            security: "is_granted('catalog.categories.view') or is_granted('catalog.categories.read_ref')",
            normalizationContext: ['groups' => ['category:read', 'default:read']],
            provider: CategoryProvider::class,
        ),
@@ -62,6 +62,9 @@ final class RbacSeeder
            'permissions' => [
                'commercial.clients.view',
                'commercial.clients.manage',
+                // Lecture des referentiels transverses pour les selects client (ERP-102).
+                'catalog.categories.read_ref',
+                'sites.read_ref',
            ],
        ],
        self::ROLE_COMPTA => [
@@ -70,6 +73,9 @@ final class RbacSeeder
                'commercial.clients.view',
                'commercial.clients.accounting.view',
                'commercial.clients.accounting.manage',
+                // Lecture des referentiels transverses pour les selects client (ERP-102).
+                'catalog.categories.read_ref',
+                'sites.read_ref',
            ],
        ],
        self::ROLE_COMMERCIALE => [
@@ -77,6 +83,9 @@ final class RbacSeeder
            'permissions' => [
                'commercial.clients.view',
                'commercial.clients.manage',
+                // Lecture des referentiels transverses pour les selects client (ERP-102).
+                'catalog.categories.read_ref',
+                'sites.read_ref',
            ],
        ],
        self::ROLE_USINE => [
@@ -40,13 +40,18 @@ use Symfony\Component\Validator\Constraints as Assert;
 */
 #[ApiResource(
    operations: [
+        // Lecture (liste + item) : permission d'administration `sites.view` OU
+        // permission de lecture-referentiel transverse `sites.read_ref` (ERP-102).
+        // Le referentiel sites alimente les selects d'adresse des modules Tiers :
+        // tout role qui gere des tiers doit pouvoir le lire sans porter l'acces
+        // admin des Sites.
        new GetCollection(
            normalizationContext: ['groups' => ['site:read']],
-            security: "is_granted('sites.view')",
+            security: "is_granted('sites.view') or is_granted('sites.read_ref')",
        ),
        new Get(
            normalizationContext: ['groups' => ['site:read']],
-            security: "is_granted('sites.view')",
+            security: "is_granted('sites.view') or is_granted('sites.read_ref')",
        ),
        new Post(
            normalizationContext: ['groups' => ['site:read']],
@@ -30,6 +30,8 @@ use function sprintf;
 *  - resource != Site::class          → no-op (les autres resources sont
 *                                        gerees par SiteScopedQueryExtension) ;
 *  - is_granted('sites.bypass_scope') → pas de filtre (admin / bypass) ;
+ *  - is_granted('sites.read_ref')     → pas de filtre (lecture-referentiel
+ *                                        transverse complet, ERP-102) ;
 *  - user non authentifie             → no-op (API Platform renvoie 401 avant) ;
 *  - user sans aucun site             → WHERE 1 = 0 (aucun acces) ;
 *  - cas normal                       → WHERE site.id IN (:allowedSites).
@@ -84,6 +86,16 @@ final class SiteCollectionScopedExtension implements QueryCollectionExtensionInt
            return;
        }

+        // 2bis) Lecture-referentiel transverse (ERP-102) : `sites.read_ref` donne
+        // acces a la LISTE COMPLETE des sites (selects d'adresse des modules Tiers).
+        // Sans ce bypass, le cloisonnement par site rattache reduirait le select
+        // aux seuls sites de l'utilisateur (voire a rien s'il n'en a aucun) et le
+        // referentiel ne serait plus "transverse". `read_ref` est une lecture seule :
+        // il ouvre la visibilite sans permettre la moindre ecriture.
+        if ($this->security->isGranted('sites.read_ref')) {
+            return;
+        }
+
        // 3) Pas d'user authentifie -> no-op (API Platform gere le 401 en amont).
        $user = $this->security->getUser();
        if (!$user instanceof User) {
@@ -33,6 +33,11 @@ final class SitesModule
            ['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)'],
+            // Lecture-referentiel transverse (ERP-102) : permet de LISTER les sites
+            // pour alimenter les selects des modules Tiers (adresses client...), sans
+            // donner l'acces d'administration `.view` (qui ouvre la page Sites dans la
+            // sidebar). Accordee aux roles metier via la matrice RBAC § 2.7.
+            ['code' => 'sites.read_ref', 'label' => 'Lire le referentiel sites (transverse, lecture seule)'],
        ];
    }
 }
@@ -6,6 +6,7 @@ namespace App\Tests\Module\Commercial\Api;

 use ApiPlatform\Symfony\Bundle\Test\Client;
 use App\Module\Core\Infrastructure\DataFixtures\RbacDemoFixtures;
+use App\Module\Sites\Domain\Entity\Site;
 use Symfony\Bundle\FrameworkBundle\Console\Application;
 use Symfony\Component\Console\Input\ArrayInput;
 use Symfony\Component\Console\Output\NullOutput;
@@ -272,6 +273,51 @@ final class ClientRBACMatrixTest extends AbstractCommercialApiTestCase
        self::assertResponseStatusCodeSame(200);
    }

+    public function testBusinessRolesCanReadCategoriesAndSitesReferentials(): void
+    {
+        // ERP-102 : /categories et /sites sont des referentiels TRANSVERSES.
+        // Tout role qui gere des clients (bureau / compta / commerciale) doit
+        // pouvoir les LISTER pour alimenter les selects de creation/filtre client,
+        // via la permission de lecture-referentiel dediee (catalog.categories.read_ref
+        // / sites.read_ref) attachee par la matrice § 2.7 — sans pour autant porter
+        // la permission d'administration `.view`. Usine, sans aucune permission,
+        // reste interdit.
+        // Le referentiel /sites est TRANSVERSE et COMPLET : le cloisonnement par
+        // site rattache (SiteCollectionScopedExtension) est neutralise par
+        // `sites.read_ref` (ERP-102). Les comptes demo ne sont rattaches qu'a un
+        // seul site (Chatellerault) alors que la base en compte plusieurs : on
+        // verifie donc que le role voit la TOTALITE du referentiel, pas son seul
+        // site rattache. Sans le bypass de scope, totalItems vaudrait 1.
+        $totalSites = $this->getEm()->getRepository(Site::class)->count([]);
+        self::assertGreaterThan(
+            1,
+            $totalSites,
+            'Pre-requis du test : la base doit contenir plusieurs sites pour distinguer scope et bypass.',
+        );
+
+        foreach (['bureau', 'compta', 'commerciale'] as $role) {
+            $client = $this->authAs($role);
+
+            $client->request('GET', '/api/categories', ['headers' => ['Accept' => self::LD]]);
+            self::assertResponseStatusCodeSame(200, sprintf('Le role %s doit pouvoir lister /categories', $role));
+
+            $response = $client->request('GET', '/api/sites', ['headers' => ['Accept' => self::LD]]);
+            self::assertResponseStatusCodeSame(200, sprintf('Le role %s doit pouvoir lister /sites', $role));
+            self::assertSame(
+                $totalSites,
+                $response->toArray()['totalItems'] ?? null,
+                sprintf('Le role %s doit voir tout le referentiel sites (%d), pas seulement son site rattache', $role, $totalSites),
+            );
+        }
+
+        // Usine : aucune permission -> reste a 403 sur les referentiels.
+        $usine = $this->authAs('usine');
+        $usine->request('GET', '/api/categories', ['headers' => ['Accept' => self::LD]]);
+        self::assertResponseStatusCodeSame(403, 'Usine ne doit pas pouvoir lister /categories');
+        $usine->request('GET', '/api/sites', ['headers' => ['Accept' => self::LD]]);
+        self::assertResponseStatusCodeSame(403, 'Usine ne doit pas pouvoir lister /sites');
+    }
+
    private function authAs(string $role): Client
    {
        return $this->authenticatedClient($role, self::PWD);
@@ -16,17 +16,18 @@ use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;
 */
 final class SitesModuleTest extends KernelTestCase
 {
-    public function testPermissionsSetContainsExactlyThreeCodes(): void
+    public function testPermissionsSetContainsExactlyFourCodes(): void
    {
        // Garde-fou : si quelqu'un ajoute une permission sans ajuster les
        // tests ou la doc, ce test casse explicitement. Si au contraire une
        // permission disparait (ex: bypass_scope retire par erreur), meme
-        // effet. Le set de 3 permissions est fige par ce test.
+        // effet. Le set de permissions est fige par ce test.
+        // `sites.read_ref` ajoutee en ERP-102 (lecture-referentiel transverse).
        $codes = array_column(SitesModule::permissions(), 'code');
        sort($codes);

        self::assertSame(
-            ['sites.bypass_scope', 'sites.manage', 'sites.view'],
+            ['sites.bypass_scope', 'sites.manage', 'sites.read_ref', 'sites.view'],
            $codes,
        );
    }
Author	SHA1	Message	Date
gitea-actions	1b924ba0fd	chore: bump version to v0.1.74 Auto Tag Develop / tag (push) Successful in 5s Details Build & Push Docker Image / build (push) Successful in 19s Details	2026-06-03 13:16:17 +00:00
matthieu	8fae987e15	docs(commercial) : refonte contact — suppression du contact inline (specs M1 + M2) (#54 ) Auto Tag Develop / tag (push) Successful in 6s Details Acte la décision refonte-contact dans les specs : le contact principal inline (firstName/lastName/phonePrimary/phoneSecondary/email) est retiré des entités tiers (Client, Supplier). Les contacts vivent uniquement dans ClientContact / SupplierContact (onglet Contacts). Garantie « >=1 contact nommé » préservée par RG-1.05/1.14 (M1) et RG-2.04/2.13 (M2). - M1 (spec-back/spec-front/cahier) : modèle Client sans contact inline ; RG-1.01/1.02 supprimées ; D1 (recherche) / D2 (export) décrites ; version V1. - M2 (spec-back/spec-front) : FICHIERS NOUVEAUX (non versionnés sur develop), introduits déjà corrigés (Supplier sans contact inline, RG-2.01/2.02 supprimées) ; version V0.2. - docs/specs/M1-clients/refonte-contact/ : décision (README) + tickets (M1 back/front/specs, M2 specs) + prompts + amendement des tickets M2. Lesstime : tâches #103 (M1 back), #104 (M1 front), #105 (M1 specs), #106 (M2 specs) ; tickets M2 #85-#97 amendés. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #54 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-03 13:16:11 +00:00
gitea-actions	6f977d387d	chore: bump version to v0.1.73 Auto Tag Develop / tag (push) Successful in 9s Details Build & Push Docker Image / build (push) Successful in 51s Details	2026-06-03 12:56:58 +00:00
matthieu	1888b70623	fix(rbac) : référentiels /categories et /sites lisibles par les rôles métier (ERP-102) (#53 ) Auto Tag Develop / tag (push) Successful in 11s Details ## Contexte ERP-102 — Découvert pendant ERP-64. Connecté avec un rôle métier (bureau / compta / commerciale), `GET /api/categories` et `GET /api/sites` renvoient 403, alors que `/tva_modes`, `/payment_delays`, `/payment_types`, `/banks` renvoient 200. Conséquences : page Création client inutilisable (le `Promise.all` rejetait → tous les selects vides) et filtres Catégories/Sites vides au répertoire. ## Cause La `security` des `GetCollection`/`Get` de `Category` et `Site` exigeait `catalog.categories.view` / `sites.view` — permissions d'administration du Catalogue / des Sites. Or ces référentiels sont transverses : tout rôle qui gère un tiers doit pouvoir les lire. ## Correctif back — Option C (permission de lecture-référentiel dédiée) Choix d'archi retenu parmi les 3 du ticket : - Pourquoi pas A (`... or is_granted('commercial.clients.view')`) : coupler `Category`/`Site` à une permission Commercial viole l'esprit de la règle ABSOLUE n°1 et ne scale pas (M2 Fournisseurs devrait rajouter un OR). - Pourquoi pas B (donner `.view` aux rôles métier) : `.view` = accès admin → items sidebar admin Catégories/Sites exposés à une commerciale. - C : nouvelle permission `catalog.categories.read_ref` / `sites.read_ref`, distincte de `.view` (pas d'item sidebar) et de `.manage`. Chaque permission appartient à son module → isolement inter-module préservé, réutilisable tel quel par M2 Fournisseurs. C'est la « permission référentiel lisible » que le ticket pointe lui-même. Détail : - `CatalogModule` / `SitesModule` : déclaration des deux permissions `read_ref`. - `Category` / `Site` : security lecture (liste + item) = `view OR read_ref`. - `RbacSeeder` (matrice § 2.7) : `read_ref` attaché à bureau / compta / commerciale ; usine reste sans accès. ## Durcissement front (résilience — requis dans tous les cas) `useClientReferentials.loadCommon` : `Promise.all` → `Promise.allSettled` avec affectation isolée par référentiel. L'échec d'un endpoint ne vide plus que son select, plus la totalité du formulaire. ## Tests (TDD) - `ClientRBACMatrixTest::testBusinessRolesCanReadCategoriesAndSitesReferentials` — bureau/compta/commerciale listent `/categories` et `/sites` (200), usine reste 403. - `SitesModuleTest` — set de permissions porté à 4 codes. - `useClientReferentials.spec` (Vitest) — un référentiel en échec ne vide que son select. ## Vérifications - `make test` (back) : 467/467 ✓ - `make nuxt-test` (front) : 131/131 ✓ - `make php-cs-fixer` : conforme ✓ ## Note miroirs RBAC `config/sidebar.php` / `personas.ts` / `SeedE2ECommand.php` non touchés : `read_ref` n'ajoute aucun item sidebar, le persona E2E `user-full` lit déjà via `.view`, et aucun persona ne modélise un rôle métier seul. Pas de nouveau test E2E (règle n°7 : bug attrapé avant prod). La source de vérité de la matrice (`RbacSeeder`) est mise à jour et couverte par `ClientRBACMatrixTest`. Closes ERP-102. --------- Co-authored-by: Matthieu <contact@malio.fr> Reviewed-on: #53 Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr> Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>	2026-06-03 12:56:46 +00:00