Partir deux semaines en laissant une maison manifestement vide n'est pas très rassurant. Les volets ne bougent plus, aucune lumière ne s'allume, et les rares minuteries que l'on branche à la va-vite se repèrent à leur régularité mécanique. Scénario Studio est né de ce besoin très ordinaire : dessiner une journée type, la faire jouer par la maison pendant l'absence, puis tout retirer au retour.
La règle qui commande tout le reste
L'application n'allume jamais une lumière et ne bouge jamais un volet. Elle écrit des scénarios dans le système domotique de la maison, et c'est lui qui exécute.
Le tableau de bord : ce qui tourne aujourd'hui dans la maison, l'état de la connexion domotique et les raccourcis vers les écrans de travail.
Ce n'est pas un détail d'implémentation, c'est ce qui rend le dispositif fiable : une fois le scénario déposé, l'application peut être éteinte. La maison continue de jouer la comédie toute seule pendant les deux semaines, sans dépendre d'un serveur qui tourne quelque part.
Deux façons de décrire un comportement
C'est la distinction structurante de l'outil, et la seule chose à comprendre pour s'en servir.
L'étape de planning — déclenchée par une heure
« À 7 h 15, ouvrir le volet de la chambre. » C'est ce qui sert à simuler une présence : une succession d'actions posées sur la journée, différentes en semaine et le week-end.
La routine de contrôle — déclenchée par une situation
« S'il fait plus de 25 °C dehors et qu'il y a plus de 500 lux dans la chambre, fermer le volet. » C'est ce qui protège du soleil et de la chaleur, indépendamment de l'heure qu'il est.
Les deux cohabitent dans un même planning et peuvent viser le même volet — ouvrir le matin, refermer quand le soleil tape. C'est le cas normal, pas un conflit : l'outil le signale comme une simple information, pour ne pas crier au loup sur ce qui est justement le comportement recherché.
Les routines de contrôle, énoncées en français : « si telle température et telle luminosité, alors fermer tel volet », avec leur plage horaire et leur délai de confirmation.
Dessiner un planning
Un planning se compose de jours-types — typiquement « semaine » et « week-end » — que l'on affecte aux jours de la semaine. Dans chaque jour-type, on place des étapes en cliquant dans une grille au quart d'heure, de 5 h du matin à minuit. Chaque étape porte une ou plusieurs actions : ouvrir, fermer, fermer partiellement, allumer, éteindre.
Une précision qui a des conséquences visibles : les volets de la maison ne sont pas calibrés. Impossible de demander « ferme à 40 % ». Une fermeture partielle s'exprime donc comme une fermeture, une attente, puis un arrêt — et l'outil ne propose jamais de piloter par pourcentage, ce qui évite de promettre ce que le matériel ne sait pas tenir.
L'éditeur de planning : les jours-types en colonnes, la grille au quart d'heure, l'affectation des jours de la semaine, et en haut les avertissements du validateur.
La relecture avant l'envoi
Avant tout déploiement, deux garde-corps.
Le validateur tourne à chaque enregistrement et applique quatorze règles de cohérence : un volet laissé ouvert toute la nuit, des étapes trop rapprochées pour l'aléa demandé, un équipement devenu indisponible, deux routines qui se contredisent. Il classe ce qu'il trouve en trois niveaux — les erreurs empêchent le déploiement, les avertissements et les informations non. Le but n'est pas d'interdire, c'est de ne pas partir en vacances avec une faute évidente.
L'aperçu montre exactement ce qui sera écrit dans la maison, ainsi que le différentiel par rapport au dernier déploiement réussi. On voit donc non seulement le résultat, mais ce qui change. Rien ne part de cet écran sans un clic explicite.
Une période, puis le retour
Un scénario ne s'applique pas « en général » : on crée une période — ce planning, du 15 au 29 août. Au déploiement, l'application retire d'abord toute autre période encore en place : elle ne laisse jamais deux de ses plannings actifs en même temps dans la maison.
Pendant l'absence, il n'y a rien à faire. Au retour, un bouton retire tout ce qui avait été écrit ; la période, elle, est conservée et pourra être redéployée aux prochaines vacances.
Reste le cas des accidents — un déploiement interrompu, une sauvegarde restaurée. Un écran dédié liste les scénarios présents dans la maison mais absents de la base de l'application, et permet de les supprimer. C'est le filet, et il n'a de sens que parce que tout ce que l'outil écrit est identifiable au premier coup d'œil.
Concevoir n'est pas déployer
L'application distingue trois rôles : consulter, concevoir, administrer. La frontière qui compte n'est pas la première mais la seconde : préparer un scénario et l'écrire réellement dans la maison sont deux gestes de portée différente. Un contributeur peut tout dessiner, tout valider, relire l'aperçu — et c'est un administrateur qui déclenche le déploiement.
Ce que l'outil ne prétend pas faire
Quelques limites, assumées et rappelées dans l'interface là où on les rencontre :
- les conditions d'une routine se cumulent toutes : pour exprimer un « ou », on crée deux routines ;
- une routine ne donne qu'un ordre par équipement — deux ordres opposés dans la même routine s'annuleraient au hasard ;
- les routines de protection suivent les jours de la semaine et ignorent les exceptions de date : le soleil ne consulte pas le calendrier ;
- le système domotique n'arbitre pas entre deux scénarios qui se contredisent — le dernier déclenché gagne. L'outil signale les contradictions qu'il sait démontrer, il ne peut pas les empêcher.
Le reste tient dans une idée simple : on dessine, on relit, on déploie, on retire. Le YAML, les identifiants d'entités et la syntaxe des automatisations restent l'affaire de la machine.