Sync-In est un projet libre de stockage, synchronisation et collaboration autour des fichiers. Son développeur principal, Johan Legrand, nous avait expliqué en octobre 2025 sa volonté de proposer une solution simple pour synchroniser et gérer des fichiers, avec un aspect collaboratif. Sync-In s’installe sur un serveur et permet la gestion des fichiers, l’utilisation d’une suite bureautique et fournit une gestion fine des autorisations.

La nouvelle mouture 2.6 intègre désormais draw.io pour la création et l’édition des diagrammes. L’installation peut se faire via le service Docker fourni ou une instance draw.io externe. La fonction prend en charge les fichiers VSDX et Gliffy, qui peuvent être importés et convertis au format .drawio.

Cette version apporte également des améliorations diverses, dont une visionneuse d’images modernisée, un mode galerie pour parcourir les images d’un dossier, la réunion du filtrage local et de la recherche globale dans la barre de navigation, des préférences utilisateur persistantes (enregistrées au niveau du compte), ou encore la possibilité pour la synchronisation d’ignorer les suppressions.

Sync-In propose en outre des améliorations de performances. La consommation mémoire se veut ainsi réduite d’environ 10 % et les vérifications de la base de données sont plus rapides. Côté sécurité, on note une protection harmonisée pour les services sensibles, dont l’authentification, la synchronisation et les liens publics.

Comme les versions précédentes, Sync-In 2.6 peut être récupéré en paquet NPM ou en image Docker. Les clients desktop (Windows, Mac, Linux, CLI) recevront prochainement une version 2.3 pour tenir compte des nouveautés introduites.

Sync-In est un projet libre de stockage, synchronisation et collaboration autour des fichiers. Son développeur principal, Johan Legrand, nous avait expliqué en octobre 2025 sa volonté de proposer une solution simple pour synchroniser et gérer des fichiers, avec un aspect collaboratif. Sync-In s’installe sur un serveur et permet la gestion des fichiers, l’utilisation d’une suite bureautique et fournit une gestion fine des autorisations.

La nouvelle mouture 2.6 intègre désormais draw.io pour la création et l’édition des diagrammes. L’installation peut se faire via le service Docker fourni ou une instance draw.io externe. La fonction prend en charge les fichiers VSDX et Gliffy, qui peuvent être importés et convertis au format .drawio.

Cette version apporte également des améliorations diverses, dont une visionneuse d’images modernisée, un mode galerie pour parcourir les images d’un dossier, la réunion du filtrage local et de la recherche globale dans la barre de navigation, des préférences utilisateur persistantes (enregistrées au niveau du compte), ou encore la possibilité pour la synchronisation d’ignorer les suppressions.

Sync-In propose en outre des améliorations de performances. La consommation mémoire se veut ainsi réduite d’environ 10 % et les vérifications de la base de données sont plus rapides. Côté sécurité, on note une protection harmonisée pour les services sensibles, dont l’authentification, la synchronisation et les liens publics.

Comme les versions précédentes, Sync-In 2.6 peut être récupéré en paquet NPM ou en image Docker. Les clients desktop (Windows, Mac, Linux, CLI) recevront prochainement une version 2.3 pour tenir compte des nouveautés introduites.

Promis, juré, crashé

Après de multiples annonces au printemps, Windows 11 a reçu ces derniers mois bon nombre d’améliorations diverses, nouvelles fonctions et autres corrections. Dans un billet faisant le point, Microsoft cherche à convaincre : les choses seraient bel et bien en train de changer.

Windows 11 se retrouve coincé à un carrefour peu enviable. D’un côté, une mauvaise réputation venant d’un manque de nouveautés à sa sortie et d’exigences strictes sur le matériel. D’un autre, le sentiment d’une mise à jour forcée après la mise à la retraite de Windows 10, même si l’Europe bénéficie d’une situation un peu moins précaire. D’un autre côté encore, des interrogations croissantes sur sa pertinence à une époque où Linux n’a plus grand-chose à lui envier pour les jeux vidéo et où le foisonnement logiciel explose via le vibe coding.

Microsoft fait un point d’étape

Dans un billet publié ce 15 octobre, Microsoft commence par mettre en avant les performances. L’éditeur l’affirme : l’ensemble du système se veut jusqu’à 20 % plus réactif, « avec des améliorations que vous pouvez ressentir dès le démarrage de votre PC et s’étendant à Démarrer, Explorateur de fichiers, Recherche, Outil de coupe, Microsoft 365, Edge et plus encore ».

L’entreprise explique qu’une bonne partie de ce travail vient d’une utilisation plus « intelligente » de la mémoire et des ressources du système. L’impact est variable selon les configurations, mais la différence se ressentirait le plus sur les systèmes équipés de 8 Go de mémoire seulement.

