La vérification par e-mail ne fonctionne pas : corriger liens, tokens et logique de renvoi

À quoi ressemble une vérification cassée

Quand la vérification par e-mail ne fonctionne pas pendant l’inscription, ce n’est rarement propre ou évident. Les utilisateurs se sentent simplement bloqués. Ils se sont inscrits, ont fait ce que vous demandiez, et votre app dit toujours qu’ils ne sont pas vérifiés.

L’expérience la plus commune est le silence : aucun e-mail n’arrive. Les gens vérifient le spam, attendent quelques minutes, appuient sur renvoyer, puis abandonnent. D’autres reçoivent un e-mail, mais le bouton mène à une page blanche, une erreur inquiétante, ou une redirection vers l’écran de connexion sans explication.

La pire version est la boucle :

“Veuillez vérifier votre e-mail” -> “Renvoyer” -> “E-mail envoyé” -> clic -> toujours “Veuillez vérifier votre e-mail.”

Voici les schémas que les utilisateurs signalent généralement (souvent avec captures d’écran et frustration) :

• Aucun e-mail de vérification n’arrive (ou il arrive plusieurs heures plus tard)
• Le lien s’ouvre mais affiche « Token invalide » ou « Lien de vérification expiré »
• Le lien fonctionne une fois, puis plus jamais, même pour une nouvelle inscription
• Après vérification, l’app continue de les traiter comme non vérifiés
• Le renvoi semble fonctionner, mais seulement le plus récent ou seulement l’ancien e-mail fonctionne (pas les deux)

Ce n’est pas seulement quelques inscriptions bloquées. Chaque flow de vérification cassé génère des tickets support, des remboursements et de mauvaises critiques. Cela crée aussi un risque : si le renvoi peut être déclenché en masse, votre système peut envoyer des milliers d’e-mails rapidement, ce qui nuit à la délivrabilité et ressemble à du spam.

Les flows d’onboarding générés par IA cassent souvent parce que les pièces sont collées avec des hypothèses de chemin heureux. Causes courantes : tokens stockés en mémoire plutôt que dans une base, liens construits avec le mauvais domaine, état de vérification non sauvegardé de façon fiable, ou un bouton de renvoi qui crée un nouveau token sans invalider l’ancien.

L’objectif est simple : la vérification doit être fiable pour les vrais utilisateurs (y compris ceux qui cliquent l’e-mail sur un autre appareil), claire quand quelque chose ne va pas, et assez stricte pour qu’on ne puisse pas l’abuser. Si vous avez hérité d’un prototype généré par IA depuis des outils comme Lovable, Bolt, v0, Cursor ou Replit, ces problèmes sont courants et généralement réparables avec un audit ciblé et quelques changements soigneux.

Symptômes courants à reconnaître rapidement

Certaines erreurs de vérification sont bruyantes (erreur claire). D’autres sont silencieuses et ne se manifestent que par « les gens ne peuvent pas s’inscrire ». La manière la plus rapide de déboguer est de nommer le symptôme exact, car chacun pointe vers une couche différente.

1) L’e-mail n’arrive jamais

Si les utilisateurs disent que l’e-mail manque, ne supposez pas que votre app ne l’a pas envoyé. Souvent elle l’a fait, mais le fournisseur l’a bloqué, il a atterri en spam, ou il est allé à la mauvaise adresse.

Signes typiques : seuls certains domaines échouent (par exemple boîtes mail d’entreprise), les messages apparaissent en spam, ou rien n’apparaît dans les logs du fournisseur d’e-mails. Vérifiez aussi les bases : faute de frappe dans l’adresse, domaine expéditeur incorrect, ou variables d’environnement qui pointent encore vers un service d’e-mail de test en production.

2) Le lien s’ouvre mais affiche « invalide » ou « expiré »

C’est la plainte classique « la vérification par e-mail ne fonctionne pas ». Cela signifie généralement que le token dans l’URL ne correspond pas à ce que votre backend attend, ou que votre logique d’expiration est trop stricte.

Patrons courants :

• Le token est mal encodé dans l’URL.
• Votre backend hache les tokens mais les compare en clair.
• Vous faites tourner les secrets entre déploiements, donc les tokens précédemment émis ne peuvent jamais se valider.
• Dérive d’horloge ou logique de fuseau horaire marque les tokens comme immédiatement expirés.

3) Le lien dit vérifié, mais l’utilisateur n’est toujours pas connecté

