Retour au blog Opérations SMS

Contrôles d’admission du trafic SMS A2P : valider chaque flux avant le routage

Un guide opérationnel pour documenter l’objectif, l’expéditeur, la destination et le profil du message, appliquer des contrôles avant l’envoi et gérer les exceptions sans confondre admissibilité et qualité de route.

Schéma de validation de l’objectif, de l’expéditeur, de la destination et du profil du contenu avant le routage du trafic SMS A2P

Pourquoi valider l’admission avant de choisir une route

Le choix d’une route et l’admission d’un flux sont deux décisions distinctes. Le premier consiste à comparer les options de connectivité pour une destination ; la seconde détermine si le trafic présenté correspond aux conditions documentées pour ce service. Il est recommandé de vérifier d’abord l’admissibilité, puis d’évaluer quelles routes disponibles sont appropriées.

Ces contrôles contribuent à éviter qu’un changement d’expéditeur, d’objectif ou de contenu passe inaperçu. Ils ne certifient pas qu’un message sera remis et ne remplacent pas les obligations légales ou contractuelles, ni les politiques de l’opérateur applicables à la destination.

  • Définissez l’unité de contrôle : client, application, expéditeur, campagne ou flux identifié de manière stable.
  • Distinguez le résultat de l’admission — accepter, rejeter ou soumettre à examen — des indicateurs de qualité de route.
  • Consignez les conditions convenues et les personnes habilitées à les modifier.
Pourquoi valider l’admission avant de choisir une route

Quelles conditions doivent être explicites

Avant d’automatiser les contrôles, traduisez l’accord opérationnel en champs concrets. À minima, documentez l’objectif déclaré, les expéditeurs autorisés, les destinations incluses et le profil de contenu attendu. Ajoutez les conditions qui font réellement partie de l’accord ou des règles applicables ; ne supposez pas qu’une liste générique couvre tous les pays et opérateurs.

Le profil de contenu peut décrire le type de message — par exemple OTP, transactionnel ou marketing —, la structure attendue, le type de variables et la présence de liens. En présence d’URL, indiquez celles qui sont autorisées et la manière dont les liens doivent être déclarés, y compris les liens raccourcis, le cas échéant. Il s’agit d’un critère opérationnel utile, mais il ne doit pas être présenté comme une obligation universelle : la CRC colombienne a décrit des exigences concernant les modèles et les liens dans le cadre de propositions réglementaires spécifiques.

  • Objectif : l’usage déclaré et les usages exclus du périmètre convenu.
  • Expéditeur : valeur ou ensemble autorisé, format attendu et statut d’autorisation lorsque ces informations sont disponibles.
  • Destination : pays, réseaux ou autres périmètres expressément inclus, ainsi que les restrictions connues.
  • Contenu : type de message, structure, variables prévues et présence d’URL ou d’autres éléments soumis à des conditions.
  • Validité : version des conditions, date de révision et responsable de leur approbation.
Quelles conditions doivent être explicites

Comment traduire les conditions documentées en règles vérifiables

Chaque condition doit être transformée en un test observable assorti d’un résultat défini. Par exemple, si l’expéditeur doit appartenir à une liste autorisée, comparez la valeur reçue à cette liste ; si la destination n’est pas couverte par l’accord, bloquez l’envoi ou soumettez-le à examen au lieu de présumer qu’il est autorisé.

Ne transformez pas une description ambiguë en règle permissive. Si l’accord mentionne uniquement des « messages de service » sans préciser les finalités ou les expéditeurs, demandez des précisions avant d’élargir l’admission. Les règles peuvent être exécutées dans votre propre système ou au point d’intégration disponible ; ne supposez pas qu’une plateforme externe applique automatiquement ces validations.

  • Formulez chaque règle sous la forme d’une condition, d’une source de données et d’un résultat en cas de correspondance ou d’absence de correspondance.
  • Utilisez des listes ou des catalogues avec gestion des versions pour les expéditeurs, les destinations et les profils lorsque l’accord l’exige.
  • Définissez les champs obligatoires et le comportement à adopter en cas de champ manquant.
  • Testez les cas autorisés, non autorisés et ambigus avant d’activer le contrôle.

