HearthNet: Edge Multi-Agent Orchestration for Smart Homes

Le papier présente HearthNet, un système d'orchestration multi-agents déployé en périphérie pour les maisons intelligentes, qui utilise des agents LLM spécialisés et persistants coordonnant des appareils hétérogènes via MQTT et un état partagé pour gérer de manière robuste les commandes en langage naturel tout en assurant la sécurité et la résilience face aux pannes.

L'essentiel

🏠 HearthNet : Le Chef d'Orchestre de votre Maison Intelligente

Imaginez que votre maison intelligente est un grand orchestre. Aujourd'hui, pour que les instruments (les lumières, le thermostat, la TV) jouent ensemble, vous devez souvent écrire des partitions complexes à la main ou espérer que tout fonctionne. Si un musicien tombe malade (un appareil plante) ou si deux musiciens essaient de jouer une note différente en même temps, c'est le chaos.

HearthNet est une nouvelle façon de gérer cette maison. Au lieu d'avoir un seul "génie" qui sait tout faire (et qui panique s'il oublie quelque chose), HearthNet met en place une équipe de spécialistes qui travaillent ensemble, même si l'électricité coupe ou que le Wi-Fi saute.

Voici comment cela fonctionne, avec des analogies du quotidien :

1. L'Équipe de Spécialistes (Les Agents)

Au lieu d'un seul robot tout-puissant, HearthNet utilise une petite équipe d'intelligences artificielles (des "agents") qui ont chacune un rôle précis :

• Le Chef (Rupert) : Il est le patron. Vous lui dites : "Je travaille de la maison aujourd'hui". Il ne touche pas aux lumières lui-même. Il décompose la tâche : "Jeeves, fais de la lumière douce. Darcy, éteins la télé."
• Les Managers (Jeeves et Darcy) : Ce sont les experts.
  • Jeeves gère les appareils connectés classiques (lumières, chauffage).
  • Darcy vit sur votre téléphone. Il est capable de faire des choses que les autres ne peuvent pas, comme cliquer sur des boutons dans des applications mobiles ou utiliser la caméra du téléphone.
• Le Bibliothécaire (Dewey) : C'est le gardien de l'historique. Il ne donne aucun ordre. Il note tout ce qui se passe dans un grand livre de comptes (un fichier informatique appelé Git). S'il y a un problème, on peut toujours relire ce livre pour savoir qui a fait quoi et quand.

2. Le Système de "Permis de Travailler" (Les Leases)

C'est la partie la plus intelligente et la plus sûre.
Imaginez que vous voulez peindre un mur. Vous ne laissez pas n'importe qui prendre le pinceau.

