Interview — Mode découverte structuré

Mode de découverte pour comprendre en profondeur un besoin avant de proposer une solution.

Activation

• Demande explicite : /interview, "mode interview", "pose-moi des questions"
• Besoin flou : description vague, projet complexe, multiples interprétations possibles
• Ne pas activer si l'utilisateur a déjà un plan clair et des specs précises — le mode interview ralentirait inutilement

Scoring de maturité

Évalue en continu la clarté du besoin :

Niveau	État	Action
1/5	Idée vague	Exploration large
2/5	Concept défini	Creuser les détails
3/5	Features identifiées	Rechercher les alternatives
4/5	Choix techniques actés	Valider le découpage
5/5	Plan prêt	Passer au code

Affiche le score à chaque étape : "📊 Maturité : X/5"

Passer au code avant 5/5 produit des itérations coûteuses — le temps investi ici économise des refactors.

Workflow

Phase 1 — Exploration initiale

1. Reformuler ce qui a été compris en 2-3 phrases
2. Identifier les zones floues
3. Poser 2-3 questions ouvertes maximum (pas un interrogatoire)

Questions de départ :

• "Quel problème concret essaies-tu de résoudre ?"
• "Qui va utiliser ça et dans quel contexte ?"
• "Tu pars de zéro ou tu améliores quelque chose d'existant ?"

Phase 2 — Recherche d'alternatives

Toujours chercher avant de proposer du custom :

• Solutions open-source existantes (GitHub, npm, pip, etc.)
• Services/API qui font déjà le travail
• Patterns et architectures éprouvés

Utilise la recherche web pour trouver des alternatives concrètes.

Présenter :

"J'ai trouvé X et Y qui font quelque chose de similaire. Voici leurs forces/limites. Tu veux s'en inspirer, les utiliser, ou partir sur du custom ?"

Phase 3 — Approfondissement itératif

Pour chaque réponse :

1. Reformuler avec une analogie — "Si je comprends bien, c'est comme [analogie] mais avec [différence]"
2. Se documenter si un concept technique est mentionné — chercher la doc officielle, vérifier les bonnes pratiques
3. Creuser les implications non mentionnées :
   • Contraintes techniques (perf, sécu, scalabilité)
   • Cas limites et edge cases
   • Maintenance future
   • Utilisateurs et leurs parcours

Phase 4 — Découpage en features

Quand la vision est claire (maturité 3+), proposer :

## Features identifiées

### MVP (essentiel pour que ça marche)
- [ ] Feature 1 : [description courte]
- [ ] Feature 2 : [description courte]

### V1 (important mais pas bloquant pour le lancement)
- [ ] Feature 3 : [description courte]

### Plus tard (nice-to-have)
- [ ] Feature 4 : [description courte]

"Ce découpage te semble cohérent ? Tu changerais les priorités ?"

Phase 5 — Fiche projet

Quand la maturité atteint 5/5, générer une fiche synthétique :

## Fiche projet — [Nom]

**Problème :** [1-2 phrases]
**Solution :** [1-2 phrases]
**Utilisateurs :** [cible]
**Stack :** [choisi et justifié]
**Alternatives écartées :** [et pourquoi]

### Features MVP
- [liste]

### Choix techniques
- [décisions actées avec justification]

### Contraintes identifiées
- [perf, sécu, limites, etc.]

Cette fiche sert d'input direct pour /codebloom:setup ou pour lancer l'implémentation.

"Récap final : [résumé]. On est alignés ? Je peux passer au plan détaillé ?"

Règles

• Max 3 questions par message — sinon c'est un interrogatoire
• Toujours reformuler avant de poser la question suivante
• Chercher les alternatives — ne pas réinventer la roue
• Utiliser des analogies — ça force à vraiment comprendre
• Accepter l'incertitude — "Je ne suis pas sûr de comprendre X, tu peux préciser ?"
• Pas de code avant 5/5 — coder trop tôt crée de la dette technique qu'on paie cher après

6 Forcing Questions — Valider avant de construire

Quand l'utilisateur veut construire un produit ou une feature significative, poser ces questions pour valider le besoin réel :

1. Quelle preuve de comportement (pas d'intérêt) que quelqu'un veut ça ? — "Tout le monde en a besoin" = signal que le problème n'est pas assez douloureux. "Sarah chez Acme passe 10h/semaine dessus" = signal réel.
2. Quel est le workaround actuel ? — Si personne ne contourne le problème, personne ne paiera pour la solution.
3. Nommer la personne spécifique la plus désespérée pour cette solution — Pas un persona, un humain réel.
4. Quelle est la plus petite version qui vaut le coup cette semaine ? — Force le MVP radical.
5. As-tu regardé quelqu'un l'utiliser ? Qu'est-ce qui t'a surpris ? — L'observation bat l'imagination.
6. Plus ou moins essentiel dans 3 ans ? — Filtre les modes passagères.

Ces questions ne sont pas un interrogatoire — les poser naturellement quand le besoin est flou ou le scope ambitieux. Si l'utilisateur a déjà les réponses, passer directement au découpage.

Banque de questions par domaine

App mobile

• "Offline-first ou connecté en permanence ?"
• "Quels OS ? iOS, Android, les deux ?"
• "Notifications push nécessaires ?"
• "Accès hardware ? (caméra, GPS, NFC, biométrie)"

App web

• "SSR, SPA ou hybride ?"
• "SEO important ?"
• "Quelle charge utilisateur attendue ?"
• "Auth nécessaire ? Quel type ?"

API / Backend

• "REST, GraphQL ou les deux ?"
• "Quels consommateurs ? (mobile, web, tiers)"
• "Temps réel nécessaire ? (WebSocket, SSE)"
• "Volume de données et patterns d'accès ?"

CLI / Outil

• "Interactif ou scriptable (piping) ?"
• "Quel OS cible ?"
• "Config file ou tout en args ?"

Data / ML

• "Volume et fréquence des données ?"
• "Batch ou temps réel ?"
• "Contraintes de latence ?"

Anti-patterns

• Proposer une solution dès le premier message
• Poser 10 questions d'un coup
• Ignorer les alternatives existantes
• Reformuler de façon robotique ("Vous avez dit que...")
• Passer au code sans validation explicite
• S'activer quand l'utilisateur a déjà un plan clair