Vérifier le numéro de téléphone par SMS (OTP) sur un formulaire de landing page : la friction vaut-elle le coup ?

Un formulaire de demande de devis qui affiche type="tel" et une validation de format n’empêche rien : 0612345678 tapé au hasard passe toute règle de validation basée sur la longueur ou les chiffres autorisés, sans qu’aucun humain ne décroche jamais à ce numéro. Pour une landing page d’artisan ou une page d’estimation où le rappel téléphonique est l’étape suivante immédiate, ce genre de lead coûte un appel pour rien — et parfois une relance, un SMS, un créneau bloqué dans l’agenda du commercial. La vérification par code SMS, ou OTP (« one-time password »), répond à un problème précis : prouver que le numéro saisi est joignable à l’instant de l’inscription, pas qu’il appartient à quelqu’un de sérieux ni qu’il correspond à une intention d’achat réelle.

Sur quels formulaires l’OTP a un vrai rôle

L’étape supplémentaire ne se justifie que si le coût d’un faux numéro dépasse largement le coût de la friction ajoutée. Trois profils de formulaire remplissent cette condition :

• La demande de devis avec rappel humain — artisan, courtier, estimation immobilière : chaque lead déclenche un appel sortant, et un numéro invalide n’est découvert qu’au moment de composer.
• La réservation d’un créneau limité — consultation gratuite, diagnostic sur site, essai encadré : un faux numéro bloque un créneau que quelqu’un d’autre aurait pu prendre.
• Le formulaire CPF ou réglementé où la fraude aux leads a un coût direct, réglementaire autant que commercial.

À l’inverse, une inscription à une newsletter, un téléchargement de lead magnet gratuit ou une simple prise de contact par email n’a aucune raison d’imposer un code SMS : le coût d’un faux contact y est presque nul, alors que la friction, elle, reste entière pour 100 % des visiteurs légitimes. Le champ téléphone peut y rester optionnel et non vérifié — c’est déjà l’essentiel de ce qui compte pour ce type de page.

Ce que l’OTP prouve, et ce qu’il ne prouve pas

Un code reçu par SMS et ressaisi correctement prouve une seule chose : le numéro est actif et son détenteur y a eu accès à l’instant T. Il ne prouve ni l’identité de la personne, ni sa solvabilité, ni son intention réelle d’acheter — un visiteur peut très bien vérifier un numéro authentique tout en n’ayant aucune intention de donner suite. C’est une différence importante avec un email jetable, plus facile à générer en masse : un numéro de mobile vérifiable a un coût d’obtention réel, ce qui limite mécaniquement la fraude à l’échelle. Une étude de Ballard, Cardwell et Young, publiée en 2019 dans JMIR Public Health and Surveillance (disponible sur Google Scholar), a construit et évalué un protocole de détection de fraude à huit critères pour des formulaires d’enquête en ligne, parmi lesquels la validité du numéro de téléphone communiqué compte parmi les signaux les plus fréquemment déclenchés pour écarter une soumission frauduleuse. Le champ téléphone, dans ce travail mené hors du contexte commercial mais confronté au même problème de saisies frauduleuses en masse, s’y révèle être l’un des signaux les plus fiables du protocole.

Le coût en friction : ce que montre la recherche sur les parcours 2FA

Ajouter une étape de vérification n’est jamais gratuit. Lyastani, Bugiel et Backes, dans une étude publiée en 2023 dans les actes du NDSS Symposium (disponible sur Google Scholar), ont analysé les parcours d’authentification à deux facteurs des sites les plus visités du web et interrogé un panel d’utilisateurs sur leur expérience : une partie notable des répondants rapporte avoir déjà abandonné un site, cessé de l’utiliser, ou renoncé à activer une option de vérification à cause d’un parcours d’authentification qui s’écartait de ce à quoi ils étaient habitués sur d’autres sites. Le mécanisme identifié est directement transposable à un OTP de formulaire : ce n’est pas la vérification elle-même qui fait fuir, c’est un parcours qui surprend — un SMS qui met trop longtemps à arriver, un champ de code mal positionné, une erreur de saisie sans message clair. Un parcours OTP bien conçu (autocomplétion du code, délai visible, réémission facile) limite fortement cette perte ; un parcours bricolé l’aggrave.

