Planification

Les files d’attente, les délais limites, l’arrêt d’urgence, les budgets et la rétention sont dans Files et reprises. Le détail de chaque scanner est dans Scanners, celui de chaque source dans Sources.

Fonctionnement

Les dix tâches planifiées

Toutes les heures sont en UTC. Le programme vérifie l’arrêt d’urgence avant chaque passage et avant chaque étape. Une étape en échec est journalisée et les suivantes continuent.

Quand	Ce qui se passe	Pour qui	Effet
Chaque minute	Alimente les analyses des instantanés de prospects, relance les finalisations en retard, clôture les lots échus	Prospects (instantanés)	Jusqu’à 100 tâches en attente par type d’analyse (10 pour les domaines imitant le nom)
Toutes les 10 minutes	Récupère les tâches bloquées, marque hors ligne les noeuds silencieux, lance les analyses en attente	Clients monitorés et prospects	Exécute les tâches en attente, avec une limite par type et par passage
Toutes les 6 heures (00, 06, 12, 18 h)	Remet en file les contrôles web, certificats, DNS étendu, reprise de sous-domaine, stockages cloud, fichiers sensibles et signaux d’exploit ; relit l’usage des clés	Actifs hors réseau de diffusion (CDN) des clients monitorés	Crée une analyse si aucune n’a été terminée depuis 7 jours
Chaque nuit à 02:15	Maintenance de nuit	Clients monitorés, lots d’instantanés expirés	Remises en file lentes, purges, score du jour
Chaque nuit à 02:45	Scan de ports, seulement si une clé Shodan est utilisable	IP hors CDN des clients monitorés	500 tâches au plus, 1,1 s entre deux appels
Toutes les 4 heures (00:30, 04:30…)	Met à jour la liste Tor et lance la réputation des IP	IP des clients monitorés	50 IP au plus par passage
Chaque heure à :50	Analyse des domaines imitant le nom	Domaines des clients monitorés	6 domaines au plus par passage, 144 par jour
Chaque nuit à 03:00	Récupère les victimes de ransomware	Global	Victimes et instantanés par secteur
Chaque nuit à 04:00	Répartit les recherches de fuites Intelligence X	Clients monitorés avec un domaine actif	Une recherche par client selon le budget du jour
Chaque heure à :20	Récupère les failles, les complète avec NVD, lance la réputation des domaines et le profil Hudson Rock	Failles globales, puis domaines et clients	Heure pleine pour obtenir le budget de 15 minutes des tâches longues

Le détail de l’enchaînement :

Toutes les 10 minutes. Trois lots tournent toutes les 30 minutes. Lot 1 (:00, :30) : découverte, contrôle web, certificats. Lot 2 (:10, :40) : résolution DNS, DNS étendu. Lot 3 (:20, :50) : expiration du domaine, reprise de sous-domaine. À chaque passage : stockages cloud, fichiers sensibles, instantanés (dont ports gratuits, et réputation des IP si la clé AbuseIPDB existe), technologies détectées (sauf si un noeud en ligne s’en charge) et technologies par navigateur (remplissage mensuel, puis 15 tâches). Les limites respectent le plafond de 1 000 sous-requêtes par exécution. La récupération des tâches bloquées et la détection des noeuds hors ligne ont lieu à chaque passage, sauf celui de la minute.
02:15. Purge des lots d’instantanés expirés (5 par nuit) et des plages CDN, puis remises en file : technologies (7 jours), découverte (30 jours), scan de ports (7 jours, hors IP CDN), couverture Shodan, expiration du domaine (30 jours), domaines imitant le nom (chaque nuit) et nettoyage de leur cache. Ensuite : surveillance des nouveaux certificats, alertes de vulnérabilités, clôture des constats anciens, purges et score quotidien.
Toutes les 4 heures. Liste Tor, remise en file de la réputation des IP (7 jours), puis son exécution (10 IP par client, 50 au total, si la clé AbuseIPDB existe).
Chaque heure à :50. Seulement les domaines imitant le nom : environ 85 sous-requêtes par tâche, le scanner le plus coûteux, donc 6 par passage. Pour plus de domaines, augmenter la fréquence, pas le lot.
Chaque heure à :20. Failles (liste CISA), NVD (l’historique seulement quand le complément n’a plus rien à vérifier), réputation des domaines, Hudson Rock.

Qui déclenche quoi

Le programme prend les tâches par priorité décroissante, puis par ancienneté. Les balayages de 6 heures et celui des technologies ajoutent +50 à un actif jamais scanné avec succès.

Déclencheur	Ce qui part	Priorité
Flash scan d’un prospect (lancé par le backend)	Dix scanners en parallèle, sans file (voir Scanners)	Aucune
Instantané du prospect (par le courtier, via le backend)	Domaine principal, suivis automatiques, puis IP	200 pour la découverte, 60 à 120 ensuite
Scans périodiques des clients couverts	Intégration : découverte, suivis, scan de ports. Ensuite, le rythme des tâches planifiées	Découverte 200, scan de ports 40
Scan profond	Aucun déclencheur de ce nom. Les plus proches : technologies par navigateur et analyse web approfondie	20 (balayage), 70 (escalade), 200 (appel direct)
À la demande, admin : nouveau scan, reprise de client, ajout d’actif, constat résolu à la main	Nouveau scan : dix types dont le scan de ports	40 à 100 ; constat résolu : 90
À la demande, courtier : import d’un lot, reprise d’un lot en échec	Comme l’instantané	Comme l’instantané
Synchronisation du backend, chaque heure	Aucun scan direct ; un client créé reçoit l’intégration, un actif ajouté reçoit contrôle web, certificats et technologies	100, 100, 50

