# Categorie 0 : Identite de l'application

> **Charge par :** step-01-cadrage.md (mode application uniquement) ou step-01b-applications.md (mode project)
> **Quand :** Toujours charge quand le mode est "application" (multi-module) ou "project" (multi-application)
> **Objectif :** Definir le cadre global de l'application avant d'entrer dans les details
>
> **Mode projet :** Si `workflow.mode === "project"`, certaines questions ont deja ete repondues au niveau projet (probleme, stakeholders, vision). Se concentrer sur l'identite specifique a cette application : nom, contexte, prefixe, roles specialises. Ne PAS re-demander les stakeholders et le probleme global.

---

## 0.1 L'application en quelques mots

> **But :** Comprendre rapidement de quoi il s'agit.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q0.1 | Quel nom donneriez-vous a cette application ? Un nom court et parlant qui la resumerait en un mot. | Nom de l'application |
| Q0.2 | En 2 a 3 phrases, quel est l'objectif principal de cette application ? A qui s'adresse-t-elle et quel probleme resout-elle ? | Description courte |

**Reformulation guidee pour Q0.1 :**
```
question: "Quel nom donneriez-vous a cette application ?"
header: "Application"
options:
  - label: "Gestion des ventes"
    description: "Suivi des clients, commandes, devis et facturation"
  - label: "Gestion des operations"
    description: "Pilotage de la logistique, des stocks et de la production"
  - label: "Ressources humaines"
    description: "Gestion du personnel, des conges et des formations"
  - label: "Gestion financiere"
    description: "Comptabilite, budget, tresorerie et rapports financiers"
```

---

## 0.2 Les grands domaines fonctionnels

> **But :** Identifier les grandes familles de fonctionnalites avant de les detailler.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q0.3 | Quels sont les grands domaines fonctionnels de cette application ? Par exemple : gestion des clients, suivi des commandes, facturation, tableau de bord... | Liste de domaines avec description courte |
| Q0.4 | Parmi ces domaines, lesquels sont indispensables pour un premier lancement ? Les autres suivront dans les versions suivantes. | Liste des domaines prioritaires |

**Reformulation guidee pour Q0.3 :**
```
question: "Quels sont les grands domaines fonctionnels de cette application ?"
header: "Domaines"
options:
  - label: "2 a 3 domaines"
    description: "Application ciblee sur quelques fonctions essentielles"
  - label: "4 a 6 domaines"
    description: "Application standard couvrant les principaux besoins"
  - label: "7 a 10 domaines"
    description: "Application complete couvrant un large perimetre"
  - label: "Plus de 10 domaines"
    description: "Application d'entreprise tres complete"
```

---

## 0.3 Les profils utilisateurs de l'application

> **But :** Definir les grands types d'acces a l'echelle de toute l'application.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q0.5 | Quels sont les grands profils d'utilisateurs de cette application ? Pensez en termes de "ce qu'ils font" et pas de titres de postes. | Liste de profils |
| Q0.6 | Certains profils n'ont-ils acces qu'a certains domaines ? Ou tout le monde voit tout ? | Regles de restriction par domaine |

**Reformulation guidee pour Q0.5 :**
```
question: "Quels profils d'utilisateurs voyez-vous pour cette application ?"
header: "Profils"
options:
  - label: "4 profils standards"
    description: "Administrateur (tout gerer), Responsable (superviser), Contributeur (travailler), Lecteur (consulter)"
  - label: "Adapter les noms"
    description: "Garder 4 niveaux d'acces mais avec des noms qui correspondent a votre organisation"
  - label: "Plus de profils"
    description: "Besoin de profils supplementaires comme Approbateur, Auditeur, Support..."
  - label: "Moins de profils"
    description: "Seulement 2 a 3 niveaux suffisent pour cette application"
```

---

## 0.4 Les processus qui traversent les domaines

