l existe deux solutions pour envoyer SMS à grande échelle, et elles impliquent des équipes différentes. La première consiste à utiliser une console web pour gérer les campagnes. La seconde utilise une API à intégrer à votre logiciel. Dans les deux cas, le message est envoyé via les mêmes connexions opérateur; la différence réside dans l'entité qui effectue l'envoi et dans le moment où le message est déclenché. Le choix de la solution la plus appropriée dépend principalement de la personne responsable de l'envoi: une personne gérant une liste de contacts ou une application réagissant à un événement.
La console: envoi géré par les gens
Une plateforme SMS en masse est une application web. Vous vous connectez, importez ou sélectionnez une liste de contacts, choisissez un identifiant d'expéditeur, rédigez le message (souvent à partir d'un modèle préenregistré), puis envoyez-le immédiatement ou programmez-le. Les rapports s'affichent sur la même page: messages distribués, échecs, messages en attente, désabonnements. Aucune configuration supplémentaire n'est requise.
Cette solution convient aux équipes marketing et opérationnelles qui gèrent les envois par lots et raisonnent en campagnes: une promotion, un rappel d’événement, une notification à un segment spécifique. L’avantage? Une large diffusion sans intervention technique. Une personne connaissant son audience peut composer, cibler et mesurer un envoi en quelques minutes, puis le répéter la semaine suivante sans avoir à créer de ticket.
L' API: envoi exécuté par le logiciel
Une API SMS en masse est une interface de programmation (généralement REST sur HTTPS, ou SMPP pour les liaisons à haut débit) que votre application appelle pour envoyer un message. Au lieu qu'un utilisateur clique sur « Envoyer », votre code le fait en réponse à un événement: une commande expédiée, une connexion nécessitant un code unique, un rendez-vous prévu le lendemain, un paiement échoué.
Cela convient aux développeurs et aux équipes produit. Le message s'intègre à un flux plutôt que d'être une simple entrée dans un calendrier. Vous envoyez un message à une personne au moment précis, des milliers de fois par jour, sans que personne ne consulte l'écran. Les messages transactionnels et déclenchés (codes, confirmations, alertes) ont toute leur place ici, car ils sont définis par le moment et le contexte, et non par une liste.
Les deux parties partagent la plomberie.
En interne, la console et l' API reposent sur les mêmes mécanismes, et il est utile de savoir à quoi s'attendre de l'une comme de l'autre:
- Les contacts et les listes sont gérés et téléchargés dans la console; via l’ API ils sont généralement envoyés ou référencés par leur ID.
- Les modèles sont des corps de messages réutilisables avec des variables, de sorte que « Bonjour {name}, votre code est {code} » s'affiche pour chaque destinataire, quelle que soit la porte d'entrée.
- Les accusés de réception (DLR) confirment à l'opérateur la réception d'un message sur le terminal. Ils s'affichent sur la console sous forme de statut; l' API les renvoie par rappel ou par interrogation, permettant ainsi à votre système de réagir.
- Des limites de débit et de bande passante s'appliquent à chaque route. Une console gère le rythme de votre campagne; via l' API, vous gérez la concurrence et restez dans les limites de votre compte.
- Le reporting se présente sous la forme d'un tableau de bord dans la console et d'enregistrements bruts via l' API, que vous pouvez stocker et analyser en parallèle de vos propres données.
L'idée est que l' API et la console sont deux portes d'entrée vers une seule couche de diffusion: même routage, même couverture, même gestion du consentement et des options de désabonnement.
Quand on a besoin des deux
La plupart des organisations finissent par utiliser les deux, et c'est généralement la solution idéale. Le principe est simple: l' API gère le trafic transactionnel généré par votre application (codes, reçus, alertes), tandis que la console gère les campagnes menées manuellement par votre équipe marketing. Même compte, mêmes identités d'expéditeur, mêmes rapports: deux interfaces adaptées à deux types de tâches.
Cette répartition des tâches permet également de répartir les responsabilités entre les personnes concernées. Les développeurs ne sont pas sollicités pour chaque envoi promotionnel, et les responsables marketing ne sont pas bloqués en attendant une publication pour modifier une simple phrase publicitaire.
Choisir et passer de l'un à l'autre
Commencez par identifier le responsable de l'envoi. Si une personne décide des envois et des destinataires, commencez par la console: c'est la solution la plus rapide pour obtenir un programme fonctionnel. Si c'est votre logiciel qui gère ces décisions, intégrez l' API. Dans les deux cas, créez un seul compte et utilisez chaque point d'accès en fonction de ses capacités.
La migration est généralement progressive, et non une refonte complète. Les équipes qui commencent par la console et ont ensuite besoin d'automatisation conservent leurs contacts, modèles et identifiants d'expéditeur, puis ajoutent des appels API pour les flux qui doivent être automatisés. Les équipes qui privilégient l'API dès le départ ajoutent souvent la console ultérieurement afin que les collègues non techniques puissent gérer des campagnes sans avoir à déployer de code. Comme les deux plateformes utilisent la même connectivité, passer de l'une à l'autre ne nécessite ni de réobtenir la délivrabilité ni de réapprouver les identifiants d'expéditeur.
BroadNet gère cette couche de distribution depuis 2003, couvrant plus de 200 pays grâce à plus de 1 000 connexions avec des opérateurs. Le choix que nous proposons à nos clients est presque toujours le même: adapter l’interface à l’opérateur d’envoi et utiliser les deux lorsque les deux sont compatibles.