Comment fonctionne une API SMS : principes pour non-tech
Dans ce guide
« On va passer par l’API. » La phrase tombe en réunion, tout le monde hoche la tête et le projet avance. Sauf que la personne qui signe le budget ne sait pas toujours très bien ce qu’elle vient de valider.
Pas besoin de savoir coder pour comprendre comment fonctionne une API SMS. Il suffit de suivre un message depuis le logiciel qui le déclenche jusqu’au téléphone qui le reçoit, et de repérer les quelques endroits où les choses peuvent coincer. C’est l’objet de cet article, qui ne contient pas une seule ligne de code.
Les détails d’intégration, pour les équipes techniques, sont dans notre guide complet de l’API SMS. Ici, on reste du côté de celui qui décide.
Une API, c’est un guichet entre deux logiciels
Commençons par le mot qui intimide. Recherche Data Gouv, la plateforme publique des données de la recherche, en donne une définition qui tient en une ligne : une API est « un ensemble de règles et de fonctionnalités qui permet à deux applications ou systèmes différents de communiquer entre eux ».
Appliquée au SMS, l’image la plus juste reste celle du guichet. Votre logiciel, boutique en ligne, CRM ou outil de prise de rendez-vous, se présente au guichet de la plateforme SMS avec un formulaire rempli selon des règles strictes : qui envoie, à quel numéro, quel texte. Le guichet vérifie que tout est en ordre et que le demandeur est bien identifié. Puis il se charge du reste.
Ce reste, votre logiciel n’a pas à le connaître. Réseaux mobiles, accords entre opérateurs : l’API masque cette complexité, et c’est tout son intérêt.
Pour un décideur, deux conséquences. Une API n’a pas d’écran, ce sont des logiciels qui l’appellent. Et elle ne prend aucune initiative. Si rien ne la sollicite dans vos outils, aucun SMS ne part. La valeur du projet se joue donc dans le choix des déclencheurs bien plus que dans la technique.
Le trajet d’un SMS, du déclencheur au téléphone du destinataire
Un client valide sa commande sur votre site et un SMS de confirmation doit partir. Voici ce qui se passe en coulisses, en quelques secondes le plus souvent.
| Étape | Qui agit | Ce qui se passe | Ce qui peut coincer |
|---|---|---|---|
| 1. Déclenchement | Votre logiciel | La commande validée génère une demande d’envoi | Un événement mal paramétré, et rien ne part |
| 2. Appel de l’API | Votre logiciel | La demande part vers la plateforme par internet, avec une clé d’identification | Clé invalide, numéro mal formaté |
| 3. Contrôles | La plateforme | Vérification de l’identité, du crédit, du numéro et du texte | Crédit épuisé, message trop long |
| 4. Réponse immédiate | La plateforme | Votre logiciel reçoit une réponse « demande acceptée » | Rien, mais ce n’est pas encore une livraison |
| 5. Routage | La plateforme | Le message est transmis au centre SMS de l’opérateur du destinataire | Route de mauvaise qualité, filtrage opérateur |
| 6. Remise | L’opérateur | Le centre SMS stocke le message puis le remet au téléphone | Téléphone éteint, hors réseau, numéro inexistant |
| 7. Compte rendu | L’opérateur puis la plateforme | Un accusé de réception remonte jusqu’à votre logiciel | Accusé tardif, voire absent sur certains réseaux |
Deux étapes méritent qu’on s’y arrête.
L’étape 5, d’abord. Entre la plateforme et l’opérateur, les échanges passent le plus souvent par SMPP, un protocole pensé pour faire circuler des SMS en volume entre applications et centres de messagerie. Sa version 3.4, qui date de 1999, fait toujours référence. Vous n’y toucherez jamais, mais la route empruntée à ce moment-là, directe vers les opérateurs français ou via une cascade d’intermédiaires, pèse lourd sur la délivrabilité de vos messages.
L’étape 6 répond à une question qu’on entend souvent : que devient un SMS envoyé à un téléphone éteint ? Il n’est pas perdu. La norme 3GPP TS 23.040, qui décrit la réalisation technique du SMS, repose sur un principe de stockage puis de remise. Le centre SMS de l’opérateur garde le message et retente la livraison quand le téléphone redevient joignable, pendant une durée de validité limitée. Passé ce délai, le message expire et l’échec vous est signalé.
Votre logiciel ne parle qu’à la plateforme, jamais à l’opérateur. Tout ce qui se passe après l’étape 4 dépend donc de votre fournisseur.
« Accepté », « délivré », « lu » : trois mots à ne pas confondre
C’est le malentendu le plus fréquent entre équipes techniques et équipes métier. Le tableau de bord affiche « OK », le marketing en conclut que le client a vu le message. Pas forcément.
Accepté veut dire que la plateforme a reçu la demande et l’a jugée conforme. Cette réponse arrive tout de suite, pendant que votre logiciel attend. Les développeurs parlent d’échange synchrone : on pose la question, on patiente, on obtient la réponse.
Délivré veut dire que le réseau de l’opérateur a remis le message au téléphone. Cette information arrive plus tard, quelques secondes après en général, beaucoup plus si le téléphone était éteint. C’est un échange asynchrone : la plateforme vous prévient quand elle sait. Le protocole SMPP prévoit ce mécanisme d’accusé de réception, souvent appelé DLR pour « delivery receipt », à condition que l’émetteur l’ait demandé au moment de l’envoi.
Lu, enfin, n’existe pas en SMS. Aucun mécanisme standard ne dit si le destinataire a ouvert le message. Seuls un clic sur un lien ou une réponse prouvent une interaction. Le RCS remonte au contraire des accusés de lecture, l’une des différences concrètes entre RCS et SMS qui comptent au moment de choisir un canal.
Ces comptes rendus arrivent par webhook, que Red Hat définit comme une communication légère, déclenchée par un événement, qui transmet automatiquement des données entre applications via HTTP. Vous donnez une adresse à la plateforme, elle y dépose chaque changement de statut.
Une règle à garder en tête pour vos reportings. Le taux d’acceptation mesure la santé de votre intégration, le taux de délivrance mesure la qualité de la route, et aucun des deux ne mesure l’attention de vos clients.
La clé API, un mot de passe confié à une machine
Au guichet, la plateforme doit savoir qui se présente. Votre logiciel s’identifie avec une clé API, une longue chaîne de caractères générée depuis votre compte.
Ce n’est pas un réglage technique anodin mais un identifiant qui engage votre entreprise. Quiconque la détient peut envoyer des SMS en votre nom, sur votre crédit, avec votre nom d’expéditeur. L’OWASP, fondation de référence sur la sécurité applicative, rappelle d’ailleurs dans son Top 10 de la sécurité des API que ces clés authentifient des applications, pas des utilisateurs.
Sans la manipuler vous-même, exigez trois réponses nettes. Où est-elle stockée ? La bonne réponse ressemble à « sur le serveur, dans un coffre à secrets », jamais « dans le code du site » ou « dans un fichier partagé ». Qui peut la voir ? Le moins de monde possible. Et si elle fuit ? Il faut pouvoir la révoquer et en générer une nouvelle rapidement, sans couper le service.
La plupart des plateformes permettent aussi de limiter une clé aux adresses IP de vos serveurs, ce qui rend une clé volée inutilisable ailleurs. Pour un service en production, ce réglage devrait être activé d’office.
API, interface web ou connecteur no-code : qui fait quoi
L’API n’est pas toujours la bonne réponse. Une interface web ou un connecteur prêt à l’emploi suffit parfois.
| Critère | Interface web | Connecteur no-code | API |
|---|---|---|---|
| Qui l’utilise | Une personne, à la main | Une personne paramètre, l’outil exécute | Un logiciel, en continu |
| Envoi typique | Campagne vers une liste | Envoi déclenché par un outil du marché | Envoi déclenché par votre propre logique métier |
| Compétences requises | Aucune | Aisance avec les outils en ligne | Un développeur |
| Mise en route | Immédiate | Rapide, sans développement | Variable selon le projet |
| Souplesse | Limitée aux fonctions de l’interface | Limitée aux événements prévus par le connecteur | Totale |
| Maintenance | Aucune | Faible | À prévoir dans la durée |
Une campagne promotionnelle mensuelle se gère très bien depuis une interface. Un SMS qui part quand une ligne s’ajoute dans un tableur ou qu’un formulaire est rempli relève plutôt du no-code, avec Zapier ou Make. L’API devient incontournable dès que le message dépend de données que seul votre système connaît : un code d’authentification, le statut d’une commande, une alerte technique. C’est le terrain naturel du SMS transactionnel.
Ce que coûte vraiment un projet d’API SMS
Le prix du SMS s’affiche en haut de toutes les grilles tarifaires. Le coût du projet, lui, se niche ailleurs.
Il y a d’abord le développement. Un premier envoi va vite, mais gérer proprement tout ce qui l’entoure prend nettement plus longtemps : numéros mal saisis à remettre au format international, statuts à enregistrer, échecs à relancer, doublons à éviter quand le réseau coupe au mauvais moment.
Vient ensuite la longueur des messages, que peu de décideurs anticipent. La norme 3GPP TS 23.038 fixe un SMS simple à 160 caractères avec l’alphabet GSM standard. Un seul caractère hors de cet alphabet, un emoji ou même un « ê », fait basculer le message en Unicode, limité à 70 caractères. Au-delà, le texte est découpé en segments de 153 caractères en GSM ou de 67 en Unicode, et chaque segment est facturé comme un SMS. Un modèle rempli automatiquement avec l’adresse du client peut ainsi coûter deux ou trois fois le prix prévu.
Reste la maintenance. Votre site évolue, l’API aussi, un certificat expire. Si personne ne surveille les statuts d’échec, une panne silencieuse peut durer des jours. Et un client qui n’a jamais reçu son SMS de confirmation ne se plaint pas de l’API, il appelle votre service client.
Les questions à poser avant de lancer le projet
Piloter un projet d’API SMS ne demande pas de lire du code. Il suffit de poser les bonnes questions, à votre équipe technique comme à votre fournisseur.
| Question | Pourquoi elle compte |
|---|---|
| Quels événements déclenchent un envoi, et qui les a validés ? | La valeur métier se joue là, tout comme le risque d’envois non voulus |
| Les statuts de délivrance sont-ils récupérés et conservés ? | Sans eux, impossible de savoir si vos clients reçoivent vos messages |
| Que se passe-t-il si l’API ne répond pas ? | Il faut une relance automatique qui n’envoie pas deux fois le même SMS |
| Où est stockée la clé API, et qui y a accès ? | Une clé exposée permet d’envoyer des SMS à vos frais et en votre nom |
| La longueur des messages générés est-elle contrôlée ? | Un texte trop long ou un caractère spécial multiplie la facture |
| Les demandes STOP remontent-elles dans vos outils ? | Un contact désinscrit qui reçoit encore vos offres, c’est une plainte assurée |
| Quelles routes le fournisseur emprunte-t-il vers les opérateurs français ? | La délivrabilité se décide à cette étape, pas dans votre code |
| Un contrat de sous-traitance RGPD est-il signé ? | La plateforme traite vos numéros pour votre compte |
Ce dernier point surprend souvent. Pour la CNIL, le sous-traitant est l’organisme « qui traite des données pour le compte d’un autre organisme », et c’est exactement la position d’une plateforme SMS qui reçoit vos numéros et vos textes. L’article 28 du RGPD impose alors un contrat écrit, pour lequel la CNIL propose des clauses contractuelles types.
Une API SMS, au fond, ne fait qu’une chose : transformer un événement de votre système en message sur un téléphone. Ce qui sépare un projet réussi d’un projet décevant se trouve presque toujours autour, dans le choix des déclencheurs, le suivi des statuts, la rigueur sur la clé et la qualité de la route.
Questions fréquentes sur le fonctionnement d’une API SMS
Faut-il être développeur pour utiliser une API SMS ?
Pour la brancher sur un logiciel maison, oui. Sans développeur, vous pouvez passer par un connecteur no-code comme Zapier ou Make, ou par les modules prêts à l’emploi des CRM et des solutions e-commerce.
Un SMS délivré a-t-il forcément été lu ?
Non. Le statut « délivré » indique que le téléphone a reçu le message, pas que son propriétaire l’a ouvert. Le SMS ne dispose d’aucun accusé de lecture standard. Seuls un clic sur un lien ou une réponse prouvent une interaction.
Que devient un SMS envoyé à un téléphone éteint ?
Le centre SMS de l’opérateur le conserve et retente la remise dès que le téléphone redevient joignable, pendant une durée de validité limitée. Au-delà, le message expire et un statut d’échec vous est remonté.
Une plateforme d’API SMS est-elle concernée par le RGPD ?
Oui. Elle traite des numéros de téléphone et des contenus de messages pour le compte de ses clients, ce qui en fait un sous-traitant au sens de l’article 28 du RGPD. Un contrat encadrant ce traitement doit être signé entre l’entreprise émettrice et la plateforme.