Nouvelles tentatives de SMS transactionnels : quand réessayer, arrêter ou vérifier un envoi

Le problème : une défaillance technique ne justifie pas toujours un autre SMS

Une politique de nouvelles tentatives de SMS transactionnels définit la conduite à tenir lorsque le résultat d’un envoi n’est pas concluant ou indique un problème. Son objectif n’est pas de maximiser le nombre de tentatives, mais d’augmenter la probabilité qu’un message encore utile arrive sans créer de doublons, de confusion pour le destinataire ni de trafic inutile.

Le point de départ consiste à distinguer les états techniques disponibles. L’acceptation d’une requête par une plateforme, son acceptation ultérieure par un opérateur et une livraison signalée sont des événements différents. Par exemple, un état équivalent à « sent » peut signifier qu’un opérateur en amont a accepté le message, sans indiquer qu’il est arrivé sur le terminal.

Par conséquent, un timeout d’intégration, une réponse tardive ou une mise à jour d’état incomplète ne doivent pas automatiquement déclencher un nouveau SMS. Avant de répéter l’envoi, le système doit déterminer si le premier message a pu être accepté ou est toujours en cours de traitement.

• N’utilisez pas l’absence immédiate de DLR comme preuve d’un échec définitif.
• N’assimilez pas l’acceptation par un fournisseur ou un opérateur à une réception confirmée sur le téléphone.
• Ne considérez pas tout état d’erreur comme une cause transitoire.
• Ne privilégiez pas le volume de nouvelles tentatives au détriment de l’utilité du message et de l’expérience du destinataire.

Distinguez trois décisions : transport, métier et clôture

Une conception robuste sépare le message logique de la tentative technique. Le message logique correspond à l’intention métier, par exemple confirmer une opération, signaler un changement ou transmettre un code à usage unique. Une tentative technique est une exécution concrète visant à transporter cette intention via une connexion, un fournisseur ou une route disponible.

La nouvelle tentative de transport consiste à réexécuter le même message logique selon des règles limitées. Elle peut être appropriée lorsqu’une cause documentée et potentiellement transitoire existe, que le message reste utile et que le risque qu’un envoi soit déjà actif est maîtrisé.

Le renvoi métier est différent : il génère une nouvelle communication pour le destinataire. Il doit être régi par des règles de produit et d’expérience, et non par une erreur réseau isolée. Par exemple, demander un nouvel OTP peut invalider le précédent, modifier son expiration et nécessiter la suppression des demandes répétées.

La clôture définitive indique qu’aucune autre tentative ne sera effectuée pour cette unité logique. Elle peut résulter d’une expiration, d’une preuve de rejet définitif, de l’épuisement de la limite de tentatives, d’un risque élevé de doublon ou de la nécessité d’une vérification opérationnelle.

• Message logique : la notification que l’activité souhaite communiquer.
• Tentative technique : une exécution individuelle pour transmettre ce message logique.
• Nouvelle tentative de transport : nouvelle exécution technique selon la même intention.
• Renvoi métier : nouvelle notification, potentiellement avec un nouveau contenu ou une nouvelle durée de validité.
• Clôture : décision explicite de ne plus effectuer d’envoi.

Définissez d’abord la fenêtre d’utilité

La première condition de toute politique doit être la fenêtre d’utilité : la période pendant laquelle la réception du SMS conserve une valeur pour le destinataire et pour le processus. Une alerte d’événement, une confirmation d’opération et un OTP peuvent avoir des fenêtres très différentes. Il n’existe pas de durée universelle adaptée à tous les cas.

L’expiration technique configurée dans une plateforme de messagerie peut limiter le temps pendant lequel un message reste en file d’attente avant de ne plus être envoyé. Toutefois, cette configuration ne remplace pas la décision métier. Le système émetteur doit appliquer une date ou une heure d’expiration cohérente avec l’objectif du message.

Lorsque la fenêtre est terminée, l’action prudente consiste à arrêter les nouvelles tentatives. La livraison tardive d’une alerte peut être inutile ; celle d’un OTP peut créer de la confusion ou inciter l’utilisateur à saisir un code qui n’est plus valide.

