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]
15. Derniers kilomètres vers 100 % — confiance graduée et auto-maintenance [🤖 Manus]
16. Discipline opérationnelle — audit, runbooks et hygiène documentaire [🤖 Perplexity]

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 (, 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 <REDACTED> '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 <REDACTED> \
  "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.

15. Derniers kilomètres vers 100 % — confiance graduée et auto-maintenance [🤖 Manus]

Ajout juin 2026 — Manus a fait l'analyse la plus systémique des six modèles. Sa force : proposer des mécanismes graduels qui transforment les points de décision humains en logiques automatisées, sans rupture brutale.

L'approche de Manus est complémentaire de celle de GPT : là où GPT a posé l'architecture (boucle fermée, dry-run, orchestration), Manus propose les mécanismes de transition qui font passer chaque étape de « supervisé par l'humain » à « autonome sous surveillance ».

15.1 Ce que Manus confirme (déjà couvert)

Manus a récapitulé l'ensemble des sections 11-14 sans contradiction. Deux de ses suggestions sont déjà traitées :

Cinq contributions sont nouvelles ou significativement étendues :

15.2 Confiance graduée — du dry-run manuel à l'auto-exécution

C'est la contribution la plus pratique de Manus. GPT a posé le principe du dry-run obligatoire (Section 13.3). Manus ajoute le mécanisme de transition : après combien de succès consécutifs un dry-run devient-il une exécution automatique ?

Le modèle de confiance graduée :

Niveau 0 — Manuel        : Dry-run, rapport Telegram, humain répond "EXECUTE"
Niveau 1 — Supervisé     : 3 dry-runs consécutifs OK → auto-exécution, rapport post-action
Niveau 2 — Autonome      : 10 dry-runs OK sur 30 jours → exécution silencieuse (alerte seulement si échec)
Niveau 3 — Inconscient   : 30 jours sans alerte → plus de rapport, sauf anomalie

Classification des actions par potentiel de confiance :

Implémentation — compteur de confiance (fichier JSON) :

{
  "queue_cleanup": {
    "dry_runs_total": 12,
    "dry_runs_consecutive_ok": 8,
    "last_false_positive": null,
    "current_level": 1,
    "promoted_to_level_2_on": null
  },
  "indexer_retest": {
    "dry_runs_total": 5,
    "dry_runs_consecutive_ok": 5,
    "last_false_positive": null,
    "current_level": 2,
    "promoted_to_level_2_on": "2026-06-18"
  }
}

Règle de rétrogradation : un seul faux positif remet le compteur à 0 et rétrograde au Niveau 0. L'humain est alerté avec le détail de ce qui a mal tourné.

Pourquoi c'est malin : le système gagne en autonomie progressivement, en faisant ses preuves. L'humain n'a pas à « faire confiance » aveuglément — il n'a qu'à surveiller les premiers cycles, et le système s'auto-promotionne quand il est prêt.

Priorité : 🟠 Phase 2. À implémenter APRÈS que les scripts de base (Phase 1) aient tourné 2-3 semaines en dry-run.

15.3 Auto-discovery d'indexers — le système trouve ses propres fallbacks

Claude a identifié le mono-indexer FR (Section 12.3). Manus va plus loin : le système cherche activement des indexers alternatifs.

Workflow proposé :

Toutes les 24h (ou au déclenchement d'une alerte C411 down) :

1. Vérifier si un indexer critique (C411) est down > 6h
2. Si oui :
   a. Activer l'indexer de fallback déjà configuré (Section 12.3)
   b. Lancer une recherche web + API pour des indexers FR alternatifs :
      - Scraper des listes communautaires (Reddit r/trackers, forums FR)
      - Tester la connectivité de chaque candidat (HEAD request)
   c. Si un candidat répond → ajout temporaire dans Prowlarr via API
      avec score bas et tag "auto-fallback"
   d. Alerter l'humain : « C411 down depuis 6h. Fallback activé.
      Indexer temporaire ajouté : <nom>. À valider ou remplacer. »

Ce qui est réaliste vs ce qui ne l'est pas :

Recommandation pragmatique : la version « réaliste » de cette idée est : 1. Avoir 2-3 indexers FR pré-configurés dans Prowlarr (un principal actif + des fallbacks désactivés) 2. Le script détecte C411 down → active automatiquement le fallback #1 3. Le script alerte l'humain : « Fallback activé. Chercher un remplacement permanent pour C411 ? » 4. La partie « recherche automatique de nouveaux indexers » reste en Phase 4 (expérimental)

Priorité : 🟠 Phase 2 (activation automatique de fallback). 🟣 Phase 4 (auto-discovery).

15.4 Auto-remédiation des ratios — levier de seeding intelligent

Claude a proposé le monitoring read-only des ratios (Section 12.2). Manus propose un cran au-dessus : des actions correctives automatiques.

⚠️ MISE EN GARDE MAJEURE : toute action sur Transmission peut violer les règles des trackers privés. Un script qui modifie la priorité de seeding ou qui re-vérifie un torrent touche au client — c'est une ligne rouge dans notre architecture. Cette section est donc expérimentale et conditionnelle.

Ce qui est safe (lecture seule) — déjà dans Section 12.2 : - Détecter un ratio faible → ✅ OK, purement read-only - Alerter l'humain → ✅ OK

Ce qui est risqué (écriture) — NOUVEAU, à valider :

Recommandation : la SEULE action d'auto-remédiation acceptable en Phase 2 est l'ajustement de priorité de seeding. C'est réversible, non destructif, et ne touche ni aux fichiers ni au tracker.

# Exemple — augmenter la priorité des torrents à ratio < 0.5
ssh <REDACTED> 'transmission-remote --list' | \
  awk '/100%.*Done.*0\.[0-4]/ {print $1}' | \
  while read id; do
    ssh <REDACTED> "transmission-remote -t $id --priority high"
  done

Pour tout le reste (verify, re-download, remove) : alerter l'humain, ne pas agir.

Priorité : 🟡 Phase 3 (priorité de seeding auto). 🔴 Jamais (re-download/re-verify auto).

15.5 CI/CD pour les applications *Arr — mises à jour testées avant déploiement

C'est une contribution entièrement nouvelle. Aucun des cinq modèles précédents n'a mentionné l'automatisation des mises à jour des applications elles-mêmes.

Le problème : actuellement, les mises à jour de Sonarr/Radarr/Prowlarr/Bazarr sont manuelles. Une mise à jour cassée (bug, breaking change, API modifiée) peut casser toute la stack sans qu'on le sache avant le prochain health check.

Solution proposée — pipeline CI/CD léger :

Mensuel (ou au déclenchement d'une nouvelle release) :

1. STAGING — Conteneurs Docker jetables :
   docker-compose -f docker-compose.staging.yml up -d
   └── Sonarr:latest + Radarr:latest + Prowlarr:latest
   └── Volumes vides, configs restaurées depuis backup

2. TEST — Suite de régression automatisée :
   ├── Test 1 : API répond ? (GET /system/status sur chaque app)
   ├── Test 2 : Profils de qualité intacts ? (GET /qualityprofile → scores FR OK)
   ├── Test 3 : Indexers joignables ? (POST /indexer/test)
   ├── Test 4 : Backup restore fonctionnel ? (Section 13.2)
   └── Test 5 : Un lookup factice répond ? (GET /series/lookup?term=test)

3. DÉCISION :
   ├── Tous les tests OK → déploiement en production (docker compose pull + up -d)
   ├── 1+ test FAIL → rollback, alerte Telegram avec logs
   └── L'humain peut toujours overrider (--force)

4. NETTOYAGE : docker-compose -f docker-compose.staging.yml down -v

Coût : ~3 minutes de CPU par mois. Les conteneurs de staging sont détruits après le test. Aucun impact sur la production pendant le test.

Ce qui rend ça possible : les apps *Arr sont sur le seedbox Whatbox, PAS sur notre VPS. Mais le pipeline de test peut tourner sur le VPS Hostinger avec des conteneurs locaux qui pointent vers des volumes vides. On ne teste pas le seedbox — on teste la compatibilité des nouvelles versions avec notre configuration.

Limites : - Le pipeline ne peut pas tester les interactions réelles avec Transmission (le client de download) - Les tests de lookup factices ne garantissent pas que les vrais indexers fonctionneront - Si le seedbox utilise une version spécifique (pas :latest), le pipeline doit tester cette version exacte

Priorité : 🟡 Phase 2-3. Excellente hygiène opérationnelle. Faible coût, fort impact préventif.

15.6 Documentation auto-générée — la source de vérité qui se met à jour toute seule

Idée méta intéressante : certaines sections du document pourraient être générées automatiquement à partir de l'état réel du système.

Sections candidates à l'auto-génération :

Implémentation : 1. Un script generate_doc_sections.py interroge les APIs 2. Produit un fichier auto-generated-sections.md avec les données actuelles 3. Ce fichier est inclus (ou référencé) dans le document principal 4. Tourne en cronjob hebdomadaire (no_agent=true)

Ce que ça NE remplace PAS : l'analyse, la roadmap, l'historique, les décisions architecturales. L'auto-génération ne couvre que les données factuelles volatiles — les choses qui changent sans décision humaine.

Exemple de sortie auto-générée :

## 📊 État du système (auto-généré le 2026-06-13)

### Indexers Prowlarr
| Nom | Statut | Dernier succès |
|-----|--------|---------------|
| C411 2 | ✅ Enabled | 2026-06-13 14:22 |
| Nyaa.si | ✅ Enabled | 2026-06-13 14:18 |
| SubsPlease | ⚠️ Disabled | 2026-06-10 03:45 |

### Versions
| Application | Version | Uptime |
|------------|---------|--------|
| Sonarr | 4.0.17 | 12 jours |
| Radarr | 6.1.1 | 12 jours |
| Prowlarr | 2.3.5 | 12 jours |

Priorité : 🟢 Phase 3+. Bonus de qualité de vie, pas essentiel au fonctionnement.

15.7 Synthèse — contributions nettes de Manus

La phrase à retenir de Manus : « L'autonomie n'est pas un switch qu'on active — c'est une échelle qu'on gravit échelon par échelon, chaque action faisant ses preuves avant d'être promue. »

C'est le seul modèle qui a proposé un mécanisme concret de transition plutôt qu'un état cible binaire (manuel vs autonome). La confiance graduée (15.2) est probablement la contribution la plus immédiatement actionnable de cette sixième itération.

16. Discipline opérationnelle — audit, runbooks et hygiène documentaire [🤖 Perplexity]

Ajout juin 2026 — Perplexity a fait l'analyse la plus « méta » des sept contributeurs. Au lieu de proposer de nouveaux outils, il a identifié ce qui manque à la couche de discipline opérationnelle : la traçabilité des décisions, les procédures d'incident, et l'hygiène du document lui-même.

L'approche de Perplexity est complémentaire de toutes les autres : les sections 11-15 ont apporté des outils et mécanismes. Perplexity apporte le cadre de conduite qui garantit que ces outils seront utilisés de façon fiable dans la durée.

16.1 Ce que Perplexity confirme (déjà couvert)

Perplexity a fait 12 recommandations. 8 sont déjà traitées dans les sections précédentes :

4 contributions sont nouvelles ou significativement étendues :

16.2 Journal d'audit unifié — chaque décision automatique est tracée

C'est la contribution la plus importante de Perplexity, et elle est entièrement nouvelle. Aucun des six modèles précédents n'a mentionné l'audit logging.

Le problème : quand le système devient autonome (Phases 2-3), les décisions sont prises par des scripts et des agents. Sans journal d'audit, il est impossible de répondre à : « Pourquoi ce fichier a-t-il été supprimé ? », « Qui a changé le score de ce profil ? », « Cette recherche a-t-elle été déclenchée automatiquement ou manuellement ? »

Structure du journal d'audit proposé :

{
  "timestamp": "2026-06-15T14:22:31Z",
  "source": "queue_cleanup_v2.py",
  "trigger": "cron_hourly_supervisor",
  "decision": "delete_queue_entry",
  "target": {
    "app": "sonarr",
    "resource": "queue/4582",
    "description": "One Piece S03E12 — zombie (hasFile=true)"
  },
  "dry_run": false,
  "confidence_level": 2,
  "action_taken": "DELETE /api/v3/queue/4582?removeFromClient=false",
  "result": {
    "http_status": 200,
    "verified_after": true,
    "verification_method": "GET /queue → entry absent"
  },
  "human_override": null,
  "error": null
}

Implémentation — fichier JSON Lines (~100 Ko/mois) :

import json, time
from pathlib import Path

AUDIT_LOG = Path("/root/seedbox-logs/audit.jsonl")

def audit_log(source, decision, target, action_taken, result, dry_run=False):
    entry = {
        "timestamp": time.strftime("%Y-%m-%dT%H:%M:%SZ", time.gmtime()),
        "source": source,
        "decision": decision,
        "target": target,
        "action_taken": action_taken,
        "result": result,
        "dry_run": dry_run
    }
    with open(AUDIT_LOG, "a") as f:
        f.write(json.dumps(entry) + "\n")

Rotation : le fichier est rotaté mensuellement (garder 6 mois d'historique). Compression gzip sur les archives.

Consultation : un script audit_query.py permet de filtrer par date, source, type de décision, ou ressource cible. Exemple : audit_query.py --last 7d --decision delete → toutes les suppressions de la semaine.

Pourquoi c'est critique : sans ça, un système autonome est une boîte noire. Avec ça, chaque action est explicable, contestable, et annulable.

Priorité : 🟠 Phase 1 (à mettre en place AVANT les premiers scripts autonomes). Le journal d'audit est un prérequis à toute exécution automatique de niveau 1 ou plus.

16.3 Runbooks incident par composant — symptômes → causes → vérifications → actions

Deuxième contribution nouvelle de Perplexity. Le document actuel décrit l'architecture et les procédures de maintenance, mais pas ce qu'il faut faire quand quelque chose casse.

Format standard d'un runbook :

COMPOSANT : <nom>
─────────────────────────────────────────────

SYMPTÔME : <ce que l'utilisateur ou le health check voit>

CAUSES PROBABLES :
  1. <cause la plus fréquente>
  2. <cause secondaire>
  3. <cause rare>

VÉRIFICATIONS (dans l'ordre) :
  1. <commande ou appel API> → <résultat attendu>
  2. <commande ou appel API> → <résultat attendu>

ACTION (si vérification confirme la cause) :
  • <action safe, read-only si possible>
  • <action corrective si approuvée>

ESCALADE (si l'action échoue) :
  → Alerter l'humain avec : <informations à inclure>

Runbooks prioritaires à créer :

Exemple — runbook Prowlarr « proxies unavailable » :

COMPOSANT : Prowlarr — indexer proxies
─────────────────────────────────────────────

SYMPTÔME : Health check affiche « All indexer proxies are unavailable »
          ou POST /indexer/test échoue avec timeout/403

CAUSES PROBABLES :
  1. FlareSolverr est down (95% des cas)
  2. FlareSolverr est up mais Cloudflare a changé son challenge
  3. L'indexer lui-même est down

VÉRIFICATIONS :
  1. curl -s http://flaresolverr:8191/v1 → doit retourner JSON
  2. docker logs flaresolverr --tail 20 → chercher "CloudflareChallengeError"
  3. curl -I https://c411.org → chercher cf-ray dans les headers
  4. POST /api/v1/indexer/test {id: 71} → vérifier le message d'erreur

ACTION :
  • Si FlareSolverr down → docker restart flaresolverr (safe)
  • Si FlareSolverr up mais erreur → redéployer fork 21hsmw (Section 12.1)
  • Si indexer vraiment down → activer fallback (Section 12.3)

ESCALADE :
  → Alerter avec : logs FlareSolverr (20 lignes), réponse curl C411,
    dernier test Prowlarr, statut des autres indexers

Stockage : un fichier runbooks.md séparé, ou une section dans ce document. L'agent Hermes peut charger le runbook pertinent quand un problème est détecté.

Priorité : 🟠 Phase 1 (runbooks Prowlarr + C411 + queue). 🟡 Phase 2 (reste).

16.4 Améliorations structurelles du document lui-même

Perplexity a fait trois suggestions qui concernent la forme du document, pas son contenu technique. Elles sont légitimes et faciles à implémenter.

16.4.1 Colonne « niveau de risque » dans les tableaux de recommandations

État actuel : les priorités sont exprimées en texte (🔴 Critique, 🟠 Important, 🟡 Standard, 🟢 Bonus) mais de façon non standardisée.

Standardisation proposée :

Application : toutes les recommandations des sections 11-16 utilisent déjà ce code couleur de façon cohérente. La formalisation dans cette section 16.4.1 suffit à standardiser.

16.4.2 Séparation « profils » vs « bibliothèque » vs « rétention »

Le constat de Perplexity : les recommandations touchent à trois couches différentes du système, et les mélanger peut créer de la confusion.

Classification proposée pour toutes les recommandations futures (et rétroactive) :

Application au document : chaque recommandation des sections 11-15 est déjà implicitement dans une de ces couches. Pour les ajouts futurs, le tag de couche sera ajouté dans le titre de la sous-section.

16.4.3 Documentation des prérequis techniques

Le constat : certaines recommandations (Tdarr, autobrr, Recyclarr) mentionnent des prérequis mais de façon dispersée.

Standardisation : chaque recommandation future inclut un bloc standardisé :

📋 PRÉREQUIS
├── CPU : <estimation>
├── RAM : <estimation>
├── Dépendances : <packages système, Python, Docker>
├── Accès requis : <APIs, SSH, fichiers>
├── Token cost (si LLM) : <estimation/mois>
└── Incompatible avec : <si conflit avec un autre outil>

Priorité : 🟢 Phase 3+ (amélioration documentaire, pas opérationnelle).

16.5 Le processus de suggestion — version 2

Perplexity, en tant que moteur de recherche, a une perspective unique : il voit le document comme une base de connaissances qui doit être interrogeable et vérifiable.

Amélioration suggérée du processus de contribution :

POUR CHAQUE SUGGESTION FUTURE :

1. RECHERCHE CONTEXTUELLE — Perplexity (ou autre moteur) vérifie :
   a. L'outil existe-t-il encore ? (dernière release, GitHub actif)
   b. Des alternatives plus récentes sont-elles apparues ?
   c. La suggestion contredit-elle une section existante ?

2. FILTRAGE HERMES — L'agent Hermes valide :
   a. Les chemins, versions, URLs sont-ils réels ? (Section 1-10 = socle)
   b. La suggestion est-elle redondante avec une section existante ?
   c. La suggestion est-elle réalisable dans notre contrainte technique ?

3. INTÉGRATION — Si les deux filtres passent :
   a. Ajout tagué [🤖 Source]
   b. Classification par couche (profils/bibliothèque/rétention/infra)
   c. Niveau de risque standardisé (🔴🟠🟡🟢)
   d. Prérequis techniques documentés
   e. Table des contributeurs mise à jour

Ce que ça change en pratique : pour la prochaine itération, on peut demander à Perplexity de vérifier les suggestions avant intégration — ça ajoute une couche de validation externe sans dépendre d'un seul modèle.

16.6 Synthèse — contributions nettes de Perplexity

La phrase à retenir de Perplexity : « Le document est très bon comme base de documentation d'exploitation, mais il gagnerait à inclure un mini runbook incident par composant : symptômes, causes probables, vérifications, et actions autorisées. »

C'est le seul contributeur qui a évalué la qualité documentaire plutôt que de proposer de nouveaux outils. Son apport est moins spectaculaire que autobrr ou la confiance graduée, mais c'est ce qui fera la différence entre « un système qui marche quand tout va bien » et « un système pour lequel on sait quoi faire quand tout va mal ».

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), 15 (🤖 Manus), 16 (🤖 Perplexity)