Modèle de préparation de réunion qui fonctionne vraiment
Un modèle de préparation de réunion pour les engineering managers qui extrait le contexte de vos outils réels, pas de votre mémoire.
By Ellis Keane · 2026-04-03
Chaque modèle de préparation de réunion que j'ai rencontré n'est en réalité qu'un modèle d'ordre du jour déguisé. On vous donne un espace pour écrire « Sujets de discussion » et « Action items », et on appelle ça de la préparation – mais la partie vraiment difficile est ignorée : savoir ce qui s'est passé depuis la dernière fois que vous avez parlé à quelqu'un.
Le vrai travail de préparation de réunion, ce sont les quinze minutes que vous passez à faire défiler Slack en essayant de vous souvenir de ce que votre rapport direct a mentionné mardi, ou les dix minutes à cliquer dans les issues Linear pour savoir si la migration a été livrée, ou encore le moment où vous ouvrez un 1:1 et réalisez que vous n'avez rien de spécifique à discuter parce que la semaine s'est brouillée (comme les semaines ont tendance à le faire).
Ce modèle de préparation de réunion part d'une prémisse différente : la préparation consiste à rassembler du contexte, pas à rédiger un ordre du jour. Le contexte opérationnel vit dans vos outils, pas dans votre tête ; le contexte interpersonnel nécessite encore du jugement et des notes, mais c'est une surface plus petite que ce que la plupart des gens pensent. L'approche comporte trois couches : un scan d'activité, une vérification des décisions et bloqueurs, et un delta de changement. Vous pouvez parcourir les trois en moins de sept minutes.
À qui s'adresse ce modèle
Public principal : les engineering managers qui animent des 1:1s, des syncs d'équipe et des points interfonctionnels – bien que quiconque entre en réunion en regrettant de ne pas avoir vérifié certaines choses puisse l'adapter. Si vous gérez 5–8 rapports directs avec un mélange de Linear, GitHub, Slack et peut-être Notion ou Figma, c'est vous que j'avais en tête. Stack d'outils différent ? La structure s'applique quand même ; remplacez les requêtes spécifiques.
Un 1:1 rapide n'a peut-être besoin que de la Couche 1. Une session de planification à forts enjeux avec cinq participants ou plus et des décisions irréversibles sur la table nécessite probablement les trois.
Couche 1 : Le scan d'activité (3 minutes)
Avant toute réunion, consultez l'activité récente des participants. Pas tout ce qu'ils ont fait – juste assez pour arriver en sachant à quoi a vraiment ressemblé leur semaine.
- [ ] Vérifier les PRs récents de chaque participant (mergés, ouverts et reviewés) dans GitHub
- [ ] Scanner leurs issues Linear : ce qui est passé à Done, ce qui est en In Progress depuis plus de 3 jours, ce qui a été réassigné
- [ ] Parcourir les canaux Slack où ils ont été actifs, chercher les fils avec 5+ réponses (ceux-ci tendent à être les discussions les plus riches). Les modificateurs de recherche Slack comme
from:@person before:today peuvent considérablement accélérer les choses
- [ ] Si applicable, vérifier l'activité Figma pour les réunions liées au design ou les mises à jour Notion pour les réunions de planification
L'objectif n'est pas de surveiller qui que ce soit (s'il vous plaît, ne transformez pas cela en audit de productivité). L'objectif est d'arriver suffisamment informé pour poser de bonnes questions. Il y a un monde de différence entre « Comment avance la migration ? » et « J'ai vu que le PR de migration a reçu trois séries de commentaires de revue de l'équipe plateforme, quel est le point de blocage ? » La seconde dit à votre rapport direct que vous faites attention, et d'après mon expérience, elle mène plus vite à la vraie conversation.
Voici à quoi cela ressemble en pratique. Disons que vous préparez un 1:1 avec un ingénieur qui travaille sur un refactoring du système de notifications. Vous vérifiez GitHub et voyez qu'il a mergé deux PRs cette semaine mais en a un ouvert depuis quatre jours sans reviewer. Vous vérifiez Linear et remarquez que l'epic parent est passé de « In Progress » à « Blocked » hier. Vous vérifiez Slack et trouvez un fil dans #platform où il a posé une question sur un changement de schéma de base de données et a reçu des réponses contradictoires de deux ingénieurs seniors.
Vous avez maintenant trois choses concrètes à discuter, et vous n'avez même pas encore écrit d'ordre du jour.
La préparation de réunion ne consiste pas à noter des sujets. C'est rassembler assez de contexte depuis vos outils pour que les sujets importants émergent d'eux-mêmes.
Couche 2 : La vérification des décisions et bloqueurs (2 minutes)
Les réunions sont (théoriquement) là où les décisions se prennent, donc il est utile de savoir quelles décisions sont en attente. Cette couche prend environ deux minutes et attrape les choses qui vous prendraient sinon par surprise en pleine réunion.
- [ ] Chercher dans Slack les messages des participants contenant « décision », « on devrait », « en attente de » ou « bloqué par » dans la dernière semaine
- [ ] Vérifier dans Linear les issues avec des bloqueurs ou dépendances impliquant les participants
- [ ] Chercher les questions ouvertes dans les documents Notion partagés ou les commentaires Figma non résolus
- [ ] Relire vos propres notes de la dernière réunion avec cette personne : avez-vous promis de faire un suivi sur quelque chose ?
Ce dernier point est celui que la plupart des gens sautent, et c'est sans doute le plus important. Oublier des engagements érode la confiance de manière fiable, et y donner suite sans qu'on vous le demande la construit de manière fiable. C'est le moyen le plus simple d'améliorer les 1:1s, et cela n'a rien à voir avec des modèles de préparation de réunion ni avec un quelconque outil.
Préparation qui fonctionne
- Extraire des données d'activité spécifiques des outils avant de rédiger un quelconque ordre du jour
- Chercher les décisions en attente dans les fils Slack et les bloqueurs Linear
- Consulter les notes des réunions précédentes pour vérifier votre propre suivi
- Laisser le contexte faire émerger les sujets plutôt que deviner de quoi discuter
Préparation qui fait perdre du temps
- Rédiger un ordre du jour générique du type « Mises à jour / Bloqueurs / Action Items » sans contexte de support
- Se fier à sa mémoire pour se rappeler ce qui s'est passé durant une semaine d'utilisation dispersée des outils
- Demander « autre chose ? » à la fin parce que vous avez épuisé les sujets dont vous vous souveniez
- Traiter chaque réunion de la même façon sans tenir compte de ce qui se passe réellement dans le travail
Couche 3 : Le delta de changement (2 minutes)
Cette couche est optionnelle mais véritablement utile pour les réunions à cadence régulière, comme les 1:1s hebdomadaires ou les syncs d'équipe bimensuels. La question à laquelle vous répondez est : qu'est-ce qui a changé depuis notre dernière discussion ?
Ouvrez vos notes ou vos enregistrements de la dernière réunion (même si ces « notes » ne sont qu'une liste à puces dans un document) et comparez l'état des choses à ce moment-là versus maintenant. Spécifiquement :
- Quels issues qui étaient « in progress » la dernière fois ont été livrés ? Lesquels n'ont pas bougé ?
- De nouvelles priorités ou urgences sont-elles apparues qui n'étaient pas sur le radar ?
- Y a-t-il eu des changements d'équipe, des annonces de réorganisation ou des modifications de roadmap qui affectent le travail de cette personne ?
Le delta de changement garde votre réunion focalisée sur le progrès versus la dérive. Au lieu d'une liste plate de sujets, vous entrez dans une conversation sur la trajectoire : voici où en étaient les choses, voici où elles en sont, et voici ce que cela signifie pour ce que nous faisons ensuite.
Exemple concret : supposons que la semaine dernière votre rapport direct avait trois issues en cours sur l'epic de paiements, dont l'un était un correctif de bug haute priorité. Cette semaine, le correctif a été livré (super), un issue est passé en revue (bien), et un n'a pas été mis à jour depuis six jours (ça vaut la peine de demander, avec tact). Voilà votre structure de 1:1, et il a fallu environ quatre-vingt-dix secondes pour l'assembler.
Mettre le tout ensemble : Le modèle
Voici le modèle proprement dit. Copiez-le, adaptez-le, supprimez les parties qui ne s'appliquent pas. Le format compte moins que l'habitude.
```
Préparation de réunion : [Personne/Groupe] – [Date]
Couche 1 : Scan d'activité
- PRs récents (mergés/ouverts/en revue) :
- Issues Linear (terminés/en cours/bloqués) :
- Fils Slack notables :
- Autre activité d'outils (Figma/Notion/etc.) :
Couche 2 : Décisions et bloqueurs
- Décisions en attente nécessitant une résolution :
- Bloqueurs actifs :
- Mes suivis de la dernière réunion :
Couche 3 : Delta de changement (vs. dernière réunion)
- Ce qui a été livré :
- Ce qui n'a pas bougé :
- Nouvelles priorités/contexte :
Notes de discussion
(À remplir pendant la réunion)
Action items
(À saisir avec responsable et échéance) ```
Le modèle est délibérément agnostique en termes d'outils. Que vous interrogiez GitHub, Linear, Jira, Shortcut ou une photo de tableau blanc, la structure est la même : activité, décisions, changement.
Pourquoi cela fonctionne mieux qu'un ordre du jour
Le modèle traditionnel de préparation de réunion demande « de quoi est-ce que je veux parler ? » Celui-ci demande « que s'est-il réellement passé ? » et laisse les sujets émerger des données. En pratique, cela signifie que vous repérez des choses que vous auriez autrement manquées, comme un PR en attente de revue depuis quatre jours, ou une décision prise dans un fil Slack mais jamais reportée dans Linear.
La même checklist à chaque fois signifie aussi moins de bloqueurs oubliés. Quand la préparation est une routine concrète de cinq à sept minutes (enfin, aussi concrète que « parcourir quelques fils Slack » peut l'être), on arrête de la redouter.
Étendre cela à toute votre semaine
Supposons que vous gérez six rapports directs avec des 1:1s hebdomadaires, plus deux syncs d'équipe et une réunion interfonctionnelle. Cela fait neuf réunions nécessitant une préparation – ce qui est déjà plus de réunions que quiconque concevrait en partant de zéro si l'on construisait une entreprise sur un tableau blanc (mais c'est ainsi, et les réunions ne vont nulle part, alors occupons-nous-en).
Si chaque session de préparation dure en moyenne quinze minutes de recherche non structurée dans les outils, cela fait plus de deux heures par semaine à rassembler du contexte. Avec ce modèle de préparation de réunion, chaque session prend cinq à sept minutes une fois que vous avez développé la mémoire musculaire. Pour neuf réunions, cela représente environ une heure – vous économisez donc à peu près une heure par semaine, ce qui sur 48 semaines de travail revient à environ 48–50 heures par an. Que vous consacriez ces heures récupérées à du vrai travail d'ingénierie ou que vous regardiez simplement par la fenêtre en vous félicitant de votre processus, c'est (honnêtement) votre affaire.
stat: "~48–50 heures/an" headline: "Temps économisé sur la préparation de réunions" source: "Basé sur 9 réunions hebdomadaires sur 48 semaines de travail, 15 min non structurées vs 6 min avec modèle"
La différence de qualité se cumule aussi. Neuf réunions préparées signifient neuf conversations qui font émerger les vrais problèmes plus tôt et génèrent moins de messages Slack « ah attends, je voulais demander pour… » après coup. C'est plus difficile à quantifier, mais si vous avez déjà envoyé un DM à 15h à quelqu'un avec qui vous veniez de passer trente minutes à 10h, vous connaissez la sensation.
Quand sauter la préparation entièrement
Chaque réunion ne mérite pas une préparation. Si vous assistez à un all-hands d'entreprise ou à un café informel, ne faites pas de requêtes Linear avant (sérieusement). Et si la réunion est l'un de ces créneaux récurrents de 30 minutes que personne ne se souvient avoir planifié mais que tout le monde a peur de supprimer, peut-être que la préparation dont vous avez besoin est le courage de cliquer sur « Refuser ». Utilisez ce modèle de préparation de réunion quand vous êtes responsable des résultats ou avez besoin de prendre des décisions : 1:1s, syncs d'équipe, sessions de planification, revues interfonctionnelles.
Si une réunion ne mérite pas cinq minutes de préparation, il vaut la peine de se demander si elle mérite trente minutes de présence. Et si vous voulez aller plus loin et automatiser entièrement votre préparation de réunion, c'est une conversation séparée (et honnêtement plus intéressante).
Recevez de la signal intelligence directement dans votre boîte de réception.
Questions fréquemment posées
Q : Que devrait inclure le modèle de préparation de réunion d'un engineering manager ? A : Un bon modèle de préparation de réunion extrait trois éléments avant chaque réunion : l'activité récente des participants (PRs, issues, messages), les décisions en attente ou bloqueurs pertinents pour l'ordre du jour, et un aperçu rapide de ce qui a changé depuis la dernière réunion. Le modèle lui-même compte moins que l'habitude de le remplir avec des données réelles provenant des outils plutôt que de la mémoire.
Q : Combien de temps devrait prendre la préparation d'un 1:1 ? A : Avec un modèle structuré et les bonnes requêtes d'outils, la préparation d'un 1:1 devrait prendre moins de cinq minutes. La plupart des engineering managers y consacrent 15–20 minutes parce qu'ils cherchent manuellement dans Slack, Linear et GitHub. Un modèle qui indique précisément où chercher réduit considérablement ce temps.
Q : Est-ce que Sugarbug automatise la préparation des réunions pour les équipes d'ingénierie ? A : Oui. Sugarbug se connecte à des outils comme Linear, GitHub, Slack, Google Calendar et Notion, puis prépare un briefing avant chaque réunion en fonction des participants et de ce qui s'est passé dans ces outils. Il extrait le même contexte que vous rassembleriez manuellement avec ce modèle, mais le fait automatiquement.
Q : Puis-je utiliser ce modèle de préparation de réunion sans outils spéciaux ? A : Absolument. Le modèle fonctionne avec rien de plus qu'un éditeur de texte et des onglets de navigateur. L'objectif est une structure reproductible pour rassembler du contexte. Si vous voulez l'automatiser plus tard, des outils existent pour cela, mais le modèle se suffit à lui-même.