Journal de décision : comment enregistrer les décisions pour que les raisons perdurent

Les organisations se souviennent de ce qu'elles ont décidé, mais oublient pourquoi. Fonctionnement, éléments à saisir, modèle léger et lien avec les résultats.

Ibrahim Elkobeissi · 2 novembre 2026 · 6 min de lecture ·

LinkedIn X WhatsApp

La façade d'un grand bâtiment institutionnel moderniste

Demandez à une équipe pourquoi une politique existe, et vous observerez souvent un silence. Quelqu'un se souvient d'une réunion. Un autre pense que c'était un problème de fournisseur. La personne concernée est partie l'année dernière. La décision est restée, mais ses raisons ont disparu.

C'est un phénomène courant, et il coûte cher. Sans les raisons, une équipe n'a que deux mauvaises options : maintenir une décision qu'elle ne comprend plus, ou l'inverser au risque de réintroduire le problème initial. Un registre de décisions offre une troisième voie. Lisez le compte rendu, vérifiez si les conditions sont toujours réunies, et décidez à nouveau avec intention.

Pourquoi les organisations oublient leurs raisons

Trois forces s'opposent à la mémoire des décisions d'une organisation.

Les raisons se perdent dans les échanges. Les décisions se prennent en réunion, par appel ou via des fils de discussion. Le résultat devient une politique ou un plan. Le contexte, lui, disparaît rarement.
Les collaborateurs partent. Les personnes qui ont pesé les options changent de rôle ou quittent l'entreprise. Leur compréhension s'en va avec elles.
La mémoire se réécrit. Dans une étude de 1975, le psychologue Baruch Fischhoff a découvert qu'une fois le résultat connu, les gens jugent l'événement comme plus prévisible qu'il ne l'était. Il a appelé cela le « déterminisme rampant ». Après coup, une décision judicieuse qui tourne mal semble imprudente, tandis qu'une décision chanceuse semble sage.

Ce dernier point est crucial. Même si les mêmes personnes restent, leur souvenir de la raison de la décision est teinté par ce qui s'est passé ensuite. Seul un enregistrement rédigé sur le moment préserve ce qui était connu, ce qui était attendu et ce qui était incertain.

Les directives d'architecture de Microsoft l'énoncent clairement : une décision qui n'est jamais consignée « sera probablement oubliée, entraînant des débats répétitifs ».

Ce que les équipes software ont appris : l'Architecture Decision Record (ADR)

L'ingénierie logicielle possède une réponse éprouvée. En novembre 2011, Michael Nygard a proposé l'Architecture Decision Record, ou ADR : un document court pour chaque décision significative, numéroté de manière séquentielle et conservé avec le projet. Son format comprend cinq parties.

Titre. Un groupe nominal court avec un numéro, par exemple : « ADR 9 : LDAP pour l'intégration multitenant ».
Contexte. Les forces en présence : techniques, politiques, sociales et locales. Nygard demande que cette section soit neutre, une simple description des faits.
Décision. La réponse à ces forces, rédigée en phrases complètes à la voix active : « Nous allons... »
Statut. Proposée, acceptée, obsolète ou remplacée, avec une référence à tout remplacement.
Conséquences. Le contexte qui en résulte. Selon Nygard : « Toutes les conséquences doivent être listées ici, pas seulement les « positives » ».

La pratique s'est généralisée. Thoughtworks a placé les ADR légers dans le cercle « Adopt » de son Technology Radar, son niveau de recommandation le plus élevé, et conseille de les conserver dans le contrôle de source plutôt que dans un wiki séparé. Le framework Azure Well-Architected de Microsoft considère le registre de décision comme l'un des livrables les plus importants d'un architecte solution. Ses directives ajoutent deux règles utiles : traitez le registre comme étant en mode « ajout uniquement » (append-only) et indiquez un niveau de confiance pour chaque décision.

Rien de tout cela n'est spécifique au logiciel. Les hôpitaux changent leurs procédures d'admission. Les écoles changent leurs politiques d'évaluation. Les agences changent de fournisseurs. Chacune de ces décisions a un contexte, des options et des conséquences, et chacune sera remise en question plus tard par quelqu'un qui n'était pas présent.

Ce qu'un registre de décision doit saisir

Un registre de décisions est la collection de ces comptes rendus, avec un index qui résume chacun d'eux. Le guide d'ingénierie de Microsoft décrit le registre comme un tableau de résumés exécutifs, avec métadonnées, pour les décisions détaillées dans les comptes rendus complets. Le modèle de registre de décisions ci-dessous est efficace bien au-delà de l'ingénierie. Chaque champ est essentiel.

