OpenClaw chez moi : un assistant IA local relié à Home Assistant, Frigate, Gmail, Patrick et Suno

J’ai longtemps cherché l’usage qui donnerait un véritable intérêt à OpenClaw dans mon quotidien. Un chatbot de plus ne me faisait pas gagner de temps. En revanche, un assistant capable de raisonner avec un modèle local, d’exécuter des tâches planifiées, d’interroger Gmail, de lire Patrick, de dialoguer avec Home Assistant, de traiter les événements Frigate et même de préparer chaque nuit une chanson pour ma fille commence à devenir beaucoup plus intéressant.

Cet article présente l’architecture que j’utilise et celle que je mets progressivement en place dans mon homelab. L’objectif n’est pas de publier une configuration contenant mes adresses IP, mes identifiants, mes tokens ou mes véritables noms d’entités Home Assistant. Je veux plutôt montrer une architecture reproductible, les choix qui ont réellement fonctionné chez moi, les limites rencontrées et les frontières de sécurité que j’ai volontairement imposées.

01Pourquoi OpenClaw et pas simplement un chat IA

Un modèle de langage seul sait répondre. OpenClaw ajoute autour de lui ce qui manque généralement pour transformer une réponse en action : un Gateway toujours actif, des sessions persistantes, un navigateur pilotable, des tâches planifiées, des outils, des skills, des nodes mobiles et des connexions vers d’autres systèmes.

Dans mon cas, je voulais un point d’entrée unique capable de travailler avec plusieurs univers :

• mes e-mails et mon calendrier ;
• les tâches, projets et absences stockés dans Patrick ;
• ma domotique Home Assistant ;
• les événements Frigate et les caméras locales ;
• mon blog et mes sujets de veille ;
• des automatisations créatives comme la chanson quotidienne de Jeanne.

Le vrai intérêt ne vient pas du nombre d’intégrations. Il vient du fait que l’assistant peut conserver un contexte, sélectionner un outil, exécuter une action, observer le résultat et poursuivre la tâche.

C’est aussi ce qui rend la sécurité plus compliquée. Un chatbot qui se trompe produit une mauvaise réponse. Un agent qui se trompe peut envoyer un e-mail, modifier une tâche ou déclencher un appareil. L’architecture doit donc être conçue autour des droits, des frontières et de la vérification, pas seulement autour du modèle le plus intelligent.

02Architecture générale de mon homelab

Mon infrastructure est volontairement séparée en plusieurs rôles. Le serveur IA ne remplace pas Home Assistant, le NAS ou les Raspberry Pi. Chacun conserve une responsabilité claire.

• Serveur IA sous Ubuntu : Ollama, OpenClaw, modèles locaux, stockage des historiques et traitements agentiques.
• Deux RTX 3060 de 12 Go : 24 Go de VRAM cumulée pour les modèles quantifiés.
• 64 Go de DDR4 et Ryzen 5600X3D : mémoire système et CPU pour les services, les débordements et les tâches hors GPU.
• Coral USB TPU : accélération dédiée aux détections utilisées par Frigate.
• Home Assistant sur une machine séparée : orchestration domotique, helpers, scripts, Google Cast et automatisations.
• Frigate : détection d’objets, reconnaissance faciale et publication des événements MQTT.
• Synology et Raspberry Pi : stockage, sauvegardes et services complémentaires.
• Nodes mobiles : notifications, localisation ou actions autorisées selon les appareils et leurs permissions.

[Téléphone / Mac / WebChat]
             |
             v
      [OpenClaw Gateway]
        |      |      |
        |      |      +--> [Skills navigateur / gog / himalaya]
        |      |
        |      +---------> [MCP Patrick / MCP Home Assistant]
        |
        +----------------> [Ollama sur serveur GPU]
                              |
                    muse-glimmer / Ornith / vision

[Caméras PoE] --> [Frigate] --> [MQTT] --> [Home Assistant]
                                           |
                                           +--> Google Cast cuisine
                                           +--> notifications mobiles

[OpenClaw + Suno Web] --> MP3 local --> webhook HA

Pour l’accès distant, je privilégie un VPN comme WireGuard plutôt qu’une exposition directe du Gateway, de Home Assistant ou d’Ollama sur Internet.

03Installation et supervision du Gateway OpenClaw

