Amazon vient d’annoncer un truc qui va faire plaisir à tous les lecteurs d’ebooks. A partir du 20 janvier 2026, les auteurs auto-édités pourront proposer leurs ebooks sans DRM en formats EPUB et PDF via la plateforme KDP (Kindle Direct Publishing). Vous pourrez enfin télécharger vos achats dans un format lisible ailleurs que sur Kindle et ça, ça fait plaisir parce que DeDRM ça commençait à bien faire ^^.

Toutefois, cette décision d’activer ou non le DRM reste entre les mains des auteurs et vu les réactions sur les forums KDP, beaucoup risquent de garder les verrous en place. Pour les titres déjà publiés, rien ne change automatiquement et les auteurs qui le souhaitent devront se connecter au portail KDP et modifier manuellement les paramètres de chaque livre s’ils veulent proposer les versions sans DRM. Et Amazon dans sa grande bonté, prévient que les modifications prendront jusqu’à 72 heures pour être effectives…

Donc si vous désactivez le DRM sur vos ouvrages, tous les acheteurs vérifiés pourront télécharger les fichiers EPUB et PDF. Et si vous réactivez le DRM plus tard, les nouveaux téléchargements dans ces formats seront bloqués. Rassurez-vous quand à vos royalties, elles restent identiques dans les deux cas.

Ce qui est dingue dans cette histoire, c’est qu’Amazon renforce en parallèle le DRM sur ses liseuses Kindle de 11e et 12e génération. Une mise à jour récente a en effet introduit un nouveau système de protection qui empêche les utilisateurs de sauvegarder leurs ebooks, sauf en jailbreakant l’appareil. Ils ont aussi supprimé la possibilité de télécharger et transférer des livres via USB.

Du coup, d’un côté Amazon ouvre une porte aux formats ouverts pour les auteurs indépendants, et de l’autre ils cadenassent encore plus leur écosystème Kindle pour les éditeurs traditionnels. La grande majorité des livres sur le Kindle Store restera donc protégée par DRM…

Bref, pour les lecteurs qui jonglent entre différentes plateformes (Apple Books, Google Play, Kobo et j’en passe), ça pourrait quand même faciliter les choses puisque vous pourrez importer vos achats KDP sans protection dans la liseuse de votre choix.

Mais encore faut-il que les auteurs jouent le jeu ? On verra bien !

Source

Si vous pensiez que LEGO se contentait de mouler du plastique comme dans les années 50, vous vous gourez car la marque danoise vient de franchir un cap historique en commercialisant sa toute première pièce fabriquée par impression 3D dans un set grand public.

Et il leur a fallu neuf ans de R&D pour y arriver !

La pièce en question se trouve dans le set Holiday Express Train (10361) de la gamme LEGO Icons, disponible depuis octobre. C’est une mini locomotive bleue avec des roues qui tournent et une petite cheminée qui monte et qui descend quand le train avance. Bref, un petit élément décoratif en apparence, mais qui représente un sacré tournant pour l’entreprise.

Alors pourquoi neuf ans de développement pour une pièce de quelques centimètres ? (qui a dit cmb ?). Parce que LEGO ne rigole pas avec la qualité, les amis ! L’équipe de Billund a dû construire un système de fabrication additive (c’est comme ça qu’on appelle les imprimantes 3D qui ajoutent les couches les unes au dessus des autres) capable de produire des pièces en masse avec le niveau de finition attendu par les fans. Ils utilisent pour cela une technologie de fusion de poudre polymère d’EOS, plus précisément une plateforme P 500 avec résolution Fine Detail, qui utilise un laser CO₂ ultra-fin pour créer des détails impossibles à obtenir avec le moulage par injection classique.

Cela permet d’avoir des mécanismes internes, des assemblages tarabiscotés, bref des trucs qu’un moule traditionnel ne pourrait jamais faire. L’impression 3D ouvre donc des possibilités que LEGO n’avait jamais eues.

Ronen Hadar, le responsable de la fabrication additive chez LEGO, compare ce moment à l’achat de la première machine à injection par les fondateurs dans les années 40. Un changement de paradigme donc et ça va s’accélérer puisque LEGO a déjà doublé la vitesse de production de ses machines et l’objectif pour eux, c’est que ces pièces imprimées en 3D deviennent “ennuyeusement normales” dans leur catalogue, et pas des curiosités de niche pour les collectionneurs.

