Limites de débit TPS des SMS A2P par destination : comment les convenir et les gérer
Un plafond TPS annoncé ne garantit pas la livraison. Apprenez à en préciser la portée, à contrôler les files d’attente par destination et à évaluer les signaux opérationnels sans confondre acceptation et livraison.
Un TPS annoncé ne garantit pas la livraison
TPS désigne généralement le nombre de messages par seconde, mais le chiffre annoncé n’est exploitable que si l’on sait ce qu’il mesure, où il s’applique et dans quelles conditions. Il n’existe pas de limite universelle que l’on puisse déduire du seul pays, de l’opérateur ou du type de connexion : il faut la confirmer auprès de la personne qui gère la route et en consigner la portée.
Il faut également distinguer les différentes étapes de l’envoi. Une réponse d’acceptation confirme tout au plus qu’une requête a été admise à un point de la chaîne ; elle ne prouve pas à elle seule que le SMS est arrivé sur le téléphone. Les états ultérieurs, y compris les DLR, doivent être interprétés en fonction de leur origine et de leur niveau de vérification.
- Considérez le TPS communiqué comme une condition à clarifier, et non comme une promesse générale de livraison.
- Consignez séparément l’admission des requêtes et les états ultérieurs du message.
- Ne transposez pas la valeur d’une route à d’autres destinations, opérateurs ou expéditeurs.
Que préciser avant de configurer le trafic
Demandez une définition écrite du périmètre de la limite et de son mode de mesure. Précisez si elle s’applique à un pays, un opérateur, une route, un expéditeur, un compte ou une session. Demandez également si elle varie selon le type de trafic, par exemple OTP, transactionnel ou marketing légitime, et quelle fenêtre temporelle sert à la calculer.
La connexion ne remplace pas cet accord. SMPP définit certains aspects de l’échange entre une application et un SMSC, tandis que HTTP décrit la sémantique des requêtes et des réponses ; aucune de ces spécifications ne fixe, à elle seule, un TPS garanti pour une route A2P ni ne confirme la livraison sur un mobile.
- Destination et opérateur, ou groupe d’opérateurs, concernés.
- Identifiant de route, compte, expéditeur et types de trafic inclus.
- Unité, fenêtre de mesure et traitement des requêtes rejetées.
- Limite par session et limite agrégée, si les deux existent.
- Conditions applicables aux pics de trafic, à la concurrence, aux pauses et aux changements de capacité.
- Codes de réponse et contact opérationnel pour les incidents ou les ajustements.
Distinguer débit soutenu, pic de trafic et concurrence
Ne supposez pas qu’un débit nominal signifie que ce volume peut être envoyé en continu. Demandez au fournisseur de préciser si la valeur correspond à un débit soutenu, à un maximum instantané ou à une moyenne calculée sur une fenêtre donnée. Si les pics de trafic sont autorisés, demandez-en les conditions et la durée ; si le nombre de sessions ou de requêtes simultanées est limité, consignez ces limites séparément.
Les éléments disponibles ne permettent pas de recommander des valeurs universelles pour ces paramètres. Si le fournisseur ne peut pas les définir, indiquez que la condition n’est pas confirmée et évitez de concevoir le système sur la base d’une interprétation optimiste.
- Documentez chaque paramètre séparément ; ne réduisez pas toutes les limites à un seul TPS.
- Distinguez le débit de messages, le nombre de requêtes simultanées et les sessions de connexion.
- Notez si la limite est partagée entre destinations, expéditeurs ou connexions, ou si le fournisseur ne l’a pas encore clarifié.
Concevoir des contrôles d’admission et des files d’attente par destination
Organisez le trafic dans des files d’attente correspondant au périmètre réel de chaque limite. Si un fournisseur confirme des limites différentes par opérateur ou par route, évitez qu’une file globale masque un dépassement dans l’un de ces groupes. Avant de mettre le contrôle en production, vérifiez comment la destination est identifiée et ce qui arrive aux messages dont le routage n’est pas encore déterminé.
Le débit de sortie doit pouvoir être ajusté sans supprimer silencieusement des messages. Définissez ce qui reste en file d’attente, ce qui est réessayé et comment éviter que les nouvelles tentatives n’aggravent une saturation. Les critères précis dépendent de l’accord et du comportement observé ; sans ces données, aucune configuration universelle ne peut être recommandée.
- Associez chaque file à une limite confirmée et conservez ce lien dans la configuration.
- Définissez explicitement les règles de pause, de reprise et de nouvelle tentative après un rejet.
- Consignez les changements de débit et de configuration afin de les rapprocher des résultats.
- Veillez à ce que les priorités de trafic ne contournent pas les restrictions de destination.
Interpréter les signaux opérationnels dans leur contexte
Une hausse des rejets ou de la latence des réponses d’acceptation peut indiquer qu’une limite est en train d’être atteinte, mais ne permet pas à elle seule d’en déterminer la cause. Vérifiez si elle coïncide avec un changement de volume, de route, de session ou de configuration, et demandez au fournisseur d’interpréter les codes de réponse. N’attribuez pas automatiquement le problème à une limite TPS.
Surveillez aussi la profondeur et l’ancienneté des files d’attente, les requêtes acceptées par rapport aux requêtes rejetées et les états ultérieurs disponibles. La latence d’admission et les DLR correspondent à des étapes différentes ; la réception d’un DLR ne doit pas être présentée comme une vérification indépendante de la réception sur le téléphone en l’absence d’une telle vérification.
- Rejets : comptabilisez-les par code, destination, route et période.
- Latence : distinguez le temps de réponse de l’API ou de la session des états ultérieurs.
- Files d’attente : surveillez leur profondeur, leur ancienneté et leur rythme de vidage.
- États : distinguez l’acceptation, les DLR et toute confirmation de réception réellement vérifiable.
Effectuer des tests progressifs avec consentement
Avant un test, convenez avec le fournisseur de la destination, de l’expéditeur, du type de trafic, de la fenêtre, du débit initial et des conditions d’arrêt. Utilisez uniquement des messages légitimes et adressez-les à des destinataires ayant consenti à recevoir ce trafic, dans le respect des règles applicables. N’augmentez pas la charge sur des destinations réelles sans autorisation explicite.
Augmentez le volume de manière contrôlée, consignez chaque changement et arrêtez le test en présence des signes d’erreur ou de saturation convenus. Un test décrit le comportement observé dans ces conditions ; il ne transforme pas le résultat en capacité garantie pour la production, ni en preuve applicable à d’autres routes ou périodes.
- Convenez à l’avance du périmètre et des critères d’arrêt.
- Gardez constantes les variables qui ne sont pas évaluées et documentez tout changement.
- Ne vous servez pas d’un test non autorisé pour remplacer une confirmation contractuelle.
Réagir à une éventuelle saturation
En cas de hausse persistante des rejets, de la latence ou de la taille des files d’attente, réduisez le débit d’admission et suivez la procédure convenue. Si la dégradation se poursuit, mettez en pause le trafic concerné, le cas échéant, et contactez le fournisseur en lui communiquant des données précises. N’augmentez pas automatiquement la concurrence et n’accélérez pas les nouvelles tentatives : sans connaître les règles de la route, ces actions peuvent accroître la pression ou compliquer le diagnostic.
Conservez une chronologie de l’incident : heure, destination, route, volume, changements de configuration, codes reçus et évolution des files d’attente. Demandez confirmation si une limite a été atteinte, si une autre condition opérationnelle est en cause ou si la limite en vigueur a changé. Escaladez l’incident par les canaux convenus et consignez la réponse.
- Réduisez le débit concerné et évitez les nouvelles tentatives agressives qui n’ont pas été convenues.
- Fournissez les codes d’erreur et les indicateurs ventilés par destination et par route.
- Demandez une décision opérationnelle et une confirmation écrite de tout changement de limite.
- Reprenez progressivement le trafic conformément à la procédure convenue.
Réviser les limites et conserver les éléments de preuve
Tenez un registre versionné qui distingue les conditions annoncées par le fournisseur de celles observées en production. Indiquez la date de confirmation, le périmètre, les paramètres, les exceptions et la personne chargée de valider tout changement. Si les indicateurs diffèrent de ce qui a été convenu, demandez un réexamen ; ne remplacez pas la limite contractuelle par un maximum observé lors d’un test bref.
Mettez à jour la fiche en cas de changement de route, de destination, d’expéditeur, de session ou de profil de trafic, ainsi qu’après tout incident important. Les cartes publiques de chiffres de BulkSMSMarket sont démonstratives tant que les données contractuelles des routes n’y sont pas intégrées ; elles ne doivent donc pas être considérées comme des limites commerciales en vigueur.
- Conservez séparément la limite annoncée, la configuration appliquée et les éléments observés.
- Consignez la période et les conditions de chaque test ou incident.
- Réexaminez l’accord avec le fournisseur avant de modifier la capacité opérationnelle.
Questions fréquentes
Existe-t-il une limite TPS universelle pour les SMS A2P par pays ?
Les informations disponibles ne permettent pas d’établir une valeur universelle. Confirmez la limite auprès de la personne qui gère la route et documentez les destinations, opérateurs, expéditeurs, sessions et fenêtres de mesure auxquels elle s’applique.
L’acceptation de la requête signifie-t-elle que le SMS a été livré ?
Non. L’acceptation indique que la requête a été admise à un point du processus, mais ne prouve pas à elle seule la livraison sur le téléphone. Interprétez séparément les états ultérieurs et leur niveau de vérification.
SMPP ou HTTP fixent-ils le débit garanti d’une route ?
Pas d’après les éléments disponibles. SMPP et HTTP définissent certains aspects des échanges techniques, mais leurs spécifications ne garantissent pas, à elles seules, une capacité A2P par destination.
Que faire si les limites de pic de trafic ou de concurrence ne sont pas définies ?
Demandez une définition écrite et indiquez que ces paramètres ne sont pas confirmés tant que vous ne l’avez pas reçue. Ne déduisez pas leur valeur du TPS nominal ni d’un test isolé.
Un test réussi démontre-t-il une capacité de production durable ?
Pas nécessairement. Il décrit uniquement le comportement observé dans les conditions de ce test. Le résultat ne garantit pas la capacité future et ne peut pas être automatiquement extrapolé à d’autres destinations, routes ou périodes.
Sources consultées
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)Internet Engineering Task Force
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA