Julien Martin
003fe6b762
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>
332 lines
16 KiB
Markdown
332 lines
16 KiB
Markdown
# Évolution — Modèle famille, responsables légaux et dossiers
|
||
|
||
**Version** : 1.1
|
||
**Date** : 16 juin 2026
|
||
**Statut** : Réflexions produit / architecture — complément au [CDC](./01_CAHIER-DES-CHARGES.md)
|
||
**Documents liés** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md)
|
||
|
||
---
|
||
|
||
## 1. Objet de ce document
|
||
|
||
Ce document **trace les réflexions** menées en 2026 sur :
|
||
|
||
- les **limites du modèle « famille / numéro de dossier »** en v1.0.0 ;
|
||
- les **contournements** acceptés pour la release **1.0.0** ;
|
||
- les **évolutions** envisagées post-1.0.0 (unités de dossier, affiliation parent–enfant, terminologie).
|
||
|
||
Il ne remplace pas le CDC : il documente l’**écart assumé** entre le modèle idéal long terme et ce qui est livré en **1.0.0**, ainsi que la **feuille de route** pour aller plus loin.
|
||
|
||
---
|
||
|
||
## 2. Modèle actuel (v1.0.0) — rappel
|
||
|
||
| Concept | Implémentation |
|
||
|--------|----------------|
|
||
| **Responsable inscrit** | Rôle applicatif `parent` + entité `parents` |
|
||
| **Second adulte** | Co-parent optionnel (`id_co_parent`) — **un seul** |
|
||
| **Enfant** | Entité `enfants` |
|
||
| **Affiliation** | Table `enfants_parents` (liens many-to-many) |
|
||
| **Dossier famille** | `dossier_famille` + `dossier_famille_enfants` (motivation, etc.) |
|
||
| **Numéro de dossier** | Format `AAAA-NNNNNN`, sur `utilisateurs` et `parents` |
|
||
| **« Famille » calculée** | Graphe : co-parent **ou** enfants partagés (`getFamilyUserIds`) |
|
||
| **Workflows** | Validation, refus, reprise : souvent **par `numero_dossier`** ou par ce graphe |
|
||
|
||
Le numéro de dossier est aujourd’hui une **aide forte** pour les cas simples (un couple, N enfants, une motivation), mais il tend à devenir **l’identifiant métier** de la famille — ce qui pose problème dans les cas complexes.
|
||
|
||
---
|
||
|
||
## 3. Limitation connue v1.0.0 — familles recomposées et multi-contextes
|
||
|
||
### 3.1 Exemple type (illustration)
|
||
|
||
```
|
||
Année 1 : Responsable M + co-responsable A → enfant α
|
||
Année 2 : Responsable M + co-responsable B → enfant β
|
||
```
|
||
|
||
Même personne **M** au centre, **deux contextes de vie** distincts. **A** n’est pas parent de β ; **B** n’est pas parent de α.
|
||
|
||
### 3.2 Autres cas couverts par la même limitation
|
||
|
||
Les exemples « maman / papa » sont **illustratifs**. La limitation s’applique **à toute configuration** :
|
||
|
||
| Configuration | Même règle |
|
||
|---------------|------------|
|
||
| Couple **HH** ou **FF** | Oui |
|
||
| **Père** avec deux partenaires et deux enfants (même ville, écarts d’âge courts) | Oui |
|
||
| **Grand-parent** en tutelle ou **tuteur légal** | Oui *(voir § 5)* |
|
||
| Recomposition, demi-fratrie, garde alternée complexe | Oui |
|
||
|
||
### 3.3 Pourquoi le modèle casse
|
||
|
||
1. **Un `numero_dossier` par user** — M ne peut pas appartenir proprement à deux unités.
|
||
2. **Un seul co-parent** par fiche `parents`.
|
||
3. **Graphe famille trop large** — M liée à A (via α) et à B (via β) → A, B et M peuvent être fusionnés en **une seule « famille »** pour validation/refus/reprise.
|
||
4. **`dossier_famille`** — une motivation / une ancre par numéro, pas deux contextes pour la même personne.
|
||
|
||
---
|
||
|
||
## 4. Décision v1.0.0 — contournement opérationnel
|
||
|
||
### 4.1 Principe
|
||
|
||
> **Le numéro de dossier reste la norme pour les cas simples, pas une obligation absolue.**
|
||
> Pour les cas trop complexes, le **gestionnaire** compose manuellement (création admin, rattachements) ou applique le contournement ci-dessous.
|
||
|
||
### 4.2 Contournement accepté pour la 1.0.0
|
||
|
||
**Créer un second compte** avec une **adresse e-mail distincte** et un **second dossier** (second `numero_dossier`).
|
||
|
||
| Dossier | Compte | Co-responsable | Enfant |
|
||
|---------|--------|----------------|--------|
|
||
| 1 | `m.personne@…` | A | α |
|
||
| 2 | `m.personne.famille2@…` *(ou alias)* | B | β |
|
||
|
||
**Conséquences assumées :**
|
||
|
||
- Une **même personne physique** peut avoir **deux identités** dans l’app.
|
||
- Pas de vue unifiée « une personne, deux contextes » en v1.0.0.
|
||
- Procédure interne gestionnaire recommandée (note « même personne physique »).
|
||
- Emails distincts **volontaires** (alias, +tag, boîte dédiée selon infra mail).
|
||
|
||
### 4.3 Nuance — inscription publique
|
||
|
||
Si le **dossier 1** existe déjà avec l’email de P (titulaire ou co-parent), une **2ᵉ inscription publique** où l’on saisit **le même email** comme co-parent est **bloquée** (*email déjà utilisé*).
|
||
|
||
Le **2ᵉ dossier** passe donc surtout par :
|
||
|
||
- **création / composition par le gestionnaire** (tickets admin #129+), ou
|
||
- **2ᵉ email** dès le départ pour la même personne physique.
|
||
|
||
### 4.4 Piste cible — parcours gestionnaire « famille complexe » *(réflexion juin 2026)*
|
||
|
||
Le contournement § 4.2 reste valable en **v1.0.0**. La **solution produit visée** pour les cas complexes est différente :
|
||
|
||
> **Seul le gestionnaire** dispose d’un **parcours de création dédié** permettant de constituer une configuration avec **plus de deux responsables** (parents, co-parents, tuteurs…) **sans** se limiter au seul champ `co_parent`, en s’appuyant sur **`enfants_parents`** comme vérité de visibilité.
|
||
|
||
**Exemple M / A / B / α / β :**
|
||
|
||
| Compte | Enfants visibles / rattachés |
|
||
|--------|------------------------------|
|
||
| **M** (un seul compte, un email) | α **et** β |
|
||
| **A** | α uniquement |
|
||
| **B** | β uniquement |
|
||
|
||
```
|
||
α ─── M ─── β
|
||
│ │
|
||
A B
|
||
```
|
||
|
||
- **M** voit et gère **ses deux enfants** sur **le même compte** (plus besoin d’un 2ᵉ email pour M).
|
||
- **A** et **B** ne voient **que** l’enfant qui leur est rattaché via `enfants_parents` — pas de fusion « famille » qui mélange A et B.
|
||
- Le parcours n’est **pas** proposé à l’inscription publique (trop error-prone) : **réservé au gestionnaire** (#129+ ou ticket dédié « famille complexe »).
|
||
|
||
**Conséquences techniques (post-1.0.0) :**
|
||
|
||
1. **Visibilité** : filtrer listes, fiches et actions parent par **liens `enfants_parents`**, pas par `getFamilyUserIds` / co-parent.
|
||
2. **Workflows** (validation, refus, reprise) : périmètre par **enfant** ou **soumission**, pas par graphe familial élargi.
|
||
3. **`co_parent`** : reste utile pour le cas simple (couple + N enfants communs) ; **insuffisant seul** pour les cas complexes — le gestionnaire compose les liens enfant par enfant.
|
||
4. **Numéro de dossier** : optionnel ou secondaire ; peut rester sur M ou sur une « unité » admin, sans imposer un numéro par co-responsable.
|
||
|
||
*Détail : § 7.5.*
|
||
|
||
---
|
||
|
||
## 5. Terminologie — « parent » aujourd’hui, qualification demain
|
||
|
||
### 5.1 v1.0.0
|
||
|
||
- Rôle technique : **`parent`** pour tout responsable inscrit (y compris tuteur, grand-parent tutrice, etc.).
|
||
- UI : « Parent 1 », « co-parent », parfois exemples maman/papa — **pas de statut juridique distinct**.
|
||
|
||
### 5.2 Évolution post-1.0.0 (piste)
|
||
|
||
Séparer deux niveaux :
|
||
|
||
| Niveau | Évolution |
|
||
|--------|-----------|
|
||
| **Rôle applicatif** | Conserver `parent` = « responsable du dossier » (auth, API) |
|
||
| **Qualification métier** | Nouveau champ, ex. `qualite_responsable` / `lien_avec_enfant` |
|
||
|
||
**Valeurs possibles (exemples)** : parent biologique ou adoptif, co-parent, tuteur légal, grand-parent exerçant la garde, autre responsable légal.
|
||
|
||
**Emplacement recommandé** : sur le **lien** `enfants_parents` (par enfant), pas seulement sur le user global.
|
||
|
||
**UI** :
|
||
|
||
- Libellés neutres : « Responsable 1 / 2 », « 2ᵉ responsable » ;
|
||
- **Combobox** pour qualifier le lien (admin + éventuellement inscription).
|
||
|
||
---
|
||
|
||
## 6. Évolutions UI / fonctionnelles liées (backlog)
|
||
|
||
Réflexions dashboard admin / gestionnaire (complément CDC §4.5.2–4.5.3).
|
||
|
||
> **Statut implémentation (juin 2026)** : §6.1 et §6.2 **en cours de livraison** (tickets #130–#131, #115–#116, #137–#138). §6.3 reporté post-1.0.0 (#129).
|
||
|
||
### 6.1 Fiche parent (#131)
|
||
|
||
- Modale **éditable** dès l’ouverture (pas lecture seule + « Modifier » factice).
|
||
- **Retirer l’ID** UUID ; option : **n° de dossier** en lecture seule.
|
||
- **Statut** en combobox (règles métier à cadrer vs validation/refus #110).
|
||
- Bas de modale :
|
||
- `Nombre d'enfants : N` (lecture seule) ;
|
||
- **Liste des prénoms/noms** (cadre) — consultation, clic → fiche enfant (#138).
|
||
|
||
### 6.2 Affiliation parent ↔ enfant (#115, #116, #138)
|
||
|
||
- **Vérité métier** : `enfants_parents`.
|
||
- **Modifier l’affiliation** ≠ modifier le téléphone : gestion des **liens** (détacher / rattacher), avec garde-fous :
|
||
- ne pas supprimer l’enfant pour retirer un lien ;
|
||
- au moins un responsable par enfant ;
|
||
- prudence sur fusion « famille » et co-parents.
|
||
- **Création enfant** : prioritaire depuis **fiche parent** (contexte famille) ; onglet **Enfants** (#137) pour vue globale + rattachement.
|
||
|
||
### 6.3 Création admin sans numéro (tickets #129+)
|
||
|
||
Le gestionnaire doit pouvoir **tout créer** depuis l’interface ; le numéro reste **généré si utile**, **optionnel** si le cas est trop complexe — **objectif post-1.0.0** (unité de dossier).
|
||
|
||
---
|
||
|
||
## 7. Évolution structurelle post-1.0.0 — « unité de dossier »
|
||
|
||
### 7.1 Principe cible
|
||
|
||
| Aujourd’hui | Cible |
|
||
|-------------|--------|
|
||
| `numero_dossier` = clé de la famille | **Liens parent↔enfant** = vérité |
|
||
| Famille déduite du graphe | **Unité de dossier** = regroupement **optionnel** |
|
||
| Un numéro par inscription | Numéro **optionnel** ; plusieurs unités par personne possibles |
|
||
|
||
### 7.2 Exemple cible (cas M / A / B) — deux approches
|
||
|
||
**Approche A — unités de dossier séparées** *(piste initiale § 7)* :
|
||
|
||
```
|
||
Unité 1 : numero 2026-000021 — M, A, α
|
||
Unité 2 : sans numéro (ou 2026-000089) — M, B, β
|
||
```
|
||
|
||
M appartient à **deux unités** ; A et B ne partagent pas la même unité. Peut impliquer **deux contextes de connexion** ou une agrégation côté M.
|
||
|
||
**Approche B — parcours gestionnaire « famille complexe »** *(préférée, § 4.4)* :
|
||
|
||
```
|
||
Compte M → enfants α, β
|
||
Compte A → enfant α
|
||
Compte B → enfant β
|
||
(liens enfants_parents ; pas de fusion A↔B)
|
||
```
|
||
|
||
- **Un seul compte pour M** avec **les deux enfants**.
|
||
- **A** et **B** isolés sur **leur** enfant respectif.
|
||
- Création **uniquement** par le gestionnaire ; inscription publique inchangée (couple + co-parent classique).
|
||
|
||
Les deux approches supposent de **cesser de déduire une « famille » unique** pour les workflows lorsque les liens enfant par enfant divergent. L’approche B maximise l’UX du responsable central (M) sans dupliquer son identité.
|
||
|
||
### 7.5 Parcours gestionnaire — création « famille complexe »
|
||
|
||
#### 7.5.1 Objectif
|
||
|
||
Permettre au **gestionnaire** de monter un dossier où :
|
||
|
||
- **N responsables** (≥ 2, parents ou tuteurs) sont créés ou rattachés ;
|
||
- chaque enfant est lié **explicitement** à un ou plusieurs responsables via `enfants_parents` ;
|
||
- un responsable (ex. **M**) peut être lié à **plusieurs enfants** dont les **autres** responsables (A, B) ne partagent **pas** la garde.
|
||
|
||
#### 7.5.2 Règles produit
|
||
|
||
| Règle | Détail |
|
||
|-------|--------|
|
||
| **Accès** | Parcours **gestionnaire uniquement** (dashboard), pas inscription publique |
|
||
| **Responsables** | Création ou rattachement de comptes `parent` ; qualification future sur le lien (§ 5) |
|
||
| **Visibilité** | Chaque responsable ne voit que **ses** enfants (liens `enfants_parents`) |
|
||
| **Co-parent UI** | Ne pas forcer « Parent 1 + co-parent unique » ; composition libre côté staff |
|
||
| **Garde-fous** | Au moins un responsable par enfant ; pas de suppression enfant pour retirer un lien |
|
||
|
||
#### 7.5.3 Esquisse du parcours UI (gestionnaire)
|
||
|
||
1. **Créer ou identifier** le responsable principal (ex. M).
|
||
2. **Ajouter d’autres responsables** (A, B, tuteur…) — comptes distincts.
|
||
3. **Créer les enfants** (α, β…) et, pour chaque enfant, **cocher les responsables** rattachés.
|
||
4. **Motivation / dossier** : texte global ou par enfant (à cadrer).
|
||
5. **Validation** : par soumission ou par enfant, sans valider « toute la famille » d’un coup si A et B ne doivent pas être fusionnés.
|
||
|
||
#### 7.5.4 Impacts techniques majeurs
|
||
|
||
| Domaine | Changement |
|
||
|---------|------------|
|
||
| **Auth / API parent** | `GET` enfants, dashboard parent : filtre `enfants_parents` pour l’utilisateur courant |
|
||
| **`getFamilyUserIds`** | Ne plus utiliser pour visibilité parent ; réservé au cas simple ou deprecated progressivement |
|
||
| **Validation / refus** | Périmètre enfant ou responsable, pas fusion A+B via graphe |
|
||
| **Reprise (#112)** | Token / périmètre = enfants liés au compte refusé, pas toute la composante connexe |
|
||
| **Admin (#115–#138)** | Prérequis : rattachement/détachement déjà en place ; ce parcours **compose** ces briques |
|
||
|
||
#### 7.5.5 Lien avec v1.0.0
|
||
|
||
| Phase | Comportement |
|
||
|-------|--------------|
|
||
| **v1.0.0** | Contournement § 4.2 (2ᵉ email M) + composition manuelle gestionnaire (#115–#138) |
|
||
| **Post-1.0.0** | Parcours § 7.5 + refonte visibilité / workflows |
|
||
|
||
### 7.3 Impacts workflows
|
||
|
||
| Flux | Adaptation future |
|
||
|------|-------------------|
|
||
| Validation / refus (#110) | Par **enfant / soumission**, pas par graphe global |
|
||
| Reprise (#112) | Périmètre = enfants liés au compte, pas composante connexe |
|
||
| Liste « à valider » | Par soumission ou par enfant |
|
||
| Recherche gestionnaire | Numéro **ou** nom **ou** enfant |
|
||
| Visibilité parent | **Uniquement** enfants via `enfants_parents` (approche B § 7.2) |
|
||
|
||
### 7.4 Migration
|
||
|
||
- **Court terme** : contournement § 4 + tickets admin.
|
||
- **Moyen terme** : table **unité de dossier**, `numero_dossier` nullable.
|
||
- **Long terme** : workflows branchés sur l’unité.
|
||
- Dossiers **existants** (couple + enfants) : une unité = un numéro → **comportement actuel préservé**.
|
||
|
||
---
|
||
|
||
## 8. Tickets Gitea associés
|
||
|
||
| Ticket | Sujet |
|
||
|--------|--------|
|
||
| #110 | Refus dossier (token reprise) — livré |
|
||
| #112 | Reprise après refus — livré |
|
||
| #115 / #116 | Rattachement parent — backend / front |
|
||
| #129+ | Création dossier admin (parent / AM) |
|
||
| #131 | Fiche parent éditable (dashboard) |
|
||
| #137 | Onglet Enfants — liste globale |
|
||
| #138 | Fiche enfant + liste dans fiche parent |
|
||
| *(à créer)* | Epic « Unité de dossier / numéro optionnel » |
|
||
| #139 | **Parcours gestionnaire « famille complexe »** (§ 7.5) — N responsables, visibilité par enfant |
|
||
| *(à créer)* | Qualification responsable légal (combobox sur lien enfant) |
|
||
|
||
---
|
||
|
||
## 9. Formulation type — release notes / doc gestionnaire (v1.0.0)
|
||
|
||
> **Familles recomposées ou responsabilités multiples**
|
||
> Une même personne ne peut pas gérer proprement deux unités familiales distinctes (recompositions, plusieurs co-responsables successifs, tuteur/GP pour plusieurs contextes) avec **un seul compte**.
|
||
> **Contournement v1.0.0** : second compte avec **email distinct** et second numéro de dossier.
|
||
> S’applique à **tous les responsables inscrits** (couples HH/FF, tuteurs, grands-parents, etc.).
|
||
> **Évolution post-1.0.0** : parcours **gestionnaire** « famille complexe » (un compte M, enfants α+β ; A et B limités à leur enfant) ; visibilité par `enfants_parents` ; workflows sans fusion graphe familial.
|
||
|
||
---
|
||
|
||
## 10. Historique des mises à jour
|
||
|
||
| Date | Auteur | Modification |
|
||
|------|--------|--------------|
|
||
| 2026-06-16 | Équipe / session produit | Création — synthèse réflexions famille, tutelle, v1.0.0 vs post-1.0.0 |
|
||
| 2026-06-16 | Implémentation ch.6 | Back : `PATCH /parents/:id/fiche`, attach/detach enfant. Front : modale parent éditable, onglet Enfants, fiche enfant |
|
||
| 2026-06-16 | Réflexion produit | § 4.4 / § 7.5 — parcours gestionnaire famille complexe : M un compte (α+β), A/B visibilité restreinte par enfant |
|
||
|
||
---
|
||
|
||
*Ce document sera enrichi au fil des décisions. Pour les décisions formelles archivées, voir aussi [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md).*
|