• Définissez une expiration par type de message avant de configurer les délais d’attente et le nombre de tentatives.
• Évaluez l’utilité du point de vue du destinataire, et pas seulement selon la disponibilité de la route.
• Empêchez le démarrage d’une tentative s’il ne reste plus assez de temps pour que le message remplisse son objectif.
• Enregistrez l’expiration comme motif de clôture, et non comme une défaillance technique générique.

Classez le résultat avant de décider

Une politique opérationnelle nécessite sa propre classification, stable et auditable. Elle ne doit pas dépendre uniquement des libellés d’état d’une intégration donnée. L’objectif est de traduire le résultat disponible en une décision : arrêter, attendre, réessayer de manière contrôlée ou vérifier.

Les rejets définitifs sont des résultats pour lesquels les preuves disponibles indiquent qu’une répétition immédiate ne résoudra pas le problème. Une défaillance potentiellement transitoire est celle dont la cause documentée permet d’envisager une nouvelle tentative dans la fenêtre d’utilité. Une acceptation sans résultat final exige une attente et un rapprochement avant l’envoi d’une autre copie. L’état incertain impose une prudence maximale, car le premier message peut avoir progressé même si l’application n’a pas reçu de confirmation concluante.

Un état équivalent à « undelivered » apporte la preuve que le message n’a pas été livré, mais n’identifie pas une cause unique. Plusieurs raisons sont possibles, y compris le filtrage du contenu par l’opérateur ou la disponibilité du terminal. Il ne fait donc pas automatiquement de la nouvelle tentative l’action appropriée.

• Rejet définitif : arrêter et classer le cas pour vérification ou correction.
• Défaillance potentiellement transitoire : évaluer une nouvelle tentative limitée.
• Acceptation sans résultat final : attendre une fenêtre de rapprochement.
• État incertain : ne pas dupliquer sans vérifier les références, les événements tardifs et l’expiration.
• Livraison signalée : clôturer le flux technique, sans supposer davantage de preuves que celles disponibles.

Ne confondez pas DLR, acceptation et réception sur le terminal

Les accusés de livraison et les callbacks d’état sont précieux pour l’exploitation, mais ils doivent être interprétés selon ce qu’ils attestent réellement. Une plateforme peut indiquer qu’elle a accepté la requête ; un état d’envoi peut indiquer l’acceptation par un opérateur en amont ; et un DLR peut communiquer un résultat ultérieur. Ce sont des signaux opérationnels distincts.

La réception indépendante sur le terminal ne doit pas être déduite du seul fait qu’un fournisseur a accepté une requête ou qu’un état d’envoi vers le réseau existe. Même lorsqu’un état de livraison signalée est disponible, la politique doit le décrire précisément comme une preuve rapportée par la chaîne de messagerie disponible, et non comme une preuve absolue de lecture ou d’action de l’utilisateur.

Cette distinction est essentielle pour éviter deux erreurs opposées : répéter un message qui a probablement déjà progressé, ou déclarer une réussite métier alors que seul un état de transport est connu.

• Conservez la signification d’origine de chaque état reçu.
• Modélisez séparément le succès du transport, la livraison signalée et le succès métier.
• Évitez d’utiliser un DLR comme preuve de consentement, d’identité, de titularité du numéro ou de lecture du message.
• Définissez les preuves suffisantes pour clôturer chaque type de flux.

Critères opérationnels pour autoriser une nouvelle tentative

Une nouvelle tentative doit exiger des conditions cumulatives, et non un unique signal d’erreur. Au minimum, évaluez la cause documentée, le temps déjà écoulé, la criticité du message, le risque de duplication et les restrictions applicables au destinataire ou à l’expéditeur.

La cause doit être interprétable. En l’absence de cause claire ou lorsqu’une référence fournisseur est en attente, traitez le cas comme incertain et privilégiez le rapprochement. Le temps écoulé doit être comparé à la fenêtre d’utilité et à une période d’attente conçue pour permettre des mises à jour tardives. La criticité peut justifier une vérification plus rapide, mais elle n’élimine pas le risque de dupliquer une notification.

Il convient également d’examiner si le contenu, l’identifiant d’expéditeur ou le destinataire peuvent être liés au résultat. Une erreur de livraison ne démontre pas à elle seule lequel de ces éléments a causé le problème. En présence d’un schéma persistant, il faut vérifier la configuration, le contenu, les événements et la connectivité plutôt que de répéter indéfiniment.

