# Categorie 2 : Parties prenantes

> **Usage :** Identification de toutes les personnes concernees et de leurs besoins reels
> **Quand charger :** TOUJOURS (noyau)
> **Objectif :** Comprendre QUI utilise le systeme, COMMENT et POURQUOI

---

## 2.1 Identification des utilisateurs

> **But :** Dresser la carte complete de toutes les personnes qui interagiront avec le systeme.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q2.1 | Qui sont les personnes qui utiliseront ce systeme au quotidien ? Decrivez leurs postes et ce qu'ils font dans l'entreprise. | Liste de profils utilisateurs |
| Q2.2 | Y a-t-il des personnes qui ne l'utiliseront pas directement mais qui beneficieront des resultats (rapports, donnees, decisions) ? | Liste de beneficiaires indirects |
| Q2.3 | Qui est le decideur final sur ce projet ? Qui peut dire "oui, on lance" ou "non, on arrete" ? | Nom et role du decideur |
| Q2.4 | Y a-t-il des personnes ou des services qui pourraient s'opposer a ce projet ou le freiner ? Pourquoi ? | Liste de resistances potentielles |

**Reformulation guidee pour Q2.1 :**
```
question: "Qui sont les personnes qui utiliseront ce systeme au quotidien ?"
header: "Utilisateurs"
options:
  - label: "Equipe operationnelle"
    description: "Les personnes qui font le travail quotidien et saisissent les donnees"
  - label: "Responsables et managers"
    description: "Les personnes qui supervisent, valident et prennent des decisions"
  - label: "Direction"
    description: "Les personnes qui consultent les tableaux de bord et les indicateurs"
  - label: "Equipe support"
    description: "Les personnes qui aident les utilisateurs et resolvent les problemes"
```

---

## 2.2 Le quotidien de chaque utilisateur

> **But :** Comprendre concretement ce que chaque type d'utilisateur fait et a besoin de faire.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q2.5 | Pour chaque type d'utilisateur : quelles sont les 3 a 5 taches principales qu'il doit accomplir avec ce systeme ? | Taches par profil utilisateur |
| Q2.6 | A quelle frequence chaque utilisateur se servira-t-il du systeme ? Tous les jours ? Plusieurs fois par jour ? Une fois par semaine ? | Frequence d'utilisation par profil |
| Q2.7 | Quel est le niveau de confort de chaque utilisateur avec les outils informatiques ? Certains sont-ils plus a l'aise que d'autres ? | Niveau d'aisance par profil |
| Q2.8 | Pour chaque utilisateur : quelles sont ses 2 a 3 plus grandes frustrations avec la facon de travailler actuelle ? | Frustrations par profil |

**Reformulation guidee pour Q2.5 :**
```
question: "Quelles sont les taches principales de chaque type d'utilisateur ?"
header: "Taches"
options:
  - label: "Saisie et creation"
    description: "Creer de nouvelles fiches, saisir des informations, remplir des formulaires"
  - label: "Consultation et recherche"
    description: "Chercher des informations, consulter des fiches, verifier des donnees"
  - label: "Validation et approbation"
    description: "Verifier le travail des autres, approuver des demandes, valider des etapes"
  - label: "Suivi et reporting"
    description: "Suivre l'avancement, consulter des indicateurs, generer des rapports"
```

---

## 2.3 Les niveaux d'acces

> **But :** Definir qui peut voir quoi et faire quoi, en langage simple.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q2.9 | Tous les utilisateurs doivent-ils voir les memes informations ? Si non, qui voit quoi ? | Regles de visibilite des donnees |
| Q2.10 | Qui a le droit de modifier ou supprimer des informations ? Tout le monde ou seulement certaines personnes ? | Regles de modification |
| Q2.11 | Y a-t-il des actions sensibles qui necessitent une validation par un superieur avant d'etre executees (approbation, suppression, publication) ? | Liste des actions a valider |
| Q2.12 | Quand un nouvel utilisateur rejoint l'equipe, quel niveau d'acces doit-il avoir par defaut ? | Acces initial |

