Pourquoi héberger soi-même sa newsletter : les vrais avantages (et comment s’y prendre)
L’hébergement de newsletters : pourquoi de plus en plus de créateurs reprennent le contrôle
Tinyletter a disparu en février 2024. Pour beaucoup d’auteurs, c’était le dernier outil simple qui permettait d’envoyer une lettre sans tout le fatras des plateformes marketing. Écrire, envoyer, c’est tout. Mailchimp, qui l’avait racheté, a mis fin à l’aventure.
Ce n’est pas un cas isolé. Les services tiers ferment, changent de cap ou augmentent leurs prix. Résultat : un nombre croissant de créateurs indépendants choisissent de gérer leur newsletter eux-mêmes.
Les limites des solutions tout-en-un
Confier sa liste à une plateforme tierce paraît pratique. On évite de toucher aux réglages DNS, aux enregistrements d’authentification et aux problèmes de délivrabilité. Mais ces outils sont pensés pour des campagnes marketing, pas pour des lettres personnelles.
Leurs fonctionnalités (pixels de tracking, tests A/B, scoring d’engagement) ne correspondent pas toujours à ce qu’on cherche. Et leur modèle de facturation par abonné devient vite coûteux dès qu’on dépasse quelques centaines de lecteurs.
Surtout, on ne maîtrise pas son audience. Si le service disparaît ou change ses priorités, tout repart de zéro.
Reprendre la main sans tout réinventer
Auto-héberger sa newsletter ne veut pas dire devenir administrateur système. Il suffit de s’appuyer sur des briques solides et de garder le contrôle sur le contenu et les abonnés.
L’approche actuelle repose sur quelques principes simples :
- Stocker les éditions sous forme de fichiers markdown dans un dépôt Git.
- Utiliser une API d’envoi pour gérer la délivrabilité (Postmark, Resend, Mailgun, etc.).
- Ajouter un petit outil en ligne de commande qui transforme le markdown en email et pilote l’envoi.
- Garder une mise en page minimaliste : texte brut ou HTML léger.
Une structure de dossiers claire
Voici à quoi peut ressembler un projet minimal :
newsletter/
├── issues/ # Un fichier .md par édition
├── subscribers.csv # Liste des abonnés
├── send/ # Script d’envoi
├── web/ # Formulaire d’inscription
└── .github/workflows/
Tout est versionné. Changer de service d’envoi se résume à modifier un fichier de configuration. Ajouter une fonctionnalité (flux RSS, partage automatique) se fait directement dans le code.
La question de la délivrabilité
Beaucoup craignent que leurs emails finissent en spam. Les enregistrements SPF, DKIM et DMARC sont techniques, mais les services d’envoi les gèrent pour vous. Vous conservez la propriété de votre liste et de votre contenu, tout en déléguant la partie technique à des spécialistes.
Un coût maîtrisé
Le prix d’un service d’envoi reste modeste : souvent 1 à 2 dollars pour mille emails. Pour une parution irrégulière, la maintenance reste légère.
Pourquoi ça change la donne
Gérer soi-même son canal de diffusion, c’est comme posséder sa propre presse. On ne dépend plus d’une plateforme qui peut disparaître. Pour un auteur indépendant, un développeur ou un fondateur qui publie en public, c’est souvent le lien le plus direct avec son audience.
Les outils actuels rendent cette approche accessible : plateformes de déploiement simplifiées, bibliothèques open source matures, API d’envoi fiables.
Par où commencer
- Vérifier où se trouve actuellement votre liste et comment elle est sauvegardée.
- Choisir un service d’envoi en fonction de son API et de son tarif réel.
- Commencer petit : un dossier de fichiers markdown, un script CLI et un endpoint pour les inscriptions.
- Tout versionner dans Git.
- Garder à l’esprit l’expérience des lecteurs plutôt que les statistiques d’ouverture.
Le mouvement ne vient pas d’une mode, mais d’un constat simple : quand on écrit pour durer, mieux vaut ne pas dépendre d’un service qui peut changer de cap du jour au lendemain.