Smppcube face à l'open source (Kannel · Jasmin · PlaySMS)

Réglons tout de suite le point gênant : Smppcube embarque Kannel. Nous ne sommes pas là pour vous dire que l’open source est du mauvais logiciel, puisque nous l’exploitons en production et que nous referions ce choix. Kannel, c’est plus de vingt ans de C éprouvé, qui tient les binds vers les SMSC mieux que tout ce que nous écririons nous-mêmes. Ce comparatif ne parle pas de la qualité du logiciel libre. Il parle d’une question bien plus étroite et bien plus chère : combien coûte la transformation d’un bearer gratuit en une activité depuis laquelle vous pouvez facturer, et ce projet est-il votre produit ou un détour ? Voici les chiffres honnêtes, un tableau côte à côte, et les cas où l’option gratuite est réellement la bonne et où vous devriez fermer cet onglet et aller construire.

Ce que « gratuit » signifie vraiment sur ce marché

Gratuit au sens de la licence et gratuit au sens du coût total sont deux monnaies différentes, et le secteur de la messagerie est particulièrement doué pour les confondre. La raison : la partie gratuite fait le travail visible et impressionnant. Elle parle SMPP. Elle déplace des milliers de messages par seconde. Elle survit à un opérateur qui fait quelque chose de grossier à trois heures du matin. La voir fonctionner pour la première fois conduit très facilement à conclure que le difficile est fait.

Le difficile n’est pas fait. Le difficile, c’est la partie ennuyeuse. Un bearer déplace des messages ; une activité décide de quel solde de quel client un message est sorti, à quel tarif et par quelle route, si ce client avait le droit de l’envoyer, ce que devient l’argent quand le message échoue définitivement quatre heures plus tard, ce que voit le client quand il se connecte pour vérifier, et ce que vous montrez à un régulateur ou à un client qui conteste six mois après. Rien de tout cela n’est dans le périmètre d’un bearer, et rien de tout cela n’est optionnel si vous facturez des gens.

Le vrai choix n’a donc jamais été « payer ou ne pas payer ». C’est : payer une licence une fois, ou payer un développeur pendant six à douze mois puis continuer à le payer indéfiniment pour maintenir ce qu’il a construit. Les deux sont légitimes. Elles coûtent simplement des sommes radicalement différentes, et une seule des deux met la facture là où vous pouvez la voir.

Ce que couvre réellement chaque option open source

Trois projets reviennent dans chacune de ces conversations. Les trois sont bons, les trois sont honnêtes sur leur périmètre, et chacun s’arrête à un endroit différent.

Kannel. La passerelle WAP et SMS open source classique, écrite en C, découpée en BearerBox (les connexions), SMSBOX (l’interface HTTP) et SQLBOX (les tables de file d’attente). C’est un bearer au sens le plus pur : il tient vos binds SMPP, il déplace des messages, et il fait les deux extrêmement bien à des volumes qui font honte à beaucoup de logiciels commerciaux. La configuration est un fichier que l’on édite en SSH. Pas d’interface graphique, pas de notion de client, pas de solde, pas de facture, pas de portail, pas de ligne de support. Ce n’est pas une lacune du projet, c’est sa frontière, tracée volontairement.

Jasmin. Une passerelle et un routeur SMS modernes en Python, avec une architecture franchement élégante : un routeur de messages, une interface de gestion en ligne de commande (jCli), une API HTTP et, contrairement à Kannel, une notion rudimentaire de facturation où un utilisateur possède des crédits qu’un envoi décrémente à un tarif configuré. Ce dernier point compte, et c’est pourquoi Jasmin se retrouve si souvent en liste courte. Mais soyons précis sur ce que c’est : des crédits par utilisateur, pas un système de facturation. Pas de facture, pas de multidevise, pas de distinction entre prépayé et postpayé, pas de grille tarifaire par client selon la route et la destination, pas d’arbre de revendeurs, pas de portail client. C’est un bien meilleur point de départ qu’un bearer nu, et cela reste un point de départ.

