État des lieux sur les fournisseurs de SMS externes

[francois-ferrandis]

Quels sont les départements concernés ?

Nous avons 3 départements qui n'utilisent pas notre fournisseur par défaut :

• Hauts-de-Seine : SFR Mail2SMS
• Pas-de-Calais : SFR Mail2SMS
• Seine-et-Marne : Clever Technologies

Quel est notre fournisseur par défaut ?

Il s'agit de Netsize. Ce service dispose d'une API HTTP et nous informe en cas de non délivrabilité.

Problèmes inhérents à l'usage d'un fournisseur de SMS externe

Lorsqu'un département utilise un fournisseur externe :

• cela nécessite le développement et la maintenance d'un module spécifique dans notre application
• cela crée une situation où nous voyons les messages d'erreur, mais seuls les département peuvent y remédier, aucun des deux partis n'est alors autonome dans la résolution des pannes

Clever Technologies

Issue dédiée : #4350

Plusieurs fois par an, le compte Clever Technologies de la Seine-et-Marne est vide de "crédit", et nous sommes alertés via notre système de gestion d'erreurs applicatives Sentry. Nous devons alors contacter le département pour qu'il rachète des crédits puis s'assurer que tous les envois sont bien relancés.

Outre cela, nous n'avons aucune visibilité dans les cas où les SMS ne peuvent pas être livrés (mauvais numéro par exemple). Cela nous empêche d'informer les agents que le numéro est injoignable (une fonctionnalité que nous n'avons aimerions développer, voir #2729).

SFR Mail2SMS

L'API proposée par ce service n'est pas une API HTTP traditionnelle, elle passe par un mécanisme d'envoi d'e-mail. Elle fonctionne de la sorte :

1. Le département crée un compte chez SFR, et y indique que l'adresse [email protected] est une adresse autorisée.
2. Notre application envoie des e-mail à [email protected] avec dans le champ FROM cette adresse de confiance, et dans le corps du mail le texte du SMS.
3. SFR reçoit le mail, délivre le SMS, puis envoie un récépissé vers l'adresse qui était dans le champ FROM

Pour le Pas-de-Calais, cette adresse FROM est [email protected]. Cela signifie que nous pouvons utiliser les credentials SMTP de la boite [email protected] pour envoyer ces e-mails, et que les récépissés sont envoyés à [email protected]. Le problème, c'est que Gandi (qui nous fournit cette boite e-mail) bloque les envois à partir d'un certain volume, afin de préserver sa réputation dans la lutte anti-spam.

Dans cette forme d'API, nous sommes donc tributaires d'une logique de rate-limiting conçue pour lutter contre le spam, qui n'est pas du tout adaptée à une API qui est censé légitimement envoyer des centaines de SMS par jour.

Cas particulier des Hauts-de-Seine

Dans les Hauts-de-Seine, une problématique supplémentaire s'ajoute à celle mentionnée ci-dessus. En effet, ce département souhaite recevoir les récépissés des SMS dans une boite mail qui leur appartient. Ils nous indiquent donc de saisir une adresse en @hauts-de-seine.fr dans le champ FROM des mails envoyés. Or, ils refusent de nous fournir les credentials SMTP de cette boite mail, et donc nous envoyons les mails en utilisant les credentials de la boite [email protected]. Cela signifie donc que nous utilisons la boite [email protected] en la faisant mentir sur le FROM. Cette pratique semblait ne pas déclencher d'erreur jusqu'à avant-hier (lundi 2 septembre), où Gandi a mis en place un mécanisme qui empêche cette pratique, et retourne une erreur "Not allowed to take this identity" (voir Sentry). Les nombreux retry de ces envois ont alors déclenché le rate-limiting (anti-spam) de Gandi, ce qui a bloqué le Pas-de-Calais qui utilise également [email protected].

Pourquoi ne pas utiliser Brevo pour déclencher SFR Mail2SMS ?

Brevo ne permet pas d'envoyer des e-mail plaintext, il rajoute forcément un corps HTML (car son business model est d'être un outil marketing). Or, SFR Mail2SMS n'accepte que les e-mail plaintext.

Quels sont les inconvénients à n'avoir qu'un seul fournisseur ?

Si nous n'avions qu'un seul fournisseur (probablement Netsize, mais à discuter), il nous faudrait avoir un fournisseur de backup en cas de panne. Cela paraît faisable, et les services de SMS transactionnels sont nombreux, sécurisés, et plus modernes que ceux que nous utilisons.

Conclusion

La gestion de fournisseurs de SMS externes est chronophage et anxiogène pour notre équipe, tout comme pour les équipes des départements que nous devons solliciter en cas de problème, ce qui arrive régulièrement. Le passage à une gestion internalisée de la gestion de SMS permettrait donc :

• une plus grande autonomie
• moins de stress pour les équipes techniques et projet
• une meilleure UX pour les agents (alertes d'échec)