Envoyer son premier SMS via l'API d'un fournisseur prend une après-midi. Ce qui suit — décider ce que signifie « envoyé », ce qui se passe quand une requête expire, comment attribuer un message à un résultat business, et ce que coûte un changement de fournisseur — détermine si l'intégration reste maintenable ou devient un impôt permanent.
Un contrat interne stable, pas des appels au SDK du fournisseur
La décision la plus importante est d'éviter que le code applicatif appelle directement le SDK d'un fournisseur. Il vaut mieux définir un contrat interne propre — destination, corps ou template, classe de trafic, expéditeur, référence propre — et laisser tout ce qui est spécifique au fournisseur derrière un adaptateur. Ainsi, ajouter un second fournisseur devient un nouvel adaptateur, pas une réécriture.
Références propres et idempotence face aux timeouts ambigus
Il faut générer une référence propre pour chaque message avant d'appeler le fournisseur, car le cas intéressant est celui où la requête expire sans réponse : le message a peut-être été envoyé ou non. Il convient d'utiliser les clés d'idempotence du fournisseur quand elles existent, ou d'interroger par référence propre avant de réessayer, et de définir une politique explicite par classe de trafic pour les cas ambigus.
Expéditeur, enregistrement et classe de trafic
L'identité de l'expéditeur n'est pas une valeur libre : selon le marché, elle peut exiger un sender ID alphanumérique enregistré, un numéro long ou un short code, avec des délais d'enregistrement de plusieurs semaines. La classe de trafic doit être un champ obligatoire sur chaque envoi, car elle détermine l'expéditeur, la route et si le message est autorisé sur ce marché.
Encodage et segmentation
GSM-7 permet 160 caractères par segment simple ; un seul caractère Unicode — une apostrophe courbe, un emoji, un nom accentué — bascule tout le message en UCS-2, réduisant la limite à 70. La facturation étant au segment, il convient de calculer l'encodage avant l'envoi, de stocker le nombre de segments sur l'enregistrement du message et de valider les templates à l'enregistrement.
Mapping de statuts, webhooks et retries
Chaque fournisseur a son propre vocabulaire de statuts et d'erreurs ; il faut les mapper vers un ensemble canonique propre et traiter les valeurs non reconnues comme une alerte explicite. Les webhooks nécessitent une vérification de signature, une protection contre le replay, une tolérance aux doublons et à l'arrivée désordonnée des événements, et un traitement asynchrone avec une réconciliation périodique des messages bloqués. Les retries doivent avoir un seul responsable de politique, avec des tentatives limitées et une échéance dure au-delà de laquelle le message est abandonné plutôt que livré en retard.
Mesure et sortie du fournisseur
L'accusé de réception est un proxy faible du résultat : il vaut mieux mesurer au niveau applicatif — achèvement de l'action, clics, taux de réponse et de désinscription — avec un identifiant de corrélation couvrant tout le parcours. Flowstates fournit des routes de messagerie et peut opérer cette couche ; les clients peuvent aussi garder leurs propres contrats via BYOV ou combiner les deux modèles sous un contrat opérationnel unique.
Les limites de sécurité du SMS
Le SMS ordinaire n'est pas chiffré de bout en bout : le contenu est visible par les intermédiaires de la chaîne de livraison et stocké en clair sur le téléphone, souvent visible sur l'écran de verrouillage. Il ne faut jamais envoyer de mots de passe, de numéros de compte complets ou de données de santé ; les codes à usage unique doivent être de courte durée, liés à la session qui les a demandés, et jamais accompagnés de l'identifiant de compte.