Noeud de scan et inactifs

Élément	Nature	Statut
Noeud de scan	programme sur une machine externe (type Raspberry Pi) qui réclame des tâches	inactif en production selon sa documentation, branché dans le code
Analyse approfondie des pages	type de tâche du noeud	inactif : aucun déclencheur
Technologies du site côté noeud	passe de détection par requête web	remplace l’étape du monitoring si un noeud en ligne l’annonce

Les identifiants techniques sont dans la Correspondance technique en bas de page.

Noeud de scan

Surveille. Les technologies d’un site, à la place du monitoring, avec les règles de détection Wappalyzer.
Entrée. Une tâche avec l’identifiant et le nom de site de l’actif. Le noeud ne reçoit jamais l’identifiant du client. HTTPS seulement.
Quand. Sur la machine du noeud (script d’installation ou Docker), qui interroge le monitoring toutes les 5 s (jusqu’à 30 s quand la file est vide ou en erreur) et envoie un signal de vie toutes les 30 s. L’enrôlement se fait par l’administration de la plateforme : création, révocation et renouvellement du jeton d’accès du noeud.
Résultat. Le monitoring enregistre les technologies sous une source propre au noeud et partage le résultat avec les autres clients du même nom de site. Une erreur passe par la reprise commune (5 essais).
Solution de repli. Une tâche réclamée et restée en cours plus de 10 minutes revient en file. Page limitée à 20 s, 5 Mo et 5 redirections. Un noeud sans signal de vie depuis 11 minutes est hors ligne : le monitoring reprend la détection. Pendant l’arrêt d’urgence, aucune tâche n’est distribuée. Un noeud révoqué ou désactivé est refusé.
Limites. Voir ci-dessous. Un noeud sans tâche reçoit une réponse vide, comme pendant l’arrêt d’urgence.

Chaque noeud a un jeton d’accès à lui, avec des capacités déclarées qui limitent les tâches qu’il peut réclamer. Un jeton global historique reste accepté en transition.
Un noeud ne peut ni créer son entrée ni s’attribuer une capacité : un signal de vie n’actualise qu’un noeud déjà enrôlé.
À l’enrôlement, le monitoring crée l’identité du noeud, garde son jeton sous forme hachée et renvoie la commande d’installation.
Ses requêtes sont refusées vers une adresse privée dès la connexion, même après redirection, ce qui évite un détournement vers le réseau interne (SSRF).

Le noeud scanne en HTTPS, le monitoring commence en HTTP clair, et leurs règles de détection peuvent diverger.
Son résultat n’a pas de signaux de page construite côté navigateur : la version par navigateur n’est jamais programmée par l’escalade pour un hôte traité par un noeud. Le balayage mensuel du navigateur reste actif.
Il sert aussi les prospects, sans filtre sur le cycle de vie ni sur les CDN.
Quand un noeud est en ligne, l’étape de détection des technologies du balayage de suivi complet saute entièrement, même pour des hôtes qu’il ne réclamera pas assez vite. Le traitement instantané du monitoring continue.

Surveille. Rien dans le monitoring. Le code du noeud extrait scripts, liens, balises d’information, formulaires et domaines externes d’une page.
Entrée. Un nom de site.
Quand. Sur le noeud, jamais : aucun code ne crée ce type de tâche. Seule une tâche insérée à la main serait réclamée.
Solution de repli. Aucune. Le monitoring range la réponse sans observation ni constat.
Limites. Absent du registre, des politiques, du scan flash et des balayages ; le type reste dans la base et dans le schéma d’enrôlement.

Trois crochets de reprogrammation des périmètres obsolètes (découverte, expiration du domaine, réputation des adresses) ne sont appelés par personne : la tâche planifiée passe par un autre chemin.
Une fonction de programmation des ports ouverts par client n’a aucun appelant.
La priorité déclarée par chaque stratégie de programmation n’est pas lue : les tâches planifiées passent leurs propres priorités.
Une condition de clé requise, acceptée par les suivis, n’est utilisée par aucune politique.
Un commentaire annonce une liste de sélecteurs DKIM plus large sur le noeud : elle n’existe pas dans le code du noeud.
La version gratuite des ports n’a pas de programmation propre : seul le suivi de la résolution des adresses la crée.

Cession immédiate. Un noeud enrôlé démarre en attente et prend la détection des technologies dès son premier signal de vie.
Retard de reprise. Après une panne, le monitoring peut mettre jusqu’à 21 minutes à reprendre la main : 11 minutes de seuil plus le balayage de 10 minutes.
Flash. Le scan flash ne passe jamais par le noeud.

Un noeud est-il enrôlé et en ligne en production ? La table des noeuds le dit, le code ne le dit pas.
Faut-il retirer l’analyse approfondie de la base et du schéma d’enrôlement, ou la brancher ?
Le noeud doit-il émettre les signaux d’escalade pour que la version par navigateur reste déclenchée ?

Nom courant	Identifiant technique
Noeud de scan	`scanner-node` (dossier `monitoring/scanner-node`)
Analyse approfondie des pages	`deep_http`
Technologies du site	`tech_stack`
Version par navigateur	`tech_stack_browser`
Jeton global historique	`SCANNER_TOKEN`
Table des noeuds	`scanner_nodes`
Crochets de reprogrammation inutilisés	`enqueueStale` (découverte, `whois`, `ip_reputation`)
Programmation des ports par client	`enqueuePortScansForClient`