Pourquoi une seule messagerie pour tout ne tient pas

Tout commence simplement. Votre premier projet obtient un contact@ un alias qui transfère vers votre Gmail personnel. Le deuxième aussi. Puis une landing page a besoin d’un formulaire, et son point de réception vous envoie aussi des emails. Au dixième projet, vous avez dix règles de transfert, un filtre par domaine et une arborescence de libellés abandonnée depuis des mois. Une seule messagerie qui essaie d’en être dix.

Puis les problèmes concrets apparaissent :

  • Des messages passent inaperçus. Le signalement d’un bug par un client payant se retrouve entre le pic de lancement d’un autre projet et vos emails personnels. Votre logiciel de messagerie ne sait pas qu’il s’agit de produits différents. Vous le découvrez quatre jours plus tard.
  • Le contexte se perd. « L’export ne fonctionne plus. » Quel export ? La moitié des messages ne précisent jamais le projet, et le seul indice est un en-tête À : enfoui dans un transfert.
  • Impossible de couper un seul projet. La semaine de lancement d’un produit inonde la messagerie de tous les autres. Le seul bouton muet disponible couvre toute votre vie.
  • Impossible de passer le relais. Un collaborateur rejoint un projet dont les messages sont dans votre compte personnel. Il faut tout transférer à la main ou partager vos identifiants. Deux mauvaises solutions.
  • Les projets abandonnés restent là. La règle de transfert survit au produit. Deux ans après, vous recevez encore le spam d’un domaine expiré sans oser supprimer un filtre entremêlé à neuf autres.

Ce ne sont pas des problèmes de filtres, mais d’organisation : vous faites passer N produits par un canal, et les libellés ne sont qu’un bricolage.

Ce que change une boîte par projet

Inversez le modèle. Chaque projet a sa boîte, son adresse email, son point de réception et ses règles de notification. Les messages restent séparés, et les réglages globaux deviennent propres à chaque projet :

  • La mise en sourdine reste ciblée. Coupez les alertes du projet en lancement ; les neuf autres continuent.
  • Le passage de relais reste ciblé. Un collaborateur reçoit les messages de ce projet (dans un canal Discord ou Slack partagé, ou une boîte d’équipe) sans accéder à votre messagerie.
  • L’archivage reste ciblé. Projet abandonné ? Archivez sa boîte. Le canal se ferme, l’historique reste lisible et rien d’autre ne change.
  • Le contexte est inclus. Si un message est dans cette boîte, il concerne ce projet. Pas d’enquête dans les en-têtes.

Vous pouvez le construire avec une boîte payante par projet ou un domaine catch-all et de nombreuses règles (certains le font). Mais cela coûte par adresse ou un après-midi par projet : personne ne poursuit au-delà du troisième. La solution est de créer une boîte sans coût de mise en place.

La configuration en pratique

C’est précisément pour cela que nous avons créé mailcontact pour. Créez un projet : il dispose de deux sources qui alimentent une seule boîte :

Une adresse email qui fonctionne immédiatement. [email protected] fonctionne dès la création du projet : aucun enregistrement DNS, serveur mail ni vérification. Mettez-la dans votre pied de page, c’est tout. (Fonctionnement de l’adresse.)

Un point de réception de formulaire pour le formulaire de votre landing page. Un envoi HTML simple email et message (avec éventuellement name et subject), envoyé avec le script MailContact hébergé pour que les visiteurs restent sur la page :

<form action="https://mailcontact.app/api/forms/your-form-id" method="POST" data-mailcontact-form>
  <label>Email <input name="email" type="email" required /></label>
  <label>Message <textarea name="message" required></textarea></label>
  <button type="submit">Send</button>
  <p data-contact-status role="status" aria-live="polite"></p>
</form>
<script defer src="https://mailcontact.app/forms/v1.js"
  crossorigin="anonymous" referrerpolicy="no-referrer"></script>

Les deux arrivent dans la même boîte de projet, et une notification (Discord, Slack, email ou webhook) se déclenche dès qu’un message arrive : plus besoin de consulter une boîte supplémentaire. Dix projets, dix boîtes, aucun nouvel onglet. Le documentation détaillent le fonctionnement. Free inclut un projet de formulaire ; Pro comprend dix projets avec chacun un formulaire et une adresse email (tarifs).

L’extrait est volontairement indépendant de la technologie : dix projets sont rarement construits avec le même outil. Des guides existent pour chaque technologie : Next.js, Astro, SvelteKit, Hugo, ou la liste complète.

Précisons le périmètre : mailcontact n’est volontairement pas un outil de tickets. Ni SLA, ni files d’assignation : une boîte claire par projet pour ses vrais messages. Vous pouvez créer un compte gratuit pour y accéder.

Séparer les canaux relève de la bonne gestion

Personne ne regroupe les journaux de dix services dans un fichier pour y chercher leurs noms. Personne n’envoie les erreurs de dix applications vers un seul projet de surveillance. Partout ailleurs, un canal par produit est la norme. L’email de contact fait exception parce que l’isolation coûtait cher : domaine, DNS, poste payant par adresse.

Quand une boîte se crée en cinq secondes plutôt qu’en un après-midi, tout change. Créer un canal de contact devient une base du projet, comme initialiser le dépôt. Cela aurait toujours dû fonctionner ainsi.

Votre prochain projet mérite sa boîte. Les neuf précédents aussi.