Les technologies IoT et les espaces intelligents devraient amorcer une nouvelle révolution technologique, mais si des milliards d’appareils IoT existent, le manque d’unification entre ces appareils continue de freiner le secteur. Quels sont les défis auxquels les dispositifs IoT sont confrontés, quelles solutions peuvent les aider et que peuvent faire les ingénieurs ?
L’ennemi juré de l’IoT : la fragmentation
Il est vraiment étonnant de voir le nombre d’appareils IoT qui existent actuellement dans le monde, les estimations actuelles plaçant le nombre total au-dessus de 14 milliards, et ce chiffre devrait atteindre 20 milliards d’ici 2024. Non seulement il est difficile d’appréhender le nombre d’appareils dans le monde, mais la quantité de données produites est également gigantesque. Grâce aux développements réalisés dans les technologies IoT et à la quantité de données générées, des industries telles que l’IA et l’apprentissage automatique ont pu s’accélérer et se développer massivement, si bien que l’IA est désormais monnaie courante dans la vie quotidienne.
Et pourtant, malgré les nombreux appareils IoT sur le marché et les nombreuses options pour la maison connectée, la plupart des appareils IoT utilisés dans les maisons sont loin d’être intelligents. En effet, la plupart des appareils IoT utilisés dans les maisons ne sont classés dans la catégorie IoT que parce qu’ils peuvent établir une connexion Internet, et ils ne font certainement rien d’intelligent, étant dans l’incapacité de partager leurs données avec d’autres systèmes, ni de répondre intelligemment aux événements en temps réel. En outre, la grande majorité des maisons n’intègrent aucune technologie intelligente par défaut, ce qui rend la plupart des maisons muettes.
Si de nombreux facteurs ont rendu difficile l’intégration de l’IoT à la maison, le principal coupable est de loin la fragmentation.
Qu’est-ce que la fragmentation de l’IoT ?
Il existe une blague dans le secteur de l’IoT qui décrit parfaitement les problèmes rencontrés par la fragmentation. En termes simples, un ingénieur constate qu’il existe 14 normes IoT et décide de créer une norme que tout le monde pourra utiliser : il y a maintenant 15 normes.
Malheureusement, cette blague correspond tout à fait à la réalité, et les centaines (si ce n’est les milliers) d’entreprises et d’ingénieurs de l’IoT qui conçoivent et fabriquent des dispositifs IoT font exactement cela. Non seulement un grand nombre de ces entreprises créent leurs propres normes (en pensant qu’elles sont les meilleures), mais elles créent souvent des écosystèmes entiers de solutions qui fonctionnent dans leur cadre personnalisé. Si cela peut être une bonne chose pour ceux qui n’utilisent qu’un seul fabricant pour leurs solutions IoT, cela introduit de nombreux défis qui freinent l’intégration des espaces intelligents.
Le premier défi que cela représente est la difficulté de créer des solutions IoT complexes qui combinent des appareils de différents fabricants. Par exemple, une maison connectée nécessitera de nombreux dispositifs intelligents allant d’une sonnette intelligente, de prises de courant intelligentes et de lumières intelligentes à des commandes de thermostat intelligentes. Malgré l’existence de tous ces appareils sur le marché, il est pratiquement impossible de trouver un seul fabricant de tous ces appareils ou des fabricants différents qui prennent en charge un protocole commun.
Le deuxième défi que la fragmentation de l’IoT introduit est le manque de support logiciel pour les maisons connectée. De même que chaque fabricant crée sa propre norme, il crée souvent ses propres plateformes logicielles utilisées pour contrôler les appareils et lire les données, mais celles-ci exposent rarement une API que les autres fabricants peuvent utiliser. Ainsi, même le côté logiciel des dispositifs IoT peut être fragmenté et isolé des autres développeurs.
Enfin, les clients qui sont contraints d’utiliser un seul fabricant pour leurs solutions IoT peuvent être prisonniers de la marque, ou pire, être redevables de toutes les décisions prises par cette marque. Par exemple, Hive a récemment annoncé qu’elle mettait fin à sa gamme de produits HomeShield, qui comprend des caméras de sécurité et des détecteurs de fuites. Une fois que les mises à jour et les services seront interrompus pour ces appareils, les clients n’auront d’autre choix que de retirer et de mettre au rebut des appareils IoT en parfait état de marche.
Qu’est-ce que Matter ?
Conscient des nombreux défis auxquels sont confrontés les dispositifs IoT, un groupe de grandes entreprises technologiques s’est réuni pour aborder le problème, et a désormais développé un nouveau protocole IoT : Matter. Même si l’arrivée de Matter s’inscrit elle aussi dans la plaisanterie précédente sur la création de normes, le fait que de nombreuses grandes entreprises technologiques soutiennent la plateforme (Google, Meta, etc.) oblige essentiellement les fabricants à adhérer à la norme en raison de la taille même des entreprises technologiques concernées.
Par essence, Matter est une norme propriétaire pour la domotique qui fournit des licences libres de droits aux fabricants, le seul coût étant celui de la certification. Malgré le coût de la certification, Matter est entièrement ouvert au public, ce qui permet aux utilisateurs de voir comment le code fonctionne et de faire des suggestions de modifications et de corrections de bugs. Bien qu’il ne soit pas clair quelle est la sanction pour l’utilisation de Matter sans l’obtention d’une certification, il est probable que les produits ne peuvent tout simplement pas porter le nom et le logo Matter (c’est-à-dire qu’un produit pourrait être compatible avec Matter, mais ne pourrait pas l’annoncer comme tel).
Les projets Matter débutant en 2019, de nombreux fabricants et entreprises ont depuis annoncé leur soutien public, parmi lesquels IKEA, Amazon, Google, Apple et Zigbee Alliance. Cependant, comme le protocole n’a été officiellement publié qu’en octobre 2022, il doit encore se généraliser ou être adopté par la communauté au sens large. En outre, la version actuelle de Matter prend en charge les appareils ménagers courants, notamment les produits d’éclairage, les interrupteurs secteur, les thermostats, les serrures de porte, les systèmes de chauffage, la ventilation, les capteurs de sécurité, les téléviseurs et les stores. La prochaine version, prévue pour mars 2024, élargira la liste des périphériques pris en charge pour inclure les aspirateurs robots, les capteurs de CO2, les détecteurs de fumée, la gestion de l’énergie, le Wi-Fi, les caméras et d’autres gros appareils.
Existe-t-il des alternatives à Matter ?
Pour l’instant, aucune norme IoT ne bénéficie du même degré de soutien que Matter, mais cela ne veut pas dire qu’il n’y a pas d’autres normes qui peuvent aider les ingénieurs à créer des appareils bien connectés.
Les méthodes les plus populaires pour la communication IoT sont de loin REST et HTTP, et ce parce que la plupart des serveurs web les prennent naturellement en charge. Cela signifie que les dispositifs IoT peuvent envoyer des paquets de données à un serveur web standard codé en PHP ou Node.js. L’avantage supplémentaire de ces protocoles est qu’ils rendent l’affichage des données très trivial, car les bases de données utilisées pour alimenter les sites web peuvent également être utilisées pour stocker les données IoT. Ainsi, une solution IoT complète peut, en théorie, être intégrée à un seul serveur web.
Une alternative à HTTP et REST est l’utilisation de sockets web. PHP, HTML et JavaScript prennent tous en charge les sockets Web, ce qui en fait un excellent choix pour les dispositifs IoT ; mais alors que HTTP et REST sont des messages à paquet unique, qui ferment leur connexion à la fin, les sockets Web peuvent rester ouverts, ce qui les rend parfaits pour le streaming de grandes quantités de données.
Enfin, MQTT est un autre protocole populaire utilisé par des millions d’appareils dans le monde. Développé à l’origine pour l’industrie pétrolière et gazière, MQTT permet à des réseaux entiers de dispositifs de publier et de s’abonner à des variables spécifiques. La légèreté de MQTT le rend idéal pour les microcontrôleurs à faible consommation d’énergie et à bas prix. En outre, il est facile de réaliser des implémentations personnalisées de MQTT en raison de la simplicité du protocole, et il existe de nombreux exemples en ligne qui peuvent être adoptés.
Que doivent faire les ingénieurs ?
Dans les protocoles HTTP et MQTT, les concepteurs peuvent exposer leur API afin d’offrir au moins la possibilité à d’autres fabricants de s’interfacer avec les appareils. En outre, il est possible de formuler un logiciel de pontage, c’est-à-dire un logiciel capable de relier deux normes différentes, ce qui permet uniquement aux produits de fonctionner avec d’autres fabricants.
Mais à part cela, il est difficile de dire ce que les ingénieurs doivent faire exactement, car Matter lui-même est très nouveau, sa documentation est très approfondie et complexe, et ce n’est peut-être pas la meilleure solution pour tous les produits IoT. Bien entendu, il a été clairement démontré que la création de nouvelles normes n’est d’aucune utilité. Les ingénieurs devraient donc éviter de créer de nouvelles normes dans la mesure du possible.
Une solution possible serait que les ingénieurs se concentrent sur des conceptions à code source ouvert qui peuvent être facilement modifiées sur le terrain. Par exemple, la création de dispositifs IoT à partir de systèmes Linux qui prennent en charge les mises à jour par voie hertzienne peut, en théorie, être mise à jour à l’avenir pour prendre en charge Matter lorsque ce protocole sera mieux établi.
Une autre solution consiste pour les ingénieurs à s’en tenir aux solutions courantes telles que HTTP et REST, et à espérer qu’en mettant leurs API à la disposition du public, Matter sera en mesure de prendre en charge leurs produits dans une certaine mesure. En effet, il peut être possible de créer une interface web qui se situe entre le dispositif IoT et un serveur Matter et qui peut traduire les messages entre les deux.
Mais ce n’est pas parce que Matter existe qu’il faut l’utiliser. À moins qu’elle ne soit essentielle à une conception, l’intégration de Matter pour le simple plaisir de la prendre en charge peut faire plus de mal que de bien, surtout si des bogues inconnus affectent Matter.
