Dessiner plutôt que programmer
Placer une action dans une grille de quinze minutes doit suffire à décrire une journée. L'utilisateur raisonne en volets, en pièces et en horaires — jamais en YAML ni en syntaxe d'automatisation.
Ne jamais piloter la maison directement
L'application n'allume aucune lumière et ne bouge aucun volet : elle écrit des automatisations, c'est Home Assistant qui exécute. Une règle vérifiable, pas une intention — le client ne sait émettre que trois appels de service, tous du domaine automation.
Des scénarios autonomes
Les bornes de dates vivent dans la condition de l'automatisation, pas dans un ordonnanceur applicatif. Conséquence directe : l'application peut être éteinte pendant les deux semaines d'absence, le scénario tient tout seul.
Un retrait propre, garanti
Tout ce qui est écrit dans la maison porte une marque de fabrique. L'application ne touche jamais une automatisation qu'elle n'a pas créée, et sait retirer l'intégralité de la sienne — un écran dédié traque même les résidus d'un déploiement interrompu.
Contexte & Problématique
Simuler une présence, de façon crédible
Une maison inhabitée se repère : volets figés, aucune lumière, horaires trop réguliers. Il fallait des horaires variables, des journées différentes en semaine et le week-end, et un aléa qui évite l'effet mécanique.
Des volets non calibrés
Impossible de demander « ferme à 40 % » : le pilotage par position est banni de tout le projet. Une fermeture partielle s'exprime en fermeture, attente, arrêt — une contrainte qui remonte jusqu'au modèle de données.
Cohabiter avec une installation existante
Home Assistant héberge déjà des automatisations écrites à la main. L'outil devait pouvoir y ajouter les siennes sans jamais risquer d'en modifier ou d'en supprimer une autre.
Concevoir n'est pas déployer
Préparer un scénario et l'écrire réellement dans la maison sont deux gestes de portée différente. Cette frontière est devenue une séparation de rôles dans l'application.
Réalisation
-
1. Synchroniser les équipements
L'application lit les entités de Home Assistant : leurs états par l'API REST, les pièces et appareils par l'API WebSocket — les registres ne sont accessibles que là. Rien n'est jamais supprimé du miroir local : une entité disparue est marquée indisponible, pour que le problème se voie au lieu qu'une ligne de planning s'évapore.
-
2. Rattacher les équipements au métier
Un identifiant technique devient « Volet cuisine », avec sa nature et sa pièce. Le rattachement se fait en lot. Les capteurs, eux, ne se rattachent pas : ils ne sont jamais pilotés.
-
3. Dessiner un planning
Un planning est un jeu de jours-types — semaine, week-end — affectés aux jours de la semaine. Dans chacun, on place des étapes à l'heure voulue en cliquant dans une grille de quinze minutes ; chaque étape porte une ou plusieurs actions.
-
4. Ajouter des routines de contrôle
Une bibliothèque de routines déclenchées par une situation — trop de soleil, trop de chaleur — plutôt que par une heure. On les place dans le planning, pour tous les jours ou pour un jour-type.
-
5. Valider et relire
Quatorze règles de cohérence tournent à chaque enregistrement : volet laissé ouvert la nuit, étapes trop rapprochées pour l'aléa demandé, capteur indisponible, routines contradictoires. Les erreurs bloquent le déploiement, pas les avertissements.
-
6. Déployer sur une période
Un planning appliqué du 15 au 29 août. Avant l'envoi, l'aperçu montre le YAML tel qu'il sera écrit, avec le différentiel par rapport au dernier déploiement réussi. Rien ne part sans un clic explicite.
-
7. Retirer, et vérifier qu'il ne reste rien
Au retour, tout ce qui a été écrit est supprimé ; la période est conservée et peut être redéployée. Un écran « orphelins » liste les automatisations présentes dans la maison mais absentes de la base — le filet en cas de déploiement interrompu.
Stack technique
Cœur applicatif
Données
Interface, sans étape de build
Dialogue Home Assistant
Sécurité
Qualité
Résultats & Impact
Le scénario survit à l'application
Les bornes de dates étant portées par les automatisations elles-mêmes, la maison continue de jouer le scénario même si le serveur applicatif est arrêté.
Un garde-fou prouvé, pas promis
Toute écriture et toute suppression passent par un contrôle de marquage ; un test démontre qu'une suppression visant un identifiant non marqué échoue.
Tester sans toucher aux volets
Un mode développement capture les équipements réels en lecture seule, puis débranche la maison : un simulateur répond en REST et en WebSocket, ce qui permet d'éprouver un déploiement complet sans conséquence physique.
Une suite de tests autonome
Aucune instance domotique, aucune base préexistante, aucun fichier de configuration n'est nécessaire pour lancer les 1014 tests — condition d'une reprise sereine du projet.
Galerie
