Mise en place des jobs avec systemd timers #27

📋 Description

Déployer les jobs sur le VPS 1 via une seule CI commune, et les planifier via systemd timers (exécution automatique, logs accessibles). Périmètre : les extracteurs, les pipelines, le système de scoring et les outils communs (apps/jobs, packages/*). Hors périmètre : la base de données (#23, #29), l'API et le frontend (#26, #80, ticket frontend).

Les jobs n'ont pas besoin de Nginx : ce ticket ne dépend pas de #26.

Principe

Un seul workflow de CI déploie tous les jobs. Il s'appuie sur le registre commun des jobs (apps/jobs, get_jobs) : quand un job est ajouté au registre, la CI le détecte automatiquement, le déploie et génère son service et son timer systemd. Aucun job n'a sa propre CI ni son propre déploiement (règle forte du projet : aucun job ne contourne les outils communs).

Fréquence de lancement : nouvelle métadonnée

Chaque job doit déclarer sa fréquence de lancement dans le registre (ex. annuelle, nocturne, à la demande, ou aucune pour un job lancé à la main). La CI s'en sert pour générer le timer.

• Ajouter ce champ au registre des jobs.
• Paramétrer les jobs déjà présents selon la documentation de chacun (ex. cadence annuelle de l'ADR-003, job nocturne de retry). Pour un job dont la doc ne tranche pas, ne pas inventer : lui laisser « pas de planification » et le signaler.

Accès de déploiement

La CI se connecte au VPS avec un rôle de déploiement dédié, aux droits limités (uniquement ce qu'il faut pour déployer le code des jobs et recharger les unités systemd, pas de droits d'administration). La clé est stockée dans les secrets GitHub Actions. Les secrets applicatifs de prod (.env.prod) restent uniquement sur le VPS, la CI ne les voit jamais.

✅ Acceptance Criteria

• Workflow de CI unique qui déploie tous les jobs sur le VPS, déclenché sur main après validation de la CI qualité
• La CI découvre les jobs via le registre : ajouter un job ne demande aucune modification du workflow
• Champ « fréquence de lancement » ajouté au registre des jobs, et jobs existants paramétrés d'après leur documentation
• Services systemd générés (un par job)
• Timers générés d'après la fréquence déclarée
• Rôle de déploiement dédié sur le VPS, droits limités, clé dans les secrets GitHub ; aucun secret applicatif de prod dans GitHub
• .env.prod et BIOWATCH_DATA_ROOT posés sur le VPS (hors /opt/biowatch, en lecture seule pour biowatch-jobs, cf. Création des utilisateurs système et isolation des services #25)
• Procédure de déploiement et de retour arrière documentée
• Logs accessibles
• Exécution automatique validée sur au moins un job

🔗 Prerequisite Issues

DoR externe : jobs disponibles dans le registre, fréquences définies dans leur documentation.

• Depends on Installation et sécurisation PostgreSQL + PostGIS #23 (la base biowatch_prod doit exister) et Création des utilisateurs système et isolation des services #25 (utilisateurs système, déjà fermé)
• Convention d'environnement posée par Environnements (Dev / Prod) #18 (BIOWATCH_ENV, .env.prod uniquement sur le VPS)

Source : Notion « Mise en place des jobs avec systemd timers » (Config VPS).