Temps de lecture 3 min
Dans le cadre de mon bénévolat pour Framasoft, je suis amené à travailler sur la conformité de l’association au Règlement Général sur la Protection des Données (RGPD).
Ça fait des années qu’on essaye d’avancer sur le sujet, mais il faut bien reconnaître que, vu le nombre de services et d’activités que l’on gère, c’est la galère. D’ailleurs, si ça vous étonne, on a une entrée claire dans la FAQ.
On a tout de même bien avancé depuis octobre dernier, accompagné‧es que nous sommes par stella.coop. Notre liste des traitements est sur pied, mais il nous reste à compléter les fiches des différents traitements (on en documente d’ailleurs l’avancement dans notre wiki public). Il nous faut donc passer sur chaque service, déterminer les finalités des traitements, lister les données récupérées, vérifier si elles sont obligatoires, leur visibilité, les services tiers utilisés, etc.
Face à cette montagne, une idée me trotte dans la tête depuis un moment : que les développeurs et développeuses de logiciels maintiennent elles-mêmes un document synthétisant les informations utiles dans le cadre du RGPD. Cela faciliterait le travail de celles et ceux qui proposent des instances de leur logiciel, mutualiserait le travail ingrat et limiterait les erreurs.
Comme on n’est jamais aussi bien servi que par soi-même, j’ai imaginé un fichier pour faciliter l’échange d’informations autour des questions liées au RGPD : le fichier GDPR.txt.
Le principe est fort simple : le fichier GDPR.txt se place à la racine du code source d’un projet logiciel — à la manière d’un fichier README — et contient l’ensemble des informations utiles concernant la collecte des données effectuée par ledit logiciel.
Le but est que les hébergeuses et hébergeurs de services puissent se baser sur des informations fiables pour créer leur propre liste de traitements de données. Car oui, attention : il ne suffit pas de fournir un fichier GDPR.txt pour se conformer au RGPD ! Ce fichier n’existe qu’à titre informatif.
Le format, quant à lui, est très simple. Si vous êtes développeur ou développeuse d’un logiciel libre, je vous invite à jeter un œil au site qui présente le format du fichier : gdpr-txt.org (en anglais). Vous pouvez également y contribuer sur Framagit.
En conclusion, j’aimerais que les acteurs et actrices du logiciel libre s’emparent de ce fichier et inventent encore d’autres manières d’informer les utilisateurs et utilisatrices sur la manière dont sont utilisées leurs données. Il serait dommage qu’après avoir bataillé pendant des années pour une meilleure réglementation autour de nos données personnelles, nous nous satisfaisions de l’état actuel. Soyons clairs : les GAFAM se torchent toujours autant avec nos données ; seulement, ils s’en lavent les mains grâce à une conformité RGPD de façade. C’est à nous désormais de placer la barre encore plus haut.
Stéphane Bortzmeyer
Il n’est pas parfaitement clair pour moi si ce fichier doit être géré par l’auteur du logiciel ou par celui ou celle qui installe et gère une instance. J’ai regardé comment appliquer ce fichier à un de mes logiciels et la plupart des décisions de journalisation sont prises par l’instance, pas par le programme.
Marien Fressinaud
Alors comme précisé sur le site :
> A GDPR.txt file must be written and maintained by the developers of the corresponding software. Hosting providers should use this file to create their own records of processing activities.
Il s’agit donc bien d’un fichier maintenu par les devs. C’est forcément un fichier incomplet du point de vue des hébergeurs vis-à-vis de leur propre conformité au RGPD, mais ce serait déjà d’une grande aide, surtout pour nous à Frama 🙂
Stéphane Bortzmeyer
Bon, j’ai fait un essai : https://framagit.org/bortzmeyer/mastodon-DNS-bot/-/blob/master/GDPR.txt
Je ne suis pas du tout satisfait. Par exemple, envoyer le nom de domaine est évidemment obligatoire (le bot ne pourrait pas répondre s’il ne connaissait pas la question) mais journaliser la requête ne l’est pas et je ne sais pas du tout comment exprimer cela.
Il y a d’autres exemples pour des programmes réels ? Je suis franchement perdu.
Marien Fressinaud
Pas simple, tu essuies un peu les plâtres 🙂 J’ai essayé de te répondre du mieux que je pouvais dans un ticket. J’ai raté ta question concernant la journalisation par contre. Si ce n’est pas obligatoire, peut-être que tu peux mettre « required: no » concernant « fediverse account name » et préciser dans « mitigation » dans quel cas la donnée est collectée (syslog configuré) ou non (aucun système de log configuré)
En exemple, j’en ai créé un pour flusio : https://github.com/flusio/flusio/blob/main/GDPR.txt
Castopod va également prochainement en proposer un.
Stéphane Bortzmeyer
« « required: no » concernant « fediverse account name » » Mais « required » veut dire que l’utilisateur doit fournir cette donnée (pas d’opt out), non ? Si c’est le cas, c’est bien « required: yes » puisque ActivityPub ne permet pas de message anonyme (de même qu’IP ne permet pas d’envoyer des paquets sans adresse source).
Frédéric Urbain
C’est pourquoi j’avais émis l’idée, pour les personnes qui gèrent une instance, de placer un tel fichier à la racine du site, à l’instar d’un robots.txt.
Stéphane Bortzmeyer
Mauvaise pratique. Oui, robots.txt le fait mais, depuis, la bonne pratique est de mettre ces ressources sous /.well-known/ https://www.bortzmeyer.org/8615.html
Marien Fressinaud
Oui, j’aurais mis ça sous /.well-known/ si ça avait été le but du fichier, pas de crainte 🙂
Je me permets de remettre ici le contenu de ma réponse faite en interne à Fred concernant son idée (j’ai vu l’idée apparaître sur Twitter d’ailleurs également)
—
Ah mais tout à fait oui ! C’est ce que j’avais proposé quand on a commencé à bosser sur les fiches RGPD d’ailleurs. Mais attention, ce n’est pas les mêmes objectifs, ni les mêmes moyens à mettre derrière.
Là, ma proposition c’est de mutualiser le travail de recherche des infos en laissant aux devs le soin de déclarer les données et finalités du logiciel.
Ce que tu proposes c’est que les hébergeurs (donc nous) déclarions de manière structurée nos fiches de traitement. Pourquoi je ne fais pas cette proposition du coup ?
– dans l’immédiat ça ne nous aide pas, au contraire ça nous rajouterait du boulot et on a décidé de viser la conformité en priorité
– je ne veux pas proposer un tel format sans l’avis d’un⋅e juriste spécialisé⋅e. Pour le format que je propose, on reste à un niveau déclaratif, on peut se permettre des trucs pas complètement justes (cf. le disclaimer sur le site), même si idéalement j’aimerais un truc robuste vis-à-vis de la loi
– je n’ai pas l’énergie de m’occuper de ça pour l’instant
La bonne nouvelle c’est que tu as eu cette idée, et qu’un mec sur GitHub semblait avoir la même vision. Donc moi j’ai plus qu’à attendre que ça se fasse 😀
Burton
Ecriture inclusive !! je retire votre site de nos recommandation
Marien Fressinaud
Vous avez 7 ans de retard ! https://contact.framasoft.org/fr/faq/#blog-inclusif
Laurent Destailleur
Le regroupement des tags n’est pas clair. Par exemple
Faut-il mettre des balises purpose et en dessous les balises data qui sont collectés pour ces purposes (et dans ce cas on aura plusieurs fois les meme blocs « data »), ou faut-il mettre tous les purpose d’abord et ensuite tous les blocs data et dans ce cas on ne sait pas à quelle finalité (purpose) un data est collecté.
Marien Fressinaud
Oui effectivement il faudrait pouvoir rattacher les traitements aux données, le format va nécessiter d’évoluer sur ce point.
(par contre je préfère les retours directement sur le dépôt, je vais me perdre sinon :))