# Qu’est-ce que SMPP ? La session SMS

SMPP est le protocole par lequel une plateforme échange des messages courts avec un centre de messagerie sur une session persistante. Un bind déclare la direction, la session porte une fenêtre de débit et les accusés reviennent sous forme de PDU. Ce n’est pas une API de requête et réponse.

- SMPP est une session persistante avec une direction de bind déclarée.

- Un bind porte une allocation de débit et une fenêtre de requêtes en cours.

- Une PDU a un en-tête de 16 octets et un corps qui dépend de la commande.

- Les accusés arrivent de façon asynchrone sur la session ; ils se rapprochent par message ID.

## Une session, pas un appel

SMPP maintient une connexion ouverte entre votre plateforme et un centre de messagerie. La plateforme s’authentifie une fois, déclare ce qu’elle veut faire, puis envoie des messages et reçoit des événements sur la même session. Le centre n’attend pas une nouvelle requête pour envoyer un accusé ou un message entrant ; il pousse une PDU quand il a quelque chose à signaler.
Cette forme convient à un flux régulier. Le coût par message est faible parce que l’état de la session est déjà établi et que le canal des accusés est déjà ouvert. Elle signifie aussi que votre client porte un état qu’un client HTTP n’a pas : état du bind, fenêtre en cours, cadence du keep-alive et comportement de reconnexion.

## Le bind déclare une direction

Un bind, c’est la session authentifiée plus une direction. Un bind émetteur envoie des messages. Un bind récepteur reçoit les messages émis depuis le mobile et les accusés. Un bind émetteur-récepteur fait les deux sur une seule session. Le fournisseur émet des identifiants pour chaque bind et peut limiter le nombre de binds ouverts.
Montez en charge en ajoutant des binds, pas en poussant un bind au-delà de son allocation. Un bind porte une allocation de débit et une fenêtre de requêtes en cours. Si votre pic demande davantage, demandez un autre bind et répartissez le trafic. Un seul bind poussé au-delà de sa fenêtre produit limitation, timeouts et reprises qui ressemblent à une panne réseau mais naissent dans le client.

### Bind, envoi, accusé

La session s’ouvre une fois ; chaque envoi reçoit une réponse avec un message ID ; l’accusé arrive plus tard sur la même session.

Alt: Une séquence de l’application vers une requête de bind, le centre de messagerie, une réponse d’envoi et un accusé de remise.

L’application ouvre un bind et le centre de messagerie répond. L’application envoie un message court avec submit_sm et reçoit submit_sm_resp avec un message ID. Plus tard, le centre envoie une PDU deliver_sm portant l’accusé de remise. L’application la confirme avec deliver_sm_resp. Un unbind ferme la session quand le travail est terminé.

| Item | Value | Note |
| --- | --- | --- |
| Premier état · 1 | Application (ESME) |  |
| Premier état · 2 | bind_transceiver | Ouvrir la session |
| Premier état · 3 | SMSC |  |
| Premier état · 4 | submit_sm_resp | Accepté pour remise |
| Premier état · 5 | Accusé de remise |  |

