petitspas/docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md

É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
Documents liés : EVOLUTIONS_CDC.md, 24_DECISIONS-PROJET.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.