docs(home-assistant): mettre à jour la documentation de l'intégration présence

Précise l'authentification Bearer (WORKLOG_API_TOKEN), la configuration
des secrets et commandes REST Home Assistant, les codes de réponse de
l'API et la conservation des événements de présence.

Co-authored-by: OpenAI/GPT-5.6-Terra <vibecoder@antoineve.me>

docs/home-assistant.md

@@ -17,12 +17,14 @@ Avant de configurer les automatisations dans Home Assistant, assurez-vous des é
 
 ## 2. Configuration des Secrets (`secrets.yaml`)
 
-Dans le fichier `secrets.yaml` de votre instance Home Assistant, ajoutez votre jeton d'API :
+Dans le fichier `secrets.yaml` de votre instance Home Assistant, ajoutez votre jeton d'API en veillant à ce que sa valeur **inclue obligatoirement le préfixe exact `Bearer `** (suivi d'un espace et de votre jeton secret) :
 
 ```yaml
-worklog_api_token: "votre_jeton_api_securise_ici"
+worklog_api_bearer_token: "Bearer votre_jeton_api_securise_ici"
 ```
 
+> **Attention (point critique)** : Ne préfixez jamais par `Bearer ` dans la section `rest_command`. La commande utilise `authorization: !secret worklog_api_bearer_token`, ce qui injecte directement la valeur complète définie dans `secrets.yaml` (qui doit donc impérativement commencer par `Bearer `).
+
 ---
 
 ## 3. Configuration de la Commande REST (`rest_command`)
@@ -34,9 +36,9 @@ rest_command:
   worklog_presence:
     url: "https://tableau-de-bord-pro.example.com/api/v1/workplace-presence"
     method: "post"
+    content_type: "application/json"
     headers:
-      authorization: "Bearer !secret worklog_api_token"
-      content_type: "application/json"
+      authorization: !secret worklog_api_bearer_token
     payload: '{"event": "{{ event }}", "occurred_at": "{{ occurred_at }}", "idempotency_key": "{{ idempotency_key }}"}'
     verify_ssl: true
 ```
@@ -111,7 +113,7 @@ action:
       occurred_at: "{{ event_timestamp }}"
       idempotency_key: "{{ idempotency }}"
   - choose:
-      - conditions: "{{ response.status not in [200, 201] }}"
+      - conditions: "{{ response.status != 200 }}"
         sequence:
           - service: persistent_notification.create
             data:
@@ -126,14 +128,17 @@ mode: single
 
 ## 5. Gestion des Réponses et de la Sécurité
 
-- **Succès (200 / 201)** : Les codes de succès sont validés silencieusement. En cas de rejeu (réseau instable), l'API renvoie un statut `200` avec le statut `"replayed"`, ce qui est géré sans erreur par l'automatisation.
+- **Succès (200 / 201)** : Les codes de succès sont validés silencieusement :
+  - **Arrivée** : Renvoie `201 Created` lors d'une nouvelle création, ou `200 OK` en cas de rejeu (requête idempotente).
+  - **Départ** : Renvoie strictement `200 OK` (qu'il s'agisse d'un nouvel enregistrement de départ ou d'un rejeu).
+  En cas de rejeu ou de succès normal, la réponse est gérée sans erreur par les automatisations.
 - **Erreurs et Notifications** : Si l'API renvoie un code d'erreur (`400`, `401`, `404`, `405`, `409`, `413`, `415`, `422`, `429`, `500`, `503`), une notification persistante est créée dans Home Assistant. **Le jeton d'authentification n'est jamais inclus** dans les messages de notification pour des raisons évidentes de sécurité.
 
 ---
 
 ## 6. Limites, Risques et Points de Vigilance
 
-1. **Maximum d'une arrivée ouverte** : L'application métier n'autorise qu'une seule arrivée ouverte (`time_slot_id IS NULL`) simultanément. Si une arrivée précédente n'a pas été fermée (ou en cas de faux départ/réarrivée manqués), une tentative de nouvelle arrivée provoquera un conflit `409` (`ArrivalAlreadyOpenError`).
+1. **Maximum d'une arrivée ouverte (globale)** : L'application métier n'autorise qu'une seule arrivée ouverte (`time_slot_id IS NULL`) simultanément **à l'échelle globale de l'application**. Si une arrivée précédente n'a pas été fermée (ou en cas de faux départ/réarrivée manqués), une tentative de nouvelle arrivée provoquera un conflit `409` (`ArrivalAlreadyOpenError`).
 2. **Précision GPS et Oscillations (Doublons / Faux déclenchements)** : Les capteurs de géolocalisation (GPS mobile, intégration companion app) peuvent osciller aux abords de la zone `lieu_de_travail` (mauvaise réception GPS, rebonds d'antenne). Cela peut générer des micro-entrées et sorties successives. Bien que la clé d'idempotence et la règle chronologique protègent contre les doublons stricts basés sur le même horodatage, des entrées/sorties rapprochées multiples peuvent nécessiter des corrections manuelles dans l'interface web du Tableau de bord pro.
 3. **Limitation de débit (Rate-limit)** : L'API applique une limite stricte de **30 requêtes par fenêtre de 60 secondes** par processus. En usage normal avec un unique tracker `person`, cette limite ne risque pas d'être atteinte, mais un dysfonctionnement d'automatisation en boucle pourrait déclencher un blocage `429`.
 4. **Alignement des fuseaux horaires** : Le fuseau horaire configuré dans la section `[home_assistant]` de `config.toml` (ex: `Europe/Paris`) doit être cohérent avec celui de l'instance Home Assistant pour que les conversions d'horodatages ISO 8601 avec offset (`occurred_at`) s'alignent parfaitement avec les journées de travail locales.