Le journal de décisions : pourquoi les meilleurs designers documentent les choix dont personne ne leur a parlé

Un designer senior et un designer confirmé peuvent livrer le même écran. Le senior se souvient du pourquoi. Le confirmé se souvient du quoi.

Cet écart tient en un seul artefact. Une trace courte, datée et structurée de chaque choix de design, avec son raisonnement attaché. Le journal de décisions. La plupart des designers n'en tiennent pas, parce que l'école ne l'a jamais demandé et que leur dernière équipe n'en avait pas. Cette pratique ne se propage pas par accident.

Les équipes qui fixent le niveau en 2026 l'appliquent déjà. Linear a ses RFC de design. Vercel livre des specs produit à côté des specs d'ingénierie. Anthropic publie des notes de recherche. Stripe tient des documents de revue de design. Brian Lovin garde les siens sur un site personnel public. Jordan Singer livre de petits produits accompagnés de journaux de design publics. Le même artefact, dans toutes les pièces.

Voici le playbook. Ce qu'est un journal, pourquoi les recruteurs le lisent en premier, d'où vient cette pratique, le modèle à six champs, où le conserver, des exemples réels, le mode d'échec, et comment démarrer demain.

L'artefact que la plupart des designers ne tiennent pas

L'artefact le plus sous-estimé du design est le journal de décisions. Pas l'étude de cas, pas le fichier Figma, pas le deck. Une trace courte, structurée et datée de chaque choix de design avec son raisonnement attaché, écrite avant la livraison.

Le coût de l'oubli se fait sentir en silence. Six mois plus tard, le designer ne sait plus dire pourquoi les champs du formulaire sont empilés plutôt qu'alignés, qui a tranché, ni ce qui a été coupé. Trois ans plus tard, le portfolio compte six projets et zéro choix défendable. Le designer reste confirmé à vie.

Ce qu'est vraiment un journal de décisions

Une trace structurée des choix de design, des alternatives envisagées, des contraintes en jeu, du raisonnement derrière la décision, du responsable et du résultat. Six champs, datés, concrets, liés à des artefacts. C'est toute la définition.

Ce n'est pas une étude de cas. Les études de cas présentent chaque choix comme inévitable. Un journal montre le choix tel qu'il a été fait, avec les alternatives sur la table, les contraintes qui les ont écartées, et le résultat que le designer assume désormais.

Ce n'est pas un compte rendu de réunion. Un journal consigne ce qui a été décidé et pourquoi, même quand la décision est tombée dans un message Slack de trente secondes. La roadmap regarde devant. Le journal regarde derrière, chaque choix déjà fait, daté, signé, prêt à être défendu.

Pourquoi les recruteurs le valorisent plus que les maquettes

Les maquettes léchées montrent un résultat. Les journaux de décisions montrent un jugement. En 2026, les recruteurs seniors lisent le journal en premier, car le résultat ne coûte plus rien à l'IA et le jugement, si.

Un modèle livre une landing page léchée en huit minutes. Le recruteur qui regarde cette page n'apprend rien sur le designer qui l'a livrée. Même modèle, même prompt, mêmes références Dribbble. Le journal est le seul artefact qui survit à la banalisation du polish par l'IA, parce que le journal n'est pas le résultat : c'est la trace des choix qui ont produit ce résultat plutôt que les dix-huit autres.

La lecture prend deux minutes. Le recruteur ouvre le journal, parcourt cinq entrées et voit comment le designer pense. Des alternatives précises, des contraintes nommées, un raisonnement concret, des résultats assumés, la volonté d'écrire « Je ferais ça autrement aujourd'hui ». C'est tout l'entretien, compressé dans un doc.

D'où vient cette pratique

Le journal de décisions est plus ancien que le logiciel. Christopher Alexander a écrit des langages de patterns qui se lisent comme des journaux de décisions à l'échelle du bâtiment, chaque pattern daté, nommé, justifié, avec ses alternatives notées. Les architectes tiennent des carnets de conception depuis des siècles.

Le logiciel l'a hérité via la culture des RFC. L'IETF publie des documents Request for Comments depuis 1969. Les ADR (architecture decision records) chez Spotify, Pivotal et Thoughtworks sont le même artefact à plus petite échelle. L'héritage le plus récent vient des labos de recherche. Anthropic publie des notes de recherche qui se lisent comme des journaux de décisions à l'échelle du modèle.