Validations lors de l’ajout d’un client, d’un expéditeur ou d’un flux

Lors de l’enregistrement d’un flux, demandez une fiche cohérente avec l’accord commercial et les règles de la destination. Vérifiez que l’objectif décrit correspond au profil de contenu et que chaque expéditeur et chaque destination entrent dans le périmètre consigné. Pour les changements ultérieurs, comparez la nouvelle configuration à la version approuvée ; ne traitez pas un changement important comme une simple mise à jour technique.

Pour les modèles, une proposition réglementaire de la CRC en Colombie décrit l’association des messages A2P à des modèles approuvés et en vigueur, dans le respect de la structure, de la finalité et du type de message déclarés, y compris lorsque des champs variables sont utilisés. Ce document n’établit pas, à lui seul, une obligation applicable dans tous les pays ou sur toutes les routes. Il précise également que la validation décrite porte sur le contenu statique et le sens des champs dynamiques, et pas nécessairement sur le texte final de chaque message ni sur la valeur concrète de données comme un OTP.

  • Vérifiez que la description de l’usage et le profil demandé ne se contredisent pas.
  • Vérifiez l’autorisation de l’expéditeur selon le mécanisme documenté pour cette destination ; ne supposez pas qu’il existe un registre universel.
  • Assurez-vous que la destination est couverte par l’accord et que les restrictions connues sont prises en compte.
  • Conservez la version approuvée du profil, la date et l’identité ou la fonction de la personne ayant autorisé l’enregistrement.

Que faire en cas de données manquantes, incompatibles ou ambiguës

L’absence de données ne vaut pas autorisation. Définissez une politique pour chaque champ : rejeter, mettre en attente ou demander des précisions. Pour les attributs qui déterminent l’admissibilité — par exemple l’objectif, l’expéditeur ou la destination —, un examen est plus sûr que de compléter l’information par supposition.

Si deux sources sont en désaccord, définissez laquelle constitue la référence opérationnelle en vigueur et qui peut résoudre le conflit. Maintenez le trafic en examen jusqu’à ce que le désaccord soit réglé s’il affecte le périmètre convenu. Évitez de « corriger » le trafic en modifiant les expéditeurs, le contenu ou les routes afin de contourner des filtres ou des restrictions.

  • Champ obligatoire manquant : ne pas router avant de l’avoir obtenu ou d’avoir appliqué la procédure d’examen approuvée.
  • Donnée incompatible avec l’accord : rejeter ou suspendre le flux concerné et communiquer la raison précise.
  • Informations contradictoires : consigner les sources et transmettre le dossier à la personne responsable.
  • Doute concernant les règles de la destination : confirmer l’exigence auprès de la partie compétente avant d’élargir le périmètre.

Gestion des exceptions : responsable, périmètre et éléments justificatifs

Une exception doit être explicite, limitée et susceptible d’être réexaminée. Consignez qui la demande, qui l’approuve, le client et le flux concernés, la condition modifiée et sa durée de validité. Si aucune date d’expiration n’est définie, fixez une date de révision et évitez qu’une exception temporaire ne devienne silencieusement la règle générale.

Les éléments justificatifs doivent permettre de reconstituer la décision sans conserver inutilement le contenu des messages. Conservez la référence à l’accord, la version de la configuration et la justification ; limitez l’accès conformément aux politiques de confidentialité et de sécurité applicables. Les exigences précises de conservation dépendent du contexte juridique et contractuel.

  • Désignez un responsable de l’approbation distinct de l’exécution automatisée lorsque le processus le permet.
  • Limitez l’exception à l’expéditeur, à la destination, à l’objectif et au profil concernés.
  • Définissez une date d’expiration, une date de révision et les conditions de révocation.
  • Consignez les éléments justificatifs strictement nécessaires et les personnes autorisées à les consulter.

Comment examiner les changements sans interrompre les usages légitimes

Tout changement ne constitue pas une infraction, mais tout changement qui modifie les conditions acceptées mérite une évaluation proportionnée. Comparez la nouvelle version à la précédente et déterminez si l’objectif, l’expéditeur, la destination, la structure du contenu ou l’utilisation des liens ont changé. Si le changement n’est pas couvert, demandez des précisions et une approbation avant d’élargir l’admission.

