@atlashub/smartstack-cli 4.17.1 → 4.19.0

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

package/templates/skills/business-analyse/questionnaire/04-data.md

@@ -1,88 +0,0 @@
-# Category 4: Data
-
-> **Usage:** Definition of entities and data rules
-> **When to load:** If feature is data-centric or full module
-
----
-
-## 4.1 Entities
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.1 | What are the main entities handled? | List |
-| Q4.2 | For each entity: important attributes? | Per entity |
-| Q4.3 | What relationships exist between entities? | Text schema |
-| Q4.4 | Expected data volume? | Estimation |
-| Q4.4b | For each entity: should the Code be auto-generated or user-provided? | Per entity |
-| Q4.4c | If auto-generated: what strategy? (sequential, daily timestamp, yearly, UUID short) | Per entity |
-| Q4.4d | What prefix represents this entity? (2-6 lowercase letters, e.g., emp, inv) | Per entity |
-
-## 4.2 Data Rules
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q4.5 | What validations on data? | List of rules |
-| Q4.6 | Which fields are required vs optional? | Per field |
-| Q4.7 | What specific formats/constraints? | List |
-| Q4.8 | Sensitive data to protect? | List + level |
-
----
-
-## Technical Mapping
-
-| Business Concept | Platform |
-|-----------------|------------|
-| Main entity | Domain Entity |
-| Required attribute | `[Required]` |
-| Unique attribute | `HasIndex().IsUnique()` |
-| 1:N relationship | Navigation property |
-| Sensitive data | Encryption + audit |
-| Code auto-generation | `ICodeGenerator<T>.NextCodeAsync()` with retry — see `apex/references/code-generation.md` |
-| Code pattern config | `analysis.entities[].codePattern` in feature.json |
-
-> **⚠️ RBAC EXCLUSION: The following concepts are handled by the platform's RBAC system
-> and MUST NOT be modeled as entity attributes or separate entities:**
->
-> | Concept | ❌ Wrong (entity attribute) | ✅ Correct (RBAC) |
-> |---------|---------------------------|-------------------|
-> | User role | `User.Role` property | Permission set `{app}.{module}.*` |
-> | Access level | `User.AccessLevel` enum | Permission matrix per role |
-> | Is admin | `User.IsAdmin` boolean | `{app}.{module}.admin` permission |
-> | Can edit | `User.CanEdit` boolean | `{app}.{module}.update` permission |
->
-> When Q4.2 asks for "important attributes", **exclude** any role/permission/access concept.
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q4.1 (entities) | Single entity listed | "Cette entité a-t-elle des sous-éléments ? (lignes de commande, pièces jointes, historique)" |
-| Q4.1 (entities) | Mentions "User" as entity | "L'utilisateur est géré par la plateforme (Identity). Décrivez plutôt l'entité MÉTIER (Client, Employee, Contact...)" |
-| Q4.2 (attributes) | Liste de champs techniques (ID, CreatedDate) | "Les champs techniques (Id, TenantId, audit) sont auto-gérés. Quels sont les attributs MÉTIER ?" |
-| Q4.3 (relationships) | "1:N" without detail | "Un {Parent} peut avoir combien de {Children} max ? Un {Child} peut-il exister sans {Parent} ?" |
-| Q4.4 (volume) | "Beaucoup" | "Ordre de grandeur : dizaines, centaines, milliers, millions ? Croissance par mois ?" |
-| Q4.4b (code pattern) | "User enters the code" or no answer | "Le code doit-il suivre un format spécifique ? (numéro séquentiel, date, combinaison ?)" |
-| Q4.4c (code strategy) | No answer | Propose strategy based on entity type: invoices/orders → timestamp-daily, employees/customers → sequential, references/categories → uuid-short, contracts → year-sequential, tickets → timestamp-minute |
-| Q4.4d (code prefix) | Too long or ambiguous | "Le préfixe est limité à 2-6 lettres minuscules. Exemple : 'emp' pour Employee, 'inv' pour Invoice, 'ctr' pour Contract." |
-| Q4.5 (validations) | Validations basiques seulement | "Y a-t-il des règles inter-champs ? (date fin > date début, montant selon statut)" |
-| Q4.8 (sensitive) | "Non" | "Pas de données personnelles (nom, email, téléphone) ? Pas de données financières ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Entity "User" avec attributs métier | **Confusion User/Identity** | La plateforme gère les Users via Identity. L'entité métier = Client, Employee, Contact |
-| Attributs Id, TenantId, CreatedBy listés | **Champs techniques comme métier** | Ces champs sont auto-générés par `AuditableEntity`. Ne pas les lister. |
-| Pas de soft delete mentionné | **Suppression non clarifiée** | "Les données supprimées sont-elles effacées définitivement ou archivées ?" → `SoftDeletableEntity` |
-| Aucune contrainte d'unicité | **Unicité non vérifiée** | "Deux entités peuvent-elles avoir le même nom/code/email ?" |
-
-### Entity Patterns
-
-| Besoin métier | Base class plateforme | Inclut automatiquement |
-|---------------|----------------------|----------------------|
-| Entité simple | `Entity` | Id, TenantId |
-| Avec audit | `AuditableEntity` | + CreatedBy, CreatedDate, ModifiedBy, ModifiedDate |
-| Avec suppression logique | `SoftDeletableEntity` | + IsDeleted, DeletedBy, DeletedDate |
-| Avec hiérarchie | `HierarchicalEntity` | + ParentId, Level, Path |

