Le problème de l'e-mail : quand votre appli créée avec l'IA doit envoyer des messages à de vraies personnes

Vous avez créé l’appli. Le formulaire d’inscription marche. Un utilisateur le remplit, clique sur « Créer un compte » — et puis rien ne se passe. Ou pire : l’e-mail de confirmation arrive quarante minutes plus tard, dans le dossier spam, avec une adresse d’expéditeur qui a l’air écrite par un robot. Vous demandez à votre créateur d’applis avec IA de « réparer l’e-mail ». Trois itérations plus tard, vous avez un nouveau bug et le même problème.

Si vous avez déjà livré quoi que ce soit avec un créateur d’applis avec IA, vous avez probablement buté là-dessus. L’e-mail a l’air d’une fonctionnalité en une ligne. Il ne l’est pas. C’est un protocole vieux de trente ans avec d’étranges règles de confiance, et le faire bien se comporter à l’intérieur d’une appli créée avec l’IA est l’un des endroits les plus courants où les fondateurs non techniques perdent discrètement des utilisateurs.

Voici ce qui se passe vraiment, et quoi demander à votre créateur d’y faire.

Pourquoi l’e-mail est plus difficile que votre créateur ne le laisse paraître

Quand votre créateur d’applis avec IA génère une fonctionnalité « envoyer un e-mail », il câble en général le plus petit truc qui marche sur un écran de test. Il utilise une adresse d’expédition par défaut. Il envoie via le service que son modèle préfère. Il suppose que vous êtes une vraie entreprise avec un vrai domaine en qui internet a confiance.

Le vrai internet ne fait pas confiance aux nouveaux expéditeurs. Les fournisseurs de messagerie — Gmail, Outlook, Yahoo, Apple — ont passé vingt ans à devenir excellents pour repérer les sources inconnues. Quand un domaine tout neuf se met à envoyer des réinitialisations de mot de passe et des e-mails de bienvenue, tous les filtres anti-spam du monde froncent les sourcils. Sans trois éléments de configuration précis en place, vos e-mails finiront en spam, seront silencieusement abandonnés, ou arriveront assez tard pour que les utilisateurs aient déjà renoncé.

Les trois éléments, ce sont SPF, DKIM et DMARC. Vous n’avez pas besoin de savoir ce que veulent dire ces sigles. Vous devez savoir que sans eux, votre fonctionnalité d’envoi d’e-mails est cassée d’une façon que vous ne pouvez pas voir de l’intérieur de l’appli.

La première chose à vérifier : de qui vient vraiment l’e-mail ?

Ouvrez le dernier e-mail qu’a envoyé votre appli. Regardez l’adresse d’expéditeur. C’est en général l’une de trois choses :

quelquechose@votredomaine.com — le meilleur cas. Votre créateur d’applis avec IA a configuré un vrai expéditeur. Si les utilisateurs ne les reçoivent toujours pas, le problème vient des trois sigles ci-dessus.
quelquechose@un-service-de-creation.com — courant. Vos e-mails sont envoyés depuis l’infrastructure partagée de votre créateur. Ça marche, mais ça vous met dans le même bassin que toutes les autres applis quelconques de la plateforme. Un mauvais voisin et votre taux de délivrabilité chute.
noreply@un-domaine-au-hasard.example — mauvais. Votre créateur d’applis avec IA a généré un substitut qu’il n’a jamais remplacé. Les utilisateurs reçoivent des e-mails d’un domaine qui ne vous appartient pas, et les fournisseurs de messagerie auront raison de s’en méfier.

Si vous êtes dans les cas 2 ou 3, c’est la première chose à corriger.

Quoi demander à votre créateur d’applis avec IA, dans l’ordre

Il existe une séquence précise qui marche pour la plupart des créateurs. Demander ces choses dans le mauvais ordre produira des résultats déroutants.

Étape 1 : choisir un fournisseur d’envoi

Demandez à votre créateur d’applis avec IA : « Je veux envoyer des e-mails depuis mon propre domaine. Connecte cette appli à Resend (ou Postmark, ou SendGrid) avec ma clé API. » Choisissez-en un. Ils sont globalement équivalents pour les petites applis. Resend et Postmark ont les parcours de configuration les plus accueillants.

