Web des Objets

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher

Le Web des Objets désigne l'intégration de tout appareil interrogeable et/ou contrôlable à distance, dans le monde du World Wide Web.

La création de réseaux d'objets intelligents à grande échelle, provenant du monde réel (dotés par exemple de puces RFID[note 1], faisant partie de réseaux de capteurs sans-fil, ou encore les systèmes embarqués) est devenu le but de nombreuses activités de recherches récentes et variés. Bien plus qu'une représentation de données et fonctionnalités par des concepts de systèmes verticaux, les objets intelligents font partie intégrante du Web.

Dans le Web des Objets, les technologies populaires du Web (HTML, JavaScript, AJAX[note 2], …) peuvent être utilisées pour développer des applications qui font appel à des objets intelligents. Les utilisateurs peuvent se servir des mécanismes Web bien connus (la navigation, la recherche, l'étiquetage, la mise en cache, les liaisons) pour interagir avec eux.

De multiples prototypes utilisent ces principes, dans un environnement de capteurs, de systèmes de supervision d'énergie et d'objets RFID sur le Web. Des applications ad-hoc telles que les Applications Composites Physiques[note 3] émergent de plus en plus de par la facilité de développement et d'intégration (faible taille).


Définition[modifier | modifier le code]

Description du Web des Objets

La notion du Web des objets est définie par une architecture commune et très utilisée telle que le World Wide Web afin d'y intégrer des objets physiques, permettant ainsi de combler le fossé entre les mondes physiques et numériques[1]. Il s'agit d'une amélioration de l'Internet des objets qui intègre des objets intelligents, non seulement dans l'Internet, mais aussi sur le Web (c'est-à-dire au niveau de la couche application)[2],[3].

Ainsi tout objet connecté devient alors une ressource disponible sur le Web. Il peut donc à son tour être utilisé dans n'importe quelle application basée sur le Web, conçue pour interagir avec le monde physique[4].

Le Web des objets consiste essentiellement dans le développement de concepts, d'outils et de systèmes pour la création et l'exploitation de réseaux d'objets associés à des ressources embarquées (puces RFID, capteurs et actionneurs, installations informatiques complexes) accessibles par des services web[5].

Depuis les années 1990, divers outils et techniques ont transformé le Web, Vlad Trifa a présenté cinq piliers qui forment la base du Web moderne[6] :

Le Web des objets est représenté par l'intersection de ces cinq tendances, et il est proposé comme une évolution du Web qui arrive dans le monde physique[6].

Les cinq piliers du Web, selon Vlad Trifa

Web social[modifier | modifier le code]

Article principal : Web social.

