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 social, le Web physique^{[note 1]}, le Web sémantique, le Web temps réel^{[note 2]} et le Web programmable^{[note 3]}.

Le Web des objets est représenté par l'intersection de ces cinq tendances et est proposé comme une évolution du Web qui s'étend dans le monde physique^[7].

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)^[7]. 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)^[8].

En dehors des serveurs et des navigateurs, divers objets sont connectés au Web^[9], tels que des entrepôts (chaque section contient des balises RFID permettant le suivi d'objets^[10]). Grâce à la prolifération (1,1 milliard en 2012^[11]) des smartphones avec capteur GPS^{[note 4]} 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^[12].

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ées et indexées par des moteurs de recherche, ou même d'élaborer des langages sémantiques tels que OWL ou RDF^[12]. Le Web sémantique vise à permettre à des agents logiciels à partager, réutiliser ou combiner des informations disponibles sur le Web^[13].

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^[12].

Un moteur de recherche pouvant agréger toutes ces données rapidement a été créé pour le Web des objets^[14].

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 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^[12].

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^[15].

Sur le Web, l'identification d'une ressource se fait par une représentation URI. 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^[16]. 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^[16].

Les applications utilisant des objets intelligents peuvent avoir besoin d'être abonnées aux différentes informations relatives à l'objet ou à l'ensemble des objets qu'elles utilisent^[17]. Avec Atom Publishing Protocol, le Web possède un modèle standardisé et RESTful pour interagir avec des collecteurs d'information ; le protocole Atom 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^[18].

Le Web des objets définit 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.

Historiquement, ce sont XML-RPC (en 1998) puis SOAP (en 1998 également) 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. JSON-RPC (en) apparait en 2005.

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^[19]. 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^[20] 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 apparaît 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.

L'idée centrale de REST est axée 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^[21].

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^[15]. Une autre priorité de REST est la communication simple point-à-point via HTTP en utilisant les formats tels que JSON^{[note 5]} ou encore XML^{[note 6],[22]}.

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 chiffrement, la scalabilité et la mise en cache^[23].

pREST décrit comment utiliser REST pour interconnecter des ressources dans les applications SEC (système embarqué connecté)^{[note 7]}. 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)^[25].

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^[25].

Dominique Guinard définit les objets intelligents (en)^{[note 8]} comme des objets du monde réel doués d'une capacité de communication^[26]. Ils sont également appelés « objets connectés », « objets communicants » ou « objets acteurs »^[27].

Les objets intelligents sont généralement limités en puissance (CPU, RAM, mémoire flash, énergie). Typiquement, sur 1 cm², on trouvera un microprocesseur, très peu de RAM (quelques milliers d’octets), un peu de mémoire flash (quelques douzaines de kibioctets), des interfaces et un module radio fréquence^{[note 9]} ou CPL^{[note 10]}. 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 cinq à dix 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.)^[28].

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^[26].

Les années 2010 marquent l'explosion du nombre d'objets connectés en circulation. En effet, la démocratisation des smartphones suscite la création d'un grand nombre d'accessoires en tout genre en vue de rendre la connexion de chacun toujours plus optimale. En ce sens, le lancement de la Samsung Galaxy Gear en 2013, puis de l'Apple Watch en 2015 et des nombreuses montres connectées qui suivirent, illustre la volonté des grands constructeur de faire de chaque objet du quotidien une plateforme de connexion potentielle.

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 11],[29]}. Il existe une quantité de systèmes embarqués connectés, en voici quelques-uns :

• Exemples de Systèmes Embarqués Connectés :
•  
  Sun SPOT.
•  
  Arduino.
•  
  Karotz.
•  
  Chumby (en).
•  
  Raspberry Pi.

• Sun SPOT, Arduino, Gumstix (en) et Raspberry Pi illustrent principalement la facette Web programmable du Web des objets
• Karotz et Chumby (en) sont deux exemples d'intégration au Web Social

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^[30]. Le comité IEEE^{[note 12]} 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^[31].

Le qualificatif intelligent pourrait quant à lui se justifier par les facultés suivantes^[30]. 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^[32] : connaître, s’adapter aux situations, communiquer.

Dans le Web des objets, le capteur intelligent se décompose donc ainsi^[33] :

• un ou plusieurs transducteurs ;
• 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.

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-*^[34],[35]. 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^[35]. 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^[35],[34]… 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^[35].

