Les décisions qu'on prend. Les raisons qu'on perd.

Comment j'ai construit un registre de décisions design lisible par l'IA, sans la laisser décider.

Le problème des trois jours

On se met d'accord en réunion. Le raisonnement est clair dans la salle. Une contrainte que personne n'aime vraiment. Une alternative envisagée puis écartée. Une limite technique qui change ce qu'on peut raisonnablement livrer.

Tout le monde est d'accord. Le travail commence.

Trois jours plus tard, quelqu'un ouvre un ticket et demande pourquoi tel élément se comporte de cette façon.

La décision est là. Le raisonnement, non.

Quelqu'un se souvient d'une partie de la discussion. Quelqu'un d'autre d'une version différente. Au final, on reconstruit l'argument ou on reprend la décision.

Je l'ai vécu particulièrement souvent avec les petites décisions de design : la position d'un élément, une interaction, un comportement qui semblait évident quand on en parlait.

On ne perd pas forcément les décisions. On perd les raisons qui les portent.

Et quand le raisonnement disparaît, il devient difficile de remettre une décision en question intelligemment. On peut la suivre, l'ignorer, ou rouvrir toute la discussion.

Je voulais une autre option.

Début 2023 : il me fallait un moyen de suivre

Début 2023, je travaillais sur des projets metaverse tout en apprenant Unity et Blender en parallèle de mes responsabilités UX. Il fallait développer assez de l'expérience pour en démontrer le potentiel et obtenir le budget pour agrandir l'équipe, donc beaucoup de choses avançaient en parallèle. Je travaillais plus de soixante heures par semaine, samedis compris.

Les projets traversaient plusieurs disciplines : environnements 3D, applications natives, lunettes connectées, WebXR, recherche et enjeux business. Un changement dans un domaine pouvait affecter des décisions dans plusieurs autres.

Ma façon habituelle d'organiser le travail ne suivait plus. J'avais toujours travaillé de manière plutôt séquentielle : me concentrer sur un sujet, organiser l'information, le terminer, fermer le dossier, passer au suivant. Ça marchait quand les sujets pouvaient être traités indépendamment. Ça devenait de plus en plus inefficace quand tout était connecté.

Le problème n'était pas seulement d'avoir trop d'information. C'est que de l'information que je considérais terminée pouvait soudain redevenir pertinente. Je devais aller plus vite, mais je passais trop de temps à reconstruire le contexte.

Alors j'ai investi du temps que je n'avais presque pas pour changer ma manière d'organiser mon travail.

J'ai commencé avec Notion, en construisant quelque chose de plus proche d'une base de données projet que d'une collection classique de documents. Décisions, contraintes et sujets pouvaient avoir leur propre état au lieu de disparaître dans des dossiers fermés. Plus tard, j'ai migré vers Obsidian pour sa flexibilité, son extensibilité et son potentiel d'automatisation.

Avec le temps, le système est devenu ce que j'appelle aujourd'hui mon registre de décisions design. Il n'a pas été construit pour produire plus de documentation. Il a été construit pour arrêter de perdre le raisonnement qui rendait la documentation utile.

Nous avons fini par recruter un designer 3D, ce qui a soulagé une partie de la charge. Mais j'ai continué à développer le système, parce que le problème de fond n'avait pas disparu.

Des décisions isolées au raisonnement connecté

Un user flow décrit un chemin qu'une personne est censée suivre. C'est utile quand la séquence d'interactions est le problème. Je dessine toujours des user flows quand il le faut.

Mais un flow ne décrit pas tout ce qui entoure ce chemin. Il n'explique pas forcément la contrainte technique qui a façonné une interaction, l'exigence business qui a éliminé une alternative, ou le comportement inattendu que les utilisateurs ont développé pour contourner une limite.

Ce qui m'intéresse, c'est le système dans lequel le flow opère : les décisions, contraintes, hypothèses et relations qui rendent l'expérience possible.

J'ai aussi une façon de travailler particulière. Mon parcours mêle design et entrepreneuriat. J'ai tendance à aller vite : tester, observer, changer, réessayer. Cette approche peut être efficace, mais elle peut aussi être difficile à communiquer dans des organisations plus hiérarchiques. Un bon résultat n'explique pas comment on y est arrivé.

Quand le raisonnement n'est pas visible, une décision peut ressembler à de l'intuition. Même des succès répétés peuvent être interprétés comme de la chance plutôt que comme le fruit d'un processus délibéré. J'ai rencontré ce problème.

Le registre est devenu un moyen d'exposer le raisonnement sans obliger tout le monde à penser ou travailler comme moi. Voici ce que je savais. Voici les contraintes A, B et D. Voici pourquoi j'ai changé C. Voici les alternatives envisagées, et pourquoi je les ai écartées.

