EViLGUARD — Infrastructure Seedbox & Automatisation

Document complet — Juin 2026

À qui s'adresse ce document : à toute personne qui veut comprendre comment fonctionne notre système, même sans aucune connaissance préalable. Chaque composant est expliqué depuis zéro.

CONTRIBUTEURS

Ce document est le socle de vérité de notre infrastructure — les données qu'il contient (paths, versions, configuration, historique) sont vérifiées et protégées. Les suggestions d'amélioration sont les bienvenues mais taguées par source pour qu'on sache qui a proposé quoi.

Format pour les suggestions futures : chaque ajout est tagué [🤖 Nom_AI] dans son titre de section, et la table ci-dessus est mise à jour. Toute suggestion qui contredit des données réelles (paths, versions, historique) est filtrée — le socle ne bouge pas.

TABLE DES MATIÈRES

1. Introduction : c'est quoi un seedbox ?
2. Le seedbox EViLGUARD — fiche technique
3. La suite *Arr — chaque application expliquée
4. Architecture de la librairie média
5. Le scoring Custom Formats — priorité FR/MULTI
6. La stack d'automatisation VPS
7. Les jobs cron Hermes
8. Historique — là d'où on vient
9. État actuel — ce qui tourne aujourd'hui
10. Vision — vers un système véritablement autonome
11. Nouvelles optimisations — curation, rétention et gain d'espace [🤖 Gemini]
12. Angles morts — monitoring passif, redondance et validation [🤖 Claude Sonnet 4.6]
13. Architecture de l'autonomie — de la détection à la réparation [🤖 GPT-4o]
14. Accélération opérationnelle — outils de power-user [🤖 Grok 4]

1. Introduction : c'est quoi un seedbox ?

Un seedbox est un serveur dédié (généralement dans un datacenter) qui télécharge et partage des fichiers via le protocole BitTorrent — 24h/24, 7j/7, à très haut débit (souvent 1 Gbps ou plus).

