flriancu/claude-code-setup

Lancement des exigences

L'utilisateur tranche les décisions explicitement et à moindre coût au départ, puis construit par étapes révisées. Une construction en une seule fois intègre des suppositions qu'il devra démêler ensuite. Une longue réflexion silencieuse avant que quoi que ce soit ne soit sur papier l'ennuie tout autant (« pas besoin d'une seule réponse, pourquoi cette longue réflexion ? faisons un brouillon de doc avec des phases »). Donc mettez des questions et un plan rapidement sur papier, et laissez-le orienter.

1. Rassembler, brièvement

• Lisez ce qui a été fourni : fichiers, dossiers, liens, images, conversations précédentes et notes de mémoire, le README du dépôt. Notez ce qui est déjà décidé pour ne pas le redemander.
• Si une entrée manque encore (« lien à venir », « photo arrivera plus tard »), commencez quand même les questions et marquez celles qui en dépendent.
• N'écrivez pas de code et ne modifiez pas encore de fichiers. Ne délibérez pas longuement : les questions sont l'outil de réflexion.

2. Poser des questions numérotées

• Une liste numérotée, regroupée par sujet lorsqu'il y en a beaucoup. Chaque question tient sur une ligne avec les options que vous voyez et votre recommandation par défaut, par exemple : 3. Emplacement d'installation : C: ou D: ? Recommandé : D:, car C: est presque plein.
• L'utilisateur répond succinctement par numéro (« 1. les deux 2. mettre à jour 3. ok »). Reflétez chaque réponse avec soin. « ok » ou « d'accord » accepte votre valeur par défaut ; « premier » et « dernier » se réfèrent à l'ordre de vos options ; un numéro sauté signifie « à vous de choisir, dites-moi ce que vous avez choisi ».
• Couvrez ce qui importe pour cet effort : objectif et public ; périmètre et non-objectifs explicites ; entrées et sorties (formats, emplacements) ; contraintes (plateforme, outils autorisés ou interdits, licences, utilisation hors ligne, matériel) ; niveau de qualité et test d'acceptation (« comment saurons-nous que ça marche ») ; comportement en cas d'échec (ce qui se passe quand chaque partie échoue à tout moment : un crash, une connexion perdue, une coupure de courant, un nœud sur plusieurs qui tombe en panne) ; fidélité (ce qui ne doit jamais être modifié) ; où vivent les choses (dépôt, chemins, distant) ; livraison (qui reçoit quoi, à quelle fréquence).
• Menez un second tour plus court uniquement pour les réponses qui ont ouvert de nouvelles questions. Arrêtez de demander dès que les inconnues restantes ont des valeurs par défaut sûres, et listez ces valeurs par défaut à la place.

3. Rédiger le contrat : REQUIREMENTS.md

Placez-le à la racine du projet, en créant le dossier si le projet est nouveau. Gardez-le simple, court et daté :

# Exigences de <Projet>

Convenues le <AAAA-MM-JJ>. Ce fichier est le contrat ; les modifications y sont enregistrées avec une date.

## Objectif
## Public et utilisation
## Périmètre
## Non-objectifs
## Décisions
- D-01 <décision> (<date>)
## Exigences fonctionnelles
- EF-01 ...
## Contraintes et exigences non fonctionnelles
- C-01 ...
## Vérification
Une ligne par exigence : comment elle est vérifiée et où se trouve la preuve.
| ID | Méthode (test / inspection / analyse / démonstration) | Preuve (cas de test, script, fichier) |
## Questions ouvertes

Les identifiants stables (D-xx, EF-xx, C-xx) permettent aux travaux, commits et rapports ultérieurs de les citer. Enregistrez les réponses de l'utilisateur dans ses propres termes ; ne les paraphrasez pas pour les rendre plus forts ou plus faibles.

Associez chaque exigence à une méthode de vérification et à un emplacement de preuve. Les quatre méthodes sont les méthodes standard du génie des exigences (ISO/IEC/IEEE 29148). Préférez un test. Lorsqu'une exigence ne peut être vérifiée que par inspection ou analyse (« pas d'appels directs aux threads OS », « surcharge d'ordonnancement inférieure à 100 microsecondes par nœud »), écrivez la vérification comme un script qui sauvegarde sa sortie comme preuve, afin que la preuve puisse être relancée plutôt que rediscutée.

4. Rédiger le plan : phases

Placez-le à côté des exigences dans PLAN.md, ou dans une section « Phases » lorsque le projet est petit. La phase 0 est généralement la configuration, ou un pilote qui prouve d'abord l'hypothèse la plus risquée. Pour chaque phase, donnez l'objectif, les étapes, le livrable, comment elle est vérifiée, et les identifiants d'exigence qu'elle sert. Gardez les phases suffisamment petites pour être révisées en une seule séance, et dites que le plan sera ajusté en cours de route.

Arrêtez-vous ensuite. Résumez les deux fichiers en quelques lignes et recommandez la première phase.

5. Exécuter sur demande, une phase à la fois

• N'exécutez que les phases que l'utilisateur nomme (« exécute la phase 0 », « exécute les phases 0 et 1 », « go »).
• À la fin de chaque phase, signalez ce qui a été fait, la preuve que ça fonctionne (commandes exécutées, sorties, résultats de tests), ce qui a dévié du plan et pourquoi, et ce qui vient ensuite. Marquez la phase comme terminée dans le plan.
• « point de progression » signifie : phase en cours, ce qui est fait, ce qui tourne, ce qui est bloqué.
• Un nouveau souhait qui change le périmètre est ajouté dans REQUIREMENTS.md avec sa date avant que vous ne le construisiez. Une décision inversée est enregistrée comme une inversion ; l'ancienne ligne reste.
• Corrigez les bugs trouvés en cours de route lorsque l'utilisateur l'a demandé ; sinon listez-les.
• Lorsque la dernière phase est terminée, ou lorsque l'utilisateur le demande, lancez un écart : exigences contre code, tests, documentation et preuves. Rapportez chaque écart avec son identifiant d'exigence, corrigez-les un par un sur demande, et relancez les scripts de preuve.
• Ne commitez pas et ne poussez pas après chaque étape. Proposez un commit lorsqu'une phase est terminée ; poussez uniquement sur demande.

Variantes

• Décisions sans code (un achat, un choix d'outil) : mêmes questions, puis une courte comparaison par rapport aux critères convenus au lieu des deux fichiers.
• Contenu de quelqu'un d'autre (le livre d'un auteur, les données d'un client, des enregistrements) : ajoutez une exigence de fidélité dès le départ. Rien dans le contenu ne change silencieusement ; chaque changement est proposé, marqué et signalé pour approbation.