Alternative à Kannel avec GUI, facturation et marque blanche

Kannel achemine en silence les SMS du monde depuis plus de vingt ans, et si vous exploitez une passerelle SMS auto-hébergée sérieuse, il y a de fortes chances que Kannel ou Jasmin soient en ce moment même dans votre stack, à tenir des bind SMPP sans jamais se plaindre. Aussi, quand un opérateur cherche une alternative à Kannel, il souhaite rarement vraiment remplacer le bearer. Il veut dire qu’il a dépassé tout ce qu’un bearer n’a jamais cherché à être : une administration graphique, des comptes clients, la facturation, des portails en marque blanche, quelqu’un à appeler à 2 heures du matin. Ce guide parle précisément de cet écart, et des manières honnêtes de le combler sans jeter le moteur qui fonctionne déjà.

Ce que Kannel et Jasmin font à merveille

Rendons aux bearers open source ce qui leur revient, car faire comme s’ils étaient faibles est le meilleur moyen de gaspiller de l’argent à les remplacer. Le BearerBox de Kannel termine du SMPP depuis avant l’existence de la plupart des startups de messagerie. Il tient des bind persistants vers vos SMSC, les maintient en vie, se reconnecte quand un opérateur laisse tomber la session, répartit le trafic entre les connexions et déplace des volumes énormes sur un matériel modeste. Il est écrit en C, il est stable au point d’en être ennuyeux, et ennuyeux est exactement ce que vous voulez de la couche qui touche les opérateurs.

Jasmin est le petit frère, écrit en Python, avec un modèle de configuration plus propre, une CLI de gestion et une API plus conviviale que beaucoup d’équipes trouvent plus faciles à appréhender. Pour la simple terminaison SMPP, l’un comme l’autre est un choix légitime et professionnel, et aucun ne sera la raison pour laquelle votre passerelle s’effondre.

Ce que les deux partagent est une philosophie de conception : ce sont des bearers, pas des produits. Ils connectent votre plateforme aux opérateurs et font cet unique travail extrêmement bien. Tout ce pour quoi une activité de revente facture réellement ses clients se situe au-dessus de ce travail, et c’est là que commence vraiment la recherche d’une alternative.

Les six choses qu’un bearer ne fera jamais pour vous

Tout juste installé, un déploiement brut de Kannel ou de Jasmin laisse six manques. Aucun n’est un défaut du logiciel. Ce sont simplement les parties qui n’ont jamais fait partie de son périmètre, et il se trouve que ce sont justement les parties qu’une activité vend.

Une administration graphique. Il n’y a aucune GUI. Chaque route, chaque tarif, chaque connexion SMSC et chaque utilisateur est une ligne dans un fichier de configuration édité en SSH. C’est très bien pour un seul ingénieur qui vit dans le stack, et cela devient un mur dès l’instant où vous voulez du personnel, ou des opérateurs non techniques, ou une piste d’audit indiquant qui a changé quoi.

Des comptes clients multi-tenant. Un bearer n’a aucune notion de client. Il déplace des messages ; il ne sait pas et ne se soucie pas que ces dix mille appartiennent à une banque et ceux-là à un fleuriste. Il n’y a pas d’isolation par client, pas de soldes distincts, pas de tarifs par client, pas moyen de suspendre un compte sans toucher à un autre. Le multi-tenant est la différence entre un tuyau et une activité, et vous le construisez ou vous l’achetez.

La facturation et le contrôle du crédit. Rien ne décompte un message du solde d’un client avant l’envoi, ne le tarife selon la route empruntée, ne le rembourse correctement en cas d’échec définitif ni ne le regroupe dans une facture. Un bearer brut enverra volontiers des messages que vous ne pourrez jamais facturer. Le contrôle du crédit, les portefeuilles prépayés, la facturation postpayée et les tarifs multidevises sont tous à votre charge.

Des portails clients en marque blanche. Vos clients n’ont nulle part où se connecter. Aucun panneau à votre marque pour composer une campagne, importer une liste de contacts, consulter un solde ou télécharger un rapport. Pour un revendeur, le portail est le produit que le client voit chaque jour, et un bearer n’en a pas.

Des rapports qu’un client peut lire. Kannel écrit des logs. Les logs ne sont pas un rapport de livraison qu’un client peut ouvrir, filtrer et comprendre sans vous appeler. Transformer les logs d’accès bruts et les événements DLR en tableaux de bord par client, en historiques exportables et en taux de livraison lisibles est une couche de reporting qui n’existe pas tant que vous ne la construisez pas.

