Configuration serveur d'une passerelle SMS : de 1 à 200 msg/s

« De quel serveur ai-je besoin ? » est la première question que pose presque chaque acheteur, et la réponse est plus modeste que ce que la plupart des gens redoutent, et plus précise que ce qu’annoncent la plupart des éditeurs. Une passerelle SMS n’est pas un encodeur vidéo. Son travail consiste à mettre en file d’attente, router, facturer et tenir les comptes, et c’est la tenue des comptes qui grossit. Ce guide vous donne la configuration serveur requise pour une passerelle SMS à chaque palier de trafic, avec des chiffres réels, explique pourquoi un vCPU dédié compte davantage que le nombre de cœurs, montre ce que les accusés de réception et les archives font à votre disque sur une année, et se termine par une courte liste d’hébergeurs et le plan de sauvegarde que vous devriez avoir avant la mise en service du premier client.

Configuration serveur d’une passerelle SMS par palier de trafic

Le chiffre qui détermine votre serveur est le nombre de messages par seconde au pic, et non le nombre de messages par mois. Un client qui envoie 1 000 000 de messages répartis sur un mois tourne en moyenne à 0,4 msg/s ; le même client qui lance une promotion vers 200 000 numéros à neuf heures du matin veut 100 msg/s pendant une demi-heure. La passerelle doit absorber cette rafale, la transmettre aux opérateurs aussi vite qu’ils l’acceptent, puis recueillir les accusés de réception qui reviennent et qui, au pic, arrivent au même rythme que les envois.

Le tableau ci-dessous reprend le dimensionnement que nous publions sur la page Plateforme, et il correspond à ce sur quoi tournent nos propres installations. Les volumes sont mensuels, les débits sont soutenus.

Débit soutenu	Volume mensuel	Serveur	Remarques
~1 msg/s	jusqu’à ~1 000 000 SMS	4 vCPU, 8 Go RAM, SSD de 100 Go, tout sur une seule machine	La plupart des revendeurs restent à ce palier pendant leur première année
~10 msg/s	de ~1 000 000 à 10 000 000	8 vCPU, 16 à 32 Go RAM, SSD de 250 à 500 Go	Index de recherche et base de données idéalement sur leurs propres disques
~50 msg/s et plus	10 000 000 et plus	16+ vCPU, 32 à 64 Go RAM, NVMe rapide, composants répartis sur plusieurs nœuds	File d’attente, base de données, recherche et couche SMPP disposent chacune de ressources propres

Deux choses surprennent dans ce tableau. D’abord, la modestie du premier palier : une plateforme multi-tenant complète, avec une console web, un serveur SMPP, une file d’attente, une base de données et un index de recherche, tient sur une machine à 4 vCPU, car à 1 msg/s aucun de ces composants n’est sous pression. Ensuite, le passage au troisième palier n’est pas une question de CPU. C’est une question d’entrées/sorties : à 50 msg/s, la base de données écrit une ligne par message, la met à jour quand l’opérateur acquitte l’envoi, la met à jour de nouveau à l’arrivée de l’accusé de réception, et l’indexe pour la recherche. Trois écritures par message à 50 msg/s, cela fait 150 écritures par seconde, en continu, plus les lectures de chaque tableau de bord client ouvert. C’est un problème de disque, et c’est pourquoi le NVMe et les nœuds séparés apparaissent à la troisième ligne et pas avant.

La question des rafales : démarrer petit, avoir de la réserve

Il existe un cas intermédiaire courant que le tableau ne saisit pas : vous partez de zéro, votre volume mensuel est donc minuscule, mais votre premier client est un réseau d’écoles ou une boutique en ligne qui envoie tout en une seule rafale matinale et s’attend à ce que tout arrive en quelques minutes. Il vous faut 100 à 200 msg/s de réserve alors que votre débit soutenu reste inférieur à 1 msg/s.

La réponse est un serveur dédié de 4 à 8 vCPU avec 32 Go de RAM. Il coûte de 50 à 100 USD par mois chez les hébergeurs listés plus bas. Il absorbe la rafale parce que les cœurs sont à vous et que la RAM garde la file d’attente et l’ensemble de travail en mémoire, et il vous accompagne jusqu’à ce que le volume soutenu, les accusés de réception et les rapports commencent à se disputer le même disque. C’est le moment de passer au palier supérieur, et il arrive généralement après le dixième client, pas après le premier.

L’erreur de débutant la plus coûteuse dans ce métier consiste à acheter le troisième palier dès le premier jour parce qu’un tableur prévoyait 50 clients. Achetez le premier palier prêt pour les rafales, surveillez le disque et la file des accusés de réception, et passez au palier suivant quand les graphiques vous le disent.

vCPU dédié ou partagé

Les catalogues des hébergeurs brouillent une frontière importante. Une instance partagée « 4 vCPU » vous donne quatre tranches de temps sur des cœurs que d’autres clients de l’hébergeur utilisent aussi ; une instance dédiée « 4 vCPU » vous donne quatre cœurs qui sont à vous. Pour un site web, la différence est invisible. Pour une passerelle SMS, c’est la différence entre une promotion livrée en dix minutes et une promotion livrée en quarante.

