@atlashub/smartstack-cli 4.17.1 → 4.19.0

package/templates/skills/business-analyse/questionnaire/08-performance.md

@@ -1,42 +0,0 @@
-# Category 8: Performance & Quality
-
-> **Usage:** Non-functional performance requirements
-> **When to load:** If feature is performance-critical or reporting
-
----
-
-## 8.1 Performance & Quality
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q8.1 | Acceptable response time? | Milliseconds |
-| Q8.2 | Expected load peaks? | When + volume |
-| Q8.3 | Specific tests required? | Types |
-| Q8.4 | Overall acceptance criteria? | List |
-
----
-
-## Platform Thresholds
-
-| Metric | Acceptable Threshold |
-|--------|---------------------|
-| API response time | < 200ms (P95) |
-| Page load | < 2s |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q8.1 (response time) | "Rapide" | "< 1 seconde ? < 200ms ? Différence acceptable entre liste et détail ?" |
-| Q8.2 (peaks) | "Non" | "Pas de clôture mensuelle ? Pas de période de saisie massive ? Pas d'import batch ?" |
-| Q8.3 (tests) | "Tests normaux" | "Tests unitaires ? Intégration ? E2E ? Tests de charge ? Tests de sécurité (OWASP) ?" |
-| Q8.4 (acceptance) | Vide | "Quels critères pour que le PO valide la livraison ? Performance, fonctionnel, UX ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Aucune mention de volume de données | **Scalabilité non planifiée** | "Avec 1M de lignes dans 2 ans, la recherche sera-t-elle toujours performante ?" |
-| Pas de tests mentionnés | **Qualité non vérifiable** | Au minimum : tests unitaires services + tests intégration API |

package/templates/skills/business-analyse/questionnaire/09-constraints.md

@@ -1,45 +0,0 @@
-# Category 9: Constraints
-
-> **Usage:** Technical and organizational constraints
-> **When to load:** If constraints identified or workflow feature
-
----
-
-## 9.1 Technical
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q9.1 | Mandated tech stack? | Technologies |
-| Q9.2 | Infrastructure limitations? | Description |
-| Q9.3 | Technology dependencies? | List |
-| Q9.4 | Compatibility constraints? | List |
-
----
-
-## Platform Constraints
-
-| Constraint | Impact | Non-négociable |
-|-----------|--------|----------------|
-| Multi-tenant | TenantId sur toutes les entités, isolation par tenant | Oui |
-| .NET 8+ | Version minimum du backend | Oui |
-| React 19+ | Version minimum du frontend | Oui |
-| SQL Server/PostgreSQL | Bases de données supportées | Oui |
-| CQRS | Commands/Queries séparées via MediatR | Oui |
-| FluentValidation | Validation côté serveur | Oui |
-| i18n (4 langues) | FR, EN, IT, DE obligatoires | Oui |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q9.1 (tech stack) | Propose une technologie hors plateforme | "La plateforme impose .NET 8 + React 19. Cette contrainte est-elle compatible avec votre besoin ?" |
-| Q9.2 (infrastructure) | "Cloud" sans précision | "Azure, AWS, on-premise ? Contraintes de localisation des données (pays) ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Technologie imposée hors stack | **Incompatibilité plateforme** | Clarifier : est-ce une intégration (OK) ou un remplacement de composant (risqué) ? |
-| "Pas de contrainte" | **Contraintes implicites oubliées** | Multi-tenant, RGPD, audit, i18n sont des contraintes de la plateforme obligatoires |

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