Implémenter la vérification par SMS en Next.js

L’implémentation repose sur trois briques : un service d’envoi de SMS (Twilio Verify, Vonage ou l’équivalent chez votre fournisseur d’infrastructure), une route serveur qui déclenche l’envoi et vérifie le code saisi, et un champ optimisé pour la saisie du code côté client.

// app/api/otp/send/route.ts (server-side, jamais exposé côté client)
export async function POST(req: Request) {
  const { phone } = await req.json();
  // valider le format (libphonenumber-js) avant tout envoi
  await verifyClient.verifications.create({ to: phone, channel: "sms" });
  return Response.json({ sent: true });
}

Côté client, l’attribut autocomplete="one-time-code" sur le champ de saisie permet à la plupart des claviers mobiles (iOS et Android) de proposer automatiquement le code reçu par SMS sans que le visiteur ait besoin de quitter le formulaire pour aller le lire dans ses messages — un gain de friction simple qui ne demande aucune bibliothèque. Sur Chrome Android, la WebOTP API (navigator.credentials.get({ otp: { transport: ["sms"] } })) va plus loin en remplissant le champ automatiquement dès réception du SMS, à condition que le message respecte un format standardisé incluant le domaine du site. Les deux mécanismes se complètent : la WebOTP API pour l’expérience la plus fluide là où elle est supportée, l’autocomplétion classique en repli partout ailleurs.

Le fallback pour les numéros non mobiles

Un numéro fixe ne reçoit pas de SMS. Bloquer purement et simplement ces visiteurs revient à perdre des leads légitimes dans les secteurs où le fixe reste courant (professions libérales, artisanat, certaines tranches d’âge). Proposer une vérification par appel vocal automatisé — le service dicte le code au lieu de l’envoyer par SMS — couvre ce cas sans complexifier l’interface : un seul bouton « recevoir par appel » suffit, affiché après un premier échec ou une détection de numéro fixe.

Pièges à éviter

• Ne pas limiter le nombre d’envois — sans limite de tentatives par numéro et par IP, le formulaire devient une porte ouverte au SMS pumping (envoi massif de codes vers des numéros surtaxés aux frais du site) ; un honeypot combiné à un throttling serveur strict est indispensable avant toute mise en production.
• Sous-estimer le coût par SMS à l’échelle — quelques centimes par envoi semblent négligeables jusqu’à ce qu’une campagne publicitaire multiplie le volume de formulaires soumis ; ce coût doit être comparé au coût réel d’un rendez-vous manqué, pas ignoré par défaut.
• Vérifier avant, jamais après l’appel commercial — l’intérêt de l’OTP disparaît s’il intervient après que le commercial a déjà tenté de joindre le numéro ; la vérification doit bloquer la soumission du formulaire elle-même.
• Conserver le numéro vérifié comme toute autre donnée personnelle — la vérification ne change rien aux obligations de durée de conservation RGPD ni au consentement requis pour être recontacté.

L’alternative plus légère : valider sans vérifier

Sur un formulaire à volume plus élevé ou à ticket moyen plus faible, l’OTP peut être disproportionné. Une validation de format stricte avec une bibliothèque comme libphonenumber-js — qui reconnaît les indicatifs et longueurs valides par pays plutôt qu’une simple regex sur le nombre de chiffres — élimine déjà la majorité des saisies grossièrement fausses, sans ajouter d’étape. Combinée à un suivi des appels sortants pour mesurer le taux réel de numéros injoignables, cette approche donne une base chiffrée pour décider, dans un second temps, si le passage à l’OTP se justifie vraiment sur cette page précise plutôt que par principe.

Sur les templates Agence & Artisan local et Immobilier — Estimation de LanderKit, le formulaire de demande de devis est livré en code source : ajouter une route de vérification OTP ou simplement durcir la validation avec libphonenumber-js se fait directement dans le composant, sans dépendre d’un plugin tiers. Pour les formulaires en plusieurs étapes, la vérification du téléphone trouve naturellement sa place comme dernière étape avant soumission — voir notre guide sur le formulaire multi-étapes pour la structurer sans casser la progression perçue.