Ça ne prouve pas que la décision était la bonne. Ça la rend compréhensible, et donc contestable. Cette distinction compte pour moi : un registre design ne doit pas exister pour défendre chaque décision passée ; il doit les rendre plus faciles à revisiter quand le contexte change.

Il crée aussi de la continuité. J'ai partagé l'approche avec des designers avec qui j'ai travaillé, et je l'utilise avec les collaborateurs de mon studio. Quand un autre designer rejoint un projet, je veux qu'il hérite de plus qu'une collection d'écrans, de composants et de conventions inexpliquées. Je veux qu'il comprenne le raisonnement derrière ces choix, et qu'il se sente libre de le questionner.

Donner une IA au registre

Avec le temps, le registre s'est structuré, et j'ai commencé à y connecter des agents IA.

Aujourd'hui, il contient quelques centaines de notes dans mon environnement de travail : le registre lui-même, plus la recherche, les notes de veille et les dossiers projet qui l'alimentent. L'information vit dans des vaults privés séparés, et j'ai automatisé une partie de l'organisation et de la synchronisation qui demandaient auparavant un travail manuel.

J'utilise un setup hybride : des modèles open-weight hébergés localement pour certaines tâches, et des modèles externes accessibles par API pour d'autres. GPT, Claude et Qwen font partie des familles de modèles avec lesquelles je travaille, selon la tâche et le déploiement.

La plupart des appels passent encore par une API, un compromis que j'accepte et un risque que je dois gérer.

Les agents n'ont pas tous les mêmes permissions. Certains sont limités à des ressources précises ou à des environnements locaux ; les services externes ne sont disponibles que là où ils sont nécessaires et autorisés.

C'est important, parce que les décisions UX peuvent contenir des informations sensibles sur les produits, la stratégie, les utilisateurs et les discussions internes.

Garder les fichiers en local ne rend pas automatiquement un système sûr, surtout quand des modèles externes sont impliqués. L'accès à l'information et la capacité à la transmettre doivent être contrôlés séparément.

Mais la partie intéressante n'est pas l'infrastructure. C'est ce qui se passe quand les agents commencent à relier l'information.

Quand je commence à travailler sur un sujet, l'agent part du contexte dont il dispose. Après quelques échanges, il peut identifier des liens avec des discussions, contraintes et décisions précédentes. Je peux aussi l'orienter vers une information précise ou lui demander d'examiner certaines dépendances.

Je le vois comme une toile de connexions. Pas forcément un knowledge graph technique, mais une façon de travailler où les sujets ne sont pas isolés simplement parce qu'ils appartiennent à des dossiers ou à des moments différents d'un projet.

Par exemple, alors que je travaillais sur l'orientation verticale d'une interface tablette pour un client, un agent a fait remonter une information d'une réunion cinq semaines plus tôt. Un autre designer avait mentionné un changement lors d'un court échange, deux minutes peut-être. J'enregistre systématiquement les réunions et je prends des notes, donc l'information avait été captée. Mais elle n'avait pas rejoint la documentation que je consultais pour cette tâche.

Je l'avais oubliée. L'agent l'a remise dans le contexte.

Le même principe aide pour les décisions pas encore prises. Parfois, une discussion à venir peut affecter une contrainte sur laquelle je m'apprête à agir. Le système peut faire apparaître cette dépendance, et me donner une raison de reporter un arbitrage plutôt que de créer du travail inutile.

C'est le type d'assistance qui a de la valeur pour moi. Pas une IA qui me dit quoi concevoir. Une IA qui m'aide à me souvenir de ce que je dois considérer avant de le concevoir.

Un registre n'est utile que si on peut le questionner

Le système a fait des erreurs.

Des agents ont fait remonter des liens incorrects, des informations dépassées et des conclusions qui ne tenaient pas à l'examen. Ça m'a poussé à changer le workflow.

Au lieu de me fier à une seule interprétation, j'ai commencé à utiliser des agents spécialisés avec des responsabilités de relecture différentes : certains examinent la qualité de la recherche, d'autres questionnent les affirmations factuelles, les références juridiques ou la cohérence éditoriale.

Leurs retours sont transmis à un agent éditorial, qui intègre les corrections dans une nouvelle version. Les versions précédentes, les rapports de relecture et les traces de décision sont conservés pour que les changements puissent être reconstitués.

Cet article est passé par ce processus.

Lors d'une relecture, un agent de recherche a contesté une phrase où j'affirmais qu'ouvrir des fichiers précis me permettait d'identifier quel fichier avait produit chaque phrase.

C'était faux.

Savoir quels fichiers étaient disponibles pour un modèle n'établit pas l'origine de chaque affirmation qu'il génère. Un contexte reproductible n'est pas une attribution vérifiable. La seconde demande une discipline à part : attacher des sources aux affirmations et vérifier qu'elles les soutiennent vraiment.

