# SMPP ou HTTP : quelle connexion choisir

SMPP tient une session persistante avec une fenêtre de débit par bind ; HTTP authentifie chaque requête et reçoit les événements sur un callback. Les deux transportent les mêmes messages et signalent les mêmes états de remise. Choisissez selon la forme du trafic et les pannes que votre équipe sait exploiter.

- SMPP garde une session ouverte et porte une fenêtre de requêtes en cours par bind.

- HTTP lance une requête authentifiée à chaque envoi et utilise un callback pour les accusés.

- Les deux modèles renvoient les mêmes états de remise ; le transport change leur mode d’arrivée.

- Les pannes diffèrent : fenêtre de bind pleine côté SMPP, callback lent côté HTTP.

## La décision en un paragraphe

Commencez par HTTP si le volume est faible, le trafic arrive par rafales et l’équipe exploite déjà des endpoints web. Passez à SMPP quand le trafic est un flux régulier, quand l’authentification et l’établissement de connexion à chaque requête ont un coût visible, ou quand les accusés doivent arriver par la même session transceiver que les envois. Beaucoup de plateformes utilisent les deux : SMPP pour le flux d’envoi et HTTP pour les callbacks entrants.
Le protocole n’est pas le produit. La route, l’enregistrement de l’expéditeur et les tests sur téléphone décident si un message arrive. SMPP et HTTP sont deux façons d’atteindre le même centre de messagerie, et l’une comme l’autre peut être bien ou mal exploitée.
La bonne question n’est pas quel protocole est le plus récent. C’est quelle panne votre équipe peut voir et corriger à la cadence du trafic. Un bind silencieux à deux heures du matin et un callback en échec à deux heures du matin sont tous deux des problèmes d’exploitation. Choisissez celui que vos outils savent diagnostiquer.

### Le même travail, deux formes

|  | SMPP | HTTP |
| --- | --- | --- |
| Session | Bind authentifié maintenu ouvert | Clé envoyée à chaque requête |
| Fenêtre | Fenêtre fixe de requêtes en cours par bind | Concurrence fixée par le client et le pool |
| Accusé de remise | PDU deliver_sm sur un bind transceiver (ou un receiver séparé) | Callback vers votre endpoint |
| Message entrant | deliver_sm sur un bind receiver ou transceiver | Callback vers votre endpoint |
| Reprise | Le client gère la fenêtre et le backoff | Le client répète la requête ; le fournisseur répète le callback |

Le tableau décrit le transport, pas l’implémentation d’un fournisseur. Confirmez les détails à l’onboarding.

## Le débit suit la forme

Un bind SMPP est provisionné avec un débit et une fenêtre. Une fois la session ouverte, un envoi coûte une PDU et une réponse, sans nouvelle poignée de main. SMPP est donc efficace pour un flux soutenu et prévisible pour dimensionner la capacité : comptez les binds, lisez l’allocation et gardez les requêtes en cours sous la fenêtre.
HTTP paie l’authentification et l’établissement de connexion à chaque requête, même si la réutilisation des connexions réduit le coût. La capacité vient de la concurrence, pas d’une fenêtre de bind : le client peut lancer une rafale puis heurter une limite de débit ou une file. Cette souplesse convient aux campagnes et aux applications à faible volume ; elle rend aussi le pic plus difficile à raisonner si le client ne plafonne pas la concurrence. Une limite de débit et une fenêtre sont deux contrôles différents : l’un plafonne les requêtes par seconde, l’autre les requêtes en cours. Le coût par requête se voit à fort volume, pas avec quelques milliers de messages par jour.

Changez le débit et la fenêtre ; le planificateur s’exécute dans le navigateur.

[Open the tool](/fr/tools/tps-planner/?src=learn-smpp-vs-http&scenario=campaign-50tps&tps=50&windowMin=60)

## Les accusés et l’entrant décident de l’intégration

SMPP remet les accusés et les messages entrants sur un bind receiver ou transceiver. Le client doit garder la session en vie pour les recevoir, rapprocher chaque accusé du message ID conservé et répondre avec deliver_sm_resp. Il n’y a pas d’endpoint de callback à sécuriser, mais une session à surveiller : un bind ouvert et silencieux est un mode de défaillance.
HTTP remet les accusés et les messages entrants à une URL. Le récepteur vérifie la signature, répond vite et traite l’événement de façon asynchrone. Un callback lent est la panne courante : le fournisseur expire le délai, réessaie, et le même événement est traité deux fois. Les clés d’idempotence et un accusé rapide font partie de l’intégration, ce ne sont pas des optimisations.
Quel que soit le chemin de l’accusé, conservez la charge utile d’origine. L’interprétation du fournisseur peut changer, et un dossier de support repose souvent sur l’état ou le code d’erreur d’origine. Conservez-les avec le message ID, la route et l’heure.

