Monitorer et logger vos envois SMS en production : ce qu'il faut suivre absolument

Si vous ne surveillez pas vos logs de production, vous découvrirez qu'une campagne a échoué uniquement quand vos clients appelleront le support en masse. Voici les principes d'observabilité technique (SRE) à appliquer à vos flux d'envoi API SMS.

Ne vous contentez pas de vérifier le nombre total de messages envoyés. Vous devez extraire des ratios clés (KPIs) à partir de vos Webhooks DLR.

1. Le Taux de Délivrance Global (Delivery Rate) :
C'est le pourcentage de messages ayant reçu le statut Delivered divisé par le total de messages acceptés par l'API.

• Benchmark sain : > 92%.
• Action : S'il chute sous les 85%, c'est souvent un problème de qualité de votre base de données (numéros inactifs) ou d'un filtrage actif par l'opérateur.

2. Le Taux d'Erreur (Hard Bounce Rate) :
Pourcentage de SMS retournant un Failed ou Rejected.

• Benchmark sain : < 5%.
• Action : Purgez impérativement les numéros Failed (invalides) de votre CRM. Les conserver détruit le Trust Score de votre Sender ID.

3. La Latence (Time-to-Deliver) :
Vital pour les SMS d'authentification (OTP). C'est le délai entre votre appel HTTP 200 OK et la réception du Webhook Delivered.

• Benchmark : suivez ce délai par opérateur et dans le temps ; une hausse brutale signale un problème de route.
• Action : Si le délai s'allonge au point que vos utilisateurs abandonnent le formulaire d'inscription, implémentez un fallback (ex: WhatsApp OTP).

Vos développeurs ne doivent pas passer leur temps sur des dashboards. Ce sont les algorithmes qui doivent donner l'alerte.

Créez un script CRON qui analyse vos logs d'envoi toutes les 15 minutes. Définissez des "Seuils d'Alerte" (Thresholds) :

• Alerte Orange : Si le taux de Rejected sur les 5 dernières minutes dépasse 10%, envoyez un message Slack/Teams au marketing pour vérifier le contenu de la campagne (mots interdits).
• Alerte Rouge : Si l'API EnvoiSMS retourne 5 erreurs HTTP 503 ou HTTP 401 consécutives, envoyez un SMS d'urgence au DevOps d'astreinte et basculez automatiquement sur un fournisseur de secours (Failover).

L'approche "Petite Équipe" (Google Sheets) :
Pas besoin d'infrastructure complexe. Créez un Google Sheet. Connectez votre webhook de réception via un outil comme Zapier ou Make.com, et incrémentez simplement des colonnes (Date, Opérateur, Statut). Un simple graphique croisé dynamique vous donnera la santé de vos envois par opérateur marocain au jour le jour.

L'approche "Tech Mature" (Grafana / ELK) :
Poussez tous les événements Webhooks dans Elasticsearch ou Prometheus. Créez un dashboard Grafana avec :

• Une jauge du taux de délivrance (Vert/Orange/Rouge).
• Un graphique chronologique (Time Series) superposant les envois IAM, Orange et inwi. Un trou sur la courbe IAM vous indiquera immédiatement un Sender ID désactivé spécifiquement chez cet opérateur.

Un incident de routage arrivera forcément (maintenance de l'opérateur local, câble sous-marin sectionné, bug applicatif). La qualité d'une équipe technique se mesure à son "Post-Mortem" (Analyse d'après incident).

1. Identifier le Blast Radius (Périmètre d'impact) : Combien de clients marocains n'ont pas reçu leur code OTP ? Sur quels opérateurs précisément ?
2. Identifier la Root Cause (Cause racine) : Était-ce un Throttling HTTP 429 parce que vous avez envoyé trop vite, ou un blocage SS7 opérateur ?
3. Action corrective : Comment le code va-t-il empêcher cela à l'avenir ? (Mise en place d'une file d'attente Redis, lissage de campagne, etc.)