Modèle de journal des décisions pour équipes à distance : une page par décision, avec un responsable et les options écartées

Pourquoi les équipes asynchrones décident par écrit

Les équipes qui partagent un bureau décident presque tout à voix haute, et ceux qui comptent l'entendent. Cela cesse de fonctionner entre fuseaux horaires : ceux qui étaient réveillés décident, ceux qui dormaient l'apprennent plus tard, et le raisonnement est déjà perdu. Écrire la décision avant qu'elle soit définitive apporte trois choses :

• La décision devient retrouvable. Les nouvelles recrues, les prestataires et vous-même dans un an pouvez la chercher au lieu de demander.
• Les alternatives sont conservées. Le choix retenu est rarement la partie intéressante. Les options refusées, et pourquoi, sont ce qui empêche le même débat de recommencer chaque trimestre.
• La décision a un responsable. Une décision sans propriétaire est annulée en silence. Une décision avec un nom dessus est défendue, ou changée délibérément.

Le monde du logiciel dispose d'un format pour cela depuis 2011, quand Michael Nygard a publié « Documenting Architecture Decisions ». Son architecture decision record (ADR) comporte cinq parties : titre, contexte, décision, statut et conséquences, avec les statuts proposed, accepted, deprecated et superseded. Le modèle ci-dessous garde cette ossature et ajoute les champs dont une équipe généraliste a besoin : un responsable, les options écartées dans une section dédiée, une date de revue et les personnes consultées.

Le modèle de journal des décisions

Copiez ceci dans une nouvelle page pour chaque décision. Gardez les titres ; supprimez le texte d'aide dont vous n'avez pas besoin.

Titre : Groupe nominal court. « Utiliser Postgres pour le stockage des événements », pas « Base de données ».
ID : DEC-014
Statut : Proposée | Acceptée | Remplacée par DEC-0xx | Obsolète
Responsable : Un seul nom. La personne qui peut changer cette décision.
Date de décision : 2026-10-28
À revoir le : 2027-04-28 (ou « jamais » pour les décisions irréversibles)
Consultés : Personnes dont l'avis a été demandé avant de décider
Informés : Personnes ou canaux prévenus après la décision

== Contexte
Quelle situation a imposé un choix. Des faits, des contraintes et des délais,
pas des opinions. Deux à six phrases.

== Décision
Le choix, en une ou deux phrases complètes, à la voix active :
« Nous allons ... ».

== Options écartées
1. Option A : pourquoi elle a perdu.
2. Option B : pourquoi elle a perdu.
3. Ne rien faire : ce que cela aurait coûté.

== Conséquences
Ce qui devient plus facile, ce qui devient plus difficile, ce que nous devons désormais
(migrations, formation, une décision ultérieure).

== Confirmation
Comment nous saurons que la décision a tenu : une métrique, une date, une vérification.

Les identifiants numérotés (DEC-001, DEC-002) comptent plus qu'il n'y paraît. Ils permettent à un message de chat, un commit ou une tâche de dire « voir DEC-014 » sans lien qui finira par casser, et ils rendent « remplacée par DEC-021 » sans ambiguïté.

À quoi sert chaque champ

Statut. Proposée signifie que le responsable l'a rédigée et attend des commentaires. Acceptée signifie que la fenêtre de commentaires est close et que la décision tient. Remplacée pointe vers la décision plus récente qui l'a remplacée. Obsolète signifie qu'elle ne s'applique plus et que rien ne l'a remplacée. Ne modifiez jamais le corps d'une décision acceptée ; écrivez-en une nouvelle et remplacez l'ancienne.

Responsable. Exactement une personne. Pas une équipe, pas deux co-responsables. Le responsable est celui qui propose la décision, clôt la fenêtre de commentaires et est interrogé en premier quand quelqu'un veut la changer. Si vous ne pouvez pas nommer un responsable, la décision n'est pas prête.

Contexte. Les forces en présence : le délai, le budget, l'intégration qui a cassé, le client qui a demandé. Écrivez-le pour qu'un lecteur dans un an comprenne pourquoi « ne rien faire » n'était pas acceptable. Laissez les arguments de côté ; ils vont dans les options.

Options écartées. C'est la section que la plupart des modèles sautent et celle qui rapporte le plus. Chaque option écartée a une ligne et une raison. « Trop cher » n'est pas une raison ; « 450 $ par mois à notre nombre de sièges contre 39 $ » en est une.

Conséquences. Dans les deux sens. Une décision qui n'a que des avantages n'a pas été pensée jusqu'au bout. Incluez les dettes : la migration que vous devez désormais, la compétence qu'il faut maintenant recruter, la décision ultérieure que vous avez repoussée.