### Modes de défaillance à concevoir

| Panne | Ce que l’on voit | Que faire |
| --- | --- | --- |
| Fenêtre de bind pleine | Les timeouts et les reprises montent ensemble ; la file grandit | Arrêtez de réessayer, laissez la fenêtre se vider, ajoutez un bind |
| Session silencieuse | Le bind est ouvert mais aucune réponse n’arrive | Envoyez enquire_link, expirez la session, reconnectez avec backoff |
| Accusé mal rapproché | Les états sont attachés au mauvais message | Rapprochez par message ID, pas par ordre d’arrivée |
| Callback lent | Le fournisseur réessaie ; des doublons apparaissent | Répondez vite, traitez ensuite, utilisez une clé d’idempotence |
| Idempotence absente | Une reprise réseau crée deux messages | Portez une référence client et dédupliquez dessus |
| Dérive de codage | Un message long arrive en morceaux ou avec de mauvais caractères | Fixez GSM-7 ou UCS-2 volontairement et testez le nombre de segments |

Les corrections sont opérationnelles. Aucun transport ne les supprime.

## Choisir et intégrer

Choisissez SMPP quand le flux d’envoi est soutenu, que le fournisseur alloue une fenêtre que vous pouvez dimensionner et que l’équipe sait exploiter une session : gestion des binds, keep-alive, reconnexion et journaux au niveau PDU. Choisissez HTTP quand le volume est modéré, que l’équipe exploite déjà des endpoints web sécurisés et qu’un callback s’intègre à l’architecture. Choisissez les deux quand l’envoi et l’entrant ont des responsables différents.
Quel que soit le choix, demandez les mêmes preuves : une route de test, l’allocation de débit, le format de l’accusé, la liste des codes d’erreur et la politique de reprise. L’[explication de SMPP](/fr/resources/learn/what-is-smpp/) couvre la session, et le [guide de connexion](/fr/resources/guides/smpp-http-connection/) couvre le chemin vers la production.
Écrivez le choix avec des chiffres : débit de pointe, fenêtre par bind, timeout du callback et budget de reprises. Une décision sans ces chiffres est une préférence. Revoyez-la quand le pic ou l’équipe change.

### Check what you learned

**Une campagne tourne à 40 messages par seconde de façon régulière et les accusés doivent arriver sur la même session transceiver. Quel transport convient ?**

SMPP avec un bind transceiver, assez de binds et une fenêtre dimensionnée pour le débit. HTTP peut porter le volume, mais les accusés arrivent sur un callback, pas sur la session SMPP.

**L’endpoint de callback met huit secondes à répondre. Que se passe-t-il ?**

Le fournisseur expire le délai et réessaie, donc le même événement est livré à nouveau. Répondez vite et traitez après la réponse.

**Pourquoi un bind silencieux est-il plus difficile qu’un bind tombé ?**

Un bind tombé échoue de façon visible. Un bind silencieux paraît ouvert, donc le client continue d’envoyer jusqu’à ce qu’un timeout le révèle. Le keep-alive le trouve plus tôt.

## FAQ

**Peut-on utiliser les deux ?**

Oui. Beaucoup de plateformes envoient par SMPP et reçoivent des callbacks HTTP pendant la migration.

**Lequel est plus rapide à intégrer ?**

HTTP, souvent en une après-midi ; SMPP devient rentable quand le volume justifie une session persistante.

**Lequel est plus fiable ?**

Aucun ne l’est par lui-même. La fiabilité vient de la route, de la politique de reprise et de l’exploitation autour.

**HTTP peut-il tenir un fort volume ?**

Oui, avec de la concurrence, un pool de connexions et des callbacks asynchrones. SMPP est généralement plus efficace pour un flux soutenu, parce que la session et le canal des accusés sont déjà ouverts.

**Faut-il une IP fixe ?**

Souvent oui pour SMPP, car le fournisseur autorise l’IP du client. Les intégrations HTTP s’appuient plutôt sur TLS et une clé. Confirmez l’exigence avant de construire.

## Sources

- [smpp.org : sessions SMPP, opérations PDU et accusés de remise](https://smpp.org/) — Accessed: 2026-10-19
- [IETF RFC 9110 : sémantique de HTTP](https://datatracker.ietf.org/doc/html/rfc9110) — 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