# Explication des accusés de réception de SMS (DLR) et des codes d'erreur

> Un accusé de réception (DLR) est la décision finale de l'opérateur concernant votre SMS. Ce document explique la signification des mentions « DELIVRD », « UNDELIV », « EXPIRED » et « REJECTD », ainsi que la signification des champs « stat » et « err ».

- URL canonique: https://www.broadnet.me/fr/blog/sms-delivery-receipts-dlr-error-codes
- Langue: fr
- Dernière mise à jour: 2026-10-20
- Éditeur: BroadNet (https://www.broadnet.me)

- Publié le: 2026-08-03
- Auteur: BroadNet Engineering

Un accusé de réception (DLR) est un message d'état renvoyé après l'envoi d'un SMS, indiquant son état final — LIVRÉ, NON LIVRÉ, EXPIRÉ, SUPPRIMÉ, ACCEPTÉ, INCONNU ou REJETÉ — conformément au protocole SMPP. Un DLR authentique provient de l'opérateur destinataire, et non de la passerelle ; il indique donc si le terminal a reçu le message et, via son champ err, la raison du non-reçu.

## Qu'est-ce qu'un accusé de réception — et qu'est-ce qu'il n'est pas ?

Dès l'envoi d'un message, vous recevez deux signaux distincts. Leur confusion est la principale cause des interruptions fantômes. Le premier est l'accusé de réception : sur SMPP, le SMSC renvoie une réponse submit_sm_resp avec le code d'état command_status ESME_ROK (0x00000000) ; sur une API HTTP, vous recevez un code 202 et un identifiant de message. Cela signifie simplement que la plateforme a accepté le message pour traitement. Le second signal, reçu ultérieurement, est l'accusé de réception de livraison (DLR) : un rapport hors bande indiquant le traitement final du message par le réseau. Sur SMPP, il est renvoyé sous la forme d'une PDU deliver_sm dont la classe esm_class le désigne comme un accusé de réception ; sur une API REST, il est transmis à votre webhook. Configurez votre système en fonction du DLR, et non de la réponse à l'envoi du message. Consultez le [guide du développeur SMPP](https://www.broadnet.me/developers/smpp) pour plus d'informations sur les indicateurs bind et receipt-request.

## Accusé de réception de passerelle par rapport à un DLR d'opérateur réel

Tous les DLR ne sont pas créés au même endroit sur le réseau, et c'est là que réside la difficulté à garantir la qualité du routage. Un DLR de niveau opérateur est généré par le réseau de destination après que le terminal a accusé réception du SMS au niveau SS7/MAP ou Diameter ; le SMSC de l'opérateur convertit ce rapport de couche réseau en accusé de réception SMPP. En revanche, un DLR intermédiaire ou de passerelle est synthétisé par un agrégateur lorsqu'il transmet le message au prochain saut, avant même que l'opérateur de destination n'ait confirmé quoi que ce soit. Sur une route directe optimale, les deux DLR coïncident ; sur une route intermédiaire, ils divergent.

Voilà pourquoi les faux DLR sont dangereux. Un agrégateur de routes grises incapable d'obtenir un accusé de réception authentique d'un opérateur falsifie souvent un DELIVRD lors du transfert intercellulaire pour que ses tableaux de bord paraissent fonctionnels, même si le message a été silencieusement abandonné en aval, filtré ou bloqué par le boîtier SIM. L'indice révélateur est un taux de livraison anormalement élevé associé à des utilisateurs réels n'ayant jamais reçu le message, ou une route renvoyant UNKNOWN en masse (le SMSC n'a pas d'état valide car aucun nœud en aval n'a renvoyé de rapport valide). Collez n'importe quelle chaîne d'accusé de réception dans le [décodeur DLR](https://www.broadnet.me/tools/dlr-decoder) pour comparer précisément ce qu'affirme une route avec un accusé de réception authentique d'un opérateur.

## Comment les DLR vous reviennent

Il existe deux protocoles de transport et une source sous-jacente. Via SMPP, la réception est renvoyée de manière asynchrone sous forme d'unité de données de protocole (PDU) deliver_sm sur votre session liée. L'état final est contenu dans le corps du message court (la chaîne classique id:… stat:… err:…) et, sur les versions 5.0 et de nombreuses implémentations 3.4, dans les volumes de liste de TLV message_state et network_error_code. Via une API HTTP, les mêmes informations sont envoyées par requête POST à un webhook que vous avez enregistré, généralement au format JSON. Ces deux protocoles sont en définitive dérivés du rapport d'état du réseau : la spécification technique 3GPP TS 23.040 définit le SMS-STATUS-REPORT et son champ TP-Status, que le SMSC de terminaison traduit en l'état du message SMPP que vous lisez. La couche SMPP est un vecteur fidèle pour un rapport généré en réalité sur le réseau mobile.

Quel que soit le mode de transport, enregistrez les mêmes champs pour chaque reçu afin de pouvoir diagnostiquer les problèmes par récurrence plutôt que par anecdotes :

- L'identifiant du message, afin que vous puissiez joindre le DLR au submit_sm d'origine.
- La valeur stat (l'état final du message) et la valeur err (le code d'erreur réseau/opérateur).
- L'opérateur de destination (MCC/MNC), l'identifiant de l'expéditeur et la route ou la liaison utilisées.
- Les horodatages de la date de soumission et de la date d'exécution vous permettent de mesurer la latence de bout en bout et de repérer les modèles d'expiration.

```
id:1a2b3c4d5e sub:001 dlvrd:001 submit date:2608031200 done date:2608031201 stat:DELIVRD err:000 text:Votre code BroadNet

id:9f8e7d6c5b sub:001 dlvrd:000 submit date:2608031200 done date:2608031205 stat:UNDELIV err:062 text:Votre code BroadNet
```

Deux champs contiennent le diagnostic. Le champ `stat` correspond à l'état final standardisé du message (voir ci-dessous). Le champ `err` est un code spécifique au réseau/à l'opérateur ; un même message UNDELIV peut arriver avec différentes valeurs `err` selon l'opérateur. Par conséquent, `err` n'a de sens que dans le contexte du réseau de destination. Notez que ce code `err` est différent du `command_status` SMPP reçu lors de la soumission de la réponse SMPP (par exemple, `ESME_RINVDSTADR`, `ESME_RTHROTTLED`). Leur décodage diffère. Utilisez l'outil de recherche de codes d'erreur SMPP (`/tools/smpp-error-codes`) pour les valeurs `command_status` et le décodeur DLR pour la chaîne de réception.

## Le message SMPP indique, décodé

SMPP définit un ensemble restreint et fermé d'états finaux, auquel s'ajoute l'état transitoire ENROUTE pouvant apparaître avant la stabilisation d'un message. Les sept états ci-dessous marquent la fin du cycle de vie d'un message, avec leur cause typique et l'action qu'ils sont censés déclencher. Il convient de les interpréter comme une distribution par opérateur, identifiant d'expéditeur et route : un seul état UNDELIV est considéré comme du bruit ; une route présentant un taux d'UNDELIV de 40 % chez un opérateur donné révèle un problème de routage.

| État DLR (stat) | Ce que cela signifie | Cause typique | Ce qu'il faut faire |
|---|---|---|---|
| LIVRÉ | Le téléphone a confirmé la réception | Le message a atteint l'appareil | Rien à signaler — c’est un succès ; vérification ponctuelle par rapport aux rapports d’utilisateurs réels pour détecter les livraisons falsifiées. |
| ACCEPTÉ | Accepté au nom de l'abonné (par exemple, lu par le service client) | L'opérateur a marqué la demande comme acceptée sans véritable accusé de réception du combiné. | À considérer comme un succès partiel ; enquêtez sur toute voie renvoyant ACCEPTD en masse — cela masque souvent une non-livraison. |
| EXPIRÉ | Période de validité expirée avant la livraison | Téléphone éteint ou hors de couverture pendant toute la durée de la période, ou épuisement des tentatives de connexion SMSC. | Réessayez plus tard ou utilisez un autre canal ; vérifiez que votre période de validité n’est pas trop courte. |
| SUPPRIMÉ | Message supprimé au SMSC avant sa distribution | Suppression manuelle/admin ou suppression du filtre anti-spam | Vérifiez le filtrage du contenu de l'opérateur et votre politique relative à l'identifiant de l'expéditeur et au contenu. |
| DÉLIVRER | Le message n'a pas pu être distribué. | MSISDN invalide ou non attribué, absence de route, rejet au niveau du réseau ou blocage du pare-feu | Validez le numéro (recherche HLR), puis vérifiez la qualité de l'acheminement et l'enregistrement de l'identifiant de l'expéditeur. |
| REJETÉ | L'opérateur a refusé le message. | Identifiant d'expéditeur non enregistré, filtre de contenu, classification de spam ou liste de consentement/Ne pas déranger | Enregistrez l'identifiant de l'expéditeur, corrigez le modèle et confirmez l'inscription pour la destination. |
| INCONNU | Le SMSC n'a pas d'état valide pour le message | Un relais en aval n'a jamais renvoyé de véritable rapport – souvent un trou noir de la voie grise | Remettez en question le trajet ; un trajet direct et sûr revient rarement à l'inconnu. |

## Interpréter les DLR comme un signal de qualité de route

Dès lors que vous acceptez que seul le DLR au niveau de l'opérateur soit fiable, le flux de reçus devient votre meilleur outil d'évaluation de la qualité des routes, surpassant toute carte de couverture ou présentation commerciale. Les routes directes renvoient des codes d'erreur spécifiques et cohérents, ainsi qu'un taux de livraison stable. Les routes « grises » renvoient des erreurs génériques, une quantité importante de messages « INCONNU » et un taux de livraison fluctuant d'une semaine à l'autre, les pare-feu des opérateurs bloquant le trafic et l'agrégateur réacheminant silencieusement les messages. Segmentez la distribution du DLR en fonction de l'opérateur et de l'identifiant de l'expéditeur au fil du temps : les opérateurs où vous observez une augmentation des messages « NON LIVRÉ »/« INCONNU » ou une disparition des détails d'erreur sont ceux qui utilisent une route dégradée. Pour les marchés réglementés du CCG (Émirats arabes unis sous la TDRA, Arabie saoudite sous la CST), un message « REJETÉ » concentré sur un identifiant d'expéditeur indique presque toujours un problème d'enregistrement ou d'approbation de modèle plutôt qu'une panne de réseau.

> BroadNet renvoie de véritables DLR au niveau opérateur (et non des accusés de réception de passerelle) sur 1,000+ connexions d'opérateurs dans 200+ pays, avec les champs stat et err exposés pour chaque message, ce qui permet de visualiser la qualité du routage en temps réel. Ce service est soutenu par un SLA de plateforme de 99,99 % et des routes A2P directes maintenues depuis 2003. Explorez l'[API SMS](https://www.broadnet.me/products/sms-api) ou le [guide du développeur SMPP](https://www.broadnet.me/developers/smpp).

## Foire aux questions

### Qu'est-ce qu'un accusé de réception de livraison par SMS ?

Un accusé de réception (DLR) est un rapport d'état renvoyé après l'envoi d'un SMS, indiquant le résultat final du message : distribué, non distribué, expiré, rejeté, etc. Il est reçu après l'accusé de réception, soit sous forme d'unité de données de protocole (PDU) SMPP deliver_sm receipt, soit via un webhook HTTP. Un accusé de réception authentique provient de l'opérateur destinataire, et non de la passerelle, confirmant ainsi la bonne réception du message par le terminal.

### Que signifie DLR ?

DLR signifie « accusé de réception » (parfois « rapport de livraison »). Dans le protocole SMPP, il s'agit du rapport d'état du message renvoyé par le SMSC pour un message soumis. Ce rapport contient un champ d'état (DELIVRD, UNDELIV, EXPIRED, DELETED, ACCEPTD, UNKNOWN, REJECTD) et un code d'erreur spécifique à l'opérateur. Il permet de distinguer la confirmation de la prise en charge d'un message pour traitement de la confirmation de sa livraison effective à un périphérique.

### Pourquoi mon SMS affiche-t-il « NON LIVRÉ / REJETÉ » ?

« UNDELIV » signifie généralement que le message n'a pas pu atteindre le terminal : numéro MSISDN invalide ou non attribué, absence de route, blocage au niveau du réseau ou du pare-feu. « REJECTD » indique que l'opérateur a refusé le message, généralement en raison d'un identifiant d'expéditeur non enregistré, d'un filtrage de contenu, d'une classification comme spam ou d'une inscription sur une liste d'opposition au démarchage téléphonique. Consultez le champ « err » et corrélez les échecs par identifiant d'expéditeur, opérateur et route afin d'identifier la cause réelle.

### En quoi un accusé de réception de passerelle diffère-t-il d'un DLR d'opérateur ?

Un accusé de réception de passerelle (submit_sm_resp avec ESME_ROK ou réponse HTTP 202) confirme uniquement que la plateforme a accepté votre message pour traitement. Un DLR de l'opérateur confirme le traitement effectif du message par le réseau de destination. Les agrégateurs sur les routes grises peuvent parfois falsifier les accusés de réception DELIVRD lors du transfert ; par conséquent, un DLR provenant de l'opérateur est le seul signal fiable attestant de la réception du message par le terminal.

## Références

- Spécifications SMPP v3.4 et v5.0 — format de réception de livraison, état du message et code d'erreur réseau : [smpp.org](https://smpp.org/)
- 3GPP TS 23.040 — réalisation technique du service de messagerie courte (SMS-STATUS-REPORT, TP-Status) : [3gpp.org](https://www.3gpp.org/)
- Outils BroadNet — [décodeur DLR](https://www.broadnet.me/tools/dlr-decoder) et [recherche de code d'erreur SMPP](https://www.broadnet.me/tools/smpp-error-codes).
- BroadNet — [Guide du développeur SMPP](https://www.broadnet.me/developers/smpp) et [API SMS](https://www.broadnet.me/products/sms-api).