Samsung fait payer 5 dollars par mois l’API SmartThings et pousse les utilisateurs de Home Assistant vers le contrôle local
Annoncé en juin 2026, le passage à 4,99 dollars par mois de l’API SmartThings pour les développeurs individuels entre en vigueur cet automne, mettant fin à des années d’accès gratuit pour les intégrations tierces comme Home Assistant, tandis que le projet LocalThings émerge pour restaurer un contrôle local. Pour quiconque pilote des appareils Samsung depuis Home Assistant, la bonne réponse n’est pas de payer l’abonnement, mais de migrer les automatisations vers des chemins locaux que plus aucun tarif ne pourra fermer.
Juin 2026. Samsung annonce qu’il fera payer 4,99 dollars par mois l’accès à l’API SmartThings pour les développeurs individuels non commerciaux. Automne 2026. Le tarif entre en vigueur, mettant fin à des années d’accès gratuit à l’un des plus grands écosystèmes domotiques du monde. 460 millions. Le nombre d’utilisateurs enregistrés que Samsung revendique pour SmartThings. Pourquoi c’est important : le paywall ne touche pas l’application grand public, mais il taxe précisément les intégrations tierces qui rendaient la plateforme ouverte — et il accélère la fuite vers le contrôle local.
Ce qui change : l’application reste gratuite, l’API devient payante
La distinction est essentielle, parce que la plupart des utilisateurs ne verront jamais la facture. Si vous pilotez des lampes, des prises ou des appareils via l’application SmartThings de Samsung, rien ne change : l’accès reste gratuit et la compatibilité automatique avec des milliers d’appareils est intacte.
Le tarif frappe les utilisateurs qui atteignent SmartThings depuis un autre logiciel. Un Home Assistant qui agrège des appareils Samsung dans un tableau de bord unique parle à l’API SmartThings — et cet accès, gratuit jusqu’ici, passe derrière un paiement mensuel. Il en va de même pour les automatisations personnalisées et toute intégration tierce construite sur l’API.
C’est un changement de nature pour un profil d’utilisateur précis : le passionné qui a bâti un système d’automatisation personnalisé autour de la plateforme. Une intégration qui fonctionnait déjà, sans coût, porte désormais une charge récurrente — non parce qu’elle a cassé, mais parce que la couche de compte en dessous appartient à Samsung, qui a le droit de la tarifer.
La justification publique de Samsung est l’investissement : les revenus financeront des fonctionnalités « entreprise » et un nouveau Developer Center. Mais, comme le note une analyse récente, les 5 dollars ne réparent rien qui soit cassé — ils achètent la continuation d’un accès qui marchait déjà, tandis que les fonctionnalités promises sont un engagement à venir.
La réponse de la communauté : LocalThings et le contrôle local
La réaction de la communauté open source a été tranchée. Paulus Schoutsen, fondateur de Home Assistant, a publiquement critiqué la décision : « Nous sommes pour le choix, mais nous sommes très déçus que les utilisateurs doivent décider de payer ou non, à l’ombre d’un énième paywall cloud. »
La frustration se comprend. Home Assistant s’est construit précisément sur le contrôle local et respectueux de la vie privée, en réduisant la dépendance aux plateformes cloud des fabricants. Une facture mensuelle pour l’API de Samsung ajoute une couche de coût et de fragmentation à un écosystème que l’open source a travaillé à garder accessible et indépendant des constructeurs.
La réponse concrète ne s’est pas fait attendre : LocalThings, un projet né pour court-circuiter le paywall et restaurer un accès local aux appareils Samsung. C’est le réflexe classique de l’auto-hébergement face à un tarif de plateforme : quand le cloud ferme sa porte, la communauté en construit une autre, côté local. Le projet s’inscrit dans une longue lignée — celle qui transforme chaque paywall d’API en argument pour posséder son propre chemin d’accès.
L’ironie Matter : l’interopérabilité des appareils ne garantit pas l’ouverture des plateformes
Il y a une ironie de fond dans cette décision. Matter, le standard promu par les grands du secteur, promet que vos appareils continuent de fonctionner quel que soit l’écosystème choisi. Samsung l’embrasse d’ailleurs — l’application SmartThings a été refondue avec le support de Matter 1.6.
Mais Matter standardise la couche appareil, pas les API cloud que les plateformes exposent aux utilisateurs avancés. Samsung peut donc adopter Matter pour la compatibilité matérielle tout en tarifant les accès API dont les passionnés dépendent réellement. L’interopérabilité au niveau des appareils ne garantit pas l’ouverture au niveau de la plateforme. C’est la leçon structurelle du paywall : les standards ouverts couvrent le matériel, pas les comptes cloud qui le pilotent.
La question qui se pose maintenant est celle du précédent. Cinq dollars par mois, c’est peu. Mais l’industrie domotique avance vers des écosystèmes de développeurs monétisés : paliers d’API payants, fonctionnalités verrouillées par abonnement, services cloud autrefois gratuits. Chaque tarif pris isolément se justifie facilement ; ensemble, ils changent l’économie du smart home ouvert et mix-and-match que Matter était censé protéger.
Ce qui se joue pour un auto-hébergeur
Le point pratique, pour qui maintient un Home Assistant ou une intégration personnalisée, est de savoir où vivent réellement ses automatisations. Si tout passe par l’application SmartThings, rien ne change — et rien ne coûte. Si le foyer dépend de Home Assistant qui dialogue avec le cloud Samsung, il faut regarder comment les projets d’intégration réagissent au tarif, et quels appareils peuvent basculer sur un contrôle local via Matter, Thread ou un projet comme LocalThings.
Le vrai coût n’est pas les 5 dollars : c’est la dépendance renouvelée. Chaque automatisation empilée sur une API payante devient plus chère à maintenir, et risque de casser si le mainteneur de l’intégration décide que l’abonnement n’en vaut pas la peine. La seule garantie durable est un chemin que aucun tarif ne peut fermer : le contrôle local, sur votre propre réseau.
Migrer vers le local : par où commencer
Pour un auto-hébergeur, la sortie du paywall suit un chemin en quatre étapes, dans l’ordre du rapport coût-bénéfice. D’abord, l’inventaire : listez les appareils Samsung que vos automatisations pilotent réellement, et la méthode par laquelle ils passent — cloud SmartThings ou chemin local. Ensuite, le standard : vérifiez, pour chaque appareil, s’il expose une interface Matter, Thread ou un accès local documenté ; c’est le critère qui décide de la suite. Puis, le pilote : testez LocalThings ou l’intégration locale de Home Assistant sur un appareil non critique avant de basculer l’ensemble. Enfin, la bascule : migrez les automatisations une par une, en gardant l’accès cloud payant uniquement pour les appareils sans alternative, le temps de les remplacer.
Le principe directeur est le même que pour toute migration d’infrastructure : ne pas tout casser d’un coup. Chaque automatisation basculée sur le local est une dépendance de moins sur un tarif que vous ne contrôlez pas. Et un appareil qui ne peut pas être piloté localement est un appareil qu’il faudra, à terme, remplacer — pas un abonnement à subir indéfiniment.
Verdict
Le paywall de l’API SmartThings est un signal, pas une catastrophe : 5 dollars par mois ne ruineront personne. Mais il révèle où se situe réellement la ligne de partage — entre les appareils qui restent ouverts par standard, et les comptes cloud qui se monétisent par abonnement.
Si vos automatisations passent par l’application SmartThings, ne faites rien : le changement ne vous concerne pas. Si vous pilotez des appareils Samsung depuis Home Assistant, ne payez pas l’abonnement comme réflexe : migrez vers un contrôle local — Matter, Thread ou LocalThings — sur les appareils qui le permettent, et ne conservez l’accès cloud payant que pour ceux qui n’ont pas d’alternative. Si vous choisissez de nouveaux appareils domotiques, faites du contrôle local un critère d’achat, pas un luxe : c’est la seule caractéristique qu’un futur tarif de plateforme ne pourra jamais reprendre. La règle à retenir : un appareil piloté par votre réseau vous appartient ; un appareil piloté par une API appartient à qui fixe le prix de l’API.