Instantané. Il plafonne à 25 sous-domaines et 6 cibles web.
Synchronisation. Un message par société, supprimées comprises (elles sont effacées du programme). Une société sans actif n’est mise en pause que si la mise en pause automatique est activée. Un état identique reste ignoré 26 heures. En cas d’échec, 5 essais espacés de 10 à 300 s ; une erreur de requête autre que « conflit » ou « trop de requêtes » échoue tout de suite.
Notifications. L’envoi des alertes (toutes les 10 minutes) et le résumé mensuel (le 1er à 09:00) ne lancent aucun scan et ne font rien tant que les notifications ne sont pas activées (désactivées par défaut).

flowchart LR
    be["Backend Inqase"]
    web["Notification de Shodan"]
    cron["Tâches planifiées"]
    api["Interface du<br/>programme"]
    flash["Flash scan<br/>en mémoire"]
    jobs["Liste des tâches<br/>de scan"]
    snapq["File des<br/>instantanés"]
    ixq["File des<br/>recherches de fuites"]
    run["Exécuteurs de scan"]
    d1["Base de données"]
    stop["Arrêt d'urgence"]
    dlq["Files des échecs"]

    be -->|"demande scan, lot, rescan, synchronisation"| api
    web -->|"scan de ports, priorité 90"| jobs
    api -->|"répond en 6 s"| flash
    api -->|"met en file"| jobs
    api -->|"ajoute une cible"| snapq
    cron -->|"chaque minute"| snapq
    cron -->|"10 min, 6 h, nuit"| jobs
    cron -->|"04:00"| ixq
    jobs -->|"priorité décroissante"| run
    snapq -->|"vide une tâche"| run
    run -->|"écrit"| d1
    ixq -->|"5 échecs"| dlq
    stop -.->|"suspend"| cron
    stop -.->|"suspend"| snapq
    classDef status fill:#9ce6ff,stroke:#2c97bb,color:#1c4657
    classDef done fill:#b3e65f,stroke:#6f9a24,color:#2c4300
    classDef problem fill:#ffb575,stroke:#b8742f,color:#5a2d00
    classDef external fill:#e5e7eb,stroke:#9ca3af,color:#374151
    class be,cron,api,flash,snapq,ixq,run status
    class jobs,d1 done
    class stop,dlq problem
    class web external

Le diagramme montre que tout passe par l’interface du programme ou par les tâches planifiées, et que l’arrêt d’urgence suspend les tâches planifiées et la file des instantanés.

Règles et pièges

Une seule analyse active par actif et par type de scan. Remettre en file deux fois n’a donc pas d’effet.
La résolution DNS n’a pas de balayage propre : elle suit la découverte (30 jours) ou un nouveau scan demandé par l’admin.
Le scan de ports ne s’exécute qu’à 02:45. Un nouveau scan demandé par l’admin, un constat résolu à la main et la notification de Shodan (priorité 90) mettent la tâche en file, mais elle attend la nuit suivante. La réputation des IP attend le passage de 4 heures.
Les ports gratuits (InternetDB) sont réservés aux instantanés. Les clients monitorés passent par le scan de ports.
Les fichiers sensibles sont encore analysés chez les prospects, en flash scan comme en instantané, malgré la décision prise.
Les stockages cloud ne comptent jamais comme terminés en flash scan : sans test d’écriture, le scanner ne peut pas prouver qu’un stockage est fermé.
L’analyse des technologies quitte le programme dès qu’un noeud en ligne la déclare. Un noeud est hors ligne après 11 minutes sans signal.
Limites de débit : voir Files et reprises.

Correspondance technique

Nom courant	Identifiant technique
Tâches planifiées, déclarées dans	`monitoring/wrangler.toml`
Scan de ports, ports gratuits	`port_scan`, `internetdb`
Découverte, résolution DNS, DNS étendu	`discovery`, `dns_resolve`, `dns_extended`
Contrôle web, certificats, technologies	`http`, `ssl`, `tech_stack`
Technologies par navigateur, analyse web approfondie	`tech_stack_browser`, `deep_http`
Fichiers sensibles, stockages cloud, domaines imitant le nom	`sensitive_paths`, `cloud_buckets`, `typosquat`
Mise en pause automatique des sociétés sans actif	`MONITORING_AUTO_PAUSE`
Activation des notifications	`MONITORING_NOTIFICATIONS_ENABLED`
Synchronisation horaire, envoi des alertes, résumé mensuel	`monitoring:sync`, `monitoring:dispatch-notifications`, `monitoring:send-summaries`

Où dans le code

monitoring/src/transport/cron/scheduled.ts (tâches planifiées et ordre des étapes)
monitoring/src/platform/db/jobs.ts (mises en file, priorités) et monitoring/src/pipelines/asset-scanners/policy.ts (suivis automatiques)
backend/routes/console.php (planning du backend) et backend/app/Jobs/SyncCompanyToMonitoring.php

Questions ouvertes

Que désigne « scan profond » ? Le code n’a aucun déclencheur de ce nom.
Le filtre qui limite la synchronisation aux sociétés ayant une politique est retiré avec la mention « TEMP ». Quand le rétablir ?
Un scan de ports demandé à la main doit-il vraiment attendre 02:45 ?
Quelle durée de calcul réelle pour un passage toutes les 10 minutes ? Le code ne donne que des nombres de sous-requêtes.
Les notifications sont-elles activées en production ?