Comptes SMPP pour vos clients : binds, TPS, DLR et facturation

Dès qu’un client technique demande « puis-je me lier en SMPP ? », votre plateforme cesse d’être un panneau web et devient, à ses yeux, un opérateur. Les comptes SMPP pour clients sont la fonctionnalité qui permet de remporter les banques, les fournisseurs d’OTP, les autres agrégateurs et tout développeur qui possède déjà une bibliothèque cliente SMPP. C’est aussi là qu’une configuration négligée fait le plus de dégâts : un client sans plafond de débit, un bind receiver que personne n’a configuré, des accusés de réception qui ne vont nulle part, un grand livre que le bind contourne. Ce guide est la liste de contrôle pour bien faire les choses, du bind que vous émettez jusqu’au test que vous menez avant de dire au client de passer en production.

Ce que sont réellement les comptes SMPP pour clients

Via l’API HTTP, un client envoie une requête par message et reçoit une réponse. En SMPP, le client ouvre une session TCP de longue durée vers votre serveur SMPP, s’authentifie une seule fois avec un system_id et un mot de passe, et transmet ses messages en flux sur cette session sous forme de paquets binaires appelés PDU. Votre plateforme doit faire tourner un serveur SMPP (celui de Smppcube écoute sur le port 2775 et figure sur la page Plateforme), accepter le bind, valider chaque submit_sm par rapport au compte du client, le placer dans la même chaîne de traitement que celle qu’alimente l’API HTTP, puis renvoyer plus tard l’accusé de réception sur la session sous forme de deliver_sm.

Un compte SMPP n’est donc pas un produit distinct doté de sa propre facturation. C’est un jeu d’identifiants rattaché à un compte client existant, plus un ensemble de limites : quels modes de bind, depuis quelles IP, combien de sessions, à quelle vitesse. Les identifiants sont la petite partie. Les limites sont le compte.

Types de bind et ce qu’il faut autoriser

SMPP définit trois modes de bind, et la configuration du compte doit indiquer ceux que le client peut utiliser :

• Transmitter : envoi seul. Le client soumet des messages et reçoit les réponses de soumission (l’ID du message), mais rien d’autre. C’est simple, et c’est la raison pour laquelle des accusés de réception se perdent, car un transmitter n’a aucun canal pour un deliver_sm.
• Receiver : réception seule. Le client reçoit les accusés de réception et les messages entrants (les réponses d’origine mobile, si vous lui en acheminez) et ne peut pas envoyer.
• Transceiver : les deux sur une seule session. C’est ce que la plupart des bibliothèques clientes modernes ouvrent par défaut et ce que vous devriez recommander, car une seule session transporte ensemble les envois et les accusés, et il n’y a rien à mal apparier.

Le schéma traditionnel d’un bind transmitter plus un bind receiver existe toujours, généralement parce qu’une pile cliente plus ancienne a été écrite ainsi. Autorisez-le, mais comptez-le comme deux sessions dans la limite du compte, et assurez-vous que le bind receiver est réellement ouvert avant de supposer que les accusés sont livrés.

Les limites de sessions comptent plus qu’on ne le pense. Un client qui ouvre dix binds transceiver « pour la redondance » occupe dix emplacements de la table de connexions de votre serveur et peut pousser dix fois le débit que vous aviez prévu. Deux à quatre sessions par compte constituent un réglage par défaut raisonnable ; un client qui en veut davantage est un client qui devrait passer à une offre supérieure.

Débit, fenêtres et throttling

En SMPP, le débit dépend de deux choses : le nombre de PDU que le client peut avoir en transit avant d’attendre les acquittements (la fenêtre), et le débit que vous autorisez. Le guide SMPP contre HTTP explique pourquoi un seul bind bien géré peut pousser des centaines de messages par seconde ; ce qui compte ici, c’est que sur votre plateforme, c’est vous qui encaissez cette poussée.

Donnez à chaque compte SMPP un plafond en messages par seconde qui découle du contrat, et non de ce que votre serveur pourrait faire. Un client qui paie pour 10 msg/s obtient 10 msg/s ; quand il dépasse ce seuil, répondez par l’erreur de throttling que définit le protocole (ESME_RTHROTTLED) plutôt que de mettre discrètement l’excédent en file d’attente. Une bibliothèque cliente bien écrite traite cette erreur comme un signal pour ralentir et réduit son rythme. Une bibliothèque mal écrite continue de marteler, et votre serveur doit alors couper le bind après des infractions répétées et en consigner la raison, faute de quoi la boucle de nouvelles tentatives mal configurée d’un seul client devient la latence de tout le monde.

