projets:quoalise:20200710notes

no way to compare when less than two revisions

Différences

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


projets:quoalise:20200710notes [2020/09/09 11:38] (Version actuelle) – créée adminconso
Ligne 1: Ligne 1:
 +<file text 20200710_notes_reunion1.txt>
 +*2020-07-10
 +14h-15h40
 +*Participants
 + * Elias Martin - Hereli & Consometers - porteur de projet
 + * Cédric
 + * Cyril
 + * Gautier
 + * Guillaume Zin
 + * Laurent Lebreton
  
 +
 +*Proposition d'ordre du jour
 +- Témoignage Eegle / Consentement / PRIDE
 +- Sujets pour la suite
 +
 +*Contraintes pride
 + * consentements multi entrée (linky, gaspar…)
 + * Assurer la réponse aux demandes d'audit
 + * Garder un modèle de donnée (abstraction) avec ses contraintes (PJ...)
 + * Ouvrir une API relative à ce modèle de données (qui se complexifie au fil du temps, 4 rôles désormais dans le Workflow Dataconnect, prise en compte PJ...)
 + * Possibilité de partager (à demander au consortium) le modèle UML et p-e un diagramme de séquence.
 + * -
 + * Abstraire la démarche, quelque soit le consentement de données, utiliser le même modèle de données
 + * Au départ modèle de données simpliste qui s’est complexifié
 + * PRIDE n'est pas un fournisseur de service final : pas d'utilisation "pour lui-même" des données.
 + * En revanche, prestataire intermédiaire pour gérer ses partages (service de "gestion de son consentement" envers des tiers)
 + * Gestion du consentement par des tokens (Warp10) pour avoir une certaine vue des données finales
 + * Il y a tout de même une problématique RGPD pour PRIDE, mais pas directement sur les données énergétiques
 + * C'est plutôt un lien de "sous-traitance" au titre du RGPD, entre PRIDE et le fournisseur de service au client.
 + * -
 + * Situations très différentes entre SGE Tiers et le Gazpar
 + * Problématique de l'étape "boite mail" (avec des utilisateurs tiers) qui vient rompre le workflow
 + * -
 + * Validité des pièces retenues par PRIDE ? la décision a sans doute eu lieu après échange avec Enedis pour définir cela.
 + * -
 + * Différence avec le consentement "PMO" pour l'Autoconsommation collective, qui est tri-partite : autre pièce, autre workflow ? Dépend du contrat 
 + * à remonter chez Enedis, via NV ?
 + * La PMO gère à la fois les index, les traitements, et la facturation de l'énergie (via des clés de répartition)
 + * Chaque résident signe un contrat avec la PMO, qui inclus forcément les données pour le fonctionnement de la boucle ACC
 + * ? Quid du repartage de ces données ? Dépend du consentement initial, dans le contrat
 + * Consentement individuel vs consentement global / communauté
 + * Responsable de traitement vs sous traitant
 + * https://www.cnil.fr/sites/default/files/atoms/files/rgpd-guide_sous-traitant-cnil.pdf
 + * Ces points manquent d'un retour d'expérience "jurisprudence" à ce jour
 +
 + * Besoins utilisateurs étudiés sur PRIDE à ce jour : 
 + * Tableau de Bord territorial - application "front-end" (intégrée à Eegle) et qui utilise l'infrastructure PRIDE pour récupérer open-data ET Linky/Gazpar
 + * Cadastre solaire ParcelER -> délégation du consentement à PRIDE avant d'utiliser leurs données
 + * PRIDE permet de remonter les justificatifs/preuves d'enregistrement pour un audit extérieur
 +
 + * Question Enedis : quelle validité contractuelle du repartage des données SGE-Tiers (pour un service final) ?
 +
 +
 +Proposition : rencontrer certains membres du consortium pour étudier une collaboration ? Partage de documents, essai de rapprochement entre Dataconnect et Addict (validité du Modèle de données)... Les modèles écos des membres du consortium sont distincts, donc la diffusion n'est pas claire.
 +
 +Cyril : on peut être amené à avoir besoin d'un point central de référence pour les consentements ou les contrats
 +Laurent : attention, le consortium ne sera peut-être pas intéressé de prendre cette responsabilité
 +Jaxom : cela peut être la région ou un autre acteur qui ferait tourner une instance
 +
 +Sous-traitant/consultant pour PRIDE (via SMILE) pour se faire accompagner pour le modèle économique.
 +Mais pas de stratégie pilotée par la Région sur cette politique "service public de la donnée".
 +
 +Position du projet Viriya - Cédric Gelineau
 + * Pas directement issu de la fédération, projet autonome
 + * Mais construction réciproque, donc l'utilisation de la fédération est regardée de près.
 + * Notamment pour l'usage du proxy DataConnect, qui sert de test pour le code produit dans SEN
 +
 +Vocabulaire : 
 + * DX/Developer Experience : "ergonomie du projet/du logiciel vu par un intégrateur."
 +
 +Position Domoticz
 + * Même articulation de "sous-traitance"
 + * Contrat en cours de signature avec un partenaire qui porte les contrats
 + * Pourrait contribuer en temps : test de nos développements, utilisation d'un proxy
 + * Cyril va essayer d'avancer sur le proxy Data Connect et mettre à dispo une library testable en Python pour Guillaume qui pourra tester
 +
 +
 +
 +*Rédaction de conditions générales ou charte ?
 +- PRIDE n'a pas de doc centralisé, mais chaque partenaire en a une.
 +- Eegle a augmenté ses SLA (établies avec un juriste) d'un volet RGPD, avec les ressources partagées par l'écosystème
 +- SEN aimerait proposer un document avec le code, pour application par les instancieurs. -> même simplement en "protection" sans engagement
 +
 +*Gestion d'identité ?
 +- PRIDE = Uniquement des papiers signés. Problématique se pose pour les collectivités territoriales
 +- SEN va étudier l'usage du France Connect comme service d'identité.
 +
 +
 +
 +</file>
  • projets/quoalise/20200710notes.txt
  • Dernière modification : 2020/09/09 11:38
  • de adminconso