Restrictions des routes SMS A2P : comment les documenter pour éviter les envois non pris en charge et les décisions de routage opaques

Pourquoi les restrictions de route doivent être des données opérationnelles

Une restriction de route SMS A2P est une condition qui détermine si un message précis peut être envoyé par une route donnée. Elle peut dépendre de la destination de terminaison, de l’opérateur lorsque cela s’applique, du type de trafic, de l’expéditeur, du contenu, d’un enregistrement préalable, de la capacité disponible ou d’une condition commerciale.

Ces conditions sont souvent dispersées entre contrats, e-mails, portails de fournisseurs, tickets et connaissances informelles détenues par une personne de l’équipe. Ce modèle est difficile à auditer et sujet aux erreurs : une route peut être techniquement disponible tout en ne prenant pas en charge une destination donnée, un Sender ID, le trafic promotionnel, les liens ou un certain niveau de volume.

La matrice de restrictions ne remplace ni le contrat, ni la réglementation applicable, ni les obligations de consentement, ni les exigences de l’opérateur, ni la confirmation du fournisseur. Son rôle est de transformer des informations dispersées en règles consultables, traçables et exploitables avant d’accepter, d’acheminer ou d’augmenter le trafic.

• Traitez chaque restriction comme une règle au périmètre explicite, et non comme une note générique.
• Modélisez concrètement la destination de terminaison ; ne déduisez pas les exigences uniquement du pays d’origine de l’expéditeur.
• Utilisez la numérotation internationale normalisée comme champ de validation de la destination, conformément à la recommandation UIT-T E.164 relative au plan international public de numérotage.
• Distinguez les restrictions techniques du SMS, les conditions commerciales d’une route et les exigences réglementaires, de consentement ou de réseau.
• Conservez pour chaque règle la source primaire, la date de consultation, le propriétaire, la version, la période de validité, le périmètre exact et le statut de vérification.

Une route disponible n’est pas nécessairement une route adaptée

La disponibilité d’une interface ou d’une connexion ne prouve pas qu’une route soit adaptée à tout le trafic. Une même route peut accepter des intégrations HTTP ou SMPP tout en limitant les expéditeurs, en exigeant un préenregistrement, en n’acceptant que certains cas d’usage ou en appliquant des limites de capacité différentes selon le compte, l’expéditeur ou le canal.

La bonne question ne consiste pas uniquement à demander s’il existe une route vers un pays. Elle doit prendre la forme d’une évaluation de compatibilité : cette destination, cet expéditeur, ce cas d’usage, ce contenu et ce schéma d’envoi sont-ils pris en charge par cette route à la date de la décision ?

Cette approche évite une conclusion particulièrement risquée : interpréter une condition commerciale, l’acceptation d’un message ou une déclaration de disponibilité comme une garantie technique de livraison ou comme le respect des obligations applicables. Même lorsqu’un envoi est accepté pour traitement, le résultat peut dépendre d’éléments échappant au contrôle d’une seule partie de la chaîne de messagerie.

• Destination : pays et, lorsque les preuves l’exigent, réseau ou opérateur de terminaison.
• Trafic : OTP ou 2FA, notification de compte, alerte de fraude, service client, marketing avec consentement ou autre catégorie contrôlée.
• Expéditeur : alphanumérique, numéro, code court ou autre type autorisé par la destination et la route.
• Contenu : langue, encodage, liens, raccourcisseurs d’URL, modèles, mots-clés de désinscription et éléments de marque.
• Schéma d’envoi : volume, débit, récurrence, période de validité et besoin de réponse.
• Conditions d’activation : préenregistrement, approbation, campagne, consentement et tests requis.

Les catégories minimales d’un tableau de restrictions

Un tableau utile doit permettre aux opérations, aux achats, à la conformité et à l’ingénierie de répondre à la même question à l’aide des mêmes champs. Une colonne « autorisé » ou « non autorisé » ne suffit pas, car cette réponse manque de contexte et n’explique pas quelle condition la modifie.

La granularité doit être suffisante pour éviter des règles trop génériques par pays. Si une condition n’a été confirmée que pour un opérateur, un réseau ou un type d’expéditeur, la fiche doit refléter cette limite plutôt que de l’étendre à toute la destination.

Les protocoles d’intégration ne doivent être enregistrés que lorsqu’ils affectent l’acceptation opérationnelle du trafic et qu’il existe des preuves spécifiques à la route ou au fournisseur concerné. La disponibilité d’une interface HTTP ou SMPP ne confirme pas à elle seule qu’un type de trafic est admissible.

Un HLR Lookup peut être utilisé comme signal technique de réseau dans le cadre d’une décision opérationnelle, mais il ne prouve ni le consentement, ni l’identité, ni la titularité du numéro, ni une livraison garantie. Des observations issues de tests opérationnels doivent rester limitées à leur périmètre : elles n’équivalent ni à une certification, ni à une couverture universelle, ni à une garantie de livraison, ni à une validation réglementaire.