Cette correction a renforcé l'argument.

Un autre agent a contesté le nombre de notes du registre. Il en comptait 574 ; j'ai vérifié le dossier moi-même, trouvé 4 090 fichiers Markdown, et rejeté la correction.

En y regardant de nouveau, l'agent avait raison sur le fond. La plupart de ces fichiers étaient des README de dépendances enfouis dans node_modules ; le registre lui-même contient quelques centaines de vraies notes.

J'avais vérifié le compte au lieu de vérifier ce qui était compté.

Une correction acceptée, une correction rejetée à tort, et l'erreur retrouvée plus tard par le même système qui permettait de la vérifier.

Les agents ne votent pas sur ce qui est vrai. Ils exposent des questions à examiner. Même quand plusieurs agents sont d'accord, ils peuvent partager le même malentendu.

C'est pour ça que le processus de relecture ne retire pas ma responsabilité sur ce qui est publié.

Pour chaque livrable substantiel, je garde une trace de son état, de ses sources, de ses relectures et de ses décisions de design, avec les versions précédentes quand c'est pertinent.

Concrètement, un dossier ressemble à ça :

status.md       l'état, les sources, et les réserves sur ces sources
reviews/        relectures factuelle, recherche et éditoriale séparées, plus l'intégration
decisions.md    ce qui a été décidé, les options écartées, et pourquoi
article-v1.txt  la version précédente, pour que la différence soit reconstituable

Le but n'est pas une traçabilité parfaite. C'est de rendre visibles le raisonnement et ses limites.

Il y a aussi un coût pratique.

Toutes les décisions ne méritent pas le même niveau d'attention. Pour un quick win, je peux implémenter d'abord et documenter le raisonnement ensuite.

Pour les problèmes plus larges, une epic, une interaction qui touche plusieurs parties d'un produit, le raisonnement se construit en même temps que le travail : contraintes, alternatives et questions ouvertes sont documentées au fur et à mesure.

Ces deux types de traces ne se valent pas.

Une décision documentée après coup est une reconstruction. Une décision documentée pendant l'exploration du problème préserve davantage le raisonnement tel qu'il s'est construit.

Je veux que le registre rende cette distinction visible, plutôt que de donner à chaque entrée une apparence artificielle de certitude.

Plus de documentation, moins de charge mentale

J'ai commencé à construire ce système parce que j'avais besoin de travailler plus vite.

Aujourd'hui, le bénéfice le plus important n'est pas seulement le temps gagné.

C'est l'attention que je récupère.

En réunion, je peux dépenser moins d'énergie à capter, organiser et retenir chaque détail. Je peux écouter plus attentivement. Poser une autre question. Suivre une réponse inattendue plutôt que de m'inquiéter de perdre la précédente.

Les échanges deviennent plus naturels.

J'enregistre toujours les réunions et je prends des notes. Mais je n'ai plus à compter sur ma seule mémoire pour préserver chaque lien entre les sujets.

Le système prend en charge une partie du travail répétitif d'organisation, de recherche et de confrontation de l'information.

Ça ne fait pas de moi un meilleur designer automatiquement. Ça crée plus d'espace pour les parties du design qui demandent une attention humaine.

Le prochain défi, c'est de faire fonctionner ça pour d'autres.

J'utilise aujourd'hui l'approche personnellement et avec des collaborateurs, mais je veux l'expérimenter sur de plus longues périodes avec d'autres designers : comprendre où elle aide, où elle crée de la friction, et ce qui la rendrait plus simple à adopter sans devoir construire tout un environnement technique.

À terme, j'aimerais en faire un Design Registry prêt à l'emploi. Quelque chose qu'un designer ou une équipe pourrait installer et adapter à sa propre façon de travailler.

C'est encore une direction, pas un produit fini.

Pour l'instant, je veux être clair sur ce que représente cet article.

Les dates de ce texte sont les miennes, pas des archives : 2023, c'est un souvenir, pas un fichier. Ce que vous lisez, c'est ce que je peux défendre en octobre 2026, pas un enregistrement de ce que je pensais dans la salle.

Le registre ne garantit pas que chaque décision était la bonne. Il ne remplace ni la discussion, ni le désaccord, ni le jugement.

Il donne à ces discussions un point de départ.

Quand quelqu'un demande pourquoi on a conçu quelque chose d'une certaine façon, on peut examiner le raisonnement, questionner les contraintes et décider si le choix a encore du sens.

Et quand je suis assis face à un autre designer, un collègue ou un utilisateur, je n'ai pas à passer la conversation à essayer de me souvenir de tout.

Le registre préserve le contexte. Pour que je puisse donner mon attention aux personnes en face de moi.