La checklist
Avancez point par point, cochez au fur et à mesure.
- L'utilisateur demande un codeConnexion, paiement ou inscription
- Votre application appelle l’API de vérificationUne requête par code
- BroadNet délivre le codeVia le meilleur canal disponibleSolution de secours en cas de non-délivranceSMSWhatsAppVoix
- L'utilisateur saisit le codeVérification par rapport au code émis
- VérifiéAccès accordé
01
Stratégie de canaux et repli
- Définir une cascade de canaux par marché (ex. SMS → WhatsApp/RCS → appel vocal).Le repli doit être délimité dans le temps : si le premier canal n'est pas confirmé en N secondes, escalader.
- Privilégier la vérification native de l'application là où disponible (autofill silencieux/OTP, push applicatif) pour réduire la dépendance au SMS.
- Utiliser l'OTP vocal comme repli dans les marchés à faible délivrabilité SMS ou pour l'accessibilité.
- Éviter d'envoyer le même OTP sur deux canaux simultanément — cela double le coût et l'exposition à l'AIT.
02
Sender ID, templates et routage
- Enregistrer les sender ID là où le marché l'exige ; les ID non enregistrés sont fréquemment abandonnés.Le pré-enregistrement du sender ID est obligatoire dans un nombre croissant de marchés.
- Utiliser une route OTP dédiée à faible latence, distincte du trafic marketing.Ne jamais partager une route entre l'OTP transactionnel et le bulk promotionnel.
- Garder le contenu du template minimal, à la marque, et cohérent pour passer les filtres de contenu.
- Prendre en charge les formats d'autofill (ex. la convention de code à usage unique lié à l'origine sur la dernière ligne) pour accélérer la saisie.
- Fixer une validity_period courte afin qu'un OTP retardé expire plutôt que d'arriver périmé.
03
Latence et réessais
- Mesurer la latence de bout en bout jusqu'au téléphone (soumission → DLR), pas seulement la latence de soumission-acceptation.
- Fixer un délai de récupération entre renvois et plafonner les renvois par utilisateur et par fenêtre.Les renvois non plafonnés sont la principale surface d'attaque pour le SMS pumping.
- Déclencher le repli sur un DLR manquant dans votre budget de latence, pas seulement sur un échec explicite.
- Dédupliquer : une vérification logique = un code, même à travers les réessais, pour ne pas dérouter l'utilisateur.
- Instrumenter le taux de livraison, la latence médiane/p95, et la conversion (code saisi) par marché.
04
Conception du message et du code
- Utiliser des codes numériques à 6 chiffres par défaut ; plus long seulement si la politique l'exige.
- Lier le code à la session/l'appareil et l'expirer côté serveur après la première utilisation ou un délai.
- Localiser le corps du message tout en gardant le code et le jeton de marque stables.
- Ne jamais inclure le code dans un lien cliquable qui pourrait être hameçonné ; le garder uniquement copiable/saisissable.
05
Protection contre la fraude et l'AIT (trafic artificiellement gonflé)
La fraude AIT / SMS pumping génère de vraies requêtes OTP vers des numéros que le fraudeur contrôle, gonflant votre facture sans utilisateur légitime. C'est la section au meilleur retour sur investissement pour la plupart des expéditeurs.
- Limiter le débit des requêtes OTP par numéro de téléphone, par IP, et par empreinte d'appareil.
- Ajouter de la friction (CAPTCHA / challenge) quand la vélocité s'emballe depuis une source.
- Bloquer ou limiter les plages de destination à haut risque et les préfixes de numéro connus comme mauvais.Un afflux soudain vers une plage de pays inhabituelle est la signature classique de l'AIT.
- Surveiller le taux de conversion par destination — le trafic pompé montre des requêtes avec une saisie de code proche de zéro.
- Utiliser l'intelligence numérique / le lookup HLR pour rejeter les numéros invalides ou à risque avant l'envoi.
- Travailler avec un fournisseur qui propose la détection AIT et agit sur les schémas suspects.
Références
Normes et textes des régulateurs cités dans ce guide. BroadNet est membre associé de la GSMA et membre du MEF et opère une messagerie de niveau opérateur depuis 2003.