Retour au blog Qualité et confiance

Comment créer une matrice de tests A2P SMS par destination, opérateur, expéditeur et type de message

Un guide opérationnel pour concevoir des tests A2P SMS reproductibles, consigner les preuves techniques et comparer les routes sans confondre DLR et réception observée sur le terminal.

Equipo editorial de BulkSMSMarket06 septembre 2026Contrôle éditorial 94/100

Matrice opérationnelle de tests A2P SMS avec destinations, réseaux, expéditeurs et résultats de livraison

Pourquoi un test isolé ne valide pas une route SMS

Un SMS envoyé à un seul numéro, sur un seul réseau et dans un seul créneau horaire ne décrit que ce cas précis. Il ne démontre pas que la même route conservera un comportement comparable pour d’autres pays, réseaux d’abonnement, types d’expéditeur, encodages, longueurs ou contenus légitimes.

Une matrice de tests A2P SMS transforme une vérification ponctuelle en programme d’évaluation reproductible. Son objectif n’est pas de promettre la livraison ni de remplacer le suivi en production : elle vise à produire des preuves comparables afin de déterminer quelles routes méritent une surveillance accrue, quels scénarios nécessitent une investigation et dans quelles conditions une route peut être évaluée avant de recevoir davantage de trafic.

La discipline principale consiste à ne pas extrapoler au-delà de l’échantillon. Un résultat favorable dans une destination ne valide pas un pays entier ; un résultat favorable sur un réseau ne valide pas nécessairement un autre réseau ; et un DLR favorable ne prouve pas à lui seul qu’une personne a vu le message dans l’interface de son téléphone.

Traitez chaque combinaison de variables comme une cellule de test indépendante.
Conservez une version identifiable de la matrice et de chaque cas exécuté.
Ne comparez que des cellules équivalentes ou documentez précisément la variable qui a changé.
Distinguez les faits observés des déclarations contractuelles, techniques ou commerciales de tiers.

Pourquoi un test isolé ne valide pas une route SMS

Ce que la matrice doit permettre de répondre avant d’acheminer du trafic en production

Avant d’augmenter le trafic, la matrice doit répondre à des questions opérationnelles précises. Quelles combinaisons de destination, réseau, expéditeur et contenu ont été testées ? Quels résultats ont été observés ? Combien d’observations comparables existent ? Quels statuts ont été reçus, dans quel ordre et avec quel délai ? Des écarts ont-ils été constatés entre l’acceptation initiale, les callbacks ou DLR et la réception observée sur un terminal de test ?

Toutes les décisions ne requièrent pas le même niveau de preuve. Une route en phase d’exploration peut nécessiter des tests contrôlés et une revue manuelle. Une route destinée à recevoir du trafic sensible, tel que des OTP ou des notifications transactionnelles, exige une couverture de cas plus proche de son utilisation réelle, avec des limites internes de risque définies par l’équipe responsable.

La matrice doit également rendre visibles les zones non testées. L’absence de résultat ne doit pas devenir une inférence positive. Marquez les cellules sans échantillon comme non évaluées, et non comme correctes.

Couverture : quelles destinations, quels réseaux et quels scénarios sont réellement représentés.
Reproductibilité : si le même cas peut être exécuté et comparé à nouveau.
Preuves : ce qui s’est produit sur la plateforme, ce que le fournisseur a indiqué et ce qui a été observé indépendamment.
Incertitude : ce qui ne peut pas être conclu en raison de la taille de l’échantillon, de l’absence de terminal de test ou de la variation des conditions.
Décision : augmenter, maintenir sous observation, suspendre ou investiguer.

Ce que la matrice doit permettre de répondre avant d’acheminer du trafic en production

Dimensions fondamentales d’une matrice de tests A2P SMS

La conception commence par la définition des dimensions susceptibles de modifier le résultat. Normalisez le numéro de destination au format international et conservez le pays comme champ explicite. La Recommandation UIT-T E.164 constitue la référence appropriée pour représenter la dimension internationale de la numérotation.

Ne déduisez pas l’opérateur actuel à partir du seul préfixe numérique. La portabilité mobile permet de conserver le MSISDN lors d’un changement de réseau d’abonnement. Il est donc utile de distinguer l’opérateur inféré à partir du préfixe, lorsqu’il existe, de l’opérateur ou réseau d’abonnement observé ou confirmé au moyen d’une procédure autorisée.

Consignez l’expéditeur exactement tel qu’il a été soumis. Le type d’expéditeur peut être alphanumérique, numérique ou relever d’un autre format autorisé par le contexte technique et réglementaire applicable. Ne supposez pas que le comportement d’un expéditeur sera identique à celui d’un autre, même pour une même destination.

