Cette semaine : Linux discute sérieusement de l’IA dans la revue de code, deux petits outils d’auth homelab gagnent en crédibilité côté OIDC, NocoDB continue de poser la question du modèle open source, et plusieurs projets self-hosted avancent sur des usages très concrets.
Le signal intéressant n’est pas une grosse release spectaculaire. C’est plutôt la maturité progressive de l’écosystème : authentification mieux standardisée, applications mobiles mieux distribuées, outils personnels qui s’intègrent à des protocoles existants, et communautés qui réagissent quand les frontières entre open source et enterprise deviennent floues.
Linux, IA et revue de code : le vrai sujet reste la charge mainteneur#
Sashiko, un système agentique de revue de code pour le kernel Linux, a relancé une discussion assez prévisible : que faire des contributions et revues assistées par IA dans un projet où la qualité du code dépend énormément du jugement humain ?
Linus Torvalds a répondu à la controverse avec une position plutôt pragmatique. Le problème n’est pas l’existence d’un outil IA en soi. Le problème commence quand l’outil produit du bruit, ajoute du travail aux mainteneurs ou donne une fausse impression de validation.
C’est probablement la bonne grille de lecture pour l’open source en 2026.
Une revue automatisée peut être utile si elle :
- repère des erreurs mécaniques ;
- pointe des régressions simples ;
- complète les tests statiques existants ;
- produit des remarques vérifiables ;
- réduit réellement le temps passé par les humains.
Elle devient toxique si elle :
- génère des commentaires vagues ;
- propose des changements non testés ;
- masque l’absence de compréhension du contributeur ;
- force les mainteneurs à trier plus de bruit qu’avant.
Pour un projet critique comme Linux, l’enjeu n’est donc pas “IA ou pas IA”. L’enjeu est plus banal et plus dur : est-ce que l’outil améliore le rapport signal/bruit ?
Le même raisonnement vaut pour nos dépôts internes. Un bot de review qui signale une erreur de verrouillage, un usage dangereux de mémoire ou une API dépréciée peut rendre service. Un bot qui reformule le code en commentaire sans rien prouver devient juste une file d’attente supplémentaire.
À retenir pour vos propres projets :
- gardez les commentaires automatiques désactivables ;
- exigez des liens vers tests, traces ou lignes précises ;
- mesurez le taux de faux positifs ;
- évitez de bloquer les merges sur une analyse IA non déterministe ;
- documentez clairement ce qui reste une décision humaine.
Réponse de Linus Torvalds sur la liste kernel
Sashiko
Pocket ID et Tinyauth : l’OIDC homelab devient moins bricolé#
Pocket ID 2.10.0 et Tinyauth 5.1.0 annoncent une certification OpenID Connect.
Pour un homelab, c’est plus important qu’une simple ligne de changelog. L’OIDC est souvent la brique qui finit par relier tout le reste : dashboard, reverse proxy, applications web, outils d’administration, services maison. Quand cette couche est approximative, on le paie ensuite avec des redirections bancales, des clients incompatibles ou des sessions difficiles à diagnostiquer.
La certification OIDC ne veut pas dire que le produit devient parfait ou automatiquement sûr. Elle indique surtout que l’implémentation respecte mieux les comportements attendus par les clients OIDC.
En pratique, ça compte pour :
- la compatibilité avec plus d’applications ;
- les flux de login moins fragiles ;
- les claims mieux structurés ;
- les erreurs de configuration plus faciles à isoler ;
- la réduction des comportements spécifiques à un outil.
Avant de brancher ce type de service sur une pile exposée, je vérifierais au minimum :
docker compose logs --tail=100 pocket-id
docker compose logs --tail=100 tinyauthEt côté configuration :
- URL publique exacte de l’issuer ;
- redirect URI strictement identique côté client et provider ;
- cookies en
Securederrière HTTPS ; - durée des sessions ;
- politique de récupération de compte ;
- sauvegarde de la base et des clés.
L’authentification est une bonne candidate pour la simplicité. Moins il y a de magie, mieux on débogue quand un reverse proxy, une application ou un navigateur refuse de coopérer.
Pocket ID v2.10.0
Tinyauth v5.1.0
NocoDB 2026.07.0 : le modèle enterprise sous surveillance#
NocoDB 2026.07.0 ajoute plusieurs fonctions orientées collaboration et gouvernance, mais une partie arrive côté enterprise. La réaction communautaire est assez nette : certains utilisateurs ont l’impression que des usages attendus dans une base collaborative glissent progressivement derrière une édition payante.
Ce n’est pas un sujet propre à NocoDB. Beaucoup de projets open source commerciaux vivent sur cette ligne :
- un coeur libre assez utile pour créer l’adoption ;
- des fonctions d’équipe, d’audit ou de permissions côté enterprise ;
- une frontière qui bouge avec le temps ;
- des utilisateurs self-hosted qui doivent réévaluer le risque de dépendance.
Il faut éviter deux excès.
Le premier serait de considérer qu’une entreprise n’a pas le droit de monétiser son produit. Maintenir une application complexe coûte cher, surtout quand elle touche aux bases de données, aux permissions et aux workflows collaboratifs.
Le second serait d’ignorer le risque opérationnel. Si une fonction devient critique dans votre organisation, sa disponibilité dans l’édition utilisée doit être traitée comme une dépendance. Pas comme une promesse implicite.
Avant de standardiser NocoDB, Baserow, Grist, Teable ou un outil équivalent, je regarderais surtout :
- licence réelle du serveur ;
- fonctions indispensables en édition libre ;
- export complet des données ;
- format des sauvegardes ;
- migration possible vers PostgreSQL ou fichiers standards ;
- historique des changements de modèle économique.
Ce n’est pas une raison pour fuir tous les projets open core. C’est une raison pour écrire noir sur blanc ce que vous acceptez de perdre si la frontière community/enterprise change.
NocoDB 2026.07.0
Discussion r/NocoDB
Discussion r/selfhosted
Dawarich 1.10.0 : Poster Studio pour valoriser ses données de position#
Dawarich 1.10.0 ajoute Poster Studio, une fonction qui permet de générer des visuels à partir de son historique de localisation.
Sur le papier, c’est exactement le genre de fonction qui donne du sens à une application personnelle : on ne collecte pas seulement des points GPS pour remplir une base, on en tire quelque chose de lisible.
Mais Dawarich manipule des données sensibles. Un historique de position complet dit beaucoup plus qu’une simple carte : domicile, travail, habitudes, trajets, lieux visités, rythme de vie.
Quelques réflexes avant d’exposer ou de partager ce type de sortie :
- vérifier ce que contient l’image exportée ;
- éviter les cartes trop précises autour du domicile ;
- retirer les métadonnées si nécessaire ;
- sauvegarder la base avant mise à jour ;
- limiter l’accès externe à l’instance.
Pour une instance Docker, les vérifications basiques restent les mêmes :
docker compose ps
docker compose logs --tail=100 dawarichEt pour les sauvegardes, ne vous contentez pas du volume applicatif si PostgreSQL ou Redis sont séparés. C’est souvent là que se trouvent les données réellement importantes.
Immich 3.0.3 arrive dans le dépôt F-Droid de FUTO#
Immich 3.0.3 publie les builds Android dans le dépôt F-Droid officiel de FUTO.
Pour les utilisateurs Android qui évitent le Play Store ou qui préfèrent une chaîne de distribution plus contrôlable, c’est une bonne nouvelle. Immich reste une application où le client mobile compte énormément : upload automatique, sauvegarde des photos, navigation dans la bibliothèque, partage familial.
Le point à surveiller reste le même qu’avec toute distribution alternative :
- source exacte du dépôt F-Droid ;
- signature de l’application ;
- rythme de mise à jour ;
- cohérence avec la version serveur ;
- comportement de l’upload après changement de canal.
J’avais détaillé les changements de fond d’Immich 3.0 dans l’article dédié : Immich 3.0 : ce qui change vraiment pour une instance self-hosted. Cette 3.0.3 ne change pas le diagnostic principal : Immich continue de se professionnaliser, mais il faut toujours lire les notes de version avant de mettre à jour serveur et clients.
Immich v3.0.3
Dépôt F-Droid FUTO
Plex, Logseq, Chatto et Fluxer : signaux faibles#
Plex continue de déployer sa nouvelle interface sur Fire TV et Roku. Les retours utilisateurs restent mitigés, ce qui n’est pas surprenant : une interface TV est très sensible aux habitudes, à la latence et au nombre de clics. Pour les gros utilisateurs self-hosted, c’est un rappel utile : l’expérience finale dépend autant du client que du serveur média.
Logseq poursuit sa bêta 2.0 avec une séparation plus nette entre les générations du produit. Avant de migrer une base de notes importante, je conseille de tester sur une copie et de vérifier export, plugins, performances et synchronisation. Les notes personnelles deviennent vite une dépendance critique.
Chatto passe open source. Le projet vise la messagerie, un domaine plus compliqué qu’il n’en a l’air : identité, notifications, chiffrement éventuel, modération, clients mobiles, persistance, migration. À surveiller, surtout si l’ouverture du code s’accompagne d’une vraie documentation de déploiement.
Fluxer travaille sur les API et la documentation self-hosting autour d’une alternative à Discord. Là aussi, le sujet est ambitieux. L’intérêt dépendra moins de la promesse que de la qualité des clients, de la gestion des permissions et de la simplicité d’exploitation.
Plex - Changes coming to Plex on Fire TV
Logseq 2.0.1
Logseq - annonce bêta
Chatto
Chatto is open source
Fluxer
La pépite : SUB/WAVE#
SUB/WAVE est une radio personnelle auto-hébergeable qui s’appuie sur Navidrome ou une API compatible Subsonic.
L’idée est simple : au lieu de parcourir manuellement sa bibliothèque musicale, on génère une radio personnelle avec une couche d’automatisation et d’IA. C’est un usage plutôt cohérent pour une médiathèque locale : les fichiers restent chez vous, mais l’interface essaie de recréer une expérience plus fluide qu’une simple liste d’albums.
Les points à vérifier avant adoption :
- compatibilité réelle avec votre serveur Subsonic/Navidrome ;
- besoin éventuel d’un provider IA externe ;
- gestion des credentials ;
- comportement sur une grosse bibliothèque ;
- facilité de sauvegarde de la configuration.
Ce genre de projet est intéressant quand il respecte une règle simple : enrichir une collection locale sans reprendre le contrôle sur elle.
Commande du jour#
: > fichier.logCette syntaxe vide un fichier sans le supprimer. C’est parfois pratique pour tronquer un log local tout en gardant le même inode, par exemple quand un processus a encore le fichier ouvert.
À utiliser avec prudence : le contenu est perdu immédiatement.
Alternative plus explicite :
truncate -s 0 fichier.logAvant de vider un fichier actif, vérifiez au moins sa taille et le service concerné :
ls -lh fichier.log
lsof fichier.logPour un log système, préférez d’abord la rotation propre via logrotate ou la configuration du service. Tronquer à la main doit rester une opération ponctuelle, pas une stratégie de maintenance.