Fiware, la révolution SmartCity est en marche

Dans le business des nouvelles technologies, il est de bon ton de parler de « révolution » ou de solution « disruptive » pour présenter un nouveau concept marketing. Cela permet de faire table rase du passé et de justifier le rachat d’une solution complète.

Pourtant en dehors des Américains qui ont fêté le début de leur révolte contre la couronne en établissant le record mondial de la plus grande théière, les révolutions sont plus tôt des épisodes sanglants et brutaux qui marquent profondément ceux qui les vivent.

Non, il n’y a pas de révolution, mais bien des multitudes d’évolutions plus ou moins rapides qui une fois misent en commun rendent abordables des solutions jusque là hors d’atteinte. Et d’ailleurs, chaque révolution technologique apporte son lot de bourgeois gentilshommes qui faisaient du DevOps, de l’agilité, du cloud computing, du web 2.0, du Big data… sans le savoir.

Le SmartCity n’échappe pas à la règle. 

Le domaine SmartCity est le résultat d’une longue chaine d’évolution qui a commencé avec l’informatisation des services de la ville, qui se poursuit encore maintenant avec la « digitalization » et qui associée à des technologies comme le Big data, l’IA, l’Internet des objets, les smartphones… permettent la création de nouveaux services dans la ville pour améliorer le quotidien des citoyens et rationaliser les couts financiers et écologiques des métropoles. 

Par exemple, placer des capteurs dans les conteneurs de déchets collectifs, pour détecter leur état afin d’optimiser la tournée des camions de collecte, relève du SmartCity et permet des optimisations financières et écologiques non négligeables, mais peut on pour autant parler de révolution ?

Le domaine SmartCity a depuis longtemps été identifié comme un formidable terrain de conquête par les acteurs technologiques. En 2016 certains estimaient que le marché représenterait 1 400 milliards de dollars en 2020 à l’échelle mondiale. Mais, en particulier en Europe, ce marché est essentiellement financé par de l’argent public. C’est pourquoi en 2011 l’Union européenne a initié le projet Fiware en s’associant avec plusieurs acteurs technologiques dont Orange, Telefonica, Atos, Engineering pour créer une boite à outils permettant de développer des compétences et solutions SmartCity localement en Europe et de s’assurer que ces développements se fassent selon une philosophie et éthique centrée sur l’intérêt des citoyens.

Aujourd’hui, Fiware est un très gros projet, ce qui le rend plutôt complexe. Alors que je suis Architecte solution dans les domaines de l’innovation, il m’a fallu plusieurs mois à travailler sur des projets utilisant Fiware pour toucher du doigt le véritable intérêt de ce programme, au-delà de la solution technique.

Je vais essayer de vous partager cette vision au travers de quelques exemples :

Les carrefours à feux

Il y a un exemple que je prends régulièrement pour illustrer ce qu’est le domaine SmartCity. Ce qui est amusant c’est qu’il m’a été expliqué il y a 20 ans alors que j’effectuais mon stage de maitrise en mathématiques appliquées à la DDE du Loiret. Je travaillais alors avec un spécialiste des calculs des programmations de carrefour à feux et il m’expliquait que les villes en heures de pointe étaient des systèmes au bord de la saturation et que le moindre grain de sable pouvait provoquer un engorgement massif. Pour prévenir ce genre d’évènement, il faudrait être capable d’anticiper l’évolution du trafic en modifier dynamiquement la programmation des feux pour optimiser le trafic en temps réel à l’échelle de la ville.

Cela tombe bien, aujourd’hui c’est possible. Nous disposons de service comme Flux Vision d’Orange qui permet de remonter à la ville des informations anonymisées sur les trajets des usagers et via les réseaux 4G, Lora ou LTE-M et les solutions IoT, il est tout à fait possible de piloter les carrefours à distance.

Et là, régulièrement quand je présente cet exemple, mes auditeurs me font la même remarque : « Mon dieu, c’est super dangereux. Et qu’est-ce qui va se passer si un terroriste prend le contrôle du système et passe tous les feux au vert ? » Ma réponse est assez simple, en tant qu’architecte je sais concevoir un système qui rend impossible cette situation, on enveloppe ça d’un joli « security by design » et hop le tour est joué.

Pourtant cela permet d’illustrer une dérive des méthodes de conception modernes, qui sous couvert d’agilité et de besoin d’aller vite on tendance à négliger l’architecture et fonce tête baissée sur la première solution fonctionnelle trouvée, quitte à la durcir plus tard si l’on identifie des problèmes.

Par exemple pour mon pilotage de carrefour à feux. Si nous nous limitons au cas simple d’un carrefour à feux composé de 4 feux tricolores, il est possible d’implémenter notre solution en reliant les 12 lampes de notre carrefour à un petit ordinateur local, qui lui exposera une API pour permettre à un serveur centralisé de piloter le carrefour (ainsi que tous les autres carrefours de la ville). Et là effectivement si le serveur tombe en panne, si le réseau défaille ou si un hackeur pirate l’API… c’est le drame. 