Pour limiter les interruptions, communiquez à l’avance les informations requises et les flux concernés. Si la politique opérationnelle le permet, maintenez les flux déjà approuvés sans modification et isolez uniquement le nouvel expéditeur ou le nouveau profil en attente. Ne promettez pas la continuité lorsque les règles de la destination ou de l’opérateur imposent une autre réponse.

  • Comparez les versions et classez le changement comme technique, éditorial ou important pour l’admissibilité.
  • Demandez un nouvel examen si l’objectif, l’expéditeur, les destinations ou le profil convenu changent.
  • Définissez le traitement du trafic existant pendant l’examen, conformément au contrat et aux règles applicables.
  • Consignez la décision et ne mettez à jour les règles qu’après approbation.

Journal des décisions pour l’audit opérationnel

Un journal utile doit expliquer ce qui a été évalué, par rapport à quelle version des conditions et avec quel résultat. Distinguez les événements d’acceptation et de rejet des indicateurs de qualité : une admission correcte ne prouve pas la remise du message, et une remise signalée ne prouve pas que le trafic était autorisé.

Si des DLR sont utilisés, distinguez le statut signalé par la chaîne de messagerie d’une réception vérifiée sur l’appareil. L’admission et les indicateurs de remise, de latence ou de disponibilité répondent à des questions différentes et peuvent comporter leurs propres incertitudes.

  • Incluez l’identifiant du flux, la date et l’heure, la destination, la version des règles et le résultat.
  • Consignez le motif normalisé du rejet ou de l’examen, ainsi que l’action entreprise.
  • Reliez les exceptions et les approbations au moyen d’une référence, sans dupliquer les données sensibles.
  • Examinez régulièrement les rejets répétés, les changements fréquents et les règles qui génèrent de l’ambiguïté.
FAQ

Questions fréquentes

Ces contrôles sont-ils des exigences universelles pour toutes les routes A2P ?

Non. Il s’agit d’une pratique opérationnelle qui permet de traduire les accords et les règles applicables en vérifications. Les obligations dépendent du pays, de l’opérateur, du contrat et du type de trafic. Les références à la CRC citées décrivent des propositions spécifiques à la Colombie et ne prouvent pas, à elles seules, l’existence d’une règle universelle ou en vigueur sur toutes les routes.

La validation d’un expéditeur prouve-t-elle que le destinataire a donné son consentement ?

Non. L’autorisation d’un expéditeur ou son inscription dans un registre ne prouve pas, à elle seule, le consentement du destinataire, l’identité de l’expéditeur ni la légalité de chaque message. Ces questions nécessitent des contrôles et des justificatifs adaptés au cas concerné et à la juridiction.

Un flux accepté garantit-il que le SMS arrivera sur le téléphone ?

Non. L’acceptation indique que le trafic a passé les contrôles définis pour son admission. Elle ne garantit ni le routage, ni la remise sur l’appareil, ni qu’un DLR équivaut à une réception vérifiée.

Faut-il vérifier chaque valeur dynamique d’un OTP avant l’envoi ?

Il n’est pas possible de déduire une exigence universelle de la documentation disponible. Dans sa réponse concernant la proposition décrite, la CRC distingue la validation de la structure et du sens des champs dynamiques de l’examen de la valeur concrète d’un OTP. Appliquez les exigences de l’accord, les règles applicables et la conception retenue en matière de confidentialité.

Que faut-il faire si l’objectif ou la destination manque ?

Définissez à l’avance une procédure de sécurité : bloquer, soumettre à examen ou demander l’information. Ne présumez pas qu’une autorisation existe à partir de renseignements incomplets et ne choisissez pas une route pour contourner une restriction.

Sources consultées

  1. Documento de soporte: Identificación de medidas para mitigar el fraude cibernético por medio de servicios móvilesComisión de Regulación de Comunicaciones (CRC), Colombia
  2. Documento de respuesta a comentarios sobre medidas contra fraude en servicios móvilesComisión de Regulación de Comunicaciones (CRC), Colombia