Pourquoi utiliser un seedbox plutôt que son PC personnel ? - Débit internet 10× à 100× plus rapide que la maison - Disponible en permanence (pas besoin de laisser son PC allumé) - Préserve les ratios sur les trackers privés (seeding continu) - Ne consomme pas la bande passante domestique - Protège la vie privée (l'adresse IP exposée est celle du datacenter)

Notre seedbox est hébergé chez Whatbox.ca (plan goji, juin 2026) et tourne sous Linux.

2. Le seedbox EViLGUARD — fiche technique

Ce qui tourne SUR le seedbox

Six applications web, chacune accessible via son sous-domaine HTTPS :

3. La suite *Arr — chaque application expliquée

Comment tout s'enchaîne (le flux complet)

┌─────────────────────────────────────────────────┐
│ 1. L'utilisateur demande un film/série           │
│    → Overseerr (interface simple, comme Netflix) │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 2. Sonarr (séries) ou Radarr (films)             │
│    prennent la requête et cherchent la release   │
│    parfaite selon nos critères de qualité        │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 3. Prowlarr interroge les indexers               │
│    (C411, Nyaa.si, SubsPlease…)                  │
│    → trouve les torrents disponibles             │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 4. Transmission télécharge le .torrent            │
│    (NE JAMAIS TOUCHER — géré par Sonarr/Radarr)  │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 5. Sonarr/Radarr importent le fichier fini       │
│    → renommage propre, placement dans la lib.    │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 6. Bazarr scanne et télécharge les sous-titres   │
│    (FR, EN) automatiquement                      │
└────────────────────┬────────────────────────────┘
                     │
                     ▼
┌─────────────────────────────────────────────────┐
│ 7. DEMONPLEX / Jellyfin                          │
│    → l'utilisateur peut maintenant regarder      │
└─────────────────────────────────────────────────┘

Overseerr — le portail de requêtes

C'est la « porte d'entrée » du système. L'utilisateur tape le nom d'un film ou d'une série, Overseerr cherche dans la base TMDb (The Movie Database), affiche une fiche avec jaquette et synopsis, et l'utilisateur clique « Demander ».

Une fois approuvée, la requête est transmise à Sonarr ou Radarr qui se charge du reste.

• API : /api/v1
• Status : GET /status (PAS /system/status — piège connu !)
• Docs : https://overseerr.evilguard.box.ca/api-docs

Sonarr — le gestionnaire de séries TV

Sonarr est le cerveau pour les séries. Il : - Garde une base de données de toutes les séries qu'on suit - Sait quels épisodes on a déjà et lesquels il manque - Cherche automatiquement les nouveaux épisodes (via Prowlarr) - Renomme proprement les fichiers et les place dans la librairie - Suit les calendriers de diffusion (les épisodes qui sortent cette semaine)

• API : /api/v3 (identique à Radarr — mêmes endpoints)
• Profils de qualité : 3 profils (Anime, HD-720p/1080p, Any)

Radarr — le gestionnaire de films

Même chose que Sonarr, mais pour les films. Cherche, télécharge, renomme, organise.

• API : /api/v3
• Profils de qualité : 5 profils actifs (Any, HD-720p, HD-1080p, HD-720p/1080p, HD-720p/1080p Copy)

Prowlarr — l'agrégateur d'indexers

Un indexer, c'est un site qui référence des torrents (comme C411, YGG, Nyaa.si). Prowlarr centralise la connexion à TOUS les indexers et les expose à Sonarr/Radarr de façon unifiée.

Avant Prowlarr, il fallait configurer chaque indexer manuellement dans chaque application. Prowlarr le fait une fois et synchronise automatiquement.

Nos 5 indexers actifs (nettoyés de 64 à 5 en mai 2026) :

• YGG est mort (hacké/effacé) — supprimé
• FlareSolverr est down — certains indexers Cloudflare ne fonctionnent plus
• Règle critique : ne JAMAIS activer « Replace MULTI by another language » (casse le scoring FR)

Bazarr — sous-titres automatiques

Bazarr scanne la librairie (ce que Sonarr/Radarr ont importé) et télécharge les sous-titres manquants depuis des providers comme OpenSubtitles.org, Sous-Titres.eu, Addic7ed.

• Fonctionne APRÈS l'importation (ne bloque jamais le flux)
• Provider minimum requis : 1 activé. Si 0, Bazarr ne peut rien faire.

Transmission — ⚠️ ZONE INTERDITE

Le client de téléchargement. Sonarr et Radarr lui envoient les .torrent à télécharger. Il seed (partage) pour maintenir les ratios sur les trackers privés.

RÈGLE D'OR : l'agent Hermes ne touche JAMAIS à Transmission. Aucune suppression de torrent, aucun arrêt de seed, aucune modification. La raison est simple : supprimer un torrent = ratio détruit sur les trackers privés = bannissement potentiel.

4. Architecture de la librairie média

Le problème qu'on a découvert (mai 2026)

Transmission téléchargeait directement dans les mêmes dossiers que la librairie :

/home/evilguard/files/anime/      ← 84 torrents + dossiers propres Sonarr
/home/evilguard/files/serie tele/ ← 386 torrents + dossiers propres Sonarr
/home/evilguard/files/films/      ← 358 torrents + dossiers propres Radarr

Conséquences : 1. Doublons dans DEMONPLEX — le media server voyait les dossiers propres de Sonarr ET les dossiers bruts de Transmission (ex: Hell's Paradise/ ET Jigokuraku S01 [BD]/) 2. Hardlinks cassés — source et destination dans le même dossier, Sonarr copiait au lieu de hardlinker → espace disque gaspillé 3. Sonarr health warning — "Download client places downloads in root folder"

Architecture cible (standard TRaSH Guides)

/home/evilguard/files/
├── .torrents/          ← Transmission UNIQUEMENT (non scanné par DEMONPLEX)
│   ├── anime/
│   ├── tv/
│   └── movies/
├── anime/              ← Librairie Sonarr (scannée par DEMONPLEX)
├── serie tele/         ← Librairie Sonarr
└── films/              ← Librairie Radarr

Le . devant .torrents/ cache le dossier au media server — plus de doublons. La séparation permet aussi les vrais hardlinks (Transmission seed depuis .torrents/, Sonarr hardlinke vers la librairie sans copie supplémentaire).

Statut : les torrents ont été déplacés vers .torrents/ le 31 mai 2026. 828 torrents, 0 conflit de dossiers partagés. Migration sécurisée et vérifiée.

5. Le scoring Custom Formats — priorité FR/MULTI

Le système de scoring détermine QUELLE release est choisie quand plusieurs sont disponibles. On ne veut pas n'importe quelle version — on veut la meilleure qualité en français.

Pour les films et séries TV classiques

Pour les anime

Qualité

• Maximum 1080p Bluray pour films et séries (PAS de 4K — trop lourd)
• Maximum 1080p WEB pour anime (les releases anime sont en WEB, pas Bluray)
• Fichiers légers privilégiés (Quality Definitions ajustées)

⚠️ Pièges connus

• La langue du profil DOIT être Any (id=-2). Si English ou Original, les custom formats français sont ignorés même avec des scores positifs.
• Sonarr et Radarr DOIVENT avoir les MÊMES scores. Pas de +20 dans Radarr « parce que c'est différent ».
• Ne PAS activer « Replace MULTI by another language » dans Prowlarr.

6. La stack d'automatisation VPS

À côté du seedbox, on a un VPS Hostinger (2.25.147.23, domaine evilai.fun) qui héberge des services d'automatisation. Ces services sont indépendants du seedbox physiquement, mais communiquent avec.

Services Docker (dans /root/automation-stack/)

Total idle : ~650 MB RAM

Pipeline de briefing quotidien (intelligence)

Deux jobs automatisés produisent un briefing d'actualité chaque matin :

1. Collecte horaire (chaque heure, :10) : un script Python interroge l'API Miniflux, récupère les nouveaux articles de toutes les catégories (AI/ML, AI Agents, Tech, US Politics, Canada Politics, World/Conflicts) et les stocke dans un buffer.

2. Briefing matinal (10:55 UTC = 6:55 Montréal) : un autre script assemble le buffer, déduplique les articles (URL exacte + similarité Jaccard > 65%), puis appelle Claude CLI pour rédiger un briefing intelligent. Le résultat est livré sur Telegram.

Coût : ~4 850 tokens Anthropic par jour (~0.90$—1.50$/mois).

Catégories de flux RSS surveillées

• AI/ML News : blogs OpenAI, Anthropic, Stability AI
• AI Agents : LangChain, AutoGPT, CrewAI
• Tech : Hacker News, TechCrunch
• US Politics : Politico, The Hill
• Canada Politics : CBC Politics, Globe & Mail
• World/Conflicts : Reuters World, AP International

7. Les jobs cron Hermes

Cinq jobs automatisés tournent en permanence, sans intervention humaine :

Le Weekly Health Check vérifie automatiquement : - Les 5 apps sont-elles en ligne ? - Les profils de qualité ont-ils les bons scores ? - Y a-t-il des warnings dans la queue Sonarr/Radarr ? - Les indexers Prowlarr sont-ils tous fonctionnels ? - L'espace disque est-il correct ?

Tous les résultats sont livrés sur Telegram.

8. Historique — là d'où on vient

Avant la maintenance du 31 mai 2026

Voici l'état du seedbox avant notre grand nettoyage :

Ce qu'on a fait le 31 mai 2026

• ✅ Prowlarr : nettoyage de 64 → 5 indexers actifs
• ✅ Scores corrigés dans tous les profils Sonarr et Radarr (MULTI=+100, French=+50, VOSTFR=+30 partout)
• ✅ Profils SD et Ultra-HD supprimés
• ✅ Langue = Any sur tous les profils
• ✅ 828 torrents Transmission déplacés vers .torrents/ avec la méthode torrent-set-location du RPC — sans casser le seeding
• ✅ Queue nettoyée : entrées zombies supprimées
• ✅ 3 séries anime recatégorisées (standard → anime) et déplacées vers /anime/
• ✅ The Boys et Monarch déplacés vers /serie tele/
• ✅ Orphelins filesystem nettoyés
• ✅ Fichiers .part supprimés
• ✅ Webhook cassé supprimé

9. État actuel — ce qui tourne aujourd'hui (juin 2026)

Ce qui est STABLE et FIABLE

Ce qui est FRAGILE ou À SURVEILLER

10. Vision — vers un système véritablement autonome

Voici la feuille de route pour transformer cet écosystème en un système qui tourne pratiquement tout seul, avec l'agent Hermes comme superviseur.

🔴 Phase 1 — Fondations (court terme, 1-2 semaines)

Ces améliorations ne coûtent presque rien et apportent une résilience immédiate.

1.1 Backup automatique des configurations *Arr

Script cron hebdomadaire → SSH sur le seedbox → export des configs → stockage local VPS

Ce qu'on sauvegarde : - Configurations Sonarr/Radarr/Prowlarr/Bazarr (les .db et config.xml) - Liste des séries et films (export JSON via API) - Custom formats

Outil : Un script Python de 50 lignes + cronjob Hermes no_agent=true

1.2 Alerte espace disque proactive

Script cron quotidien → GET /diskspace → si volume > 85% → alerte Telegram

Ne pas attendre 95%. À 85%, on a le temps d'agir avant que les downloads échouent.

1.3 Health check Prowlarr quotidien (pas seulement hebdomadaire)

Le health check actuel est dominical. Un check quotidien (léger, 2 appels API) sur Prowlarr uniquement permet de détecter un indexer qui tombe en 24h au lieu de 7 jours.

1.4 Détection C411 — API key expiration

L'API key C411 a une durée de vie. Un check mensuel peut vérifier que les appels à C411 fonctionnent encore (via Prowlarr /indexer/test).

🟡 Phase 2 — Semi-autonomie (moyen terme, 2-4 semaines)

Ces améliorations demandent un peu plus de logique mais restent dans le domaine du scriptable.

2.1 Auto-résolution des queues bloquées

Actuellement le health check DÉTECTE les entrées zombie dans la queue. Mais il ne les RÉSOUT pas.

Flux proposé : 1. Script scanne la queue Sonarr/Radarr → trouve les entrées en warning 2. Pour chaque entrée : vérifie via API si l'épisode a déjà un fichier (hasFile=True) 3. Si oui → DELETE /queue/{id}?removeFromClient=false (safe, juste l'affichage) 4. Si non → log dans le rapport sans action (décision humaine) 5. Résumé livré sur Telegram : « 3 zombies nettoyés, 1 épisode vraiment manquant »

Risque : FAIBLE — la seule action destructive (removeFromClient=true) n'est JAMAIS utilisée.

2.2 Recyclarr — synchronisation automatique des profils

Recyclarr est un outil qui synchronise les configurations *Arr avec les TRaSH Guides (standards de la communauté). Une fois configuré :

• Les profils de qualité restent TOUJOURS conformes aux meilleures pratiques
• Les custom formats sont synchronisés automatiquement
• Plus besoin de vérifier manuellement que french=+50 n'est pas revenu à 0

Installation : un binaire sur le VPS + un fichier YAML de config + un cron mensuel.

2.3 Auto-approbation intelligente des requêtes Overseerr

Actuellement, les requêtes Overseerr nécessitent une approbation manuelle.

Règles d'auto-approbation proposées : - Film standard (pas 4K, pas box set, < 20 Go estimé) → auto-approuver - Série standard (pas 4K, < 3 saisons) → auto-approuver - Film 4K, box set, collection complète → demander confirmation humaine - Espace disque < 50 Go sur le volume cible → refuser avec notification

Implémentation : script Python qui interroge Overseerr /request?filter=pending, applique les règles, POST /request/{id}/approve ou notifie.

2.4 Réparation automatique FlareSolverr

FlareSolverr est un conteneur Docker qui résout les challenges Cloudflare pour les indexers. Quand il tombe, les indexers protégés deviennent inaccessibles.

Monitoring : - Check périodique de la santé FlareSolverr (HTTP GET sur son port) - Si down → docker restart flaresolverr - Si toujours down après 3 tentatives → alerte Telegram

🟢 Phase 3 — Autonomie avancée (long terme, 1-3 mois)

Ces améliorations utilisent l'intelligence de l'agent Hermes pour prendre des décisions complexes.

3.1 Agent de curation de contenu

Un agent qui, chaque semaine : 1. Analyse les tendances Overseerr (ce que les utilisateurs demandent) 2. Compare avec ce qui est disponible sur les indexers 3. Suggère des ajouts proactifs : « Cette série est dispo en MULTI 1080p, tendance #1 cette semaine sur Overseerr. L'ajouter ? » 4. L'utilisateur répond « oui » et l'agent fait tout : lookup → add → search

Technologie : cronjob Hermes avec media-management skill, fréquence hebdomadaire.

3.2 Agent de résolution de conflits

Quand un download échoue pour une raison complexe (pas juste un zombie), un agent diagnostique :

1. Lit l'erreur exacte dans la queue
2. Vérifie l'indexer dans Prowlarr (est-il down ? l'API key est-elle valide ?)
3. Vérifie les alternatives (autres indexers, autres releases)
4. Propose une solution : « C411 a rejeté ce torrent (403). 2 autres releases sont dispo sur Nyaa et SubsPlease. Re-search sur ces indexers ? »
5. Si l'utilisateur ne répond pas en 24h, l'agent re-tente automatiquement (règle : « ne jamais rester bloqué plus de 24h »)

