Foire aux questions

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

Pour les questions “Que veut dire …”, rendez-vous sur le Glossaire.

Et si vous avez une question ou un mot non-défini, parlez-en avec un membre, qui viendra compléter la page !

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.

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 : 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 (EUPL).

(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

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é

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 :
  1. entre en contact avec l'organisme gérant un serveur auquel il veut se connecter
  2. demande d'avoir un lien (connexion de la fédération) avec ce serveur
  3. 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 :
  1. entre en contact avec un organisme gérant un serveur connecté à la fédération
  2. 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 :
  1. installe son serveur
  2. 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)
  3. continue en suivant le point 1 ci-dessus

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 :
  1. la fédération “technique” doit se doter d'une structure morale
  2. 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
  3. 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” :
  1. on fait une charte qui est approuvée publiquement par les organismes mettant en place des serveurs

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 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 Glossaire.