OpenClaw s’articule autour d’un Gateway. C’est le plan de contrôle chargé des sessions, du routage, des canaux, des tâches planifiées, des nodes et des appels d’outils.

L’installation recommandée passe par l’assistant d’onboarding :

npm install -g openclaw@latest

openclaw onboard --install-daemon

openclaw gateway status --require-rpc
openclaw channels status --probe
openclaw dashboard

Le tableau de bord local est généralement exposé sur le port 18789 en loopback. Je ne conseille pas de remplacer ce comportement par une écoute publique sans avoir lu les options d’authentification et d’exposition distante.

Les commandes que j’utilise pour les contrôles courants sont simples :

openclaw gateway status
openclaw gateway restart
openclaw logs --follow
openclaw doctor

En production domestique, le Gateway doit être supervisé. Sur Linux, il peut fonctionner via un service systemd utilisateur ou système. Le point important est d’éviter deux superviseurs concurrents qui tenteraient de redémarrer le même processus.

04Ollama : configuration 128k et optimisation de la VRAM

Ollama tourne comme service sur le serveur GPU. Mon objectif est de conserver un contexte suffisamment important pour les tâches agentiques tout en évitant que plusieurs modèles et plusieurs requêtes parallèles se disputent les 24 Go de VRAM.

La logique de ma surcharge systemd est la suivante :

# /etc/systemd/system/ollama.service.d/override.conf
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
Environment="OLLAMA_CONTEXT_LENGTH=128000"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q4_0"
Environment="OLLAMA_KEEP_ALIVE=8h"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_NUM_PARALLEL=1"

Puis :

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl status ollama
ollama ps

Pourquoi ces paramètres ?

• OLLAMA_CONTEXT_LENGTH=128000 donne au modèle un budget important pour les historiques, les outils et les tâches longues.
• OLLAMA_FLASH_ATTENTION=1 réduit la pression mémoire lorsque le backend et le modèle le supportent.
• OLLAMA_KV_CACHE_TYPE=q4_0 compresse fortement le cache de contexte. C’est un choix agressif pour faire tenir un grand contexte, avec un compromis potentiel sur la qualité.
• OLLAMA_KEEP_ALIVE=8h évite de recharger le modèle principal à chaque interaction.
• OLLAMA_MAX_LOADED_MODELS=1 empêche plusieurs gros modèles de rester simultanément en mémoire.
• OLLAMA_NUM_PARALLEL=1 évite de multiplier la consommation du KV cache avec plusieurs requêtes parallèles.

Avec ma configuration actuelle, ollama ps montre le modèle principal chargé à 100 % sur le GPU, avec un contexte de 128k et un keep-alive de huit heures. C’est le résultat que je recherchais : pas d’offload massif vers le CPU, car les performances d’un agent s’effondrent rapidement lorsqu’il passe son temps à déplacer les données entre la RAM et la VRAM.

Connexion d’OpenClaw à Ollama

OpenClaw utilise l’API native d’Ollama. Il ne faut pas ajouter /v1 à l’URL, car ce mode compatible OpenAI peut dégrader la gestion des appels d’outils.

Exemple simplifié dans ~/.openclaw/openclaw.json :

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://<SERVEUR_OLLAMA_LAN>:11434",
        apiKey: "ollama-local",
        api: "ollama",
        timeoutSeconds: 300,
        contextWindow: 128000,
        models: [
          {
            id: "muse-glimmer:latest",
            name: "muse-glimmer:latest",
            input: ["text"],
            params: {
              num_ctx: 128000,
              keep_alive: "8h"
            }
          }
        ]
      }
    }
  },
  agents: {
    defaults: {
      model: {
        primary: "ollama/muse-glimmer:latest"
      }
    }
  }
}

La valeur contextWindow informe OpenClaw du budget disponible. La valeur num_ctx est transmise à Ollama. Je préfère les garder cohérentes pour éviter qu’OpenClaw construise un contexte que le backend ne peut pas réellement exécuter.

05Choisir les modèles selon les usages

Je ne cherche plus le « meilleur modèle absolu ». Je cherche le meilleur modèle que mon matériel peut exécuter correctement pour une tâche donnée.

Mon ollama list contient davantage de modèles, mais les conserver sur disque ne signifie pas les charger tous. Le paramètre OLLAMA_MAX_LOADED_MODELS=1 force un choix clair et évite une fragmentation inutile de la VRAM.