La firme précise que dans ce cas, Windows 11 peut garder en mémoire jusqu’à 2 Go supplémentaires de « données actives » au lieu de les déplacer vers un stockage plus lent (le swap). D’autres travaux ont été entrepris, comme un chargement en mémoire des widgets uniquement quand ils sont ouverts, économisant 200 Mo.

Microsoft braque les projecteurs sur de vastes travaux en cours qui commencent à donner leurs fruits sur les usages quotidiens. Par exemple, un fonctionnement plus fiable des casques Bluetooth, notamment sur l’appairage et la reconnexion. L’éditeur mentionne spécifiquement les AirPods, dont l’appairage peut être compliqué et qui se fait jusqu’à 15 secondes plus vite (donnant une idée du problème initial).

Outre une connexion plus rapide via Windows Hello, Microsoft cite aussi le travail en cours sur la qualité générale des pilotes tiers via sa Driver Quality Initiative. Dans ce sens, l’entreprise confirme ce qu’elle avait déjà dit cet été.

Nouvelle recherche, nouvelle application Photos

Les choses sont « dites »

Le débat secoue la communauté du libre depuis des mois : faut-il accepter le code généré par IA ? Pour certains, c’est une trahison de l’esprit même du libre. Pour d’autres, ce n’est pas un problème. Pour Linus Torvalds, il n’y a vraiment aucun problème, mais à une condition. Au point de se mettre une nouvelle fois en colère.

La question de savoir si le code généré par IA doit être accepté dans le noyau Linux semble être tranchée depuis un moment. Mais, le débat a évolué il y a bientôt 18 mois : le code généré par IA doit-il recevoir un marquage spécial ?

La question a été officiellement posée par Sash Levin en juillet 2025, comme le relevait alors Phoronix. Développeur travaillant chez NVIDIA et co-mainteneur des versions LTS (Long Term Support) du noyau, il avait proposé que les contributions au code générées par des LLM soient marquées d’un label « Co-developed-by ». Avec le temps, cette proposition évoluera en « Assisted-by ».

Dans un premier temps, cette proposition va plaire, au point d’être adoptée au Maintainers Summit 2025 en fin d’année dernière. À ce moment déjà, Linus Torvalds doutait déjà du bien-fondé de l’approche. Dans les mois qui suivent, un document coding-assistants.rst entre dans le noyau 7.0 pour formaliser ce qui est alors considéré comme une bonne pratique.

L’usage raisonné à grands coups de marteau

Les positions du père de Linux vont retentir plusieurs fois en 2026. Dès janvier, il s’oppose à ce que la documentation du noyau prenne parti. Sans jamais vraiment le dire, il milite alors pour un usage « raisonné » de l’IA. En mai par exemple, il tempête contre les trop nombreux rapports de bugs produits par les outils automatiques. Une critique désormais courante, portée notamment par l’équipe de FFmpeg qui fustigeait les LLM utilisés à la va-vite pour générer des rapports de bugs de faible qualité (le fameux slop, ou « bouillie »).

Deux mois plus tard éclate un débat autour de Sashiko, un service centralisé proposé par Google pour surveiller automatiquement la mailing-list du noyau (entre autres) pour publier ensuite des reviews de code de manière automatisée. Linus Torvalds intervient alors pour indiquer que le consensus général des mainteneurs du noyau est que l’IA est utile quand elle est utilisée correctement. Il ne souhaite pas que les rapports générés soient rejetés en bloc, tout en soulignant les améliorations nécessaires.

Le cas du noyau Linux 7.3

Depuis, sa position s’est encore affirmée, notamment à travers la gestation du noyau Linux 7.3. Les Release Candidates 6 et 7 sont devenues une « nouvelle normalité », car au lieu de ne corriger que quelques bugs – ce qui est traditionnellement le cas à ce stade du développement –, elles en corrigent des centaines.

Jonathan Corbet (LWN.net) a ainsi fait un compte-rendu du dernier Maintainers Summit qui s’est tenu le 8 octobre à Prague. Selon lui, le noyau 7.3 comporte actuellement 18 533 changements. Sur cet ensemble, 10 % des correctifs portent la mention « Assisted-by », mais il ajoute : « Le nombre réel de correctifs assistés par LLM est sûrement bien plus élevé ».

Il rapporte également la prise de parole de Linus Torvalds : blâmer les LLM au sein de la communauté est contre-productif car le problème se concentre sur les utilisateurs qui ne savent comment les utiliser, ou même comment fonctionne le noyau. « Torvalds et d’autres ont répété que les contributions de faible qualité venaient de nouveaux développeurs et qu’elles devraient recevoir une faible priorité, la communauté devrait arrêter d’essayer de rendre la contribution facile. De nombreux développeurs ont déclaré, à plusieurs reprises qu’ils essayaient de les mentorer mais que c’était presque toujours une perte de temps ; ils n’écoutent pas », rapporte sévèrement Jonathan Corbet.

