Tester votre intégration SMS en sandbox au Maroc avant de passer en production

1. Vous pouvez drainer entièrement votre solde de crédits à cause d'une boucle infinie dans votre code.
2. Vous pouvez envoyer des SMS de test ("Hello test 123") à des centaines de vrais clients marocains à 3 heures du matin.

C'est pourquoi toutes les intégrations professionnelles exigent le passage par un environnement Sandbox (Bac à sable). Voici comment paramétrer et simuler de vraies conditions réseaux télécoms marocaines sans envoyer de vrais SMS.

Un bon environnement de test ne se limite pas à retourner HTTP 200 OK. L'objectif est de s'assurer que votre application (CRM, Laravel, Node.js) réagit correctement aux événements asynchrones complexes (les Delivery Reports ou Webhooks DLR).

En mode Sandbox sur EnvoiSMS :

• Vos appels API sont gratuits (le solde de crédit n'est pas débité).
• Les SMS ne sont jamais acheminés aux réseaux réels (IAM, Orange, inwi), empêchant toute communication accidentelle à de vrais abonnés.
• Vous pouvez simuler différents statuts DLR (Delivered, Rejected, Failed) en utilisant des numéros de test spécifiques (Magic Numbers).

Pour qualifier votre code avant le déploiement sur les serveurs marocains, utilisez des "Magic Numbers" (Numéros magiques) dans votre payload API de test pour forcer la passerelle à générer des scénarios d'erreurs :

• Tester le succès (Le cas nominal) : Utilisez le numéro +212600000001. L'API vous renverra un HTTP 200 et déclenchera immédiatement un appel Webhook avec le statut Delivered.
• Tester le rejet réseau (Le pare-feu) : Utilisez le numéro +212600000002. La Sandbox simulera un blocage opérateur (ex: Sender ID interdit) et votre Webhook recevra un Rejected avec un code d'erreur métier.
• Tester l'erreur fatale (Le faux numéro) : Utilisez le numéro +212600000003. La Sandbox simulera un numéro qui n'existe plus chez Maroc Telecom, vous retournant un webhook Failed. Votre script de gestion de base de données doit détecter ce statut et désactiver ce contact automatiquement.

Ne remplacez pas la TEST_API_KEY par votre LIVE_API_KEY avant d'avoir coché ces 4 points :

1. [ ] Nettoyage des numéros (E.164) : Votre backend force-t-il tous les formats locaux saisis par vos utilisateurs (0661123456, 07 14 56...) au standard international +212661123456 ?
2. [ ] Vérification de la longueur (Encodage) : Avez-vous vérifié si vos SMS en arabe (UCS-2) ne dépassent pas la limite de 70 caractères, sous peine d'être surfacturés sur de multiples segments ?
3. [ ] Sécurité des Webhooks : Votre serveur vérifie-t-il la signature HMAC-SHA256 (X-EnvoiSMS-Signature) pour s'assurer que les événements DLR reçus proviennent bien de nos serveurs et non d'un pirate ?
4. [ ] Sender ID conforme : Avez-vous entamé la procédure de whitelisting manuelle de votre Sender ID auprès de l'équipe support ? En production, un Sender ID non validé par les opérateurs marocains sera purement et simplement rejeté.

La transition de la Sandbox à la production révèle souvent un oubli critique : le Rate-Limiting.
En test, vous envoyez 3 SMS à la main. En production, votre tâche CRON va tenter d'envoyer 10 000 SMS en une seconde. Votre script va frapper la limite de débit réseau et crasher avec des erreurs HTTP 429.

Assurez-vous que votre architecture de production intègre une file d'attente (Redis / Queue) permettant de lisser l'envoi massif à un rythme constant (sous la limite par minute de votre clé API : 60 à 1 200 requêtes/minute selon le palier).