Un jour, ma femme m'a demandé pourquoi la lumière du salon mettait trois secondes à s'allumer. Trois secondes, ce n'est pas grand-chose. Sauf que ces trois secondes passaient par un serveur quelque part en Allemagne, puis revenaient. Un soir de panne internet, la maison est devenue une maison normale. Plus de scénarios, plus d'éclairage automatique, plus rien. Le lendemain, j'ai commandé un mini-PC d'occasion et j'ai commencé à tout rapatrier chez moi.
Ce que j'ai découvert en six mois de bidouille, c'est qu'un serveur domotique local ne se sécurise pas en cochant une case dans une interface. Ça se joue sur trois couches distinctes, et si vous en ratez une, les deux autres ne servent à rien. Je vais vous montrer comment je m'y suis pris, ce qui a raté, et pourquoi j'ai failli tout débrancher au bout de la deuxième semaine.
Points clés à retenir
- Un serveur domotique local n'est utile que si les appareils eux-mêmes ne parlent pas à Internet
- La segmentation réseau (VLAN IoT) est plus importante que le mot de passe de votre box
- Zigbee, Z-Wave et Matter over Thread fonctionnent sans Wi-Fi : c'est le critère de choix n°1
- Un accès distant ne devrait jamais passer par une redirection de port
- Sauvegardez la configuration du serveur avant de toucher au pare-feu. Toujours
Comment configurer un serveur domotique vraiment local
Avant le matériel, il faut trancher une question bête : local, ça veut dire quoi pour vous ? Pour certains, un Raspberry Pi qui tourne dans un placard suffit. Pour d'autres, il faut que rien ne sorte de la maison, jamais.
La différence n'est pas cosmétique. Un serveur qui héberge votre logiciel mais laisse vos ampoules appeler le cloud du fabricant reste dépendant d'Internet. J'ai vu des installations « locales » continuer à tomber en panne quand la fibre coupait, simplement parce que les capteurs étaient des modèles Wi-Fi bas de gamme.
Quelle plateforme pour un serveur local ?
Trois familles d'options, que je classe ici selon mon usage, pas selon les fiches techniques.
| Option | Effort de départ | Contrôle réel | Pour qui |
|---|---|---|---|
| Box domotique propriétaire | Faible | Limité | Qui veut que ça marche ce week-end |
| Raspberry Pi + Jeedom/Domoticz/Gladys | Moyen | Élevé | Qui accepte de lire des logs |
| Mini-PC ou NAS + conteneurs | Élevé | Total | Qui a déjà un peu d'admin système |
Mon choix s'est porté sur un mini-PC d'occasion à 90 euros, avec un SSD et 8 Go de RAM. Franchement, c'est surdimensionné pour Jeedom, mais j'ai pu y coller Home Assistant en conteneur à côté, et ça m'a servi plus tard. La box propriétaire est plus simple, mais quand le fabricant décide d'arrêter le service, votre matériel devient une brique.
Installer, puis durcir immédiatement
L'installation standard de la plupart des plateformes vous laisse avec deux choses à corriger dans la première heure : un compte administrateur par défaut et une interface accessible sur toutes les interfaces réseau. Sur mon premier essai, j'ai laissé l'interface en HTTP simple sur le port 80. Ça a duré quatre jours. Quatre jours pendant lesquels n'importe quel appareil du réseau pouvait tenter de s'y connecter.
- Changez le mot de passe administrateur avant même de configurer le moindre appareil
- Activez l'authentification à deux facteurs si la plateforme la propose
- Restreignez l'écoute aux interfaces nécessaires, pas à 0.0.0.0
- Placez l'interface derrière un reverse proxy avec certificat TLS
- Programmez les mises à jour automatiques de sécurité, pas des fonctionnalités
Le point 3 est celui que tout le monde saute. Sur Jeedom comme sur Domoticz, il existe un réglage qui limite les adresses IP autorisées à accéder à l'interface d'administration. Ça ne coûte rien et ça bloque déjà toute une catégorie de scans opportunistes.
Comment sécuriser le réseau de la domotique sans se couper les doigts
Le deuxième soir, j'ai bloqué mon propre accès à distance en appliquant une règle de pare-feu trop zélée. Ma femme regardait un film, elle n'a rien remarqué. Moi, j'ai passé une heure à rebrancher un écran sur le serveur. Leçon retenue : sauvegardez la configuration avant de toucher au pare-feu.
Créer un VLAN dédié pour les objets connectés
Le principe est simple : vos appareils domotiques ne devraient jamais discuter directement avec votre ordinateur de travail ni avec le NAS qui contient vos photos. Ils vivent sur un segment réseau séparé, et seuls les flux strictement nécessaires traversent la frontière.
Concrètement, sur un routeur qui gère les VLAN (la plupart des routeurs un peu sérieux le font), vous créez un réseau 192.168.30.0/24 pour l'IoT, distinct du réseau principal 192.168.10.0/24. Le serveur domotique, lui, se place sur un troisième segment ou se voit autoriser l'accès aux deux.
- Règle 1 : l'IoT ne peut parler qu'au serveur domotique, sur les ports nécessaires
- Règle 2 : l'IoT n'a aucun accès sortant vers Internet
- Règle 3 : votre réseau principal peut administrer le serveur, mais pas les appareils
- Bloquez les requêtes DNS sortantes des appareils : s'ils ne peuvent pas résoudre, ils ne peuvent pas appeler leur cloud
La règle 2 est celle qui change tout. Aucune de mes ampoules ne peut joindre l'extérieur, donc aucune ne peut envoyer de télémétrie, même si le firmware le voulait. Et le jour où une faille est découverte dans un modèle, la surface d'exposition reste votre réseau interne.
Comment puis-je sécuriser mon accès à distance ?
Vous voulez consulter votre tableau de bord depuis le bureau ou en vacances, et c'est là que la plupart des tutoriels vous font faire une erreur : ouvrir un port sur la box. Une redirection de port vers l'interface domotique, c'est une porte d'entrée permanente sur un service qui n'est pas conçu pour être exposé.
Ma règle : jamais de redirection de port. À la place, un tunnel VPN de type WireGuard, hébergé sur le serveur lui-même ou sur un petit routeur dédié. Vous vous connectez au VPN, et vous accédez à l'interface comme si vous étiez à la maison. Ça ajoute une étape (activer le VPN avant de consulter), mais ça élimine toute la catégorie d'attaques qui visent les services exposés.
Alternative que j'utilise quand le VPN n'est pas pratique depuis un appareil : un service de tunnel chiffré auto-hébergé, avec authentification à deux facteurs devant le tableau de bord. Plus simple à configurer, un peu moins souverain, mais infiniment plus sûr qu'un port ouvert.
Zigbee, Z-Wave, Matter : le critère qui compte vraiment
Voici un tableau qui aurait dû exister dans tous les guides que j'ai lus avant de commencer. La vraie question n'est pas « quel protocole est le plus moderne », c'est « est-ce que cet appareil continue de fonctionner quand la fibre coupe ».
| Protocole | Fonctionne sans Internet | Passerelle nécessaire | Mon avis |
|---|---|---|---|
| Wi-Fi cloud du fabricant | Non | Aucune | À éviter pour tout ce qui est critique |
| Zigbee | Oui | Oui, locale | Le plus répandu, le moins cher |
| Z-Wave | Oui | Oui, locale | Plus cher, meilleure portée |
| Matter over Thread | Oui | Oui (border router) | Prometteur, encore jeune |
J'ai commencé avec des prises Wi-Fi à 15 euros. Cinq sur six ont fini à la poubelle en un an, soit parce que l'application avait changé, soit parce que le fabricant avait arrêté le service. Depuis, je n'achète plus que du Zigbee ou du Z-Wave. La passerelle coûte entre 30 et 50 euros, elle reste chez moi, et elle parle au serveur local sans passer par l'extérieur.
Comment paramétrer un serveur pour qu'il tienne dans le temps
Un serveur domotique qui tourne des années sans surveillance, ça se prépare. Trois choses que j'ai apprises à mes dépens :
- Sauvegardez la configuration chaque semaine, sur un support qui n'est pas le serveur lui-même
- Surveillez l'espace disque : une base de données qui grossit peut faire tomber le service en silence
- Documentez vos automatisations, pas seulement vos appareils
Le deuxième point m'a coûté un week-end entier. Une base de données de moins de 2 Go, mais un journal système qui avait rempli le SSD. Le serveur répondait aux pings, mais toutes les automatisations étaient mortes depuis six jours. Depuis, j'ai une alerte qui m'envoie un message si l'espace libre passe sous 15 %.
Les erreurs que j'ai faites, pour que vous ne les fassiez pas
Trois mois après le début, j'ai brièvement exposé mon tableau de bord sur Internet, le temps d'un déplacement. J'ai découvert plus tard que le service avait enregistré environ 400 tentatives de connexion sur cette période. Aucune n'a abouti, mais je n'ai pas fermé l'œil pendant deux nuits.
Il y a aussi une erreur moins spectaculaire : j'ai voulu tout automatiser d'un coup. Scènes d'éclairage, chauffage, volets, alarme, arrosage du jardin. Résultat : un système complexe que personne d'autre que moi ne comprenait, et que ma famille a fini par contourner en utilisant les interrupteurs physiques. Un serveur local se construit par petites touches. C'est moins satisfaisant sur le moment, mais ça survit au quotidien.
Et un point que je tiens à dire : votre sauvegarde hors ligne compte plus que votre configuration. J'ai perdu deux ans d'historique de capteurs en changeant de disque sans copie préalable. Le chemin, l'heure et la version du serveur, tout était noté. Sauf que le disque, lui, ne se lisait plus.
Ce qui reste après avoir tout configuré
Il y a un moment où vous réalisez que le plus dur n'est pas technique. C'est de choisir ce qu'on automatise. Une lumière qui s'allume toute seule quand vous rentrez, oui. Un système qui décide à votre place de la température du salon, non.
Ce que je cherche maintenant, ce n'est pas la maison qui fait tout à ma place, c'est celle qui continue de fonctionner quand je ne suis pas joignable. Une maison dont les décisions vitales tiennent dans un boîtier qui ne parle à personne. Le jour où l'opérateur coupe, où le service du fabricant disparaît, où une mise à jour casse quelque chose, l'installation tient. C'est ça, la vraie promesse du serveur local. Pas la performance. La résilience.
Et si vous ne devez retenir qu'une chose : commencez par bloquer l'accès Internet de vos appareils, avant même de configurer le plus beau des tableaux de bord. Le reste, c'est de la décoration.
