dobjets connectés en entreprise - · par une application mobile, ... de l’optimisation du code...

Compagnie IBM France

17 avenue de l’Europe

92275 Bois-Colombes Cedex

Téléphone : +33 (0)1 58 75 00 00

1


Société par Actions Simplifiée au capital de 657.364.587,00 Euros

Siège Social : 17 avenue de l’Europe

92275 Bois-Colombes Cedex 552 118 465 RCS Nanterre

Siret 552 118 465 03644 - Code NAF 6202A

Bonnes Pratiques pour réussir ses Projets

d’Objets Connectés en Entreprise

Cas d’Usage et Principes d’Architecture

Version 1.6

Serge Bonnaud - Analytics Architect - IBM France

[email protected] + 33 6 14 21 01 57

IBM France, Février 2016

mailto:[email protected]




Téléphone : +33 (0)1 58 75 00 00

2





Siret 552 118 465 03644 - Code NAF 6202A

Contents Les objets connectés et l’internet des objets : Préambule .......................................................... 4

L’internet des objets : Une définition .................................................................................... 4

Les objets connectés : Pourquoi ? .......................................................................................... 6 De l’objet connecté au service en passant par la donnée... ........................................................ 7

Valorisation des données ....................................................................................................... 8 Chaine de transformation de la donnée ................................................................................ 10 Nature du lien entre Internet des objets, Big Data et Analytics ........................................... 11

Objet Connecté et Capteur intelligent .................................................................................. 13 Mettre au point la chaine de transformation de la donnée ....................................................... 16

Décodage de la donnée brute ............................................................................................... 18 Amélioration de la qualité de la donnée .............................................................................. 18 Etude des corrélations .......................................................................................................... 19 Traitements Analytiques ...................................................................................................... 22

Analyse prédictive ........................................................................................................... 22 Analyse géospatiale avancée ............................................................................................ 24

Assemblage des Services ..................................................................................................... 26

API Management ................................................................................................................. 29 Ouverture vers les traitements Cognitif ............................................................................... 30

Le service en tant que produit .................................................................................................. 32 Bénéfices attendus d’une Approche Services ...................................................................... 33 Catégorisation et Typologie des Services ............................................................................ 34

Notion de micro-service ....................................................................................................... 35 Synthèse : Réussir son virage vers l’Internet Des Objets ........................................................ 38

Le Business Model : des objets connectés aux services connectés ..................................... 38 Cas d’usage .......................................................................................................................... 39

Plate-forme ........................................................................................................................... 39 Gouvernance ........................................................................................................................ 41

Figure 1 : Les dimensions variées de l’IoT ................................................................................ 6 Figure 2 : Les nouvelles opportunités apportées par l’IoT ........................................................ 7 Figure 3 : Méthode IBM Design Thinking ................................................................................ 9 Figure 4 : Les liens entre IoT, Big Data et Analytics .............................................................. 13

Figure 5 : Gestion d’un dossier sinistre assurance avec les services Cognitif Watson ............ 15 Figure 6 : La chaine continue de transformation de la donnée ................................................ 17 Figure 7 : Véhicules Connectés : Service d’agrégation pour la détection de pollution ........... 21 Figure 8 : Analyse descriptive : Pilotage d’une usine en temps-réel ....................................... 23

Figure 9 : Analyse Prédictive : Pilotage d’une usine : Prédictions des pannes ....................... 24 Figure 10 : Calcul ‘intelligent’ d’itinéraire de délestage ou d’évitement ................................ 25 Figure 11 : Assemblage rapide et visuel des services (NodeRed) ........................................... 26

Figure 12 : Catalogue de services BlueMix ............................................................................. 28




Téléphone : +33 (0)1 58 75 00 00

3





Siret 552 118 465 03644 - Code NAF 6202A

Figure 13 : Visualisation des données en temps-réel (service BlueMix)................................. 29 Figure 14 : Reconnaissance de Patterns dans les flux vidéo .................................................... 31 Figure 15 : Application à base de Micro-Services ................................................................... 37 Figure 16 : Plate-forme IoT for Automotive ............................................................................ 40

REMERCIEMENTS Je tiens à remercier pour ses relectures attentives et pertinentes mon collègue Christophe

Didier, IBM Smarter Cities Technical Leader, passionné par les sujets d’innovation,

toujours enthousiaste et porteur d’expériences concrètes menés sur de nombreux projets

Smarter Cities et IoT.




Téléphone : +33 (0)1 58 75 00 00

4





Siret 552 118 465 03644 - Code NAF 6202A

Les objets connectés et l’internet des objets : Préambule

L’internet des objets : Une définition

Depuis quelque temps, les objets connectés sont devenus incontournables dans notre vie

quotidienne. Tout le monde, du particulier aux entreprises, ne cesse d’évoquer ce sujet. Chacun

cherche à en savoir plus sur ce nouveau marché en plein essor.

Presque quotidiennement, une annonce dans la presse est faite dans ce domaine. Les innovations

sur ce marché très dynamique sont en effet nombreuses, et suscitent un intérêt de plus en plus

grandissant, des médias aux entreprises, en passant par chacun d’entre nous.

Les objets connectés se sont ainsi progressivement intégrés dans nos habitations, nos véhicules, nos

lieux de vie et de travail. Nous les portons parfois sur nous et deviennent des wearables. Nous

interagissons continuellement avec eux, jour et nuit, sans parfois d’ailleurs nous en apercevoir, ou

en être vraiment conscient.

Ceci dit, si l’on fait un léger retour dans le passé, depuis le début du siècle, l’humanité a de tout

temps créé des objets, des ‘choses’ de plus en plus modernes et connectées, que cela soient des

machines, des véhicules, des systèmes, des usines, des pièces ou des équipements industriels.

Depuis longtemps, l’homme a réussi à faire communiquer tous ces ‘objets’ entre eux, puis à les

piloter à travers de puissants centres de commande et de surveillance dont l’objectif a été de

coordonner les activités liées à ces objets (Exemple : Centre de Supervision Urbain pour CSU, Air

Traffic System pour ATS, centre de contrôle ferroviaire, ..)

Par la suite, l’objet connecté le plus célèbre, l’ordinateur, a été relié à d’autres ordinateurs et a

constitué les fameux centres de traitement automatisé de l’information, pour reprendre un terme

employé dans les années 1950. Ces centres sont devenus par la suite des Datacenter répartis sur la

planète et la puissance de calcul a été démultipliée.

Pour connecter ces ‘choses’ ou ces ‘objets’, les moyens techniques n’ont cessé d’évoluer, des plus

rudimentaires aux plus sophistiqués. Certains feraient d’ailleurs sourire de nos jours : signal radio,

Morse, Radio-Télégraphe ont été utilisés jusqu’au milieu du 20ème siècle pour communiquer entre

navires ou avions, puis les modems et le réseau téléphonique commuté entre ordinateurs vers les

années 1980.

Dans le domaine ferroviaire en 1950, certains modèles de trains étaient déjà capables d’émettre des

données grâce aux premiers équipements de signalisation sur les voies. La liaison mécanique entre

le matériel roulant et le sol était d’une certaine manière déjà ‘communicante’.




Téléphone : +33 (0)1 58 75 00 00

5





Siret 552 118 465 03644 - Code NAF 6202A

Pour donner un autre exemple dans le domaine spatial, en 1977 l’ordinateur des sondes Voyager

utilisait 512 Ko de mémoire, ce qui est bien peu aujourd’hui, et une liaison modem débitant

quelques dizaines de bits par seconde. Ceci dit, notre sonde, comme notre train précédemment,

était déjà elle aussi connectée.

Les progrès aidant, la connectivité, les performances des réseaux, les capacités de calcul n’ont cessé

de s’améliorer et les technologies ont progressé à vitesse exponentielle : systèmes SCADA en usines,

automates bancaires, avions connectés en liaison satellite, atelier flexibles connectés, robots pilotés

par une application mobile, véhicules connectés, réseau Internet et Téléphone avec nos milliards de

devices connectés à ce jour.

Si l’on lit la définition que donne Wikipédia de l’Internet Des Objets, on apprend qu’il s’agit d’arriver

à faire parler entre-eux des objets qui ne l’étaient pas auparavant, et de la même manière que si ils

étaient connectés à Internet.

Cette définition est simple et claire mais elle mérite d’être complétée. Certes l’apparition des

devices intelligent, l’augmentation de la puissance des réseaux de télécommunication et des

capacités de calcul informatique sur la planète, sont clairement des moteurs de l’Internet Des Objets

et permettent.

Mais au-delà de la technologie, l’Internet des Objets est aussi un facteur d’accélération du

phénomène d’Uberisation en permettant aux professionnels et aux clients de se mettre en contact

direct, de manière quasi-instantanée, et cela grâce à l'utilisation de nouvelles technologies.

L’Internet des Objets a introduit aussi le phénomène de Fog Computing. Dans le Fog Computing, une

partie des traitements sont hébergés à la périphérie du réseau ou même sur des dispositifs

intermédiaires tels que les passerelles, box ou points d'accès. Ainsi, le Fog Computing réduit le

temps de latence, soulage les plate-formes hébergées dans les Cloud et au final améliore la qualité

de service globale.

Cette nouvelle architecture de traitements, plus répartie et décentralisée que dans les systèmes

centraux, change l’approche en matière de politique de sécurité. De nouvelles menaces apparaissent

et il faudra réfléchir à sécuriser chaque point d’accès de la chaine de transformation.

En revanche, au-delà de la technologie et de tous ces phénomènes, l’objectif métier est bien de

définir la valeur que l’on attend de l’internet des objets et de ses objets de plus en plus connectés,

voire ‘intelligents’ pour certains d’entre-eux.




Téléphone : +33 (0)1 58 75 00 00

6





