Des pull requests fusionnées au changelog publié
Zero lit les pull requests fusionnées cette semaine, garde celles qui concernent vos utilisateurs, rédige l'article de changelog et le publie sur votre blog, votre liste Resend et X dans la même exécution, une fois le brouillon validé.
Ce que Zero produit : l'article, l'e-mail et le fil
Voici une vraie actualité produit Zero, publiée sur vm0.ai le 20 juillet 2026 et montrée telle qu'elle est sortie : l'article de blog, la même actualité en newsletter et en fil sur X. Une seule exécution a écrit les trois à partir des pull requests fusionnées de la semaine.
Qu'est-ce que l'automatisation du changelog ?
L'automatisation du changelog consiste à générer votre actualité produit à partir du travail réellement fusionné par l'équipe, au lieu de l'écrire de mémoire en fin de semaine. Zero est l'agent au milieu : il lit les pull requests fusionnées sur GitHub, garde celles qui concernent les utilisateurs, les regroupe par thèmes, rédige l'article de changelog et le publie sur votre blog, en newsletter Resend et en fil X en une seule exécution. Le résultat est une actualité produit hebdomadaire qui sort à l'heure et dit la même chose sur tous les canaux.
Pourquoi le changelog hebdomadaire mange un vendredi
Vendredi après-midi. Une trentaine de pull requests ont été fusionnées cette semaine et quelqu'un doit en tirer une actualité que les gens liront vraiment. Vous parcourez la liste des merges, devinez lesquels concernent les utilisateurs, écrivez l'article, le raccourcissez pour l'e-mail, le raccourcissez encore pour X, puis collez chaque version dans un outil différent. C'est la même lecture trois fois, et ce qui arrive sur X ne dit presque jamais exactement la même chose que ce qui est arrivé dans la boîte de réception.
Comment Zero transforme une semaine de merges en changelog publié
Étape 1 : Connectez vos outils
Étape 2 : Demandez à Zero
Étape 3 : Allez plus loin
Intégrations GitHub, Resend, X et Slack pour automatiser le changelog
Ce workflow lit dans un outil et écrit dans trois. GitHub est la seule source de vérité sur ce qui a été livré ; Resend et X sont des destinations ; Slack est l'endroit où le brouillon attend une personne. Chaque connecteur est accordé séparément et limité à ce que le workflow utilise réellement : un accès en lecture à votre dépôt n'implique donc jamais le droit de publier depuis votre compte.
Intégration GitHub : ce que Zero lit pour construire le changelog
RequisZero interroge les pull requests fusionnées dans les dépôts que vous indiquez sur la période choisie et lit, pour chacune, le titre, le corps, les libellés, l'heure de fusion, l'auteur et les chemins de fichiers modifiés. Ces cinq signaux distinguent un changement visible d'une refactorisation interne : un libellé de note de release est le plus fort, les chemins modifiés attrapent ceux que personne n'a étiquetés, et le corps apporte le détail que le titre laisse de côté. Dans ce workflow, l'intégration GitHub est en lecture seule. Zero n'ouvre aucune issue, ne pousse aucun commit et ne modifie aucune pull request. Pointez-le vers plusieurs dépôts et il les lit dans la même passe : un frontend et un backend séparés donnent quand même un seul changelog.
Intégration Resend : la newsletter que Zero envoie
RequisZero lit vos audiences Resend pour pouvoir désigner celle que vous nommez par son nom plutôt que par un identifiant, puis crée et envoie la campagne : objet, pré-en-tête, corps HTML et version texte. Après l'envoi, il relit le résultat et indique combien de messages ont été remis, différés et rejetés, ce qui explique que le rapport et la campagne ne se contredisent jamais. Le droit d'envoi est accordé séparément de l'accès en lecture aux audiences, et Zero n'ajoute, ne supprime ni n'exporte jamais de contacts.
Intégration X : le fil que Zero publie
RequisLe fil est écrit pour X, pas tronqué depuis l'article : une publication par thème, une ouverture qui dit ce qui a changé et une publication finale qui renvoie au texte complet. Zero publie chaque entrée en réponse à la précédente pour que le fil tienne ensemble, et vérifie la longueur avant publication plutôt que de laisser une publication être coupée. L'accès en écriture est limité au compte connecté, et publier le fil est tout ce qu'il fait. Zero ne lit ni votre fil d'actualité, ni vos mentions, ni vos messages privés.
Intégration Slack : là où le brouillon attend la validation
OptionnelSlack est facultatif et gagne sa place à l'étape de validation. Zero publie le brouillon complet dans le canal que vous indiquez, texte du blog, objet de l'e-mail et chaque publication du fil compris, puis s'arrête. Rien n'est publié tant que personne n'a validé, et vous pouvez demander une réécriture dans le même fil pour recevoir le brouillon mis à jour sur place. Sans Slack, le workflow se déroule quand même de bout en bout : le brouillon revient là où vous avez lancé l'exécution.
Zero, l'écriture manuelle et un générateur de changelog
Automatiser le changelog, ce sont deux problèmes : décider ce qui mérite d'être annoncé, et porter cette annonce sur tous les canaux. La plupart des outils n'en résolvent qu'un.
L'écrire à la main
Quelqu'un lit la liste des merges, décide de ce qui compte, écrit l'article puis le réécrit deux fois pour l'e-mail et pour X. Le jugement est bon et le ton est juste, mais cela coûte les mêmes 90 minutes chaque semaine et c'est la première chose sacrifiée dans une semaine chargée.
Un générateur de changelog
Les titres de commits ou de pull requests sont rassemblés automatiquement sur une page de notes de release. Aucun merge n'est oublié, mais ce sont des titres qui sont publiés et non des thèmes, une refactorisation ne se distingue pas d'une fonctionnalité, et tout s'arrête à une seule destination.
Le workflow de changelog de Zero
Zero lit les mêmes merges, applique votre règle sur ce qui concerne les utilisateurs, regroupe le reste par thèmes et rédige le texte de chaque canal. Blog, Resend et X sont publiés depuis un unique brouillon validé en une exécution, et l'exécution indique ce qui a été retenu et pourquoi.
Conseils pour de meilleurs résultats
Questions fréquentes
Comment automatiser un changelog à partir des pull requests GitHub ?
Connectez GitHub à Zero et donnez-lui une planification ou un déclencheur de release. Zero lit les pull requests fusionnées sur la période, les filtre avec votre règle sur ce qui concerne les utilisateurs, regroupe les survivantes par thèmes et rédige l'article de changelog. Ajoutez Resend et X et la même exécution le publiera aussi sur ces canaux.
Comment Zero décide-t-il quels merges concernent les utilisateurs ?
Selon la règle que vous lui donnez, appliquée à quatre signaux : le libellé de note de release, les chemins de fichiers modifiés, le titre de la pull request et son corps. Le libellé est le signal le plus fort et celui que la plupart des équipes finissent par standardiser. Tout ce que Zero exclut figure dans le rapport d'exécution avec sa raison : une mauvaise décision se voit au lieu de passer inaperçue.
Peut-on publier un même brouillon en newsletter et sur X en même temps ?
Oui. Zero écrit les thèmes une fois, puis les adapte à chaque canal : l'article complet sur le blog, l'e-mail au format boîte de réception avec objet et pré-en-tête, et un fil comptant une publication par thème. Les trois sont publiés dans la même exécution depuis le même brouillon validé, donc les faits ne peuvent pas diverger d'un canal à l'autre.
Quelque chose peut-il être publié sans ma validation ?
Non, sauf si vous le demandez. Par défaut, Zero publie le brouillon dans un canal et attend. Vous pouvez le valider, demander une réécriture dans le même fil ou l'abandonner. Si vous préférez une publication sans supervision, dites-le dans le prompt et Zero saute l'étape de validation.
De quels outils cette automatisation du changelog a-t-elle besoin ?
GitHub est requis comme source de ce qui a été livré. Resend et X sont requis comme les deux destinations de publication. Slack est facultatif et ne sert qu'à l'étape de validation ; sans lui, le brouillon revient là où vous avez lancé l'exécution.
Quelles autorisations ce workflow demande-t-il ?
GitHub a besoin d'un accès en lecture aux dépôts depuis lesquels vous publiez. Resend a besoin du droit d'envoi et d'un accès en lecture aux audiences. X a besoin d'un accès en écriture sur le compte qui publie le fil. Slack, si vous l'utilisez, doit pouvoir publier dans le canal de validation. Chaque connecteur est accordé séparément dans Zero, et en révoquer un laisse les autres intacts.
Zero peut-il construire un seul changelog à partir de plusieurs dépôts ?
Oui. Nommez chaque dépôt dans le prompt et Zero les lit dans la même passe, puis regroupe les changements selon le comportement qu'ils modifient plutôt que selon leur dépôt d'origine. Un frontend et un backend séparés donnent quand même un seul article.
Puis-je le déclencher sur un tag de release plutôt qu'une planification hebdomadaire ?
Oui. Créez une automatisation qui démarre le workflow quand une release est taguée sur GitHub. Zero construit alors le changelog à partir des pull requests de cette release plutôt que d'une fenêtre de dates, et le reste de l'exécution est identique.
Publiez le changelog de cette semaine
Connectez GitHub, Resend et X, puis utilisez le prompt hebdomadaire pour voir toute l'exécution : lecture, regroupement, rédaction, validation, publication.