La raison tient à la forme de la charge. Le trafic web est régulier et tolérant ; une seconde de lenteur ici ou là passe inaperçue. Le trafic SMS arrive en rafales et conserve un état : pendant une rafale, la couche SMPP doit alimenter ses binds avec les opérateurs et répondre à temps à leurs battements (heartbeats), la file d’attente doit se vider, et les accusés de réception doivent être rattachés à leurs messages tant que ceux-ci sont encore « chauds » dans la base de données. Si un voisin utilise le cœur partagé à ce moment-là, le bind se fige, la fenêtre de l’opérateur se remplit, l’opérateur limite votre débit (throttling) et vos accusés de réception s’empilent derrière les envois. Rien ne casse, mais tout ce que vous avez promis au client en matière de rapidité et de rapports arrive désormais en retard.

Règle empirique : un vCPU partagé pour la démonstration et le serveur de préproduction, un vCPU dédié pour tout ce qu’un client paie. L’écart de prix au premier palier est de 20 à 40 USD par mois, soit moins d’une heure de votre temps passée à expliquer à un client pourquoi le rapport d’hier est encore en cours de mise à jour.

RAM : ce qui vit réellement en mémoire

Il est plus simple de raisonner sur les besoins en mémoire. Trois éléments veulent rester résidents : la file d’attente (chaque message accepté mais pas encore transmis à un opérateur, plus chaque accusé de réception pas encore rapproché), l’ensemble de travail de la base de données (les derniers jours de messages, les grilles tarifaires, les comptes clients) et le cache de l’index de recherche. Au premier palier, les trois tiennent ensemble dans 8 Go, avec de la place pour le système d’exploitation et la console web. Au deuxième palier, l’ensemble de travail grossit avec votre historique, et 16 à 32 Go évitent à la base de données de solliciter le disque pour les rapports que les clients ouvrent chaque matin.

En pratique, là où la RAM vient à manquer, ce n’est pas la file d’attente, ce sont les rapports. Un client qui demande « tous les messages vers ce pays au dernier trimestre » sur une base de données obligée de lire ces données sur le disque transforme une requête de deux secondes en requête de deux minutes, et ralentit tout le monde pendant son exécution. Ajouter de la RAM est la correction la moins chère ; archiver les anciens messages dans une base documentaire, ce que fait l’architecture séparée du troisième palier, est la correction durable.

Disque : les accusés de réception et les archives font la croissance

C’est sur le disque que se produit la vraie croissance, et c’est la partie que personne ne dimensionne. Chaque message envoyé produit au moins trois enregistrements : le message lui-même, son accusé de réception provenant de l’opérateur, et l’écriture de facturation qui a débité le client. Ajoutez les index qui rendent la recherche et les rapports rapides, et un chiffre de planification pratique est d’environ 1 Ko par message, tout compris, avant compression.

Au premier palier, 1 000 000 de messages par mois représentent environ 1 Go de croissance par mois. Un SSD de 100 Go en contient des années. Au deuxième palier, 10 000 000 de messages par mois représentent 10 Go par mois, soit 120 Go par an, et un index de recherche ajoute 30 à 50 pour cent par-dessus. C’est pourquoi la deuxième ligne indique 250 à 500 Go, et pourquoi l’index de recherche et la base de données se trouvent « idéalement » sur leurs propres disques : ils se disputent la même bande passante d’écriture lorsqu’ils en partagent un.

Deux choix de conception empêchent que cela devienne un problème. Premièrement, un niveau d’archivage : la base de données principale conserve la fenêtre récente (disons 90 jours) et les messages plus anciens passent dans une base documentaire où ils restent consultables, mais ne ralentissent plus les tables transactionnelles. Deuxièmement, une politique de conservation que vous décidez vraiment : de nombreux opérateurs de messagerie conservent les accusés de réception de 12 à 24 mois en cas de litige et suppriment plus tôt le corps des messages, et certains marchés réglementent la durée de conservation, vérifiez donc la règle pour les pays vers lesquels vous envoyez. Une plateforme dotée d’une couche d’archivage intégrée, et c’est ainsi qu’est dessinée la pile Smppcube, avec MongoDB pour l’archive à côté de MySQL comme système de référence, fait de ces deux choix un réglage plutôt qu’un projet.

Réseau et ports

La bande passante n’est pas la contrainte ; un message pèse quelques centaines d’octets. Ce qui compte, c’est une IP publique stable, car les opérateurs inscrivent généralement l’IP de votre bind SMPP sur une allowlist et n’aiment pas la mettre à jour, ainsi qu’un port entrant 2775 ouvert (ou le port de votre choix) si vos propres clients se lient à votre serveur SMPP. Derrière cela : HTTPS pour la console et l’API HTTP, et un accès sortant vers les points de terminaison SMPP et HTTP des opérateurs. Si vous fonctionnez en DMZ ou isolé du réseau (air-gap), la passerelle n’a besoin que des liens opérateurs et du réseau de la console, et c’est l’une des raisons pour lesquelles l’auto-hébergement fonctionne dans des environnements réglementés où un panneau SaaS ne pourrait même pas être approuvé.

