Le modèle d'email de mise à jour produit qu'on lit
7 min de lecture mis à jour le
L’email de mise à jour produit qu’on lit est celui envoyé à quelqu’un qui a demandé exactement ce qu’il annonce. Tout le reste rivalise avec le reste de la boîte de réception en intérêt, une compétition qu’une annonce de release perd la plupart des semaines. Ce seul fait devrait décider de la forme de l’email avant toute rédaction : qui le reçoit, et ce que cette personne a fait pour se retrouver sur la liste.
Qu’est-ce qu’un email de mise à jour produit ?
C’est un message qui dit aux utilisateurs existants ce qui a changé dans un produit qu’ils utilisent déjà. Il en existe quatre types distincts, et les traiter comme une seule liste est la raison pour laquelle les taux d’ouverture déclinent. Chacun a un déclencheur différent, un public différent et une fréquence acceptable différente.
| Type | Déclencheur | Public | Fréquence |
|---|---|---|---|
| Notification ciblée | La demande précise de quelqu’un est livrée | Une personne | Chaque fois que ça arrive |
| Avis de changement cassant | Un changement qui coûte du travail au lecteur | Comptes concernés seulement | Chaque fois que ça arrive |
| Digest | Le passage du temps | Utilisateurs opt-in | Mensuel au maximum |
| Annonce de lancement | Un lancement qui mérite une interruption | Segment ou tous | Rare, et devrait sembler rare |
La plupart des équipes ne construisent que le troisième, l’envoient à tout le monde, et en concluent que les emails de mise à jour produit ne fonctionnent pas. Les deux premiers portent presque toute la valeur, car le lecteur a une raison préalable de s’y intéresser, et le message arrive pendant que cette raison est vivante.
Ces quatre lignes sont toutes écrites pour des clientes. Les ventes, le support et le customer success doivent aussi savoir ce qui est sorti, généralement sous une forme différente de ces quatre-là ; notes de release internes couvre ce que ce document devrait dire et pourquoi il doit sortir avant la note orientée client.
L’email est l’un des plusieurs canaux qu’une annonce de lancement peut utiliser, pas le seul. Comment annoncer une nouvelle fonctionnalité couvre les autres, et comment choisir entre eux selon l’ampleur réelle de la fonctionnalité.
Que contient le modèle ?
Six blocs, dans cet ordre. Le premier est celui qui manque le plus souvent et celui qui fait le travail.
Objet : <ce qui a changé, avec les mots du lecteur>
1. Pourquoi vous recevez ceci
"Vous avez demandé l'export CSV en mars." ou
"Votre intégration appelle /v1/invoices, qui change le 15 janvier."
2. Ce qui a changé
Une phrase. Ce qui est désormais possible, ou ce qui casse désormais.
3. Ce que vous devez faire
Souvent "rien". Dites-le explicitement, ne le laissez pas implicite.
4. Où le voir
Un lien vers l'entrée du changelog, pas vers la page d'accueil.
5. Quand
La date de livraison, ou depuis quand cela s'applique.
6. Comment se désabonner
Un clic, et respecté immédiatement.Le bloc 1 est la différence entre un message et une diffusion générale. Un lecteur à qui l’on dit, dès la première ligne, que ceci est la résolution de quelque chose qu’il a personnellement demandé, lit le reste. Sans lui, les blocs 2 à 5 sont une newsletter, quelle que soit la qualité de l’écriture.
Gardez l’ensemble sous environ 150 mots. L’email est un pointeur vers l’entrée du changelog, et l’entrée est où va le détail. Un email qui reproduit l’entrée entière ne donne au lecteur aucune raison de cliquer, et ne vous donne aucun signal sur l’intérêt que cela a suscité.
Quels objets fonctionnent ?
Nommez le changement, pas la release. “L’export CSV est en ligne” bat “mise à jour de septembre” parce que le premier est un fait que le lecteur peut évaluer et le second un contenant. Les numéros de version dans l’objet sont utiles aux appelants d’une API et du bruit pour tous les autres, autre raison de séparer les publics.
Évitez d’affirmer un bénéfice auquel le lecteur n’a pas consenti. “Vos rapports sont désormais plus rapides” affirme quelque chose sur son expérience ; “Les rapports de plus de 10 000 lignes chargent désormais en moins d’une seconde” rapporte un changement et le laisse décider si cela compte.
Quand en envoyer un, et à qui ?
Envoyez une notification ciblée au moment où la chose est livrée, aux personnes qui l’ont demandée, individuellement. Envoyez un avis de changement cassant dès que la date est certaine et à nouveau juste avant, aux comptes réellement concernés plutôt qu’à toute la liste. Envoyez un digest seulement si vous avez assez de changements pour qu’un lecteur en rate sinon, et laissez les gens s’y inscrire séparément.
La liste que vous ne devriez presque jamais utiliser est “tous les utilisateurs”. Elle transforme un message précis en un message générique, et entraîne au désabonnement. Segmentez selon un comportement que vous stockez déjà : qui l’a demandé, qui utilise cet endpoint, qui est sur ce plan.
Faut-il un consentement pour l’envoyer ?
Pour les clients existants, une mise à jour sur un service qu’ils utilisent est en général une question juridique différente du marketing envers un prospect, et la réponse dépend d’où ils se trouvent et de ce que vous leur avez dit à l’inscription. Dans l’UE, la question pertinente est quelle base légale de l’article 6 du RGPD s’applique, et aux États-Unis les messages commerciaux portent des exigences précises fixées dans le guide de conformité CAN-SPAM de la FTC. Les deux exigent la même chose en pratique : dites qui vous êtes, précisez l’objet, et laissez les gens pouvoir arrêter.
Quelle que soit la base, gardez les flux transactionnel et marketing séparés au niveau de l’envoi. Un avis de changement cassant qu’un client a désabonné parce qu’il partageait une liste avec un digest promotionnel est un incident de support qui attend sa date.
À quoi cela ressemble-t-il une fois rempli ?
La notification ciblée, l’email de mise à jour produit de plus grande valeur et celui que la plupart des équipes ne construisent jamais :
Objet : L'export CSV est en ligne
Bonjour Dana,
vous avez demandé l'export CSV en mars.
C'est en ligne depuis ce matin. Les rapports ont désormais un
bouton Export qui génère un CSV de la vue actuelle, filtres
inclus.
Rien à faire de votre côté. C'est déjà activé sur votre compte.
Détails : example.com/changelog#csv-export
Livré : 2 septembre 2026
Vous recevez ceci parce que vous l'avez demandé. Se désabonner
des mises à jour de demandes : <lien>Quatre-vingt-dix mots, et le lecteur sait dès la première ligne pourquoi cela est arrivé. Comparez avec le même changement dans un digest mensuel, où il apparaît comme un point parmi neuf et Dana n’a aucune raison de remarquer que sa propre demande est sortie.
Que devriez-vous mesurer ?
Pas le taux d’ouverture seul. Pour une notification ciblée, la question est de savoir si la personne qui a demandé est revenue et a utilisé la chose, donc le chiffre à surveiller est le clic vers l’entrée et si ce compte utilise la fonctionnalité dans la semaine. Pour un avis de changement cassant, c’est la couverture : quelle part des comptes concernés a ouvert avant la date, et avec qui vous avez fait un suivi individuel.
Un digest est le seul des quatre où un taux d’ouverture signifie grand-chose, et même là il est plus utile comme tendance contre son propre historique que contre un benchmark du secteur. Différents types d’emails de mise à jour produit ont des tâches différentes, donc un chiffre moyenné sur tous ne décrit rien sur quoi agir.
En quoi est-ce différent des notes de version ?
Les notes de version sont un document qui reste disponible. L’email est un mécanisme de livraison qui arrive une fois. Le même changement produit les deux, et l’email devrait être plus court que l’entrée vers laquelle il pointe. Bonnes pratiques des notes de version couvre le document, et changelog vs notes de version couvre lequel vous êtes en train d’écrire.
La relation à bien avoir : l’entrée du changelog est le texte canonique et l’email la cite. Quand les deux divergent, le lecteur qui clique trouve une description différente du changement et cesse de faire confiance aux deux. Publier l’entrée d’abord et générer l’email à partir d’elle élimine la dérive par construction. changeloop fonctionne de la même façon de son côté : une entrée est relue et publiée une fois sur la page, le flux et le widget, et la personne qui l’a demandée via le widget en est avertie sur l’issue GitHub qu’est devenu son retour, et dans le widget lui-même. changeloop n’envoie pas l’email ; votre outil d’emailing cite l’entrée publiée.
FAQ
À quelle fréquence devrait sortir un email de mise à jour produit ? Aussi souvent qu’il y a quelque chose de précis que le destinataire veut savoir, ce qui pour une notification ciblée est chaque fois que sa demande est livrée et pour un digest est mensuel au maximum.
L’email devrait-il contenir l’entrée entière du changelog ? Non. Une phrase et un lien. L’entrée est la version canonique, et une copie complète dans l’email signifie deux textes à garder alignés.
Quel taux d’ouverture devrais-je attendre ? Comparez chaque type à lui-même plutôt qu’à un benchmark. Une notification ciblée et un digest mensuel sont des produits différents, et les moyenner cache le seul chiffre qui mérite d’être surveillé.
Faut-il une liste séparée pour les changements cassants ? Oui, et cela devrait être celle dont les gens ne peuvent pas se désabonner par inadvertance sans comprendre la conséquence, car c’est celle qui leur coûte une panne.
Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.