Optimiser son budget et maîtriser les coûts grâce aux SMS automatisés

Time to read:

April 21, 2026

Rédigé par

Amanda Lange

Twilion

Révisé par

Dylan Frankcom

Twilion

Optimiser son budget et maîtriser les coûts grâce aux SMS automatisés

Imaginez que votre entreprise s’apprête à lancer une nouvelle campagne SMS auprès de ses utilisateurs. Vous préparez un message marketing de 150 caractères et l’envoyez à 100 000 destinataires. En toute logique, vous prévoyez donc d’être facturé pour 100 000 segments. Mais lorsque la facture arrive, mauvaise surprise : le montant est trois fois plus élevé que prévu. Pourquoi une telle différence ? Tout simplement parce que votre message marketing contenait des emojis, des guillemets typographiques ou d’autres caractères spéciaux qui, sans en avoir l’air, peuvent sensiblement augmenter le coût de vos envois.

Les messages enrichis et les services RCS (Rich Communication Services ou services de communication enrichie) peuvent vous aider à rendre vos communications marketing plus attrayantes et à mieux capter l’attention de vos destinataires. Mais pour une petite entreprise dont le budget marketing est compté, l’objectif reste de créer des campagnes efficaces sans découvrir, au moment de la facturation, des coûts bien supérieurs à ceux qui avaient été prévus pour ses envois de SMS automatisés. Même au sein des grandes entreprises, la maîtrise des coûts reste un enjeu essentiel. Quelle est donc l’origine de cet écart de facturation, et quelles mesures permettent de l’éviter ? La suite de cet article revient sur les principales causes de ces surcoûts et présente plusieurs solutions susceptibles de les prévenir.

Pourquoi votre facture SMS peut-elle être plus élevée que prévu ?

Voici la raison technique pour laquelle le coût de vos SMS augmente dès qu’un message contient un emoji ou certains caractères spéciaux.

Les SMS utilisent l’encodage GSM-7, un système hérité des débuts des réseaux mobiles. Pour permettre la transmission de caractères alphanumériques dans les messages texte, 128 caractères ont à l’origine été associés à des valeurs numériques pouvant être acheminées sur le réseau. Cette correspondance entre caractères et valeurs numériques est ce que l’on appelle l’encodage des caractères.

Il existe toutefois une contrainte importante. Dès lors qu’un message contient un caractère absent du jeu de caractères GSM-7, par exemple un emoji, un caractère appartenant à une écriture non latine ou un guillemet typographique, l’intégralité du message est encodée sur 16 bits. Ce mode d’encodage est appelé encodage de caractères UCS-2. Lorsque ce basculement n’est pas intentionnel, il peut avoir une incidence directe sur la segmentation et, par conséquent, sur le coût d’envoi.

Le passage de GSM-7 à UCS-2 augmente en effet l’espace occupé par chaque caractère dans les données transmises, ce qui diminue la capacité disponible dans chaque segment SMS. Twilio envoie les SMS sous forme de segments, à ne pas confondre avec notre solution Twilio Segment ! Chaque segment peut contenir jusqu’à 160 caractères avec l’encodage GSM-7, contre seulement 70 avec l’encodage UCS-2. Twilio ajoute par ailleurs un en-tête de données utilisateur (User Data Header, UDH) de 6 octets au début des messages segmentés. Cet en-tête fournit à l’appareil destinataire les informations nécessaires pour reconstituer les différentes parties du message dans le bon ordre. Une fois cet espace réservé, la capacité utile de chaque segment est ramenée à 153 caractères en GSM-7 et à 67 caractères en UCS-2. Dès que votre message dépasse l’une de ces limites, il est réparti sur plusieurs segments. Et comme chaque segment supplémentaire peut être facturé, la note peut rapidement dépasser le montant que vous aviez prévu.

Caractères susceptibles de modifier l’encodage

Les emojis sont l’un des responsables les plus faciles à identifier. Ajoutez-en un à votre SMS et le message bascule automatiquement vers l’encodage UCS-2, puisque les emojis ne figurent pas dans le jeu de caractères GSM-7 standard. Ce cas reste néanmoins relativement simple à identifier. D’autres caractères, moins immédiatement visibles, peuvent également entraîner une modification de l’encodage du SMS, parmi lesquels :

