3 December 20257 min de lecture
Toute équipe qui commence à travailler sur plusieurs sites fait la même découverte le même mois : ce qui s’est cassé, ce ne sont pas les réunions. Ce sont toutes ces choses qui se réglaient en quatre minutes après une réunion, debout près de la porte, et qui désormais ne se règlent nulle part.
La réaction habituelle est d’écrire davantage. La direction est bonne et, appliquée sans discernement, elle produit un wiki de quatre cents pages auquel personne ne se fie parce que personne ne sait quelles pages sont encore vraies. La question utile est plus étroite : que faut-il précisément écrire, et où cela va-t-il.
La position par défaut est fausse dans les deux sens
Les équipes écrivent trop sur ce qui change constamment et pas assez sur ce qui ne change presque jamais. Les points d’avancement, répétés trois fois par semaine dans des mots légèrement différents, représentent un gros volume d’écriture avec une durée de vie de deux jours. Pendant ce temps, la raison pour laquelle la logique de reprise des paiements fonctionne ainsi, stable depuis deux ans et destinée à dérouter chaque nouvel arrivant, n’est écrite nulle part.
Inversez la logique. Écrivez abondamment sur les décisions et le raisonnement, qui sont durables. Soyez bref sur l’état d’avancement, qui est périssable et de toute façon visible dans l’outil de suivi.
Ce qu’il faut réellement écrire
- Les décisions, avec la raison et les options écartées. Les options écartées sont la moitié précieuse ; sans elles, la personne suivante rouvrira le même débat.
- Tout ce qui a été convenu oralement lors d’un appel, écrit ensuite par celui qui a passé l’appel, à l’endroit où vit le travail plutôt que dans un message de chat qui disparaît vers le haut.
- Le raisonnement derrière un ticket : pourquoi cela se construit, qui l’utilise, à quoi ressemblerait un mauvais résultat.
- Les contraintes qui ne sautent pas aux yeux dans le code : le client qu’on ne peut pas casser, la migration qui ne doit pas tourner pendant les heures ouvrées, le service auquel personne ne touche sans demander.
- Tout ce que vous avez expliqué deux fois à l’oral. La troisième fois prouve que cela doit être écrit.
Notez ce qui manque. Pas de comptes rendus de réunion. Pas de transcription. Pas de récit quotidien de ce que chacun a fait. Ce sont les artefacts que produisent les équipes à qui l’on a dit de communiquer davantage sans leur dire pourquoi.
Des décisions, pas des comptes rendus
L’habitude d’écriture la plus rentable pour une équipe distribuée est la note de décision courte. Quelques phrases : ce que nous avons décidé, pourquoi, ce que nous avons envisagé à la place, et à qui s’adresser. Attachée au ticket ou à la pull request concernée, et non classée dans une archive séparée.
Cela survit aux fuseaux horaires, aux types de contrat et aux départs. C’est aussi ce qui rend la passation peu coûteuse deux ans plus tard, car le transfert de connaissances est surtout un transfert de raisonnement, et le raisonnement est la partie qui n’arrive jamais dans le code.
Un seul endroit, et une règle sur lequel
Un contexte écrit éparpillé entre la messagerie, les e-mails, un wiki, des commentaires de tickets et trois documents équivaut fonctionnellement à une absence de contexte écrit, car personne ne peut être certain d’avoir tout trouvé. La discipline ne porte pas sur le volume. Elle porte sur l’existence d’une règle que chacun sait énoncer.
Une règle qui fonctionne : la messagerie sert à la coordination et est réputée perdue ; le ticket contient tout ce qui concerne ce travail précis ; le dépôt contient tout ce qui concerne le fonctionnement du système. Si un écrit n’appartient manifestement ni à un ticket ni au code, c’est probablement une note de décision, et sa place est auprès de ce qu’elle contraint.
Le test est simple. Quelqu’un qui arrive dans six mois doit pouvoir trouver la réponse sans demander à un humain. Si le seul chemin passe par une personne, ce n’est pas écrit, c’est mémorisé.
Comment poser une question qui n’a besoin d’une réponse qu’une fois
Les questions asynchrones ont une structure de coût que les gens sous-estiment. Une question floue coûte un aller-retour, et un aller-retour même sur un petit écart horaire peut coûter la majeure partie d’une journée. Deux allers-retours et la journée est perdue.
Le format qui l’évite : indiquez ce que vous cherchez à faire, ce que vous avez déjà essayé, le point précis sur lequel vous bloquez et, surtout, ce que vous ferez si personne ne répond. C’est cette dernière partie qui fait l’essentiel du travail. Elle convertit une question bloquante en question non bloquante, et elle permet à l’autre partie de répondre d’un seul mot quand l’hypothèse est bonne.
Cela vaut dans les deux sens. Un responsable qui demande « comment ça avance ? » a posé une question à laquelle on ne peut pas répondre utilement et a dépensé un aller-retour pour s’en apercevoir.
Le chevauchement sert à ce que l’écrit ne peut pas faire
Tout consigner par écrit ne remplace pas le fait de se parler, et les équipes qui traitent l’asynchrone comme une idéologie plutôt que comme un outil finissent par régler un désaccord en neuf messages là où un appel de dix minutes aurait suffi.
Réservez les heures communes aux catégories où l’écrit est réellement moins bon : le désaccord, l’ambiguïté qui demande plusieurs échanges, tout ce qui comporte un risque de ton, et la première conversation sur un travail dont la forme n’est pas encore claire. Une journée de travail qui se recouvre sur la majeure partie de sa longueur, ce qui est le cas entre Beyrouth et l’Europe de l’Ouest, rend cela assez peu coûteux pour qu’il n’y ait aucune raison d’être dogmatique. Puis écrivez ce que vous avez conclu.
Le coût, énoncé honnêtement
Écrire prend du temps et une partie de cet effort est perdue. Des notes de décision sont rédigées pour des décisions que personne ne rouvre. Du contexte est ajouté à des tickets qui seront annulés. Ce gaspillage est réel, et l’argument pour continuer n’est pas que chaque note soit rentable. C’est que vous ne pouvez pas savoir à l’avance lesquelles le seront, et que celles qui le sont le sont énormément, généralement au moment où quelqu’un part ou lorsqu’une mission change de mains.
Commencez par deux habitudes plutôt que par une politique : les décisions s’écrivent là où vit le travail, et tout ce qui est expliqué deux fois est écrit la troisième. Une équipe qui ne fait que ces deux choses est mieux documentée que la plupart, et aucune des deux n’oblige à entretenir un wiki.