Concevoir une application sans mot de passe : l’architecture No-Auth de Covoit-Facile
Comment concevoir une application web collaborative sans contraindre l'utilisateur à créer un compte, tout en maintenant sécurité et simplicité d'usage.
Lorsque j'ai conçu Covoiturage Facile, la première décision d'architecture a été radicale : aucun système de compte utilisateur, aucun mot de passe, aucun identifiant à mémoriser.
Dans cet article, je vous explique pourquoi ce choix est pertinent pour ce type d'outil, et comment le mettre en œuvre techniquement en toute sécurité.
Le constat : la friction tue l'adoption
Pour un évènement ponctuel (un mariage, un week-end associatif, une compétition sportive), obliger 40 personnes à :
- Télécharger une application,
- Renseigner un e-mail et un mot de passe complexe,
- Valider un lien d'activation reçu par mail (souvent dans les spams),
- Se reconnecter…
… conduit inévitablement à un taux d'abandon supérieur à 50%. Les gens finissent par s'organiser par messages désordonnés sur WhatsApp ou SMS.
L'approche par jeton de capacité (Capability URLs)
Au lieu de vérifier l'identité d'un utilisateur par un cookie de session lié à un compte en base de données, nous utilisons le concept des Capability URLs (liens d'accès par jeton cryptographique aléatoire).
1. Le lien Organisateur vs le lien Participant
Lors de la création d'un évènement, le système génère deux clés distinctes à entropie élevée :
public class EventSecurityService
{
public static string GenerateSecureToken(int length = 32)
{
var bytes = new byte[length];
RandomNumberGenerator.Fill(bytes);
return Base64UrlTextEncoder.Encode(bytes);
}
}
- Le jeton d'administration (Organisateur) : Donné une seule fois à l'organisateur. Il permet de modifier l'évènement, d'ajouter/supprimer des trajets ou de clôturer l'évènement.
- Le jeton de consultation/participation (Public) : Partageable avec tous les invités. Il permet uniquement de déclarer un trajet de covoiturage ou de s'inscrire sur une place libre.
2. Comment protéger les inscriptions individuelles ?
Un conducteur souhaite pouvoir modifier le nombre de places dans sa voiture, ou annuler son trajet sans que n'importe qui d'autre puisse le faire.
Pour résoudre cela sans compte :
- Lorsqu'un utilisateur inscrit son véhicule, un jeton local (cookie sécurisé ou
localStorage) est stocké dans son navigateur. - Ce jeton lui accorde les droits d'édition sur *sa* fiche véhicule uniquement.
- S'il change d'appareil, un bouton « Lien de gestion personnel » lui permet de recevoir son lien direct par message.
Respect de la vie privée et conformité RGPD
Un autre avantage majeur de l'architecture sans compte est la minimisation des données :
- Aucune collecte d'adresses e-mail obligatoires.
- Pas de base d'utilisateurs centralisée susceptible d'être ciblée par des fuites de données d'identifiants.
- Rétention éphémère : Une fois la date de l'évènement passée (+ 30 jours), les données et les coordonnées associées sont automatiquement purgées par une tâche de fond planifiée.
Conclusion
L'architecture sans compte (No-Auth / Zero-Registration) n'est pas adaptée à tous les types de produits, mais pour les outils évènementiels et collaboratifs ponctuels, elle offre une fluidité d'usage imbattable et un soulagement considérable en matière de sécurité et de maintenance.