Il faut également garder une réalité en tête : un modèle local quantifié de 20 à 35 milliards de paramètres peut être très utile, mais il ne présente pas la même robustesse qu’un grand modèle cloud sur les longues chaînes d’outils, les instructions ambiguës ou les contenus susceptibles de contenir des injections de prompt.

06Skills, MCP et séparation des droits

OpenClaw distingue plusieurs notions souvent mélangées :

• le modèle, qui raisonne ;
• l’outil, qui exécute une action ;
• le skill, qui explique au modèle quand et comment utiliser des outils ;
• le serveur MCP, qui expose des fonctions structurées provenant d’une application externe ;
• le Gateway, qui orchestre l’ensemble.

Un skill OpenClaw est principalement un ensemble d’instructions Markdown, souvent organisé autour d’un fichier SKILL.md. Cela ne signifie pas qu’il faut installer n’importe quel skill sans le lire.

openclaw skills search "suno"
openclaw skills verify @machinesbefree/suno-browser-songmaking
openclaw skills verify @machinesbefree/suno-browser-songmaking --card
openclaw skills install @machinesbefree/suno-browser-songmaking

Mes principales intégrations

• gog : accès scriptable à Gmail, Calendar, Drive, Docs, Sheets et Contacts.
• Himalaya : gestion d’e-mails via IMAP, SMTP, Gmail ou Microsoft Graph selon le compte.
• Home Assistant MCP : lecture du contexte domotique et exécution d’actions autorisées.
• Patrick MCP : lecture des tâches, projets et absences.
• Browser automation : interaction avec des services Web qui ne disposent pas d’une API adaptée.
• blogwatcher : veille, analyse de sources et préparation de sujets de blog.

Je sépare autant que possible les intégrations en lecture seule des intégrations capables d’écrire ou de déclencher une action. Un outil qui lit le calendrier n’a pas besoin du droit d’envoyer un e-mail. Un workflow Suno n’a pas besoin d’un token administrateur Home Assistant.

07Gmail et Google Workspace avec gog

Pour Google Workspace, j’utilise gog, une CLI pensée pour les scripts et les agents. Elle expose des commandes stables avec des sorties JSON ou texte simples à exploiter.

Exemples :

gog gmail search 'newer_than:7d' --max 20
gog calendar events --today
gog drive ls --max 20 --json

L’authentification repose sur OAuth. Les autorisations doivent être limitées aux services nécessaires et les tokens doivent rester dans le trousseau ou l’espace de secrets prévu, jamais dans un prompt, un dépôt Git ou un fichier de log.

Un premier workflow exécute chaque matin une analyse des e-mails reçus pendant les dernières 24 heures :

1. rechercher les nouveaux messages ;
2. supprimer le bruit évident ;
3. résumer les sujets importants ;
4. extraire les actions et les échéances ;
5. rapprocher les actions des projets existants dans Patrick ;
6. produire un résumé persistant dans memory/YYYY-MM-DD-email-summary.md ;
7. envoyer une notification sur un node mobile.

Je commence en lecture seule. La création automatique de tâches ou l’envoi de réponses ne doivent être activés qu’après avoir constaté que l’extraction est fiable et que le modèle ne transforme pas chaque phrase en urgence.

08Patrick IA comme source de contexte opérationnel

Patrick est mon assistant de gestion d’équipe. Il centralise les tâches, les projets, les comptes rendus, les absences et une partie du contexte opérationnel.

J’ai déjà consacré un article complet à son fonctionnement : Patrick IA : l’assistant de gestion d’équipe.

L’intégration MCP utilisée par OpenClaw expose notamment des outils de lecture :

patrick-read__get-person-open-tasks
patrick-read__get-project-operational-context
patrick-read__get-team-upcoming-time-off

Le prénom suffit pour interroger les tâches d’une personne ; l’agent n’a pas besoin de demander un UUID à l’utilisateur.

Cette intégration permet à OpenClaw de répondre à des demandes comme :

• « Quelles sont les tâches ouvertes de cette personne ? »
• « Quel est le contexte opérationnel du projet IFS ? »
• « Qui sera absent la semaine prochaine ? »
• « Les actions détectées dans mes e-mails existent-elles déjà dans Patrick ? »

Le choix d’une surface en lecture seule est volontaire. Le jour où OpenClaw pourra créer ou modifier directement des tâches, ces outils seront séparés et soumis à des règles plus strictes.