package/templates/skills/business-analyse/questionnaire/05-integrations.md

@@ -1,58 +0,0 @@
-# Category 5: Integrations
-
-> **Usage:** Connections with internal and external systems
-> **When to load:** If feature involves integrations
-
----
-
-## 5.1 Existing Systems
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.1 | What internal systems should we integrate with? | List |
-| Q5.2 | What external systems? | List |
-| Q5.3 | Existing APIs to use? | Documentation |
-| Q5.4 | Data to import from another system? | List + format |
-
-## 5.2 Data Flows
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q5.5 | Flow direction? (inbound/outbound/bidirectional) | Per system |
-| Q5.6 | Synchronization frequency? | Real-time/Batch |
-| Q5.7 | Data conflict management? | Strategy |
-| Q5.8 | Fallback if external system unavailable? | Behavior |
-
----
-
-## Integration Patterns
-
-| Integration Type | Pattern | When to use |
-|-----------------|---------|-------------|
-| REST API | HttpClient + Polly | Appel synchrone à un service externe avec retry/circuit-breaker |
-| Message Queue | MassTransit | Communication asynchrone entre modules/services |
-| Webhook | Controller endpoint | Réception d'événements depuis un système externe |
-| Real-time | SignalR | Notifications temps réel vers le navigateur |
-| Batch import | Background job (Hangfire) | Import/traitement de gros volumes en arrière-plan |
-| File storage | Azure Blob / local | Upload/download de documents et pièces jointes |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q5.1 (internal) | "Aucun" | "Ce module doit-il notifier d'autres modules ? Lire des données d'un autre contexte ?" |
-| Q5.2 (external) | "Aucun" | "Pas d'envoi d'emails ? Pas de connexion ERP, CRM, comptabilité ? Pas de SSO externe ?" |
-| Q5.3 (APIs) | "Oui il y a une API" | "Avez-vous la documentation (Swagger/OpenAPI) ? Quel format (REST/SOAP/GraphQL) ? Auth (API key, OAuth) ?" |
-| Q5.6 (frequency) | "Temps réel" | "Temps réel = chaque seconde (SignalR) ou à chaque modification (event-driven) ? Quelle latence acceptable ?" |
-| Q5.7 (conflicts) | "Pas de conflits" | "Si le système externe envoie une donnée qui existe déjà, on écrase, on ignore ou on signale ?" |
-| Q5.8 (fallback) | "Ça ne devrait pas arriver" | "Si le service est down 1h, que fait l'utilisateur ? File d'attente, mode dégradé, retry ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Intégration synchrone pour tout | **Couplage fort** | Si l'autre système peut être lent/down, proposer pattern asynchrone (MassTransit) |
-| "On verra plus tard pour l'intégration" | **Intégration non planifiée** | Documenter minimum : système cible, direction du flux, format attendu |
-| Pas de stratégie d'erreur | **Pas de résilience** | Toute intégration externe DOIT avoir un fallback (Polly retry + circuit breaker) |

