@atlashub/smartstack-cli 4.18.0 → 4.20.0

package/templates/skills/business-analyse/questionnaire/00-application.md

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

package/templates/skills/business-analyse/questionnaire/00b-project.md

@@ -1,85 +0,0 @@
-# Questionnaire Category 00b: Project-Level Questions
-
-> **Loaded by:** step-01-cadrage (when multi-application mode detected)
-> **Condition:** Only loaded when user confirms "Multiple applications"
-> **Purpose:** Gather project-level information that spans all applications
-
----
-
-## Questions
-
-### Q0b.1: Project Name
-```
-question: "{language == 'fr' ? 'Quel nom souhaitez-vous donner au projet global ?' : 'What name would you like for the overall project?'}"
-header: "Projet"
-options:
-  - label: "{suggested_project_name}"
-    description: "{language == 'fr' ? 'Nom suggéré basé sur votre description' : 'Suggested name based on your description'}"
-  - label: "{language == 'fr' ? 'Personnaliser' : 'Customize'}"
-    description: "{language == 'fr' ? 'Choisir un autre nom' : 'Choose another name'}"
-```
-
-### Q0b.2: Deployment Model
-```
-question: "{language == 'fr' ? 'Comment ces applications seront-elles déployées ?' : 'How will these applications be deployed?'}"
-header: "Déploiement"
-options:
-  - label: "{language == 'fr' ? 'Ensemble' : 'Together'}"
-    description: "{language == 'fr' ? 'Toutes les applications sont déployées en même temps' : 'All applications deployed at the same time'}"
-  - label: "{language == 'fr' ? 'Par phases' : 'Phased'}"
-    description: "{language == 'fr' ? 'Chaque application est livrée séparément, par priorité' : 'Each application delivered separately, by priority'}"
-```
-
-### Q0b.3: Cross-Application Data Flows
-```
-question: "{language == 'fr' ? 'Existe-t-il des flux de données entre les applications identifiées ?' : 'Are there data flows between the identified applications?'}"
-header: "Flux"
-options:
-  - label: "{language == 'fr' ? 'Oui, plusieurs' : 'Yes, several'}"
-    description: "{language == 'fr' ? 'Des données sont partagées entre applications (ex: employés RH utilisés par le self-service)' : 'Data is shared between applications (e.g., HR employees used by self-service)'}"
-  - label: "{language == 'fr' ? 'Quelques liens' : 'A few links'}"
-    description: "{language == 'fr' ? 'Peu de dépendances entre applications' : 'Few dependencies between applications'}"
-  - label: "{language == 'fr' ? 'Indépendantes' : 'Independent'}"
-    description: "{language == 'fr' ? 'Les applications sont autonomes, pas de données partagées' : 'Applications are autonomous, no shared data'}"
-```
-
-### Q0b.4: Global vs Per-Application Roles
-```
-question: "{language == 'fr' ? 'Les rôles utilisateur sont-ils partagés entre applications ?' : 'Are user roles shared across applications?'}"
-header: "Rôles"
-options:
-  - label: "{language == 'fr' ? 'Rôles globaux' : 'Global roles'}"
-    description: "{language == 'fr' ? 'Les mêmes rôles (admin, manager...) s'appliquent à toutes les applications' : 'Same roles (admin, manager...) apply to all applications'}"
-  - label: "{language == 'fr' ? 'Rôles spécifiques' : 'Specific roles'}"
-    description: "{language == 'fr' ? 'Chaque application a ses propres rôles (ex: RH Admin vs Employee)' : 'Each application has its own roles (e.g., HR Admin vs Employee)'}"
-  - label: "{language == 'fr' ? 'Mixte' : 'Mixed'}"
-    description: "{language == 'fr' ? 'Certains rôles sont globaux, d'autres spécifiques à une application' : 'Some roles are global, others are application-specific'}"
-```
-
-### Q0b.5: Shared Infrastructure
-```
-question: "{language == 'fr' ? 'Quelles infrastructures partagées doivent être prises en compte ?' : 'What shared infrastructure needs to be considered?'}"
-header: "Infra"
-multiSelect: true
-options:
-  - label: "SSO / Auth"
-    description: "{language == 'fr' ? 'Authentification unique entre applications' : 'Single sign-on between applications'}"
-  - label: "Notifications"
-    description: "{language == 'fr' ? 'Service de notification partagé (email, in-app)' : 'Shared notification service (email, in-app)'}"
-  - label: "{language == 'fr' ? 'Base de données partagée' : 'Shared database'}"
-    description: "{language == 'fr' ? 'Toutes les applications partagent la même base de données' : 'All applications share the same database'}"
-  - label: "{language == 'fr' ? 'Aucune' : 'None'}"
-    description: "{language == 'fr' ? 'Chaque application est autonome' : 'Each application is autonomous'}"
-```
-
----
-
-## Mapping to Project Feature.json
-
-| Question | Target Field |
-|----------|-------------|
-| Q0b.1 | `metadata.projectName` |
-| Q0b.2 | `cadrage.deploymentModel` |
-| Q0b.3 | Informs `applicationDependencyGraph.edges[]` |
-| Q0b.4 | Informs `cadrage.globalRoles[]` vs per-app `applications[].applicationRoles[]` |
-| Q0b.5 | `cadrage.sharedInfrastructure[]` |

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

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

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

@@ -1,164 +0,0 @@
-# Categorie 3 : Perimetre fonctionnel
-
-> **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 Les fonctionnalites attendues
-
-> **But :** Lister tout ce que le systeme doit permettre de faire, puis hierarchiser.
-
-| # | 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 |
-
-**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 |
-
----
-
-## 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