> **But :** Identifier les flux de bout en bout qui impliquent plusieurs domaines.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q0.7 | Y a-t-il des processus metier qui traversent plusieurs domaines ? Par exemple : une commande qui va de la vente a la livraison puis a la facturation ? | Description des processus transversaux |
| Q0.8 | Quand un nouvel utilisateur rejoint l'equipe, quel profil d'acces recoit-il par defaut ? | Profil par defaut |

**Reformulation guidee pour Q0.7 :**
```
question: "Y a-t-il des processus metier qui traversent plusieurs domaines ?"
header: "Processus"
options:
  - label: "Oui, plusieurs processus"
    description: "Des enchainements impliquent 2 domaines ou plus (commande puis facturation puis livraison)"
  - label: "Oui, un processus principal"
    description: "Un grand flux traverse l'ensemble de l'application"
  - label: "Non, domaines independants"
    description: "Chaque domaine fonctionne de maniere autonome"
  - label: "A definir plus tard"
    description: "Les interactions seront identifiees au fil de l'analyse"
```

---

## Guide d'elicitation approfondi

### Techniques de relance

| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
|----------|----------------------------------------|---------------------|
| Q0.2 (objectif) | Description trop vague ("gerer les choses") | "Pouvez-vous completer la phrase : 'Grace a cette application, les utilisateurs pourront...' ?" |
| Q0.3 (domaines) | "On a besoin de tout" | "Si vous ne pouviez garder que 3 domaines pour le premier lancement, lesquels choisiriez-vous ?" |
| Q0.4 (priorites) | Tout est prioritaire | "Quel domaine apporte le plus de valeur immediatement ? Lequel peut fonctionner sans les autres ?" |
| Q0.5 (profils) | Confusion entre titres de poste et profils | "Oublions les titres. Parmi vos utilisateurs : qui fait la saisie au quotidien ? Qui valide ? Qui consulte ? Qui administre ?" |
| Q0.7 (processus transversaux) | "Pas de lien entre domaines" | "Quand une information est creee dans un domaine, un autre domaine en a-t-il besoin ? Par exemple, une vente declenche-t-elle une facture ?" |

### Signaux d'alerte a detecter

| Signal du client | Probleme sous-jacent | Action de l'analyste |
|------------------|---------------------|----------------------|
| Plus de 10 domaines pour une premiere version | **Ambition trop large** | Suggerer une approche par phases : domaines fondamentaux d'abord, extensions ensuite |
| "Tout est prioritaire" | **Pas de hierarchisation** | "Si vous aviez un budget pour 3 domaines seulement, lesquels choisiriez-vous en premier ?" |
| Confusion entre role organisationnel et acces | **Roles mal definis** | Separer : "le poste dans l'entreprise" (directeur, comptable) et "ce qu'il fait dans l'application" (consulter, modifier, administrer) |
| Un seul domaine qui fait tout | **Vision monolithique** | "Pourrait-on decouper ce domaine en sous-domaines independants ? Certains utilisateurs n'auraient-ils besoin que d'une partie ?" |

---

## Mapping vers le cadrage

| Reponse | Alimente |
|---------|----------|
| Q0.1, Q0.2 | `metadata.application`, `cadrage.problem` |
| Q0.3, Q0.4 | `modules[]` dans le fichier principal |
| Q0.5, Q0.6 | `cadrage.applicationRoles[]` |
| Q0.7 | `consolidation.e2eFlows[]` (rempli a l'etape 04) |
| Q0.8 | `cadrage.applicationRoles[].isDefault` |

---

## Strategie de questionnement

### Ordre des questions en 2 lots

**Lot 1 (Q0.1, Q0.2, Q0.3, Q0.4) : L'application et ses domaines**
- Definir l'identite et le perimetre global
- Hierarchiser les domaines pour le premier lancement

**Lot 2 (Q0.5, Q0.6, Q0.7, Q0.8) : Les profils et les processus**
- Etablir les grands profils d'acces
- Identifier les flux transversaux
