Après des années de galère avec un NAS bruyant puis un miniPC pas beaucoup mieux, j'ai fini par trouver la configuration Plex idéale. Un Mac Mini M4 , deux SSD Lexar SL500 , et le silence absolu. Retour d'expérience.

Le bruit, l'ennemi numéro un

J'ai un serveur Plex depuis des années. Un serveur que je partage avec ma famille et mes amis les plus proches, et qui me sert à stocker des films et des séries souvent introuvables sur les plateformes légales, ou des versions numérisées de DVD et Blu-Ray que j'ai achetés, mais que je veux pouvoir streamer sur mon Apple TV. Vous voyez l'idée. Pendant longtemps, tout ça tournait sur un NAS Synology d'entrée de gamme. Ça marchait, mais dès que je voulais transcoder un film pour le regarder à distance, c'était mort. Lecture directe obligatoire, avec les problèmes de débit que ça implique, surtout à l'époque où j'étais encore en ADSL. Il y a trois ou quatre ans, j'ai décidé de monter d'un cran en déportant le serveur Plex sur un miniPC Beelink. Plus de puissance, transcodage enfin possible, bien pratique pour moi à distance ou pour mes proches qui n'ont pas forcément la fibre.

Sauf que toutes ces solutions avaient le même défaut. Le bruit. Entre les disques durs mécaniques, le ventilateur du NAS Synology qui ronronnait en permanence et celui du miniPC Beelink qui se mettait à souffler dès qu'on lui demandait un peu d'effort, c'était toujours pénible. Et comme je n'ai jamais eu la place de planquer tout ça dans un bureau ou un placard technique, le serveur a toujours tourné dans mon salon. Autant dire que les soirs de film, l'ambiance était moyennement au rendez-vous.

Le Mac Mini M4, une bête silencieuse

Et puis il y a quelques semaines, j'ai tout changé. Adios le miniPC, filé à un ami, et place au Mac Mini M4. Ce petit machin tout mignon, complètement silencieux, est une vraie bête de course pour Plex. On parle de quatre à cinq transcodages simultanés sans broncher, avec une sollicitation processeur qui reste sous les 3 à 4%. C'est presque absurde. Le tout en restant frais, sans ventilateur qui se déclenche, sans bruit parasite. Rien. Le silence total.

Pour l'administration, pas besoin d'écran ni de clavier. Tout se fait à distance via l'application Partage d'écran de macOS. Le Mac Mini est branché directement sur ma Livebox, et ça tourne comme une horloge. Et comme bonus, ça me fait un second Mac pour faire des tests quand j'en ai besoin. Pas mal pour une machine qui fait à peine la taille d'une main.

Les SSD Lexar SL500 en remplacement du NAS

Pour compléter le tableau, j'ai déplacé mes données les plus consultées, les films et les séries que ma famille et moi regardons le plus souvent, sur deux SSD SL500 de chez Lexar. Et là, c'est le coup de grâce pour le bruit. Non seulement les ventilateurs ont disparu avec le Mac Mini, mais les vibrations et le ronronnement des disques mécaniques du NAS aussi. Le silence est total. J'ai quand même gardé un NAS Synology en arrière-plan pour stocker les données froides, mon Time Machine et les films que personne ne regarde jamais. Il reste accessible à Plex au cas où, mais il est si peu sollicité qu'on l'entend à peine.

Le résultat, c'est une configuration compacte, silencieuse, et qui gère sans effort tout ce que je lui demande. Le Mac Mini fait tourner Plex comme si de rien n'était, les SSD Lexar offrent des temps d'accès instantanés, et le NAS se contente de dormir dans son coin.

Franchement, si vous êtes du genre à soigner votre setup multimédia à la maison, ce genre de configuration change la vie. Ça a un coût, on ne va pas se mentir, un Mac Mini M4 plus deux SSD externes ce n'est pas donné. Mais le confort au quotidien est incomparable. Plus de bruit, des performances de dingue pour le transcodage, et une machine qui ne chauffe même pas. Si vous avez la possibilité de basculer votre serveur Plex sur un Mac Mini, n'hésitez pas trop longtemps. Moi en tout cas, je ne reviendrais pas en arrière.

Si vous voulez vous équiper, voilà ma config :

• Mac mini M4
• SSD SL500 de chez Lexar

Un mec de 54 ans vient de plaider coupable pour avoir siphonné 8 millions de dollars aux artistes musicaux en utilisant 10 000 bots et de la musique générée par IA. Michael Smith, résident de Cornelius en Caroline du Nord, a monté pendant des années une ferme à streams qui écoutait en boucle des centaines de milliers de fausses chansons sur Spotify et Apple Music.

Le truc, c'est que ces plateformes ne paient pas un tarif fixe par écoute. Elles fonctionnent avec un pot commun mensuel qu'elles redistribuent proportionnellement au nombre de streams. Du coup, chaque fausse écoute générée par les bots de Smith grignotait directement la part des vrais artistes. En gros, c'est pas Spotify qui se faisait voler, c'est les musiciens qui galèrent déjà à vivre de leur art !

Pour le contenu, Smith avait en fait trouvé un deal avec le CEO d'une boîte de musique IA qui lui pondait des milliers de morceaux par semaine. Les fichiers WAV arrivaient sous forme de chaînes aléatoires de lettres et de chiffres, et il les renommait avec des noms d'artistes fictifs du genre "Calorie Event", "Calms Scorching" ou encore "Calypso Xored" (on sent le générateur de noms random). Les titres, pareil... "Zygotes", "Zyme Bedewing"... si vous tombez là-dessus dans votre discover, y'a de quoi tiquer quand même mais bon...

Et ce problème, ça pose une question que Spotify connaît bien : comment distinguer les vrais streams des faux quand les bots sont suffisamment dispersés sur des milliers de morceaux ? Smith avait justement calibré ses 10 000 bots pour ne pas déclencher les alertes anti-fraude, en répartissant les écoutes sur un catalogue énorme plutôt que de matraquer un seul titre. Pas con.

Mais le bonhomme s'est quand même fait choper. Il a accepté de rendre la totalité des 8 091 843 dollars et risque jusqu'à 5 ans de prison lors de son procès qui aura lieu le 29 juillet prochain. Pas sûr que le ratio risque/récompense en valait la chandelle, en fait.

Le problème de fond, c'est que cette affaire n'est probablement que la partie émergée de l'iceberg. Et je suis sûr que y'en a en France qui font la même... bah sachez que c'est pas cool et que vous risquez d'avoir de GROS ennuis... Avec les outils de génération musicale par IA qui se démocratisent, n'importe qui peut inonder les plateformes de contenu synthétique pour gratter des royalties.

Et tant que le modèle de rémunération repose sur un pot commun plutôt que sur un paiement direct par utilisateur, il sera vulnérable. Encore une fois, les vrais perdants, c'est pas les plateformes (elles prennent leur commission quoi qu'il arrive), mais ce sont les artistes indépendants qui voient leur part du gâteau fondre à chaque bot supplémentaire.

Moche...

Bref, la prochaine fois que votre playlist de découvertes vous propose un artiste nommé "Calypso Xored" ou un connerie de ce style... méfiance !

Source

SynthID, le filigrane invisible que Google injecte dans chaque image Gemini, c'était censé être incassable. Sauf qu'un dev a eu l'idée toute bête de générer des images noires et blanches avec Gemini, puis de regarder ce qui restait dans le domaine fréquentiel. Et là, surprise... le watermark est apparu en clair avec toutes ses fréquences porteuses !

Le projet reverse-SynthID documente le truc de A à Z où on comprend en gros, que le marquage IA de Google fonctionne en injectant de l'énergie à des fréquences bien précises dans le spectre de l'image via une transformation de Fourier . Le chercheur a identifié 6 fréquences porteuses principales, toutes avec une cohérence de phase supérieure à 99,9% et la blague, c'est que ce pattern est fixe. Donc pas de message unique par image, pas de clé qui change... c'est juste la même empreinte spectrale sur toutes les images sorties du modèle Gemini.