Il faudra que vous vous inscriviez vous-même chez le fournisseur et que vous récupériez une clé API. L’IA ne peut pas faire cette partie — ça nécessite que vous entriez une carte bancaire et que vous vérifiiez votre identité. Comptez trente minutes.

Étape 2 : vérifier votre domaine

Une fois votre fournisseur d’envoi connecté, le fournisseur vous demandera d’ajouter trois enregistrements DNS à votre domaine. Ce sont les enregistrements SPF, DKIM et DMARC dont j’ai parlé. Votre fournisseur vous montrera exactement quoi coller.

C’est l’étape que la plupart des fondateurs non techniques sautent, et c’est celle qui règle 80 % des plaintes « mes e-mails partent en spam ». Demandez à votre créateur d’applis avec IA : « Aide-moi à trouver où ajouter des enregistrements DNS pour le domaine que j’ai acheté. » Il vous guidera à travers votre bureau d’enregistrement (GoDaddy, Namecheap, Cloudflare, peu importe).

C’est aussi la seule étape qui prend du temps dans le monde réel — les modifications DNS peuvent mettre quelques heures à se propager. Ne paniquez pas si ça ne marche pas tout de suite.

Étape 3 : réécrire le contenu de vos e-mails

Celle-là surprend les gens. Le contenu de vos e-mails compte autant que la configuration. Les créateurs d’applis avec IA partent par défaut sur du texte marketing bavard qui ressemble à du spam. Deux choses précises à corriger :

Pas d’objet tout en majuscules. « BIENVENUE DANS MON APPLI » est un signal de spam. « Bienvenue chez Boats by Maria » non.
Pas de liens nus vers des domaines de redirection. Si votre e-mail dit « Cliquez ici » et que le lien pointe vers une URL de suivi qui rebondit à travers trois fournisseurs, les filtres anti-spam le remarquent. Demandez à votre créateur d’utiliser des liens qui vont directement vers votre domaine.

Une vérification rapide : envoyez-vous un vrai e-mail depuis l’appli, puis transférez-le vers mail-tester.com. Il note votre e-mail sur 10 et vous dit exactement quoi corriger. Une note de 8 ou plus signifie que les boîtes de réception vous accepteront. En dessous de 6, attendez-vous à des problèmes.

Les trois e-mails qui doivent fonctionner

Vous n’avez pas besoin d’envoyer parfaitement chaque e-mail. Vous avez besoin d’envoyer parfaitement trois e-mails précis, parce que si l’un d’eux échoue, votre appli casse pour les nouveaux utilisateurs.

La confirmation d’inscription. Si les utilisateurs s’inscrivent et ne peuvent pas confirmer leur adresse, ils ne peuvent pas se connecter. Assurez-vous que celui-ci arrive en moins d’une minute, à chaque fois.
La réinitialisation de mot de passe. C’est l’e-mail que les utilisateurs remarquent quand il manque. S’ils demandent une réinitialisation et que rien n’arrive, votre boîte de support se remplit le jour même.
L’e-mail « quelque chose s’est passé sur votre compte » — une nouvelle connexion, une invitation, un commentaire. Ceux-là bâtissent la confiance. S’ils arrivent de façon fiable, les utilisateurs commencent à traiter votre appli comme un vrai service.

Tout le reste — newsletters, mises à jour produit, séquences automatisées — est du bonus. Faites en sorte que les trois e-mails essentiels se délivrent de façon constante avant de construire quoi que ce soit de sophistiqué.

Quand faire appel à un humain

Si vous avez fait les trois étapes ci-dessus et que les e-mails partent toujours en spam, le problème vient presque toujours de l’une de ces trois choses : votre domaine est trop récent (attendez une semaine, envoyez avec parcimonie), votre contenu déclenche un filtre précis (lancez le test mail-tester), ou votre volume d’envoi a brusquement bondi (commencez petit, montez progressivement).

Si vous avez passé plus d’une journée là-dessus et que c’est toujours cassé, c’est le bon moment pour payer un freelance pour deux heures. La délivrabilité des e-mails est l’une des rares choses d’une appli moderne où un humain expérimenté peut corriger ce qu’un créateur d’applis avec IA n’arrive pas tout à fait à raisonner — parce que la réponse vit souvent dans des enregistrements DNS que l’IA ne peut pas voir.

Vous pouvez livrer une appli créée avec l’IA entière sans jamais câbler de vrais e-mails. Vous ne pouvez pas garder vos utilisateurs sans eux.