09Home Assistant : contrôle conversationnel et périmètre exposé

Home Assistant propose désormais un serveur MCP officiel exposé sur /api/mcp. Un client MCP peut ainsi accéder aux outils de l’API Assist et au contexte des entités autorisées.

Dans mon architecture, un pont MCP local peut écouter sur un port interne dédié avant de relayer les appels vers Home Assistant. Ce port ne doit pas être exposé à Internet.

Le point essentiel est le contrôle d’accès :

• utilisateur Home Assistant dédié lorsque c’est possible ;
• entités explicitement exposées à Assist ;
• aucun accès à des domaines inutiles ;
• pas de serrure, portail ou action sensible accessible sans règle complémentaire ;
• journalisation des appels importants.

Les commandes conversationnelles deviennent alors possibles :

• « Éteins les lumières du salon » ;
• « Quel est l’état de la pompe à chaleur ? » ;
• « Active le mode nuit » ;
• « Donne-moi les températures des principales pièces ».

10Frigate : distinguer reconnaissance faciale et vision générative

Frigate effectue localement la détection d’objets et la reconnaissance faciale. Lorsqu’une reconnaissance est réalisée, il publie sur MQTT un message frigate/tracked_object_update contenant notamment :

{
  "type": "face",
  "id": "...",
  "name": "Jeanne",
  "score": 0.95,
  "camera": "camera_cuisine",
  "timestamp": 178...
}

C’est Frigate qui doit rester la source de vérité pour l’identité d’une personne. Un modèle de vision comme Qwen VL peut décrire une scène, des vêtements, un colis ou un contexte. Il ne doit pas être utilisé pour improviser l’identité de quelqu’un à partir d’une simple image.

Je sépare donc deux pipelines :

• Reconnaissance d’identité : Frigate, base de visages locale, score et caméra connus.
• Description sémantique facultative : modèle de vision local pour enrichir une notification, par exemple « personne portant un manteau rouge avec un sac ».

Cette distinction évite une erreur fréquente : demander au LLM « Qui est sur l’image ? » et traiter sa réponse comme un fait. Le modèle génératif peut halluciner. Frigate, lui, produit un nom, un score et un identifiant de caméra structurés.

Dans mes automatisations sensibles, je filtre toujours :

• le type d’événement ;
• le vrai nom technique renvoyé par Frigate ;
• la caméra exacte ;
• un score minimal configurable ;
• les éventuelles zones utiles.

11Grand cas d’usage : la chanson du matin de Jeanne

C’est probablement l’automatisation la plus inutilement complexe et la plus amusante de mon installation.

Chaque nuit, OpenClaw prépare une chanson originale pour Jeanne. Le matin, la chanson ne se lance pas à heure fixe. Home Assistant attend que Frigate reconnaisse Jeanne dans la cuisine, sur une seule caméra précise, puis diffuse le morceau sur le Google Cast de cette même pièce.

02:00
OpenClaw
   |
   +--> historique des 30 dernières chansons
   +--> météo du matin
   +--> concept + paroles + style
   +--> navigateur Suno authentifié
   +--> génération et sélection
   +--> téléchargement MP3
   +--> stockage local + URL HTTP
   +--> POST webhook Home Assistant
                         |
                         v
                 chanson prête = oui

06:30 - 10:30
Frigate caméra cuisine
   |
   +--> type = face
   +--> nom = Jeanne
   +--> score >= 0,80
                         |
                         v
                 Home Assistant
                         |
                         +--> une seule lecture par jour
                         +--> Google Cast cuisine

11.1 Une frontière de sécurité très claire

OpenClaw gère uniquement :

• la création de la chanson ;
• l’interaction avec Suno ;
• le téléchargement ;
• l’exposition locale du MP3 ;
• la notification par webhook.

Home Assistant gère uniquement :

• l’attente du matin ;
• les événements MQTT de Frigate ;
• la reconnaissance de Jeanne ;
• la caméra autorisée ;
• la plage horaire ;
• l’anti-répétition ;
• le volume et le Google Cast de la cuisine.

OpenClaw ne pilote jamais directement le Google Home. Il ne reçoit aucun token administrateur Home Assistant et ne tente pas lui-même de reconnaître Jeanne.

11.2 Installer et contrôler le skill Suno

Je n’utilise pas d’API Suno tierce. Le skill @machinesbefree/suno-browser-songmaking automatise le site Web avec une session de navigateur persistante.

