---
suivi: 1884
date: 2026-10-14
sujet: Alertes foncières — colonnes palier et scénario
chantier: foncier
type: correctif
statut: poussé
hash: c8b6d65fe
fichiers:
  - database/migrations/2026_10_14_114500_widen_alerte_scenario_et_palier_foncier.php
  - app/Services/Foncier/FoncierAlerteEvaluationService.php
  - app/Support/Foncier/Alertes/Types/PromesseParcelleCoherenceType.php
  - app/Http/Controllers/Admin/FoncierAlertesController.php
  - database/data/journal_mises_a_jour_post_2026_06_12.php
  - tests/Unit/FoncierAlerteColonnes1884Test.php
  - tests/Feature/Foncier/FoncierAlerteColonnes1884Test.php
  - docs/suivi/SUIVI_1884_alertes_foncier_colonnes.md
---

# SUIVI #1884 — colonnes des alertes foncières

## PROMPT ENVOYÉ

Correctif du diagnostic #1883. Élargir `alertes.scenario` à VARCHAR(191) et `foncier_alertes_emises.palier` à VARCHAR(96), sans changer le format des clés. Un échec d’enregistrement de l’émission ne doit plus interrompre la tournée. Une cloche `delivre = 0` (jamais créée) est rejouée ; une cloche `delivre = 1` ne l’est pas. Le bouton « Évaluer maintenant » ne répond plus 500 et clôt le run du jour s’il est ouvert. Pas de SSH, pas de requête prod, pas de front.

## Fiches lues

- #1883 (diagnostic de cette conversation) : le second 1406 sort d’`evaluer()` et réserve la journée. Le format de palier ne doit pas changer.
- #1077 LEÇON : verrou et dédup en base ; un échec Teams s’enregistre `delivre = 0` sur le canal teams et reste visible. Le filtre `dejaEmise` reste limité au canal cloche.
- #1225 LEÇON : l’alerte de cohérence est un filet, sans régression d’état. Les chaînes `manque_sous_compromis.p…` et `sous_compromis_sans_promesse.p…` sont inchangées.
- #1828 LEÇON : ne pas modifier `DeclencheFoncierAlertes` ni l’heure de 8 h. L’occupation est après la cohérence : elle repart dès que la tournée va au bout.
- #1871 LEÇON : le rattrapage des tâches est dans `terminate` du middleware. Le bouton admin ne crée pas de ligne de run, sinon il consommerait le verrou et sauterait ce rattrapage.

## SYNTHÈSE

`alertes.scenario` passe à VARCHAR(191), `foncier_alertes_emises.palier` à VARCHAR(96). ALTER brut, hors transaction, ignoré sous SQLite. Index uniques utf8mb4 : 1 792 et 1 756 octets, sous 3 072.

Écritures `delivre = 0`, une seule méthode `enregistrerEmission` :

| Fichier | Lignes | Canal | Cause |
|---|---|---|---|
| FoncierAlerteEvaluationService.php | catch création cloche | cloche | `Alerte::create` a levé |
| FoncierAlerteEvaluationService.php | Teams retour false | teams | notification non délivrée |
| FoncierAlerteEvaluationService.php | catch Teams | teams | exception à l’envoi |

`dejaEmise` ne lit que le canal cloche, et seulement si `delivre = 1`. L’échec Teams ne bloque pas et ne relance pas une cloche déjà délivrée. Aucun envoi volontairement retenu n’écrit `delivre = 0`.

Le catch autour de l’enregistrement d’échec journalise et laisse les types suivants s’exécuter. Le bouton admin attrape une exception (redirection, pas de 500) et, seulement si l’évaluation aboutit, met `finished_at` et `nb_emises` sur la ligne du jour déjà présente.

## DÉPLOIEMENT-TEST

git pull origin main
php artisan migrate --force
php artisan optimize:clear
php artisan view:clear
php artisan journal:sync

Pas de route:clear. Pas de rebuild. Puis, le 14/10, Administration, Alertes foncières, bouton Évaluer maintenant. Aucun SQL.

## LEÇON

Ne pas raccourcir le palier : c’est la clé de dédup. Ne pas traiter un `delivre = 0` teams comme une cloche à renvoyer. Ne pas insérer `foncier_alerte_runs` depuis le bouton admin.