Vue d'ensemble
Fonctionnement
Section intitulée « Fonctionnement »Chemin d’une demande : l’adresse demandée, le contrôle d’accès, un écran léger, la validation des données, la logique métier, l’enregistrement, puis les tâches de fond, les réactions aux événements et les emails.
Trois conventions comptent. Chaque cas d’usage a sa propre brique de logique, qui reçoit ses dépendances à la création. Un statut ne change que par un point d’entrée unique qui impose les transitions permises (voir point d’entrée unique des statuts). Les adresses de pages sont écrites en dur côté écran, sans outil de génération. Détails dans Tests et conventions.
| Accès | Qui entre | Protection |
|---|---|---|
| Administrateur | L’équipe Inqase | Réservé aux administrateurs, la page semble absente pour les autres |
| Courtier | Les courtiers actifs | Réservé aux courtiers |
| Client | Les clients avec un abonnement | Réservé aux clients |
| Offre publique | Tout le monde | Un brouillon est identifié par un jeton personnel |
| Pages de paiement et d’offre | Le destinataire d’un email | Liens signés |
| Interface publique | Formulaires de contact et de liste d’attente, notifications DocuSign | Sans connexion |
| Notifications Stripe | Stripe | Contrôle de signature, voir Paiements |
| Assistants IA | Comptes autorisés | Connexion OAuth et rôle valide |
Qui peut accéder à quoi : voir Portails et courtiers.
File d’attente et planification
Section intitulée « File d’attente et planification »Les tâches de fond passent par des files d’attente. Un superviseur surveille deux files sur Redis : la file principale, et celle des illustrations des communications courtier. Selon l’exemple de configuration, la file par défaut est la base de données, mais la valeur de production n’est pas dans le code. Chaque tâche planifiée ne tourne jamais en double et sur un seul serveur.
| Quand | Tâche |
|---|---|
| Chaque heure | Synchronisation du monitoring |
| Toutes les 5 / 10 / 15 minutes | Synchronisation par lot du scan courtier / envoi des notifications de monitoring / surveillance de l’usage Cloudflare |
| Chaque jour 02:00, 03:30 | Expiration des offres envoyées, purge des anciens corps d’email |
| Chaque jour 09:30, 09:45, 10:00 | Relance des paiements en attente, reprise des paiements échoués, relance des offres abandonnées |
| Chaque mois | Résumés de monitoring (le 1er, 09:00), mise à jour de la liste des suffixes publics ; chaque semaine, mise à jour de la liste des emails jetables |
La demande de déclaration de renouvellement et le traitement des renouvellements dus ne sont volontairement pas planifiés tant que l’assureur n’a pas validé la synchronisation des prix Stripe au renouvellement. Voir Polices et renouvellements et Déploiement et exploitation.
Aller plus loin
Section intitulée « Aller plus loin »| Page | Sujet |
|---|---|
| Authentification, médias et journaux | Connexion, liens magiques, fichiers privés, journaux, qui envoie quel email |
| Modèle de données | Ce que la base garde et ses relations |
| Portails et courtiers | Qui accède à quoi |
| Tarification | Calcul de la prime |
| Paiements | Stripe et notifications automatiques |
| Polices et renouvellements | Cycle de vie d’une police |
| Commissions et bordereau | Rémunération des courtiers |
| Tests et conventions | Règles de code et de test |
| Déploiement et exploitation | Mise en production et suivi |
| Développement local | Installer le projet |
| Décisions | Choix d’architecture |
Où dans le code
Section intitulée « Où dans le code »bootstrap/app.php,routes/console.php(tâches planifiées)app/Http/Controllers,app/Services,app/Actions,app/Models
Le backend est une application Laravel 12 (PHP 8.4, Inertia 2, Vue 3).
Questions ouvertes
Section intitulée « Questions ouvertes »- Quelle file d’attente tourne en production : la base de données comme dans l’exemple de configuration, ou Redis comme le suppose le superviseur ?