Le prompt qui démarre un projet

Pourquoi le prompting structuré

Un bon prompt de démarrage poursuit trois objectifs simultanément : autonomie de l'agent (pas de questions retour bloquantes en cours de session), sécurité du contexte (pas d'interprétation hasardeuse de ce qu'on n'a pas dit), économie de tokens (le bon modèle pour la bonne tâche, ni plus ni moins).

Un prompt mal écrit coûte cher : itérations supplémentaires, ré-écritures, modèle trop puissant invoqué pour rien. Sur un projet long comme celui-ci, l'écart cumulé entre un prompt soigné et un prompt approximatif se chiffre en heures et en euros.

Anatomie d'un prompt de démarrage

Un prompt de kickoff projet contient six sections-clés. Chaque section adresse un type de question que l'agent poserait sinon en cours de session :

• Contexte — où on en est, ce qui existe (stack actuelle, historique, repo, branche par défaut)
• Objectif — ce qu'on veut atteindre, en une phrase
• Contraintes — ce qu'on ne peut pas faire (deadline, stack imposée, dépendances figées, conventions repo)
• Stack — versions concrètes, pas "récent" ou "moderne"
• Critères de succès — comment on saura que c'est terminé (mesurable de préférence)
• Hors-scope — ce qui n'est PAS demandé (évite les sur-livraisons)

Bonus à inclure quand pertinent : les branches de validation explicites (à quels moments l'agent doit demander confirmation utilisateur), les permissions accordées (yarn install, git commit, force-push interdit, etc.), et le mapping modèle/tâche (cf. section suivante).

Le bon modèle pour la bonne tâche

Trois familles de modèles, trois usages typiques :

• Opus 4.7 — architecture, design, review critique, plans complexes. Raisonnement profond, peut coûter cher mais évite les itérations futures.
• Sonnet 4.6 — implémentation mécanique, refacto multi-fichiers, intégration de spec claire. Standard, rapport qualité/coût optimal pour la majorité des tâches dev.
• Haiku 4.5 — tâches isolées, recherches simples, formatage, deletes triviaux, audits grep. Rapide et bon marché, parfait quand le contexte de raisonnement est minimal.

Règle d'or : toujours commencer par Sonnet. Escalader vers Opus uniquement quand on observe des erreurs de jugement (architecture incohérente, plan flou). Descendre vers Haiku quand la tâche est mécanique (renommer un champ, supprimer un fichier mort, ajouter un test verbatim depuis un spec).

Ordre de grandeur observé sur ce projet (Plans 1 à 6, ~20 PRs et fixups) : ~70% Sonnet, ~20% Opus, ~10% Haiku. Inverser ce mix (tout en Opus) multiplie le coût par environ 5×.

Sécuriser le contexte

L'agent ne devine pas. Quand une donnée manque, il interpole — souvent mal. Sécuriser le contexte, c'est donner toute la data nécessaire d'entrée :

• Inclure les fichiers et sections exactes à modifier (paths absolus, ranges de lignes si pertinent)
• Préciser les conventions repo (nommage, formats commits, structure de tests, branches autorisées)
• Mentionner les écueils connus ("attention, X était cassé avant la migration Y, fais bien Z d'abord")
• Citer les sources externes (repo, doc, ticket) plutôt que de paraphraser

Autonomie de l'agent

L'objectif n'est pas zéro question. C'est zéro question évitable. Préparer toutes les décisions tranchables à l'avance dans le prompt initial évite que la session s'arrête toutes les 5 minutes sur une ambiguïté.

• Lister les "questions à NE PAS poser" avec leur réponse anticipée : "n'utilise pas X, on a déjà Y", "ne crée pas de tests pour ça, c'est un MVP"
• Définir explicitement les branches de validation : "après la migration des sections 1-3, demande validation visuelle avant de continuer sur 4-6"
• Préciser les permissions : si l'agent peut commit/push directement, ou s'il doit attendre une confirmation par PR
• Donner le mapping modèle/tâche pour que l'agent puisse s'auto-router sur le bon coût

Exemple appliqué : QAConsulting (deux approches)

Voici deux façons d'avoir démarré ce projet (refonte du site qaconsulting.fr) avec un prompt de kickoff. Les deux sont valides — le choix dépend du contexte.

**Approche A — Prompt mono "kickoff complet"** : un seul gros prompt qui pose le cadre une fois pour toutes.

# Refonte qaconsulting.fr — Prompt de kickoff

## Contexte

Site CV mono-page existant en Next 13 / Pages Router / styled-components.
Audit SEO : `x-robots-tag: noindex` global → site invisible Google.
Stack actuelle : React 18, TypeScript, Drupal pour un blog non-utilisé.
Prod hébergée sur Vercel, domaine www.qaconsulting.fr.
Repo : github.com/Jawstheone/QA-Consulting (branche develop = source de vérité).

## Objectif

Transformer le site en vitrine candidat senior (Tech Lead React + IA appliquée)
indexable Google, multi-pages, avec section "Best Practices IA" mettant en
avant les outils que j'utilise au quotidien (Claude Code, Superpowers, RTK,
monitor-ccu) — chacun dans son article dédié avec attribution complète.

