Vérification par SMS à l’inscription des utilisateurs : un OTP sans failles
· 3 min de lecture
Un numéro de téléphone vérifié vaut de l’or : c’est la récupération de compte, le second facteur et le filtre anti-bots, tout en un. Le vérifier semble trivial —envoyer un code et le comparer— et c’est pour cela que presque toutes les implémentations maison commettent les trois mêmes erreurs. Nous les décrivons, car notre API existe pour que vous n’ayez pas à les résoudre vous-même.
Les trois erreurs classiques
- Conserver le code en clair. Le code finit dans la base de données, dans les journaux ou dans l’historique des messages du tableau de bord — et quiconque voit l’un des trois peut vérifier le téléphone d’un autre. Sur notre plateforme, le code n’est jamais stocké en clair : seulement son empreinte cryptographique, et le texte du SMS est masqué dans l’historique.
- Des codes éternels. Sans expiration ni limite de tentatives, un code à 6 chiffres se casse par force brute. Les nôtres expirent et se bloquent après quelques tentatives échouées.
- Ignorer la fraude au trafic. Le SMS pumping —des bots qui demandent des milliers de vérifications vers des tranches aux tarifs gonflés— se paie de votre poche. Limites par origine et contrôle par destination, intégrés d’office.
Comment l’intégrer
Deux appels : verify/start avec le numéro, verify/check avec le code saisi
par l’utilisateur. Un code erroné renvoie le statut invalid — pas une erreur
HTTP — pour que votre formulaire distingue « il s’est trompé » de « quelque
chose a échoué ». Idempotence à l’envoi : si votre serveur réessaie, ni le SMS
ni la facturation ne sont dupliqués.
L’utilisateur préfère WhatsApp ? Le même flux fonctionne sur les deux canaux, et votre code décide du nouvel essai sur l’autre avec un appel de plus.
Le détail que presque personne ne regarde : l’accusé
Un OTP qui « a été envoyé » mais n’est pas arrivé, c’est un utilisateur perdu au pire moment : l’inscription. En Espagne, l’accusé confirme la remise sur le terminal ; dans d’autres destinations, seulement que le réseau l’a accepté — nous l’avons mesuré pays par pays et nous vous prévenons avant l’envoi, pas après la facturation.
Documentation de l’API · Prix par pays · Mode test à la création du compte, sans carte.
Le coût d’une mauvaise mise en œuvre, en chiffres que vous connaissez déjà
Un formulaire d’inscription qui perd des utilisateurs à l’étape du code, c’est de l’argent jeté en acquisition : chaque clic arrivé jusque-là a déjà été payé. Les trois fuites typiques et leur remède :
« Le code n’arrive pas. » Parfois c’est la couverture ; souvent, c’est un accusé qui a menti. Un renvoi visible après quelques secondes —avec un délai minimal entre les envois pour ne pas brûler le solde— et un nouvel essai par l’autre canal règlent la plupart des cas.
« Je me suis trompé en le tapant. » Une réponse invalid claire et un
champ prêt pour réessayer, sans recharger la page ni invalider le code restant
avant épuisement des tentatives.
« Il est arrivé en retard. » Une expiration courte, c’est de la sécurité, mais l’utilisateur doit la voir : un compte à rebours visible évite qu’il tape un code déjà mort.
Tout cela est déjà réglé dans l’API : expiration, tentatives, délais de renvoi et statuts que votre interface peut traduire en messages utiles.