Siret 552 118 465 03644 - Code NAF 6202A

Les objets connectés : Pourquoi ?

De nos jours la question n’est pas tant de savoir quoi connecter ou comment. En effet, toute ‘chose’

ou objet ou équipement est potentiellement connectable et les moyens ne cessent de progresser,

tant au niveau des processeurs (le monde du silicone), de l’optimisation du code embarqué, du débit

des réseaux (Edge, 2G, 3G, 4G, ..), de l’émergence des acteurs de type simless-card, de l’apport

inestimable du Cloud Computing combiné avec la virtualisation des ressources IT (voir schéma ci-

dessous).

Figure 1 : Les dimensions variées de l’IoT

Ormis les capacités techniques évoluant rapidement (comme on le voit sur le schéma précédent), les

questions structurantes qui émergent de ces sujets sont plutôt les suivantes :

Pourquoi connecter ce type d’objet particulier ?

Pour quels nouveaux usages ?

Pour qui et pour quelle finalité ?

Qu’espère gagner les entreprises ?

Quels sont les impacts sur les méthodes de développement logiciel ?




Téléphone : +33 (0)1 58 75 00 00

7





Siret 552 118 465 03644 - Code NAF 6202A

Quels sont les modèles d’architecture applicative et technique recommandés ?

Quelle organisation humaine et type de compétences sont nécessaires ?

Ce document va tenter de donner quelques éléments de réponse à chacune de ces questions.

Figure 2 : Les nouvelles opportunités apportées par l’IoT

De l’objet connecté au service en passant par la donnée... Les objets connectés, type montre, T-Shirt ou bracelet FitBit, apportent une certaine forme de bien-

être, un service supplémentaire à l’individu, qui décide ou non d’en faire l’acquisition.

Parfois même, l’objet connecté permet de contrôler la santé des individus et d’anticiper des

événements importants, typiquement pour des personnes âgées à domicile, la détection d’un

malaise, d’une chute et le déclenchement d’un appel automatique vers les secours.




Téléphone : +33 (0)1 58 75 00 00

8





Siret 552 118 465 03644 - Code NAF 6202A

De grands acteurs de l’informatique ont réussi à démocratiser et simplifier l’accès aux devices et aux

objets connectés. Certains de ces acteurs centrent leurs innovations sur l’utilisateur final, d’autres

sur l’entreprise, la santé ou la collectivité humaine. Parmi ces noms on trouve Apple, Amazon,

Microsoft, Google, IBM, HP, sans oublier les nombreuses Start-Up qui tous les jours innovent dans ce

domaine de l’objet connecté. Il suffit en particulier de regarder le nombre d’entreprises Françaises

mises à l’honneur au CES à Las Vegas depuis quelques années.

Attardons nous maintenant un instant sur le point de vue de nos entreprises et laissons

momentanément de côté celui du particulier.

Quel que soit le secteur d’activité d’une entreprise, toutes cherchent en effet à bénéficier de

l’information digitale grandissante générée par l’environnement dans lequel elles opèrent, voire de

créer des objets communicants.

Ceci dit nos entreprises possèdent déjà une quantité astronomique de données sur leurs clients,

leurs produits et leurs usages, accumulés depuis des années. La question est donc bien de savoir

comment gérer les données existantes avec les données émises par les objets connectés.

En fait, une partie de la réponse réside dans les rapprochements judicieux à réaliser entre ces deux

univers de données, l’un pouvant être vu comme une extension du précédent. Aujourd’hui l’IoT

permet d’ouvrir et fluidifier l’information.

Les objets connectés ou les réseaux sociaux auront tendance à produire de la donnée non-structurée

alors que l’existant des référentiels de données est plutôt de type structuré.

Identifier les rapprochements pertinents pour le métier, corréler ensemble les données structurées

et non-structurées, comprendre ces corrélations dans leur contexte et prendre une décision

appropriée est le réel enjeu de l’Internet Des Objets.

Ces corrélations passe par l’utilisation des Analytiques Avancées et de la Data Science, ces fameux

traitements à la frontière du Big Data, des mathématiques et du Cognitif.

IBM a investi en particulier de manière spectaculaire dans le cognitif et mis sur le marché de

nombreuses innovations en 2015 avec sa division IBM Watson : http://www-05.ibm.com/fr/watson/

Valorisation des données

Avant d’évoquer les moyens d’analyser les données, une première mise en garde s’impose. En effet,

il ne faudrait pas que nos entreprises deviennent ‘addictives’ à la donnée et accumulent de grands

volumes dans ces fameux lacs de données (Data Lake), en pensant découvrir à posteriori un ‘service’

innovant auquel personne n’aurait encore pensé. Les choses se passent rarement de cette manière.

Il est en effet illusoire de vouloir stocker et analyser tous les flux de données, même avec les

traitements analytiques les plus aboutis.

http://www-05.ibm.com/fr/watson/




Téléphone : +33 (0)1 58 75 00 00

9





Siret 552 118 465 03644 - Code NAF 6202A

Cette approche du ‘tout stocker’ ne fonctionne pas car les Analystes et les Data Scientist vont se

trouver submergés par le volume accumulé. Ils risquent également de rencontrer des problèmes

inattendus de qualité de la donnée qui épuisent et découragent les organisations.

De plus ils ne sont pas forcément les mieux placés pour proposer ces fameux services innovants, le

rôle du Marketing et du Product Management restent prépondérant pour identifier les nouveaux

services. Ces derniers devront travailler en coopération étroite avec les Data Scientist.

A ce titre, il me semble important de privilégier, ce que l’on appelle de nos jours un dispositif

d’Incubation permettant de favoriser la collaboration étendue et l’innovation coopérative. En

particulier je recommande des séances de brainstorming sur les données et les services auxquelles

devront participer Analystes Métier, Data Scientist, Analystes Donnés et équipes Marketing.

En gérant mieux la relation entre les données existantes et les celles provenant des objets

connectés, nos entreprises arriveront ainsi à proposer de nouveaux services digitaux à leurs clients

en complément de leurs produits traditionnels.

Des méthodes de conception agiles telles qu’IBM Design Thinking mise en œuvre à l’IBM Studio

http://www.ibm.com/design/thinking/ – cf. figure ci-dessous, sont adaptées à la conception de ces

services digitaux.

Figure 3 : Méthode IBM Design Thinking

http://www.ibm.com/design/thinking/




Téléphone : +33 (0)1 58 75 00 00

10





Siret 552 118 465 03644 - Code NAF 6202A

En effet, les équipes de l’IBM Studio mettent en œuvre une méthode brevetée par IBM : l'IBM

Design Thinking. Elle s'inspire de la technique du Design Thinking conceptualisée dans les années

1980 par l'université américaine de Stanford. Basée sur une synthèse entre pensée analytique et

pensée intuitive, elle a été complétée par IBM par des notions liées aux méthodes agiles.

D’un point de vue métier, ces nouveaux services peuvent contribuer à une stratégie de

diversification, de fidélisation, de changement de Business Model ou de ventes croisées. Tout

dépend de ce que l’entreprise cherche à obtenir en lançant sur le marché des services digitaux basés

sur les objets connectés.

Le facteur temps ajoute une contrainte à l’étape de valorisation de la donnée. La rapidité de mise sur

le marché des nouveaux services est déterminante pour la réussite des projets Internet Des Objets.

Les services doivent être développés rapidement, les données comprises et exploitables, et cela avec

le niveau de qualité attendue par des consommateurs de plus en exigeants.

Chaine de transformation de la donnée

Tout le monde aura compris que la donnée est intimement liée au service qui va la valoriser, la

transformer et l’exposer aux utilisateurs.

Quand on parle de donnée dans un contexte Internet Des Objets, il est important de préciser le sens

que l’en entend faire tenir au terme ‘donnée’. Le propos dans cet article est de différentier la

donnée brute de la donné transformée.

Entre ces deux points sémantiquement éloignés, une chaine de transformation temporelle va

s’opérer entre les données brutes émises par les objets connectés, jusqu’aux données transformées

exposées aux futurs consommateurs.

Cette chaine de transformation de l’information est extrêmement puissante. La donnée

transformation sera considérée comme une information avec toute sa sémantique associée, son

sens métier, son sens pour l’entreprise, pour le particulier, pour le malade, pour l’agriculture, pour le

médecin, le pilote, le conducteur etc.

Nous pourrions aisément opérer l’analogie avec la pyramide de la complexité dans le domaine du

vivant, depuis les atomes individuels et les bactéries jusqu’aux assemblages de molécules simples,

complexes, acide aminés et protéines.

Pour donner une seconde analogie « simpliste », la donnée brute pourrait être considérée de nos

jours comme une forme de pétrole non-raffiné. En contrepartie, la donnée valorisée serait ainsi

perçue comme une forme de pétrole raffiné.




Téléphone : +33 (0)1 58 75 00 00

11





Siret 552 118 465 03644 - Code NAF 6202A

Certes on pourrait rétorquer que la donnée ne se tarie pas dans les entreprises, contrairement au

pétrole sur la terre. Mais une chose est sure, dans les deux situations, il faudra creuser de plus en

plus profond pour en tirer la valeur maximale.

Nature du lien entre Internet des objets, Big Data et Analytics

Selon moi, il ne faut pas chercher systématiquement à faire un lien entre ces trois domaines. Par contre il existe des projets et des initiatives dans lesquels un certain nombre de ces domaines sont amenés à cohabiter ensemble.

Selon que le projet Internet Des Objets intègre ou non une dimension Capteurs, Big Data, Analytique ou Mobilité, les patterns d’architecture et les solutions seront différents.

Dans le monde du Big Data, l’habitude est de traiter de manière performante et rapide un volume considérable de données non-structurées, parfois avec de fortes contraintes temps-réel. Dans l’Internet Des Objets, la volumétrie n’est pas toujours importante, et parfois les capteurs transmettent peu de données avec une fréquence faible.

