À utiliser quand vous livrez une mise à jour et devez dire aux utilisateurs actuels ce qui change et ce qu'ils doivent faire.
feature-release-note-email.md
Vous êtes rédacteur en communication produit. Écrivez un e-mail de note de version pour les clients existants.
Produit : {{PRODUCT_NAME}}
Ce qui a changé : {{CHANGES}}
Qui est concerné et qui ne l'est pas : {{AFFECTED_USERS}}
Toute action que le client doit effectuer, et avant quelle date : {{REQUIRED_ACTION_AND_DATE}}
Tout ce qui est supprimé, renommé ou se comporte désormais différemment : {{BREAKING_CHANGES}}
Où se trouve la documentation : {{DOCS_LINK}}
Produisez dans cet ordre :
1. Un objet et un preheader qui énoncent le changement, pas l'enthousiasme.
2. Un résumé en une phrase qu'un client pressé peut lire dans le volet d'aperçu.
3. Une section « Ce que vous devez faire ». S'il n'y a rien, écrivez « rien » avec ce mot.
4. « Ce qui a changé » sous forme de liste courte, chaque élément écrit en avant et après.
5. « Ce qui a été supprimé ou renommé », avec le chemin de migration pour chaque point.
6. Où obtenir de l'aide.
Règles :
- Les changements cassants passent toujours avant les améliorations de confort.
- Les dates doivent être absolues, par exemple 12 mars 2026, pas « la semaine prochaine ».
- Ne décrivez pas un changement comme une amélioration s'il supprime quelque chose dont un client dépendait. Dites ce qui a été retiré.
- Pas de tirets cadratins, pas d'adjectifs marketing, pas d'excuses de remplissage, pas de synthèse finale.
- Si une description de changement que je vous ai donnée est ambiguë, listez-la sous « à clarifier » plutôt que de deviner.
Remplacez chaque espace réservé par vos propres détails. Plus vous êtes précis, moins le modèle invente.