Face à ce problème, la réponse usuelle consiste à durcir la solution. On va redonder les systèmes pour prévenir les pannes, ajouter des équipements de sécurités, et essayer de boucher les trous chaque fois qu’ils apparaissent… mais la faille reste là, intrinsèque au design même de la solution retenue.

Une autre approche consiste à commencer par essayer de comprendre le problème pour essayer d’y apporter une solution adaptée prenant en compte les besoins fonctionnels et non fonctionnels. Par exemple pour notre carrefour à feux, nous pouvons remarquer qu’un feu tricolore est régi par un automate à états finis comportant deux états stables (vert et rouge) et deux transitions (rouge -> vert, et vert -> rouge en passant par l’orange). Fort de ce constat, nous allons piloter le feu par un petit circuit électronique dédié comportant une commande binaire (pour l’état vert ou rouge) et deux indicateurs pour informer si le feu est dans l’état rouge, vert ou en transition. Comme nous sommes sur de l’électronique simple, il ne sera pas possible d’en modifier le comportement à distance.

De même, le carrefour est lui-même une machine à deux états stables et deux transitions. Soit l’une des voies et vertes, soit c’est l’autre. Là encore la solution peut être implémentée par des composants électroniques simples rendant physiquement l’allumage du carrefour tout vert impossible. Et finalement la seule chose qui sera rendue pilotable de l’extérieur via un composant réseau, c’est la durée des temps de vert de chaque voie.

La base du problème c’est qu’aujourd’hui nous cherchons à aller vite, nous mettons la pression sur les équipes techniques pour réduire les couts et les délais tout en leur demandant de concevoir des solutions évolutives. Or quand nous abordons des sujets nouveaux ou innovants, il est parfois très difficile de se projeter.

Nous pouvons alors donner notre confiance plus ou moins aveugle à des professionnels en espérant qu’ils en soient dignes. Mais nous pouvons aussi réduire les risques en échangeant et partageant les idées pour résoudre ces problèmes avec d’autres acteurs faisant face aux mêmes problématiques.

C’est cette deuxième solution que Fiware cherche à adresser, en favorisant la création d’une communauté échangeant et partageant sur le domaine SmartCity des idées, des solutions, mais également des outils dont le catalogue des Generic Enabler proposant des API royaltie free et une implémentation open source.

Les données publiques, privées ou en zone grise

Il y a un point qui focalise toutes les attentions autour du SmartCity c’est la donnée. En effet comme évoquer au début de l’article, le SmartCity est né du besoin de partager les données entre les acteurs de la ville pour optimiser les services existants et en créer de nouveaux. Mais ce qui cristallise les tensions autour de la donnée, ce n’est pas tant comment la partager que de déterminer qui la possède. Avoir le contrôle du stockage de la donnée, donne le pouvoir de choisir qui y aura accès. 

Le problème c’est que ces luttes de pouvoir occultent la véritable difficulté qui consiste à déterminer ce qui est utile et ce qui peut être nuisible de partager. Les questions de sphère publique et privée sont de base très complexe à traiter, car très culturelles et subjectives, mais avec l’IoT (Internet des Objets) nous nous retrouvons avec beaucoup de données en zone grise pour lesquelles nous ne savons pas déterminer précisément si elles relèvent du public ou du privé.

Pour illustrer cela, bien qu’aujourd’hui l’expérience et la loi nous obligent à considérer les adresses IP comme des données privées, les éditeurs de sites web consulter anonymement (sans être connecté sous un compte) pourraient se dire qu’une adresse IP ne leur permet pas à eux d’identifier une personne et la considérer comme une donnée publique. Dès lors, comme pour eux cette donnée ne porte pas d’information personnelle ils pourraient être tentés (je ne sais pas pour qu’elle raison) ne partager cette donnée (avec l’heure et l’URL appelée) avec d’autres services du même genre.

Le problème c’est que si quelqu’un accède à cette base de données en ayant la capacité de réconcilier adresses IP et identité de l’usager, il se retrouvera alors en possession d’une mine d’information personnelle. Certains répondrons « Et alors ? », et bien je les invite à partager publiquement des photos de nue de leurs familles ainsi que l’accès aux coordonnées GPS temps réel de leurs enfants (c’est une image hein, ne le faites pas !). Quand nous partageons des données personnelles sans en avoir conscience, comment en comprendre les conséquences ?

Faciliter le partage des données publiques est une très bonne chose, cela permet plus de transparence au sein de notre démocratie et cela peut permettre la création de valeur en facilitant l’innovation et l’expérimentation de nouveaux services. Mais il faut être vigilant sur le partage des données en zone grise, dans le doute il ne faut partager que celles qui sont utiles et en restreindre l’accès à ceux qui en ont l’utilité. 

Par exemple si l’on place un capteur pour mesurer le poids de chaque dépôt dans une poubelle collective, le log de dépôt (date, heure, poids) est-il de l’ordre public ou privé ? Est-il utile de le partager publiquement, ou est-ce que des statistiques sur les dépôts ne seraient pas suffisantes pour les usages légitimes ?