**Reformulation guidee pour Q2.9 :**
```
question: "Tous les utilisateurs voient-ils les memes informations ?"
header: "Visibilite"
options:
  - label: "Oui, tout est visible par tous"
    description: "Pas de restriction, tous les utilisateurs voient toutes les donnees"
  - label: "Non, selon le role"
    description: "Chaque role ne voit que les informations qui le concernent"
  - label: "Non, selon le service"
    description: "Chaque service ou equipe ne voit que ses propres donnees"
  - label: "C'est complexe"
    description: "Les regles de visibilite dependent de plusieurs criteres combines"
```

---

## 2.4 La conduite du changement

> **But :** Anticiper les resistances et planifier l'adoption.

| # | Question | Type de reponse |
|---|----------|-----------------|
| Q2.13 | Comment reagiront les utilisateurs face a ce changement ? Qui sera enthousiaste et qui sera reticent ? | Cartographie des attitudes |
| Q2.14 | Y a-t-il eu des tentatives precedentes de resoudre ce probleme ? Qu'est-ce qui a fonctionne ou echoue ? | Historique des initiatives passees |

---

## Guide d'elicitation approfondi

### Techniques de relance par question

| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
|----------|----------------------------------------|---------------------|
| Q2.1 (utilisateurs directs) | Un seul type d'utilisateur mentionne | "Pensez aux differents moments de la journee : qui intervient le matin pour la saisie ? Qui consulte les rapports l'apres-midi ? Qui gere les cas particuliers ? Y a-t-il un administrateur, un auditeur, ou un processus automatique ?" |
| Q2.2 (beneficiaires indirects) | "Personne d'autre" | "Quand une information est creee dans le systeme, qui en a besoin ensuite ? La direction consulte-t-elle des chiffres qui en dependent ? Un autre service attend-il des resultats ?" |
| Q2.4 (oppositions) | "Personne ne s'opposera" | "Quand un nouvel outil est introduit, qui doit changer ses habitudes le plus ? Cette personne est-elle favorable au changement ?" |
| Q2.5 (taches par role) | Taches generiques ("gerer les donnees") | "Prenons le role {role} : quand il arrive le matin et ouvre le systeme, quelle est sa premiere action ? Que fait-il ensuite ? A quel moment considere-t-il que sa tache est terminee ?" |
| Q2.6 (frequence) | "Regulierement" | "Combien de fois par jour ? Est-ce 3 fois par jour ou 30 fois ? Y a-t-il des periodes plus intenses que d'autres (debut de mois, fin d'annee) ?" |
| Q2.7 (aisance informatique) | "Ils se debrouillent" | "Si je donnais un nouveau logiciel a cet utilisateur sans formation, combien de temps lui faudrait-il pour etre autonome ? 5 minutes, 1 heure, une journee ?" |
| Q2.8 (frustrations) | "Rien de special" | "Quelle tache fait le plus soupirer vos equipes ? Quelle question posent-ils le plus souvent ? De quoi se plaignent-ils en pause cafe ?" |
| Q2.9 (visibilite) | Reponse ambigue | "Prenons un exemple : un employe du service A peut-il voir les donnees du service B ? Un stagiaire voit-il la meme chose qu'un directeur ?" |
| Q2.13 (changement) | "Ca ira" (trop optimiste) | "La derniere fois qu'un nouvel outil a ete introduit, comment ca s'est passe ? Certains utilisateurs l'ont-ils evite ou contourne ?" |

### Signaux d'alerte a detecter

