Jellyfin perd trois piliers en une semaine et renumérote ses versions
En l’espace d’une semaine, Jellyfin a vu partir trois de ses mainteneurs les plus expérimentés, dont son chef de projet historique Joshua Boniface, parti pour cause de burn-out. Dans la foulée, le projet annonce renuméroter ses versions et sauter directement à la 12.0 — voici ce que cela change pour votre serveur.
Août 2026. La médiathèque auto-hébergée la plus installée du monde traverse une secousse de gouvernance. En l’espace de quelques jours, Jellyfin a vu partir trois de ses figures historiques : le chef de projet Joshua Boniface, le cofondateur Andrew Rabert et le pilier administratif Anthony Lavado. Dans la foulée, le projet tranche une vieille question de versioning et annonce que la prochaine version majeure sautera directement à la 12.0.
Le code, lui, n’est pas en danger : votre serveur continuera de transcoder lundi. Mais l’épisode dit quelque chose de plus profond sur le modèle de maintenance du self-hosted, et il vaut la peine qu’on le regarde sans alarmisme ni naïveté.
Trois départs, trois raisons différentes
Le 17 juillet 2026, Andrew Rabert, l’un des tout premiers contributeurs, démissionne. Il développait un nouveau client de bureau destiné à corriger les limites du Jellyfin Media Player — le support HDR, la maintenance. Les désaccords portent sur l’approche de développement, notamment l’opposition à son usage d’outils assistés par IA. Son application quitte le giron officiel et devient Jellium Desktop.
Deux jours plus tard, le 19 juillet, Joshua Boniface annonce quitter son poste de chef de projet, qu’il occupait depuis la création du projet en 2018 — un fork entièrement ouvert d’Emby. Le motif tient en un mot : burn-out. « Je ne pouvais plus fournir l’effort, mental ou temporel, que le rôle exigeait, et je n’accomplissais donc plus mes fonctions à un niveau acceptable », écrit-il. Il évoque des risques pour sa santé mentale.
Le même jour, Anthony Lavado, pilier des opérations — stores d’applications, communication, releases, finances —, annonce son départ pour des raisons personnelles, en s’engageant à accompagner la transition aussi longtemps qu’il le faudra, « même si cela prend un an ».
Ce qui a précédé : un signal déjà visible en mai
Ces départs ne sortent pas de nulle part. Le billet « State of the Fin » publié par l’équipe en mai 2026 signalait déjà le burn-out comme un problème croissant, et pointait une cause précise : le flot de pull requests générées par IA qui alourdissait la charge de relecture sans apporter grand-chose.
C’est là le nœud du problème. Jellyfin compte des millions d’utilisateurs, mais sa maintenance repose sur une poignée de bénévoles. Quand un outil devient aussi central que la médiathèque familiale, on oublie qu’il n’y a ni contrat, ni SLA, ni équipe de support payée derrière — seulement des personnes qui peuvent, un jour, ne plus avoir l’énergie.
Un fork devenu la référence
Pour mesurer ce que trois départs représentent, il faut rappeler la trajectoire. Jellyfin est né fin 2018 d’un fork d’Emby, lorsque ce dernier a commencé à fermer son code et à basculer vers un modèle payant. Boniface disait s’attendre, au départ, à quelques centaines d’utilisateurs. Sept ans et demi plus tard, le logiciel est utilisé par des millions de personnes.
C’est exactement ce décalage qui rend l’épisode actuel délicat : la base d’utilisateurs a crû bien plus vite que la base de mainteneurs. Un fork communautaire qui gagne des millions d’utilisateurs sans gagner proportionnellement de contributeurs finit inévitablement par concentrer le savoir et la charge sur une poignée de personnes. Trois d’entre elles viennent de lâcher prise — le problème n’est pas leur départ, c’est la structure qui les rendait irremplaçables.
La renumérotation : le 10. disparaît, place au 12.0
Au milieu de la secousse, le projet règle une question de versioning qui traînait depuis des années. 10.11.x sera la dernière branche de l’ancien schéma. La prochaine version majeure saute directement à 12.0, sans passer par la 11, et les release candidates sont déjà sorties.
La logique est saine : le préfixe permanent 10. réservait de l’espace pour une rupture d’API majeure qui n’arrive jamais, et les utilisateurs se trompaient constamment sur ce qui comptait comme « version majeure ». Désormais, le premier chiffre signifie changements significatifs, le second correctifs de bugs et de sécurité. Un numéro de version qui ne change jamais est une documentation qui ment — c’est corrigé.
L’avertissement pratique vise quiconque automatise : toute règle épinglée sur 10.* cessera de correspondre une fois la 12.0 sortie. Vérifiez vos règles Watchtower et vos tags Compose maintenant, pas pendant la mise à niveau.
Ce que cela change pour votre serveur
Concrètement, presque rien dans l’immédiat. Jellyfin continue de tourner, les dépôts ne sont pas abandonnés, et un groupe large de contributeurs — dont beaucoup ont des années d’expérience — maintient le projet. Les deux partants accompagnent le transfert de leurs responsabilités.
Mais le risque réel n’est pas le code : c’est la connaissance institutionnelle. Trois personnes qui détenaient une part importante de la mémoire du projet viennent de partir. La succession — qui reprend le rôle de Boniface, tenu pendant sept ans et demi — dira plus sur les deux prochaines années du projet que n’importe quelle note de version.
La parade ne consiste pas à fuir vers Plex. Elle tient en deux réflexes : garder vos métadonnées de bibliothèque portables et votre configuration sous contrôle de version, pour que vos données ne soient jamais otages du projet, quelle que soit sa forme dans deux ans.
La checklist pratique
Concrètement, pour un serveur Jellyfin que vous gérez, quatre réflexes suffisent à neutraliser l’essentiel du risque :
- Gardez vos métadonnées portables — activez l’écriture des fichiers .nfo à côté de vos médias, plutôt que de tout confier à la base interne ;
- Versionnez la configuration — le
docker-compose.ymlou les unités systemd dans un dépôt Git, pour reconstruire le serveur à l’identique ; - Épinglez une majeure —
jellyfin/jellyfin:10.11aujourd’hui, à reconsidérer pour12à la sortie stable ; - Gardez Watchtower prudent — jamais
:latestsans avoir lu les notes de version.
Aucune de ces actions ne protège de la gouvernance du projet, mais elles garantissent une chose : votre donnée ne sera jamais otage de la forme que prendra Jellyfin dans deux ans.
Verdict
L’épisode Jellyfin est le cas visible d’une tendance plus large, pas une exception. Le flot de PR générées par IA est devenu une charge opérationnelle réelle pour les projets bénévoles, et il se manifeste par du burn-out chez ceux qui les relisent.
Si vous utilisez Jellyfin, ne paniquez pas : votre serveur continue de fonctionner, et le projet n’est pas mort. Mais ne traitez pas cette dépendance comme un abonnement commercial.
Vérifiez vos épinglages de version dès maintenant : toute automatisation calée sur 10.* doit être repensée avant la 12.0, et Watchtower pointé sur :latest reste une mauvaise idée sur une application qui assume des changements de schéma à chaque majeure.
Et si Jellyfin compte vraiment pour vous, la réponse utile n’est pas l’anxiété : c’est de contribuer — du temps ou de l’argent — aux projets dont vous dépendez. Le self-hosted ne survit pas par la magie des millions d’utilisateurs ; il survit par les quelques personnes qui revoient les pull requests le soir. Trois d’entre elles viennent de rendre les armes.