Chantier SEN1 - Phase de POC

Cette page présente les réalisations de la première phase du Chantier SEN1, qui s'est tenue de Décembre 2018 à Juillet 2019. Il s'agit d'une Preuve de Concept, en anglais Proof of Concept ou POC.

Ce travail s'est mené dans le respect de la charte Prestalibre, et en particulier l'ensemble des réalisations (codes, documentation, livrables) sont diffusées sous la licence EUPL v1.2.

Le contenu de cette page est issu du rapport de synthèse, dont la lecture reste recommandée pour comprendre l'articulation des cinq rapports et trois outils techniques produits.

La Région Bretagne, en tant que maître d'ouvrage du chantier SEN1, a confié la réalisation d'une première étape à ALOEN et Breizh ALEC, dont l'énergie est l'un des sujets d'action. Puis ALOEN s'est entourée de quelques entrepreneurs indépendants et membres du Collectif des Consometers, pour disposer d'une expertise technique à même de remplir les objectifs du projet. Nous avons engagé une relation de coopération, matérialisée notamment par l'engagement de respect de la charte Prestalibre, afin de respecter au mieux les volontés initiales et d'apporter des solutions techniques pertinentes. Ce travail s'est ainsi organisé en mode « best effort » dans le cadre défini par le Commanditaire. L’objectif était de réaliser le maximum de choses en respectant le cahier des charges, dans le budget dédié, et en fonction des priorités.

La décision d'une phase de POC a permis d'engager un volume financier limité pour tester des hypothèses et réaliser un travail préparatoire à un déploiement à grande échelle de SEN1. La principale orientation de cette réalisation est la mise en place d'une infrastructure « fédérée » (cf. infra) qui permet de relier les outils existants, plutôt que d'en concevoir un nouveau (nous l’appelons également fédération technique). C'est donc ce travail de POC exploratoire qui est présenté ici, de manière succincte. L'ensemble du travail est détaillé dans les livrables mentionnés ci-avant.

A la suite du dialogue initial entre les partenaires du projet, la solution d'une fédération est apparue pertinente pour répondre aux problématiques identifiées suivantes :

• Apporter de la cohérence aux solutions logicielles publiques et privées, disparates, globalement peu efficaces, et souvent synonymes de perte de contrôle des données personnelles ou commerciales sensibles - et assurer une meilleure compréhension et gestion de leurs données aux usagers.
• Créer un guichet unique, qui mette en synergie et cohérence les outils existants pour rediriger les utilisateurs en fonction de leurs besoins.
• Éviter l’écueil du développement d’une n-ième solution inadaptée, hors-sol ou non-évolutive, provoquant de la dette technologique.
• Ne pas essayer de créer une « super-plateforme » qui centraliserait tous les besoins, usages, données et services (solution non viable au niveau architecture, stockage etc…, et ne peut pas répondre de façon optimale à tous les besoins).

La notion de fédération ayant déjà des applications pratiques en informatique, opérationnelles et reconnues (exemple : le mail), nous avons pris le parti de choisir une solution existante et adaptée à notre situation. Le travail s'est donc focalisé sur la justification de ce choix, pour un protocole (méthode de communication) et un formalisme (manière de présenter les données) associés. Chacun de ces points a fait l'objet d'un rapport dédié.

Nous avons retenu le protocole XMPP, mis en œuvre dans la suite du POC-SEN1, et le formalisme SENML.

• Il faut noter que plusieurs protocoles identifiés dans la phase de recherche sont très intéressants, mais se trouvent encore en phase de recherche et développement. Ainsi, le résultat actuel de nos travaux ne présage pas de la situation dans un à deux ans, quand ces projets auront publié leurs premières implémentations prêtes pour mise en production et réellement utilisées. Un travail de veille est donc à poursuivre dans ce secteur, qui pourrait apporter de meilleures solutions aux défis soulevés par le chantier SEN1.
• SENML : SENsor Markup Language, publié par l’Internet Engineering Task Force qui est suffisamment générique pour être à l’épreuve du temps.

Nous sommes partis de deux solutions (logicielles) préexistantes et sous licence libre, disposant de fonctionnalités d’enregistrement et d’affichage de données énergétiques :

• logNact pour le volet tertiaire et services publics, réalisé par Liberasys,
• BMHS pour le volet particulier, réalisé par Grégory Elleouet.