| Signal du client | Probleme sous-jacent | Action de l'analyste |
|------------------|---------------------|----------------------|
| "Tous les utilisateurs font la meme chose" | **Roles non differencies** | "Qui peut supprimer une fiche ? Qui ne fait que consulter ? Qui valide le travail des autres ?" |
| Un seul type d'utilisateur identifie | **Parties prenantes manquantes** | Proposer systematiquement : administrateur, utilisateur quotidien, lecteur seul, auditeur, support technique |
| Melange entre titre de poste et niveau d'acces | **Confusion role metier et acces** | Separer : le role metier (chef de projet, comptable) ET son niveau d'acces (consultation, modification, administration) |
| "Tout le monde doit tout voir" | **Securite non reflechie** | "Meme les stagiaires ? Meme les prestataires externes ? Meme les donnees salariales ou financieres ?" |
| "Personne ne s'y opposera" | **Resistance sous-estimee** | "Quels utilisateurs devront changer le plus leurs habitudes ? Cette personne a-t-elle ete consultee ?" |

### Regles d'enchainement

| Apres | Si la reponse indique... | Alors |
|-------|-------------------------|-------|
| Q2.1 | Plus de 4 types d'utilisateurs | Approfondir Q2.5 par lots (2 roles par lot maximum) |
| Q2.4 | Resistances identifiees | Insister sur Q2.13-Q2.14 pour anticiper la conduite du changement |
| Q2.7 | Utilisateurs peu a l'aise | Prioriser les questions d'interface utilisateur (categorie 07) |
| Q2.9 | Regles de visibilite complexes | Charger le questionnaire de securite (categorie 06) en priorite |
| Q2.11 | Actions a valider identifiees | Noter pour la phase de specification : workflows d'approbation a modeliser |
| Q2.14 | Echecs passes | Comprendre les raisons d'echec pour ne pas les reproduire |

---

## Regle de mapping des roles vers les permissions

> **Important :** Les roles identifies ici sont des profils metier. Ils seront mappes
> vers des niveaux d'acces de la plateforme lors de la phase de specification.
>
> Cette correspondance est transparente pour le client. Il definit des profils
> en langage naturel, le systeme s'occupe de la traduction technique.

| Profil utilisateur decrit par le client | Niveau d'acces correspondant |
|-----------------------------------------|-----------------------------|
| "Il gere tout, c'est l'administrateur" | Administration complete |
| "Il supervise et valide" | Lecture, creation, modification, validation |
| "Il saisit et modifie au quotidien" | Lecture, creation, modification |
| "Il consulte les rapports" | Lecture seule |

---

## Mapping vers le cadrage

| Reponse | Alimente |
|---------|----------|
| Q2.1, Q2.2, Q2.3, Q2.4 | `cadrage.stakeholders[]` |
| Q2.5, Q2.6, Q2.7, Q2.8 | `cadrage.stakeholders[].tasks`, `.frequency`, `.painPoints` |
| Q2.9, Q2.10, Q2.11, Q2.12 | `cadrage.applicationRoles[]` |
| Q2.13, Q2.14 | `cadrage.risks[]` (risque adoption) |

---

## Strategie de questionnement

### Ordre des questions en 4 lots

**Lot 1 (Q2.1, Q2.2, Q2.3, Q2.4) : Qui est concerne ?**
- Identifier tous les acteurs du projet
- Ne pas oublier les beneficiaires indirects et les opposants potentiels

**Lot 2 (Q2.5, Q2.6, Q2.7, Q2.8) : Que font-ils au quotidien ?**
- Detailler les taches, frequences et frustrations par profil
- Si plus de 4 profils : traiter les 2 plus importants d'abord

**Lot 3 (Q2.9, Q2.10, Q2.11, Q2.12) : Qui a le droit de faire quoi ?**
- Etablir les regles de visibilite et de modification
- Identifier les actions sensibles necessitant validation

**Lot 4 (Q2.13, Q2.14) : Comment vont-ils reagir ?**
- Anticiper les resistances et tirer les lecons du passe
- Ce lot peut etre fusionne avec le lot 3 si le projet est simple
