[Création] Réflexion sur la création d'un usager même si mail déjà utilisé

[ClaireCasu]

Contexte et "bug" de départ

Comportement observé Situation rencontrée lors de l'import du fichier de ARCHER AIP - le 10 avril avec Quentin et Samantha. Nous avons tenté de créer un demandeur (avec un mail), alors que le conjoint existe déjà et contient un mail. Il y a une erreur, ce n'est pas possible de le créer. Autrement dit, si conjoint créé d'abord avec un mail, demandeur ne peut pas être créé

Comportement souhaité Même si le conjoint a déjà été créé avec un mail, il faudrait pouvoir créer le demandeur aussi avec le même email.

Solution - Etude de faisabilité

Etudier la faisabilité (et présenter les avantages / inconvénients) d'une solution qui permettrait de créer un usager avec un mail déjà utilisé par RDV S.

[Michaelvilleneuve]

@ClaireCasu Je me demande si ce bug n'a pas été résolu par un des fixs qu'on a fait récemment. De mon côté je parviens bien à créer les deux malgré le même mail + numéro de téléphone + nom de famille

[ClaireCasu]

Je tente de reproduire mais je crois qu'ici ce qui était important c'est d'avoir le même numéro CAF (pour jouer sur conjoint/demandeur)

[aminedhobb]

Contexte

Pour rappel, rdv-i a mis en place plusieurs règles permettant de prévenir la création de doublons dans l'application. Ces règles sont importantes car un département ne veut pas avoir deux fiches avec des suivis distincts pour deux mêmes usagers.

Voici un schéma rappelant les principales règles de matching à la création de l'usager et les règles de validation à chaque sauvegarde d'usager (création ou modification):

À côté de ça nous avons une règle sur rdv-s qui ne permet pas de créer deux personnes avec la même adresse email. Pour contourner ce problème nous procédons de la façon suivante:

Pour les couples de bénéficiaires du RSA qui partagent les mêmes infos de contacts, on crée la fiche du conjoint sans le mail dans rdv-solidarités. Le conjoint devra cependant remplir son mail obligatoirement lors de la prise du rdv (qui doit évidemment être différent de celui du demandeur)

Voici alors le flow qui représente la création d'un usager sur rdv-sp :

Différents problèmes rencontrées lors de la création d'usagers

Nous avons plusieurs cas qui peuvent être embêtants pour nos utilisateurs où la création de l'usager ne fonctionne pas. Je répertorie ci-dessous différents cas de figure que j'ai pu relever soit en regardant les mails nous alertant sur ces problèmes, soit au niveau des logs de l'API pour voir les différentes occurrences de ce problème pour les Bouches-du-Rhône. Cette liste n'est pas exhaustive mais regroupe déjà une bonne partie des cas rencontrés:

• Des demandeurs/conjoints sont créés avec les mêmes données de contacts mais sans renseigner le rôle correctement => L'adresse mail n'est pas filtrée pour le conjoint lors de la création sur rdv-s, on a donc une erreur rdv-s disant que l'usager existe déjà sur rdv-s et qu'il est rattaché à un usager sur rdv-i (= la première personne du couple créée)

• Un demandeur est créé après le conjoint mais le conjoint a entre temps eu le temps de renseigner l’adresse du couple dans rdv-sp => on a une erreur disant que l'usager existe déjà sur rdv-s et qu'il est rattaché à un usager sur rdv-i

• Le rôle n'est pas consistant d'une fois à l'autre => le matching ne se fait pas correctement et on a une erreur

• Des personnes partagent la même adresse email (pas le même prénom) mais n'ont pas le même numéro CAF/rôle => L'adresse n'est pas filtré lors de la création sur rdv-s, on a donc une erreur rdv-s disant que l'usager existe déjà sur rdv-s et qu'il est rattaché à un usager sur rdv-i

• Il se peut (cas rare je pense) que l'on trouve un doublon par numéro CAF + rôle et un autre différent par adresse mail + prénom. On a donc une erreur au moment d'enregistrer l'usager (le matching se fait sur l'un mais on détecte le doublon de l'autre au moment de la sauvegarde)