Spectre FFT du watermark SynthID - les pics lumineux correspondent aux fréquences porteuses identifiées

Du coup, une fois que vous avez profilé cette empreinte avec une cinquantaine d'images PNG de référence (25 noires, 25 blanches, générées via l'API Gemini), vous pouvez faire deux trucs. D'abord, détecter le filigrane avec 90% de précision, sans avoir le moindre accès au code source de Google. Et ensuite le retirer en soustrayant les composantes spectrales identifiées, fréquence par fréquence, tout en préservant la qualité de l'image à plus de 40 dB PSNR. Visuellement identique à l'original !

Et c'est là que la différence avec UnMarker (dont je vous avais parlé) saute aux yeux car ce dernier "secoue" l'image en aveugle pour casser le watermark. Alors que Reverse-SynthID, c'est plutôt scruté à la loupe et hyper ciblé. Résultat, y'a clairement moins de dégradation et un drop de confiance du détecteur.

Les fréquences porteuses reconstruites - la structure diagonale du watermark SynthID

Par contre, je l'ai implémenté en Rust et j'ai essayé de voir si ça marchait vraiment sur mes propres images générée avec Gemini. Hé bien non, car le bypass ne fait PAS chuter la confiance du détecteur de 100 à 0, mais juste de quelques pourcents.

Le watermark est atténué, mais pas effacé. Ce n'est donc pas un outil clé en main pour faire disparaître tous les filigranes SynthID en un clic. Mais le fait qu'une seule personne, avec du Python et du traitement de signal classique (FFT, filtres notch, soustraction spectrale), ait pu reverse-engineerer un système que Google présente comme LA solution anti-deepfakes...

Ça confirme ce que les chercheurs de l'Université de Waterloo avaient déjà démontré : le watermarking d'images IA, c'est pété by design.

D'ailleurs, Google le sait très bien et ils pourraient changer le pattern demain et tout serait à refaire, mais ça confirme surtout que le principe même du watermarking spectral a une date de péremption. Après, ça arrange tout le monde d'avoir un truc à montrer quand les gouvernements demandent "et contre les deepfakes, vous faites quoi ?"

Et si c'est la petite étoile visible en bas à droite des images Gemini qui vous gêne (pas le watermark spectral invisible, juste le marqueur visuel), j'ai développé un outil pour mes Patreons qui s'en occupe.

Bref, tout est sur le repo si le reverse-engineering de watermarks IA, ça vous branche !

Des chercheurs de l'université de Californie du Sud viennent de publier une étude improbable : demander à un modèle d'IA de jouer les experts dégrade ses performances sur les tâches factuelles. Commencer un prompt par "Tu es un expert en programmation" produit de moins bons résultats que de poser la question directement.

Le piège du "tu es un expert"

L'étude, intitulée "Expert Personas Improve LLM Alignment but Damage Accuracy", a mesuré l'impact des instructions de rôle sur les réponses des modèles de langage.

Sur le benchmark MMLU, qui teste les connaissances générales et le raisonnement, les modèles avec une persona d'expert ont obtenu 68 % de bonnes réponses contre 71,6 % sans aucune instruction de rôle.

La baisse est constante sur toutes les catégories testées : maths, code, sciences, culture générale. Bref, dire à une IA qu'elle est brillante la rend un peu moins brillante.

Quand ça marche quand même

Par contre, le persona prompting fonctionne très bien pour un autre type de tâches : la sécurité et l'alignement. En attribuant un rôle de "moniteur de sécurité" au modèle, les chercheurs ont augmenté le taux de refus d'attaques de 53,2 % à 70,9 %, soit une hausse de 17,7 points. Pour les tâches d'écriture et de mise en forme, les personas aident aussi.

L'explication est assez logique : quand on colle un rôle d'expert au modèle, il bascule en mode "suivi d'instructions" et mobilise moins de ressources pour aller chercher les faits dans ses données d'entraînement. Aucune connaissance n'est ajoutée, on déplace juste l'attention du modèle.

Le bon réflexe à adopter

Les chercheurs de l'USC proposent un outil baptisé PRISM qui active automatiquement les personas uniquement quand c'est utile. Mais en attendant que ce genre de système soit intégré aux chatbots grand public, la recommandation est simple : si vous avez besoin de réponses factuelles ou de code, posez votre question directement sans ajouter de rôle.

Si vous voulez que l'IA respecte un ton, un format ou des consignes de sécurité, le persona prompting reste la bonne approche.

On a quand même passé deux ans à répéter partout qu'il fallait commencer ses prompts par "Tu es un expert en..." pour avoir de meilleurs résultats. Visiblement, c'était un peu du vent.

Source : Search Engine Journal

Dirt 3 qui passe de 110 à 860 FPS sous nunux, non, j'ai pas fumé la moquette ! En fait c'est surtout grâce au fameux module de synchronisation kernel NTSYNC promis avec Wine 11 qui est enfin dispo dans certaines distros. Et la bonne nouvelle c'est que les premiers benchmarks développeurs viennent de tomber, donc on va regarder ça ensemble !

Concrètement, Fedora 42, Ubuntu 25.04 et SteamOS 3.7.20 beta embarquent maintenant le module par défaut avec le kernel 6.14. Du coup Resident Evil 2 bondit de 26 à 77 FPS, Call of Juarez grimpe de 99 à 224 FPS, et Tiny Tina's Wonderlands passe de 130 à 360. Et Call of Duty Black Ops est maintenant devenu... jouable ! Woohoo !

Alors attention, ces benchmarks comparent Wine vanilla (sans aucune optimisation) avec Wine + le module. Cela veut dire que si vous utilisiez déjà fsync via Proton ou Lutris, les gains seront moins spectaculaires. Après les jeux qui en profitent le plus sont ceux avec de grosses charges multi-thread où la synchronisation était vraiment le problèmo noméro uno.

Pour capter pourquoi cette news est un gros morceau, faut regarder un peu sous le capot. Au temps jadis, chaque fois qu'un jeu Windows devait coordonner ses threads (genre, attendre qu'une texture finisse de charger), Wine faisait des allers-retours avec wineserver... des milliers de fois par seconde. Du coup, on se tapait des micro-sacades et une cadence d'images pourrie.

Y'a eu des tentatives pour arranger ça. D'abord esync, puis fsync... ça améliorait les choses mais c'était du bricolage. Ça nécessitait des patchs kernel non-officiels que personne ne maintenait vraiment, et certains jeux gourmands faisaient carrément tout planter.

Mais tout cela c'est de l'histoire ancienne puisque NTSYNC, semble être enfin la bonne approche. Elizabeth Figura (CodeWeavers), la même dev qui avait pondu les solutions précédentes, a créé, cette fois, un vrai module intégré directement dans le noyau Linux. Comme ça, plus de bidouilles à la con et surtout plus d'approximations. Le noyau gère enfin la synchronisation lui-même, nativement, comme il aurait toujours dû le faire.

La stonksitude du barbu gamer est à son maaaax

Après des années de boulot et une présentation à la Linux Plumbers Conference 2023, le module a fini par être mergé dans le kernel mainline il y a peu. Ça marche donc "out of the box" et ça c'est plutôt chouette !

Et pour les possesseurs de Steam Deck, quand Valve rebasera Proton officiel sur Wine 11, tout le monde aura ça gratos !! En attendant, si vous êtes impatient, sachez que Proton-GE le supporte déjà ! Entre ça et le fait que 90% des jeux Windows tournent maintenant sous Linux , y'a clairement plus d'excuses pour rester sous Windows si c'est le gaming qui vous retenait, mes cocos !

Bref, c'est carrément la plus grosse avancée gaming Linux depuis Proton. Pas mal pour un module kernel bien velu quand même !

