Page vie privée

[johanricher]

Les mentions relatives à l’utilisation des données personnelles et à la gestion des cookies doivent être visibles sur le site.

Exemples :

• api.gouv.fr
• Annuaire des entreprises

Tâches

• @johanricher Ecrire contenu : https://pad.incubateur.net/aE48U2ZvSdmILJjE7T0aBQ
• @florimondmanca Relire draft
• Add "Vie privée" #496
  • Implémenter le contenu dans une nouvelle page catalogue.data.gouv.fr/vie-privee
  • Ajouter lien dans le footer

[johanricher]

Premier draft : https://pad.incubateur.net/aE48U2ZvSdmILJjE7T0aBQ

[florimondmanca]

Quelques commentaires :

• Ce site a été conçu de telle façon à réduire au minimum la collecte et le traitement des données à caractère personnel.

  Je dirais "de façon à minimiser la collecte". En effet "Réduire au minimum" est un peu ambigu, on pourrait comprendre "on n'a pas trop réduit la collecte", c'est-à-dire "maximiser", non ?

• catalogue.data.gouv.fr ne collecte pas les données suivantes : ...

  Est-il utile de préciser ce qu'on ne collecte pas, sachant qu'on dit la ligne au-dessus "Les seules informations collectées sont : ..." ?

• Il n'y a pas de mention des cookies Mon Compte Pro, mais c'est bel et bien mentionné dans leurs CGU (partie 3 - Modalités d'utilisation du Service), donc ça peut être OK. Mais je reformulerais en indiquant qu'on peut trouver dans le CGU des infos complémentaires sur ce qui est collecté par Mon Compte Pro :

  Le service Mon Compte Pro peut être amené à collecter ou traiter des données personnelles pour son propre fonctionnement. Pour plus d'informations, consulter les Conditions générales d’utilisation de Mon Compte Pro."

[johanricher]

Je dirais "de façon à minimiser la collecte". En effet "Réduire au minimum" est un peu ambigu (...)

"Minimiser" signifie juste "réduire". On perd l'idée qu'on a réduit le plus possible. J'ai repris la formulation dans le RGPD concernant ce qu'on appelle communément le "privacy by design" ;

le responsable du traitement devrait adopter des règles internes et mettre en œuvre des mesures qui respectent, en particulier, les principes de protection des données dès la conception et de protection des données par défaut. Ces mesures pourraient consister, entre autres, à réduire à un minimum le traitement des données à caractère personnel (...)

Est-il utile de préciser ce qu'on ne collecte pas (...) ?

Non, pas nécessaire en effet. Pour l'instant ça permet peut-être entre nous d'expliciter et vérifier ce qu'on collecte ou pas. Vous confirmez la liste ? par exemple l'adresse email il me semble en fait qu'on la traite puisqu'on l'affiche dans le header en mode connecté. On en a pas besoin (envoi de mails) donc on ne devrait pas la traiter (récupérer, stocker, afficher) mais pour l'instant on la traite.

Mon point c'est qu'on doit faire la liste des données personnelles qu'on traite, notamment celles qu'on récupère depuis MCP.

Ok pour ta reformulation.

[florimondmanca]

Ah, "réduire à un minimum" c'est parfait 👍

Vous confirmez la liste ? par exemple l'adresse email il me semble en fait qu'on la traite puisqu'on l'affiche dans le header en mode connecté. On en a pas besoin (envoi de mails) donc on ne devrait pas la traiter (récupérer, stocker, afficher) mais pour l'instant on la traite.

Oui, on collecte l'email et elle est en fait essentielle puisqu'à ce jour elle sert d'identifiant unique (pas visible dans le cas Mon Compte Pro mais bien réel en base et dans la logique du code : on n'a qu'un seul compte si on a une adresse mail liée à un PasswordUser ou un DataPassUser, par exemple).

Par contre on ne traite pas d'ID Mon Compte Pro (on a notre propre ID en base et Mon Compte Pro ne l'expose pas dans son endpoint par défaut).

À l'avenir, on pourrait peut-être en effet cantonner l'usage d'un email au seul mécanisme d'authentification email/mdp ("legacy"), car en effet d'un point de vue purement logique, on n'en a pas l'utilité actuellement. On devrait pouvoir ne traiter qu'un ID et un "display name". Edit : j'ai ouvert #486 pour explorer ce point. En fait ça dépend de ce que Mon Compte Pro expose quand on ajoute le scope profile.

[johanricher]

Ok merci d'avoir ouvert ce ticket, ça permet d'envisager de réduire encore un peu le volume de données personnelles qu'on traite.

Par contre on ne traite pas d'ID Mon Compte Pro (on a notre propre ID en base et Mon Compte Pro ne l'expose pas dans son endpoint par défaut).

Comment on récupère depuis l'API MCP les données d'un user (SIRET, adresse email) si c'est pas à partir de son ID ? Autre façon de poser la question : on ne stocke pas pour chaque user un mapping entre ID catalogue.data.gouv.fr et ID MCP ?

[florimondmanca]

Comment on récupère depuis l'API MCP les données d'un user (SIRET, adresse email) si c'est pas à partir de son ID ?

C'est possible grâce au protocole OpenID Connect utilisé par MonComptePro. Dans ce protocole on demande des scopes (ici openid, email), l'utilisateur s'authentifie puis le serveur renvoie un code qui permet d'accéder à un endpoint GET /userinfo. C'est là que l'on récupère email et organisations.

Et donc non il n'y a pas de mapping. De toute façon on ne pourrait pas puisque MonComptePro ne nous fournit pas "d'ID MonComptePro" (le userinfo ne contient littéralement que email et orgs). On stocke un Account (comprenant email, role, api_token), et une entrée dans la table DataPassUser qui ne contient que le account_id et sert à savoir que cet utilisateur s'est connecté avec MonComptePro (éventuellement au terme d'une sélection de l'orga, ou d'avoir demandé la création de son orga, etc - ce qu'on ne refait pas plusieurs fois).

[johanricher]

Ok c'est top, merci pour ces précisions. J'ai mis à jour le pad. A priori il est complet ?

[florimondmanca]

Oui, en tout cas ce qui y est écrit me semble correct !