Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reparer reconciliation sur email pour FranceConnect #1237

Closed
adipasquale opened this issue Mar 15, 2021 · 1 comment
Closed

reparer reconciliation sur email pour FranceConnect #1237

adipasquale opened this issue Mar 15, 2021 · 1 comment
Assignees
Labels
Bug 🔴 bug .M taille "medium"

Comments

@adipasquale
Copy link
Contributor

adipasquale commented Mar 15, 2021

cf https://sentry.io/organizations/rdv-solidarites/issues/2244974663/?environment=production&project=1811205&query=is%3Aunresolved

direction adoptée : créer un nouveau compte usager, au risque de creer des comptes doublons on ne prend pas le risque de reconcilier des comptes a tort.

@adipasquale adipasquale added the Bug 🔴 bug label Mar 15, 2021
@adipasquale adipasquale added this to To do in Déploiement en production via automation Mar 15, 2021
@adipasquale adipasquale moved this from To do to In progress in Déploiement en production Mar 25, 2021
@adipasquale adipasquale added the .M taille "medium" label Mar 25, 2021
@adipasquale adipasquale self-assigned this Mar 25, 2021
@adipasquale
Copy link
Contributor Author

adipasquale commented Mar 25, 2021

report de la discussion Slack en vrac:

Adrien Di Pasquale Aujourd’hui à 10 h 42
est-ce que ca vous paraitrait OK de faire la reconciliation usagers FranceConnect sur base d’un match exact sur prénom + nom d'usage + date de naissance
c’est a dire :
un agent créé un compte usager avec prenom nom et date de naissance mais sans email
puis l’usager essaie de se connecter via FC et ca matche le compte ^
on associe l’usager au compte créé par l’agent
aujourd’hui ca echoue sur une erreur pas belle car on gere mal ce cas, et je ne suis pas sur du bon fix.
l’autre direction serait de creer un deuxieme compte usager dissocié en se disant que ce n’est pas assez fiable comme match (on est censés matcher sur plus de champs)
46 réponses
Yannick il y a 6 heures
La date de naissance me semble un point clef oui. Je me demande si ça ne devrait pas être un champ obligatoire. C'était demandé à une époque, nous avons repoussé pour ne pas tomber dans le schéma de l'informatique de gestion avec plein de champs obligatoire, mais là, ça défini une identité j'ai l'impression.
Adrien Di Pasquale il y a 6 heures
selon FC on ne peut faire la réconciliation auto que sur base de :
Nom de naissance
Prénoms
Sexe
Date de naissance
Code géographique INSEE de la ville de naissance
Code géographique INSEE du pays de naissance
Adrien Di Pasquale il y a 6 heures
(cependant on la fait déjà sur base de l’email tout seul ce qui est une grosse enfreinte)
Yannick il y a 6 heures
ok
Yannick il y a 6 heures
ça fait peut-être beaucoup d'ajouter tout ça ?
Yannick il y a 6 heures
En tout cas pour le moment...
Adrien Di Pasquale il y a 6 heures
oui oui c’est pas le but de cette discussion
Yannick il y a 6 heures
bonjour le RGPD aussi :perplexe:
Yannick il y a 6 heures
oui, pardon, c'est moi qui fait dérivé.
Yannick il y a 6 heures
En tout cas, ça me parait pas mal de faire un match exact.
Yannick il y a 6 heures
Le hic c'est que si l'orthographe n'est pas exactement la même ça va faire des doublons, c'est bien ça ?
Adrien Di Pasquale il y a 5 heures
oui mais toujours pas ma question :) je ne veux même pas lancer la discussion sur le fuzzy matching - je demande si ça vous parait ok déjà en cas de match exact sur ces trois champs, ce qui serait une enfreinte supplémentaire à FC mais en même temps me paraît raisonnable
Yannick il y a 5 heures
moi ça me parait ok
👍
1

