La réunion de planning qui remplace trois jours de Notion non lu

L’équipe est distribuée sur trois fuseaux horaires. Les docs sont dans Notion. Les décisions sont censées se prendre de manière asynchrone pour respecter les contraintes de disponibilité de chacun.

Le problème : ça fait trois semaines que la page de planification Q3 est en draft. Elle a dix-sept commentaires. Personne n’a pris la décision de lancer la capability A avant la capability B. L’équipe travaille sur la capability B parce que c’est ce que les développeurs ont choisi en attendant une clarification qui n’est pas venue.

Ce n’est pas une histoire de timezones ou d’outils. C’est une histoire de confondre communication et décision.

L’async n’est pas fait pour tout

La communication asynchrone a des propriétés précieuses. Elle respecte les rythmes différents. Elle permet la réflexion avant la réponse. Elle crée un historique. Elle fonctionne très bien pour transmettre de l’information, partager du contexte, recueillir des avis.

Elle fonctionne mal pour prendre des décisions collectives sur des sujets complexes avec des dépendances multiples.

Voici pourquoi : une décision complexe implique souvent de résoudre plusieurs questions en séquence rapide. « Fait-on A avant B ? Ça dépend de si C est déjà terminé. Mais si C est terminé, alors on peut faire A et B en parallèle, sauf si l’équipe front n’est pas disponible. Dans ce cas, B en premier. Mais B dépend d’une décision sur le design que personne n’a encore prise. »

Cette conversation, en async, produit des fils de commentaires qui s’allongent sur plusieurs jours sans résolution. Chaque réponse nécessite un re-contexte complet. Les décisions intermédiaires ne se prennent pas parce que personne ne sait si la prochaine réponse va changer les conditions.

La même conversation, en synchrone, prend vingt minutes.

Ce que produit une bonne réunion de planning

Une réunion de planning bien menée produit une chose : des décisions.

Pas des comptes-rendus. Pas des listes de questions. Pas des « à discuter avec l’équipe ». Des décisions. Des arbitrages tranchés sur ce qui est dans le périmètre et ce qui ne l’est pas. Des responsabilités claires sur qui fait quoi. Des dépendances identifiées et séquencées.

Ces décisions, une fois prises en réunion, peuvent être documentées de manière asynchrone. Le Notion reprend de la valeur : c’est là où on note ce qui a été décidé, pas là où on essaie de décider.

La distinction est fondamentale. Notion est excellent pour documenter. Il est mauvais pour décider.

Les caractéristiques d’une réunion de planning qui fonctionne

Pas toutes les réunions de planning sont utiles. Beaucoup sont du Scrum théâtre appliqué au planning : une forme respectée, un fond absent.

Ce qui rend une réunion de planning efficace :

Un objectif de sortie défini à l’avance. Pas « on va discuter du Q3 ». « On sort de cette réunion avec la liste des capabilities du Q3 priorisées, les dépendances identifiées et un responsable désigné pour chaque capability. »

La différence entre ces deux formulations est la différence entre une réunion qui se termine par « merci, on se reparle » et une réunion qui se termine par « ok, c’est acté, qui note les décisions ? ».

Les participants qui ont le mandat de décider. Une réunion de planning avec des gens qui doivent « remonter à leur manager » ou « vérifier avec l’équipe » avant de valider ne produit pas de décisions. Elle produit une liste de questions supplémentaires.

Chaque participant doit avoir le mandat de valider ce qui concerne son périmètre. Si ce n’est pas le cas, les bonnes personnes ne sont pas dans la réunion.

Un backlog pré-filtré. Arriver en réunion de planning avec un backlog non travaillé et essayer de tout prioriser en temps réel est inefficace. Le travail de pré-filtrage - identifier les candidats pour le cycle, éliminer les redondances, regrouper les items connexes - doit se faire avant la réunion, de manière asynchrone.

La réunion traite les cas ambigus et les arbitrages. L’async traite le tri préliminaire.

