API de vérification à l'inscription

C'est un contrôle placé dans le parcours d'inscription qui exige qu'un nouveau compte soit rattaché à un numéro de téléphone dont le propriétaire peut prouver qu'il le détient. C'est le signal d'identité le moins cher disponible au moment précis où vous en savez le moins sur un utilisateur, et le seul qu'il ne puisse pas générer en masse gratuitement.

La distinction qui compte est entre collecter un numéro et en vérifier un. Un formulaire qui stocke simplement ce qui a été saisi possède un champ de contact. Un formulaire qui le vérifie possède une contrainte — et c'est sur les contraintes que repose l'économie de l'abus.

Les inscriptions automatisées sont le cas évident : un script peut fabriquer des adresses e-mail indéfiniment, mais chaque numéro vérifié coûte une vraie carte SIM ou un vrai compte WhatsApp. Ce seul fait transforme une attaque gratuite en une attaque tarifée.

Les cas plus subtils valent davantage. Les programmes de parrainage et les bonus de bienvenue ne valent que par leur définition d'une personne distincte, et une adresse e-mail non vérifiée n'en est pas une. Une boîte jetable derrière un essai gratuit non plus. La vérification à l'inscription est ce qui empêche la même personne de réclamer cinquante fois une offre réservée aux nouveaux.

Placez la vérification aussi tôt qu'elle peut porter son poids, et pas plus tôt. Vérifier avant que l'utilisateur ait vu la moindre valeur est la façon la plus courante de le perdre ; vérifier après qu'il a créé du contenu ou dépensé de l'argent oblige à défaire un compte existant.

Un défaut raisonnable : vérifier à la fin de l'inscription, une fois le compte créé mais avant qu'il puisse agir — publier, transiger, inviter ou réclamer quoi que ce soit. Si votre produit a un mode anonyme réellement utile, reportez la vérification à la première action qui vous coûte quelque chose.

Chaque étape ajoutée fait perdre des utilisateurs, et c'est un coût réel, pas un argument à balayer. Ce que vous maîtrisez, c'est la friction que porte cette étape. Un flux à code classique demande de quitter votre page, trouver un message, lire un code, revenir et le saisir — quatre occasions d'abandonner, plus une attente de livraison opérateur qui peut ne jamais aboutir.

Un flux Reverse OTP remplace tout cela par un appui et un envoi. L'utilisateur ne s'éloigne jamais longtemps, ne recopie rien et n'attend pas la livraison sur un appareil qu'il tient déjà. Le contrôle est le même ; les façons d'y échouer sont bien moins nombreuses.

Ouvrez une session avec POST /start-verification quand l'utilisateur atteint l'étape de vérification, en passant votre propre identifiant comme session_id pour que le résultat retombe directement sur le compte en attente. Affichez le lien profond WhatsApp renvoyé en QR code sur desktop ou en bouton sur mobile.

Puis attendez le callback, ou lisez GET /check-verification-status au retour de l'utilisateur sur l'onglet. Ne marquez le compte vérifié que si le statut est verified — et stockez le numéro renvoyé par l'API, pas celui saisi par l'utilisateur, car les deux ont le droit de différer.

Les sessions expirent : faites du redémarrage une action visible et banale plutôt qu'un état d'erreur. Les utilisateurs sans WhatsApp ont besoin d'un repli SMS présenté clairement, pas comme un dernier recours caché. Et les numéros partagés ou recyclés existent : décidez délibérément si un numéro peut être rattaché à plusieurs comptes, car le défaut que vous retenez devient silencieusement une politique.

Enfin, traitez la vérification comme réutilisable. Une fois un numéro prouvé à l'inscription, la même preuve peut soutenir la récupération de compte et les contrôles renforcés ultérieurs sans nouvel enrôlement.