Le nom de EPCIS-Restadapter désigne ce nouveau^[Quand ?] 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 EPC). C'est de ce fait une opportunité pour créer une plus grande communauté de développeurs utilisant les EPCIS et leur API RESTful et ainsi assurer leur avenir dans l'Internet/Web des objets ou dans les prototypes et appareils mobiles^[36].

Le but du Web des objets étant d’amener le maximum d’objets intelligents au plus proche du Web^[37], 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^[38]. 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^[38].

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^[38].

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^[38],[39]. 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^[38],[39].

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)^[40]. 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)^[40].

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

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é^[42]. 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^[43]. 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 »^[42].

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^[44].

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^[45].

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)^[46]. 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)^[46].

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^[47]. 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^[48].

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^[47]. La contrepartie 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 côté serveur^[48].

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 sept kilooctets de mémoire EEPROM pour fonctionner^[49]. 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^[50].

Les objets intelligent peuvent être intégrés dans le Web de deux façons : soit directement connectés au Web, soit à travers un intermédiaire, le proxy^[51].

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 plates-formes embarquées supporteront les connexions TCP/IP, notamment grâce au protocole 6LoWPAN^{[note 13]}. 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^[51].

Cependant, pour un grand nombre d’objets intelligents, il n’est parfois pas souhaitable d’y accéder de manière directe^[52]. 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^[52]. C'est généralement le cas des réseaux de capteurs sans-fil^[53]. 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^[53].

Les proxy inverse 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^[53].

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^[26]. C'est un serveur Web^[51] 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 14]}…)^[54].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^[54].

De nombreux systèmes ont été proposés pour intégrer des systèmes de capteurs à Internet, tels que SenseWeb, Pachube^[55]… 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^[56], les objets intelligents sont considérés comme des acteurs passifs qui sont seulement autorisés à transmettre des données^[57]. 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^[56].

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 15]}(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^[37]. En d'autres termes, mélanger les services du monde réel avec le monde virtuel^[58]. C’est la raison pour laquelle Dominique Guinard a 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^[37]. 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^[59].

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 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^[60].

À Singapour, le projet WaterWise^[61] a consisté à placer des capteurs sur les conduites d’eau pour surveiller en temps réel la pression et la température, ainsi qu'à analyser la composition chimique et biologique de l’eau. Cela a permis 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^[62], a construit, en partenariat avec la ville, un centre d’opération^[63] qui fonctionne indépendamment de tout organisme tout en recevant des données de plusieurs d’entre eux.

En France, le projet MolluSCAN eye, développé par le CNRS et l'université de Bordeaux, utilise la capacité d'animaux à « goûter » la qualité de l'eau en continu pour surveiller en temps réel des milieux aquatiques à travers le monde^[64]. Il utilise des huitres ou d'autres bivalves, équipés d'électrodes électromagnétiques légères, comme sentinelles pour poser des diagnostics en ligne sur la santé de sites marins distants allant de l'Arctique aux tropiques.

Mother, créé par la société française SES.SE, a été présenté au salon CES 2014, et est capable de transformer n'importe quel objet ou accessoire de la maison en objets connecté (brosse à dent, boite de médicaments, arrosoir pour les plantes…)^[65].

Le compteur Linky d'Enedis est quant à lui capable de surveiller la consommation électrique en quasi temps-réel d'une habitation ainsi que les potentielles pannes l'affectant. D'autres dispositifs ne nécessitant pas un changement de compteur existe comme le capteur Luko Elec de la start-up Luko^[66],[67].

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, de tracer les marchandises avec des balises RFID et des capteurs, de détecter les évènements qui affectent la cargaison, tel qu'un retard dû à la météo, et ainsi réduire les dégâts en réacheminant la cargaison^[68],[69]. SenseAware^[70] permet au consommateur d'avoir des informations sur la cargaison.

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^[71].

En 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^[72].

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)^[72].

En 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^[73].

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

En 2009, S. Duquennoy met en œuvre un d’un système d’exploitation dédié au support d’applications web en environnement contraint d’un nouveau genre (Smews)^[74].

En 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…)^[46].

Le tableau suivant récapitule l'évolution du Web, du Web 1.0 au Web des objets^[75].

Dans l'Union européenne, la Commission européenne présente dès le 18 juin 2009 une communication qui expose les perspectives et les enjeux de son développement^[76]. Elle traite en premier lieu de la définition, de la présentation des applications actuelles et des enjeux d'une gouvernance publique^[77]. 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)^[78]
• la liberté pour un individu de pouvoir se déconnecter d’un réseau à tout moment^[79].

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^[80].

