Notifications e-mail et SMS déclenchées par la boutique

Modifier un e-mail existant : le plus simple, à une condition

Les e-mails transactionnels d’une boutique reposent sur des gabarits que l’on peut modifier. Ajouter une information disponible dans la commande — une référence, une mention, un lien de suivi — est un travail court, à condition que la donnée soit déjà accessible au moment où l’e-mail est construit. Quand elle ne l’est pas, il faut la rendre disponible, et c’est là que la charge change d’ordre.

Un point mérite d’être signalé : modifier un gabarit d’e-mail livré avec la plateforme sans précaution fait perdre la modification à la mise à jour suivante, exactement comme pour un module. Sur PrestaShop, les gabarits d’e-mail peuvent être fournis par le thème ; sur WordPress et WooCommerce, ils se surchargent depuis le thème enfant. Dans les deux cas, la modification doit vivre ailleurs que dans le cœur.

SMS et alertes internes : ce que ça implique vraiment

Le SMS n’est pas un e-mail plus court. Il passe par un opérateur extérieur, avec un coût par message, un format d’expéditeur réglementé et des règles de consentement propres. Techniquement, le travail consiste à déclencher l’envoi au bon moment, à gérer les échecs, et surtout à ne pas envoyer deux fois le même message si le statut de commande change deux fois. Cette dernière précaution est ce qui distingue une intégration correcte d’une intégration coûteuse.

L’alerte interne est le cas le plus simple techniquement et le plus utile en exploitation : prévenir une adresse ou un canal d’équipe quand une commande remplit une condition particulière. Elle ne dépend d’aucun consentement client et ne coûte rien par message.

Dans tous les cas, je pose la même question avant d’écrire quoi que ce soit : que doit-il se passer si l’envoi échoue. Une notification perdue en silence est pire qu’une notification absente, parce que tout le monde continue de compter dessus.