diff --git a/docs/polar-ble-runbook-mac.md b/docs/polar-ble-runbook-mac.md
index 9e26311..7118c9d 100644
--- a/docs/polar-ble-runbook-mac.md
+++ b/docs/polar-ble-runbook-mac.md
@@ -78,6 +78,23 @@ partage pas**, et une synchro Flow en cours empêchera la connexion.
 En cas d'échec, le message distingue les cas — montre introuvable, PsFTP
 muet, requête refusée. Ce ne sont pas les mêmes causes.
 
+## L'heure de l'objectif — ce qu'on sait, et ce qu'on ne sait pas
+
+Un objectif est rangé sous `/U/0/<AAAAMMJJ>/TST/<HHMMSS>/`, et le `start_time`
+écrit dans le fichier doit concorder avec ce dossier : c'est le couple qui situe
+la séance dans la journée. `build_session.py --hour` et le paramètre `hour` des
+routes produisent les deux ensemble, il n'y a donc rien à accorder à la main.
+
+⚠️ **En revanche, on ignore si la montre conditionne l'affichage à cette
+heure.** Propose-t-elle l'objectif toute la journée, ou seulement à son
+approche ? Le test du 2026-08-17 ne l'a pas mesuré. À observer au premier envoi
+réussi : écrire un objectif daté 18 h et regarder s'il apparaît immédiatement.
+
+- S'il apparaît tout de suite → l'heure n'est qu'une étiquette, en fixer une par
+  défaut suffit.
+- S'il n'apparaît qu'à l'approche → il faut écrire à l'heure du départ. Sans
+  conséquence pratique : l'envoi se fait de toute façon juste avant de sortir.
+
 ## Ce qui reste inconnu, et ne se lèvera qu'ici
 
 1. **La V3 accepte-t-elle une connexion BLE tierce** alors qu'elle est appairée