Et c’est là encore que Fiware est une force en permettant la création d’une large communauté pour réfléchir à ces problèmes. Un élément de réponse se trouve par exemple dans les travaux sur les Data Models qui au-delà de l’aspect sémantique permettent de réfléchir à ce qui peut être partagé.

Fiware est la force

Il est temps maintenant de rentrer dans le vif du sujet et d’essayer de montrer comment la mise en œuvre des architectures Fiware est une véritable force pour les villes.

Dans la plupart des grandes villes, nous allons trouver un service de gestion du trafic routier permettant de connaitre l’état de congestion du réseau routier de la ville, ainsi qu’un service de gestion des parkings publics permettant d’en connaitre le taux d’occupation et le nombre de places disponibles.

Sur la base de ces deux services nous pouvons imaginer la création d’un troisième qui réponde à la question « compte tenu de la circulation et de l’état des parkings, où dois je aller me garer pour être à l’heure à mon rendez-vous dans x minutes à l’adresse y ? ». Ce service n’est pas très compliqué à créer, il doit récupérer les données pertinentes des deux autres services, les injecter dans un outil de calcul d’itinéraire et produire le résultat. Pour récupérer les données des deux services, il pourra s’appuyer sur leurs API, ou interroger une solution Big Data dans laquelle les deux autres déversent leurs données.

Les choses vont se compliquer quand les fournisseurs de données vont faire évoluer leurs interfaces, soit notre service « Find a parking » devra évoluer simultanément, soit il faudra mettre en place des convertisseurs ou traducteurs pour permettre aux services de continuer de fonctionner ensemble. Et là, nous retombons dans les travers de mon exemple sur les « carrefours à feux ».

Le problème peut sembler bénin, si nous ne considérons que ces trois uniques services et d’autant plus si la ville les gouverne tous les trois. Mais à l’échelle d’une ville, il y a bien plus de trois services et certains services s’appuient sur bien plus que deux sources de données. Nous pourrions par exemple pour notre service intégrer les transports en commun bus/métro, les services de location de vélos ou voiture et pourquoi pas un service de météo avec détection de pluie. Si en plus certains services sont issus de startups, d’autres de la ville et d’autres confier à des sociétés privées sous contrat… la gestion du changement va rapidement devenir un cauchemar. La légende urbaine amenant à penser que tout sera résolu en déversant toutes les données dans une grande solution Big data tournera vite au gloubi-boulga et à moins que la ville soit l’Ile aux enfants ça ne sera pas une bonne chose.

Une solution consiste, comme pour le carrefour à feux, à analyser le problème sans se focaliser sur l’implémentation technique, afin d’en déterminer les caractéristiques intrinsèques. Par exemple, comment définir un service de location de vélo, quels sont les acteurs, quelles sont les fonctionnalités attendues, quelles sont les données manipulées et partageables. À partir de là, il sera possible de définir les interfaces de tout service de location de vélo et de faire en sorte que tous les services voulant travailler avec la ville parlent ce même langage. Ce travail porte un nom, et il n’a rien de révolutionnaire, c’est l’architecture fonctionnelle.

Si ce travail est bien fait, il sera par exemple possible de changer de prestataire pour le service de location de vélo sans impacter les autres services qui interagissent avec lui. Mais mieux, si ce travail d’architecture fonctionnelle est partagé par plusieurs villes, un service développé pour l’une pourra simplement fonctionner pour une autre.

Et c’est là que se situe la force de Fiware. La base de l’architecture Fiware repose sur deux éléments :

• Le Context Broker : un composant open-source proposant une API royaltie-free (NGSI) pour partager les données entre services. Ce composant offre également des fonctionnalités pour permettre à un service de s’abonner à des évènements liés à la modification des données (publish/subscribe).
• Les Data Models : Le résultat de travaux d’architecture fonctionnelle réalisés et partagés par la communauté pour adresser les différents problèmes de la ville. 

L’association de ces deux éléments permet de définir un véritable langage commun, non seulement à tous les services, mais également à toutes les villes, ce qui permet de partager non seulement les problèmes, mais surtout leurs solutions avec l’ensemble de la communauté.

Placer Fiware au cœur du système d’information de la ville peut leur permettre de garder le contrôle sur les échanges de données et s’assurer qu’ils se font dans l’intérêt du bien commun tout en facilitant l’innovation et la création de nouveaux services.

Fiware est une solution pertinente pour les villes, mais elle ne fonctionnera que si les villes s’y intéressent. Sans l’implication des villes dans la communauté, Fiware se vide de son sens, c’est le drame de tous les projets « ouverts ». 

Dans cet article j’ai mis l’accent sur les aspects SmartCity, mais ce n’est pas le seul domaine d’application de Fiware qui permet également d’adresser les problématiques Industry 4.0 et Smart AgriFood et finalement tous domaines ayant à traiter du partage de données entre plusieurs sources et consommateurs ayant chacune des gouvernances propres.

Fiware est une solution complexe, qu’il n’est pas facile à résumer dans un simple article, mais si vous souhaitez en savoir plus et si vous en avez l’occasion venez rencontrer la communauté Fiware à l’occasion du prochain Fiware Summit à Porto les 8 et 9 mai prochain, personnellement j’y serais !!