Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:chantier-sen1:poc [2019/10/31 10:15] – créée adminconso
+++ projets:chantier-sen1:poc [2019/10/31 11:04] (Version actuelle) – contenu rapport de synthèse adminconso
@@ Ligne 3: / Ligne 3: @@
-Ce travail s'est mené dans le respect de la [[realisations:charte_prestalibre|charte Prestalibre]].
+Ce travail s'est mené dans le respect de la [[realisations:charte_prestalibre|charte Prestalibre]], et en particulier l'ensemble des réalisations (codes, documentation, livrables) sont diffusées sous la licence EUPL v1.2.
-===== Liens utiles =====
+Le contenu de cette page est issu du [[https://github.com/consometers/sen1-poc-docs/blob/master/rapport_conclusion.pdf|rapport de synthèse]], dont la lecture reste recommandée pour comprendre l'articulation des cinq rapports et trois outils techniques produits.
+<note>** Liens utiles**
   * Livrables : https://cloud.consometers.org/index.php/s/livrables-sen1-poc
   * Dépôt de code et documentation : https://github.com/consometers/sen1-poc
-  * Interface publique d'une réalisation : http://srv4.consometers.org/zabbix/zabbix.php?action=dashboard.list
+  * Interface web publique d'une réalisation : http://srv4.consometers.org/zabbix/zabbix.php?action=dashboard.list
+</note>
 ===== Introduction =====
@@ Ligne 19: / Ligne 22: @@
 ==== Pourquoi une fédération ====
+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é.
 ==== Comment se fédérer ====
+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 : [[https://www.rfc-editor.org/rfc/pdfrfc/rfc8428.txt.pdf|SENsor Markup Language]], publié par l’Internet Engineering Task Force qui est suffisamment générique pour être à l’épreuve du temps.
 ==== Réalisations du POC ====
+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).
+{{ :projets:chantier-sen1:schemas_architecture_v3.png?nolink&600 |}}
+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.
+<note tip>Les codes de ces trois proxies sont disponibles dans le [[https://github.com/consometers/sen1-poc-proxies|dépôt de code dédié]].
+</note>
+===== Besoins Utilisateurs mis en œuvre =====
+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.//
+==== Financement citoyen de la transition énergétique ====
+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.
+{{ :projets:chantier-sen1:bmhs-repartion_invest.jpg?nolink|réalisation du besoin 1 - interface web}}
+==== Éducation à l'énergie ====
+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.
+<note tip>Cette réalisation est accessible publiquement [[https://srv4.consometers.org/zabbix/zabbix.php?action=dashboard.view&dashboardid=11|à ce lien]].</note>
+{{ :projets:chantier-sen1:lognact-kermelo.jpg?nolink | réalisation du besoin 2 - interface web}}
+==== Autres besoins référencés ====
+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 ».