2,3 Ko. C’est la taille du fichier json.html qui tourne sur la passerelle Wattcube Web de mon tableau électrique. Il m’a fallu trois ans de domotique pour comprendre que ce fichier valait plus que tous les hubs « intelligents » vendus avec une app exclusive. Parce que ce fichier, c’est la sortie de secours qui évite l’enfermement dans une seule interface, un seul fournisseur, un seul cloud.
JSON, pas un protocole, un format de données
JSON signifie JavaScript Object Notation. Malgré le nom, il n’y a pas de JavaScript à écrire. Il s’agit simplement d’une manière structurée d’écrire des données lisibles par un humain et par une machine. Pas de binaire, pas de licence, pas d’abonnement. Du texte pur que n’importe quel script shell, Python ou Node.js peut lire en quelques lignes. Dans un monde domotique où chaque fabricant invente son API REST propriétaire, le JSON brut et local fait figure d’arme anti-obsolescence.
Wattcube Web : quand une box industrielle joue l’ouverture
Le Wattcube Web n’a jamais été une box domotique grand public au sens marketing du terme. Conçu par une entreprise spécialisée dans les modules d’éclairage sur rail DIN, c’est une passerelle qui pilote des micromodules CPL, des contacteurs et des compteurs d’énergie. L’interface d’origine se résume à un panneau de supervision web plutôt austère, accessible via l’adresse IP locale de la box. Rien de très spectaculaire.
Sauf qu’à une époque où la plupart des fabricants imposaient leur application mobile comme seul moyen d’interroger l’état des équipements, le Wattcube Web faisait un choix radical : exposer toutes les données de ses modules via une URL unique, /json.html. Une page qui ne renvoie pas du HTML décoratif, mais un objet JSON structuré avec, pour chaque module, son identifiant, son état, sa consommation instantanée et la date du dernier relevé.
Ce n’est pas une API complète avec authentification OAuth et token refresh. C’est un fichier. Et c’est sa force. Un cron job sur un Raspberry Pi, un script Node-RED, un plugin Home Assistant, tout peut venir y piocher l’état réel de l’installation sans jamais solliciter un serveur distant, sans renouveler un jeton toutes les deux heures, sans craindre la fermeture d’un service en ligne qui rendrait la box muette.
Ce que le JSON local apporte que les API cloud ne donneront jamais
La promesse classique d’une box connectée, c’est « piloter depuis votre smartphone où que vous soyez ». Pour cela, le fabricant fait transiter toutes les commandes par son cloud. Dans le meilleur des cas, la latence passe de 5 ms en local à 200 ms en passant par Internet. Dans le pire, vous perdez l’accès à votre propre chauffage quand les serveurs du constructeur sont en panne.
Un fichier JSON servi directement par la passerelle rétablit une vérité simple : l’état de votre maison vous appartient, ici et maintenant. Pas besoin de 4G, pas besoin d’abonnement, pas besoin que le fournisseur soit encore en vie dans cinq ans. Si votre réseau local fonctionne, vos dashboards fonctionnent. Et si vous voulez une supervision à distance, vous mettez vous-même en place un VPN, un reverse proxy ou un tunnel dont vous maîtrisez les paramètres.
C’est l’essence du local-first que nous défendons quand nous évoquons la Hardware & Tech : la couche logicielle la plus résiliente est celle qui ne dépend d’aucune infrastructure extérieure. Le Wattcube Web incarnait ce principe bien avant que Matter ne le remette au goût du jour.
Les limites d’un fichier json.html
L’approche a ses angles morts, qu’il serait malhonnête de ne pas évoquer. Un fichier statique n’est pas une API bidirectionnelle. Vous pouvez lire l’état, mais pour commander un module, il faut encore employer l’interface web classique ou les applets de la box. Certains utilisateurs ont patiemment cartographié les requêtes HTTP internes pour construire des pilotes capables d’écrire. Cela demande du temps, des compétences et une bonne dose de tolérance à l’absence de documentation officielle.
La seconde limite, c’est le volume. Avec une trentaine de modules, le JSON reste compact et se parse en quelques millisecondes. Poussez l’installation à une centaine de points pilotés et vous atteignez des tailles de réponse qui commencent à peser sur le petit processeur de la passerelle. La consommation de la box peut légèrement augmenter si vous interrogez le fichier toutes les secondes. Un polling raisonnable, autour de 5 à 10 secondes, ne pose aucun problème.
Enfin, le JSON local expose tout, tout le temps. Si votre réseau domestique n’est pas segmenté, n’importe quel appareil connecté peut techniquement lire ce fichier. L’avantage devient un risque quand un invité malin ou un objet IoT peu fiable se met à fouiller. Un VLAN dédié à la domotique règle le problème en quelques minutes, mais ce n’est pas un réflexe standard.
Questions fréquentes
Pourquoi le Wattcube Web a-t-il choisi JSON plutôt que MQTT ?
Les concepteurs de la passerelle ne l’ont jamais officiellement expliqué. Une hypothèse probable tient à la simplicité de déploiement : un fichier HTML servi par le serveur web embarqué, sans broker supplémentaire à configurer, sans client à installer. C’était le plus petit dénominateur commun, celui qui garantit qu’un intégrateur peut récupérer les données avec un simple navigateur ou un script wget. Ce n’est pas idéal pour du push temps réel, mais pour un pilotage avec une fréquence de rafraîchissement de cinq secondes, c’est amplement suffisant.
Est-ce que cette approche fonctionne encore avec les box domotiques récentes ?
Oui, et de manière encore plus fluide aujourd’hui. La plupart des logiciels modernes (Home Assistant, Jeedom, openHAB) disposent de connecteurs REST ou de la possibilité d’ingérer un fichier JSON distant via un capteur command line. On écrit une petite commande curl et on transforme la réponse en entités. L’absence d’authentification complexe élimine la moitié des problèmes d’intégration. En 2026, ce vieux fichier json.html reste l’un des moyens les plus rapides de réintégrer une installation héritée dans un tableau de bord moderne.
Peut-on appliquer ce principe à d’autres équipements ?
Absolument. Il suffit que le fabricant expose un endpoint HTTP renvoyant du JSON. Certains chargeurs de véhicule électrique le font, quelques compteurs d’énergie modbus en rajoutent un via un petit serveur intégré. Si vous flashez un ESP32 avec ESPhome, vous obtenez exactement cela : une API JSON locale, sans intermédiaire. Le modèle du Wattcube Web est plus universel qu’il n’y paraît, et chaque fois qu’un constructeur l’adopte, il donne à son matériel quelques années de vie supplémentaires hors de son cloud propriétaire.
Votre recommandation sur json en domotique
Trois questions pour cibler la config / le produit fait pour votre usage.
