@atlashub/smartstack-cli 2.9.0 → 3.0.0

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

@@ -1,69 +1,189 @@
-# Category 2: Stakeholders
+# Categorie 2 : Parties prenantes
 
-> **Usage:** Identification of stakeholders and their needs
-> **When to load:** ALWAYS (core)
+> **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
+## 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"
+```
 
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q2.1 | Who are the direct end users? | List of roles |
-| Q2.2 | Who are the indirect beneficiaries? | List |
-| Q2.3 | Who is the sponsor/final decision maker? | Name + role |
-| Q2.4 | Who can block the project? | List + reasons |
+---
+
+## 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.2 Needs by Role
+---
 
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q2.5 | For each role: What tasks should they accomplish? | Per role |
-| Q2.6 | What frequency of use per role? | Daily/Weekly/Monthly |
-| Q2.7 | What level of technical expertise per role? | Novice/Intermediate/Expert |
-| Q2.8 | What current frustrations per role? | List of pain points |
+## 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"
+```
 
 ---
 
-## Role -> Permission Mapping
+## 2.4 La conduite du changement
 
-> **⚠️ RBAC RULE: Roles are platform permissions, NOT entity attributes.**
->
-> When stakeholders mention "roles" (admin, manager, user...), these MUST be mapped
-> to the platform's RBAC permission system (`business.{app}.{module}.{action}`).
->
-> **NEVER** model a role as:
-> - A property/column on a User entity (e.g. `User.Role`, `User.RoleType`)
-> - An enum or string attribute on any business entity
-> - A separate `Role` entity with a FK on User
+> **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.
 >
-> **ALWAYS** map roles to permission sets in the matrix below:
+> Cette correspondance est transparente pour le client. Il definit des profils
+> en langage naturel, le systeme s'occupe de la traduction technique.
 
-| Discovered Role | Platform Permission |
-|-----------------|----------------------|
-| Admin | `*.admin` |
-| Manager | `*.read,create,update` |
-| User | `*.read,create` |
-| ReadOnly | `*.read` |
+| 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) |
+
+---
 
-> If the business need requires **custom roles beyond these 4**, document them
-> as additional permission sets — not as data model concepts.
+## Strategie de questionnement
 
-## Elicitation Guide
+### Ordre des questions en 4 lots
 
-### Follow-ups by Question
+**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
 
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q2.1 (end users) | Only 1-2 roles listed | "Y a-t-il des auditeurs, des administrateurs système, du support, des processus automatisés ?" |
-| Q2.5 (tasks per role) | Generic tasks ("manage data") | "Prenons le rôle {role} : en arrivant le matin, quelle est sa première action ? Et après ?" |
-| Q2.6 (frequency) | "Régulièrement" | "Quotidien ? 10 fois/jour ou 1 fois ? Certains jours plus que d'autres ?" |
-| Q2.8 (frustrations) | "Rien de particulier" | "Quel processus prend le plus de temps ? Qu'est-ce qui vous fait soupirer ?" |
+**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
 
-### Anti-patterns to Detect
+**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
 
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Un seul type d'utilisateur identifié | **Stakeholders manquants** | Proposer systématiquement : admin, utilisateur métier, lecteur, auditeur, support N1 |
-| "Tous les utilisateurs font la même chose" | **Rôles non différenciés** | "Qui peut supprimer ? Qui ne fait que consulter ? Qui valide ?" |
-| Mélange rôle organisationnel et accès | **Confusion rôle/permission** | Séparer : rôle métier (chef de projet) vs niveau d'accès (lecture/écriture) |
+**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

package/templates/skills/business-analyse/questionnaire/03-scope.md

@@ -1,58 +1,164 @@
-# Category 3: Functional Scope
+# Categorie 3 : Perimetre fonctionnel
 
-> **Usage:** Scope definition with priority levels
-> **When to load:** ALWAYS (core)
+> **Usage :** Definir ce que le systeme doit faire et ne pas faire, avec des priorites claires
+> **Quand charger :** TOUJOURS (noyau)
+> **Objectif :** Delimiter le perimetre et hierarchiser les fonctionnalites
 
 ---
 