Adrien Di Pasquale il y a 5 heures
@thomas un avis sur la question ?
Yannick il y a 5 heures
Je réponds ça, mais je manque d'élément de contexte je crois. Ça parait ok vis à vis de quoi ? Parce qu'aujourd'hui on fait quoi ?
Adrien Di Pasquale il y a 5 heures
aujourd’hui ca echoue avec une 500 les usagers ne peuvent pas se connecter a FC dans ce cas (compte preexistant avec match exact sur ces 3 champs) (modifié)
Adrien Di Pasquale il y a 5 heures
ma question c’est est-ce que ca vous parait ok d’enfreindre une fois de plus les recos FC dans le but d’eviter un certain nombre de comptes doublons
Yannick il y a 5 heures
Au moment de la connexion avec FC, si le compte existe déjà avec prénom, nom et date de naissance identique, ça fait une 500 ?
Adrien Di Pasquale il y a 5 heures
oui => https://sentry.io/organizations/rdv-solidarites/issues/2244974663/events/?environment=production&project=1811205 (modifié)
Yannick il y a 5 heures
(désolé de faire le boulet qui comprend pas)
Yannick il y a 5 heures
Ok, c'est clair pour moi. et je confirme que ça me conviens.
Adrien Di Pasquale il y a 5 heures
:parfait: merci et déso si c’était pas clair
Thomas il y a 4 heures
:pensif: la question que je me pose c'est le risque d'usurpation/vol des données avec cette réconciliation.
Thomas il y a 4 heures
Je laisserais bien la main aux agents pour ne pas prendre de responsabilités.
Thomas il y a 4 heures
@adrien Di Pasquale le problème c'est lorsqu'il nous manque une adresse email « d'un côté » ?
Thomas il y a 4 heures
(Dispo pour échanger de vive voix)
Adrien Di Pasquale il y a 3 heures
Il n’y a pas de “probleme” bloquant, on peut tout a fait laisser France Connect créer un deuxieme compte usager avec le meme prenom nom d’usage et date de naissance, puis esperer que les agents feront les de-duplications eux memes. a mon avis on degrade l’UX usager et agent dans 99%+ des cas concernés en faisant ca, mais on a aucun trou de sécurité et on n’enfreint pas (plus qu’aujourd’hui) les recommendations FC
L’adresse email n’entre pas en jeu dans ce cas.
Thomas il y a 2 heures
Perso, je ne suis pas à l'aise avec un match automatique. Cela dit il faut corriger l'existant et permettre aux usagers de se créer un compte, qui pourra être associé manuellement par un agent.
Thomas il y a 2 heures
À ce titre les expérimentations data.insertion vont être intéressantes et sera peut-être un moyen d'améliorer les UX mais avec les 100kRDV et l'accroissement de l'usage de la plateforme, les cas particuliers vont se multiplier et le risque (évalué au doigt mouillé) d'une mauvaise consolidation de compte me parait trop important.
Yannick il y a 2 heures
ceci étant, ça fait beaucoup de taf supplémentaire pour les agents aussi :pensif:
:pensif:
1

Yannick il y a 2 heures
ou alors, il faut ajouter les outils manquant (qui fait qu'aujourd'hui illes ne se servent pas de la fusion, ou très peu)
Yannick il y a 2 heures
la page de « détection de potentiel doublon »
Adrien Di Pasquale il y a 2 heures
:parfait: bien recu thomas, ca me va aussi d’etre “frileux”
Thomas il y a 2 heures
Pourquoi ça fait beaucoup de taff pour les agents ? Le problème dans Sentry n'est apparu que 70x.
Adrien Di Pasquale il y a 2 heures
il faudra cependant s’inquieter dans ce cas de notre “faille” actuelle de reconciliation auto sur base de l’email unique.
Yannick il y a 2 heures
Je clarifie : si on laisse les agents se « démerder » pour détecter et fusionner les comptes usagers, ça fait 70x un travail de détection d'un potentiel doublons (aujourd'hui, à la main) + le travail de fusion (aidé par l'outil)
Thomas il y a 2 heures
Actuellement, la reconciliation est faite après validation de l'accès à l'email ? (modifié)
Adrien Di Pasquale il y a 2 heures
non avant il n’y a pas de validation d’acces a l’email dans ce cas (modifié)
Thomas il y a 2 heures
Dans quel cas ? :sueur_et_sourire:
compte ordinaire puis compte FC ? (là j'imagine que le compte ordinaire est passé par une validation de l'email)
compte FC puis compte ordinaire (là ça serait bien que la réconciliation soit faite après validation de l'email sinon un méchant connaissant une personne s'étant connectée avec FC pourrait avoir accès à ces infos en "recréant" un compte avec les mêmes infos, non ? :pensif: )
Adrien Di Pasquale il y a 2 heures
cette discussion parle uniquement du cas 1 : compte ordinaire existant puis connexion via FC avec les mêmes infos (ici email) (modifié)
:parfait:
1

Adrien Di Pasquale il y a 2 heures
Le compte ordinaire est effectivement passé par une validation de l’email mais ça peut être le “vrai utilisateur” qui l’a faite, tandis que le hacker serait celui qui arrive via FC
C’est pour ça que je disais qu’il n’y a pas de validation de l’email dans ce cas (ce cas == le moment de la connexion via FC)
:parfait:
1

Thomas il y a 2 heures
Et là la proposition c'est dans les cas où
il n'y a pas d'email dans le compte existant ?
l'email est différent connu est différent de celui dans FC ?
Adrien Di Pasquale il y a une heure
L’email n’a pas d’importance ici. s’il y a le même email ça fusionne forcément, donc on est dans le reste des cas : les emails sont différents ou absents d’un côté ou absents des deux côtés.
Le cas c’est : il y a match exact sur nom d’usage + prénom + date de naissance. Aujourd’hui on a un check “qui fait du zèle” pour éviter les doublons, qui déclenche une 500.
on a deux pistes pour corriger la 500 :
on décide que ça équivaut à identité -> on fusionne les comptes == on authentifie la personne connectée via FC au compte existant
on décide que ça n’équivaut pas à identité => on créé un nouveau compte usager avec les mêmes 3 infos
(modifié)
Thomas il y a une heure
Merci beaucoup pour ces éléments de clarification. Je pense que le plus sage c'est d'éviter les fusions hâtives. :visage_froid:
Adrien Di Pasquale il y a une heure
:parfait: ca marche ! merci a toi d’avoir pris le temps
:prière:
1

Yannick il y a une heure
Merci pour ces questions et clarification. J'ai augmenté mon niveau de connaissance / compréhension du problème :homme_qui_salue:

@yaf yaf closed this as completed Apr 15, 2021
Déploiement en production automation moved this from In progress to Done Apr 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug 🔴 bug .M taille "medium"
Projects
No open projects
Development

No branches or pull requests

2 participants