Décisions

Conditions figées sur la police

2026-05-21

Contexte. Les conditions générales et particulières, la fiche d’information produit (IPID) et les mentions légales changent selon la version. Un client doit retrouver exactement les documents qu’il a signés.

Décision. À l’émission, la police fige la version de chaque type de document du produit. Une version publiée plus tard ne modifie jamais une police existante.

Conséquences.

Ajouter un type de document oblige à le déclarer à deux endroits : la liste des types et la liste des fichiers figés.
Les anciennes polices gardent leurs anciens fichiers, qui doivent rester disponibles dans le stockage.
L’extraction des conditions du produit doit être relancée pour chaque nouvelle version.

Code. app/Support/ProductTerms.php

Renouvellement par période de police

2026-05-26

Contexte. Le premier renouvellement copiait la police et marquait l’ancienne « renouvelée ». Cela dupliquait les données et cassait l’historique d’une police belge reconduite tacitement.

Décision. Une police est unique pendant toute sa vie. Chaque renouvellement ajoute une période de police, avec une prime recalculée sur le chiffre d’affaires que le client redéclare, demandé 30 jours avant l’échéance.

Conséquences.

Plus de copie de police ni de statut « renouvelée » : toute lecture de la période en cours passe par la période de police.
Les deux commandes de renouvellement (demande de déclaration, traitement des échéances) ne sont pas planifiées : le renouvellement est manuel aujourd’hui.
Le prix de l’abonnement Stripe n’est pas mis à jour après un renouvellement, en attente de la validation de Hiscox.

Code. app/Services/RenewalService.php

Point d’entrée unique des statuts

2026-05-26

Contexte. Les changements de statut faits directement produisaient des demandes incohérentes : police générée sans offre acceptée, prime modifiée après acceptation.

Décision. Tout changement de statut passe par un point d’entrée unique, qui n’autorise que les passages prévus. Les forçages par un admin sont journalisés avec l’ancien et le nouveau statut. Un passage manuel vers un statut payé (sauf « paiement confirmé ») exige une offre acceptée.

Conséquences.

Un passage interdit est refusé avec une erreur.
Le forçage par un admin et la création directe en brouillon restent des exceptions acceptées.
Les nouvelles règles de parcours se déclarent avec les statuts, jamais dans les écrans.

Code. app/Models/QuoteRequest.php

Bordereau maître Hiscox

2026-05-27

Contexte. Hiscox exige son format maître multi-branches, pas un simple CSV. Les avenants en cours de période doivent apparaître comme des lignes distinctes.

Décision. Le bordereau s’exporte dans le modèle Excel maître de Hiscox. Une ligne d’avenant porte la variation de prime et de commission calculée au prorata depuis la date d’effet, négatifs permis, avec le nouveau chiffre d’affaires (convention confirmée par le CTO de Hiscox).

Conséquences.

Le modèle Excel fait partie du dépôt et doit suivre les changements de Hiscox.
Les chaînes d’avenants sont calculées au prorata depuis l’échéance d’origine, donc elles s’additionnent.
Les totaux d’une période peuvent diminuer après un avenant négatif.

Code. app/Services/BordereauExporter.php

Snapshot des réponses de risque

2026-05-30

Contexte. Les questions de risque varient selon le produit et évoluent. Les intégrer au contrat DocuSign alourdissait la signature et figeait une structure instable.

Décision. À l’émission, les questions et les réponses, dans la langue du contrat, sont copiées dans la police, pour l’audit seulement. Le contrat s’appuie sur la déclaration sur l’honneur.

Conséquences.

Les questions peuvent évoluer sans toucher au contrat.
Cette copie n’est pas interrogeable finement.
Une traduction manquante bloque la copie, donc l’émission échoue bruyamment.

Code. app/Services/PolicyService.php

Commissions à l’encaissement

2026-06-25

Contexte. Compter les commissions à la souscription surestime ce que le courtier peut réclamer tant que le client n’a pas payé.

Décision. Les commissions sont comptées sur ce qui est encaissé. Un relevé mensuel par courtier regroupe les lignes, puis il est approuvé et payé.

Conséquences.

Une facture impayée ou un remboursement réduit le relevé en cours ou le suivant, par des lignes négatives de reprise.
Un relevé ne peut pas être payé sans accord de courtage au dossier.
Une commande de reconstruction doit pouvoir rejouer l’historique, et elle n’est pas planifiée.

Code. app/Services/BrokerCommissionStatementService.php

Cœur neutre vis-à-vis des produits

2026-09-30

Contexte. La plateforme est partie d’un seul produit, la cyber. Ajouter la responsabilité civile imposait de retirer les hypothèses cyber du cœur.

Décision. Chaque produit est décrit par sa propre configuration. Les documents, la déclaration de tarification et les garanties sont fournis par produit.

Conséquences.

Un nouveau produit, c’est une configuration et du code dédié, pas des conditions dans les règles communes.
La fiche client est partagée, un bloc propre au produit s’affiche sur la police.
La responsabilité civile reste désactivée, et le bordereau Hiscox ne doit pas changer.

Code. app/Enums/ProductType.php

Isolation des courtiers sur une société partagée

2026-10-02

Contexte. Une société est partagée entre courtiers, qui peuvent être concurrents. Un courtier ne doit jamais voir les contacts ni les demandes de l’autre.

Décision. L’accès d’un courtier est borné à ce qui le concerne : il ne voit que les sociétés et les contacts qu’il connaît. Modifier une société exige une police ou une offre envoyée par ce courtier. Un test garde la règle.

Conséquences.

Toute lecture faite pour un courtier doit appliquer ce filtre : un filtre oublié fait fuiter des données entre concurrents.
Un contact que le courtier n’a pas créé est en lecture seule pour lui.
Ces filtres sont lourds pour la base, donc toute modification demande le test de garde.

Code. tests/Feature/Broker/SharedCompanyGuardTest.php

Offre acceptée au paiement

2026-10-06

Contexte. Accepter l’offre au clic sur « Payer » laissait des demandes acceptées mais impayées, avec une commission et une police en suspens.

Décision. L’offre est acceptée quand la demande passe à un statut payé, déclenché par la notification automatique de Stripe. Avant cela, une seule offre est désignée comme offre à payer.

Conséquences.

Pas d’acceptation sans argent : les paiements abandonnés restent des offres envoyées.
Tout chemin qui marque une demande payée accepte l’offre exactement une fois.
Le délai entre le clic et l’acceptation dépend de l’arrivée de la notification, voir notifications Stripe tolérantes à l’ordre.

Code. app/Observers/QuoteRequestOfferAcceptanceObserver.php

Webhooks Stripe tolérants à l’ordre

2026-11-12

Contexte. Stripe ne garantit pas l’ordre de ses notifications. Une notification « session de paiement terminée » arrivée en retard a fait repasser un paiement réglé en cours de traitement, et un échec de facture pouvait arriver avant que l’abonnement soit connu.

Décision. Le traitement verrouille le paiement et ignore la notification s’il est déjà réglé, remboursé, annulé ou en litige. Un échec reçu avant l’abonnement fait échouer le traitement, donc Stripe le rejoue.

Conséquences.

Le journal des notifications marque une notification comme traitée même quand elle est ignorée.
Le rejeu repose sur le mécanisme de nouvel essai de Stripe.
Le retour silencieux de l’émission de la police après paiement reste voulu.

Code. app/Http/Controllers/StripeWebhookController.php