Nous avons mis en place l’infrastructure nécessaire afin d’instancier (lancer et faire s'exécuter un programme préexistant) :

• deux serveurs XMPP afin de simuler la fédération au niveau protocolaire (1 et 2 sur le schéma ci-après),
• les solutions logNact (4) et BMHS (5) pour le POC de SEN1 (afin de pouvoir faire nos propres modifications sur ces solutions).

Notons que nous avons mis en place un embryon de fédération technique avec deux serveurs et deux noms de domaines afin de tester l’architecture technique fédérée (1 et 2). Cela nous a permis d’utiliser le minimum de ressources tout en validant le fonctionnement pratique. A terme une fédération technique doit avoir un certain nombre de serveurs (3), financés et hébergés par différents organismes afin d’obtenir de la résilience (technique, géographique, politique, financière).

Afin de répondre aux attentes des besoins utilisateurs sélectionnés, il était nécessaire d’échanger des données entre logNact et BMHS. Ces deux solutions logicielles ne sont pas conçues à la base pour échanger des données avec d’autres programmes. Et leur manière d’enregistrer les données est différente. Nous avons choisi de créer des programmes intermédiaires entre une solution et la fédération, ce qui nous semble plus intéressant en terme temps de réalisation et permet d’éviter une forme d’ingérence dans des programmes préexistants. Nous avons réalisé ce que nous appelons des proxies de données (8 à 11).

L’intérêt d’un protocole d’échange de données est que plusieurs applications développées dans des architectures et des langages différents puissent communiquer entre elles. Pour démontrer cette possibilité dans le POC du chantier SEN1, deux langages ont été utilisés pour implémenter les proxies de données logNact, BMHS et PRIDE : Python pour l’application logNact et Java/Groovy pour l’application BMHS et PRIDE. L’un est exécuté sous forme de daemon sur un système Linux, l’autre est déployé dans un conteneur d’applications Web.

Il a été porté une attention toute particulière à ce que les besoins utilisateurs permettant de tester le protocole d’échange fédéré soient issus de besoins réels, exprimés par de futurs utilisateurs potentiels. Ainsi, pendant toute la période de développement du POC, différentes rencontres avec des associations nous ont permis d'identifier des envies et des manques dans les solutions actuelles. Parmi l’ensemble des besoins, nous en avons sélectionné deux, permettant de tester les échanges de données stockées mais aussi de montrer la possibilité des échanges de données en temps réel permise par la future fédération.

NB : retrouvez davantage de captures d'écran dans le rapport de conclusion.

Ce premier besoin utilisateur a été soumis par les collaborateurs de la SCIC Lucioles Énergies issue de l’association « les Lucioles de la Ria d’Etel en transition ». Cette association s’engage sur une réflexion constructive sur l’avenir énergétique de son territoire et interpelle les citoyens afin de les engager collectivement dans un processus de transition énergétique. Au travers de la coopérative, ils permettent à des citoyens d’investir dans des installations photovoltaïques. Cependant, ces acteurs souffrent d’un manque de visibilité au quotidien quant au devenir des projets. Ils n’ont pas toujours d’outil permettant à l’investisseur de voir les bienfaits de son investissement. Il s’agissait ici de permettre d’informer sur un projet photovoltaïque coopératif, tout en visualisant, au sein d’un même outil, la consommation et la production personnelle d'un citoyen investisseur.

Ce second besoin utilisateur émanait des collaborateurs de la structure Oncimè. Cette SAS est issue d'un partenariat entre l'association Bretagne Énergies Citoyennes et la Ville de Lorient. Elle permet la location de panneaux photovoltaïques et favorise l’engagement citoyen autour de projets basé sur l'autoconsommation. C’est dans ce cadre que la ville lui a notamment confié pour mission d’animer des ateliers de sensibilisation à l’énergie dans les écoles. Ainsi, ils avaient besoin d’un outil leur permettant de visualiser des profils de consommation et de production issues de bâtiments de différents types. L’aspect temporel était une notion importante du besoin exprimé, permettant la visualisation sur une journée ou une semaine.

Dans ce travail de recherche des besoins utilisateurs, nous avons identifié une vingtaine d’autres besoins issus de différentes administrations ou associations. Ils ont fait l’objet pour certains d’entre eux de nombreux échanges pour les définir et pour d’autres sont encore à l’état de projet. Ils ont été détaillés au sein d’un livrable spécifique intitulé « besoins exprimés ».