Pour un projet open source qui publie surtout des nouvelles et des versions, Buttondown est un choix à examiner : son offre gratuite couvre jusqu’à 100 abonnés et son éditeur accepte le Markdown. Gardez toutefois la liste séparée des notifications techniques et vérifiez les options de segmentation avant d’en faire un outil de coordination. Une bonne lettre explique les changements, remercie les contributions sans les classer et rend les informations de financement compréhensibles. En France, documentez l’origine des adresses et le consentement aux nouvelles commerciales.
Buttondown convient comme premier choix à un mainteneur qui veut publier des notes de version, un bulletin communautaire et des nouvelles de financement sans bâtir un parcours marketing complexe. Son format éditorial se prête aux textes en Markdown et à une rédaction légère, adaptée à une équipe bénévole. L’offre gratuite de Buttondown couvre les 100 premiers abonnés ; la limite devient vite concrète pour un projet populaire, et la segmentation ainsi que les automatisations sont des options payantes à évaluer.
Beehiiv peut convenir si le projet publie une lettre régulière avec analyses, liens et récits de la communauté, et veut développer une audience de lecteurs. Son offre de départ limite le nombre de publications et de sièges ; les besoins de coordination de plusieurs mainteneurs peuvent imposer une autre organisation. Vérifiez les conditions du forfait choisi avant d’y déplacer une liste existante.
MailerLite
MailerLite est à considérer pour une association de mainteneurs qui veut envoyer des bulletins, formulaires et quelques suivis aux nouveaux inscrits. Les offres sont encadrées par le nombre d’abonnés et le volume mensuel ; prévoyez une migration ou un budget lorsque la communauté dépasse le palier retenu, et vérifiez les options d’export avant de bâtir vos habitudes.
Brevo
Brevo peut aider une structure qui distingue abonnés, partenaires et contacts professionnels dans ses campagnes. Gardez les annonces de versions publiques accessibles dans le dépôt et utilisez l’email pour leur donner du contexte. Les coûts dépendent notamment du volume d’envoi selon l’offre retenue ; une liste ancienne ou des digests trop fréquents peuvent gonfler la facture et fatiguer les bénévoles.
Mailchimp
Mailchimp est une option à comparer si des membres connaissent déjà son interface et peuvent reprendre la liste lors d’un changement de mainteneur. Pour un projet, sa richesse peut alourdir une simple lettre de version. Contrôlez le nombre de contacts conservés et les conditions de l’offre choisie, puis gardez une copie exportable des consentements et des préférences.
Kit
ConvertKit, désormais présenté sous le nom Kit, peut convenir à un mainteneur qui signe aussi des essais techniques ou anime une lettre personnelle autour de son projet. Cette approche éditoriale ne remplace pas les canaux d’alerte du dépôt et ne doit pas transformer les contributeurs en prospects. Vérifiez le coût aux paliers de contacts et séparez les abonnements aux sujets distincts.
Loops
Loops peut être étudié lorsque le projet open source s’accompagne d’un service logiciel et doit distinguer messages de produit et bulletin communautaire. Ce positionnement peut être disproportionné pour un dépôt maintenu sur le temps libre, et la tarification dépend des contacts abonnés au-delà de l’offre de démarrage. Vérifiez aussi les règles de conservation et le contrat de sous-traitance avant un import.
Une annonce de version publique doit rester consultable dans le dépôt ou sur la page de publication, même si vous la résumez par email. Les alertes de sécurité, notifications de revue et échanges liés à une contribution suivent un autre rythme et ne doivent pas dépendre d’une lettre facultative. Définissez quels messages partent de GitHub ou de votre forge et lesquels relèvent de la newsletter. Vérifiez les connecteurs ou prévoyez un export contrôlé plutôt qu’une synchronisation supposée.
Proposez quelques choix lisibles, comme les versions majeures, les récits de maintenances, les appels à contribution documentaire ou les nouvelles de financement. Une personne qui suit le projet pour l’utiliser n’a pas forcément envie de recevoir les demandes de bénévolat. Évitez de déduire une préférence durable d’une issue ouverte ou d’une pull request. Donnez une façon simple de modifier ses choix et consignez leur source sans aspirer tout l’historique de la forge.
Un bon message de sortie résume les changements visibles, les corrections qui comptent pour les utilisateurs et le lien vers les notes détaillées. Pour une version qui exige une migration, nommez les incompatibilités et donnez un chemin vérifiable, sans cacher les étapes dans un long digest. Faites relire les commandes et extraits de configuration par une personne qui connaît le projet. N’envoyez pas automatiquement chaque commit à toute la liste : regroupez les informations selon leur utilité.
La newsletter ne remplace pas le processus de divulgation coordonnée, les avis publiés ni les consignes propres au projet. Décidez qui peut envoyer une alerte de sécurité, comment les utilisateurs concernés sont identifiés et où se trouve la version corrigée. Ne diffusez pas de détail exploitable avant le moment prévu avec les personnes qui signalent la faille. Limitez les données des destinataires au nécessaire et vérifiez les accès aux listes sensibles.
Remerciez une contribution précise avec l’accord de son auteur et décrivez son effet concret : documentation clarifiée, traduction relue ou bogue reproduit. Évitez les tableaux de « meilleurs contributeurs » qui réduisent un travail collectif à un score et peuvent exposer des pseudonymes. Une lettre peut aussi expliquer comment proposer une amélioration ou demander de l’aide. Demandez avant de publier une citation, un portrait ou un lien vers un profil personnel.
Quand le projet sollicite des dons, du mécénat ou des sponsors, expliquez les dépenses concernées et les priorités de maintenance sans laisser entendre qu’un versement garantit une fonctionnalité. Distinguez les annonces destinées aux utilisateurs des échanges avec des partenaires potentiels. Indiquez comment la communauté peut consulter les informations financières pertinentes et qui répond aux questions. Une liste de sponsors ne doit apparaître qu’avec leur accord et selon les règles applicables à votre structure.
Répondez d’abord dans le canal où la contribution a été proposée : remerciez la personne, indiquez la prochaine étape et liez le guide correspondant. Si elle s’abonne ensuite à la lettre, envoyez un message distinct qui explique les réunions ouvertes, les règles de discussion et la manière de demander une revue. Ne transformez pas l’adresse trouvée dans une forge en inscription automatique. Un parcours utile reste facultatif, évite les relances culpabilisantes et propose un contact humain lorsque les consignes ne suffisent pas.
Commencez par le numéro de version et une phrase qui résume à qui elle sert. Séparez nouveautés, corrections et changements incompatibles, puis liez les notes complètes, les paquets publiés et le guide de migration s’il existe. Indiquez clairement si une action est nécessaire ou si la mise à jour est facultative. Pour un projet utilisé dans des environnements variés, faites vérifier les instructions sur une installation propre. L’annonce doit rester intelligible sans supposer que chaque abonné suit le dépôt quotidiennement.
Utilisez le processus de sécurité publié par le projet, avec un avis accessible et des instructions de mise à jour vérifiées. La lettre peut relayer cet avis lorsqu’il est public, mais ne doit pas révéler prématurément une faille ni remplacer les canaux suivis par les personnes qui déploient le logiciel. Précisez les versions concernées et les mesures disponibles, sans spéculer sur l’impact. Gardez une trace de la validation éditoriale et évitez de joindre des listes détaillées d’utilisateurs à un outil généraliste.
Choisissez une cadence que les mainteneurs peuvent tenir même pendant une période calme : un récapitulatif mensuel ou à chaque version importante peut suffire. Annoncez cette cadence au formulaire et distinguez-la des avis indispensables publiés par les canaux techniques. Si aucune nouvelle utile n’est prête, ne remplissez pas le calendrier pour respecter une fréquence artificielle. Regardez les désabonnements et les réponses directes après chaque envoi, puis demandez aux abonnés s’ils préfèrent moins de messages ou seulement les sorties majeures.
Demandez à la personne si elle souhaite être nommée avant de publier son nom, son pseudonyme, une citation ou un lien de profil. Un remerciement collectif peut décrire le travail réalisé sans exposer d’identité, par exemple la correction d’une traduction ou l’amélioration d’un tutoriel. Évitez les palmarès et les compteurs de contributions : ils favorisent les tâches faciles à compter et peuvent décourager les revues discrètes. L’auteur doit pouvoir retirer son accord pour une future édition.
Expliquez d’abord pourquoi le changement est nécessaire et quelles interfaces ou configurations il touche. Publiez une feuille de route datée, un guide de migration et un canal où signaler un blocage ; adaptez le délai à la politique réelle du projet plutôt que de promettre un préavis universel. Envoyez un rappel aux personnes qui ont choisi les annonces de versions, puis mettez à jour les notes lorsque le calendrier évolue. N’envoyez pas un message ciblé à des utilisateurs que vous ne pouvez pas identifier de façon fiable.
Partagez les sujets en exploration comme des pistes, et réservez le terme « prévu » aux travaux réellement décidés. Expliquez les critères qui guident les priorités, les dépendances et les inconnues ; invitez les retours dans l’espace public du projet plutôt que par réponse à une boîte peu surveillée. Précisez que les idées reçues ne valent pas engagement de livraison. Cette distinction évite qu’une archive de newsletter soit interprétée comme une promesse contractuelle ou comme un calendrier garanti.
Décrivez les besoins que le financement peut soutenir, comme la maintenance, l’hébergement ou la documentation, et indiquez comment consulter les informations de l’organisme bénéficiaire. Distinguez clairement don, sponsoring et achat éventuel d’un service. Ne promettez ni priorité dans la file des issues ni fonctionnalité en échange d’un soutien, sauf si une offre distincte le prévoit et a été validée. Donnez un lien de paiement vérifié et une adresse de contact pour les questions administratives.
Suivez d’abord les informations utiles au fonctionnement éditorial : inscriptions confirmées, désabonnements, rebonds et réponses reçues. Pour une annonce de sortie, vous pouvez observer les clics vers les notes, mais ils ne prouvent ni installation ni adoption. Évitez de rapprocher automatiquement l’identité des abonnés et leur activité dans le dépôt : ce suivi peut surprendre et créer un profil disproportionné. Définissez une durée de conservation, limitez les accès et partagez les résultats sous forme agrégée lorsque cela suffit.
La plupart des lettres ont besoin d’une adresse, d’une preuve d’inscription et des préférences choisies ; un nom ou un profil de forge n’est pas toujours nécessaire. Si vous proposez des thèmes, conservez le choix plutôt qu’un historique détaillé de navigation ou de contributions. Définissez qui peut exporter la liste, comment traiter une demande de suppression et combien de temps garder les journaux. Demandez au fournisseur le contrat de sous-traitance prévu par l’article 28 du RGPD et le lieu d’hébergement, puis faites valider les points incertains par votre DPO ou conseil.