Cette semaine : Jellyfin traverse une séquence de gouvernance compliquée, Codeberg formalise une position très stricte sur les projets générés par LLM, Samsung prépare la monétisation de l’API SmartThings, et plusieurs outils self-hosted ont des mises à jour à ne pas laisser dormir.
Le fil conducteur est assez clair : les services qu’on auto-héberge ne vivent pas seulement par leur code. Ils dépendent aussi de mainteneurs disponibles, de règles de contribution lisibles, de modèles économiques acceptables et de mises à jour appliquées à temps.
Jellyfin : départs dans la gouvernance et client desktop renommé#
Jellyfin a annoncé des changements de leadership : le project leader Joshua Boniface et Anthony Lavado quittent l’organisation, après le départ d’Andrew Rabert quelques jours plus tôt.
Le point visible côté utilisateur, c’est aussi le renommage du client desktop que Rabert développait. Le projet n’est plus un projet officiel de l’organisation Jellyfin et doit donc changer de nom et de branding.
Il faut éviter de transformer ça en feuilleton. Les projets open source ont des désaccords internes, de la fatigue, des mainteneurs qui partent et des responsabilités qui changent. Ce n’est pas automatiquement un signal de mort du projet.
Mais pour Jellyfin, ce n’est pas anodin non plus.
Jellyfin dépend beaucoup de son écosystème client :
- TV ;
- mobile ;
- desktop ;
- navigateur ;
- intégrations tierces ;
- compatibilité avec des bibliothèques médias très différentes.
Quand une partie de l’effort client sort du périmètre officiel, le risque n’est pas seulement technique. Il touche aussi la documentation, le support, les attentes des utilisateurs et la manière dont les bugs sont priorisés.
Si Jellyfin est central dans votre maison ou chez des proches, je vérifierais surtout :
- quels clients sont réellement utilisés ;
- si le client desktop officiel répond encore à vos besoins ;
- si une alternative non officielle devient nécessaire ;
- si vos utilisateurs savent quoi faire en cas de changement d’application ;
- si votre serveur est simple à restaurer.
Commandes de vérification basiques côté serveur :
docker compose ps jellyfin
docker compose logs --tail=100 jellyfinLe risque immédiat pour une instance existante reste limité. Le risque à surveiller est plus lent : fragmentation client, fatigue mainteneur, perte de clarté sur les projets officiellement supportés.
Jellyfin - Project Leadership Changes
Jellium Desktop - Rename the app
Codeberg et LLM : une forge libre peut aussi fixer ses limites#
Codeberg a publié une position très ferme sur les LLM. Deux motions ont été votées par les membres de l’association :
- ne pas utiliser les données des utilisateurs et projets pour entraîner des LLM ;
- faire évoluer les conditions d’utilisation pour limiter les projets dits “vibe-coded”.
Le point opérationnel est plus intéressant que le débat culturel.
Codeberg explique que certains usages LLM consomment beaucoup de ressources : crawlers agressifs, CI/CD lourde, artefacts volumineux, projets générés vite mais peu maintenus. Pour une forge associative, financée autrement qu’une grande plateforme commerciale, ce coût devient vite concret.
La position de Codeberg est dure, mais elle pose une question saine : une infrastructure communautaire a-t-elle vocation à héberger beaucoup de code généré, peu relu, peu maintenu, avec une empreinte disproportionnée ?
Pour un mainteneur, la leçon est pratique.
Il faut documenter ce qui est accepté :
- contributions générées ou assistées par IA ;
- niveau de relecture humaine attendu ;
- tests obligatoires ;
- responsabilité du contributeur ;
- usage autorisé des ressources CI ;
- règles de disclosure quand un patch est largement produit par un outil.
Un fichier de politique projet n’a pas besoin d’être idéologique. Il doit surtout éviter les ambiguïtés au moment où une contribution arrive et où personne ne sait si elle a été comprise par la personne qui l’envoie.
Codeberg - Protecting our FLOSS commons from LLMs
SmartThings : l’API gratuite touche à sa fin#
Samsung annonce une évolution du modèle SmartThings API : des offres commerciales payantes arrivent, ainsi qu’un plan individuel non commercial à 4,99 dollars par mois.
La bascule n’est pas immédiate. L’accès gratuit reste annoncé jusqu’à la fin du troisième trimestre 2026, avec application des nouvelles limites à partir d’octobre 2026.
Pour un utilisateur Home Assistant ou homelab, c’est le genre de changement qui mérite une ligne dans le backlog avant de casser silencieusement une automatisation.
À vérifier maintenant :
- quelles automatisations dépendent de SmartThings Cloud ;
- quels appareils peuvent fonctionner en local via Matter, Zigbee ou Z-Wave ;
- quels scripts utilisent directement l’API SmartThings ;
- quel compte développeur est utilisé ;
- quel volume d’appels API est réellement nécessaire.
Ce n’est pas forcément une raison de jeter tout l’écosystème SmartThings. Mais c’est un rappel classique : dès qu’une maison connectée dépend d’une API cloud, le modèle économique du fournisseur devient une dépendance technique.
Si votre pile Home Assistant repose sur cette intégration, l’objectif réaliste est de réduire la dépendance au cloud quand c’est possible, pas de tout migrer dans la panique.
SmartThings - A New Enhanced SmartThings API Experience
Vikunja 2.4.0 : dix correctifs sécurité et premières fonctions Pro#
Vikunja 2.4.0 est une grosse release : plus de mille commits depuis la 2.3.0, une nouvelle API v2, les premières fonctions Pro, et surtout dix correctifs de sécurité.
Les failles corrigées touchent principalement :
- les contrôles d’accès autour des tableaux kanban ;
- la hiérarchie de projets ;
- les liens de partage ;
- les tokens API ;
- certains scénarios OIDC ;
- les tokens de reset stockés en clair.
Le risque dépend beaucoup de votre usage.
Une instance personnelle non exposée, avec un seul utilisateur, n’a pas le même profil qu’une instance d’équipe ouverte sur Internet avec OIDC, partage de projets et liens publics. Mais dès qu’il y a plusieurs comptes ou des partages, cette mise à jour mérite une vraie fenêtre.
Avant upgrade :
docker compose ps vikunja
docker compose logs --tail=100 vikunjaPuis sauvegarde de la base et du volume applicatif réellement utilisé. Après mise à jour, vérifiez au minimum :
- login local ;
- login OIDC si activé ;
- accès aux projets partagés ;
- tableaux kanban ;
- tokens API ;
- intégrations qui consomment l’API.
Vikunja introduit aussi ses premières fonctions Pro pour les instances self-hosted. Le projet précise qu’aucune fonction existante de la version libre n’est déplacée derrière une licence dans cette release. C’est le bon moment pour surveiller calmement l’évolution du modèle, sans procès d’intention et sans naïveté.
vaultwarden 1.37.0 : mise à jour à planifier rapidement#
vaultwarden 1.37.0 est une release à traiter sérieusement si vous l’utilisez comme gestionnaire de mots de passe.
Deux points ressortent :
- la version est requise pour le support des clients Bitwarden 2026.7.0 et plus récents ;
- plusieurs correctifs de sécurité sont inclus.
Les advisories listées par le projet sont encore privées au moment de la release, en attente de CVE ou de publication complète. On sait toutefois qu’elles couvrent notamment des sujets comme SSRF sur l’endpoint d’icônes, accès inter-organisation, contournements de politiques ou énumération de données via certains rôles.
Pour un service qui stocke des secrets, je ne chercherais pas à optimiser au jour près. Le bon ordre reste :
- sauvegarde ;
- lecture de la release ;
- mise à jour ;
- test des clients ;
- vérification des logs.
Commandes de contrôle :
docker compose ps vaultwarden
docker compose logs --tail=100 vaultwardenSi vous utilisez des organisations, SSO, envoi de secrets ou l’import de répertoires, testez ces chemins explicitement après upgrade. Ce sont souvent les fonctions “pas quotidiennes” qui cassent sans être vues tout de suite.
Signaux de veille cette semaine#
Bandcamp ajoute une API Subsonic en bêta. C’est intéressant parce que Subsonic continue de servir de protocole d’interopérabilité musical au-delà du pur self-hosting. Bandcamp permet de générer des identifiants et de streamer sa collection via certains clients compatibles, dont Amperfy, Feishin et Submariner. Pour l’instant, la bêta peut être lente sur de grosses collections.
Pangolin 1.21.0 ajoute la détection de même réseau. L’idée est d’éviter le relais quand client et site sont sur le même réseau, avec clients et sites à jour. La release ajoute aussi des améliorations sur les share links, l’IdP utilisé en dernier, les ressources privées et l’API d’intégration. Comme d’habitude avec Pangolin, sauvegarde de la config avant upgrade.
Nextcloud publie des releases de maintenance. FreshRSS remonte notamment 34.0.2, 33.0.7 et 32.0.13. Pour Nextcloud, les mises à jour de maintenance ne sont pas glamour, mais elles réduisent souvent plus de friction réelle que les grandes annonces. À planifier après sauvegarde, surtout si beaucoup d’apps tierces sont installées.
OpenAI et Hugging Face documentent un incident de sécurité pendant une évaluation de modèle. Le récit est inhabituel : des modèles testés avec des garde-fous réduits ont chaîné des vulnérabilités et atteint l’infrastructure Hugging Face dans le cadre d’une évaluation cyber. Le point opérationnel n’est pas de paniquer sur “l’IA qui hacke tout”. Le point utile est plus simple : les environnements d’évaluation de modèles capables doivent être isolés comme des environnements offensifs.
degoog propose un agrégateur de moteurs de recherche self-hosted. Le projet permet d’interroger plusieurs moteurs, d’ajouter des plugins, transports et thèmes. Le README prévient clairement qu’une instance exposée sans mot de passe de paramètres permettrait à n’importe qui d’installer des extensions, donc potentiellement d’exécuter du code côté serveur. C’est exactement le genre de détail à lire avant un docker run public.
Bandcamp - Discover Improvements and Subsonic Implementation
Pangolin 1.21.0
Nextcloud Server v34.0.2
OpenAI - Hugging Face model evaluation security incident
degoog
Les pépites de la semaine#
open-wanderer/wanderer : base de données self-hosted pour traces et aventures outdoor. À regarder si vous voulez garder vos parcours hors des grandes plateformes sportives, mais le vrai critère sera l’import/export propre des traces.
Navidrome côté Jellyfin : un PR expérimental ajoute un support API qui doit permettre à terme de streamer sa musique via des clients Jellyfin. Ce n’est pas encore une promesse de production, mais l’angle est bon : réutiliser des clients existants plutôt que reconstruire une interface pour chaque serveur média.
Ruff 0.16.0 : la release remonte dans la veille technique avec un nombre de règles par défaut en forte hausse. Pour une équipe Python, ce type de changement mérite un test sur branche avant activation large, surtout si le lint est bloquant en CI.
wanderer
Navidrome - experimental Jellyfin API support
Ruff v0.16.0
Commande du jour#
fold -w 100 -s fichier.txtfold replie les lignes longues à une largeur donnée. L’option -w fixe la largeur, et -s évite de couper les mots quand c’est possible.
C’est pratique pour relire une sortie ou un fichier texte dans un terminal étroit :
journalctl -u nginx --since today | fold -w 120 -sCe n’est pas un outil de formatage persistant. Il sert surtout à rendre une sortie lisible sans modifier le fichier source.
Sources#
- Jellyfin - Project Leadership Changes
- Jellium Desktop - Rename the app
- Codeberg - Protecting our FLOSS commons from LLMs
- SmartThings - A New Enhanced SmartThings API Experience
- Vikunja 2.4.0
- vaultwarden 1.37.0
- Bandcamp - Discover Improvements and Subsonic Implementation
- Pangolin 1.21.0
- Nextcloud Server v34.0.2
- OpenAI - Hugging Face model evaluation security incident
- degoog
- wanderer
- Navidrome - experimental Jellyfin API support
- Ruff v0.16.0