Linus Torvalds se fâche (encore)

Au sommet de Pragues, les mainteneurs du noyau ont convenu que l’étiquette était désormais obsolète. Cependant, le développeur Laurent Pinchart s’y est opposé. Dans un message daté du 13 octobre, il refuse que l’étiquette soit supprimée tant qu’un mécanisme de remplacement n’a pas été mis en place. Il soutient qu’une règle sert à fixer les attentes, même si certains la contournent.

La réponse de Torvalds, dans la nuit du 13 au 14 octobre, est salée.

« Je ne comprends pas toute cette idée idiote du « n’utilisez pas l’IA pour X ». Voici une nouvelle règle rien que pour vous : n’utilisez aucun compilateur pour vos contributions au noyau. Parce que si vous ne pouvez pas démontrer que vous comprenez réellement ce que fait la machine en écrivant votre code en assembleur, alors je ne veux pas voir votre contribution. Vous n’êtes manifestement pas compétent si vous ne savez pas l’écrire ainsi.

Et au fait, vous feriez mieux de ne pas utiliser non plus d’éditeur pour rédiger ce message de validation. Parce que j’ai besoin que vous me montriez que vous savez réellement écrire un bon message de validation sans outils qui permettent de revenir en arrière facilement et de masquer les erreurs commises en tapant. D’accord ? Parce que, sinon, vos validations assistées par des outils ne montrent clairement pas que vous savez ce que vous faites.

Ne voyez-vous pas à quel point ce genre de règles serait ABSOLUMENT STUPIDE ?

Alors non. Nous n’allons pas établir de règles stupides qui disent « vous ne pouvez pas utiliser d’outils pour X ». Ce que j’attends moi, c’est que les gens fassent de leur mieux, et j’attends d’eux qu’ils comprennent ce qu’ils font. Mais cette compréhension a très peu de rapport avec les outils qu’ils utilisent.

Et, très honnêtement, d’après mon expérience, les personnes que je respecte et que je juge intelligentes ne sont pas celles qui rechignent à utiliser des outils nouveaux et intéressants. »

Aujourd’hui, un nombre croissant accepte les contributions générées par LLM. Dernièrement, le cas le plus visible a été le projet Debian, qui a adopté un consensus que l’on trouve dans plusieurs autres projets, dont Fedora, LLVM ou même Firefox : les contributions sont acceptées à condition que les personnes qui les émettent soient capables de les relire, de les comprendre et de les expliquer.

D’autres projets, comme Gentoo, NetBSD, Zig ou Krita refusent explicitement ce type de contribution ou ont mis en place un moratoire sur cet usage. Enfin, beaucoup ne sont pas encore officiellement positionnés, à l’instar du projet KDE, qui vient de fêter ses 30 ans.

• KDE fête ses 30 ans

Les choses sont « dites »

Le débat secoue la communauté du libre depuis des mois : faut-il accepter le code généré par IA ? Pour certains, c’est une trahison de l’esprit même du libre. Pour d’autres, ce n’est pas un problème. Pour Linus Torvalds, il n’y a vraiment aucun problème, mais à une condition. Au point de se mettre une nouvelle fois en colère.

La question de savoir si le code généré par IA doit être accepté dans le noyau Linux semble être tranchée depuis un moment. Mais, le débat a évolué il y a bientôt 18 mois : le code généré par IA doit-il recevoir un marquage spécial ?

La question a été officiellement posée par Sash Levin en juillet 2025, comme le relevait alors Phoronix. Développeur travaillant chez NVIDIA et co-mainteneur des versions LTS (Long Term Support) du noyau, il avait proposé que les contributions au code générées par des LLM soient marquées d’un label « Co-developed-by ». Avec le temps, cette proposition évoluera en « Assisted-by ».

Dans un premier temps, cette proposition va plaire, au point d’être adoptée au Maintainers Summit 2025 en fin d’année dernière. À ce moment déjà, Linus Torvalds doutait déjà du bien-fondé de l’approche. Dans les mois qui suivent, un document coding-assistants.rst entre dans le noyau 7.0 pour formaliser ce qui est alors considéré comme une bonne pratique.

L’usage raisonné à grands coups de marteau

Les positions du père de Linux vont retentir plusieurs fois en 2026. Dès janvier, il s’oppose à ce que la documentation du noyau prenne parti. Sans jamais vraiment le dire, il milite alors pour un usage « raisonné » de l’IA. En mai par exemple, il tempête contre les trop nombreux rapports de bugs produits par les outils automatiques. Une critique désormais courante, portée notamment par l’équipe de FFmpeg qui fustigeait les LLM utilisés à la va-vite pour générer des rapports de bugs de faible qualité (le fameux slop, ou « bouillie »).

