Votre accusé de réception SMS ment (et dans quels pays)
· 5 min de lecture
Si vous envoyez des SMS par API, votre tableau de bord affiche delivered et
vous considérez le message comme reçu. En Espagne, c’est presque toujours vrai.
Hors d’Espagne, bien souvent non : ce delivered signifie seulement que le
réseau de l’opérateur a accepté le message, pas qu’il soit apparu sur l’écran
de qui que ce soit.
La différence ressemble à un détail technique. Ce n’en est pas un : c’est la raison pour laquelle un client jure n’avoir jamais reçu le code de vérification alors que vous avez un enregistrement qui dit le contraire.
Les quatre sens de « délivré »
L’accusé de réception —le DLR, delivery report— remonte du réseau mobile jusqu’à votre fournisseur, et tous les réseaux ne rapportent pas la même chose :
| Ce que confirme l’accusé | Ce que vous savez vraiment |
|---|---|
| Remise sur le terminal | Le message est arrivé sur le téléphone. C’est le bon cas. |
| Acceptation par le réseau | L’opérateur l’a pris en charge. Il peut finir délivré, retenu ou écarté. |
| Partiel | Certains réseaux du pays rapportent la remise réelle et d’autres non. |
| Sans accusé | Aucune information : le statut reste à « envoyé » et tout s’arrête là. |
L’Espagne, le Portugal, l’Allemagne ou le Royaume-Uni rapportent généralement la remise sur le terminal. Une bonne partie de l’Amérique latine, de l’Afrique et de l’Asie rapporte l’acceptation par le réseau, et certaines destinations ne rapportent rien. Un même indicatif peut présenter les deux comportements : dans le +1 cohabitent des réseaux qui rapportent et d’autres qui ne le font pas, si bien qu’une règle pour « +1 » est tout simplement fausse.
Pourquoi cela coûte de l’argent, pas seulement de la précision
Trois conséquences concrètes, par ordre de gravité :
1. Le remboursement automatique se ferme pour toujours. Si votre
plateforme considère delivered comme un statut final —et elle doit le
faire— un accusé de réseau clôt le dossier. Le message n’est jamais arrivé,
personne ne l’a renvoyé et l’échec a été silencieux : pas d’erreur, pas
d’alerte, rien à examiner.
2. Vos indicateurs mentent vers le haut. Pour une destination qui ne rapporte que l’acceptation, votre taux de « délivrés » ne mesure pas des remises : il mesure des acceptations. Si vous prenez des décisions de routage avec ce chiffre, vous les prenez avec une donnée qui ne dit pas ce que vous croyez.
3. Les OTP se perdent en silence. C’est le cas le plus coûteux :
l’utilisateur ne peut pas se connecter, ne réessaie pas et s’en va. Vous voyez
un delivered et il n’y a rien à investiguer.
Comment savoir ce que vous dit votre fournisseur
Posez ces questions par écrit, pays par pays, avant d’arrêter les tarifs :
- L’accusé confirme-t-il la remise sur le terminal ou l’acceptation par le réseau ?
- Quels codes d’erreur renvoyez-vous et que signifie chacun d’eux ?
- L’accusé arrive-t-il par webhook avec des relances, ou faut-il l’interroger ?
- Réécrivez-vous l’expéditeur dans certaines destinations ?
Si la réponse est « délivré, c’est délivré », méfiez-vous : personne qui exploite réellement des routes internationales ne peut dire cela sans nuance.
Ce que nous faisons de ce problème
Chez SMSverifica, le niveau d’accusé de chaque destination est une donnée du système, pas une note dans un e-mail. Chaque pays a une déclaration de ce que confirme son accusé, avec sa source et sa date, et cela a trois effets :
- Vous êtes averti AVANT l’envoi, dans le tableau de bord et dans l’API, quand la destination ne confirme pas la remise sur le terminal. L’envoi n’est pas bloqué : bloquer une destination légitime à cause d’une donnée d’un tiers serait pire.
- L’avertissement est figé dans le message : dans un an, vous saurez ce que l’on savait le jour de l’envoi, pas ce que nous savons aujourd’hui.
- Une donnée inconnue n’est jamais traitée comme bonne, et une donnée vérifiée il y a plus de six mois se dégrade d’elle-même. Si personne ne publie le niveau d’accusé d’une destination, nous disons qu’il n’est pas connu.
Et il y a un endroit où avertir ne suffit pas : dans la messagerie certifiée, ce que l’on vend, c’est précisément l’affirmation de la remise. Là, le système est strict : si la destination ne confirme pas la remise sur le terminal, le certificat n’est pas émis. Nous préférons perdre cet envoi plutôt que signer un document que nous ne pourrions pas défendre devant un tiers.
Ce que vous pouvez faire dès aujourd’hui dans votre intégration
- Ne considérez pas
deliveredcomme une preuve pour les destinations qui ne confirment que le réseau. Enregistrez le niveau d’accusé avec le message. - Pour les OTP, ajoutez un second canal : si le SMS n’est pas confirmé en 30 à 60 secondes, proposez WhatsApp, un appel ou un renvoi. C’est moins cher que de perdre l’utilisateur.
- Mesurez par destination, pas globalement. Un taux moyen cache justement le pays qui vous fait défaut.
- Demandez la donnée par écrit à votre fournisseur et conservez-la avec sa date : elle change avec le temps et avec les routes.
Nous publions le prix de chaque destination et vous avertissons de ce que confirme son accusé avant que vous n’envoyiez. Vous pouvez le voir dans prix et destinations ou l’essayer avec votre propre code : dès que vous vérifiez votre e-mail, le mode test s’ouvre et l’API fonctionne sans dépenser un euro.