---
titre: Spec 06 — Décisions Phase 0 (listings bien × plateforme)
statut: Acceptée
date_proposition: 2026-05-21
date_decision: 2026-05-21
priorite: P1
release_cible: v0.X (liste à planifier lors de l’implémentation)
---

# 006 — Décisions Phase 0 pour [06-listings-plateforme-par-bien.md](../specifications/06-listings-plateforme-par-bien.md)

> **Actualisation (2026-05-20)** : la contrainte **« une seule fiche par couple (bien, plateforme) »** a été **levée**. Plusieurs lignes `property_platform_listing` sont autorisées pour le même bien et la même plateforme (anciennes vs nouvelle annonce Booking, etc.) ; l’unicité **identifiant de flux / organisation** est conservée. Voir la spec **06** et **`Version20260520195500`** en base.

Synthèse des réponses métier pour figer les arbitrages avant implémentation.

## 1. Nommage technique

- **Entité** : **`PropertyPlatformListing`**
- **Table SQL** recommandée : **`property_platform_listing`** (alignée sur Doctrine par défaut).

## 2. Historique / versionnement des fiches listing

**Pas d’historique en v1.** Modèle intentionnellement simple :

- Pas de jeu de lignes « archivées » (`active=false`, remplacements, `valid_from` / `valid_to`).
- Une **nouvelle ligne** existe pour chaque couple **(bien, plateforme)** au plus (**une seule fiche vivante**) ; mise à jour par **édition en place** (URL ou code qui change).  
  Suppression métier uniquement si l’organisation retire **réellement** le listing (**supprimer** la ligne ou équivalent fonctionnel MVP).

Référer aux contraintes d’unicité dans la spec 06 après mise à jour.

## 3. Unicités (« faisons simple »)

À implémenter côté BDD :

- **`UNIQUE (property_id, rental_platform_id)`** — un bien ne peut avoir qu’**une** annonce / code par plateforme.
- **`UNIQUE (organization_id, payout_identifier_normalized)`** — logique garantie soit par :
  - une contrainte / index fonctionnel reliant `organization_id` depuis `JOIN property`, soit
  - unicité appliquée en **service** après normalisation systématique du code en base (`payout_identifier` stocké sous **forme canonique** pour le lookup dans les libellés).

**Résultat** : dans une même organisation, **deux biens différents** ne partagent pas le **même** identifiant de flux ; une même ligne **(bien, plateforme)** ne se duplique pas.

## 4. Stockage des identifiants (« ID » paiement Booking)

Pas de distinction « brute vs normalisée » en double colonne en v1 : on **persiste une valeur canonique**, c’est-à-dire :

- représentée **exactement comme la sous-chaîne à matcher** après normalisation métier commune (voir spec § extraction) pour les flux de **cette** organisation ;
- en pratique : **identifiant lié au bien et à la plateforme**, tel que paramétré par l’utilisateur après **trim / nettoyage d’usage** défini dans l’application (sans sur-ingénierie documentaire au stade métier).

L’usage est : « **codes que la banque / Booking reflète dans le libellé** » pour ce bien sur cette plateforme.

## 5. Extraction du libellé à l’import

**Paramétrable par organisation** : chaque organisation peut avoir des formats d’écritures / plateformes / banques différents.

À prévoir lors de la phase données :

- un champ (ou petite config) **scoped organisation** permettant de définir la **regex d’extraction** (avec défaut MVP documenté dans la spec, ex. comportement équivalent **`ID.` + digits** lorsque vide).
- L’expression doit être **restrictive** au domaine métier toléré (erreur utilisateur lisible si regex invalide en admin).

Pas de fichier par listing pour la regex — **granularité organisation** sauf évolution ultérieure.

## 6. Permissions

Alignement sur le périmètre actuel **`Property`** (cf. [`PropertyController`](../../src/Controller/Admin/PropertyController.php) : garde **`ROLE_SUPERADMIN`** aujourd’hui).

Décision métier répétée : **les mêmes rôles peuvent créer/modifier/supprimer une fiche `PropertyPlatformListing`** que pour l’édition des **properties** tant que cette politique RBAC subsiste pour les biens ; si la création bien ouvre aux **ADMIN** org plus tard ([03](../specifications/03-roles-permissions.md)), **étendre de la même façon** les listings.

## 7. Confidentialité UI — affichage du « code paiement »

**Affichage intégral** du champ identifiant pour les utilisateurs qui accèdent à l’UI des listings (**pas de masquage MVP** tel `****96`).

## 8. Changelog fichier décisions

| Date | Qui | Changement |
|------|-----|-------------|
| 2026-05-21 | Métier + doc | Figement Phase 0 après questionnaire. |