package/templates/skills/business-analyse/questionnaire/06-security.md

@@ -1,68 +0,0 @@
-# Category 6: Security & Permissions
-
-> **Usage:** Definition of access and restrictions
-> **When to load:** ALWAYS (core, minimal)
-
----
-
-## 6.1 Access
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q6.1 | Who can VIEW data? | List of roles |
-| Q6.2 | Who can CREATE entries? | List of roles |
-| Q6.3 | Who can MODIFY? | List of roles |
-| Q6.4 | Who can DELETE? | List of roles |
-
-## 6.2 Restrictions
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q6.5 | Geographic restrictions? | Countries/regions |
-| Q6.6 | Time-based restrictions? (hours, periods) | Ranges |
-| Q6.7 | Audit trail required? Which actions? | List |
-| Q6.8 | Regulatory compliance? (GDPR, etc.) | List of standards |
-
----
-
-## Platform Permission
-
-**Format:** `{application}.{module}.{action}`
-
-| Action | Permission |
-|--------|------------|
-| Read | `.read` |
-| Create | `.create` |
-| Update | `.update` |
-| Delete | `.delete` |
-| Export | `.export` |
-| Import | `.import` |
-| Admin | `.admin` |
-
-> **⚠️ RBAC ARCHITECTURE: La plateforme gère les rôles et permissions via son système RBAC intégré (HasData).**
->
-> - Les rôles identifiés en Q6.1-Q6.4 sont des **ensembles de permissions**, pas des données métier
-> - L'accès est contrôlé par des permissions attribuées aux rôles, pas par des propriétés d'entité
-> - Ne jamais proposer de créer une entité `Role`, `UserRole`, ou un attribut `User.Role`
-> - Le mapping rôle → permissions se fait dans la **Permission Matrix** (step-03c-compile)
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q6.1-Q6.4 (access) | "Admin peut tout faire" | "Tout = aussi supprimer ? Aussi exporter des données sensibles ? Aussi modifier les données d'un autre tenant ?" |
-| Q6.1-Q6.4 (access) | Un seul rôle défini | "Qui ne fait que consulter ? Qui peut modifier mais pas supprimer ? Qui valide les actions critiques ?" |
-| Q6.4 (delete) | "Tout le monde peut supprimer" | "Suppression logique ou physique ? Confirmation requise ? Possibilité de restaurer ?" |
-| Q6.7 (audit) | "Non" | "Pas besoin de savoir qui a modifié quoi et quand ? Pas de traçabilité réglementaire ?" |
-| Q6.8 (compliance) | "Pas concerné" | "Données personnelles (RGPD) ? Données financières (SOX) ? Données de santé (HDS) ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "Admin = accès total sans restriction" | **Super-admin sans granularité** | Même l'admin devrait avoir des permissions explicites, pas un bypass global |
-| Aucune mention de multi-tenant | **Isolation oubliée** | La plateforme est multi-tenant : chaque requête est filtrée par TenantId automatiquement |
-| Pas d'audit trail | **Traçabilité absente** | `AuditableEntity` fournit CreatedBy/ModifiedBy. Suffisant ou besoin d'un audit log détaillé ? |
-| Permissions uniquement CRUD | **Actions métier non couvertes** | Y a-t-il des actions spécifiques ? (valider, approuver, archiver, publier) → permissions custom |

package/templates/skills/business-analyse/questionnaire/07-ui.md

