Documentation fonctionnelle — Phase 1

Vue d’ensemble

Protéger ses Enfants est une plateforme SaaS de planification successorale. La Phase 1 (MVP France) couvre le parcours de bout en bout : situation familiale et patrimoniale, simulation, aperçu gratuit (~15 %), déblocage payant du rapport complet (49 EUR), puis mise en relation notaire pour les cas complexes.

Structure familiale (parents et utilisateur connecté)

Chaque membre de la famille (parent1, parent2, enfant, ex-conjoint, tuteur, beau-parent) est nommé par son prénom (first_name). Le membre parent qui correspond à l’utilisateur connecté est marqué par l’indicateur is_self.

• first_name : prénom du membre (obligatoirement non vide quand fourni, max 100 caractères, espaces superflus supprimés, échappement anti-XSS).
• is_self : booléen identifiant le parent (parent1 ou parent2) qui est l’utilisateur connecté ; rejeté (422) sur un enfant ou tout autre type de membre.
• Règle au plus un is_self : un seul membre par famille peut porter is_self=true (validation applicative + index unique partiel en base) ; sinon 422.
• Mise à jour protégée par la propriété de la famille (Family.user_id) — aucune fuite IDOR.
• POST/PATCH /api/v1/family/{family_id}/members — création et mise à jour des membres avec ces champs.
• Saisie (assistant famille, étape « Situation maritale ») : une sous-section « Les parents » collecte le prénom du parent 1 et, si marié(e)/pacsé(e), du parent 2.
• Désignation « C’est moi » : choix exclusif (radiogroup accessible) entre parent 1 et parent 2 ; en l’absence de conjoint, c’est toujours le parent 1 (titulaire du compte).
• Validation côté client alignée sur le backend : prénom non vide quand renseigné (max 100), choix « c’est moi » unique. Les saisies sont incluses dans la sauvegarde brouillon (localStorage) et envoyées au backend (first_name + is_self).
• Affichage dans l’interface : les prénoms saisis remplacent partout les libellés génériques « Parent 1 / Parent 2 » — choix du scénario au lancement (« Décès de Marie »), résumé de succession, défunt et tableau des bénéficiaires de l’écran de résultats, export CSV, et structure familiale du tableau de bord.
• Mention « (vous) » : le parent correspondant à l’utilisateur connecté (is_self) est suivi du texte explicite « (vous) » — repli sur « Parent 1 / Parent 2 » si aucun prénom n’est renseigné, et distinction jamais portée par la couleur seule (accessibilité WCAG).

Tunnel freemium (preview → paiement → rapport)

• Preview gratuit (~15 %) : résumé patrimonial, chronologie, points d’attention et 2 premiers bénéficiaires ; sections suivantes floutées.
• Paiement (49 EUR) : CTA « Débloquer le rapport complet » → session Stripe Checkout ; le webhook Stripe positionne report_unlocked=true.
• Rapport complet : tous les bénéficiaires, fiscalité, recommandations, bases légales, export PDF et CSV.

Panel d’administration

Back-office /admin/* réservé au rôle ADMIN. Configuration runtime sans redéploiement : secrets (Stripe, SMTP, OAuth, Claude API) saisis par formulaire et stockés chiffrés en base — jamais en variable d’environnement.

• /admin/settings — SMTP, Stripe, OAuth Google/Apple, clé Claude API, prix par pays
• /admin/notaires — gestion des partenaires notaires (CRUD, filtres, statistiques)
• /admin/feature-flags — activation/désactivation des fonctionnalités en temps réel

Parcours notaire

Score de complexité pondéré (famille recomposée +3, mineurs +2, immobiliers multiples +2, patrimoine >500 000 EUR +2, régime non standard +1, ex-conjoints multiples +2). Un score ≥ 5 recommande un notaire.

• GET /api/v1/simulations/{id}/complexity — score + critères déclencheurs
• POST /api/v1/simulations/{id}/refer-notary — génération + envoi du dossier au partenaire le plus proche
• Suivi du statut (en attente → envoyé → accepté/refusé) sur l’écran /notaire
• Dossier notaire et rapports PDF personnalisés : prénoms des parents (repli « Parent 1 / Parent 2 » si absent), mention « (vous) » pour l’utilisateur connecté, en-tête « Demandeur (utilisateur) ». HTML échappé (Jinja2 autoescape / markupsafe), montants et logique inchangés.

Timeline interactive des jalons enfants

L’écran /jalons visualise les jalons clés par enfant : 16 ans, majorité (18 ans), fin d’études estimée (25 ans) et période de minorité sous tutelle.

• Statbar de synthèse : nombre d’enfants, prochain jalon, minorité cumulée, fenêtres à risque
• Frise horizontale par enfant (axe 0 → 27, segment minorité/tutelle, marqueurs 16/18/25, repère « Aujourd’hui »)
• Tableau dense filtrable par enfant ou par « à risque » avec conséquence juridique

Emails transactionnels

Envoi via SMTP (configuré dans le panel admin), templates HTML Jinja2 avec auto-échappement (anti-XSS). Chaque envoi est journalisé ; fallback silencieux si SMTP non configuré.

• Bienvenue — à l’inscription
• Réinitialisation du mot de passe — sur demande
• Confirmation de paiement — après déblocage du rapport (lien inclus)
• Dossier notaire envoyé — mise en relation notaire

Conformité RGPD (cookies, export, suppression)

• Bannière de consentement cookies au premier accès (analytics uniquement, hébergés UE) ; choix journalisé
• Export des données : GET /api/v1/users/data (droit d’accès et portabilité, art. 15 et 20)
• Suppression de compte : DELETE /api/v1/users/delete par anonymisation, en deux étapes (art. 17)
• Page /mes-donnees accessible depuis le tableau de bord
• Hébergement exclusif UE, chiffrement TLS 1.3 (transit) et AES-256 (at-rest)