Il y a un ticket dans Linear que je connais par cœur.
Titre : "Améliorer l'UX du formulaire."
Description : vide.
Commentaires : un lien vers une réunion qui a eu lieu il y a six semaines et dont personne n'a pris de notes.
J'ai passé deux jours à coder quelque chose. Puis j'ai montré. Puis j'ai refait.
Ce n'est pas un problème d'équipe défaillante. C'est souvent la norme dans la plupart des projets que j'ai vus.
Ce que ça coûte vraiment
Le coût évident, c'est le temps. Tu codes, tu montres, tu refais. Trois itérations pour quelque chose qui aurait pu être cadré en trente minutes.
Le coût moins évident, c'est la charge mentale de naviguer dans le flou. Chaque décision que tu prends sans spec explicite est une décision que tu devras peut-être défaire. Tu le sais en codant. Alors tu codes avec une main en l'air, prêt à reculer.
Et puis il y a ce que j'appellerais la dette de décision. Pas la dette technique — la dette des choix jamais documentés.
"Pourquoi l'UID ne change pas quand on édite le nom du type ?"
Parce qu'on en avait parlé en réunion il y a six semaines, que c'est dans la tête de deux personnes, et que la troisième a codé le contraire trois semaines plus tard.
Ce qui change quand quelqu'un refuse de jouer le jeu
J'ai une collègue qui ne commence pas un ticket sans critères d'acceptance. Pas parce qu'elle est difficile — parce qu'elle a arrêté de vouloir deviner.
Au début, ça crée des frictions.
"Tu peux pas juste le faire ?"
Non. Elle peut, mais elle ne veut pas. Parce qu'elle sait ce que ça coûte.
Ce qui s'est passé : le PM a commencé à mieux écrire ses tickets. Pas parce qu'il avait réalisé quelque chose de profond sur la gestion de projet. Parce que la friction de la demande de clarification coûtait moins cher que les allers-retours.
Le problème n'était pas que les tickets étaient flous par fatalité. C'est qu'il n'y avait aucun coût à les écrire flous.
Où Claude entre dans l'équation
Je n'ai pas de collègue qui systématise ça pour moi. Et je n'ai pas envie de passer pour celle qui bloque tout le monde avec des questions de process.
Alors j'ai commencé à faire quelque chose de différent : avant de toucher au code, je colle le ticket dans Claude et je lui demande de me poser les questions qu'il me poserait pour pouvoir l'implémenter.
Ce qui sort n'est pas la liste de questions que j'aurais posée. C'est souvent plus précis. "Est-ce que ce comportement s'applique aux types existants ou seulement aux nouveaux ?" "Que se passe-t-il si l'utilisateur quitte la page sans sauvegarder ?"
Des questions que j'aurais posées après avoir commencé l'implémentation. Là, je les ai avant de commencer.
Ce que ça change concrètement
Parfois je réponds aux questions moi-même — parce que je connais le contexte. Et là je réalise que le ticket n'était pas si flou : j'avais l'information, je ne l'avais juste pas mise au bon endroit.
Parfois je ne peux pas répondre. Et là je sais exactement quoi demander au PM, à la bizdev, ou dans le slack de l'équipe — avec une question précise, pas un "j'ai besoin de plus de détails."
Parfois les questions révèlent qu'on est en train de coder la mauvaise chose. Pas un bug — une incompréhension de l'objectif. C'est plus agréable à découvrir avant qu'après.
Ce que Claude ne fait pas
Il ne remplace pas la réflexion produit. Il ne sait pas pourquoi on veut cette feature, ce que veulent vraiment les utilisateurs, quels sont les arbitrages business derrière le ticket.
Ce qu'il fait, c'est forcer l'articulation. Quand tu dois répondre à "quel est le comportement attendu si X ?", tu réalises si tu le sais ou si tu l'as supposé.
C'est ça la vraie valeur. Pas l'IA qui pense à ta place — l'IA comme surface de rebond pour ce que tu avais à moitié formalisé dans ta tête.
La question honnête
Est-ce que ça résout le problème de fond ?
Non. Les tickets mal écrits existent toujours. La dette de décision s'accumule toujours.
Ce que ça change, c'est ma position face à cette réalité. Je ne subis plus le flou passivement — je le rends visible, au moins pour moi, avant d'ouvrir mon éditeur.
Et c'est suffisant pour que ça vaille le détour.
Top comments (0)