WORKFLOW PILOTÉ PAR SPÉCIFICATIONS CLAUDE

La génération de code avec Claude est suffisamment rapide pour que le goulot d'étranglement ne soit plus la frappe. Le goulot d'étranglement, c'est de savoir exactement ce que vous voulez avant que Claude ne l'écrive. Un workflow piloté par spécifications anticipe la réflexion pour que la phase d'implémentation devienne de l'exécution plutôt que de l'exploration.

Les équipes qui livrent bien avec Claude sont celles qui ont développé une discipline de spécification avant l'existence des outils IA. Les équipes qui peinent sont celles qui essaient de contourner la spécification en demandant à Claude de trouver la solution.

Je décris le problème à Claude en trois ou quatre phrases. Ensuite, je demande à Claude de formuler cinq questions dont les réponses changeraient le design. J'y réponds. Puis je demande à Claude de résumer la spécification produit résultante en 200 mots.

Cette étape prend 30 à 60 minutes et produit une spécification écrite dont découle le reste du travail. Les cinq questions sont généralement celles que j'aurais ignorées en passant directement au code ; les faire émerger via l'étape de brainstorm, c'est toute la valeur ajoutée.

Avec la spécification en main, je demande à Claude d'identifier les choix architecturaux qui ont le plus grand effet en aval. La forme de la base de données, la surface de l'API, la stratégie de rendu, le modèle de déploiement. Pour chacun, Claude propose deux ou trois options avec leurs compromis respectifs.

Je choisis. Les décisions vont dans le même document pour que la phase de développement dispose d'une seule source de vérité. Les décisions prises à ce stade coûtent 10 fois moins cher à réviser que celles découvertes durant l'implémentation.

La génération de code est la dernière étape et elle est la plus rapide parce que la spécification est déjà complète. Claude écrit le schéma, les requêtes, les composants, les routes, les tests, à peu près dans cet ordre. Je révise chaque commit.

La plupart des révisions font ressortir une petite refactorisation ou un cas limite oublié ; les réécrtures complètes sont rares quand la spécification était claire. La cadence est deux à cinq fois plus rapide que l'ingénierie sans assistance sur du travail greenfield.

Trois portes de révision entre le brainstorm et le code livré :

Porte de spécification : avant qu'un seul code soit écrit, la spécification de 200 mots se lit de haut en bas. Tout ce qui est ambigu est clarifié. Tout ce qui est aspirationnel est supprimé.

Portail architectural : avant toute migration de base de données, les décisions architecturales sont examinées par rapport à la spécification. Tout ce qui ne respecte pas la spécification est reconsidéré.

Portail de commit : chaque commit rédigé par Claude fait l'objet d'une revue humaine avant sa fusion. La revue est plus rapide que d'écrire le code vous-même, mais elle est non-contournable. Claude n'approuve pas ses propres pull requests.

Travaux exploratoires ou de recherche où l'objectif est d'apprendre ce qui est possible plutôt que de construire quelque chose de connu. Pour ceux-ci, l'étape spec produit des spécifications vagues qui contraignent Claude de manière contre-productive. Une conversation itérative avec des artefacts concrets est le bon modèle à la place.

Corrections de bugs dont la cause est inconnue. L'étape spec suppose que vous connaissez la destination ; le débogage, c'est déterminer où vous êtes. Pour déboguer, passez directement au modèle de débogage systématique (reproduire, isoler, diagnostiquer, corriger) et sautez l'étape spec.

Polissage UI où chaque itération est mineure et la rétroaction visuelle est le signal. Pour ceux-ci, Claude dans Cursor avec hot reload et diff côte à côte est l'outil adéquat, non une spécification écrite.