Différences

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

--- ressources:faq [2018/10/03 14:33] – créée jaxom
+++ ressources:faq [2020/02/27 15:06] (Version actuelle) – ↷ Liens modifiés en raison d'un déplacement. adminconso
@@ Ligne 1: / Ligne 1: @@
-Foire aux questions pour clarifier les termes utilisés, les concepts, etc
+====== Foire aux questions ======
-===== Q1. Bonjour =====
-===== Q2. Maybe =====
+Cette page liste des questions adressées au collectif, et nos réponses, afin que tout le monde ait le même niveau de compréhension. Si quelqu'un vous a déjà posé la question “Pourquoi faire XXX ?”, alors la réponse a sa place ici :-)
-===== Q3. Essayons =====
+Pour les questions “Que veut dire ...”, rendez-vous sur le [[lexique|Glossaire]].
+Et si vous avez une question ou un mot non-défini, parlez-en avec un membre, qui viendra compléter la page !
+----
+===== Pourquoi anonymiser les données de comptages énergétiques ? =====
+C'est un moyen technique de répondre aux exigences du RGPD : soit on a du consentement soit on doit travailler sur des données non personnelles. Auquel cas on les anonymise. On prend pour cela un identifiant ne représentant pas une donnée personnelle (ex : nombre aléatoire). Typiquement on remplace un nom+prénom ou une adresse mail par : 346841354.
+Lorsque l'on est toujours capable de rattacher des données à quelqu'un (à travers une table de correspondance : nom+prénom / nombre aléatoire), on parle de **pseudonymisation**. C'est un autre niveau d'anonymisation.
+cf. Respect du secret statistique, INSEE et Enedis. cf https://linc.cnil.fr/cabanon-protection-des-donnees-et-utilisabilite-une-nouvelle-approche-pour-lanonymisation
+Anonymiser : rendre anonymes des données à caractères personnel, par ex. voir le  CDC pour Linky. En fin de compte, c'est la CNIL qui est juge de la "bonne" anonymisation des données personnelles.
+===== Pourquoi mettre en place une charte à destination des prestataires ? =====
+Ce document permet à tout acteur de se saisir des valeurs des Consometers, tout en restant maître de son processus de décision. Retrouvez la charte ici : {{ :ressources:charte_prestalibre_v0.1.pdf |}}.
+C'est un document générique, indépendant des projets ou marchés. C'est un outil à destination de tout donneur d'ordre qui permet de privilégier les prestataires qui répondront à certains critères.
+Ces critères sont de manière générique : la bonne collaboration entre prestataires et la création ou l'amélioration des communs.
+La charte peut également être modifiée/adaptée par un donneur d'ordres avant son application, puisque sa licence est libre ([[https://fr.wikipedia.org/wiki/Licence_publique_de_l'Union_europ%C3%A9enne|EUPL]]).
+===== Pourquoi s'orienter vers une fédération ? =====
+(points issus de la //note fédération// produite par le collectif en juin 2018)
+  * Ouvert à tous, facilité pour un organisme ou un fournisseur de services de commencer "dans son coin" puis facilité de rejoindre le réseau
+  *     Flexible (répond aux besoins de différents profils d’utilisateurs, d'organismes, de fournisseurs de services, de données, d'intérêts économiques)
+  *     Souple (entrer, sortir, se faire "jeter" --> mise en confiance)
+  *     Relocalisation, résilience du réseau global
+  *     Echange de données, Communication facilitée (et sûre) pour un partage des données
+  *     Autonomie des organismes hébergeant des serveurs de la fédération
+  *     Pas d’impacts en cas d’arrêt d’un des membres
+  *     Migration aisée (par exemple en cas de l'arrêt d'activité d'un organisme et de ses serveurs)
+  *     Scalabilité (= passage à l'échelle) de la solution technique en fonction des besoins utilisateurs
+  *     Rayonnement des donneurs d'ordres
+===== Pourquoi remettre en question la centralisation ? =====
+La centralisation présente les inconvénients suivants :
+  *     1 seul acteur : risque de crash ou de mauvaise gestion (pas de résilience du fournisseur de service)
+  *     risque de collusion (intérêts financiers et stratégiques qui ne correspondent pas à l'intérêt général)
+  *     pas de possibilité de faire sans (moins de liberté, pas de possibilité d'expérimentation autonome)
+  *     1 seul prestataire à financer, business model de service qui va être compliqué à définir
+  *     passage à l'échelle (augmentation du nombre d'utilisateurs des services) plus compliqué
+===== Comment rentrer "techniquement" dans la fédération ? =====
+Plusieurs cas :
+  * Un organisme met en place son propre serveur et veut commencer à échanger avec d'autres serveurs de la fédération. Dans ce cas il :
+    - entre en contact avec l'organisme gérant un serveur auquel il veut se connecter
+    - demande d'avoir un lien (connexion de la fédération) avec ce serveur
+    - se connecte à ce serveur (si l'organisme gérant ce serveur l'accepte)
+  * Un fournisseur de service veut bénéficier de l'infrastructure de la fédération, sans mettre en place son propre serveur. Dans ce cas, il :
+    - entre en contact avec un organisme gérant un serveur connecté à la fédération
+    - négocie des modalités d'accès (obligatoirement : inclusion dans le protocole de "green button", et éventuellement : tarif, stockage, capacités techniques, ...)
+  * Un fournisseur de service veut bénéficier de l'infrastructure de la fédération, en mettant en place son serveur et en rejoignant la fédération. Dans ce cas, il :
+    - installe son serveur
+    - PAS POUR LE MOMENT/A DETERMINER : signe une charte ou un contrat ou des engagements envers la fédération (groupe social et technique, instance morale éventuelle)
+    - continue en suivant le point 1 ci-dessus
+===== Comment mettre en place des règles pour la fédération ? =====
+Si on doit mettre des règles pour la fédération technique (ex : ne pas exploiter les enfants), dans ce cas :
+  * Si on veut un cadre fort :
+    - la fédération "technique" doit se doter d'une structure morale
+    - les organismes mettant en place des serveurs dans la fédération DOIVENT contracter avec la structure morale pour être acceptés dans la fédération
+    - la fédération personne morale DOIT disposer d'un registre des organismes ayant contracté (ou mieux avoir un répertoire technique pour whitelister les organismes qui ont contracté)
+  * Si on veut un cadre "faible" :
+    - on fait une charte qui est approuvée publiquement par les organismes mettant en place des serveurs
+===== Pourquoi ne pas donner de règles de fonctionnement pour la fédération POUR LE MOMENT ? =====
+Pour le moment, à ce stade de réflexion/conception de la fédération :
+  * nous n'avons pas de contrainte spécifique qui nécessitent de mettre en place des règles de fonctionnement
+  *     le RGPD est une loi applicable et donne déjà beaucoup de garanties
+  * la fédération, de par sa nature (plusieurs serveurs avec plusieurs données et discutant entre eux) donne la notion de confiance intrinsèquement car :
+    * un producteur de données envoie ses données à un serveur en particulier, le producteur connait le serveur et l'organisme qui le gère, il a confiance
+    * chaque serveur voulant se connecter à la fédération le fait en se connectant à d'autres serveurs.
+    * c'est à chaque organisme gérant un serveur de la fédération d'autoriser ou non une nouvelle connexion d'un autre serveur
+Cependant, il est prévu d'implémenter des mécanismes techniques de discussion entre les serveurs de la fédération qui vont permettre de systématiser la protection des données. Par exemple :
+  *  mécanisme de "green button" (voir la définition de "Green Button" dans le [[lexique|Glossaire]].)
+  *  traçabilité des consentements "green buttons"
+  *  traçabilité des données et des traitements appliqués
+Enfin, ce sera aux organismes responsables d'un serveur de respecter la RGPD. Par exemple : ne pas rendre inopérant le système de "green button" intégré en modifiant le code source...
+Voir une définition de l'**auto-régulation** dans le [[lexique|Glossaire]].