Confirmation. Comment vous vérifierez, plus tard, que la décision a produit ce que vous attendiez. Ce champ est emprunté à MADR, le modèle Markdown Architectural Decision Records d'adr.github.io, qui a ajouté une section Confirmation à côté de Context and Problem Statement, Decision Drivers, Considered Options, Decision Outcome et Pros and Cons of the Options. Une ligne de confirmation transforme la date de revue en question avec une réponse plutôt qu'en simple rappel d'agenda.

Journal des décisions, ADR et MADR comparés

Si toutes les décisions de votre équipe touchent au code, gardez les ADR dans le dépôt et sautez le reste de cet article. Si vos décisions incluent « quel prestataire de paie » et « proposons-nous un plan annuel », elles ont besoin d'un endroit lisible par ceux qui n'ouvrent pas le dépôt.

Comment documenter une décision de façon asynchrone

Le modèle est la partie facile. Le process est ce qui rend la chose asynchrone plutôt qu'une réunion avec de la frappe en plus.

1. Ouvrez l'entrée en Proposée avant d'avoir décidé. Le responsable écrit le contexte, un brouillon de décision et au moins deux options écartées. Écrire d'abord les alternatives est ce qui force une vraie réflexion ; une décision rédigée après coup est un communiqué de presse.
2. Fixez la fenêtre de commentaires. Dites-le dans l'entrée : « Commentaires jusqu'à jeudi 17:00 UTC ». Quarante-huit heures couvrent deux fois tous les fuseaux. Pour une décision réversible, vingt-quatre suffisent.
3. Postez un seul message, dans un seul canal. Mettez le lien de l'entrée, indiquez la fenêtre, mentionnez nommément les personnes consultées. Ne collez pas toute la décision dans le chat ; la page est l'archive, le chat est la notification.
4. Commentez sur la page, pas dans le fil. Les commentaires en ligne restent attachés à la phrase concernée. Un fil de chat a disparu en une semaine.
5. Le responsable clôt la fenêtre. Soit la décision passe en Acceptée, éventuellement modifiée selon les commentaires, soit le responsable explique pourquoi elle a changé et rouvre une fenêtre plus courte. Le silence vaut accord ; écrivez-le dans l'entrée pour que personne ne soit surpris.
6. Fixez la date de revue au moment d'accepter. Six mois est un défaut raisonnable pour les décisions d'outillage et de process. Pour une décision qui ne peut pas être annulée à bas coût, écrivez « jamais » et dites pourquoi.
7. Prévenez la liste des informés. Une ligne dans le canal d'équipe : « DEC-014 acceptée : nous utiliserons X. Revue en avril ». C'est toute l'annonce.

La cadence de revue qui garde le journal vivant

Les journaux meurent parce que personne ne les lit. Deux vérifications récurrentes y remédient, toutes deux faites par une seule personne.

Chaque semaine, cinq minutes. Le propriétaire du journal (en général la personne qui tient les opérations) filtre sur Statut = Proposée et vérifie que chaque entrée a une fenêtre de commentaires qui n'a pas expiré en silence. Les fenêtres expirées passent en Acceptée ou reçoivent une relance.

Chaque mois, vingt minutes. Filtrez sur À revoir le dans les 30 prochains jours. Pour chaque décision, le responsable répond à la ligne de confirmation en un seul commentaire : a tenu, a tenu avec des changements, ou n'a pas tenu. Une décision qui n'a pas tenu reçoit une nouvelle entrée en Proposée qui la remplace. C'est la seule réunion dont le journal ait jamais besoin, et elle peut être un compte rendu écrit plutôt qu'un appel.

Deux chiffres disent si le journal fonctionne. Le premier est la part des décisions avec au moins une option écartée notée ; en dessous de 80 pour cent, les gens consignent après coup. Le second est le nombre d'entrées en Remplacée. Zéro après un an signifie que les décisions changent dans le chat et que le journal est devenu une fiction.

Tenir le journal dans Atrix

N'importe quel outil capable de contenir une page par décision et de filtrer sur un champ fera l'affaire : un dossier de fichiers Markdown dans le dépôt, une base Notion, un espace Confluence. Nous tenons le nôtre comme base de données de pages dans Atrix, c'est-à-dire une page dont les sous-pages sont des lignes, et voici ce que cela donne en pratique.

