Éléments d'action vs. Décisions : Pourquoi le suivi des tâches fait perdre le raisonnement
Un élément d'action est une tâche : ce qui sera fait, par qui, d'ici quand — il se clôt lorsque le travail est terminé. Une décision est un choix : l'option X par rapport aux options Y et Z, pour des raisons — et elle reste pertinente longtemps après que chaque tâche associée soit clôturée, car elle explique pourquoi les choses sont telles qu'elles sont. Les équipes suivent rigoureusement les éléments d'action dans les systèmes de tâches tandis que les décisions qui les sous-tendent ne sont pas enregistrées, ce qui explique pourquoi des questions réglées sont de nouveau débattues. La solution : consigner chaque décision significative avec ses options et sa justification dans un registre de décisions, et laisser les éléments d'action faire référence à la décision qu'ils exécutent.
Votre suivi des tâches est méticuleux et vos décisions sont légendaires. La distinction qui le fixe est suffisamment petite pour tenir en une ligne chacune :
- Un élément d'action est une tâche — quoi, qui, quand. Il se clôt lorsque le travail est terminé, et une fois clôturé, il devient une histoire inerte.
- Une décision est un choix — X plutôt que Y et Z, parce que. Elle ne "se ferme" jamais : elle reste porteuse tant que ses conséquences perdurent.
- Les outils et les habitudes capturent le premier et perdent le second — la tâche survit à la réunion, le raisonnement ne le fait pas.
- La solution est une habitude : les décisions importantes sont enregistrées avec des options et des justifications (le guide), et les éléments d'action font référence à la décision qu'ils exécutent.
La réunion se termine bien. Trois éléments d'action apparaissent dans le suivi en quelques minutes : "Migrer la facturation vers le fournisseur A — K., fin de sprint." "Déprécier l'ancien point de terminaison — S., vendredi." "Mettre à jour la page de tarification — M., jeudi." Propriétaires, délais, critères de réalisation. Manuel.
Six mois plus tard, les trois tâches sont depuis longtemps closes — et un nouveau responsable d'équipe se demande pourquoi le fournisseur A a été choisi plutôt que l'alternative évidente. Le suivi a la réponse à une question que personne ne pose : qui a migré la facturation et quand. La question posée — pourquoi — n'a jamais été un point d'action pour quiconque. C'était la décision dont découlaient les points d'action, et elle n'existe nulle part.
Ceci est la version au niveau des tâches d'une frontière que cette série trace trois fois : au niveau du document dans les minutes contre le registre des décisions, et comme une pratique d'écriture complète dans comment documenter les décisions. Ce post est la coupure la plus nette des trois, car les tâches et les décisions sont confondues dans le même souffle — généralement dans la dernière minute de la réunion : "d'accord, donc les éléments d'action sont…"
La tâche a été suivie.
La décision s'est perdue.
Le mode de défaillance des réunions bien organisées
Élément d'action vs. Décision : La véritable différence
Mettez les deux artefacts côte à côte et ils diffèrent sur chaque propriété qui compte :
Ce que c'est
Point d'action : une unité de travail — ce qui sera fait, par qui, d'ici quand. Décision : un choix résolu — option X plutôt que Y et Z, pour des raisons énoncées.
Quand cela se termine
Un élément d'action se clôt lorsque le travail est expédié, et "clos" signifie inerte. Une décision n'a pas d'état final : elle reste porteuse de charge tant que ses conséquences perdurent — souvent pendant des années.
Quelle question cela répond-il plus tard ?
La tâche répond à "a-t-elle été faite ?" La décision répond à "pourquoi est-ce comme ça ?" — la question que chaque nouvel employé, auditeur et post-mortem pose en réalité.
Ce que cela coûte de le perdre
Une tâche perdue refait surface d'elle-même — quelqu'un remarque que le travail est manquant. Une décision perdue échoue silencieusement : le choix reste en vigueur tandis que son raisonnement s'évapore, jusqu'à ce que quelqu'un la relitige depuis le début.
Pourquoi la décision est l'actif durable
Voici l'asymétrie qui rend cela digne d'un post : l'élément d'action n'a plus de valeur après son achèvement ; la décision prend de la valeur. Personne n'a jamais eu besoin de "migrer la facturation — K., fin de sprint" après que la migration ait été effectuée. Mais "Fournisseur A plutôt que B et construction, car l'hébergement UE a éliminé B et la construction a coûté deux trimestres" devient de plus en plus précieux chaque mois — il intègre le nouveau responsable en quarante secondes, il établit un précédent auquel le choix du prochain fournisseur peut se référer, et lors du renouvellement du contrat, il vous indique exactement quelles hypothèses vérifier à nouveau.
Les équipes ont le stockage exactement à l'envers : des systèmes élaborés pour l'artefact avec une durée de vie d'un sprint, et aucun système du tout pour l'artefact avec une durée de vie de plusieurs années. Cette inversion n'est pas de la négligence — les outils de suivi des tâches existent parce que les tâches ont des propriétaires qui ressentent la douleur de les perdre cette semaine. Une décision perdue fait mal à quelqu'un d'autre, plus tard, qui ne peut pas retracer la douleur à sa cause. (Nous avons comptabilisé ce coût cumulatif séparément dans le coût des décisions non documentées.) Les objectifs héritent de l'inversion identique — les cibles trimestrielles sont suivies méticuleusement et le raisonnement qui les a établies est introuvable, ce qui est le cas pour traiter un Résultat Clé comme un enregistrement de décision.
Ce qu'un véritable enregistrement de décision capture
La réparation ne consiste pas à alourdir les éléments d'action avec du contexte — il s'agit de donner à la décision son propre artefact. La pratique complète est l'enregistrement en sept champs; l'essence au niveau des tâches est trois choses qu'un élément d'action ne peut structurellement pas contenir : les options qui ont échoué (donc "avons-nous déjà envisagé… ?" a une réponse), les arguments qui ont décidé (de sorte que le raisonnement puisse être jugé lorsque les circonstances changent), et une date de révision (afin que le choix soit réexaminé intentionnellement plutôt que par crise).
Puis liez vers le bas : chaque élément d'action qui exécute la décision y fait référence. "Migrer la facturation — K., fin du sprint (Décision #47)." Un pointeur, et l'historique inerte du suivi devient navigable de nouveau vers un raisonnement vivant — qui est aussi la colonne vertébrale d'un audit de décision utilisable. SPADE nomme la même couture dans ses propres lettres : D produit la décision, et les éléments d'action sont ce qui découle de E par la suite — deux artefacts d'un même rituel, qui est exactement la séparation pour laquelle cet article plaide.
Les éléments d'action exécutent des décisions.
Ils ne peuvent pas les expliquer.
Un journal de décision n'est pas une liste de tâches.
Une confusion mérite son propre avertissement, car les outils l'encouragent : mettre les décisions dans le suivi des tâches en tant que tâches spéciales. Cela semble ordonné et cela échoue structurellement — tout le cycle de vie du suivi est inadapté aux décisions. Les tâches veulent être clôturées ; les décisions ne doivent pas l'être. Les tâches sont archivées hors de vue une fois terminées ; les décisions doivent rester trouvables précisément après que tout ce qui les entoure est "terminé". Les tâches appartiennent à celui qui les exécute ; les décisions à celui qui les prend. Six mois plus tard, une décision classée comme une tâche est un ticket clôturé dans un sprint archivé — techniquement stockée, pratiquement disparue.
Les deux systèmes coexistent proprement dès que chacun détient son propre artefact : le tracker suit le travail, le journal conserve les choix, et des pointeurs les relient. (Version au niveau du document de la même séparation : procès-verbaux vs. le journal des décisions.)
Nos billets portent déjà le contexte
La plus forte objection : les tickets modernes sont riches — descriptions, fils de commentaires, liens. Tout le débat sur le fournisseur est là, dans les commentaires de l'épopée, horodaté. Pourquoi maintenir un second artefact alors que la discussion est déjà attachée à l'œuvre ?
Deux réponses structurelles. Premièrement, un fil de commentaires est une transcription, pas un verdict : il préserve tout ce qui a été dit, dans l'ordre, sans marqueur indiquant quel argument a réellement décidé de l'issue — reconstruire la logique à partir de quarante commentaires est de l'archéologie, et le prochain lecteur ne le fera pas. Deuxièmement, le fil est classé sous le travail, pas le choix : lorsque l'épopée se termine et que le sprint est archivé, la discussion sombre avec elle. Le rôle du dossier est l'opposé — un verdict d'une demi-page avec le raisonnement décisif, classé sous la question, trouvable lorsque le travail qui l'a porté est depuis longtemps disparu.
La concession honnête : pour de petits choix réversibles, le fil de ticket est vraiment suffisant — cette pratique est pour des décisions que vous détesteriez devoir re-argumenter. Si le retour en arrière coûte un sprint ou plus, cela mérite un enregistrement ; si le retour en arrière coûte un après-midi, laissez le ticket le porter.
Le diagnostic
Ouvrez votre suivi et trouvez une tâche complétée qui a exécuté un choix significatif. Essayez maintenant de répondre, à partir de tout ce qui est écrit quelque part : quelles étaient les alternatives, et pourquoi ont-elles échoué ? Si la piste se termine par "per discussion" — vos décisions sont du folklore avec des délais.
Comment Argumentree capture les décisions — avec le raisonnement associé
La raison pour laquelle les décisions ne sont pas enregistrées est que les les enregistrer est une étape distincte après la discussion — et les étapes distinctes sont souvent omises. Dans Argumentree, la discussion elle-même constitue l'enregistrement : la question est explicite, les options portent leurs arguments pour et contre dans un arbre noté, et la décision est accompagnée de son raisonnement décisif déjà structuré. Rien à transcrire, rien à reconstruire.
Les éléments d'action font alors le seul travail pour lequel ils sont bons — exécuter — tandis que chaque question "pourquoi" est dirigée vers un enregistrement vivant. Le tracker maintient le sprint ; Argumentree conserve les raisons. Pour capturer la prochaine décision au lieu de simplement ses tâches, commencez gratuitement et enregistrez un vrai choix avec son raisonnement.
Suivez le travail. Gardez le pourquoi.
Les éléments d'action et les décisions sont tous deux de réels artefacts et méritent tous deux des systèmes — l'échec réside dans l'utilisation d'un seul système pour les deux et dans le fait de laisser l'artefact durable mourir dans le cycle de vie de celui jetable.
Alors gardez la dernière minute de vos réunions, avec un amendement. Après "d'accord, les actions à entreprendre sont...", ajoutez la deuxième question : "et qu'est-ce que nous venons de décider, et pourquoi ?" Cinq minutes, sept champs, une entrée de journal — et le prochain nouveau prospect obtient une réponse au lieu d'un projet archéologique.
Les tâches se rapprochent. Les décisions s'accumulent.
Donnez aux décisions leur propre système
Argumentez-le une fois, de manière structurée — et maintenez le raisonnement tant que la décision tient.
Sources et lectures complémentaires
- Nygard, M. (2011). Documenter les décisions architecturales. Cognitect.La pratique du record-par-décision à laquelle s'applique ce post se situe à la frontière des tâches — les décisions survivent au travail qui les met en œuvre.
- Rogers, P. & Blenko, M. (2006). Qui a le D ? Harvard Business Review, janvier 2006.Propriété de la décision (RAPID®) — pourquoi le décideur, et non le faiseur, possède le dossier.
- Registres de Décisions Architecturales — adr.github.ioModèles et outils pour la pratique des enregistrements de décision.
Questions Fréquemment Posées
Quelle est la différence entre un élément d'action et une décision ?
Un élément d'action est une tâche — ce qui sera fait, par qui, d'ici quand — et il se clôt lorsque le travail est terminé. Une décision est un choix résolu — une option par rapport aux alternatives, pour des raisons énoncées — et elle reste pertinente tant que ses conséquences perdurent. La tâche répond à la question "a-t-elle été faite ?"; la décision répond à la question "pourquoi est-ce comme ça ?".
Pourquoi les décisions ne devraient-elles pas être suivies dans le suivi des tâches ?
Parce que le cycle de vie du tracker est inadapté pour eux : les tâches doivent être fermées et archivées, tandis que les décisions doivent rester trouvables longtemps après que le travail associé est terminé. Une décision enregistrée sous forme de ticket devient un élément clos dans un sprint archivé — stocké mais pratiquement introuvable. Les décisions doivent figurer dans un registre des décisions, avec des éléments d'action faisant référence à la décision qu'ils exécutent.
Toutes les décisions doivent-elles être enregistrées ?
Non — seulement les choix significatifs. Un seuil pratique : si inverser le choix coûterait un sprint ou plus, ou si vous détesteriez devoir le re-débattre dans six mois, cela mérite un enregistrement. Les petits choix réversibles peuvent rester dans le ticket qui les met en œuvre.
Que devrait contenir le registre des décisions ?
Au minimum, les trois choses qu'un élément d'action ne peut pas contenir : les options qui ont perdu, les arguments qui ont décidé du résultat et une date de révision. Le modèle complet à sept champs — question, options, arguments, décision, justification, responsable, date de révision — se trouve dans notre guide sur la façon de documenter les décisions.
Le fil de commentaires du ticket n'est-il pas déjà l'enregistrement de la décision ?
Un fil de commentaires est une transcription, pas un verdict : il préserve tout ce qui a été dit sans marqueur de ce qui a réellement décidé de l'issue, et il est archivé sous le travail, donc il disparaît lorsque le ticket est clos. Un enregistrement est l'opposé — un court verdict avec le raisonnement décisif, archivé sous la question, trouvable après que le travail soit terminé.
Comment les éléments d'action et le registre des décisions sont-ils liés ?
Par référence : chaque élément d'action qui exécute une décision cite son entrée de journal ("Décision n°47"). Le suivi conserve le travail ; le journal conserve le pourquoi ; le pointeur les rend navigables dans les deux sens.
Cessez de re-discuter des questions réglées
Délibération structurée avec enregistrements automatiques des décisions — le raisonnement reste aussi longtemps que la décision.
À propos Argumentree Team
Decision Science
The Argumentree team is building the collaborative decision-making platform Argumentree. Our mission is to transform how organizations make, document, and learn from decisions.
Articles connexes
Pensez-vous que le fil de tickets est suffisant ?
Apportez l'argument — structuré — au forum Argumentree.
Rejoignez la discussion