Scénario Studio tourne sur Python 3.12, sans aucune étape de compilation front et sans le moindre paquet npm. Quinze dépendances en production, choisies moins pour leur popularité que pour une raison précise. Cet article passe en revue ces choix — et surtout ce qu'ils ont apporté concrètement.
Le socle web
FastAPI assure le routage, la validation et l'injection de dépendances. C'est ce dernier point qui a compté : session de base de données et client domotique sont injectés dans les routes, ce qui permet de les remplacer dans les tests sans bricolage ni variable globale. Une fonctionnalité de confort côté production, une fonctionnalité structurante côté tests.
Uvicorn sert l'application : un seul processus à lancer, à surveiller et à redémarrer. Pour une application domestique, cette simplicité d'exploitation vaut mieux qu'une architecture distribuée dont personne n'a besoin.
Les données
SQLAlchemy 2 en mode asynchrone, avec les modèles typés de la nouvelle API. L'asynchrone impose une discipline salutaire : un chargement paresseux non prévu ne passe pas inaperçu, il lève une erreur. On est donc obligé de dire explicitement ce que l'on veut charger — ce qui évite la lente dérive vers des dizaines de requêtes cachées par page.
Alembic gère les migrations, avec deux particularités : un environnement asynchrone, et le mode « batch » indispensable à SQLite, incapable de modifier une colonne en place. Les migrations sont testées en appelant la vraie ligne de commande dans un sous-processus, et un test échoue dès qu'un modèle a changé sans migration correspondante.
SQLite pour un usage personnel, PostgreSQL dès que plusieurs personnes écrivent, les deux pilotes étant asynchrones. La bascule est proposée dans l'interface, mais ne prend effet qu'au redémarrage : changer de moteur sous les pieds d'un processus en cours de requête serait un risque gratuit, et l'ancienne base reste intacte.
Pydantic 2 valide les schémas d'API et la configuration. Le bénéfice est net au démarrage : une configuration incohérente fait échouer le lancement, au lieu d'être découverte trois écrans plus loin par une erreur incompréhensible.
Le dialogue avec la maison
httpx pour l'API REST — et sa fonction de transport simulé, qui permet de faire répondre une fausse instance domotique entière sans réseau ni serveur de test. websockets pour l'API temps réel, seul moyen d'accéder aux registres des pièces et des appareils.
PyYAML produit les automatisations, avec un représenteur maison qui force l'écriture des heures entre apostrophes — sans quoi une heure comme 18:45:00 serait relue comme un nombre.
La sécurité
Authlib gère l'authentification par OpenID Connect, en flux d'autorisation avec PKCE, toutes les adresses provenant de la découverte automatique du fournisseur — rien n'est codé en dur. Les comptes locaux restent disponibles en accès de secours.
cryptography chiffre les secrets persistés hors base : clé dérivée de la clé applicative, chiffrement symétrique authentifié. Quant aux mots de passe locaux, ils sont hachés avec scrypt, disponible dans la bibliothèque standard — les paramètres de coût sont inscrits dans l'empreinte, ce qui permettra de les renforcer plus tard sans invalider l'existant. Aucune dépendance supplémentaire pour cela.
L'interface, sans étape de build
C'est le choix le plus discutable en apparence, et le plus rentable à l'usage : pas d'interface monopage, pas de compilation, pas de dépendances JavaScript à maintenir.
- Jinja2 rend le HTML côté serveur.
- HTMX permet de ne renvoyer que des fragments de HTML lors des interactions. Le serveur reste la seule source de vérité : il n'y a pas d'état dupliqué entre le client et le serveur, donc pas de désynchronisation entre les deux.
- Alpine.js couvre ce qui doit répondre sans aller-retour : panneaux, filtres, glisser-déposer dans la grille.
- Tailwind fournit les styles, ce qui laisse à peine plus de cent lignes de CSS maison.
Le vrai gain n'est pas la performance, c'est la durée de vie : une application sans chaîne de compilation front se reprend deux ans plus tard sans avoir à réparer d'abord l'outillage qui la construit. La contrepartie est connue — pas d'interactions très riches côté client — et elle correspond au besoin.
Détail d'ergonomie qui tient en une variable : chaque section porte sa couleur — ciel pour les plannings, ambre pour les équipements, émeraude pour les périodes. La teinte est posée une fois sur la page et consommée par quatre classes ; on sait toujours où l'on se trouve, sans multiplier les feuilles de style.
L'interface entière est du HTML rendu côté serveur : ni interface monopage, ni compilation, ni dépendance JavaScript à maintenir.
La qualité
pytest et son extension asynchrone en mode automatique, ruff pour le formatage et l'analyse, mypy pour le typage — non strict, mais avec la vérification des fonctions non annotées, ce qui attrape l'essentiel sans transformer chaque modification en négociation avec l'outil.
Le fil conducteur de ces choix
Aucun de ces composants n'est exotique, et c'est délibéré. Trois critères ont guidé la sélection : ce qui se teste sans réseau (le transport simulé de httpx, l'injection de dépendances de FastAPI), ce qui échoue tôt et bruyamment (validation de configuration au démarrage, refus des chargements implicites, types de date qui rejettent une valeur ambiguë) et ce qui survit au temps (pas de chaîne de compilation, bibliothèque standard quand elle suffit).
Une application domestique n'a pas de contrainte de charge ; sa vraie contrainte est de rester compréhensible et modifiable longtemps après avoir été écrite.