Files et reprises

En bref

Les analyses passent par des files d’attente pour ne pas tout lancer d’un coup. Cette page explique ce qui arrive quand un travail tarde, échoue ou doit être arrêté : réessais, délais limites, arrêt d’urgence, plafonds de débit, et ce que le programme de monitoring garde ou rend au backend. À retenir : un travail raté est réessayé jusqu’à 5 fois puis abandonné, relâcher l’arrêt d’urgence sans vider les files peut lancer une vague de travaux d’un coup, et personne ne lit les files des échecs : il faut les consulter dans Cloudflare.

Le calendrier des tâches planifiées est dans Planification. Les gestes d’exploitation sont dans Lancer et exploiter. Les noms techniques sont dans la correspondance technique en bas de page.

Fonctionnement

Files d’attente

File	Qui y met des messages	Taille d’un lot	Réessais	File des échecs
Recherches de fuites (Intelligence X)	La tâche de 04:00, la création d’un client, l’ajout d’une cible d’instantané, et la file elle-même (relectures d’une recherche)	8 messages ou 30 s	5	Oui
Instantanés de prospects	L’envoi d’un lot par le courtier (par 100), la tâche de chaque minute, l’ajout d’une cible	10 messages ou 5 s	5	Oui

• Délais. La finalisation d’une cible part 60 s après son ajout, puis 120 s si elle attend encore ; un échec la relance après 30 s. Le suivi d’une recherche Intelligence X revient après 5 s, puis 30 s, 5 fois au plus. Une erreur définitive est acquittée et journalisée.
• Dernier essai. Au 5e essai Intelligence X d’une cible, elle passe en erreur du fournisseur pour ne pas bloquer son lot.
• Files des échecs. Aucun code ne les lit et aucun programme ne les traite. On les voit dans le tableau de bord Cloudflare : c’est là qu’il faut regarder si des messages semblent perdus.

Ce que devient un message perdu :

• Ajout d’une cible : la cible n’existe jamais, le lot la compte en échec. Finalisation ou vidage d’un type d’analyse : les tâches planifiées reprennent.
• Recherche Intelligence X : la réservation de 24 h ramène le client le lendemain.
• Suivi d’une recherche Intelligence X : la recherche, déjà payée, est perdue ; le client revient après sa réservation.

États et reprise d’une tâche

Chaque analyse est une tâche qui passe par quatre états : en attente, en cours, terminée, en échec. Deux tâches actives pour le même actif et le même type de scan sont impossibles.

Passage	Déclenché par	Condition
Vers « en attente »	Une remise en file	Aucune tâche active ni terminée récemment
« En cours » vers « terminée »	La fin du scan	Écriture réussie
« En échec » puis de nouveau « en attente »	Le réessai automatique	Erreur passagère et moins de 5 essais ; priorité 30
« En cours » bloquée plus de 10 min	La récupération automatique	Retour en attente avec un essai de plus, ou en échec au 5e

• Cycle épuisé. Une tâche en échec aux 5 essais épuisés, plus récente que le dernier succès, est conservée : les balayages de 6 heures et celui des technologies ne remettent pas l’actif en file tant qu’un succès ne l’a pas levée. Les remises en file de nuit ignorent cette garde.
• Reprise d’un lot. Un lot en échec côté backend repart à la demande du courtier (3 essais) sans créer de doublon. Un résultat sans score devient une cible en échec que le courtier peut relancer.

Délais limites

Objet	Délai	À l’expiration
Tâche en cours	10 min	Récupération automatique
Cible d’instantané	45 min	Recherche de fuites encore en attente : erreur du fournisseur. Analyses encore actives : cible prête, marquée « délai dépassé », scan incomplet
Lot d’instantané	180 min	Clôt seulement un lot sans cible ouverte, « prêt avec erreurs ». Ne force pas les cibles ouvertes
Flash scan	6 s au total (5 s pour les technologies, 3 s pour la découverte)	Un scanner en retard est absent des analyses terminées
Backend, flash scan	Appel de 15 s ; « en cours » depuis 3 min devient « indisponible »	Échec gardé en mémoire 5 min

Arrêt d’urgence et garde aveugle

Le bouton rouge a deux leviers indépendants, pour qu’un seul suffise si l’autre tombe.

1. Interrupteur du programme de monitoring. Tant qu’il est posé : les tâches planifiées s’arrêtent, chaque lot d’une file est relancé 12 h plus tard, plus aucune tâche n’est distribuée aux exécuteurs et le flash scan répond « monitoring arrêté » (503).
2. Pause de livraison des files chez Cloudflare. Le backend suspend les deux files via Cloudflare (droit « Queues: Edit »). Elle tient même si le programme est cassé.

L’admin enclenche et relâche depuis la page monitoring du backend (message Slack). Un arrêt partiel se rejoue.

Ce que l’arrêt ne coupe pas : l’interface (créer un client, mettre une tâche en file), la synchronisation horaire et la notification de Shodan, donc les tâches s’accumulent. Les tâches planifiées sont sautées en entier, la récupération des tâches bloquées aussi : au relâchement, une tâche restée en cours perd un essai et les cibles d’instantané dépassent leur délai de 45 min. Sans la pause Cloudflare, un message est jeté en file des échecs après environ 2,5 jours d’arrêt (5 essais de 12 h).

À faire au relâchement : s’attendre à une vague de tâches et surveiller la consommation Cloudflare.

Garde aveugle. Toutes les 15 min, le backend compare cinq mesures facturées (requêtes du programme, temps de calcul, lectures et écritures de la base, opérations de files) à leur médiane des 7 derniers jours. Il alerte sur Slack en cas de pic (30 minutes à 5 fois la normale), de hausse soutenue (6 h à 3 fois) ou de projection au-delà du quota inclus. Si les chiffres sont illisibles depuis 60 minutes, un seul message l’annonce. Elle n’arrête rien d’elle-même : un humain décide.

Limites de débit et budgets

Limite	Valeur
Interface, par adresse IP (avant authentification, notification de Shodan comprise)	60 requêtes par minute
Interface, par jeton d’accès ou par noeud (après authentification)	60 par minute ; les contrôles de disponibilité et le script d’installation d’un noeud sont hors limite
Flash scan, par IP	5 scans réels par jour, résultat gardé 24 h
Rendu par navigateur	8 h par mois, lot de 15, 14 jours entre deux rendus d’un hôte

Budgets par source (Intelligence X, Shodan, Hudson Rock, réputation de domaine) : voir Sources et Fuites et vulnérabilités. Le calendrier de passage réserve une cible 24 h à chaque prise ; un succès la reporte de 7 jours, un échec double le délai (1, 2, 4 jours, plafonné à 7), une erreur définitive attend 7 jours.

Remontée vers le backend et rétention

Le programme n’envoie aucune notification au backend : le backend vient lire.

• Flash scan : réponse immédiate. Lot : lecture toutes les 5 min tant qu’il est en cours.
• Clients, actifs, constats, scores : à la demande, données fraîches 10 min, périmées après 24 h.
• Alertes à notifier : toutes les 10 min ; résumé mensuel le 1er à 09:00.

Seuls les constats critiques, et six types urgents de gravité haute, partent par e-mail dès leur apparition. Le backend marque avant d’envoyer, pour ne jamais doubler. Les sociétés sans police signée n’en reçoivent pas.

Rétention	Durée
Tâches terminées et en échec	30 jours (échecs épuisés conservés)
Résultats de scan	90 jours, les deux derniers de chaque actif et type de scan conservés
Lots d’instantanés et leurs clients	30 jours
Victimes de ransomware	730 jours, Belgique sans limite ; instantanés par secteur 365 jours
Constats	Clos, jamais supprimés, après 15 à 120 jours sans nouvelle observation (45 par défaut)

Règles et pièges

• Une tâche réessayée repart à la priorité 30 : un instantané réessayé passe derrière les autres.
• Le bouton rouge ne coupe pas les écritures de l’interface : relâcher sans vider peut lancer une vague de tâches d’un coup.

Correspondance technique

Nom courant	Identifiant technique
File des recherches de fuites, sa file des échecs	intelx-jobs, intelx-jobs-dlq
File des instantanés, sa file des échecs	snapshot-jobs, snapshot-jobs-dlq
Liste des tâches de scan	scan_jobs
Récupération des tâches bloquées	reclaimStale
Envoi d’un lot par le courtier	SubmitBrokerScanBatch
Garde aveugle (toutes les 15 min)	monitoring:watch-cloudflare-usage
Calendrier de passage des cibles	schedules
Tables sans purge	provider_requests, idempotency_keys, score_snapshots

Où dans le code

• monitoring/src/transport/queue/router.ts et monitoring/src/platform/db/snapshots.ts (files, délais, états d’instantané)
• monitoring/src/platform/db/jobs.ts (cycle de vie des tâches) et monitoring/src/platform/scheduling/schedules.ts (calendrier)
• backend/app/Services/Monitoring/EmergencyStop.php et backend/app/Console/Commands/WatchCloudflareUsage.php

Questions ouvertes

• Qui surveille les files des échecs, et combien de temps Cloudflare y garde-t-il un message ? Le code ne le dit pas.
• Les 60 requêtes par minute suffisent-elles quand flash scan, synchronisation et lecture de lots partagent le même jeton et la même IP ?
• Faut-il purger l’historique des appels aux fournisseurs, les clés d’unicité des messages et les instantanés de score ? Aucune purge n’existe.
• Les états de lot « annulé » et « expiré » et l’état de cible « en échec » sont autorisés mais jamais écrits : sont-ils voués à servir ?