Les utilisateurs cliquent sur le lien, voient un message de succès, puis sont renvoyés vers un écran de connexion comme si rien ne s’était passé.

Cela arrive quand la vérification et la connexion sont traitées comme des étapes séparées alors que l’UI laisse entendre qu’elles sont liées. Autres causes courantes : cookies de session non définis (mauvais domaine, flags secure manquants, cookies tiers bloqués), ou le endpoint de vérification met à jour la base mais le frontend utilise un état utilisateur obsolète.

4) Le renvoi fonctionne, mais les anciens liens fonctionnent encore (ou rien ne fonctionne)

Les flows de renvoi se comportent souvent bizarrement dans les onboarding générés par IA. Vous pouvez voir des renvois qui génèrent sans cesse de nouveaux e-mails tandis que chaque lien reste valide pour toujours, ou l’inverse où chaque nouvel e-mail échoue instantanément.

Un flux de renvoi fiable a besoin d’une règle claire : un nouveau token invalide-t-il l’ancien, ou bien n’importe quel token actif fonctionne-t-il ?

• Si vous ne révoquez pas les anciens tokens, des attaquants peuvent utiliser n’importe quel lien divulgué.
• Si vous révoquez trop agressivement sans prévenir l’utilisateur, il cliquera un e-mail antérieur et verra « expiré » alors qu’il vient de demander un renvoi.

5) Comptes multiples, doublons et conditions de course

Les clics répétés et les tentatives d’inscription répétées peuvent créer des cas limites : deux lignes utilisateur pour le même e-mail, un flag vérifié qui bascule d’un côté à l’autre, ou des erreurs « déjà vérifié » qui ne débloquent pas la connexion.

Cherchez des races comme : un utilisateur s’inscrit deux fois avant que la première vérification ne soit complétée, deux requêtes de vérification s’exécutent en même temps, ou un renvoi crée un second enregistrement en attente. Cela apparaît surtout avec des utilisateurs impatients sur mobile qui tapent plusieurs fois le lien.

Si ces symptômes apparaissent ensemble, cela signifie souvent que le flow a été assemblé à partir de bouts de code sans source unique de vérité pour les tokens, l’expiration et l’état utilisateur.

Où se logent généralement les défaillances (livraison, app, base)

Quand la vérification par e-mail ne fonctionne pas, les équipes commencent souvent par toucher la mauvaise couche. Traitez-le comme une course de relais : le fournisseur d’e-mails doit livrer le message, l’app doit accepter le clic, et la base doit enregistrer le nouvel état.

Scindez le problème en trois zones

La plupart des pannes correspondent à une de ces zones :

• Livraison : l’e-mail n’arrive pas, atterrit en spam, ou le client mail modifie le lien (wrapping, troncature, réécriture « safe-link »)
• App : le endpoint de vérification rejette la requête, le frontend affiche le mauvais message, ou le endpoint vérifie mais l’UI reste bloquée
• Base : l’enregistrement du token manque ou est écrasé, les timestamps sont erronés, ou le flag vérifié de l’utilisateur ne se met jamais à jour

Commencez par une question simple : le clic a-t-il atteint votre backend ? Si vous avez une entrée de log serveur pour la requête de vérification, la livraison est probablement correcte et le problème est dans l’app ou la base.

Le changement d’état doit se produire côté serveur

Un bug courant dans les onboarding générés par IA : le frontend fait croire que la vérification a réussi (affiche un écran de succès) mais aucun changement d’état backend n’a lieu. La vérification doit être une action serveur qui met à jour des enregistrements réels : statut utilisateur, token marqué comme utilisé ou non, et l’heure.

Votre modèle de base devrait répondre clairement à ces questions :

• À quel utilisateur ce token appartient-il ?
• Quand a-t-il été créé et quand expire-t-il ?
• A-t-il déjà été utilisé ?
• Quel est le statut de vérification actuel de l’utilisateur ?

Si l’un de ces éléments manque, vous verrez des comportements instables comme « fonctionne une fois », « ne fonctionne que sur mobile », ou « continue d’afficher lien expiré ».

Mismatches d’environnement (dev vs prod)

Même quand le code est correct, les paramètres peuvent changer le comportement entre environnements. Un backend peut générer des liens avec le mauvais host, ou utiliser des secrets différents pour signer les tokens en production. Un autre classique : la prod exécute plusieurs instances, mais les tokens sont stockés en mémoire, donc la moitié des requêtes ne peut pas les valider.

