Pourquoi le KNX n'est pas toujours la réponse en domotique industrielle

Le KNX est né dans les années nonante comme un protocole ouvert européen pour l'automatisation des bâtiments. La promesse était simple : tout appareil certifié KNX devrait pouvoir dialoguer avec n'importe quel autre appareil certifié KNX, quel qu'en soit le fabricant. En théorie, cela tient debout. En pratique, trente ans plus tard, le résultat est tout autre.

Je vais vous raconter aujourd'hui trois cas réels vécus ces dernières années. Le principal est celui d'une usine de chaussures à Elche qui a passé deux ans au bord de la fermeture à cause d'une installation KNX mal conçue, jusqu'à ce que nous décidions de retirer littéralement tout le système et de repartir de zéro avec des Shelly et un Raspberry Pi. Mais d'abord, laissez-moi vous expliquer pourquoi ce genre de situation est bien plus courant qu'il n'y paraît.

Le mythe du standard ouvert

Le KNX est certifié par la KNX Association, dont le siège est à Bruxelles. Le nom sonne comme un consortium neutre. La réalité, c'est que pour travailler comme intégrateur professionnel il vous faut ETS, le logiciel officiel de programmation, qui coûte autour de 4 000 € pour la version professionnelle et qui est propriétaire à 100 %. Chaque projet KNX vit dans un fichier ETS — si vous perdez le fichier, ou si l'intégrateur d'origine ne vous le remet pas à la fin du chantier, vous ne pouvez plus rien reprogrammer sans tout refaire depuis le début.

Si « ouvert » que soit le protocole sur le câble, la porte d'entrée de l'écosystème est un logiciel propriétaire coûteux. Et cela commence déjà à contredire le mot « standard ».

Le deuxième piège est la fragmentation entre fabricants. Gira, Jung, ABB, MDT, Siemens, Schneider, Theben, Hager… tous vendent des produits « certifiés KNX ». Mais chacun implémente ses propres extensions, ses propres application programs, et dispose de son propre catalogue de références. Quand vous mélangez les fabricants dans une même installation, les incompatibilités surgissent dans les recoins du projet : une sortie relais qui n'obéit pas à une entrée binaire, un thermostat qui ignore les événements du bus lorsque la consigne change, une passerelle DALI qui répond hors délai. Techniquement, tout respecte le standard. Fonctionnellement, plus rien ne marche ensemble.

Le troisième piège, c'est le stock. Le KNX n'est pas du matériel grand public — c'est du matériel d'intégration professionnelle. Quand une référence est retirée du catalogue (et cela arrive en permanence), vous pouvez passer des semaines à chercher une pièce précise dans toute l'Europe. Et quand vous la trouvez, elle coûte le double de son prix au moment de l'installation d'origine.

Quand l'un de ces trois problèmes vous prend au dépourvu, vous n'avez pas une installation domotique — vous avez une bombe à retardement hors de prix.

Le cas d'Elche : deux ans de chaos

En 2019, une usine de chaussures d'Elche nous a contactés pour un problème qu'elle tentait de résoudre depuis deux ans avec son installateur d'origine. Elle avait investi près de 60 000 € dans un système KNX « clé en main » qui pilotait :

• L'éclairage intérieur des halls de production
• L'éclairage extérieur et celui du parking
• La commande des fours de thermofixation des semelles
• La climatisation des bureaux

Tout était intégré, tout était automatisé, tout était « conforme au standard européen ». Le problème, c'est que dès le premier jour, rien ne fonctionnait correctement. Les lumières s'allumaient toutes seules la nuit. Les fours — la pièce la plus critique de la production, car sans eux il n'y a pas de chaussures — s'éteignaient sans raison apparente et, pire encore, il n'y avait aucun moyen de les réarmer manuellement sans appeler l'intégrateur. L'usine s'arrêtait entre 4 et 8 heures à chaque fois.