## Contraintes

- Conserver le domaine et l'email actuels (contact@qaconsulting.fr)
- Pas de breaking change sur les URLs publiques existantes
- Tout texte d'article reste factuel : si un chiffre n'est pas mesuré, on
  reformule en qualitatif
- Conventions commits : Conventional Commits FR, pas de Co-Authored-By trailer
- Branche `develop` = staging, `main` = prod (Vercel auto-deploy sur push main)

## Stack cible

- Next 15 (App Router), TypeScript 5.5, Tailwind v4
- Plus de styled-components à terme
- Tests Jest + @testing-library/react
- IA : Claude Code (Opus 4.7 pour planning, Sonnet 4.6 pour implémentation)

## Critères de succès

- Lighthouse mobile ≥ 95 sur les 5 routes indexables
- 0 styled-components dans src/ et tests/
- Sitemap GSC re-soumis et accepté
- PDF /cv téléchargeable et lisible
- Tests verts (objectif final ~70/70)
- Pas de régression visuelle sur viewport 1440 et 375

## Hors-scope

- Internationalisation (FR seulement)
- Mode sombre toggle
- Refonte du contenu CV au-delà du strict cohérence (sera traité plus tard)
- Storybook (à supprimer si présent et inutilisé)

## Branches de validation

- Après chaque "Plan" majeur (1, 2, 3, 4, 4.5, 5, 6) : ouvrir une PR
  develop ← feat/plan-N et attendre validation utilisateur avant release
  develop → main
- Si décision architecturale ambiguë : poser la question avec ≤4 options
  multiple-choice
- Sur tâche PDF /cv : gate critique, pas de modification sans validation visuelle

## Modèles à utiliser

- Plans, architecture, design : Opus 4.7
- Implémentation mécanique tâche par tâche : Sonnet 4.6
- Reviews triviales et grep défensifs : Haiku 4.5

## Permissions

- yarn install / commit / push : OK sans confirmation
- Pas de force-push, pas de --no-verify, pas de modification de main directe
- Toute suppression de fichier > 5 lignes : confirmer avant

**Approche B — Prompts gradués** : un kickoff léger qui sert de socle, puis des prompts ciblés pour chaque type de tâche.

# Refonte qaconsulting.fr — Kickoff (léger)

