# É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).*