Guide RGPD & Sécurité

A chaque étape du développement d'un produit, savoir quelles questions se poser, quelles actions entreprendre, et quelles ressources mobiliser.

Ce document est une proposition en cours d’élaboration. Il est susceptible d’être amendé ou de faire l’objet de contre-propositions.

⚕ Hygiène : grands principes valables par tous les temps

  • 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 ?

🔎 Phase d'investigation

9 semaines pour instruire un problème et envisager des solutions pour le résoudre

Question à se poser
A faire
A ne pas faire
Question à se poser
  • 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 ?

A faire
  1. 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]) ;

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

  3. 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é.

  4. Je crée une fiche pour la nouvelle startup sur beta.gouv.fr.

A ne pas faire
  • 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).

🧱 Phase de construction produit

3 à 6 mois pour développer une première solution numérique et l'expérimenter auprès d'utilisateurs

Questions à se poser
A faire
A ne pas faire
Questions à se poser
  • 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 ?

A faire
  1. Je rédige les Conditions Générales d'Utilisation (CGU) et mentions légales et les soumet à l'équipe juridique :

  2. Je choisis les bons outils :

    • 💡 Info et recommandation pour la gestion des cookies : lien

  3. Je recense toutes les données traitées et les finalités qui leur sont associées [1 à 2h] :

  4. 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) :

  5. Organiser un atelier d'analyse de risques en suivant le guide Agile de l'ANSSI [1 demi-journée en équipe complète] :

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

A ne pas faire
  • 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.

🚀 Phase d'accélération

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)

Question à se poser
A faire
A ne pas faire
Question à se poser
  • Qui est le Responsable de la sécurité des systèmes d'information (RSSI) dans mon administration ?

A faire
  1. Je reviens sur les actions des phases précédentes, en répète certaines (atelier risques) et mets à jour les documents correspondants ;

  2. A partir du livrable de l'atelier risques, je constitue un dossier d'homologation de sécurité :

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

  4. [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.

A ne pas faire
  • 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 !