Avant d’acheter ou de vendre de la capacité A2P, il est préférable de vérifier le périmètre de chaque restriction, les preuves disponibles et leur validité. Des règles précises et à jour réduisent l’ambiguïté dans la gestion responsable de la capacité.

• Identifiant de règle : code unique et stable destiné aux références dans les tickets, contrôles et modifications.
• Destination : pays, préfixe ou modèle de numérotation applicable, ainsi que format attendu.
• Opérateur ou réseau : obligatoire uniquement lorsque la condition est confirmée à ce niveau.
• Route ou relation commerciale : identifiant interne de la route et périmètre de la condition.
• Type de trafic : valeur contrôlée, et non libellé libre.
• Type et valeur de l’expéditeur : catégorie d’expéditeur, restrictions de longueur ou de format et capacité de réponse lorsque cela s’applique.
• Contenu : exigences relatives aux modèles, liens, domaines, raccourcisseurs, langues ou catégories non prises en charge.
• Protocoles d’intégration : interface, paramètres ou limitations affectant l’acceptation opérationnelle du trafic, lorsqu’ils sont documentés pour la route spécifique.

Déclaré, vérifié et en attente de confirmation

La qualité d’une matrice dépend autant de ce qu’elle enregistre que de la façon dont elle exprime le niveau de certitude. Une règle déclarée par un fournisseur, une exigence confirmée par une documentation officielle et une condition observée lors d’un test n’ont pas la même valeur probante.

Utilisez des statuts de preuve explicites. Cela évite qu’une équipe transforme une déclaration commerciale en fait vérifié, ou qu’une observation technique limitée devienne une règle universelle. Le statut doit accompagner chaque restriction, et ne pas rester dans une note générale sur la route.

Définissez également une décision par défaut. Lorsqu’une condition est en attente de confirmation, contradictoire, expirée ou hors périmètre, le trafic ne doit pas être accepté ou routé automatiquement au titre de cette règle ; il doit être soumis à une confirmation documentée ou à une revue humaine.

• Déclarée : condition communiquée par la contrepartie, en attente de validation indépendante ou de preuves documentaires suffisantes.
• Vérifiée : condition étayée par une source primaire, une approbation documentée, une clause applicable ou une preuve opérationnelle au périmètre défini.
• En attente de confirmation : information incomplète, contradictoire, expirée ou dont l’application au cas d’usage n’est pas clairement établie ; décision par défaut : pas d’acceptation ni de routage automatique.
• Non applicable : la condition a été évaluée et ne correspond pas au périmètre de cette fiche ; elle doit inclure une justification.
• Retirée ou remplacée : règle historique qui ne doit pas être utilisée pour de nouvelles décisions, mais conservée à des fins d’audit.

Sender ID, préenregistrement et capacité de réponse

L’expéditeur doit être documenté comme un objet soumis à des règles, et non comme un texte ajouté à la fin du flux. La fiche doit indiquer quel type d’expéditeur sera utilisé, s’il est autorisé dans la destination, s’il nécessite un enregistrement préalable et quelles preuves démontrent son statut.

Les Sender ID alphanumériques méritent une attention particulière. Ils sont couramment utilisés pour une messagerie unidirectionnelle et ne doivent pas être considérés comme un canal de réponse, sous réserve des règles de la destination et du fournisseur. La documentation de Twilio indique que les Sender ID alphanumériques ne sont pas disponibles pour les destinations aux États-Unis et au Canada ; cette condition s’applique au fournisseur documenté et ne doit pas être automatiquement extrapolée à d’autres routes ou fournisseurs.

Lorsqu’un préenregistrement est requis, enregistrez l’identifiant de la demande ou de la campagne, son statut, la date d’approbation, l’entité approbatrice, la date d’expiration lorsqu’elle existe, ainsi que les messages ou domaines couverts. Un expéditeur actif ou enregistré ne prouve pas à lui seul que tout le trafic associé est admissible.

• Nom ou valeur de l’expéditeur demandé et valeur effectivement approuvée.
• Type d’expéditeur et capacité à recevoir des messages entrants ou des réponses.
• Exigence de préenregistrement par destination et statut du dossier.
• Marque, cas d’usage, exemples de messages, liens et mots-clés lorsqu’ils font partie du processus applicable.
• Date d’activation, validité, renouvellement et responsable chargé de vérifier le statut.
• Restrictions liant l’expéditeur à une campagne, un domaine, un type de trafic ou une route précise.

Classez le trafic avant d’appliquer les règles

La catégorie de trafic ne doit pas être un champ libre tel que « transactionnel » sans définition. Une classification contrôlée permet d’appliquer des restrictions cohérentes et d’identifier les cas où un flux mixte nécessite un examen complémentaire.

Dans le contexte des campagnes A2P aux États-Unis, les catégories documentées comprennent la 2FA, les notifications de compte, le service client, les alertes de fraude, le marketing et les campagnes mixtes. La classification exacte applicable dépendra de la destination, du cadre d’enregistrement et de la route ; la matrice doit donc conserver le catalogue utilisé et sa source.

