Déploiement et exploitation

Fonctionnement

Déploiement

Le déploiement passe par Ploi, sans interruption de service (déclaration du propriétaire), sur un serveur Hetzner à Nuremberg. Les étapes vivent dans Ploi : préparer une nouvelle version dans un dossier à part (dépendances, front, migrations de base), basculer, puis redémarrer les programmes de file d’attente.

Vérifié dans le dépôt : une page de santé existe et la CI ne déploie pas. Aucun environnement de test intermédiaire n’est mentionné.
Configuré dans Ploi, pas dans le dépôt : le script de déploiement, l’ordre des migrations et de la bascule, le redémarrage des files, le nombre de versions conservées.
Ne fusionne que sur CI verte. Une migration doit rester compatible avec la version précédente pendant la bascule : supprimer ou renommer une colonne casse les programmes pas encore redémarrés.

Retour arrière. On rebascule vers la version précédente conservée par Ploi (étapes inconnues et non testées). Les migrations ne s’annulent jamais seules : on écrit une migration corrective.

Tâches planifiées importantes

Le planificateur doit tourner en production. Chaque tâche ne se lance jamais deux fois en même temps, ni sur deux serveurs.

Quand	Tâche	Effet
02:00 chaque jour	Expiration des offres	Fait expirer les offres envoyées ou acceptées hors validité.
09:30 chaque jour	Relances de paiement en attente	Premières relances à J+3 et J+14.
09:45 chaque jour	Reprise des paiements échoués	Relance d’un renouvellement échoué, 7 jours après l’échec.
10:00 chaque jour	Relances d’offre abandonnée	Relances à 24 h et 7 jours.
toutes les 5 min	Suivi des scans de courtiers	Met à jour les scans de portefeuille en cours.
toutes les 10 min	Notifications du monitoring	Envoie par email les alertes critiques, notifie Slack.
toutes les 15 min	Surveillance de l’usage Cloudflare	Alerte sur un usage anormal.
chaque heure	Synchronisation du monitoring	Réconcilie les entreprises avec le programme de monitoring.
le 1er, 09:00	Résumé mensuel du monitoring	Envoie le résumé du mois.

Également planifiés : l’effacement du contenu des emails conservés (03:30 chaque jour), la mise à jour de la liste des emails jetables (chaque semaine) et le rafraîchissement de la liste des suffixes de domaines du monitoring (chaque mois).

Non planifiés : les demandes de déclaration de chiffre d’affaires, le traitement des renouvellements dus et la construction des relevés de commission. Les paiements récurrents sont prélevés par les abonnements Stripe eux-mêmes. La mise à jour du prix Stripe au renouvellement attend la validation de Hiscox, donc aucun renouvellement automatique ne part. Lance les relevés de commission à la main chaque mois : voir Polices et renouvellements et Commissions et bordereau.

Files d’attente

Deux files tournent sur Redis, avec jusqu’à 10 programmes chacune en production : la file générale et celle des images générées par IA. Un tableau de bord de suivi est disponible.
La file générale n’essaie une tâche qu’une fois, celle des images IA trois fois. L’émission de la police après paiement fixe ses propres 3 essais, espacés de 30 secondes. Les tâches échouées sont gardées 7 jours : on les rejoue depuis le tableau de bord ou en ligne de commande. Les réactions aux notifications de Stripe passent par la file.

Journaux et alertes

Les erreurs remontent dans Sentry, dans le fichier journal de l’application, dans un lecteur de logs et dans Nightwatch. Slack a deux voies :

Événements métier : nouveau prospect, police signée, échec de l’émission de la police après paiement, échec de la notification DocuSign, litiges, résiliations, mandat inactif, inscription partenaire, renouvellement déclaré.
Alertes techniques (canal #alerts-tech) : alerte de sécurité critique, usage Cloudflare, arrêt d’urgence.

Règles et pièges

Sauvegardes

Pour l’instant, les sauvegardes se font uniquement au niveau Hetzner. Cela évoluera bientôt.

Incidents courants

La notification de paiement de Stripe échoue. En production, la réception refuse tout si la clé de vérification n’est pas renseignée. Chaque notification est enregistrée une seule fois : un seul programme la traite et un rejeu n’a jamais d’effet double. Si le traitement plante, l’échec est noté avec son message, mais Stripe a déjà reçu sa réponse et ne rejouera pas. Une facture payée reçue avant que l’abonnement soit connu fait volontairement échouer la notification pour que Stripe réessaie. Diagnostic : chercher les notifications en échec jamais traitées, corriger, puis rejouer la tâche ou renvoyer depuis le tableau de bord Stripe. Payé mais sans police : regarde les tâches échouées d’émission de police (après 3 essais, elle journalise en critique et poste sur Slack). Voir webhooks Stripe tolérants à l’ordre.

Scan de courtier bloqué. Le suivi réessaie toutes les 5 minutes tant que le scan est en cours. Le programme de monitoring ferme une cible après 45 minutes et un scan complet après 180. Si rien ne bouge : l’arrêt d’urgence est-il enclenché ? L’adresse et le jeton d’accès du monitoring sont-ils corrects ? Les tâches de scan s’accumulent-elles dans leur file ? Détails : exploiter le monitoring.

Risques à corriger

Inventaire des secrets : Secrets et clés.

La connexion admin vit sur une adresse cachée, hors de l’espace admin, protégée par mot de passe. La double authentification existe mais reste optionnelle : rien n’oblige un admin à l’activer. L’adresse cachée n’est pas une protection : ne t’y fie pas.

Pour les développeurs : commandes et noms utiles

Tâches : routes/console.php, par exemple quotes:expire-sent, payments:remind-pending, payments:recover-failed, quotes:send-abandoned-recovery, monitoring:sync. Non planifiées : renewals:request-declarations, renewals:process-due, broker:build-commission-statements.
Files : Horizon (supervisor-1, supervisor-ai-images), tableau de bord sur /horizon, rejeu avec artisan queue:retry <uuid|all>. Les échecs vont aussi dans _failed_jobs. Tâche d’émission : ProcessPolicyAfterPayment.
Notifications Stripe : table stripe_webhook_events (failed_at renseigné, processed_at nul), variable STRIPE_WEBHOOK_SECRET.
Scan courtier : tâche broker-scan-sync, scans en scanning, variables MONITORING_API_URL et MONITORING_API_TOKEN, file snapshot-jobs.
Journaux : SENTRY_LARAVEL_DSN, VITE_SENTRY_DSN, LOG_STACK, NIGHTWATCH_*, SLACK_WEBHOOK_URL, SLACK_ALERTS_CHANNEL, SLACK_ERROR_CHANNEL (jamais lue).
Mode de file : .env.example fixe QUEUE_CONNECTION=database, phpunit.xml fixe sync, Horizon suppose redis.

Où dans le code

routes/console.php
config/horizon.php, app/Providers/HorizonServiceProvider.php
app/Http/Controllers/StripeWebhookController.php

Questions ouvertes

Valeur du mode de file en production (Horizon suppose Redis) et nombre réel de programmes actifs.
Étapes de retour arrière dans Ploi (non testées).
Quand les commandes de renouvellement seront-elles planifiées, et qui lance les relevés de commission chaque mois en attendant ?