Gérer une passerelle SMS auto-hébergée : ce que cela implique vraiment

Une passerelle SMS auto-hébergée fait partie de ces choses qui paraissent simples de l’extérieur et révèlent leur vraie forme la semaine de la mise en production. Envoyer un message est facile ; en envoyer des millions de façon fiable, facturer chacun correctement, prouver la livraison et le faire sans panne à 2 heures du matin, voilà le vrai travail. Ce guide parcourt l’architecture en termes clairs, donne des chiffres matériels honnêtes, marque la ligne où le logiciel gratuit s’arrête et expose les opérations que vous assumerez dès que le trafic sera réel. L’objectif est de vous aider à décider en toute lucidité, que vous choisissiez de construire, d’acheter ou de continuer à louer encore un peu.

Qu’est-ce qu’une passerelle SMS auto-hébergée, au fond

Sous les tableaux de bord, une passerelle est une petite chaîne de montage à quatre postes. Le trafic entre, est mis en file d’attente, est envoyé et est comptabilisé. Comprendre ces quatre postes, c’est l’essentiel de la bataille.

L’entrée est la manière dont les messages arrivent. Les clients professionnels envoient via une API HTTP pour la commodité, via un panneau web pour des campagnes ponctuelles, ou via un bind SMPP lorsqu’ils sont une autre plateforme qui pousse de gros volumes. SMPP est le protocole natif des télécommunications : une connexion TCP persistante, authentifiée une seule fois, puis les messages y circulent sous forme de paquets binaires. Un client SMPP bien configuré peut soumettre des dizaines de milliers de messages par seconde, et c’est précisément pour cela que les expéditeurs sérieux le préfèrent à HTTP.

La file d’attente est l’amortisseur. On n’envoie jamais directement de l’entrée vers l’opérateur, car les opérateurs acceptent à leur propre rythme et vos rafales entrantes ne correspondent pas à celui-ci. À la place, chaque message accepté atterrit dans une file rapide en mémoire (Redis est le choix habituel) et renvoie aussitôt un accusé. C’est ce qui vous permet d’accepter un envoi d’un million de messages en quelques secondes sans en perdre aucun, puis de les alimenter aux opérateurs de façon régulière. La persistance de cette file compte : si la machine redémarre et que la file n’existait qu’en mémoire, tout ce qui n’a pas encore été écrit sur disque est perdu.

Le transport est la partie qui parle réellement aux opérateurs. Dans la plupart des piles auto-hébergées, il s’agit de Kannel, dont le BearerBox maintient les connexions SMPP persistantes vers chaque SMSC (le centre de messages de l’opérateur), les garde actives, se reconnecte lorsqu’elles tombent et équilibre le trafic entre les sessions. Un processus complémentaire lit la file en attente et remet les messages au transport ; un autre s’occupe des accusés de réception et des messages entrants qui reviennent. Cette couche a des décennies d’existence et est extrêmement fiable, et il n’y a aucune honte à s’appuyer dessus.

La facturation et la comptabilité est le poste que tout le monde sous-estime. Chaque message doit être décompté sur le solde du bon client avant l’envoi, tarifé selon la route empruntée, remboursé correctement lorsqu’un opérateur signale un échec définitif, et regroupé dans une facture que le client peut lire. Ce n’est pas une fonction qu’on ajoute après coup ; elle est tissée à travers tous les autres postes, et c’est là que les passerelles amateurs perdent de l’argent en silence.

Dimensionnement du serveur : ce qu’il vous faut vraiment à 1, 10 et 50 messages par seconde

La première erreur de dimensionnement est de raisonner en totaux mensuels. Le trafic SMS est en rafales : la vente flash d’un commerçant ou l’envoi nocturne des relevés d’une banque pousse le volume d’un mois en une heure. Ce qui sollicite la machine, c’est le pic de débit soutenu, le volume des accusés de réception qui reviennent (souvent autant d’événements que de messages envoyés) et la charge de rapports et de recherche que génèrent vos clients. Dimensionnez pour le pic, pas pour la moyenne.

Le tableau ci-dessous est un point de départ pour un déploiement à nœud unique, pas un contrat. La taille du message, l’encodage, le mélange de routes et la durée de conservation des enregistrements déplacent tous les chiffres.

Débit soutenu	Volume mensuel approximatif	Matériel initial (nœud unique)	Ce qui cède en premier
~1 msg/s	Jusqu’à ~1 000 000	4 vCPU, 8 Go RAM, SSD de 100 Go, tous les composants ensemble	Le disque qui se remplit de journaux et de DLR
~10 msg/s	De ~1 000 000 à 10 000 000	8 vCPU, de 16 à 32 Go RAM, SSD de 250 à 500 Go	Recherche et rapports sous la charge des clients
~50 msg/s	À partir de 10 000 000	16+ vCPU, de 32 à 64 Go RAM, NVMe rapide, composants répartis sur plusieurs nœuds	Les limites du nœud unique ; l’heure de passer en actif-actif

Deux remarques pratiques. Premièrement : le débit vers un même opérateur est généralement limité par le nombre de sessions SMPP que l’opérateur autorise, pas par votre matériel ; si une route est lente alors que votre machine est inactive, il vous faut probablement plus de sessions, jusqu’au maximum de l’opérateur, et non un serveur plus grand. Deuxièmement : dès que la plateforme devient critique pour l’activité, cessez de faire grossir une seule machine et passez à une topologie à haute disponibilité avec les composants sur des nœuds dédiés. Une base de référence documentée, relevée sur votre propre déploiement, vaut plus que n’importe quel tableau générique, car le « normal » se définit par rapport à votre matériel et à votre trafic.