PlaySMS. Celui qui ressemble le plus à un produit, parce que c’est une application web en PHP : une interface de navigateur, des comptes utilisateurs avec des niveaux dont un palier revendeur, un solde de crédit simple, des groupes de contacts, et des modules de passerelle qui lui permettent de piloter Kannel ou un modem en dessous. Pour une petite structure avec une poignée d’utilisateurs, cela peut réellement suffire, et nous préférons que vous le sachiez plutôt que de le découvrir plus tard. Là où les opérateurs le dépassent, c’est la profondeur et le rythme : grilles tarifaires par route, prépayé et postpayé en parallèle, facturation multidevise, isolation réelle entre clients, marque blanche par client, les canaux récents, et une cadence de développement qui suive WhatsApp et RCS changeant leurs règles chaque trimestre.

Le schéma est le même pour les trois. La couche télécoms est résolue et gratuite. La couche commerciale n’est pas résolue et elle est à vous.

Le comparatif, côte à côte

	Kannel	Jasmin	PlaySMS	Smppcube v9
Coût de licence	Gratuit	Gratuit	Gratuit	6,400 USD une fois
Binds SMPP vers les SMSC	Excellent	Excellent	Via un module de passerelle	Kannel, dans la pile
Interface d’administration	Aucune	CLI (jCli)	Oui, basique	Interface web complète
Comptes clients	Aucun	Utilisateurs avec crédits	Oui, niveaux basiques	Multi-tenant avec arbre de revendeurs
Contrôle du crédit	Aucun	Crédits par utilisateur	Solde simple	Routes crédit, portefeuille et automatiques
Grilles tarifaires par route	Aucune	Tarification basique	Limitée	Par client, route et destination
Facturation	Aucune	Aucune	Aucune	Prépayé, postpayé, récurrent, multidevise
Portail client en marque blanche	Aucun	Aucun	Partiel	Par client, entièrement à sa marque
Rapports lisibles par le client	Fichiers de log	Fichiers de log	Basiques	Tableaux de bord et exports
WhatsApp, RCS, voix	Non	Non	Non	Dans la même plateforme
Support avec un responsable	Communauté	Communauté	Communauté	Éditeur, avec SLA
Délai jusqu’au premier client payant	De 6 à 12 mois	De 4 à 9 mois	Des semaines, puis un plafond	Des jours

Lisez ce tableau honnêtement et deux choses sautent aux yeux. Les lignes du haut, les lignes télécoms, sont à égalité ou presque, parce que nous sommes tous debout sur le même logiciel. Chaque ligne où apparaissent l’argent, les clients ou la marque est l’endroit où les options gratuites s’arrêtent et où le projet de développement commence. La dernière ligne est celle qui finit par compter le plus, et nous allons lui donner un prix dans un instant.

Les quatre manques, avec un prix sur chacun

Le guide sur l’alternative à Kannel parcourt ce qu’un bearer ne fera jamais pour vous. Cet article fait la chose la moins confortable et met un chiffre sur chaque manque. Les estimations ci-dessous supposent un développeur full-stack compétent qui maîtrise déjà SMPP, les accusés de réception et l’argent, un animal plus rare qu’il n’y paraît, et qui se facture en conséquence.

Multi-tenant. Environ 1 à 2 mois de développement. Des comptes, un arbre de revendeurs, des groupes de permissions, l’isolation par client des contacts, des campagnes et des sender ID, et un interrupteur de suspension qui arrête un client sans toucher aux autres. Cela ressemble à un week-end de CRUD, jusqu’au jour où un bug fait fuiter la liste de contacts d’un client dans l’export d’un autre : un appel téléphonique que l’on ne passe qu’une fois.

Facturation. Environ 3 à 6 mois de développement, et c’est là que les projets meurent. Réserver le crédit avant l’envoi, tarifer selon la route réellement empruntée, rembourser correctement sur un échec définitif mais pas sur un échec temporaire, rendre chaque opération idempotente pour qu’une reprise de la file ne facture jamais deux fois, tenir prépayé et postpayé en parallèle, gérer plusieurs devises, et produire une facture qu’un service comptable accepte. Le guide des modèles de facturation décrit la discipline comptable que cela demande. La première version prend un mois et semble terminée. La version qui survit à un client contestant une ligne de 50.00 USD en prend six.

Portails en marque blanche et rapports. Environ 2 à 3 mois de développement. Un panneau à la marque de chaque client : composer, importer une liste, vérifier un solde, sortir un rapport de livraison, consulter une facture. Plus la transformation des événements DLR bruts en quelque chose que le client puisse filtrer et comprendre sans vous appeler. C’est la partie que vos clients touchent tous les jours, donc c’est aussi la partie qui ne peut pas ressembler à un outil interne.