Si vous avez hérité d’un prototype généré par IA (Lovable/Bolt/v0/Cursor/Replit), la cause racine est souvent plusieurs petits décalages entre livraison, app et base qui n’apparaissent qu’en production.

Erreurs de liens et de tokens qui cassent la vérification

Quand la vérification par e-mail ne fonctionne pas, le bug n’est souvent pas dans l’e-mail lui-même, mais dans la création, le stockage et la vérification du token.

Un lien de vérification n’est fiable que si les règles entourant son token le sont. Si ces règles sont vagues (ou inexistantes), vous obtenez des échecs aléatoires pour de vrais utilisateurs et des abus faciles pour les attaquants.

Erreurs de token qui cassent silencieusement le flux

Voici les problèmes que l’on retrouve le plus dans du code d’onboarding généré par IA :

• Le token n’est pas stocké côté serveur, donc l’app ne peut pas le valider ensuite. Certains prototypes mettent le token dans l’état client (localStorage) et le comparent à lui-même, ce qui ne prouve rien.
• Le token fuit dans les logs. Si vous loggez des URL complètes ou des corps de requête, votre token peut finir dans les logs serveur, analytics, outils d’erreurs ou captures support.
• Le token est stocké en clair. Si votre base fuit, des attaquants peuvent immédiatement vérifier des comptes. Pattern plus sûr : stocker un digest haché du token, comme pour un mot de passe.
• L’expiration est mal réglée. Trop courte et les retards normaux causent « lien expiré ». Jamais d’expiration et les vieux liens fonctionnent pour toujours.
• Le token est lié à la mauvaise chose. Discordance fréquente : le token est généré pour un user_id, mais l’endpoint cherche par e-mail, ou le lien pointe vers le mauvais hôte API.
• L’endpoint ne vérifie pas la finalité et l’état. Un token doit être valide uniquement pour une finalité (vérifier l’e-mail) et seulement quand le compte n’est pas déjà vérifié.
• Plusieurs tokens valides existent sans règles claires. Si vous autorisez un nombre illimité de tokens actifs, il vous faut une politique claire : le plus récent gagne, ou tout token actif fonctionne.

Un petit exemple réaliste : quelqu’un s’inscrit, demande deux renvois, puis clique le premier e-mail. Votre système n’accepte que le token le plus récent, donc il renvoie « token invalide ». L’utilisateur n’a rien fait de mal. Vos règles et vos messages n’ont pas correspondu à ce qui s’est passé.

Un ensemble de règles qui marche en pratique : générez un token aléatoire, stockez seulement son hachage, fixez une expiration raisonnable (heures, pas minutes), liez-le à l’utilisateur et à la finalité, et choisissez une politique pour les tokens multiples (souvent « le plus récent gagne » avec révocation des anciens).

Logique de renvoi qui fonctionne et n’invite pas aux abus

Quand la vérification casse, les utilisateurs appuient d’abord sur renvoyer. Si le renvoi est faible, cela tourne en boucle infinie pour les vrais utilisateurs et en outil gratuit pour les mauvais acteurs.

Un bon bouton de renvoi fait trois choses à chaque fois : il crée un token neuf, rend inutiles les tokens plus anciens, et ralentit les requêtes répétées. Générer un nouveau token sans invalider l’ancien mène à des états confus comme « déjà utilisé » ou « token mismatch », selon quel e-mail l’utilisateur clique.

Gardez le comportement de renvoi prévisible :

• Émettez un nouveau token et révoquez les anciens tokens inutilisés
• Limitez le débit par compte et par IP (un court cooldown plus un plafond journalier)
• Retournez le même message que l’adresse existe ou non (prévenir la découverte de comptes)
• Stockez des hachages de tokens (pas les tokens bruts) et utilisez une durée d’expiration claire
• Affichez un état UI clair comme « E-mail envoyé. Réessayez dans 30 secondes. »

Évitez une boucle de renvoi en utilisant une source unique de vérité pour la « vérification en attente ». Ne vous basez pas sur des flags frontend ou le localStorage. Basez-vous sur l’état serveur (par exemple un champ dans la table users indiquant la vérification). L’UI devrait lire cet état et n’offrir que des actions sensées : renvoyer, changer d’e-mail, ou contacter le support.

Gérer les utilisateurs qui changent d’e-mail avant vérification est un autre point de casse courant. Traitez-le comme un nouveau flow de vérification : mettez à jour l’e-mail en attente, révoquez tous les tokens précédents, et exigez la vérification de la nouvelle adresse. Sinon vous risquez de vérifier la mauvaise adresse ou de laisser plusieurs liens valides flotter.

