For the English version, please check the page below:
Avec Decidim, nous héritons d'un système d'authentification en deux parties : comptes et autorisations.
Un compte est un utilisateur — il possède un nom, un pseudonyme, un email, et un mot de passe.
Une autorisation est la permission d'effectuer une action sur la plateforme. En général, l'autorisation est obtenue si l'on fait partie d'un "recensement", en saisissant un numéro de téléphone, en fournissant une photo de carte d'identité, ou toute autre chose certifiant son identité.
Cependant nous avons modifié, changé et détourné ces deux systèmes depuis que nous avons commencé à utiliser Decidim, car nos clients avaient des demandes précises. Pour le compte, nous avons créé des champs d'inscription supplémentaires qui permettent d'ajouter des champs à l'inscription ou encore le module Friendly Signup qui a éliminé le besoin de saisir plusieurs fois le mot de passe, de choisir un pseudonyme, etc. En ce qui concerne les autorisations, nous les avons détournées pour collecter des informations supplémentaires auprès des porteurs de projets ou des votants, que nous avons ensuite récupéré via notre outil de BI et de visualisation.
Ces personnalisations de modules proviennent principalement des demandes des clients qui souhaitent collecter des informations sur les utilisateurs ou restreindre/sécuriser certaines actions sur la plateforme. C'est une demande légitime, bien que cela conduise souvent à une qualité d’UX réduite et à beaucoup de dette technique. Nous avons plusieurs modules dédiés à différentes versions de l'authentification, et certains de ces modules sont divisés en plusieurs branches radicalement différentes. Voici un résumé des problèmes que rencontrent ces modules :
En plus, voici certaines demandes auxquelles nous ne pouvons pas répondre :
Par conséquent, la situation de l'authentification n'est pas optimale malgré des avancées très intéressantes, notamment Friendly Signup et les champs supplémentaires à l'inscription. Le défi majeur reste de pouvoir répondre aux nombreuses méthodes d'authentification différentes sans créer un module unique pour chaque plateforme, sans refuser systématiquement toutes les demandes des clients, et sans sacrifier l'expérience utilisateur.
La réponse que nous proposons résulte d'une cartographie de plusieurs demandes clients que nous avons vues en équipe, les cas étant un école d’ingénieurs, une métropole française et une mégalopole américaine, mais ce ne sont pas les seuls cas où nous avons dû faire des authentifications personnalisées. Voici les trois exemples :