Pour le trafic récurrent, la documentation doit distinguer le mécanisme d’inscription, le mécanisme de désinscription et l’assistance. Dans le guide de The Campaign Registry, l’opt-in est obligatoire pour presque tous les types de campagne, et les éléments d’opt-out et HELP ont leurs propres exigences. Aux États-Unis, pour le trafic soumis au champ d’application de la TCPA, les demandes de retrait du consentement doivent être traitées comme des événements opérationnels : la FCC exige qu’elles soient traitées dans un délai raisonnable ne dépassant pas dix jours ouvrables à compter de leur réception. Cette règle ne constitue pas une exigence mondiale.

• OTP ou 2FA : définissez l’événement qui génère le code, la durée de validité attendue et l’expéditeur autorisé.
• Alertes transactionnelles : décrivez l’événement de compte, commande, sécurité ou service qui déclenche le message.
• Marketing avec consentement : documentez le parcours de consentement, la fréquence, le message d’inscription, la désinscription et l’aide lorsque cela s’applique.
• Service client : délimitez l’existence éventuelle d’une conversation, l’expéditeur utilisé et le contenu autorisé.
• Trafic non pris en charge : utilisez une catégorie explicite pour les interdictions confirmées ; ne le laissez pas comme une exception implicite.
• Trafic mixte : exigez une vérification humaine lorsqu’il combine plusieurs finalités ou lorsque la classification n’est pas claire.

Contenu, liens et mécanismes de désinscription

Le contenu doit être évalué comme un texte final rendu. Les variables de personnalisation peuvent introduire des caractères, des liens ou une longueur supplémentaire qui n’existaient pas dans le modèle de base. Valider uniquement le modèle incomplet peut entraîner une classification erronée de l’encodage ou le non-respect d’une condition de route.

Documentez séparément les restrictions de contenu vérifiées pour chaque destination ou campagne : modèles requis, exemples de messages approuvés, domaines, liens, raccourcisseurs, marques et mots-clés. Si les preuves concernant une catégorie sont insuffisantes, marquez la condition comme en attente de confirmation et ne la transformez pas en interdiction ou autorisation universelle.

Une DLR avec un statut de livraison ne valide ni le contenu, ni le consentement, ni le préenregistrement, ni l’adéquation d’une campagne. Il s’agit d’un statut de livraison signalé par la chaîne de messagerie ; la conformité nécessite ses propres preuves.

• Conservez les exemples approuvés avec la version de la campagne ou de l’expéditeur.
• Enregistrez les domaines et les liens autorisés lorsque le cadre applicable l’exige.
• Ne présumez pas qu’un raccourcisseur est autorisé parce qu’un autre lien a été accepté.
• Pour les campagnes récurrentes, associez les instructions de désinscription et d’aide aux preuves du parcours d’inscription.
• Enregistrez les demandes de désinscription reçues, leur date de réception, le système responsable et la date d’exécution.
• Distinguez une DLR fournie par un fournisseur d’une réception vérifiée indépendamment sur le terminal ; elles ne sont pas équivalentes.
• Lorsque les règles américaines applicables le prévoient, enregistrez les mots-clés de révocation tels que STOP ainsi que l’automatisation associée.

Limites techniques : documenter sans promettre la livraison

Les limites techniques sont nécessaires pour décider si un message peut être traité comme prévu, mais elles ne doivent pas être formulées comme des garanties de livraison. La mise en œuvre technique du SMS est régie par des spécifications telles que 3GPP TS 23.040, qui reste soumise à un contrôle des modifications, tandis que les limites effectives d’une plateforme ou d’une route peuvent ajouter leurs propres conditions.

À titre de référence technique documentée par Twilio, un SMS GSM-7 accepte 160 caractères dans un segment et UCS-2 en accepte 70. Pour les messages concaténés, les références sont de 153 caractères GSM-7 et de 67 caractères UCS-2 par segment. Un seul caractère hors de l’ensemble GSM-7 peut faire passer l’ensemble du message en UCS-2 et modifier le nombre de segments.

Le débit d’envoi, la capacité et le temps d’attente en file nécessitent également du contexte. Une limite de TPS ou de MPS doit inclure le périmètre, la date de vérification et la condition applicable, car elle peut dépendre du compte, de l’expéditeur et du canal. Dépasser cette limite peut entraîner une mise en file d’attente. La période de validité doit également être enregistrée : une file d’attente peut expirer plus tôt si une Validity Period plus courte est définie. Sur la plateforme documentée par Twilio, les messages ne peuvent pas rester en file d’attente plus de dix heures ; ce comportement est propre à la plateforme documentée et ne constitue pas une limite générale du SMS ou des routes A2P.

• Encodage attendu : GSM-7, UCS-2 ou autre condition documentée par la plateforme.
• Longueur et segmentation calculées sur le texte final rendu.
• Politique de concaténation et traitement des messages multiparties.
• TPS ou MPS : valeur, unité, périmètre, source, date et comportement lors du dépassement du seuil.
• Période de validité : valeur demandée, limite prise en charge et conséquence de l’expiration.
• DLR : statuts disponibles, origine de l’accusé de réception et limites d’interprétation.