# Comment fonctionne un test de route SMS

Un test de route envoie un contenu réel par une route nommée vers des téléphones nommés d’un marché nommé, à une date donnée, puis note ce qui est arrivé et quand. Il prouve cette route sur ces téléphones à ce moment. Il ne prouve pas tous les téléphones, tous les réseaux ni la semaine prochaine.

- Un test de route prouve une route nommée sur des téléphones nommés d’un marché, à un moment donné.

- Un test ne prouve pas tous les téléphones, tous les réseaux ni la performance future.

- Un rapport utile porte le contenu, les téléphones, la route, les états d’accusé et la date.

- Un échec désigne la route, l’expéditeur ou le téléphone à ce moment.

## Ce qu’un test prouve

Un test de route répond à une question étroite : si nous envoyons ce contenu depuis cet expéditeur par cette route vers ces téléphones dans ce marché aujourd’hui, qu’est-ce qui arrive et en combien de temps ? La réponse vaut pour cette combinaison. Ce n’est pas une affirmation de couverture ni une prévision. Un autre téléphone, un autre marché ou un changement de route peuvent donner un résultat différent.
Cette étroitesse fait la valeur. Un test qui nomme ses téléphones, son contenu et sa date peut être répété et comparé. Un test qui ne donne qu’un pourcentage de remise, non. Demandez l’enregistrement brut : la chaîne d’expéditeur affichée sur le téléphone, l’état de l’accusé, le délai entre l’envoi et l’accusé et la route de réponse si le flux en a besoin.
Écrivez la question avant le test. Une question comme cette route remet-elle un OTP de cet expéditeur à un téléphone courant de ce marché en moins de dix secondes produit un résultat utilisable. La question de savoir si la route est bonne produit une opinion.

### Ce que le test de route enregistre

| Contrôle | Ce que le test enregistre | Ce que cela ne prouve pas |
| --- | --- | --- |
| Remise | Téléphone, marché, expéditeur, contenu et état de l’accusé | Que tous les téléphones du marché affichent le message |
| Délai | Envoi à l’accusé, médiane et 95e centile | La latence de tous les réseaux ou de toutes les heures |
| Expéditeur | La chaîne affichée sur le téléphone | Que la chaîne survive à un changement de route |
| Réponse | Route de réponse, délai et contenu | Que toutes les routes entrantes fonctionnent |
| Contenu | Modèle exact, codage et nombre de segments | Que tous les filtres l’acceptent |
| Répétition | La date et les conditions | Ce que la route fera le mois prochain |

Un téléphone par modèle est un échantillon, pas un recensement.

## Comment le test est exécuté

Mettez d’abord la question au clair. S’agit-il d’une nouvelle route, d’un nouvel expéditeur, d’un nouveau marché ou d’un changement sur une route existante ? La question décide des téléphones, du contenu et du nombre d’envois. Choisissez ensuite des téléphones représentatifs du marché : plus d’un modèle, plus d’un réseau quand la route en traverse plusieurs, et au moins un téléphone sur le réseau qui portera l’essentiel du trafic.
Figez le contenu. Utilisez le modèle que vous allez envoyer, avec les liens, les variables et les caractères qui décident GSM-7 ou UCS-2. Envoyez le même contenu à tous les téléphones, notez l’heure d’envoi, l’heure de l’accusé et l’état, et conservez les données brutes. Si le flux a besoin de réponses, envoyez une réponse depuis chaque téléphone et notez le délai d’arrivée. Lancez le test à l’heure où vous attendez du trafic, pas seulement dans une fenêtre calme.

### La séquence du test

1. **Mettre la question au clair**

Nommez la route, l’expéditeur et le marché. Écrivez à quoi ressemblerait un résultat réussi.

2. **Choisir les téléphones**

Prenez plus d’un modèle et, si cela compte, plus d’un réseau. Notez le modèle et le réseau.

3. **Figer le contenu**

Utilisez le modèle exact que vous enverrez. Notez le codage et le nombre de segments.

4. **Envoyer et noter**

Capturez l’heure d’envoi, le message ID et la route. Ne changez pas le contenu entre les envois.

5. **Lire l’accusé**

Capturez l’état, le code d’erreur et l’heure de fin. Remis n’est pas un contrôle d’affichage.

6. **Répéter sur une seconde route**

Exécutez le même contenu sur une seconde route si vous devez comparer. Changez une variable à la fois.

7. **Écrire les limites**

Dites ce que le test n’a pas couvert : téléphones, marchés, heures, contenu et dates.

### Ce que contient un rapport d’échantillon