• Le prénom n'est pas épelé de la même manière d'un enregistrement à l'autre => Le matching sur mail + prénom ou tel + prénom ne se fait pas => On a une erreur une erreur rdv-s disant que l'usager existe déjà sur rdv-s et qu'il est rattaché à un usager sur rdv-i

• Des personnes sont enregistrées sans les données de contacts, puis lorsqu'on enregistre les données de contacts on se rend compte que des personnes avec ce mail + prénom (ou tel + prénom) existent déjà dans l'appli. Comme le matching avec l'usager existant ne s'est pas fait lors de la création de l'usager, on a une erreur au moment de sauvegarder la personne

Proposition de solution

Première solution

Numéro CAF/rôle

On remarque dans les problèmes évoqués ci-dessus que ce qui revient le plus souvent est le mauvais renseignement du numéro CAF/rôle. Sachant cela, et sachant que l'identification via Numéro CAF + rôle a été mise en place quand on ne faisait pas de matching sur d'autres données (NIR, email, tel), je propose tout simplement d'abandonner le matching sur ces données-là. Ainsi, pour éviter les doublons sur rdv-i on se fiera uniquement sur le NIR, l'ID interne, le mail + prénom et le tel + prénom

Adresse email sur rdv-s

Pour éviter les erreurs venant du fait que l'on ne puisse pas créer deux usagers avec la même adresse email, on peut envisager trois solutions possibles (dépend des plans de rdv-sp):

• Soit on enlève cette règle d'unicité sur les adresses email. Demande probablement beaucoup d'effort sur la refonte de l'archi interne de rdv-sp mais peut intéresser l'équipe rdv-sp
• Soit on introduit un nouveau champ du type contact_email au niveau des usagers sur rdv-sp, qui servira uniquement d'adresse pour envoyer des notifications à l'usager dans le cas où il n'a pas d'email renseigné. Il n'y aura donc pas de contraintes d'unicité sur ce nouveau champ.
• Soit on ne fait aucun changement sur rdv-sp et on crée les usagers rdv-sp depuis rdv-i sans adresse email. On laisse les usagers renseigner l'email au moment de la prise de rdv. Cependant il ne faudra pas forcer le renseignement de l'adresse mail par l'usager, parce que si l'email est déjà pris ça bloquerait la prise de rdv

Avantages

• Potentiellement simple à mettre en place
• Rend l'appli beaucoup plus flexible et moins complexe
• Les numéros CAF/rôle n'ont plus qu'un rôle informatif
• Evite des cas de faux matching quand le rôle n'est pas renseigné
• Ne force plus le conjoint à rentrer une adresse mail différente de celle du demandeur lors de la prise de rdv

Inconvénients

• Si l'utilisateur de rdv-i utilisait le numéro CAF + rôle et ne renseignait pas de NIR ou d'ID interne, la prévention de doublon est moins robuste (car dépendante du prénom) et est même impossible sans données de contacts non plus
• Un usager ne pourrait plus se connecter à son compte rdv-sp et consulter sa liste de rendez-vous (aujourd'hui un usager invité sur rdv-i qui a pris rdv en autonomie peut se connecter sur rdv-sp en cliquant sur "se connecter" -> "mot de passe oublié")
• Cette solution ne répond pas aux deux derniers problèmes citées dans la partie 2
• Il pourrait y avoir des effets de bord que l'on anticipe pas

[ClaireCasu]

Hello, j'ai pris le temps de lire le document, merci beaucoup, c'est clair.

• L'absence de prévention de doublon pour les usagers sans données de contact me semble dangereuse (- mais en regardant les chiffres je vois que ça ne concerne pas grand monde).
• Pour le côté rdv-sp, si on prend la solution 2, comment on gère le contact_email par rapport à l'email normal? C'est par défaut le même et si 2 usagers ont le même mail on enlève l'email normal pour une des deux personnes?
• J'apporte quelques comptages pour essayer de comprendre la réalité des variables identifiantes. Il y a vraiment très peu de monde avec juste le couple "CAF+rôle". On pourrait imaginer d'adapter notre discours pour la suite en explicitant qu'une des variables identifiantes (parmi la liste) est obligatoire?

[amaurydubot]

Je ferme ce ticket : tout la réflexion d' @aminedhobb est documentée dans Notion. Par ailleurs, il y a désormais le ticket #2065.