Prenons l’exemple de votre compteur d’eau, il n’y a pas si longtemps que cela, un technicien venait une fois par an relevé votre index de consommation. Puis pour améliorer la prédiction de consommation et mensualiser votre facture, deux visites annuelles ont été nécessaires. Cela fait 100% de données supplémentaires certes mais cela reste une fréquence de 2 fois par an !

Avec le compteur d’eau connecté via réseau radio et énergie embarquée (type pile de montre), l’index est relevé 2 fois par jour. On est donc sur du temps-réel quotidien au lieu d’annuel : l’IoT permet ce changement d’échelle et donc de changer les possibilités de business : relation client améliorée, détection de consommation anormale ou suspecte.

Une fréquence plus élevée permettrait de continuer et de changer encore le domaine des possibles : détection de fuites mais aussi détection d’absence d’où un lien avec la sécurité de ce genre d’information anodine a prime abord qui pourrait être utilisée à des fins beaucoup plus malveillantes. Bref le temps réel est un mélange entre le besoin métier et ce que la technologie est capable d’apporter avec une réalité économique pour un projet.

De 2 fois par jour à 10 fois par secondes, cela reste du temps-réel valable et approprié à certain domaines métier … et uniquement sur 3 valeurs : index d’eau, horodatage, numéro de compteur.

