docs(#117): CDC V1.4 (users à jour, reste conservé) + SRS utilisateurs.
- CDC complet conservé ; sections gestion utilisateurs / dossiers alignées v0.1.0 - Archive V1.3 + EVOLUTIONS_CDC ; nouvelle 12_SRS-GESTION-UTILISATEURS - INDEX / versions / bilan mis à jour Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,307 @@
|
||||
# Évolutions du Cahier des Charges
|
||||
|
||||
Ce document liste les modifications à apporter au cahier des charges original pour le rendre conforme à l'application développée.
|
||||
|
||||
> **Intrant pour #117** (amendement CDC post-0.1.0). Compléter avec le [bilan 0.1.0](./29_BILAN-VERSION-0.1.0.md) et **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
|
||||
|
||||
> **Obsolète depuis #152** : ne plus proposer de champ « naissance multiple / `est_multiple` » — retiré de l’app (BDD, API, front).
|
||||
|
||||
## 1. Gestion des Enfants
|
||||
|
||||
### Modifications à apporter dans la section "Création de compte parent"
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Mentionne uniquement la collecte d'informations sur l'enfant
|
||||
- Ne précise pas la possibilité d'ajouter plusieurs enfants
|
||||
- Ne mentionne pas la gestion des enfants à naître
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Ajouter le paragraphe suivant après la description de la collecte d'informations sur l'enfant :
|
||||
|
||||
```
|
||||
Les parents peuvent ajouter autant d'enfants que nécessaire. Pour chaque enfant, les informations suivantes sont collectées :
|
||||
- Prénom
|
||||
- Date de naissance (ou date prévue pour les enfants à naître)
|
||||
- Genre
|
||||
- Photo (optionnelle)
|
||||
- Consentement pour l'utilisation de la photo
|
||||
|
||||
Les parents peuvent :
|
||||
- Ajouter un nouvel enfant à tout moment
|
||||
- Supprimer un enfant ajouté
|
||||
- Modifier les informations d'un enfant existant
|
||||
- Indiquer si l'enfant est à naître
|
||||
- Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant
|
||||
|
||||
Note : le concept de « naissance multiple » / jumeaux n'est pas géré par un champ dédié (retiré en 0.1.0, #152).
|
||||
```
|
||||
|
||||
### Modifications à apporter dans la section "Workflow de création de compte"
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Étape 3 : "Collecte des informations sur l'enfant"
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Remplacer l'étape 3 par :
|
||||
```
|
||||
3. Collecte des informations sur les enfants
|
||||
- Ajout d'un premier enfant
|
||||
- Possibilité d'ajouter d'autres enfants
|
||||
- Pour chaque enfant :
|
||||
* Saisie du prénom
|
||||
* Saisie de la date de naissance (ou date prévue)
|
||||
* Genre
|
||||
* Option d'ajout d'une photo
|
||||
* Option de consentement photo
|
||||
* Indication si enfant à naître
|
||||
- Possibilité de modifier ou supprimer un enfant
|
||||
```
|
||||
|
||||
## 2. Workflow de Création de Compte
|
||||
|
||||
### Modifications à apporter dans la section "Workflow de création de compte"
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Ne précise pas l'ordre exact des étapes
|
||||
- Ne mentionne pas le statut du compte après création
|
||||
- Ne détaille pas le processus de validation
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Ajouter les précisions suivantes au workflow :
|
||||
|
||||
```
|
||||
Le processus de création de compte suit l'ordre suivant :
|
||||
1. Collecte des informations du premier parent
|
||||
2. Option d'ajout d'un second parent
|
||||
3. Collecte des informations sur les enfants
|
||||
4. Description de la situation familiale
|
||||
5. Acceptation des conditions générales
|
||||
6. Résumé et validation finale
|
||||
|
||||
Après la validation :
|
||||
- Le compte est créé avec le statut "en attente"
|
||||
- Un gestionnaire doit valider le compte avant son activation
|
||||
- Les parents reçoivent une notification de la création de leur compte
|
||||
- Une notification est envoyée aux gestionnaires pour validation
|
||||
```
|
||||
|
||||
## 3. Informations Supplémentaires
|
||||
|
||||
### Modifications à apporter dans la section "Création de compte parent"
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Ne mentionne pas la possibilité de présentation personnelle
|
||||
- Ne mentionne pas la gestion des photos
|
||||
- Ne précise pas les statuts possibles du compte
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Ajouter les sections suivantes :
|
||||
|
||||
```
|
||||
### Informations complémentaires
|
||||
Le premier parent peut optionnellement ajouter une présentation personnelle pour décrire sa situation et ses attentes.
|
||||
|
||||
### Gestion des photos
|
||||
Pour chaque enfant, les parents peuvent :
|
||||
- Ajouter une photo
|
||||
- Donner ou retirer leur consentement pour l'utilisation de la photo
|
||||
- La photo est stockée de manière sécurisée
|
||||
- Le consentement est enregistré avec date et heure
|
||||
|
||||
### Statut du compte
|
||||
Les statuts possibles du compte sont :
|
||||
- En attente : compte créé, en attente de validation
|
||||
- Validé : compte activé par un gestionnaire
|
||||
- Rejeté : compte refusé par un gestionnaire
|
||||
- Suspendu : compte temporairement désactivé
|
||||
```
|
||||
|
||||
## 4. Validation et Sécurité
|
||||
|
||||
### Modifications à apporter dans la section "Validation"
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Mentionne la validation par un gestionnaire
|
||||
- Ne précise pas le processus de validation
|
||||
- Ne mentionne pas les notifications
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Ajouter la section suivante :
|
||||
|
||||
```
|
||||
### Processus de validation
|
||||
1. Création du compte avec statut "en attente"
|
||||
2. Notification automatique aux gestionnaires
|
||||
3. Revue des informations par un gestionnaire
|
||||
4. Décision de validation ou rejet
|
||||
5. Notification aux parents de la décision
|
||||
6. Activation ou rejet du compte selon la décision
|
||||
|
||||
### Notifications
|
||||
- Les parents reçoivent une notification à chaque changement de statut
|
||||
- Les gestionnaires reçoivent une notification pour chaque nouveau compte
|
||||
- Un historique des validations est conservé
|
||||
```
|
||||
|
||||
## 5. Initialisation de l'Application
|
||||
|
||||
### Ajout de l'administrateur par défaut
|
||||
|
||||
#### Situation actuelle dans le CDC :
|
||||
- Ne mentionne pas l'existence d'un administrateur par défaut
|
||||
- Ne précise pas les identifiants de connexion par défaut
|
||||
|
||||
#### Modifications proposées :
|
||||
|
||||
Ajouter la section suivante :
|
||||
|
||||
```
|
||||
### Administrateur par défaut
|
||||
Lors du premier démarrage de l'application, un compte administrateur est automatiquement créé avec les identifiants suivants :
|
||||
- Email : administrateur@ptitspas.fr
|
||||
- Mot de passe : password
|
||||
|
||||
Ce compte permet d'accéder à toutes les fonctionnalités administratives de l'application.
|
||||
Le changement de mot de passe est obligatoire lors de la première connexion.
|
||||
L'application doit forcer ce changement avant d'autoriser l'accès aux fonctionnalités administratives.
|
||||
```
|
||||
|
||||
## 6. Changement de Nom de l'Application
|
||||
|
||||
### Situation actuelle dans le CDC :
|
||||
- L'application est nommée "SuperNounou" dans tout le document
|
||||
- Les références à l'application utilisent ce nom
|
||||
|
||||
### Modifications proposées :
|
||||
|
||||
Ajouter la section suivante :
|
||||
|
||||
```
|
||||
### Changement de nom
|
||||
L'application est renommée "P'titsPas" dans toute la documentation et l'interface utilisateur.
|
||||
Ce changement implique :
|
||||
- Mise à jour de toutes les références à "SuperNounou" dans le CDC
|
||||
- Mise à jour des mentions légales
|
||||
- Mise à jour de la documentation technique
|
||||
- Mise à jour des interfaces utilisateur
|
||||
- Mise à jour des messages système et notifications
|
||||
- Mise à jour des adresses email (ex: support@ptitspas.fr)
|
||||
```
|
||||
|
||||
### Impact sur l'application :
|
||||
- Mise à jour de tous les textes statiques dans le code
|
||||
- Mise à jour des templates d'email
|
||||
- Mise à jour des messages de notification
|
||||
- Mise à jour de la documentation utilisateur
|
||||
- Mise à jour des mentions légales et CGU
|
||||
|
||||
## Format de présentation
|
||||
|
||||
Pour chaque évolution identifiée, ce document suivra la structure suivante :
|
||||
1. Section concernée dans le CDC
|
||||
2. Situation actuelle
|
||||
3. Modifications proposées
|
||||
4. Impact sur l'application
|
||||
|
||||
## Prochaines évolutions à documenter
|
||||
|
||||
- [x] Ajouter d'autres évolutions identifiées
|
||||
- [ ] Mettre à jour le CDC original
|
||||
- [ ] Valider les modifications avec les parties prenantes
|
||||
- [ ] Modifier le texte de la checkbox de consentement photo (libellé actuel : 'J\'accepte l\'utilisation de ma photo.') sur l'écran d'inscription Nounou Étape 2 (`nanny_register_step2_screen.dart`).
|
||||
|
||||
# Évolutions proposées au cahier des charges
|
||||
|
||||
## 1. Workflow de création de compte
|
||||
|
||||
### 1.1 Récupération de compte
|
||||
|
||||
#### 1.1.1 Fonctionnalités
|
||||
- Ajout d'un lien "Mot de passe oublié" sur la page de connexion
|
||||
- Processus de récupération en 3 étapes :
|
||||
1. Saisie de l'adresse email
|
||||
2. Envoi d'un lien unique de réinitialisation (valide 24h)
|
||||
3. Création d'un nouveau mot de passe
|
||||
|
||||
#### 1.1.2 Sécurité
|
||||
- Le lien de réinitialisation doit être unique et à usage unique
|
||||
- Le lien expire après 24 heures
|
||||
- Le nouveau mot de passe doit respecter les mêmes critères que lors de la création de compte
|
||||
- Notification par email lors de la réinitialisation du mot de passe
|
||||
|
||||
#### 1.1.3 Interface
|
||||
- Page dédiée pour la saisie de l'email
|
||||
- Page de confirmation d'envoi du lien
|
||||
- Formulaire de réinitialisation du mot de passe
|
||||
- Messages d'erreur clairs en cas de :
|
||||
- Email non trouvé
|
||||
- Lien expiré
|
||||
- Mot de passe non conforme
|
||||
|
||||
## X. Amélioration de la Gestion des Photos Utilisateurs (Proposition)
|
||||
|
||||
### X.1 Recadrage et Redimensionnement des Photos
|
||||
|
||||
#### X.1.1 Fonctionnalités
|
||||
- **Contexte :** Lors du téléchargement de photos par les utilisateurs (photos de profil, photos d'enfants).
|
||||
- **Besoin :** Permettre à l'utilisateur de recadrer l'image (notamment en format carré pour les avatars) et potentiellement de la faire pivoter ou de zoomer avant son enregistrement final.
|
||||
- **Objectif :** Améliorer l'expérience utilisateur, assurer une meilleure qualité et cohérence visuelle des images stockées et affichées dans l'application.
|
||||
|
||||
#### X.1.2 Solution Technique Envisagée (pour discussion)
|
||||
- L'intégration d'une librairie Flutter tierce dédiée au recadrage d'image (par exemple, `image_cropper` ou `crop_image`) sera nécessaire après la sélection initiale de l'image via `image_picker`.
|
||||
- La tentative initiale avec `image_cropper` (version 5.0.1) a rencontré des difficultés techniques d'intégration (erreur "Too many positional arguments" persistante avec `AndroidUiSettings`) et a été mise en attente. Une investigation plus approfondie ou l'évaluation d'alternatives sera requise.
|
||||
|
||||
#### X.1.3 Impact sur l'application
|
||||
- Modification du flux de sélection d'image dans les écrans concernés (ex: `parent_register_step3_screen.dart`).
|
||||
- Ajout potentiel de nouvelles dépendances et configurations spécifiques aux plateformes.
|
||||
- Mise à jour de la documentation utilisateur si cette fonctionnalité est implémentée.
|
||||
|
||||
## 8. Évolution future - Gouvernance intra-RPE
|
||||
|
||||
### 8.1 Niveaux d'accès et rôles différenciés dans un même Relais
|
||||
|
||||
#### 8.1.1 Situation actuelle
|
||||
- Le périmètre actuel prévoit un rattachement simple entre gestionnaire et relais.
|
||||
- Le rôle "gestionnaire" est traité de manière uniforme dans l'outil.
|
||||
|
||||
#### 8.1.2 Évolution à prévoir
|
||||
- Introduire un modèle de rôles internes au relais (par exemple : responsable/coordinatrice, animatrice/référente, administratif).
|
||||
- Permettre des niveaux d'autorité différents selon les actions (pilotage, validation, consultation, administration locale).
|
||||
- Définir des permissions fines par fonctionnalité (lecture, création, modification, suppression, validation).
|
||||
- Prévoir une gestion multi-utilisateurs par relais avec traçabilité des décisions.
|
||||
|
||||
#### 8.1.3 Impact attendu
|
||||
- Évolution du modèle de données vers un RBAC intra-RPE.
|
||||
- Adaptation des écrans d'administration pour gérer les rôles locaux.
|
||||
- Renforcement des contrôles d'accès backend et des règles métier.
|
||||
- Clarification des workflows décisionnels dans l'application.
|
||||
|
||||
## 9. Modèle famille, numéro de dossier et responsables légaux
|
||||
|
||||
### 9.1 Situation actuelle (v1.0.0)
|
||||
|
||||
- Un **numéro de dossier** par inscription (`AAAA-NNNNNN`), fortement utilisé dans les workflows (validation, refus, reprise).
|
||||
- **Un co-parent** par fiche `parents` ; affiliation réelle via `enfants_parents`.
|
||||
- La « famille » est **déduite** du graphe (co-parent + enfants partagés) — fusion parfois trop large en cas de recompositions.
|
||||
|
||||
### 9.2 Limitation v1.0.0 — familles recomposées
|
||||
|
||||
Cas type : même responsable M avec co-responsable A (enfant α) puis co-responsable B (enfant β). Le modèle actuel ne permet pas de séparer proprement **deux unités familiales** pour une même personne.
|
||||
|
||||
**Contournement accepté pour la release 1.0.0** : second compte avec **email distinct** et second numéro de dossier (procédure gestionnaire). S'applique aussi aux couples HH/FF, tuteurs, grands-parents, etc.
|
||||
|
||||
### 9.3 Évolutions post-1.0.0 (pistes)
|
||||
|
||||
| Sujet | Piste |
|
||||
|-------|--------|
|
||||
| **Unité de dossier** | Numéro **optionnel** ; plusieurs unités par personne |
|
||||
| **Affiliation** | Gestion admin des liens parent↔enfant (#115, #116, #138) |
|
||||
| **Qualification** | Combobox « lien responsable–enfant » (tuteur, GP, parent…) sur `enfants_parents` |
|
||||
| **UI admin** | Fiche parent éditable (#131), liste enfants en bas de fiche |
|
||||
|
||||
**Détail complet, scénarios, tickets et formulation release notes** : [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).
|
||||
@@ -4,13 +4,15 @@ Ancienne documentation **déplacée** depuis `docs/` :
|
||||
|
||||
| Fichier | Motif |
|
||||
|---------|--------|
|
||||
| `01_CAHIER-DES-CHARGES-v1.3.md` | CDC V1.3 — remplacé par [01 V1.4](../../01_CAHIER-DES-CHARGES.md) |
|
||||
| `EVOLUTIONS_CDC.md` | Patch CDC — absorbé dans V1.4 + [12_SRS](../../12_SRS-GESTION-UTILISATEURS.md) |
|
||||
| `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) |
|
||||
| `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) |
|
||||
| `STATUS-APPLICATION.md` | Instantané daté |
|
||||
| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans |
|
||||
| `23_LISTE-TICKETS.md` | Liste Phase 1 figée — suivi = Gitea + bilans |
|
||||
| `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) |
|
||||
| `SuperNounou_*` | CDC / SSS historiques |
|
||||
| `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle |
|
||||
| `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle |
|
||||
|
||||
Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md).
|
||||
Références actives : [01 CDC V1.4](../../01_CAHIER-DES-CHARGES.md), [12 SRS users](../../12_SRS-GESTION-UTILISATEURS.md), [29 bilan 0.1.0](../../29_BILAN-VERSION-0.1.0.md).
|
||||
|
||||
Reference in New Issue
Block a user