SMPP contre API HTTP SMSC : laquelle votre plateforme doit-elle parler ?

Lorsque vous connectez une plateforme de messagerie au monde extérieur, vous choisissez en réalité comment elle dialogue avec les opérateurs, et deux réponses dominent l’usage. L’une est SMPP, le protocole binaire des télécoms qui achemine depuis des décennies le SMS application vers personne (A2P). L’autre est une API HTTP, la même logique de requête et de réponse qui alimente le reste du web. Ce ne sont pas tant des rivaux que des outils pour des tâches différentes, et la conclusion honnête, vers laquelle mène ce guide, est que tout ce que vous appelleriez une plateforme sérieuse finit par parler les deux. Voici ce qui les sépare vraiment, et pourquoi.

Qu’est-ce que SMPP, et pourquoi les opérateurs l’utilisent encore

SMPP, pour Short Message Peer-to-Peer, est un protocole binaire parlé sur une connexion TCP de longue durée, par convention sur le port 2775. Au lieu d’ouvrir une connexion neuve par message, comme le fait une requête web, un client SMPP établit une session persistante appelée bind, dans l’un de trois modes : transmitter (envoi seul), receiver (réception seule) ou transceiver (les deux sur une connexion). Une fois lié, il transmet en flux des paquets binaires compacts appelés PDU : un submit_sm pour envoyer un message, un deliver_sm pour en recevoir un ou un accusé de réception, un enquire_link en guise de battement (heartbeat) pour garder la session vivante.

La raison pour laquelle opérateurs et grands agrégateurs se standardisent encore sur SMPP tient à l’efficacité à grand volume. Un bind persistant supprime le surcoût d’ouverture de connexion à chaque message, et SMPP gère le fenêtrage (windowing) : l’émetteur peut mettre plusieurs messages en transit avant d’attendre les acquittements, si bien qu’un seul bind en bonne santé soutient de plusieurs centaines à quelques milliers de messages par seconde. Il est en outre taillé pour le domaine, avec des champs natifs pour le sender ID, l’encodage des données, les périodes de validité, l’envoi programmé et les indicateurs de livraison enregistrée. Quand votre trafic se mesure en millions de messages par jour, cette densité et ce contrôle ne sont pas un luxe : c’est la différence entre un serveur et dix.

Le prix d’une telle puissance est la complexité. SMPP conserve l’état, vous devez donc gérer les bind, vous reconnecter en cas de coupure, répondre aux battements, respecter la fenêtre et corréler les accusés asynchrones par l’ID du message. Il tend aussi à exiger une relation d’IP stable, et c’est pourquoi les bind avec les opérateurs se placent souvent derrière une allowlist d’IP ou un petit VPN, plutôt que sur l’internet ouvert.

Où s’inscrivent les API HTTP SMSC

Une API HTTP fait l’échange inverse. Vous envoyez une requête par message (ou par petit lot) vers une URL, vous recevez en retour une réponse JSON ou de formulaire, et il n’y a aucune session à maintenir. L’authentification est un jeton ou une clé dans un en-tête, les accusés de réception reviennent comme des appels webhook vers une URL que vous hébergez, et le tout traverse pare-feu et répartiteurs de charge ordinaires sans traitement particulier. Pour un développeur, câbler un fournisseur HTTP est l’affaire d’un après-midi ; câbler une pile SMPP est un projet.

C’est justement cette simplicité qui a multiplié les fournisseurs HTTP. Quantité de fournisseurs régionaux, d’agrégateurs WhatsApp et RCS, et d’entrants CPaaS plus récents exposent d’abord le HTTP et le SMPP seulement sur demande, voire pas du tout. Pour des volumes faibles et moyens, ou pour un pays que vous atteignez via un unique fournisseur spécialisé, une route HTTP n’est pas un compromis au rabais : c’est le choix raisonnable. Le surcoût par message est plus élevé et le plafond brut de débit plus bas qu’un bind SMPP bien réglé, mais on le met à l’échelle de façon ennuyeuse, à l’horizontale, en faisant plus de requêtes simultanées ; et pour la plupart des revendeurs, ce plafond dépasse de loin le trafic réel.

La limite honnête est le contrôle et la cohérence. Chaque fournisseur HTTP invente ses propres noms de champs, sa propre manière d’exprimer l’Unicode et les messages longs, et son propre format d’appel DLR. Parlez à cinq fournisseurs HTTP et vous aurez, de fait, intégré cinq produits légèrement différents.

Les vraies différences : débit, DLR et encodage

Trois détails techniques causent presque toute la douleur concrète, il vaut donc la peine d’être précis.

Débit et contrôle de flux. Le débit SMPP est gouverné par la taille de la fenêtre et la latence aller-retour : avec une fenêtre de, disons, 10 PDU non acquittées et un lien rapide, un bind pousse beaucoup de trafic, et les opérateurs imposent un débit contractuel que vous ne devez pas dépasser, sous peine de throttling. Le débit HTTP est gouverné par le nombre de requêtes simultanées que vous faites et par la limite de débit (rate limit) du fournisseur, généralement exprimée en requêtes par seconde. Conséquence pratique : SMPP récompense un petit nombre de connexions persistantes bien gérées, tandis que HTTP récompense un pool de workers qui font des appels en parallèle. La conception de la file d’attente et des workers de votre plateforme change en conséquence.