Source: smpp.org : sessions SMPP et opérations PDU (https://smpp.org/)

## La fenêtre est le contrat

La fenêtre est le nombre de requêtes que votre client peut avoir en cours avant d’attendre les réponses. Ce n’est pas une suggestion. Envoyez plus que la fenêtre ne le permet et le centre vous limite ; continuez au même rythme et la file grossit. Lisez le code de réponse de chaque envoi, ralentissez en cas de limitation et laissez la fenêtre se vider avant la rafale suivante.
Le trafic de keep-alive maintient la session en vie. Un client qui n’envoie jamais enquire_link peut rester sur une connexion morte jusqu’à l’échec du premier envoi. Un client qui se reconnecte immédiatement après chaque coupure peut marteler le fournisseur. Utilisez un backoff, plafonnez la cadence de reconnexion et alertez quand le bind est tombé plus longtemps que votre trafic ne le tolère.

### Une PDU, champ par champ

L’en-tête est fixe ; le corps dépend de la commande. Un submit_sm porte les adresses, le codage et un indicateur d’accusé.

Alt: Une PDU submit_sm décodée avec la longueur de commande, le command ID, l’état, le numéro de séquence et les champs du corps.

Toute PDU commence par une longueur de commande de quatre octets, un command ID de quatre octets, un état de commande de quatre octets et un numéro de séquence de quatre octets. Le corps suit. Pour submit_sm, il porte les adresses source et destination, le message court, le codage des données et l’indicateur d’accusé enregistré. Les paramètres facultatifs voyagent en champs étiquette-longueur-valeur.

| Item | Value | Note |
| --- | --- | --- |
| command_length | 53 |  |
| command_id | 0x00000004 |  |
| command_status | 0x00000000 |  |
| sequence_number | 1 |  |
| service_type |  |  |
| source_addr_ton | 1 |  |
| source_addr_npi | 1 |  |
| source_addr | 12345 |  |
| dest_addr_ton | 1 |  |
| dest_addr_npi | 1 |  |
| destination_addr | 15551234567 |  |
| esm_class | 0x00 |  |
| protocol_id | 0x00 |  |
| priority_flag | 0 |  |
| schedule_delivery_time |  |  |
| validity_period |  |  |
| registered_delivery | 0x01 |  |
| replace_if_present_flag | 0x00 |  |
| data_coding | 0x00 |  |
| sm_default_msg_id | 0x00 |  |
| sm_length | 4 |  |
| short_message | 54657374 |  |
| Texte | Test |  |

Source: Spécification SMPP v3.4, en-tête PDU et submit_sm (https://smpp.org/SMPP_v3_4_Issue1_2.pdf)

## Une journée dans la vie d’un message

Le client ouvre un bind émetteur-récepteur et lit la réponse. Il envoie un message et conserve le message ID de la réponse. Le centre achemine le message vers le réseau de destination. Quelques minutes plus tard, une PDU deliver_sm arrive avec l’accusé : le message ID d’origine, un état et souvent un code réseau. Le client confirme l’accusé et rapproche l’état de son propre enregistrement.
Chaque étape a son mode de défaillance. Un bind peut être refusé pour de mauvais identifiants ou une mauvaise version d’interface. Un envoi peut être limité, refusé, ou accepté puis échouer dans l’accusé. Un accusé peut arriver après l’expiration du code. Concevez le client pour conserver le message ID, accepter un accusé tardif et laisser l’état de l’application faire foi sur ce que l’utilisateur a fait.

Le décodeur s’exécute dans le navigateur ; l’accusé collé n’en sort pas.

[Open the tool](/fr/tools/smpp-decoder/?src=learn-what-is-smpp&scenario=dlr-example&sample=id%3A0123456789+sub%3A001+dlvrd%3A001+submit+date%3A2610181200+done+date%3A2610181201+stat%3ADELIVRD+err%3A000+text%3AVotre+code+est+123456)

### Décodez un accusé avant de déboguer une route

Collez un accusé de remise dans le [décodeur SMPP et DLR](/fr/tools/smpp-decoder/) et lisez les champs. Vérifiez le message ID, l’état, la date de fin et le code d’erreur. Si l’état n’est pas DELIVRD, le code d’erreur, lu dans la table des codes du fournisseur, peut indiquer si le numéro, le téléphone ou le réseau a refusé le message. Faites-le avant de demander au fournisseur de changer la route.

## Accusés et débogage

Un accusé est asynchrone. Il arrive sur la session sous forme de PDU deliver_sm, et son format dépend du centre de messagerie. Les implémentations récentes portent l’état dans un champ étiquette-longueur-valeur message_state. Les anciennes placent un accusé texte dans le champ du message court, avec des paires clé-valeur comme id, stat et err. Analysez les deux au lieu d’en supposer un.
Rapprochez par message ID, pas par ordre d’arrivée. Deux messages envoyés à une seconde d’intervalle peuvent revenir dans l’ordre inverse, et une reprise peut produire un doublon. Conservez l’ID à l’envoi, mettez à jour l’enregistrement à l’arrivée de l’accusé et ignorez un second accusé pour le même ID sauf si son état est plus récent. Le [guide de connexion](/fr/resources/guides/smpp-http-connection/) en fait une séquence d’exploitation.

### Check what you learned

**Pourquoi un second bind aide-t-il plus qu’une cadence de reprise plus élevée ?**

Un bind porte une fenêtre. Ajouter un bind ajoute de la capacité ; réessayer contre une fenêtre pleine ajoute de la file et du délai.

**D’où vient le message ID ?**

Le centre de messagerie le renvoie dans submit_sm_resp. Conservez-le et rapprochez l’accusé ultérieur par cet ID.

**Que prouve un accusé de remise ?**

Que le réseau a accepté et remis le message vers le téléphone. Cela ne prouve pas qu’une personne l’a lu.

## FAQ

**Faut-il SMPP pour commencer ?**

Non. HTTP s’intègre en une après-midi ; SMPP devient rentable quand un volume régulier justifie une session.

**Qu’est-ce qu’un bind ?**

Une session persistante avec une direction déclarée : émetteur, récepteur ou émetteur-récepteur. Elle porte une allocation de débit et reste ouverte par des échanges de keep-alive.

**Qu’est-ce qu’une PDU ?**

Protocol Data Unit : le message binaire échangé par SMPP. Toute PDU a un en-tête de 16 octets et un corps propre à la commande.

**Peut-on utiliser SMPP sur l’internet public ?**

Souvent oui, avec TLS et une liste d’IP autorisées, mais demandez au fournisseur. Certains déploiements utilisent une connexion privée.

**Comment sont traités les messages longs ?**

En segments concaténés avec un en-tête de données utilisateur, ou en TLV de payload que le réseau segmente. Testez le résultat sur le téléphone.

## Sources

- [smpp.org : sessions SMPP, opérations de bind et accusés de remise](https://smpp.org/) — Accessed: 2026-10-19
- [Spécification SMPP v3.4, Issue 1.2](https://smpp.org/SMPP_v3_4_Issue1_2.pdf) — Accessed: 2026-10-19
- [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

Updated: 2026-10-19