openclaw skills verify @machinesbefree/suno-browser-songmaking
openclaw skills install @machinesbefree/suno-browser-songmaking

Le skill est essentiellement un runbook de navigation : recueillir un brief, écrire les paroles, passer en mode personnalisé, saisir les paroles et les tags de style, lancer la génération et examiner les résultats.

J’utilise un profil navigateur dédié à Suno. Lorsqu’une reconnexion est nécessaire, elle est effectuée manuellement dans ce profil. L’agent ne reçoit jamais le mot de passe en clair.

11.3 Planifier le job à 02:00

OpenClaw possède son propre planificateur Cron. Les tâches sont stockées par le Gateway et survivent à ses redémarrages.

Exemple de job isolé :

openclaw cron create "0 2 * * *" \
  --name "Jeanne - chanson du matin" \
  --session isolated \
  --tz "Europe/Paris" \
  --exact \
  --model "ollama/muse-glimmer:latest" \
  --tools "browser,exec,read,write" \
  --timeout-seconds 3600 \
  --message "Exécute le workflow documenté de création de la chanson quotidienne de Jeanne. Une seule génération réelle, historique obligatoire, stockage local, contrôle HTTP puis notification du webhook."

La tâche est isolée afin de ne pas polluer la conversation principale. Le timeout est volontairement large, car la génération et le téléchargement via un service Web peuvent prendre du temps.

11.4 Produire des chansons réellement différentes

Le plus difficile n’est pas de générer une chanson. C’est d’éviter de générer la même chanson tous les jours avec trois mots différents.

Chaque exécution consulte un historique persistant, par exemple :

{
  "date": "2026-08-20",
  "title": "Jeanne et l'araignée qui faisait du disco",
  "story": "Une araignée apprend à Jeanne une danse magique",
  "characters": ["Jeanne", "Araignée Disco"],
  "style": "disco funk enfantin",
  "weather": "soleil",
  "filename": "2026-08-20-jeanne-araignee-disco.mp3",
  "media_url": "http://<SERVEUR_OPENCLAW>:8088/music/jeanne/2026/08/..."
}

Avant de créer un nouveau concept, l’agent regarde au minimum les 30 dernières chansons et accorde une attention particulière aux sept derniers jours.

Il évite :

• le même thème deux jours de suite ;
• le même style musical ;
• le même personnage central ;
• la même structure d’histoire ;
• les refrains et formulations répétitives.

Environ une chanson sur cinq doit utiliser un univers entièrement original. Jeanne aime les sorcières, les araignées, les petits ours, les histoires magiques, les aventures et certains univers connus, mais les prompts ne demandent jamais de copier une chanson, des paroles, une mélodie ou le style précis d’un artiste.

La météo du matin sert uniquement d’inspiration :

• pluie : bottes magiques, flaques et grenouilles ;
• soleil : jardin, trésor et pique-nique ;
• vent : cerf-volant ou voyage dans les nuages ;
• neige : petit ours et château de neige ;
• brouillard : forêt magique et amusante.

Si la météo est indisponible, la chanson doit tout de même être générée. Une source d’inspiration ne doit jamais devenir un point de panne obligatoire.

11.5 Paroles et description musicale

Les paroles sont écrites en français pour une enfant de cinq ans, avec une durée cible de deux à trois minutes.

Structure privilégiée :

Intro courte
Couplet 1
Refrain
Couplet 2
Refrain
Pont
Dernier refrain
Conclusion

Le ton reste joyeux, drôle, rassurant et magique. Les sorcières, araignées ou monstres peuvent apparaître, mais ils restent gentils ou amusants.

Les styles varient fortement : pop enfantine, pop-rock, disco, funk, synthpop, swing, jazz joyeux, folk, musique de conte, orchestral aventure ou électro légère.

11.6 Stocker et exposer le MP3

Le fichier n’est pas seulement téléchargé. Il doit être servi par HTTP afin que le Chromecast puisse le récupérer directement.

Organisation :

/srv/openclaw/music/
└── jeanne/
    └── 2026/
        └── 08/
            └── 2026-08-20-jeanne-araignee-disco.mp3

Exemple de serveur HTTP minimal avec Nginx en Docker :

services:
  jeanne-music:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "8088:80"
    volumes:
      - /srv/openclaw/music:/usr/share/nginx/html/music:ro