3.3 Système de scoring prédictif

Utiliser l'historique des downloads pour prédire la qualité : - Quels indexers ont le meilleur taux de succès pour le FR/MULTI ? - Quels types de releases échouent le plus souvent ? - Ajuster automatiquement les priorités d'indexers dans Prowlarr

Implémentation : base SQLite légère sur le VPS, alimentée par les logs des queues Sonarr/Radarr.

3.4 Auto-scaling de la librairie

Quand l'espace disque atteint 80% : 1. Lister les séries non monitorées (plus suivies) 2. Lister les fichiers les plus volumineux 3. Lister les doublons qualité (ex: on a le 1080p ET le 720p du même épisode) 4. Proposer un plan de nettoyage avec impact estimé en Go 5. L'utilisateur valide et l'agent exécute

3.5 Agent Gardien — supervision globale

Un job cron qui tourne toutes les 6 heures et exécute TOUS les checks précédents en séquence :

Toutes les 6h :
├── Check 1 : Toutes les apps en ligne ?
├── Check 2 : Espace disque < 85% ?
├── Check 3 : Indexers Prowlarr OK ?
├── Check 4 : Queue Sonarr/Radarr propre ?
├── Check 5 : FlareSolverr up ?
├── Check 6 : Briefing livré ce matin ?
└── Rapport consolidé → Telegram (seulement si problème)

Silencieux si tout va bien. L'utilisateur ne reçoit un message que quand quelque chose nécessite son attention.

🟣 Phase 4 — Le Rêve (vision long terme)

4.1 Dashboard de supervision en temps réel

Un mini-dashboard web (sur le portal evilai.fun) qui affiche en temps réel : - Statut de tous les services (vert/jaune/rouge) - Derniers downloads (avec jaquettes) - Espace disque (jauge visuelle) - Activité récente (timeline des événements) - Santé des indexers

Intégré au dashboard existant ou en page dédiée ops.evilai.fun/seedbox.

4.2 Assistant conversationnel autonome

Un agent Hermes accessible via Telegram qui peut : - « Ajoute la série X » → lookup, choix du profil, add, search - « Pourquoi le download de Y est bloqué ? » → diagnostic complet, résolution - « Quel espace disque il reste ? » → réponse instantanée - « Trouve-moi un film d'action français récent » → recherche Overseerr → proposition - « Fais le ménage » → scan complet, rapport de nettoyage, exécution après approbation

Cet assistant est déjà partiellement possible aujourd'hui — il suffit d'activer le seedbox-management skill dans une conversation Telegram.

4.3 Multi-seedbox (futur lointain)

Si un deuxième seedbox est ajouté (pour la redondance ou la capacité) : - Synchronisation des configurations *Arr entre les deux seedboxes - Répartition des downloads (load balancing) - Failover automatique si un seedbox tombe

Récapitulatif — la roadmap complète

MAINTENANT ─── PHASE 1 ─── PHASE 2 ─── PHASE 3 ─── PHASE 4
  (stable)    (fondations)  (semi-auto)  (autonome)  (rêve)
     │             │             │            │           │
     │        backup auto   recyclarr    curation    dashboard
     │        alerte disk   queue auto   conflits    assistant
     │        prowlarr 24h  overseerr    prédictif   multi-box
     │             │        flaresolv    scaling
     │             │             │        gardien
     ▼             ▼             ▼            ▼           ▼
  juin 2026    ~1-2 sem     ~2-4 sem    ~1-3 mois    ~6+ mois

Outils à notre disposition pour réaliser cette vision

Conclusion

On est passé d'un seedbox chaotique (64 indexers dont des sites pornos, scores FR à 0, doublons partout, queue zombie) à un système propre et stable (5 indexers, scoring correct, architecture séparée, health checks automatisés).

La prochaine étape est de passer de stable à autonome : un système qui non seulement détecte ses propres problèmes mais les résout, et qui anticipe les besoins avant qu'ils ne deviennent des urgences.

Et au-delà de l'autonomie, la section suivante explore des outils complémentaires pour optimiser l'espace, automatiser la curation, et gérer la rétention — des briques essentielles pour un seedbox qui tourne vraiment tout seul.

11. Nouvelles optimisations — curation, rétention et gain d'espace [🤖 Gemini]

Ajout juin 2026 — analyse croisée Hermes + Gemini pour compléter la roadmap vers l'autonomie.

Ces quatre outils sont purement algorithmiques (open-source, pas de LLM, pas de tokens). Ils s'intègrent à la stack existante pour couvrir trois angles morts de notre architecture actuelle : la qualité vidéo automatisée, l'enrichissement de la librairie, et le nettoyage intelligent.

11.1 Recyclarr — profils de qualité synchronisés avec la communauté

Recyclarr est un outil CLI qui synchronise automatiquement les configurations Sonarr/Radarr avec les TRaSH Guides — les standards de la communauté *Arr.

Ce que ça apporte par rapport à notre setup manuel actuel : - Les custom formats TRaSH (x265, HEVC, 10bit, groupes à éviter) sont importés automatiquement - Les scores de priorité sont maintenus à jour sans intervention humaine - Fini le risque qu'un profil revienne à french=0 sans qu'on le sache - Supporte nos profils FR/MULTI via les templates de langue

