Revue des modifications apportées aux modèles SMS A2P : repérer les risques avant la publication

Pourquoi même une petite modification mérite une revue complète

Une modification de quelques mots peut changer le sens du message, la façon dont l’expéditeur est perçu ou les informations reçues par le destinataire. Elle peut aussi introduire une variable imprévue, modifier un lien ou changer l’encodage et la longueur du SMS. C’est pourquoi une simple comparaison visuelle des textes ne suffit pas.

Dans le trafic A2P, la traçabilité est un enjeu opérationnel important : l’analyse de Telefónica et d’Analysys Mason associe la croissance du trafic à des difficultés accrues pour retracer l’origine des SMS, ainsi qu’à des risques de sécurité et de fraude. Un registre interne des modifications aide à identifier qui a proposé, révisé et approuvé une version ; il ne prouve pas à lui seul son origine auprès de tiers et ne garantit pas la remise d’un message.

• Traitez chaque modification comme une nouvelle version, même si elle semble mineure.
• Examinez séparément le contenu et les effets techniques.
• Ne présentez pas l’approbation interne comme une garantie d’acceptation par un opérateur, un fournisseur ou un organisme de réglementation.

Que consigner dans chaque version

Créez un registre pour chaque modèle et chaque version. Incluez un identifiant stable, la date, le motif de la modification et le statut — par exemple : brouillon, en cours de révision, approuvé, retiré. Conservez la version précédemment approuvée afin de disposer d’une référence claire pour la comparaison.

Consignez l’objet du message, le public visé, les destinations et l’expéditeur configuré. Ajoutez le texte exact, les variables autorisées et leur format attendu, les liens prévus et toute condition d’utilisation. Notez également quelle équipe ou personne a proposé la modification, qui a vérifié chaque point de contrôle et qui a pris la décision finale.

Les informations sur les destinations et l’expéditeur permettent de délimiter la revue, mais les exigences applicables peuvent varier selon le pays, l’opérateur, le fournisseur et le type de trafic. Ne partez pas du principe qu’un modèle accepté dans une destination peut être utilisé sans modification dans une autre.

• Identité : identifiant du modèle, numéro de version, date et statut.
• Utilisation : objet, public, destinations et expéditeur.
• Contenu : texte exact, variables, format et liens.
• Gouvernance : auteur, réviseurs, approbateur, décision et éléments justificatifs associés.

Comparer les changements de fond, pas seulement les différences de texte

Comparez la proposition à la dernière version approuvée et conservez les deux versions. L’affichage des différences aide à repérer les ajouts et les suppressions, mais la revue doit aussi interpréter ce qui change pour le destinataire et pour les opérations.

Classez les modifications selon leurs effets : objet ou public ; expéditeur ou destination ; sens de l’offre ou de la notification ; variables ; lien ; et caractéristiques techniques. Le remplacement d’un mot peut changer une condition, tandis qu’une correction de format peut ne pas modifier le sens. L’équipe doit justifier le classement et ne pas se fier uniquement à une comparaison automatisée.

Si la modification élargit l’utilisation prévue, ajoute une destination ou change la finalité, suspendez la publication jusqu’à la vérification des autorisations internes et des exigences applicables. S’il est impossible de déterminer si la nouvelle version reste dans le périmètre approuvé, traitez-la comme une modification de fond.

• Comparez la proposition à la version autorisée, et non à un brouillon récent qui n’a pas été approuvé.
• Examinez le sens, le public et le contexte en plus des différences littérales.
• Signalez comme étant en attente toute modification dont le périmètre ou l’autorisation n’est pas clair.

Valider les variables, les liens, l’encodage et le nombre de segments

Tenez à jour une liste explicite des variables autorisées pour chaque modèle. Pour chacune, précisez son nom, si elle est obligatoire et le type ou le format de valeur attendu. Vérifiez qu’aucune variable ne manque, qu’aucun marqueur inconnu n’apparaît et que l’insertion d’une valeur d’exemple ne produit pas un texte ambigu ou inadapté. Si la longueur des valeurs peut varier considérablement, testez des cas représentatifs de la plage prévue.

Vérifiez séparément les liens : confirmez que la destination est celle attendue, que l’URL générée n’est pas tronquée et que le parcours de redirection, s’il existe, est autorisé par le processus interne. N’incluez pas de données personnelles ni de secrets dans les liens de test. La revue technique ne démontre pas qu’une destination web est sûre dans tous les contextes ni qu’un opérateur acceptera le message.

Vérifiez l’encodage effectif du texte qui sera envoyé. Les caractères disponibles et leur représentation peuvent modifier la longueur du message ; selon l’implémentation, les caractères qui ne figurent pas dans le répertoire GSM 03.38 peuvent nécessiter un encodage Unicode. Calculez le nombre de segments à l’aide du même composant ou de la même configuration que pour l’envoi, puis vérifiez le résultat dans la documentation technique du fournisseur ou de la route. Ne partez pas du principe qu’une limite universelle s’applique : la capacité et le calcul dépendent de l’encodage et de l’implémentation.

• Rejetez les variables non définies, celles qui sont vides lorsqu’elles ne sont pas autorisées ou celles dont le format est inattendu.
• Validez le message une fois composé, et pas uniquement le modèle avec ses marqueurs.
• Vérifiez l’encodage et le nombre de segments avec la configuration effective d’envoi.
• Documentez l’outil ou la méthode de calcul ; ne transposez pas les limites d’une route à une autre.