Exploitation et l’impôt éternel. Environ 20 à 30 pour cent du développement, chaque année, indéfiniment. Correctifs de sécurité, une règle de modèles WhatsApp qui a changé, un opérateur qui s’est mis à renvoyer un nouveau code d’erreur, le développeur qui a écrit votre moteur de facturation et qui part ailleurs en vous laissant un grand livre non documenté. Un logiciel n’est pas un achat d’immobilisation que l’on fait une fois : c’est un animal que l’on nourrit. Tout le monde modélise le développement. Presque personne ne modélise la nourriture.

Additionnez : six à douze mois de développement pour une première version sur laquelle vous mettriez un client payant, plus une ligne de maintenance permanente. C’est le même chiffre que celui de notre guide Kannel, et ce n’est pas un chiffre pour faire peur. C’est ce que coûte ce problème précis, et c’est la raison d’être des plateformes commerciales.

Coût total de possession sur trois ans

Les chiffres, donc. Les deux colonnes ci-dessous supposent la même activité : un revendeur avec des clients à facturer, sur son propre serveur. La fourchette de coût du développeur va d’un prestataire compétent sur un marché émergent, autour de 3,000 USD par mois, jusqu’à un recrutement européen ou nord-américain autour de 8,000 USD par mois, un écart réellement énorme et la première raison pour laquelle cette décision ne se pose pas de la même façon à Abidjan qu’à Paris.

Poste, 3 ans	Open source, construit	Smppcube v9
Licence logicielle	0 USD	6,400 USD, une fois
Serveur, de 40 à 80 USD par mois	De 1,440 à 2,880 USD	De 1,440 à 2,880 USD
Construire la couche manquante, de 6 à 12 mois de développement	De 18,000 à 96,000 USD	0 USD
Maintenance, années 2 et 3	De 7,200 à 38,400 USD	Votre propre temps d’exploitation
Support quand un bind tombe	Bonne volonté de la communauté	Inclus
Total en trésorerie sur trois ans	De 26,640 à 137,280 USD	De 7,840 à 9,280 USD

Avant que quiconque nous écrive : oui, le bas de cette colonne open source est atteignable. Si le développeur, c’est vous, et que votre temps n’a pas de prix de marché parce que vous auriez de toute façon été assis à ce bureau, la colonne du développement s’effondre vers le coût de votre serveur et de votre patience. C’est un scénario réel et nous le disons deux sections plus bas. Ce que ce n’est pas, c’est gratuit. Ce sont six à douze mois de votre vie professionnelle, dépensés en infrastructure plutôt qu’en clients, et payés dans la seule monnaie que vous ne pourrez pas facturer ensuite.

Et regardez la forme des deux colonnes, pas seulement les totaux. L’une est un petit nombre fixe, entièrement connu dès le premier jour. L’autre est une fourchette avec un facteur cinq d’écart, sans date de fin, et avec une traîne qui ne s’arrête jamais. Dans une activité bâtie sur des marges fines au message, la colonne prévisible vaut déjà quelque chose en soi.

La ligne que personne ne met dans le tableur

Voici le chiffre qui écrase tout ce qui précède, et qui n’apparaît jamais dans les comparatifs « faire ou acheter » que les gens publient sur les forums.

Reprenez le calcul de coin de table du guide de la revente : dix clients de taille moyenne à 300 000 messages par mois en moyenne, cela fait 3 000 000 de messages, et à un écart de 0.0030 USD cela donne 9,000 USD de marge brute chaque mois. Maintenant, retardez de six mois le jour où vous pouvez intégrer le client numéro un, pendant que vous construisez un moteur de facturation. Cela fait 54,000 USD de marge qui n’ont jamais existé, et c’est le cas optimiste, car il suppose que les clients vous attendent. Ils ne vous attendent pas. Ils signent avec l’opérateur qui était prêt en mars.

Voilà pourquoi le délai jusqu’au premier revenu a sa place dans le tableau comparatif, et pourquoi nous l’y avons mis. Chaque mois de développement est un mois sans vendre, sur un marché où la douve défensive n’est pas la technologie du tout : c’est la qualité des routes, le service, et l’adhérence d’un client dont les systèmes sont déjà câblés à votre API. Aucune de ces trois choses ne se gagne en écrivant un grand livre de crédits. Elles se gagnent en ayant des clients, ce qui exige de pouvoir prendre des clients, ce qui est précisément la chose devant laquelle le développement se tient.