Site CV Next 13 + styled-components, invisible Google.
Cible : vitrine candidat senior + section IA, Next 15 + Tailwind.
Sources : github.com/Jawstheone/QA-Consulting, branche develop.
Modèle : Opus 4.7. Convention : commits FR, branche feat/* → develop → main.
Premier livrable attendu : un plan d'audit + roadmap incrémentale en plans
de 1-2 semaines chacun.

# Feature — [nom de la feature]

Plan : docs/superpowers/plans/[plan-N].md
Tâche actuelle : T[X] [titre]
Modèle : Sonnet 4.6
Critères : tsc/lint/test green, 1 commit Conventional Commits FR
Branche : feat/plan-N (déjà créée)
Hors-scope : tout ce qui n'est pas dans T[X]

# Debug — [symptôme observé]

Reproduction : [étapes ou commande]
Logs / erreur : [paste ici]
Hypothèse : [si tu en as une, sinon "à investiguer"]
Modèle : Sonnet 4.6 (escalade vers Opus si analyse profonde requise)
Critères : root cause identifiée + fix en commit séparé + test régression
si pertinent

# Review — PR #[N]

Spec / plan : docs/superpowers/plans/[plan-N].md
PR : https://github.com/Jawstheone/QA-Consulting/pull/N
Modèle : Opus 4.7 (review demande du jugement)
Sortie attendue : Strengths / Critical / Important / Minor / Assessment APPROVED|NEEDS_FIXES
Si NEEDS_FIXES : fixes proposés en bullets actionnable

**Comparaison des deux approches** :

• Mono "kickoff complet" — Avantages : autonomie maximale (l'agent connaît tout en début de session), économie de cache (le gros prompt est mis en cache prompt caching à 0,1× pendant 5 min), une seule passe d'analyse contexte, idéal Opus pour architecture. Inconvénients : difficile à écrire d'un coup (auteur risque l'oubli), context-window peut atteindre les limites, agent peut perdre le focus sur les détails noyés dans la masse, moins agile pour pivoter en cours de session.
• Gradués (kickoff léger + feature/debug/review séparés) — Avantages : plus simple à écrire prompt par prompt, on peut adapter le modèle par prompt (Opus pour kickoff, Sonnet pour features, Haiku pour reviews simples), souplesse pour pivoter, prompts ré-utilisables (template feature). Inconvénients : moins économe en cache (le contexte se reconstruit à chaque session), risque d'incohérence inter-prompts (l'auteur oublie une convention entre 2 prompts), pas d'autonomie multi-features dans une seule session.

Verdict pratique : **mono pour démarrer un projet vierge ou un gros chantier** (ex: refonte complète QAConsulting), **gradués pour la vie quotidienne d'un projet établi** (ex: feature isolée sur un projet existant).

Anti-patterns courants

• Prompt trop court : "fais X" sans contexte → l'agent invente, divergence garantie
• Pas de critères de succès : la tâche peut être "presque terminée" infiniment
• Sur-spécification cosmétique : décrire chaque ligne de code → l'agent devient une calculatrice, perte d'utilité
• Modèle mal-matché : Haiku pour de l'archi (résultat médiocre) ou Opus pour un format JSON (gaspillage)
• Pas de hors-scope : l'agent rajoute des features non demandées (overbuilding)
• Ambiguïté "tu peux faire ça si tu veux" : l'agent fera ou ne fera pas selon humeur du modèle, coût d'incertitude

Outils complémentaires

Le prompting est une compétence qui paye à long terme, mais elle se renforce avec les bons outils :

• Claude Code — l'agent CLI lui-même, qui exécute les prompts dans un contexte projet réel
• Superpowers ou CC AI Virtual Staff — skills réutilisables pour ne pas répéter le même prompt à chaque session
• RTK — économie de 60-90% des tokens sur opérations CLI répétitives (git, ls, cat, grep, etc.) qui sinon polluent le contexte
• monitor-ccu — tracking visuel des coûts session par session, feedback nécessaire pour calibrer la règle modèle/tâche en condition réelle

Chaque outil est documenté ailleurs sur ce site dans sa propre fiche. Le prompt est la couche conceptuelle ; ces outils en sont l'infrastructure.