Intégration à notre roadmap : correspond à la Phase 2.2 déjà planifiée. Installation : un binaire sur le VPS, un fichier YAML de config, un cronjob Hermes mensuel.

Configuration type (fichier recyclarr.yml) :

sonarr:
  series-fr:
    base_url: https://sonarr.evilguard.box.ca
    api_key: !env SONARR_API_KEY
    quality_definition: series
    quality_profiles:
      - name: HD-720p/1080p
        reset_unmatched_scores: true
        qualities:
          - name: Bluray-1080p
          - name: WEB-1080p
          - name: Bluray-720p
        custom_formats:
          # Priorité x265/HEVC pour économiser l'espace
          - names: [x265 (HD), HEVC]
            scores: [100]
          # On garde notre scoring FR — Recyclarr ne touche pas aux CFs qu'on ne liste pas
          - names: [MULTi|DUAL]
            scores: [100]
          - names: [French Audio]
            scores: [50]
          - names: [VOSTFR]
            scores: [30]
radarr:
  movies-fr:
    base_url: https://radarr.evilguard.box.ca
    api_key: !env RADARR_API_KEY
    quality_definition: movie
    quality_profiles:
      - name: HD-1080p
        custom_formats:
          - names: [x265 (HD), HEVC]
            scores: [100]
          - names: [MULTi|DUAL]
            scores: [100]
          - names: [French Audio]
            scores: [50]

⚠️ Recyclarr ne remplace PAS notre scoring FR manuel — il le complète avec les formats techniques (codec, groupe). Les deux couches coexistent.

11.2 Kometa — collections dynamiques et curation automatique

Kometa (anciennement Plex Meta Manager) s'intègre à DEMONPLEX/Jellyfin pour enrichir la librairie avec des métadonnées et des collections automatisées.

Ce que ça fait concrètement : - Crée des collections dynamiques basées sur des listes Trakt, IMDb, TMDb, Letterboxd - Exemple : collection « Top 250 IMDb », « Animés de la saison », « Films français primés » - Interroge Radarr/Sonarr pour identifier les médias manquants dans ces collections - Peut déclencher automatiquement l'ajout des titres manquants dans Radarr/Sonarr

Pourquoi c'est pertinent pour nous : - Plus besoin de chercher manuellement « quels films français sont sortis ce mois-ci » - Kometa fait la curation éditoriale et Overseerr gère l'approbation - Les collections apparaissent dans DEMONPLEX comme des catégories « Netflix-style »

Intégration à notre roadmap : ce n'est pas dans les phases 1-4 actuelles — c'est une couche supplémentaire entre la Phase 2 (semi-auto) et la Phase 3 (curation agent). Kometa automatise la curation éditoriale pendant que l'agent Hermes garde la supervision stratégique.

Installation : conteneur Docker sur le VPS, config YAML pointant vers l'API DEMONPLEX et les APIs *Arr. Cron quotidien.

11.3 Tdarr / Unmanic — transcodage automatique H.264 → H.265

Tdarr et Unmanic sont des moteurs d'analyse et de transcodage vidéo qui tournent en arrière-plan.

Le problème qu'ils résolvent : Beaucoup de releases sont encodées en H.264, un codec qui produit des fichiers volumineux. Le H.265 (HEVC) offre une qualité visuelle identique pour une taille de fichier 40 à 60% inférieure.

Fonctionnement : 1. Le moteur scanne le dossier /home/evilguard/files/ 2. Identifie les fichiers H.264 (via ffprobe) 3. Transcode la piste vidéo en H.265 tout en copiant l'audio et les sous-titres sans perte 4. Remplace le fichier original (ou le place à côté selon la config)

Gain estimé pour notre librairie : - 828 torrents seedés × moyenne ~2-5 Go par fichier → potentiellement 2-4 To d'espace récupéré - Pour de l'anime en 1080p : réduction typique de 1.5 Go → 600 Mo par épisode

⚠️ Mises en garde critiques :

Recommandation : commencer par un test sur 5-10 fichiers anime (les plus petits, les plus rapides) via Unmanic en mode dry-run pour mesurer le gain réel avant de déployer à grande échelle.

Intégration à notre roadmap : Phase 3 (autonomie avancée) ou Phase 4 (rêve). C'est le projet le plus lourd techniquement, mais avec le plus gros retour sur investissement en espace disque.

11.4 Maintainerr — règles de rétention et nettoyage automatique