@@ -1,43 +0,0 @@
-# Category 10: Documentation & Support
-
-> **Usage:** Documentation and support needs
-> **When to load:** If documentation explicitly required
-
----
-
-## 10.1 Documentation
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q10.1 | User documentation needed? | Yes/No + type |
-| Q10.2 | Technical documentation needed? | Yes/No + type |
-| Q10.3 | User training planned? | Plan |
-| Q10.4 | Knowledge base to create? | Scope |
-
----
-
-## Documentation
-
-| Type | Generated by | Format |
-|------|-------------|--------|
-| 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 finish` | Changelog automatique |
-| ERD (schéma données) | `/documentation` skill | Mermaid diagram |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q10.1 (user doc) | "Oui" sans détail | "Guide pas-à-pas ? FAQ ? Vidéo tutoriel ? Tooltips in-app ? Quel public cible ?" |
-| Q10.2 (tech doc) | "Non" | "Pas de documentation API ? Pas de schéma de données pour les développeurs futurs ?" |
-| Q10.3 (training) | "Pas prévu" | "Comment les utilisateurs apprendront-ils ? Formation, doc, auto-apprentissage ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "La doc se fera après" | **Documentation en dette** | Le feature.json EST la doc. `/documentation` la génère automatiquement au step-08. |

package/templates/skills/business-analyse/questionnaire/11-data-lifecycle.md

@@ -1,59 +0,0 @@
-# Category 11: Data Lifecycle
-
-> **Usage:** Lifecycle, retention, archival and compliance for business data
-> **When to load:** If feature is data-centric or full module
-
----
-
-## 11.1 Data Retention
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q11.1 | How long must data be kept active? | Duration |
-| Q11.2 | Is there a legal retention period? (GDPR, fiscal, regulatory) | Duration + regulation |
-| Q11.3 | What happens after the retention period? | Archive/Purge/Anonymize |
-| Q11.4 | Who decides when data is archived or purged? | Role |
-
-## 11.2 Data States
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q11.5 | What states can a record go through? (draft, active, archived, deleted) | List of states |
-| Q11.6 | Can a deleted record be restored? | Yes/No + conditions |
-| Q11.7 | Should historical versions be kept? (versioning) | Yes/No + depth |
-| Q11.8 | Is there a "freeze" or "lock" state? (immutable after validation) | Yes/No + trigger |
-
----
-
-## Lifecycle Patterns
-
-| Need | Platform Pattern | Impact |
-|------|-------------------|--------|
-| Soft delete | `SoftDeletableEntity` | IsDeleted, DeletedBy, DeletedDate auto-managed |
-| Audit trail | `AuditableEntity` | CreatedBy/Date, ModifiedBy/Date auto-managed |
-| Versioning | Custom `EntityVersion` table | Manual implementation per entity |
-| Archival | Status enum + background job | Scheduled job moves old records |
-| GDPR purge | Anonymization service | Replace personal data with `[REDACTED]` |
-| Immutable after state | Validation in Update command | `if (entity.Status == Locked) throw` |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q11.1 (retention) | "Toujours" | "Pas de limite légale ? Avec 1M de lignes dans 5 ans, les performances resteront-elles acceptables ?" |
-| Q11.2 (legal) | "Je ne sais pas" | "Données personnelles = RGPD (effacement après demande). Données fiscales = 10 ans. Données RH = 5 ans après départ." |
-| Q11.3 (after retention) | "On supprime" | "Suppression physique ou logique ? Anonymisation des données personnelles ? Export avant suppression ?" |
-| Q11.5 (states) | "Actif ou supprimé" | "Pas de brouillon ? Pas de 'en attente de validation' ? Pas d'archivé consultable mais non modifiable ?" |
-| Q11.6 (restore) | "Non" | "Si un utilisateur supprime par erreur, aucun recours ? Même pas l'admin ?" |
-| Q11.8 (freeze) | "Non" | "Une fois une facture validée, peut-on encore la modifier ? Une commande livrée, peut-on changer son contenu ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "On garde tout pour toujours" | **Pas de stratégie de rétention** | Volume illimité = performance dégradée. Définir une politique d'archivage. |
-| Suppression physique de données personnelles | **Non-conformité RGPD** | RGPD exige la possibilité d'effacer/anonymiser. `SoftDeletableEntity` + anonymisation. |
-| Aucun état intermédiaire | **Lifecycle trop simple** | La plupart des entités métier passent par brouillon → actif → archivé minimum. |
-| Données modifiables sans limite | **Pas d'immutabilité** | Certains documents (factures, contrats) doivent être figés après validation. |

package/templates/skills/business-analyse/questionnaire/12-migration.md

@@ -1,58 +0,0 @@
-# Category 12: Migration & Transition
-
-> **Usage:** Plan transition from AS-IS to TO-BE, handle existing data
-> **When to load:** ALWAYS for new modules (not enhancements)
-
----
-
-## 12.1 Existing Data
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q12.1 | Is there existing data to migrate? | Yes/No + source |
-| Q12.2 | What format is the existing data in? | Excel/CSV/DB/API/Manual |
-| Q12.3 | What volume of data to migrate? | Estimation |
-| Q12.4 | What data quality issues exist? (duplicates, missing fields, inconsistencies) | List |
-
-## 12.2 Transition Plan
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q12.5 | Is there a coexistence period? (old + new system in parallel) | Duration |
-| Q12.6 | What is the cutover strategy? | Big-bang / Progressive / Parallel |
-| Q12.7 | Who validates the migrated data? | Role |
-| Q12.8 | What is the rollback plan if migration fails? | Strategy |
-
----
-
-## Migration Patterns
-
-| Need | Pattern | Tool |
-|------|---------|------|
-| CSV/Excel import | Background job + FluentValidation | Hangfire + custom importer |
-| Database migration | EF Core seed / SQL script | `dotnet ef` + seed data |
-| API import | HttpClient batch | Background job + Polly |
-| Data cleanup | Validation pipeline | FluentValidation + reporting |
-| Progressive rollout | Feature flag | LaunchDarkly / custom config |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q12.1 (existing data) | "Oui" sans détail | "Dans quel outil ? Excel, ERP, autre DB ? Combien de fichiers/tables ? Qui y a accès ?" |
-| Q12.2 (format) | "Excel" | "Un seul fichier ou plusieurs ? Avec des onglets ? Des macros ? Des formules ? Quelles colonnes ?" |
-| Q12.4 (quality) | "C'est propre" | "Pas de doublons ? Pas de champs vides obligatoires ? Pas de formats incohérents (dates, montants) ?" |
-| Q12.5 (coexistence) | "Non" | "Les utilisateurs passent directement au nouveau système ? Pas de période d'apprentissage en parallèle ?" |
-| Q12.6 (cutover) | "On verra" | "Big-bang (bascule à date fixe) ou progressif (équipe par équipe) ? Si progressif, quels groupes en premier ?" |
-| Q12.8 (rollback) | "Pas prévu" | "Si l'import échoue ou corrompt des données, comment revenir en arrière ? Backup avant migration ?" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| "On saisira tout à la main" | **Migration non planifiée** | Si > 100 enregistrements, l'import automatisé est indispensable |
-| Pas de validation post-migration | **Données non vérifiées** | Prévoir un rapport de migration : importés / rejetés / à corriger |
-| Aucun rollback plan | **Risque de perte de données** | Toujours faire un backup avant migration + possibilité de rollback |
-| "On migrera plus tard" | **Dette technique** | Si la migration est nécessaire, la planifier dès le départ même si simplifiée |

package/templates/skills/business-analyse/questionnaire/13-cross-module.md

@@ -1,69 +0,0 @@
-# Category 13: Cross-Module Impact
-
-> **Usage:** Analyze impact on existing modules and shared dependencies
-> **When to load:** ALWAYS for new modules (not enhancements)
-
----
-
-## 13.1 Existing Module Dependencies
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q13.1 | Which existing modules does this new module interact with? | List |
-| Q13.2 | What data is shared between modules? (entities, lookup tables) | Per module |
-| Q13.3 | Are there existing entities this module will reference? (FK relationships) | List |
-| Q13.4 | Will this module produce events that other modules consume? | List of events |
-
-## 13.2 Impact Assessment
-
-| # | Question | Answer Type |
-|---|----------|-------------|
-| Q13.5 | Will existing modules need modifications to support this new module? | List of changes |
-| Q13.6 | Are there shared UI components or navigation changes? | List |
-| Q13.7 | Will this module affect existing permissions/roles? | Yes/No + detail |
-| Q13.8 | Is there a risk of data model conflicts? (same entity modified by 2 modules) | Risk assessment |
-
----
-
-## Cross-Module Patterns
-
-| Need | Pattern | Example |
-|------|---------|---------|
-| Reference another entity | Navigation property + FK | `Order.ClientId → Client` |
-| Shared lookup data | Shared entity in Domain | `Status`, `Category` entities |
-| Event notification | MediatR notification | `OrderCreatedNotification` |
-| Cross-module query | Read-only DTO from other module | `IClientQueryService` |
-| Navigation link | Menu entry in NavRoute | `business/{app}/{module}` |
-| Shared permission | Permission hierarchy | `{app}.*` covers all modules |
-
-## Elicitation Guide
-
-### Follow-ups by Question
-
-| Question | If answer is vague/insufficient | Probe |
-|----------|-------------------------------|-------|
-| Q13.1 (interactions) | "Aucun" | "Ce module est totalement isolé ? Pas de lien avec des clients, produits, utilisateurs d'autres modules ?" |
-| Q13.2 (shared data) | "Je ne sais pas" | Use `{codebase_context}` from pre-research: "J'ai trouvé les entités {list} dans {app}. Ce module a-t-il besoin de les référencer ?" |
-| Q13.3 (FK references) | Vague | "Une {entity} de ce module appartient-elle à un {existing_entity} ? (ex: OrderLine → Product)" |
-| Q13.4 (events) | "Non" | "Quand un {entity} est créé/modifié/supprimé, faut-il notifier un autre module ? Mettre à jour un compteur ?" |
-| Q13.5 (modifications) | "Non" | "Pas de nouvelle colonne dans le menu ? Pas de lien depuis une page existante vers ce nouveau module ?" |
-| Q13.8 (conflicts) | "Pas de risque" | "Deux modules modifient-ils la même entité ? (ex: module A crée un Client, module B le modifie)" |
-
-### Anti-patterns to Detect
-
-| Signal | Anti-pattern | Action |
-|--------|-------------|--------|
-| Module totalement isolé | **Silo de données** | Rare qu'un module métier n'ait aucune connexion. Vérifier avec le codebase context. |
-| Duplication d'entité existante | **Entité dupliquée** | Si `Client` existe déjà, ne pas créer `Customer`. Référencer l'existant. |
-| Modification d'entité d'un autre module | **Couplage fort** | Utiliser des événements (MediatR) plutôt que des modifications directes. |
-| Aucune mention de navigation | **Module orphelin dans l'UI** | Le module doit apparaître dans le menu de l'application (NavRoute). |
-
-### Using Pre-Research Context
-
-> **IMPORTANT:** This category benefits most from step 3 (Pre-Research).
->
-> Use `{codebase_context}` to:
-> - **List existing entities** and ask the user which ones this module references
-> - **Show existing modules** and ask about interactions
-> - **Detect potential duplicates** (entity names similar to what the user describes)
-> - **Propose event patterns** based on existing MediatR notifications

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

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

package/templates/skills/business-analyse/questionnaire/15-success-metrics.md

@@ -1,136 +0,0 @@
-# Categorie 15 : Criteres de reussite
-
-> **Usage :** Definir comment mesurer le succes du projet de maniere objective
-> **Quand charger :** TOUJOURS (noyau, charge dans le cadrage)
-> **Objectif :** Etablir des criteres observables et mesurables pour evaluer le resultat
-
----
-
-## 15.1 La definition du succes
-
-> **But :** Determiner concretement ce qui fera dire "ce projet est un succes".
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.1 | Quand le systeme sera en place, comment saurez-vous que le projet est un succes ? Quel changement concret observerez-vous ? | Description du succes observable |
-| Q15.2 | Si vous deviez convaincre votre direction que le projet a reussi, quels chiffres ou faits leur presenteriez-vous ? | Metriques de succes |
-| Q15.3 | Au bout de combien de temps apres le lancement pourrez-vous juger si ca fonctionne ? 1 semaine ? 1 mois ? 3 mois ? | Delai d'evaluation |
-
-**Reformulation guidee pour Q15.1 :**
-```
-question: "Comment saurez-vous que le projet est un succes ?"
-header: "Succes"
-options:
-  - label: "Gain de temps mesurable"
-    description: "Un processus qui prenait X heures ne prend plus que Y minutes"
-  - label: "Reduction des erreurs"
-    description: "Le nombre d'erreurs ou de corrections a diminue de maniere significative"
-  - label: "Meilleure satisfaction"
-    description: "Les utilisateurs expriment clairement que leur quotidien s'est ameliore"
-  - label: "Indicateurs en hausse"
-    description: "Des chiffres cles (chiffre d'affaires, productivite, qualite) se sont ameliores"
-```
-
----
-
-## 15.2 Les objectifs mesurables
-
-> **But :** Transformer les attentes en objectifs chiffres et verifiables.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.4 | Pour chaque amelioration attendue, pouvez-vous donner un objectif chiffre ? Par exemple : "reduire le temps de traitement de 2 heures a 30 minutes" | Objectifs quantifies |
-| Q15.5 | Quels indicateurs suivez-vous deja aujourd'hui qui pourraient servir de reference ? | Indicateurs existants |
-| Q15.6 | Y a-t-il des indicateurs que vous ne suivez pas aujourd'hui mais que vous aimeriez pouvoir mesurer grace au nouveau systeme ? | Nouveaux indicateurs souhaites |
-
-**Reformulation guidee pour Q15.4 :**
-```
-question: "Pouvez-vous chiffrer les ameliorations attendues ?"
-header: "Objectifs"
-options:
-  - label: "Temps divise par 2 ou plus"
-    description: "Le processus actuel prend trop de temps, l'objectif est de le reduire d'au moins 50%"
-  - label: "Erreurs reduites a moins de 5%"
-    description: "Le taux d'erreur actuel est trop eleve, l'objectif est de le ramener sous les 5%"
-  - label: "100% de tracabilite"
-    description: "Aujourd'hui des informations se perdent, l'objectif est de tout tracer"
-  - label: "Difficile a chiffrer"
-    description: "L'amelioration est qualitative et difficile a mesurer numeriquement"
-```
-
----
-
-## 15.3 Les criteres d'acceptation
-
-> **But :** Definir les conditions minimales pour que le systeme soit considere comme livre.
-
-| # | Question | Type de reponse |
-|---|----------|-----------------|
-| Q15.7 | Quelles sont les conditions minimales pour que vous acceptiez de mettre le systeme en service ? | Liste de conditions obligatoires |
-| Q15.8 | Qui decide officiellement que le systeme est pret a etre utilise ? Quel est le processus de validation finale ? | Processus de validation |
-
-**Reformulation guidee pour Q15.7 :**
-```
-question: "Quelles conditions minimales pour mettre le systeme en service ?"
-header: "Acceptation"
-multiSelect: true
-options:
-  - label: "Toutes les fonctionnalites vitales presentes"
-    description: "Les fonctionnalites classees indispensables fonctionnent correctement"
-  - label: "Donnees migrees et verifiees"
-    description: "Les donnees existantes ont ete transferees et validees dans le nouveau systeme"
-  - label: "Utilisateurs formes"
-    description: "Les utilisateurs principaux ont ete formes et savent utiliser le systeme"
-  - label: "Tests valides"
-    description: "Les tests de fonctionnement ont ete realises et les resultats sont satisfaisants"
-```
-
----
-
-## Guide d'elicitation approfondi
-
-### Techniques de relance par question
-
-| Question | Si la reponse est vague ou insuffisante | Relance recommandee |
-|----------|----------------------------------------|---------------------|
-| Q15.1 (succes) | "Que tout fonctionne bien" | "Concretement, imaginons que je visite votre bureau 3 mois apres le lancement. Qu'est-ce que je verrais de different par rapport a aujourd'hui ? Qu'est-ce que les gens feraient differemment ?" |
-| Q15.2 (chiffres) | "Je ne sais pas quels chiffres" | "Pensez a votre patron : qu'est-ce qui le convaincrait ? Nombre de dossiers traites par jour ? Temps de reponse aux clients ? Taux d'erreur ? Satisfaction des equipes ?" |
-| Q15.3 (delai) | "Tout de suite" | "Certains benefices apparaissent immediatement (gain de temps) et d'autres prennent du temps (adoption, qualite des donnees). Quel delai est realiste pour chaque benefice ?" |
-| Q15.4 (objectifs chiffres) | "Difficile a chiffrer" | "Meme approximativement : le processus prend combien de temps aujourd'hui ? Quel serait un temps acceptable ? Combien d'erreurs par mois avez-vous aujourd'hui ?" |
-| Q15.5 (indicateurs existants) | "On ne mesure rien" | "Comment evaluez-vous si la journee s'est bien passee ? Quels signaux vous disent que ca va bien ou mal ?" |
-| Q15.7 (conditions minimales) | "Il faut que tout soit parfait" | "Si vous deviez lancer avec seulement 80% des fonctionnalites, lesquelles seraient dans ces 80% ?" |
-
-### Signaux d'alerte a detecter
-
-| Signal du client | Probleme sous-jacent | Action de l'analyste |
-|------------------|---------------------|----------------------|
-| Aucun critere mesurable | **Succes non defini** | Proposer des metriques standards : temps de traitement, taux d'erreur, taux d'adoption, satisfaction utilisateur |
-| "Ca doit etre parfait" | **Attentes irrealistes** | "La perfection est un objectif, mais quel est le niveau minimum acceptable pour un premier lancement ?" |
-| Indicateurs contradictoires | **Objectifs mal alignes** | "Ces deux objectifs semblent en tension. Lequel est prioritaire si vous devez choisir ?" |
-| Pas de processus de validation | **Pas de gouvernance** | "Qui signe l'acceptation ? Un email suffit ou faut-il un proces-verbal formel ?" |
-| Succes mesure uniquement par la technique | **Oubli de l'humain** | "Au-dela du fonctionnement technique, comment mesurez-vous la satisfaction des utilisateurs ?" |
-
----
-
-## Mapping vers le cadrage
-
-| Reponse | Alimente |
-|---------|----------|
-| Q15.1, Q15.2, Q15.3 | `cadrage.acceptanceCriteria[]` |
-| Q15.4, Q15.5, Q15.6 | `cadrage.acceptanceCriteria[]` + `cadrage.toBe` (enrichissement) |
-| Q15.7, Q15.8 | `cadrage.acceptanceCriteria[]` (conditions de livraison) |
-
----
-
-## Strategie de questionnement
-
-### Ordre des questions en 2 lots
-
-**Lot 1 (Q15.1, Q15.2, Q15.3, Q15.4) : Definir le succes**
-- Commencer par la vision qualitative du succes
-- Puis quantifier avec des metriques et des delais
-
-**Lot 2 (Q15.5, Q15.6, Q15.7, Q15.8) : Mesurer et valider**
-- Identifier les indicateurs de reference existants
-- Definir les conditions minimales de livraison
-- Clarifier le processus de validation finale