Module — Finalisation¶

Écrans communs en aval de toutes les branches du parcours dégât des eaux : Création de compte → Récapitulatif → Analyse IA → Signature du constat → Rapport → Envoi(s) → Suivi → VOE → Confirmation. Ces écrans sont mutualisés ; ils sont dupliqués dans Figma pour chaque branche mais correspondent à un seul module en code.

Vue d'ensemble¶

flowchart LR
    A[Création de compte<br/>ou skip si connecté] --> R[Récapitulatif]
    R --> C[Analyse IA]
    C --> B[Constat<br/>+ Signature<br/>+ Rapport]
    B --> M{MED dans<br/>l'app ?}
    M -->|oui<br/>conditionnel branches DO=Oui PAS INCLU sub-B<br/>+ PARTIEL sub-B| MED[Aperçu MED<br/>+ Signature MED]
    M -->|non| D[Envoi à l'assureur]
    MED --> D
    D --> S[Suivi de l'envoi]
    S --> V[VOE]
    V --> E((Confirmation))

Ordre de l'écran Analyse IA : l'IA tourne AVANT la signature du constat (sur les données saisies par l'utilisateur via le tronc commun + la branche). L'utilisateur valide les estimations, puis seulement génère et signe le constat — pas l'inverse.

Nouveau 2026-06-09 : l'ordre Récap → IA → Signature a été clarifié après audit des 4 flowcharts utilisateur (TOUT INCLU / PAS INCLU / PARTIEL / PAS DE DO). Le diagramme ci-dessus reflète l'ordre réel. Le Récap est universel sur les 4 branches, c'est le point d'entrée du module Finalisation.

1. Création de compte (ou skip si déjà connecté)¶

L'inscription est demandée après la saisie de la déclaration, juste avant l'écran Récapitulatif. C'est un choix produit explicite : l'utilisateur ne crée son compte qu'au moment où la valeur est tangible (générer le constat, lancer l'analyse IA).

Skip si déjà connecté : si l'utilisateur est déjà authentifié (session Sanctum user active, pas guest), cette étape est automatiquement sautée par ClaimFlow.nextStep côté mobile (commit livré, cf. lib/features/claims/domain/claim_flow.dart L131-142). L'utilisateur passe directement du dernier écran du tronc commun (ou de la branche cause/travaux) vers le Récapitulatif (§2). Quand l'écran Récapitulatif aura été livré (EP-MOB-15.01), ClaimFlow.nextStep routera vers lui au lieu de retourner null.

Écrans¶

Étape	Description	Capture
1. Choix d'inscription	« Créez votre compte HomyExpert afin d'envoyer votre déclaration de sinistre et de suivre votre dossier. » + 3 CTA SSO (Apple / Google / mon adresse email) + lien « J'ai déjà un compte »
2. Formulaire email	Étape 4/4 — Comprendre le sinistre. Champs : Prénom / Nom / Adresse email / Mot de passe (avec règles 8 caractères / 1 majuscule / 1 chiffre) / Confirmation. CGU + politique de confidentialité.
3. Vérification email	« Vous avez reçu un code de vérification par email » + 6 cases vides + clavier numérique iOS + lien « Renvoyer » + CTA « Accéder à mes emails »
4. Compte créé	Coche verte + « Votre compte a bien été créé » (transition automatique)

Refs maquette : - MK:12246:23058 Choix SSO - MK:12246:23101 Formulaire - MK:12246:23122 Vérification code - MK:12246:23170 Compte créé

Spécifications complémentaires¶

Fournisseurs d'authentification : Apple SSO + Google SSO + email/mot de passe.
Règles de mot de passe : 8 caractères minimum + 1 majuscule + 1 chiffre.
Vérification email obligatoire avant de continuer (code 6 chiffres).
Le suivi des sinistres se fait sous l'identité du compte créé. La déclaration en cours est rattachée au compte au moment de la création.

2. Récapitulatif¶

Dernier écran avant l'Analyse IA — l'utilisateur revoit toutes ses réponses du parcours, regroupées par section, et peut « Modifier » chaque bloc qui ramène à l'écran source.

Statut : livré dans EP-MOB-15.01 — Écran récap éditable (ClickUp 86c9pgd17).

Architecture backend-driven (révision 2026-06-10) : le Récap consomme un endpoint backend dédié GET /api/v1/claims/{id}/recap qui retourne un payload normalisé { claim_id, sections: [{ key, title_key, edit_step, fields: [{ label_key, value }] }] }. La logique « quelles sections afficher, quels champs y mettre, vers quel step pointe le crayon » vit dans le service App\Services\Claim\RecapBuilder côté Laravel — single source of truth. Mobile et web (futur EP-WEB-16) sont des renderers purs : lookup i18n via les title_key / label_key, format des value wire (enum → libellé localisé, ISO date → format local). Garantit zéro drift entre plateformes : ajouter une section ou un field = 1 PR backend, mobile + web la voient automatiquement.

Universel sur les 4 branches TOUT INCLU / PAS INCLU / PARTIEL / PAS DE DO — confirmé par les flowcharts utilisateur 2026-06-09. Le Récap est le point d'entrée du module Finalisation et précède l'Analyse IA, jamais l'inverse.

Feature évolutive — à tenir à jour à chaque ajout produit

Le contenu du Récap s'étoffera à chaque nouveau scénario ou type de sinistre ajouté au parcours (Incendie, Vol, Bris, Tempête, ainsi que les variantes locataire bailleur / GPA multi-contractors / etc.). Le contrat produit est non-négociable : le Récap montre TOUT ce qui a été collecté — sinon l'analyse IA travaille sur des données incomplètes et l'estimation est biaisée.

Checklist obligatoire à chaque PR qui ajoute un champ métier au parcours :

Vérifier si la donnée doit apparaître au Récap (par défaut : oui).
Étendre App\Services\Claim\RecapBuilder côté backend — nouveau field dans une section existante, ou nouvelle section si la donnée est type-spécifique.
Ajouter la clé i18n + le formatter d'enum si applicable côté mobile (lib/features/claims/presentation/claim_recap_screen.dart + lib/l10n/app_fr.arb) et côté web (futur EP-WEB-16).
Étendre les tests ShowClaimRecapTest (Pest) avec le nouveau champ.
Mettre à jour la liste des sections ci-dessous (§ Sections affichées).

Toute ouverture d'un EP-BACK / EP-MOB qui ajoute des champs métier doit inclure une sous-tâche « MAJ Récap » dans son backlog. La règle est tracée côté projet via project-recap-evolutive (mémoire claude).

Sous-titre¶

« Il s'agit de la dernière étape avant l'analyse de vos dommages et l'estimation de vos indemnités. »

Sections affichées (toutes branches DDE)¶

L'écran présente toutes les sections renseignées au cours du tronc commun + de la branche cause. Chaque section a un bouton « Modifier » qui ramène à l'écran de saisie correspondant (route mobile résolue via ClaimFlow.routeOf(<step>)).

Informations du déclarant
Statut d'occupation (Propriétaire / Locataire) + sous-cas (Résidence principale, etc.)
Coordonnées du déclarant
Informations du bien
Adresse complète, ville
Type de bien (appartement / maison)
Détails du sinistre
Date de constatation
Type de sinistre (Dégât des eaux)
Biens concernés (Mon bien et celui d'un tiers / Mon bien uniquement / etc.)
Cause (Travaux / Phénomène naturel / Aucune des deux)
Détails des pièces touchées + dommages
Liste des pièces (Salon, Salle de bain, etc.)
Pour chaque pièce : Dommage n°1, n°2, … avec type + descriptions + fichiers joints
Recherche de fuite (si applicable)
Recherche effectuée ? (Oui / Non)
Si Oui : résultat (zones touchées)
Origine du sinistre (si applicable)
Type de fuite suspectée
Dommages visibles
Professionnel impliqué (si applicable)
Professionnel suspecté
Coordonnées (Nom entreprise / adresse / mail / téléphone)
Déclaration de blessures (si applicable)
Des blessés à déclarer ? (Oui / Non)
Contrat et assurance (variable selon branche cause)
Branche travaux GPA : âge du logement, GPA applicable, MED (état + courrier), Dommages-Ouvrage couvertes
Coordonnées des assureurs (RC Pro/Décennale du constructeur, Dommages-Ouvrage, multirisques) — collectées juste avant le Récap

Comportement « Modifier »¶

Le bouton « Modifier » par section délègue la nav à ClaimFlow.routeOf(stepCorrespondant). L'utilisateur revient sur l'écran de saisie, modifie sa réponse, puis le système doit savoir le ramener au Récap. Pour ça, on s'appuie sur step_history côté backend qui maintient la suite d'écrans visités et permet de reprendre exactement où on en était. Le retour au Récap se fait via le back chevron qui consulte Claim.previousStep (pas reconstruit en local).

CTA¶

Bottom CTA : « Lancer l'analyse » (= passer à §3 Analyse IA)
Bouton secondaire par section : « Modifier »

Refs maquette + ClickUp¶

T-MOB-15.01 — 86c9pgd17 — Écran récap éditable
Maquettes Figma : à compléter (sections individuelles existent par section dans Figma mais l'écran agrégé final est à confirmer en design)

3. Analyse IA¶

Le moteur HomyExpert connecte la déclaration aux contrats d'assurance de l'utilisateur et estime les dommages couverts. Tourne après le Récap et avant la génération + signature du constat : l'utilisateur peut encore ajuster sa déclaration via la sortie « Modifications possibles » avant de figer le constat.

Anciennement §3, déplacé en §2 après l'audit 2026-06-09 (Récap a pris la §2, Constat/Signature passe en §4).

Écrans¶

Étape	Description	Capture
1. Loader	Cercle de progression (ex. 72%) + « Analyse IA en cours » + sous-titre « Connexion à vos contrats… » + liste d'étapes (les libellés affichés sont des placeholders)
2. Résultats	« Résultats de l'analyse — Estimation des dommages déclarés » + Carte chiffrée (« Dommage estimé 4 200 € — Couvert à 100 % par votre contrat MRH ») + Liste des garanties activées (✓ Dégât des eaux / ✓ Mobilier endommagé / ✓ Frais d'hébergement / ⊘ Protection juridique grisée) + bouton « Modifier » (« Modifications possibles — Ajustez votre déclaration ») + CTA « Valider et générer le constat »

Refs maquette : - MK:12280:21919 Loader - MK:12280:21936 Résultats

Spécifications complémentaires¶

Cœur métier de HomyExpert : appariement automatique entre la déclaration et les contrats d'assurance de l'utilisateur, avec estimation chiffrée et identification des garanties activables.
Source des contrats : à valider côté client — connexion aux assurances par scrap / API (type Mes Données Assurance) ou saisie manuelle des contrats dans le compte utilisateur en amont.
Garanties : la liste affichée provient du contrat MRH (Multi-Risques Habitation) détecté. Items grisés = garanties absentes du contrat de l'utilisateur.
CTA Modifier : permet de revenir sur la déclaration pour ajuster avant génération définitive du constat.

4. Constat + Signature + Rapport¶

Le constat amiable est un PDF généré à partir des données de la déclaration après validation de l'analyse IA. L'utilisateur le signe électroniquement, le télécharge, puis prend connaissance du rapport de sinistre détaillé.

Écrans¶

Étape	Description	Capture
1. Aperçu PDF	« Signez votre constat. Il s'agit du document à transmettre à votre assureur. » + Aperçu PDF du constat (style « Constat amiable » français) + bouton « Signer »
2. Zone de signature	« Signature » + sous-titre « Signez le constat afin de finaliser votre déclaration. Il sera par la suite envoyé à votre assureur. » + zone tactile « Signez ici » + texte légal « En signant vous certifiez l'exactitude des informations fournies et vous engagez à informer votre assureur de toute modification » + CTA « Valider ma signature »
3. Téléchargement	« Téléchargez votre constat. Il s'agit du document à transmettre à votre assureur. » + Aperçu du constat signé + CTA « Partager le rapport » + « Suivant »
4. Rapport détaillé	« Le rapport de sinistre. Il s'agit d'une description approfondie du sinistre pouvant servir d'annexe au constat. » + Rapport PDF + CTA « Partager le rapport » + « Suivant »

Refs maquette : - MK:12280:21861 Aperçu PDF - MK:12280:21895 Zone signature - MK:12280:21872 Téléchargement - MK:12280:21884 Rapport détaillé

Spécifications complémentaires¶

Deux documents générés : (a) le constat amiable (style officiel français, 2 pages) ; (b) le rapport de sinistre (description approfondie, plus long, sert d'annexe).
Signature tactile : l'utilisateur signe au doigt dans une zone canvas. La signature est embarquée dans le PDF final.
Date et heure de signature affichées dans le PDF (« Date et heure : 09/03/2026 à 13:56 »).
Texte légal : à valider avec le service juridique côté client (responsabilité, modification ultérieure).

5. Mise en demeure (conditionnel — branches DO=Oui PAS INCLU sub-B + PARTIEL sub-B)¶

Cette section ne s'applique qu'aux branches où l'utilisateur n'a pas encore envoyé sa mise en demeure (MED) à l'entreprise responsable des travaux. Dans les sous-branches PAS INCLU « MED pas encore envoyée » et PARTIEL « MED pas encore envoyée », la MED est générée dans l'app, signée tactilement comme le constat, et envoyée par lettre recommandée à l'entreprise. La branche PAS DE DO n'a PAS de MED obligatoire (annotation flowchart « Mise en demeure non obligatoire »).

Statut code 2026-06-30 — livré 🟢 : le stub CompanyFormalNoticeStubController a été supprimé. La MED est désormais portée par 4 ClaimStep dédiés (FORMAL_NOTICE_PREVIEW, FORMAL_NOTICE_PDF_PREVIEW, FORMAL_NOTICE_SIGNATURE, FORMAL_NOTICE_DISPATCH), le modèle FormalNoticeDraft côté backend (pré-rempli depuis les sections du tronc commun + branche), une signature canvas dédiée côté mobile (package signature), un PDF Blade généré via Spatie\LaravelPdf, et l'envoi LRE via AR24. Routes finales : GET /api/v1/claims/{id}/formal-notice/draft, PUT …/formal-notice/draft, GET …/formal-notice/pdf, POST …/formal-notice/sign, POST …/formal-notice/dispatch/payment-intent. Le cron DetectUnsuccessfulFormalNoticeJob (Laravel Scheduler, daily 09:00) scanne les FormalNotice au statut SENT dont la deadline AR24 est expirée et pose data->med_overdue_triggered_at sur le dispatch parent + push best-effort vers le déclarant.

Écrans¶

Étape	Description	Capture
1. Aperçu de la mise en demeure	Aperçu PDF + sections « Identification du désordre » / « Photos » / « Coordonnées du constructeur » / « Modifications possibles » + CTA « Signer »	(à venir — Figma en cours)
2. Zone de signature MED	« Signature de la mise en demeure » + zone tactile « Signez ici » + texte légal	(à venir)
3. Confirmation MED signée	« Mise en demeure générée et signée » + aperçu PDF signé + CTA « Envoyer à l'entreprise »	(à venir)

Spécifications complémentaires¶

Source du contenu MED : pré-rempli à partir des sections du tronc commun (Identification du désordre = pièces touchées + dommages ; Photos = média uploadés ; Coordonnées du constructeur = form RC Pro/Décennale ou coords manuelles). Côté backend : modèle FormalNoticeDraft + service de templating mutualisé (source unique avec les rendus LRE / email assureur depuis le refactor 2026-06-26).
Bouton « Modifier » par section avant signature.
Signature distincte du constat : signature tactile dédiée (canvas écran FORMAL_NOTICE_SIGNATURE, package signature côté mobile), embarquée dans le PDF MED par le backend.
4 ClaimStep dédiés : FORMAL_NOTICE_PREVIEW (récap éditable) → FORMAL_NOTICE_PDF_PREVIEW (aperçu PDF Spatie\LaravelPdf) → FORMAL_NOTICE_SIGNATURE (canvas) → FORMAL_NOTICE_DISPATCH (PaymentIntent AR24 + envoi LRE).
Cron J+8 : DetectUnsuccessfulFormalNoticeJob programmé daily 09:00, scan des FormalNotice statut SENT dont la deadline AR24 est expirée, pose data->med_overdue_triggered_at sur le dispatch parent et déclenche un push best-effort vers le déclarant. Permet à la step FINALIZATION_DISPATCH_TRACKING (§7) de basculer en phase med_overdue.
Suite : après signature + envoi MED, l'utilisateur arrive directement sur §7 Suivi (où le destinataire est l'entreprise responsable). Le passage automatique au 2ᵉ envoi (DO, multirisques) est piloté côté backend via le ClaimDispatchScenarioResolver.

Cas particulier — Gate J+8 si MED infructueuse¶

Après envoi de la MED par LRE à l'entreprise : - Le user reçoit une notification in-app au moment où l'accusé de réception AR24 arrive (avec une mention « L'entreprise a 8 jours ouvrés pour répondre. Vous serez notifié·e si pas de réponse »). - Si aucune réponse à J+8 après l'envoi, trigger automatique d'un 2ème envoi vers le destinataire suivant : - Sub-branche PAS INCLU sub-B → envoi LRE à l'assureur multirisques (pour indemnisation des conséquences) - Sub-branche PARTIEL sub-B (Décla N°1 zones incluses) → envoi LRE à l'assureur Dommages-Ouvrage - Sub-branche PARTIEL sub-B (Décla N°2 zones exclues) → envoi LRE à l'assureur multirisques (pour indemnisation des conséquences) - Notification in-app au user pour l'avertir du trigger automatique.

Statut code : Dispatch::isOverdue() + legal_deadline_days + sent_at existent côté backend comme briques de base. Le job scheduler qui déclenche les envois suivants n'est pas encore écrit (zéro match MedInfructueuse, j_plus_8, addDays(8) dans app/Jobs/). Côté mobile, pas de handler in-app pour les notifications post-MED. À spec'd + coder.

6. Envoi(s) à l'assureur (variations par branche)¶

L'utilisateur choisit comment envoyer la déclaration : LRE (Lettre Recommandée Électronique via AR24, 6 € payés à AR24 à chaque envoi quel que soit le tier d'abonnement HomyExpert) ou email (gratuit, sans valeur juridique forte). Le destinataire et le nombre d'envois dépendent de la branche.

Variations par branche¶

Branche	Destinataire(s)	Mode
TOUT INCLU	Assureur Dommages-Ouvrage	Séquentiel (DO d'abord, multirisques en fallback si DO ne répond pas)
PAS INCLU sub-A (MED déjà envoyée)	Assureur multirisques	Direct
PAS INCLU sub-B (MED à effectuer)	Entreprise responsable → si infructueux J+8 → multirisques	Séquentiel avec gate J+8
PARTIEL Décla N°1 (zones incluses)	Assureur Dommages-Ouvrage	Séquentiel (DO d'abord, multirisques en fallback)
PARTIEL Décla N°2 (zones exclues)	Assureur multirisques	Conditionné par paywall Premium
PAS DE DO	Constructeur (via RC Décennale) + assureur multirisques	Parallèle — 2 envois simultanés

Écrans (gabarit commun — re-utilisé pour chaque destinataire)¶

Note : les étapes 1-3 se rejouent pour chaque destinataire (DO, multirisques, entreprise responsable, constructeur). Les écrans Suivi (§7) / VOE (§8) / Confirmation (§9) ne s'affichent qu'après le dernier envoi.

Étape	Description	Capture
1. Choix d'envoi	« Envoie de la déclaration. Lettre recommandée électronique » + 2 cartes : Envoi par email (gratuit) et Envoi par lettre recommandée électronique (« Service payant ») + encart info « L'envoi par lettre recommandée électronique a la même valeur juridique qu'une lettre papier »
2. Modal AR24 (si LRE)	« Suivie de l'envoi — Lettre recommandée électronique. Tarif de l'envoi : 6,00 € » + 3 étapes (1. Création de votre compte d'envoi / 2. Paiement sécurisé / 3. Renseigner le destinataire et envoyer) + CGU AR24 + CTA « Payer 6.00 € »
3. Récap destinataire	« Envoi de la déclaration » + carte « Destinataire : Axa France — Service Sinistres » avec Mode d'envoi / Pièces jointes (Constat + Rapport) / Objet (« Déclaration sinistre MRH-AXA-48291 ») + CTA « Confirmer l'envoi »

Refs maquette : - MK:12280:21968 Choix envoi - MK:12280:22067 Modal AR24 - MK:12280:21985 Récap destinataire

Spécifications complémentaires¶

Intégration AR24 : service tiers payant (6 €) pour la lettre recommandée électronique. Tunnel propre (création de compte AR24 + paiement sécurisé + envoi). À documenter via leur API.
Numéro de suivi LRE au format LR-FR-AAAA-XXXXXX (à confirmer avec AR24).
Email gratuit : envoi standard à l'adresse de l'assureur (sans valeur juridique forte).
Notification utilisateur : copie de la déclaration envoyée par email à l'utilisateur après chaque envoi.

7. Suivi des envois¶

Une fois tous les envois confirmés, l'utilisateur arrive sur le suivi unifié des courriers. Architecture backend-driven : le mobile rend purement le payload retourné par GET /api/v1/claims/{id}/dispatch-tracking, dont la logique vit dans App\Services\Claim\ClaimDispatchScenarioResolver. Aucune règle métier (état des cartes, libellés, bandeaux d'alerte, CTA) n'est dupliquée côté front.

Étape	Description	Capture
Suivi envoi (LRE)	« Suivi de l'envoi — Lettre recommandée électronique » + Numéro de suivi (« LR-FR-2026-084711 ») + Timeline (✓ Lettre créée / ✓ Envoi confirmé / Lettre distribuée / Accusé de réception) + Note délai juridique + CTA « Besoin d'aide ? Contacter HomyExpert » + lien « Terminer sans accompagnement »

Refs maquette : - MK:12280:22016 Suivi envoi

Scénarios + phases dynamiques (backend-driven)¶

Le résolveur expose 8 scenario_key exhaustifs, croisés avec un phase_key dynamique selon l'état de la timeline. La matrice est déclarée dans config/claim_dispatch_tracking.php.

`scenario_key`	Quand	Phases possibles
`natural_phenomenon`	Chez moi + cause = Phénomène naturel (envoi multirisques seul)	`default`
`none_cause`	Chez moi + cause = Aucune (envoi multirisques seul)	`default`
`works_no_do`	Travaux sans Dommages-Ouvrage (envoi parallèle multirisques + entreprise)	`default`
`works_do_full`	Travaux DO Tout inclus (DO d'abord, escalade multirisques à J+8)	`awaiting_do` · `do_overdue` · `escalated` · `do_acknowledged`
`works_do_partial`	Travaux DO Partiel (paywall freemium — désactivé V1)	`default`
`works_do_none`	Travaux DO Pas inclus (envoi parallèle multirisques + entreprise)	`default`
`works_gpa`	Travaux Garantie de Parfait Achèvement < 1 an (MED entreprise → DO → multirisques)	`awaiting_med` · `med_overdue` · `awaiting_do` · `do_overdue` · `escalated`
`neighbor`	Sinistre tiers / voisin / parties communes (envoi multirisques ± assureur du tiers)	`declarant_only` · `with_third_party`

Conventions de phase :

awaiting_med / awaiting_do — envoi en cours, deadline encore active
med_overdue / do_overdue — deadline expirée (J+8 MED, J+10 AR24) — posées par le cron DetectUnsuccessfulFormalNoticeJob ou par le webhook AR24
escalated — l'utilisateur (ou le système) a déclenché l'envoi suivant via l'action escalate_dispatch (cf. ci-dessous)
do_acknowledged — AR DO reçu, parcours considéré comme abouti côté plateforme
default / declarant_only / with_third_party — phases de rendu standard (pas d'escalade)

Payload `GET /dispatch-tracking`¶

Pour chaque carte, le payload contient scenario_key, phase_key, icon_kind, banner_tone, title, info_banner, cta_label, action, et la liste des recipients[] (déclarant + assureur(s) + entreprise selon scénario). Voir la section dédiée dans api-contracts.md § GET /dispatch-tracking.

Action `escalate_dispatch`¶

Quand la phase est do_overdue, le payload retourne une action kind: escalate_dispatch portant le dispatch_id du DO parent. L'appel front correspondant déclenche la création du dispatch multirisques côté backend et bascule la phase vers escalated. Pour med_overdue, l'action retournée est kind: dispatch_do (création du dispatch DO, sans dispatch_id puisqu'il n'y a pas de parent à escalader).

Spécifications complémentaires¶

État des cartes LRE vs Email : 2 états dédiés (auto_dispatched_lre, auto_dispatched_email) — utilisés selon dispatch.mode (AR24 LRE vs Email). Permet de différencier le rendu (timeline AR24 + numéro de suivi vs simple confirmation email).
Notifications push + email quand un AR est reçu côté AR24 (canal notifications, listé dans le composer dev script --queue=default,notifications,media).
Resume-aware refresh : à chaque retour foreground de l'app (AppLifecycleState.resumed), le mobile invalide automatiquement le provider claimDispatchTracking (cf. §10 Architecture).

8. Une question ? Contactez HomyExpert (optionnelle)¶

Renommé 2026-06-29 depuis « Mise en relation VOE Conseil » — l'avatar de chat factice « VOE En ligne » a été retiré au profit d'un formulaire de contact libre qui crée un ticket support par email côté équipe HomyExpert.

Étape	Description
Formulaire contact support	Titre « Une question ? Contactez l'équipe HomyExpert » + champ Sujet (input simple) + champ Message (textarea multi-ligne) + CTA « Envoyer » + lien « Terminer sans accompagnement ».

Spécifications complémentaires¶

Endpoint : POST /api/v1/claims/{claim}/contact-support (auth.dual) — payload { subject, message } → envoie un Mail\ClaimSupportRequest à l'équipe HomyExpert (Mailable brandé, footer vide). Réponse 204 No Content.
Écran mobile : ClaimContactSupportScreen (renommé depuis ClaimVoeChatScreen le 2026-06-29 — migration data réelle 2026_06_29_151517 qui réécrit toutes les valeurs FINALIZATION_VOE_CHAT en FINALIZATION_CONTACT_SUPPORT dans claims.current_step et claim_step_histories.step).
Pas de chat temps réel V1 : c'est un formulaire ticket — l'équipe répond par email hors-app.
Skip possible via le lien « Terminer sans accompagnement » sur l'écran de suivi.
Plus aucune mention SMS dans les wordings (canal SMS non livré V1, cf. mémoire feedback_no_sms_mentions).

9. Confirmation finale¶

Étape	Description	Capture
Confirmation finale	Coche verte + « Votre déclaration a bien été envoyée ! » + Note « Vous recevrez une copie de la déclaration de sinistre sur la boîte mail renseignée lors de votre inscription. » + Encart « Prochaines étapes » : 1. Examen par l'assureur (sous 2-3 jours ouvrés) / 2. Travaux de restauration (commencent après validation) + CTA « Voir le suivi du sinistre »

Refs maquette : - MK:12280:22109 Confirmation envoi

Spécifications complémentaires¶

CTA « Voir le suivi du sinistre » ramène l'utilisateur sur le détail du dossier (dashboard).
Email de confirmation envoyé en parallèle (copie PDF du constat + rapport).

Module Envoi à la DO (cas spécifique travaux GPA)¶

Module additionnel pour la branche travaux + DO=Oui : le constat doit être envoyé également à l'assureur Dommages-Ouvrage. La section Figma est nommée « à changer envoie du constat à la DO » (le wording est en cours de finalisation par le designer).

Écrans¶

Étape	Description	Capture
1. Choix d'envoi	« Envoi du constat à la DO. Lettre recommandée électronique » + identique au choix d'envoi principal (email vs LRE)
2. Récap destinataire	« Envoi de la déclaration. Lettre recommandée électronique » + carte destinataire (assureur DO)
3-4. Progression	États successifs du tunnel
5. Confirmation	Identique à la confirmation principale (« Votre déclaration a bien été envoyée »)

Refs maquette : - MK:12285:30898 Choix envoi DO - MK:12285:30915 Récap - MK:12285:31104 Confirmation

Spécifications complémentaires¶

Deux envois successifs dans certains cas : (a) constat à l'assureur multirisques de l'utilisateur, (b) constat à l'assureur Dommages-Ouvrage (uniquement si DO=Oui dans le routage). Les deux peuvent passer par AR24 (donc 2 × 6 € à payer) ou en email.
Wording « Envoi du constat à la DO » non finalisé côté design (section nommée « à changer »). À aligner côté client.

Module — Finalisation¶

Vue d'ensemble¶

1. Création de compte (ou skip si déjà connecté)¶

Écrans¶

Spécifications complémentaires¶

2. Récapitulatif¶

Sous-titre¶

Sections affichées (toutes branches DDE)¶

Comportement « Modifier »¶

CTA¶

Refs maquette + ClickUp¶

3. Analyse IA¶

Écrans¶

Spécifications complémentaires¶

4. Constat + Signature + Rapport¶

Écrans¶

Spécifications complémentaires¶

5. Mise en demeure (conditionnel — branches DO=Oui PAS INCLU sub-B + PARTIEL sub-B)¶

Écrans¶

Spécifications complémentaires¶

Cas particulier — Gate J+8 si MED infructueuse¶

6. Envoi(s) à l'assureur (variations par branche)¶

Variations par branche¶

Écrans (gabarit commun — re-utilisé pour chaque destinataire)¶

Spécifications complémentaires¶

7. Suivi des envois¶

Scénarios + phases dynamiques (backend-driven)¶

Payload GET /dispatch-tracking¶

Action escalate_dispatch¶

Spécifications complémentaires¶

8. Une question ? Contactez HomyExpert (optionnelle)¶

Spécifications complémentaires¶

9. Confirmation finale¶

Spécifications complémentaires¶

Module Envoi à la DO (cas spécifique travaux GPA)¶

Écrans¶

Spécifications complémentaires¶

Payload `GET /dispatch-tracking`¶

Action `escalate_dispatch`¶