Squash merge develop → master. - Fiche parent éditable (co-parent, PATCH fiche, GET /parents) - Fiche AM 3 onglets (PATCH fiche, rattacher/détacher enfants) - Table enfants_assistantes_maternelles + enum garde/sans_garde - Migration SQL + BDD.sql canonique - Correctifs recette : @Get() parents, DTO fiche AM, fix NIR Co-authored-by: Cursor <cursoragent@cursor.com>
305 lines
12 KiB
Markdown
305 lines
12 KiB
Markdown
# É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.
|
||
|
||
> **Document complémentaire (juin 2026)** — réflexions sur le **modèle famille / numéro de dossier**, familles recomposées, tuteurs et responsables légaux : voir **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
|
||
|
||
## 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 naissances multiples
|
||
- 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)
|
||
- Photo (optionnelle)
|
||
- Consentement pour l'utilisation de la photo
|
||
- Indication si l'enfant fait partie d'une naissance multiple (jumeaux, triplés, etc.)
|
||
|
||
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
|
||
- Indiquer si l'enfant fait partie d'une naissance multiple
|
||
- Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant
|
||
```
|
||
|
||
### 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)
|
||
* Option d'ajout d'une photo
|
||
* Option de consentement photo
|
||
* Indication si naissance multiple
|
||
* 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). |