FLUX DE TRAVAIL AXÉ SUR LES SPÉCIFICATIONS CLAUDE
Le processus précis en trois étapes que j'applique à chaque projet réalisé avec l'aide de Claude. De la réflexion initiale à la mise en œuvre en passant par la définition du cahier des charges, avec des contrôles permettant de détecter les erreurs dès le début.
← Tous les guides Tous les guides de ce sujet
Sur cette page
Pourquoi l'approche axée sur les spécifications est importante
La génération de code avec Claude est suffisamment rapide pour que la saisie ne constitue plus un frein. Le véritable obstacle réside dans le fait de savoir exactement ce que l'on veut avant que Claude ne l'écrive. Un workflow axé sur les spécifications concentre la réflexion en amont, de sorte que la phase de mise en œuvre devient une simple exécution plutôt qu'une exploration.
Les équipes qui parviennent à bien travailler avec Claude sont celles qui ont mis en place une discipline en matière de spécifications avant même l'apparition des outils d'IA. Celles qui rencontrent des difficultés sont celles qui tentent de faire l'impasse sur les spécifications en demandant à Claude de s'en charger.
Étape 1 : brainstorming structuré
Je décris le problème à Claude en trois ou quatre phrases. Ensuite, je demande à Claude de formuler cinq questions dont les réponses modifieraient la conception. J'y réponds. Puis je demande à Claude de résumer le cahier des charges qui en résulte en 200 mots.
Cette étape dure entre 30 et 60 minutes et aboutit à un cahier des charges écrit qui sert de base au reste du travail. Ces cinq questions sont généralement celles que j'aurais ignorées si j'étais passé directement au codage ; les mettre en évidence lors de la phase de brainstorming, c'est là tout l'intérêt de cette étape.
Étape 2 : décisions techniques
Une fois le cahier des charges en main, je demande à Claude d'identifier les choix architecturaux qui auront le plus d'impact en aval : structure de la base de données, interface API, stratégie de rendu, modèle de déploiement. Pour chacun d'entre eux, Claude propose deux ou trois options, avec leurs avantages et leurs inconvénients respectifs.
C'est moi qui choisis. Les décisions sont consignées dans un seul et même document, afin que la phase de développement dispose d'une source unique de référence. Les décisions prises à ce stade sont dix fois moins coûteuses à modifier que celles identifiées au cours de la mise en œuvre.
Étape 3 : mise en œuvre basée sur le cahier des charges
La génération de code constitue la dernière étape et c'est la plus rapide, car le cahier des charges est déjà finalisé. Claude rédige le schéma, les requêtes, les composants, les routes et les tests, à peu près dans cet ordre. Je vérifie chaque commit.
La plupart des revues font ressortir une petite refonte ou un cas limite qui avait été omis ; les réécritures complètes sont rares lorsque le cahier des charges était clair. Le rythme est deux à cinq fois plus rapide que celui d'un travail d'ingénierie effectué sans aide sur un projet entièrement nouveau.
Les barrières qui interceptent les défaillances
Trois étapes de révision entre la phase de réflexion et le code livré :
« Spec gate » : avant d'écrire la moindre ligne de code, le cahier des charges de 200 mots est lu de bout en bout. Tout ce qui prête à ambiguïté est clarifié. Tout ce qui relève de l'aspiration est supprimé.
Contrôle architectural : avant toute migration de base de données, les choix architecturaux sont examinés à la lumière du cahier des charges. Tout élément qui ne répond pas aux exigences de ce dernier est réexaminé.
Contrôle des commits : chaque commit rédigé par Claude fait l'objet d'une révision humaine avant d'être fusionné. Cette révision est plus rapide que d'écrire le code soi-même, mais elle est obligatoire. Claude n'approuve pas ses propres pull requests.
Quand l'approche axée sur les spécifications ne fonctionne pas
Travaux exploratoires ou axés sur la recherche, dont l’objectif est de découvrir ce qui est possible plutôt que de créer quelque chose de déjà connu. Dans ce type de cas, la phase de définition des spécifications aboutit à des spécifications vagues qui limitent Claude de manière contre-productive. Il vaut mieux privilégier un dialogue itératif s’appuyant sur des éléments concrets.
Corrections de bogues dont la cause est inconnue. La phase de spécification part du principe que vous connaissez la destination ; le débogage consiste à déterminer où vous vous trouvez. Pour le débogage, passez directement au modèle de débogage systématique (reproduction, isolation, diagnostic, correction) et ignorez la phase de spécification.
Une amélioration de l'interface utilisateur où chaque itération est mineure et où le retour visuel sert de signal. Pour cela, Claude dans Cursor, avec la réinitialisation à chaud et la comparaison côte à côte, est l'outil idéal, bien plus qu'un cahier des charges écrit.