Cycle de vie d'une offre

Fonctionnement

Une demande d’offre passe par 20 statuts, nommés ici en français ; le courtier voit à la place une étape calculée (voir le Glossaire). Le tableau « Correspondance technique » en bas de page donne le nom de chaque statut dans le code.

Une demande d’offre contient des offres ; chaque offre a des paiements et, après émission, une police. Chacun a ses propres statuts.

stateDiagram-v2
    state "Brouillon" as Draft
    state "Offre chiffrée" as Priced
    state "En revue" as InReview
    state "Approuvée" as Approved
    state "Refusée" as Declined
    state "Offre expirée" as QuoteExpired
    state "Paiement en attente" as PaymentPending
    state "Paiement confirmé" as PaymentConfirmed
    state "Contrat" as Contract
    state "Police émise" as PolicyIssued
    state "Annulée" as Cancelled
    [*] --> Draft
    Draft --> Priced : entreprise identifiée, risque ok, offre calculée
    Draft --> InReview : secteur refusé, mauvaise réponse, prix sur mesure
    InReview --> Approved : l'admin approuve
    InReview --> Declined : l'admin refuse
    Approved --> Priced : offre calculée
    Priced --> QuoteExpired : offre envoyée hors validité, tâche de nuit
    QuoteExpired --> Priced : recalculée
    Priced --> PaymentPending : paiement ouvert
    PaymentPending --> Priced : paiement échoué, retour forcé
    PaymentPending --> PaymentConfirmed : facture Stripe payée
    PaymentConfirmed --> Contract : générer le contrat
    PaymentConfirmed --> PolicyIssued : émission automatique
    Contract --> PolicyIssued : signé
    Priced --> Cancelled : l'admin clôt

    classDef status fill:#9ce6ff,stroke:#2c97bb,color:#1c4657
    classDef done fill:#b3e65f,stroke:#6f9a24,color:#2c4300
    classDef problem fill:#ffb575,stroke:#b8742f,color:#5a2d00
    class Draft,Priced,InReview,Approved,PaymentPending,PaymentConfirmed,Contract status
    class PolicyIssued done
    class Declined,QuoteExpired,Cancelled problem

Le diagramme regroupe des statuts : « Brouillon » couvre Brouillon, Entreprise identifiée et Risque évalué ; « En revue » couvre En attente de revue manuelle, En attente de revue et En revue ; « Contrat » couvre Contrat généré et Signée. Deux passages seulement envoient un email au client : le refus envoie « Demande refusée » (uniquement depuis l’action admin « Refuser ») et l’émission de la police envoie « Police active » (pas sur le chemin DocuSign, voir Emails). Le statut « Prix communiqué » est omis : l’action admin « Envoyer l’offre » l’écrit depuis « Offre chiffrée » ou « Approuvée ».

Comment naît une offre

Quatre entrées convergent vers une offre chiffrée, valable 30 jours sauf si une revue intervient : le parcours public et le lien d’un courtier (même parcours, courtier imposé) sont décrits dans Parcours public d’une offre, l’assistant courtier dans Offre créée par un courtier.

Revue manuelle et transmission à un courtier

Rien n’est refusé automatiquement : un « refus » d’éligibilité ou une réponse de risque bloquante met la demande en « En attente de revue manuelle », un prix sur mesure la met en « En attente de revue ». Le prospect voit une page de statut et l’équipe ne reçoit ni email ni Slack (voir Emails). Le déroulé complet est dans Revue manuelle et prix sur mesure. La reprise par un courtier de l’annuaire est décrite dans Courtier de l’annuaire et reprise.

Règles et pièges

