Emails
Fonctionnement
Section intitulée « Fonctionnement »Tout est envoyé par le backend, y compris les emails de monitoring ; voir Vue d’ensemble.
Les envois manuels (offre, lien de paiement, documents) vont aux adresses choisies par le courtier ou l’admin. Depuis le portail courtier, le courtier est mis en adresse de réponse ; les envois admin n’en définissent aucune. Les emails liés à un événement sont placés en file d’attente. Les relances partent d’une tâche planifiée. Les emails au cabinet du courtier partent une fois vers les utilisateurs qui ont gardé l’email activé (« offre à suivre » et « paiement échoué » sont toujours envoyés par email ; les trois, avec « nouveau prospect », mettent la boîte de transmission Inqase en copie) et ajoutent une notification cloche par utilisateur, selon ses préférences. La colonne Type est le regroupement de cette page, pas celui du journal.
| À | Déclencheur | Type | |
|---|---|---|---|
| Offre | Adresses choisies | Courtier « Envoyer l’offre », admin « Envoyer l’offre » | transactionnel |
| Relance d’offre | Idem | Courtier « Relancer le client » | relance |
| Demande d’informations | Adresses choisies | Courtier « Demander des informations », admin | transactionnel |
| Lien de paiement | Contact de la demande ou adresse choisie | Renvoi par courtier ou admin, ouverture d’un paiement | transactionnel |
| Relance de paiement | Contact de la demande | Tâche de 09:30, paiement en attente depuis 3 et 14 jours | relance |
| Récupération d’un renouvellement échoué | Contact de la demande | Tâche de 09:45, paiement de renouvellement échoué depuis 7 jours | relance |
| Demande abandonnée | Contact de la demande | Tâche de 10:00, 24 h et 7 jours après la création | relance |
| Documents de la police | Adresses choisies | Courtier « Envoyer au client » (documents) | transactionnel |
| Contrat | Adresses choisies | Admin, envoi du contrat | transactionnel |
| Police active | Contact de la demande | Émission de la police, après le premier paiement ou par l’admin | transactionnel |
| Paiement de renouvellement reçu | Contacts de la police | Paiement reçu, renouvellements uniquement | transactionnel |
| Paiement échoué | Contacts de la police : contacts du cabinet courtier et de l’entreprise cliente ayant un email (avant l’existence d’une police : contact de la demande et contacts du cabinet courtier) | Stripe signale une facture impayée | avertissement |
| Prochain prélèvement | Utilisateur client | Stripe annonce une facture à venir, avec un magic link de 14 jours | avertissement |
| Mandat SEPA invalidé | Utilisateur client | Stripe signale un mandat devenu inactif | avertissement |
| Avenant | Contact de la demande | Avenant appliqué à la police | transactionnel |
| Renouvellement | Contact de la demande | Renouvellement de la police (commande non planifiée) | transactionnel |
| Déclaration de renouvellement à remplir | Utilisateur client de la police | Courtier ou admin « Lancer le renouvellement » ou « Relancer le client » (une fois par jour et par police), commande de demande de déclaration | relance |
| Demande refusée | Contact de la demande | Admin « Refuser » sur une demande en revue | transactionnel |
| Digest d’alertes de sécurité | Contacts d’entreprise ayant opté | Toutes les 10 min pour les alertes, chaque mois pour le résumé | avertissement |
| Magic link (client, courtier) | L’adresse saisie, si un utilisateur a accès à ce portail | Demande de connexion (30 minutes), lien de bienvenue courtier (24 heures), usage unique | transactionnel |
| Invitation courtier | Utilisateur invité | Invitation d’un utilisateur courtier | transactionnel |
| Convention signée | L’utilisateur qui accepte | Première acceptation d’une version | transactionnel |
| Nouveau prospect | Cabinet courtier | Création de la demande, au premier calcul d’offre (parcours ou admin « Calculer les offres »), demande liée à un courtier | notification portail + email |
| Offre à suivre | Cabinet courtier | Le prospect transmet, l’admin assigne ou notifie | notification portail + email |
| Paiement échoué côté courtier, police émise | Cabinet / utilisateurs courtier | Paiement échoué, police émise | notification portail + email |
| Renouvellement déclaré | Utilisateurs courtier | Le client soumet la déclaration | notification portail |
| Invitation courtier annuaire | Courtier annuaire | Transmission ou action admin, une fois par demande | transactionnel |
| Transmission à assigner | Boîte de transmission Inqase | Transmission sans courtier joignable | transactionnel |
| Contact et liste d’attente, demande à l’assistant | Boîtes Inqase | Formulaires publics, outil de contact de l’assistant | transactionnel |
| Demande créée, prospect, courtier inscrit, police signée, traitement échoué, notification DocuSign échouée, alertes de renouvellement | Canal Slack principal | Événement ou commande correspondant | Slack |
| Litige, abonnement supprimé, mandat inactif, prélèvement après annulation | Canal Slack principal | Notifications automatiques de Stripe | Slack |
| Alerte de sécurité critique, usage Cloudflare, garde Cloudflare aveugle, arrêt d’urgence | Canal Slack d’alertes | Tâches de monitoring, arrêt d’urgence | Slack |
Règles et pièges
Section intitulée « Règles et pièges »- Le premier paiement n’envoie pas de « paiement reçu » : le client reçoit « Police active », le courtier reçoit la version courtier.
- Les deux commandes de renouvellement (demande de déclaration, traitement des échéances) ne sont pas planifiées, donc les emails de renouvellement ne partent qu’à la main.
- L’événement « demande créée » (qui produit le Slack « Demande créée » et l’email « nouveau prospect » au courtier) se déclenche au premier calcul de l’offre, pas au début de la demande. Les offres créées par un courtier et les brouillons de l’assistant coupent cet envoi.
- Les messages Slack des chemins de renouvellement et des alertes de monitoring sont protégés : un échec de Slack ne fait pas échouer la tâche. L’alerte d’échec du traitement de police ne l’est pas.
- Revue manuelle et prix sur mesure : le prospect voit une page de statut, personne dans l’équipe Inqase ne reçoit d’email ni de Slack. Seul le pipeline admin la montre.
- La relance courtier après 7 jours sans réponse n’existe que dans le portail, pas par email.
- À la fin d’une signature DocuSign, la demande passe à « Police émise » et un message Slack « police signée » part, mais l’événement d’émission ne part pas : l’email d’émission au client et au courtier est manqué sur ce chemin.
- L’email « Demande refusée » n’est envoyé que par l’action « Refuser » du pipeline admin. Passer à « Refusée » depuis le formulaire d’édition admin n’envoie rien.
- La tâche de relance des demandes abandonnées tourne une fois par jour mais chaque relance regarde une fenêtre d’une heure (créée 24 à 25 heures, ou 7 jours à 7 jours et 1 heure, avant l’exécution), donc la plupart des demandes abandonnées ne sont jamais relancées. Problème de code, non corrigé ici.
- Aucun email à l’approbation, à l’expiration d’une offre, au remboursement, à l’annulation d’une police (litige perdu : Slack uniquement) ni pour un relevé de commission.
- Le statut « Remis » n’est jamais écrit : un email reste « Envoyé ».
Où voir les emails envoyés
Section intitulée « Où voir les emails envoyés »- Journal admin (« Mails »), page « Emails » du back-office : il liste chaque email et notification mail avec destinataire, type, statut et corps ; filtres par destinataire, type, statut, courtier, dates. Les corps de plus de 24 mois sont effacés (tâche de 03:30).
- L’envoi passe par Cloudflare Email Sending. Les alertes Slack vont vers un canal principal et un canal d’alertes.
- Les corps d’email contiennent des données personnelles : le journal est réservé à l’administrateur.
- Un envoi qui ne passe pas par l’enregistrement automatique n’est pas tracé, et aucun retour du fournisseur ne fait passer un email à « délivré ».
- En local : les messages sont écrits dans le journal de l’application tant qu’aucun service d’envoi n’est configuré. Le journal admin marche aussi en local ; il n’y a pas de conteneur Mailpit.
Où dans le code
Section intitulée « Où dans le code »app/Mail/etapp/Notifications/app/Listeners/etroutes/console.phpapp/Services/EmailLog/EmailLogRecorder.php
Correspondance technique
Section intitulée « Correspondance technique »| Identifiant technique | |
|---|---|
| Offre, Relance d’offre | QuoteEmailMail |
| Demande d’informations | RequestInfoMail |
| Lien de paiement | PaymentLinkMail |
| Relance de paiement, récupération d’un renouvellement | PaymentReminderMail, commandes payments:remind-pending, payments:recover-failed |
| Demande abandonnée | QuoteResumeEmail, commande quotes:send-abandoned-recovery |
| Documents de la police | PolicyDocumentsMail |
| Contrat | ContractEmailMail |
| Police active | PolicyIssuedNotification, événement PolicyIssued |
| Prochain prélèvement | UpcomingInvoiceNotification |
| Demande refusée | QuoteDeclinedNotification |
| Convention signée | BrokerAgreementSignedMail |
| Invitation courtier annuaire | DirectoryBrokerLeadMail |
| Transmission à assigner | BrokerHandoffMail, réglage broker.handoff_inbox |
| Nouveau prospect | événement QuoteRequestCreated |
| Alertes et résumés de monitoring | commandes monitoring:dispatch-notifications, monitoring:send-summaries |
| Renouvellement | événement PolicyRenewed, commandes renewals:request-declarations, renewals:process-due |
| Journal admin | /admin/emails |