Une courte liste d’hébergeurs, avec les prix

Tout hébergeur qui vend des vCPU dédiés, un stockage SSD ou NVMe et une IP statique, et qui vous laisse ouvrir un port, fera l’affaire. Voici ceux que nous rencontrons le plus souvent. Un serveur dédié de 4 à 8 vCPU et 32 Go, qui couvre le premier palier prêt pour les rafales ainsi que le CPU et la RAM du deuxième palier, coûte généralement de 50 à 100 USD par mois chez n’importe lequel des quatre premiers ; le troisième palier, avec NVMe et nœuds séparés, fait partout l’objet d’un devis sur mesure.

Hébergeur	Adapté à	Pourquoi il revient souvent
Hetzner	Europe	Offres à vCPU dédiés et serveurs physiques à bas prix
Netcup	Europe	Cœurs dédiés à faible coût ; nous tournons nous-mêmes sur Netcup
DigitalOcean	Régions dans le monde entier	Console simple, tarification prévisible, instantanés faciles
OVHcloud	Europe, Amérique du Nord	Serveurs physiques disponibles quand les machines virtuelles ne suffisent plus
Alibaba Cloud	Arabie saoudite et Golfe	Un centre de données dans le Royaume, pour la résidence des données
Votre propre matériel	Isolé du réseau ou réglementé	Frais de colocation uniquement ; la passerelle n’a besoin de rien de l’extérieur, hormis les liens opérateurs

La mention « nous tournons nous-mêmes sur Netcup » figure ici parce que les acheteurs posent la question ; c’est le constat de ce qui fonctionne aux deux premiers paliers, pas une recommandation d’ignorer les autres. Vérifiez les tarifs en vigueur avant de décider. Si vos clients sont dans un seul pays, un hébergeur disposant d’une région dans ce pays raccourcit l’aller-retour vers les opérateurs et, surtout, conserve les données là où le régulateur les attend.

La facture complète, en toute honnêteté

Le dimensionnement du serveur n’a de sens qu’à côté du reste de la facture, et c’est là que le modèle auto-hébergé mérite son nom. Trois lignes, dont une seule nous revient :

1. La licence, une fois : 6,400 USD pour la plateforme, tous les canaux, toutes les fonctionnalités et la première année de support. C’est la page des tarifs résumée en un chiffre.
2. Le serveur, chaque mois : de 50 à 100 USD aux deux premiers paliers, payés à l’hébergeur de votre choix, sur votre propre compte, et vous pouvez le déplacer quand vous le souhaitez.
3. Votre trafic opérateur, aux tarifs que vous négociez avec votre propre SMSC ou agrégateur. Nous ne nous plaçons jamais au milieu.

Comparez avec un panneau loué, où les frais de plateforme augmentent avec votre trafic et où le serveur est invisible parce qu’il appartient au fournisseur : la ligne serveur est la seule que vous ne pouvez pas rendre moins chère en grandissant, et ici, c’est la plus petite ligne de la page.

Sauvegardes, surveillance et les parties ennuyeuses

Un serveur n’est pas un plan. Avant la mise en service du premier client, trois éléments doivent exister et avoir été testés :

• Une sauvegarde nocturne que vous avez restaurée au moins une fois. Un export (dump) de la base de données plus le répertoire de configuration, copiés hors de la machine (l’instantané de l’hébergeur est pratique, mais un instantané sur le même compte que le serveur ne protège pas contre le blocage de ce compte). Testez la restauration sur la machine de préproduction ; une sauvegarde que personne n’a restaurée n’est qu’un espoir.
• Des alertes sur le disque et la file d’attente. Deux seuils suffisent : le disque au-delà de 80 pour cent, et une file d’accusés de réception vieille de plus de 15 minutes. Le premier vous dit d’archiver ou d’agrandir ; le second vous signale qu’un bind opérateur est en mauvaise santé avant qu’un client ne le fasse.
• Un serveur de préproduction. Le VPS partagé le moins cher que vous trouverez, avec la même version, sur lequel les mises à jour et les nouvelles grilles tarifaires sont essayées en premier. Il coûte le prix d’un café par mois ; sa valeur, c’est chaque mise à jour que vous n’avez pas à annuler sur la machine de production pendant que les clients envoient.

Quand vous n’avez besoin de rien de tout cela

Si vous envoyez quelques milliers de messages par mois depuis une seule application et n’avez aucun client à vous, vous n’avez pas du tout besoin d’un serveur de passerelle ; une API HTTP de n’importe quel fournisseur, appelée depuis votre application, est la bonne taille. Le dimensionnement de ce guide s’adresse aux opérateurs qui vendent de la messagerie à d’autres : revendeurs, agrégateurs, opérateurs, ou une entreprise qui gère la messagerie pour de nombreuses équipes internes. À ce stade, le serveur est la partie la moins coûteuse de l’activité, et savoir à quel palier vous vous trouvez, et ce qui vous fera passer au suivant, résume l’essentiel de ce que « configuration requise » a jamais voulu dire.