Source

Sora, c’est fini les amis !

Hé oui, cest chacals d'OpenAI ferment leur plateforme de vidéos IA, et franchement, ça me rend un peu triste. À vrai dire, même si c’était que de la vidéo générée à partir de prompts, moi je me marrais bien. C'était fun de regarder le produit de ses prompts mais aussi de regarder les conneries des autres. Les versions québécoises, aïe aïe aïe, c’était quelque chose quand même !

Mais bon, le plus urgent maintenant, c’est de sauvegarder vos vidéos avant que tout disparaisse. OpenAI n’a pas encore communiqué de date précise pour la coupure, juste un vague « on vous dira bientôt ». Du coup, autant ne pas traîner, parce que quand ce genre de service cloud ferme, en général c’est pas 6 mois de préavis qu’on vous file...

// ==========================================================
// SORA BACKUP - Sauvegarde complète vidéos + images + prompts par Korben
// ==========================================================
// Usage : Ouvrir https://sora.com, F12 > Console, coller ce script
// Les fichiers sont téléchargés via le navigateur (dossier Downloads)
// Un fichier manifest.json récapitule tout (prompts, metadata, URLs)
// ==========================================================

(async () => {
 // --- Mini ZIP builder (STORE, pas de lib externe) ---
 const crc32table = new Uint32Array(256);
 for (let i = 0; i < 256; i++) {
 let c = i;
 for (let j = 0; j < 8; j++) c = (c & 1) ? (0xEDB88320 ^ (c >>> 1)) : (c >>> 1);
 crc32table[i] = c;
 }
 function crc32(buf) {
 let c = 0xFFFFFFFF;
 for (let i = 0; i < buf.length; i++) c = crc32table[(c ^ buf[i]) & 0xFF] ^ (c >>> 8);
 return (c ^ 0xFFFFFFFF) >>> 0;
 }
 const zipFiles = []; // {name, data (Uint8Array), crc, size}

 const PAGE_SIZE = 50;
 const DELAY_MS = 1500;
 const manifest = [];
 let totalDownloaded = 0;
 let totalErrors = 0;

 // --- Auth : récupérer le Bearer token ---
 // OPTION 1 : Coller ton token ici (Network tab > Authorization header)
 // OPTION 2 : Laisser vide, le script tentera de le récupérer auto
 let AUTH_TOKEN = '';

 async function getAuthToken() {
 if (AUTH_TOKEN) return AUTH_TOKEN;

 // Auto-detect : endpoint session ChatGPT
 for (const path of ['/api/auth/session', '/backend-api/auth/session']) {
 try {
 const r = await fetch(path, { credentials: 'include' });
 if (r.ok) {
 const json = await r.json();
 if (json.accessToken) {
 AUTH_TOKEN = json.accessToken;
 console.log(' 🔑 Token récupéré automatiquement');
 return AUTH_TOKEN;
 }
 }
 } catch(e) {}
 }

 // Fallback : demander à l'utilisateur
 const input = prompt(
 'Token non trouvé automatiquement.\n\n' +
 'Pour le récupérer :\n' +
 '1. F12 > onglet Réseau\n' +
 '2. Rafraîchis la page\n' +
 '3. Clique sur une requête /backend/...\n' +
 '4. Copie le header Authorization\n\n' +
 'Colle le token ici (Bearer eyJ...):'
 );
 if (input) {
 AUTH_TOKEN = input.replace(/^Bearer\s+/i, '').trim();
 return AUTH_TOKEN;
 }

 console.error(' ❌ Pas de token. Annulation.');
 return null;
 }

 // --- Fetch API avec auth ---
 async function apiFetch(url) {
 const token = await getAuthToken();
 const headers = {};
 if (token) headers['Authorization'] = 'Bearer ' + token;

 // oai-device-id requis par certains endpoints
 const deviceId = localStorage.getItem('oai-did') || '';
 if (deviceId) headers['oai-device-id'] = deviceId;

 const resp = await fetch(url, {
 method: 'GET',
 credentials: 'include',
 headers
 });

 if (!resp.ok) throw new Error(`HTTP ${resp.status} for ${url}`);
 return resp.json();
 }

 // --- Pagination générique ---
 async function fetchAllPages(baseUrl, dataField = 'data', cursorParam = 'after', cursorField = 'last_id') {
 let allItems = [];
 let cursor = '';
 let page = 0;

 while (true) {
 let url = baseUrl;
 if (cursor) url += `&${cursorParam}=${cursor}`;

 console.log(` 📄 Page ${++page} (${allItems.length} items so far)...`);
 const json = await apiFetch(url);

 const items = json[dataField];
 if (!Array.isArray(items) || items.length === 0) break;

 allItems = allItems.concat(items);
 cursor = json[cursorField] || '';

 if (!json.has_more && !cursor) break;
 await sleep(DELAY_MS);
 }

 return allItems;
 }

 // Variante pour les endpoints project_y (cursor-based)
 async function fetchAllPagesCursor(baseUrl) {
 let allItems = [];
 let cursor = '';
 let page = 0;

 while (true) {
 let url = baseUrl;
 if (cursor) url += `&cursor=${cursor}`;

 console.log(` 📄 Page ${++page} (${allItems.length} items so far)...`);
 const json = await apiFetch(url);

 const items = json.items;
 if (!Array.isArray(items) || items.length === 0) break;

 allItems = allItems.concat(items);
 cursor = json.cursor || '';

 if (!cursor) break;
 await sleep(DELAY_MS);
 }

 return allItems;
 }

 function sleep(ms) { return new Promise(r => setTimeout(r, ms)); }

 // --- Extraire URL du média depuis une generation ---
 function getMediaUrl(gen) {
 return gen?.encodings?.source?.path
 || gen?.downloadable_url
 || gen?.url
 || '';
 }

 // --- Extraire le prompt (peut être dans actions, prompt, ou input_text) ---
 function getPrompt(item, gen) {
 // Prompt direct
 if (gen?.prompt) return gen.prompt;
 if (item?.prompt) return item.prompt;
 if (item?.input_text) return item.input_text;
 // Storyboard : les actions sont les descriptions des scènes
 if (item?.actions && typeof item.actions === 'object') {
 return Object.entries(item.actions)
 .sort((a,b) => Number(a[0]) - Number(b[0]))
 .map(([frame, desc]) => `[frame ${frame}] ${desc}`)
 .join(' | ');
 }
 if (gen?.actions && typeof gen.actions === 'object') {
 return Object.entries(gen.actions)
 .sort((a,b) => Number(a[0]) - Number(b[0]))
 .map(([frame, desc]) => `[frame ${frame}] ${desc}`)
 .join(' | ');
 }
 return '';
 }

 // --- Dérouler les items du profil Sora en items plats ---
 function flattenProfileItems(items) {
 const flat = [];
 for (const item of items) {
 const post = item.post || item;
 const attachments = post.attachments || [];
 if (attachments.length === 0) continue;

 for (const att of attachments) {
 const url = att.encodings?.source?.path || att.downloadable_url || att.url || '';
 if (!url) continue;

 flat.push({
 id: post.id || att.generation_id || '',
 generation_id: att.generation_id || '',
 task_id: att.task_id || '',
 title: att.title || post.discovery_phrase || '',
 prompt: post.text || '',
 emoji: post.emoji || '',
 type: att.generation_type || att.kind || '',
 width: att.width || 0,
 height: att.height || 0,
 duration_s: att.duration_s || 0,
 is_public: !!post.posted_to_public,
 created_at: post.posted_at ? new Date(post.posted_at * 1000).toISOString() : '',
 url: url,
 permalink: post.permalink || '',
 username: item.profile?.username || '',
 });
 }
 }
 return flat;
 }

 // --- Sanitize filename ---
 function sanitize(name) {
 return name.replace(/[<>:"\/\\|?*\x00-\x1f]/g, '_').substring(0, 100);
 }

 // --- Ajouter un fichier au ZIP ---
 async function addToZip(url, filename) {
 try {
 const resp = await fetch(url);
 if (!resp.ok) throw new Error(`HTTP ${resp.status}`);
 const buf = await resp.arrayBuffer();
 const data = new Uint8Array(buf);
 zipFiles.push({ name: filename, data, crc: crc32(data), size: data.length });
 totalDownloaded++;
 return true;
 } catch(e) {
 console.warn(` ⚠️ Erreur ${filename}:`, e.message);
 totalErrors++;
 return false;
 }
 }

 // --- Déduire l'extension ---
 function getExt(url, type) {
 if (!url) return type === 'video' ? '.mp4' : '.png';
 const m = url.match(/\.(mp4|webm|mov|png|jpg|jpeg|webp|gif)/i);
 return m ? '.' + m[1].toLowerCase() : (type === 'video' ? '.mp4' : '.png');
 }

 // ==========================================================
 // MAIN
 // ==========================================================
 const origin = window.location.origin;
 console.log('🎬 SORA BACKUP - Démarrage');
 console.log('='.repeat(50));

 // 1. Mes posts Sora (profil)
 console.log('\n📦 1/2 - Récupération de mes posts Sora...');
 let myPosts = [];
 try {
 myPosts = await fetchAllPagesCursor(
 `${origin}/backend/project_y/profile_feed/me?limit=${PAGE_SIZE}&cut=nf2`
 );
 console.log(` ✅ ${myPosts.length} posts de profil`);
 // Debug premier item
 if (myPosts.length > 0) {
 const first = myPosts[0];
 console.log(' 🔍 Premier item - clés:', Object.keys(first).join(', '));
 console.log(' 🔍 URL:', first.url?.substring(0, 80) || 'none');
 console.log(' 🔍 DL:', first.downloadable_url?.substring(0, 80) || 'none');
 console.log(' 🔍 ENC:', first.encodings?.source?.path?.substring(0, 80) || 'none');
 console.log(' 🔍 GENS:', first.generations?.length || 'none');
 console.log(' 🔍 TITLE:', first.title || 'none');
 }
 } catch(e) {
 console.warn(' ⚠️ profil failed:', e.message);
 }

 // 2. Mes likes sur Sora
 console.log('\n📦 2/2 - Récupération de mes likes Sora...');
 let myLikes = [];
 try {
 myLikes = await fetchAllPagesCursor(
 `${origin}/backend/project_y/profile_feed/me?limit=${PAGE_SIZE}&cut=appearances`
 );
 if (myCameos.length) console.log(` ✅ ${myCameos.length} cameos trouvés`);
 } catch(e) {}

 // --- Dérouler les generations et dédupliquer ---
 console.log('\n🔄 Extraction des vidéos...');
 const rawAll = [...myPosts, ...myLikes];
 const flatItems = flattenProfileItems(rawAll);

 const seen = new Set();
 const allItems = [];
 for (const item of flatItems) {
 if (item.id && seen.has(item.id)) continue;
 // Filtrer : vidéos uniquement
 const isVideo = item.type === 'video_gen' || item.url.includes('/videos/') || item.url.includes('.mp4');
 if (!isVideo) continue;
 if (item.id) seen.add(item.id);
 allItems.push(item);
 }

 console.log(`📊 Total unique: ${allItems.length} vidéos à télécharger`);
 console.log('='.repeat(50));

 // --- Construire le manifest et télécharger ---
 console.log('\n⬇️ Téléchargement en cours...');
 console.log('(Les fichiers arrivent dans ton dossier Downloads)');

 for (let i = 0; i < allItems.length; i++) {
 const meta = allItems[i];
 const url = meta.url;

 if (!url) {
 console.log(` ⏭️ [${i+1}/${allItems.length}] ${meta.id} - pas d'URL, skip`);
 meta.downloaded = false;
 manifest.push(meta);
 continue;
 }

 const type = (meta.task_type === 'image_gen' || url.match(/\.(png|jpg|jpeg|webp|gif)/i)) ? 'image' : 'video';
 const ext = getExt(url, type);
 const nameBase = meta.title
 ? sanitize(meta.title)
 : (meta.prompt ? sanitize(meta.prompt.substring(0, 60)) : meta.id);
 const filename = `sora_${String(i+1).padStart(4,'0')}_${nameBase}${ext}`;

 console.log(` ⬇️ [${i+1}/${allItems.length}] ${filename}`);
 meta.filename = filename;
 meta.downloaded = await addToZip(url, filename);
 manifest.push(meta);

 // Pause entre downloads pour pas surcharger
 if (i < allItems.length - 1) await sleep(800);
 }

 // --- Ajouter le manifest au ZIP ---
 console.log('\n📝 Ajout du manifest au ZIP...');
 const manifestData = new TextEncoder().encode(JSON.stringify(manifest, null, 2));
 zipFiles.push({ name: 'manifest.json', data: manifestData, crc: crc32(manifestData), size: manifestData.length });

 // --- Générer le ZIP (format STORE, pas de compression) ---
 console.log('\n📦 Génération du ZIP...');
 const enc = new TextEncoder();
 const blobParts = [];
 const centralParts = [];
 let offset = 0;

 for (const f of zipFiles) {
 const nameBytes = enc.encode(f.name);
 // Local file header (30 bytes + name)
 const lh = new ArrayBuffer(30);
 const lv = new DataView(lh);
 lv.setUint32(0, 0x04034b50, true);
 lv.setUint16(4, 20, true);
 lv.setUint16(8, 0, true); // STORE
 lv.setUint32(14, f.crc, true);
 lv.setUint32(18, f.size, true);
 lv.setUint32(22, f.size, true);
 lv.setUint16(26, nameBytes.length, true);
 blobParts.push(new Uint8Array(lh), nameBytes, f.data);

 // Central directory entry (46 bytes + name)
 const ch = new ArrayBuffer(46);
 const cv = new DataView(ch);
 cv.setUint32(0, 0x02014b50, true);
 cv.setUint16(4, 20, true);
 cv.setUint16(6, 20, true);
 cv.setUint16(10, 0, true); // STORE
 cv.setUint32(16, f.crc, true);
 cv.setUint32(20, f.size, true);
 cv.setUint32(24, f.size, true);
 cv.setUint16(28, nameBytes.length, true);
 cv.setUint32(42, offset, true);
 centralParts.push(new Uint8Array(ch), nameBytes);

 offset += 30 + nameBytes.length + f.size;
 }

 const centralSize = centralParts.reduce((s, p) => s + p.length, 0);
 const eocd = new ArrayBuffer(22);
 const ev = new DataView(eocd);
 ev.setUint32(0, 0x06054b50, true);
 ev.setUint16(8, zipFiles.length, true);
 ev.setUint16(10, zipFiles.length, true);
 ev.setUint32(12, centralSize, true);
 ev.setUint32(16, offset, true);

 const zipBlob = new Blob([...blobParts, ...centralParts, new Uint8Array(eocd)], { type: 'application/zip' });

 const zipName = `sora_backup_${new Date().toISOString().split('T')[0]}.zip`;
 const a = document.createElement('a');
 a.href = URL.createObjectURL(zipBlob);
 a.download = zipName;
 document.body.appendChild(a);
 a.click();
 document.body.removeChild(a);
 URL.revokeObjectURL(a.href);

 // --- Résumé ---
 const sizeMB = (zipBlob.size / 1024 / 1024).toFixed(1);
 console.log('\n' + '='.repeat(50));
 console.log('🎬 SORA BACKUP TERMINÉ');
 console.log(` ✅ Vidéos dans le ZIP : ${totalDownloaded}`);
 console.log(` ❌ Erreurs : ${totalErrors}`);
 console.log(` 📦 Fichier : ${zipName} (${sizeMB} MB)`);
 console.log(` 📝 manifest.json inclus dans le ZIP`);
 console.log('='.repeat(50));
})();

Un groupe de pirates a compromis Trivy, un scanner de vulnérabilités open source très utilisé dans les pipelines de développement. Résultat : plus de 1 000 environnements SaaS infectés par un malware qui vole des clés API, des identifiants cloud et des tokens GitHub.

Un scanner de sécurité devenu vecteur d'attaque

Trivy est un outil open source maintenu par Aqua Security. Il sert à détecter des failles, des mauvaises configurations et des secrets exposés dans du code, et il est intégré dans les chaînes de déploiement continu (CI/CD) d'un très grand nombre d'entreprises. Le groupe TeamPCP a réussi à compromettre la version 0.69.4 de Trivy en exploitant une mauvaise configuration dans le composant GitHub Action du projet.

En février, ils ont volé un token d'accès privilégié, et ce token n'a jamais été correctement révoqué. En mars, les attaquants l'ont utilisé pour injecter du code malveillant directement dans le projet, en poussant des images Docker et des versions GitHub vérolées vers les utilisateurs.

Le résultat : 75 des 76 tags de trivy-action ont été remplacés par des versions malveillantes.

La contamination s'étend

L'attaque ne s'est pas arrêtée à Trivy. Le même groupe a aussi compromis liteLLM, une bibliothèque Python qui sert d'interface pour les modèles de langage et qui est présente dans 36 % des environnements cloud.

Ils ont aussi touché KICK (un outil d'analyse statique de Checkmarx) et déployé CanisterWorm, un ver qui se propage via des paquets npm vérolés. Le malware installé est un infostealer qui extrait les clés API, les identifiants de bases de données, les tokens GitHub et toute information sensible accessible dans l'environnement de build.

Mandiant, la branche cybersécurité de Google, estime que plus de 1 000 environnements SaaS sont actuellement compromis, et que ce chiffre pourrait grimper à 10 000. TeamPCP travaillerait avec le groupe Lapsus$, connu pour ses attaques contre Microsoft, Nvidia et Uber.

Des révélations à la conférence RSA

Les détails de l'attaque ont été rendus publics lors de la conférence RSA. Le chercheur en sécurité Paul McCarty a été le premier à tirer la sonnette d'alarme, suivi par les équipes de Socket, Wiz et Aikido.dev. Aqua Security a vu ses 44 dépôts GitHub internes défacés, avec une exposition du code source et des configurations CI/CD.

L'affaire montre à quel point les outils de sécurité open source, quand ils sont mal protégés, peuvent devenir le point d'entrée idéal pour une attaque à grande échelle.

C'est quand même un comble : un scanner de vulnérabilités qui devient lui-même le vecteur d'une attaque. Le fait qu'un simple token non révoqué ait suffi pour compromettre toute la chaîne montre que la sécurité des projets open source reste un vrai sujet. Et quand on sait que liteLLM est présent dans plus d'un tiers des environnements cloud, on mesure l'ampleur du problème...

Source : The Register

Le pilote Vulkan open source d'Intel pour Linux vient de recevoir une optimisation qui améliore les performances des jeux DirectX 12 tournant via Proton.

La modification a été intégrée à Mesa 26.1 et concerne les cartes graphiques Arc Alchemist et Battlemage. Le patch avait été proposé pour la première fois en 2020, il aura donc fallu plus de cinq ans pour le voir arriver.

Ce qui change pour les joueurs Linux

L'optimisation porte sur la façon dont le pilote ANV gère le cache d'état graphique. En utilisant une combinaison de deux identifiants internes (Binding Table Pointer et Binding Table Index) au lieu d'un seul pour référencer les textures, le pilote peut supprimer certaines étapes de synchronisation qui ralentissaient le rendu.

Les développeurs d'Intel indiquent que le gain est mesurable sur tous les jeux DirectX 12 qu'ils ont testés via VKD3D-Proton, la couche de traduction utilisée par Steam pour faire tourner les jeux Windows sur Linux.

Pas de chiffres précis dans la note technique, mais une autre modification récente du même pilote (un simple changement d'une ligne de code pour le prefetch des tables de textures) avait déjà montré des gains allant jusqu'à 3 à 4 % sur God of War et Destiny 2.

Un patch qui a mis cinq ans à arriver

L'anecdote vaut quand même le détour. Ce patch a été proposé pour la première fois en novembre 2020, et il vient d'être fusionné dans Mesa en mars 2026.

Plus de cinq ans entre la proposition et l'intégration, ce qui donne une idée du rythme de développement des pilotes graphiques open source. Le code nécessite aussi un correctif au niveau du noyau Linux (dans le pilote Xe), qui devrait arriver avec Linux 7.1.

Les GPU concernés sont les Intel Arc à partir de la génération Alchemist (Arc A770, A750, etc.) et les plus récents Battlemage (Arc B580, B570).

Quelques limites quand même

L'optimisation ne fonctionne bien qu'avec les jeux DirectX 12. Sur les titres DirectX 11, les développeurs ont constaté des baisses de performances, ce qui fait que le mécanisme est activé automatiquement pour DX12 et désactivé pour DX11. Il est aussi possible de forcer son activation ou sa désactivation via un réglage dans la configuration DRI.

C'est le genre de petite avancée qui, mise bout à bout avec les autres, finit par rendre les GPU Intel Arc de plus en plus viables sous Linux pour le jeu. Cinq ans pour un patch, c'est long, mais le résultat est là. Et puis ça montre aussi que l'approche open source d'Intel sur ses pilotes graphiques continue de porter ses fruits, même si le chemin est quand même un peu plus lent que chez NVIDIA ou AMD.

Source : Phoronix

Europol vient de coordonner un coup de filet massif contre le dark web. En dix jours, 23 pays ont fermé plus de 373 000 sites frauduleux qui proposaient des contenus pédocriminels.

Le plus ironique : l'opérateur n'a jamais livré la moindre donnée, il arnaquait ses propres clients. Et ces clients sont désormais dans le viseur de la police.

Une opération dans 23 pays

L'opération Alice a été lancée le 9 mars et a duré dix jours. Sous la direction des autorités allemandes et avec le soutien d'Europol, des policiers de 23 pays ont participé à ce coup de filet, de la France aux États-Unis en passant par la Suisse, l'Australie et le Royaume-Uni.

L'enquête avait démarré en 2021 autour d'une plateforme baptisée "Alice with Violence CP", qui proposait des contenus pédocriminels à la vente sur le dark web. Au total, 105 serveurs ont été saisis, tous hébergés en Allemagne, et l'opérateur a été identifié : un homme de 35 ans basé en Chine, visé par un mandat d'arrêt international.

L'arnaqueur arnaqué

Le détail qui rend cette affaire si particulière : le suspect n'a jamais livré les contenus qu'il vendait. Il gérait environ 90 000 sites sur le réseau Tor qui proposaient des "packs" de 17 à 215 euros, payables en Bitcoin. Les acheteurs recevaient en échange... rien du tout.

En cinq ans d'activité, il a encaissé 345 000 euros auprès de 10 000 clients qui pensaient acheter des contenus pédocriminels. Un escroc qui arnaque des criminels, en somme.

440 suspects identifiés

Sauf que ces clients, même s'ils n'ont rien reçu, ont quand même tenté d'acheter des contenus illégaux. Europol a donc remonté les paiements en cryptomonnaies et identifié 440 personnes à travers le monde.

Plus de 100 d'entre elles font l'objet d'enquêtes actives. En Suisse, cinq personnes ont été placées en détention. En Allemagne, 14 suspects sont visés par des procédures. La France a mobilisé l'Office de protection des mineurs pour sa part de l'enquête.

On a quand même un type qui a monté 373 000 faux sites depuis la Chine et qui a encaissé 345 000 euros en arnaquant des gens qui voulaient acheter les pires contenus imaginables. Et grâce à lui, la police a maintenant une liste de 440 noms.

Source : Techspot

James Gullberg a mis en ligne un projet de bras robotique à 6 axes, principalement imprimé en 3D et conçu pour apprendre la robotique. Ce petit robot embarque un Raspberry Pi, des microcontrôleurs STM32 et tourne sous ROS 2.

Le tout pour un budget qui reste accessible, avec des mouvements décrits comme étonnamment fluides pour du fait maison.

Un bras robot signé James Gullberg

James Gullberg a publié sur son site un projet qui risque de plaire aux bricoleurs : un bras robotique compact à 6 degrés de liberté, dont la structure est quasi intégralement imprimée en 3D. Seuls les systèmes d'entraînement font appel à des pièces métalliques.

Le projet est pensé comme un outil pédagogique. On n'est pas sur un robot industriel, mais sur une plateforme d'expérimentation qui permet de toucher à la conception mécanique, à la planification de mouvement et au contrôle logiciel.

Six axes, un Raspberry Pi et ROS 2 sous le capot

Côté mécanique, chaque articulation a droit à son propre système de réduction. La base utilise un réducteur planétaire classique, tandis que l'épaule et le coude embarquent des réducteurs planétaires à anneau fendu, qui offrent une densité de couple élevée par rapport à leur encombrement.

Le poignet s'appuie sur un différentiel à courroie inversé. Pour le retour de position, des aimants alternés sont intégrés directement dans la couronne de sortie et suivis par un encodeur magnétique.

Un microcontrôleur STM32 gère le contrôle moteur avec des boucles PID et de la génération de pas. Un Raspberry Pi fait office d'ordinateur de bord et communique avec les moteurs via un bus CAN. Le tout tourne sous ROS 2.

Le résultat est visiblement assez bluffant : les vidéos montrent des mouvements fluides, bien loin de ce qu'on pourrait attendre d'un projet fait maison.

Apprendre la robotique sans se ruiner

Ce projet rejoint une vague de bras robotiques open source accessibles. On pense au Thor, au HELENE ou encore au BCN3D Moveo. Mais celui de Gullberg se distingue par la variété des mécanismes employés. Chaque articulation utilise un design différent, et c'est voulu : le but est d'expérimenter, pas de produire en série.

Côté budget, on ne connaît pas le coût exact, mais les composants restent a priori sur des montants franchement raisonnables, puisqu'on parle là d'un simple STM32, d'un modeste un Raspberry Pi, e quelques moteurs et bien évidemment du filament pour imprimante 3D. Bref, on est loin des prix d'un kit de robotique du commerce.

Ce mini bras robotique coche quand même beaucoup de cases. Il est ouvert, documenté, modulaire, et il permet de toucher à des concepts qui coûtent habituellement une fortune en formation.

Source : JCGullberg

Un développeur a réussi à porter MS-DOS 2.0 sur l'Apple IIe, l'ordinateur personnel d'Apple sorti en 1983. Le projet, baptisé "reboot-camp-83", repose sur une carte d'extension qui embarque un processeur Intel 8088 à 8 MHz.

Le tout communique avec le processeur 6502 de l'Apple II, et le code est en accès libre. Quarante ans de retard, mais le geste est là, et il est plutôt classe.

Un processeur Intel dans un Apple II

Seth Kushniryk vient de publier "reboot-camp-83", un projet open source qui permet de faire tourner des applications MS-DOS 2.0 sur un Apple IIe. Pour que ça fonctionne, il faut une carte d'extension AD8088, fabriquée à l'époque par ALF Products.

Cette carte contient un processeur Intel 8088 qui tourne à 8 MHz et qui se branche sur le bus d'extension de l'Apple II. On se retrouve avec deux processeurs dans la même machine : le 6502 d'Apple et le 8088 d'Intel.

La chaîne YouTube Electron Impressions a placé une dionée attrape-mouche dans un accélérateur de particules pour voir ce qui allait se passer.

Résultat : toutes les mâchoires de la plante se sont refermées en même temps sous l'effet de la radiation ionisante. La plante a confondu le faisceau de particules avec une proie.

Comment la dionée attrape ses proies

La dionée attrape-mouche fonctionne grâce à un mécanisme assez fascinant. Ses mâchoires sont tapissées de petits poils sensibles qui détectent le contact d'un insecte. Quand un poil est touché, il active des canaux à calcium dans les cellules de la plante.

Un développeur a mis au point un système de détection de drones qui tient dans la main et coûte moins de 15 dollars.

Le projet Batear utilise un microcontrôleur ESP32-S3 et un micro pour repérer les drones par le son de leurs hélices. Le tout est open source et fonctionne sans connexion internet.

Écouter les hélices plutôt que chercher un radar

Le principe de Batear est assez simple en fait. Plutôt que d'utiliser un radar ou une caméra, le système analyse le son ambiant pour y détecter les fréquences caractéristiques des moteurs de drones.

L'algorithme de Goertzel surveille six fréquences précises entre 200 et 4000 Hz, qui correspondent aux harmoniques habituelles des rotors.

Le Z80 de Zilog, le processeur qui a fait tourner le ZX Spectrum, le Game Boy et des dizaines de micro-ordinateurs des années 80, a été arrêté en juin 2024 après 48 ans de bons et loyaux services.

Un bricoleur a créé le PicoZ80 , une petite carte qui se glisse directement dans le même support et qui émule le processeur original grâce à une puce Raspberry Pi.

48 ans de service, et puis s'en va

Le Zilog Z80 a été lancé en 1976 et il a alimenté une bonne partie de l'histoire de l'informatique personnelle. ZX Spectrum, MSX, Amstrad CPC, Game Boy, calculatrices Texas Instruments : la liste des machines qui ont tourné avec ce processeur 8 bits est longue.

Zilog a annoncé sa fin de vie en avril 2024 et a cessé de prendre des commandes en juin de la même année. Les stocks de Z80 neufs en boîtier DIP-40 commencent donc à se raréfier, et c'est là que le PicoZ80 entre en jeu.

Un Raspberry Pi dans un boîtier DIP-40

Le PicoZ80, développé par le maker eaw, utilise un microcontrôleur RP2350B (la puce du Raspberry Pi Pico 2) monté sur un circuit imprimé au format DIP-40, avec le même brochage que le Z80 original. Un des deux coeurs Cortex-M33 à 150 MHz se charge d'émuler le Z80, pendant que le second gère l'accélération et les périphériques.

Les moteurs PIO du RP2350 prennent en charge les transactions de bus en temps réel, ce qui garantit un timing identique à celui du processeur d'origine. La carte embarque aussi 8 Mo de PSRAM, 16 Mo de flash pour stocker des images ROM, et un coprocesseur ESP32 qui ajoute le WiFi, le Bluetooth et un lecteur de carte SD.

Des machines classiques qui renaissent

Le PicoZ80 peut fonctionner comme un simple Z80 de remplacement, mais il propose aussi des "personas" de machines classiques. Des pilotes existent déjà pour le RC2014, le Sharp MZ-80A et le Sharp MZ-700, et d'autres sont en développement pour l'Amstrad PCW8256.

La carte fait aussi office d'expandeur mémoire, d'hôte USB et d'émulateur de disquette. Vous remplacez un processeur de 48 ans et vous gagnez au passage le WiFi et le stockage sans fil.

Bref, on parle quand même d'un projet qui ressuscite un processeur plus vieux que moi (de 1976) avec une puce à quelques euros. Pour les passionnés de rétro-informatique qui ont un vieux micro au fond du placard, c'est peut-être la meilleure nouvelle de l'année.

Source : Hackaday

Si vous êtes sous Windows 10 ou 11, vous avez forcément déjà ragé sur un truc tout bête. Genre redimensionner 50 photos d'un coup, renommer des fichiers en masse, ou juste organiser vos fenêtres proprement sur un écran ultra-large. Tout ça, Windows ne sait pas le faire nativement et c'est bien dommage ! Heureusement, c'est là que les PowerToys entrent en jeu... Si vous ne connaissez pas encore ça, sachez simplement qu'il s'agit d'un pack d'une trentaine d'utilitaires open source, maintenus par Microsoft eux-mêmes qui s'installent comme ceci dans un powershell lancé en admin :

winget install Microsoft.PowerToys -s winget

C'est gratuit, c'est dispo sur GitHub, et franchement, c'est à se demander pourquoi tout ça n'est pas intégré par défaut dans l'OS. C'est fou quand même !

Le premier truc qui change la vie, c'est FancyZones. Si vous avez un grand écran, le Snap Layout de Windows 11 c'est... limité. Avec FancyZones, vous créez vos propres zones de dépôt. Vous maintenez MAJ, vous glissez une fenêtre, hop, elle se cale exactement où vous voulez. Une fois qu'on y a goûté, impossible de revenir en arrière.

Autre indispensable c'est PowerToys Run. Tapez Alt + Espace et une barre de recherche épurée apparaît comme Spotlight sur Mac. Ça cherche vos applis, vos fichiers, ça fait calculatrice et conversion d'unités. Bref, vous pouvez oublier le menu Démarrer (et ses pubs).

Pour garder une fenêtre au premier plan quoi que vous fassiez, Win + Ctrl + T et c'est réglé. Always on Top, ça s'appelle et ça se matérialise sous la forme d'une bordure colorée qui apparaît pour vous montrer que la fenêtre est "clouée". Pratique quand vous suivez un tuto tout en tapant du code à côté.

Côté renommage de fichiers, PowerRename remplace avantageusement des outils comme Ant Renamer . Clic droit sur vos fichiers, search & replace avec support des regex pour les plus courageux. Du coup, fini le renommage un par un comme en 2003.

Y'a aussi Color Picker (Win + Maj + C) qui transforme votre curseur en pipette pour chopper n'importe quel code couleur à l'écran. Et Text Extractor (Win + Maj + T) qui fait de l'OCR instantané sur une zone de votre écran. Attention, ça marche pas toujours selon la police, mais ça évite de retaper du texte à la main.

Le plus dingue, c'est Crop and Lock. Vous faites Win + Ctrl + Maj + R et vous découpez une zone d'une appli pour en faire une fenêtre indépendante. Genre un graphique ou un flux d'infos. Sous le capot, ça crée une sorte de proxy visuel de la fenêtre originale, et vous pouvez même continuer à interagir dedans.

Et si vous avez deux PC côte à côte, Mouse Without Borders vous permet de les contrôler avec la même souris et le même clavier. Vous passez d'un écran à l'autre comme si c'était la même machine. Et d'ailleurs, si vous perdez votre curseur sur vos écrans géants, y'a aussi un utilitaire ici pour retrouver sa souris facilement.

Après j'ai pas tout listé. Y'a par exemple un éditeur de variables d'environnement hyper fastoche à utiliser, un aperçu du registre (pour éviter les bêtises), une fonction "Command Not Found" pour vous aider dans le terminal, un redimensionneur d'images intégré au clic droit...etc. Bref, à vous de fouiller mais ce que je retiens c'est que Microsoft a mis 30 ans à admettre que son OS avait des manques, et au lieu d'y répondre au cœur de Windows, ils ont fait ce side project devenu indispensable.

Et pour ceux qui veulent gérer leurs installs avec une interface graphique, allez voir WingetUI . C'est le complément parfait.

Voilà. Installez ça et remerciez-moi plus tard !

"Une requête ChatGPT consomme 10 fois plus d'énergie qu'une recherche Google."

Cette phrase, vous l'avez lue 100 fois. Mais est-ce vraiment vrai ?

Charles Duprat, chercheur en inclusion numérique, vient de publier un papier qui retourne complètement ce chiffre. Et même si je suis incapable de vérifier la validité scientifique de tout ce qu'il avance, ça vaut le coup d'en parler.

Son argument de base est simple et pas con. En fait quand on compare l'énergie d'une requête IA vs une recherche Google, on ne regarde en fait que ce qui se passe côté serveur, plutôt que l'ensemble de la chaîne. Le GPU Nvidia qui mouline d'un côté, l'index Google qui répond de l'autre.

Sauf que dans la vraie vie, une recherche web sur votre iPhone ou votre Android, c'est clairement pas juste un serveur qui tourne ! C'est le téléchargement de plusieurs mégaoctets via la 4G, c'est du JavaScript et du CSS qui font chauffer le CPU de votre téléphone, c'est du temps d'écran, et surtout c'est des dizaines de scripts publicitaires et de trackers qui tournent en arrière-plan. Et rien de tout ça n'apparaît dans le bilan "officiel".

Du coup, le chercheur a modélisé la comparaison au niveau de la session utilisateur complète. Donc pas juste la requête serveur, mais tout le trajet : réseau mobile, rendu de page, pubs, temps passé à lire. Et là, les résultats sont contre-intuitifs car pour une tâche complexe sur mobile (genre comparer des pompes à chaleur et des chaudières gaz), une session LLM consommerait environ 5,4 fois moins d'énergie qu'une session de recherche web classique. Dans le pire des cas modélisé, l'avantage reste quand même de 1,6 fois.

Alors d'où ça vient ?

D'abord, la page web médiane sur mobile pèse 2,56 Mo. Oui, 2,56 Mo pour une seule page web sur Chrome ou Safari qui est ensuite transmise en 4G à 0,17 kWh/Go, et ça, ça coûte déjà plus en énergie réseau qu'une inférence LLM complète. Une réponse ChatGPT ou Claude, c'est environ 5 Ko de texte brut. Le ratio de transmission est de 500 pour 1 avant même de parler du reste. Quand on sait déjà que la consommation réelle des datacenters est un sujet à tiroirs, ça relativise pas mal.

Et puis y'a le boulet de la pub programmatique ! Des études (Khan et al., 2024) montrent que les bloqueurs de pub intégrés comme Brave réduisent la consommation électrique du terminal de 15 à 44%. En gros, quand vous naviguez sur un site d'actu classique, jusqu'à 41% de l'énergie de la session sert à charger et exécuter du JavaScript publicitaire. Hé bien le LLM court-circuite tout ça en vous filant une réponse texte directe.

Comme je vous le disais en intro, je suis totalement incapable de valider la méthodologie de cette étude... Allez savoir si les paramètres sont bien calibrés. Et c'est un working paper, donc pas encore relu par des pairs, avec des simulations plus nombreuses. L'auteur se base sur des chiffres publiés par Google pour Gemini (0,24 Wh par prompt, issu d'un papier arXiv), par Epoch AI pour ChatGPT (0,30 Wh), et par Sam Altman lui-même (0,34 Wh). Et comme ces chiffres viennent des constructeurs eux-mêmes, ça mérite qu'on garde un oeil critique.

Par contre, l'étude a aussi l'honnêteté de poser ses propres limites car l'avantage s'effondre pour les requêtes simples en Wi-Fi depuis votre PC ou Mac (quasi parité LLM <> Google). Et surtout, ça s'inverse violemment dès qu'on passe aux modèles de raisonnement type o3 ou Deep Think, qui consomment 30 à 700 fois plus qu'une inférence standard parce qu'ils génèrent des chaînes de pensée à rallonge.

Le paradoxe de Jevons est aussi mentionné : si l'IA est plus efficace par requête, les gens en feront forcément plus, donc la consommation globale augmentera quand même. Et la question des modèles éco-responsables reste elle aussi entière.

Mais bon, cette étude remet quand même en question un truc qu'on répète tous sans trop réfléchir. Comparer un serveur IA à un serveur Google, c'est oublier que la recherche web moderne, c'est devenu "recherche + publicité + réseau mobile + rendering JavaScript + temps d'attention". Et comme Google lui-même commence à coller de l'IA (les AI Overviews) en plus par-dessus ses résultats classiques, ça devient un joyeux bordel à mesurer...

Bref, lisez l'étude vous-mêmes , c'est en accès libre. Et faites-vous votre propre avis !

Un développeur vietnamien a trouvé le moyen de faire fonctionner du code Arduino sur un microcontrôleur 8051, une architecture conçue par Intel en 1980.

L'astuce repose sur un émulateur RISC-V intégré directement dans la puce, et le tout est disponible en open source sur GitHub.

Une puce de 45 ans qui refuse de mourir

Le 8051, c'est un microcontrôleur 8 bits qu'Intel a conçu en 1980. L'anecdote veut que son architecture ait été dessinée en un week-end par l'ingénieur John Wharton.

Depuis, Intel a vendu plus de 100 millions d'unités rien que sur la première décennie, et des variantes compatibles sont encore produites et utilisées un peu partout, des souris d'ordinateur aux puces Bluetooth.

La version ciblée ici, c'est le STC8H8K64U, un dérivé moderne fabriqué par le chinois STC Micro. Il coûte moins d'un dollar et reste populaire en Asie, mais les outils de développement modernes ne le prennent pas en charge. D'où l'idée du projet.

Un émulateur RISC-V dans un 8051

Bùi Trịnh Thế Viên n'a pas cherché à porter le compilateur Arduino directement sur l'architecture 8051, ce qui aurait été un chantier monstre.

Il a opté pour une approche détournée : intégrer un émulateur RISC-V (appelé rv51, écrit en assembleur 8051 par un autre développeur, cyrozap) dans la puce STC8. Le code Arduino est compilé pour RISC-V, puis exécuté via cet émulateur.

Le projet est disponible sur GitHub sous le nom STC_Arduino_Core.

Des limites assumées

L'émulation a un coût. L'émulateur consomme 8 Ko de mémoire flash sur la puce, et la vitesse d'exécution est divisée par 100 à 1 000 par rapport au code natif. Pour le code qui demande du temps réel, comme la gestion des interruptions, il faut repasser sur de l'assembleur 8051 classique.

Et puis il faut le dire, des microcontrôleurs RISC-V natifs existent et coûtent à peine plus cher. Le projet reste donc un exercice technique et pédagogique, pas une solution de production.

C'est le genre de bidouille qui fait sourire. Faire tourner du code Arduino sur une architecture de 1980 via un émulateur RISC-V coincé dans 8 Ko, il fallait quand même y penser.

Bon par contre, on ne va pas se raconter d'histoires, en pratique ça n'a pas beaucoup d'intérêt face à un vrai microcontrôleur RISC-V à 2 euros. Mais l'exercice a le mérite de prouver que le 8051 a encore de la ressource, 45 ans après sa création.

Source : Hackaday

« Can it run DOOM ? » Vous connaissez tous la question je pense. En effet, depuis 1993, le FPS d'id Software a tourné sur à peu près tout ce qui contient un processeur, des calculatrices aux écouteurs en passant par des tests de grossesse. Et là, Adam Rice vient de pousser le délire encore plus loin en stockant et en lançant le jeu entier... via des enregistrements DNS.

Oui, ce bon vieux protocole de plus de 40 ans, conçu à la base pour traduire des noms de domaine en adresses IP (RFC 1035, tout ça). En fait, la magie tient dans le fait que les enregistrements TXT n'ont aucune validation de contenu. Du coup, rien n'empêche d'y coller du texte arbitraire... genre un FPS complet converti en texte via base64. En gros, le DNS devient un stockage clé-valeur distribué mondialement et mis en cache un peu partout. Pas mal comme CDN du pauvre !

Le fichier WAD (les niveaux et assets du jeu, 4 Mo) passe à 1,7 Mo après compression, les DLLs du moteur de 4,4 Mo à 1,2 Mo, et le tout est découpé en 1 966 enregistrements TXT sur une seule zone CloudFlare Pro. Un record spécial contient également les métadonnées de réassemblage (nombre de chunks, hash de vérification).

Ensuite, côté joueur, un script PowerShell de 250 lignes résout les 2 000 requêtes, reconstruit le binaire en mémoire et hop, ça tourne. Les données du jeu ne touchent ainsi jamais le disque, puisque tout reste en mémoire. Le tout chargé en 10 à 20 secondes (PowerShell 7 requis) !

Le truc rigolo, c'est que l'auteur ne connaît pas le C#. C'est Claude (oui, encore cette fichue IA, ahaha) qui s'est tapé le portage en modifiant managed-doom, un port C# du moteur original, pour remplacer les lectures fichier par des flux mémoire et virer toutes les dépendances natives au profit d'appels Win32 directs. L'audio a été sacrifié pour réduire le nombre de records mais bon, on va pas chipoter. Après si vous voulez tester, sachez que ça ne fonctionne que sous Windows car ça repose sur PowerShell, donc pas de version Linux pour l'instant.

D'ailleurs, si le concept vous rappelle quelque chose, c'est normal. Planquer des données dans les enregistrements TXT, c'est en fait une technique bien connue en sécu. J'en parlais déjà avec DNSteal pour exfiltrer des fichiers via DNS , ou avec ces malwares carrément stockés dans les records DNS . Adam Rice le dit lui-même, son projet est parti de l'exploration de techniques d'implants (staging de shellcode via TXT records) sauf qu'au lieu de planquer un trojan, il y a planqué ce FPS de +33 ans. C'est quand même plus sympa !

À vrai dire, avant d'en arriver là, il a d'abord fait un proof of concept avec une image de canard (va savoir pourquoi). Encoder la photo en base64, découper en chunks, uploader via l'API CloudFlare, reconstruire de l'autre côté avec un hash identique et ça a marché du premier coup. Par contre pour la vidéo, oubliez, un MP4 de 1 Go ferait 670 000 enregistrements.

Voilà et tout ça pour 20 dollars par mois (le prix de la zone CloudFlare Pro). Donc si DOOM sur des écouteurs vous avait déjà fait sourire, attendez qu'un taré le fasse tourner avec que des paquets ICMP. Bah quoi ??

Bref, le code est dispo sur GitHub et le DNS a clairement pas fini de nous surprendre.

Source

Si vous avez reçu ma newsletter 3 fois ce lundi, non, vous n'êtes pas dans la Matrice, et non, je ne suis pas non plus devenu un affreux spammeur de viagra.

En fait, mon plugin WordPress a juste décidé de partir en freestyle. Pour ceux qui ne le savent pas, mes newsletters sont générées automatiquement puisque c'est un récap de tout ce qui a été publié dans la semaine. Je suis tout seul aux manettes, j'ai pas une armée de stagiaires pour rédiger ça à la main, et croyez-moi, c'est pas dans mon intérêt non plus de vous spammer, car chaque envoi me coûte des sous-sous.

Bref, j'ai (normalement) corrigé le tir en intégrant un système de verrou dans le plugin pour que ça ne se reproduise plus. Tout est artisanal ici, c'est du fait maison, et jusqu'à présent ça tournait nickel. Pas de bol. Ouin.

Un grand merci donc à tous ceux qui m'ont gentiment signalé le problème. Vous êtes au top ! J'ai quand même eu droit à un "Allez ciao KorbenGPT" d'une personne qui visiblement ne s'est pas remis de ce trauma que je lui ai infligé avec mon spam involontaire de ce matin. Bon vent l'ami et beaucoup de courage pour la suite ^^.

Pour les autres, les vrais, ceux qui sont encore là sachez que si vous n'êtes pas encore abonné à la newsletter, c'est par ici . Et promis, je ferais tout ce qui en mon pouvoir pour qu'à l'avenir, vous ne la receviez qu'une seule fois. ;)

Merci