Transformez un message Slack en issue GitHub, puis en correctif
Décrivez un bug en langage courant dans Slack. Zero rédige l'issue GitHub et l'assigne, et lorsque la cause tient dans un seul composant, il ouvre une pull request avec le correctif et un test de non-régression pour votre revue.
Ce que Zero produit : du message Slack au correctif en revue
Un fil réel du canal #bug-report de l'équipe vm0, capturé tel quel. Un membre de l'équipe a collé le signalement d'un client et demandé le correctif. Quatre minutes plus tard, Zero avait créé l'issue GitHub avec son diagnostic. Quatorze minutes après le premier message, la pull request était ouverte et le lien de prévisualisation publié. Les deux captures sont ci-dessous : le fil où tout a commencé, et la pull request écrite par Zero. Les deux sont publics : vous pouvez lire l'issue, le diff et la revue vous-même.
Ce qui s'est passé dans le fil
Un membre de l'équipe a signalé dans #bug-report un bug de mise en page de la PWA remonté par un client, captures à l'appui. Zero a lu le fil, l'a rattaché à une barre supérieure rendue sans le safe area inset d'iOS et a créé l'issue #11708 avec les labels et son raisonnement. Quand le correctif a été demandé dans le fil, Zero a modifié un seul fichier (une hauteur minimale et un padding de safe area sur la barre supérieure mobile), ouvert la pull request #11709 avec le lien de prévisualisation, et s'est arrêté là. La revue et le merge ont été faits par un humain.
- Du message à l'issue
- 4 minissue #11708, labels bug et PWA
- Du message à la pull request
- 14 minPR #11709 avec lien de prévisualisation
- Fichiers modifiés par le correctif
- 1mergé par un humain, pas par Zero
Que signifie créer une issue GitHub depuis Slack ?
Créer une issue GitHub depuis Slack, c'est transformer un bug décrit dans une conversation en une issue correctement structurée dans votre dépôt, sans que personne ait à quitter le fil pour tout retaper. La difficulté n'a jamais été l'appel d'API : c'est écrire un titre clair, séparer les étapes de reproduction du comportement attendu, choisir des labels, fixer une priorité et trouver la bonne personne. Zero fait ce travail. Il lit le message Slack et les réponses autour, rédige le corps de l'issue, applique des labels et une priorité qu'il peut justifier, désigne la personne responsable en rapprochant le nom affiché dans Slack d'un identifiant GitHub, puis publie le lien de l'issue dans le même fil pour que l'auteur du signalement puisse le vérifier d'un coup d'œil.
Pourquoi les signalements de bugs se perdent dans les fils Slack
Quelqu'un repère un bug pendant une démo, ou un client écrit un samedi. Le chemin habituel est long : ouvrir GitHub, retrouver le dépôt, rédiger une issue formatée, assigner quelqu'un, puis attendre que cette personne s'en saisisse, lise le code et écrive le correctif. Un changement de dix minutes devient un aller-retour de plusieurs jours entre trois personnes, et la moitié des signalements ne quitte jamais le fil. À la place, décrivez-le dans Slack. Zero crée l'issue avec les étapes de reproduction, les labels et un responsable, et là où la cause est circonscrite, il va plus loin et ouvre une pull request avec le correctif et un test. Vous relisez et vous livrez.
Comment Zero crée une issue GitHub depuis Slack
Étape 1 : Connectez vos outils
Étape 2 : Demandez à Zero
Étape 3 : Allez plus loin
Les intégrations Slack et GitHub derrière ce workflow
C'est une intégration Slack-GitHub avec un agent au milieu : Zero lit la conversation dans Slack et écrit l'enregistrement dans GitHub. Chaque connecteur est accordé séparément et limité à ce que le workflow utilise réellement, si bien que lire un canal n'implique jamais un accès en écriture à vos dépôts.
Intégration Slack : la conversation que Zero lit
RequisZero lit le message que vous lui désignez et les réponses alentour, de sorte qu'un contexte arrivé trois messages plus tard se retrouve quand même dans l'issue. Il récupère les captures d'écran jointes et les reporte, lit le nom affiché de l'auteur pour déterminer un responsable, et conserve le permalien du message afin que chaque issue renvoie à l'endroit où le signalement a commencé. Il n'écrit qu'une seule chose : une réponse dans le même fil avec le numéro et le lien de l'issue. Zero ne publie pas dans d'autres canaux, n'envoie pas de messages privés et ne modifie les messages de personne.
Intégration GitHub : l'issue que Zero crée
RequisZero crée l'issue dans le dépôt que vous indiquez, avec un titre rédigé à partir du signalement plutôt qu'une copie du message brut, une description, des étapes de reproduction, le comportement attendu et la zone concernée lorsque le fil la nomme. Il applique les labels que vous précisez ou les déduit de la formulation, fixe une priorité qu'il explique et assigne le responsable. Avant de créer, il cherche dans les issues ouvertes le même symptôme et commente l'issue existante en cas de correspondance. Quand il peut aussi corriger le bug, il pousse une branche et ouvre une pull request qui ferme l'issue et demande une revue. L'accès en écriture est limité aux dépôts que vous accordez, et c'est toute la surface : issues, commentaires et pull requests ouvertes pour revue. Zero ne fusionne pas, ne force-push pas et ne touche pas aux réglages du dépôt.
Zero, l'app GitHub pour Slack et un outil d'automatisation
Faire passer un bug d'un message Slack à GitHub comporte trois étapes : capter le signalement, écrire une issue exploitable et l'acheminer vers un responsable. Les options existantes en résolvent chacune une.
L'app GitHub pour Slack
Taper /github ouvre une boîte de dialogue où vous remplissez vous-même le titre, le corps, les labels et le responsable. Cela évite le détour par le navigateur, mais c'est toujours vous qui écrivez l'issue, et un formulaire au milieu d'une conversation est exactement la friction qui pousse à dire « je le signalerai plus tard ».
Un outil d'automatisation
Un outil no-code peut copier un message Slack dans une nouvelle issue sur un déclencheur. Ce qu'il copie, c'est le message brut : l'issue hérite donc de ce que l'auteur a écrit sur le moment, et les règles de labels, de priorité, d'affectation et de doublons, c'est à vous de les définir et de les maintenir, canal par canal.
Le workflow Slack vers GitHub de Zero
Zero lit le fil et rédige l'issue : un vrai titre, des étapes de reproduction séparées du comportement attendu, des labels et une priorité qu'il peut justifier, et un responsable déduit du nom affiché de l'auteur. Quand la cause tient dans un seul composant, il continue et ouvre une pull request avec le correctif et un test de non-régression, rattachée à l'issue et en attente de votre revue. Il vérifie d'abord les issues ouvertes et commente un doublon au lieu d'en créer un, puis répond dans le fil avec le lien.
Conseils pour de meilleurs résultats
Questions fréquentes
Comment créer une issue GitHub à partir d'un message Slack ?
Connectez Slack et GitHub à Zero, décrivez le bug dans le canal et mentionnez Zero. Il lit le message et les réponses voisines, rédige une issue avec titre, étapes de reproduction, comportement attendu, labels et priorité, la crée dans le dépôt indiqué, l'assigne et répond dans le fil avec le numéro et le lien. Vous ne remplissez aucun formulaire.
En quoi est-ce différent de l'app GitHub pour Slack ?
L'app GitHub vous donne un formulaire à remplir : titre, corps, labels et responsable, c'est vous qui les écrivez. Zero les rédige à partir de la conversation, vérifie l'existence d'une issue au même symptôme avant de créer, et peut traiter un canal entier de façon planifiée plutôt qu'un message à la fois.
Zero crée-t-il seulement l'issue, ou peut-il corriger le bug ?
Les deux, et il vous dit ce qu'il a fait et pourquoi. Zero crée toujours l'issue. Lorsque le fil ou le code désigne un seul composant, que le comportement attendu est sans ambiguïté et qu'un test en échec peut être écrit d'abord, il ouvre en plus une pull request avec le correctif et ce test, la rattache à l'issue et demande une revue. Les utilitaires partagés, les tokens de design et tout ce qui demande une décision produit sont signalés plutôt que modifiés. Zero ne fusionne jamais : chaque correctif arrive sous forme de pull request que vous relisez.
Zero peut-il assigner l'issue à la bonne personne automatiquement ?
Oui. Zero rapproche le nom que vous mentionnez, ou le nom affiché dans Slack de l'auteur, des identifiants GitHub du dépôt et assigne l'issue. Nommer le responsable dans votre message reste le plus fiable ; si personne n'est nommé, Zero se rabat sur le propriétaire de la zone visée par le fil et indique dans l'issue comment il a tranché.
Comment Zero évite-t-il les issues GitHub en double ?
Avant de créer quoi que ce soit, Zero cherche dans les issues ouvertes le même symptôme, la même zone concernée et une formulation proche. En cas de correspondance, il ajoute le nouveau fil Slack en commentaire sur cette issue, avec l'auteur et l'horodatage, et répond dans Slack avec le lien de l'issue existante au lieu d'en ouvrir une seconde.
Que se passe-t-il si un signalement n'a pas d'étapes de reproduction ?
Zero crée quand même l'issue pour que le signalement ne se perde pas, la marque comme nécessitant des étapes de reproduction et répond dans le fil Slack pour les demander. La réponse arrive alors dans le fil déjà lié depuis l'issue.
Zero peut-il créer des issues depuis un canal entier de façon planifiée ?
Oui. Désignez à Zero un ou plusieurs canaux et donnez-lui une planification, par exemple chaque vendredi à 16 h. Il lit les messages de la semaine, crée une issue pour chacun qui décrit un défaut, commente les doublons, écarte les demandes de fonctionnalités et les questions, et rend compte de ce qu'il a fait.
Cela fonctionne-t-il avec Linear ou Jira plutôt que GitHub ?
La même forme de workflow s'applique à tout outil de suivi auquel Zero est connecté ; cette page couvre la voie GitHub, qui utilise le connecteur GitHub. Linear se connecte de la même façon, et vous nommez l'outil de suivi dans l'instruction.
Signalez votre prochain bug sans quitter Slack
Connectez Slack et GitHub, décrivez le bug comme vous le diriez à un collègue, et laissez Zero rédiger l'issue et l'assigner. Quand la cause est circonscrite, la pull request vous attend elle aussi.