Journal de Décisions pour Startups
Les startups prennent des centaines de décisions par semaine. La plupart s'évaporent dans des fils Slack et des réunions oubliées. Voici comment créer un journal de décisions efficace.
By Ellis Keane · 2026-03-16
En 1986, la navette spatiale Challenger se désintégra 73 secondes après le lancement. L'enquête qui suivit révéla que des ingénieurs de Morton Thiokol avaient soulevé des inquiétudes la veille concernant les joints toriques, estimant que le froid rendait le lancement dangereux. La direction passa outre. La décision fut prise lors d'une téléconférence et, bien que des graphiques et des témoignages existassent, le raisonnement critique derrière cette décision était fragmenté entre les participants et n'avait jamais été transmis de façon fiable à la hiérarchie.
Je ne compare pas les décisions produit de votre startup à une catastrophe spatiale (enfin, pas la plupart d'entre elles). Mais le schéma d'échec sous-jacent est le même que celui que j'observe chaque semaine dans les startups, avec moins d'enjeux : une décision est prise, le raisonnement qui la sous-tend vit dans la tête de quelqu'un ou dans un fil Slack qui est sur le point de disparaître de l'écran, et trois mois plus tard personne ne peut reconstruire pourquoi nous avons choisi l'approche A plutôt que l'approche B. Non pas parce que la décision était mauvaise – parfois elle était excellente –, mais parce que le contexte qui la rendait juste s'est évaporé.
"Une décision est prise, le raisonnement qui la sous-tend vit dans la tête de quelqu'un ou dans un fil Slack qui est sur le point de disparaître de l'écran, et trois mois plus tard personne ne peut reconstruire pourquoi nous avons choisi l'approche A plutôt que l'approche B." – Ellis Keane
Un journal de décisions pour startups n'est pas un exercice bureaucratique. C'est la différence entre « nous avons essayé ça et ça n'a pas marché » (utile) et « je crois qu'on en a parlé une fois ? » (inutile).
L'anatomie d'une décision perdue
Permettez-moi de retracer une décision concrète à travers son cycle de vie, car la version abstraite de ce problème convainc moins que la version concrète.
Nous sommes un mardi de février. Votre responsable ingénierie et votre PM sont dans un fil Slack pour débattre s'il faut construire un système de notifications maison ou utiliser un service tiers. Le fil compte 47 messages (je sais, mais c'est comme ça), et au message 38, ils ont opté pour l'option externe parce que la construction interne prendrait trois sprints et que la date de lancement est dans deux semaines.
Le PM crée un ticket Linear : « Intégrer [Service X] pour les notifications. » Un ingénieur le prend en charge et commence à développer. Le fil Slack est toujours là, techniquement, mais personne ne le marque d'un signet ni ne le lie depuis le ticket Linear.
Avancez jusqu'en mai. Le service tiers a un problème de fiabilité. Quelqu'un demande : « Pourquoi n'avons-nous pas construit ça nous-mêmes ? » Le PM se souvient de la conversation, mais pas des détails. Le responsable ingénierie est en congé parental. Le fil Slack se trouve quelque part dans le canal #engineering de février, mais personne ne se souvient de la date exacte, et la recherche Slack renvoie 200 résultats pour « notification » – parce que, bien sûr, toutes les équipes parlent constamment de notifications.
L'équipe passe 45 minutes en réunion à reconstruire le raisonnement original. Elle parvient finalement à la même conclusion – la contrainte de délai était toujours valable –, mais les 45 minutes sont perdues et le doute persiste. Multipliez cela par les dizaines de décisions qu'une startup prend chaque mois, et vous obtenez une part significative de temps passé à rejouer des choix qui avaient déjà été faits de façon réfléchie.
Pourquoi les startups sont particulièrement mauvaises dans ce domaine
Les grandes entreprises (malgré tous leurs défauts, et ils sont nombreux) ont tendance à encoder la mémoire institutionnelle dans des processus : architecture decision records, RFC, documents de conception qui passent par des cycles de révision formels. Les décisions sont peut-être enfouies dans Confluence, mais elles sont au moins consignées quelque part.
Les startups n'ont pas cette infrastructure, et la construire ressemble exactement au type de surcharge qu'on est censé éviter quand on est petit et rapide. Il y a un argument raisonnable selon lequel « on s'en souviendra » fonctionne à quatre personnes – et c'est vrai –, jusqu'à ce que la cinquième personne arrive et n'ait aucun contexte sur pourquoi les choses sont comme elles sont.
L'autre facteur qui rend le suivi des décisions particulièrement difficile dans les startups est la fragmentation des outils. Les décisions se prennent partout : fils Slack, appels Zoom, commentaires Notion, discussions Linear, revues de PR GitHub, et – de plus en plus – dans des messages privés qui n'atteignent jamais un canal partagé. Chaque outil capture un fragment de la décision, mais aucun n'en capture la totalité, et les liens entre eux sont maintenus par la mémoire humaine, qui – dit avec affection – est la base de données la moins fiable à laquelle nous ayons accès.
Ce dont un journal de décisions a vraiment besoin
Il y a une tentation de trop sophistiquer cela. J'ai vu des équipes construire des bases de données Notion élaborées avec 15 propriétés par entrée – type de décision, niveau d'impact, statut de révision, parties prenantes, OKR associés – puis ne jamais les utiliser parce que la charge de remplir tous ces champs pour chaque décision dépasse la valeur perçue.
Un journal de décisions pour startups doit être suffisamment léger pour que les gens l'utilisent réellement. Voici ce qui compte :
La décision elle-même. Une phrase. « Nous utilisons le Service X pour les notifications plutôt que de développer notre propre solution. » Pas un paragraphe – une phrase.
Qui l'a prise, et quand. Nom et date. Cela semble évident, mais c'est la partie qui compte le plus quand quelqu'un remet en question la décision six mois plus tard. Il ne s'agit pas de trouver un coupable (enfin, pas vraiment) – il s'agit de savoir à qui s'adresser pour le raisonnement original.
Quelles alternatives ont été envisagées. Deux ou trois puces. « Développement interne envisagé (estimation de 3 sprints, délai trop serré) » et « Service Y envisagé (le prix ne passe pas à l'échelle au-delà de 10 000 utilisateurs). » C'est la partie qui prévient les redébats – si les alternatives et leurs compromis sont documentés, l'équipe n'a pas besoin de les redécouvrir.
Où la discussion a eu lieu. Un lien vers le fil Slack, le ticket Linear, le commentaire Notion – partout où le vrai débat s'est tenu. C'est le champ le plus sous-estimé. Sans lui, l'entrée du journal est une affirmation sans preuve. Avec lui, quiconque veut le contexte complet peut lire la conversation originale.
Ce qui changerait la décision. C'est facultatif mais incroyablement utile pour les startups où le contexte évolue vite. « Nous reconsidérerions si la date de lancement se décale de plus de quatre semaines » ou « Ceci suppose que nous restons sous 10 000 notifications mensuelles. » Cela transforme un enregistrement statique en un enregistrement vivant.
Le meilleur journal de décisions pour startups est celui que votre équipe remplit vraiment. Cinq champs, une phrase chacun. S'il faut plus de 90 secondes pour consigner une décision, le système sera abandonné en moins d'un mois.
Où le mettre
J'ai vu des équipes essayer trois approches, et elles ont toutes leurs compromis.
Une base de données Notion. C'est le plus courant et ça fonctionne raisonnablement bien. Créez une base de données avec les cinq champs ci-dessus, ajoutez un modèle pour que le remplissage soit rapide, et liez chaque entrée à la page de projet concernée. L'inconvénient : Notion est l'endroit où vivent les spécifications, pas là où se prennent les décisions, donc vous comptez sur quelqu'un pour aller sur Notion après que la décision a été prise ailleurs. Cette étape « après » est là où l'abandon se produit.
Directement dans Slack. Certaines équipes utilisent un canal dédié #décisions et publient un message formaté pour chaque décision. C'est moins de friction (la décision a probablement été prise dans Slack de toute façon), mais la recherche Slack rend difficile la recherche de décisions par projet ou plage de dates, et l'absence de champs structurés fait que la cohérence se dégrade avec le temps.
Directement dans Linear. Si la décision concerne un flux de travail spécifique, la consigner comme commentaire sur le ticket Linear pertinent garde la décision proche du travail qu'elle affecte. L'inconvénient est que les décisions couvrant plusieurs tickets ou projets n'ont pas de place naturelle.
Aucun n'est idéal, pour être honnête. Le problème fondamental est que les décisions se prennent sur plusieurs outils, mais les journaux vivent dans un seul outil, donc il y a toujours une étape manuelle pour combler l'écart. Cette étape manuelle est le seul point de défaillance de chaque journal de décisions que j'ai vu.
Ce que nous construisons chez Sugarbug
L'approche que nous adoptons avec Sugarbug consiste à détecter les décisions au moment où elles se prennent sur les différents outils, plutôt que de demander à quelqu'un de les consigner manuellement.
Quand un fil Slack parvient à une conclusion (« OK, on part sur le Service X »), quand une discussion sur un ticket Linear se résout, quand une revue de PR GitHub se termine par une approbation – ce sont tous des signaux qu'une décision a été prise. Sugarbug ingère ces signaux, les classe et les lie aux tâches et aux personnes concernées dans le graphe de connaissances. Le « journal de décisions » n'est pas une base de données séparée que quelqu'un doit maintenir – c'est une vue sur les décisions déjà intégrées dans vos outils existants.
Nous affinons encore la précision de la classification (déterminer la différence entre « une décision » et « juste une conversation » est plus difficile qu'il n'y paraît), mais le pari directionnel est que capturer les décisions à la source, là où elles se produisent réellement, est plus fiable que de demander aux humains de les dupliquer dans un système séparé.
Si cela vous intéresse, sugarbug.ai fournit plus de détails. Mais le système manuel décrit ci-dessus servira bien la plupart des startups jusqu'à ce que l'équipe soit suffisamment grande pour que le taux d'abandon de la consignation manuelle devienne un vrai problème – généralement autour de 8 à 12 personnes, d'après notre expérience.
Arrêtez de perdre vos décisions dans le défilement Slack. Sugarbug les capture automatiquement depuis les outils où elles se produisent vraiment.
Q: Que doit contenir le journal de décisions d'une startup ? A: Au minimum : la décision elle-même (une phrase), qui l'a prise, quand, quelles alternatives ont été envisagées et où la discussion a eu lieu. Ce dernier champ est le plus important – sans lien vers la conversation originale, l'entrée du journal devient une affirmation sans preuve, et quand quelqu'un la remet en question six mois plus tard, vous vous retrouvez à reconstruire de mémoire.
Q: Sugarbug crée-t-il automatiquement un journal de décisions à partir des outils existants ? A: C'est la direction que nous prenons. Sugarbug ingère des signaux provenant de Slack, Linear, GitHub, Notion et d'autres outils, en les classifiant dans un graphe de connaissances. Lorsqu'il détecte une décision – une PR approuvée, une discussion Linear résolue, un fil Slack qui se termine par une prochaine étape claire –, il lie automatiquement cette décision à la tâche et aux personnes concernées. Nous affinons encore la classification (distinguer « décision » de « conversation » est vraiment délicat), mais l'ingestion et la liaison des signaux fonctionnent.
Q: À quelle fréquence une startup devrait-elle mettre à jour son journal de décisions ? A: Idéalement, les décisions sont consignées au moment où elles sont prises, pas regroupées chaque semaine. Le vendredi, le raisonnement derrière la décision du mardi est déjà flou, et la probabilité que quelqu'un remplisse correctement le champ « alternatives envisagées » chute rapidement. En cas de consignation manuelle, faites-en une habitude de 90 secondes immédiatement après la décision. Si vous utilisez un outil comme Sugarbug, l'objectif est la capture en temps réel depuis les outils où les décisions se prennent réellement.
Q: Sugarbug peut-il suivre les décisions sur Slack, Linear et GitHub ? A: Sugarbug se connecte aux trois (et à Notion et Figma) et maintient un graphe de connaissances des relations entre les conversations, les tâches et les modifications de code. Quand une décision émerge dans un fil Slack, conduit à un ticket Linear et génère une PR GitHub, Sugarbug relie toute la chaîne pour que vous puissiez retracer la décision de son origine à son implémentation sans que personne ait besoin de créer ces liens manuellement.
Q: Quelle est la différence entre un journal de décisions et un Architecture Decision Record (ADR) ? A: Les ADR sont généralement des documents formels pour des choix techniques importants – « nous utilisons PostgreSQL plutôt que MongoDB » – avec des sections structurées pour le contexte, la décision et les conséquences. Un journal de décisions pour startups est plus large et plus léger : il capture les décisions opérationnelles quotidiennes (quel fournisseur, quel délai, quelle fonctionnalité à supprimer) que les ADR considéreraient trop mineures pour être documentées. Les deux sont utiles ; le journal de décisions couvre les 95 % de décisions qui ne justifient pas un ADR formel mais qui doivent néanmoins être traçables.