Une limite de temps tenue. Une réunion de planning sans limite de temps dérive. Deux heures pour planifier un trimestre est atteignable si le backlog est préparé. Quatre heures révèle un problème de préparation ou de mandat.

La question de la distribution géographique

L’argument le plus courant contre les réunions synchrones est la distribution géographique. Si l’équipe est sur Paris, Montréal et Sydney, il n’y a pas de fenêtre commune acceptable.

C’est vrai. Mais ça appelle une réponse différente de « on fait tout en async ». Ça appelle une réflexion sur la structure de l’équipe.

Une équipe où les décisions de planification nécessitent la présence de personnes sur trois fuseaux à douze heures de décalage a probablement un problème de structure plus fondamental : trop de couplage entre des sous-équipes qui devraient être plus autonomes.

Dans les équipes vraiment distribuées qui fonctionnent bien, il y a généralement une de ces deux solutions : soit les décisions de planification sont prises au niveau de l’équipe locale avec une interface claire vers les autres équipes, soit il y a une fenêtre de synchronisation acceptable (même imparfaite) réservée aux décisions importantes.

Dire « on fait tout en async » est souvent une façon d’éviter de régler le vrai problème.

Le paradoxe de la documentation async

Voici un paradoxe fréquent dans les équipes tech : plus une équipe documente de manière asynchrone, moins la documentation est lue.

Quand tout passe par Notion et Slack, chacun est submergé de notifications et de mises à jour. La page de planification Q3 n’est qu’une parmi les vingt pages qui ont changé cette semaine. Elle sera lue partiellement, commentée sans relire les commentaires précédents, ou simplement pas lue du tout.

La réunion de planning crée un point de synchronisation. Tout le monde est dans la même pièce (ou le même appel) en même temps. L’information circule en une fois. Les questions sont posées et répondues immédiatement. Le document produit après la réunion n’est pas une spec à déchiffrer : c’est un compte-rendu de décisions que tout le monde a entendues.

Ce document-là est lu. Parce qu’il y a un contexte partagé qui donne envie de vérifier ce qui a été acté.

Planifier sans réunion : quand ça marche vraiment

Il existe des contextes où la planification async fonctionne bien.

Les équipes très petites avec un fort alignement. Deux personnes qui se connaissent bien, ont les mêmes objectifs et une communication fluide peuvent planifier en async parce que les décisions implicites sont déjà partagées.

Les décisions de faible impact. Choisir l’ordre de deux tickets de même priorité ne nécessite pas une réunion. Écrire « je commence par X, ça te va ? » dans Slack est suffisant.

Les équipes avec une culture de décision claire. Quand les rôles sont définis et que chacun peut prendre des décisions dans son périmètre sans validation collective, l’async fonctionne parce qu’il y a moins de points de décision collective.

Dans ces contextes, forcer une réunion serait contre-productif. Le problème, c’est quand on applique l’async par défaut à des situations qui ne remplissent pas ces conditions.

Ce que la réunion de planning révèle

Un dernier effet de la réunion de planning synchrone : elle révèle les désaccords.

En async, le désaccord peut rester latent. Chacun continue de son côté, convaincu que sa lecture du plan est correcte. La divergence n’émerge qu’à la réunion de review quand il est trop tard pour changer de cap facilement.

En synchrone, le désaccord s’exprime immédiatement. Ce moment peut être inconfortable. Il est aussi productif : c’est le moment où deux visions différentes du même travail se rencontrent, se challengent, et arrivent à une résolution commune.

La réunion de planning est un détecteur de désaccords latents. C’est peut-être la raison pour laquelle certaines équipes l’évitent.

L’async est un outil puissant. La réunion de planning en est un autre. L’erreur est de traiter l’async comme une idéologie plutôt qu’un moyen parmi d’autres.

Une heure de synchronisation au bon moment produit plus de valeur que trois semaines de commentaires Notion. Le tout est de savoir quand utiliser lequel.