Introduction : traitez la délivrabilité comme un uptime, pas comme une métrique vanité

La plupart des équipes ne regardent la délivrabilité SMS qu'une fois par mois, sous la forme d'un simple pourcentage.

« Ça a l'air correct, on est autour de 95 %. »

Pendant ce temps :

Un opérateur américain commence à filtrer silencieusement un nouveau flux promotionnel.
Une séquence OTP critique commence à échouer à 2 heures du matin.
Un pool de numéros « burner » s'essouffle et les codes d'erreur grimpent discrètement.

Le temps que quelqu'un s'en rende compte, vous avez déjà :

Perdu 5 à 6 chiffres de revenu à cause de paniers ou de dépôts abandonnés.
Endommagé la confiance (« je n'ai jamais reçu le code, votre application est cassée »).
Appris aux opérateurs à considérer votre marque comme bruyante ou risquée.

Dans notre travail de triage de centaines d'incidents de délivrabilité, le schéma est clair : les équipes qui traitent la délivrabilité comme de la fiabilité de production (SRE) se rétablissent vite. Celles qui la traitent comme une métrique vanité hebdomadaire se font surprendre.

Ce guide vous montre comment :

Choisir les bons KPI (et ignorer ceux qui trompent).
Segmenter les données par opérateur, pool d'expéditeurs, route et campagne.
Construire un dashboard et un système d'alerting qui détecte les problèmes tôt.
Utiliser la supervision pour améliorer la délivrabilité, pas seulement la constater.

Section 1 : les KPI de délivrabilité SMS qui comptent vraiment

Vous n'avez pas besoin de 40 métriques. Vous avez besoin d'un petit ensemble de KPI directement corrélés aux incidents et à leur résolution.

1. Taux de délivrance (par opérateur, pool, campagne)

Définition :

Taux de délivrance = messages avec accusé de réception « delivered » positif ÷ total des tentatives d'envoi

Bonne pratique :

Toujours segmenter par :
- Opérateur (Verizon, AT&T, T-Mobile, opérateurs internationaux)
- Pool / grid d'expéditeurs
- Campagne / flux (OTP, promotions, transactionnel)
- Pays / région

À quoi ressemble un « bon » résultat (A2P américain, correctement configuré) :

Flux transactionnels critiques : 99 % et plus
Promotions à fort volume : 98 à 99 % et plus
Tout ce qui reste durablement sous 97 à 98 % mérite une investigation.

2. Taux d'échec définitif (« hard-fail ») / taux d'erreur

Définition :

Pourcentage de messages avec des codes d'échec définitifs :
- Numéro invalide
- Abonné inconnu
- Rejet permanent de l'opérateur

Pourquoi c'est important :

Une hausse des hard-fails signifie souvent :
- Une mauvaise hygiène de liste.
- Un blocage côté opérateur visant des expéditeurs ou contenus spécifiques.
- Un pool de numéros fatigué ou « grillé ».

À surveiller :

Des sauts soudains sur un seul opérateur.
Des routes ou pools spécifiques avec un taux de hard-fail persistant supérieur à 1-2 %.

3. Taux d'échec temporaire (« soft-fail ») / taux de retry

Définition :

Échecs temporaires :
- Problèmes réseau
- Congestion
- Limitation de débit / throttling

Pourquoi c'est important :

Un taux élevé de soft-fails signifie que vous sollicitez trop les opérateurs ou que vous frappez des routes congestionnées.
Cela révèle si votre stratégie de retry fonctionne ou si elle ne fait que marteler le réseau.

4. Indicateurs « inconnu » / filtré / « fausse délivrance »

Les opérateurs ne donnent pas toujours un code « filtré ». Certains :

Renvoient des erreurs génériques.
Annoncent « delivered » alors que les appareils ne reçoivent rien (filtrage fantôme, ou « shadow filtering »).

Indicateurs indirects à surveiller :

Des baisses dans le comportement en aval (clics, connexions) malgré des accusés de réception « OK ».
Tests d'échantillonnage : des numéros sentinelles sur chaque opérateur que vous journalisez séparément.
Des chutes de performance soudaines sur de nouvelles campagnes alors que les autres restent stables.

5. Santé des pools et des grids

Si vous utilisez :

Des pools de numéros burner
Des Private Pool Grids
Ou même de simples numéros dédiés

… vous devez suivre, par pool/grid :

Le taux de délivrance
Le taux de hard-fail
Le taux de plaintes / désinscription
Le nombre de messages quotidiens par expéditeur

Schémas sains :

Une performance stable dans le temps.
Aucun expéditeur ne dépassant :
- Plus de 1 % de hard-fail sur une fenêtre de 24 heures.
- Plus de 0,3 à 0,5 % de plaintes / désinscriptions sur les promotions.

Section 2 : le « cube de délivrabilité », comment segmenter vos données

Un seul « taux de délivrance » global cache tout.

Vous avez besoin d'un cube de délivrabilité :

Opérateur (Verizon, AT&T, T-Mobile, etc.)
Expéditeur (pool, grid, numéro individuel)
Route / produit (gateway, région)
Campagne / flux (OTP, promotions, transactionnel)
Niveau de risque du contenu (grand public, à haut risque, SHAFT)

Exemple de segmentation qui révèle de vrais problèmes

Verizon × Promo × Grid A :
- Le taux de délivrance chute de 99,1 % à 94,4 % en 48 heures.
- Les hard-fails et soft-fails sont légèrement en hausse.
- Les autres opérateurs restent stables.
Action :
- Basculer les promotions du Grid A vers le Grid B pour Verizon.
- Examiner les changements de contenu récents et les schémas de vélocité.
- Réduire temporairement le volume au niveau de référence + 20 % pendant les tests.

Sans segmentation, vous ne verriez que :

Taux de délivrance global : 97,8 % → 96,9 % (on hausse les épaules).

Avec segmentation, vous voyez :

Une seule combinaison de la matrice est en train de s'effondrer alors que les autres sont saines.

Section 3 : seuils d'alerte et actions à mener quand elles se déclenchent

1. Alertes sur le taux de délivrance par opérateur

Seuils recommandés (à ajuster selon votre référence) :

Déclencher une alerte si le taux de délivrance sur un opérateur majeur :
- Chute de plus de 2 points par rapport à la médiane sur 7 jours.
- Ou tombe sous 97 % pendant plus de 30 à 60 minutes sur un trafic actif.

Procédure (runbook) :

Confirmer qu'il ne s'agit pas d'un artefact de données (dashboards, logs bruts).
Vérifier :
- Les déploiements récents (changements de contenu, changements de routage).
- Les nouveaux lancements de campagnes.
- Les pics de volume.
Atténuer :
- Réduire temporairement la vélocité d'envoi sur cet opérateur.
- Basculer vers un pool / grid alternatif si disponible.
- Suspendre les nouvelles campagnes à risque pour cet opérateur.

2. Alertes sur la santé des pools / grids

Déclencher une alerte quand :

Le taux de hard-fail d'un pool ou d'un grid dépasse 1 à 2 % pendant plus d'une heure sur un volume significatif.
Le taux de plaintes / désinscriptions dépasse 0,3 à 0,5 % sur les promotions.

Procédure (runbook) :

Arrêter d'envoyer de nouvelles campagnes sur ce pool / grid.
Basculer une partie du trafic vers des pools plus sains.
Investiguer :
- Avez-vous mélangé du contenu plus risqué sur un pool jusque-là propre ?
- Les politiques de l'opérateur ont-elles changé (par exemple, nouvelle règle sur les mots-clés SHAFT) ?

3. Alertes de filtrage fantôme et de « fausse délivrance »

Comme vous ne verrez pas toujours des codes d'erreur clairs :

Comparez :
- Messages délivrés → conversions attendues (clics, connexions, utilisations d'OTP).
Déclenchez une alerte quand :
- La délivrabilité reste « bonne » mais la conversion en aval chute fortement pour un opérateur ou une campagne donnée.

C'est là que :

Les numéros sentinelles par opérateur sont précieux.
Des tests en conditions réelles périodiques (manuels + automatisés) permettent de vérifier la réalité par rapport aux accusés de réception.

Section 4 : concevoir le dashboard de délivrabilité SMS

Votre dashboard n'a pas besoin d'être sophistiqué. Il doit être utile sous pression.

Disposition 1 : vue d'ensemble exécutive

Tuiles de premier niveau :

Taux de délivrance global (dernières 24 h, 7 j)
Taux de délivrance par opérateur (Verizon, AT&T, T-Mobile, top 3 à 5 internationaux)
% de messages par :
- Transactionnel vs marketing
- Grand public vs à haut risque

Tendances :

Graphiques en courbes :
- Taux de délivrance par opérateur dans le temps.
- Volume par opérateur.

Utilisez cette vue pour répondre à : « Sommes-nous en train de brûler, oui ou non ? »

Disposition 2 : vue opérations / SRE

Tableaux et graphiques par :

Opérateur × Pool × Campagne
Métriques de santé des pools (délivrance, hard-fail, soft-fail, plaintes)

Exemples :

Heatmap : taux de délivrance par opérateur (colonnes) et pool/grid (lignes).
Tableau triable :
- « Afficher les pools avec le taux de hard-fail le plus élevé aujourd'hui. »

Utilisez cette vue lorsqu'une alerte se déclenche.

Disposition 3 : vue analytique / marketing

Se concentre sur :

Performance des campagnes :
- Taux de délivrance vs CTR vs conversion.
Tests A/B :
- Variantes de contenu vs délivrabilité.

Cette vue relie délivrabilité et revenu, ce qui facilite la justification des décisions d'infrastructure.

Section 5 : diagnostiquer les problèmes courants à partir de vos métriques

Scénario 1 : un opérateur s'effondre, les autres restent stables

Causes probables :

Filtrage spécifique à l'opérateur sur :
- Le motif du contenu.
- Le domaine de l'URL.
- La réputation du pool d'expéditeurs.

À vérifier :

Des changements récents de contenu ou de template ?
De nouvelles URL utilisées ? (par exemple, changement de raccourcisseur de lien)
La montée en volume : avez-vous accéléré trop vite sur cet opérateur ?

Scénario 2 : tous les opérateurs se dégradent en même temps

Causes probables :

Changement de contenu global (par exemple, des promotions plus agressives).
Montée en volume agressive sur l'ensemble du trafic.
Changement au niveau de la plateforme (routage, logique de pool).

À vérifier :

Les derniers déploiements.
Les nouvelles campagnes à haut risque.
Si les contrôles (logique burner, plafonds par opérateur) sont réellement appliqués.

Scénario 3 : les métriques semblent bonnes, mais le support reçoit des « je ne l'ai pas reçu »

Causes probables :

Filtrage au niveau de l'appareil (dossiers spam).
Filtrage fantôme au niveau de l'opérateur avec des accusés de réception trompeurs.
Zones régionales affectées (par exemple, certains indicatifs de zone).

À vérifier :

Tests sur appareils sentinelles pour chaque opérateur.
Répartitions par région / indicatif de zone.
Présence de mots-clés ou de motifs sensibles.

Section 6 : comment la supervision de la délivrabilité change vos choix d'infrastructure

Une fois que vous voyez :

Quels pools se dégradent le plus vite
Quels opérateurs sont les plus sensibles
Comment le contenu et le volume affectent les résultats

… il devient évident pourquoi l'infrastructure compte.

Les équipes qui migrent vers :

Des Private Pool Grids (100+ SIM multi-opérateurs par grid)
Des algorithmes de correspondance opérateur (Verizon→Verizon, AT&T→AT&T)
Des pools de numéros burner avec retrait automatisé

… peuvent utiliser leurs dashboards pour :

Rotater et mettre au repos les expéditeurs de manière proactive.
Tester en A/B des stratégies de routage, pas seulement le contenu.
Créer des playbooks par opérateur plutôt que des correctifs génériques.

Nous observons régulièrement :

40 à 60 % d'incidents en moins après le déploiement d'une supervision adéquate et d'un routage basé sur des grids.
Une RCA plus rapide (analyse des causes racines) parce que les logs et les métriques sont alignés.
De meilleures discussions sur le risque avec la conformité et le juridique (« voici exactement comment nous contrôlons les abus et surveillons les plaintes »).

FAQ : métriques et dashboards de délivrabilité SMS

1. Qu'est-ce qu'un « bon » taux de délivrance global ?

Pour un programme sain et bien architecturé :

Flux transactionnels : 99 % et plus
Marketing à fort volume : 98 à 99 %

Tout ce qui est sous 97 à 98 % sur les flux essentiels est un signal d'alerte.

2. À quelle fréquence devons-nous vérifier la délivrabilité ?

Dashboards : quotidiennement (ou plus souvent lors des lancements).
Alertes : en temps réel pour les baisses significatives.
Revues approfondies : hebdomadaires ou mensuelles avec analyse de tendance.

3. Ai-je vraiment besoin de données par opérateur ?

Oui. La plupart des incidents sérieux sont spécifiques à un opérateur. Sans segmentation par opérateur, vous pilotez à l'aveugle.

4. Et pour les petits expéditeurs ? Est-ce excessif ?

Si vous :

Envoyez un faible volume.
Opérez dans des verticales à faible risque.
Ne tirez pas un revenu critique du SMS.

… vous pouvez vous contenter d'une supervision plus simple. Mais dès que le SMS devient un revenu central, vous regretterez de ne pas avoir mis cela en place.

5. Comment démarrer si mon fournisseur actuel n'expose pas de bonnes métriques ?

Options :

Récupérer les CDR / logs et construire votre propre agrégation.
Utiliser des webhooks pour journaliser les DLR dans votre entrepôt de données.
Envisager une gateway qui expose les données au niveau opérateur par conception.

6. Quel est le rapport avec l'enregistrement A2P 10DLC ?

La conformité 10DLC affecte :

Le volume autorisé.
Le niveau de scrutin.
Les sanctions en cas d'abus.

La supervision fournit la boucle de rétroaction qui vous indique si :

Vos campagnes se comportent dans les attentes des opérateurs.
Vous êtes sur le point de franchir un seuil.

7. La supervision peut-elle corriger un mauvais contenu ou un mauvais consentement ?

Non. Elle peut seulement vous dire :

À quel point la situation est mauvaise.
Où elle est mauvaise.

Vous avez toujours besoin d'un opt-in propre, d'une messagerie claire, et du respect de la législation locale.

8. Comment détecter le filtrage spam au niveau de l'appareil ?

Placer des appareils sentinelles sur les différents opérateurs et plateformes (iOS/Android).
Corréler les accusés de réception « delivered » avec les réceptions réelles sur l'appareil et le comportement observé.

9. Où se situe la confidentialité dans tout cela ?

Une gateway privilégiant la confidentialité devrait :

Minimiser les données personnelles (PII) stockées.
Offrir des contrôles clairs de rétention des données.
Fournir malgré tout des métriques agrégées sans exposer de contenu sensible.

10. Ai-je besoin d'un ingénieur dédié à la délivrabilité ?

Pas nécessairement. Mais vous avez besoin :

D'une responsabilité claire (quelqu'un qui en est garant).
De runbooks et de dashboards que des non-experts peuvent suivre en cas d'incident.

Conclusion : rendez la délivrabilité observable avant qu'elle ne devienne coûteuse

On ne peut pas corriger ce qu'on ne voit pas.

Un dashboard de délivrabilité basique associé à un système d'alerting peut :

Détecter les problèmes spécifiques à un opérateur avant qu'ils n'explosent.
Démontrer le ROI d'une meilleure infrastructure (correspondance opérateur, grids privés).
Transformer le SMS d'une boîte noire en un système géré de façon opérationnelle.

Si le SMS est lié à votre revenu, traitez-le comme un problème SRE :

Instrumentez-le.
Mettez des alertes en place.
Construisez des runbooks autour de lui.

Une fois que c'est en place, vous êtes en excellente position pour évaluer si une gateway privée à correspondance opérateur vaut l'investissement, car vous disposerez de données concrètes montrant où votre fournisseur actuel laisse de l'argent sur la table.