Une ampoule qu'on allume avec son téléphone est connectée. Elle n'est pas nécessairement intelligente. La différence apparaît quand la maison peut reconnaître une situation courante — quelqu'un part, personne n'est revenu depuis un certain temps, une personne rentre — et exécuter toute seule la suite d'actions appropriée.
C'est une façon beaucoup plus utile d'aborder la domotique. Au lieu de commencer par une liste d'appareils à acheter, on commence par une petite friction du quotidien : ce geste répétitif qu'on aimerait ne plus avoir à faire.
Un exemple réel permet de bien voir la différence. Le besoin de départ était simple : lorsqu'une personne quitte la maison, certains appareils doivent s'éteindre. Si l'absence se prolonge, le robot aspirateur peut profiter du logement vide pour travailler. Au retour, la maison doit reprendre un fonctionnement normal.
Derrière cette demande apparemment banale se cachent presque tous les principes d'une bonne automatisation.
Commencer par « je pars », pas par « je veux automatiser une lampe »
Une erreur fréquente consiste à penser appareil par appareil.
On achète une ampoule intelligente, puis on cherche quoi automatiser avec l'ampoule. On ajoute une prise connectée, puis un capteur, puis une application de plus. Le résultat peut devenir une collection de commandes à distance plutôt qu'une maison qui réduit réellement les gestes du quotidien.
L'approche inverse est plus intéressante : décrire d'abord la situation.
Dans notre exemple :
Situation : la maison devient vide.
Premier effet : les appareils qui n'ont aucune raison de fonctionner en l'absence des occupants peuvent être éteints.
Après une absence suffisamment longue : certaines tâches deviennent au contraire plus faciles à exécuter, comme passer l'aspirateur robot.
Au retour : les fonctions qui doivent être disponibles en présence d'une personne retrouvent leur état normal.
L'objet de l'automatisation n'est donc pas « la lampe » ou « l'aspirateur ». C'est l'état personne à la maison.
Cette distinction paraît théorique, mais elle change complètement la conception du système.
Une automatisation utile a souvent quatre couches
Une façon simple de concevoir un scénario consiste à le décomposer ainsi :
signal → vérification → état → action
Le signal indique que quelque chose vient peut-être de changer. Le téléphone n'est plus détecté sur le réseau, par exemple.
La vérification évite de réagir trop vite. On peut attendre quelques minutes et vérifier que le signal est toujours valable.
L'état représente ce qui se passe réellement dans le logement : « personne n'est à la maison » est beaucoup plus significatif que « le téléphone X vient de disparaître du Wi-Fi ».
Enfin, l'action décrit ce que la maison doit faire dans cette situation.
Cette couche intermédiaire est précieuse. Elle évite de créer une dizaine de règles indépendantes du genre « si le téléphone disparaît, éteindre ceci », « si le téléphone disparaît, éteindre cela », « si le téléphone disparaît, lancer ceci ».
On peut plutôt construire un état cohérent, puis lui associer un scénario.
Le téléphone peut devenir un capteur de présence
Il n'est pas toujours nécessaire d'acheter un détecteur supplémentaire pour commencer.
Un téléphone possède déjà plusieurs caractéristiques utiles à la domotique : il se connecte au réseau Wi-Fi, peut transmettre sa position, entrer dans une zone géographique, communiquer par Bluetooth et fournir différents états à une application d'automatisation.
Home Assistant, par exemple, permet de détecter la présence à partir de la localisation envoyée par un téléphone ou, avec des intégrations compatibles, à partir des appareils vus sur le réseau. Plusieurs sources de suivi peuvent aussi être associées à une même personne.
Cela ouvre une possibilité intéressante : réutiliser ce qui existe déjà avant d'ajouter du matériel.
Dans une première version du système décrit ici, un ancien téléphone Android restait à la maison et devait servir d'intermédiaire pour déterminer si le téléphone principal était encore présent sur le réseau domestique. Ce n'était pas l'architecture la plus élégante à long terme, mais c'était un excellent prototype : elle permettait de vérifier si l'automatisation était réellement utile avant de construire une infrastructure plus ambitieuse.
Un signal n'est pas encore une vérité
Supposons qu'un téléphone disparaisse du réseau Wi-Fi. La conclusion « la personne vient de quitter la maison » semble logique, mais elle n'est pas toujours vraie.
Le téléphone peut changer momentanément de connexion, le réseau peut redémarrer ou le suivi peut simplement prendre du retard.
C'est pourquoi une automatisation robuste ne devrait pas toujours réagir au premier changement observé.
Dans le prototype, l'idée était d'attendre environ 3 à 5 minutes avant de considérer l'absence comme réelle. Ce délai n'est pas une valeur universelle : il dépend du système et du niveau de réactivité recherché. Le principe, lui, est généralisable.
Pour une lumière oubliée, attendre quelques minutes est rarement grave. Déclencher une mauvaise action chaque fois que le réseau hésite devient en revanche très agaçant.
La question à poser pour chaque automatisation est donc : que se passe-t-il si ce signal est faux?
Plus la conséquence est importante, plus la confirmation doit être solide.
La durée fait partie du contexte
« Parti depuis deux minutes » et « absent depuis deux heures » ne décrivent pas nécessairement la même situation domestique.
C'est particulièrement évident avec l'entretien de la maison.
Lorsqu'une personne vient tout juste de sortir, il peut être inutile de lancer immédiatement le robot aspirateur : elle a peut-être seulement descendu les poubelles ou oublié quelque chose dans l'auto.
Après une absence prolongée, la probabilité qu'il s'agisse d'un vrai départ est plus forte et le logement vide crée une occasion : le robot peut circuler sans gêner personne.
On obtient alors un scénario à plusieurs étapes :
- départ probable;
- courte confirmation;
- passage de la maison en mode absence;
- après un délai plus long, lancement éventuel des tâches adaptées à une maison vide;
- retour d'un occupant;
- reprise du mode normal.
C'est beaucoup plus proche de la façon dont on raisonne naturellement qu'une collection de commandes « marche/arrêt ».
Un autre besoin à décrire avant d’automatiser est celui d’une zone de séchage du linge qui gère aussi l’humidité.
Créer des scènes plutôt que piloter chaque appareil partout
Une autre idée utile consiste à séparer ce que la maison doit faire de ce qui décide quand elle doit le faire.
Imaginons un scénario « Départ » qui éteint certaines lumières, modifie le fonctionnement d'un appareil et prépare le logement pour une absence.
Le système chargé de détecter le départ n'a pas besoin de reproduire toute cette logique. Il peut simplement déclencher « Départ ».
Cette séparation devient encore plus intéressante lorsque plusieurs fabricants cohabitent.
Une application de fabricant peut continuer à bien gérer ses propres appareils. Une scène peut regrouper plusieurs actions. Et un niveau supérieur d'automatisation peut décider quand appeler cette scène ou d'autres scripts.
Home Assistant distingue justement ces concepts : une scène décrit des états souhaités pour plusieurs entités, tandis qu'un script peut exécuter une séquence d'actions. Une automatisation ajoute le déclencheur et les conditions qui déterminent quand cette séquence doit partir.
Cette organisation facilite aussi les modifications. Ajouter une nouvelle lampe au scénario « Départ » ne devrait pas obliger à reconstruire toute la logique de détection de présence.
Pour une scène lumineuse, les usages restent prioritaires : planifier l’éclairage de la salle de bain aide à distinguer les besoins.
Le fabricant d'une ampoule ne devrait pas décider de toute la maison
C'est souvent ici qu'un système domotique commence à évoluer.
Dans la première expérimentation, plusieurs appareils étaient gérés dans Xiaomi Home. L'application savait déjà exécuter une scène comprenant plusieurs actions. Le problème n'était donc pas de contrôler individuellement chaque appareil, mais de déclencher cette scène depuis une logique extérieure.
Différentes pistes ont été explorées sur Android : raccourcis, automatisation locale et appels plus directs à l'application. Cette recherche avait une utilité réelle, mais elle révélait aussi une limite architecturale : plus on voulait créer de scénarios transversaux, plus le système dépendait des possibilités offertes par l'application d'un fabricant.
C'est une bonne raison de distinguer deux rôles.
L'écosystème du fabricant peut s'occuper de communiquer avec son matériel.
Le « cerveau » de la maison peut, lui, décider qu'il est temps de passer en mode absence, de lancer une séquence ou de combiner des appareils provenant de plusieurs écosystèmes.
Cette indépendance devient surtout intéressante quand les automatisations se multiplient.
Il n'est pas nécessaire de commencer avec un serveur et vingt capteurs
L'autre erreur serait de conclure qu'une vraie maison intelligente exige immédiatement une installation complexe.
Ce n'est pas le cas.
Le prototype avec un ancien Android avait précisément un intérêt : utiliser du matériel déjà disponible pour résoudre une petite tâche. Des applications d'automatisation Android comme Automate ont permis d'explorer la logique avant de décider si une architecture plus permanente en valait la peine.
Cette démarche évite d'acheter un mini-ordinateur, plusieurs capteurs et des passerelles simplement pour découvrir trois semaines plus tard que le scénario imaginé ne sert presque jamais.
On peut commencer avec une seule friction.
Si la solution fonctionne et que de nouveaux besoins apparaissent, le système peut évoluer.
Quand Home Assistant devient intéressant
Dans le cas présenté ici, l'évolution a finalement mené à une architecture plus centralisée :
téléphone Android → Home Assistant → scripts et automatisations → appareils
Telegram a également été ajouté comme canal pratique d'interaction et de notification.
L'intérêt de Home Assistant n'est pas seulement d'offrir une autre interface. C'est de déplacer la logique de la maison vers un système qui n'appartient pas à un seul fabricant. Le projet met notamment l'accent sur le contrôle local et peut communiquer localement avec les appareils lorsque les intégrations le permettent.
À partir de là, le téléphone peut devenir une source d'information parmi d'autres plutôt que le centre de tout le montage.
Le système peut aussi évoluer vers une présence plus fiable : localisation du téléphone, information du routeur, autres capteurs ou combinaison de plusieurs sources selon les besoins.
Home Assistant n'est donc pas nécessairement le point de départ. Il peut être la réponse naturelle au moment où les petits bricolages commencent à se gêner entre eux.
Une bonne automatisation doit aussi savoir ne rien faire
Le meilleur scénario n'est pas celui qui contient le plus d'étapes.
Une automatisation domestique réussie devient souvent presque invisible. Elle agit lorsqu'une situation est suffisamment claire et reste tranquille lorsqu'elle ne l'est pas.
Avant d'automatiser un geste, quatre questions sont particulièrement utiles :
- Quel problème concret disparaît?
- Quel signal permet de reconnaître la situation?
- Comment éviter un faux déclenchement?
- Que doit-il se passer pour revenir à l'état normal?
La dernière question est facile à oublier. Pourtant, automatiser le départ sans penser au retour crée rapidement des comportements absurdes.
Un aspirateur lancé parce que la maison est vide doit savoir ce qui se passe si quelqu'un revient plus tôt que prévu. Un éclairage désactivé en mode absence ne doit pas empêcher l'arrivée de fonctionner normalement. Une règle temporaire doit avoir une sortie.
Un exemple à reproduire chez soi
Pour commencer, nul besoin de choisir immédiatement une plateforme.
Prenons une situation très banale : quitter la maison.
On peut l'écrire sur papier avant de toucher à une application :
Problème : certains appareils restent inutilement allumés après le départ.
Signal possible : le ou les téléphones ne sont plus détectés à la maison.
Risque d'erreur : une déconnexion temporaire ressemble à un départ.
Confirmation : attendre quelques minutes ou croiser plusieurs informations.
État obtenu : personne à la maison.
Action immédiate : éteindre ce qui n'a pas besoin de fonctionner.
Action différée : si l'absence continue, lancer une tâche plus longue qui dérange lorsqu'on est présent.
Retour : annuler ou adapter les tâches incompatibles avec la présence et rétablir le fonctionnement normal.
À ce moment seulement vient la question des outils.
Peut-être que l'application déjà installée suffit. Peut-être qu'un vieux téléphone peut servir de prototype. Peut-être que le réseau domestique peut fournir la présence. Peut-être qu'après cinq ou dix scénarios, Home Assistant deviendra beaucoup plus simple que l'empilement d'applications.
L'architecture découle du besoin, et non l'inverse.
À retenir
La domotique devient vraiment utile lorsqu'elle cesse d'être une télécommande sophistiquée.
Le meilleur point de départ est une petite situation répétitive : partir, rentrer, dormir, se lever, ouvrir une fenêtre, commencer une lessive ou quitter une pièce. Il faut ensuite trouver un signal suffisamment fiable, prévoir les erreurs, tenir compte de la durée et regrouper les actions dans des scénarios réutilisables.
Un ancien téléphone et une application peuvent suffire pour tester une idée. Une plateforme comme Home Assistant devient pertinente lorsque plusieurs appareils, fabricants et scénarios doivent partager la même logique.
Le but n'est pas d'avoir la maison la plus « intelligente ». C'est d'avoir quelques gestes en moins à penser chaque jour.