About this case study
Ce guide décrit un processus reproductible de marketing des livraisons, pas un résultat client rapporté ni la promesse qu’une mise à jour isolée fera revenir des utilisateurs inactifs.
Chaque livraison est un contenu déjà payé
En 2026, le développement n’est presque jamais le goulot d’étranglement. Avec Lovable, Bolt, Cursor, v0 ou Replit, on livre trois ou quatre vraies améliorations dans la semaine. Ce que presque personne ne fait, c’est le dire. Le travail part en production, le journal Git s’allonge, et les seuls à le remarquer sont ceux qui ont déjà l’application ouverte.
Un changelog est le contenu le moins cher que vous écrirez jamais, parce que la réflexion est terminée avant même d’ouvrir l’éditeur. Vous n’inventez pas un sujet : vous en rapportez un. La seule décision qui reste est de l’écrire comme un diff ou comme un résultat.
Un diff dit : « Ajout de l’export CSV en masse. » Un résultat dit : « Vous pouvez maintenant récupérer un mois de données dans un tableur en un clic, et le rapport client cesse d’être une séance de ressaisie. » Même livraison, lecteur radicalement différent. La première phrase est écrite pour vous. La seconde est écrite pour quelqu’un qui hésite à rouvrir votre application.
Rédigé en résultats, un changelog fait deux choses à la fois. Il touche l’utilisateur parti précisément parce qu’il manquait ce qui existe désormais. Et il montre au visiteur qui arrive ce qu’aucune landing page ne peut simuler : un produit visiblement en mouvement.
Le modèle d’entrée de changelog
Chaque entrée répond aux mêmes questions dans le même ordre. Quatre lignes courtes, une capture, un lien :
- Ce qui a changé, en une phrase compréhensible hors de la base de code. Pas de noms internes, pas de numéros de ticket, pas de « refonte de la couche de synchronisation ».
- À qui cela s’adresse, décrit comme un comportement et non comme une formule d’abonnement : « si vous relisez vos publications sur mobile », « si vous gérez plusieurs marques ».
- Ce que cette personne peut faire maintenant et ne pouvait pas faire la semaine dernière. C’est la ligne qui déclenche le clic : écrivez une capacité, pas un nom de fonctionnalité.
- Pourquoi cela compte, en une proposition : l’agacement qui disparaît, l’étape supprimée, le bricolage mis à la retraite.
- Une capture ou un court clip de la chose elle-même, recadré au plus près du changement. Une image du nouvel état vaut mieux que n’importe quel adjectif posé à côté.
- Un lien, directement vers l’écran où vit le changement. Pas la page d’accueil : personne n’ira chercher.
Quelles livraisons méritent une publication publique
Pas toutes. Si chaque montée de version de dépendance devient une annonce, votre audience apprend qu’on peut sauter vos publications sans risque — et la seule livraison qui comptait est sautée avec les autres. C’est la retenue qui garde le canal digne d’être lu.
La règle est assez étroite pour s’appliquer en cinq secondes : une livraison mérite une publication quand elle change ce que quelqu’un peut faire, supprime une raison exprimée de partir, ou se voit dès l’ouverture de l’application. Tout le reste — corrections, performance, retouches de texte — reste sur la page du changelog sans publication dédiée.
Pour qui livre chaque semaine, cela se stabilise sur un partage simple. Tout entre dans l’entrée du changelog. Environ une livraison par semaine passe la barre de la publication publique. Une fois par mois, les petites sont regroupées dans un récapitulatif unique du type « ce qui est sorti en août », pour que le travail invisible ait aussi son moment.
Si une semaine rien ne passe la barre, ne fabriquez pas d’annonce. Publiez autre chose : une décision que vous avez inversée, une contrainte rencontrée, une question sur laquelle vous bloquez. C’est votre cadence de build in public qui porte les semaines que la feuille de route ne porte pas.
Transformer une entrée en une publication par réseau
L’entrée est la source. Chaque réseau reçoit la même nouvelle dans sa propre forme — jamais le même bloc de texte collé trois fois :
- Instagram : commencez par le visuel. La capture recadrée ou un enregistrement d’écran de cinq secondes est la publication ; la légende dit à qui cela s’adresse et ce que la personne peut faire maintenant.
- Threads : écrivez sur le ton de la conversation, comme si vous répondiez à la personne qui l’avait demandé. « Vous l’aviez demandé. C’est en ligne. » Puis laissez le fil ouvert et répondez à ce qui arrive.
- X : la version la plus courte qui tienne seule. Une ligne sur la capacité, la capture, le lien. Renvoyez le raisonnement dans une réponse plutôt que dans le premier message.
- Gardez le même lien de destination sur les trois, pour savoir quel réseau a réellement amené des gens sur le nouvel écran.
- Écrivez les trois dans la même séance, tant que la livraison est fraîche. Y revenir deux jours plus tard retransforme systématiquement un résultat en diff.
Le flux hebdomadaire, de bout en bout
Donnez des jours fixes à la boucle pour qu’elle survive à une semaine chargée. Livrer le mercredi. Écrire l’entrée le jeudi, tant que vous vous rappelez pourquoi vous avez construit la chose. Publier le vendredi matin, et garder l’après-midi libre pour répondre aux gens. Quatre créneaux dans l’agenda, aucune décision à reprendre.
Dans Amplispect, l’entrée passe une fois dans l’éditeur et devient la source des trois versions. L’aperçu par réseau montre comment la légende et la capture s’afficheront vraiment sur Instagram, Threads et X avant toute mise en file, et la validation attrape la légende qui dépasse la limite d’un réseau ou l’image au mauvais format — les deux échecs qu’on découvre normalement en direct.
Planifiez l’ensemble au lieu de publier à la main. Une publication de livraison qui part à l’heure choisie est une publication que vous préparez le jeudi et pour laquelle vous restez disponible le vendredi, ce qui compte plus que l’heure exacte retenue.
Ensuite les réponses reviennent dans une seule file plutôt que dans trois applications. Amplispect synchronise les commentaires pris en charge dans l’espace de travail et peut rédiger une réponse, mais rien ne part avant que vous l’ayez lue et validée. Répondre dans l’heure aux premières questions sur une nouveauté, c’est toute la raison d’être de ce vendredi après-midi libre.
Au bout d’un trimestre, relisez vos publications de livraison et demandez-vous quel type de mise à jour a vraiment fait réagir. Les fondateurs sont souvent surpris : le petit agacement disparu dépasse souvent la fonctionnalité phare, parce que plus de gens l’avaient réellement vécu. Ce signal appartient à la prochaine feuille de route, pas seulement à la prochaine légende.
Ce que cela produit réellement
Après un trimestre de livraisons hebdomadaires, vous avez une douzaine de publications de livraison, une page de changelog qui se lit comme un produit en mouvement, et un relevé des types de mise à jour auxquels les gens répondent vraiment. Ce relevé est la partie précieuse : il vous dit quoi annoncer ensuite et, souvent, quoi construire ensuite. Les utilisateurs qui reviennent et les inscriptions restent des résultats à mesurer, pas des chiffres que ce processus peut promettre.
Le garde-fou
N’annoncez jamais quelque chose qui n’est pas entièrement disponible pour la personne qui clique. Une publication qui atterrit sur un feature flag, une liste d’attente ou un écran qui ne ressemble en rien à la capture coûte plus de confiance que la mise à jour n’en rapporte. Livrez, capturez ce qui est livré, puis publiez.
Aller plus loin
Où les publications de livraison s’insèrent dans le reste de votre distribution :
- Transformez votre landing page en 30 jours de publicationsExploitez les pages que vous avez déjà pour les semaines sans livraison.
- Build in Public : une cadence de publication qui amène des utilisateurs, pas juste des abonnésLe rythme de publication qui porte les semaines entre deux livraisons.
- Vos 10 premières publications sur votre app quand vous n’avez ni utilisateurs ni témoignagesQuoi publier avant d’avoir un changelog qui mérite une annonce.
- Comment faire croître votre app avec une boucle hebdomadaireComment une livraison hebdomadaire devient une boucle d’acquisition reproductible.
- Comment distribuer une app : le guide complet pour les fondateurs qui ont déjà construitLa vue d’ensemble pour mettre une application devant des gens une fois qu’elle est construite.
- Planificateur de publicationsRédigez la livraison une fois, prévisualisez par réseau et planifiez tout le lot en une passe.
- Gestion des commentairesRassemblez toutes les réponses à une publication de livraison dans une file que vous relisez avant de répondre.
Questions fréquentes
Que doit contenir une entrée de changelog ?
Ce qui a changé en langage simple, à qui cela s’adresse, ce que la personne peut faire maintenant, pourquoi cela compte, une capture du changement et un lien vers l’écran exact. Les numéros de version et les noms internes sont facultatifs ; la capacité ne l’est pas.
Faut-il publier sur les réseaux à chaque mise à jour ?
Non. Publiez quand une livraison change ce que quelqu’un peut faire, supprime une raison de partir, ou se voit dès l’ouverture de l’application. Les corrections et le travail de performance restent sur la page du changelog et peuvent être regroupés dans un récapitulatif mensuel.
Comment annoncer une nouvelle fonctionnalité sur les réseaux ?
Écrivez d’abord le résultat, puis adaptez-le à chaque réseau : une publication visuelle sur Instagram, une publication conversationnelle sur Threads et la version la plus courte sur X. Gardez le même lien de destination partout pour voir quel réseau a apporté du trafic.
Les notes de version sont-elles vraiment du bon marketing ?
Oui, quand elles sont écrites pour les utilisateurs et non pour l’équipe. C’est le seul contenu dont le travail est déjà fait, il donne aux utilisateurs inactifs une raison concrète de revenir et montre aux nouveaux visiteurs que le produit continue de s’améliorer.