De nombreux services en ligne sont disponibles en 2011 pour construire et soutenir les communautés virtuelles, depuis les réseaux sociaux tels que Facebook ou MySpace, jusqu'à des plates-formes génériques (Ning, Facebook/Google connect)[6]. Il est possible de partager des objets avec d'autres personnes et partager des données ou des fonctionnalités vers une utilisation participative et collaborative d'objets d'amis (ces objets peuvent être des objets physiques mais aussi des objets virtuels comme les [réseaux sociaux, des services ou des applications)[7].

Web physique[modifier | modifier le code]

En dehors des serveurs et des navigateurs, divers objets sont connectés au Web[8], tels que des entrepôts (chaque section contient des balises RFID permettant le suivi d'objets[9]). Grâce à la prolifération (1,1 milliard en 2012[10]) des smartphones avec capteur GPS[note 9] et connexion à Internet, les applications de géolocalisation sont florissantes et des services permettent de créer un Web physique. Cela étend la portée des informations sur le Web de l'état des objets physiques du monde réel[6].

Web sémantique[modifier | modifier le code]

Article principal : Web sémantique.

Diverses annotations sémantiques sont de plus en plus utilisées aujourd'hui comme les informations d'en-tête de métadonnées analysés et indexés par des moteurs de recherche, ou même d'élaborer des langages sémantiques tels que OWL ou RDF[6]. Le Web sémantique vise à permettre à des agents logiciels à partager, réutiliser ou combiner des informations disponibles sur le Web[11].

Real-Time Web[modifier | modifier le code]

Article principal : Real time web.

Des finances aux journaux en passant par les réseaux sociaux, de nombreux domaines reposent sur des informations en temps réel livrées en temps opportun. Les services en ligne ont de plus en plus besoin de grandes quantités d'informations pour être livrés de manière sûre aussi vite que possible. Divers outils et techniques ont fait leur apparition pour transmettre des informations en temps réel sur le Web[6]. Un moteur de recherche pouvant agréger toutes ces données rapidement a été créé pour le Web des Objets[12].

Web programmable[modifier | modifier le code]

Article principal : Web 2.0.

Une des principales caractéristiques du Web 2.0 est la possibilité d'accéder à des données brutes à partir d'applications Web via une API[note 10] Web. Le Web des Objets correspond au Web 2.0 auquel on ajoute l'interaction avec les objets physiques. De nombreuses entreprises ont pris conscience des avantages à rendre leurs données et leurs services accessibles par voie de programme et pas seulement dans la fourniture de produits finis. En 2011, des milliers de sites Web mettent à disposition leurs données par le biais d'API ouvertes[6].

Les standards utilisés[modifier | modifier le code]

Spécifications[modifier | modifier le code]

HTTP[modifier | modifier le code]

Article principal : HTTP.

Le protocole HTTP est utilisé dans le Web des Objets en tant que protocole applicatif : les opérations fournies par HTTP (GET, POST, PUT, DELETE) fournissent aux ressources d'un objet connecté les quatre fonctionnalités basiques de contrôle CRUD, elles en définissent alors une interface uniforme, avec une sémantique connue et partagée[13].

URI[modifier | modifier le code]

Article principal : Uniform Resource Identifier.

Sur le Web, l'identification d'une ressource se fait par une représentation URI[note 11]. Un objet intelligent peut comporter nombre de ressources (capteurs, actionneurs, source d'énergie, interface radio, …), chacun pouvant être lié à une ou plusieurs autres ressources : structurés de manière hiérarchique, ces ressources fournissent également des liens de retour vers la ressource-parent ou de transfert vers les ressources-enfant[14]. La modélisation de cet objet par URI (ses ressources, leurs liens, leurs hiérarchies) n'est pas en soi strictement nécessaire, mais une bonne conception de ces URI facilitera le travail des développeurs sur la découverte et la compréhension des différentes ressources et de leurs interactions[14].

Atom[modifier | modifier le code]

Article principal : Atom.

Les applications utilisant des objets intelligents peuvent avoir besoin d'être abonné aux différentes informations relatives à l'objet ou à l'ensemble des objets qu'elle utilise[14]. Avec Atom, le Web possède un modèle standardisé et RESTful pour interagir avec des collecteurs d'information ; le protocole Atom Publishing Protocol ajoute également des interactions en mode lecture/écriture. Toute information ou opération d'un objet ou d'un ensemble d'objets peut ainsi être mémorisé dans une mémoire tampon, permettant aux utilisateurs de superviser ces objets par souscription au flux Atom sur un serveur distant, plutôt que d'interroger unitairement tous les objets[14].

Style Architectural[modifier | modifier le code]

Le Web des Objets défini l'ouverture des objets au web : l'accessibilité et l'interopérabilité sont donc des aspects majeurs dans le choix et la conception d'une architecture. La communication entre les applications résidentes sur un objet et les applications web est appelée Service Web.

Services Web WS-*[modifier | modifier le code]

Historiquement, ce sont XML-RPC puis SOAP qui ont été les premières approches pour le développement d'un protocole générique, utilisant le paradigme d'appel de méthodes à distance.

Ce paradigme facilite le travail du développeur : le modèle d’interaction par appel de méthodes métier est le même que celui de l’application ; il améliore également un aspect de l’interopérabilité en spécifiant le format dans lequel les informations doivent être encodées[15]. Cependant, on ne peut pas parler d’interopérabilité du protocole applicatif dans la mesure où les méthodes métiers apparaissent dans l’interface publiée. Les applications discutant sur ce modèle sont fortement couplées, impliquant un investissement supplémentaire pour l’intégration de chaque nouvelle application. SOAP a su évoluer[16] pour pallier ce problème en généralisant les modèles d’interactions, principalement les communications synchrones et asynchrones, et les communications avec et sans état. Cependant, en décrivant de plus en plus exhaustivement ces différents modèles d’interaction, SOAP est devenu un cadre de développement de protocoles applicatifs et non plus un protocole générique.

Dans le Web des Objets, SOAP apparait donc comme un protocole puissant par ses possibilités (synchrone/asynchrone, description des services et de leur composition), mais complexe à mettre en œuvre et à faire évoluer.

REST (RESTful architecture)[modifier | modifier le code]

Article principal : Representational State Transfer.

L'idée centrale de REST est axé sur de la notion de ressource comme l'un des composants d'une application qui doit être utilisé ou pris en compte. Une ressource peut donc représenter un objet physique (un capteur de température par exemple), mais aussi un concept abstrait tel que des collections d'objets[2].

REST propose deux règles de base : l'identification d'une ressource à l'aide d'un URI, et la définition d'une interface uniforme par l'utilisation du protocole HTTP[13]. Une autre priorité de REST est la communication simple point-à-point via HTTP en utilisant les formats tels que JSON[note 12] ou encore XML[note 13],[17].

La simplicité de ce style architectural le rend particulièrement attractif dans le développement du Web des Objets : la facilité de son utilisation, et la possibilité de bénéficier des caractéristiques de HTTP pour assurer l'authentification, le cryptage, la scalabilité et la mise en cache[18].

Principaux avantages et inconvénients du REST et des Services Web WS-*[19]
Besoin REST WS-* Justification
Mobile et embarqué + - Léger, support Internet Protocol/HTTP
Simple d'utilisation ++ - Simple à comprendre/appréhender
Évolutivité ++ + Méchanisme Web
Commerce + ++ QoS et sécurité
Contrat de service + ++ WSDL
Sécurité avancée - +++ WS-Security
pREST[modifier | modifier le code]

pREST décrit comment utiliser REST pour interconnecter des ressources dans les applications SEC[note 14]. Tout en pREST est modélisé comme une ressource Web. Producteurs et consommateurs de données de capteurs peuvent alors être connectés en utilisant pREST (par exemple, une caméra envoie une image sur le serveur Web afin d'être publiée)[6].

TinyREST[modifier | modifier le code]

TinyREST propose également une passerelle pour connecter directement des dispositifs comme des ressources sur le Web. Permettant ainsi aux clients d'envoyer des requêtes Web à l'URI de divers terminaux via la passerelle. Malheureusement, il introduit un verbe supplémentaire (SUBSCRIBE) en plus de POST et GET pour supporter les interactions de publications et de souscriptions. Ceci est contraire aux principes du REST car cela réduit la compatibilité avec les autres applications RESTful[6].

Les objets intelligents[modifier | modifier le code]

Dominique Guinard définit les objets intelligents[note 15] comme des objets du monde réel doués d'une capacité de communication[19]. Ils sont également appelés « objets connectés », « objets communicants » ou « objets acteurs »[20].

Les objets intelligents sont généralement limités en puissance (CPU, RAM, Mémoire flash, énergie). Typiquement, sur 1 cm2, on trouvera un microprocesseur, très peu de RAM (quelques dizaines d’octets), un peu de Flash (quelques douzaines de kibioctets), des interfaces et un module radiofréquence[note 16] ou CPL[note 17]. Lorsque ces objets disposent de piles et sont connectés en sans-fil, le point critique est leur consommation en énergie. Les flux de données sont souvent extrêmement limités (quelques paquets par minute, voire par mois), mais chaque bit transmis a un coût énergétique, et l’objet intelligent doit rester autonome (sans remplacement de pile) pendant 5 à 10 ans. C’est face à ce problème d’économies d’énergie que la notion d’objet « intelligent » et les techniques de gestion de l’énergie deviennent primordiales. Ceci ne s’applique pas, bien entendu, aux objets raccordés au courant électrique alternatif comme ceux connectés via CPL (ceux-ci peuvent cependant avoir des contraintes de mémoire, CPU, etc.)[21].

Parmi les domaines d'application de ces objets, on peut citer : les réseaux de capteurs déployés dans nos villes modernes, les rendant plus intelligentes et adaptatives. Il y a également la domotique qui permet à nos nouveaux téléviseurs, radio-réveils, réfrigérateurs ou cadres photos de nous rendre la vie plus facile et d'optimiser notre communication ou notre consommation d'énergie. De façon similaire, l'industrie bénéficie de robots et de machines de plus en plus intelligentes et les biens de consommation sont équipés d'étiquettes électroniques ou de codes-barres liés à des sources d'informations virtuelles permettant de nouveaux cas d'utilisation[19].

Les Systèmes Embarqués Connectés (SEC)[modifier | modifier le code]

Vlad Trifa définit que tout appareil possédant une puissance de calcul limitée et/ou une source d’énergie restreinte, équipé d’une interface de communication avec ou sans fil et de divers capteurs ou actionneurs, est un Système Embarqué Connecté[note 18],[6]. Il existe une quantité de Systèmes Embarqués Connectés, en voici quelques-uns :

Les capteurs intelligents/futés[modifier | modifier le code]

Un capteur est un dispositif qui transforme une grandeur physique mesurée (température, pression, niveau) en une grandeur utilisable (intensité électrique, position d’un flotteur) à l'aide d'au moins un transducteur. Par extension, le mot capteur est utilisé pour désigner l’ensemble : capteur, conditionneur, transmetteur de signaux et alimentation[22]. Le comité IEEE[note 19] a activement participé à la consolidation de la définition du capteur intelligent (IEEE 1451 (en)). Un capteur intelligent/futé est un capteur qui fournit des fonctionnalités qui vont au-delà de celles nécessaires à la juste représentation d’une mesure perçue[23].

Le qualificatif intelligent pourrait quant à lui se justifier par les facultés suivantes[22]. Cela correspond principalement à l'intégration dans le corps du capteur d'un organe de calcul interne (microprocesseur, microcontrôleur), d'un système de conditionnement du signal (programmable ou contrôlé) et d'une interface de communication bidirectionnelle[24] :

  • connaître ;
  • s’adapter aux situations ;
  • communiquer.

Dans le Web des Objets, le capteur intelligent se décompose donc ainsi[25] :

  • un ou plusieurs transducteur(s) ;
  • des conditionneurs spécifiques ;
  • une mémoire ;
  • une alimentation ;
  • un organe intelligent interne permettant un traitement local, et l'élaboration d'un signal numérique ;
  • une interface de communication.

RFID[modifier | modifier le code]

Article principal : Radio-identification.
Une puce RFID

EPCIS (en) (EPICS) est un standard de la norme EPCglobal (en) qui définit des interfaces autorisant la capture et la récupération de données RFID. Ces interfaces limitent l'espace applicatif aux plates-formes ayant une puissance confortable et pouvant interagir avec les Services Web WS-*[14],[18]. L'idée de D. Guinard, M. Mueller et J. Pasquier-Rocha est la création d'une architecture RESTful répondant de façon transparente au standard EPCIS[18]. En considérant cette approche, chaque récupération de données ou étiquetages d'objets, chaque lecture d'information RFID aura une URI unique qui pourra par la suite être utilisée dans un courriel, une signature, être attaché à un courriel, etc[18],[14]… En outre ce changement de paradigme permet aux langages Web tels que le HTML et le JavaScript d'utiliser directement les données RFID pour développer rapidement des applications légères telles que des applications mobiles ou des mashups. De cette façon les données RFID seraient utilisables par l'univers du Web des Objets[18].

Le nom de EPCIS-Restadapter désigne ce nouveau standard qui se décline comme un module open-source du projet Fosstrack (Fosstrack est une plate-forme logicielle open-source qui met en application les caractéristiques de réseau de EPC). C'est de ce fait une bonne chance de créer une plus grande communauté de développeurs utilisant les EPCIS et son API RESTful et ainsi assurer leur avenir dans l'Internet/Web des Objets ou dans les prototypes et appareils mobiles[18].

Les Réseaux de capteurs sans-fil[modifier | modifier le code]

Article principal : Réseau de capteurs sans fil.
Exemple d'architecture d'un réseau de capteurs sans-fil

Le but du Web des Objets étant d’amener le maximum d’objets intelligents au plus proche du Web[19], certaines caractéristiques des réseaux de capteurs sans-fil les rendent possiblement intéressant : leur capacité à être fiable, hétérogènes, évolutifs, et robuste[26]. Pour atteindre cet objectif, il faut une conception rigoureuse. Particulièrement dans un contexte ou les ressources des objets peuvent être limitées et où la topologie des réseaux est évolutive[26].

Pour répondre aux services de haute disponibilité mentionnés ci-dessus, sans affecter l'hétérogénéité des architectures de réseaux de capteurs sans fil existant, une couche middleware est nécessaire[26].

Le middleware peut être considéré comme une infrastructure logicielle qui fait la liaison entre le réseau de capteur, le système d’exploitation, la pile réseau, et les applications. Une solution middleware complète devrait contenir un environnement d'exécution qui supporte et coordonne des applications multiples et des services systèmes standardisés. Ex : l’agrégation de données ou la gestion et la manipulation des règles des applications cibles[26],[27]. L’architecture logicielle du middleware devra également fournir un mécanisme efficace et adapté à l’utilisation des ressources systèmes. Des ressources systèmes bien maitrisées permettent une dépense d’énergie adaptée et de ce fait, cela participe à prolonger la vie du réseau de capteur[26],[27].

Grâce à l’hétérogénéité des réseaux de capteurs sans fil, les nœuds de capteurs peuvent supporter plusieurs types de capteurs. Ces capteurs peuvent avoir des besoins en énergie différents et des capacités de calcul qui diffèrent, ils peuvent communiquer avec d’autres réseaux (à travers une passerelle)[26]. De ce fait, les capteurs les plus puissants (mais « gourmands » en termes d’énergie et onéreux) peuvent effectuer des opérations complexes. À l’inverse, les plus « économes », qui sont aussi les moins chers, permettent un déploiement de masse et ainsi augmente la durée de vie du réseau (fiabilité accrue)[26].

Du fait de leur robustesse, le déploiement de réseaux de capteurs sans fils dans des milieux hostiles est possible[28].

Grâce aux progrès réalisés dans les technologies des microsystèmes électromécaniques, le développement de nœuds de capteurs multifonctions, à faible consommation d’énergie et faible coût s’est démocratisé[29]. Les réseaux de capteurs sont utilisés dans de nombreux environnements : le bâtiment, les services publics, l’industrie, les habitations (domotique), le transport (routier, maritime, …), les systèmes d'automatisation et dans bien d’autres domaines[30]. Le nombre de réseaux de capteurs sans fil devraient s’accroître dans les prochaines années, car ils permettent une analyse et une surveillance fiable du « monde physique »[29].

Les serveurs Web embarqués[modifier | modifier le code]

Article principal : Serveur web embarqué.

Un nombre important d'équipements personnels munis d'un écran possèdent un navigateur Web, le Web des Objets propose d’embarquer des serveurs web dans les environnements systèmes qui sont très contraints et ne disposent pas d’écran. Cette extension du Web des Objets jusqu’à l’informatique enfouie constitue un grand défi. Il s'agit en effet d’embarquer des serveurs d’applications Web exigeants en performances et en fonctionnalités dans les équipements aux fortes contraintes matérielles[31].

En 2002, Tim Kindberg et son équipe avec un projet nommé CoolTown ont proposé de faire le lien entre les objets physiques et des pages Web contenant des informations et des associations de services. Ils utilisaient des interfaces infrarouges et des codes barres sur les objets, les utilisateurs n'avaient plus qu'à récupérer l'URI pour interagir avec l'objet[14].

Depuis 2002, plusieurs projets de serveurs Web embarqués sur des objets physiques ont été menés, tous axés sur le Web des Objets (Luckenbach en 2005, Wilde en 2007, Stirbu en 2008 et Guinard en 2010)[14]. Ces serveurs Web implémentaient leur propre pile TCP/IP, cela permettait notamment d'économiser de la mémoire (empreinte mémoire d'environ 100 à 200 octets et quelques kilooctets de mémoire EEPROM)[14].

Une des particularités communes à ces serveurs Web embarqués est qu'ils utilisent le concept d'AJAX. Ce modèle d’application Web permet de construire des applications Web et des sites Web dynamiques interactifs depuis un poste client à travers le protocole HTTP. Le défaut principal de ce concept pour le Web des Objets (notamment en réseau PAN) est qu'il n'autorise pas l'envoi de données (notifications d’évènement) du serveur vers le client[32]. En effet ce cas d’usage peut être utile pour un capteur souhaitant lever une alerte ou pour une application qui a besoin d’informer ses clients de la mise à jour de divers états du serveur[31].

Un nouveau modèle d’application Web a vu le jour, ce dernier autorise désormais l’envoi de données du serveur vers le client. Les travaux ont été menés dans le but d’évaluer la meilleure stratégie concernant la notification d’évènements basée sur le Web. Son nom est Comet[32]. La contre partie est que le paradigme Comet impose au serveur de maintenir ouvertes autant de connexions qu'il y a de clients en attente de notification, engendrant classiquement une consommation de mémoire importante coté serveur[31].

En 2009, Simon Duquennoy met en œuvre un système d’exploitation dédié au support d’applications web en environnement contraint d’un nouveau genre. Son nom est Smews. Il n'a besoin que de 200 octets de mémoire RAM et de 7 kilooctets de mémoire EEPROM pour fonctionner[33].C'est la première solution de ce genre basée sur Comet, elle s’oriente sur une conception conjointe du serveur Web et du système d’exploitation. L’objectif de ce projet est d’allier compacité, fonctionnalités et performances dans le but de servir le Web des Objets[31].

Intégration directe ou indirecte des objets au Web[modifier | modifier le code]

Schéma d'architecture avec intégration directe ou indirecte

Pour intégrer les objets intelligent dans le Web, il y a 2 façons de faire : soit les objets intelligents sont directement connectés au Web soit ils utilisent un intermédiaire : le proxy[34].

Des travaux antérieurs ont montré qu’il est possible d’embarquer des serveurs web sur des systèmes limités en ressources. De plus il est probable que dans un avenir proche, nombre de plate-formes embarquées supporteront les connexions TCP/IP, notamment grâce au protocole 6LoWPAN[note 20]. Cette approche est parfois utile car il n’y a pas le besoin de convertir les requêtes HTTP du client Web vers le protocole spécifique à chaque objet. De ce fait ces derniers peuvent être directement intégrés et faire en sorte que leurs API RESTful soient directement accessibles depuis le Web[34].

Cependant, pour un grand nombre d’objets intelligents, il n’est parfois pas souhaitable d’y accéder de manière directe[19]. Dans le cas des objets intelligents limités en ressources, notamment ceux qui n'ont pas de connexion filaire, les besoins des protocoles TCP/IP et HTTP ne sont pas adaptés car trop consommateurs en termes d’énergie, de calcul, de mémoire et de bande passante. De plus, certains objets intelligents ne les supportent pas nativement[19]. C'est généralement le cas des réseaux de capteurs sans-fil[35]. Dans ce cas, l’intégration du monde physique (objets intelligents) au Web passe par l’utilisation d’un reverse-proxy. Il sert de passerelle entre le réseau interne (les objets qui ne communiquent pas via IP) et le Web[35].

Les reverse proxies ont des propriétés intéressantes pour le Web des Objets : ils font office de point de coupure et servent à masquer le réseau interne des requêtes clientes. Ils servent aussi à stocker en mémoire (locale) certaines données statiques (pages HTML, images, etc.) et jouent un rôle dans la répartition de charge pour les nombreuses architectures orientées services[35].

Pour le Web des Objets, une approche similaire a été imaginée, c’est le concept de la passerelle intelligente (Smart Gateway). Il s'agit un reverse proxy amélioré car elle fait plus que de la simple transmission de donnée[19]. C'est un serveur Web[34] qui, vu de l’intérieur, du côté des objets intelligents, s’adapte et comprend les divers protocoles propriétaires (ex : RFID, Zigbee, Bluetooth, Ultra Large Bande[note 21], …)[28].Depuis le Web, elle doit être totalement transparente. Le client Web utilise les protocoles de communication standards du Web, comme HTTP, pour communiquer avec la Smart Gateway[28].

Du Mashup Web 2.0 au Mashup Physique[modifier | modifier le code]

De nombreux systèmes ont été proposés pour intégrer des systèmes de capteurs à Internet, tels que SenseWeb, Pachube[36], … Ils sont conçus comme un service web qui permet à des personnes de connecter et partager en temps réel les données de leurs capteurs et de les transmettre vers un serveur central.

Ces approches sont basées sur un référentiel centralisé et les objets intelligents doivent être enregistrés avant de pouvoir publier des données[35], les objets intelligents sont considérés comme des acteurs passifs qui sont seulement autorisés à transmettre des données[34]. Ce type d'application concerne davantage le stockage et la récupération de données, ce n'est pas suffisamment évolutif, et donc moins adapté au Web des Objets[35].

L'un des buts du Web des Objets est d’amener ces derniers au plus proche du Web et de faciliter leurs utilisations dans des applications composites. Tout comme les aficionados des technologies du Web et du Web 2.0 créent facilement des mashups[note 22](c'est-à-dire des applications légères et dynamiques utilisant plusieurs services du Web), ils devraient pouvoir en faire de même avec les objets intelligents[19]. En d'autres termes, mélanger les services du monde réel avec le monde virtuel[37]. C’est la raison pour laquelle Dominique Guinard à traité le sujet de la composition de services et introduit la notion de mashups physiques. Il y propose une plate-forme logicielle construite comme une extension d'un gestionnaire de processus et offrant des éléments de langage permettant de créer des éditeurs de Mashup pour les objets intelligents[19]. Le but est de faire en sorte que les utilisateurs finaux réutilisent les fonctionnalités du monde réel (réseaux de capteurs et actionneurs sans-fils, appareils électroniques, etc.) et de combiner ces services aux mashups physiques[38].


Dominique Guinard distingue trois approches du développement de mashups physiques :

  • Le développement manuel de mashups : il consiste au développement d'applications composites qui intègrent des Objets intelligents grâce aux technologies du Web telles que HTML, HTTP, Atom et Javascript mais sans utiliser les outils spécifiques des mashups. Cela implique un minimum de connaissances pour le développeur.
  • Le développement de mashups basé sur les Widgets : dans ce type de développement, un logiciel Framework, parfois appelé portail, communique avec des objets intelligents et rend leurs données disponibles sous forme d'un tableau de données où les données sont écrites en temps réel dans des variables stockées en mémoire. Les développeurs n'ont plus qu'à créer des widgets (ou portlet) qui iront lire et enregistrer ces variables. Ces widgets sont généralement écrits en combinant les langages HTML et JavaScript. Grâce à ce modèle, la communication avec les objets intelligents est dite à haut niveau d'abstraction. De ce fait les utilisateurs de ce modèle peuvent créer des applications composites liées à leurs domaines sans avoir à apprendre les subtilités des systèmes embarqués.
  • Le développement de mashup par l'utilisateur final grâce aux éditeurs de mashup : comme son nom l'indique cette approche permet aux utilisateurs finals de créer leurs propres applications composites. Dans le cas des mashups Web 2.0 cela se fait généralement via un éditeur de mashup comme Yahoo Pipes, ClickScript, etc. Ces plates-formes Web permettent de créer visuellement des sites Web grâce à des règles simples. Une approche similaire peut être appliquée pour permettre aux utilisateurs de créer de petites applications adaptées à leurs besoins utilisant leurs objets intelligentes.

Pour mieux appréhender les exigences d'un éditeur de Mashup physique, Dominique Guinard a adapté un éditeur de mashup Web 2.0. qui implémente des applications qui accèdent à des objets intelligents. Il a choisi d'adapter l'éditeur de Mashup Clickscript[19].

Exemples d'applications[modifier | modifier le code]

  • À Singapour, le projet WaterWise[39] a consisté à placer des capteurs sur les conduites d’eau pour surveiller en temps réel la pression, la température, et analyser la composition chimique et biologique de l’eau… ce qui permet de repérer les fuites, de réagir plus vite à un incident. Et surtout de mieux étalonner la consommation selon la demande.
  • À Rio de Janeiro, IBM, avec leur initiative Smart Planet[40], a construit, en partenariat avec la ville, un centre d’opération[41] qui fonctionne indépendamment de tout organisme tout en recevant des données de plusieurs d’entre eux.
  • La perte de cargaison en raison de vol ou de dégâts est significative, l'impact financier est évalué à 50 milliards de dollars par an. Les solutions seraient de suivre, tracer les marchandises avec des balises RFID et des capteurs (SenseAware[42] permet au consommateur d'avoir des informations sur la cargaison) et détecter les évènements qui affectent la cargaison (retard dû à la météo) et ainsi réduire les dégâts (en réacheminant la cargaison)[43],[44].
  • Dans le monde médical, les capteurs et les liaisons de données offrent des possibilités pour contrôler la santé d'un patient en temps réel et à un coût relativement bas[44].
  • "Mother" crée par la societé française SES.SE a fait sensation en salon CES 2014 lors de sa presentation, un innovant concept capable de transformer en objets connecté n'importe quel objet ou accessoire dans la maison (brosse à dent, boite de medicaments, arrosoir pour les plantes etc..)[45],[46]

Historique[modifier | modifier le code]

2002 : Pour le projet Cool Town, T. Kindberg a proposé de lier des objets physiques avec des pages Web contenant des informations et des services associés[14].

Depuis 2002, plusieurs projets de serveurs Web embarqués sur des objets physiques ont été menés, tous axés sur le Web des Objets (T. Luckenbach en 2005, E. Wilde en 2007, V. Stirbu en 2008 et D. Guinard en 2010)[14].

2007 : L'idée du Web des Objets est venu de Dave Raggett et Erik Wilde, qui ont inspiré les premiers travaux de Vlad Trifa et Dominique Guinard sur le Web des Objets, où les technologies Web ont été utilisées pour contrôler des robots et d'autres dispositifs intégrés[6].

Des petits serveurs Web sont intégrés dans des objets intelligents (Richardson et Ruby en 2007, R. Fielding en 2000)[14].

2009 : Mise en œuvre par S. Duquennoy d’un système d’exploitation dédié au support d’applications web en environnement contraint d’un nouveau genre (Smews)[31].

2010 : Une autre façon d'utiliser le Web, pour les objets physiques, est d'intégrer des objets intelligents dans une architecture Web standard (utilisant les standards comme SOAP, WSDL, UDDI, …)[14].

Le tableau suivant récapitule l'évolution du Web, du Web 1.0 au Web des Objets[44].

Du Web 1.0 au Web des Objets
Date apparition Description Technologies
Web 1.0 1995 page HTML Statique HTML, HTTP
Web 1.5 1997 Contenu HTML dynamique Coté client (JavaScript, DHTML, Flash, …), coté serveur (CGI, PHP, Perl, JSP, …)
Web 2.0 2003 Partage d'information participatif, intéropérabilité, conception centré sur l'utilisateur et collaboration sur le Web. Weblogs, wikis, podcasts, fils RSS, web services, … URI, XML, RDF, OWL
Web 3.0 2008 Les définitions varient du Web sémantique à l'intelligence artificielle Amélioration des technologies du Web 2.0
Web des Objets 2010 Tous les jours, des périphériques et des objets sont complètement intégrés au Web Utilise les normes standards (comme URI, HTTP, Atom, REST, etc.)

Volet juridique[modifier | modifier le code]

La Commission Européenne est active sur le sujet de l'Internet des Objets. Elle présente dès le 18 juin 2009 une communication qui expose les perspectives et les enjeux de son développement[47]. Elle traite en premier lieu de la définition, de la présentation des applications actuelles et des enjeux d'une gouvernance publique[47]. Elle s'occupe également des principes fondateurs de cette gouvernance :

  • le respect de la vie privée
  • la confiance dans la société de l’information (protection des données personnelles)[47]
  • la liberté pour un individu de pouvoir se déconnecter d’un réseau à tout moment[47].

Cette Commission est aussi partie prenante dans les mandats de normalisation, en relation directe avec les différents organismes de normalisations (ETSI, CEN, CENELEC), de leurs homologues internationaux (ISO, UIT) et d'autres organismes et consortiums de normalisation (IETF, EPCglobal, etc.) : toutes les parties concernées participent ainsi à l'établissement des normes de l'Internet des Objets de manière ouverte, transparente et consensuelle. Une attention particulière est donnée sur les études :

  • du groupe de travail sur la communication de machine à machine de l'Institut Européen des normes de télécommunications (ETSI)
  • de l'IETF (Internet Engineering Task Force) dans le domaine des services de recherche[47].

Notes[modifier | modifier le code]

  1. Acronyme : Radio Frequency IDentification. Traduction : Radio-identification
  2. Acronyme : Asynchronous JavaScript and XML.
  3. Traduction de : Physical Mashups
  4. Traduction de : Social Web
  5. Traduction de : Physical Web
  6. Traduction de : Semantical Web
  7. Traduction de : Real-Time Web
  8. Traduction de : Programmable Web
  9. Acronyme : Global Positioning System. Traduction : système de localisation mondial
  10. Acronyme : Application Programming Interface. Traduction littérale : Interface de programmation
  11. Acronyme : Uniform Resource Identifier. Traduction littérale : identifiant uniforme de ressource
  12. Acronyme : JavaScript Object Notation.
  13. Acronyme : Extensible Markup Language.
  14. Acronyme : Système embarqué connecté. Traduit de : Networked Embedded Devices.
  15. Traduit de : Smart Things.
  16. Acronyme : RF.
  17. Acronyme de : Courant Porteur en Ligne.
  18. Acronyme : SEC. Traduit de : Network Embedded Devices (NED).
  19. Acronyme de : Institute of Electrical and Electronic Engineers.
  20. Acronyme : IPv6 Low power Wireless Personal Area Networks.
  21. Traduction de : Ultra-WideBand (UWB).
  22. Traduction de : Applications composites


Références[modifier | modifier le code]

  1. S. Mathew 2011, p. 9
  2. a et b D. Guinard 2010, p. 1
  3. V. Stirbu 2008, p. 513
  4. B. Christophe 2011, p. 55
  5. A. Ruppen 2011, p. 860
  6. a, b, c, d, e, f, g, h, i, j et k V. Trifa 2011, p. 28
  7. A. Pintus 2012, p. 401
  8. Actualité des objets connectés
  9. E. Wilde 2007, p. 8
  10. M. Cherki 2012, p. 1
  11. M. Ruta 2011, p. 1
  12. B. Ostermaier 2010, p. 1
  13. a et b D. Guinard 2009, p. 2
  14. a, b, c, d, e, f, g, h, i, j, k, l et m D. Guinard 2011, p. 6
  15. R. Costello 2010, p. 3
  16. H. Haas 2010, p. 1
  17. L. Gao 2011, p. 1
  18. a, b, c, d, e et f D. Guinard 2010, p. 3
  19. a, b, c, d, e, f, g, h, i et j D. Guinard 2011, p. 98
  20. Philippe Gautier l, « Internet des Objets : Objets « connectés », objets « communicants »… ou objets « acteurs » », sur refondation.org,‎ 26 janvier 2010
  21. CiscoMag 2009, p. 1
  22. a et b F. Brissaud 2008, p. 2
  23. R. Frank 2000, p. 3
  24. Ministère de l'Industrie 1996, p. 1
  25. Michel Robert 1993, p. 9
  26. a, b, c, d, e, f et g S. Bandhari 2012, p. 36
  27. a et b Salem Hadim 2006, p. 1
  28. a, b et c D. Zeng 2011, p. 2
  29. a et b K.I. Hwang 2003, p. 1090
  30. F. Lewis 2005, p. 8
  31. a, b, c, d et e S. Duquennoy 2010, p. 41
  32. a et b S. Duquennoy 2011, p. 89
  33. S. Duquennoy 2009, p. 323
  34. a, b, c et d D. Guinard 2010, p. 4
  35. a, b, c, d et e D. Guinard 2010, p. 4
  36. PACHUBE
  37. D. Guinard 2010, p. 863
  38. V. Trifa 2010, p. 1
  39. WaterWise
  40. Smart Planet
  41. centre d’opération de Smart Planet
  42. SenseAware
  43. T. Hayes 2004, p. 1
  44. a, b et c C. Fortuna 2012, p. 21
  45. http://www.01net.com/editorial/611216/lancement-de-mother-l-objet-connecte-qui-analyse-notre-vie-quotidienne/
  46. http://www.futuremag.fr/emission/emission-15
  47. a, b, c, d et e Commission Européenne 2009, p. 2


Bibliographie[modifier | modifier le code]

  • (en) D. Guinard, A Web of Things Application Architecture - Integrating the Real-World into the Web,‎ 2011, 1-225 p. (lire en ligne)
    Thèse, DOCTOR OF SCIENCE, Diss. ETH No. 19891, ETH Zurich
  • (en) V. Trifa, Building Blocks for a Participatory Web of Things: Devices, Infrastructures, and Programming Frameworks,‎ 2011, 1-154 p. (lire en ligne)
    Thèse, DOCTOR OF SCIENCE, Diss. ETH No. 19890, ETH Zurich
  • (en) D. Guinard, V. Trifa, F. Mattern et E. Wilde, From the Internet of Things to the Web of Things : Resource Oriented Architecture and Best Practices,‎ 2011, 1-33 p. (lire en ligne)
  • (en) C. Pfister, Get Started with the Internet of Things,‎ 2011, 1-42 p. (ISBN 978-1-4493-9357-1)
  • (en) D. Guinard, V. Trifa et E. Wilde, « A Resource Oriented Architecture for the Web of Things », IEEE Conference Publications,‎ 2010, p. 1-8 (ISBN 978-1-4244-7413-4, lien DOI?)
  • (en) T. Berners-Lee, « The Future Web », ERCIM News,‎ 2008, p. 1-64 (ISSN 0926-4981)
  • (en) S. Mathew, Y. Atif, Q. Sheng et Z. Maamar, Web of Things : Description, Discovery and Integration,‎ 2011, 9-15 p. (ISBN 978-0-7695-4580-6, lien DOI?)
  • (en) A. Ruppen, J. Pasquier et T. Hürlimann, A RESTful architecture for integrating decomposable delayed services within the Web of Things,‎ 2011, 860-865 p. (ISSN 1521-9097, lien DOI?)
  • (en) D. Guinard, V. Trifa, T. Pham et O. Liechti, Towards physical Mashups in the Web of Things,‎ 2009, 1-4 p. (ISBN 978-1-4244-6314-5, lien DOI?)
  • (en) L. Gao, C. Zhang et L. Sun, RESTful Web of Things API in Sharing Sensor Data,‎ 2009, 1-4 p. (lien DOI?)
  • (en) S. Duquennoy, G. Grimaud et J-J. Vandewalle, The Web of Things: interconnecting devices with high usability and performance,‎ 2009, 323-330 p. (ISBN 978-0-7695-3678-1, lien DOI?)
  • (en) Leonard Richardson et Sam Ruby, RESTful Web Services, O'Reilly,‎ 2007, 299–314 p. (ISBN 0-596-52926-0)
  • (en) V. Stirbu, Towards a RESTfull Plug and Play Experience in the Web of Things,‎ 2008, 512-517 p. (ISBN 978-0-7695-3279-0, lien DOI?)
  • Commission Européenne, L'Internet des Objets,‎ 2009 (lire en ligne), p. 1-12
  • (en) Kwang-il Hwang, Jeongsik In, NhoKyung Park et Doo-seop Eom, A Design and Implementation of Wireless Sensor Gateway for Efficient Querying and Managing through World Wide Web,‎ 2003, 1090 - 1097 p. (lien DOI?)
  • (en) F. Lewis, Wireless Sensor Networks : Smart Environnements : Technologies, Protocols and Applications,‎ 2005, 1-18 p. (lien DOI?)
  • (en) Deze Zeng, Song Guo et Zixue Cheng, « The Web of Things: A Survey », Journal of Communications, Vol 6, No 6 (2011), 424-438, Sep 2011,‎ 2011, p. 1-15 (lien DOI?, lire en ligne)
  • Sébastien Faye, Rapport Technique Contrôle du trafic routier urbain par un réseau fixe de capteurs sans fil,‎ 2011 (lire en ligne), p. 1-44
  • (en) Lili Wu, Janne Riihijarvi et Petri Mahonen, A modular wireless sensor network,‎ 2008, 882 - 886 p. (ISBN 978-1-4244-1009-5, lien DOI?)
  • (en) Dominique Guinard, Vlad Trifa et Eric Wilde, Towards the Web of Things : Web Mashups for Embedded Devices,‎ 2010 (lire en ligne), p. 1-44
  • (en) D. Guinard, M. Fischer et V. Trifa, Sharing Using Social Networks in a Composable Web of Things,‎ 2010, 702 - 707 p. (ISBN 978-1-4244-5328-3)
  • Florent Brissaud et Dominique Charpentier, Capteurs intelligents : nouvelles technologies et nouvelles problématiques pour la sureté de fonctionnement,‎ 2008 (lire en ligne), p. 1-8
  • Capteurs intelligents,‎ 1996 (lire en ligne), p. 1
  • Michel Robert, Michel Porte et Michel Marchandiaux, Capteurs intelligents et méthodologie d'évaluation,‎ 1993 (ISBN 2-86601-382-4), p. 166
  • (en) Randy Frank, Understanding smart sensors,‎ 2000 (ISBN 0-89006-824-0), p. 389
  • Dominique Guinard, Vlad Trifa et Erik Wilde, Architecting a Mashable Open World Wide Web of Things,‎ 2010 (lire en ligne), p. 9
  • (en) Raymond Yee, Pro Web 2.0 Mashups Remixing Data and Web Services,‎ 2008, 603 p. (ISBN 978-1-59059-858-0)
  • « L’Internet des objets, ou la connexion d’objets intelligents via l’Internet ou un Intranet », CiscoMag, No 25 (2009), 1-5, Mars 2009,‎ 2009, p. 5 (lire en ligne)
  • (en) Dominique Guinard, Towards Opportunistic Applications in a Web of Things,‎ 2010, 863 - 864 p. (ISBN 978-1-4244-6605-4)
  • (en) Simon Mayer, Dominique Guinard et Vlad Trifa, Facilitating the Integration and Interaction of Real-World Services for the Web of Things,‎ 2010 (lire en ligne), p. 6
  • (en) S. Bandhari, I. Khan, S.N. Han, S.H. Shah Newaz, G.M. Lee et N. Crespi, D2.1 State-of-the-art relevant to the Web of Objects,‎ 2012 (lire en ligne), p. 140
  • (en) B. Christophe, M. Boussard, M. Lu et A. Pastor, « The Web of Things Vision: Things as a Service and Interaction Patterns », Bell Labs Technical Journal, N°16,‎ 2011, p. 55-62 (ISSN 1538-7305, lien DOI?, lire en ligne)
  • (en) A. Pintus, D. Carboni et A. Piras, Paraimpu: A Plateform for a Social Web of Things,‎ 2012 (lien DOI?), p. 401-404
  • (en) M. Ruta, F. Scioscia, E. Di Scioscia et D. Rotondi, Ubiquitous Knowledge Bases for the Semantic Web of Things,‎ 2011 (lire en ligne), p. 1-6
    1st IoT International Forum, Berlin, November 2011.
  • (en) B. Ostermaier, K. Römer, F. Mattern, M. Fahrmair et W. Kellerer, A Real-Time Search Engine for the Web of Things,‎ 2010 (ISBN 978-1-4244-7414-1), p. 1-8
  • (en) Dominique Guinard, Mathias Mueller et Jacques Pasquier-Rocha, Giving RFID a REST: Building a Web-Enabled EPCIS,‎ 2010, 1 - 8 p. (ISBN 978-1-4244-7413-4, lien DOI?)
  • (en) S. Hadim, Middleware: middleware challenges and approaches for wireless sensor networks,‎ 2006, 1 - 23 p. (ISSN 1541-4922, lien DOI?)
  • Simon Duquennoy, Smews : un système d'exploitation dédié au support d'applications Web en environnement contraint,‎ 2010 (lire en ligne), p. 1-143
    Thèse Simon Duquennoy : Docteur de l'Université Lille1 - Sciences et Technologies
  • (en) Simon Duquennoy, Gilles Grimaud et Jean-Jacques Vandewalle, Consistency and scalability in event notification for embedded Web applications,‎ 2009, 89 - 98 p. (ISBN 978-1-4244-5124-1, ISSN 1550-4441, lien DOI?)
  • (en) Simon Duquennoy, Gilles Grimaud et Jean-Jacques Vandewalle, The Web of Things: Interconnecting Devices with High Usability and Performance,‎ 2009, 323 - 330 p. (ISBN 978-1-4244-4359-8, lien DOI?)
  • (fr) M. Cherki, « Un Français sur trois saisit son smartphone dès le réveil », Le Figaro,‎ 2012
  • (en) C. Fortuna, M. Grobelnik, « The Web of Things »,‎ 2012
  • (en) E. Wilde, « Putting Things to REST », School of Information, UC Berkeley,‎ 2007, p. 1-13
  • (fr) R. Costello, Stéphane Lavirotte, « Cours Applications réparties, REST - Université Nice Sophia Antipolis »,‎ 2010
  • (fr) W3C, Hugo Haas, « From SOAP/1.1 to SOAP Version 1.2 in 9 points »,‎ 2003
  • (en) T. Hayes, « The Full Cost of Cargo Losses »,‎ 2004

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]