Accusés de réception. C’est là que les intégrations naïves se brisent. En SMPP, le DLR n’est pas une réponse à votre submit ; il arrive plus tard, sans être sollicité, sous forme de deliver_sm sur votre bind, et vous devez le rattacher au message d’origine par l’ID que l’opérateur a attribué à l’envoi. Si vous n’êtes pas à l’écoute, ou si vous perdez le bind, vous perdez les accusés. En HTTP, le DLR est un appel que le fournisseur envoie en POST vers votre webhook, ce qui signifie que votre point de terminaison doit être joignable, idempotent (les fournisseurs réessaient) et capable de corréler sur votre propre référence. Même notion, livré, échoué, expiré, rejeté, inconnu, mais deux mécanismes totalement différents à capturer de façon fiable.

Encodage des caractères. Le SMS est impitoyable ici. L’alphabet GSM 03.38 fait tenir 160 caractères dans un seul message sur 7 bits ; sortez-en (un emoji, beaucoup de caractères accentués ou non latins) et le message passe en UCS-2, qui n’en contient que 70 par partie. Les textes plus longs sont découpés en segments cousus par un en-tête de données utilisateur (UDH), et chaque segment est facturé. SMPP expose tout cela directement via le champ data_coding et attend de vous que vous fassiez les choses correctement. Les fournisseurs HTTP tentent d’ordinaire de l’abstraire, mais le font de façon incohérente, et un fournisseur qui rétrograde en silence un message Unicode ou compte mal les segments vous coûtera de l’argent sans le dire ou vous abîmera le texte. Quel que soit le protocole, l’encodage est une chose que votre plateforme doit gérer délibérément, non espérer que le fournisseur la réussisse.

Pourquoi une plateforme sérieuse parle les deux

Rassemblez ces différences et la conclusion s’écrit d’elle-même. Votre meilleure route vers un pays peut être un bind SMPP avec un opérateur national ; l’unique route vers le suivant peut être un spécialiste HTTP ; le secours pour les deux peut être un troisième fournisseur, sur le protocole qu’il se trouve proposer. Si votre plateforme ne sait parler qu’un seul, vos choix de routage sont réduits de moitié et vos négociations avec les fournisseurs restent otages d’une limite technique, au lieu d’être guidées par le prix et la qualité de livraison.

C’est pourquoi une passerelle mature fait tourner une pile SMPP et un client HTTP côte à côte, et expose en général les deux à ses propres clients aussi : un serveur SMPP auquel les clients techniques se lient, et une API HTTP pour tous les autres. La vraie valeur de la plateforme n’est aucun des deux protocoles : c’est la couche au-dessus d’eux, le moteur de routage, la facturation, la normalisation des accusés de réception, qui rend le choix du protocole invisible pour celui qui envoie un message. Une plateforme auto-hébergée comme Smppcube embarque à la fois un serveur SMPP de niveau opérateur et une API HTTP, précisément pour que ce soit l’opérateur, non le protocole, qui décide comment circule le trafic. Si vous pesez l’idée d’exploiter cette pile vous-même, le guide de la passerelle auto-hébergée couvre le versant opérationnel.

Un adaptateur HTTP générique unique pour les fournisseurs (comment ça marche vraiment)

Le piège des fournisseurs HTTP, à savoir que chacun est subtilement différent, a une solution, et cette solution est un motif qu’il vaut la peine de comprendre avant d’acheter ou de construire. Plutôt que d’écrire du code sur mesure pour chaque fournisseur, éparpillé dans la base de code, vous définissez une seule interface interne, une unique forme normalisée pour envoie un message et voici un accusé de réception, puis vous écrivez un adaptateur mince par fournisseur qui traduit entre les bizarreries du fournisseur et cette forme interne.

Chaque adaptateur possède exactement les différences : comment ce fournisseur s’authentifie, comment il nomme les champs de destination et de texte, comment il veut que l’Unicode soit signalé, et comment interpréter son appel DLR particulier vers l’ensemble commun de statuts de la plateforme. Tout ce qui se trouve en amont, la file d’attente, le routeur, la facturation, les rapports, ne parle qu’à l’interface interne et ne sait ni ne se soucie de quel fournisseur se cache derrière. Intégrer un nouveau fournisseur HTTP devient alors une configuration et un petit adaptateur, non une réécriture ; et ajouter plus tard des fournisseurs de voix par API suit exactement le même motif. C’est ainsi qu’une plateforme reste ouverte à des dizaines de fournisseurs régionaux sans s’effondrer sous leurs incohérences, et c’est la conception qu’une passerelle auto-hébergée devrait déjà mettre en œuvre, pour que vous ne touchiez jamais au code de protocole afin d’ajouter une route.

Lequel choisir ?

Si vous êtes un revendeur qui câble son premier fournisseur et que celui-ci propose du HTTP, commencez par là : c’est plus rapide à intégrer, facile à tester, et suffisant pour prouver votre activité. Ajoutez SMPP quand le volume, une relation avec un opérateur, ou un client technique qui veut se lier à vous rendent la machinerie supplémentaire justifiée. Si vous êtes un agrégateur ou un opérateur qui traite des volumes sérieux et des accords directs avec les carriers, SMPP n’est pas facultatif : c’est la langue que parlent vos fournisseurs.

Le contrepoint honnête à tout cela : ne choisissez pas de protocole du tout, si vous pouvez l’éviter. Choisissez une plateforme qui parle déjà les deux et en masque la différence, pour que votre énergie aille à la qualité des routes et aux clients, plutôt qu’à maintenir une pile de protocole binaire. C’est tout l’intérêt d’acheter une passerelle plutôt que d’en construire une, et vous pouvez voir où se situe une option auto-hébergée, en pleine propriété, sur la page des tarifs. Le protocole devrait être un détail que vous configurez, jamais un mur contre lequel vous bâtissez votre activité.