Validation des modèles SMS A2P : contrôle avant publication
Un guide opérationnel pour examiner les modifications apportées aux modèles SMS, vérifier leurs effets techniques et assurer leur traçabilité avant l’envoi.
Une petite modification peut changer le comportement technique
Modifier un modèle peut avoir des effets sur le jeu de caractères, la longueur du message et, selon le codage et les règles applicables, le nombre de segments. Un changement apparemment rédactionnel — par exemple, l’ajout d’un symbole ou la modification d’une variable — mérite une nouvelle vérification technique, et pas seulement une validation stylistique.
Ne partez pas du principe que toutes les plateformes gèrent le codage, la concaténation ou les variables de la même manière. Vérifiez le comportement indiqué dans la documentation de la plateforme et du connecteur utilisés. Les règles applicables dépendent du codage effectif et de l’implémentation.
- Traitez chaque modification comme un changement à évaluer.
- Consignez le résultat renvoyé par le système de validation ou la plateforme, sans le généraliser à d’autres environnements.
- Ne remplacez pas une vérification technique par un simple comptage générique des caractères.
Créez un registre permettant d’identifier chaque modèle
Tenez un registre centralisé comprenant un identifiant unique et suffisamment d’informations pour comprendre l’usage prévu de chaque modèle. La structure exacte dépend de vos processus, mais elle doit permettre de distinguer le contenu approuvé des autres variantes et de désigner les responsabilités.
À titre de minimum opérationnel, pensez à consigner l’objectif, la langue, l’expéditeur prévu, l’équipe responsable, la version et le statut d’approbation. Si une plateforme exige des champs supplémentaires, documentez également ces exigences.
- Attribuez un identifiant stable qui ne dépende pas du texte affiché.
- Distinguez l’objectif du modèle de son contenu précis.
- Indiquez qui gère le modèle et qui peut en autoriser la publication.
- Conservez le texte exact associé à chaque version approuvée.
Validez le contenu, les caractères, les variables et la longueur
Avant d’approuver une modification, vérifiez le texte selon les règles techniques de la plateforme et du parcours d’envoi prévus. La vérification doit préciser si les caractères utilisés sont acceptés, quel codage s’applique et comment sont calculés la longueur et les segments. Il est imprudent de déduire ces résultats du seul aspect visuel du message.
Traitez les variables comme des éléments ayant leurs propres règles : format attendu, possibilité d’être vide, longueur maximale prévue et caractères qu’elles peuvent contenir. Si ces contraintes ne sont pas définies, la validation est incomplète. Les informations disponibles ne permettent pas d’établir une règle universelle applicable à tous les systèmes pour le traitement des variables ou la concaténation des messages.
- Vérifiez le texte final traité par l’intégration, et pas seulement le modèle contenant des marqueurs.
- Repérez les caractères susceptibles de modifier le codage selon les règles documentées de votre système.
- Vérifiez les limites de longueur et de nombre de segments avec l’outil ou la documentation appropriés.
- Consignez le codage et le résultat de validation observés.
Testez des substitutions représentatives avant la publication
Un modèle peut sembler valide alors que ses valeurs réelles ne le sont pas. Testez des substitutions correspondant à des données légitimes de l’environnement : une valeur courante, une valeur proche de la limite autorisée et les cas particuliers prévus par le contrat de la variable. Vérifiez également le comportement lorsqu’un champ facultatif est vide, si cela peut se produire.
N’introduisez pas de valeurs de test arbitraires en production. Utilisez des données synthétiques ou de test autorisées et évitez d’inclure des informations personnelles inutiles. L’objectif est de vérifier le texte obtenu et son traitement technique, pas d’élargir la portée du message.
- Testez des valeurs courtes et longues dans les limites définies.
- Ne testez les caractères spéciaux que s’ils sont autorisés dans le champ.
- Vérifiez que la substitution ne laisse aucun marqueur non résolu et ne génère pas de contenu ambigu.
- Conservez les résultats des tests sans exposer de données sensibles.
Distinguez les validations éditoriale, technique et de publication
Une relecture du contenu ne remplace pas une vérification technique, et une validation technique ne suffit pas à déterminer si le message est autorisé à l’envoi. Prévoyez des points de contrôle distincts : examen de l’objectif et du texte, validation des caractères et du comportement, puis autorisation de publication conformément aux règles internes et applicables.
Pour les communications marketing, vérifiez également que l’usage et le public visé respectent les exigences de consentement et les règles pertinentes. Les tests techniques ne prouvent ni l’existence du consentement ni la légitimité de l’envoi.
- Définissez les personnes chargées de relire le contenu et celles qui vérifient les aspects techniques.
- Exigez une approbation avant de rendre une version disponible pour les envois.
- Consignez la décision, la personne responsable et la date, conformément à la politique de conservation de l’organisation.
- Ne confondez pas la réussite d’un test avec l’autorisation d’envoyer.
Gérez les versions et associez les envois au modèle utilisé
Chaque modification approuvée devrait donner lieu à une version identifiable. Cela évite qu’une modification ultérieure remplace silencieusement le contenu validé. Établissez un lien entre la version publiée et l’envoi ou le processus qui l’a utilisée, dans la mesure permise par la plateforme et vos systèmes.
Définissez à l’avance comment conserver ce lien : par exemple, en enregistrant l’identifiant et la version dans les systèmes de gestion. Ne supposez pas qu’une API ou un connecteur propose cette fonction ; vérifiez les champs et les journaux mis à disposition par l’intégration concernée.
- Ne remplacez pas une version approuvée sans conserver son historique.
- Consignez le statut de chaque version — brouillon, en cours de révision, approuvée, publiée ou retirée — si ces statuts correspondent à votre processus.
- Associez les résultats de validation et les approbations à la version exacte.
- Vérifiez que les registres disponibles permettent d’identifier la version utilisée.
Effectuez des tests de régression avant le déploiement
Avant de publier une modification, comparez son résultat à celui de la version précédente et répétez les vérifications concernées. Les tests de régression doivent porter sur le contenu visible, les variables, le codage, la longueur et les segments, ainsi que sur la compatibilité avec l’intégration chargée de l’envoi.
L’étendue des tests dépend de la modification. Une retouche qui ne concerne pas une variable peut nécessiter des vérifications différentes d’un changement portant sur son format ou sa longueur. Documentez les critères définissant le périmètre des tests afin que l’équipe puisse justifier les éléments revérifiés.
- Comparez le texte exact et la liste des modifications.
- Répétez les tests de substitution pertinents.
- Confirmez que le système d’envoi accepte la version et les champs prévus.
- Validez de nouveau les aspects dont le résultat peut être affecté par la modification.
Consignez les échecs et retirez les versions en assurant leur traçabilité
En cas d’échec de validation, consignez la version examinée, l’environnement de test, le résultat observé et la cause connue. Distinguez une erreur reproductible d’une cause qui n’est pas encore confirmée ; en l’absence de preuves suffisantes, n’attribuez pas l’échec au codage, à l’opérateur ou au transport.
Si vous devez retirer un modèle, marquez la version comme indisponible pour les nouveaux envois, selon les fonctionnalités de votre système. Conservez l’historique et les preuves d’approbation ou de retrait conformément aux politiques internes et aux obligations applicables. Ne supprimez pas les registres nécessaires pour reconstituer les événements.
- Indiquez la date, la personne responsable, l’identifiant du modèle et sa version.
- Joignez le résultat technique disponible et les étapes permettant de reproduire l’échec.
- Précisez si la cause est confirmée ou si elle reste à examiner.
- Vérifiez ce que signifie le retrait d’une version sur la plateforme concernée et quels registres sont conservés.
Questions fréquentes
Un simple comptage des caractères du modèle suffit-il ?
Pas nécessairement. Le résultat peut dépendre des caractères, du codage et des règles de la plateforme concernant la longueur et la concaténation. Validez le texte final et consultez la documentation du système d’envoi.
Chaque modification du texte nécessite-t-elle une nouvelle version ?
Pour assurer le contrôle, il est recommandé d’identifier chaque modification approuvée par une nouvelle version ou par un historique équivalent. Vous pouvez ainsi conserver la trace du contenu validé et de la version publiée.
Quelles valeurs de variables faut-il tester ?
Testez des valeurs représentatives dans les limites définies, notamment des valeurs proches du maximum et les caractères spéciaux acceptés par le champ. Si les limites ne sont pas documentées, clarifiez-les avant d’approuver le modèle.
Un test technique prouve-t-il que l’envoi est autorisé ?
Non. Le test porte sur les aspects techniques du modèle et de l’intégration. L’autorisation du contenu et, le cas échéant, le consentement et la conformité réglementaire nécessitent des contrôles distincts.
Sources consultées
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMPP v3.4 specificationSMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- Comprender los segmentos de mensajes para SMSHubSpot Knowledge Base
- Configuración y protocolo del conector SMSAdobe Experience League