diff --git a/docs/polar-ble-runbook-mac.md b/docs/polar-ble-runbook-mac.md
index 004d2d7..9a76fe1 100644
--- a/docs/polar-ble-runbook-mac.md
+++ b/docs/polar-ble-runbook-mac.md
@@ -324,3 +324,62 @@ montre au Mac cinq minutes avant de courir n'était pas un usage.
 montre les exécute selon les zones réglées dans Flow. Vérifiées alignées le
 2026-08-17, à 1 bpm près sur la frontière Z2/Z3. La réponse du serveur porte les
 bornes de `current_zones()` pour ce contrôle — les afficher avant l'envoi.
+
+## 2026-09-01 — Après réinitialisation, le BLE marche. Et ANCS n'est pas la voie.
+
+### Fait neuf : l'écriture BLE a abouti
+
+Rapporté par Sylvain : **après la réinitialisation complète de la montre** (celle
+qu'a imposée l'incident USB), l'envoi de l'exercice par Bluetooth **a
+fonctionné**. Il ajoute lui-même : « ce n'est pas viable ».
+
+Ça confirme le diagnostic du 31/08 plutôt que de l'infirmer : le refus ne vient
+pas d'une interdiction des apps tierces, mais de **l'occupation du canal PsFTP
+par Flow**. Montre neuve, pas encore liée à Flow ⇒ le canal est libre ⇒ notre
+session s'ouvre. Dès que Flow reprend la main, elle se referme.
+
+⇒ **Le prix d'accès au BLE reste le même** : ne pas avoir Flow. Et depuis le
+01/09 ce prix a augmenté — la Polar est devenue la montre de sport, donc Flow
+est le seul canal par lequel les séances entrent dans HealthKit puis dans coach.
+
+### La question de Sylvain : « et le protocole des notifications iOS ? »
+
+Bonne intuition — les notifications iOS arrivent bien à la montre **pendant que
+Flow est connecté**. Mais le canal ne peut pas porter une séance, et la raison
+est structurelle.
+
+**ANCS — Apple Notification Center Service** ([spec Apple][ancs]) :
+
+- **Les rôles sont inversés par rapport à PsFTP.** « The publisher of the ANCS
+  service (**the iOS device**) shall be referred to as the *Notification
+  Provider* » ; « any client of the ANCS service (**an accessory**) shall be
+  referred to as a *Notification Consumer* ». C'est l'**iPhone** qui est
+  serveur, la montre qui est cliente — d'où l'absence de conflit avec Flow : la
+  montre ne cède rien, elle consomme.
+- **Trois caractéristiques, et rien d'autre** : Notification Source
+  (`9FBF120D-…`), Control Point (`69D1D8F3-…`), Data Source (`22EAC6E9-…`).
+- **Aucun transport de binaire.** La spec ne décrit aucun mécanisme de transfert
+  de fichier ni de payload applicatif : uniquement des métadonnées de
+  notification et des commandes d'action prédéfinies.
+
+⇒ **On ne fera pas passer un `.BPB` par ANCS.** Ce n'est pas une limite de notre
+implémentation, c'est ce que le protocole est.
+
+### Ce qu'ANCS permet quand même, et qui n'est pas rien
+
+ANCS transporte du **texte affiché au poignet**, sans câble, sans dissocier, et
+**sans toucher à Flow**. Une notification locale iOS émise par coach est relayée
+par ANCS et s'affiche sur la montre. Le canal existe déjà côté projet :
+`@capacitor/local-notifications` est installé, et `web/static/local-notifications.js`
+est chargé par `_layout.html` — **aucun build Xcode nécessaire**.
+
+⚠️ Ce que ça ne fait PAS, et il faut le dire avant de le construire : pas
+d'objectif structuré, **pas d'alerte de zone**, pas de guidage par étape, pas de
+comparaison à l'exécution. C'est un **pense-bête au poignet**, pas un
+remplacement du `.BPB`. La longueur réellement affichable par la V3 n'est pas
+documentée et devra être mesurée.
+
+⇒ Le seul chemin qui écrit un vrai objectif **en préservant Flow** reste le
+**câble**.
+
+[ancs]: https://developer.apple.com/library/archive/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Specification/Specification.html