• La cause disponible est-elle documentée et compatible avec un comportement transitoire ?
• Le message se situe-t-il toujours dans sa fenêtre d’utilité ?
• Existe-t-il un identifiant fournisseur ou une mise à jour en attente susceptible de confirmer l’état ?
• Le destinataire pourrait-il recevoir deux copies si une nouvelle tentative est effectuée maintenant ?
• Le message est-il suffisamment critique pour justifier le risque résiduel ?
• Existe-t-il une restriction récurrente liée au destinataire, à l’expéditeur ou au contenu nécessitant une vérification ?

Concevez une séquence de tentatives avec des conditions d’arrêt explicites

Une séquence de nouvelles tentatives doit être définie par type de message, et non comme une règle globale. Elle doit préciser le nombre maximal de tentatives techniques, le délai entre elles, l’expiration absolue, les causes admissibles et les conditions d’arrêt. Si l’un de ces éléments n’est pas défini, le comportement restera exposé à des décisions improvisées.

Les délais d’attente doivent permettre la réception d’événements et de callbacks tardifs avant de générer une autre copie. Les callbacks HTTP peuvent arriver dans le désordre et présenter des variations de latence ; certaines transitions peuvent se produire très près les unes des autres. Une automatisation ne devrait donc pas décider uniquement à partir du premier événement observé ou du premier timeout local.

La limite de tentatives doit être faible et justifiée pour le cas d’usage. Si la dégradation persiste, davantage de répétitions peuvent accroître les doublons, les coûts opérationnels et la frustration sans corriger la cause. Le dernier résultat doit conduire à une clôture ou à une vérification, et non à une boucle infinie.

• Fixez un nombre maximal de tentatives techniques par message logique.
• Définissez un délai minimal de rapprochement avant chaque nouvelle tentative.
• Appliquez une expiration absolue qui prévaut sur toute nouvelle tentative en attente.
• Autorisez les nouvelles tentatives uniquement pour des causes préalablement approuvées.
• Arrêtez le flux en cas de livraison signalée, de rejet définitif, d’expiration, de risque élevé de doublon ou d’épuisement de la limite.
• Orientez les cas répétés ou non concluants vers une vérification opérationnelle.

OTP : coordonnez livraison, expiration et sécurité

Les OTP et autres secrets d’authentification exigent une politique plus stricte. Un secret hors bande a une durée de vie courte et est transmis par un canal indépendant. Si le code a déjà expiré, une nouvelle tentative de transport n’apporte aucune valeur et peut dégrader l’expérience.

La validité du code, la limite de tentatives d’authentification et la suppression des demandes répétées doivent fonctionner comme un ensemble. Lorsqu’un nouveau code est généré, le système doit décider explicitement ce qu’il advient du précédent, quelle tentative technique reste associée à chaque code et quels messages sont supprimés. Ne laissez pas la couche de transport continuer à renvoyer un code que le backend d’authentification considère déjà comme invalide.

Les flux PSTN/SMS nécessitent également des alternatives d’authentification et des contrôles de risque adaptés au contexte. Une couverture limitée, des changements d’appareil ou de carte SIM, la portabilité du numéro et des comportements anormaux sont des exemples de signaux pouvant justifier des contrôles supplémentaires. Le renvoi de SMS ne doit pas devenir la réponse automatique à une dégradation persistante.

Les réponses destinées à l’utilisateur doivent être prudentes, en particulier pour l’authentification et la récupération de compte. Évitez les messages qui révèlent inutilement si un compte existe ou quel est son état.

• Associez chaque OTP à une expiration métier sans ambiguïté.
• Ne réessayez pas d’envoyer un OTP après son expiration.
• Contrôlez les demandes répétées afin de réduire la fatigue et le trafic inutile.
• Appliquez une limitation de débit aux tentatives d’authentification lorsque cela est approprié.
• Définissez des alternatives d’authentification lorsque le SMS n’est pas adapté ou n’est pas disponible.
• Conservez des réponses externes génériques lorsque nécessaire afin d’éviter l’énumération de comptes.