Deux autres chiffres ont leur place sur le compte. Une taille de fenêtre (10 à 20 PDU non acquittées est une valeur typique pour un bind exposé aux clients ; les opérateurs en amont peuvent en autoriser davantage) et un intervalle d’enquire_link, le battement (heartbeat) qui maintient en vie une session inactive. Communiquez les trois au client lorsque vous émettez les identifiants. Le ticket « SMPP ne fonctionne pas » le plus fréquent vient d’une bibliothèque cliente configurée pour une fenêtre que votre serveur n’accorde pas, qui expire à chaque dixième message et le signale comme une panne de la plateforme.

Où vont les accusés de réception

Un accusé de réception (DLR) en SMPP n’est pas une réponse à la soumission du client. Il arrive plus tard, sans avoir été sollicité, sous forme de deliver_sm sur le bind receiver ou transceiver du client, et le client le rattache au message d’origine grâce à l’ID de message que votre serveur a renvoyé lors de la soumission. Trois conséquences en découlent.

Premièrement, l’accusé doit avoir un endroit où aller. Si le client est lié uniquement en transmitter et qu’aucun bind receiver n’est ouvert, l’accusé n’a aucun chemin. Décidez de la politique à l’avance : exiger des binds transceiver, conserver les accusés pendant un court délai jusqu’à ce qu’un bind receiver apparaisse, ou proposer un webhook comme canal des accusés pour les clients qui ne peuvent pas exploiter de receiver. Jeter les accusés en silence est la seule option qui vous reviendra sous forme de litige.

Deuxièmement, l’accusé est à vous avant d’être à lui. Votre plateforme a besoin de l’accusé de l’opérateur pour solder le message dans le grand livre, pour afficher le statut dans la console du client et pour alimenter vos propres rapports de qualité de livraison par route. Stockez-le, mettez à jour le message, puis transmettez-le. Une conception qui se contente de relayer les accusés vers le bind sans rien garder est une conception sans réponse lorsque le client dit « vous m’avez facturé 4 000 messages qui ne sont jamais arrivés ».

Troisièmement, les accusés arrivent à peu près au rythme des envois, et les accusés d’une campagne arrivent après la campagne. Un client qui envoie 50 000 messages en cinq minutes recevra 50 000 paquets deliver_sm au cours des dix minutes suivantes. Si son bind receiver tarde à acquitter, votre file sortante d’accusés grossit ; faites-en une file dont la profondeur est visible plutôt qu’un tampon illimité, et déclenchez une alerte sur l’ancienneté, afin qu’un bind client bloqué apparaisse sur votre tableau de bord avant que le client n’ouvre un ticket.

Sender ID, encodage et les erreurs fréquentes des clients

Un compte SMPP a aussi besoin d’un règlement. Quelles adresses source (identifiants d’expéditeur, ou sender ID) le client peut-il utiliser, alphanumériques ou numériques, et votre serveur réécrit-il ou rejette-t-il un sender ID inconnu ? Quels codages de données (GSM 7-bit ou UCS-2 pour les écritures non latines), et comment les messages longs sont-ils découpés (concaténation UDH, que la bibliothèque du client gère généralement, mais pas toujours) ? Quelle période de validité et quel indicateur registered delivery exigez-vous pour que les accusés soient tout simplement demandés ?

Ces règles doivent résider sur le compte et être appliquées au moment de la soumission, en renvoyant un code d’erreur clair, plutôt que d’être acceptées puis d’échouer en silence chez l’opérateur. De même qu’une bonne API HTTP renvoie un 400 accompagné d’une raison, un bon serveur SMPP rejette le submit_sm avec le bon statut et laisse le client corriger de son côté. Chaque règle appliquée à votre périphérie est un litige que vous n’aurez pas plus tard.

Facturation par bind : c’est le compte qui détient le grand livre

C’est la partie qui déraille quand le serveur SMPP est greffé à côté de la plateforme au lieu d’y être intégré. Un message qui entre par SMPP doit être tarifé et débité exactement comme un message qui entre par la console ou par l’API HTTP : même plan tarifaire, même solde, même marge enregistrée sur la même route. Les trois modes de facturation du guide de la facturation (CreditRoute, WalletRoute et AutoRoute) s’appliquent au compte, et le bind en hérite. Quand le solde atteint zéro, le serveur SMPP doit rejeter la soumission avec une erreur appropriée plutôt que d’accepter du trafic dans une file d’attente qui ne sera jamais payée.