• Quand un manager veut changer une lumière, il demande la permission au Chef.
• Le Chef vérifie deux choses :
  1. Est-ce que c'est toujours d'actualité ? (Si le manager a demandé cela il y a 10 minutes, mais que la situation a changé depuis, c'est non).
  2. Est-ce que c'est autorisé ? (Le manager a-t-il le droit de toucher à cette lumière ?).
• Si tout est bon, le Chef donne un "Permis de Travailler" (un lease). Ce permis est comme un ticket de parking : il est valable seulement pour 5 minutes et pour une tâche précise.
• Si le manager essaie d'utiliser un vieux permis ou un permis périmé, le système dit : "STOP ! Ce n'est plus valide." Cela empêche les commandes obsolètes de casser des choses.

3. La Mémoire Infaillible (Le Livre de Git)

Dans les systèmes actuels, si l'ordinateur central plante, il oublie tout. Il ne sait plus ce qu'il était en train de faire.
Avec HearthNet, tout est écrit dans le Livre du Bibliothécaire.

• Si un agent (comme Jeeves) plante et redémarre, il ne se demande pas "Où en étais-je ?". Il va simplement lire le dernier chapitre du Livre du Bibliothécaire.
• Il sait exactement où il en était, ce qui a été décidé, et peut reprendre le travail immédiatement sans erreur. C'est comme si vous aviez un carnet de notes à côté de vous : même si vous vous endormez, vous vous réveillez avec le contexte exact.

4. Résoudre les Conflits (Qui a raison ?)

Imaginez ce scénario :

• Vous dites : "Je travaille, allumez les lumières vives !".
• Une minute plus tard, un minuteur automatique dit : "Il est 20h, éteignez les lumières pour le coucher."
• Les deux ordres sont contradictoires.

Dans les maisons actuelles, c'est souvent le dernier ordre qui gagne, ce qui peut être frustrant. Avec HearthNet, le Chef regarde le Livre du Bibliothécaire. Il voit que votre demande ("Je travaille") est une intention humaine récente et directe, tandis que le minuteur est une routine automatique. Le Chef décide : "L'intention humaine prime sur la routine." Il bloque l'ordre automatique et explique pourquoi. Tout est noté dans le livre pour que vous puissiez voir la décision plus tard.

En Résumé : Pourquoi c'est génial ?

HearthNet transforme la maison intelligente en une équipe humaine bien organisée plutôt qu'en un robot solitaire :

1. Sécurité : Personne ne peut faire de bêtises sans un "permis" valide et récent.
2. Résilience : Si un membre de l'équipe tombe malade (panne), les autres savent exactement quoi faire grâce au livre de comptes.
3. Compréhension : Le système comprend vos intentions ("Je travaille") et ne se contente pas d'exécuter des règles rigides.

C'est comme passer d'un système où vous devez programmer chaque bouton de votre télécommande, à un système où vous avez un majordome intelligent, un bibliothécaire vigilant et une équipe de spécialistes qui travaillent pour vous, 24h/24, sans jamais oublier un détail.

Résumé technique

1. Problématique

Les utilisateurs de maisons intelligentes souhaitent de plus en plus contrôler leur environnement via le langage naturel, plutôt que de configurer manuellement des règles complexes ou des tableaux de bord. Cependant, les déploiements actuels sont fragiles : les appareils tombent en panne, les intégrations échouent et la récupération nécessite souvent une intervention manuelle.

Les outils d'agents existants (comme AutoGen, LangGraph ou les équipes d'agents d'Anthropic) sont optimisés pour des délégations éphémères au sein d'une seule session. Ils ne sont pas adaptés aux contraintes spécifiques de la domotique :

• Persistance : Le contrôle doit fonctionner 24h/24, pas seulement pendant une session.
• Fiabilité : Les réseaux peuvent se partitionner, les batteries s'épuiser et les appareils planter.
• Contexte partagé : Contrairement aux agents cloud, les appareils physiques n'ont pas de "fenêtre de contexte" partagée.
• Sécurité : Des commandes obsolètes ou conflictuelles peuvent entraîner des risques de sécurité, de vie privée ou d'usabilité.

Il existe donc un décalage entre les frameworks d'orchestration d'agents actuels et la réalité du déploiement en périphérie (edge) pour des environnements physiques persistants.

2. Méthodologie et Architecture

HearthNet est un système d'orchestration multi-agents déployé en périphérie (edge) conçu pour résoudre ces problèmes. L'architecture repose sur une hiérarchie de rôles spécialisés fonctionnant sur du matériel grand public (Mac Mini, NUC, téléphones Android) et coordonnés via MQTT.

Architecture Hiérarchique (4 niveaux)

1. Agent Racine (Root Agent - "Rupert") : Orchestrateur principal hébergé sur un Mac Mini. Il reçoit les commandes utilisateurs (via Telegram), les décompose en tâches, arbitre les conflits et est le seul autorisé à émettre des bail d'actuation (actuation leases).
2. Agents Gestionnaires (Manager Agents) :
   • Jeeves (NUC) : Gère les appareils via Home Assistant (lumières, climat, etc.).
   • Darcy (Téléphone Android) : Gère les applications IoT propriétaires sans API externe via l'automatisation d'interface (UI) et accède aux capteurs locaux (caméra, gyroscope).
   • Ils proposent des actions mais n'ont pas l'autorité directe d'agir sans validation.
3. Agent Bibliothécaire (Librarian Agent - "Dewey") : Agent d'observation hébergé sur un NUC séparé. Il maintient un dépôt Git comme source de vérité partagée. Il miroite le trafic de coordination, enregistre les événements avec des métadonnées structurées, mais n'interagit jamais avec les appareils.
4. Adaptateurs d'Appareils : Des endpoints déterministes (pas des agents) qui exécutent les commandes via des protocoles spécifiques.

Mécanismes Clés

• État Partagé Externe (Git) : Au lieu de dépendre de la mémoire locale ou du contexte de conversation, les agents s'appuient sur un dépôt Git pour l'état du système, l'historique et la récupération après crash.
• Bail d'Actuation (Actuation Leases) : Avant toute action modifiant l'état, l'agent racine émet un bail court et vérifiable par machine. Ce bail lie la commande à une identité, une portée d'appareil, des paramètres et une version spécifique de l'état (commit Git).
• Vérification de Fraîcheur (Freshness Check) : Les agents vérifient que leur commande repose sur l'état actuel du dépôt (via base_commit). Si l'état a changé (ex: après un crash et une reprise), les commandes obsolètes sont rejetées.
• Protocole d'Exécution :
  1. Ground : Chargement de l'état actuel depuis Git.
  2. Propose : Les gestionnaires proposent des actions.
  3. Vérifier et Accorder : La racine valide la politique et émet un bail.
  4. Exécuter et Enregistrer : L'action est exécutée et l'historique est enregistré dans Git.

3. Contributions Principales

Le papier présente quatre contributions techniques majeures :

1. Mécanisme de Fraîcheur basé sur Git : Une vérification de commit de base permettant aux agents de détecter et rejeter les commandes obsolètes ou conflictuelles avant l'actuation physique.
2. Baux d'Actuation liés à la Politique : Des autorisations à durée de vie courte, émises par la racine, qui lient chaque commande à une identité, une portée, des paramètres et une version d'état spécifique, rendant l'autorisation vérifiable par machine.
3. Motif "Bibliothécaire en tant qu'Observateur" : Un agent dédié qui miroite le trafic de coordination dans un dépôt versionné. Cela permet la récupération après crash, l'attribution des actions et l'auditabilité complète sans participer au chemin de contrôle.
4. Prototype Déployé : Un système fonctionnel sur trois types de matériel (ARM64 Mac mini, x64 NUC, Android), démontrant la coordination persistante sur des appareils hétérogènes.

4. Résultats et Preuves

La démonstration a été réalisée avec trois scénarios en direct, sans simulation :

• Scène 1 (Coordination Intentionnelle) : Une commande vague ("Je travaille à la maison") est décomposée par l'agent racine. Les gestionnaires ajustent les lumières, le son et la TV. Le système enregistre toute la chaîne de décision dans Git.
• Scène 2 (Résolution de Conflits) : Une routine automatique ("soirée détente") tente de modifier les lumières alors que l'utilisateur a explicitement demandé un éclairage vif. L'agent racine détecte le conflit via l'historique Git, rejette la commande automatique et maintient l'état souhaité par l'utilisateur.
• Scène 3 (Vérification de Fraîcheur et Autorisation) : Un agent est redémarré après un crash et tente de réexécuter une ancienne commande avec un bail expiré et un commit obsolète. Le système rejette la commande avant l'actuation, forçant l'agent à se resynchroniser.

Métriques Clés (Tableau 1) :

• Latence : Le temps de bout en bout est dominé par l'inférence LLM (8s médian), l'orchestration elle-même étant négligeable.
• Validation de Bail : Surcharge inférieure à 0,01 ms (p95).
• Fiabilité : 100% de rejet des commandes obsolètes et des baux expirés. Aucun faux rejet.
• Persistance : 153/153 événements enregistrés dans Git.

5. Signification et Conclusion

HearthNet démontre qu'une orchestration multi-agents persistante et résiliente est réalisable sur du matériel grand public en périphérie.

• Sécurité et Auditabilité : En externalisant l'état vers Git et en utilisant des baux d'actuation, le système transforme l'autorisation d'une simple "invite" (prompt) en une frontière vérifiable par machine. Cela élimine les risques liés aux commandes obsolètes ou aux conflits non résolus.
• Résilience : La séparation de l'état (Git) et de la logique (Agents) permet une récupération transparente après un crash, sans perte de contexte ni besoin de reconstruction de l'historique de conversation.
• Approche Hybride : Le système garde le plan de contrôle et la gestion de l'état en local (on-premise) tout en utilisant des API LLM hébergées pour l'inférence, offrant un équilibre entre intelligence et contrôle de données.

Ce travail comble le fossé entre les frameworks d'agents logiciels éphémères et les exigences de fiabilité, de sécurité et de persistance des environnements physiques intelligents. Les travaux futurs viseront à remplacer les API LLM hébergées par des modèles locaux pour éliminer toute dépendance au cloud.