Quelqu’un pour répondre à minuit. L’open source s’accompagne d’une communauté, généreuse et souvent excellente, mais ce n’est pas un SLA. Quand un bind tombe pendant l’envoi nocturne des relevés d’un client, il n’y a pas de ligne de support qui prenne le problème en charge. Pour un loisir, c’est très bien. Pour une activité avec des clients payants, l’absence d’un support responsable est un coût réel.

Le résumé honnête : transformer un bearer en une activité est un projet logiciel, et un gros. Le vrai coût de ce logiciel gratuit, ce sont les mois d’ingénierie consacrés à la facturation, au multi-tenant, aux portails et au reporting, plus leur maintenance pour toujours. Donnez un prix honnête à ce projet avant de décider de le gérer vous-même.

La migration qui conserve vos bind SMSC

Voici la partie rassurante, et la raison pour laquelle « alternative » est le mauvais mot. Vous n’avez pas à arracher Kannel pour obtenir tout ce qui précède. La voie la moins risquée, et généralement la plus intelligente, consiste à poser une plateforme de gestion au-dessus du bearer auquel vous faites déjà confiance.

Cela fonctionne parce que Kannel est conçu pour être piloté. Il expose une interface sendsms pour soumettre des messages et une interface d’administration pour l’état et le contrôle, ce qui est exactement la jointure sur laquelle une plateforme se branche. Une plateforme comme Smppcube se place au-dessus du bearer : elle gère la GUI, les comptes multi-tenant, la facturation et les portails, et transmet les messages vers le bas à Kannel, qui continue de faire ce en quoi il excelle : tenir vos bind avec les opérateurs. Les connexions que vous avez pris le temps de régler avec chaque SMSC ne bougent pas.

Une migration sensée ressemble à ceci. D’abord, dressez la plateforme à côté de votre Kannel en fonctionnement, pointée vers le même BearerBox, de sorte que rien ne change encore en production. Ensuite, recréez vos routes et vos tarifs dans la plateforme pour qu’ils correspondent à ce que Kannel utilise déjà. Troisièmement, créez les comptes clients et leurs tarifs par client, en important les soldes que vous suiviez dans des feuilles de calcul. Quatrièmement, déplacez un client de confiance vers le nouveau portail et observez une vraie campagne circuler d’un bout à l’autre : depuis le panneau, à travers la facturation de la plateforme, vers le bas par Kannel, jusqu’au SMSC, et de retour sous forme d’accusé de livraison que le client peut lire. Cinquièmement, basculez le reste une fois que les chiffres concordent, et mettez les feuilles de calcul à la retraite.

À aucun moment de cette séquence vous ne remplacez le bearer ni ne laissez tomber un bind. Vous ajoutez la couche métier qui a toujours manqué, au-dessus de la couche télécom qui a toujours été bonne. Parce que Smppcube est une licence unique que vous possédez entièrement plutôt qu’un panneau en location, la plateforme vers laquelle vous migrez reste elle aussi sur votre propre serveur, ce qui préserve la posture air-gap ou DMZ qui vous a fait choisir l’auto-hébergement au départ.

Restez sur Kannel (ou Jasmin) si…

La conclusion respectueuse, sans argumentaire de vente : parfois un bearer brut est exactement ce qu’il faut, et ajouter une plateforme n’est qu’une surcharge à éviter.

Restez sur Kannel ou Jasmin brut si vous êtes un locataire unique sans clients à facturer. Si vous connectez l’un de vos propres systèmes à un seul opérateur et qu’il n’y a pas d’arbre de revendeurs, pas d’isolation par client, pas de facture à émettre, un bearer plus quelques scripts est la bonne réponse, économique, et une plateforme complète est un poids dont vous n’avez pas besoin. Restez-y si écrire et posséder ce logiciel est vraiment votre activité et non une distraction, car certaines équipes veulent vraiment posséder chaque couche et ont le temps d’ingénierie pour les maintenir. Et restez-y tant que vous êtes encore en train de prouver qu’il existe une demande, car une passerelle pilotée par fichiers de configuration est un excellent moyen de mener un premier pilote avant d’investir dans l’outillage.

Le test est le même que celui qui traverse toute décision honnête de construire ou d’acheter dans la messagerie : construire la couche de facturation, de multi-tenant et de portails est-il votre produit, ou est-ce de six à douze mois de travail dressés entre vous et la vente à des clients ? Répondez à cela d’abord. Si la réponse est que vous voulez vendre de la messagerie plutôt qu’écrire un logiciel de passerelle, l’alternative que vous cherchez n’est pas du tout un remplacement de Kannel. C’est un foyer pour lui.