Gestion des files d’attente de sortie A2P SMS : admission, résorption et reprise
Un guide opérationnel pour définir quels messages la file accepte, comment les classer en cas de défaillance, quand ils expirent et comment rétablir le flux sans confondre acceptation en aval et livraison au destinataire.
La file commence là où un système retient le message
Une chaîne A2P peut comporter plusieurs files : dans l’application émettrice, sur la plateforme de messagerie, sur une connexion ou chez un intermédiaire, ainsi que dans les systèmes en aval. Pour assurer une exploitation claire, identifiez la file que vous mesurez et déterminez qui est responsable de chaque transition.
Un message « en file d’attente » n’est pas encore nécessairement accepté par le système suivant, et l’acceptation par ce système ne prouve pas non plus qu’il est arrivé sur le téléphone. Définissez explicitement la frontière des responsabilités : par exemple, message reçu par la plateforme, tentative d’envoi, réponse d’acceptation du système suivant et résultat ultérieur de livraison, s’il est disponible.
- Attribuez à chaque message un identifiant qui peut être corrélé entre les systèmes que vous contrôlez.
- Enregistrez l’heure d’entrée dans la file, celle de la tentative de traitement et le résultat renvoyé par le système suivant.
- Distinguez les états internes de ceux communiqués par les interfaces ou les rapports externes.
Définissez des états qui expliquent ce qui s’est passé
Un modèle interne utile permet de distinguer les tâches en attente de celles en cours de traitement et de celles qui ont déjà obtenu une réponse du système suivant. Il doit aussi représenter les messages différés, expirés ou mis de côté pour examen. Ce sont des catégories opérationnelles : elles ne doivent pas être présentées comme une liste d’états SMPP normatifs ni automatiquement confondues avec les codes d’une interface.
Documentez les transitions autorisées, l’événement qui les déclenche et le système qui fournit les éléments de preuve. Par exemple, une réponse d’acceptation en aval peut clore la responsabilité de la file locale, mais ne doit pas être présentée comme une livraison finale au destinataire sans preuve appropriée.
- En attente : accepté par la plateforme, sans tentative active à ce stade.
- En cours de traitement : un processus de traitement gère l’envoi.
- Accepté en aval : le système suivant a confirmé qu’il accepte le message ; cela ne signifie pas qu’il a été reçu sur le terminal.
- Différé : le traitement est reporté conformément à une politique définie.
- Expiré : le message a perdu son utilité temporelle et ne doit pas être envoyé comme s’il était toujours valable.
- À examiner : une décision opérationnelle est nécessaire avant de reprendre le traitement ou de clôturer le dossier.
Admettez le trafic de façon à protéger la capacité
Une file ne devrait pas croître sans limite opérationnelle. Définissez des limites d’admission et de capacité en fonction des ressources que vous contrôlez réellement : stockage, processus de traitement disponibles, connexions et capacité configurée pour les destinations ou les classes de trafic. Il n’existe pas de seuil universel pouvant être fixé sans connaître l’architecture, les accords et le comportement observé.
La segmentation par destination ou classe peut contribuer à empêcher qu’un flux problématique monopolise les ressources destinées aux autres flux. Elle ajoute toutefois de la complexité : précisez ce qui se passe lorsqu’une limite est atteinte, comment le résultat est communiqué à l’émetteur et qui peut ajuster la politique. N’acceptez pas un message si le système ne peut pas le conserver de manière fiable jusqu’à son traitement ou le rejeter clairement.
- Fixez des limites par file et par segment lorsque les comportements ou les exigences diffèrent.
- Définissez explicitement l’action à appliquer lorsque la capacité est atteinte : rejeter, différer ou appliquer une autre politique documentée.
- Assurez-vous que l’application émettrice peut distinguer une admission d’un rejet et gérer ses propres nouvelles tentatives sans créer de doublons.
- Réévaluez les limites à partir des données d’entrée, de sortie, d’ancienneté et de ressources, plutôt que de chiffres génériques.
Classez la défaillance avant de réessayer
Toutes les défaillances ne justifient pas le même traitement. Une saturation temporaire, une indisponibilité, un rejet potentiellement transitoire et une erreur nécessitant de corriger le message ou la configuration ont des implications différentes. Utilisez la réponse concrète de l’interface ou du système connecté ainsi que la documentation applicable pour la classification ; n’inventez pas d’équivalence entre les codes.
Pour chaque classe de défaillance, documentez si le message doit faire l’objet d’une nouvelle tentative, être différé, rejeté ou soumis à examen. Les nouvelles tentatives doivent être limitées et coordonnées entre l’émetteur et la plateforme : si les deux répètent l’envoi sans coordination, ils risquent d’accroître la charge et de créer des doublons. Conservez le résultat d’origine pour faciliter le diagnostic.
- Saturation : protégez les ressources et appliquez la politique d’admission ou de report définie.
- Indisponibilité : déterminez s’il convient d’attendre et de réessayer, en limitant les tentatives et en consignant leur motif.
- Rejet potentiellement récupérable : confirmez quelle condition doit changer avant une nouvelle tentative.
- Erreur permanente ou non corrigeable automatiquement : évitez les cycles de nouvelles tentatives et orientez le cas vers une clôture ou un examen.
- Dans tous les cas, consignez la réponse observée et la décision appliquée.
Gérez l’ordre et les priorités sans provoquer de famine
FIFO — premier entré, premier sorti — est une option simple lorsque les messages d’une file ont les mêmes exigences d’urgence et qu’aucune raison opérationnelle ne justifie de modifier l’ordre. Si certaines classes ont une durée de validité ou une priorité différente, une politique explicite peut être plus appropriée, mais elle doit préserver la traçabilité et éviter que le trafic de priorité inférieure soit bloqué indéfiniment.
Avant d’introduire des priorités, définissez quels messages peuvent appartenir à chaque classe, qui détermine cette classification et comment vérifier le bon fonctionnement de la politique. Ne fondez pas les priorités sur des contenus sensibles et ne les utilisez pas pour contourner les contrôles de consentement ou de conformité.
- Utilisez FIFO lorsque l’ordre doit être préservé et que la classe de messages est homogène.
- Ne séparez les classes que si une nécessité opérationnelle est justifiée et vérifiable.
- Mesurez le temps d’attente par classe et vérifiez si une priorité provoque la famine d’autres classes.
- Documentez le traitement des messages de même priorité et celui des changements de classe.
Alignez la durée de validité sur l’utilité du message
La durée de validité indique pendant combien de temps un message reste utile à l’envoi. Un code à usage unique, une notification transactionnelle et une campagne autorisée peuvent avoir des exigences temporelles différentes ; ne supposez pas qu’ils partagent une durée appropriée. Le responsable du message doit définir cette utilité et la plateforme doit appliquer une politique cohérente avec celle-ci.
Lorsqu’un message expire, ne l’envoyez pas silencieusement comme s’il était encore valable. Consignez l’expiration et communiquez le résultat de sorte que le système émetteur puisse décider de la suite à donner. Si un nouvel envoi est envisagé, il doit relever d’une nouvelle décision métier et non d’une répétition automatique d’un contenu obsolète.
- Définissez la durée de validité pour chaque cas d’usage avec le responsable du message.
- Si la politique l’exige, vérifiez l’ancienneté avant chaque nouvelle tentative.
- Distinguez l’expiration du rejet et de l’échec de livraison.
- Évitez de réactiver automatiquement les messages expirés sans décision explicite.
Rétablissez le service par une résorption contrôlée
Après une interruption, la reprise ne consiste pas simplement à relancer tous les envois en attente. Vérifiez d’abord que la cause de l’accumulation est résolue et que le système suivant peut accepter le trafic. Libérez ensuite les tâches progressivement, en fonction de la capacité disponible et dans les limites de concurrence définies par la configuration et les accords applicables.
Pendant la résorption, surveillez toute nouvelle hausse de l’ancienneté ou de la profondeur de la file, l’augmentation des rejets et le maintien des résultats attendus. La réduction de la file ne suffit pas à prouver que le service est rétabli si les messages expirent, sont rejetés ou sont soumis à examen sans que l’équipe s’en aperçoive.
- Identifiez et corrigez la cause de l’interruption avant d’accélérer les envois.
- Reprenez le traitement avec des limites contrôlées, et non en vidant sans restriction les messages accumulés.
- Vérifiez séparément l’acceptation en aval et les résultats ultérieurs.
- Prévoyez une procédure pour interrompre de nouveau le traitement si l’accumulation réapparaît ou si les résultats se dégradent.
Surveillez la santé de la file, pas seulement sa taille
La profondeur indique le nombre de messages en attente, mais ne suffit pas à expliquer si la situation s’améliore. Ajoutez l’ancienneté du message le plus ancien, les taux d’entrée et de sortie ainsi que les résultats ventilés par destination et par classe. Interprétez ces métriques avec les événements d’admission, de rejet, de report et d’expiration.
L’acceptation par le système suivant doit être présentée comme une acceptation, et non comme une livraison finale. Si des rapports de livraison sont reçus, leur signification dépend de leur source et de leur niveau de vérification : un DLR reçu n’équivaut pas nécessairement à une réception sur le terminal vérifiée de manière indépendante. Documentez cette incertitude dans les tableaux de bord et les rapports.
- Profondeur de la file et ancienneté du message le plus ancien.
- Taux d’entrée et de sortie, mesurés sur des intervalles adaptés à l’exploitation.
- Acceptations, rejets, reports, expirations et messages soumis à examen.
- Résultats ventilés par destination et par classe, selon des définitions cohérentes.
- Alertes liées à vos propres seuils opérationnels, révisés à partir de données réelles.
Questions fréquentes
L’acceptation d’un message en aval signifie-t-elle qu’il a été livré ?
Non. Elle indique que le système suivant a accepté le message, d’après la réponse observée. Elle ne prouve pas à elle seule que le téléphone l’a reçu. Les rapports de livraison doivent également être interprétés en fonction de leur source et de leur niveau de vérification.
Quelle devrait être la taille maximale d’une file de sortie ?
Il n’existe pas de valeur universelle applicable à toutes les plateformes. La limite dépend des ressources, des destinations, des classes de trafic, des accords et du comportement observé. Définissez-la à partir des données opérationnelles et prévoyez explicitement l’action à appliquer lorsqu’elle est atteinte.
Faut-il réessayer l’envoi de tout message rejeté ?
Non. Déterminez d’abord si la cause est temporaire, corrigeable ou permanente à partir de la réponse et de la documentation de l’interface connectée. Limitez les nouvelles tentatives, évitez que l’émetteur et la plateforme réessaient sans coordination et ne réessayez pas automatiquement d’envoyer un contenu expiré.
Faut-il toujours utiliser FIFO ?
FIFO est pertinent lorsque l’ordre doit être préservé et que les messages ont des exigences similaires. Si des priorités sont nécessaires, définissez explicitement les classes et les règles, puis vérifiez qu’une classe n’en laisse pas une autre en attente indéfiniment.
Sources consultées
- SMPP v3.4, Issue 1.2SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA