Décisions

En bref

Cette page garde les deux choix qui engagent plusieurs dépôts à la fois : c’est le backend qui pilote le service de monitoring, et l’aperçu de sécurité du parcours d’offre est calculé sur le moment, pendant la navigation du visiteur. Pour chaque choix, on lit le contexte, la décision et ce qu’elle coûte. « Pas encore fait » signifie que le code ne la suit pas aujourd’hui.

Le backend pilote le monitoring

2026-05-01

Contexte. Les scans tournent sur un service séparé (Cloudflare) alors que les données métier vivent dans le backend. Un système doit scanner, l’autre doit posséder les entreprises, et pousser à chaque changement multiplie les points d’entrée et les cas de panne.

Décision. Le backend envoie chaque entreprise au service de monitoring par une interface protégée par un jeton d’accès, puis relit alertes et scores. Une tâche planifiée tourne toutes les heures et lance une synchronisation par entreprise. Cette solution remplace des écouteurs de changements sur les polices et les contacts, jamais livrés.

Conséquences.

• Pas de base de scans dans le backend : les pages de monitoring dépendent de la disponibilité du service, et les appelants doivent gérer son indisponibilité.
• La synchronisation est idempotente et se rétablit seule après une panne, mais un changement attend jusqu’à une heure.
• Toutes les entreprises sont synchronisées, y compris les supprimées (le client du monitoring est alors retiré) ; le filtre prévu sur les polices signées n’est pas appliqué.

Code. backend/app/Services/Monitoring/MonitoringClient.php (tâche monitoring:sync, SyncCompanyToMonitoring)

Flash scan synchrone

2026-07-29

Contexte. Le parcours d’offre affiche un aperçu de sécurité pendant la navigation. Un scan complet avec création d’un client et de tâches serait trop lent et créerait des données pour des visiteurs anonymes.

Décision. Le monitoring propose un point d’accès d’aperçu rapide : il scanne un domaine donné avec des délais bornés et répond dans le même appel. Le parcours demande le site web à l’étape 1 et lance le scan pendant que le visiteur navigue.

Conséquences.

• Les adresses IP littérales et les hôtes privés ou réservés sont refusés (protection contre le SSRF : faire appeler au serveur une adresse interne).
• L’arrêt d’urgence du monitoring arrête aussi le flash scan.
• Chaque scanner a une échéance (6 secondes au total en production) : un scanner lent donne un aperçu incomplet. On n’a pas vérifié si les scanners appelés écrivent quelque chose (lecture du coffre à clés, compteurs de quota).

Code. monitoring/src/transport/http/flash-scan.ts (POST /api/v1/flash-scan)