Logigrammes d’inscription et de connexion

L’inscription

1. Le visiteur envoie le formulaire (e-mail, mot de passe).
2. Décision : la saisie est-elle valide (format, règles de mot de passe) ? Non → afficher les erreurs.
3. Décision : l’e-mail est-il déjà inscrit ? Choisissez ce que vous révélez : beaucoup de services affichent un message neutre (« Consultez votre boîte de réception ») pour que l’inscription ne permette pas de savoir qui a un compte.
4. Le système crée le compte à l’état « non vérifié » et envoie un e-mail de vérification.
5. Attente : l’utilisateur clique sur le lien. Délai dépassé → relance, ou expiration du lien.
6. L’utilisateur vérifie → compte actif → fin.

La connexion

1. L’utilisateur saisit son e-mail et son mot de passe.
2. Décision : identifiants corrects ? Non → incrémenter le compteur d’échecs.
3. Décision : trop d’échecs ? Oui → bloquer ou ralentir les tentatives suivantes, prévenir l’utilisateur.
4. Décision : double authentification activée ? Oui → demander le code → valide ? Non → retour à la saisie du code, avec sa propre limite de tentatives.
5. Décision : compte vérifié ? Non → proposer de renvoyer l’e-mail de vérification.
6. Ouvrir la session → fin.

La réinitialisation du mot de passe

1. L’utilisateur demande une réinitialisation avec son e-mail.
2. Le système répond par le même message neutre, que le compte existe ou non.
3. Si le compte existe, il envoie un lien à usage unique qui expire.
4. L’utilisateur choisit un nouveau mot de passe → décision : lien encore valide ? → mise à jour du mot de passe, fermeture des autres sessions si c’est votre politique → fin.

Connexion via un autre fournisseur

Les boutons « Se connecter avec Google » et équivalents reposent en général sur OAuth 2.0 et OpenID Connect. Pour les applications web et mobiles, le flux « authorization code » avec PKCE est le schéma recommandé. Dans un logigramme, représentez-le comme un relais vers le couloir du fournisseur puis un retour, avec des branches « l’utilisateur annule » et « e-mail déjà lié à un autre compte ».

Les choix de sécurité sont des décisions

Longueur minimale du mot de passe, nombre de tentatives avant blocage, durée de validité des liens : ces règles apparaissent dans le schéma sous forme de décisions et de délais. En France, la CNIL publie des recommandations sur les mots de passe dont vous pouvez vous inspirer. Écrire ces seuils sur le schéma permet de les relire avec l’équipe sécurité.

Conseils pour ces schémas

• Des couloirs pour l’utilisateur, le frontend, le backend et le service d’e-mail ou d’identité : voir le logigramme en couloirs.
• Les limites et délais sur le schéma (5 tentatives, lien valable 24 h) ; chaque boucle a une sortie, comme dans conditions et boucles.
• Les endpoints sur les étapes automatiques, comme dans un workflow d’intégration d’API.

Décrivez votre parcours en quelques phrases et générez le logigramme, puis ajoutez les branches ci-dessus qui manquent.