Guillemets typographiques et apostrophes : un simple copier-coller depuis Google Docs peut suffire à introduire ce type de caractère. Les guillemets typographiques incurvés, qui paraissent parfaitement anodins à l’écran, sont pourtant considérés comme des caractères non standard et peuvent faire basculer tout le SMS vers l’encodage UCS-2. Le même principe s’applique aux apostrophes typographiques. Celles-ci peuvent être remplacées par des apostrophes standard sans incidence perceptible pour le destinataire. En revanche, leur présence peut avoir un impact sur l’encodage du message et, par conséquent, sur son coût de transmission.

Tirets longs :il y a ensuite le fameux tiret cadratin (—), devenu presque incontournable dans les textes rédigés ou reformulés à l’aide de l’IA. Aussi élégant soit-il, ce simple signe de ponctuation peut poser problème s’il n’est pas remplacé avant l’envoi. L’erreur est d’autant plus facile à commettre que les outils d’IA et les fonctions de correction automatique ont tendance à l’insérer spontanément. La solution est pourtant simple : remplacez le tiret cadratin par un trait d’union (-). Vous réduisez ainsi le risque de faire basculer votre message vers un encodage moins avantageux et conservez davantage de place pour le contenu de votre SMS.

Accents : La prise en charge des caractères accentués varie selon les caractères concernés. Ils sont naturellement plus fréquents dans les communications rédigées dans des langues autres que l’anglais. Certains, comme pour « é », sont inclus dans le jeu de caractères GSM-7, tandis que d’autres, comme « â », peuvent entraîner le passage à l’encodage UCS-2. En cas de doute sur la compatibilité d’un caractère spécial, consultez la table des caractères GSM-7 disponible dans la documentation Twilio afin de vérifier s’il est pris en charge.

S’appuyer sur les outils Twilio pour éviter les changements d’encodage indésirables

Vous connaissez désormais l’origine du problème. Voyons à présent comment l’éviter lors de vos prochains envois.

Plusieurs solutions permettent de vérifier la compatibilité de vos communications avec l’encodage GSM-7 et, par conséquent, de mieux maîtriser les coûts associés à leur envoi.

La méthode la plus simple consiste à analyser votre message avant son envoi à l’aide du Twilio Messaging Segment Calculator. En testant le contenu de votre SMS avant de procéder à l’envoi, vous pouvez déterminer précisément le nombre de segments requis.

L’exemple ci-dessous compare un SMS contenant uniquement du texte à un message enrichi de quelques emojis, afin d’illustrer l’incidence de ces caractères sur le mode d’encodage utilisé.

Message Segment Calculator showing an SMS message in GSM-7.

Message Segment Calculator showing an SMS message in Unicode.

Twilio propose par ailleurs la fonctionnalité Smart Encoding, qui peut être activée ou désactivée pour les SMS.

Smart Encoding se charge automatiquement de remplacer les guillemets typographiques et d’autres caractères susceptibles de poser problème par des équivalents compatibles avec GSM-7. La fonctionnalité est disponible chaque fois que vous utilisez les fonctions d’envoi automatisé de SMS de Twilio. L’option Smart Encoding est visible dans les captures d’écran du Messaging Segment Calculator.

Elle ne supprime pas les emojis, mais convertit certains caractères susceptibles, en l’absence de traitement, d’entraîner un changement d’encodage. L’exemple suivant illustre le fonctionnement de cette option avec l’un de ces caractères particulièrement difficiles à identifier.

Sans smart encoding :

Unfortunately this SMS includes an EM dash and no smart encoding, so it's swapped to Unicode.

Le même message avec Smart Encoding activé :

With smart encoding, this is a GSM-7 message. Screenshot of that.

À première vue, le résultat est identique, mais le nombre de caractères disponibles par segment est différent.

Pour profiter de Smart Encoding avec votre service de messagerie Twilio, il vous suffit d’activer l’option correspondante dans le tableau de bord Twilio. Créez tout d’abord un Service de messagerie (Messaging Service), puis rendez-vous dans la section Content Settings (Paramètres de contenu), comme le montre la capture d’écran ci-dessous. Assurez-vous que l’option Smart Encoding soit bien activée, avec le paramètre défini sur On/Activé.

Gérer les caractères directement dans votre code