Maintainerr est une interface de règles de rétention pour Plex/Jellyfin/*Arr.

Le problème : actuellement, rien ne supprime jamais rien. Les séries terminées qu'on a regardées il y a 3 ans dorment sur le disque pour toujours.

Règles de rétention proposées :

Détails techniques : - Maintainerr se connecte à DEMONPLEX pour savoir ce qui a été regardé - Se connecte à Sonarr/Radarr pour déclencher la suppression - Utilise deleteFiles=false par défaut (retire juste de la librairie *Arr) - Mode dry-run disponible pour simuler avant d'exécuter

Économie potentielle : en appliquant ces règles, on pourrait libérer 30-50% de l'espace occupé par du contenu déjà consommé.

Intégration à notre roadmap : correspond à la Phase 3.4 (auto-scaling de la librairie). Maintainerr est la brique technique qui implémente les règles de décision. L'agent Hermes garde la supervision : « 12 séries et 8 films éligibles à la suppression — exécuter ? »

11.5 Synthèse — comment ces outils s'intègrent à notre roadmap

OUTIL           → PHASE ACTUELLE    EFFORT    GAIN PRINCIPAL
─────────────────────────────────────────────────────────────
Recyclarr       → Phase 2.2         ★☆☆       Profils toujours à jour
Kometa          → Phase 2.5 (NEW)   ★★☆       Curation éditoriale auto
Tdarr/Unmanic   → Phase 3 (avancé)  ★★★       Gain 40-60% espace disque
Maintainerr     → Phase 3.4         ★★☆       Nettoyage intelligent

Aucun de ces outils ne consomme de tokens LLM. Ce sont des binaires/containers open-source qui tournent en cron ou en daemon. L'agent Hermes reste le superviseur : il reçoit les rapports, valide les actions destructives, et garde la vue d'ensemble.

11.6 Prochaines actions concrètes

1. Cette semaine : installer Recyclarr sur le VPS, configurer le YAML de base, premier dry-run
2. Semaine prochaine : installer Kometa en conteneur Docker, connecter à l'API DEMONPLEX, créer 2-3 collections test
3. Ce mois-ci : évaluer si le transcodage H.264→H.265 est viable sur notre infra (test Unmanic sur 5 fichiers anime)
4. Prochain mois : installer Maintainerr, configurer les règles de rétention en dry-run, valider les suppressions proposées avant exécution

12. Angles morts — monitoring passif, redondance et validation [🤖 Claude Sonnet 4.6]

Ajout juin 2026 — Claude Sonnet 4.6 a identifié des angles morts que ni la roadmap initiale ni Gemini n'avaient couverts.

Ces sept points ne sont pas des « features à construire » mais des trous de sécurité opérationnelle : des risques qui ne sont pas détectés par nos health checks actuels. La plupart se résolvent avec des scripts de 20 à 50 lignes.

12.1 FlareSolverr — plan de survie quand Cloudflare bloque tout

Le problème (rappel) : FlareSolverr est le proxy qui contourne les challenges Cloudflare pour les indexers protégés. Il est actuellement down chez nous (signalé « All indexer proxies unavailable » dans Prowlarr). Avec l'évolution de Cloudflare vers Turnstile (challenges invisibles), le FlareSolverr classique (v1/v2) est cassé pour de bon.

La solution en 2026 — fork 21hsmw : - Le fork FlareSolverr v3 / 21hsmw intègre le support Turnstile et des challenges JS plus modernes - Alternative : FlareSolverr-rotating-HA avec un pool de proxies résidentiels - Ces forks ne sont pas « officiels » mais ils sont activement maintenus et testés contre les défis Cloudflare actuels

Plan d'action : 1. Vérifier si C411 est réellement derrière Cloudflare → curl -I https://c411.org (chercher cf-ray dans les headers) 2. Si oui : remplacer le conteneur FlareSolverr actuel par le fork 21hsmw (docker pull 21hsmw/flaresolverr:latest) 3. Tester dans Prowlarr : POST /indexer/test sur l'indexer C411 4. Si le test passe → redéployer, sinon → chercher un proxy résidentiel ou un autre indexer FR

Si FlareSolverr reste cassé : chercher un indexer FR/MULTI qui n'est PAS derrière Cloudflare (YGG est mort, Pirate Bay est public → les releases FR y sont rares). Alternatives à évaluer : Sharewood, TheCinemaClub, un tracker FR privé.

⚠️ Note : certains seedbox (dont Whatbox) peuvent bloquer FlareSolverr par politique. Vérifier les ToS avant de redéployer.

Priorité : 🔴 Urgent si C411 est derrière CF et FlareSolverr est down. Un indexer principal inaccessible = tout le téléchargement FR est bloqué.

12.2 Monitoring Transmission en lecture seule — ratios et santé des trackers

La règle d'or est « Transmission = off-limits pour toute écriture ». 100% d'accord.

Mais ça ne veut pas dire zéro visibilité. Un script read-only qui interroge le RPC Transmission peut donner des alertes vitales sans jamais toucher à un torrent.

Ce que le script lit (via transmission-remote) : - Ratio de chaque torrent (upload/download) - Temps de seed - Torrents en erreur (status=error) - Trackers muets (pas de réponse depuis X heures) - Torrents en pause/arrêtés anormalement

Alarmes à configurer :

Script minimal (SSH, read-only, 0 tokens) :

# Via SSH sur le seedbox (transmission-remote est installé par défaut sur Whatbox)
ssh evilguard@goji.whatbox.ca 'transmission-remote --list' | \
  awk 'NR>2 {print $1, $2, $4, $5, $6}' | \
  python3 -c "
import sys, json
for line in sys.stdin:
    parts = line.strip().split()
    if len(parts) >= 5:
        tid, done, size, ratio, status = parts[0], parts[1], parts[2], parts[3], parts[4]
        # Ratio parsing — transmission-remote affiche '0.0', '1.5', 'None', 'N/A'
        try:
            r = float(ratio)
            if r < 0.5 and float(done.rstrip('%')) >= 100:
                print(f'LOW RATIO: torrent {tid} seeded {done}, ratio={r}')
        except ValueError:
            pass  # skip non-numeric ratios
"

Sécurité : le script utilise transmission-remote --list qui est purement read-only. Aucun flag --remove, --stop, --start, --verify ne figure dans la commande. Le seul appel modifiant quoi que ce soit déclencherait une alarme dans l'audit du script.

Résultat : un cronjob Hermes quotidien (no_agent=true) qui alerte Telegram seulement si des torrents dépassent les seuils de ratio. Silencieux sinon.

12.3 Redondance d'indexers — le problème du mono-indexer FR

État actuel : 5 indexers dans Prowlarr. 4 sont des trackers anime (Nyaa.si, SubsPlease, Tokyo Toshokan, Shana Project). Un seul indexer couvre le contenu général FR/MULTI : C411.

Si C411 tombe (API key expirée, maintenance, Cloudflare qui bloque, ban du compte) : - ✅ Anime continue à fonctionner (Nyaa + SubsPlease) - ❌ Films FR, séries FR, tout le contenu MULTi/VF — plus aucun téléchargement possible

Solutions à évaluer :

Recommandation immédiate : option la moins chère = ajouter un indexer public FR dans Prowlarr (via Jackett si nécessaire) comme fallback silencieux. Configuré avec un score plus bas que C411 dans les profils de qualité, il ne sera jamais choisi sauf si C411 est indisponible.

À faire cette semaine : vérifier quels indexers publics FR sont encore actifs en 2026 → test de connexion via Prowlarr POST /indexer/test.

12.4 ntfy — bus d'alertes secondaire

État actuel : ntfy tourne sur le VPS (port 2586) mais n'est utilisé par rien. Le canal d'alerte principal est Telegram (via les cronjobs Hermes et le deliver).

Le risque : si Hermes ou Telegram est down (rate-limit, blocage IP, panne du gateway), les alertes critiques (disque plein, tracker down, ratio faible) n'arrivent pas.

Plan (effort minimal) : 1. Le script de monitoring ratio (12.2) et le health check hebdo envoient aussi vers ntfy 2. ntfy est configuré avec un webhook vers Home Assistant (si utilisé) 3. L'app ntfy sur le téléphone reçoit les alertes critiques même si Telegram est muet

Une ligne dans un script :

curl -s -d "ALERTE: Ratio faible torrent #42 — ratio=0.3" https://ntfy.evilai.fun/seedbox-alerts

Aucun changement d'infrastructure — ntfy est déjà déployé, juste pas utilisé.

12.5 Changedetection.io — surveillance de C411 et Whatbox

État actuel : Changedetection.io surveille des sites web pour le briefing (changements de contenu). Mais on ne surveille pas les pages de statut de notre propre infra.

2 URLs à ajouter (30 secondes) : 1. Page de statut C411 (s'ils en ont une) ou page d'accueil C411 (détecte si le site est down) 2. Page de statut Whatbox : https://whatbox.ca/status ou leur page d'incidents

Avantage : Changedetection alerte AVANT que le health check hebdo ne détecte la panne — et avant que toi tu ne remarques que les downloads sont bloqués depuis 3 jours.

Effort : 0 code. 2 URLs dans l'interface Changedetection.io. Notification vers ntfy ou Telegram.

12.6 Bazarr — angle mort de la qualité des sous-titres

Le problème : Bazarr télécharge des sous-titres, mais personne ne vérifie leur qualité. Un sous-titre VOSTFR peut être : - Parfaitement synchronisé - Décalé de 2 secondes (agaçant mais lisible) - Complètement désynchronisé (inutilisable) - Partiel (seulement les 10 premières minutes) - Machine-translated (qualité médiocre)

Solution : un script subliminal (CLI Python) peut : 1. Scanner les fichiers déjà sous-titrés par Bazarr 2. Scorer chaque sous-titre (match de nom, hash, score de confiance) 3. Reporter ceux qui sont en dessous d'un seuil

# Exemple — subliminal score les sous-titres existants
subliminal --verbose download -l fr --age 7d /home/evilguard/files/serie\ tele/
# En mode --dry-run, il liste ce qu'il téléchargerait SANS rien modifier

Priorité : 🟢 Faible. C'est un problème de qualité, pas de fonctionnement. Mettre ça en Phase 3 (quand les urgences sont réglées).

12.7 Validation post-import — est-ce que le fichier a vraiment du français ?

Le problème : le scoring Custom Formats favorise les releases marquées MULTI, mais personne ne vérifie que la piste audio FR est réellement présente dans le fichier. Les releases sont taguées par les uploaders, pas par une vérification automatique.

Scénario réel : un uploader tag MULTi parce que le fichier MKV a un flag de langue fra dans ses métadonnées — mais la piste est vide, mal encodée, ou pire : c'est une VOSTFR taguée MULTI par erreur. Sonarr l'importe avec un score de +100, et DEMONPLEX affiche le film comme « disponible en français ».

Solution — script ffprobe hebdomadaire sur un échantillon aléatoire :

# 1. Lister les 20 derniers imports Sonarr/Radarr
# 2. Via SSH, ffprobe sur chaque fichier
# 3. Vérifier la présence d'une piste audio avec lang=fre/fra
# 4. Si absent → alerte « MULTI tagué mais pas de piste FR »

# Commande type (sur un fichier)
ssh evilguard@goji.whatbox.ca \
  "ffprobe -v quiet -show_entries stream=index,codec_type,codec_name:stream_tags=language \
   -of json 'FICHIER.mkv'" | \
  python3 -c "
import sys, json
tracks = json.load(sys.stdin)
has_fr = any(
    s.get('codec_type') == 'audio' and 
    s.get('tags', {}).get('language', '') in ('fre', 'fra')
    for s in tracks.get('streams', [])
)
print('OK' if has_fr else 'PAS DE PISTE FR')
"

Fréquence : hebdomadaire, sur les 20 derniers imports. Si > 10% des fichiers n'ont pas de piste FR malgré le scoring MULTI → alerte Telegram.

Coût : ~5 secondes par fichier × 20 fichiers = ~2 minutes par semaine. SSH read-only, aucun fichier modifié.

Priorité : 🟡 Moyenne. Pas urgent mais ça ferme un angle mort réel. Si 15% de notre librairie MULTI n'a pas de français en pratique, tout le scoring est compromis.

12.8 Synthèse — les 7 angles morts

Ce qui peut être fait ce weekend : les items 12.1, 12.2, 12.4, 12.5 — les quatre ensemble prennent moins de 2 heures et ferment les risques les plus critiques.

13. Architecture de l'autonomie — de la détection à la réparation [🤖 GPT-4o]

Ajout juin 2026 — GPT-4o a analysé l'ensemble du document. Sur ses 8 recommandations, 4 étaient déjà couvertes (points 2, 4, 5, 7) et 4 apportent un regard architectural nouveau.

L'analyse de GPT est centrée sur une idée-force : le système ne manque pas de monitoring — il manque de boucles fermées. Détecter un problème, c'est bien. Le réparer automatiquement et n'alerter que si la réparation échoue, c'est l'autonomie.

13.1 Le modèle de la boucle fermée — detect → verify → repair → confirm → escalate

État actuel : la plupart de nos checks s'arrêtent à l'étape « detect + report ». Le health check hebdo liste les problèmes et attend l'humain. Même les scripts no_agent (hourly_collect, morning_briefing) sont des collecteurs, pas des réparateurs.

Le modèle cible en 5 étapes :

DÉTECTER  →  VÉRIFIER  →  RÉPARER  →  CONFIRMER  →  ESCALADER
(script)     (cross-       (action      (re-check      (seulement
             check)        safe)        post-action)   si échec)

Exemple concret — nettoyage de queue zombie :

Le point clé de GPT : ne jamais escalader avant d'avoir essayé de réparer. Si la réparation échoue, le message Telegram arrive AVEC le diagnostic et la tentative échouée — l'humain n'a pas à refaire l'enquête.

Ce modèle s'applique à : - Queue zombie → auto-clean si hasFile=True - Indexer down → auto-retest 3× en 30 minutes avant d'alerter - Import bloqué → auto-retrigger EpisodeSearch 1× avant d'alerter - Disque > 85% → auto-dry-run Maintainerr, proposer la liste, ne pas supprimer

Ce qui ne s'automatise PAS (escalade immédiate) : - Tout ce qui touche à deleteFiles=true - Tout ce qui touche à Transmission (même en lecture, on ne répare pas) - Changement de profil de qualité (risque de re-download massif) - Approbation Overseerr > 50 Go (séries complètes, 4K)

13.2 Backups testés, pas juste sauvegardés

État actuel : Phase 1.1 propose un backup quotidien des configs *Arr (bases SQLite, config.xml, Custom Formats). Mais le document ne mentionne pas la restauration de test.

Ce que GPT souligne (et il a raison) : « A backup you haven't restored is a guess, not a backup. »

Procédure de test de restauration — à exécuter 1× par mois :

1. Créer un conteneur Sonarr jetable (Docker, port aléatoire, volume vide)
2. Restaurer le dernier backup SQLite + config.xml dans le conteneur
3. Vérifier que :
   - Les séries sont listées (count = même que prod)
   - Les profils de qualité ont les bons scores (french=+50, MULTI=+100)
   - Les indexers Prowlarr sont joignables (test de connexion)
   - Les root folders sont montés (ou au moins listés)
4. Détruire le conteneur

Automatisation : un script test_restore.sh exécuté par un cronjob Hermes mensuel (no_agent=true). Il spin un conteneur, restaure, valide 4 assertions, nettoie, et envoie ✅ Restore test OK ou ❌ Restore test FAILED: <raison> sur Telegram.

Coût : ~2 minutes de CPU par mois. Aucun token. Juste Docker + curl.

13.3 « Dry-run first » comme politique système, pas comme bonne pratique

État actuel : le dry-run est mentionné à plusieurs endroits (Maintainerr en 11.4, cleanup filesystem en section 8, Unmanic en 11.3) mais comme une suggestion locale, pas comme une règle transverse.

Ce que GPT recommande : toute action destructive doit avoir un mode dry-run obligatoire avant exécution. Et ce dry-run doit être traçable (loggé, horodaté, avec le résultat affiché).

Politique proposée — à appliquer à tous les nouveaux scripts :

# Template standard pour tout script destructif
DRY_RUN = os.environ.get("DRY_RUN", "true").lower() == "true"

def delete_queue_entry(queue_id):
    if DRY_RUN:
        log(f"[DRY-RUN] Would delete queue entry {queue_id}")
        return {"simulated": True, "id": queue_id}
    else:
        resp = call("sonarr", "DELETE", f"queue/{queue_id}", 
                     params={"removeFromClient": "false"})
        log(f"[LIVE] Deleted queue entry {queue_id} — status: {resp}")
        return resp

Règle : le cronjob passe toujours en DRY_RUN=true en première exécution. Le rapport arrive sur Telegram : « 12 entrées à nettoyer, 3 indexers à retester, 0 fichier à supprimer. Envoyer EXECUTE pour lancer. »

L'humain répond EXECUTE → le cronjob repasse avec DRY_RUN=false.

C'est plus lent qu'un auto-clean silencieux, mais c'est infiniment plus sûr. Et après 2-3 semaines sans faux positifs, on peut passer certains nettoyages en auto (queue zombie, retest indexer) tout en gardant le dry-run obligatoire pour les suppressions de fichiers.

13.4 La couche d'orchestration — un maître, des travailleurs

C'est la recommandation architecturale la plus structurelle de GPT.

État actuel — ce qui contrôle quoi :

Hermes cronjobs (5)     → health check, briefing, collecte RSS
n8n                     → workflows visuels (installé, peu utilisé)
Cronicle                → scheduler alternatif (installé, inutilisé)
Scripts no_agent (3)    → hourly_collect, morning_briefing, briefing_prune
cron (système)          → aucun (tout passe par Hermes)

Le problème : si on ajoute 5 nouveaux scripts pour la Phase 1 (backup, disk alert, Prowlarr check, ratio Transmission, FlareSolverr check), on se retrouve avec ~10 jobs indépendants qui ne se parlent pas. Si le job « disk alert » détecte un disque plein pendant que le job « Prowlarr check » essaie de lancer un search, personne ne fait le lien.

La recommandation de GPT : un orchestrateur unique qui : 1. Possède l'état — sait ce qui est en cours, ce qui a échoué, ce qui est bloqué 2. Séquence les actions — ne lance pas un search si le disque est à 90% 3. Centralise les alertes — un seul flux Telegram, pas 10 jobs qui ping chacun de leur côté 4. Survit aux pannes — si le VPS reboot, l'orchestrateur reprend là où il était

Deux candidats naturels dans notre stack :

Recommandation : rester sur Hermes comme cerveau central (les cronjobs existent déjà, on les maîtrise) mais ajouter un job « superviseur » unique qui remplace les jobs indépendants de la Phase 1 :

Toutes les heures — job superviseur (no_agent=false, 1 seul job) :
├── 1. Script backup_configs.py       (no_agent: backup DB → .tar.gz)
├── 2. Script check_disk.py            (no_agent: alert si >85%)
├── 3. Script check_prowlarr.py        (no_agent: indexers OK ?)
├── 4. Script check_flaresolverr.py    (no_agent: FlareSolverr répond ?)
├── 5. Script check_transmission.py    (no_agent: ratios, via SSH R/O)
├── 6. Agent (Hermes) — consolide les 5 rapports
│   → Si tout OK : silencieux (pas de message)
│   → Si 1-2 warnings : 1 message consolidé Telegram
│   → Si critique (disque >95%, C411 down) : ALERTE immédiate
└── 7. Agent — si dry-run approuvé, exécute les réparations safe

Avantage : un seul job à superviser, un seul flux Telegram, une seule boucle de décision. Les scripts restent indépendants et testables unitairement — le job superviseur les orchestre.

Évolution future : si la complexité explose (20+ scripts, dépendances entre eux), migrer vers n8n. Mais pour la Phase 1-2, Hermes + 1 job superviseur est le bon ratio simplicité/puissance.

13.5 Ce que GPT confirme (déjà dans le document)

Quatre des huit recommandations de GPT sont déjà traitées dans les sections précédentes. Il les a identifiées indépendamment, ce qui renforce leur priorité :

Ce recoupement est précieux : trois modèles différents (Gemini, Claude, GPT) ont identifié indépendamment les mêmes risques. Ça valide le diagnostic.

13.6 Synthèse — contributions nettes de GPT

La phrase à retenir de GPT : « The project doesn't need more automation first. It needs safer automation first. »

C'est le principe directeur pour toute la Phase 1 : chaque nouveau script commence par un dry-run, chaque réparation est vérifiée après coup, et l'humain n'est dérangé que si la machine a échoué.

14. Accélération opérationnelle — outils de power-user [🤖 Grok 4]

Ajout juin 2026 — Grok 4 a fourni l'analyse la plus « terrain » des quatre modèles. Il a confirmé 8 points déjà couverts et apporté 2 outils que personne d'autre n'avait mentionnés, plus 2 améliorations concrètes.

L'approche de Grok est résolument orientée seedbox privé + tracker privé : IRC racing, tableau de bord natif *Arr, cross-seed. C'est le seul modèle qui a parlé le langage du power-user de tracker.

14.1 Ce que Grok confirme (déjà dans le document)

Grok a identifié 8 points déjà traités — le taux de recoupement le plus élevé des quatre contributeurs. C'est une excellente nouvelle : cinq modèles indépendants convergent sur les mêmes priorités.

14.2 autobrr — IRC racing, le game-changer pour tracker privé

C'est LA contribution majeure de Grok. Aucun des quatre autres modèles n'a mentionné autobrr, et c'est pourtant l'outil le plus impactant pour un seedbox avec tracker privé.

autobrr est un daemon qui surveille les annonces IRC des trackers privés en temps réel. Là où Prowlarr poll les flux RSS toutes les ~15-30 minutes, autobrr reçoit l'annonce instantanément via IRC.

La différence concrète :

Prowlarr RSS (actuel) :    [sortie du release] ... 15-30 min ... [Prowlarr voit] → [envoie à Sonarr] → [recherche]
autobrr IRC (cible) :      [sortie du release] → [autobrr reçoit] → [push instantané] → [Sonarr import]
                            └── délai : < 5 secondes ──┘

Pourquoi c'est critique pour nous : - Sur C411 (tracker privé), les releases populaires ont des centaines de leechers dans les 60 premières secondes - Plus on arrive tôt dans le swarm, plus on upload → meilleur ratio - Pour le contenu FR/MULTI, être dans les premiers = différence entre ratio 2.0 et ratio 0.3 - autobrr peut appliquer des filtres complexes (langue, résolution, taille, release group) AVANT de push → pas de bruit

Filtre type pour notre stack :

# Exemple — filtre autobrr pour contenu FR/MULTI
filters:
  - name: "FR-MULTI-1080p"
    match_releases: "MULTi.*1080p|FRENCH.*1080p|VFQ.*1080p"
    must_not_contain: ["4K", "2160p", "CAM", "TS", "HC"]
    min_size: "500MB"
    max_size: "15GB"
    actions:
      - type: "sonarr"
      - type: "radarr"

Architecture de déploiement : - autobrr tourne sur le VPS Hostinger en conteneur Docker (~50 MB RAM) - Il se connecte au canal IRC de C411 (si C411 a un announce channel IRC — à vérifier) - Il push directement vers Sonarr/Radarr sur le seedbox via leurs API HTTPS - Si C411 n'a PAS d'IRC, autobrr peut quand même servir de filtre avancé sur les flux RSS

Priorité : 🟠 Phase 2. C'est le plus gros saut qualitatif en termes d'automatisation après la Phase 1. À planifier juste après Recyclarr.

Note : il faut vérifier que C411 a un canal IRC d'annonce. Les trackers privés français n'ont pas toujours cette infrastructure. Si IRC n'est pas dispo, le mode RSS filtré d'autobrr reste utile mais perd l'avantage de vitesse.

14.3 Notifiarr — dashboard natif *Arr et notifications riches

Notifiarr est un pont entre les applications *Arr et Discord (ou d'autres plateformes). C'est le seul outil de la liste qui offre une intégration native et bidirectionnelle avec Sonarr, Radarr, Prowlarr, et Bazarr.

Ce que ça apporte par rapport à notre setup actuel (Telegram + Hermes cron) :

Le dashboard Notifiarr en particulier : une interface web qui montre l'état de Sonarr, Radarr, Prowlarr, Bazarr en une seule page — downloads en cours, espace disque, santé des indexers, erreurs récentes. C'est ce que notre roadmap Phase 4.1 envisageait de construire manuellement.

Points de friction :

Recommandation : installer Notifiarr en complément du health check Hermes, pas en remplacement. Hermes garde l'analyse hebdomadaire approfondie + le dry-run + les actions. Notifiarr apporte le temps réel et le dashboard visuel que Hermes ne peut pas fournir (pas d'interface web).

Déploiement : conteneur Docker sur le VPS Hostinger (~50 MB RAM). Configuration via une interface web. Connexion aux API *Arr existantes.

Priorité : 🟡 Phase 2-3. Utile mais pas critique. Les notifications Telegram + Hermes couvrent déjà l'essentiel. Notifiarr est un confort, pas une nécessité.

14.4 BorgBackup — déduplication et stockage hors-seedbox

État actuel : Phase 1.1 mentionne rsync comme outil de backup. Grok suggère BorgBackup comme alternative plus puissante.

Différence rsync vs Borg :

Pour nos backups de config *Arr : - Bases SQLite + XML = ~50-100 Mo par backup - Avec Borg : 30 jours d'historique = ~100 Mo + incréments (~5 Mo/jour) = ~250 Mo total - Avec rsync : 30 jours × 100 Mo = 3 Go (ou on ne garde que la dernière)

Script type :

#!/bin/bash
# Backup quotidien des configs *Arr vers Borg
export BORG_PASSPHRASE="$(cat /root/.borg_passphrase)"

# Initialiser le repo (première fois)
borg init --encryption=repokey /mnt/backups/seedbox-configs.borg

# Backup
borg create --stats --compression lz4 \
  /mnt/backups/seedbox-configs.borg::'{hostname}-{now:%Y-%m-%d}' \
  /home/evilguard/.arr_keys.json \
  /home/evilguard/.config/Sonarr/Backups/ \
  /home/evilguard/.config/Radarr/Backups/ \
  /home/evilguard/.config/Prowlarr/Backups/

# Nettoyage : garder 7 jours, 4 semaines, 6 mois
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 \
  /mnt/backups/seedbox-configs.borg

⚠️ Stockage hors-seedbox : Grok a raison d'insister là-dessus. Si le seedbox est compromis, un backup stocké SUR le seedbox ne sert à rien. La destination doit être le VPS Hostinger (/root/backups/seedbox/). Le script tourne sur le VPS et pull les backups via SSH — c'est le VPS qui va chercher les données, pas le seedbox qui les push.

Priorité : 🟠 Phase 1.1 (backup). Borg remplace rsync dans le plan Phase 1. Même effort, meilleur résultat.

14.5 Analyse historique Sonarr/Radarr — quel release group est fiable ?

C'est l'idée la plus « IA » de Grok : utiliser l'historique des imports pour entraîner des décisions futures.

Le concept : 1. Analyser l'historique Sonarr/Radarr (1-6 mois) via leur API 2. Croiser avec les succès/échecs de download 3. Identifier les release groups fiables pour le contenu FR/MULTI 4. Bloquer automatiquement (ou baisser le score) des groupes problématiques

Ce que ça pourrait révéler (exemples hypothétiques) :

Implémentation : - Script Python qui interroge /api/v3/history?pageSize=500 (Sonarr) et /api/v3/history?pageSize=500 (Radarr) - Parse le nom de la release pour extraire le groupe (dernier segment après -) - Croise avec le statut de l'import (imported vs failed) - Génère un rapport : « 3 groupes à bloquer, 2 groupes recommandés » - L'humain valide avant application

Où ça s'intègre : ce n'est pas dans les phases 1-4 actuelles. C'est une couche d'intelligence qui peut s'ajouter à partir de la Phase 3. Pas de nouvelle dépendance — juste de l'analyse de données existantes.

Priorité : 🟢 Phase 3+. Intéressant mais pas urgent. Les Custom Formats TRaSH + Recyclarr couvrent déjà une partie de ce besoin.

14.6 Bazarr provider health + Prowlarr sync status — deux checks oubliés

Grok a pointé deux métriques spécifiques que nos health checks actuels ne couvrent pas :

Bazarr — santé des providers de sous-titres : - GET /api/providers → vérifier qu'au moins 1 provider FR est activé - GET /api/system/languages → vérifier que fr est dans les langues - Si 0 providers FR actifs → Bazarr télécharge 0 sous-titres, et le compteur wanted reste à 0 (sans erreur visible) - C'est un silent failure — tout a l'air de marcher, mais rien ne se passe

Prowlarr — statut de la dernière synchronisation : - GET /api/v1/indexerstats → vérifier la date du dernier sync réussi - Si le dernier sync date de >24h → les indexers n'envoient plus de nouveaux résultats à Sonarr/Radarr - Cause possible : Prowlarr est up mais le mécanisme de sync est cassé (bug, timeout, API key expirée)

À ajouter au health check hebdo (SOP-A) et au job superviseur horaire (Section 13.4) :

# Bazarr
providers = call("bazarr", "GET", "system/providers")
fr_active = [p for p in providers.get("data", []) if p.get("enabled") and "fr" in str(p.get("languages", [])).lower()]
if not fr_active:
    alert("⚠️ Bazarr : aucun provider FR actif — aucun sous-titre téléchargé")

# Prowlarr sync
stats = call("prowlarr", "GET", "indexerstats")
last_sync = stats.get("lastSyncTime")
if last_sync and (now - last_sync).days > 1:
    alert("⚠️ Prowlarr : dernière synchronisation > 24h — indexers non propagés")

Priorité : 🟠 Phase 1 (à inclure dans le health check dès maintenant). 5 lignes de code, zéro coût.

14.7 Ffprobe → re-search automatique en cas d'échec

C'est une extension de la Section 12.7 (Claude). Claude a proposé la validation ffprobe. Grok propose d'aller plus loin : si la validation échoue, déclencher automatiquement une re-search.

Workflow :

ffprobe → piste FR absente → alerte + trigger POST /command {name: "EpisodeSearch", episodeIds: [id]}

Pourquoi c'est malin : le fichier MULTI tagué sans piste FR est probablement un faux tag de l'uploader (piste FR annoncée dans le nom mais absente du fichier). Une autre release du même épisode aura peut-être la vraie piste MULTI. Autant re-search tout de suite plutôt que d'attendre la prochaine recherche automatique.

La boucle complète (détection → réparation) : 1. Script ffprobe hebdo → scanne les 20 derniers imports 2. Si piste FR absente → log l'épisode + release group fautif 3. POST /command {name: "EpisodeSearch", episodeIds: [id]} → re-search 4. Si le re-search trouve un meilleur fichier → l'ancien est remplacé automatiquement 5. Si toujours pas de FR après 2 tentatives → alerter l'humain

Ajouter à la boucle fermée de Section 13.1 :

DÉTECTER (ffprobe) → VÉRIFIER (piste FR absente ?) → RÉPARER (re-search) → CONFIRMER (nouveau ffprobe) → ESCALADER (si 2 échecs)

Priorité : 🟡 Phase 2-3. Nécessite que le health check de base soit stable d'abord.

14.8 Git versioning des configurations *Arr

Suggestion légère mais pertinente : versionner les exports de config dans Git.

Ce que ça apporte par rapport au backup classique : - Historique des changements : « Qui a changé le score MULTI de +100 à +20 et quand ? » - Diff visuel : git diff entre deux versions de la config - Rollback facile : git checkout <commit> pour revenir à une config stable

Fichiers à versionner :

seedbox-config/
├── sonarr/
│   ├── quality-profiles.json      # Export API
│   ├── custom-formats.json
│   └── settings.json
├── radarr/
│   ├── quality-profiles.json
│   ├── custom-formats.json
│   └── settings.json
├── prowlarr/
│   ├── indexers.json
│   └── applications.json
└── README.md                       # Explication des profils, historique des changements

Automatisation : un script export_configs.sh qui : 1. Appelle les API *Arr pour exporter les configs en JSON 2. Commit dans le repo Git local 3. Push vers un repo privé (GitHub/GitLab) 4. Tourne en cron hebdomadaire (no_agent=true)

Priorité : 🟢 Phase 2. Faible effort, bonne hygiène, pas critique.

14.9 Synthèse — contributions nettes de Grok

Le mot de Grok : « Your foundation is already better than most people's final state. »

C'est le seul modèle qui a formulé un compliment sur l'architecture existante avant de proposer des améliorations. Et sa reco autobrr est la contribution la plus « seedbox-native » des cinq modèles — personne d'autre n'a pensé à l'IRC racing, qui est pourtant la pratique standard des power-users de trackers privés.

Document rédigé le 6 juin 2026 par l'agent Hermes pour EViLGUARD. Dernière mise à jour : 6 juin 2026 — ajout Sections 11 (🤖 Gemini), 12 (🤖 Claude), 13 (🤖 GPT-4o), 14 (🤖 Grok 4)