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>
474afce348