Il est également possible de gérer le remplacement des caractères directement au niveau du code de votre application, sans dépendre exclusivement des fonctionnalités proposées par votre service de messagerie. Deux approches principales permettent de traiter les caractères susceptibles d’entraîner un surcoût dans les SMS automatisés : Le remplacement, qui consiste à substituer aux caractères non pris en charge par GSM-7 des équivalents compatibles avec cet encodage afin d’éviter des coûts supplémentaires, et le calcul, qui permet d’estimer le coût d’envoi d’un message et d’avertir l’utilisateur des frais correspondants.

Méthode de normalisation des caractères GSM-7

En programmation défensive, prévoir une méthode de normalisation des caractères, souvent appelée «∘Sanitizer », est une bonne pratique bien établie. Elle permet notamment de traiter les caractères susceptibles de poser problème avant qu’ils n’aient des conséquences sur le fonctionnement de votre application ou, dans le cas des SMS, sur les coûts d’envoi. Si vous développez avec .NET 10, vous disposez des fonctionnalités de C# 14 et d’outils performants, comme ReadOnlySpan<char> et les mécanismes optimisés de construction de chaînes de caractères, qui vous permettent de mettre en œuvre ce type de traitement sans compromettre les performances de votre application. Si votre application repose sur un autre langage de programmation, les principes fondamentaux et les approches décrits ci-dessous peuvent également servir de référence pour concevoir une solution adaptée à votre environnement technique et aux spécificités de votre projet.

L’exemple suivant présente une méthode susceptible d’être intégrée à votre code. Cette méthode permet d’identifier les caractères fréquemment responsables d’une augmentation des coûts d’envoi et de les remplacer par des équivalents pris en charge par l’encodage GSM-7.

using System;
using System.Text;
using System.Text.RegularExpressions;

public static class SmsSanitizer
{
   // Basic GSM-7 character set (simplified example)
   private const string GsmBasic = "@£$¥èéùìòÇ\nØø\rÅåΔ_ΦΓΛΩΠΨΣΘΞ ÆæßÉ !\"#¤%&'()*+,-./0123456789:;<=>?¡ABCDEFGHIJKLMNOPQRSTUVWXYZÄÖÑÜ§¿abcdefghijklmnopqrstuvwxyzäöñüà";
   public static string Sanitize(ReadOnlySpan<char> input)
   {
       // Use Span<char> for the buffer to avoid multiple allocations
       Span<char> output = stackalloc char[input.Length];
       int outputIdx = 0;
       foreach (char c in input)
       {
           char replacement = c;
           // Handle special characters with their GSM-7 safe equivalents
           if (c == '\u201C' || c == '\u201D') // Left and right double quotes
               replacement = '"';
           else if (c == '\'' || c == '\u2018' || c == '\u2019') // Single quotes and apostrophes
               replacement = '\'';
           else if (c == '\u2014' || c == '\u2013') // Em dash and en dash
               replacement = '-';
           // Add the character if it's in GSM-7 basic set, otherwise add the replacement or '?'
           if (GsmBasic.Contains(replacement))
           {
               output[outputIdx++] = replacement;
           }
           else
           {
               // If replacement isn't in GSM-7 either, use '?'
               output[outputIdx++] = '?';
           }
       }
       return new string(output[..outputIdx]);
   }
}

Elle peut être intégrée directement à votre webhook ou au contrôleur chargé de la gestion de vos campagnes.

app.MapPost("/api/validate-sms", (string messageBody) => {
    var sanitized = SmsSanitizer.Sanitize(messageBody);
    var stats = GetMessageStats(sanitized);
    return Results.Ok(new {
        Original = messageBody,
        Sanitized = sanitized,
        EstimatedSegments = stats.Segments,
        EncodingUsed = stats.Encoding,
        PotentialSavings = "If this contained smart quotes, we just saved you money!"
    });
});

Logique de calcul du nombre de segments

Pour informer les utilisateurs des éventuels surcoûts avant l’envoi de leurs messages, il est nécessaire de déterminer si les caractères présents dans le contenu entraînent un basculement vers l’encodage UCS-2. Cette approche implique de développer un outil capable de calculer le nombre de segments requis pour la transmission d’un SMS, selon un principe similaire à celui du calculateur proposé par Twilio. Pour repérer les caractères susceptibles de poser problème, cette méthode utilise une expression régulière (Regex) qui analyse le contenu de votre SMS à la recherche de caractères spéciaux.