Voilà, pour l’instant c’est une seule petite pièce dans un set de train de Noël mais si LEGO tient ses promesses, on pourrait voir débarquer des éléments de plus en plus complexes dans les années à venir… Des briques avec des mécanismes intégrés, des formes organiques, et des trucs qu’on n’imagine même pas encore.

Source

Discord a trouvé une solution radicale pour gérer son app de ses morts qui bouffe 4 Go de RAM sous Windows 11 (consommation ressentie : 4 millions de Go) : La redémarrer automatiquement quand elle dépasse ce seuil.

Les champions quoi ! Plutôt que de corriger les fuites mémoires, ils ont tout simplement décidé d’intégrer un auto-relaunch dans l’app en douce pour qu’elle se relance toutes les quelques heures.

Donc, si votre Discord a tourné pendant au moins 1 heure, que vous êtes inactif depuis 30 minutes (pas de souris/clavier), et que vous n’êtes pas en vocal ou en visio, l’app se redémarrera automatiquement dès qu’elle atteindra les 4 Go de conso mémoire.

Bien sûr Discord présente ça comme une solution temporaire pendant qu’ils bossent sur le vrai problème, mais je trouve ça marrant de normaliser ce bug en ajoutant une fonctionnalité qui le “contourne” bruyamment.

Le pire dans tout ça, c’est que le problème vient d’une connerie technique assez basique. L’app Discord utilise une bibliothèque appelée “systeminformation” qui appelle PowerShell avec des commandes comme Get-WmiObject Win32_logicaldisk juste pour récupérer des infos système basiques. Mais comme ils passent par Powershell plutôt que d’utiliser les API natives de Windows, ça bouffe de la RAM comme un gros porc.

Comme vous, je me demande pourquoi Discord ne refait pas son app avec un framework plus léger ? Hé bien c’est simple : ils sont coincés ! Parce Discord est bâti sur Electron, et Electron c’est un framework qui embarque un Chromium complet salade tomates oignons dans chaque application. Ça permet aux devs web de créer des apps desktop avec du JavaScript, du HTML et du CSS , mais le prix à payer c’est une app qui pèse 85 Mo à l’installation et bouffe 200-400 Mo de RAM au démarrage.

En théorie Electron permet de créer une app cross-platform facilement. C’est-à-dire d’avoir un seul code pour Windows, Mac et Linux. Mais dans les faits, Discord maintient quand même du code spécifique par plateforme pour les notifications, l’overlay gaming, les raccourcis système, etc. Bref, ils ont tous les inconvénients d’Electron (RAM, taille) sans vraiment profiter de l’avantage du “write once, run everywhere”.

C’est vrai que réécrire Discord en natif coûterait des millions. Faudrait refaire toute l’interface, toutes les fonctionnalités, tous les systèmes de plugins et de thèmes. Surtout que pendant ce temps, l’équipe actuelle continue d’ajouter des fonctionnalités sur leur usine à gaz, ce qui creuse encore plus la dette technique. C’est le sunk cost fallacy version logicielle… en gros, ils ont tellement investi dans Electron qu’ils ne peuvent plus reculer, même si repartir de zéro serait probablement moins coûteux sur le long terme.

Pourtant, des alternatives à Electron existent. Tauri est devenu le framework préféré des devs qui veulent de la performance … On est à 2-3 Mo d’installeur, 30-40 Mo de RAM au repos et il utilise Rust et le webview natif du système plutôt que d’embarquer Chromium. Les apps sont donc légères, rapides, et consomment 10 fois moins de ressources.

Y’a aussi Flutter, React Native Desktop, Qt… des frameworks qui produisent des apps vraiment natives avec des performances dignes de ce nom. Visual Studio Code démontre qu’Electron peut être performant si on l’optimise correctement, mais ça demande un boulot monstre et malheureusement, Discord n’a clairement pas envie de mettre les moyens.

Le vrai problème n’est donc pas technique, c’est économique, car pour 1 dev natif, y’a 8 devs web . Electron permet d’embaucher des devs JavaScript pas cher plutôt que des devs C++/Rust/Swift qui coûtent une blinde… donc, sacrifier la RAM des utilisateurs coûte moins cher que payer des ingénieurs système. Et comme les PC ont maintenant 16-32 Go de RAM, ils se disent que 4 Go pour du chat en ligne, c’est acceptable. Lol.

Bref, tout ça pour dire que Discord normalise le “patch-as-a-feature”, et j’imagine que demain Slack, Teams et tous les autres vont faire pareil. En attendant, jetez un œil à Ripcord et Stoat pour ceux qui veulent un truc mieux.

Source