--- title: "API SMS ou SMPP : quelle connexion choisir ?" description: "API SMS ou SMPP : sessions et binds, fenêtrage, débit, accusés de réception, encodage, sécurité TLS, charge d'exploitation et migration, comparés point par point." canonical: "https://omnichannels.ai/fr/blog/sms-api-vs-smpp/" language: "fr" updated: "2026-10-10" publisher: "BroadNet Technologies" brand: "OmniChannels.ai" category: "integration" primaryQuery: "sms api vs smpp" keywords: ["smpp vs api http", "api rest sms", "bind transceiver smpp", "fenêtrage smpp débit", "accusé de réception smpp deliver_sm", "smpp over tls", "migrer de http vers smpp", "protocole smpp 3.4"] published: "2026-10-10" author: "OmniChannels.ai Editorial Team" reviewer: "BroadNet Messaging Solutions Team" readingMinutes: 12 answer: "Utilisez une API SMS REST pour le trafic applicatif (OTP, alertes, notifications) et dès qu'il vous faut aussi WhatsApp, RCS ou d'autres canaux : c'est du HTTPS sans état, simple à sécuriser et rapide à intégrer. Optez pour SMPP si vous envoyez des volumes SMS élevés et soutenus, exploitez déjà des clients SMPP ou revendez du SMS : un bind persistant avec fenêtrage garde de nombreux messages en vol. Beaucoup d'entreprises combinent les deux sur un même compte." takeaways: ["Une API SMS REST envoie chaque message dans une requête HTTPS indépendante, alors que SMPP maintient une session longue durée, appelée bind, sur laquelle circulent des PDU binaires.", "Le débit SMPP dépend du fenêtrage : un client qui attend chaque submit_sm_resp avant d'envoyer le message suivant gaspille l'essentiel de la connexion.", "En REST, les statuts de livraison arrivent sur votre webhook ; en SMPP, les accusés de réception arrivent sous forme de PDU deliver_sm sur la même session et doivent chacun être acquittés.", "SMPP v3.4 ne prévoit aucun chiffrement natif : les binds de production doivent passer par TLS et partir d'adresses IP sources autorisées.", "SMPP ne transporte que du SMS : une architecture hybride, avec REST pour le trafic multicanal et SMPP pour le SMS en masse, est un choix courant sur la durée."] faq: - q: "SMPP est-il plus rapide qu'une API SMS ?" a: "SMPP peut soutenir un débit plus élevé, car une seule session persistante transporte de nombreux messages en vol sans nouvelle requête HTTP pour chacun. Pour un OTP isolé, la différence est rarement perceptible, puisque le délai de livraison côté opérateur domine. Sur les deux interfaces, le débit est fixé par les limites de votre compte : demandez à votre fournisseur ses limites documentées plutôt que de supposer que SMPP est toujours plus rapide." - q: "Peut-on envoyer des messages WhatsApp via SMPP ?" a: "Non. SMPP est un protocole dédié au SMS et aux services de messages courts associés. WhatsApp, RCS, Messenger, Instagram, l'e-mail et les notifications push passent par des API HTTP. Si vous avez besoin de plusieurs canaux, utilisez une API REST pour ceux-ci et n'ajoutez SMPP que pour le SMS à fort volume, si nécessaire." - q: "Qu'est-ce qu'un bind SMPP ?" a: "Un bind est une session SMPP authentifiée entre votre client, appelé ESME, et le SMSC du fournisseur. Vous ouvrez une connexion TCP ou TLS, puis envoyez bind_transmitter, bind_receiver ou bind_transceiver avec votre system_id et votre mot de passe. Un bind transceiver permet à la fois de soumettre des messages et de recevoir les accusés de réception sur une seule session : c'est le choix habituel." - q: "SMPP est-il sécurisé ?" a: "SMPP v3.4 ne chiffre pas lui-même le trafic, et les identifiants transitent dans la requête de bind. Faites passer les binds de production par TLS, limitez les connexions aux adresses IP sources enregistrées, stockez le system_id et le mot de passe comme des secrets et renouvelez-les en cas d'exposition. Évitez le SMPP en clair sur l'internet public." - q: "En quoi les accusés de réception diffèrent-ils entre SMPP et REST ?" a: "En SMPP, l'accusé arrive sous forme de PDU deliver_sm contenant un texte comme stat:DELIVRD, et votre client doit répondre par deliver_sm_resp. En REST, le fournisseur envoie un événement JSON à votre webhook avec un statut normalisé, par exemple DELIVERED ou FAILED. Dans les deux cas, le traitement est asynchrone : une soumission acceptée ne prouve jamais la livraison." - q: "Combien de temps faut-il pour passer d'une API SMS à SMPP ?" a: "Le code n'est pas l'étape la plus longue si vous utilisez une bibliothèque SMPP éprouvée. Le provisionnement prend davantage de temps : convenir du débit et du nombre de binds, enregistrer les IP sources, tester les accusés de réception et l'encodage. Prévoyez une période de fonctionnement en parallèle, avec une petite part du trafic sur SMPP, avant de basculer les volumes." sources: - title: "Short Message Peer to Peer Protocol Specification v3.4 (SMPP.org)" url: "https://smpp.org/SMPP_v3_4_Issue1_2.pdf" - title: "SMPP.org: Short Message Peer-to-Peer protocol resources" url: "https://smpp.org/" - title: "RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3" url: "https://www.rfc-editor.org/rfc/rfc8446" - title: "RFC 9110: HTTP Semantics" url: "https://www.rfc-editor.org/rfc/rfc9110" - title: "3GPP TS 23.040 : réalisation technique du service de messages courts (SMS)" url: "https://www.3gpp.org/dynareport?code=23040" --- # API SMS ou SMPP : quelle connexion choisir ? Canonical: https://omnichannels.ai/fr/blog/sms-api-vs-smpp/ Language: fr Publisher: OmniChannels.ai by BroadNet Technologies Ce guide s'adresse aux ingénieurs et responsables techniques qui doivent choisir comment se connecter à un fournisseur SMS : via une API SMS HTTP/REST, via SMPP, ou les deux. Il explique ce qui distingue réellement les deux approches, sur le réseau comme en exploitation, pour vous permettre de choisir la bonne interface pour chaque type de trafic et de planifier une migration si votre premier choix devient trop étroit. Pour une vue d'ensemble des modèles d'intégration, webhooks et idempotence compris, consultez notre [guide d'intégration d'une API de messagerie](/fr/blog/messaging-api-integration-guide/). ## Quelle est la différence entre une API SMS et SMPP ? Une API SMS REST envoie chaque message dans une requête HTTPS distincte et renvoie un identifiant de message. SMPP (Short Message Peer-to-Peer) maintient ouverte une session authentifiée de longue durée et y échange, dans les deux sens, des messages binaires appelés PDU. REST privilégie la simplicité ; SMPP privilégie les volumes SMS soutenus. | | API SMS REST | SMPP v3.4 | |---|---|---| | Transport | Requête et réponse HTTPS | Session TCP persistante, encapsulée dans TLS en production | | État | Sans état ; chaque requête est autonome | Bind avec état, numéros de séquence et keep-alive | | Authentification | Jeton Bearer dans un en-tête | `system_id` et mot de passe dans le bind, plus liste blanche d'IP | | Canaux | SMS et, avec une API multicanale, WhatsApp, RCS et d'autres | SMS uniquement | | Modèle de débit | Requêtes par seconde, plus des endpoints d'envoi en masse | Messages par seconde et par bind, nombreux en vol grâce au fenêtrage | | Accusés de réception | Webhook JSON avec statuts normalisés | PDU `deliver_sm` sur la session, format texte | | Encodage | Un champ comme `messageType` (`TEXT` ou `UNICODE`) | `data_coding` (0 pour GSM-7, 8 pour UCS-2), UDH pour les messages longs | | Outillage | N'importe quel client HTTP, SDK, OpenAPI | Une bibliothèque cliente SMPP | | Charge d'exploitation | Faible | Modérée : connexions, reconnexion, fenêtres, accusés | | Idéal pour | Applications, OTP, notifications, multicanal | Agrégateurs, revendeurs, gros expéditeurs rompus à SMPP | ## Comment fonctionne une API SMS REST ? Vous envoyez un `POST` HTTPS avec un jeton et un corps JSON, et le fournisseur répond par un identifiant. Chaque requête est indépendante : vous pouvez envoyer depuis n'importe quel serveur, fonction ou conteneur sans gérer de connexion. Un envoi type avec notre API ressemble à ceci : ```bash curl -X POST https://api.broadnet.me/sms/sendSms \ -H "Authorization: Bearer $BROADNET_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "senderId": "OmniDemo", "destinationNumber": "971500000000", "message": "Your OmniDemo code is 482913", "messageType": "TEXT" }' ``` La réponse est un `200 OK` avec l'identifiant du message en texte brut. Le statut final arrive ensuite sur votre webhook : SUBMITTED, SENT, DELIVERED, FAILED ou REJECTED. Les noms de champs et les options figurent dans la [référence de l'API SMS](/developers/sms/). Les points forts de REST : - **Un outillage familier** : n'importe quel langage, n'importe quel client HTTP, des codes de statut standard définis par la RFC 9110. - **Une sécurité simple** : TLS partout et un jeton dans l'en-tête `Authorization`. - **De l'envoi en masse sans connexion** : vous chargez un fichier de destinataires en une requête au lieu d'ouvrir une session. - **Une seule API pour plusieurs canaux** : le même schéma envoie des modèles WhatsApp ou des cartes RCS. Les limites de REST : chaque message, ou chaque lot, coûte un aller-retour HTTP, et vous atteindrez une limite de requêtes par seconde bien avant une limite opérateur. Pour la plupart du trafic applicatif, cela ne pose jamais problème. ## Comment fonctionne SMPP ? SMPP est un protocole binaire défini par la spécification SMPP v3.4, publiée par le SMPP Developers Forum (devenu ensuite le SMS Forum) et qui reste la version la plus déployée. Votre système, appelé ESME (External Short Message Entity), se connecte au SMSC (Short Message Service Centre) du fournisseur et ouvre une session appelée bind. ### Types de bind - **Transmitter (TX)**, via `bind_transmitter` : soumission de messages uniquement. - **Receiver (RX)**, via `bind_receiver` : réception des accusés de réception et des messages entrants uniquement. - **Transceiver (TRX)**, via `bind_transceiver` : les deux sur une seule session. C'est le choix habituel. ### Cycle de vie d'une session 1. Ouvrez une connexion TLS vers l'hôte et le port communiqués par votre fournisseur. 2. Envoyez `bind_transceiver` avec votre `system_id` et votre mot de passe, puis attendez une réponse avec `command_status` à 0. 3. Envoyez les messages avec `submit_sm`. Chaque `submit_sm_resp` renvoie un `message_id`. 4. Recevez les accusés de réception sous forme de `deliver_sm` et répondez à chacun par `deliver_sm_resp`. 5. Envoyez régulièrement `enquire_link` pendant les périodes d'inactivité pour que chaque partie sache que la session est vivante. 6. Fermez avec `unbind` et attendez `unbind_resp`. Chaque PDU porte un numéro de séquence, repris à l'identique dans la réponse : c'est ainsi que vous associez un `submit_sm_resp` au message envoyé. Notre [documentation SMPP](/developers/smpp/) détaille chaque étape avec nos paramètres. ## Qu'est-ce que le fenêtrage SMPP et pourquoi compte-t-il ? Le fenêtrage consiste à envoyer plusieurs PDU `submit_sm` avant d'avoir reçu leurs réponses. Le nombre de PDU non acquittées autorisées en vol constitue la fenêtre. C'est la principale raison pour laquelle SMPP soutient un débit supérieur à un HTTP qui traite une requête à la fois. Avec une fenêtre de 1, votre client envoie un message, attend un aller-retour complet pour la réponse, puis envoie le suivant. Le débit est alors plafonné par la latence réseau, pas par le débit convenu. Avec une fenêtre plus large, la connexion reste occupée pendant que les réponses arrivent. Quelques règles empiriques : - **Utilisez la taille de fenêtre convenue avec votre fournisseur** et ne la dépassez jamais ; les PDU en excès peuvent être rejetées. - **Respectez le débit convenu par bind.** Si vous recevez `ESME_RTHROTTLED`, ralentissez et réessayez avec un backoff. - **Suivez les numéros de séquence en attente** pour qu'une déconnexion ne vous fasse pas perdre la trace des messages acceptés. - **Montez en charge en ajoutant des binds**, dans la limite du nombre convenu pour votre compte, plutôt qu'en élargissant sans cesse la fenêtre. Les limites par défaut de notre API REST et de nos binds SMPP figurent dans [errors and limits](/developers/errors-and-limits/) ; les limites de votre compte sont confirmées lors du provisionnement de l'accès. ## En quoi les accusés de réception diffèrent-ils ? En REST, le fournisseur envoie un événement JSON à votre [webhook](/developers/webhooks/). En SMPP, l'accusé arrive sous forme de PDU `deliver_sm` sur la session, avec le bit d'accusé de réception positionné dans `esm_class`. Les deux sont asynchrones : ni un `200 OK` ni un `submit_sm_resp` ne signifient que le mobile a reçu le message. La spécification SMPP v3.4 donne le format texte de l'accusé à titre d'exemple et laisse le format exact au fabricant du SMSC, mais la plupart des fournisseurs le suivent : ```text id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code ``` Si vos systèmes consomment les deux interfaces, ramenez les états SMPP à un modèle de statuts unique. Une correspondance type : | `stat` SMPP | Signification | Statut normalisé | |---|---|---| | `ACCEPTD` | Accepté, état intermédiaire | SENT | | `DELIVRD` | Livré au mobile | DELIVERED | | `UNDELIV` | Non livrable | FAILED | | `EXPIRED` | Période de validité écoulée | FAILED | | `REJECTD` | Rejeté, par exemple expéditeur bloqué | REJECTED | | `DELETED` | Supprimé avant livraison | FAILED | | `UNKNOWN` | Aucune information d'état | Conserver le dernier statut connu | Deux différences pratiques comptent davantage que le format : - **L'acquittement.** Un client SMPP doit répondre à chaque `deliver_sm`. Les accusés non acquittés sont renvoyés et peuvent ralentir le bind. Un gestionnaire de webhook doit, pour la même raison, répondre rapidement par un `2xx`. - **La reprise.** Si votre client SMPP est déconnecté, les accusés attendent le bind suivant ou peuvent expirer dans la file du fournisseur. En REST, un fournisseur peut proposer de renvoyer les accusés sur une plage de dates. Demandez comment chacun fonctionne. Pour comprendre la signification de chaque statut, lisez [les statuts de livraison des messages expliqués](/fr/blog/message-delivery-status-explained/). ## Comment l'encodage est-il géré ? Les deux interfaces doivent choisir entre GSM-7 et Unicode, et toutes deux découpent les messages longs en segments. La différence tient à qui fait le travail. - **REST :** vous renseignez un champ comme `messageType` à `TEXT` ou `UNICODE`, et la plateforme segmente les messages longs. Notre API propose aussi `POST /sms/identify` pour compter au préalable les caractères et les segments. - **SMPP :** vous renseignez `data_coding` (0 pour l'alphabet GSM-7 par défaut, 8 pour UCS-2) et encodez vous-même les octets. Pour les messages longs, vous ajoutez soit un User Data Header à chaque partie en positionnant `esm_class` à 0x40, soit vous envoyez le texte complet dans le champ `message_payload` si votre fournisseur l'active. Selon la 3GPP TS 23.040, un SMS unique transporte 140 octets : 160 caractères GSM-7 ou 70 caractères UCS-2, ramenés à 153 ou 67 par partie lorsque l'en-tête est ajouté. Une seule lettre arabe ou un seul emoji fait passer tout le message en Unicode. Les erreurs d'encodage sont le défaut d'intégration SMPP le plus fréquent : testez avec de l'arabe, des emoji et des textes longs. Voir notre [guide des limites de caractères](/fr/blog/sms-character-limits-unicode-arabic/). ## Comment se comparent les modèles de sécurité ? REST s'appuie sur TLS et sur un jeton Bearer à chaque requête. SMPP v3.4 n'a pas de chiffrement propre et transmet les identifiants dans le bind : il dépend donc du transport et des contrôles réseau qui l'entourent. Pour SMPP : - **Utilisez TLS** (TLS 1.3 est défini par la RFC 8446) ou une liaison privée ; jamais de SMPP en clair sur l'internet public. - **Enregistrez les adresses IP sources** pour que seuls vos serveurs puissent établir un bind. - **Stockez le `system_id` et le mot de passe comme des secrets**, distincts par environnement, et renouvelez-les en cas d'exposition. - **Surveillez les échecs de bind**, qui peuvent révéler une erreur de configuration ou un usage abusif des identifiants. Pour REST : - **Gardez le jeton uniquement côté serveur**, jamais dans une application mobile ni dans du code navigateur. - **Évitez les anciennes interfaces HTTP** qui passent un identifiant et un mot de passe dans l'URL, où ils finissent dans les journaux. - **Protégez le webhook** avec HTTPS, un chemin impossible à deviner et une validation stricte du corps de requête. ## Que vous coûte chaque option en exploitation ? REST n'ajoute quasiment aucune charge d'exploitation : une requête réussit ou renvoie une erreur que vous pouvez réessayer. SMPP ajoute un composant permanent qu'il faut surveiller et maintenir. Un client SMPP doit gérer : 1. les connexions, avec une reconnexion par backoff et jitter plutôt qu'une boucle serrée ; 2. les keep-alive et la détection des connexions silencieuses à moitié ouvertes ; 3. le contrôle de la fenêtre et du débit par bind ; 4. le suivi des séquences et la réconciliation après déconnexion ; 5. l'acquittement et le stockage des accusés de réception ; 6. la logique d'encodage et de concaténation ; 7. la supervision de l'état des binds, du débit, des erreurs de throttling et du retard des accusés. Des bibliothèques open source éprouvées gèrent le protocole, mais votre équipe reste responsable du comportement autour, y compris pendant une fenêtre de maintenance du fournisseur à 3 heures du matin. ## Quand utiliser chacune ? Utilisez REST, sauf si vous avez une raison claire d'ajouter SMPP. ### Choisissez une API SMS REST si - vous envoyez des OTP, des alertes, des notifications ou des campagnes depuis des applications ; - vous avez besoin de WhatsApp, de RCS ou d'autres canaux en plus du SMS ; - votre plateforme tourne sur des fonctions serverless ou des conteneurs éphémères ; - votre équipe n'a ni expérience de SMPP ni besoin de l'acquérir. ### Choisissez SMPP si - vous envoyez des volumes SMS élevés et soutenus et avez atteint les limites de REST ; - vous exploitez déjà une passerelle SMPP ou une plateforme de messagerie ; - vous êtes agrégateur, opérateur ou revendeur et raccordez le trafic SMS de vos propres clients ; - vous avez besoin du même protocole avec plusieurs fournisseurs amont. ## À quoi ressemble une architecture hybride ? Beaucoup d'entreprises utilisent les deux sur un même compte : REST pour le trafic multicanal et applicatif, SMPP pour le SMS en masse. Le piège est de se retrouver avec deux modèles de livraison. - **Routez par cas d'usage**, pas au hasard : par exemple, OTP et WhatsApp en REST, relevés SMS en masse en SMPP. - **Normalisez les statuts** issus des webhooks et des `deliver_sm` dans une seule table indexée par identifiant de message. - **Appliquez une seule politique d'identifiants d'expéditeur (Sender ID)** aux deux, car les enregistrements s'appliquent quelle que soit l'interface. - **Produisez des rapports communs**, pour qu'une campagne répartie sur les deux interfaces affiche un résultat unique. ## Comment migrer d'une API SMS vers SMPP ? Avancez progressivement, avec les deux interfaces actives, et mesurez avant de déplacer les volumes. 1. **Confirmez le besoin** : documentez le volume ou le débit que REST ne couvre pas. 2. **Demandez le provisionnement** : communiquez les pays de destination, les identifiants d'expéditeur, le débit de pointe attendu et les adresses IP sources. 3. **Choisissez une bibliothèque cliente éprouvée** dans votre stack et encapsulez-la dans votre propre interface d'envoi. 4. **Construisez d'abord la gestion des accusés**, alignée sur le même modèle de statuts que vos webhooks. 5. **Testez l'encodage** : GSM-7, arabe, emoji et messages multi-parties sur de vrais mobiles. 6. **Testez les pannes** : coupez la connexion en plein envoi, déclenchez le throttling et vérifiez la réconciliation. 7. **Faites tourner en parallèle** : basculez une petite part d'un type de trafic sur SMPP et comparez livraison et accusés. 8. **Déplacez les volumes par paliers**, en gardant REST comme voie de repli. Voici une configuration de bind indicative. L'hôte, le port et les limites sont des valeurs fictives ; les valeurs réelles accompagnent vos identifiants provisionnés. ```text host: port: bind type: transceiver system_id: password: system_type: (vide sauf indication contraire) interface_version: 0x34 source_addr_ton/npi: 5 / 0 (identifiant d'expéditeur alphanumérique) dest_addr_ton/npi: 1 / 1 (numéro international) registered_delivery: 1 (demander les accusés de réception) data_coding: 0 (GSM-7) or 8 (UCS-2) enquire_link: every 30 seconds while idle window: as agreed for your account ``` ## Exemple concret : un distributeur régional ajoute SMPP pour ses relevés « Souq Rafiq » (entreprise fictive), un e-commerçant présent aux Émirats arabes unis, en Égypte et en Jordanie, envoie ses OTP et ses mises à jour de commande via une API REST, et ses modèles WhatsApp via la même API. Les relevés de compte mensuels, envoyés par SMS à toute sa base clients, ont pris une telle ampleur que la tâche REST dure plus longtemps que l'entreprise ne le souhaite. - **Décision :** conserver les OTP, les mises à jour de commande et WhatsApp en REST. Basculer les SMS de relevé mensuel sur un bind SMPP transceiver. - **Provisionnement :** l'équipe enregistre deux IP sources, confirme les identifiants d'expéditeur par pays et convient du débit et du nombre de binds. - **Développement :** un petit service SMPP s'appuie sur une bibliothèque open source, écrit les accusés dans la même table de statuts que le webhook et expose la même interface d'envoi interne que la voie REST. - **Tests :** les relevés en arabe sont validés en UCS-2, avec une concaténation correcte sur plusieurs mobiles. - **Déploiement :** un premier pays bascule. Après comparaison de la livraison et des délais d'accusés avec la référence REST, les autres pays suivent, REST restant la voie de repli. ## Erreurs fréquentes - **Choisir SMPP par prestige.** Si REST couvre votre volume, SMPP ne fait qu'ajouter du travail. - **Fonctionner avec une fenêtre de 1**, puis reprocher au fournisseur un débit trop faible. - **Ne pas acquitter les `deliver_sm`**, ce qui provoque des renvois d'accusés et du throttling. - **Se reconnecter en boucle serrée** après une déconnexion, ce qui peut ressembler à une attaque. - **Mélanger `short_message` et `message_payload`** dans une même PDU, ce qui provoque des erreurs de longueur. - **Faire passer du SMPP en clair sur internet**, en exposant identifiants et contenus. - **Garder deux modèles de statuts** dans une architecture hybride, si bien que les rapports divergent. - **Limites :** ce guide décrit les pratiques courantes. Tailles de fenêtre, débits, ports TLS et détails des accusés varient selon le fournisseur et le compte ; faites-les confirmer lors du provisionnement. ## Comment OmniChannels.ai vous aide OmniChannels.ai propose les deux. L'API REST à l'adresse `https://api.broadnet.me` utilise un jeton Bearer et couvre le SMS aux côtés de WhatsApp, RCS, Messenger, Instagram, Telegram, E-mail et Push, avec des statuts de livraison poussés vers votre webhook dans un format unique. Pour le SMS à fort volume, des binds SMPP 3.4 sur TLS sont provisionnés par compte, avec liste blanche d'IP sources, et empruntent les mêmes routes SMS via la connectivité opérateur directe de BroadNet. Les revendeurs et partenaires wholesale peuvent disposer de binds dédiés. Commencez par la [documentation SMPP](/developers/smpp/) ou le [quickstart](/developers/quickstart/), ou consultez la [présentation développeurs](/developers/).