Dans les environnements multi-locataires à grande échelle, la gestion de dizaines de tâches d'arrière-plan hétérogènes — couvrant les audits QA automatisés, la prospection commerciale B2B, le routage d'e-mails OAuth et la synchronisation distribuée de contenu — devient rapidement ingérable lorsqu'elle repose sur des tâches cron non coordonnées ou des scripts shell isolés. Sans cadre d'orchestration centralisé, les processus longs risquent de créer des processus orphelins, de saturer les cœurs CPU du serveur et de fonctionner sans observabilité en temps réel.
Pour relever ce défi architectural, nous avons conçu Job Runner v2.0 : une plateforme haute performance en Node.js et TypeScript bâtie sur une architecture modulaire de plugins. En définissant des contrats de sous-systèmes strictement typés, Job Runner a consolidé trois moteurs d'automatisation auparavant distincts — QA Watchdog, Lead Hunter et Article Sync — au sein d'une plateforme unique, observable et isolée au niveau des processus sur le nœud de calcul dédié (192.168.11.18:8084).
1. Le Problème des Scripts d'Arrière-Plan Fragmentés
Avant la consolidation sous un orchestrateur unifié, chaque outil opérationnel fonctionnait dans son propre silo :
- QA Watchdog : Lançait des spiders Playwright headless autonomes pour auditer les erreurs HTTP 404, vérifier les formulaires de contact dynamiques et inspecter les schémas JSON-LD sur plus de 130 domaines.
- Lead Hunter : Exécutait des boucles de découverte commerciale sur les registres d'entreprises régionaux, envoyait des audits techniques via l'API Google Gmail et synchronisait les prospects avec Frappe CRM.
- Article Sync et Indexation SEO : Exécutait des routines planifiées pour synchroniser les fichiers JSON avec MongoDB Atlas et notifier instantanément les passerelles IndexNow.
Lorsqu'ils étaient lancés via des sessions SSH détachées ou des crons système classiques, des rejets de promesses non gérés ou des boucles infinies pouvaient bloquer les cœurs CPU à 100 % indéfiniment.
2. L'Architecture Modulaire de Plugins en TypeScript
Job Runner v2.0 abstrait chaque domaine opérationnel dans un module strictement typé sous src/modules/ via un contrat déclaratif unifié :
export interface JobDef {
key: string;
name: string;
description: string;
queue: 'qa' | 'lead-hunter' | 'seo' | 'maintenance' | 'social';
bin: 'node' | 'bash';
script: string;
cwd: string;
baseArgs: string[];
schedule?: string;
retries: number;
logFile: string;
}
A. Intégration de QA-Watchdog (src/modules/qa/)
Toutes les suites de tests automatisés ont été migrées sous forme de spiders TypeScript natifs : 404 Fast Spider (qa:spider), Contact Form Liveness (qa:contact-forms), Static Asset Auditor (qa:asset-audit) et SEO Schema Validator (qa:seo-audit) couvrant plus de 3 400 articles publiés.
B. Intégration de Lead-Hunter (src/modules/marketing/)
Le moteur de prospection commerciale fonctionne selon une cascade déterministe en cinq étapes : découverte régionale de PME, audit des régressions techniques (absence de SSL, LCP lent, balise viewport manquante), déduplication dans Frappe CRM v15 via API REST, routage exclusif via le microservice OAuth Google Gmail sur le port 8085 et suivi automatique des rebonds.
C. Intégration d'Article Sync et du Moteur de Contenu Versionné (src/modules/content/)
La synchronisation du contenu repose sur une double écriture atomique entre les shards JSON, la base SQLite des révisions (data/revisions.db) et MongoDB, avec captures d'état immuables (v1 → v2) et notifications IndexNow instantanées.
3. Isolation Stricte des Groupes de Processus POSIX et Télémétrie
Pour éviter toute saturation CPU et tout processus Chromium orphelin, Job Runner applique deux invariants de stabilité essentiels :
- Sandboxing par Groupe de Processus (
-pid) : Lorsqu'une tâche est arrêtée ou dépasse son délai d'exécution, Job Runner envoieSIGTERM/SIGKILLà l'identifiant négatif du groupe de processus (process.kill(-child.pid, 'SIGTERM')), garantissant la terminaison propre de tous les processus enfants. - Télémétrie Dual-Push : Tous les journaux et métriques de cycle de vie sont transmis en temps réel à Prometheus et Promtail/Loki, alimentant les tableaux de bord Grafana sur les nœuds
.32et.18.
| File d'Attente | Chemin du Module | Limite de Concurrence | Mécanisme d'Isolation et de Reprise | Destination Télémétrie |
|---|---|---|---|---|
qa |
src/modules/qa/ |
2 spiders parallèles | Kill de groupe POSIX -pid + timeout 15 min |
Loki {job="qa_watchdog"} + Prometheus |
lead-hunter |
src/modules/marketing/ |
1 pipeline séquentiel | Déduplication idempotente Frappe CRM + retry OAuth | Loki {job="lead_hunter"} + Webhook CRM |
seo / maintenance |
src/modules/content/ |
4 workers atomiques | Verrou SHA-256 + double écriture SQLite/MongoDB | Loki {job="cms_sync"} + IndexNow HTTP 200 |
4. Conclusion
En réunissant la validation QA, l'automatisation marketing et la synchronisation de contenu au sein d'une architecture modulaire de plugins en TypeScript, nous avons transformé des scripts d'arrière-plan fragiles en un moteur d'automatisation d'entreprise résilient et entièrement observable.
