---
suivi: 1543
date: 2026-09-15
sujet: Constructibilité parcelle — valeur Pour partie
chantier: foncier / parcelles / urbanisme
type: feature
statut: poussé
hash: 88777d08
fichiers:
  - app/Support/Foncier/FoncierReferentiels.php
  - app/Services/Foncier/ParcelleCreationService.php
  - resources/js/Components/Foncier/Prospection/ProspectionParcellesSublist.vue
  - tests/Unit/Parcelle1510SourceTest.php
  - tests/Unit/Parcelle1540SourceTest.php
  - tests/Unit/Parcelle1543SourceTest.php
  - public/build/
  - docs/suivi/SUIVI_1543_constructible_pour_partie.md
---

# SUIVI #1543 — Constructibilité « Pour partie »

## PROMPT ENVOYÉ

Ajouter la valeur « Pour partie » à la constructibilité d’une parcelle,
juste après Oui. Clé snake_case dans CONSTRUCTIBILITES.
Couvrir fiche, création unitaire, liste, filtre, validation serveur.
Pas de migration. Rebase Vite. Push HECTAREG main.

## BASE GIT

HEAD = origin/main `577d4d79` (#1542 poussé) au départ. Rebase Vite :
déjà à jour après #1542. Journal `parcelle_constructible` déjà à jour
sur main (même `code` #1540, collision locale #1542).

## FICHES LUES

- **#1540 LEÇON** — source unique `CONSTRUCTIBILITES` / `constructible_libelle`.
  Sous-liste commune : fallback encore en dur (ajouter `pour_partie`).
  `nb_constructibles` ne compte que `oui` (et legacy true/1).
  Colonne varchar(32) : pas d’ALTER. Modale multiparcelle : pas de champ.
- **#1542** — page Alertes poussée juste avant ; rebuild Vite après.
- **#1533 LEÇON** — liste / filtre dans `Prospection/Index.vue`.
- **#1242 / #1247** — `parcelles.constructible` = `VARCHAR(32) NULL`.

## SYNTHÈSE

Clé technique `pour_partie` / constante `CONSTRUCTIBLE_POUR_PARTIE`,
insérée entre `oui` et `potentiel`. Clés existantes inchangées.
`optionsConstructibilites()` et `libelleConstructible()` suivent le
tableau. Validation unitaire = `Rule::in(array_keys(CONSTRUCTIBILITES))`.
`normalizeConstructible()` accepte toute clé du référentiel.
Sous-liste commune : libellé via `constructible_libelle` + fallback
`pour_partie`. Journal déjà présent (même `code` / `sujet`, #1406).

### Mapping UI ↔ back

| Libellé affiché | Valeur postée | Colonne DB | Libellé back |
| --- | --- | --- | --- |
| Non renseigné | null | parcelles.constructible NULL | non renseigné |
| Oui | oui | oui | Oui |
| Pour partie | pour_partie | pour_partie | Pour partie |
| Potentiel | potentiel | potentiel | Potentiel |
| À devenir | a_devenir | a_devenir | À devenir |
| Jamais | jamais | jamais | Jamais |

Placeholder « Non renseigné » ajouté au front, pas dans le référentiel.

## DÉPLOIEMENT-TEST

1. `git pull origin main`
2. `php artisan optimize:clear` + `view:clear` + `journal:sync`
3. Fiche parcelle → six entrées dans l’ordre
4. Enregistrer Pour partie → persiste
5. Liste Constr. + filtre Constructible
6. Dépliage commune
7. Création unitaire
8. Parcelles déjà renseignées inchangées

Pas de migration. JAMAIS npm/composer/optimize/config:cache sur OVH.

## LEÇON

Même piège #1540 : le fallback de `ProspectionParcellesSublist.vue`
reste en dur — une 5e valeur sans branche s’affichait en clé brute.
`nb_constructibles` (mode propriétaire) compte seulement `oui`
(et legacy true/1) : **Pour partie n’est pas inclus**, comme Potentiel.
Arbitrage ultérieur si le compteur doit élargir « constructible ».
Colonne varchar(32) : pas d’ALTER. Deux lots front en parallèle
écrasent `public/build/` : sérialiser (ici #1542 puis #1543).