Ce que l’open source vous donne, et où il s’arrête

Le monde du SMS open source est vraiment bon, et prétendre le contraire vous fait dépenser plus. Kannel et Jasmin terminent le SMPP, maintiennent les binds avec les opérateurs et déplacent des volumes énormes pour le prix du serveur. Si votre besoin est un tuyau direct entre un système et un opérateur, ils sont souvent la bonne réponse et vous ne devriez pas surinvestir.

Là où ils s’arrêtent, c’est la couche métier, et l’écart est plus large qu’il n’y paraît. Par défaut, vous n’obtenez aucune administration graphique, donc chaque route, tarif et utilisateur est un fichier de configuration. Vous n’obtenez pas de comptes clients multi-locataires, ce qui signifie aucun cloisonnement, solde ou tarif par client. Vous n’obtenez ni facturation, ni émission de factures, ni contrôle du crédit. Vous n’obtenez pas de portails clients en marque blanche, ni les rapports de livraison lisibles que les clients réclament, ni un moteur de désinscription (opt-out), ni personne à appeler quand un bind tombe à minuit. Rien de tout cela n’est une critique des outils ; ils ont été conçus pour être un transport, pas un produit. Cela signifie simplement que transformer un transport en activité est un projet logiciel, et vous devriez chiffrer ce projet honnêtement avant de le lancer. Ce vrai coût du « gratuit » fait l’objet d’une comparaison dédiée.

Les opérations dont personne ne vous prévient

La mise en production est le début du travail, pas la fin. Quatre réalités opérationnelles détermineront si votre passerelle est une activité ou un casse-tête.

Les accusés de réception (DLR) sont la façon de prouver qu’un message est arrivé, et ils ne sont pas facultatifs. Un opérateur renvoie un accusé indiquant livré, échoué ou expiré, et votre plateforme doit le rapprocher du message d’origine, mettre à jour le rapport du client et décider de la facturation. Un échec temporaire (téléphone éteint, congestion du réseau) peut encore être livré dans sa fenêtre de validité et ne devrait pas être remboursé prématurément ; un échec définitif (numéro invalide, bloqué) ne sera jamais livré et devrait être remboursé. Se tromper dans ce classement, c’est ainsi que l’on perd de l’argent sur des remboursements qu’on ne devrait pas accorder, ou que l’on irrite les clients en facturant des messages qui ne sont jamais arrivés.

Les nouvelles tentatives et la validité décident du sort des messages qui ne passent pas du premier coup. Il vous faut une politique de nouvelles tentatives sensée et une période de validité, faute de quoi une route bloquée accumulera en silence du trafic non livré jusqu’à ce qu’un client demande pourquoi sa campagne n’est jamais partie.

La surveillance fait la différence entre l’apprendre par un graphique et l’apprendre par un client mécontent. Au minimum, surveillez l’état des binds avec les opérateurs, la profondeur de la file, le taux de livraison par route et l’espace disque libre. Une passerelle sans surveillance n’est pas une passerelle plus petite ; c’est une bombe à retardement pleine de bonnes intentions. Une réalité peu reluisante qu’il vaut la peine d’intégrer : une part surprenante des incidents du type « tout est cassé » n’est qu’un disque plein, alors vérifiez cela en premier.

Les sauvegardes sont celles que vous regretterez d’avoir négligées. Votre système d’enregistrement, votre liste de clients, vos soldes et la persistance de votre file ont tous besoin d’une sauvegarde que vous avez réellement testée en la restaurant, pas seulement planifiée. Testez-la une fois avant d’avoir des clients, car le jour où vous en aurez besoin est le pire jour possible pour découvrir qu’elle n’a jamais fonctionné.

Construire ou acheter, honnêtement

Voici le carrefour, sans discours commercial. Si vous avez le temps d’ingénierie, que vous aimez être maître de la pile et que le tuyau de messagerie lui-même est votre produit, construire sur de l’open source est légitime et peu coûteux en matière de licences. Cette économie, vous la dépenserez dans les mois nécessaires pour construire les couches de facturation, de multi-locataires, de portail et de rapports, et pour les maintenir à jamais, mais pour certaines équipes, c’est exactement le bon compromis.

Si, au contraire, votre objectif est de vendre de la messagerie à des clients ce trimestre, acheter une plateforme dont vous êtes propriétaire est généralement le meilleur calcul. Une plateforme sous licence à paiement unique comme Smppcube fournit toute la couche métier, les comptes multi-locataires, la facturation, les portails et les rapports, par-dessus le même transport éprouvé, et tourne sur votre propre serveur, ce qui vous permet de conserver la posture air-gap ou DMZ pour laquelle on choisit souvent l’auto-hébergement en premier lieu. En échange d’une redevance de licence, vous économisez de six à douze mois que vous ne passez pas à construire un logiciel qui n’est pas votre facteur de différenciation.

Le test honnête est simple : écrire un logiciel de passerelle est-il votre métier, ou une distraction par rapport à celui-ci ? Répondez d’abord à cela, et l’architecture, le dimensionnement et les opérations ci-dessus deviennent une liste de contrôle plutôt qu’une surprise. Partez de votre propre chiffre de pic de débit et d’une idée claire de la personne à qui vous vendez, et le reste de la décision se règle de lui-même.