--- title: "Décodeur d'accusés de réception SMS (DLR)" description: "Décodez les accusés de réception SMPP : codes stat comme DELIVRD et UNDELIV, err, dates, délai de livraison et erreurs command_status. Gratuit, dans le navigateur." canonical: "https://omnichannels.ai/fr/tools/sms-delivery-report-decoder/" language: "fr" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" --- # Décodeur d'accusés de réception SMS (DLR) Canonical: https://omnichannels.ai/fr/tools/sms-delivery-report-decoder/ Language: fr Publisher: OmniChannels.ai by BroadNet Technologies Un accusé de réception SMPP (DLR) est le reçu qu'un SMSC renvoie dans un PDU deliver_sm après l'envoi d'un SMS. Son texte suit le modèle id, sub, dlvrd, submit date, done date, stat, err et text. Le champ stat donne le résultat : DELIVRD signifie délivré sur le téléphone ; UNDELIV, EXPIRED, DELETED et REJECTD sont des échecs définitifs ; ENROUTE et ACCEPTD sont intermédiaires. Les dates suivent le format AAMMJJhhmm, parfois avec les secondes. ## Comment décoder un accusé de réception SMS 1. **Copiez le texte de l'accusé:** Récupérez le short_message du PDU deliver_sm dans votre client SMPP ou les journaux du SMSC, par exemple id:… sub:001 dlvrd:001 … stat:DELIVRD err:000. Les préfixes de journal sont ignorés. 2. **Collez un accusé par ligne:** Collez un seul accusé ou des centaines. Vous pouvez aussi coller une valeur command_status, comme 0x00000058 ou ESME_RTHROTTLED, sur sa propre ligne. 3. **Lisez les champs décodés:** Chaque accusé affiche la signification du statut, son caractère final ou non, le statut webhook le plus proche, des dates lisibles, le délai de livraison et des alertes pour les champs manquants ou incohérents. 4. **Consultez la synthèse du lot:** Voyez les totaux par stat et par statut webhook, le taux de délivrance et le délai médian, puis copiez le tout en JSON pour un ticket ou un jeu de test. ## Anatomie d'un accusé de réception SMPP Quand vous envoyez un SMS avec registered_delivery à 1, le SMSC renvoie plus tard un PDU deliver_sm sur un bind récepteur ou émetteur-récepteur. Le bit 0x04 de son esm_class indique qu'il s'agit d'un accusé et non d'un message entrant, et son short_message contient un accusé texte. L'annexe B de la spécification SMPP v3.4 donne ce format en exemple, et presque tous les SMSC le suivent : id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm stat:DDDDDDD err:E text:…. L'annexe B étant un exemple et non une règle stricte, les accusés réels varient : clés en minuscules, espaces en trop, submit_date avec un tiret bas, dates à 12 chiffres avec secondes ou champ text absent. Ce décodeur accepte toutes ces variantes et signale les champs manquants. - id : l'identifiant renvoyé par le SMSC dans submit_sm_resp. Il permet de rattacher l'accusé à votre message. L'exemple de la spécification montre 10 caractères, mais beaucoup de SMSC utilisent des identifiants plus longs, parfois en hexadécimal. - sub et dlvrd : le nombre de messages soumis et délivrés, sur 3 chiffres. Ils servent surtout pour les listes de diffusion ; pour un SMS unique, on voit généralement 001 et 001 (ou 000). - submit date et done date : la date de soumission et celle de l'état final, selon l'horloge du SMSC. - stat : l'état final ou intermédiaire, sous forme de code de 7 lettres comme DELIVRD. - err : un code d'erreur de 3 caractères, propre au réseau ou au SMSC ; 000 signifie aucune erreur. - text : les 20 premiers caractères du message d'origine, souvent tronqués ou vides. - Des TLV optionnels peuvent reprendre ces données sous une forme plus propre : receipted_message_id (0x001E), message_state (0x0427) et network_error_code (0x0423). ## Les codes stat des DLR et leur signification SMPP v3.4 définit huit états de message. ENROUTE et ACCEPTD sont intermédiaires, les autres sont finaux. Notre API normalise tous les canaux en six statuts webhook (SUBMITTED, SENT, DELIVERED, READ, FAILED, REJECTED), et le décodeur affiche la correspondance la plus proche pour chaque valeur stat. Cette correspondance est indicative : la règle exacte de votre compte est confirmée lors de la mise en service. - DELIVRD (message_state 2) : délivré sur le téléphone. Statut webhook le plus proche : DELIVERED. - ACCEPTD (6) : formellement « lu manuellement par le service client pour le compte de l'abonné », mais la plupart des SMSC l'envoient comme accusé intermédiaire « accepté par le réseau ». Le plus proche : SENT. - ENROUTE (1) : toujours en transit, par exemple en attente d'une nouvelle tentative. Le plus proche : SENT. - UNDELIV (5) : non distribuable, par exemple un numéro invalide ou inactif. Le plus proche : FAILED. - EXPIRED (3) : la période de validité a expiré avant que le téléphone soit joignable, souvent éteint ou hors couverture. Le plus proche : FAILED. - DELETED (4) : supprimé avant la livraison, par exemple via cancel_sm. Le plus proche : FAILED. - REJECTD (8) : refusé par le réseau ou un pare-feu SMS, par exemple un identifiant d'expéditeur (Sender ID) non enregistré ou un contenu bloqué. Le plus proche : REJECTED. - UNKNOWN (7) : le SMSC n'a pas d'état final. Considérez-le comme non confirmé, pas comme un échec avéré. ## Codes err : pourquoi il n'existe pas de liste universelle Le champ err fait trois caractères et la spécification SMPP n'en définit pas les valeurs. 000 signifie toujours aucune erreur, mais les autres valeurs viennent de l'éditeur du SMSC, de l'opérateur ou d'un agrégateur intermédiaire. Certains SMSC transmettent les causes d'erreur GSM MAP (par exemple, l'erreur MAP 1 correspond à un abonné inconnu et la 27 à un abonné absent), d'autres utilisent leur propre table. Si l'accusé contient le TLV network_error_code (0x0423), il est plus fiable : son premier octet indique le type de réseau (3 pour GSM) et les deux suivants le code d'erreur. Un accusé DELIVRD avec un err non nul est incohérent et mérite d'être signalé à votre fournisseur ; le décodeur le met en évidence. ## Erreurs command_status et accusés de réception SMPP signale les problèmes à deux moments. Le command_status de submit_sm_resp arrive en quelques millisecondes et indique si le SMSC a accepté votre requête ; 0x00000000 (ESME_ROK) signifie accepté, pas délivré. L'accusé de réception arrive de quelques secondes à quelques jours plus tard et donne le résultat final. Les valeurs command_status sont définies à la section 5.1.3 de SMPP v3.4. Les plus fréquentes en production sont 0x00000058 ESME_RTHROTTLED (vous dépassez le débit convenu : ralentissez et réessayez avec un backoff exponentiel), 0x00000014 ESME_RMSGQFUL (file pleine : temporisez), 0x0000000A et 0x0000000B (adresse source ou destination invalide) et 0x0000000D ou 0x0000000E (échec du bind ou mot de passe erroné). Les valeurs 0x00000400 à 0x000004FF sont réservées aux erreurs propres à l'éditeur du SMSC : interrogez votre fournisseur. ## Dates, fuseaux horaires et délai de livraison Les dates des accusés suivent le format AAMMJJhhmm, et beaucoup de SMSC ajoutent les secondes (AAMMJJhhmmss). Aucun fuseau horaire n'est indiqué : l'heure est celle de l'horloge du SMSC, généralement UTC. Le décodeur affiche les dates telles quelles et calcule le délai comme done date moins submit date, ce qui reste juste tant que les deux proviennent de la même horloge. Le délai est un bon indicateur de qualité. Un OTP vers un téléphone joignable aboutit généralement en quelques secondes. De longs délais suivis d'EXPIRED signalent des téléphones éteints ou en itinérance, et une done date antérieure à la submit date indique des horloges désaccordées. Des dates à la minute ne mesurent pas un délai inférieur à la minute : privilégiez les SMSC qui envoient les secondes. ## Traiter les accusés de façon fiable en production Répondez à chaque deliver_sm par un deliver_sm_resp, même si votre traitement échoue, sinon le SMSC le renvoie et peut brider le bind. Stockez l'accusé brut, puis traitez-le de façon asynchrone et idempotente par identifiant de message, car les accusés peuvent arriver en double ou dans le désordre : un ENROUTE tardif ne doit jamais écraser un DELIVRD. Si vous préférez ne pas analyser d'accusés, notre API SMS REST fournit les mêmes informations sous forme de statuts webhook normalisés, et les accusés manqués peuvent être renvoyés avec POST /sms/resendDlr. Des binds SMPP sur TLS sont disponibles pour les gros volumes et les revendeurs. ## Questions sur les accusés de réception ### Que signifie stat:DELIVRD dans un accusé de réception SMS ? DELIVRD est l'état SMPP « délivré » : le SMSC a la confirmation que le message est arrivé sur le téléphone du destinataire. Cela ne veut pas dire qu'il a été ouvert ou lu ; le SMS classique n'a pas d'accusé de lecture. Dans nos webhooks, il correspond à DELIVERED. ### Quelle différence entre UNDELIV, EXPIRED et REJECTD ? UNDELIV signifie que le réseau n'a pas pu remettre le message, par exemple parce que le numéro est invalide ou inactif. EXPIRED signifie que les tentatives ont duré jusqu'à la fin de la période de validité, en général parce que le téléphone était éteint ou hors couverture. REJECTD signifie que le réseau ou un pare-feu a refusé le message, par exemple pour un identifiant d'expéditeur non enregistré ou un contenu bloqué. ### Que signifie ACCEPTD dans un DLR SMPP ? Dans la spécification SMPP v3.4, ACCEPTD signifie que le message a été lu manuellement par le service client pour le compte de l'abonné. En pratique, la plupart des SMSC et agrégateurs l'utilisent comme accusé intermédiaire indiquant que le réseau a accepté le message ; un accusé final DELIVRD ou d'échec suit. ### Qu'est-ce que l'erreur SMPP 0x00000058 ? 0x00000058 correspond à ESME_RTHROTTLED : vous avez envoyé plus de messages par seconde que votre bind ne l'autorise. L'erreur est temporaire. Réduisez votre débit, gardez une fenêtre raisonnable de submit_sm en attente et réessayez les messages refusés avec un backoff exponentiel plutôt qu'immédiatement. ### Que signifie err:000 et où trouver les autres codes err ? err:000 signifie aucune erreur. Les valeurs err non nulles ne sont pas définies par la spécification SMPP ; elles viennent de l'éditeur du SMSC, de l'opérateur ou d'un agrégateur, et certaines reprennent les causes d'erreur GSM MAP. Demandez sa table d'erreurs à votre fournisseur et consultez le TLV network_error_code s'il est présent. ### Quel format de date utilise un accusé de réception SMPP ? submit date et done date utilisent le format AAMMJJhhmm, par exemple 2610101201 pour le 10 octobre 2026 à 12 h 01. Beaucoup de SMSC ajoutent les secondes (AAMMJJhhmmss). Aucun fuseau horaire n'est inclus : c'est l'horloge du SMSC, généralement UTC. ### Pourquoi n'ai-je pas reçu d'accusé de réception ? Causes fréquentes : registered_delivery n'est pas à 1 dans submit_sm, un bind émetteur seul sans bind récepteur, un réseau de destination qui ne renvoie pas d'accusés, ou un client qui n'acquitte pas les deliver_sm. Certaines routes ne renvoient que des accusés intermédiaires. Pour le trafic REST, vérifiez votre webhook et faites renvoyer les accusés avec /sms/resendDlr. ### Le texte de mes accusés est-il envoyé quelque part ? Non. Le décodeur fonctionne entièrement dans votre navigateur. Rien de ce que vous collez, y compris les identifiants ou le texte des messages, n'est envoyé à nos serveurs.