-## 3.1 Functionality (Priority Levels)
+## 3.1 Les fonctionnalites attendues
 
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q3.1 | List ESSENTIAL features (Must-Have) | List |
-| Q3.2 | List DESIRED features (Should-Have) | List |
-| Q3.3 | List OPTIONAL features (Could-Have) | List |
-| Q3.4 | Any known constraints limiting scope? | List of constraints |
+> **But :** Lister tout ce que le systeme doit permettre de faire, puis hierarchiser.
 
-## 3.2 Business Process
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.1 | Listez toutes les fonctionnalites que vous souhaitez dans ce systeme. Ne vous censurez pas, notez tout ce qui vous vient a l'esprit. | Liste libre de fonctionnalites |
+| Q3.2 | Parmi cette liste, quelles sont les fonctionnalites INDISPENSABLES ? Celles sans lesquelles le systeme n'a aucun interet ? | Liste de fonctionnalites vitales |
+| Q3.3 | Quelles fonctionnalites seraient tres utiles mais pourraient attendre une deuxieme version si necessaire ? | Liste de fonctionnalites importantes |
+| Q3.4 | Y a-t-il des choses que le systeme ne doit explicitement PAS faire ? Des limites claires a poser ? | Liste d'exclusions |
 
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q3.5 | Describe the main user flow | Steps |
-| Q3.6 | What are the decision points in the flow? | List |
-| Q3.7 | What alternative flows exist? | Per condition |
-| Q3.8 | What are the possible error cases? | List |
+**Reformulation guidee pour Q3.2 :**
+```
+question: "Quelles fonctionnalites sont absolument indispensables ?"
+header: "Indispensable"
+options:
+  - label: "Creer et consulter les fiches"
+    description: "La base : pouvoir ajouter de nouvelles informations et les retrouver"
+  - label: "Suivre l'avancement"
+    description: "Voir ou en est chaque element, son statut et son historique"
+  - label: "Controler les acces"
+    description: "S'assurer que chaque personne ne voit et fait que ce qu'elle a le droit"
+  - label: "Generer des rapports"
+    description: "Produire des syntheses et des indicateurs pour la prise de decision"
+```
+
+**Test de priorite :**
+> Pour chaque fonctionnalite classee comme indispensable, poser la question :
+> "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?"
+> - Si la reponse est "non" : c'est bien indispensable
+> - Si la reponse est "oui, mais..." : c'est important mais pas vital
+
+---
+
+## 3.2 Le parcours principal
+
+> **But :** Comprendre le flux de travail principal de bout en bout.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.5 | Decrivez le parcours typique d'un utilisateur du debut a la fin : il ouvre le systeme, que fait-il en premier ? Puis ensuite ? Comment termine-t-il sa tache ? | Liste d'etapes ordonnees |
+| Q3.6 | A quels moments l'utilisateur doit-il prendre une decision ? Quelles sont les options possibles a chaque point de decision ? | Points de decision et options |
+| Q3.7 | Que se passe-t-il quand quelque chose ne se deroule pas comme prevu ? Quels sont les cas particuliers ou les exceptions ? | Scenarios alternatifs |
+| Q3.8 | Que se passe-t-il quand une erreur survient ? Comment l'utilisateur est-il informe ? Que doit-il faire pour corriger ? | Gestion des erreurs |
+
+**Reformulation guidee pour Q3.5 :**
+```
+question: "Decrivez le parcours typique d'un utilisateur du debut a la fin"
+header: "Parcours"
+options:
+  - label: "Saisie puis validation"
+    description: "L'utilisateur cree une fiche, un responsable la valide, elle est publiee"
+  - label: "Recherche puis action"
+    description: "L'utilisateur cherche une information, puis effectue une action dessus"
+  - label: "Reception puis traitement"
+    description: "Une demande arrive, l'utilisateur la traite etape par etape"
+  - label: "Suivi continu"
+    description: "L'utilisateur surveille un tableau de bord et intervient quand necessaire"
+```
+
+---
+
+## 3.3 Les besoins transversaux
+
+> **But :** Identifier les fonctionnalites qui traversent tout le systeme.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q3.9 | Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ? Si oui, dans quelles situations ? | Liste de situations de notification |
+| Q3.10 | Faut-il pouvoir exporter des donnees du systeme (rapports, fichiers, impressions) ? Dans quel format et pour qui ? | Besoins d'export |
+| Q3.11 | Faut-il pouvoir importer des donnees dans le systeme depuis une source externe (fichiers, autres logiciels) ? | Besoins d'import |
+| Q3.12 | Faut-il garder un historique de qui a fait quoi et quand ? Pour quelles actions ? | Besoins de tracabilite |
+
+**Reformulation guidee pour Q3.9 :**
+```
+question: "Les utilisateurs ont-ils besoin de recevoir des notifications ou des alertes ?"
+header: "Alertes"
+options:
+  - label: "Oui, en temps reel"
+    description: "Notifications instantanees quand quelque chose de nouveau arrive ou change"
+  - label: "Oui, par email"
+    description: "Recapitulatif par email quotidien ou a chaque evenement important"
+  - label: "Oui, les deux"
+    description: "Notification en temps reel dans l'application et recapitulatif par email"
+  - label: "Non, pas necessaire"
+    description: "Les utilisateurs consulteront le systeme de leur propre initiative"
+```
+
+---
+
+## Guide d'elicitation approfondi
+
+### Techniques de relance par question
+
+| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
+|----------|----------------------------------------|---------------------|
+| Q3.1 (liste de fonctionnalites) | Moins de 5 elements | "Pensez a une journee complete de travail. De l'ouverture de session a la fermeture, quelles actions devriez-vous pouvoir faire ? Creation ? Recherche ? Modification ? Exportation ? Suivi ?" |
+| Q3.2 (indispensable) | Tout est marque comme indispensable | "Si vous ne pouviez garder que 3 fonctionnalites pour un premier lancement, lesquelles choisiriez-vous ? Les autres sont tres importantes mais pourraient venir dans un second temps." |
+| Q3.4 (exclusions) | "Je ne vois pas" | "Certains utilisateurs pourraient-ils s'attendre a des fonctionnalites que vous ne souhaitez PAS inclure ? Par exemple : gestion financiere, messagerie integree, application mobile ?" |
+| Q3.5 (parcours principal) | Moins de 3 etapes | "Detaillons : l'utilisateur arrive sur l'ecran d'accueil. Que voit-il ? Ou clique-t-il ? Que remplit-il ? Que se passe-t-il quand il valide ? Qui est notifie ?" |
+| Q3.6 (decisions) | "Il n'y a pas vraiment de choix" | "A chaque etape, l'utilisateur peut-il annuler ? Revenir en arriere ? Sauvegarder en brouillon ? Deleguer a quelqu'un d'autre ?" |
+| Q3.7 (cas particuliers) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur n'a pas toutes les informations ? Si une donnee est incorrecte ? Si deux personnes modifient la meme fiche en meme temps ?" |
+| Q3.8 (erreurs) | "On verra" | "Prenons un exemple : l'utilisateur oublie un champ obligatoire. Le systeme le bloque ? L'avertit ? Le laisse continuer avec un rappel plus tard ?" |
+| Q3.9 (notifications) | Reponse vague | "Quand un element change de statut, qui doit etre prevenu ? Quand une action urgente est requise, comment l'utilisateur le sait-il aujourd'hui ?" |
+| Q3.12 (tracabilite) | "On ne sait pas" | "Si dans 6 mois quelqu'un demande 'Qui a modifie cette fiche et pourquoi ?', devez-vous pouvoir repondre ?" |
+
+### Signaux d'alerte a detecter
+
+| Signal du client | Probleme sous-jacent | Action de l'analyste |
+|------------------|---------------------|----------------------|
+| Tout est indispensable (> 10 elements vitaux) | **Priorites non definies** | Appliquer le test : "Si on enlevait cette fonctionnalite, le systeme aurait-il encore de la valeur ?" |
+| Aucune exclusion identifiee | **Perimetre non borne** | "Y a-t-il des aspects qui relevent d'un autre projet, d'un autre service, ou d'une version future ?" |
+| Parcours lineaire sans alternative | **Seul le cas ideal est decrit** | "Que se passe-t-il a l'etape X si la condition Y n'est pas remplie ? Si l'utilisateur change d'avis ?" |
+| Melange fonctionnel et technique | **Solution dans le perimetre** | Separer : "gerer les commandes" (ce que fait le systeme) est fonctionnel, "utiliser tel outil" (comment il le fait) est technique |
+| Fonctionnalites tres detaillees pour certains sujets et vagues pour d'autres | **Expertise inegale** | Approfondir les zones vagues : "Ce sujet semble moins detaille. Est-ce parce qu'il est moins important ou parce qu'il est moins bien connu ?" |
+
+### Regles d'enchainement
+
+| Apres | Si la reponse indique... | Alors |
+|-------|-------------------------|-------|
+| Q3.1 | Plus de 15 fonctionnalites | Passer plus de temps sur Q3.2 pour hierarchiser |
+| Q3.2 | Plus de 10 elements indispensables | Challenger chaque element avec le test de priorite |
+| Q3.5 | Parcours avec approbation | Charger les questions de workflow (categorie 11 cycle de vie) |
+| Q3.7 | Beaucoup de cas particuliers | Prevoir de la complexite dans l'estimation des modules |
+| Q3.9 | Notifications en temps reel souhaitees | Noter pour la specification : integration de notifications |
+| Q3.11 | Import de donnees existantes | Charger le questionnaire de migration (categorie 12) |
+| Q3.12 | Tracabilite requise | Noter pour la specification : journal d'activite |
 
 ---
 
