Ce billet a pour objectif de donner une vision de l’évolution de l’architecture de l’Internet des objets (IoT) sur un horizon de 5 ans. Nous abordons également les impacts en termes d’émergence de nouveaux acteurs-business opérant et exploitant les systèmes d’IoT.
L’Internet des objets est principalement réalisé par des constructeurs de matériel/logiciel intégrant leurs produits de manière fermée. La figure suivante montre les objets d’un même constructeur, interopérables entre eux, enfermés dans une bulle de communication délimitée par une passerelle. Cette passerelle est souvent reliée à un service SaaS propriétaire dans le cloud qui traite et expose tout ou partie des données. Ce service cloud étant réalisé grâce à des systèmes appelés “plate-forme IoT”. 
Cette architecture a l’énorme avantage de fixer la responsabilité sans équivoque du constructeur sur le bon fonctionnement du système qu’il livre (objet/passerelle/plate-forme IoT Cloud). La contrepartie est que le client est enfermé dans la solution du constructeur. A titre d'exemple, dans le domaine des équipements électriques professionnels, les grands constructeurs (Schneider, Siemens…) appliquent cette stratégie de systèmes fermés depuis toujours. Dans le monde de l’électronique grand public, il en va de même avec des offres comme Nest de Google, Hue de Philips… En fonction de leur influence, les constructeurs invitent les autres offres à s’interconnecter à la leur et les considèrent comme des périphériques. Google Nest, se présente ainsi comme un intégrateur des solutions tierces et revendique de pouvoir contrôler des lampes Philips Hue. La figure suivante montre des modes d’encapsulation différents, l’un en passant par leurs offres cloud, l’autre par intégration des objets d’un tiers dans son système.
L’écosystème s’ouvre ainsi mais reste dans le paradigme du XXe siècle où les intégrateurs applicatifs ont contrôlé globalement le marché et finalement l’on tué, par la simple limitation de l’offre. Ce manque d’interopérabilité contraint donc les solutions nouvelles à s’adapter aux exigences des constructeurs en situation de force. Par exemple, un constructeur d'objet peut s'aligner sur NEST et donc vivre dans le sillage de Google ou il peut pousser son offre concurrente. Dans ce dernier cas, le marché est inondé par une répétition d'offres équivalentes, réduisant leur propre rentabilité et finissant par disparaître.
La vision ultime de l’Internet des objets est que tous les objets sont connectés à l’Internet et peuvent tous communiquer en pair-à-pair, quelle que soit leur localisation et à tout moment. Ceci est rendu effectivement possible par la baisse des coûts de l’électronique et du firmware. Les systèmes d'IoT seront fortement distribués et dynamiques (ajout/retrait à chaud d'objets et d'applications). Pour tout architecte de SI, il est clair que si l'architecture d'un système d'IoT n'est pas guidée un minimum par un cadre de référence, le système composé ne fonctionnera pas. Des initiatives sont donc nées pour spécifier des architectures de référence des systèmes IoT. Il s'agit des "frameworks IoT" dont les plus connus sont OpenInterconnect, AllSeen Alliance et oneM2M. Ces frameworks vont prendre une place de plus en plus importante, encore peu perçue actuellement. Ces frameworks sont implémentés sous forme de middlewares à utiliser dans les différents composants du système d'IoT : objets, passerelles, serveurs... Les logiciels parmi les plus avancés étant oM2M (pour oneM2M) et AllJoyn ® (pour AllSeen Alliance).
Il se pose donc la question de comment les objets vont pouvoir se comprendre d’un point de vue fonctionnel pour collaborer. Près de 150 ans après la généralisation de la distribution de l’électricité, l’Europe n’a toujours pas réussi à se mettre d’accord sur un modèle unique de prise électrique ! Il serait illusoire de croire que l’on pourra normaliser le monde des objets pour qu’ils disposent des mêmes représentations (sémantiques et techniques) et pouvoir se “comprendre” en échangeant des messages. Des efforts de normalisation sont en cours, avec des spécifications d'interopérabilités définies au sein des "Frameworks IoT", mais également au niveau d'organismes de normalisation "métier" (automobile...). Bien sûr, plusieurs frameworks incompatibles entre-eux sont en cours de définition...
Le modèle retenu pour résoudre le problème est l’émergence de services et d’opérateurs spécialisés dans la conversion des données issues/reçues par les objets. Ces services peuvent prendre des formes variées, comme celui de la figure ci-dessus montrant un système de conversion de message entre deux objets. Un nouveau business apparaît ici, celui des “fournisseurs de services d’interopérabilité”.
En disposant de services assurant l’interopérabilité entre objets, on construit des applications qui communiquent avec les objets et composent ainsi un système fonctionnel. Par exemple, en ayant acheté une éolienne chez le constructeur A et une batterie chez le constructeur B, il est possible d’acheter une application d’optimisation énergétique qui va s’appuyer sur les services d’interopérabilité pour parler avec l’éolienne et la batterie et ainsi exécuter ses fonctions d’optimisation. L’application est composée d’objets, de services d’interopérabilité et d’applications. Il va exister des “Applications store IoT” où il sera possible de venir prendre des applications pour les déployer dans un environnement d’exécution.
Ces stores d’application sont à rapprocher dans le principe de ce qui existe déjà dans la téléphonie mobile. Ces stores portent de nombreuses méta-données descriptives des applications permettant leur déploiement, leur activation et leur maintien en conditions opérationnelles (en conformité avec les spécifications du framework IoT retenu).
Ce sont des systèmes PaaS sur lesquels on peut déployer des applications IoT. Si cette notion ne vous est pas familière, nous vous invitons à lire l'article Cap sur les plates-formes IoT. Les plates-formes sont en général présentes dans le cloud. Elles sont conçues en s’appuyant sur les frameworks IoT rendant la création, le déploiement et l’opération des applications les plus simples possible. Un fournisseur d'application IoT devra donc a un moment choisir, le où les frameworks dans lequel il concevra son application et l'offrira au déploiement. Il devra tester que son application fonctionne bien sur le ou les frameworks où elle est censée tourner.
En termes d'usage, un client souhaitant faire fonctionner par exemple une application d’optimisation énergétique, devra acheter l’application sur le “store” et la déployer sur une plate-forme IoT compatible de son choix.
Le fournisseur de plateforme IoT peut architecturer son offre PaaS de deux manières :
On comprend ainsi l'enjeu majeur de la compétition des frameworks IoT car ils conditionnent les offres de plates-formes, mais également tout le fonctionnement du système et les services associés. Comme il est quasi certain que différents framework IoT cohabiteront, les services d'interopérabilité inter-framework seront nécessaires.
Les objets participent à des transactions (achat, vente, réservation…) et il est nécessaire de disposer de systèmes de sécurité et de confiance. Il s’agit par exemple de la distribution de clefs cryptographiques, mais aussi de services de plus haut niveau tels que l'identification, l'authentification, l'autorisation, la non répudiation et l'horodatage. Les tiers de confiance comme les banques, les "fournisseurs d'identité" (IDP) ou les blockchains sont donc requis dans les processus et applications d'IoT. Les prestataires de services de confiance vont donc se développer sur toutes les fonctions en relation avec les objets. Les applications IoT et les objets utiliseront donc en direct ces services de confiance.
La figure suivante illustre le fonctionnement global de l’IoT à l’horizon 2020 en réunissant les éléments que nous venons de présenter :
Tout d'abord, le client définit (compose) le système dont il a besoin : objets, applications, tiers de confiance.
Puis, il déploie l’application sur la plate-forme IoT. Celle-ci, en fonction des objets choisis à faire co-fonctionner, appelle les services d’interopérabilité nécessaires aux échanges.
Lorsque l’application a besoin de services de confiance, elle appelle les tiers de confiance exposant les services adaptés.
Les objets peuvent également parler entre eux grâce aux services d'interopérabilité et les services de confiance.
Le framework IoT définit l'architecture générique d'un tel fonctionnement.
Par rapport au "modèle commercial et technique fermé" actuellement pratiqué, la vision montre l'existence de nouveaux acteurs :
- Les organismes spécificateurs de Frameworks IoT. Ils établissent les architectures de référence des systèmes d'IoT. Chaque framework IoT peut embarquer des exigences d'interopérabilité (modèles de données et sémantiques).
- Les opérateurs d’interopérabilité vont apparaître pour offrir des services de conversion sémantique et technique de données entre objets (appartenant plutôt à des frameworks IoT différents). De nombreux travaux sont menés actuellement sur ce sujet :
- Les applications store existent déjà pour l’IoT, mais sont encore “propriétaires” à des plate-formes IoT. Une nouvelle génération va apparaître portant des meta-data décrivant les attributs de déploiement. Les technologies du PaaS sont parfaitement adaptées à ce mécanisme de déploiement à la demande.
- Les plates-formes IoT constituent actuellement un point d’attention particulier car elles ont bien été identifiées et comprises par les architectes IoT. Mais leur rôle est encore souvent limité à un “hub télécom” multi-protocoles. Elles vont s’étoffer pour offrir des services de framework IoT et ainsi accueillir les applications venant des “applications stores”.
- Les services de confiance seront de plus en plus présents car les objets et applications participent à des transactions commerciales et financières. La blockchain, et en particulier Ethereum, sont des candidats idéaux pour automatiser les transactions inter objets / systèmes.
La structuration du marché suivant ce modèle n’en est qu’à ses débuts. Nous sommes convaincus que ce modèle permettra une forte accélération de l’offre IoT “ouverte”, mais le cheminement jusqu'à une telle vision prendra environ 5 ans. Les places à prendre se disputent donc aujourd'hui...
Nota : Pour les personnes intéressées par les architectures et technologies des plateformes IoT, OCTO Academy propose une formation spécialisée.
Si vous avez des projets autour de l'IoT n’hésitez à revenir vers nous. Angélique Vernier ou moi-même (Arnaud-François Fausse) nous ferons un plaisir de vous accompagner. Contacts : avernier@octo.com, afausse@octo.com