Le BLE marche sur montre réinitialisée, et ANCS ne portera jamais un .BPB

Deux apports de Sylvain le 01/09, consignés avant qu'ils se perdent.

Premier : après la réinitialisation complète imposée par l'incident USB, l'envoi
Bluetooth a abouti. Il juge lui-même que ce n'est pas viable. Cela confirme le
diagnostic du 31/08 au lieu de l'infirmer — le refus ne venait pas d'une
interdiction des apps tierces mais de l'occupation du canal PsFTP par Flow.
Montre non encore liée, canal libre, session ouverte. Le prix d'accès au BLE
reste donc « ne pas avoir Flow », et ce prix a augmenté ce matin : la Polar étant
devenue la montre de sport, Flow est le seul canal qui fait entrer les séances
dans HealthKit puis dans coach.

Second : sa question sur le protocole des notifications iOS. L'intuition est
bonne — elles arrivent à la montre pendant que Flow est connecté — mais la spec
ANCS d'Apple, lue à la source, ferme la piste pour un transfert de séance. Les
rôles y sont inversés par rapport à PsFTP : l'iPhone est le serveur
(Notification Provider), la montre est cliente (Notification Consumer), d'où
l'absence de conflit avec Flow. Et le service n'expose que trois
caractéristiques — Notification Source, Control Point, Data Source — sans aucun
mécanisme de transfert de binaire ou de payload applicatif.

Ce qu'ANCS permet en revanche, et qui est noté comme piste : afficher du texte au
poignet sans câble, sans dissocier et sans toucher à Flow, via une notification
locale iOS. Le canal est déjà en place côté projet — @capacitor/local-notifications
installé, local-notifications.js chargé par _layout.html — donc sans build Xcode.
Écrit avec ses limites : pas d'objectif structuré, pas d'alerte de zone, pas de
guidage par étape. Un pense-bête, pas un remplacement du .BPB.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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