-## Prioritization
-
-| Priority | Criterion |
-|----------|-----------|
-| Must | Without this feature, the module has no value — implement first |
-| Should | Brings significant value — implement right after Must items |
-| Could | Nice-to-have — implement if no technical blocker |
-| Won't | Out of scope for this feature — belongs to a different module or feature |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q3.1 (Must-Have) | > 10 items listed | "Si vous ne pouviez en garder que 3 à implémenter en premier, lesquels ? Les autres sont peut-être Should-Have." |
-| Q3.1 (Must-Have) | Mélange CRUD + complexe | "Le CRUD de base (liste, création, modification, suppression) est-il un Must, ou certaines actions sont Could ?" |
-| Q3.2 (Should-Have) | Vide | "Y a-t-il des fonctionnalités utiles mais moins critiques ? Export, filtres avancés, notifications ?" |
-| Q3.4 (limites) | Vide | "Y a-t-il des contraintes connues qui pourraient limiter le périmètre ? (budget, délai, dépendance)" |
-| Q3.5 (main flow) | < 3 étapes | "Détaillez : l'utilisateur arrive sur l'écran → que voit-il ? → que clique-t-il ? → que se passe-t-il ?" |
-| Q3.7 (alt flows) | "Il n'y en a pas" | "Que se passe-t-il si l'utilisateur annule ? S'il n'a pas la permission ? Si les données sont invalides ?" |
-| Q3.8 (errors) | Liste vide | "Que se passe-t-il si le réseau coupe ? Si un champ obligatoire manque ? Si un doublon existe ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Tout est Must-Have | **Scope non priorisé** | Appliquer le test : "Sans cette fonctionnalité, le module a-t-il ZÉRO valeur ?" |
-| Q3.4 pas de limite identifiée | **Scope à valider** | Le scope sera naturellement borné par les Must-Have/Should-Have. Vérifier que les Must-Have sont réalistes. |
-| Flow linéaire sans alternative | **Happy path uniquement** | "Que se passe-t-il au step X si la condition Y n'est pas remplie ?" |
-| Mélange fonctionnel/technique | **Solution dans le scope** | Séparer : "gérer les commandes" (fonctionnel) vs "utiliser Redis" (technique) |
+## Mapping vers le cadrage
+
+| Reponse | Alimente |
+|---------|----------|
+| Q3.1, Q3.2, Q3.3 | `cadrage.globalScope` (indispensable, important, optionnel, hors perimetre) |
+| Q3.4 | `cadrage.globalScope.outOfScope` |
+| Q3.5, Q3.6, Q3.7, Q3.8 | `cadrage.coverageMatrix` + base pour les cas d'utilisation |
+| Q3.9, Q3.10, Q3.11, Q3.12 | `cadrage.coverageMatrix` + detection de modules transversaux |
+
+---
+
+## Strategie de questionnement
+
+### Ordre des questions en 3 lots
+
+**Lot 1 (Q3.1, Q3.2, Q3.3, Q3.4) : Quoi et dans quel ordre ?**
+- Commencer par un brainstorming libre (Q3.1) puis hierarchiser
+- Bien definir les limites (Q3.4) pour eviter les derives
+
+**Lot 2 (Q3.5, Q3.6, Q3.7, Q3.8) : Comment ca se deroule ?**
+- Cartographier le parcours principal puis les variantes
+- Ne pas accepter un parcours uniquement ideal
+
+**Lot 3 (Q3.9, Q3.10, Q3.11, Q3.12) : Quels besoins transversaux ?**
+- Identifier les fonctionnalites qui traversent tout le systeme
+- Ces reponses orientent le choix des questionnaires conditionnels