Pays et destination au format international.
Réseau mobile ou réseau d’abonnement, avec la source de l’attribution.
Type de numérotation et statut connu de portabilité, le cas échéant.
Route, connexion ou configuration en cours d’évaluation.
Expéditeur soumis et son format.
Type de message : OTP, transactionnel ou marketing autorisé.
Encodage, alphabet, longueur et concaténation.
Créneau horaire et date d’exécution.

Distinguez OTP, messages transactionnels et marketing autorisé

Les OTP, les messages transactionnels et le marketing autorisé ne doivent pas être regroupés dans une même conclusion opérationnelle. Bien qu’ils utilisent tous les SMS, ils répondent généralement à des attentes différentes en matière de contenu, de rapidité et de traçabilité. Un test doit représenter le cas d’usage légitime à évaluer, sans réutiliser indistinctement le même texte pour tous les scénarios.

Pour les OTP, utilisez des textes de test sans ambiguïté, sans données personnelles ni codes donnant un accès réel. Consignez l’instant d’envoi et l’observation sur le terminal lorsque vous disposez d’un appareil de test contrôlé. Pour les messages transactionnels, utilisez une notification fictive et clairement identifiée comme un test. Pour le marketing, limitez les essais aux numéros autorisés et à un contenu conforme aux obligations applicables.

Cette distinction réduit les interprétations erronées. Le résultat technique d’un court message de test ne démontre pas nécessairement le comportement d’un message concaténé, contenant des caractères non GSM ou utilisant un expéditeur différent.

OTP : texte de test court, sans identifiants ni accès réel.
Transactionnel : événement fictif, identifiable et sans information sensible.
Marketing autorisé : uniquement des destinataires de test autorisés et un contenu conforme.
Ne regroupez pas les résultats entre catégories sans indiquer que le cas d’usage a changé.

Sélectionnez les numéros de test de manière responsable

Maintenez un inventaire contrôlé de numéros de test disposant d’une autorisation documentée pour recevoir des messages. Chaque numéro doit avoir un identifiant interne, un pays, un format international, une source d’attribution réseau et, lorsque cela est possible, des informations sur la possibilité d’observer la réception sur un terminal contrôlé.

N’exposez pas les numéros complets dans des rapports largement diffusés lorsque cela n’est pas nécessaire. Utilisez un identifiant interne ou une version masquée dans les tableaux de bord, et réservez les données opérationnelles complètes aux contrôles d’accès appropriés.

Examinez régulièrement l’inventaire. Un numéro peut changer de statut, d’appareil ou de réseau d’abonnement. Si un résultat dépend d’une condition qui ne peut plus être vérifiée, marquez cette cellule comme nécessitant une mise à jour.

Identifiant interne du numéro de test.
Destination normalisée et pays.
Réseau attribué et méthode ou date d’attribution.
Statut d’autorisation pour les tests.
Disponibilité d’un terminal contrôlé pour une observation indépendante.
Date de dernière validation de l’inventaire.

Concevez des cas qui modifient une variable à la fois

Un cas de base permet de détecter les différences sans confondre les causes. Définissez un message de test légitime, identifiable et dépourvu d’informations sensibles. Créez ensuite des variations contrôlées : modifiez l’encodage, la longueur, l’expéditeur ou un élément du contenu, tout en maintenant les autres variables constantes.

L’encodage doit être une dimension explicite. La spécification 3GPP TS 23.038 prévoit notamment l’alphabet GSM sur 7 bits, les données sur 8 bits et l’UCS2 sur 16 bits. Elle établit également qu’avec l’alphabet GSM sur 7 bits, un message peut contenir jusqu’à 160 caractères. La longueur, les caractères utilisés et la concaténation peuvent modifier le traitement technique du message.

Incluez des cas à une seule partie et des cas concaténés lorsqu’ils sont pertinents pour le trafic prévu. Consignez la configuration demandée et le résultat observé ; ne déduisez pas l’encodage final à partir du texte visible sur le téléphone.

Cas de base : texte court, identifiable et sans caractères ambigus.
Variation d’encodage : testez le jeu de caractères pertinent pour votre trafic.
Variation de longueur : une partie et, le cas échéant, un message concaténé.
Variation d’expéditeur : évaluez chaque expéditeur qui sera utilisé.
Variation de contenu : ne modifiez que l’élément que vous souhaitez étudier.
Créneau horaire : répétez les tests sur des plages définies sans modifier les autres conditions.

Ce qu’il faut mesurer pour chaque envoi