| Partie | Ce qu’elle contient |
| --- | --- |
| Périmètre | La route, l’expéditeur, le marché et la date |
| Méthode | Comment les téléphones ont été choisis et le contenu figé |
| Résultats | État de remise, délai de remise et chaîne d’expéditeur par téléphone |
| Réponses | La route de réponse et le délai, quand le flux a besoin de réponses |
| Échecs | L’état de l’accusé, le code d’erreur et le téléphone |
| Preuves | Les enregistrements bruts et le contenu utilisé |
| Limites | Ce que le test ne prouve pas et quand le répéter |

Un rapport sans le contenu, les téléphones ou la date est un récit.

## Lire un échec

Un accusé absent n’est pas un accusé en échec. Absent signifie que l’enregistrement n’est jamais arrivé ; le message a peut-être atteint le téléphone. Un accusé en échec porte un état et souvent un code réseau qui nomme la raison : abonné inconnu, abonné absent, mémoire pleine, service bloqué. Lisez le code avant de changer la route.
Un accusé de remise sans affichage demande un autre contrôle : le téléphone, l’application de messages, le dossier de spam et la chaîne d’expéditeur. Une réponse qui n’arrive jamais désigne la route entrante ou le type d’expéditeur, pas le chemin sortant. Un résultat lent désigne la route, une file ou un bind limité. Corrigez l’étape que la preuve nomme.
Notez l’échec avec les mêmes champs qu’un succès : téléphone, marché, expéditeur, contenu, route, heure et état. Un enregistrement d’échec sans ces champs ne peut pas être comparé à l’exécution suivante, et c’est l’exécution suivante qui prouve la correction.

## Ce qu’il faut vérifier avant de croire un rapport

Demandez la date, les téléphones, les réseaux et le contenu exact. Demandez quelle route a porté le trafic et si elle était directe ou via un agrégateur. Demandez les états d’accusé et les codes d’erreur, pas seulement un pourcentage. Demandez ce que le test n’a pas couvert et quand il faudrait le répéter.
Comparez ensuite le rapport à votre propre trafic. Un test sur un téléphone peut réussir alors que la production échoue sur un autre modèle, un autre réseau ou un modèle de message plus long. Le [rapport d’échantillon d’un test de route](/fr/resources/downloads/route-test-sample-report/) montre la forme de l’enregistrement. Le [guide des fournisseurs](/fr/resources/learn/how-to-choose-an-a2p-sms-provider/) transforme le résultat en questions pour le fournisseur suivant.

Ouvrez l’outil de règles pour la liste à jour par marché ; il reste sur sa propre page.

### Check what you learned

**Un test remet sur un téléphone à Mexico. Qu’avez-vous prouvé ?**

Que cette route, cet expéditeur et ce contenu sont arrivés à ce téléphone dans ce marché à cette date. Vous n’avez pas prouvé les autres téléphones, les autres réseaux ni la semaine prochaine.

**Un accusé manque. Le message est-il perdu ?**

Pas forcément. L’enregistrement de l’accusé peut manquer alors que le message est arrivé. Vérifiez le téléphone et l’enregistrement du fournisseur avant de renvoyer.

**Que répéteriez-vous après un changement de route ?**

La même question, le même contenu et les mêmes téléphones sur la nouvelle route, avec une seconde route pour comparer si la décision en dépend.

## FAQ

**Combien de téléphones faut-il ?**

Assez pour représenter les modèles et les réseaux qui comptent pour le lancement. Un téléphone est un échantillon, pas un recensement.

**Un test prouve-t-il la remise ?**

Il prouve la remise sur les téléphones testés à ce moment. La remise sur un marché demande un suivi de production et des tests répétés.

**Combien de temps prend un test ?**

Les envois prennent quelques minutes ; collecter les réponses et écrire les limites prend plus longtemps. Fixez le périmètre avant de commencer.

**Peut-on comparer deux fournisseurs ?**

Oui, si les deux tests utilisent le même contenu, les mêmes téléphones, le même marché et la même fenêtre de temps. Changez une variable à la fois.

**Et si le test échoue ?**

Lisez d’abord l’état de l’accusé et le code d’erreur. Vérifiez ensuite l’expéditeur, le téléphone et la route, et changez une variable avant l’envoi suivant.

## Sources

- [3GPP TS 23.040 : réalisation technique du service de messages courts](https://www.3gpp.org/ftp/Specs/archive/23_series/23.040/) — Accessed: 2026-10-19
- [3GPP TS 23.038 : alphabets et informations propres à la langue](https://www.3gpp.org/ftp/Specs/archive/23_series/23.038/) — Accessed: 2026-10-19
- [smpp.org : accusés de remise, états et codes d’erreur](https://smpp.org/smpp-delivery-receipt.html) — Accessed: 2026-10-19

Updated: 2026-10-19