ID et titre. Un numéro et une phrase indiquant ce qui a été décidé.
Date. Le moment où la décision a été prise, et non le moment où elle a été rédigée.
Responsable. La personne garante de la décision et les personnes consultées.
Contexte. Le problème, les contraintes et les forces en tension.
Options envisagées. Y compris celles rejetées, et pourquoi. C'est le champ le plus souvent manquant et le plus souvent nécessaire.
Décision. Une phrase claire commençant par « Nous allons... »
Preuves. Liens vers les données, rapports, audits ou retours sur lesquels la décision s'appuie.
Résultat attendu. Ce qui devrait être vrai si la décision est appliquée, et d'ici quand.
Confiance. Élevée, moyenne ou faible, avec une précision sur ce qui reste incertain.
Date de révision. Quand la décision sera confrontée à son résultat attendu.
Statut. Proposée, acceptée, remplacée ou retirée, avec un lien vers tout remplacement.

Les champs de résultat attendu et de confiance font office de Journal de décision. Ils enregistrent ce que vous pensiez avant de connaître le résultat, ce que le recul a tendance à effacer.

Nous appliquons la même rigueur à nos propres décisions produit. Ce qui est observé est distingué de ce qui est déduit, et les points de vue divergents sont conservés plutôt qu'atténués. Une décision mérite au moins autant d'attention que cela.

Liez chaque décision à ses preuves et à son résultat.

Un enregistrement qui se suffit à lui-même est préférable au néant. Un enregistrement lié est bien plus utile.

Liez l'enregistrement aux preuves. Lorsqu'une décision cite une enquête de patients, une analyse de coûts ou un rapport d'incident, liez la source elle-même. Les lecteurs ultérieurs pourront alors juger si les preuves sont toujours valables. Les recommandations de Microsoft vont dans le même sens : un enregistrement sans justification « perd de sa valeur avec le temps. »

Liez l'enregistrement au résultat. À la date de révision, notez ce qui s'est réellement passé par rapport à ce qui était attendu. Si l'écart est important, demandez-vous pourquoi. Les preuves étaient-elles faibles ? Les conditions ont-elles changé ? La décision était-elle judicieuse et le résultat simplement dû à la malchance ? La réponse est une leçon, et elle doit faire partie de la même chaîne. Notre article sur les leçons apprises qui transforment le projet suivant explique comment pérenniser ces enseignements.

Liez l'enregistrement aux décisions suivantes. Lorsqu'une décision est annulée, ne modifiez pas l'ancien enregistrement. Marquez-le comme remplacé et pointez vers le nouveau. L'historique d'un changement de direction est souvent l'élément le plus précieux du journal.

Un exemple hypothétique illustre la chaîne. Une clinique décide de confier les appels de suivi des infirmiers à un coordinateur dédié. L'enregistrement cite les données de complétion des appels, désigne le responsable des opérations comme propriétaire, prévoit une hausse de la complétion sous trois mois et fixe une date de révision. Lors de la révision, la complétion a augmenté, mais la charge de travail des infirmiers n'a pas diminué comme prévu. Un nouvel enregistrement remplace le premier, ajuste le rôle et y renvoie par un lien. Deux ans plus tard, un nouveau manager peut lire toute l'histoire en cinq minutes.

Gardez-le assez léger pour qu'il dure.

Les journaux de décision échouent comme la plupart des documentations. Ils deviennent une corvée, puis ils s'arrêtent. Cinq règles permettent de les maintenir vivants.

N'enregistrez que les décisions significatives. Le test de Microsoft est utile : les décisions qui façonnent la structure, affectent des qualités clés ou sont difficiles à inverser.
Gardez chaque enregistrement court. Une page ou moins. Liez le matériel de support au lieu de le copier.
Rédigez-le au moment de la décision. Un enregistrement rédigé la semaine même est précis. Un enregistrement rédigé des mois plus tard est une reconstruction.
Gardez-le là où se trouve le travail. Un journal conservé à côté des plans et procédures qu'il affecte est lu. Un journal dans un dossier séparé ne l'est pas.
Commencez maintenant, puis complétez les anciens. Commencez par les nouvelles décisions. Ensuite, reconstituez les quelques décisions passées sur lesquelles on vous interroge le plus, et marquez-les comme « reconstruites ».

Une décision sans ses raisons est une instruction. Une décision avec ses raisons peut être testée, conservée ou modifiée avec soin.

Comment Prism conserve les enregistrements de décision

Prism centralise les décisions et les connaissances d'une organisation sous forme d'éléments avec un niveau de confiance défini : ratifié, prouvé, observé ou inféré. Chaque décision est liée à ses preuves, aux étapes de sa mise en œuvre, ainsi qu'aux résultats et aux leçons de type « Pause et Apprentissage » qui en découlent. Lorsqu'une décision est remplacée, la précédente reste visible. Les assistants que votre équipe utilise déjà peuvent aussi lire l'enregistrement, ainsi les raisons sont disponibles si quelqu'un pose la question. Les humains prennent les décisions. Prism conserve leurs raisons.