Le client demandait une chose, l'installateur en faisait une autre, et quand quelque chose lâchait la réponse était toujours la même : « c'est la faute du fabricant français, la pièce a un bug, nous attendons un nouveau firmware ». Deux ans d'un nouveau firmware qui n'est jamais arrivé. (Je dis « fabricant français » pour ne pas mettre la marque au milieu — quiconque travaille dans ce secteur saura de qui je parle.)

Ils nous ont appelés parce qu'ils étaient au bord de l'effondrement. Chaque panne arrêtait la chaîne de production. Les semelles qui se trouvaient dans le four au moment de l'extinction ressortaient partiellement thermofixées et finissaient à la benne. Les opérateurs passaient la moitié de leur temps au téléphone à essayer de joindre l'intégrateur d'origine, qui ne décrochait même plus.

Quand une usine perd entre 4 et 8 heures de production chaque fois qu'un système d'éclairage a un problème, ce que vous avez n'est pas une installation domotique. C'est une bombe à retardement hors de prix.

Diagnostic technique

La première chose que j'ai demandée, c'est le fichier ETS du projet d'origine. Il leur a fallu une semaine pour me le procurer — l'intégrateur l'avait perdu « en changeant d'ordinateur ». Quand nous avons enfin pu l'ouvrir, nous avons trouvé ce que je soupçonnais déjà : une architecture KNX avec près de quatre-vingts appareils de quatre fabricants différents, des zones du bus qui ne respectaient pas la topologie recommandée, des boucles de rétroaction entre actionneurs et capteurs, et une gestion des fours implémentée comme une cascade d'objets de communication dépendant de l'état du bus en temps réel.

En clair : le système fonctionnait mal parce qu'il avait été mal conçu. Les fours avaient leur logique de sécurité — température maximale, détection de surchauffe, mise en sécurité en cas de défaut — déléguée au bus KNX. La moindre collision ou le moindre retard sur le bus se traduisait par un ordre d'extinction que le four exécutait sans savoir pourquoi. Et comme l'intégrateur avait tout programmé avec des groupes de communication entrelacés, redémarrer un four exigeait littéralement de reprogrammer depuis ETS.

Cette architecture n'aurait jamais dû quitter la table de conception. Mais quand le KNX vous permet de tout piloter depuis le bus, il existe une incitation dangereuse à placer la logique critique sur le bus. Aucun technicien industriel sérieux ne mettrait le verrouillage de sécurité d'un four sur un bus partagé avec l'éclairage du parking. Et pourtant, c'était bien le cas.

La solution : Shelly Pro + Raspberry Pi

La décision a été radicale : retirer tout le KNX. Littéralement tout. Appareils, actionneurs, capteurs, passerelles. Nous avons récupéré ce qui pouvait se revendre sur le marché de l'occasion et le reste est parti à la ferraille.

À la place, nous avons installé une architecture bien plus simple et bien plus robuste :

• Shelly Pro 4PM pour chaque groupe d'éclairage. Ce sont des actionneurs modulaires DIN montés en tableau, avec quatre canaux, mesure de consommation par canal et communication WiFi + Ethernet. Ils fonctionnent sans serveur central : si le coordinateur tombe, chaque Shelly conserve sa logique locale.
• Shelly Pro EM-50 pour mesurer la consommation triphasée de chaque zone critique, avec remontée en temps réel vers une base de données maison.
• Les fours ont retrouvé leur propre armoire dédiée, avec verrouillage de sécurité câblé et relais de réarmement physique. La seule intégration avec le système général est un signal d'état (marche/arrêt) et un ordre d'arrêt d'urgence, tous deux par contact sec. Pas de bus partagé pour la logique critique.
• Un Raspberry Pi 4 faisant tourner Home Assistant comme coordinateur de l'ensemble du système. Scripts d'automatisation en YAML, sauvegardes automatiques sur un NAS du client, et une interface web à laquelle le chef d'atelier accède depuis son téléphone.
• Un modem 4G de secours pour les moments où le réseau WiFi de l'usine posait problème, ce qui arrivait souvent à cause du bruit électromagnétique des machines.