Un bind SMPP est une porte vers le compte du client, pas un compte distinct. Si le grand livre ne voit pas la porte, la porte est une fuite.

Là où SMPP justifie sa propre ligne commerciale, c’est dans l’offre qui entoure le bind : un engagement mensuel minimal en échange d’un plafond de débit plus élevé, des frais par session supplémentaire, un supplément pour une route dédiée ou un code court. Tarifez ces éléments comme des conditions du compte, afin que le grand livre enregistre les frais et le trafic sur le même relevé, et qu’un client qui passe de HTTP à SMPP voie une seule facture avec une ligne de plus, et non une nouvelle relation.

Intégration d’un client : le dossier d’identifiants

Lorsqu’un client est approuvé pour SMPP, envoyez un seul document, et faites-en le même document à chaque fois :

1. L’hôte, le port, et ce qui est attendu en matière de TLS si vous terminez TLS devant le serveur SMPP.
2. Le system_id et le mot de passe (transmis par un autre canal que l’e-mail qui contient le reste).
3. Les modes de bind autorisés et le nombre maximal de sessions.
4. Les adresses IP depuis lesquelles vous accepterez les binds, et la manière de les modifier.
5. Le plafond de débit en msg/s, la taille de fenêtre, l’intervalle d’enquire_link.
6. Les sender ID autorisés, les règles de codage, le traitement des messages longs, l’indicateur registered delivery exigé.
7. La destination des accusés de réception, et les codes d’erreur que le client doit s’attendre à recevoir et à traiter.
8. La route de test et les numéros de test à utiliser avant la mise en production.

La moitié de ces éléments sont des chiffres que l’ingénieur du client saisira dans un fichier de configuration dans l’heure qui suit. Les donner tous d’un coup fait la différence entre une intégration d’une journée et un fil d’e-mails de deux semaines.

Tester avant la mise en production

N’activez jamais le compte SMPP d’un client sur des routes de production. Fournissez une route de test qui accepte les messages, génère un accusé de réception plausible après un court délai et ne facture rien, et accompagnez le client dans six vérifications sur cette route : un bind dans chaque mode autorisé ; un message unique et son accusé rapprochés par l’ID ; un message long dans une écriture non latine qui arrive en un seul message sur un vrai téléphone ; une rafale au-delà du plafond de débit qui produit des erreurs de throttling et un ralentissement correct ; un sender ID volontairement erroné qui produit le rejet attendu ; et une connexion coupée suivie d’une reconnexion propre. Seulement ensuite, faites passer le compte sur ses routes de production, en laissant le plafond en place.

C’est cette même route de test que vous utilisez pour reproduire plus tard le problème d’un client. Un client qui dit « les accusés se sont arrêtés » peut se lier à la route de test, envoyer un message et regarder l’accusé revenir dans la console, ce qui transforme un ticket vague en une vérification de dix minutes de son bind receiver.

Quand un client ne devrait pas avoir SMPP

Ce n’est pas parce qu’un client demande SMPP qu’il doit l’obtenir. Une équipe marketing qui envoie depuis un navigateur n’a que faire d’un bind ; un développeur qui envoie 300 OTP par jour est mieux servi par l’API HTTP, qui ne nécessite aucune session persistante et renvoie des erreurs qu’il peut lire. SMPP s’adresse aux clients qui ont du volume, une pile SMPP existante, ou une raison de conformité de conserver une relation protocolaire directe. Tous les autres reçoivent l’API, et votre file de support s’en trouve allégée.

Ce qui rend l’offre crédible, c’est qu’il s’agit de la même plateforme en dessous, et qu’avec une licence auto-hébergée le serveur SMPP est inclus au lieu d’être vendu comme un palier séparé. Un client qui démarre sur l’API HTTP et évolue vers un bind SMPP conserve son compte, son solde, son plan tarifaire et ses rapports ; le bind est un canal de plus vers un compte omnicanal qui peut aussi transporter son trafic WhatsApp et RCS sur le même grand livre. Cette continuité est ce qu’un revendeur qui loue un panneau ne peut généralement pas offrir, et c’est la raison discrète pour laquelle les clients techniques restent.