SuggestArr : automatiser les demandes de médias à partir de l'historique de visionnage
Effortlessly request recommended movies, TV shows and anime to Jellyseer/Overseer based on your recently watched content on Jellyfin, Plex or Emby—let SuggestArr handle it all automatically, keeping your library fresh with new and exciting content!
En bref
- De quoi s’agit-il ?
- SuggestArr relie Jellyfin, Plex ou Emby à Seer pour proposer et demander automatiquement des titres similaires via TMDb, avec une couche LLM optionnelle. Le point sensible n'est pas la fonction, c'est le workflow d'approbation et le nettoyage des demandes non suivies.
- À qui s’adresse-t-il ?
- SuggestArr convient aux administrateurs qui veulent alimenter un Seer à partir de l'historique réel de leurs utilisateurs et qui acceptent de passer par la page Requests pour valider les suggestions. Il ne convient pas à qui veut un système entièrement silencieux sans revue, ni à qui refuse d'exposer une clé TMDb et éventuellement un point d'accès LLM.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : un Seer qui ne sait pas quoi demander
Un serveur Jellyseerr ou Overseerr est une file d'attente. Il traite bien les demandes qu'on lui soumet, mais il ne décide pas à votre place ce qui mérite d'entrer dans la bibliothèque. L'administrateur finit par parcourir TMDb à la main, ou par laisser la bibliothèque se figer autour des mêmes séries. SuggestArr s'attaque précisément à ce vide : le projet récupère le contenu récemment regardé sur Jellyfin, Plex ou Emby, cherche des titres similaires via l'API TMDb, puis envoie les demandes de téléchargement à Seer. Le public visé est donc l'administrateur auto-hébergé qui fait déjà tourner les trois briques (serveur média, Seer, TMDb) et qui veut que le catalogue se renouvelle sans intervention quotidienne. Le README précise que la fonction IA est en beta, ce qui situe le reste du projet comme la partie stable.
Le flux réel : historique, TMDb, Seer, puis revue humaine
Le mécanisme tient en quatre étapes documentées. D'abord la collecte : SuggestArr interroge le serveur média configuré pour obtenir les contenus récemment vus. Ensuite la recherche : ces titres servent de graines pour TMDb, qui renvoie des similaires. Puis la demande : les titres retenus sont envoyés à Seer. Enfin la revue, et c'est la partie que le README met en avant. Les nouvelles tâches suivent le réglage global Approuver les demandes avant envoi à Seer, désactivé par défaut dans Advanced. Chaque tâche peut hériter de ce réglage ou le surcharger, soit pour toujours approuver, soit pour toujours envoyer automatiquement. Les résultats retenus apparaissent sur la page Requests, où le propriétaire de la tâche ou un administrateur peut les envoyer à Seer, les rejeter, ou les blacklister globalement. Le même bloc de réglages peut mettre une tâche en pause tant que ses suggestions attendent une revue, et rejeter automatiquement les suggestions restées en attente au-delà d'un nombre de jours configurable. Cette pause est surchargeable par tâche. Autrement dit, l'automatisation complète existe, mais l'architecture place la validation humaine au centre par défaut.
Trakt : des graines par utilisateur, pas par administrateur
Le volet Trakt mérite qu'on s'y arrête, parce qu'il déplace la logique du serveur vers l'individu. Chaque utilisateur SuggestArr lie son propre compte Trakt depuis son profil, tandis que l'administrateur ne configure que les identifiants partagés de l'application. Les récents visionnages Trakt peuvent servir de graines de recommandation, et les éléments entièrement vus sur Trakt rejoignent l'ensemble des contenus à ignorer. Un panneau repliable Recent Trakt Preview affiche les derniers éléments récupérés depuis Trakt. La mise en route demande une application OAuth créée sur trakt.tv, puis la saisie du Client ID et du Client Secret dans Services -> Trakt, avant que chaque utilisateur ne clique sur Link Trakt dans Profile -> Trakt Account. Trakt reste optionnel : l'historique du serveur média fonctionne sans lui. L'intérêt est réel pour les foyers où plusieurs personnes partagent une même bibliothèque mais pas les mêmes habitudes.
Installation : Docker Compose, un volume, deux variables
Le README donne un exemple Docker Compose complet. L'image est ciuse99/suggestarr:latest, également publiée sur GitHub Container Registry sous ghcr.io/giuseppe99barchetta/suggestarr:latest. Le conteneur s'appelle SuggestArr, redémarre toujours, et expose le port via ${SUGGESTARR_PORT:-5000}. Un seul volume est monté : ./config_files vers /app/config/config_files. Deux variables d'environnement sont documentées : LOG_LEVEL, décrit comme optionnel et utile seulement pour inspecter en profondeur, et SUGGESTARR_PORT, qui vaut 5000 par défaut. Le lancement se fait avec docker-compose up. L'interface web répond ensuite sur http://localhost:5000, ou sur le port personnalisé. C'est là que se font la configuration, le choix du service média, la gestion des tâches cron et le pré-test de configuration, que le README décrit comme une validation automatique des clés API et des URL pendant l'installation. Les prérequis listés sont Python 3.x ou Docker, une clé API TMDb, un serveur Jellyfin, Plex ou Emby configuré, un Seer configuré, et en option une base externe PostgreSQL ou MySQL.
Les limites que le README admet lui-même
Deux points sont explicitement documentés comme restrictifs. Le premier concerne l'identité des demandes : la note indique que seuls les utilisateurs Seer locaux sont pris en charge pour choisir un utilisateur spécifique lors de l'envoi. Si votre Seer s'appuie sur de l'authentification déléguée, cette fonction ne s'appliquera pas. Le second concerne le statut de l'IA : les recommandations par LLM et la recherche en langage naturel sont marquées beta, donc à traiter comme telles. Il faut ajouter un coût de fonctionnement non chiffré dans le matériel fourni : l'appel à TMDb est incontournable, et l'usage d'un LLM compatible OpenAI (OpenAI, Ollama, Gemini, LiteLLM) ajoute soit une dépendance réseau, soit une charge locale si vous hébergez le modèle. Le projet n'est pas non plus un outil de découverte passive : il écrit dans Seer. Une mauvaise configuration des filtres produit des demandes réelles, pas des suggestions théoriques. Les fonctions de nettoyage existent justement parce que ce risque est reconnu : le README mentionne l'élagage optionnel des demandes et fichiers issus de SuggestArr lorsque les utilisateurs ne les mettent jamais en favori dans Plex, Jellyfin ou Emby. C'est un filet de sécurité, pas une garantie.
Face à un script maison ou à un simple cron TMDb
L'alternative évidente pour un administrateur à l'aise en Python est un script personnel : interroger l'API du serveur média, appeler TMDb, puis poster sur l'API de Seer. La différence n'est pas dans la faisabilité, elle est dans ce que SuggestArr ajoute autour. Un script maison n'a pas de page Requests avec envoi, rejet et blacklist globale. Il n'a pas de pause par tâche conditionnée à des demandes Seer en attente d'approbation, ni de pause quand un utilisateur n'a pas regardé une demande SuggestArr depuis un nombre de jours configurable. Il n'a pas non plus de visibilité par utilisateur, ni de limitation des utilisateurs ordinaires aux demandes liées à leur propre compte Plex, Jellyfin ou Emby. Ces éléments sont des réglages de gouvernance, pas des fonctions de recommandation. À l'inverse, un script maison reste plus simple à auditer et ne dépend que de vous. Le choix se joue donc sur le nombre d'utilisateurs à gérer et sur votre tolérance à laisser un outil écrire dans Seer.
Maintenance, licence et coût de mise à jour
Le dépôt est actif : trois versions publiées entre début août et début septembre 2026, la dernière étant v2.14.0, et le dernier push sur main date du 8 septembre 2026. Le rythme est soutenu, ce qui implique des mises à jour fréquentes de l'image Docker. Le volume ./config_files:/app/config/config_files est le point à sauvegarder avant toute montée de version, puisque c'est là que réside la configuration. Le projet est sous licence MIT, ce qui autorise l'usage, la modification et la redistribution avec conservation de l'avis de licence ; ce n'est pas un avis juridique, et les dépendances tierces (TMDb, Seer, Trakt, fournisseur LLM) ont leurs propres conditions d'utilisation à vérifier séparément. Le README propose un lien de don Buy Me a Coffee et un serveur Discord, ce qui indique un modèle de maintenance porté par l'auteur plutôt qu'une structure. La prise en charge de bases externes PostgreSQL et MySQL est présentée comme une option pour la scalabilité, ce qui suggère que SQLite reste le chemin par défaut, sans que le matériel fourni ne détaille de seuil de bascule.
Conclusion éditoriale
SuggestArr convient aux administrateurs qui veulent alimenter un Seer à partir de l'historique réel de leurs utilisateurs et qui acceptent de passer par la page Requests pour valider les suggestions. Il ne convient pas à qui veut un système entièrement silencieux sans revue, ni à qui refuse d'exposer une clé TMDb et éventuellement un point d'accès LLM. Avant de l'adopter, vérifiez le comportement de Approuver les demandes avant envoi à Seer dans Advanced, la valeur du délai de rejet automatique des suggestions en attente, et le fait que seuls les utilisateurs Seer locaux sont pris en charge pour l'envoi des demandes.
Notes de la communauté