La journalisation importe, mais faites-le en sécurité. Enregistrez événements et timestamps (verification_sent, verification_clicked, verification_succeeded, verification_failed) ainsi que des métadonnées grossières comme l’ID utilisateur et les codes de réponse du fournisseur. Ne consignez jamais les tokens bruts ou les URLs complètes. Si vous avez besoin de traces, loggez un identifiant de token (par exemple les 6 premiers caractères d’un hachage) et gardez-le hors des messages visibles par les clients.

Pas à pas : rendre la vérification fiable de bout en bout

Si votre problème de vérification par e-mail n’apparaît que parfois, c’est généralement parce que le flow est réparti entre trop d’endroits. Rendez-le ennuyeux : un token, un endpoint, un changement d’état clair.

1) Construisez un flux simple et répétable

Décidez du fonctionnement des tokens avant de toucher l’UI.

1. Générez un token difficile à deviner. Utilisez une valeur longue et aléatoire (pas un code court, pas un identifiant utilisateur, pas un JWT prédictible sauf si vous savez exactement ce que vous faites).
2. Stockez seulement ce dont vous avez besoin. Sauvegardez un hachage du token (pas le token brut), plus user_id, expires_at, et used_at (ou un simple status).
3. Envoyez un seul lien de vérification pointant vers un seul endpoint backend, par exemple : GET /verify-email?token=....
4. Vérifiez une fois et définissez une source unique de vérité. Quand le token est valide, marquez l’utilisateur comme vérifié (par exemple users.email_verified_at = now()), et marquez le token comme utilisé.
5. Gérez l’expiration avec un parcours convivial. Si le token est expiré, affichez un message clair et proposez un moyen sûr de demander un nouvel e-mail.

2) Rendre le renvoi et les clics répétés sûrs

Deux règles gardent cela fiable : invalidez les anciens tokens, et rendez chaque action idempotente.

Quand un utilisateur clique deux fois sur le même lien (ou quand son client mail le précharge), rien ne doit casser. Si l’utilisateur est déjà vérifié, l’endpoint doit répondre « Vous êtes vérifié » et s’arrêter.

Pour les renvois, évitez plusieurs tokens actifs par utilisateur. Quand vous émettez un nouveau token, invalidez tous les tokens inutilisés précédents pour cet utilisateur. Cela empêche les cas limites où un e-mail plus ancien arrive plus tard et confond l’utilisateur.

Checklist rapide pour attraper la plupart des erreurs d’onboarding générées par IA :

• Un seul token actif par utilisateur, invalidé après un renvoi
• Un seul endpoint de vérification qui effectue le changement d’état complet (pas d’actions partagées entre frontend et backend)
• Mise à jour atomique : vérifier l’utilisateur et consommer le token dans la même opération
• Fenêtre d’expiration claire (par exemple 15 minutes à 24 heures) et un parcours propre « renvoyer »
• Réponses idempotentes pour tokens déjà vérifiés ou déjà utilisés

Exemple : un fondateur teste l’inscription, clique le lien et ça marche. Plus tard, un collègue utilise le même lien et obtient « token invalide ». Cela peut être acceptable, mais seulement si l’endpoint répond « Déjà vérifié » au lieu d’une erreur. Souvent l’état est correct, mais le message et l’idempotence manquent, donc ça paraît cassé.

Résistance aux abus et contrôles de sécurité à ajouter tôt

Les équipes se concentrent souvent sur la délivrabilité et l’UI. Mais beaucoup de flux « cassés » sont en réalité bloqués par des contrôles de sécurité manquants, ou fonctionnent mais sont faciles à abuser. Ajoutez quelques garde-fous tôt pour que la vérification reste fiable sous trafic réel.

Limitez les renvois et tentatives de vérification

Les boutons de renvoi attirent les abus. Si un bot déclenche des centaines d’e-mails par minute, votre fournisseur peut retarder ou refuser les messages, et les vrais utilisateurs sont bloqués.

Limites qui fonctionnent sans pénaliser les vrais utilisateurs :

• Limite de renvoi par compte (par exemple 1 par minute avec un plafond journalier)
• Limite de tentatives de vérification par token (bloquer après quelques tentatives erronées)
• Throttles IP ou appareil pour les inscriptions et renvois répétés
• Cooldowns progressifs où chaque renvoi augmente l’attente
• Feedback utilisateur clair (un compte à rebours vaut mieux qu’un bouton cliquable en boucle)

