@atlashub/smartstack-cli 3.39.0 → 3.41.0

package/templates/skills/business-analyse/questionnaire/02-stakeholders.md

@@ -1,189 +1,189 @@
-# 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
+# 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