Trois lignées, un même artefact. Les designers sont les derniers arrivés, et le niveau monte assez vite pour que « en retard » commence à se lire comme « junior ».

Le modèle à six champs, copiez-le

Six champs. Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. Le modèle est court exprès. La discipline est dans l'écriture, pas dans la conception du modèle. Copiez ce bloc. Utilisez-le demain.

Date: 2026-04-30 Project: Acme Onboarding v3 Decision Stack email and password vertically on the signup screen, no inline social login row. Alternatives 1. Inline social login row (Google, Apple, GitHub) above the fields. 2. Two-step flow, email first then password on screen 2. 3. Magic-link only, no password field. Constraints - Mobile-first, 360px min width, single column. - Engineering will not ship social OAuth this quarter. - Support flagged 14% of tickets as password reset confusion. - [Brand voice](/paper/glossary/brand-voice) rejects "Continue with" social patterns as generic. Reasoning Vertical stack ships fastest and matches the brand register. Two-step tested cleaner in 2024 but added a screen we cannot afford given the 38% drop on screen 2. Magic-link only blocks the password manager flow 22% of paid users rely on. Owner Maya Chen, design. Reviewer: Jordan Park, eng lead. Outcome (filled 2 weeks post-ship) Conversion +6.1% vs v2. Password reset tickets dropped 9%. Re-evaluate magic-link as v3.1 when OAuth lands in Q3.

Copy

Une entrée par vrai choix. Cinq à dix entrées par projet. Oubliez la page de garde. Le bloc ci-dessus, c'est le travail.

Comment écrire chaque champ sans tergiverser

Chaque champ a sa règle. Sautez la règle et le journal tourne au théâtre.

Decision. Une phrase, au présent, concrète. « Empiler l'email et le mot de passe verticalement. » Pas « on sentait que le vertical pourrait marcher ». Si le choix n'a pas été fait, n'écrivez pas encore l'entrée.

Alternatives. Liste numérotée, deux à quatre vraies options qui étaient sur la table. Pas des hommes de paille. Si une seule a été envisagée, écrivez-la et expliquez pourquoi la recherche s'est arrêtée.

Constraints. Liste à puces, nommées, sourcées. Capacité d'ingénierie, règles de marque, tickets support, plancher d'accessibilité, budget de performance. Sans elles, le journal se lit comme du blanchiment de goût.

Reasoning. Trois à cinq phrases, sans « on sentait ». Utilisez « parce que ». Utilisez « par rapport à ». Citez la contrainte ou la donnée qui a tranché. Liez l'artefact.

Owner. Nommez le designer. Nommez le relecteur. Les journaux anonymes ne survivent pas au contact d'un relecteur senior.

Outcome. Rempli de deux semaines à deux mois après la livraison, daté. Ce que la métrique a fait, ce qui a été revu, ce qui changerait la prochaine fois. Oser écrire « je me suis trompé sur le blocage du magic-link » est le signal de confiance le plus fort du journal.

Où garder le journal

Le journal vit là où l'équipe l'ouvrira vraiment. Le stockage compte moins que la cadence.

Notion. La mise en place la plus simple pour toute l'équipe. Une base de données, une entrée par décision, six champs en colonnes. La plupart des équipes produit le paient déjà et un designer peut la monter en une heure.

Linear docs. Le bon choix si l'ingénierie et le design y vivent déjà. Les décisions s'installent à côté des tickets qui les ont déclenchées, et le passage vers les RFC d'ingénierie est à un clic.

Un fichier markdown dans le repo. Le bon choix pour les design engineers et les responsables de design system. Un decisions.md à la racine du repo ou sous /docs/decisions/ fait sérieux parce qu'il est versionné avec le code. Les ingénieurs respectent ce format au premier regard.

Un petit blog privé ou un site personnel. Le bon choix pour un designer qui construit sa trace publique. Brian Lovin fait comme ça. Site statique, entrées datées, liens publics. Le contenu sert à la fois de vitrine portfolio et de présence de recrutement.

Choisissez-en un. Tenez-le un trimestre. Le premier faux pas, c'est de choisir un outil et de ne plus jamais l'ouvrir.

Les RFC de design de Linear et les specs produit de Vercel

Linear traite les RFC de design comme des artefacts de premier rang dans ses docs. Chaque choix de design important part avec une RFC, écrite avant le travail, relue par les leads design et ingénierie, archivée avec le projet. La RFC fait partie du travail, pas d'un compte rendu après coup.