Le coût total du projet de migration complet a été de 6 200 € de matériel plus 8 jours de travail de deux techniciens. Moins d'un dixième du coût du système KNX d'origine.

Cette installation fonctionne depuis 2019. Zéro arrêt imputable au système. Les fours ne se sont pas éteints tout seuls une seule fois. Quand un Shelly est tombé en panne (deux fois en six ans), le client en a acheté un neuf sur Amazon, l'a remplacé en vingt minutes et l'a reconfiguré en clonant la configuration via Home Assistant. Aucun technicien extérieur nécessaire.

D'autres cas que j'ai vus

Celui d'Elche n'est pas un cas isolé. Ces dernières années, j'ai vu des variantes du même problème dans différents secteurs. En voici trois autres dont je me souviens bien :

Pharmacie à Madrid — référence retirée du catalogue, réfrigérateurs en danger

80 000 € investis dans un système KNX Siemens qui pilotait l'éclairage, la climatisation et les réfrigérateurs de l'arrière-boutique où sont conservés des médicaments sensibles à la température. La troisième année, la référence précise du thermostat du réfrigérateur a été retirée du catalogue et il n'existait aucun modèle compatible en stock dans toute l'Espagne. Deux semaines avec les réfrigérateurs en mode manuel — à relever les températures toutes les heures avec un thermomètre de poche, de peur de perdre un lot d'insuline — pendant que nous cherchions une pièce de rechange sur eBay Allemagne à trois fois son prix d'origine.

La solution finale a consisté à remplacer toute la partie critique (réfrigérateurs + climatisation de la salle de préparation) par des régulateurs industriels classiques, avec un thermomètre Shelly H&T en surveillance de secours qui alerte le propriétaire par Telegram dès qu'une température sort de la plage. Le client a conservé le KNX uniquement pour l'éclairage, parce qu'il était déjà en place et qu'il fonctionnait — là, la règle s'applique : ce qui marche, on n'y touche pas.

Copropriété à Alicante — alarmes fantômes

Système KNX qui pilotait l'accès au garage, les lumières communes et les alarmes périmétriques. Chaque nuit, de façon aléatoire, l'une des alarmes se déclenchait toute seule. Les copropriétaires ont appelé l'intégrateur, qui leur a facturé un déplacement, a mis cela sur le compte « d'un coup de foudre », et est reparti. Deux semaines plus tard, une autre alarme fantôme. Puis une autre. Puis encore une autre.

L'intégrateur d'origine parlait de « bruit électromagnétique sur le bus » et proposait une passerelle de filtrage à 1 200 €, plus le déplacement pour l'installer. Quand on nous a appelés pour un second avis, le vrai diagnostic a pris vingt minutes : la passerelle IP du système avait un bug connu que le fabricant avait corrigé dans un nouveau firmware — mais ce firmware exigeait de mettre ETS à jour dans une version que l'intégrateur n'avait pas et refusait d'acheter. Solution : nous avons remplacé la passerelle par un Shelly Plus i4 qui envoie ses événements à Home Assistant, et les faux positifs ont disparu le jour même. Coût total : 45 € de matériel + 2 heures de travail.

Bureaux d'un cabinet de conseil technologique — intégration impossible

Entreprise moderne avec un système KNX qu'elle voulait intégrer à Google Calendar, pour que les salles de réunion coupent automatiquement l'éclairage et la climatisation après plus de quinze minutes d'inoccupation et en l'absence de réservation à venir. Sur le papier, une intégration triviale. Dans le monde KNX réel, impossible sans passerelles coûteuses, sans programmation ETS et sans facturer à part chaque changement de logique.

Nous avons migré les salles de réunion vers Shelly + Home Assistant + HACS, et l'équipe informatique interne de l'entreprise a pu programmer l'intégration avec son Google Workspace en un après-midi, sans appeler le moindre consultant extérieur. L'intégrateur KNX d'origine leur réclamait de l'argent depuis six mois pour une étude de faisabilité — qu'il n'a jamais livrée.

Quand le KNX a bel et bien du sens

Je ne veux pas que cet article sonne comme une attaque en règle. Le KNX conserve des scénarios où il reste le bon choix :

