L’Open Home Foundation, qui porte notamment Home Assistant, publie une position très claire : un appareil connecté ne devrait pas devenir inutile parce qu’un fabricant coupe son cloud, ferme son API ou retire une fonction après l’achat. Le texte réclame du contrôle local, des interfaces documentées et un véritable droit à l’interopérabilité. C’est une proposition politique, pas encore une nouvelle règle.
Le vrai problème : on achète du matériel, mais on loue parfois son fonctionnement
Une ampoule, une caméra ou un thermostat peut être physiquement installé chez vous tout en restant dépendant d’un serveur distant. Tant que le fabricant maintient son service, tout va bien. Mais si l’entreprise ferme, change de stratégie, impose un abonnement ou désactive une fonction, l’objet posé dans votre salon peut perdre une partie de son intérêt du jour au lendemain.
L’Open Home Foundation part de ce constat simple : la maison connectée touche à des usages durables et parfois sensibles. On ne remplace pas une serrure, un chauffage ou un système d’alarme comme on change une application. Le matériel devrait donc rester utile pendant une durée raisonnable, même lorsque la relation commerciale avec son fabricant se dégrade.
Ce n’est pas seulement une question de confort. Une dépendance intégrale au cloud ajoute aussi des risques de panne, de confidentialité et de sécurité. Lorsque toutes les commandes passent par Internet, une coupure extérieure peut suffire à rendre un équipement indisponible chez soi. L’appareil est dans la maison, mais le bouton principal est ailleurs.
Fonctionnement local et API documentée : le minimum demandé
Le texte défend une approche « local-first » : lorsque c’est techniquement possible, les fonctions essentielles doivent continuer à fonctionner sur le réseau domestique, sans connexion obligatoire à Internet. Le cloud peut apporter des services supplémentaires, mais il ne devrait pas être l’unique interrupteur de l’objet.
La fondation demande aussi des standards ouverts, des interfaces matérielles et logicielles documentées, ainsi que moins de comptes et d’applications obligatoires. En pratique, cela permettrait à un thermostat, un capteur ou une caméra d’être piloté par plusieurs plateformes, y compris après l’arrêt de l’application d’origine.
Matter va déjà dans cette direction, mais ne règle pas tout, comme nous l’expliquions dans notre article sur l’adoption de Matter et Thread. Un logo d’interopérabilité peut simplifier l’ajout d’un produit sans garantir que toutes ses fonctions avancées seront accessibles localement. Le problème n’est donc pas uniquement le protocole : il concerne aussi ce que le fabricant choisit d’exposer, de conserver ou de verrouiller.
Modifier un produit sans demander la permission
Le passage le plus ambitieux concerne ce que la fondation appelle l’« interopérabilité adverse ». Derrière ce terme un peu martial se cache une idée assez concrète : un tiers devrait pouvoir rendre un produit compatible avec un autre service, même si le fabricant n’a pas donné son autorisation préalable.
C’est exactement ce qui permet à des communautés comme Home Assistant de prolonger la vie d’appareils abandonnés ou enfermés dans leur application. Aujourd’hui, ce travail dépend souvent d’API tolérées, d’une rétro-ingénierie fragile ou de clés d’accès que la marque peut révoquer.
La demande mérite néanmoins une limite claire : ouvrir ne signifie pas ignorer la sécurité. Une serrure ou une caméra ne doit pas devenir un terrain de jeu sans garde-fous. Le bon équilibre consiste à protéger l’utilisateur contre les intrusions tout en évitant que la sécurité serve de prétexte universel pour interdire toute compatibilité indépendante.
Interdire les fonctions qui disparaissent après l’achat
Autre proposition forte : un fabricant ne devrait pas pouvoir supprimer définitivement une fonction de base une fois le produit vendu, sauf risque de sécurité crédible ou impossibilité technique réelle. Autrement dit, une mise à jour ne devrait pas transformer silencieusement un achat en produit dégradé.
La fondation vise aussi les programmes « Works with ». Ces labels peuvent aider le consommateur, mais ils ne devraient pas devenir un péage : payer pour avoir le droit d’accéder à un écosystème ou réserver certaines compatibilités aux partenaires commerciaux revient à créer un jardin clos avec une porte tarifée.
Le raisonnement est cohérent, mais l’Open Home Foundation n’est pas neutre dans cette histoire. Elle développe Home Assistant et son propre programme de certification. Son intérêt est naturellement de favoriser les produits ouverts. Elle l’assume toutefois et affirme que les mêmes exigences doivent s’appliquer à ses propres labels. Cela ne transforme pas sa position en loi, mais cela la rend au moins vérifiable.
Une déclaration utile, mais qui ne change encore aucune règle
Le document est un manifeste destiné aux fabricants, aux plateformes et aux pouvoirs publics. Il ne donne aujourd’hui aucun nouveau droit automatique au propriétaire d’un objet connecté. Si une marque ferme son cloud demain, ce texte ne suffira pas à récupérer les fonctions perdues.
Son intérêt est ailleurs : il formule précisément ce que devrait signifier « posséder » un appareil connecté. Posséder le plastique et l’électronique ne sert pas à grand-chose si les fonctions essentielles restent à la discrétion d’un serveur, d’une licence ou d’un partenariat commercial.
Pour l’acheteur, le réflexe reste donc très concret : avant de payer, vérifier l’existence d’un contrôle local, d’une compatibilité documentée, d’un mode hors ligne et d’un engagement de support. Les promesses vagues d’écosystème comptent moins que la capacité réelle du produit à fonctionner sans permission permanente.
Ce qu’il faut retenir
- L’Open Home Foundation veut imposer le contrôle local, les API documentées et l’interopérabilité réelle.
- Elle demande qu’une fonction essentielle ne puisse plus être supprimée arbitrairement après l’achat.
- Ce texte pose un cap politique utile, mais ne crée encore aucun droit nouveau pour le consommateur.