Un détail important : ne créez pas un token tout neuf à chaque clic sans limites. Cela peut inonder votre base et compliquer le support (« quel e-mail est le bon ?").

Empêcher la lecture/rejeu et les chemins de prise de contrôle courants

Les tokens doivent être à usage unique et de courte durée. Après une vérification réussie, marquez le token comme utilisé et refusez-le pour toujours.

Surveillez aussi les comportements favorables à la prise de contrôle. La vérification ne doit pas changer silencieusement l’adresse e-mail d’un compte juste parce que quelqu’un a cliqué sur un lien. Un pattern plus sûr : demander le changement -> envoyer le lien à la nouvelle adresse -> confirmer -> notifier l’ancienne adresse.

La gestion des redirections est un autre problème discret. Si votre endpoint de vérification accepte un paramètre de redirection, autorisez uniquement des destinations internes connues. Sinon, des attaquants peuvent utiliser votre domaine pour rediriger vers des pages de phishing.

Traitez les tokens comme des mots de passe : ils fuient facilement. Évitez de placer des tokens complets dans des logs, analytics, rapports d’erreurs ou captures de support. Si vous devez journaliser, conservez seulement un préfixe court.

Un exemple réaliste : un prototype capture l’URL de vérification (avec token) dans un outil analytics, et elle finit dans des dashboards tiers. Toute personne y ayant accès peut vérifier des comptes. Cela arrive plus souvent qu’on ne le croit parce que le code modèle logge souvent les URL complètes par défaut.

Pièges courants dans les flows d’onboarding générés par IA

Quand la vérification par e-mail ne fonctionne pas dans une app générée par IA, on blâme souvent le fournisseur d’e-mails en premier. La livraison peut faire partie du problème, mais les échecs répétés viennent généralement d’un état d’application confus : la base dit une chose, le serveur vérifie une autre, et l’UI en affiche une troisième.

Un schéma fréquent est « trop de tokens, pas de règles ». Le flow génère un nouveau token à chaque renvoi, mais les anciens tokens ne sont jamais révoqués. L’utilisateur clique sur le premier e-mail, le serveur vérifie le token le plus récent, et vous obtenez une discordance même si le lien semble valide. Deux onglets ou deux appareils peuvent aussi créer des requêtes concurrentes qui laissent l’état dans un endroit étrange.

Le design du token est un autre piège. Le code généré par IA utilise parfois des tokens prévisibles, ou met un user ID (ou e-mail) directement dans le lien et appelle ça « vérification ». C’est facile à deviner ou réutiliser, et plus difficile à invalider en toute sécurité.

La vérité serveur bat la vérité client

Si l’UI définit isVerified = true après que l’utilisateur clique le lien (sans mise à jour serveur), cela semblera correct dans ce navigateur et échouera partout ailleurs. Vous avez besoin d’une seule source de vérité côté serveur, stockée en base, et chaque action protégée doit la vérifier. Sinon, des gens peuvent contourner la vérification en appelant directement les endpoints.

Le temps est un autre échec discret. Les vrais utilisateurs cliquent tard, cliquent deux fois, ou reçoivent les e-mails hors ordre. Si vous ne testez pas les fenêtres d’expiration, le décalage d’horloge entre services, et les livraisons retardées, vous proposerez un flow qui ne marche qu’en condition de laboratoire parfaite.

Vérifications rapides qui attrapent la plupart des bugs d’onboarding :

• Une seule validité de token par utilisateur à la fois, avec règles de priorité claires
• Hachage des tokens en base (pas les tokens bruts) et validation toujours serveur
• Le renvoi est un changement d’état : révoquer les anciens tokens, mettre une nouvelle expiration et logger l’événement
• La vérification est idempotente : un second clic répond « déjà vérifié » et non une erreur
• Testez les timings : liens expirés, e-mails hors ordre, double-clics et changement d’appareil

Exemple réaliste : réparer une inscription cassée cette semaine

Un fondateur livre une app générée par IA et les premiers utilisateurs butent : l’inscription fonctionne mais personne ne peut se connecter car l’app exige une vérification par e-mail. Les tickets support disent la même chose : « Je n’ai jamais reçu l’e-mail. » Quelques utilisateurs le reçoivent, mais cliquer sur le bouton affiche une erreur comme « token invalide ». Le fondateur cherche « vérification e-mail ne fonctionne pas » et fait des ajustements rapides, mais le problème revient.

Commencez par les parties ennuyeuses. Le fournisseur d’e-mail rejette les envois parce que l’adresse from ne correspond pas au domaine vérifié, donc beaucoup de messages ne quittent pas le fournisseur. Par-dessus ça, l’app génère des tokens en mémoire, les envoie par e-mail, mais ne les sauvegarde jamais en base. Donc quand un utilisateur clique le lien, le serveur n’a rien contre quoi comparer.

Une correction stable ressemble à ceci :

• Corriger les paramètres d’expéditeur (domaine vérifié, adresse from et reply-to)
• Stocker un token haché avec une date d’expiration et l’ID utilisateur
• Valider au clic : l’utilisateur existe, le token correspond, n’est pas expiré, et n’a pas déjà été utilisé
• Ajouter une limite de renvoi (cooldown + plafond journalier) par utilisateur et par IP
• Invalider les anciens tokens quand un nouveau est émis

Après la correction, la vérification fonctionne même quand quelqu’un ouvre l’e-mail des heures plus tard. S’il demande un nouveau mail, seul le lien le plus récent est accepté, et les liens plus anciens échouent en toute sécurité avec un message clair. Cela réduit la confusion et ferme une voie d’abus courante où des attaquants inondent de renvois ou réutilisent d’anciens tokens.

Pendant la transition, le support a besoin d’un script simple qui n’accuse pas l’utilisateur. Par exemple : « Nous avons corrigé nos e-mails de vérification. Veuillez demander un nouveau mail de vérification depuis l’écran de connexion. Si vous ne le recevez pas dans les 5 minutes, vérifiez le spam et dites-nous quel domaine d’e-mail vous avez utilisé (Gmail, Outlook, etc.). »

Vérifications rapides et prochaines étapes

Si la vérification par e-mail bloque les inscriptions, faites une passe rapide qui vérifie toute la chaîne. La plupart des rapports « ça ne marche pas » se ramènent à un décalage entre ce qui a été envoyé et ce que votre serveur attend quand le lien est ouvert.

Checklist rapide que vous pouvez exécuter en ~15 minutes :

• Livraison : confirmez que l’e-mail est réellement envoyé, pas bloqué dans la file du fournisseur, et qu’il ne tombe pas en spam (vérifiez les événements du fournisseur et les rebonds)
• Correction du lien : ouvrez l’e-mail et comparez le domaine, le chemin et les params de la query au routage de votre app (vérifiez l’encodage URL)
• Règles du token : confirmez le format du token, la stratégie de hachage, la durée de vie et les paramètres horaires concordent des deux côtés
• Mises à jour d’état : assurez-vous que verified est écrit une fois, sur le bon enregistrement utilisateur, et que la connexion lit bien ce même champ
• Journalisation : ajoutez un trace ID par requête, loggez des codes de raison clairs (expired, already_used, invalid), et ne loggez jamais les tokens complets (juste un préfixe)

Puis faites quelques tests d’edge en fenêtre incognito pour voir ce que voient les nouveaux utilisateurs :

• Token expiré : attendez la TTL, cliquez, confirmez que vous obtenez un résultat expiré clair et un chemin sûr pour renvoyer
• Renvoyer deux fois : demandez deux renvois, confirmez que seul le lien le plus récent marche (ou que les plus anciens sont invalidés)
• Cliquer un ancien lien après un renvoi : confirmez que vous ne vérifiez pas le mauvais token ou ne repassez pas l’utilisateur en non vérifié
• Cliquer deux fois sur le même lien : confirmez que le second clic est géré en sécurité et ne renvoie pas d’erreur
• Créer deux comptes et permuter les liens : confirmez que les liens ne peuvent pas vérifier un autre utilisateur

Si vous avez hérité d’un code généré par IA, cherchez les flows d’auth spaghetti : multiples endpoints de vérification, tokens stockés à différents endroits, ou logique UI qui marque un utilisateur vérifié avant que le serveur le fasse. Ces cas sont difficiles à repérer sans lire le flux bout en bout.

Si vous voulez une seconde paire d’yeux, FixMyMess (fixmymess.ai) se spécialise dans le diagnostic et la réparation de code d’apps générées par IA, y compris l’auth cassée et les flows de vérification. Un audit ciblé du code révèle souvent les petits problèmes cumulatifs (config livraison, persistance des tokens, règles de renvoi, mises à jour d’état) qui n’apparaissent qu’en production.