1. Grandes villas de luxe avec un intégrateur unique de confiance qui va maintenir le système pendant des années et où le budget n'est pas le sujet. Ici, la complexité du bus, le logiciel coûteux et les pièces spécifiques se justifient, parce que le client veut un système élégant, avec des écrans tactiles Gira ou Jung dans chaque pièce, et qu'il accepte de payer.
2. Les projets où le KNX est déjà installé et fonctionne bien. Si vous héritez d'une installation qui marche, n'y touchez pas. Le coût de la migration dépasse presque toujours le bénéfice. Ajoutez des couches par-dessus s'il vous faut plus de fonctionnalités, mais ne refaites pas ce qui fonctionne.
3. Les intégrations spécifiques avec certains fabricants européens de climatisation qui ne proposent que des interfaces KNX natives et pour lesquels les passerelles vers d'autres protocoles sont chères ou instables.
4. Les bâtiments certifiés où la documentation formelle d'un système KNX facilite les audits d'efficacité énergétique ou les certifications LEED/BREEAM.

Dans tous les autres cas — et particulièrement dans les environnements industriels où l'arrêt de production coûte cher et où la simplicité de remplacement est critique — il existe de meilleures alternatives.

Quoi utiliser à la place du KNX

Ma recommandation technique par type de projet, sans esbroufe et sans engagement envers le moindre fabricant :

• Logement résidentiel classique (< 200 m²) : Shelly standard + Home Assistant. Coût par point : 25 à 40 €. Configuration par navigateur. Composants disponibles sur Amazon avec livraison en 24 h.
• Logement de luxe ou grande villa : Shelly Pro en tableau DIN + Home Assistant sur un Intel NUC avec SSD. Même philosophie que le résidentiel, mais avec des actionneurs DIN professionnels et une sauvegarde physique du serveur. Coût par point : 40 à 80 €.
• Bureaux et espaces commerciaux : Shelly Pro + ESPHome (pour les capteurs sur mesure) + Home Assistant + intégration aux API de l'entreprise. Ici, la valeur ajoutée réside dans la capacité à s'intégrer à Slack, Google Calendar, Microsoft Teams, etc.
• Industrie : automates PLC classiques (Siemens S7, Schneider M2xx) pour la logique de sécurité critique. Shelly Pro + Home Assistant pour la couche de supervision et l'éclairage général. Ne jamais mélanger les deux sur le même bus. La règle est simple : la sécurité passe par le câble physique, la supervision passe par IP.
• Agricole / serres / hors réseau : même schéma que pour l'industrie, mais avec une attention particulière à la consommation électrique, car ces systèmes fonctionnent souvent sur du solaire isolé. J'y ai utilisé avec succès Raspberry Pi + Node-RED + Shelly Plus pour piloter l'irrigation, la ventilation, la température et le niveau d'eau. C'est ce que j'ai fait sur le projet de la sierra de Murcia dont je parle sur ma page de projets.

Conclusion

Le KNX n'est pas mort. Il a des cas d'usage légitimes. Mais il a cessé d'être la réponse par défaut il y a au moins une décennie, et les fabricants européens traditionnels ne s'en sont toujours pas aperçus.

Quand un client me demande un système domotique industriel, ma première question n'est pas « KNX ou pas KNX ? » mais « quel est votre plan pour les dix prochaines années ? ». Si la réponse comprend un intégrateur externe unique, un budget pour des pièces de rechange coûteuses et du temps pour attendre un firmware, le KNX peut avoir du sens. Dans tous les autres cas, vous serez probablement mieux servi par une combinaison de Shelly, Home Assistant, ESPHome et d'un peu de bon sens industriel.

Le client d'Elche n'a plus eu le moindre problème depuis six ans. Il n'a eu à appeler personne. Son usine ne s'est pas arrêtée. Et quand une pièce lâche, il en achète une neuve sur Amazon pour moins de 100 € et la remplace lui-même en vingt minutes. C'est ce type de domotique que je veux construire.