# Spécification de fonctionnalité : [NOM DE LA FONCTIONNALITÉ]

**Branche feature** : `[###-nom-court]`  
**Créé le** : [DATE]  
**Statut** : Brouillon  
**Entrée** : Description utilisateur : « $ARGUMENTS »

Pour UnionFlow : ne pas inventer de packages, routes ou features non listés dans `.specify/memory/inventaire-code.md`.

## Scénarios utilisateur et tests *(obligatoire)*

<!--
  Les user stories doivent être PRIORISÉES par ordre d'importance.
  Chaque user story doit être TESTABLE INDÉPENDAMMENT : en n'implémentant qu'une seule,
  on doit avoir un MVP (Minimum Viable Product) qui apporte de la valeur.
  Priorités : P1, P2, P3, etc. (P1 = le plus critique).
  Chaque story = slice autonome : développable, testable, déployable, démontrable seule.
-->

### User Story 1 - [Titre court] (Priorité : P1)

[Décrire ce parcours utilisateur en langage simple]

**Pourquoi cette priorité** : [Valeur et justification]

**Test indépendant** : [Comment tester cette story seule — ex. « Testable par [action] et livre [valeur] »]

**Scénarios d'acceptation** :

1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]
2. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]

---

### User Story 2 - [Titre court] (Priorité : P2)

[Décrire ce parcours utilisateur en langage simple]

**Pourquoi cette priorité** : [Valeur et justification]

**Test indépendant** : [Comment tester cette story seule]

**Scénarios d'acceptation** :

1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]

---

### User Story 3 - [Titre court] (Priorité : P3)

[Décrire ce parcours utilisateur en langage simple]

**Pourquoi cette priorité** : [Valeur et justification]

**Test indépendant** : [Comment tester cette story seule]

**Scénarios d'acceptation** :

1. **Étant donné** [état initial], **quand** [action], **alors** [résultat attendu]

---

[Ajouter d'autres user stories si besoin, chacune avec une priorité]

### Cas limites

<!-- Remplir avec les vrais cas limites -->

- Que se passe-t-il quand [condition limite] ?
- Comment le système gère-t-il [scénario d'erreur] ?

## Exigences *(obligatoire)*

<!-- Remplir avec les exigences fonctionnelles réelles -->

### Exigences fonctionnelles

- **EF-001** : Le système DOIT [capacité, ex. « permettre aux utilisateurs de créer un compte »]
- **EF-002** : Le système DOIT [capacité, ex. « valider les adresses e-mail »]
- **EF-003** : Les utilisateurs DOIVENT pouvoir [interaction clé, ex. « réinitialiser leur mot de passe »]
- **EF-004** : Le système DOIT [exigence données, ex. « persister les préférences utilisateur »]
- **EF-005** : Le système DOIT [comportement, ex. « journaliser tous les événements de sécurité »]

*Exemple de marquage d'exigences floues :*

- **EF-006** : Le système DOIT authentifier les utilisateurs via [À PRÉCISER : méthode non précisée — email/mot de passe, SSO, OAuth ?]
- **EF-007** : Le système DOIT conserver les données utilisateur pendant [À PRÉCISER : durée de rétention non précisée]

### Entités clés *(si la feature concerne des données)*

- **[Entité 1]** : [Ce qu'elle représente, attributs clés sans détail d'implémentation]
- **[Entité 2]** : [Ce qu'elle représente, relations avec les autres entités]

## Critères de succès *(obligatoire)*

<!-- Définir des critères mesurables, indépendants de la technologie -->

### Résultats mesurables

- **CS-001** : [Métrique mesurable, ex. « Les utilisateurs peuvent créer un compte en moins de 2 minutes »]
- **CS-002** : [Métrique mesurable, ex. « Le système supporte 1000 utilisateurs concurrents sans dégradation »]
- **CS-003** : [Métrique satisfaction, ex. « 90 % des utilisateurs réussissent la tâche principale du premier coup »]
- **CS-004** : [Métrique métier, ex. « Réduire de 50 % les tickets support liés à [X] »]