Vercel livre des specs produit à côté des specs d'ingénierie dans le même repo. Le choix de design et le choix d'ingénierie se trouvent dans le même doc, daté, attribué, relu. L'équipe traite la spec comme le contrat. Quand v0 lance une nouvelle surface, la spec fait partie de l'artefact de lancement.

Les deux équipes considèrent le raisonnement écrit comme une part du métier. Pas un compte rendu du mercredi après-midi. Pas optionnel. L'artefact est le travail, au même titre que le fichier Figma, et un designer qui arrive sans lui a l'air inachevé.

Les notes de recherche d'Anthropic et les docs de revue de design de Stripe

Anthropic publie des notes de recherche qui se lisent comme des journaux de décisions à l'échelle du modèle. Ce qu'ils ont essayé, ce qui a marché, ce qui n'a pas marché, le prochain mouvement. Courtes, datées, attribuées, liées. Lisez-en trois et la pratique devient évidente. Les notes sont la trace, pas le storytelling.

Stripe tient des documents de revue de design qui survivent d'un cycle produit à l'autre. Stripe Press est la vitrine publique, la pratique interne est plus ancienne. Les revues sont écrites, archivées et rouvertes quand le cycle suivant rencontre un choix similaire. Une mémoire institutionnelle qui s'accumule au fil des années au lieu de partir quand un designer senior s'en va.

Si vous voulez de l'aide pour intégrer cela au métier de votre équipe, engagez Brainy. BrandBrainy livre la couche de savoir-faire que l'IA ne sait pas imiter. ClaudeBrainy livre les Skill packs et les bibliothèques de prompts qui font du journal un réflexe plutôt qu'une discipline.

Brian Lovin et Jordan Singer gardent le leur en public

Brian Lovin tient depuis longtemps un site personnel qui se lit comme un journal de décisions public sur son propre travail. Des pages courtes, une écriture directe, des choix de design expliqués en trois ou quatre phrases chacun, datés, liés au produit en ligne. Des années d'entrées. Le site sert à la fois de portfolio et de présence de recrutement, le double usage sur lequel s'appuie le playbook de l'anti-portfolio.

Jordan Singer livre de petits produits accompagnés de journaux de design publics. Chaque projet a une trace écrite des choix qui le sous-tendent, publiée en ouvert, avec la volonté de dire à voix haute « ça n'a pas marché ». Le journal est à la fois le marketing, la trace et l'artefact de recrutement.

Les deux sont des modèles que n'importe quel designer en poste peut copier cette semaine. Site statique, entrées à six champs, datées, publiques, liées. Quinze minutes par entrée. Trois par mois. Un an plus tard, le journal public se lit comme du senior d'une façon qu'aucune étude de cas Behance n'atteindra jamais.

La mise en garde : la rationalisation a posteriori

Un journal de décisions écrit après la livraison, une fois le résultat connu, n'est pas un journal, c'est un argumentaire de vente. Les recruteurs seniors voient la différence en deux minutes.

Le signe qui trahit, c'est le champ des alternatives. Un journal vivant liste des alternatives réellement sur la table, dont souvent une qui sonnait fort. Un journal a posteriori liste trois options que l'auteur n'a jamais sérieusement envisagées, conçues pour que l'option retenue paraisse évidente. Le recruteur a fait cet exercice cent fois. Il sait à quoi ressemble le storytelling.

L'autre signe, c'est le champ du résultat. Les journaux vivants incluent des résultats qui n'ont pas correspondu à la prédiction. « Je m'attendais à un gain de conversion, le test est resté plat, voici ce qui a dérapé. » Les journaux de théâtre n'incluent que des victoires, arrondies d'avance pour paraître meilleures qu'elles n'étaient.

La solution est inconfortable. Écrivez l'entrée avant la livraison. Datez-la. Soumettez-la à un relecteur qui contredira. Remplissez le résultat deux semaines plus tard, même quand la nouvelle est mauvaise. Surtout quand elle est mauvaise. L'entrée honnête s'accumule.

Comment utiliser le journal en entretien et en revue

Un journal fait ses preuves deux fois. Une fois quand le travail est livré, une autre quand le designer déroule un choix devant un recruteur ou un relecteur senior.