package/templates/skills/business-analyse/questionnaire/10-documentation.md

@@ -23,7 +23,7 @@
 | Documentation module | `/documentation` (auto step-08) | React page intégrée via doc-data.ts + DocRenderer |
 | Swagger API | Automatic (Swashbuckle) | OpenAPI 3.0 |
 | User guide | Manual or AI | Markdown / PDF |
-| Release notes | `/gitflow:11-finish` | Changelog automatique |
+| Release notes | `/gitflow finish` | Changelog automatique |
 | ERD (schéma données) | `/documentation` skill | Mermaid diagram |
 
 ## Elicitation Guide

package/templates/skills/business-analyse/questionnaire/14-risk-assumptions.md

@@ -0,0 +1,135 @@
+# Categorie 14 : Risques et hypotheses
+
+> **Usage :** Identifier les risques du projet et les hypotheses non validees
+> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
+> **Objectif :** Anticiper ce qui pourrait mal tourner et valider les certitudes
+
+---
+
+## 14.1 Les risques identifies
+
+> **But :** Lister tout ce qui pourrait empecher le projet de reussir.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q14.1 | Quels sont les principaux risques que vous voyez pour ce projet ? Qu'est-ce qui pourrait mal tourner ? | Liste de risques |
+| Q14.2 | Parmi ces risques, lesquels auraient les consequences les plus graves si ils se realisaient ? | Hierarchisation par gravite |
+| Q14.3 | Pour chaque risque grave : avez-vous une idee de comment le prevenir ou le reduire ? | Mesures de mitigation |
+
+**Reformulation guidee pour Q14.1 :**
+```
+question: "Quels sont les principaux risques que vous voyez pour ce projet ?"
+header: "Risques"
+multiSelect: true
+options:
+  - label: "Adoption par les utilisateurs"
+    description: "Les utilisateurs pourraient ne pas vouloir changer leurs habitudes ou utiliser le nouveau systeme"
+  - label: "Qualite des donnees existantes"
+    description: "Les donnees actuelles sont incompletes, incorrectes ou dispersees dans plusieurs formats"
+  - label: "Complexite des regles metier"
+    description: "Certaines regles sont mal documentees, contradictoires ou connues uniquement par quelques personnes"
+  - label: "Dependances externes"
+    description: "Le projet depend de systemes, equipes ou decisions externes qui pourraient retarder ou bloquer"
+```
+
+---
+
+## 14.2 Les hypotheses a valider
+
+> **But :** Rendre explicites les certitudes non verifiees qui sous-tendent le projet.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q14.4 | Quelles hypotheses faites-vous sur le projet ? Qu'est-ce que vous tenez pour acquis sans l'avoir verifie ? | Liste d'hypotheses |
+| Q14.5 | Parmi ces hypotheses, lesquelles seraient les plus graves si elles se revelaient fausses ? | Hierarchisation par impact |
+| Q14.6 | Comment pourriez-vous verifier ces hypotheses avant que le projet avance trop loin ? | Methodes de validation |
+
+**Reformulation guidee pour Q14.4 :**
+```
+question: "Quelles hypotheses faites-vous sur ce projet sans les avoir verifiees ?"
+header: "Hypotheses"
+multiSelect: true
+options:
+  - label: "Les utilisateurs vont s'adapter"
+    description: "On suppose que les utilisateurs accepteront le changement sans difficulte"
+  - label: "Les donnees sont fiables"
+    description: "On suppose que les donnees existantes sont correctes et exploitables"
+  - label: "Le processus actuel est bien compris"
+    description: "On suppose que tout le monde decrit le processus de la meme facon"
+  - label: "Les besoins ne changeront pas"
+    description: "On suppose que le perimetre restera stable pendant le developpement"
+```
+
+---
+
+## 14.3 Les lecons du passe
+
+> **But :** Tirer parti des experiences precedentes pour eviter de reproduire les erreurs.
+
+| # | Question | Type de reponse |
+|---|----------|-----------------|
+| Q14.7 | Y a-t-il eu des projets similaires dans l'entreprise par le passe ? Qu'est-ce qui a fonctionne et qu'est-ce qui a echoue ? | Retour d'experience |
+| Q14.8 | Si ce projet devait echouer, quelle serait la raison la plus probable selon vous ? | Cause d'echec anticipee |
+
+**Reformulation guidee pour Q14.8 :**
+```
+question: "Si ce projet devait echouer, quelle serait la raison la plus probable ?"
+header: "Echec"
+options:
+  - label: "Perimetre trop ambitieux"
+    description: "Trop de fonctionnalites a developper, pas assez de temps ou de budget"
+  - label: "Resistance au changement"
+    description: "Les utilisateurs refusent de changer leurs habitudes de travail"
+  - label: "Regles metier mal comprises"
+    description: "Des malentendus sur le fonctionnement reel du metier"
+  - label: "Manque de disponibilite"
+    description: "Les personnes cles ne sont pas assez disponibles pour valider et tester"
+```
+
+---
+
+## Guide d'elicitation approfondi
+
+### Techniques de relance par question
+
+| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
+|----------|----------------------------------------|---------------------|
+| Q14.1 (risques) | "Je ne vois pas de risque" | "Pensez aux projets passes : qu'est-ce qui a coince ? Les delais ? L'adoption ? La qualite des donnees ? Les changements de priorite en cours de route ?" |
+| Q14.3 (mitigation) | "On verra quand ca arrivera" | "Si ce risque se realise dans 3 mois, que ferez-vous concretement ? Qui sera responsable de la resolution ?" |
+| Q14.4 (hypotheses) | "On ne fait pas d'hypotheses" | "Par exemple : est-on certain que tous les utilisateurs ont un ordinateur ? Que les donnees actuelles sont completes ? Que le processus est le meme dans tous les services ?" |
+| Q14.7 (passe) | "C'est le premier projet de ce type" | "Y a-t-il eu d'autres tentatives de numerisation ou de changement d'outil ? Meme dans un autre domaine ? Qu'est-ce qui s'est bien passe ?" |
+| Q14.8 (echec) | Refuse de repondre ou "ca ne va pas echouer" | "C'est une question difficile mais importante. Imaginons le pire scenario : qu'est-ce qui en serait la cause ? Cela nous aide a le prevenir." |
+
+### Signaux d'alerte a detecter
+
+| Signal du client | Probleme sous-jacent | Action de l'analyste |
+|------------------|---------------------|----------------------|
+| "Il n'y a aucun risque" | **Manque de recul ou deni** | Proposer des risques standards et demander lesquels pourraient s'appliquer |
+| "On ne fait pas d'hypotheses, c'est un fait" | **Certitude non questionnee** | "Comment le savez-vous ? Quand est-ce que cela a ete verifie pour la derniere fois ?" |
+| Risques uniquement techniques | **Vision incomplete** | Ajouter les dimensions humaines (adoption, formation), organisationnelles (disponibilite, politique) et metier (regles changeantes) |
+| Pas de lecon du passe | **Memoire organisationnelle absente** | Chercher aupres d'autres interlocuteurs qui etaient presents lors de projets anterieurs |
+
+---
+
+## Mapping vers le cadrage
+
+| Reponse | Alimente |
+|---------|----------|
+| Q14.1, Q14.2, Q14.3 | `cadrage.risks[]` |
+| Q14.4, Q14.5, Q14.6 | `cadrage.risks[]` (type: "assumption") |
+| Q14.7, Q14.8 | `cadrage.risks[]` (enrichissement avec contexte historique) |
+
+---
+
+## Strategie de questionnement
+
+### Ordre des questions en 2 lots
+
+**Lot 1 (Q14.1, Q14.2, Q14.3, Q14.4) : Risques et hypotheses**
+- Commencer par les risques visibles puis les hypotheses implicites
+- Hierarchiser par gravite et par probabilite
+
+**Lot 2 (Q14.5, Q14.6, Q14.7, Q14.8) : Validation et lecons**
+- Identifier comment verifier les hypotheses
+- Tirer les lecons des experiences passees
+- Terminer par la question difficile de l'echec potentiel