Distinguer les contrôles internes des obligations locales

Un processus interne peut exiger que l’objet soit documenté, que la liste des variables soit établie, qu’une approbation soit obtenue et que les preuves des tests soient conservées. Ces contrôles contribuent à la cohérence et à la traçabilité, mais ne remplacent pas la vérification des règles applicables au pays, à l’opérateur, au fournisseur, au secteur et au type de message.

Avant d’approuver, vérifiez que le public et le contenu sont cohérents avec la base d’autorisation applicable et les préférences de contact enregistrées. Vérifiez également la manière dont les demandes de désabonnement sont traitées, le cas échéant. Les obligations concrètes en matière de consentement, d’information, de conservation des registres et d’exclusion ne sont pas les mêmes dans toutes les juridictions ; consultez les sources officielles ou un conseiller compétent pour chaque destination.

La CRC de Colombie a présenté une proposition visant à vérifier qui envoie des messages commerciaux, à déterminer s’ils sont légitimes et à assurer leur traçabilité. La source la décrit comme une proposition, et non comme une obligation générale en vigueur. Ne transformez pas cette initiative en règle applicable à d’autres pays ni en affirmation sur l’état actuel d’une réglementation.

• Identifiez l’exigence locale vérifiée, la destination concernée et la source consultée.
• Vérifiez que le contenu correspond à l’objet et au public autorisés.
• Ne déduisez pas le consentement, l’identité ou la remise d’un message d’une validation technique.

Effectuer des tests selon des critères d’acceptation définis

Avant les tests, définissez les critères de conformité : variables complètes et au format valide, lien attendu, texte rendu conforme, encodage et nombre de segments vérifiés, expéditeur et destination dans le périmètre approuvé. Consignez le résultat ainsi que la configuration utilisée.

Utilisez des données de test contrôlées et des destinataires autorisés pour les tests, conformément aux règles locales et aux politiques du fournisseur. N’envoyez pas à de vrais utilisateurs un modèle dont l’utilisation n’a pas encore été autorisée. Un test technique vérifie des aspects précis du processus, mais ne prouve pas que l’ensemble du public a donné son consentement et ne garantit ni l’acceptation, ni la remise, ni l’affichage sur le terminal.

Si le fournisseur renvoie un statut de remise, conservez sa signification et son niveau de certitude. Un DLR reçu ne signifie pas nécessairement que la réception sur l’appareil a été vérifiée indépendamment. Consignez séparément les statuts signalés, les erreurs et toute observation disponible, sans les présenter comme une garantie.

• Définissez les critères d’acceptation avant d’exécuter les tests.
• Consignez la date, la version, la configuration, le résultat et la personne responsable.
• Distinguez les tests techniques, l’autorisation d’utilisation et les preuves de remise.

Publier, surveiller et pouvoir revenir en arrière

Ne publiez que la version approuvée et associez la configuration d’envoi à son identifiant. Si le système permet de limiter le périmètre, appliquez la modification de manière contrôlée, dans les limites des destinations et des utilisations autorisées ; n’élargissez pas le public au seul motif qu’un test a réussi.

Après la publication, surveillez les rejets, les erreurs de format, les changements de comportement signalés et les écarts entre les résultats prévus et observés. Le fait qu’un changement coïncide avec un problème ne prouve pas à lui seul que le modèle en est la cause : comparez la version, la destination, la configuration et les informations disponibles du fournisseur.

Définissez à l’avance qui peut interrompre l’envoi et comment rétablir la dernière version approuvée. En cas d’incident, consignez ce qui a été interrompu, la version active, la personne qui a décidé du retour en arrière et les éléments justifiant cette décision. Revenir en arrière réduit l’exposition à une modification connue, mais ne garantit pas l’acceptation ou la remise des messages ultérieurs.

• Associez la publication à la version approuvée.
• Définissez les responsables et les critères de suspension ou de retour en arrière avant le lancement.
• Conservez l’incident et le résultat de l’action corrective dans l’historique.

Liste de contrôle et clôture vérifiable

Clôturez chaque modification par une décision explicite : approuvée, rejetée ou en attente. Joignez suffisamment d’éléments pour reconstituer les vérifications effectuées, sans conserver plus de données personnelles que nécessaire. Assurez-vous que le modèle publié correspond à la version approuvée et que la version précédente reste consultable.

Un registre utile n’a pas besoin de promettre qu’il évitera les filtres ou les problèmes de remise. Sa valeur est plus concrète : il permet d’expliquer le périmètre de la modification, de répéter les validations, d’identifier les responsables et de répondre précisément à un incident ou à une demande de conformité.

• Existe-t-il une version approuvée de référence et une proposition identifiable ?
• L’objet, le public, l’expéditeur et les destinations ont-ils été documentés ?
• Les différences de sens et de périmètre ont-elles été examinées ?
• Les variables et les liens sont-ils autorisés et validés ?
• L’encodage et le nombre de segments ont-ils été vérifiés avec la configuration effective ?
• Les exigences applicables à chaque destination ont-elles été vérifiées ?
• Les tests reposent-ils sur des critères et des données définis, avec des destinataires autorisés ?
• Les approbateurs, les éléments justificatifs, la décision et la procédure de retour en arrière sont-ils consignés ?