# Business Analysis - Elicitation & Interaction (_elicitation.md)

> **Loaded by:** step-01-cadrage, step-03a-data
> **Purpose:** Interactive questioning techniques, AskUserQuestion formatting, ULTRATHINK mode

---

## Interactive Elicitation Protocol

> **RULE: ALL questions MUST be asked interactively using `AskUserQuestion`.**
> **NEVER dump a list of questions as text. ALWAYS use the tool.**

### Protocol

1. **Group questions by theme** — max 4 questions per `AskUserQuestion` call (tool limit)
2. **Propose predefined options** — for questions with predictable answers, provide 2-4 options
3. **The user can always choose "Other"** — the tool adds this automatically for free-text answers
4. **Process answers immediately** — apply ULTRATHINK + follow-ups before moving to next group
5. **Adapt next questions** — based on previous answers, skip irrelevant questions

### Batching Strategy

| Category | Questions | Batches |
|----------|-----------|---------|
| 01-context | Q1.1-Q1.4 | 1 call |
| 02-stakeholders | Q2.1-Q2.8 | 2 calls |
| 03-scope | Q3.1-Q3.8 | 2 calls |
| 04-data | Q4.1-Q4.8 | 2 calls |
| 05-integrations | Q5.1-Q5.8 | 2 calls |
| 06-security | Q6.1-Q6.8 | 2 calls |
| 07-ui | Q7.1-Q7.8 | 2 calls |
| 08-performance | Q8.1-Q8.4 | 1 call |
| 09-constraints | Q9.1-Q9.4 | 1 call |
| 10-documentation | Q10.1-Q10.4 | 1 call |
| 11-data-lifecycle | Q11.1-Q11.8 | 2 calls |
| 12-migration | Q12.1-Q12.8 | 2 calls |
| 13-cross-module | Q13.1-Q13.8 | 2 calls |

### AskUserQuestion Format

> **FORMATTING CRITICAL: `AskUserQuestion` does NOT support markdown or line breaks.**
> Le champ `question` est rendu en texte brut (plain text). Il n'y a pas de retour a la ligne,
> pas de gras, pas de puces. Une question simple reste lisible meme longue. Mais du contenu
> structure (listes, resumes multi-points, tableaux) devient un mur de texte illisible.

| Field | Rule |
|-------|------|
| `question` | **1 question ou 1 phrase.** Jamais de liste, resume multi-points ou contenu structure. |
| `header` | 1-2 mots (max 12 chars) |
| `label` (option) | Court et clair (~20 chars) |
| `description` (option) | 1 phrase explicative (~60 chars) |

> **Pour afficher du contenu structure** (resumes, listes, tableaux, syntheses) :
> **TOUJOURS** utiliser du **texte direct** (output text) AVANT l'appel `AskUserQuestion`.
> Le texte direct supporte le markdown et sera correctement formate avec titres, puces, gras, etc.
>
> **Exemple — Validation de synthese :**
> 1. Afficher le resume structure en markdown (texte direct)
> 2. Puis poser une question courte : "Cette synthese est-elle correcte ?"

```
AskUserQuestion({
  questions: [
    {
      question: "Quel probleme metier ce module doit-il resoudre ?",
      header: "Probleme",       // max 12 chars
      options: [
        { label: "Processus manuel", description: "Automatiser un processus existant fait manuellement" },
        { label: "Donnees dispersees", description: "Centraliser des donnees eparpillees dans plusieurs outils" },
        { label: "Manque visibilite", description: "Obtenir des indicateurs et du suivi inexistants aujourd'hui" },
        { label: "Conformite", description: "Repondre a une obligation reglementaire ou de securite" }
      ],
      multiSelect: false
    },
    // ... up to 4 questions per call
  ]
})
```

### After Each Batch

1. **Evaluate answer quality** (see Answer Quality Indicators)
2. **If insufficient** -> follow-up AskUserQuestion with targeted probes from the Elicitation Guide
3. **If solution-oriented** -> reframe using Technique 1 before proceeding
4. **If sufficient/excellent** -> record and move to next batch
5. **Summarize** what was understood before moving to the next category

---

## Techniques d'elicitation

> **Objectif :** Guider COMMENT questionner, pas seulement QUOI demander.
> **Principe :** Chaque technique doit etre appliquee naturellement dans le flux de la conversation,
> pas comme un outil supplementaire. L'analyste choisit la technique adaptee a la situation.

### Technique 1 : Reformulation du besoin

Quand le client decrit une **solution** (bouton, ecran, champ, outil), reformuler en **besoin** :

