orsqu'un code d'accès à usage unique n'est pas reçu, l'utilisateur se retrouve bloqué sur l'écran de connexion ou de paiement, à deux doigts d'abandonner. Le plus frustrant pour l'équipe d'ingénierie est que le message a souvent été envoyé correctement : l'API a renvoyé un code 202, la requête SMPP a été acceptée et la plateforme affiche un message en attente. L'erreur se produit en aval, sur un réseau inaccessible à l'équipe applicative. Cet article détaille les raisons, non exhaustives, de l'échec des codes d'accès à usage unique en production, explique comment les distinguer des reçus valides et propose une solution pour chacune d'elles.
La surface de rupture est plus petite qu'il n'y paraît.
Le trafic OTP échoue pour l'une des sept raisons suivantes, classées approximativement par ordre de fréquence : rejet de l'identifiant de l'expéditeur par l'opérateur de destination, un saut de route grise entraînant la perte ou le retard du message, une limitation de débit au niveau du SMSC ou du pare-feu, le déclenchement des filtres de contenu sur un modèle, une incompatibilité d'encodage entre le contenu UCS-2 et un modèle GSM-7, une congestion du réseau chez l'opérateur de destination et l'indisponibilité du terminal (éteint, hors couverture, portage avec un routage obsolète). Tous les autres cas (MSISDN corrompu, identifiants expirés, interruption de service) sont minoritaires. Commencez par diagnostiquer les cas les plus fréquents.
Lisez les accusés de réception, pas la réponse à la soumission
L'erreur la plus fréquente commise par les équipes est de considérer une soumission réussie (code 202 HTTP, ESME_ROK sur submit_sm) comme une preuve de la bonne réception du message. Ce n'est pas le cas. La soumission signifie que la plateforme a accepté le message ; la livraison signifie que le terminal l'a reçu. Chaque système OTP doit être configuré pour utiliser l'accusé de réception de livraison (DLR), qui arrive ultérieurement sous forme de webhook ou d'unité de données de protocole (PDU) deliver_sm et contient l'un des codes d'état suivants : DELIVRD, UNDELIV, REJECTD, EXPIRED, UNKNOWN. Le premier indicateur pour toute enquête OTP est la distribution des états DLR par route, identifiant de l'expéditeur, opérateur de destination et plage horaire, et non le taux de réussite de la soumission.
Diagnostiquer en délimitant le lieu de la panne.
Une analyse OTP rigoureuse segmente l'échec en quatre étapes et remonte à partir du signal le plus en aval. Étape 1 : échec à la soumission – la plateforme a rejeté l'appel avant même son départ, presque toujours à cause d'un identifiant d'expéditeur incorrect, d'une catégorie de modèle non enregistrée, d'un pays non pris en charge ou d'un champ obligatoire manquant. Étape 2 : acceptation à la soumission mais jamais remise au SMSC de destination – généralement un problème de qualité de routage ou un blocage par pare-feu. Étape 3 : remise au SMSC et retour d'un DLR négatif – contenu filtré, identifiant d'expéditeur sur liste noire chez l'opérateur, destinataire bloqué. Étape 4 : DLR positif mais l'utilisateur ne signale aucun message – téléphone éteint, transfert vers un autre opérateur avec un routage obsolète, filtre anti-spam au niveau du système d'exploitation ou notification désactivée. La solution diffère pour chaque étape ; les confondre risque d'entraîner des recherches infructueuses.
Les sept causes fréquentes et les solutions à adopter pour chacune d'elles.
1. Rejet de l'identifiant de l'expéditeur
De nombreux marchés réglementés — les Émirats arabes unis (TDRA), l'Arabie saoudite (CST), l'Égypte (NTRA) et l'Inde (DLT de la TRAI) — exigent que chaque identifiant d'expéditeur alphanumérique soit préenregistré auprès d'une entité juridique vérifiée. Le trafic envoyé avec un identifiant non enregistré est rejeté au niveau de l'opérateur et génère un DLR négatif (aucun message distribué), alors que la réponse à la soumission est 202. La solution consiste à enregistrer l'identifiant. Pour le diagnostiquer, il faut corréler les erreurs UNDELIV/REJECTD avec l'identifiant d'expéditeur et le pays de destination : si tous les échecs concernent le même identifiant d'expéditeur dans un même pays, le problème vient de l'enregistrement. Consultez le guide d'enregistrement des identifiants d'expéditeur pour les marchés du CCG pour connaître les documents nécessaires.
2. Sauts par la voie grise
Les routes internationales économiques impliquent souvent un ou plusieurs sauts de réinjection via des agrégateurs partenaires ou des terminaux de type SIM farm. Chaque saut augmente la latence, la probabilité de perte silencieuse et le risque que le pare-feu de l'opérateur de destination catégorise le trafic comme A2P non autorisé et le bloque. On observe alors un taux de perte élevé, une forte variance de latence et un taux de livraison qui chute brutalement lorsque l'opérateur de destination déploie ou met à jour un pare-feu SMS. La solution consiste à acheminer les OTP directement depuis l'opérateur ; les avantages et les inconvénients sont analysés dans l'article « Routes directes versus routes grises ».
3. Limitation du débit au niveau du SMSC ou du pare-feu
Chaque opérateur et chaque pare-feu impose un plafond de TPS par identifiant d'expéditeur et par route. En cas de dépassement de ce plafond, les messages sont soit immédiatement rejetés (dans le meilleur des cas, l'échec est visible), soit mis en file d'attente et livrés en retard (dans le pire des cas, ils arrivent après l'expiration du code OTP et l'utilisateur a déjà abandonné). Le diagnostic consiste à analyser les pics de soumission par rapport à la latence p95 : une courbe de latence stable sous charge constante, avec des pics lors des pics de trafic, indique une limitation de débit. La solution consiste à limiter le débit au niveau de la couche application pour lisser les pics et à négocier un plafond de TPS plus élevé spécifiquement pour le trafic nécessitant un code OTP.
4. Filtres de contenu
Les systèmes de classification de contenu des opérateurs et des pare-feu peuvent signaler les modèles de mots de passe à usage unique (OTP) contenant des mots-clés, des URL (la plupart des opérateurs sont très stricts concernant les liens raccourcis non vérifiés dans les contenus transactionnels), des noms d'expéditeur inhabituels ou des mises en page ressemblant à des techniques d'hameçonnage connues. Le signe distinctif est une augmentation soudaine du taux de rejet d'un seul modèle, alors que tous les autres sont correctement acheminés. La solution réside dans la qualité des modèles : un texte OTP court et classique, sans liens raccourcis ni langage incitant à l'urgence. Si le modèle est réglementé (sur certains marchés, les modèles transactionnels doivent être pré-enregistrés), assurez-vous que la version enregistrée corresponde à la version envoyée ; de petites variations peuvent être détectées.
5. Incompatibilité d'encodage
Les modèles OTP contenant un caractère non ASCII (une voyelle accentuée, un guillemet spécial issu d'un document de conception, un chiffre arabe) entraînent une conversion silencieuse du message de GSM-7 à UCS-2, réduisant ainsi le nombre de caractères par segment de 160 à 70 et provoquant la concaténation de messages que certains téléphones anciens réassemblent incorrectement. Le diagnostic consiste à examiner le modèle rendu octet par octet, et non le modèle tel que le développeur le conçoit. La solution réside dans une analyse des modèles prenant en compte l'encodage et une vérification lors de la compilation qui signale tout caractère non GSM-7 dans un modèle transactionnel.
6. Congestion du réseau
Les centres de messagerie SMSC des opérateurs de destination peuvent être saturés lors d'événements majeurs (Aïd, Black Friday, jours fériés, pannes importantes). Les requêtes sont acceptées, mais les délais de livraison passent de moins d'une seconde à plusieurs minutes. Il n'existe pas de solution miracle côté expéditeur ; la seule solution consiste à détecter le problème (une forte augmentation de la latence p95 sur toutes les routes vers un même opérateur) et à basculer vers un canal alternatif avant la fermeture de la fenêtre OTP.
7. Combiné injoignable
Une petite fraction, mais persistante, des échecs de transmission de mots de passe à usage unique (OTP) n'est pas liée à l'infrastructure : le téléphone est éteint, hors couverture, en mode avion, le filtre anti-spam de l'opérateur bloque les expéditeurs inconnus, ou le numéro a été transféré vers un nouvel opérateur et les tables de routage n'ont pas encore convergé. Le problème se manifeste par des DLR expirés ou inconnus, dispersés sur toutes les routes et tous les identifiants d'expéditeur, sans concentration d'opérateurs. La solution consiste en la chaîne de repli décrite ci-dessous.
Créez le tableau de bord de diagnostic une seule fois, utilisez-le indéfiniment
La plupart des enquêtes OTP s'enlisent car l'équipe doit analyser les journaux bruts sous pression. Les équipes qui se rétablissent rapidement disposent d'un tableau de bord permanent avec cinq widgets : la distribution des statuts DLR par opérateur de destination (le graphique le plus utile), la latence de bout en bout p50/p95/p99 par route, le taux de livraison au niveau de l'identifiant de l'expéditeur, le taux de livraison au niveau du modèle de contenu et une série chronologique en temps réel du délai entre l'envoi et la livraison pour la dernière heure. Mettez-les en place une seule fois. Ils font toute la différence entre un diagnostic en quarante minutes et un diagnostic en quatre heures.
Des solutions de remédiation qui fonctionnent réellement
Liaisons directes uniquement pour les OTP
Le trafic marketing de masse et le trafic OTP ne doivent pas partager de liaison ni de route. Le marketing est sensible aux coûts, tolère la latence et peut emprunter des routes de gros ; l'OTP est critique en termes de latence et de délivrabilité, et nécessite une liaison directe. Les partager signifie qu'un pic de marketing sature le chemin OTP et qu'un filtre de parcours marketing nuit à la réputation de la route pour l'OTP.
Chaîne de secours, automatique et à durée limitée
Concevez le système en tenant compte du risque de défaillance de chaque canal et adaptez la chaîne de repli en conséquence : privilégiez l’authentification WhatsApp ou RCS lorsque l’utilisateur est joignable, utilisez les SMS comme solution de repli universelle et, en dernier recours, l’authentification vocale par code OTP. Le repli doit être automatique (aucune nouvelle tentative manuelle de la part de l’utilisateur), limité dans le temps (le délai d’attente avant basculement est inférieur à la tolérance de l’utilisateur, généralement de 8 à 15 secondes) et conditionnel (ne basculez pas en cas de réponse positive du DLR ; basculez en cas de délai d’attente dépassé ou de réponse négative du DLR). Le code OTP doit être généré une seule fois et réutilisé pour tous les canaux afin d’éviter de présenter deux codes valides à l’utilisateur.
Dédoublonner chaque nouvelle tentative
Lorsque l'utilisateur appuie sur « Renvoyer » ou que l'application effectue une nouvelle tentative automatique, vérifiez avant de renvoyer. L'API BroadNet n'accepte pas de clé d'idempotence : la déduplication se fait donc dans votre code — enregistrez chaque envoi avant de l'effectuer, conservez l'identifiant de message renvoyé par l'API et vérifiez le statut de ce message avant tout renvoi (voir idempotence et nouvelles tentatives sûres). Sans cette vérification, un premier envoi, certes lent mais réussi, suivi d'un renvoi automatique, génère deux codes OTP dans la boîte de réception de l'utilisateur. Si ce dernier utilise le plus ancien, la vérification échoue et l'équipe incrimine le service OTP alors que le problème réside dans la logique de nouvelle tentative.
Solution de repli vocale pour la longue queue
Environ 1 % des utilisateurs ne reçoivent pas de SMS chaque jour pour les raisons évoquées ci-dessus. Ce 1 % représente la minorité qui contacte le support. Un code OTP vocal (ou mot de passe à usage unique) – un appel qui lit le code à voix haute – résout la quasi-totalité de ces problèmes. C'est ce qui fait la différence entre un utilisateur agacé qui essaie un autre navigateur et un utilisateur perdu qui abandonne.
Le service OTP de BroadNet gère la liaison directe, la chaîne de repli et l'escalade vocale derrière un seul appel API, renvoie un identifiant de message à vérifier avant tout renvoi — et expose la ventilation DLR par canal et par opérateur sur laquelle repose le guide de diagnostic ci-dessus.
Ce à quoi ressemble le bien, en chiffres
Un système OTP performant, acheminant des SMS vers un marché réglementé du CCG via des routes directes d'opérateurs et doté d'une chaîne de secours fonctionnelle, devrait garantir : un taux de réussite de bout en bout supérieur à 99 % (l'utilisateur a bien vérifié l'authentification, et non pas seulement la réception du message), une latence p95 inférieure à cinq secondes sur le canal principal et un taux de basculement vers le canal secondaire mesurable mais faible (1 à 3 %). Si vos résultats sont nettement inférieurs, le problème provient très probablement de l'une des sept causes mentionnées ci-dessus ; il est donc essentiel de diagnostiquer la cause, et non de faire des suppositions.
Lectures complémentaires
- API SMS versus SMPP : lequel est le meilleur pour les entreprises ?
- Comment les banques doivent surveiller la distribution des codes OTP et la fraude
- Comment la vérification flash des appels affecte les revenus A2P des opérateurs
- Glossaire — qu'est-ce qu'un OTP, qu'est-ce qu'un DLR, qu'est-ce que la vérification par appel flash
- Pages produits — Service OTP et MyOTP voice OTP
- Couverture — Routage SMS et OTP A2P des Émirats arabes unis