Le contrepoint, dit honnêtement : cet argument ne mord que si vous avez réellement des clients qui attendent. Si vous êtes encore en train de prouver la demande, un lancement retardé ne vous coûte rien puisqu’il n’y avait pas de revenu à retarder. Ce qui nous amène à la section vers laquelle tout cet article se dirigeait.

Quand l’open source reste le bon choix

Nous préférons perdre la vente plutôt que vous vendre 6,400 USD de logiciel dont vous n’aviez pas besoin. Quatre cas où le gratuit est correct.

Vous êtes un locataire unique et vous n’avez personne à facturer. Une entreprise, un opérateur, vos propres systèmes envoyant vos propres messages. Pas d’arbre de revendeurs, pas de soldes clients, pas de factures, pas de portail. Kannel plus quelques scripts est la bonne réponse, et une plateforme multi-tenant est un poids que vous porteriez pour rien. C’est le cas le plus fréquent où nous vous disons de ne pas acheter.

Vous êtes encore en train de valider le marché. Aucun client pour l’instant, aucun contrat signé, juste une hypothèse. Une passerelle gratuite et un tableur font un pilote parfaitement respectable, et cela vous coûte un week-end de découvrir si quelqu’un acceptera de vous payer. Achetez la plateforme quand la réponse est oui, pas avant.

Le logiciel de passerelle est votre produit. Certaines équipes construisent une plateforme de messagerie pour la vendre, ou ont une exigence réellement inhabituelle qu’aucun produit commercial ne modélise. Si le logiciel est l’activité plutôt qu’un impôt sur l’activité, bien sûr que vous le construisez. Le construire est le sujet.

Vos volumes et vos marges sont minuscules. Quelques milliers de messages par mois avec un écart faible n’amortiront une licence dans aucun horizon raisonnable, et n’amortiront pas non plus six mois de développement. Restez petit, restez gratuit, et soyez honnête avec vous-même sur lequel des deux vous êtes.

Remarquez que trois de ces quatre cas sont le même test habillé différemment : la couche commerciale est-elle votre produit, ou est-elle la chose qui se tient entre vous et votre produit ?

Décider cela en un après-midi

Vous n’avez pas besoin d’un consultant. Vous avez besoin de quatre réponses honnêtes, écrites là où vous ne pourrez pas les arranger plus tard.

Premièrement, avez-vous des clients à facturer ? Si non, arrêtez-vous, utilisez Kannel, revenez quand la réponse changera. Si oui, la couche commerciale n’est pas optionnelle et la seule question est de savoir qui l’écrit.

Deuxièmement, combien vaut réellement un mois de développement pour vous ? Prenez un vrai chiffre : ce que vous paieriez quelqu’un, ou ce que vous pourriez gagner avec ces heures en faisant autre chose. Si votre réponse est « rien, je fais ça par plaisir », c’est une réponse légitime, et la colonne du développement vient de devenir très bon marché. Écrivez-la quand même, car elle change dès que vous êtes vraiment occupé.

Troisièmement, combien coûte un mois de retard ? Multipliez votre marge brute mensuelle attendue par les mois de développement. Si ce nombre est plus grand qu’une licence, le débat est déjà terminé et aucun raffinement du tableur ne le ramènera.

Quatrièmement, qui répond à deux heures du matin ? Pas qui le corrigera un jour. Qui prend le problème en charge pendant que l’envoi nocturne des relevés d’un client est en train d’échouer. Si la réponse est « moi, et je suis aussi la seule personne qui comprenne le code de facturation que j’ai écrit », donnez-lui un prix honnête. C’est une personne, pas une ligne budgétaire, et c’est la contrainte qui plafonne silencieusement votre taille maximale.

Ensuite, décidez, et soyez en paix avec votre décision. Si les quatre réponses pointent vers l’open source, vous avez notre bénédiction et notre respect, et le guide de la passerelle auto-hébergée vous dira à quoi vous vous engagez sur le plan de l’exploitation. Si elles pointent dans l’autre sens, ce que vous achetez n’est pas vraiment du logiciel. Ce sont les six à douze mois que vous récupérez pour les passer sur vos clients, livrés sous forme de licence unique sur votre propre serveur, avec la couche multi-tenant, la facturation et les portails déjà écrits, et Kannel toujours en dessous, à faire le travail dans lequel il a toujours été bon.