Les regroupements de statuts (clos, payé, en revue) sont définis avec les statuts eux-mêmes, pas dans un service à part. Un nouveau statut doit être placé dans le bon groupe. L’étape affichée au courtier se déduit du statut, de la date d’archivage, de l’envoi ou non de l’offre et du remplissage du chiffre d’affaires et des garanties.
Une offre expirée n’est pas close : le courtier la voit archivée mais Inqase peut la recalculer. Le statut est posé par la tâche de nuit de 02:00 (offre envoyée dont la validité est dépassée, 30 jours après le chiffrage) et à la volée quand le client tente de payer une offre expirée.
Le système refuse un changement de statut absent de la liste des suivants autorisés. Un changement forcé contourne cette liste et est journalisé ; il sert au retour à « Offre chiffrée » après un échec de paiement (seulement si aucun autre paiement n’est ouvert) et pour rouvrir une offre annulée en brouillon. Le formulaire d’édition admin contourne aussi la liste.
Rien n’est refusé automatiquement : un « refus » d’éligibilité et des réponses de risque ratées vont en revue manuelle. Seul un admin peut refuser une demande. Seule l’action « Refuser » du pipeline envoie l’email de refus ; le formulaire d’édition admin non.
Une offre est acceptée quand le paiement est reçu, pas au clic sur « payer » : voir offre acceptée au paiement. Les autres offres du même produit passent en « Rejetée » et leurs paiements ouverts en « Annulé ».
Une offre devient payable quand elle passe de « Offre chiffrée » à « Paiement en attente » ; le paiement est refusé sur une offre close ou expirée.
Une police n’expire jamais : le renouvellement ajoute une période d’assurance. Seul un litige Stripe perdu annule une police. Voir Polices et renouvellements.
Particularités des entrées : un courtier annuaire (non partenaire) ne reçoit aucun email pour un simple choix ; le cabinet d’un courtier partenaire reçoit un email « nouveau prospect » dès qu’une offre est calculée pour la première fois. Une offre créée par un courtier ne notifie aucun prospect. Une demande de transmission ne peut être faite qu’une fois.

Pourquoi : les groupes vivent avec les statuts parce qu’un service dédié n’ajoutait qu’une couche.

Statuts qu’aucun code n’atteint

« Refusée pour inéligibilité » : l’éligibilité route vers la revue à la place.
« Offre acceptée » : il ne reste que des lecteurs (l’acceptation se fait au paiement). Les anciennes données et les modifications admin manuelles peuvent encore le porter.
« Refusée par la souscription » : le contrôle des réponses de risque ne la pose que s’il déclare un refus, ce qu’il ne fait jamais ; un admin peut la poser à la main.
Offre « Expirée » et « Convertie » : l’expiration met la demande en « Offre expirée ».
Police « En attente », « Suspendue », « Expirée » : lus dans l’affichage et les écouteurs, jamais écrits.
Email « Remis » et cible de scan courtier « En cours d’analyse » : déclarés, jamais écrits.

Où dans le code

app/Enums/QuoteRequestStatus.php
app/Http/Presenters/BrokerDossierPresenter.php
app/Services/PricingService.php

Questions ouvertes

Simplification des statuts (acceptée, pas faite) : un plan de nettoyage daté du 2026-10-06 (absent des dépôts, non vérifié) vise 17 statuts en fusionnant « Offre acceptée », « Prix communiqué » et les statuts de revue. Il en existe toujours 20 ; chaque fusion exige une migration de données et des groupes mis à jour.
Quel écran doit annuler une police pour non-paiement ou à la demande du client ? Aujourd’hui seul un litige perdu le fait.
Les deux commandes de renouvellement (demande de déclaration, traitement des échéances) ne sont pas planifiées (en attente de la validation Hiscox), donc aucun renouvellement ne tourne seul.

Correspondance technique

Nom courant	Valeur dans le code
Brouillon, Entreprise identifiée, Risque évalué	`draft`, `company_identified`, `risk_assessed`
Offre chiffrée	`priced`
En attente de revue manuelle, En attente de revue, En revue	`awaiting_manual_review`, `pending_review`, `in_review`
Approuvée, Refusée	`approved`, `declined`
Refusée par la souscription, Refusée pour inéligibilité	`declined_by_underwriting`, `declined_by_eligibility`
Paiement en attente, Paiement confirmé	`payment_pending`, `payment_confirmed`
Contrat généré, Signée, Police émise	`policy_generated`, `signed`, `policy_issued`
Annulée, Prix communiqué, Offre acceptée, Offre expirée	`cancelled`, `pricing_provided`, `quote_accepted`, `quote_expired`
Offre rejetée, expirée, convertie	`QuoteStatus::Rejected`, `Expired`, `Converted`
Police en attente, suspendue, expirée	`PolicyStatus::Pending`, `Suspended`, `Expired`
Tâche de nuit d’expiration	`quotes:expire-sent`
Commandes de renouvellement	`renewals:request-declarations`, `renewals:process-due`
Demande d’offre, offre, police	`QuoteRequest`, `Quote`, `Policy`