Résumé
Dans la première partie de cette série, une revue de conception contradictoire avait trouvé trois vrais problèmes avant qu’une ligne ne soit écrite. La question qui suivait était évidente: quel workflow rend cela répétable ? Cet article est ma réponse, et il demande aussi ce que cette réponse change pour chaque rôle du cycle de développement.
La règle tient en peu de mots: la spécification est la source de vérité, les invariants sont le contrat, le code en est une implémentation. Quand quelque chose casse, je commence par me demander si la spécification est fausse ou incomplète, je la corrige, et seulement ensuite je laisse l’IA réaligner le code; jamais l’inverse. Dans un projet classique, la spécification dérive pendant que le code avance; avec une IA qui la lit comme la vérité, cette dérive devient dangereuse, car la session suivante réintroduit l’ancien comportement à partir de l’ancien document.
Autour de cette règle, un système d’exploitation: un CLAUDE.md concis qui renvoie à des fichiers de règles ciblés, des skills à responsabilité unique, un plan par fonctionnalité qui fait office d’état de référence, des prompts versionnés comme des actifs du projet, et des tâches assez petites pour que «terminé» signifie une preuve plutôt qu’une impression. Le jour où j’ai exigé la sortie réelle plutôt qu’une prédiction, une suite annoncée verte comptait 138 échecs.
Ce qui m’a le plus surpris, c’est que la qualité est devenue moins chère. Quand le coût mécanique des tests, des migrations et des décisions documentées s’effondre, la bonne façon de faire cesse d’être la façon coûteuse; sur ce projet, le code de test pèse plus lourd que le code de production. Chaque rôle passe de la production d’un artefact à la définition de contraintes et au jugement de la justesse. L’IA écrit le code; elle ne décide pas s’il est juste. Il faut encore un ingénieur, et peut-être plus de compétence d’ingénierie qu’avant.
Idées clés
- La spécification est la source de vérité, les invariants sont le contrat, le code en est une implémentation: on corrige d’abord la spécification, puis on réaligne le code.
- Un CLAUDE.md concis qui renvoie à des fichiers de règles ciblés, un plan par fonctionnalité comme état de référence, et des prompts versionnés comme des actifs du projet.
- Une tâche, un fichier, une vérification: «terminé» veut dire la sortie réelle de la commande de vérification, pas une prédiction que les tests devraient passer.
- La qualité est devenue moins chère: quand le coût mécanique de la rigueur tombe, les tests, les migrations et les décisions documentées cessent d’être un luxe.
- Ne demandez pas si l’IA peut écrire votre code. Demandez-vous si vous sauriez qu’il est faux.
Pourquoi j’ai écrit cet article
Dans la première partie, une revue de conception contradictoire avait trouvé trois vrais problèmes avant l’implémentation. La question évidente était de savoir quel workflow rend cela répétable; cet article y répond.