L’URL devient alors :

http://<IP_OPENCLAW_LAN>:8088/music/jeanne/2026/08/fichier.mp3

Le port doit rester accessible uniquement depuis le LAN. Le volume est monté en lecture seule et aucun autre répertoire du serveur n’est exposé.

Avant d’appeler Home Assistant, OpenClaw vérifie que l’URL répond correctement et que le type MIME permet la lecture du MP3.

11.7 Notifier Home Assistant sans lui donner de token

Le webhook ne déclenche aucune lecture immédiate. Il annonce uniquement que la chanson du jour est prête.

{
  "date": "2026-08-20",
  "title": "Jeanne et l'araignée qui faisait du disco",
  "media_url": "http://<IP_OPENCLAW>:8088/music/jeanne/2026/08/fichier.mp3",
  "filename": "fichier.mp3",
  "style": "disco funk enfantin",
  "story": "Jeanne rencontre une araignée qui adore danser",
  "weather": "soleil"
}

Test :

curl -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "date":"2026-08-20",
    "title":"Test Jeanne",
    "media_url":"http://<IP_OPENCLAW>:8088/music/jeanne/test.mp3"
  }' \
  "http://<IP_HOME_ASSISTANT>:8123/api/webhook/<SECRET_ALEATOIRE>"

Côté Home Assistant :

trigger:
  - platform: webhook
    webhook_id: !secret suno_daily_webhook_id
    allowed_methods:
      - POST
    local_only: true

L’identifiant du webhook doit être long, aléatoire et traité comme un mot de passe. Il ne doit jamais apparaître dans l’article, un dépôt public ou une capture d’écran.

11.8 La machine à états Home Assistant

Home Assistant conserve au minimum les états suivants :

• input_boolean.suno_daily_enabled ;
• input_boolean.suno_daily_ready ;
• input_boolean.suno_daily_played ;
• input_text.suno_daily_title ;
• input_text.suno_daily_media_url ;
• input_text.suno_daily_date ;
• input_number.suno_daily_volume ;
• input_number.suno_daily_face_score ;
• input_datetime.suno_daily_start_time ;
• input_datetime.suno_daily_end_time.

Valeurs initiales :

• volume : 35 % ;
• score facial minimal : 0,80 ;
• début : 06:30 ;
• fin : 10:30 ;
• une seule lecture quotidienne.

Le webhook vérifie que la date reçue correspond au jour courant, stocke le titre et l’URL, active ready et remet played à zéro.

Une automatisation à 00:05 réinitialise les états. Si la génération échoue pendant la nuit, la chanson de la veille ne peut donc pas être rejouée par erreur.

11.9 Déclencher uniquement sur Jeanne, dans la cuisine

Le trigger MQTT écoute :

frigate/tracked_object_update

La condition logique est strictement équivalente à :

type == "face"
AND name == VALEUR_REELLE_FRIGATE_POUR_JEANNE
AND camera == VALEUR_REELLE_CAMERA_9_CUISINE
AND score >= seuil_configurable
AND heure comprise entre 06:30 et 10:30
AND chanson prête
AND date chanson == aujourd'hui
AND chanson non jouée
AND Google Cast cuisine disponible

Il ne faut jamais inventer le nom technique de la caméra, de Jeanne ou du media_player. Ils doivent être lus dans Frigate et Home Assistant pendant l’installation.

Les cas suivants ne déclenchent rien :

• Louis reconnu ;
• une autre personne reconnue ;
• une simple détection person ;
• Jeanne reconnue sur une autre caméra ;
• un score insuffisant ;
• un événement hors plage horaire ;
• une chanson ancienne ou déjà jouée.

11.10 Anti-répétition et race conditions

Frigate peut publier plusieurs reconnaissances en quelques secondes. Une simple condition played == false ne suffit pas toujours si deux exécutions démarrent simultanément.

La stratégie robuste combine :

• une automatisation Home Assistant en mode: single ;
• un verrou temporaire in_progress facultatif mais recommandé ;
• un script de lecture séparé ;
• une attente courte du passage du lecteur en état playing ;
• le passage de played à vrai seulement après l’envoi de la commande.

Le script :

1. sélectionne le Google Cast de la cuisine ;
2. règle le volume ;
3. appelle media_player.play_media ;
4. utilise l’URL reçue ;
5. indique le titre lorsque le lecteur le supporte.

