La réinitialisation du 31/08 était un choix, pas une nécessité constatée

Sylvain corrige : il a réinitialisé la montre de son propre chef, la montre
n'avait pas planté. Cette section affirmait « les redémarrages n'ont rien changé,
il a FALLU une réinitialisation » — une inférence présentée comme une
observation, et personne n'avait épuisé les gestes réversibles avant.

Ce qui reste établi : après un essai BLE refusé, l'interface USB ne répondait
plus dans la foulée — plus aucun /dev/cu.usbmodem*, system_profiler muet, même
câble et même port qu'une heure plus tôt. Ce qui ne l'est pas, et qui est retiré :
que ce soit durable, qu'une réinitialisation soit le remède, et que « le firmware
dégrade son état ». Cette dernière formule extrapolait depuis une observation
unique. Le plantage du 17/08 sur requête malformée, lui, reste établi.

Si le cas se reproduit, la marche à suivre demande maintenant d'épuiser les
gestes réversibles — débrancher, changer de port et de câble, redémarrer la
montre, laisser reposer — et de noter lequel a marché. C'est la mesure qui
manque au dossier.

Conséquence sur une décision prise ce matin : le refus d'ajouter un bouton
« Réessayer » s'appuyait sur ce « coût matériel avéré ». La prémisse ne tient
plus telle quelle. Le bouton reste absent pour une autre raison — la voie BLE
n'est pas viable, outiller la répétition d'un chemin qu'on n'emprunte pas serait
à contre-emploi — et la section dit désormais que la décision revient à Sylvain.

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

docs/polar-ble-runbook-mac.md

@@ -287,25 +287,40 @@ OK) pour libérer son canal, puis rouvrir Flow.
 3. **Le firmware plante sur requête malformée.** Les garde-fous couvrent les
    formes connues ; ils ne prouvent pas qu'il n'en existe pas d'autres.
 
-## 🔴 CE QUE L'ESSAI BLE A COÛTÉ (31/08) — à lire avant d'en retenter un
+## 🟠 CE QUE L'ESSAI BLE A COÛTÉ (31/08) — corrigé le 01/09
 
-Après la tentative de connexion Bluetooth refusée par la montre
+⚠️ **Cette section a d'abord été écrite plus alarmante que les faits.** Sylvain
-(« connexion impossible » à l'écran), **son interface USB a cessé d'exister** :
+l'a corrigée le 01/09 : **la réinitialisation était de son propre chef**, pas une
+nécessité constatée. Distinguer ce qui a été observé de ce qui en a été déduit.
+
+**Observé** — après la tentative de connexion Bluetooth refusée par la montre
+(« connexion impossible » à l'écran), **son interface USB ne répondait plus** :
 plus aucun `/dev/cu.usbmodem*`, et `system_profiler` ne listait plus rien —
 alors que la montre chargeait normalement, et que c'était le même câble, le même
 port et la même montre qu'une heure plus tôt.
 
-**Les redémarrages n'ont rien changé.** Il a fallu une **réinitialisation** pour
+**Déduit à tort** — « les redémarrages n'ont rien changé, il a *fallu* une
-que l'USB revienne.
+réinitialisation ». La réinitialisation a été **choisie**, pas imposée : aucune
+autre voie n'a été épuisée avant. On ne sait donc pas si l'USB serait revenu
+seul, après un délai, un autre port ou un autre câble.
 
-⚠️ **Conséquence à assumer** : une tentative de connexion PsFTP refusée peut
+⇒ **Ce qui reste établi** : un essai BLE refusé peut laisser l'USB muet dans la
-désactiver durablement l'interface USB de la V3. Ce n'est pas une hypothèse,
+foulée. ⇒ **Ce qui ne l'est pas** : que ce soit durable, ni qu'une
-c'est ce qui s'est produit. Le firmware ne se contente pas de refuser : il
+réinitialisation soit le remède. Si le cas se reproduit, épuiser d'abord les
-dégrade son état.
+gestes réversibles — débrancher/rebrancher, changer de port et de câble,
+redémarrer la montre, laisser reposer — et **noter lequel a marché**. C'est
+cette mesure qui manque.
 
-⇒ **Ne pas retenter d'essai BLE sans nécessité**, et surtout pas juste avant une
+⚠️ **Conséquence à assumer, dans sa juste mesure** : une tentative de connexion
-sortie : le repli par câble n'est pas garanti disponible après coup. Si un essai
+PsFTP refusée peut laisser l'USB muet — observé une fois. Que le firmware
-doit avoir lieu, écrire la séance PAR CÂBLE D'ABORD.
+« dégrade durablement son état » était une extrapolation depuis cette
+observation unique : **retirée**. Le plantage du 17/08 sur requête malformée,
+lui, reste établi et documenté plus haut.
+
+⇒ **Ne pas multiplier les essais sans raison**, et prévoir que le câble puisse
+ne pas répondre juste après. Écrire la séance PAR CÂBLE D'ABORD quand c'est
+possible — non parce que la casse est certaine, mais parce qu'un aller-retour de
+diagnostic avant une sortie coûte plus que deux minutes d'anticipation.
 
 ## Si la montre se bloque
 
@@ -448,10 +463,17 @@ cohérente avec les envois réussis du 01/09, pas une méthode établie.
 
 ### Pourquoi il n'y a pas de bouton « Réessayer » dans l'UI
 
-Il serait facile à écrire, et c'est délibérément écarté : **chaque tentative de
+⚠️ **Écrit sur une prémisse trop forte, corrigée le 01/09.** L'argument était
-session PsFTP refusée a un coût matériel avéré** — celle du 31/08 a désactivé
+« chaque tentative refusée a un coût matériel avéré — celle du 31/08 a désactivé
-l'interface USB de la montre jusqu'à une réinitialisation. Un bouton qui banalise
+l'USB jusqu'à une réinitialisation ». Or la réinitialisation était **un choix de
-la répétition transformerait un risque connu en réflexe. Le geste reste manuel,
+Sylvain**, pas une nécessité constatée. Ce qui reste : l'USB a été muet après un
-et l'avertissement reste devant.
+essai, une fois, et personne n'a cherché s'il serait revenu seul.
+
+Le bouton n'est donc pas refusé sur un risque « avéré ». Il reste absent parce
+que **la voie BLE elle-même n'est pas viable** (course contre Flow, geste manuel
+sur la montre à chaque envoi) : outiller la répétition d'un chemin qu'on
+n'emprunte pas serait du travail à contre-emploi. **C'est à Sylvain de trancher
+s'il veut ce bouton** — la décision lui revient, et l'argument matériel ne doit
+plus peser plus qu'il ne vaut.
 
 [qs]: https://support.polar.com/e_manuals/vantage-v3/polar-vantage-v3-user-manual-francais/quick-settings.htm