Le fork Pinchflat-ngx reprend le gestionnaire YouTube que son mainteneur a délaissé
Pinchflat, le gestionnaire de téléchargement YouTube auto-hébergé, n’a plus connu d’activité depuis environ dix mois ; un fork, Pinchflat-ngx, reprend le projet avec 808 commits et y ajoute PostgreSQL, l’OIDC et un staging disque pensé pour les NAS. Si vous archivez déjà des chaînes, la bascule vers l’image latest est peu risquée, mais la migration vers PostgreSQL reste un chemin de réinstallation.
Vendredi 2 octobre 2026. La lettre selfh.st relève qu’un fork « sauvage » est apparu autour de Pinchflat, le gestionnaire de médias YouTube auto-hébergé : Pinchflat-ngx, porté par un développeur sous le pseudo TheBadFella, affiche 808 commits et 139 étoiles. Dix mois de silence. Le projet d’origine, kieraneglin/pinchflat, n’a plus connu d’activité depuis environ dix mois. Un plan de continuité. Le fork n’est pas une copie : il ajoute PostgreSQL 18, l’authentification OIDC, un staging disque pour les NAS et un fournisseur de PO-token contre les blocages YouTube.
Ce qui s’est passé : un projet dormant, un fork en 808 commits
Pinchflat est un gestionnaire de téléchargement YouTube construit en Elixir/Phoenix LiveView, qui s’appuie sur yt-dlp pour récupérer chaînes, playlists et podcasts et les classer dans une médiathèque, avec SponsorBlock et des profils de rétention. C’est l’une des applications de référence pour archiver ses abonnements YouTube sur son propre serveur — une tâche qui exige un suivi constant, car YouTube fait évoluer régulièrement ses protections anti-automatisation.
Quand un mainteneur unique s’arrête, ce suivi s’arrête avec lui. selfh.st indique que le dépôt d’origine n’a plus bougé depuis environ dix mois ; pour une application dont la survie dépend de la mise à jour continue de yt-dlp et des contournements associés, dix mois est une éternité. Le fork Pinchflat-ngx est la réponse classique du self-hosted à ce vide : reprendre le code, continuer à le maintenir, et profiter de l’occasion pour moderniser ce que l’original laissait en plan.
Ce que le fork change réellement
La comparaison livrée par le README du fork tient en cinq différences, toutes orientées vers l’usage réel en homelab.
- PostgreSQL 18 en option. L’image
latestconserve SQLite ; une imagelatest-postgresajoute PostgreSQL 18 pour ceux qui veulent une base partagée et des sauvegardespg_dumpintégrées. - OIDC / SSO. En plus de l’HTTP Basic Auth, le fork prend en charge OAuth2/OpenID Connect — Authentik, Authelia et assimilés — avec découverte du fournisseur, PKCE et validation de
stateetnonce. - Staging disque local. La variable
DOWNLOAD_STAGING_PATHfait atterrir les téléchargements sur un disque rapide local avant un transfert atomique vers la bibliothèque, ce qui évite les écritures directes sur un partage NFS ou un NAS lent. - Fournisseur de PO-token. Une intégration du service
bgutil-ytdlp-pot-providercontourne les blocages SABR de YouTube quand l’instance rencontre des erreurs d’authentification. - Téléchargement de vidéos uniques. Là où l’original ne traitait que chaînes et playlists, le fork accepte l’URL d’une vidéo isolée.
S’y ajoutent des éléments de confort : gestion des cookies depuis l’interface, contrôle de la version de yt-dlp (stable, nightly, épinglée), diagnostics de file d’attente, réglage séparé des workers de téléchargement, d’indexation et de métadonnées, et une interface Material 3 en mode sombre AMOLED.
La migration : ce qui est compatible, ce qui ne l’est pas
Le point décisif pour un utilisateur existant de Pinchflat est la compatibilité de la base. L’image latest du fork reste sur SQLite : elle reprend le format de l’original, ce qui fait de la bascule une opération peu risquée — on change l’image du conteneur, on conserve les volumes config et downloads, et l’application repart.
Le chemin PostgreSQL est une autre histoire. Le README est explicite : l’image latest-postgres « crée et migre son propre schéma, mais ne copie pas les données d’une base SQLite existante ». Autrement dit, passer en PostgreSQL n’est pas une mise à niveau, c’est une réinstallation — nouvelle base, réindexation des sources, nouvelle configuration des profils. Le fork documente des sauvegardes pg_dump avec rétention une fois en place, mais la bascule initiale se fait à la main, et un volume PostgreSQL en version 16 ou antérieure n’est pas compatible tel quel avec le serveur 18.
services:
pinchflat-ngx:
image: ghcr.io/thebadfella/pinchflat-ngx:latest
environment:
TZ: Europe/Paris
ports:
- '8945:8945'
volumes:
- ./config:/config
- ./downloads:/downloads
restart: unless-stoppedC’est le déploiement de départ pour un utilisateur qui vient de Pinchflat : même port 8945, mêmes volumes, image remplacée. Pour une OIDC avec Authentik ou Authelia, le fork précise que l’OIDC remplace l’HTTP Basic Auth sur les routes du navigateur, tandis que les flux de podcast conservent l’Basic Auth et les jetons de route pour ne pas casser les clients existants.
Le fond du problème : le fork comme plan de continuité
L’histoire de Pinchflat-ngx dépasse le cas d’un outil YouTube. Elle illustre le risque structurel du self-hosted à mainteneur unique : la valeur d’une application n’est pas seulement dans son code, mais dans le suivi continu qu’elle exige — ici, la course contre les protections YouTube. Quand ce suivi s’arrête, l’application ne « casse » pas d’un coup, elle se dégrade silencieusement, jusqu’au jour où yt-dlp ne suffit plus à contourner un nouveau mécanisme.
Le fork est alors moins une rébellion qu’un mécanisme de survie du modèle : quelqu’un reprend la charge de maintenance et, au passage, corrige les angles morts que l’original traînait — absence de SSO, base mono-fichier, écritures directes sur le NAS. La question que doit se poser un auto-hébergeur n’est donc pas « faut-il passer au fork ? », mais « à quel point dépends-je d’un mainteneur unique, et qu’est-ce que je fais s’il disparaît ? ».
Verdict
Si vous faites déjà tourner Pinchflat et qu’il fonctionne, basculez sur l’image latest de Pinchflat-ngx : même base SQLite, même port, même volumes, et vous récupérez un projet activement maintenu sans réinstallation. Si vous voulez le PostgreSQL, l’OIDC ou le staging disque, traitez la migration vers latest-postgres comme un nouveau déploiement — nouvelle base, réindexation — et prévoyez le temps de reconfigurer profils et sources, plutôt que d’espérer une bascule transparente. Si vous hésitez encore sur le principe, gardez en tête que le vrai coût d’un fork n’est pas technique mais de confiance : vérifiez l’activité du dépôt, l’historique des commits et l’existence d’un chemin de retour vers l’original avant de confier vos archives à un projet porté par une personne. Pour un outil dont la matière première est votre bibliothèque YouTube, la continuité de maintenance vaut plus que la nouveauté des fonctionnalités.