L’enregistrement de chaque envoi doit permettre de reconstituer la séquence complète. Conservez l’instant de soumission, le résultat d’acceptation, les identifiants de corrélation renvoyés par l’interface, tous les événements de callback ou DLR et toute observation indépendante sur le terminal.

Les identifiants sont essentiels. La spécification 3GPP TS 23.040 définit des éléments tels que TP-Message-Reference et SMS-STATUS-REPORT, ainsi que les horodatages et statuts associés. Dans une intégration HTTP ou SMPP, l’identifiant exposé par chaque système peut être différent ; documentez la manière dont un identifiant client est corrélé avec l’identifiant du fournisseur, le callback et l’observation de test.

Consignez les statuts temporaires et les échecs, et pas uniquement un résultat final simplifié. Le flux SMS peut inclure une indisponibilité temporaire, des tentatives répétées ou des résultats ultérieurs. La suppression de ces événements intermédiaires empêche de comprendre si une différence est liée à l’acceptation, à la livraison, à la notification ou au délai de rapport.

Identifiant interne d’exécution et version du cas.
Horodatage de soumission et résultat d’acceptation.
Identifiants de corrélation disponibles.
Route ou configuration évaluée.
Destination et expéditeur tels qu’ils ont été soumis.
Encodage, longueur et nombre de parties attendues.
Événements DLR ou callback : statut brut, heure de réception et charge utile conservée.
Observation sur le terminal : oui, non ou non disponible ; heure et méthode d’observation.

Un DLR indiquant une livraison n’équivaut pas à une réception observée sur le terminal

Un DLR constitue une preuve technique précieuse, mais doit être interprété à son niveau exact. La norme TS 23.040 distingue SMS-SUBMIT, SMS-DELIVER, SMS-DELIVER-REPORT et SMS-STATUS-REPORT. Ces mécanismes décrivent des événements, des accusés et des résultats de transfert ; ils ne définissent pas un événement de lecture par la personne destinataire.

Classez les preuves afin d’éviter les affirmations excessives. L’acceptation confirme qu’une interface a accepté l’envoi selon ses conditions. Un callback ou un DLR confirme qu’un rapport contenant un statut et une heure a été reçu. L’observation indépendante sur un terminal contrôlé confirme que le message a été vu sur cet appareil et à ce moment-là, si la corrélation avec l’envoi est solide. Aucun niveau ne prouve à lui seul le consentement, l’identité, la propriété du numéro ou la lecture par un utilisateur final.

Lorsqu’aucune observation sur terminal n’est disponible, présentez le résultat comme un statut rapporté, et non comme une réception vérifiée. Lorsqu’elle est disponible, conservez la méthode de vérification et l’identifiant reliant l’observation à l’envoi précis.

Niveau 1 : acceptation de l’envoi par l’interface.
Niveau 2 : DLR ou callback reçu et conservé.
Niveau 3 : réception observée sur un terminal de test contrôlé.
N’assimilez pas la réception observée à une lecture humaine, au consentement ou à l’identité.
Ne présentez pas un DLR comme une garantie universelle de livraison.

FAQ

Questions fréquentes

Combien d’envois une matrice de tests A2P SMS nécessite-t-elle ?

Il n’existe pas de nombre universel permettant de rendre un échantillon concluant. Définissez-le selon le risque opérationnel, les destinations, les réseaux, le type de message et la variabilité que vous devez observer. L’essentiel est de conserver la taille de l’échantillon par cellule et de ne pas comparer comme équivalentes des cellules présentant une couverture ou des conditions différentes.

Un DLR indiquant « livré » prouve-t-il que le SMS est arrivé sur le téléphone ?

Non, pas à lui seul. Un DLR est un rapport technique de statut et doit être conservé comme preuve à ce niveau. La réception observée sur un terminal de test contrôlé constitue une preuve distincte. Ni l’un ni l’autre ne prouve à lui seul qu’une personne a lu le message.

Faut-il inclure une requête HLR dans la matrice ?

Elle peut être enregistrée comme source de contexte lorsque son utilisation est autorisée, mais ne doit pas être considérée comme une preuve de consentement, d’identité, de propriété du numéro, de route réelle ou de livraison. La portabilité mobile peut dissocier le préfixe numérique du réseau d’abonnement actuel.

Pourquoi tester les caractères et les messages longs ?

Parce que l’encodage et l’alphabet sont des variables techniques explicites. La norme TS 23.038 prévoit le GSM sur 7 bits, les données sur 8 bits et l’UCS2 sur 16 bits, et la longueur peut nécessiter une concaténation. Un résultat obtenu avec un texte court ne valide pas automatiquement un autre contenu ou une longueur différente.