Contexte et motivations
Le point de rupture le plus fréquent dans les maisons connectées est la perte d’accès aux serveurs des fournisseurs. L’auteur cite deux exemples concrets : l’API Nest interrompue par Google et une erreur TLS affichée sur un réfrigérateur Samsung. Ces incidents justifient la règle fondamentale « pas d’Internet, pas de problème », qui impose que les fonctions essentielles continuent de fonctionner même si la connexion réseau est coupée.
Pour garantir cette résilience, l’ensemble du système repose sur du matériel possédé par l’utilisateur : des cartes ESP flashées avec le firmware Tasmota, un broker MQTT et Node‑RED exécutés sur un Raspberry Pi. Les services cloud (Alexa, plusieurs services AWS) sont conservés uniquement comme interfaces supplémentaires, jamais comme unique point d’entrée.
Architecture technique
Chaque dispositif publie ses mesures sur des topics MQTT ; aucun n’a besoin de connaître les destinataires. Par exemple, le capteur de température BME280 intégré au contrôleur d’arrosage envoie home/garden/temperature et le flux Node‑RED s’abonne pour déclencher la pompe selon un planning. Cette séparation « publish/subscribe » élimine les dépendances point‑à‑point et simplifie l’ajout de nouveaux acteurs (application mobile, tableau de bord, Alexa).
Le broker centralise les messages et assure la persistance locale. En cas de coupure d’Internet, les appareils continuent d’échanger via le réseau local, ce qui maintient l’éclairage, le système d’arrosage et le contrôle du garage opérationnels. Les logs de chaque automatisation sont stockés dans Grafana, permettant de visualiser, par exemple, les 21 ouvertures de porte enregistrées sur plusieurs jours et d’identifier les redondances comme les quatre déclencheurs programmés qui s’affrontaient sur la même pompe.
Analyse des impacts et limites
Le modèle local réduit les risques liés aux API tierces : aucune mise à jour serveur ne peut désactiver une fonction critique. Cependant, il introduit des exigences de maintenance : les firmwares Tasmota doivent être tenus à jour, le broker MQTT doit être sécurisé (authentification, chiffrement TLS) pour éviter l’injection de commandes. Le recours à des batteries est limité à des durées supérieures à un an afin d’éviter les pannes nocturnes, ce qui contraint le choix des capteurs (ex. capteurs de porte à faible consommation).
Les services cloud restent utiles pour l’accès à distance (Alexa, AWS IoT) mais sont configurés comme chemins alternatifs, non comme uniques. Cette redondance implique une gestion cohérente des identifiants et des logs, conformément à la règle « un dispositif cloud nécessite une API avec journalisation ».
Bonnes pratiques et recommandations
1. Centraliser la configuration dans un seul tableau de bord plutôt que de multiplier les applications fournisseurs.
2. Conserver le mode de commande traditionnel (interrupteur mural) pendant la migration vers le dispositif intelligent.
3. Vérifier régulièrement les automatisations pour éviter les conflits, comme les déclencheurs multiples sur un même actionneur.
4. Utiliser des entrées multiples (application, QR code, NFC) afin de garantir l’accès même si l’un des canaux échoue.
