API de vérification de numéro de téléphone

Vérifier un numéro de téléphone, c'est prouver que la personne en face de vous contrôle réellement le numéro qu'elle a saisi. Un numéro dans un formulaire est une affirmation ; la vérification en fait une preuve. Sans elle, un champ d'inscription accepte les fautes de frappe, les numéros jetables, ceux des autres et tout ce qu'un script décide d'y coller.

Cette preuve vaut la peine pour trois raisons distinctes. Elle vous donne un canal de contact qui fonctionne, donc les réinitialisations de mot de passe et les notifications arrivent sur un vrai téléphone. Elle vous donne un identifiant stable pour un compte, ce qui rend coûteux le multi-comptes et l'abus de bonus. Et elle vous donne un second facteur mobilisable plus tard, sans demander à l'utilisateur d'enrôler quoi que ce soit de nouveau.

Tout flux de vérification repose sur la même idée : il faut qu'il se passe sur le téléphone quelque chose que seul son détenteur pouvait provoquer. La version classique envoie un code à usage unique par SMS et demande à l'utilisateur de le recopier. Phone-Verif inverse le sens — l'utilisateur envoie un message au lieu d'en recevoir un — mais la forme reste la même : créer une session, présenter un défi, attendre la preuve, lire le résultat.

Concrètement, cela fait trois éléments de votre côté. Un appel qui ouvre une session de vérification et vous donne quelque chose à montrer. Un écran ou un widget où l'utilisateur agit. Et un moyen d'apprendre le résultat, par callback ou en lisant le statut de la session.

WhatsApp est le canal principal. L'API renvoie un lien profond WhatsApp contenant un court jeton de session ; vous l'affichez en QR code sur desktop ou en bouton sur mobile. L'utilisateur le touche, WhatsApp s'ouvre avec le message déjà rédigé, il l'envoie. WhatsApp communique le numéro émetteur au serveur : comme WhatsApp a vérifié ce numéro à la création du compte, vous héritez d'une preuve que vous n'avez pas eu à construire.

La part de votre trafic couverte dépend entièrement du marché. L'usage de WhatsApp est quasi universel au Brésil, en Inde et dans une grande partie de l'Europe et de l'Afrique, et marginal aux États-Unis, au Japon et en Corée du Sud. Mieux vaut regarder où sont réellement vos utilisateurs avant de décider du niveau de repli nécessaire.

Pour les utilisateurs sans WhatsApp, la même session accepte le même jeton par SMS : l'utilisateur envoie le jeton en message texte au numéro de vérification. La session, le jeton et le statut que vous lisez ensuite sont identiques, donc votre intégration ne se dédouble pas — seule change l'instruction affichée.

Cela compte plus qu'il n'y paraît. Un flux exclusivement WhatsApp perd silencieusement tout le monde sur les marchés à faible adoption ; un flux exclusivement SMS paie un opérateur à chaque tentative, y compris celles déclenchées par un bot. Garder les deux sur une seule session permet de privilégier le canal économique et sûr tout en atteignant le reste.

Dans un flux OTP classique, le serveur envoie un secret en espérant qu'il arrive sur le bon téléphone et nulle part ailleurs. C'est cette hypothèse qu'exploitent le SIM swap et le phishing d'OTP, et c'est elle qui rend rentable le trafic artificiellement gonflé : chaque tentative vous coûte un message, qu'un vrai utilisateur soit derrière ou non.

Le Reverse OTP supprime l'hypothèse. Aucun secret n'est envoyé à l'utilisateur : rien à intercepter, rien à lui soutirer, et aucun message sortant qu'un fraudeur puisse vous faire payer. L'acte d'envoyer est lui-même la preuve.

Une session démarre à l'état pending. Elle passe par whatsapp_previewed quand l'utilisateur voit le message pré-rempli, opened quand il ouvre le lien, et verified dès que le message arrive et est rattaché à la session. Si personne n'agit à temps, elle termine à expired.

Seul l'état verified porte le numéro de téléphone ; avant cela, le champ est nul. Traitez le statut comme le signal et le numéro comme sa charge utile, jamais l'inverse — cette seule règle élimine la plupart des conditions de course rencontrées à la première intégration.

L'intégration tient en deux appels REST. POST /start-verification ouvre une session et renvoie le numéro WhatsApp, le lien profond et une URL web hébergée si vous préférez rediriger plutôt que construire votre écran. GET /check-verification-status renvoie l'état de la session et, une fois vérifiée, le numéro lui-même.

Vous pouvez aussi éviter toute interface et intégrer la page de vérification hébergée dans une iframe, c'est le chemin le plus rapide vers quelque chose qui fonctionne. Dans tous les cas, préférez le callback à une boucle de polling en production, et n'interrogez le statut qu'en développement ou lorsque l'utilisateur revient explicitement sur votre page.

Les sessions sont de courte durée et chaque jeton est lié à une seule d'entre elles : un message rejoué ne correspond à rien. Le numéro que vous recevez provient de l'infrastructure de WhatsApp et non d'une saisie utilisateur, ce qui ferme la faille où quelqu'un tape simplement le numéro d'un tiers en attendant un code intercepté.

Côté confidentialité, le flux fait circuler moins de données personnelles que celui qu'il remplace : aucun code ne traverse un réseau télécom pour atteindre l'utilisateur, et vous conservez le numéro vérifié plutôt qu'une traînée de tentatives de livraison.

Les vérifications sont facturées en crédits prépayés. Pas d'abonnement, et les crédits n'expirent pas : un pic saisonnier d'inscriptions coûte ce qu'il coûte et un mois calme ne coûte rien. Les nouveaux comptes démarrent avec des crédits offerts, de quoi dérouler le flux complet en environnement de test avant de s'engager.