Guide RGPD & Sécurité
Ce document est une proposition en cours d’élaboration. Il est susceptible d’être amendé ou de faire l’objet de contre-propositions.
Accepter que ces sujets coûtent du temps et des ressources et qu'ils ne soient pas (très) visibles des utilisateurs ;
Plus tôt on se pose les questions, plus il est facile et rapide d'y répondre et de traiter le sujet des données et de la sécurité ;
La relation de confiance qu'une équipe établit avec les référents-experts de ces sujets dans l'administration est son meilleur passeport pour la liberté et l'autonomie, davantage que les livrables attendus ;
En matière de données, ce qui vaut pour soi vaut pour les autres : que n'aimerions-nous pas voir circuler sur nous-mêmes ?
9 semaines pour instruire un problème et envisager des solutions pour le résoudre
Quels outils utilise l'équipe pour communiquer, prendre des notes, conduire des entretiens ?
"Qui ça regarde ?" Est-ce que je suis en train de partager des données au delà du périmètre de l'équipe ou de ceux qu'elles regardent ?
Exemple : Un entretien utilisateur peut être partagé avec l'équipe, le coach, l'environnement de l'équipe, mais sans doute pas au-delà. Est-ce que j'ai autorisé la lecture de mon Google doc par défaut, ou l'ai-je restreint au cercle d'intéressés ?
Est-ce que je sais ce qu'est une donnée personnelle ?
Je me documente sur les sujets RGPD & sécurité :
Je rencontre l'équipe juridique de la DINUM et de l'administration sponsor du produit pour une première prise de contact ([email protected], [email protected]) ;
Je limite l'accès aux docs partagés à ceux que "ça regarde" et j'utilise des outils différenciés en fonction du degré de gêne (sensibilité) des informations :
💡 pad.incubateur.net est une alternative à Google doc qui permet de prendre des notes. L'option signed-in people can edit limite la diffusion à la communauté @beta.gouv.fr.
Je minimise les informations collectées et supprime celles dont je n'ai pas besoin. Après un entretien utilisateur, ai-je besoin de conserver dans mes notes toutes les données de le personne interrogée (date de naissance, numéro de tél, nom, etc.) ?
Exemple : Un plan de déploiement peut sans doute être sur Google doc en accès ouvert, mais des notes d'entretien utilisateurs, plutôt en accès limité.
Je crée une fiche pour la nouvelle startup sur beta.gouv.fr.
Accepter des fichiers de coordonnées de personnes à contacter sans avoir vérifié le consentement de ces personnes ;
Discuter ou échanger des données personnelles sur des outils partagés (Trello, Slack).
3 à 6 mois pour développer une première solution numérique et l'expérimenter auprès d'utilisateurs
Quelle(s) donnée(s) personnelle(s) ai-je prévu de collecter ou d'utiliser dans mon produit, dans quel but précis ?
Exemple : J'utilise des "traceurs" ou un outil de web analyse ; et je le fais dans le but d'optimiser le parcours sur le site.
Suis-je en train de collecter des données dont je ne sais vraiment à quoi elles serviront ?
Est-ce que le produit que je construit peut se rattacher à une démarche administrative existante, un service, ou un texte juridique ?
Qui est mon référent RGPD (DPO ou délégué DPO) ou sécurité ?
Quelle solution d'hébergement utilisé-je pour mon site ? Est-elle opérée ou localisée en France, en Europe ?
Je rédige les Conditions Générales d'Utilisation (CGU) et mentions légales et les soumet à l'équipe juridique :
💡 Modèle à adapter : Mes-aides
Je choisis les bons outils :
💡 Info et recommandation pour la gestion des cookies : lien
Je recense toutes les données traitées et les finalités qui leur sont associées [1 à 2h] :
💡 Tableau données-finalités écrit par la startup Itou. Le vôtre sera plus simple !
Si mon produit rentre dans l'un des critères de la CNIL : commencer à réaliser une analyse d'impact relative à la protection des donnée (AIPD, aussi appelée EIVP) :
💡 Exemple d'AIPD pour la startup Itou
Organiser un atelier d'analyse de risques en suivant le guide Agile de l'ANSSI [1 demi-journée en équipe complète] :
💡 Exemple de résultat d'un atelier pour Le.taxi
Pour la rédaction d'une AIPD, comme pour l'atelier d'analyse de risques, nous vous conseillons de solliciter l'aide d'expert(e)s dans la communauté.
Fausse bonne idée : considérer que le recueil du consentement est nécessaire, ou suffisant, ou facile à mettre en oeuvre. Le consentement est en réalité souvent inutile dans l'administration, et complexe à stocker, gérer dans le temps.
Mon produit a rencontré ses utilisateurs et démontré sa valeur en phase d'expérimentation ; je concentre mes efforts sur son déploiement à grande échelle (de 100 à 1 000 ou de 1 000 à 100 000 utilisateurs)
Qui est le Responsable de la sécurité des systèmes d'information (RSSI) dans mon administration ?
Je reviens sur les actions des phases précédentes, en répète certaines (atelier risques) et mets à jour les documents correspondants ;
A partir du livrable de l'atelier risques, je constitue un dossier d'homologation de sécurité :
💡 Exemples de dossier d'homologation de sécurité : Le.taxi et Aidants connect
Je partage le dossier avec le RSSI de mon administration, prends en compte ses retours et me renseigne sur l'autorité d'homologation :
💡 Pour connaître le RSSI de la DINUM, tu peux interroger l'équipe de coanimation de beta.gouv.fr
[Optionnel] A ce stade, je peux solliciter un prestataire pour réaliser un test d'intrusion. Je contacte la DINUM si besoin pour en discuter.
Déstaffer les développeurs expérimentés dont on a plus que jamais besoin pour la montée en charge du produit ;
Croire que c'est fini !