La page de base de données reçoit sept propriétés, bien en dessous de la limite de vingt : Statut en sélection avec Proposée, Acceptée, Remplacée et Obsolète ; Responsable en personne ; Décidée et À revoir le en dates ; Consultés en texte ; Remplace en texte contenant l'ancien ID ; et Confirmée en case à cocher que la revue mensuelle coche. Chaque ligne est une page complète, donc le modèle ci-dessus vit dans le corps de la ligne et les propriétés dans le tableau. Les types de propriété disponibles sont texte, nombre, sélection, date, case à cocher, personne et URL ; il n'y a donc ni formule ni rollup. Si vous en avez besoin, gardez un tableur à côté.

Deux choses rendent cela meilleur qu'un dossier de fichiers pour une équipe non technique : les commentaires sont posés sur la phrase concernée, et l'historique de la page garde chaque modification, donc « qui a changé la décision après son acceptation » a une réponse. Documents et tableaux blancs donne la liste complète de ce que les pages savent faire.

Ce que nous ne pensions pas utiliser tous les jours, c'est le serveur MCP. Le serveur MCP d'Atrix expose 85 outils, dont pages_create et pages_append, si bien qu'un assistant IA connecté à l'espace de travail peut rédiger une entrée à partir d'un fil de discussion et l'ajouter au journal sans que personne ne quitte la conversation. L'outil pages_append fusionne avec quiconque modifie la page au même moment au lieu de l'écraser, ce qui compte quand le responsable est au milieu d'une phrase. L'assistant rédige en Proposée ; une personne fixe toujours le responsable, clôt la fenêtre et marque Acceptée. L'installation tient en une commande claude mcp add et une connexion OAuth ; la documentation MCP détaille les scopes, et Claude comme les autres assistants listés fonctionnent de la même façon.

Les limites méritent d'être dites. Il n'y a pas de plan gratuit : un espace de travail coûte 39 $ par mois en Builder pour 5 sièges ou 149 $ en Studio pour 15, après un essai de 7 jours qui demande une carte. La base de données n'a pas de colonnes de formule, et il n'existe pas encore de rappel automatique « revue à faire » sur une propriété de page ; nous utilisons le filtre mensuel à la place.

FAQ

Quelle est la différence entre un journal des décisions et un registre des décisions ?

Aucune qui compte. Les chefs de projet parlent plutôt de registre, les équipes logicielles de journal, et les deux désignent une entrée par décision avec un statut et un responsable. Choisissez un mot et utilisez-le partout pour que la recherche fonctionne.

Quel niveau de détail pour une entrée du journal des décisions ?

Assez pour que quelqu'un qui n'était pas impliqué comprenne pourquoi la décision a été prise et ce qui a été écarté, et pas plus. La plupart des entrées tiennent en 150 à 400 mots. Si une entrée dépasse une page, c'est probablement deux décisions, ou un document de conception vers lequel la décision devrait renvoyer.

Qu'est-ce qu'un architecture decision record ?

Un ADR est un document court qui consigne une décision architecturalement significative : le contexte, la décision, son statut et ses conséquences. Le format vient du billet de Michael Nygard de 2011, « Documenting Architecture Decisions », et se conserve en général sous forme de fichiers Markdown numérotés dans le dépôt. MADR est un modèle d'ADR plus structuré, avec des sections pour les options considérées et leurs avantages et inconvénients.

Qui doit être propriétaire du journal des décisions ?

Une personne est propriétaire du journal dans son ensemble, en général celle qui tient les opérations ou le lead engineering, et effectue les vérifications hebdomadaire et mensuelle. Chaque décision a son propre responsable, la personne capable de la changer. Ce sont des rôles différents, et ce devraient le plus souvent être des personnes différentes.

Faut-il aussi consigner les petites décisions ?

Consignez une décision si l'annuler coûterait plus d'une heure, si elle touche le travail de plus d'une personne, ou si quelqu'un demandera probablement « pourquoi » dans six mois. Quelle règle de linter activer n'a pas besoin d'entrée ; quel linter, si.

Que faire d'une décision qui se révèle mauvaise ?

Écrivez une nouvelle entrée. Passez l'ancienne en Remplacée par le nouvel ID et laissez son corps intact. Le journal est une histoire, et la trace d'une mauvaise décision avec son raisonnement intact est plus utile qu'une version corrigée qui cache ce que l'on savait à l'époque.

Prochaine étape

Créez une page « Décisions », transformez-la en base de données avec Statut, Responsable et À revoir le, et collez le modèle dans sa première ligne. Documents et tableaux blancs montre l'éditeur, et la page des tarifs donne les limites de chaque plan si vous voulez l'essayer avec votre propre équipe.