Deux mois plus tard éclate un débat autour de Sashiko, un service centralisé proposé par Google pour surveiller automatiquement la mailing-list du noyau (entre autres) pour publier ensuite des reviews de code de manière automatisée. Linus Torvalds intervient alors pour indiquer que le consensus général des mainteneurs du noyau est que l’IA est utile quand elle est utilisée correctement. Il ne souhaite pas que les rapports générés soient rejetés en bloc, tout en soulignant les améliorations nécessaires.

Le cas du noyau Linux 7.3

Depuis, sa position s’est encore affirmée, notamment à travers la gestation du noyau Linux 7.3. Les Release Candidates 6 et 7 sont devenues une « nouvelle normalité », car au lieu de ne corriger que quelques bugs – ce qui est traditionnellement le cas à ce stade du développement –, elles en corrigent des centaines.

Jonathan Corbet (LWN.net) a ainsi fait un compte-rendu du dernier Maintainers Summit qui s’est tenu le 8 octobre à Prague. Selon lui, le noyau 7.3 comporte actuellement 18 533 changements. Sur cet ensemble, 10 % des correctifs portent la mention « Assisted-by », mais il ajoute : « Le nombre réel de correctifs assistés par LLM est sûrement bien plus élevé ».

Il rapporte également la prise de parole de Linus Torvalds : blâmer les LLM au sein de la communauté est contre-productif car le problème se concentre sur les utilisateurs qui ne savent comment les utiliser, ou même comment fonctionne le noyau. « Torvalds et d’autres ont répété que les contributions de faible qualité venaient de nouveaux développeurs et qu’elles devraient recevoir une faible priorité, la communauté devrait arrêter d’essayer de rendre la contribution facile. De nombreux développeurs ont déclaré, à plusieurs reprises qu’ils essayaient de les mentorer mais que c’était presque toujours une perte de temps ; ils n’écoutent pas », rapporte sévèrement Jonathan Corbet.

Linus Torvalds se fâche (encore)

Au sommet de Pragues, les mainteneurs du noyau ont convenu que l’étiquette était désormais obsolète. Cependant, le développeur Laurent Pinchart s’y est opposé. Dans un message daté du 13 octobre, il refuse que l’étiquette soit supprimée tant qu’un mécanisme de remplacement n’a pas été mis en place. Il soutient qu’une règle sert à fixer les attentes, même si certains la contournent.

La réponse de Torvalds, dans la nuit du 13 au 14 octobre, est salée.

« Je ne comprends pas toute cette idée idiote du « n’utilisez pas l’IA pour X ». Voici une nouvelle règle rien que pour vous : n’utilisez aucun compilateur pour vos contributions au noyau. Parce que si vous ne pouvez pas démontrer que vous comprenez réellement ce que fait la machine en écrivant votre code en assembleur, alors je ne veux pas voir votre contribution. Vous n’êtes manifestement pas compétent si vous ne savez pas l’écrire ainsi.

Et au fait, vous feriez mieux de ne pas utiliser non plus d’éditeur pour rédiger ce message de validation. Parce que j’ai besoin que vous me montriez que vous savez réellement écrire un bon message de validation sans outils qui permettent de revenir en arrière facilement et de masquer les erreurs commises en tapant. D’accord ? Parce que, sinon, vos validations assistées par des outils ne montrent clairement pas que vous savez ce que vous faites.

Ne voyez-vous pas à quel point ce genre de règles serait ABSOLUMENT STUPIDE ?

Alors non. Nous n’allons pas établir de règles stupides qui disent « vous ne pouvez pas utiliser d’outils pour X ». Ce que j’attends moi, c’est que les gens fassent de leur mieux, et j’attends d’eux qu’ils comprennent ce qu’ils font. Mais cette compréhension a très peu de rapport avec les outils qu’ils utilisent.

Et, très honnêtement, d’après mon expérience, les personnes que je respecte et que je juge intelligentes ne sont pas celles qui rechignent à utiliser des outils nouveaux et intéressants. »

Aujourd’hui, un nombre croissant accepte les contributions générées par LLM. Dernièrement, le cas le plus visible a été le projet Debian, qui a adopté un consensus que l’on trouve dans plusieurs autres projets, dont Fedora, LLVM ou même Firefox : les contributions sont acceptées à condition que les personnes qui les émettent soient capables de les relire, de les comprendre et de les expliquer.

D’autres projets, comme Gentoo, NetBSD, Zig ou Krita refusent explicitement ce type de contribution ou ont mis en place un moratoire sur cet usage. Enfin, beaucoup ne sont pas encore officiellement positionnés, à l’instar du projet KDE, qui vient de fêter ses 30 ans.

• KDE fête ses 30 ans