Les e-mails qu’un assistant IA te doit : comment Notis utilise Customer.io

Voici une façon sous-estimée de perdre un utilisateur : ton assistant IA cesse de fonctionner sans prévenir, et la personne ne s’en rend compte qu’en se demandant pourquoi rien ne s’est passé mardi dernier.

Les agents échouent en silence. Les intégrations expirent. Les cartes sont refusées. Les automatisations sont mises en pause. Rien de tout ça n’est visible dans un fil de discussion, parce que le fil de discussion est justement l’endroit où il ne se passe rien.

Chez Notis, on traite donc l’e-mail opérationnel comme une partie du produit, et c’est Customer.io qui le fait tourner.

Le partage des rôles : notre backend décide du quand, Customer.io du quoi

La règle de conception est ennuyeuse, et elle a bien tenu.

Notis décide du déclencheur. Notre backend Python sait qu’un paiement d’abonnement a échoué, qu’une automatisation a atteint une limite de crédits et s’est mise en pause, que le token d’une intégration connectée a expiré, qu’une sandbox est sur le point d’être nettoyée, qu’un canal s’est retrouvé orphelin quand quelqu’un a changé de numéro de téléphone. Ce sont des faits que seul le backend connaît.

Customer.io s’occupe du message. Templates, textes, mise en page, localisation, envoi. Chacun de nos envois transactionnels porte un identifiant de message qui correspond à un template de leur côté, et part vers leur point d’envoi européen.

Cette séparation me permet de réécrire le texte d’un e-mail d’échec de paiement à 23 h sans toucher à un déploiement. Et elle fait que le code du backend se lit comme une liste d’événements produit plutôt que comme une liste de chaînes HTML.

Ce que contient vraiment l’inventaire

On tient une liste de référence de tous les e-mails opérationnels que le produit peut envoyer, vérifiée pour la dernière fois contre l’espace de travail Customer.io le 18 août 2026. En voici un échantillon :

• la fin de l’essai gratuit, avec l’offre pour passer à un forfait supérieur
• une automatisation mise en pause faute de crédits
• un sujet ou une automatisation précise mise en pause par le système
• un canal désactivé ou orphelin
• un paiement échoué, un abonnement annulé
• une intégration déconnectée, ou un lot d’intégrations expirées
• un prélèvement à la demande qui a échoué
• un avertissement de consommation quand quelqu’un approche d’une limite
• une sandbox programmée pour suppression
• une invitation dans une équipe
• la vérification d’un alias e-mail
• un échec de livraison définitif, quand on a renoncé à renvoyer un message qui t’était destiné

Lis cette liste comme une spécification produit plutôt que comme une liste de diffusion. Chaque élément est un moment où l’état de l’assistant et la représentation que l’utilisateur s’en fait ont divergé, et la seule façon de réparer, c’est de le dire.

Celui que je mettrais en avant, c’est l’échec de livraison définitif. Notis répond par WhatsApp, iMessage, Telegram et e-mail. Parfois, la livraison vers un canal échoue pour de bon : un numéro est bloqué, une session expire, une restriction du fournisseur s’applique. Pour l’utilisateur, l’expérience se résume à « l’assistant m’a ignoré ». Lui envoyer un e-mail à ce sujet, c’est la différence entre un rapport de bug et un désabonnement.

Pourquoi ne pas les envoyer nous-mêmes

On a déjà un canal e-mail. Notis te répond par e-mail via un tout autre fournisseur. Alors pourquoi ajouter Customer.io ?

Parce que ce sont deux métiers différents qui portent les mêmes vêtements.

L’e-mail comme canal, c’est une conversation. Il doit s’enchaîner correctement dans le fil, conserver les références, transporter les pièces jointes et arriver comme une réponse de ton assistant. L’e-mail de cycle de vie, c’est un avis. Il doit s’afficher correctement dans tous les clients mail, être modifiable par quelqu’un qui n’est pas ingénieur, pouvoir être désactivé et être traçable.

Mélanger les deux, c’est comme ça qu’on se retrouve avec un système où changer le pied de page d’un avis de facturation exige une mise en production du backend, et où un désabonnement du marketing supprime par accident une alerte d’échec de paiement. Les garder séparés coûte un fournisseur de plus et évite toute une catégorie d’incidents.

Pour info, on garde aussi la prospection du fondateur dans un troisième endroit. Trois systèmes d’e-mail, ça paraît trop, jusqu’à ce que tu remarques qu’ils ont trois façons différentes de tomber en panne.

La discipline qui fait que ça marche

Un seul inventaire, vérifié contre l’espace de travail réel. Une liste d’e-mails dans un document devient de la fiction en moins d’un mois. La nôtre est vérifiée contre le véritable espace de travail Customer.io, avec une date associée. Si un template existe et que rien ne le déclenche, c’est une anomalie à traiter. Si le code référence un identifiant de message qui n’existe pas, c’est une panne qui attend le bon mardi.

Chaque e-mail opérationnel doit être actionnable. « Une erreur s’est produite » n’est pas une notification, c’est un générateur d’anxiété. Chaque e-mail doit dire ce qui s’est passé, ce que ça signifie pour le travail en cours et la seule chose sur laquelle cliquer.

Envoie depuis la région où se trouvent tes utilisateurs. On envoie vers le point d’accès européen de Customer.io. Pour un produit opéré depuis la Suisse avec des utilisateurs européens, ce n’est pas un simple bonus.

Si tu construis un produit à base d’agents

Ce que personne ne te dit : plus ton produit est autonome, plus il doit d’e-mails aux gens.

Un outil qui n’agit que lorsqu’on clique n’a presque pas besoin de messages de cycle de vie : l’utilisateur était juste là. Un assistant qui fait tourner des automatisations, détient des intégrations, dépense des crédits et travaille pendant que tu dors accumule une longue liste d’états dans lesquels tu peux te retrouver sans le savoir. Chacun d’eux a besoin d’un moyen de te joindre en dehors du produit.

Donc :

1. Commence par lister les états d’échec silencieux. Chacun est un e-mail.
2. Sépare la livraison conversationnelle des notifications de cycle de vie. Outils différents, exigences de fiabilité différentes.
3. Garde les déclencheurs dans le code et les textes dans l’ESP. Ton futur toi modifiera les textes bien plus souvent que les déclencheurs.
4. Audite l’inventaire à une date précise, et note cette date.

Notis est un produit porté par son fondateur, qui élargit encore ce que l’assistant peut faire seul. Plus il travaille sans surveillance, plus il est important qu’il te prévienne quand il n’y arrive pas.

Customer.io, c’est la façon dont il te prévient. Ça vaut le coup d’œil si ton produit fait des choses pendant que personne ne regarde.