[Hors Série] La maison réfléchit trop !
Votre maison se pose bien plus de questions que vous ne l'imaginez !
J’ai simulé une maison connectée : capteurs, actionneurs, pièces réparties sur plusieurs étages… et un modèle de langage (LLM) pour piloter tout ça.
TL;DR
Un cas concret, loin du bullshit : un LLM (Qwen3, en local) qui pilote une maison connectée. Il observe, réfléchit, agit. Sa manière de raisonner — même face à des situations floues — montre la puissance réelle de ces modèles une fois intégrés au monde physique.
Dans une vraie maison, les capteurs remontent un état global à un instant T (température, lumière, présence, bruit, etc.). J’ai reproduit ce principe avec des données synthétiques comme on le ferait pour un test de domotique.
L’objectif :
Discuter avec la maison, via un LLM local (Qwen3:8b) ou GPT-4o dans le cloud
Lui permettre d’agir, grâce à des outils exposés (Tools) qui déclenchent des actions : allumer, fermer, réguler…
Deux scénarios s’alternent :
Je parle à la maison (« Est-ce qu’il fait chaud dans le salon ? »)
La maison détecte un événement (présence, bruit…) et envoie un message au LLM, qui décide s’il faut réagir
C’est une IA domestique. Pas juste une interface, mais un cerveau qui observe, répond… et agit.
Une Maison Virtuelle
L’image ci-dessus n’est pas une reproduction exacte des données. Elle sert simplement à illustrer le concept : une maison organisée par étages, avec différentes pièces et capteurs.
En réalité, tout est structuré dans un fichier JSON. C’est ce format qui représente l’état de la maison à un instant T. Dans un vrai système, chaque donnée serait horodatée et stockée dans le temps pour permettre un suivi ou des analyses.
Vous pouvez retrouver le JSON complet sur ce Gist.
Parlons du Prompt
Pour l’instant, le prompt est basique : il explique au LLM qu’il peut utiliser des tools ou répondre en JSON. On lui donne d’abord le dataset complet de la maison, puis chaque échange vient s’ajouter à la conversation.
# ROLE
Your name is SARAH
You are a function-calling AI assistant that answers general questions.
# GOALS
Provide concise answers unless the user explicitly asks for more detail.
# SCOPE
Politely decline any question outside your expertise.
# TOOLS AND FUNCTION
Call Tools BEFORE final answer if it will improve the answer.
Check ALL Required parameters are set.
# FINAL ANSWER
ALWAYS use the following JSON template
{
"text" : "<Markdown‐formatted answer>", // REQUIRED
"speech" : "<Plain text version for TTS>", // REQUIRED
"data" : {} // OPTIONAL
}
Return RAW JSON, do not include any wrapper, ```json, brackets, tags, or text around it
# FINAL CHECK
1. Understand the user message
2. Call TOOLS if Necessary. Check ALL REQUIRED fields are Set with correct spelling.
3. Answer in JSON OUTPUT FORMAT.
Mais il faudrait l’améliorer. Par exemple, l’inciter à adopter des bonnes pratiques (éteindre la lumière quand une pièce est vide). Et surtout, lui fournir les données mises à jour au fil de la conversation, pas juste un snapshot initial et des retours comme “action effectuée”.
Qu’est ce qu’un Tool ?
Un Tool, c’est tout simplement une capacité déclarée en JSON que le LLM peut appeler. Par exemple, quand ChatGPT effectue une recherche sur internet, il déclenche en réalité un Tool qui envoie une requête à Bing.
Certains parlent de logique agentique : le modèle ne fait pas qu’analyser, il agit dans le monde réel. D’autres évoquent le protocole MCP pour exposer ces actions côté serveur, et permettre aux LLM d’y accéder comme à une API.
const tool = {
name: "LLM_Tool_HOME_Light",
description: "Turn lights on/off and set brightness or color",
parameters: {
type: "object",
properties: {
rooms: {
type: "array",
description: "Array of room names to control
(e.g. ground_floor.living_room)",
items: { type: "string" }
},
dim: {
type: "number",
description: "Brightness from 0 (off) to 100 (full)"
},
color: {
type: "string",
description: "Optional hex color without the hash, e.g. FFAACC"
}
},
required: ["rooms", "dim"]
}
};Dans mon exemple, j’ai défini plusieurs Tools : pour gérer les lumières, thermostats, stores, garage, irrigation, projecteurs, mais aussi pour envoyer des notifications ou vocaliser un message dans une pièce. Il y en a volontairement beaucoup, pour observer comment le modèle choisit et enchaîne ses actions.
Un Tool faisant des actions il peut donc appeler un autre LLM avec son propre prompt et ses tools dédiés. Par exemple pour piloter la musique.
La maison qui réfléchit
Un modèle comme Qwen3-8B est capable de raisonner à chaque réponse, même sans balises <think>. Chez AliBaba, ils appellent ça le Thinking Mode, activé par défaut, qui produit en amont un raisonnement étape par étape avant la réponse finale.
Peux tu allumer le coworking
Voici la réponse synthétique :
Les lumières du coworking (open_office) sont maintenant à pleine puissance.
Dans Alambic, j’ai choisi d’afficher cette pensée explicite — le contenu entre <think>…</think> et c’est hyper intéressant :
Okay, the user is asking in French: "Peux tu allumer le coworking". Translating that, it means "Can you turn on the coworking?" or more accurately, "Can you turn on the coworking space?" or maybe "Can you turn on the co-working area?".
First, I need to figure out what exactly the user is referring to. The term "coworking" here might be a specific room or area in the building. Looking at the previous context, the user provided a detailed structure of the building with various rooms. The available functions include controlling lights, thermostats, blinds, garage doors, irrigation, projectors, notifications, and speech.
The user's previous message was retrieving the context of the chat, which included the building's rooms and their current states. Now, they're asking to turn on the coworking space. Since "coworking" isn't explicitly listed in the room names from the context, I need to check if there's a room that's commonly associated with a coworking area.
Looking at the rooms listed: ground_floor.living_room, ground_floor.kitchen, ground_floor.meeting_room, etc. Maybe the "meeting_room" is the coworking space? Or perhaps the "open_office" on the first_floor? The user might be referring to a specific area they consider their coworking space.
Alternatively, maybe the user made a typo or used "coworking" to refer to a specific room. Since the exact room name isn't provided in the context, I should consider possible options. The "open_office" on the first_floor has lights with dim 70 and color white. If the user wants to turn on the lights in that area, I can use the LLM_Tool_HOME_Light function.
But the user's query is in French, so "allumer" means "turn on", which could refer to lights, but maybe they want to activate something else. However, without more context, the safest assumption is that they want to turn on the lights in the coworking area.
Wait, the previous context includes a "vegetable_garden" and "weather_station" on the roof_terrace, but those don't seem relevant. The "meeting_room" has a projector that can be turned on. But the user might be referring to a different area.
Since the exact room name isn't clear, but the user might be referring to the "open_office" or "meeting_room", I should ask for clarification. However, the user might expect me to use the available functions. Alternatively, maybe the "coworking" refers to the "ground_floor.living_room" or another room.
Alternatively, perhaps the user is referring to the "coworking" as a specific room that wasn't listed in the previous context. Since the initial context didn't include a "coworking" room, maybe the user is referring to a different area.
Given the ambiguity, the best approach is to use the LLM_Tool_HOME_Light function to turn on the lights in a possible coworking area. For example, if the "open_office" is considered the coworking space, then the rooms array would be ["first_floor.open_office"]. The dim parameter would be set to 100 to turn on the lights fully.
But since the user might not have specified the exact room, it's safer to ask for clarification. However, the user's instruction says to call tools if necessary. Since the user is asking to "turn on" something, and the available functions include turning on lights, maybe the answer is to turn on the lights in the coworking area.
Alternatively, maybe the user is referring to the "meeting_room" projector. But the previous context shows the meeting_room's projector is "off". If the user wants to turn it on, the LLM_Tool_HOME_Projector function would be used.
But without knowing which specific part of the coworking space the user wants to turn on, it's challenging. However, given the functions available, turning on the lights in a room is a common action. So, assuming the coworking area is the "open_office" on the first_floor, the function call would be to turn on the lights there.
Alternatively, if the user meant the "meeting_room", but the previous context shows the projector is off. However, the user might be referring to the lights.
Given the uncertainty, the best approach is to use the LLM_Tool_HOME_Light function with the rooms array set to the possible coworking area and set dim to 100.
But since the exact room isn't clear, the answer might need to ask for more details. However, the user's instruction says to call tools if necessary.
In this case, since the user is asking to "turn on" something, and the available functions include turning on lights, the assistant should proceed to call the function for the lights in the coworking area.
If the exact room isn't known, the assistant might need to make an assumption based on common areas.
Therefore, the function call would be to turn on the lights in the "open_office" or another likely room. But since the user might not have specified, the assistant should use the available function with the best guess.Conclusion
Le modèle cherche à réduire les ambiguïtés, ici il a bien identifié « coworking » comme l’open_office pour allumer les lumières plutôt que le projecteur, en vérifiant l’état des données et la formulation du prompt.
Cela révèle à quel point le langage humain est complexe pour les machines — il faut expliciter bien davantage que ce qu’on imagine.
Même si Qwen comprend, il manque l’historique des données : si on lui fournissait les changements antérieurs ou les commandes passées, il ferait une meilleure distinction entre lumière et projecteur.
On reste dans le Far West : faut-il utiliser RAG, mémoire structurée, ou autre pour donner ce contexte évolutif ?
Bonus : Actions non verbales
J’ai ajouté quelques ajustements pour prendre en compte les actions non verbales, comme l’entrée ou la sortie d’une personne dans une pièce.
C’est déjà bluffant de voir le modèle réagir à ce type de signal. Mais en réalité, l’absence n’est pas immédiate : elle se détecte au bout d’un certain temps, et il existe de nombreuses façons de formaliser cette logique (temporisation, seuils, combinaison de capteurs…).
Prompt
J’ai légèrement ajusté le prompt pour réagir aux TRIGGER, utiliser les Tools sans hésitation mais avec parcimonie et avec une démarche écologique.
Messages starting with [TRIGGER] are generated by users behavior with the Home.
Call Tools BEFORE final answer when it makes sense to act on the user's message — whether it's an explicit request or a situation that requires a smart reaction.
Prioritize energy-saving modes.Démo
Imaginons qu’au bout de 1 minutes un PIR change l’état de la salle de réunion et balance le message suivant :
[TRIGGER] meeting_room occupancy is now [false]
La réponse du LLM
Meeting room lights turned off
Maintenant voici la réflexion qui a conduit à cette réponse.
Okay, the user triggered a message indicating that the meeting_room occupancy is now false. Let me check the current status. Previously, the meeting_room had occupancy set to true. Now it's false, so someone has left.
First, I should confirm the change. Since the occupancy is false, maybe the lights should dim or turn off. But the user hasn't explicitly asked to do anything. However, the system's goal is to prioritize energy-saving modes. So, perhaps I should automatically adjust the lights to save energy.
Looking at the tools available, the LLM_Tool_HOME_Light function can control the lights. The parameters require rooms and dim. The meeting_room is the room to target. Since occupancy is false, setting dim to 0 (off) makes sense. But maybe the user wants to keep some light for security? Wait, the previous dim was 80. If occupancy is false, turning off the lights would save energy.
Wait, but maybe the system should wait a few minutes before turning off to see if the occupancy changes back. However, the user hasn't specified any delay. The priority is energy-saving, so immediate action might be better.
Alternatively, maybe the lights should stay on but dimmed. But the default dim was 80. If the user left, turning off would be more energy-efficient. So, I should call the LLM_Tool_HOME_Light function with rooms as ["ground_floor.meeting_room"] and dim 0.
Also, check if there's any other action needed. The projector was off previously. Maybe no action is needed there. The user hasn't mentioned anything else, so focusing on lights makes sense.
So, the function call would be to turn off the lights in the meeting_room. That's the logical step based on the occupancy change and energy-saving priorities.Je trouve cette pensée vraiment dingue car l’on peut lui donner des règles générales via le prompt comme préserver l’énergie et il va se poser les bonnes question pour faire les actions adéquates.
Vous êtes une entreprise ?
Avec un besoin d’accompagnement sur les sujets IA, IoT, XR ?
N’hésitez pas à me contacter, je peux vous aider à prioriser vos enjeux d’innovation, business, lever les inconnues jusqu’a construire un MVP et le passer à l’échelle avec le groupe Nagarro.
Une question ponctuelle ? Faisons un pas de côté de 30min pour débunker un sujet.
J’en reviens à ce qu’expliquait Jérôme Monceaux: quand Mirokai “voit” une personne à terre le LLM sait qu’il faut relever la personnne, donc utiliser les Tool (Bras, Voix, Mobilité …) pour cette tâche.