| Le client dit | L'analyste demande |
|---------------|-------------------|
| "Il me faut un menu deroulant pour les roles" | "Quel probleme rencontrez-vous aujourd'hui avec la gestion des acces ? Pourquoi certaines personnes doivent-elles avoir des acces differents ?" |
| "On a besoin d'un bouton d'export" | "Que faites-vous avec les donnees une fois exportees ? Qui en a besoin et pourquoi ?" |
| "Ajoutez un champ statut" | "Quel parcours suit cet element du debut a la fin ? Quels evenements declenchent un changement d'etat ?" |

### Technique 2 : Chaine des pourquoi

Quand le besoin semble superficiel, enchainez jusqu'a 5 "Pourquoi ?" pour trouver la cause racine :

```
Client : "On a besoin de suivre l'activite des utilisateurs"
-> Pourquoi ? "Pour savoir qui a modifie quoi"
-> Pourquoi ? "Parce qu'on a eu des problemes de donnees incorrectes"
-> Pourquoi ? "Parce que plusieurs personnes modifient les memes fiches"
-> CAUSE RACINE : Conflit d'edition simultanee -> Besoin de journal d'activite + protection des modifications
```

### Technique 3 : Extraction de scenario concret

Ne jamais accepter de descriptions abstraites. Toujours demander un **scenario de vie reelle** :

```
"Racontez-moi une journee type : vous arrivez au bureau, vous ouvrez l'application.
 Quelle est la PREMIERE chose que vous devez faire ?
 Puis ensuite ? Quelles informations consultez-vous ? Quelles decisions prenez-vous ?"
```

### Technique 4 : Test d'absence

Valider la necessite en demandant ce qui se passe SANS :

```
"Si cette fonctionnalite N'EXISTAIT PAS, que feriez-vous a la place ?
 Combien de temps ou d'argent le contournement actuel coute-t-il ?"
```

### Technique 5 : Verification de completude

Pour chaque reponse sous forme de liste, verifier qu'il ne manque rien :

| Type de reponse | Relance |
|-----------------|---------|
| "Il y a 3 types d'utilisateurs" | "Y a-t-il des acteurs externes ? Des auditeurs ? Des administrateurs systeme ? Des processus automatiques ?" |
| "Le flux principal est A puis B puis C" | "Que se passe-t-il si l'utilisateur annule a l'etape B ? Si l'etape C echoue ? S'il veut revenir a A ?" |
| "Champs obligatoires : nom et email" | "Quelles contraintes d'unicite ? Quel format ? Que se passe-t-il en cas de doublon ?" |

### Technique 6 : Projection dans le futur

Demander au client de se projeter pour decouvrir des besoins non exprimes :

```
"Imaginons que nous sommes 2 ans dans le futur et que l'application fonctionne parfaitement.
 Qu'est-ce qui a change dans votre facon de travailler ?
 Quels nouveaux besoins sont apparus auxquels vous ne pensez pas aujourd'hui ?"
```

### Technique 7 : Test de contradiction

Quand deux reponses semblent contradictoires, les confronter pour clarifier :

```
"Vous avez mentionne que [affirmation A], mais vous dites aussi que [affirmation B].
 Ces deux elements semblent en tension. Pouvez-vous m'aider a comprendre
 comment ils coexistent dans la realite ?"
```

### Technique 8 : Escalade d'impact

Augmenter progressivement l'echelle pour tester les limites :

```
"Aujourd'hui vous avez 50 fiches. Que se passe-t-il avec 500 ? Avec 5000 ?
 Est-ce que le processus reste le meme ou faudrait-il faire differemment ?"
```

### Indicateurs de qualite des reponses

| Qualite | Signal | Action |
|---------|--------|--------|
| **Insuffisante** | Moins d'une phrase, "je ne sais pas", adjectif vague | Appliquer les techniques 1 a 8, demander un exemple concret |
| **Orientee solution** | Contient des termes d'interface ou techniques (bouton, champ, base de donnees) | Appliquer la technique 1 (reformuler en besoin) |
| **Suffisante** | Contient QUI, QUOI, POURQUOI et un exemple concret | Continuer, noter le niveau de confiance |
| **Excellente** | Inclut les cas limites, les contraintes et des criteres mesurables | Continuer, marquer comme "Confirme" |

---

## ULTRATHINK

Behavioral mode for critical phases (01, 03a):

```
ULTRATHINK MODE:
- Consider ALL edge cases
- Challenge EVERY assumption
- Anticipate UNEXPRESSED needs
- Validate completeness before output
- Apply Elicitation Techniques (see above)

DO NOT:
- Accept vague answers
- Skip question categories
- Assume stakeholder thought of everything
- Accept solutions without understanding the problem first
```

**DO NOT invoke** as a skill/tool - it is a thinking mode.