@@ -1,76 +0,0 @@
-# Category 7: User Interface
-
-> **Usage:** Definition of user experience
-> **When to load:** If feature is UI-centric or full module
-
----
-
-## 7.1 Experience
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q7.1 | Target devices? (desktop, mobile, tablet) | List |
-| Q7.2 | Browsers to support? | List + versions |
-| Q7.3 | Accessibility required? (WCAG level) | A/AA/AAA |
-| Q7.4 | Dark/light mode required? | Yes/No |
-
-## 7.2 Screens
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q7.5 | Main screens needed? | List |
-| Q7.6 | Existing mockups/wireframes? | Documents |
-| Q7.7 | Key information per screen? | Per screen |
-| Q7.8 | Possible actions per screen? | Per screen |
-
-## 7.3 Dashboards & Analytics
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q7.9 | Dashboards ou tableaux de bord requis ? | List (noms + descriptions) |
-| Q7.10 | KPIs à afficher par dashboard ? | Per dashboard: nom, métrique, format (number/currency/percent), seuils |
-| Q7.11 | Types de graphiques souhaités ? | Per KPI: bar, line, pie, area, scatter, kpi-card |
-| Q7.12 | Filtres temporels ? | Période par défaut + plages disponibles (jour/semaine/mois/trimestre/année) |
-
----
-
-## UI Components
-
-| Need | Component | Détail |
-|------|-----------|--------|
-| List with pagination | DataTable | Tri, pagination, sélection, actions inline |
-| Creation form | Form page (`/create` route) | Validation FluentValidation, i18n des erreurs |
-| Edit form | Form page (`/:id/edit` route) | Pré-remplissage, dirty check, optimistic locking |
-| Filters | FilterBar | Filtres combinables, persistance URL params |
-| Export | ExportButton | CSV/Excel, respecte les filtres actifs |
-| Cards/Grid | CardGrid | Affichage visuel alternatif au tableau |
-| Detail view | DetailPanel | Side panel ou page dédiée |
-| Status/Workflow | StatusBadge + Timeline | Affichage état + historique transitions |
-| Tooltips/Infobulles | Tooltip | Info contextuelle sur champs/actions |
-| KPI Card | StatCard | Valeur numérique + tendance + icône |
-| Chart (Bar/Line/Pie) | RechartsChart | Graphique interactif via Recharts |
-| Dashboard layout | DashboardGrid | Grille responsive de KPI + charts |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q7.1 (devices) | "Desktop uniquement" | "Aucun accès mobile ? Même pas en consultation ? Tablette en atelier/terrain ?" |
-| Q7.5 (screens) | "Un écran de liste" | "Avec pages dédiées pour création et édition ? Détail en page avec onglets ?" |
-| Q7.5 (screens) | Pas de mention dashboard | "L'utilisateur a-t-il besoin d'un tableau de bord avec des KPIs avant de plonger dans les données ?" |
-| Q7.7 (key info) | "Toutes les colonnes" | "Sur mobile/petit écran, quelles 3-4 colonnes sont indispensables ? Le reste = détail secondaire" |
-| Q7.8 (actions) | "CRUD classique" | "Actions métier spécifiques ? (valider, dupliquer, archiver, changer statut, assigner)" |
-| Q7.9 (dashboards) | "Juste des chiffres" | "Les tendances/comparaisons ne seraient-elles pas plus lisibles en graphique ? Bar chart pour comparer, line chart pour évoluer ?" |
-| Q7.10 (KPIs) | Pas de seuils définis | "À partir de quel seuil un KPI est-il en alerte ? En critique ? (ex: stock < 10 = warning, < 3 = critique)" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "Un seul gros formulaire avec tout" | **Formulaire monolithique** | Proposer des étapes/wizard ou des onglets par section logique |
-| Aucune mention de feedback utilisateur | **UX silencieuse** | "Quels messages de succès/erreur ? Toast, notification, redirect ?" |
-| "Identique à [autre app]" | **Copier sans adapter** | "Quelles différences de contexte ? L'utilisateur fait-il le même parcours ?" |
-| Actions sans confirmation | **Actions destructives non protégées** | "La suppression nécessite-t-elle une confirmation ? Un motif ? Une double validation ?" |
-| "Juste des chiffres sur la page" | **Dashboard sans visualisation** | "Les tendances/comparaisons ne seraient-elles pas plus lisibles en graphique ? Bar chart pour comparer, line chart pour évoluer ?" |