D'autre part, les aspects géolocalisation et protection des données donnent lieu à de nombreux débats entre experts^[81].

Les législations locales peuvent imposer ces impératifs de sécurité et protection des données. Par exemple, en France, selon l’article 226-17 du Code pénal, le non-respect de l’obligation de sécurité imposée à tout traitement de données à caractère personnel est sanctionné de cinq ans d’emprisonnement et de 300 000 euros d’amende. Lorsque c’est une personne morale qui est en cause, l’amende peut être multipliée par 5.

La FTC émet régulièrement des recommandations détaillées à l'intention des entreprises du Web des objets (the Internet of Things)^[82].

• (en) D. Guinard, A Web of Things Application Architecture : Integrating the Real-World into the Web (thèse de doctorat en science), ETH Zurich, 2011, 1-225 p. (lire en ligne [PDF])
• (en) V. Trifa, Building Blocks for a Participatory Web of Things : Devices, Infrastructures, and Programming Frameworks, 2011, 1-154 p. (lire en ligne [PDF])
  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 [PDF])
• (en) C. Pfister, Get Started with the Internet of Things, 2011, 1-42 p. (ISBN 978-1-4493-9357-1, lire en ligne)
• (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, DOI 10.1109/IOT.2010.5678452)
• (en) T. Berners-Lee, « The Future Web », ERCIM News,‎ 2008, p. 1-64 (ISSN 0926-4981)
• Instituts Carnot, Livre blanc des instituts Carnot, 2014, 1-48 p. (lire en ligne [PDF])
• (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, DOI 10.1109/iThings/CPSCom.2011.165)
• (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, DOI 10.1109/ICPADS.2011.10)
• (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, DOI 10.1109/INSS.2009.5409925)
• (en) L. Gao, C. Zhang et L. Sun, RESTful Web of Things API in Sharing Sensor Data, 2009, 1-4 p. (DOI 10.1109/ITAP.2011.6006157)
• (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, DOI 10.1109/ICESS.2009.13)
• (en) Leonard Richardson et Sam Ruby, RESTful Web Services, O'Reilly, 2007, 299–314 p. (ISBN 978-0-596-52926-0 et 0-596-52926-0, lire en ligne)
• (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, DOI 10.1109/ICSC.2008.51)
• Commission Européenne, L'Internet des objets, EUR-Lex, 2009 (lire en ligne [PDF]), 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. (DOI 10.1109/TCE.2003.1261201)
• (en) F. Lewis, Wireless Sensor Networks : Smart Environnements : Technologies, Protocols and Applications, 2005, 1-18 p. (DOI 10.1002/047168659X.ch2)
• (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 (DOI 10.4304/jcm.6.6.424-438, 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, DOI 10.1109/CHINACOM.2007.4469525)
• (en) Dominique Guinard, Vlad Trifa et Eric Wilde, Towards the Web of Things : Web Mashups for Embedded Devices, 2010 (lire en ligne [PDF]), 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 [PDF]), 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, Paris, Hermès, 1993, 166 p. (ISBN 2-86601-382-4), p. 166
• (en) Randy Frank, Understanding smart sensors, 2000, 269 p. (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 [PDF]), 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 [PDF])
• (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 [PDF]), 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, docx (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^o 16,‎ 2011, p. 55-62 (ISSN 1538-7305, DOI 10.1002/bltj.20485, lire en ligne [PDF])
• (en) A. Pintus, D. Carboni et A. Piras, Paraimpu : A Plateform for a Social Web of Things, 2012 (DOI 10.1145/2187980.2188059), 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, DOI 10.1109/IOT.2010.5678447)
• (en) S. Hadim, Middleware : middleware challenges and approaches for wireless sensor networks, 2006, 1 - 23 p. (ISSN 1541-4922, DOI 10.1109/MDSO.2006.19)
• 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, DOI 10.1109/WSE.2009.5631249)
• (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, DOI 10.1109/ICESS.2009.13)
• 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
• R. Costello, Stéphane Lavirotte, « Cours Applications réparties, REST »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)} [PDF], Université Nice Sophia Antipolis, 2010
• 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

• (en) « Lien sur le blog WebOfThings.org »

•   Portail d’Internet
•   Portail du Web sémantique
•   Portail de l’informatique
•   Portail de l’électricité et de l’électronique