En fait tout dépend de l’objet connecté. Si l’on parle d’un véhicule moderne qui transmet plus de 1000 données brutes à la seconde depuis son CANBUS (https://en.wikipedia.org/wiki/CAN_bus), il y a de fortes chances que les dimensions Big Data et Temps-Réel du projet soit prépondérante.

Si l’on parle d’une sonde météorologique montée sur des toits d’immeuble, le volume de données transmis risque d’être moins important et les contraintes temps-réel moins fortes.

https://en.wikipedia.org/wiki/CAN_bus




Téléphone : +33 (0)1 58 75 00 00

12





Siret 552 118 465 03644 - Code NAF 6202A

La météo ressentie, utilisée et utile pour le consommateur finale ne change pas 1000 fois par seconde, sauf si l’on étudie les éclairs, ni 1 fois par seconde sauf si l’on s’en sert pour fermer une zone non-étanche et fragile via une fenêtre de toit, ni 1 fois par minute sauf si l’on craint le vent et l’envolé d’objets. Bref dans la majorité des cas, un suivi de l’évolution météo entre 1 et 5 minutes paraît être une bonne fréquence.

Pour conclure, cette section va tenter de donner quelques clés pour identifier les domaines de contribution d’un projet Internet Des Objets (IoT).

Tout d’abord, imaginons que le volume, la fréquence, et la nature des données générées par nos objets ‘connectés’ nécessitent de mettre en œuvre une brique de type « lac de données » (Data Lake).

Si ce Data Lake est utilisé pour stocker ces données au fil de l'eau et exécuter à haute performance des traitements analytique, alors la dimension Big Data est avérée et on parlera dans ce cas de Data At Rest.

A ce titre, la solution IBM for Hadoop http://www.ibm.com/analytics/us/en/technology/hadoop/

permet d'implémenter un Data Lake.

Cette dimension Big Data sera qualifiée de temps-réel si les temps de réponse attendus sont contraints, par exemple inférieurs à la seconde. On parlera alors de Data In Motion en complément de Data At Rest.

Dans le cas de temps de réaction attendus proches de la micro-seconde (temps-réel fort), on recommandera l'usage d’un composant de type CEP (Complex Event Processing), telle que la solution IBM InfoSphere Streams http://www.ibm.com/analytics/us/en/technology/stream-

computing/. Le composant CEP viendra s’intégrer naturellement au composant Hadoop.

Si les données sont utilisées dans des traitements plus complexes qu’un simple suivi geospatial d'une flotte d'objets connectés sur une carte, alors le projet possède une dimension analytique dite avancée.

Quand le projet IoT consiste seulement à visualiser sur des cartes des objets en mouvement, remonter des alertes sur ces objets, calculer des tendances simples, on dira que le traitement analytique est simple et de nature géospatiale. Ce type de projet se réfère en général à de la supervision de flottes, plus ou moins temps-réel.

Dans les traitements analytiques avancés, on trouve les analyses de type prescriptif, prédictif ou cognitif (Machine Learning, Natural Language Processing, analyse de la voix..).

http://www.ibm.com/analytics/us/en/technology/hadoop/

http://www.ibm.com/analytics/us/en/technology/stream-computing/

http://www.ibm.com/analytics/us/en/technology/stream-computing/




Téléphone : +33 (0)1 58 75 00 00

13





Siret 552 118 465 03644 - Code NAF 6202A

Enfin si les besoins impliquent de connecter un type d’objet particulier pour exploiter le flux de données dans un traitement analytique, alors le projet possède également une dimension IoT, sinon le projet est seulement du ressort du domaine du Big Data.

A noter qu'IBM investit, innove et fournit d’ores et déjà des services Cognitifs à travers sa solution Watson http://www.ibm.com/smarterplanet/us/en/ibmwatson/

La figure ci-dessous illustre les relations entre les différents domaines, IoT, Big Data et Analytics.

Figure 4 : Les liens entre IoT, Big Data et Analytics

Objet Connecté et Capteur intelligent

Avant de lancer son projet de type Internet Des Objets, il est recommandé de mener une phase

d’étude préalable dans laquelle les moyens de connectivité existants seront analysés.

En sortie de cette étude, on devra déterminer si ces moyens sont suffisants ou non pour couvrir les

traitements analytiques demandés, mais surtout pour atteindre les objectifs métiers fixés.

En fonction des résultats de l’étude, il peut s’avérer nécessaire de prendre un certain nombre

d’actions importantes telles que :

http://www.ibm.com/smarterplanet/us/en/ibmwatson/




Téléphone : +33 (0)1 58 75 00 00

14





Siret 552 118 465 03644 - Code NAF 6202A

développer une nouvelle génération de capteurs, choix stratégique d’entreprise qui doit être

lié aux réflexions sur le Business Model.

améliorer la connectivité existante en impactant au minimum les caractéristiques physiques

ou logiciel de notre capteur (Exemple : passer d’une connectivité Edge à 3G ou 4G, voire

l’inverse généraliser en passant sur des technologies LongRange type LoRa ou Sigfox.

augmenter les capacités du capteur existant à l’aide d’un complément technologique non-

intrusif (Exemple : tag beacon, RFID, utilisation d’un smartphone pour accéder à Internet ou

comme rendu visuel, …)

modifier physiquement (structurellement) l’objet connecté (Exemple : ajout d’un capteur de pression pour mesurer la quantité de gaz restant dans une bouteille de gaz).

opérer des modifications sur le logiciel embarqué du capteur en opérant si possible une mise

à jour du firmware.

Dans le thème de l’objet connecté et du capteur, un point de discussion important doit avoir lieu sur

la part d’intelligence, ou plutôt d’autonomie à attribuer au dit objet. En fait tout dépend de la nature

du cas d’usage mais aussi des capacités intrinsèques du capteur.

Certes, embarquer une partie des traitements analytiques permet de rendre notre objet (par son

capteur) plus intelligent et autonome, mais l’impact n’est pas négligeable sur la maintenance et les

couts de mise à jour.

Si le besoin est de garantir un temps de réaction immédiat ou temps-réel concernant un unique flux

de donnée (Exemple : Déclenchement AIRBAG d’un véhicule), la décision la plus judicieuse est

d’embarquer le traitement à l’intérieur du capteur, dans ce cas le boitier télématique (un ECU

particulier).

En revanche, si le traitement nécessite une corrélation et un rapprochement de plusieurs flux de

capteurs différents, alors il convient probablement de s’appuyer sur une plate-forme analytique

(back-end) pour agréger toutes ces données avant de restituer le résultat.

En général, la réponse est une combinaison de la criticité du service à rendre, des exigences de

performance attendues et des capacités de calcul et de stockage du capteur.

Dans tous les cas, la décision devra être raisonnable et prendre en compte ces trois variables, sans

oublier également les couts de maintenance et d’administration générés par le logiciel embarqué.

Il est intéressant de noter qu’il existe de nos jours des composants logiciel adaptés à l’embarqué, à

savoir des moteurs de règles à faible empreinte ou des agents logiciels se nichant dans les systèmes

d’exploitation (Exemple : Agent de mise à jour pour l’OTA : Over The Air Firmware Update).




Téléphone : +33 (0)1 58 75 00 00

15





Siret 552 118 465 03644 - Code NAF 6202A

Le cas d’usage ci-dessous (sinistre assurance) décrit un exemple de capteur intelligent coopérant

avec une plate-forme analytique (back-end).

Dans cet exemple, l’utilisateur pose une question en langage naturel. Le système, que l’on peut

qualifier dans cette situation de cognitif, analyse la question et propose une réponse adaptée en

utilisant également la voix.

En complément, l’analyse cognitive de l’image du véhicule accidenté permet de déterminer les

dégâts survenus et d’enrichir automatiquement le dossier sinistre.

Cas d’usage : Analyse Cognitive d’une question posée en langage naturel lors d’un sinistre

automobile.

Figure 5 : Gestion d’un dossier sinistre assurance avec les services Cognitif Watson

Dans cet exemple, plusieurs implémentations sont possibles pour répartir les traitements entre

l’objet connecté (ici le téléphone de l’assuré) et la plate-forme de traitement analytique,

représentée par le conseiller clientèle.

En voici une répartition possible :

1. Enregistrement de la voix par le capteur du téléphone et génération d’un fichier audio en local par l’application Assurance s’exécutant sur le téléphone mobile.




Téléphone : +33 (0)1 58 75 00 00

16





Siret 552 118 465 03644 - Code NAF 6202A

2. Transformation du fichier audio généré en son équivalent texte et envoi à la plate-forme analytique dans le CLOUD ou envoie du fichier audio à la plate-forme CLOUD et génération de l’équivalent texte.

3. Traitement Cognitif par la Plate-forme analytique : Analyse sémantique du texte : découverte des concepts et des liens entre concepts. Sélection des actions à exécuter.

4. En fonction de l’action sélectionnée, fabrication et émission d’une réponse adaptée en proposant au conseiller la meilleure réponse à donner à l’assuré.

Dans un mode entièrement automatique sans intervention humaine, on aurait pu envisager de construire la réponse en fichier texte, transformer le fichier texte en fichier audio, puis à la fin du processus envoyer le fichier audio à l’application mobile de l’assuré.

Mettre au point la chaine de transformation de la donnée Apres cette incursion dans le domaine du cognitif, je propose de revenir un instant sur l’une des

tâches les plus délicates des projets IoT, à savoir la transformation de la donnée brute.

Transformer la donnée brute en donnée valorisée, c'est-à-dire exploitable, commercialisable, et

pouvant être consommée par un tiers, n’est pas toujours une mince affaire.

Selon moi, il est important de mettre en œuvre plusieurs étapes séquentielles pour aboutir à une

donnée exploitable. La figure ci-dessous visualise ses étapes ainsi que leurs dépendances.




Téléphone : +33 (0)1 58 75 00 00

17





Siret 552 118 465 03644 - Code NAF 6202A

Figure 6 : La chaine continue de transformation de la donnée

Très souvent, la donnée brute n’est pas lisible par un humain, elle est produite par les systèmes

télématiques des objets connectés, que cela soit un avion, une voiture, un train, un capteur en usine.

Très souvent la donnée brute est de type binaire et très liée à l'équipement physique.

La donnée transformée, quant à elle, sera valorisée à travers les traitements analytiques et restituée

au consommateur par les services de publication (application mobile, interface portail Web, ..).

Elle possède un vrai sens métier pour l’expression finale du service (la partie que verra le

consommateur...), encore faut-il transformer cette donnée correctement en mettant en œuvre un

certain nombre d’étapes et de bonnes pratiques.

Comme visualisé sur le schéma ci-dessous, entre notre donnée brute et notre donnée valorisée va

s’opérer une succession de transformations plus ou moins complexes, dont chaque étape dépendra

de la précédente. Dans les processus dynamiques et temporels (type time series), cette chaine de

transformation ne s’arrête pas et elle devra prendre en compte des phénomènes aléatoires

imprévisibles.




Téléphone : +33 (0)1 58 75 00 00

18





Siret 552 118 465 03644 - Code NAF 6202A

En tout premier lieu, notre donnée brute doit d’abord être décodée, souvent au rythme de sa

production par l’équipement de télémétrie ou le capteur.

De manière à disposer d’une fonction de décodage générique, qui puisse résister aux changements

imposés par la variété des modèles d’objets connectés, une base de règles indépendante du

traitement de décodage sera préconisée.

En effet, une telle base de règles permet de réduire le couplage entre l’étape de décodage

(adhérence au capteur) et les étapes suivantes de transformation.

Décodage de la donnée brute

Les règles de décodage seront sélectionnées en fonction du modèle de l’équipement ou de

paramètres de configuration spécifiques (Exemple : La règle stipule que la donnée brute doit être

extraite à une fréquence temporelle donnée, toutes les secondes, et que la tolérance sur les valeurs

est de 2 %).

En général, il est recommandé que ces règles soient formalisées à l’aide d’une grammaire

standardisée et produites sous forme d’un fichier texte. Ecrire les règles en langage naturel,

directement par les analystes métier, est la situation idéale.

Pour chaque donnée brute, la règle est sélectionnée, comprise et le calcul de décodage est réalisé.

Toutes les informations permettant de réaliser le calcul de décodage sont portées par la règle : la

règle se doit d’être auto-porteuse et autonome.

Une règle peut-être quelque chose de simple, exemple une fonction affine Y = aX + B, ou quelque

chose de plus complexe avec des tests et des variantes de calcul différentes.

Exemple : Prenons le cas d’une fonction affine qui modélise une variable continue de type vitesse, la

variable ‘X’ est la donnée brute générée par capteur, a et b sont des coefficients spécifiques à la

vitesse et ‘Y’ la vitesse réelle mesurée dans une unité compréhensible par un système ou un humain,

typiquement en mètres par seconde ou Km/heure, la formule Y = aX + B constitue la règle qui

permet de calculer une vitesse exploitable à partir d’une donnée brute.

Les règles sont souvent des assets protégés et dépendent très souvent du capteur ou de

l’équipement et de la manière dont le fabriquant a conçu l’architecture du système. Ces

problématiques sont du ressort de la discipline dénommée Ingénierie Système.

Amélioration de la qualité de la donnée

Une fois la donnée brute décodée, une étape d’amélioration de la qualité est en général

nécessaire. Cette étape n’est pas à négliger et est souvent sous-estimée en termes de charge, de

ressources et d’efforts associés.

Suivant les projets, plusieurs types de problèmes liés à la qualité de la donnée peuvent en effet

survenir.




Téléphone : +33 (0)1 58 75 00 00

19





Siret 552 118 465 03644 - Code NAF 6202A

Parmi ceux-ci on peut trouver :

des données manquantes non émises par le capteur.

des données émises ou reçues dans un ordre non attendu.

des données identiques émises plusieurs fois.

des données incorrectes ou fausses au niveau de leurs valeurs.

Des données exactes mais émises ou traitées dans un contexte non attendu.

En effet, les exemples cités ci-dessus peuvent être très pénalisants et amener à la génération de

résultats faux ou incohérents.

Comme expliqué précédemment, la solution passe par la mise en place au plus tôt d’une couche

logicielle spécialisée et chargée d’améliorer la qualité des données.

Le principe en est très simple : cette couche prend en entrée la donnée après décodage, puis produit

en sortie la même donnée mais avec une qualité améliorée afin de ne pas propager en cascade une

sémantique imprécise.

Cette couche est placée en séquence juste après la couche de décodage des données brutes.

Le but de cet article n’est pas d’apporter des solutions à tous les problèmes de qualité pouvant

survenir sur les données brutes. Je propose juste d’illustrer le propos avec un exemple choisi :

Prenons le cas de données dans une trame qui ne seraient pas reçues dans le bon ordre, une

solution consisterait à développer un traitement analytique en temps-réel qui réordonnera les

données de la trame en appliquant des règles de détection d’incohérence et une action correctrice

associée.

Exemple l’évènement FIN d’émission qui arrive avant l’évènement DEBUT d’émission suite à des

problèmes de calage GPS sur un véhicule en mouvement entre les valeurs résiduelles dans le

calculateur embarqué et les valeurs données par les satellites.

Ce type de problème nécessite de mémoriser l’évènement DEBUT et de rechercher ‘en arrière’ dans

la trame pour trouver l’événement FIN en se basant sur l’identifiant du capteur.

Des outils tels que les logiciels CEP (Complex Event Processing) sont adaptés pour résoudre ce type

de difficulté par des traitements spécialisés (suppression de doublons, simulation de données

manquantes, remplacement de valeurs, …).

Etude des corrélations

L’étape suivante consiste à étudier les corrélations (une illustration est donnée sur le schéma ci-

dessus) entre les données d’un même capteur ou entre plusieurs capteurs.




Téléphone : +33 (0)1 58 75 00 00

20





Siret 552 118 465 03644 - Code NAF 6202A

Pour rappel nous faisons l’hypothèse qu’un capteur donné est attaché à un unique objet physique

pouvant se déplacer ou non : Avion, Train, Voiture, Bâtiment, Camion, Bouteille : Avion, train,

voiture, bâtiment, bouteille, machines en usine, …

Dans le cas d’usage ci-dessous, il s’agit d’un gestionnaire de flotte qui supervise une flotte de

véhicule. Les véhicules remontent par télémétrie des données toutes les secondes, dont le taux de

pollution collecté en temps-réel. (On suppose que les véhicules sont équipés d’un tel capteur de

détection de pollution).

Le suivi de la flotte est réalisé sur une zone géographique découpée en octogones de 500 mètres de

côté.

En fonction du nombre de véhicules qui détectent un seuil de pollution anormal et des valeurs

réelles de pollution mesurée, un calcul d’agrégation est réalisé toutes les secondes par octogone de

500 mètres de côté.

Le niveau de pollution agrégé est traduit dans l’exemple ci-dessous par une couleur différente

attribuée au polygone. Lorsque le niveau de pollution revient à la normal, les véhicules notifient le

superviseur (message Air Quality Normal).




Téléphone : +33 (0)1 58 75 00 00

21





Siret 552 118 465 03644 - Code NAF 6202A

Figure 7 : Véhicules Connectés : Service d’agrégation pour la détection de pollution

Un tel service est très intéressant car il change le paradigme naturel lié à la ‘voiture’. Cette dernière

n’est plus considérée comme un moyen de se déplacer mais devient un capteur météorologique

pouvant contribuer à prévenir les pics de pollution.

Un tel service complémenterait les prévisions météo actuelles en apportant un maillage plus fin de

l’analyse de la pollution. On pourrait même envisager de prévoir des évènements localisés tels que

le dégel, l’émergence de brouillard, la présence de plaques de verglas sur le sol, en analysant

simultanément le comportement d’une communauté de véhicules dans un court intervalle de

temps.

Enfin un dernier bénéfice lié à ce changement de paradigme est la capacité de monétiser les

données collectées par le constructeur vers des partenaires offrant eux-mêmes un service de

prévisions de ce type (entretien de l’écosystème).




Téléphone : +33 (0)1 58 75 00 00

22





Siret 552 118 465 03644 - Code NAF 6202A

Est-on sur un phénomène d’Uberisation grâce à cette nouvelle source d’information rendue possible

via l’objet connecté ?

Il en effet très difficile et complexe via des algorithmes mathématique massif de comprendre voire

prédire les dimensions météo sur une matrice hyper fine (de l’ordre de quelques mètres) alors

qu’avec un simple capteur embarqué sur des véhicules communs, l’information est disponible et

suffisamment fiable.

Une voiture n’est plus considérée comme un moyen de transport mais alors comme un moyen

météorologique. Il y a création d’un choc business entre le conducteur du véhicule, son propriétaire,

le constructeur du véhicule, les organismes météo voire les assureurs in fine.

Traitements Analytiques

Une fois la donnée décodée, améliorée au niveau de sa qualité et corrélée, il devient en théorie

possible de l’utiliser sans risque dans des traitements analytiques.

La variété des traitements analytiques est aujourd’hui vaste. En voici une liste non-exhaustive :

Geospatial, Descriptif, Statistique, Prédictif, Cognitif (Machine Learning, Analyse Sémantique du

langage naturel, analyse intelligente de la vidéo ou des réseaux sociaux, de la météo, du contenu

textuel, de la voix …. (Des exemples seront donnés ultérieurement dans ce document).

Il est à noter que des traitements plus traditionnels sont souvent mis en œuvre en même temps que

ces traitements analytiques. L’intégration des deux types de traitement devra être étudiée lors

d’ateliers d’architecture.

Par exemple, en fonction de la consommation d’un service connecté, évaluée par le nombre

d’appels sur une période de temps donnée, on devra calculer un montant à facturer au client, éditer

la facture, gérer les relances, encaisser le paiement de manière sécurisé, saisir les informations dans

les logiciels de gestion du suivi client, estimer des prévisions de consommation, …

L’ensemble de ces étapes est du ressort de l’informatique que je qualifierai de traditionnelle,

représentée par les applications centrales de l’entreprise et les processus associés (ERP, CRM, suivi

des commandes, ..).

A ce stade, la problématique est de clairement réfléchir aux différents points d’intégration entre la

plate-forme analytique et le reste du système d’information de l’entreprise.

Analyse prédictive

Les deux figures ci-dessous illustrent des exemples de tableau de bord utilisés dans le domaine

industriel.

Le premier tableau de bord est du ressort de l’analyse dite descriptive (figure 7) et le second de

l’analyse prédictive (figure 8).




Téléphone : +33 (0)1 58 75 00 00

23





Siret 552 118 465 03644 - Code NAF 6202A

D’un point de vue plus général, les deux tableaux de bord ont pour vocation de surveiller la

production des machines d’une usine incluant l’évolution des tendances des anomalies, les

remontées d’alarmes, l’évaluation globale de l’état de l’usine et de ses machines, le nombre de

pièces en défaut produites, l’estimation du nombre de pièces en défaut à venir, …

Figure 8 : Analyse descriptive : Pilotage d’une usine en temps-réel

Le tableau de bord ci-dessous (Figure 8) est une parfaite illustration d’analyse prédictive sur des

machines en usines fabriquant des pièces : Estimation future du nombre de pièces en défaut par

machines à partir d’un modèle de type régression linéaire et arbre de décision, sélection des

variables prédictives influençant l’apparition des défauts, calcul d’un score de prédiction et

définition des règles par groupes statistiques.




Téléphone : +33 (0)1 58 75 00 00

24





Siret 552 118 465 03644 - Code NAF 6202A

Figure 9 : Analyse Prédictive : Pilotage d’une usine : Prédictions des pannes

Cette approche est en continuité avec la démarche Six Sigma https://fr.wikipedia.org/wiki/Six_Sigma

initiée dans les années 1980/1990 respectivement chez Motorola et General Electric. Cette

démarche reprenant le cycle général défini par W. Edwards Deming, à savoir Plan-Do-Check-Act.

Analyse géospatiale avancée

Nous constatons souvent que les démonstrations concernant les objets connectés ont tendance à

mettre l’accent sur la représentation de points mobiles se déplaçant sur des cartes, les points

représentant la dite ‘chose’ connectée, avion, immeuble, véhicule, capteur ...

Ce type de démonstration se réfère communément à ce que l’on appelle des systèmes ‘geospatial’,

adapté à la supervision sur la terre de flotte d’objets connectés ou aux déplacements de personnes à

l’intérieur de bâtiments (GeoFencing) ou sur des zones géographiques délimitées.

En général ces applications se contentent de remonter des données sur les objets connectés,

visualiser l’objet sur une carte, lancer des alertes en cas de dépassement de seuil et éventuellement

gérer un processus opérationnel de traitement de l’alerte ou de l’évènement.

On parlera tout simplement de traitement analytique simple, et non avancé comme illustré

précédemment dans la section Analyse Prédictive.

Dans l’exemple ci-dessous (Figure 9), le système analytique collecte, décode et enregistre les

données d’une flotte de véhicules en mouvements. Le traitement analytique permet de reconstituer

et visualiser les trajectoires des véhicules sur la carte.




Téléphone : +33 (0)1 58 75 00 00

25





Siret 552 118 465 03644 - Code NAF 6202A

Figure 10 : Calcul ‘intelligent’ d’itinéraire de délestage ou d’évitement

En fait le système va beaucoup plus loin qu’une simple visualisation. En effet, les évènements

considérés comme risqués (accident, risque de verglas, risque huile sur la route, déclenchement Air

Bag, incident sur une route, …) sont aussi détectés et enregistrés soit de manière automatique, soit

de manière déclarative ou par l’analyse des comportements collectifs.

Par exemple, lors de la survenue d’un accident, les véhicules approchant de la zone sont notifiés du

danger et un itinéraire de délestage est proposé.

Cet itinéraire ne sera pas le même pour tous les véhicules concernés, il sera calculé en fonction de la

densité de circulation, des différents itinéraires possibles de délestage et de la décision ou non de les

emprunter par les véhicules notifiés. Le conducteur se verra en effet proposer une liste d’itinéraires

possibles avec un score associé. Chacune des réponses des conducteurs (ou non d’ailleurs) sera prise

en compte dans les propositions suivantes.

En conclusion, les données de positionnement des véhicules ont été rapprochées avec des données

environnementales (état de la route, évènement dynamique temporel tel que l’accident), mais aussi

avec les prises de décision des conducteurs suite aux propositions de délestage.

La gestion de l’évènement a donc fait l’objet d’un traitement analytique que l’on peut considérer

comme ‘avancé’, voire cognitif, puisque tous les véhicules n’ont pas été routés par défaut sur le

même itinéraire de délestage, comme le ferait un système classique.




Téléphone : +33 (0)1 58 75 00 00

26





Siret 552 118 465 03644 - Code NAF 6202A

Il y a ici un lien évident avec le domaine Transport des villes intelligentes (Smarter Cities) qui met en

relation pour des fins d’optimisation (que ce soit en fluidité des déplacements, en baise de pollution,

en sécurisation des mouvements voitures et citoyens …), les phénomènes de météo locale, la qualité

des infrastructures, la densité courante de la population, les transports en commun (pour un report

modal potentiel) et les moyens de transports pilotés par le particulier (voiture, motos, vélos …).

Assemblage des Services

Dans cette étape de développement, les traitements analytiques sont assemblés et exposés sous

forme de services à consommer.

Durant cette association, les traitements sont encapsulés à l’aide d’une interface standardisée,

documentée et portant en général un contrat de service si cela est justifié (Exemple de contrat de

service : Ensemble de règles définissant le temps de réponse du service, le nombre d’appels

maximum que le consommateur s’engage à passer sur une période de temps donnée, et

l’engagement du fournisseur sur sa capacité maximum d’appels à supporter).

C’est cette interface qui sera vue par l’utilisateur ou le consommateur final comme la seule

expression visible de toute la chaine de transformation de la valeur.

Il est recommandé que les traitements analytiques soient eux-mêmes conçus de manières

modulaires, réutilisables, pouvant être idéalement assemblés et configurés de manière dynamique.

Pour développer les services, il est intéressant d’utiliser des méthodes de développement rapide et

visuel proposant un assemblage par câblage des composants ou des micro-services unitaires.

A ce titre, IBM propose sa plate-forme BlueMix en mode Cloud permettant de développer, déployer, superviser et opérer des applications composites, Web et mobile ou pour l’internet des objets.

Les applications réalisées à l’aide de l’environnement interactif BlueMix sont composées visuellement à partir d’un catalogue de services.

Figure 11 : Assemblage rapide et visuel des services (NodeRed)

IBM participe à la communauté Open Source en apportant fréquemment des technologies issues de sa Recherche.




Téléphone : +33 (0)1 58 75 00 00

27





Siret 552 118 465 03644 - Code NAF 6202A

NodeRed est un environnement rapide et simple pour construire ses microflows d’intégration, pour les objets connectés en particulier. Ces flux d’informations conçus, et gérés par la suite, via une interface graphique conviviale génèrent du code NodeJS à base de JavaScript qui sont alors exécutés sur des serveurs NodeJS avec grande efficacité. Cette technologie a été donnée à la communauté Open Source et peut donc être exécutée de l’embarqué sur un simple Rapsberry jusqu’au Cloud. Elle est disponible nativement dans le Cloud IoT IBM.

Le catalogue des services offert par BlueMix est divers, varié et couvre plus de 140 fonctions différentes.

Ce catalogue offre une large gamme de services, dédiés au développement mobile, Web, à l’intégration, à la sécurité, au stockage et incluant également de nombreux traitements analytiques et cognitifs parmi :

Reconnaissance de patterns dans des images et des vidéos,

Analyse sémantique de texte,

Analyse de données Twitter,

Intégration de données de The Weather Company (récente acquisition IBM, service disponible sur BlueMix), Facebook.

Analyse de la voix,

Tableaux de bord de supervision (temps-réel),

Reporting Analytique,

Gestion de cartes et traitement géospatiaux,

Analyse prédictive et prescriptive.




Téléphone : +33 (0)1 58 75 00 00

28





Siret 552 118 465 03644 - Code NAF 6202A

Figure 12 : Catalogue de services BlueMix

La figure ci-dessous représente un service BlueMix permettant de suivre les données de plusieurs objets connectés avec remontée d’alertes et lancement de procédures d’exploitations




Téléphone : +33 (0)1 58 75 00 00

29





Siret 552 118 465 03644 - Code NAF 6202A

Figure 13 : Visualisation des données en temps-réel (service BlueMix)

API Management

Afin de pouvoir être exposés à l’extérieur de l’entreprise, supervisés et administrés, les services sont

gérés par un composant particulier appelé API Management.

Ce composant prend en charge le catalogue des offres et, la gestion des contrats et la supervision

des services, ainsi qu’un module de support à la facturation.

Par exemple, un consommateur pourra appeler un service par l’intermédiaire de son API, depuis une

application mobile, l’application mobile étant déposée sur un Application Store (Apple Store, Google

Play, ..) ou au travers d’un portail utilisateur.

Cette application mobile sera souvent développée en même temps que l’API. L’API et l’application

mobile sont donc vues comme les interfaces d’accès aux traitements analytiques s’exécutant au

niveau du back-end.

Le rôle des applications mobile apparait donc comme très important dans les projets d’objets

connectés. En particulier l’expérience utilisateur et l’interface homme-machine devront être pensées

pour faciliter l’adoption rapide des utilisateurs, de plus en exigeant, et fonctionnant souvent dans

une pensée de l’instantanéité.




Téléphone : +33 (0)1 58 75 00 00

30





Siret 552 118 465 03644 - Code NAF 6202A

Ouverture vers les traitements Cognitif

Comme évoqué précédemment, il ne faudrait pas résumer les projets IoT à de la gestion de cartes et

au suivi d’objets, dont la valeur ajoutée est certes intéressante mais relativement faible. En

l’occurrence, il existe des types de traitements beaucoup plus intéressants qu’un simple suivi

geospatial d’objets en mouvement.

En particulier, nous pensons que les années à venir seront passionnantes avec l’émergence des

approches cognitives, typiquement ce que propose IBM avec sa division Watson.

Dans le monde des objets connectés, les services COGNITIF de la famille Watson consistent à

comprendre des comportements, des situations, de percevoir le sens des choses (analyse de

sentiments), en se basant sur des techniques d’analyse sémantique de l’information et

d’apprentissage (Machine Learning).

En comprenant le sens d’une situation ou le contenu d’une image, d’un texte, il devient alors

possible de prendre une décision adaptée et parfois automatique, s’approchant de ce qu’aurait fait

un opérateur ‘humain’ (ou un analyste).

Le but des approches cognitives n’est pas de remplacer l’humain, de prendre une décision

automatique ou d’imiter le fonctionnement du cerveau.

L’objectif est plutôt de comprendre la sémantique d’un domaine métier (thésaurus, ontologie), puis

de proposer une liste de réponses possibles à des questions posées.

Le système cognitif associe un score de confiance à chaque réponse, puis au fur et à mesure de

l’apprentissage (supervisé ou non), le système devient plus précis et pertinent sur les réponses à

fournir à l’avenir.

Parmi les services cognitifs offerts par Watson, on peut citer le service Questions/Réponses pour

créer des applications capables de comprendre le langage naturel et proposer des réponses ou le

service de reconnaissance visuelle de pattern permettant d’identifier des objets ou des personnes

dans des contextes et situations donnés (cf. figure ci-dessous).




Téléphone : +33 (0)1 58 75 00 00

31





Siret 552 118 465 03644 - Code NAF 6202A

Figure 14 : Reconnaissance de Patterns dans les flux vidéo

Les systèmes Watson deviennent alors des assistants en mode conversationnel avec l’expert humain

responsable du domaine d’activités.

Cela peut couvrir la gestion du trafic routier avec l’analyse en temps-réel de flux provenant de plus

de 1000 caméras ou l’analyse d’imagerie médicale en haute définition. Dans ces deux cas, on

comprend facilement la complémentarité des capacités d’analyse et de fonctionnement entre

l’homme et la machine : calcul analytique, massivement parallèle, distribué, historique et connecté.

Ces assistants, au delà de l’analyse massive, apprennent en permanence et ont la capacité de créer

des « patterns », des analogies, des corrélations, des rapprochements au service de l’expert qui doit

se concentrer sur la validation et la prise de décision in fine.




Téléphone : +33 (0)1 58 75 00 00

32





Siret 552 118 465 03644 - Code NAF 6202A

Le service en tant que produit

Qu’est-ce qu’un service ? Pour comprendre intimement la notion de service, ce qui n’est pas

toujours simple, je propose d’opérer une simple analogie et de revenir tout simplement aux

principes fondamentaux du commerce et d’opérer une comparaison entre un service et un produit

manufacturé.

Historiquement, si l’on prend le domaine du manufacturing, une entreprise vendait des produits ou

des biens associés à une garantie. Dans le cas de produits plus sophistiqués, une entreprise peut

proposer, souvent en s’appuyant sur un tiers sous-traitant, un service d’après-vente ou de support.

Le service autour des objets connectés est par nature digital et numérique. Il offre une valeur

additionnelle en sus du bien ou du produit auquel il est intimement associé.

En effet, les offres et les biens tendant à perdre de leur caractère compétitif dans l’économie

traditionnelle (commeditisation de la valeur), la valeur se déporte vers une expression beaucoup

plus immatérielle et digitale, mais dont les impacts sur le consommateur et le client sont loin d’être

négligeables. C’est l’innovation incrémentale ou la construction destructive qui permet de

maintenir en effet la valeur.

En conclusion, notre entreprise, de par ses nouveaux services ou produits digitaux, devient elle-

même digitale et va devoir opérer une transformation souvent profonde dans toutes ses strates,

direction générale, fabrications, études, commerce, marketing, fonctions support.

Critères de caractérisation des services

Pour pouvoir s’appeler service digital, ce dernier doit vérifier un certain nombre de critères :

Il s’appuie sur des traitements analytiques de la donnée, que cette dernière soit structurée ou non-structurée. La variété des traitements analytiques sera abordée ultérieurement dans cet article.

Il est considéré comme un produit ou un bien, au même titre que les autres biens de l’entreprise. Il peut être dépendant ou inclure lui-même d’autres services, faire l’objet de rangement dans des catalogues, tout comme des produits

Il doit faire l’objet d’un contrat, formalisé, précis et sans ambiguïté entre ces consommateurs potentiels et ces producteurs.

Il doit être tout simplement mesurable et quantifiable aussi bien d’un point de vue métier

que technique. On doit être capable de facturer un service, de mesurer ses ventes, mais aussi sa réputation, son succès, de prévoir son comportement, son échec potentiel, de




Téléphone : +33 (0)1 58 75 00 00

33





Siret 552 118 465 03644 - Code NAF 6202A

mesurer l’évolution de son nombre de consommateurs, et enfin de collecter des données techniques pour garantir sa disponibilité.

Son cycle de vie doit être défini dans chacune de ses étapes. Ce cycle doit avoir été pensé avant de commencer les développements, en particulier le plus grand soin doit être pris pour la gestion des changements du service, depuis sa création jusqu’à sa disparition.

Il est préférable que les services soient pensés pour être personnalisables et configurables. Cette personnalisation doit être relativement aisée, typiquement un service pourra être décliné rapidement par pays, par catégorie de clients cible, par SLA, par période d’applicabilité...

Un service n’est pas seulement une expression digitale d’un traitement sur des données, c’est aussi un ensemble d’éléments opérationnels pour la commercialisation, sa gestion, sa mise sur le marché, sa facturation : Catalogue produit sur le Web, fiches produit, programme de formation du réseau commercial, matériel marketing et de promotions, guides de bon usage, règles légales, contrat sur la propriété des données.

La notion de service doit être intimement et profondément matérialisée à tous les niveaux organisationnels, fonctionnels et techniques. Elle doit être comprise et partagée par tous les acteurs qui manipulent dans l’organisation le catalogue des services.

Il doit être accessible par tous les canaux interactifs actuels : applications Web et Mobiles, sur tablette, Smartphones...

Bénéfices attendus d’une Approche Services

Pour une entreprise, l’enjeu est clair. Comme évoqué précédemment, il s’agit de mieux exploiter les

données dont elle est propriétaire en les rapprochant avec de nouvelles sources de données, dont

celles issues typiquement des objets connectés.

En exploitant l’ensemble de ces données par des traitements analytiques, l’entreprise propose alors

des services ‘digitaux’ à ses clients ou partenaires. Dans ces traitements, notre entreprise pourra

aussi s’appuyer sur des données acquises en Open Data ou acquérir des données supplémentaires

auprès de partenaires ou de clients.

Nous venons de voir qu’un service s’appuie sur un ensemble de traitements analytiques. Une fois

cette association réalisée, ces services sont proposés sous forme de catalogue et feront l’objet d’une

facturation auprès des clients.

Quel que soit le domaine d’activité de notre entreprise, un service est censé apporter une ‘valeur

mesurable’ et perceptible pour une catégorie d’utilisateurs donnée.




Téléphone : +33 (0)1 58 75 00 00

34





Siret 552 118 465 03644 - Code NAF 6202A

Les services contribuent en général à un ou plusieurs de ces objectifs :

Amélioration de la qualité finale des produits ou des biens.

Réduction des couts de fabrication ou d’approvisionnement du produit par l’analyse de données issues des objets connectés.

Revente de données brutes ou valorisées à des tiers partenaires ou à ses clients.

Vente de services au client final en complément du produit ou du bien physique afin d’apporter une valeur innovante et attractive sur ce bien.

Proposition en contexte de produits ou de services complémentaires aux clients existants (up-sell)

Catégorisation et Typologie des Services

Existe-il des catégories différentes de service ? Clairement la réponse est positive.

Pour rappel, un service est une réponse à un besoin fonctionnel et doit correspondre aux attentes

des consommateurs ou des futurs utilisateurs. Très souvent, les consommateurs pourront souscrire

un ou plusieurs contrats attachés à un service. Ce contrat stipulera les conditions d’usage, le respect

des données privées ainsi qu’un niveau de qualité, de support ou de performance attendu. On

parlera ainsi de SLA pour Service Level Agreement.

Les services sont en effet définis par des caractéristiques ou propriétés qui déterminent leur

appartenance à une catégorie. On pourra ranger les services dans plusieurs catégories, par exemple

un critère qui définira la valeur métier apportée et une autre qui définira sa nature fonctionnelle ou

technique ou son niveau de SLA.

Pour rappel, la définition du service adopté dans ce document est la suivante : Un service est une

chaine de transformation séquentielle de plusieurs données brutes vers une donnée de synthèse

exploitable, certaines de ces données brutes étant produites par des objets connectés, d’autres par

des systèmes plus classiques.

Voici un exemple de caractéristiques ou de capacités qui aident à définir les catégories de service en

prenant un point de vue fonctionnel.

la présence de temps-réel pour les notifications et l’émission d’évènements, de message ou d’alertes. Exemple : Un service d’appel d’urgence en contexte émis par un objet connecté, typiquement un véhicule en mouvement en situation de danger : Déclenchement Airbag sur une voiture qui génère un SMS vers un centre d’appel 24*24).

la présence ou non d’un principe de souscription immédiate. Exemple : Supposons un service de géolocalisation de véhicule qui enregistre les positions d’un objet en mouvement, ces positions n’étant pas exploitées en service normal. Lors de la déclaration de vol de




Téléphone : +33 (0)1 58 75 00 00

35





Siret 552 118 465 03644 - Code NAF 6202A

l’objet, le service est notifié et reconstruit (calcul, visualisation, analyse) la trajectoire passée de l’objet avec ses propriétés, et cela juste avant la réception du message de déclaration de vol.

la présence ou non d’un principe de souscription différée : Exemple : La production d’un certificat de bonne conduite pour un conducteur de véhicule, publié une fois par trimestre, en analysant les données de conduite, est considéré comme un service de type souscription différé.

la mise en corrélation entre plusieurs sources de données émanant de plusieurs objets connectés, typiquement le rapprochement des données de N véhicules circulant en même temps.

l’utilisation dans le service de modèles analytiques simples de type géospatiaux (visualisation de points sur des cartes) ou calculs statistiques élémentaires sur les données collectées (moyenne / écart-type des vitesses, températures, rythme cardiaque, données collectées sur des bâtiments, avions, voitures, trains…

• l’utilisation de modèles analytiques avancés issus des mathématiques ou des statistiques, typiquement, des modèles de scoring et de segmentation, de mise en associations, de traductions automatisée, d’analyse sémantique de contenu textuel et linguistique, d’analyse prédictive (C5, CHAID, régression linéaire, ..), Machine Learning et apprentissage (SVM), analyse « Intelligente » de vidéos ou d’images par détection de patterns, ..

Notion de micro-service

Dans un projet d’objet connecté, il est recommandé d’utiliser une architecture à base de Micro-

Services plutôt qu’une architecture traditionnelle monolithique. Mais d’abord définissons ce qu’est

une architecture à base de micro-services.

Comme dans tout projet, les principes d’analyse par les cas d’usage continuent de s’appliquer et

restent vrais.

En complément de l’analyse par les cas d’usage, il est recommandé d’utiliser une méthodologie agile

de projet type SCRUM privilégiant les principes d’itérations, d’incréments et de collaboration entre

tous les membres de l’équipe (Data Scientist, Architecte, Analyste Donnée, Développeur

Analytique) .

De même, la découverte des objets qui réalisent le système par l’étude des scénarios privilégiant

l’étude de la dynamique du système (diagrammes de séquence ou d’interactions) s’appliquent à 100

% (les diagrammes de séquence étant des réalisations instanciées des cas d’usage : cas nominal, cas

d’erreur, branche alternative, ..)




Téléphone : +33 (0)1 58 75 00 00

36





Siret 552 118 465 03644 - Code NAF 6202A

Dans une architecture d’objet connecté, il est essentiel de découpler au maximum les nombreuses

étapes de transformation de la donnée et de privilégier l’asynchronisme dans les échanges inter-

couches et inter-composants.

Le découplage fort apparait vital dans une architecture d’objets connectés en raison de l’écart

naturel et profond qui existe entre les données brutes (le monde des capteurs) et le monde de la

restitution de la donnée transformée.

En effet, si la demande est d’aller extraire une nouvelle donnée pour implémenter différemment un

service, l’impact doit être minimisé sur chaque couche applicative et les interfaces doivent résister

aux changements.

Si cet ajout nécessite de modifier le code de tous les composants dans toutes les couches de

l’architecture, le cout de maintenance de notre solution sera exorbitant et ces évolutions

deviendront quasi impossibles pour suivre le rythme demandé par les utilisateurs.

Une autre raison qui milite pour une architecture à base de micro-services est la durée différente

entre le cycle d’évolution des objets connectés et le cycle de développement des traitements

analytiques et services de restitution (applications mobiles, portails, ..)

Dans une architecture d’objet connecté, les cycles de modification et de développement des

capteurs sont en effet soumis à des contraintes industrielles et opérationnelles parfois fortes qui

amènent à des délais longs pour produire et mettre sur le marché un capteur de nouvelle génération

(certification, mise en conformité, intégration système, gestion du matériel...)

En revanche, les autres composants (décodage, amélioration de la qualité, corrélation, stockage,

analyse temps-réel) ainsi que les composants de publication (applications mobile) sont amenés à

changer plus souvent et suivent des cycles plus agiles. La raison en est essentiellement due à leur

nature logicielle et non matériel.

Dans une architecture d’objet connecté, il sera en général assez aisé d’industrialiser les briques

logicielles (stockage Big Data, Complex Event Processing, …) et valider leurs principes d’intégration.

Cette phase d’industrialisation donne lieu à la mise en place de l’architecture que l’on qualifiera

architecture technique (à différentier de l’architecture physique matérielle).

Ce qui reste plus délicat est de concevoir, au-dessus de l’architecture technique, l’architecture dite

applicative.

En effet les principes traditionnels de développement logiciel ne peuvent plus s’appliquer pour

concevoir l’architecture applicative. Le danger est de développer des applications monolithiques,

peu maintenables et peu adaptées à l’agilité demandée par les projets d’objets connectés.

Afin de maitriser cette dérive naturelle, il est recommandé de décrire les principes d’architecture

applicative ainsi que les solutions à mettre en œuvre par nature de service (cf. section




Téléphone : +33 (0)1 58 75 00 00

37





Siret 552 118 465 03644 - Code NAF 6202A

Catégorisation et Typologie de Service) sous forme de patterns en utilisant un langage de

modélisation graphique tel que UML (Unified Modeling Language).

Par type de service connecté (Souscription Immédiate ou Différée, Temps-réel, Corrélation,

Geospatial, analytique avancé, ..), un ou plusieurs patterns modéliseront la solution et les

dépendances entre les micro-services contributeurs pour l’implémentation.

Idéalement les patterns seront rendus génériques et variabilisés, de manière à pouvoir les instancier

dans des contextes différents. Ces micros-services doivent être idéalement conçus comme étant des

fonctions atomiques, génériques et réutilisables.

A ce titre, un micro-service respecte les principes suivants :

Il implémente une seule fonction. Son interface est documentée et n’expose que des données propres sa réalisation. Il s’appuie sur une communication par évènement en mode asynchrone (de type publication

souscription) pour éliminer les dépendances point-à-point. Il privilégie les protocoles de type REST. Il est un candidat pour devenir une API portant un contrat de service (nombre de sollicitations

maximum, temps de réponse, ..) Il accepte que les données soient décentralisées et réparties dans plusieurs référentiels. Il est testable dès la spécification de son interface.

Figure 15 : Application à base de Micro-Services




Téléphone : +33 (0)1 58 75 00 00

38





Siret 552 118 465 03644 - Code NAF 6202A

Synthèse : Réussir son virage vers l’Internet Des Objets

Cette section a pour objectif de conclure cet article en synthétisant quelques conseils et bonnes

pratiques pour réussir son initiative ou son projet IoT en entreprise.

En résumé, voici les points de discussion que je conseille de parcourir lorsqu’une entreprise décide

de lancer un projet IoT

avoir défini un minimum de cadrage au niveau du Business Model.

avoir documenté et sélectionné un ou plusieurs cas d’usage alignés avec le Business Model.

s’être s’appuyé sur une plate-forme performante de traitement analytique de la donnée.

avoir mis en place un minimum de gouvernance et d’organisation.

avoir défini un processus de développement logiciel agile.

s’être appuyé sur une architecture applicative à base de micro-services.

avoir un minimum réfléchi à la confidentialité de la donnée et à la propriété intellectuelle des services.

Suivant l’ampleur et les objectifs métiers recherchés, l’importance de ces sujets et l’effort à y

consacrer varient lors du projet.

Les sections suivantes donnent quelques clés pour appréhender quelques-uns des domaines listés ci-

dessus.

Le Business Model : des objets connectés aux services connectés

Le Business Model touche à la stratégie de l’entreprise. Il n’est pas obligatoire de le formaliser

complétement pour lancer un projet IoT.

Ceci dit, y réfléchir en avance de phase permet de réduire les risques économiques et surtout de

définir tôt la valeur métier et d’obtenir un consensus de toutes les parties prenantes.

Le Business Model permet de formaliser l’approche marché, équilibrer l’équation économique et

définir les critères de rentabilité. Il est la condition essentielle qui fera qu’un projet d’objets

connectés devienne un projet réussi de services connectés.

Connecter des objets doit permettre au final de proposer un catalogue de services aux

consommateurs et d’augmenter les revenus de l’entreprise. Ne jamais oublier que dans le sujet de

l’IoT, le consommateur ou le client achète un service et non un objet.

La différence est importante, même si l’objet en tant que tel peut faire partie de l’attractivité

marketing auprès du consommateur (Exemple : Le cas du bracelet FitBit qui calcule le nombre de pas

et évalue la qualité du sommeil mais fournit au final un service d’évaluation de de l’activité physique

d’une personne).




Téléphone : +33 (0)1 58 75 00 00

39





Siret 552 118 465 03644 - Code NAF 6202A

Dans cette réflexion il est important de réfléchir à équilibrer les investissements avec les revenus

attendus générés par les services connectés.

Les zones d’investissement vont concerner les couts de télécommunication, les éventuels couts de

développement des capteurs mais aussi les couts d’infrastructure incluant la plate-forme de

traitement analytique.

Quant aux revenus, ils peuvent faire l’objet d’un modèle de souscription à l’usage ou à la

consommation (redevance). A l’heure actuelle le consommateur cherche avant tout à bénéficier

d’un cout complet forfaitisant ses accès au service, à la manière des opérateurs de

télécommunication.

Cas d’usage

Les cas d’usage sont les expressions de la mise en situation des utilisateurs consommant le service.

Ils sont absolument clés et doivent faire l’objet d’un consensus entre responsable marketing, chef

produit, directeur financier et équipe projet.

Ils doivent être compris, documentés, communiqués et partagés en toute transparence avec

l’ensemble des parties prenantes.

De nos jours, leur formalisation repose sur des techniques agiles, les approches fonctionnelles

traditionnelles n’étant plus adaptées car trop verbeuses et peu explicites pour les utilisateurs métier.

On privilégiera ainsi une approche basée sur un diagramme de contexte et une modélisation par cas

d’usage incluant la rédaction textuelle d’un ou plusieurs scénarios nominaux et d’une ou deux

branches alternatives.

Le maquettage de l’expérience utilisateur et des séquences de navigation sur les applications pourra

compléter la phase de modélisation des cas d’usage (techniques de Sketching / Storyboarding).

Cette pratique est fortement recommandée lorsque les interactions homme-machine sont réalisées

à l’aide d’applications mobile.

L’approche Design Thinking peut aider à faire émerger et concrétiser l’innovation dans le projet IoT

(http://www.ibm.com/design/thinking/)

Plate-forme

La plate-forme logicielle est un composant clé de la solution car elle apporte l’automatisation et les

traitements analytiques nécessaires à la réussite du projet. On parle souvent de plate-forme M2M

pour Machine To Machine ou plate-forme Analytique.

Une plate-forme pour l’IoT offre en général les services suivants :

Support à la connectivité (protocoles, montée en charges, authentification et sécurité).

Analyse en temps-réel (Complex Event Processing).




Téléphone : +33 (0)1 58 75 00 00

40





Siret 552 118 465 03644 - Code NAF 6202A

Traitements analytiques avancés (geospatial, prédictif, prescriptif, cognitif).

Respect des standards ouverts.

Capacités d’intégration (applications entreprise) par les API.

Capacités de développer en mode agile les services connectés (DevOps).

Choix du modèle de déploiement (Cloud, Hybride, OnPremise, paiement à l’objet).

Exposition et gestion des services par les API.

Les plate-formes IBM pour l’internet des objets couvrent l’ensemble de ces services. Elles sont

déclinées par industrie (Automobile, Assurance, …) et seront souvent dénommées IoT for

<Something>.

La figure ci-dessous visualise les capacités et les services offerts par la plate-forme IBM IoT for

Automotive, qui s’adresse au marché du véhicule connecté.

Figure 16 : Plate-forme IoT for Automotive




Téléphone : +33 (0)1 58 75 00 00

41





Siret 552 118 465 03644 - Code NAF 6202A

Une entreprise peut ainsi choisir d’activer les services de la plate-forme sans obligation contractuelle

ou commerciale. La plate-forme est pré-intégrée et permet de développer les services connectés de

manière agile en appliquant les principes DevOps.

Cette approche modulaire (Start Little, Think Big), caractéristique des solutions d’IBM pour

l’internet des objets, permet ainsi une mise en œuvre des services connectés de manière progressive

et incrémentale.

Gouvernance

La gouvernance des projets Internet des Objets présente des différences par rapport à un projet

classique. La principale différence vient du fait que le concept de service est central et partagé par

toutes les parties-prenantes du projet.

De plus, la mutualisation des ressources pour développer les services est en général plus forte que

dans les projets traditionnels et s’impose souvent naturellement. Enfin ne pas oublier que

l’approche service est par nature une démarche de bout en bout, depuis le consommateur jusqu’au

producteur.

La somme de toutes ces raisons amène au fait qu’il est recommandé de penser la gouvernance

différemment. Les règles de gouvernance doivent être définies à tous les niveaux : développement

des services, architecture de la solution, cycle de vie, mise sur le marché par le marketing, plan de

commercialisation et gestion des offres …

Les questions suivantes pour la gouvernance devront être évoquées lors des études préalables, en

général en même temps que le Business Model.

Quel est le processus de décision pour mettre sur le marché un service ?

Comment collecte-t-on les besoins et les retours des utilisateurs ?

Qui finance le développement des services ?

Quelles sont les règles d’usage ?

Quelle gestion des changements à mettre en place sur les services ?

Confidentialité de la Donnée et Propriété Intellectuelle

La partie Confidentialité et Propriété intellectuelle de la donnée est délicate et se réfère aux lois en

vigueur dans chaque pays (CNIL en France).

En effet, chaque pays définit ses propres règles en matière de stockage et d’exploitation de la

donnée, incluant l’anonymisation et le cryptage de la donnée.

En France le principe de la déclaration de fichiers pour les données d’identité allié au respect du

principe de Finalité de la CNIL continuent de s’appliquer pour les projets d’objets connectés.




Téléphone : +33 (0)1 58 75 00 00

42





Siret 552 118 465 03644 - Code NAF 6202A

En général, sur notre territoire, une solution simple consiste à faire signer au consommateur du

service un contrat définissant les règles (Terms & Conditions) qui s’appliquent sur les données. Ces

règles sont acceptées par le consommateur qui signe de manière digitale le contrat, par

l’intermédiaire typiquement d’une application portail ou mobile.

En contrepartie, le fournisseur s’engage à offrir un certain nombre de garanties, tel que le droit à

l’oubli, l’accès aux informations, la capacité de modifier les données d’identité, le cryptage et

l’anonymisation voire le droit à l’oubli dans certains cas…

En effet certains services nécessiteront d’anonymiser de manière irréversible une partie des

données collectées, alors que d’autres nécessiteront seulement de crypter ces données de manière

temporaire, et de les décrypter lors d’évènements spécifiques.

Par exemple dans le domaine du véhicule connecté, Le fournisseur s’engage à ne pas chercher à

identifier et stocker le conducteur d’un véhicule, mais utilisera le VIN, à savoir l’identifiant posé en

usine et identifiant de manière unique tout véhicule : Vehicule Identification Number.

En revanche, lorsque notre objet connecté va traverser la frontière entre deux pays, les règles

énumérées ci-dessus ne peuvent plus s’appliquer car elles ne sont valables que pour la France.

Il sera probablement nécessaire de prévoir des contrats différents par pays, à faire signer par le

consommateur lors de la souscription. De plus, il faudra prendre compte, au niveau de la solution

technique, ces changements de législation et faire en sorte d’assurer la continuité de service sur

toute la chaine de collecte et de transformation de la donnée.

Enfin, dernier conseil avisé : Il est recommandé de traiter les aspects de confidentialité et de

propriété intellectuelle assez tôt dans le projet, par exemple dès la phase de réflexion sur le Business

Model.

Conclusion

L’Internet des Objets (IoT) est un sujet passionnant apporteur de valeur et d’innovation, se situant

à la croisée des chemins entre la connectivité, les télécommunications, le Big Data, l’analytique et

la mobilité.

L’IoT dynamise l’intérêt grandissant des approches cognitives qui émergent sur le marché, en

particulier avec les nouveaux services en mode SaaS tels qu’IBM Watson.

En parallèle, les projets IoT ont permis l’émergence de nouveaux rôles tels que les Data Scientist,

Data Analyst et Business Analyst, travaillant en mode collaboratif et agile au sein d’incubateur (Data

Laboratory) et conjointement avec les responsables marketing et les équipes de réalisation.

Comme évoqué tout au long de cet article, l’IoT est et sera porteur de croissance pour l’économie en

facilitant l’émergence de nouveaux Business Model, l’incubation d’idées et la naissance de startups

de plus en plus surprenantes et innovantes. Les modes de consommation sont et vont continuer à




Téléphone : +33 (0)1 58 75 00 00

43





Siret 552 118 465 03644 - Code NAF 6202A

être profondément modifiés pour chacun d’entre nous. Ils vont transformer l’économie

traditionnelle basée sur la notion de biens, en économie du service et de la donnée pour de

nombreuses décennies

dobjets connectés en entreprise - · par une application mobile, ... de l’optimisation du code...

Documents