Pourquoi j’écris une « fiche de mission » pour chaque projet

On pourrait croire que, l’IA sachant désormais écrire du code, le coût de démarrage a baissé et qu’il devient moins important de réfléchir d’abord. Mon expérience dit exactement l’inverse : depuis que le code est facile, l’essentiel est de dire exactement ce que l’on veut.

D’où ma règle actuelle : toute tâche dépassant une demi-journée commence par une fiche de mission. Tant qu’elle n’est pas écrite, le travail ne commence pas.

Ce que contient une fiche de mission

Quatre sections, une quinzaine de lignes en général — bien plus courte qu’on ne l’imagine :

• Objectif : quelle chose utilisable existera dans le monde une fois ceci terminé. Une phrase, sans verbes sans fin comme « améliorer » ou « peaufiner ».
• Entrées : le matériau disponible, les décisions déjà prises qu’il faut respecter, et le fichier où trouver le précédent à suivre.
• Critères de recette : une liste que l’on coche point par point. « Vérifié » doit vouloir dire « commande + sortie » ; un critère flou n’est pas un critère.
• Hors périmètre : ce que ce tour ne touchera pas, explicitement, et où ces choses ont été renvoyées.

La dernière section est la plus souvent sautée, et la plus précieuse.

Les trois choses qu’elle empêche

D’abord, elle me protège de moi-même. Si je n’arrive pas à écrire des critères de recette clairs, c’est en général que je n’ai pas décidé ce que je voulais. Et c’est précisément le moment où j’ai le plus envie de commencer quand même, quitte à réfléchir en route. La fiche force ce flou à se montrer : hésiter à la rédaction coûte bien moins cher qu’hésiter à la reprise.

Ensuite, elle empêche la dérive. L’échec coûteux, dans le travail avec l’IA, n’est pas qu’elle écrive du mauvais code : c’est qu’elle fasse avec enthousiasme, et très bien, quelque chose qu’il ne fallait pas faire. Avec des limites écrites, « on pourrait aussi faire ça au passage ? » reçoit une réponse qui ne dépend pas de mon humeur : non — au vivier de tâches, pour le tour suivant.

Enfin, elle empêche l’oubli. Mes fenêtres changent : le contexte se remplit, le sujet tourne, une fenêtre part à la retraite et une autre prend le relais. Ce qui fait tenir l’établi pendant que ses occupants se succèdent, c’est la fiche de mission restée dans le dépôt. Elle est écrite pour la prochaine fenêtre, pas pour moi aujourd’hui.

Elles ont fini par devenir des outils

À la troisième fois que j’ai écrit le même préambule, je l’ai figé en outil. J’ai aujourd’hui quelques skills écrits par moi : un pour lancer un projet (project-init, rattaché à murDrift), qui met en place d’un coup l’architecture, les jalons et l’infrastructure de vérification ; un pour la veille (murPick), qui transforme les candidats en un « menu » à cocher avant tout travail ; et un qui pré-installe dans un nouvel espace de travail mon parcours et mes préférences (memory-seed, également rattaché à murDrift), pour ne pas avoir à me présenter à chaque changement de répertoire.

Leur point commun : figer le jugement en processus, puis figer le processus en scripts. Une règle sans script derrière elle n’est que de l’art accroché au mur. Ces disciplines éparses ont toutes été rassemblées dans murDrift — un ensemble de contraintes d’ingénierie qui empêche les projets longs de dériver en silence.

Une raison égoïste

Écrire des fiches de mission a un effet secondaire dont je suis devenu friand : chaque petite tâche se termine par un « terminé » sans ambiguïté — on coche, on ferme la carte — ce qui convient très bien à un tempérament un peu maniaque. Ce qui épuise sur un projet long, ce n’est en général pas la difficulté, c’est l’absence de bords — et la fiche de mission rend au moins les bords.

L’article que vous lisez a lui aussi commencé par une carte.