# Catégorie 2 : Parties prenantes et périmètre

> **Usage :** Identifier les profils utilisateurs, leurs droits, et délimiter le périmètre fonctionnel
> **Quand charger :** TOUJOURS (noyau)
> **Objectif :** Comprendre QUI utilise le système, avec quels DROITS, et QUOI il doit faire

---

## 2.1 Identification des utilisateurs

> **But :** Identifier les types de profils/rôles qui interagiront avec le système.

| # | Question | Type de réponse |
|---|----------|-----------------|
| Q2.1 | Qui sont les types de profils qui utiliseront ce système ? Décrivez leurs rôles et ce qu'ils font. | Liste de profils utilisateurs |

---

## 2.2 Tâches par profil

> **But :** Comprendre concrètement ce que chaque type d'utilisateur fait.

| # | Question | Type de réponse |
|---|----------|-----------------|
| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 à 5 tâches principales qu'il doit accomplir avec ce système ? | Tâches par profil utilisateur |

---

## 2.3 Les niveaux d'accès

> **But :** Définir les règles métier de permissions par rôle (SmartStack gère nativement RBAC + isolation tenant).
> **Note :** Ne PAS demander le modèle de visibilité (cloisonné, tout visible, etc.) — SmartStack utilise toujours RBAC avec isolation tenant. Se concentrer sur les RÈGLES MÉTIER : quel rôle accède à quoi.

| # | Question | Type de réponse |
|---|----------|-----------------|
| Q2.9 | Pour chaque profil identifié, quelles données ou sections doivent lui être restreintes ? Y a-t-il des données sensibles visibles uniquement par certains rôles ? | Restrictions par rôle |
| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Règles de modification |
| Q2.11 | Y a-t-il des actions sensibles qui nécessitent une validation par un supérieur ? | Liste des actions à valider |

---

## 2.4 Limites du périmètre (OBLIGATOIRE)

> **But :** Borner ce que le système ne doit PAS faire. Essentiel pour eviter le scope creep.

| # | Question | Type de réponse |
|---|----------|-----------------|
| Q2.15 | Y a-t-il des choses que le système ne doit explicitement PAS faire ? Des limites claires à poser ? | Liste d'exclusions |

> **Note :** La detection des fonctionnalites IN-SCOPE est couverte par la reformulation (phase 2 de step-01).
> L'IA detecte les modules depuis le brief + domain research et les presente pour validation.
> Il n'est donc plus necessaire de demander au client de lister ses features (ex-Q2.12) ni de les classifier (ex-Q2.13).

---

## 2.5 Parcours principal (DEPLACE vers step-03)

> **IMPORTANT :** Les questions Q2.16 (parcours), Q2.17 (decisions), Q2.18 (erreurs) ont ete **deplacees vers step-03-specify**.
> Elles alimentent directement les use cases par module et evitent la duplication cadrage → specification.
> En step-01, le parcours est capture dans la reformulation : "Le parcours type que j'ai compris est X → Y → Z. Correct ?"

---

## 2.6 Intégrations et systèmes externes (CONDITIONNEL)

> **But :** Identifier les échanges de données avec l'extérieur et les migrations initiales.
> **Condition :** Poser UNIQUEMENT si le brief mentionne un systeme externe, une integration, une migration ou un import de donnees.
> Si non pertinent : `cadrage.externalIntegrations = []` et `cadrage.dataImport = null` (auto-rempli).

| # | Question | Type de réponse |
|---|----------|-----------------|
| Q2.19 | Ce système doit-il échanger des données avec d'autres outils ? (comptabilité, email, banque, API tierces) | Liste d'intégrations |
| Q2.20 | Y a-t-il des données existantes à importer lors du démarrage ? (Excel, ancien système) | Description import |

- Mapping → `cadrage.json` : champs `externalIntegrations[]` et `dataImport`

---

## Guide d'élicitation approfondi

### Techniques de relance

| Question | Si la réponse est vague | Relance recommandée |
|----------|------------------------|---------------------|
| Q2.1 (utilisateurs) | Un seul type mentionné | "Pensez aux différents moments de la journée : qui saisit ? Qui consulte les rapports ? Qui gère les cas particuliers ?" |
| Q2.1 (utilisateurs) | Utilisateurs hors entreprise mentionnés (clients, fournisseurs, partenaires) | "Quelles données ces utilisateurs externes doivent-ils consulter ou créer ? Quelles restrictions par rapport aux internes ?" |
| Q2.5 (tâches) | Tâches génériques | "Quand il arrive le matin et ouvre le système, quelle est sa première action ?" |
| Q2.9 (restrictions) | Réponse ambiguë | "Un employé voit-il les données salariales ? Un manager voit-il uniquement son équipe ou toute l'entreprise ?" |
| Q2.15 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre à des fonctionnalités que vous ne souhaitez PAS inclure ?" |

### Signaux d'alerte à détecter

| Signal du client | Problème sous-jacent | Action de l'analyste |
|------------------|---------------------|----------------------|
| "Tous les utilisateurs font la même chose" | Rôles non différenciés | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
| "Tout le monde doit tout voir" | Restrictions non définies | "Quelles données sont sensibles ? Un manager voit-il les données de toutes les équipes ou seulement la sienne ?" |
| Aucune exclusion identifiée | Périmètre non borné | "Y a-t-il des aspects qui relèvent d'un autre projet ou d'une version future ?" |
| "Nos clients doivent pouvoir..." ou "Les fournisseurs voient..." | Utilisateurs externes accédant au système | Classifier auto en 4b-bis. Approfondir les RÈGLES MÉTIER : quelles données, quelles actions, quelles restrictions ? |

---

## Mapping vers le cadrage

| Réponse | Alimente | Remplissage |
|---------|----------|-------------|
| Q2.1, Q2.5 | `cadrage.stakeholders[]` | Reponse directe |
| Q2.9-Q2.11 | `cadrage.applicationRoles[]` | Reponse directe |
| Q2.15 | `cadrage.globalScope.excluded` | Reponse directe |
| Q2.19, Q2.20 | `cadrage.externalIntegrations[]`, `cadrage.dataImport` | Reponse directe OU auto-rempli (vide) si non pertinent |
| (reformulation) | `cadrage.globalScope.inScope` | Auto-deduit depuis brief + domain research, confirme en phase 2 |
| (step-03) | `cadrage.coverageMatrix` | Construit lors de la specification des use cases |
