Articles

Rédigez automatiquement votre daily standup à partir des PR GitHub et de l'activité Jira

Vous avez déjà rédigé votre standup hier. Il est simplement éparpillé entre les pull requests, les messages de commit, les fils Slack et les transitions Jira. Le retaper dans un formulaire chaque matin, c'est ce qui fait perdre du temps, pas le travail lui-même. Avec un seul assistant compatible MCP pointé sur votre dépôt et votre outil de suivi, vous pouvez avoir votre brouillon prêt avant même d'ouvrir le canal du standup. Vous parcourez, modifiez ce qui ne va pas, et envoyez. L'ensemble prend 30 secondes au lieu de cinq minutes.

Pourquoi rédiger un brouillon vaut mieux qu'écrire de zéro

Les arguments en faveur de l'automatisation sont ici plus restreints qu'on ne le pense. Les standups sont courts, donc en générer un n'est pas un énorme gain de temps en valeur absolue. L'avantage, c'est qu'un brouillon IA vous fait partir des données plutôt que d'un champ vide. Quand vous partez d'un champ vide à 9h, vous écrivez ce qui vous semble récent : l'après-midi d'hier, ce qui est à l'écran, le bug que votre manager vient d'évoquer. Vous oubliez la PR que vous avez livrée avant le déjeuner. Vous oubliez avoir aidé quelqu'un à déboguer son déploiement. Le point devient déséquilibré. Quand vous partez d'un brouillon construit à partir d'activité réelle, vous éditez, vous ne résumez pas. Le résultat est plus précis, demande moins d'effort, et ne coûte presque rien une fois le workflow en place.

Les sources de données qui valent la peine

La plupart des standups d'ingénierie ont besoin de trois signaux. Un assistant IA avec les bons serveurs MCP connectés peut récupérer les trois sans que vous copiez-colliez quoi que ce soit. Vous n'avez pas besoin de tout. Un bon brouillon peut sortir de GitHub plus votre outil de suivi, c'est suffisant. Le contexte calendrier est appréciable mais optionnel.

Le workflow, de bout en bout

Voici à quoi ressemble réellement la boucle une fois les serveurs MCP connectés. (Pour un rappel sur le MCP, voir ce qu'est le MCP et pourquoi les équipes agiles s'y intéressent.)

1. Connectez les serveurs MCP dont votre assistant a besoin

   Pointez votre client IA sur le serveur MCP GitHub, le serveur MCP de votre outil de suivi (Atlassian en publie un pour Jira, Linear a le sien), et le serveur MCP Kollabe. Configuration unique par client.

2. Envoyez à l'assistant votre prompt de standup

   Un prompt réutilisable qui dit au modèle où chercher, quelle forme doivent prendre les réponses, et à quel standup les soumettre. Sauvegardez-le comme une slash command, un snippet, ou un prompt enregistré dans votre client.

3. Relisez le brouillon

   L'assistant récupère l'activité de la veille, rédige les réponses question par question, et vous montre le résultat. Modifiez ce qui ne va pas. Ajoutez un blocage que personne ne connaît encore.

4. Envoyez

   Demandez à l'assistant d'envoyer. Il appelle l'outil

   standup_submit_answers

   de Kollabe et votre point apparaît dans le canal comme n'importe quelle autre soumission.

Un prompt qui fonctionne vraiment

L'astuce pour un bon brouillon, c'est d'être précis sur le format. Si vous demandez « rédige mon standup », vous obtiendrez de la prose. Si vous dites au modèle exactement à quelles questions répondre et à quoi ressemble une bonne réponse, vous obtiendrez quelque chose d'envoyable. Voici un prompt qui fonctionne dans Claude Desktop, Cursor, ou n'importe quel client MCP. Adaptez les éléments spécifiques à votre équipe.

Draft my standup for today.

1. Use the Kollabe MCP to find my standup. Get the question list.
2. For yesterday's date, pull:
   - GitHub: my PRs (opened, merged, reviewed) in the
     acme/api and acme/web repos
   - Jira: tickets I moved or commented on in project ENG