11.11 Gestion des erreurs

• Suno indisponible : retenter raisonnablement pendant la nuit.
• Session expirée : arrêter proprement et demander une reconnexion manuelle.
• Génération échouée : retenter sans consommer une quantité incontrôlée de crédits.
• Téléchargement échoué : reprendre le téléchargement sans recréer la chanson.
• Serveur HTTP inaccessible : ne pas notifier Home Assistant tant que le fichier n’est pas lisible.
• Webhook indisponible : conserver le MP3 et retenter uniquement la notification.
• Échec de la nuit : ne jamais remplacer silencieusement la chanson du jour par celle de la veille.

12OpenClaw comme assistant de veille et de blog

OpenClaw peut également devenir un point d’entrée pour ma veille : surveiller les sorties OpenClaw, Ollama, Home Assistant, Frigate, IFS ou PC SOFT, retrouver les sujets déjà traités et préparer une liste d’idées.

Je ne veux pas qu’il publie automatiquement. Il peut :

• collecter les sources ;
• détecter les changements ;
• relier un sujet à mes anciens articles ;
• préparer une structure ;
• signaler les affirmations à vérifier ;
• proposer un brouillon.

La publication reste une action humaine, car une erreur factuelle ou une mauvaise interprétation ne doit pas devenir automatiquement un article public.

13Sécurité, confidentialité et réduction du rayon d’explosion

Le principal risque d’un agent n’est pas qu’il soit « intelligent ». C’est qu’il dispose de trop de droits.

Mes règles principales :

• Gateway non exposé directement à Internet ;
• accès distant par WireGuard ou autre VPN ;
• Ollama limité au LAN et filtré ;
• skills tiers vérifiés et lus avant installation ;
• profils navigateur dédiés aux services automatisés ;
• OAuth et tokens stockés dans un trousseau ou un gestionnaire de secrets ;
• agents et workspaces séparés pour les usages professionnels et familiaux ;
• outils d’écriture séparés des outils de lecture ;
• Home Assistant limité aux entités exposées ;
• webhook Suno local, POST uniquement et sans token HA ;
• logs locaux avec une durée de conservation maîtrisée ;
• aucun secret dans Git, les prompts ou les articles.

14Limites réelles de l’agent local

Le contexte de 128k coûte cher

Un contexte important améliore les tâches longues, mais augmente fortement la consommation du KV cache. La quantification q4_0 aide à le faire tenir, au prix d’un compromis.

Un modèle local ne remplace pas systématiquement un grand modèle cloud

Pour une conversation simple, muse-glimmer produit chez moi de très bons résultats. Pour des agents complexes avec beaucoup d’outils, un modèle local peut boucler, oublier une contrainte ou mal interpréter un résultat.

Les nodes mobiles consomment de la batterie

Les fonctions de localisation, de mouvement, de capture ou de notification dépendent des permissions du système et peuvent être limitées lorsque le téléphone optimise agressivement l’application en arrière-plan.

OAuth et sessions Web expirent

Gmail, Google Workspace et Suno peuvent demander une nouvelle authentification. Une bonne automatisation doit s’arrêter clairement au lieu de tenter de contourner une page de connexion.

Le local demande de l’exploitation

Il faut surveiller les services, les sauvegardes, les disques, la VRAM, les mises à jour, les certificats et les logs. Le cloud masque une partie de ce travail ; le local vous le rend.

15Ce que cette architecture change réellement

OpenClaw commence à avoir de la valeur lorsque je ne le considère plus comme une interface de chat, mais comme un orchestrateur.

Ollama fournit le raisonnement local. OpenClaw apporte les sessions, les tâches planifiées, les outils et le navigateur. Home Assistant conserve la décision domotique. Frigate reste responsable de la reconnaissance. Patrick fournit le contexte métier. Suno génère la musique dans une frontière clairement identifiée.

Chaque composant possède une responsabilité et, surtout, chaque intégration possède un niveau de confiance différent.

Le résultat n’est pas un assistant omnipotent avec un token administrateur sur toute la maison. C’est une collection de workflows limités, observables et remplaçables.

Et c’est probablement la leçon la plus importante : pour qu’un agent soit réellement utile, il ne faut pas commencer par lui donner tous les accès. Il faut commencer par un besoin précis, une frontière claire, un test reproductible et un moyen simple de l’arrêter.