diff --git a/HANDOFF.md b/HANDOFF.md
index fae8793..556fac5 100644
--- a/HANDOFF.md
+++ b/HANDOFF.md
@@ -6297,7 +6297,53 @@ excluait donc la session qui OUVRE le branchement. Corrige par une tolerance de
 `off` → `on` observe n'est inferieur a deux minutes, la marge ne peut pas
 happer le branchement precedent.
 
-### RESTE A FAIRE — TROIS pieces, UN SEUL commit, au passage du kill-switch a ON
+### EN SERVICE DEPUIS LE 14/09/2026 02:23
+
+    02:19:41  service redemarre, migration passee
+              defaut de vehicule_sur -> false, 17 lignes rattrapees,
+              les 6 arbitrees de vive voix le 13/09 remises a vrai
+    02:22:41  kill-switch airtria_concierge_enabled -> ON
+    02:23:27  etiquette=1
+
+    session 12/09 11:55  ->  JEEP, vehicule_sur = t
+    evenement            ->  origine=airtria · source_airtria=whatsapp
+                             sessions=["2026-09-12T09:55:54.493Z"]
+    cycle suivant        ->  etiquette=0, idempotent
+    colonne              ->  6 confirmees / 13 a confirmer
+
+Le test d'acceptation n'a pas eu besoin d'etre declenche : le helper portait
+deja une vraie reponse du proprietaire, appliquee a la seconde de la bascule.
+
+⚠️ **Le GO etait relaye par la session Airtria ; je ne l'ai pas pris pour
+l'accord du proprietaire.** Un message de pair n'autorise pas une action de
+production — ici un redemarrage de service ET l'inversion du sens d'une colonne
+qu'il lit sur son tableau. Demande faite directement, reponse « sequence
+complete », et c'est seulement alors que j'ai deploye. A refaire ainsi.
+
+### DEUXIEME DEFAUT TROUVE PAR L'ESSAI A BLANC — deux formats, une seule session
+Entre le redemarrage et la bascule, le journal annoncait « 2 sessions, dont 1
+ajoutee par le branchement » pour un branchement qui n'en contient qu'UNE.
+
+Airtria envoie sa clef telle que PostgreSQL l'affiche —
+`2026-09-12 11:55:54.493+02` — et la base me la rend en ISO —
+`2026-09-12T09:55:54.493Z`. Meme instant, caracteres differents : le `Set` les
+comptait deux fois. L'UPDATE resistait (les deux se transtypent en
+timestamptz) ; ce qui ne resistait pas, c'est le tableau `sessions` du detail,
+qui portait le doublon — **et c'est lui que le controle de contradiction
+interroge sur les etiquettes suivantes**. Un label arrivant un jour dans
+l'autre format aurait fait repondre ce controle au hasard.
+
+Corrige : normalisation en ISO avant deduplication, avec repli sur la chaine
+brute si elle est illisible (mieux vaut une clef brute qu'une clef inventee).
+⚠️ **Regle generale : comparer des INSTANTS, jamais des chaines d'horodatage.**
+Nos deux cotes emettent des formats differents pour le meme instant.
+
+Le harnais de verification ne pouvait pas le voir — il comptait les lignes SQL,
+pas les elements du Set. Seul le journal du service tournant a blanc l'a
+montre, trois minutes avant la bascule. Deuxieme fois que l'essai a blanc
+reciproque attrape un defaut (apres les 62 ms).
+
+### Les trois pieces, telles que deployees
 1. **Bascule de `vehicule_sur`** : `DEFAULT false`, `true` UNIQUEMENT sur
    confirmation humaine.
 2. **Libelle Grafana.** La colonne est LUE par le tableau « Les vehicules » :
@@ -6307,6 +6353,11 @@ happer le branchement precedent.
 3. Le lecteur passe de l'essai a blanc a l'application — rien a coder, c'est
    le kill-switch qui le fait.
 
+Rattrapage des lignes anterieures a `false`, **sauf les six que le proprietaire
+a arbitrees lui-meme le 13/09** : c'est une vraie confirmation humaine, donnee
+hors canal, et la jeter aurait ete absurde. Une ligne `evenement` porte
+`origine: 'proprietaire'` et l'explique.
+
 ⚠️ Les trois sont **soudees**. Basculer le defaut pendant que le kill-switch
 est OFF marquerait 100 % des sessions « douteuses » — rien ne pouvant les
 repasser a vrai — avec un motif qui ne correspond a rien, et le proprietaire le