3. For each standup question, draft a 1-2 sentence answer using
   the activity above. Reference ticket IDs and PR numbers.
   For "Today", use my calendar plus any in-progress PRs as context.
4. If I had no real blockers, leave the blocker answer empty.
   Don't invent one.
5. Show me the draft. Wait for confirmation before submitting.

La ligne « wait for confirmation » est importante. Sans elle, certains clients enverront dès le premier tour et vous perdrez la possibilité d'éditer.

À quoi devrait ressembler le brouillon

Un bon standup auto-rédigé se lit comme celui qu'aurait écrit un humain attentif. Court, précis, avec les numéros de tickets aux bons endroits.

Question	Réponse auto-rédigée
Qu'avez-vous fait hier ?	Livré ENG-412 (rate limiting sur /v1/auth) — PR #2841 mergée. Relu la PR #2839 de Sarah sur la migration de facturation, demandé des changements sur le chemin de rollback.
Que faites-vous aujourd'hui ?	Démarrage de ENG-415 (rotation du refresh token). Pair programming avec Tom à 14h sur le déploiement staging.
Des blocages ?	Besoin de la validation du DBA sur le plan de migration dans ENG-418 avant de pouvoir merger. Relancé Priya hier, pas encore de réponse.

Remarquez ce que le modèle n'a pas fait : il n'a pas garni avec des « belle progression aujourd'hui » ni résumé la description de la PR. Il a tiré les faits qui comptent et s'est arrêté. Si vos brouillons sortent gonflés, le problème est presque toujours dans le prompt. Ajoutez une règle explicite « pas de remplissage, pas de récapitulatif des descriptions de PR » et ça se resserre immédiatement.

L'étape de soumission

Une fois le brouillon correct, l'assistant l'envoie via l'outil MCP de Kollabe. Le flux est :

1. standup_list

   pour trouver le standup de votre espace

2. standup_list_questions

   pour récupérer les IDs des questions

3. standup_submit_answers

   avec des paires

   {questionId, answer}

   pour la date

Vous n'avez pas à penser à tout ça. Le modèle fait la recherche. C'est utile à connaître au cas où une étape échoue, car l'erreur indique généralement quel appel a cassé. Si votre équipe utilise l'outil de standup de Kollabe, les soumissions apparaissent dans le canal de la même façon, qu'elles viennent de l'application web ou d'un client MCP. Les réactions et le résumé IA quotidien fonctionnent par-dessus dans les deux cas.

Points de vigilance

Quelques autres pièges à connaître :

• Les dépôts privés et projets Jira ont besoin de tokens avec les bons scopes. OAuth gère ça pour la plupart des serveurs MCP, mais si vous ne voyez pas un dépôt ou un projet dans votre assistant, c'est probablement que la connexion n'a pas reçu l'accès.
• Les fuseaux horaires comptent. « Hier » pour une équipe de Londres n'est pas « hier » pour une équipe de San Francisco. Dites au modèle quel fuseau vous voulez.
• N'envoyez pas les blocages automatiquement. Un blocage est une demande d'aide. Si l'IA fait remonter quelque chose qui ressemble à un blocage, décidez vous-même si c'en est vraiment un et qui vous devez taguer. Les blocages auto-envoyés se font ignorer rapidement.
• Modifiez la voix d'écriture. Les points courts sont bons mais une lecture stérile sonne bizarrement. Un peu de personnalité fait beaucoup. Voir comment écrire des points de standup qui se font vraiment lire pour les règles.

Quand cela vaut la peine d'être mis en place

L'auto-rédaction gagne sa place quand vous soumettez des standups quotidiennement, que vous vivez dans GitHub et un outil de suivi, et que vous avez déjà un assistant compatible MCP pour d'autres tâches. La mise en place prend 10 minutes. Le gain quotidien est petit par personne mais s'accumule sur une année. Cela ne vaut pas la peine si le standup de votre équipe est surtout du temps de parole synchrone, ou si votre travail se passe surtout en dehors d'outils que l'IA peut lire (ateliers, appels client, design). Pour ces équipes, l'IA est mieux utilisée du côté de la détection de motifs — en lisant les soumissions de toute l'équipe et en signalant les tendances.