Vos e-mails de réinitialisation risquent de partir en spam (et vous ne le verrez qu'en production)

Un utilisateur clique sur « Mot de passe oublié ». Il attend le mail. Rien dans sa boîte de réception. Il finit par le trouver dans ses spams, en anglais, expédié par un noreply@…firebaseapp.com qu'il ne reconnaît pas. Il hésite, n'ouvre pas, abandonne.

Ce détail a un coût direct : un utilisateur qui ne peut pas réinitialiser son mot de passe est un utilisateur que vous perdez au pire moment, celui où il essayait justement de revenir.

Et voici ce qui rend ce problème sournois : en développement, tout fonctionne. Le mail part, vous le recevez, vous validez, vous passez à autre chose. Le défaut n'apparaît qu'en conditions réelles : vraie boîte Gmail, vrais filtres, vraie réputation de domaine. Que vous ayez codé votre application vous-même, fait générer une partie du backend par une IA, ou assemblé le tout en no-code, le piège est identique et il est invisible en test. Les outils modernes rendent la construction rapide et accessible ; ils ne signalent pas pour autant les angles morts de la mise en production.

Un client m'a confié récemment son application, qu'il avait construite avec l'IA, pour la sécuriser avant sa mise en production. Symptôme rapporté : ses mails de réinitialisation partaient systématiquement en indésirables. Bonne nouvelle, et c'est ce que je lui ai dit d'abord : ce n'est pas sa faute, et la cause n'est presque jamais celle qu'on soupçonne.

La plupart des guides sur le sujet vous donnent une liste de réglages à appliquer : configurez SPF, ajoutez DKIM, activez DMARC. C'est utile, mais ça saute une étape, celle où l'on lit ce qui cloche réellement chez vous avant de toucher à quoi que ce soit. Un réglage appliqué à l'aveugle, sans avoir posé le diagnostic, corrige rarement le bon problème. Cet article prend l'autre chemin : d'abord comprendre ce que disent vos e-mails, ensuite corriger, et enfin savoir quoi vérifier sur votre application avant de la lancer.

Le symptôme : vos e-mails les plus importants finissent en spam

Les mails concernés étaient les plus critiques du parcours : la réinitialisation de mot de passe. Ceux dont dépend l'accès au compte.

Le premier réflexe, quand on découvre ça, c'est d'accuser le contenu : « le template est mal fichu », « il y a un mot qui déclenche les filtres ». On passe alors des heures à retoucher un objet, enlever un lien, réécrire une formulation. C'est presque toujours du temps perdu, parce qu'on traite un symptôme sans avoir posé le diagnostic.

Ma règle sur ce type de problème est simple : on ne devine pas, on va lire ce que dit la machine.

Ne devinez pas : lisez les en-têtes

Un e-mail transporte, au-delà de son contenu visible, des informations techniques appelées en-têtes. Elles disent d'où le mail est parti, qui l'a signé, et si le domaine expéditeur a bien autorisé cet envoi. C'est là qu'est le diagnostic, pas dans le corps du message.

Dans Gmail : ouvrez le mail, puis « Afficher l'original ». Trois lignes comptent :

• SPF : le serveur qui a envoyé avait-il le droit de le faire pour ce domaine ?
• DKIM : le mail est-il signé cryptographiquement, et par quel domaine ?
• DMARC : l'ensemble est-il cohérent avec le domaine affiché comme expéditeur ?

Le verdict, ici, était contre-intuitif :

SPF passait. DKIM passait aussi, mais en signant pour firebaseapp.com, pas pour le domaine de l'application. Et c'est précisément ce décalage qui faisait échouer DMARC. Le mail était techniquement valide, mais signé au nom d'un domaine qui n'était pas le sien.

Voilà l'intérêt de lire plutôt que deviner : le problème n'était pas le contenu. Il était dans l'identité de l'expéditeur.

Le vrai coupable : le domaine partagé de Firebase

Quand une application utilise Firebase Authentication et laisse Firebase envoyer lui-même les mails de reset, ces mails partent de l'infrastructure de Google, signés pour firebaseapp.com.

Ce domaine n'est pas le vôtre. Il est mutualisé entre des milliers de projets Firebase. Sa réputation d'expéditeur est donc une moyenne subie : elle dépend du comportement de tous les autres projets, sur lesquels vous n'avez aucun contrôle. Ajoutez le défaut d'alignement avec votre propre domaine, le DMARC en échec, et les filtres anti-spam ont toutes les raisons de se méfier.

Le mail est correct, mais il arrive sous une identité empruntée, à la réputation incertaine. Aucun template mieux écrit ne corrigera ça.

La solution : reprendre le contrôle de l'envoi

La tentation serait de créer un système de mot de passe parallèle pour contourner Firebase. Mauvaise idée : on veut garder Firebase comme source d'authentification, sans dupliquer la logique de connexion.

L'approche retenue sépare deux rôles qu'on avait laissés collés :

• Firebase génère le lien de réinitialisation (via l'Admin SDK). Il reste le cerveau de l'authentification.
• Le backend envoie le mail, via un service d'envoi dédié, depuis sa propre adresse (contact@ sur le domaine de l'application).

Le changement n'est pas cosmétique. On cesse de laisser un tiers expédier à sa place, il redevient l'expéditeur. Concrètement, ses mails sont désormais sous sa marque et dans la bonne langue, envoyés depuis un domaine vérifié dont il maîtrise la réputation, et mieux délivrés parce que l'identité de l'expéditeur est enfin alignée. Côté utilisateur, la connexion via Firebase reste identique : on a repris la main sur l'envoi sans rien casser.

Ce que cette expérience vous apprend à vérifier sur votre application

Voilà le vrai enjeu. Ce problème d'e-mails n'est pas un incident isolé : c'est un exemple d'une catégorie entière de défauts qui ne se révèlent qu'en production. Que votre application vienne de vous, d'une IA ou du no-code, voici les cinq points à vérifier avant de la mettre entre les mains de vrais utilisateurs.

1. Qui envoie réellement vos e-mails ? Pas « est-ce que le mail part », mais qui l'envoie. Firebase directement ? Votre backend ? Un service tiers (Resend, SendGrid, Mailgun, Brevo) ? Tant que vous ne le savez pas, vous ne contrôlez pas votre délivrabilité.

2. Depuis quel domaine partent-ils ? Il y a une différence décisive entre noreply@…firebaseapp.com (domaine partagé, réputation subie) et contact@votredomaine.com (domaine que vous possédez et authentifiez). Si vos mails partent d'un domaine qui n'est pas le vôtre, vous héritez de la réputation des autres.

3. SPF est-il correctement configuré, et n'y en a-t-il qu'un seul ? SPF autorise certains serveurs à envoyer pour votre domaine. Piège classique, rencontré en migrant vers un envoi propre : un domaine n'autorise qu'un seul enregistrement SPF. Si vous en ajoutez un deuxième (par exemple en branchant un nouveau service d'envoi), la configuration casse silencieusement. La solution : fusionner les include dans une valeur SPF unique, pas empiler les enregistrements.

4. DKIM signe-t-il pour votre domaine ? Un DKIM qui passe ne suffit pas. Ce qui compte, c'est pour quel domaine il signe. S'il signe pour celui d'un tiers, l'alignement échouera.

5. DMARC passe-t-il réellement ? DMARC est le juge final : il vérifie que SPF et DKIM sont cohérents avec le domaine affiché. C'est lui qui décide, en pratique, si vous atterrissez en boîte de réception ou en spam. Un DMARC en échec est le signal qu'il faut aller lire les en-têtes.

Et le principe qui relie ces cinq points reste le même : on ne devine pas, on va lire ce que dit la machine.

Une dernière nuance, pour être honnête jusqu'au bout : même quand ces cinq points passent, un mail peut encore finir en spam. Un domaine neuf, sans historique d'envoi, met du temps à gagner la confiance des fournisseurs de messagerie. La réputation se construit dans la durée, elle ne se configure pas d'un coup. L'authentification correcte est la condition nécessaire ; elle n'est pas toujours suffisante le premier jour. C'est précisément pour ça que le diagnostic par les en-têtes reste votre meilleur outil : il vous dit si le problème vient de votre configuration (que vous pouvez corriger tout de suite) ou de votre réputation (qui se gagne avec le temps et un volume d'envoi sain).

Pour d'autres angles morts avant le lancement, consultez aussi notre FAQ et l'article sur le blocage en production.

Si vous construisez avec une IA : posez-lui la bonne question

L'IA ne produit pas des applications « qui envoient en spam ». Le problème est plus subtil : elle produit une application fonctionnelle sans forcément attirer votre attention sur les aspects opérationnels de la mise en production. Elle répond à ce que vous demandez, donc tout dépend de ce que vous demandez.

Ne lui demandez pas seulement :

« Configure Firebase Authentication pour envoyer les e-mails de réinitialisation. »

Elle vous livrera quelque chose qui marche en test, et vous serez exactement au point de départ de cet article.

Demandez-lui plutôt :

« Analyse la configuration d'envoi des e-mails de mon application et identifie les risques de délivrabilité, d'authentification du domaine et d'alignement SPF/DKIM/DMARC avant la mise en production. »

La différence n'est pas dans l'outil, elle est dans la question. Savoir quoi demander est ce qui sépare une application qui fonctionne d'une application qui tient.

« Ça fonctionne » ne veut pas dire « c'est prêt »

C'est le vrai message, bien au-delà des e-mails. Une application peut passer tous vos tests et rater tous ses vrais utilisateurs, parce que les tests ne reproduisent pas les conditions réelles : la vraie réputation d'un domaine, les vrais filtres, la vraie charge, les vrais appareils.

Les e-mails en spam sont le premier de ces angles morts, un de ceux qu'on doit lever pour sécuriser une application avant son lancement. Il y en a d'autres : des permissions trop larges qui passent inaperçues en test, des configurations qui tiennent avec dix utilisateurs mais pas avec dix mille. J'y reviendrai ici, cas par cas, avec la même méthode à chaque fois : le symptôme tel que vous le vivez, ce qu'on croit, ce qui se passe vraiment, comment le vérifier soi-même, et quoi demander à son IA.

---

Vous avez construit votre application avec l'IA et vous voulez sécuriser ce qui se passe « derrière » avant le lancement ? C'est exactement le genre de vérification que je mène. Faisons le point sur votre application : 30 min, gratuit, sans engagement.