Gardez à l’esprit les limites de caractères propres à chaque encodage :

GSM-7 : jusqu’à 160 caractères pour un SMS tenant sur un seul segment, contre 153 caractères par segment lorsque le message en nécessite plusieurs (7 caractères étant réservés aux en-têtes de segmentation).
UCS-2 : jusqu’à 70 caractères pour un SMS tenant sur un seul segment, contre 67 caractères par segment pour les messages plus longs (3 caractères étant réservés aux en-têtes).

public static (int Segments, string Encoding) GetMessageStats(string text)
{
    // Regex for characters NOT in the GSM-7 basic or extended sets
    // (Simplified for this example)
    bool isUcs2 = Regex.IsMatch(text, @"[^a-zA-Z0-9\s!""#\$%&'()\*\+\,\-\.\/\:\;\<\=\>\?\@\[\\\]\^_\{\|\}\~¡£¥§¿äöñüàèéìòùò]");
    int limit = isUcs2 ? 70 : 160;
    int multiLimit = isUcs2 ? 67 : 153;
    if (text.Length <= limit) return (1, isUcs2 ? "UCS-2" : "GSM-7");
    int segments = (int)Math.Ceiling((double)text.Length / multiLimit);
    return (segments, isUcs2 ? "UCS-2" : "GSM-7");
}

La méthode présentée plus haut repose sur un principe simple : plutôt que de rechercher les caractères autorisés, elle utilise une expression régulière négative pour identifier tous ceux qui ne figurent pas dans la plage de caractères définie comme compatible. Vous pouvez ainsi savoir immédiatement si votre message contient des caractères susceptibles de provoquer un changement d’encodage et, potentiellement, une augmentation des coûts d’envoi. Et avant de cliquer sur « Envoyer », gardez ce dernier conseil à l’esprit : en cas de doute, mieux vaut vérifier deux fois plutôt que de découvrir une mauvaise surprise sur votre facture ! Cette précaution pourrait bien vous éviter de mauvaises surprises au moment de recevoir votre facture.

Gardez toutefois à l’esprit que les méthodes présentées ici ne sont que des exemples : vous devrez les adapter et les intégrer à votre propre environnement technique. Que vous travailliez sur une application console .NET, une API web ou le backend d’un plugin Twilio Flex, ces méthodes peuvent trouver leur place dans votre architecture. Les outils intégrés de Twilio constituent déjà une solution efficace pour la plupart des applications, mais développer votre propre logique de traitement vous offre davantage de liberté pour adapter le fonctionnement de vos messages et garder la maîtrise des résultats obtenus.

Conclusion

Un bon message marketing sait aller à l’essentiel. Mais pour qu’il soit aussi peu couteux, encore faut-il qu’il utilise des caractères compatibles avec l’encodage GSM-7. En maîtrisant les principes de comptage des caractères et de segmentation des SMS, vous pouvez désormais déterminer plus précisément le nombre de segments nécessaires à chaque envoi et identifier les possibilités de réduction des coûts. Cette meilleure visibilité sur les volumes facturables vous permettra de planifier le lancement de vos campagnes en toute sérénité, tout en limitant les risques de dépenses imprévues.

Envie d’aller plus loin dans l’utilisation des SMS automatisés ou de découvrir comment tirer pleinement parti du marketing par SMS ? Retrouvez d’autres conseils, explications et bonnes pratiques dans les ressources proposées sur le blog Twilio :

Ensemble, créons des solutions innovantes qui font toute la différence !

Amanda Lange est ingénieure .NET spécialisée dans la conception et la rédaction de contenus techniques. Elle accompagne les développeurs dans leur apprentissage des technologies C# et .NET afin de les aider à concevoir et à créer des applications performantes. Elle est joignable à l’adresse amlange [ at] twilio.com.

Résumé généré par l’IA

L’utilisation de caractères spéciaux dans les SMS peut en effet entraîner une hausse des coûts en provoquant le passage de l’encodage GSM-7 à l’encodage UCS-2.
Parmi les pièges les plus courants figurent les emojis, les guillemets typographiques, les tirets longs et certains caractères accentués.
Les outils Twilio, notamment Messaging Segment Calculator et Smart Encoding, permettent d’optimiser la composition des SMS afin de mieux maîtriser les coûts associés à leur envoi.

Ce résumé a été généré par l’IA.