En entretien, le journal remplace la présentation d'étude de cas. Ouvrez le doc. Choisissez trois entrées. Pour chacune, lisez la décision, nommez la meilleure alternative, nommez la contrainte déterminante, expliquez le raisonnement en deux phrases, partagez le résultat, y compris ce qui changerait la prochaine fois. Cinq minutes par entrée, quinze au total. Le recruteur en apprend plus sur le jugement qu'un deck d'étude de cas de quarante-cinq minutes n'en montrerait.

En revue senior, le journal est la conversation. Le relecteur lit l'entrée, conteste le raisonnement, demande pourquoi la meilleure alternative a été écartée. La discussion affûte la décision suivante avant qu'elle soit prise. C'est ça, une bonne revue de design. Pas un retour sur des pixels rendus, un débat sur le choix qui est derrière.

Un designer qui sait défendre le journal défend le travail. Un designer sans journal ne défend rien.

Le nouveau niveau : un travail senior sans journal se lit comme du junior

Le journal de décisions n'est plus un petit plus pour les seniors. C'est le signal le moins cher de jugement senior qu'un designer puisse livrer, et le coût de s'en passer augmente.

Un portfolio senior avec un journal public se lit comme senior. Un portfolio sans journal se lit comme un travail qui aurait pu être senior, difficile à dire. Les recruteurs lisent les deux. Le premier est rappelé. Un junior avec un journal sur trois petits projets se lit comme en avance sur son niveau. Un junior avec douze shots Dribbble parfaits et pas de journal se lit comme le même junior qu'il y a un an.

Le goût est le dernier avantage défensif en 2026 parce que la production s'est banalisée, et le journal est l'artefact public qui prouve que le goût existe dans le travail. Si vous livrez en profil hybride de design engineering, le journal fait aussi office de RFC d'ingénierie au niveau design. Si vous gravissez la nouvelle échelle de carrière du design, le journal est l'artefact sur lequel repose l'échelle.

FAQ

Qu'est-ce qu'un journal de décisions de design ?

Une trace structurée et courte des choix de design avec leur raisonnement attaché. Six champs par entrée : Decision, Alternatives, Constraints, Reasoning, Owner, Outcome. Daté, concret, lié à des artefacts.

En quoi diffère-t-il d'une étude de cas ?

Une étude de cas présente chaque choix comme inévitable. Un journal montre les choix tels qu'ils ont réellement été faits, avec les alternatives sur la table, les contraintes qui encadraient la décision et le résultat assumé. Les études de cas vendent. Les journaux documentent.

Où dois-je le garder ?

Là où votre équipe l'ouvrira vraiment. Notion pour les équipes produit, Linear docs pour les équipes qui y sont déjà, un fichier markdown dans le repo pour les design engineers, un petit site privé pour une trace publique individuelle.

Quelle longueur pour chaque entrée ?

Courte. Le modèle complet tient sur un écran. Quinze minutes par entrée.

Et si mon entreprise n'adopte pas cette pratique ?

Tenez-le à titre personnel. Le journal individuel d'un designer s'accumule d'un poste à l'autre. Brian Lovin et Jordan Singer gardent les leurs en public. La pratique est à vous, pas à votre employeur, et l'artefact vous suit.

Lancez le journal cette semaine

Trois mouvements. Mettez en place le stockage. Choisissez Notion, Linear, le repo ou un petit site. Montez-le en trente minutes. Prenez celui que vous ouvrirez demain.

Écrivez trois entrées sur des choix déjà faits. De vraies décisions de ce trimestre. Six champs chacune. Des alternatives honnêtes, de vraies contraintes, aucune tergiversation, des résultats datés et sans enjolivure. Les trois premières sont les plus dures, les suivantes vont plus vite.

Montrez le journal à un relecteur senior. Demandez-lui de contester le raisonnement. Prenez la contestation comme un signal. Mettez à jour les entrées. C'est à la première revue que le journal commence à s'accumuler.

Si vous voulez de l'aide pour intégrer la pratique du journal de décisions au métier de votre équipe, engagez Brainy. BrandBrainy livre la couche de marque et de savoir-faire que l'IA ne sait pas imiter. ClaudeBrainy livre les Skill packs et les bibliothèques de prompts qui font du journal un réflexe plutôt qu'une discipline. Les équipes qui l'appliquent déjà prennent de l'avance. Le niveau monte, et le designer qui commence cette semaine est celui que les équipes citées liront dans un trimestre.