Vous faites tourner des LLMs en local comme le gros fifou de Hipster IA que vous êtes et, Ô drame, la VRAM de votre ordinateur explose dès que le contexte dépasse 8000 pauvres malheureux tokens ?

Le problème c'est le KV cache les amis ! Le KV cache c'est ce truc qui stocke les clés et valeurs d'attention et qui grossit linéairement avec la longueur du prompt. C'est pour gérer ce problème que Google a annoncé sous la forme d'un whitepaper uniquement un algo qui compresse tout ça de 3,8 à 6,4 fois... et youpi pour nous, y'a un dev qui l'a déjà implémenté dans un fork de llama.cpp .

Concrètement ça donne :

llama-server -m model.gguf -ctk turbo3 -ctv turbo3 -fa on

Et vous venez de diviser la mémoire du cache par 4,6. Et voilà comment un énoooorme Command-R+ de 104 milliards de paramètres arrive à tourner à 128K tokens de contexte sur un MacBook M5 Max, avec un pic mémoire max de 74 Go.

Pour bien comprendre pourquoi c'est costaud, faut revenir au problème de base. En fait quand un LLM génère du texte, il stocke pour chaque token passé 2 vecteurs (la clé K et la valeur V) dans un cache. Plus le contexte est long, plus ce cache grossit. Et ça s'accumule vite... Par exemple, sur un Llama 70B avec 128K tokens de contexte, le KV cache en fp16 bouffe à lui seul plus de 40 Go de RAM. Du coup votre modèle Llama 3.1 ou Qwen3 rentre évidemment en mémoire, mais le cache, lui, fait tout déborder comme vous quand vous vous incrustez dans la mini piscine Intex des gosses.

Google a publié son papier TurboQuant fin mars et leur idée c'est de compresser ces vecteurs K et V en 3-4 bits au lieu de 16, sans ré-entraîner le modèle. En fait l'algorithme fait ça en deux étapes...

D'abord PolarQuant : on applique une rotation Walsh-Hadamard aux vecteurs pour "gaussianiser" leur distribution, genre transformer des données qui partent dans tous les sens en une forme bien ronde et prévisible.

Puis on convertit les coordonnées cartésiennes en coordonnées polaires, rayon + angle. Le rayon capture alors l'essentiel de l'information, et l'angle se compresse très bien parce que sa distribution est connue à l'avance.

Ensuite, deuxième étape, QJL (Quantized Johnson-Lindenstrauss) : Il s'agit d'un correcteur d'erreur à 1 bit qui élimine le biais résiduel, le tout sans overhead mémoire pour les constantes de quantification, contrairement aux méthodes classiques comme q4_0 ou q5_1 qui perdent 1-2 bits rien qu'en stockant leurs propres paramètres.

Et c'est là qu'intervient notre développeur de génie, TheTom, qui a pris ce document académique de Google et l'a transformé en code C avec des kernels Metal pour Apple Silicon et CUDA pour NVIDIA. Et c'est pas juste un portage bête et méchant puisqu'il a vraiment poussé les expériences bien au-delà du document original avec une couverture de tests de 100% et des benchmarks sur des modèles de 1.5 à 104 milliards de paramètres.

Et ses découvertes les plus intéressantes c'est justement ce qui n'est PAS dans le paper. Première trouvaille : la compression des valeurs V est gratuite. Compresser V à 2 bits sur Qwen, Llama, Mistral ou Command-R+ n'a aucun impact mesurable sur la qualité d'attention, tant que les clés K restent en q8_0.

Et cela a été confirmé sur Metal M5 Max 128 Go, CUDA RTX 4090 et RTX 3090 par plusieurs testeurs indépendants. C'est franchement contre-intuitif, mais cela veut dire que toute la dégradation de qualité vient de la compression des clés K, et pas de leurs valeurs. Du coup une config asymétrique (K en q8_0, V en turbo3) arrive à récupèrer des modèles où la compression symétrique échoue.

Deuxième trouvaille : les couches limites sont hypersensibles. Protéger les 2 premières et 2 dernières couches en q8_0 pendant qu'on compresse le reste en turbo2 permet de récupérer jusqu'à 91% de la perte de qualité. Et plus le modèle est gros, mieux ça marche. C'est seulement 15 lignes de code, et là encore, y'a aucun impact sur la vitesse.

Troisième trouvaille : Sparse V, un décodage du cache qui saute les positions V à faible poids d'attention permet de gagner environ 23% de vitesse de décodage à 32K tokens de contexte. Et zéro dégradation de la qualité.

Côté chiffres bruts, y'a 3 modes : turbo4 compresse 3.8x et le modèle répond quasi pareil qu'avant. turbo3 compresse 4.6x avec une perte de qualité à peine détectable. turbo2 pousse à 6.4x mais là faut l'utiliser malin (uniquement sur les valeurs V, pas les clés K).

Et dire que pour l'instant Google n'a toujours pas publié de code officiel (mais c'est prévu pour le second trimestre 2026)... Donc pour le moment, cette implémentation communautaire est le seul moyen de tester TurboQuant dans un fork llama.cpp. Ça tourne sur Apple Silicon M1 à M5, NVIDIA RTX 3080 Ti à 5090 et AMD 6800 XT / 9070 XT et visiblement, pas mal de monde a testé sur du matériel varié et les résultats sont au rendez-vous.

Donc voilà, si vous faites de l' inférence LLM locale et que la mémoire vous limite, c'est le moment de tester ça !

Le code source de Claude Code a fuité hier, et au-delà du buzz, y'a, je trouve, quelques leçons concrètes à tirer de tout ça.

Alors rassurez-vous, je vais pas vous balancer du code TypeScript à copier-coller (on n'est pas des cochons), ni des leçons de morale sur ce qu'on peut ou pas pousser sur un dépôt Git, mais plutôt vous lister des patterns d'architecture / bonnes pratiques que vous pouvez implémenter dès maintenant dans votre fichier settings.json via le système de hooks de Claude Code .

Je reste vague techniquement, volontairement pour 2 raisons. D'abord parce qu'il y a eu fuite de code, donc je peux pas poster du code propriétaire ici. Et ensuite parce que chaque projet / boite à outil qu'on se crée dans Claude Code ou ailleurs est différente, donc ce sera à vous (ou à Claude en fait) d'adapter chacune de ces bonnes pratiques.

Concrètement, tout passe par le fichier .claude/settings.json de votre projet (ou ~/.claude/settings.json pour du global). Dedans, vous déclarez des hooks, c'est-à-dire des scripts .cjs ou .sh qui se déclenchent automatiquement à des moments précis : avant qu'un outil s'exécute (PreToolUse), quand vous tapez un message (UserPromptSubmit), après un commit (PostToolUse), etc.

Le script reçoit du JSON en stdin, fait son boulot, et renvoie un code de sortie : 0 pour laisser passer, 2 pour bloquer. Pas besoin de l'API Claude, pas besoin de tokens, ça tourne en local sur votre machine. Hé bien tout ce que vous allez lire ci-dessous, ce sera à vous de l'implémenter dans des scripts de ce type.

Et le plus simple pour ça, c'est de donner les parties de mon article qui vous intéressent à votre propre Claude Code pour qu'il aille lui-même faire les scripts cjs / sh et les bons appels de hooks dans le settings.json. Pourquoi se prendre la tête ?

Et encore une fois, j'insiste, il s'agit de concepts d'ingénierie logicielle, et pas de code propriétaire appartenant à Anthropic.

La première bonne pratique c'est le circuit breaker ou disjoncteur en français...

En gros, quand vos scripts JavaScript appellent des APIs genre l'endpoint chat/completions d'OpenAI ou generateContent de Gemini, ça peut parfois ne pas répondre, parce que la vie quoi... ^^

Et malheureusement, quand cela arrive, votre code continue de marteler l'endpoint en boucle, ce qui fait que vous cramez des tokens pour rien. Le fix est pourtant très simple : Après 3 échecs consécutifs, on coupe, et on passe au fallback. Netflix avait popularisé ça avec leur librairie Hystrix y'a 10 ans, et c'est ce type de protection qu'on retrouve aujourd'hui dans Claude Code. Concrètement, c'est un module Node.js de 40 lignes avec un compteur et un état ouvert/fermé et comme ça, fini les retry storms !

Deuxième pattern : le scanner de secrets en pre-commit.

Un git commit qui embarque une clé API dans un .env, ça arrive trop souvent (demandez à Anthropic et leur fichier .map de 60 Mo ^^). Le hook PreToolUse permet heureusement d'intercepter chaque git commit AVANT exécution. Votre script parcourt alors les fichiers stagés via git diff --cached, cherche les patterns sk-ant-api, ghp_, AKIA, -----BEGIN RSA PRIVATE KEY----- et renvoie un exit 2 pour bloquer.

Perso, j'ai dans ma boite à outil IA, 18 regex dans un fichier .claude/hooks/secret-scanner.cjs qui couvrent Anthropic, OpenAI, AWS, GitHub, Slack, Stripe et les JWT. Par contre, attention aux faux positifs car un fichier contenant "sk-ant-api" dans un commentaire, ça bloquera tout. Ça m'est déjà arrivé et heureusement, l'IA est assez maligne pour comprendre d'où vient le blocage et éventuellement passer outre si ce n'est pas justifié.

Et troisième truc sympa : la détection de frustration.

En effet, un hook UserPromptSubmit se déclenche quand vous tapez un message de rageux. Ainsi, si votre prompt contient "putain", "ça marche pas" ou "wtf", le hook injecte via stdout un contexte qui dit à Claude d'aller droit au but. Comme ça, y'a plus de blabla et on part direct sur une solution concrète.

Et c'est pareil pour "continue" ou "finis" qui injecte "reprendre sans résumer" automatiquement. Franchement, c'est 30 lignes de JavaScript rikiki à mettre dans .claude/hooks/frustration-detector.cjs et ça change carrément la vie quand vous êtes en mode debug à 2h du mat avec un café dans la main gauche et un œil qui se ferme tout seul en tremblant !

Quatrième bonne pratique : les tags @[MODEL] dans vos skills.

Car vous le savez, certaines règles que vous avez mis en place existent uniquement à cause d'un biais du modèle actuel. Genre, Opus 4.6 qui colle ces putains de tirets cadratins (Unicode U+2014) partout. Du coup, ça oblige les gens à mettre dans leurs skills une règle du genre "0 em-dash". Sauf que le jour où Sonnet 5 ne les utilisera plus, cette règle ce sera du bruit inutile.

Alors en taguant @[OPUS-4.6] dans un commentaire HTML, vous pourrez ensuite faire facilement un grep -r "@\[OPUS" quand vous changez de modèle. C'est du tracking de dette technique pour le prompt engineering, quoi... et perso, je n'y avais pas pensé avant.

Cinquième pattern : les seuils numériques.

Votre "Fais des fonctions courtes" dans un CLAUDE.md, ça ne veut rien dire pour un agent et malheureusement, la plupart des gens écrivent encore "sois concis" ou "toi faire code propre" sans aucun chiffre alors qu'un "Max 50 lignes par fonction, couverture tests ≥ 80%, 0 warning ESLint" c'est vachement plus efficace car vérifiable par un script.

Enfin, dernier pattern : la consolidation mémoire.

Anthropic a mis en place un système nommé autoDream qui tourne pendant l'inactivité de Claude Code pour nettoyer la mémoire. Il vire les doublons, résout les contradictions, vérifie que les fichiers existent encore. Et même s'il ne le réclame pas parce qu'ils n'ont pas de bouche pour vous parler, vos CLAUDE.md de 200 lignes et vos JSON de 70 Ko ont besoin du même traitement ! Donc il faut que vous ajoutiez une phase genre "dream" en bash ou Node.js à la fin de vos workflows, comme ça, plutôt que de tout garder, le script scan le répertoire ~/.claude/, trie les entrées par date, et fusionne les doublons. C'est comme la consolidation pendant l'inactivité, mais en 5 secondes sur un Apple M4.

D'ailleurs, la communauté n'a pas perdu de temps. Un développeur a catalogué les 88 feature flags planqués dans le code, dont 54 qui compilent proprement (les autres dépendent de modules internes d'Anthropic). Et un autre a reconstitué 8 diagrammes d'architecture complets du pipeline : cycle de vie d'une requête, système de permissions, orchestration multi-agents... C'est la meilleure doc technique qui existe sur le fonctionnement interne de Claude Code, et elle ne vient pas d'Anthropic ^^

Architecture globale de Claude Code reconstituée par la communauté

Voilà et toutes ces pratiques, ça repose sur les 25 événements du système de hooks (PreToolUse, PostToolUse, UserPromptSubmit, Stop...) avec 3 types de handlers : command pour les scripts shell, prompt pour une évaluation LLM, et agent pour une vérification multi-étapes.

Après, si l'un de vos scripts plante comme une merde, le hook laissera passer des choses, donc pensez bien à tester chaque retour de script avec un echo '{}' | ./mon-hook.sh && echo $? avant de déployer.

Et voilà ! Je vous invite à lire mon article sur la fuite pour plus d'infos.

Et si je vous disais qu'on pouvait faire tourner Firefox dans un terminal ? Et pas un navigateur en mode texte, hein. Non, le véritable Firefox, avec ses onglets, les images, la totale... Hé oui c'est possible et que ça fonctionne via SSH, donc depuis un serveur distant. Bienvenue dans le futur (ou le passé, j'sais plus trop) !

Term.everything c'est un compositeur Wayland construit from scratch en Go qui, au lieu de balancer l'image sur votre écran, la convertit en caractères ANSI et l'affiche dans le terminal. Du coup, n'importe quelle app GUI Linux peut tourner là-dedans. Firefox, un gestionnaire de fichiers, un lecteur vidéo... et même Doom (parce que si ça peut pas faire tourner Doom, ça compte pas). Le binaire fait une poignée de Mo, c'est sous licence AGPL-3.0, et y'a zéro dépendance externe.

L'outil propose 2 modes d'affichage. Le mode basique qui convertit les pixels en blocs Unicode, et dont la qualité dépend du nombre de lignes et colonnes de votre terminal. Plus vous zoomez out (Ctrl+- sur Alacritty), plus c'est net... mais plus ça rame. Donc si votre terminal supporte le protocole image, genre Kitty ou iTerm2, l'autre mode, c'est du rendu pleine résolution et là non seulement c'est pas dégeu mais en plus ça marche bien !

Le truc vraiment dingue, c'est surtout le SSH parce que si vous avez un serveur Linux distant, vous vous connectez dessus en SSH, vous lancez term-everything firefox et hop, Firefox s'affiche dans votre terminal local. Pas de X11 forwarding relou à mettre en place ni de VNC / RDP zarbi.

Pour les admins sys qui gèrent des serveurs headless, c'est quand même sympa ! D'ailleurs si vous aimez les outils SSH bien pensés , celui-ci aussi va vous plaire.

Par contre, on est encore en bêta et certaines apps vont planter ou refuser de se lancer. C'est normal, c'est un compositeur Wayland complet écrit par un seul gars (chapeau l'artiste !). Ce n'est donc pas le genre de truc qu'on met en prod, mais pour du dépannage sur un serveur Debian distant ou juste pour la beauté du geste, ça envoie du pâté.

Le créateur de term.everything est d'ailleurs le même qui avait codé Fontemon , un jeu vidéo caché dans une police de caractères. On est donc clairement dans la catégorie "parce qu'on peut le faire et que c'est marrant".

Bref, si vous voulez épater vos collègues en lançant KDE dans un terminal par-dessus SSH, ou juste jouer à Doom dans tmux, c'est par là que ça se passe.

Amusez-vous bien et merci à Lorenper pour l'info !

Une coalition d'entreprises européennes vient de lancer Euro-Office, une suite bureautique open source qui ambitionne de concurrencer Microsoft 365. Le problème, c'est que le projet est un fork d'OnlyOffice, et ce dernier accuse Nextcloud et IONOS de violer sa licence.

Un projet présenté au Bundestag

Euro-Office a été dévoilé le 27 mars à Berlin, directement au Bundestag. Derrière le projet, on retrouve huit organisations européennes : IONOS, Nextcloud, Eurostack, XWiki, OpenProject, Soverin, Abilian et BTactic.

L'idée est de proposer une suite bureautique capable d'éditer documents, tableurs et présentations, avec une compatibilité Microsoft complète, le tout sous contrôle européen.

Plutôt que de repartir de zéro, la coalition a choisi de forker le code open source d'OnlyOffice, jugé plus moderne et performant dans un navigateur que les alternatives dérivées de LibreOffice. Une préversion est d'ailleurs déjà proposée sur GitHub, et la première version stable est annoncée pour cet été.

OnlyOffice accuse de violation de licence

Et voilà que ça se complique. Deux jours après l'annonce, OnlyOffice a publié un billet de blog accusant Nextcloud et IONOS de violer les conditions de sa licence AGPL v3.

Le reproche est précis : Euro-Office aurait supprimé toutes les références à la marque OnlyOffice, alors que la licence impose de conserver le logo et les attributions dans les travaux dérivés. Ces conditions supplémentaires ont été ajoutées en mai 2021 via la section 7 du fichier LICENSE.txt.

Côté Nextcloud, on se défend en affirmant que les forks font partie de l'ADN de l'open source. L'entreprise dit avoir consulté Bradley M. Kuhn, le créateur de la licence AGPL, qui soutiendrait leur position "à 100 %".

La Free Software Foundation serait aussi de leur côté. Nextcloud avance par ailleurs que la collaboration directe avec OnlyOffice était compliquée, la société étant basée en Russie.

La souveraineté numérique en toile de fond

Le timing n'est pas anodin. Partout en Europe, des administrations et des entreprises cherchent à réduire leur dépendance aux outils américains.

Euro-Office arrive avec un argument fort : une suite bureautique développée et hébergée en Europe, sans dépendance vis-à-vis d'acteurs non européens. C'est exactement ce que réclament plusieurs gouvernements depuis des années.

C'est quand même un drôle de démarrage pour un projet censé incarner la souveraineté numérique européenne. On lance une alternative à Microsoft en se basant sur le code d'une entreprise russe, et trois jours plus tard on se retrouve avec une accusation de violation de licence sur les bras.

Le fond du débat juridique est intéressant : est-ce qu'on peut forker un logiciel AGPL et retirer les mentions de la marque originale ?

Source : OnlyOffice.com

60 Mo de source maps (ces fichiers qui permettent de remonter du code minifié à l'original) ont été oubliés dans un paquet npm. Et voilà comment Anthropic a involontairement balancé en public le code source complet de Claude Code, son outil à 2.5 milliards de dollars de revenus annuels.

Alors qu'est-ce qui s'est passé exactement ?

Hé bien hier, la version 2.1.88 du package @anthropic-ai/claude-code sur le registre npm embarquait un fichier .map de 59.8 Mo. Un truc normalement réservé au debug interne, sauf que ce fichier .map contenait les pointeurs vers les 1 900 fichiers TypeScript originaux, en clair. Chaofan Shou, un développeur chez Solayer Labs, a alors repéré la boulette et l'a partagée sur X. Le temps qu'Anthropic réagisse, le code était déjà mirroré partout sur GitHub, avec 41 500+ forks en quelques heures. Autant dire que le dentifrice ne rentrera pas dans le tube !

Pour ma part, j'avais un petit dépôt à moi assez ancien avec quelques trucs relatifs à Claude Code, qui n'avait rien à voir avec tout ça, qui s'est même retrouvé striké... Ils ratissent large avec leur DMCA donc.

Et là, c'est la fête pour les curieux comme moi parce que les entrailles de l'outil révèlent pas mal de surprises. Côté architecture, on découvre environ 40 outils internes avec gestion de permissions, un moteur de requêtes de 46 000 lignes de TypeScript, un système multi-agents capable de spawner des essaims de sous-tâches en parallèle, et un pont de communication entre le terminal et votre éditeur VS Code ou JetBrains. Le tout tourne sur Bun (pas Node.js ^^) avec Ink pour l'interface terminal. Par contre, pas de tests unitaires visibles dans le dump.

Côté mémoire, c'est plutôt bien pensé puisqu'au lieu de tout stocker bêtement dans la fenêtre de contexte du modèle, l'outil utilise un fichier texte MEMORY.md ultra-léger (genre 150 caractères par entrée) qui sert d'index de pointeurs. Les vraies données, elles, sont distribuées dans des fichiers thématiques chargés à la demande, et les transcripts bruts ne sont jamais relus entièrement, mais juste fouillés à la recherche d'identifiants précis. L'agent traite en fait sa propre mémoire comme un "hint" ce qui le force à vérifier toujours le vrai code avant d'agir. En gros, il a une mémoire sceptique, et pour moi c'est clairement le truc le plus intéressant du dump.

Y'a aussi un truc qui s'appelle KAIROS (mentionné 150 fois dans le code) qui est un genre de mode daemon autonome. En fait, pendant que vous allez chercher votre café, l'agent tourne en arrière-plan et fait ce qu'ils appellent autoDream : il consolide sa mémoire dans des fichiers JSON, vire les contradictions et transforme les observations vagues en données structurées. Comme ça, quand vous revenez devant votre écran, le contexte est nettoyé.

Et puis le code balance aussi la roadmap interne d'Anthropic (bon courage au service comm ^^). On y trouve les noms de code des modèles... Capybara pour un variant de Claude 4.6, Fennec pour Opus 4.6, et un mystérieux Numbat qui n'est pas encore sorti. D'ailleurs, les commentaires internes révèlent que Capybara v8 a un taux de fausses affirmations qui tourne autour de 30%, ce qui est une grosse régression par rapport aux 17% de la v4. Y'a même un "Undercover Mode" qui permet à l'agent de contribuer à des repos publics sans révéler d'infos internes (c'est sympa pour les projets open source).

Anthropic a confirmé la fuite : "C'était un problème de packaging lié à une erreur humaine, pas une faille de sécurité. Aucune donnée client n'a été exposée." Mouais, attention quand même, parce que le code est déjà partout et n'en repartira pas. Et même si aucun secret client n'a fuité, exposer l'architecture complète d'un agent IA à 2.5 milliards de revenus, c'est pas rien non plus.

Bon, et maintenant qu'est-ce qu'on peut en faire ? Bah pas mal de choses en fait.

Par exemple, le système de mémoire auto-correcteur est un pattern directement réutilisable pour vos propres agents IA. L'architecture "index léger + fichiers à la demande" résout élégamment le problème de la pollution de contexte qui fait halluciner les LLM sur les longues sessions. Les +40 outils internes permettent aussi de comprendre comment structurer un système de permissions granulaires dans un agent autonome . Et le concept KAIROS/autoDream, la consolidation mémoire pendant l'idle, c'est une idée qu'aucun outil open source n'implémente encore. Autant dire que les alternatives open source à Claude Code ou Codex vont monter en gamme dans les jours qui viennent. Et le code est déjà nettoyé, réécris en Rust et mis sur GitHub si vous voulez fouiller. Bon, pas sûr que le pattern autoDream soit simple à reimplémenter, mais le système de mémoire oui.

Je trouve ça assez marrant que le code proprio d'une boite qui a aspiré tout l'open source du monde voire plus, sans autorisation, pour le revendre sous la forme de temps machine / tokens, devienne lui aussi en quelque sorte "open source" sans qu'on leur demande leur avis ^^. La vie est bien faite.

Maintenant, pour les développeurs qui publient sur npm, la leçon est limpide : Vérifiez votre .npmignore et votre champ files dans package.json. Ou plutôt, lancez la commande npm pack --dry-run dans votre terminal avant chaque publish. Ça prend 2 secondes et ça vous montre exactement ce qui sera inclus dans le paquet. Ça aurait évité 60 Mo de secrets industriels qui partent en public.

Bref, un .npmignore bien configuré, ça coûte 0 euro. Alors qu'une fuite de propriété intellectuelle évaluée à 2.5 milliards... un peu plus !

Source

La bibliothèque JavaScript Axios, téléchargée plus de 100 millions de fois par semaine, a été compromise. Un attaquant a détourné le compte du mainteneur principal pour y glisser un malware multiplateforme qui vise aussi bien macOS que Windows et Linux.

Un compte piraté, deux versions vérolées

Tout est parti du compte npm de jasonsaayman, le mainteneur principal d'Axios. L'attaquant a réussi à prendre le contrôle du compte, a changé l'adresse mail vers un ProtonMail anonyme, et a publié deux versions malveillantes : axios 1.14.1 et axios 0.30.4.

Les deux ont été mises en ligne en l'espace de 39 minutes, et pas via le processus habituel. Au lieu de passer par GitHub Actions, le pipeline d'intégration continue du projet, les paquets ont été poussés directement avec la ligne de commande npm. Un détail qui aurait pu alerter plus tôt, mais qui est passé entre les mailles du filet pendant deux à trois heures avant que npm ne retire les versions concernées.

Un malware bien préparé, avec auto-destruction

Le plus vicieux dans l'affaire, c'est la méthode. Plutôt que de modifier directement le code d'Axios, l'attaquant a ajouté une dépendance fantôme appelée plain-crypto-js. Elle n'est jamais importée dans le code source, son seul rôle est d'exécuter un script d'installation qui fonctionne comme un programme d'installation de malware. 

Ce qui veut dire que dès que vous faites un npm install, le script contacte un serveur de commande en moins de deux secondes et télécharge un programme malveillant adapté à votre système : un daemon déguisé sur macOS, un script PowerShell sur Windows, une porte dérobée en Python sur Linux. Et une fois le malware déployé, le script se supprime, remplace son propre fichier de configuration par une version propre, et fait comme si de rien n'était. Même un npm list affiche alors un numéro de version différent pour brouiller les pistes.

Une attaque attribuée à la Corée du Nord

StepSecurity et Socket.dev ont été les premiers à repérer la compromission. Selon Ashish Kurmi, CTO de StepSecurity, ce n'est pas du tout une attaque opportuniste. La dépendance malveillante avait été préparée 18 heures à l'avance, trois programmes malveillants différents étaient prêts pour trois systèmes d'exploitation, et les deux branches de publication ont été touchées en moins de 40 minutes.

Elastic a de son côté relevé que le binaire macOS présente des similitudes avec WAVESHAPER, une porte dérobée en C++ déjà documentée par Mandiant et attribué à un acteur nord-coréen identifié sous le nom UNC1069. Pour les chercheurs en sécurité, le message est clair : si vous avez installé axios 1.14.1 ou axios 0.30.4, considérez votre machine comme compromise. Il faut supprimer la dépendance, faire tourner les identifiants, et dans certains cas, réinstaller la machine.

Franchement, c'est le genre d'attaque qui fait froid dans le dos. Axios, c'est une brique de base pour à peu près tous les projets JavaScript qui font des appels réseau. Et là, en deux heures, un attaquant a réussi à transformer cette brique en porte d'entrée pour un cheval de Troie, y compris sur Mac.

Le plus déroutant, c'est que le système de publication npm permet encore de pousser un paquet manuellement sans que personne ne bronche. Bon par contre, il faut reconnaître que StepSecurity et Socket.dev ont fait du bon boulot en détectant le problème aussi vite.

Sans eux, la fenêtre d'exposition aurait pu être bien plus large, c'est faramineux quand on y pense. Et quand on sait que la piste nord-coréenne revient de plus en plus souvent dans ce genre d'opérations, on se dit que la sécurité de la chaîne logicielle mérite qu'on s'y intéresse de près.

Source : The Register

Vous vous souvenez de cette proposition de loi pour interdire les réseaux sociaux aux moins de 15 ans ? Le Sénat l'a adoptée en première lecture il y a quelques jours, avec un système à deux niveaux. D'abord une liste noire de plateformes jugées nocives d'un côté, et de l'autre, un accès conditionnel avec accord parental.

Sauf qu'un amendement déposé la semaine dernière par le sénateur Bernard Lotte (LR) propose d'étendre cette logique aux... plus de 50 ans. Ouais, vous avez bien lu ! L'amendement n°104-AP, intitulé "Protection des publics vulnérables face aux manipulations numériques", s'appuie sur les conclusions du comité d'évaluation et leur constat est sans appel : les seniors seraient les premiers relayeurs de fausses informations sur Facebook et WhatsApp, biiiien loin devant les ados.
67% des partages de fake news sur Facebook en France viendraient des plus de 55 ans, d'après le rapport. Le reste se répartit ensuite entre X, Instagram et Telegram.

Du coup, le texte prévoit une "évaluation des compétences numériques" obligatoire dès 50 ans pour conserver son accès aux plateformes sociales. Concrètement, c'est un QCM de 40 questions, renouvelable tous les deux ans, administré en préfecture. Parmi les questions qui ont fuité : "Votre neveu vous envoie un lien DHL pour récupérer un colis, que faites-vous ?" et "Un prince nigérian vous propose un héritage de 4,5 millions d'euros, quelle est votre réponse ?". Spoiler : "je clique" n'est pas la bonne réponse.

38% des seniors interrogés ont d'ailleurs répondu oui au prince nigérian lors du test pilote à Limoges. La ministre du Numérique Anne Le Hénanff a qualifié l'amendement de "disproportionné" (sans blague). Par contre, elle a quand même lâché que "la vulnérabilité numérique des seniors est un vrai sujet de société"... va savoir ce que ça veut dire. Le texte prévoit aussi un "Permis Internet Senior", formation obligatoire de 12 heures en préfecture. Au programme : "Identifier les chaînes WhatsApp toxiques" et "Pourquoi il ne faut jamais partager les publications qui commencent par ATTENTION URGENT PARTAGEZ". C'est assez dingue.

Tenez, et le meilleur pour la fin ! Les exceptions !

Car oui, les seniors justifiant d'une activité pro nécessitant l'usage des réseaux sociaux pourraient obtenir une dérogation temporaire, renouvelable tous les 6 mois sur présentation d'un justificatif LinkedIn et d'un certificat Pix. Idem pour les grands-parents qui "produisent du contenu éducatif à destination de leurs petits-enfants" (en gros, vos photos de potager sur Instagram doivent avoir un objectif pédagogique clairement identifié). Et les élus de plus de 50 ans ? Exemptés, évidemment. Faut bien qu'ils continuent à poster leurs selfies devant les inaugurations de ronds-points.

Attention par contre, côté sanctions, ça ne rigole pas non plus ! Les plateformes qui ne vérifieraient pas l'âge de leurs utilisateurs seniors risquent une amende pouvant aller jusqu'à 1% de leur chiffre d'affaires mondial. Donc pour Meta, on parle d'environ 1,3 milliard d'euros. Et les contrevenants, eux, seraient condamnés à 20 heures de travaux d'intérêt numérique. Comprenez : aider les djeuns à configurer leur imprimante Brother, installer LibreOffice sur le PC du voisin, et expliquer pourquoi le WiFi de la Livebox plante après chaque mise à jour. Plutôt que de la prison, quoi... Faut reconnaître que c'est créatif.

Bref, le prochain débat en commission est prévu tout début avril. D'ici là, si vous avez plus de 50 ans, profitez bien de vos réseaux car après, faudra vous trouver des occupations, comme aller à la pêche pour attraper des petits poissons.

Source

Denuvo, la célèbre protection anti-piratage qui emmerde les joueurs PC depuis une décennie, traverse une sale période. Depuis début 2026, des pirates contournent la protection via des hyperviseurs, et les jeux protégés tombent désormais en quelques heures au lieu de plusieurs semaines : Resident Evil Requiem, Crimson Desert, Life is Strange: Reunion... tous craqués le jour de leur sortie ! Même Assassin's Creed Shadows, qui avait tenu 11 mois, a fini par tomber.

En fait, ces crackers ne s'embêtent plus à faire du reverse engineering sur les protections de Denuvo, ce qui leur prenait des mois. Ils ont monté un truc qui attaque sur 5 couches, du UEFI (Ring -2) jusqu'au processus du jeu (Ring 3). Un bootkit open source appelé EfiGuard désactive les protections au démarrage, puis un hyperviseur (SimpleSvm sur AMD, hyperkd sur Intel) prend le contrôle en Ring -1, sous le système d'exploitation. De là, il intercepte les CPUID, falsifie les structures mémoire Windows et triche sur les timings CPU pour que Denuvo croie que tout est normal. Un audit de sécurité indépendant publié sur GitHub n'a certes trouvé aucun malware dans le package, mais prévient que le système est laissé sans protection le temps que l'hyperviseur tourne.

Pour que ça fonctionne, il faut bien sûr désactiver des protections Windows assez critiques comme le VBS (Virtualization-Based Security), le HVCI (Hypervisor-Enforced Code Integrity) et la vérification de signature des driver, ce qui ouvre un peu trop grand le système, qui pourrait alors se voir installer un rootkit ou autre malware...

Et côté matériel, c'est la loterie car ça tourne plutôt bien sur AMD, mais les processeurs Intel posent des soucis de stabilité qui nécessitent des bidouilles franchement dangereuses. FitGirl, la repackeuse la plus connue de la scène, avait même d'abord refusé de toucher à ces cracks en déclarant qu'"aucun jeu ne vaut les dommages potentiels irrécupérables qu'il peut causer à l'ordinateur". Mais depuis, elle a changé d'avis après les améliorations apportées par KiriGiri et l'équipe MKDEV, et publie maintenant des repacks avec un tag "HYPERVISOR" bien visible. M'enfin bon, elle reste quand même prudente.

Irdeto, la boîte qui possède Denuvo, promet bien sûr une contre-mesure qui ne devrait pas ralentir les jeux. Les options sur la table sont : détecter la présence d'hyperviseurs tiers via les CPUID ou la latence CPU, ou imposer des vérifications de licence quotidiennes (ce qui emmerderait aussi les joueurs légitimes).

Et le pire dans tout ça, c'est que Denuvo a un impact mesurable sur les performances des jeux légitimes. Le blogueur Nathan Baggs et le développeur @valigo ont montré que la protection embarque une machine virtuelle qui compresse le code du jeu, bousille le cache processeur, perturbe le prédicteur de branchement et rajoute des instructions parasites. Cela veut dire concrètement que Ghostwire Tokyo mettait 200 secondes à démarrer avec Denuvo contre 54 sans, et Mass Effect Andromeda a gagné 12% de FPS quand la protection a été retirée.

Bref, c'est l'éternel jeu du chat et de la souris et Denuvo sait très qu'ils ne peuvent pas vaincre le piratage. Par contre, ils pouvaient jusqu'à présent maintenir une fenêtre de protection suffisante pour que les éditeurs récupèrent leur investissement sur les premières semaines de vente.

Mais avec ces bypasses hyperviseur, cette fenêtre vient de tomber à zéro. Gloups... Donc la vraie question maintenant, elle est surtout pour les joueurs légitimes : Est-ce que la prochaine "mise à jour de sécurité" de Denuvo va encore bouffer des performances sur leur machine pendant que les pirates jouent sans protection, sans ralentissement, et sans payer ?

On verra bien mais pour l'instant, la tendance des éditeurs c'est plutôt de lâcher les DRM car ils ont compris un truc que Denuvo refuse d'admettre : Avec ces conneries de DRM, ce sont toujours les clients honnêtes qui trinquent !

Source

Si vous êtes abonné Qobuz et que vous êtes sous Linux, vous connaissez cette douleur sourde qui vous coupe le souffle la nuit : IL N'Y A PAS DE CLIENT OFFICIEL ! Vous êtes donc condamné comme n'importe quel gueux à utiliser le lecteur web, qui est aussi "audiophile-phile" qu'un casque de chantier.

Mais heureusement, QBZ vient régler ça, et vous allez voir, c'est du sérieux !

Il s'agit d'un client natif et open source (sous licence MIT) écrit en Rust avec Tauri 2.0 côté desktop et SvelteKit pour l'interface, ce qui fait que c'est léger, que ça démarre vite, et surtout ça gère le bit-perfect via 4 backends audio au choix : PipeWire, ALSA, ALSA Direct (accès exclusif au DAC) et PulseAudio.

Le switching de sample rate se fait alors à la volée, de 44.1 à 192 kHz, selon ce que votre DAC supporte. Pour les audiophiles... bah ça change tout par rapport au resampling sauvage du navigateur. Ouf, on est sauvé en fait ^^

Côté fonctionnalités, c'est clairement loin du petit projet bricolé un dimanche soir en vibe coding puisque ce lecteur décode nativement FLAC, MP3, AAC, ALAC, WavPack, Ogg Vorbis et Opus, le tout avec du gapless playback et de la normalisation de loudness EBU R128. Je comprends pas tout parce que je suis pas expert là dedans, mais si vous aimez la Hi-Fi, je sais que ça vous parle.

Y'a aussi une gestion de bibliothèque locale avec scan de dossiers et indexation SQLite, et même un import de playlists depuis Spotify, Apple Music, Tidal ou Deezer. Ainsi, si vous migrez vers Qobuz, ça vous fera gagner des heures plutôt que de tout vous retaper à créer à la main !

Niveau intégrations, c'est aussi super complet : scrobbling Last.fm et ListenBrainz, enrichissement MusicBrainz, pochettes via Discogs, contrôle MPRIS et touches média. Et le casting vers Chromecast, DLNA/UPnP et AirPlay est intégré. Le Chromecast directement depuis un client Linux sans bidouille, c'est pas courant, et ça fait plaizzz !

L'interface est également hyper soignée avec 26 thèmes au choix (Dark, OLED, Nord, Dracula, Tokyo Night...) et 17 panneaux de visualisation dont un spectre, un oscilloscope et un spectrogramme. Y'a même un mode immersif plein écran, le tout dispo en 5 langues dont le français.

Pour l'installation, c'est packagé proprement : Flatpak, AUR, Snap, AppImage, DEB, RPM et même un DMG pour macOS (Apple Silicon, expérimental) et si vous êtes sur Arch, un petit yay -S qbz-bin et c'est réglé.

Par contre, il y a quelques limites à connaître comme le seeking sur des pistes hi-res au-dessus de 96 kHz qui peut prendre 10 à 20 secondes. ALSA Direct bloque aussi les autres applis audio (logique, c'est l'accès exclusif). Et le bit-perfect via PipeWire est limité quand on lance le tout en sandbox Flatpak. En fait, le problème c'est que la sandbox bloque l'accès direct au matériel donc si vous voulez le max de qualité, optez pour le paquet natif.

Si Qobuz est votre service de streaming et que Linux est votre OS préféré d'amour, les alternatives payantes comme Audirvana ou Roon ne sont clairement pas données. C'est pour cela que je vous parle de QBZ qui fait le boulot gratuitement comme un chef et dont le développeur (vicrodh) est super actif (il recherche des contributeurs si vous voulez l'aider).

Et un grand merci à Pierre pour le tuyau !

Vous vous souvenez de Civilization III ? Hé bien des fans ont décidé de le recréer de zéro en open source avec OpenCiv3 , et franchement ça a de la gueule, vous allez voir !

En fait, leur idée c'était pas juste de cloner le jeu de Sid Meier tel quel, mais plutôt de le réimaginer en corrigeant tous les trucs qui étaient cassés à l'époque, mais aussi en virant les limites arbitraires du moteur original et en poussant le modding aussi loin que possible. En gros, ils nous ont pondu un Civ3 comme il aurait dû être si les développeurs avaient eu le temps de tout finir.

Côté technique, c'est du Godot avec du C#, ça tourne sur Windows, Linux et Mac et c'est sous licence MIT. Du coup vous pouvez forker le truc et en faire votre propre version si ça vous chante.

Après, voilà, on est encore en pré-alpha. La version 0.3 "Dutch" est sortie en décembre dernier, et permet de lancer une partie, explorer la carte, créer des villes et taper sur vos voisins. Mais la fin du jeu n'est pas encore là. Et le truc sympa, c'est que contrairement à d'habitude, le jeu fonctionne en mode standalone avec des graphismes de remplacement, donc pas forcément besoin d'avoir Civ3 installé. Après si vous avez l'édition Conquests ou Complete qui traîne quelque part sur votre disque dur, OpenCiv3 est capable d'importer les graphismes originaux pour un rendu fidèle !

Mais comme vous l'avez compris, le vrai kiff du projet, c'est le modding. Le Civ3 original vous laissait modifier trois bricoles via des fichiers texte, et c'était pas ouf... Mais OpenCiv3, lui, veut ouvrir toutes les portes en changeant les règles de combat, en ajoutant des mécaniques de jeu, en créant des scénarios complets, voire en inventant de toutes pièces de nouvelles civilisations... bref tout est prévu pour être modifiable. Ça rappelle un peu ce qu' UnCiv fait avec Civ V sur Android , sauf que c'est sur PC.

Voilà, c'est encore super jeune mais si vous avez la nostalgie des soirées "encore un tour", ça vaut le coup de garder un œil dessus !

À découvrir ici : OpenCiv3

Un YouTubeur de la chaîne Usagi Electric vient d'installer un PDP-11 dans un bureau IKEA. Ce mini-ordinateur mythique de Digital Equipment Corporation, qui date des années 70, servait à piloter un spectromètre infrarouge en laboratoire. Plus de cinquante ans après sa fabrication, la machine tourne encore. Et c'est assez beau à voir.

Le PDP-11, un monument

Le PDP-11, c'est un gros morceau d'histoire informatique. Fabriqué par Digital Equipment Corporation à partir de 1970, ce mini-ordinateur 16 bits s'est vendu à environ 600 000 exemplaires dans le monde et a été décliné dans à peu près tous les formats possibles, du rack de laboratoire à la puce en passant par la station de bureau avec ses rangées de voyants clignotants.

Si vous avez déjà passé des heures sur Sandspiel, Orb.farm ou l'un de ces vieux jeux sandbox en Flash, ce site va bien bien vous replonger là-dedans... mais en mieux. Il s'agit de Sandboxels et c'est un simulateur de particules jouable directement dans le navigateur, avec plus de 500 éléments qui interagissent entre eux selon les lois de la physique (enfin, à peu près).

Le concept, c'est que vous choisissez un élément (eau, feu, sable, acide, TNT...), vous le placez sur une grille de pixels, et vous regardez ce qui se passe. Sauf que ça va beaucoup plus loin qu'un bête falling sand game des années 2000 puisqu'il y a de la simulation de chaleur qui se propage, de l'électricité pour créer des circuits fonctionnels, des réactions chimiques entre éléments, et même de la biologie avec des plantes, des insectes et des humains qui se baladent sur votre terrain. Du coup, on peut construire des écosystèmes entiers, des villes miniatures, ou juste tout faire péter au TNT. Chacun son kiff !

Le jeu est l'oeuvre de R74n et il vient de débarquer sur neal.fun , la plateforme de Neal Agarwal (le mec derrière Infinite Craft et The Password Game).

Et l'aspect le plus addictif, je trouve, ce sont les entités vivantes. Vous pouvez par exemple balancer des rats dans une ville que vous avez construite et regarder le bazar s'installer. Ou planter une forêt, y foutre le feu, et observer la propagation pixel par pixel. C'est un peu un god game version bac à sable pixelisé, où chaque grain de matière a son propre comportement. Par contre, attention sur les grosses scènes avec des milliers de particules, ça peut vite faire ramer votre vieux laptop.

Et si le navigateur ne vous suffit pas, le jeu est aussi dispo sur Steam à 0,99 € , parce que oui, ça existe en version desktop. Avec le Workshop pour partager vos créations, la sauvegarde dans le cloud, et même des cartes à collectionner.

Y'a aussi un support complet du modding, ce qui en fait un terrain de jeu quasi infini. Vous pouvez alors créer vos propres éléments, inventer vos propres réactions chimiques, et les partager avec la communauté. La dernière mise à jour a même ajouté des pushers, des affichages texte LCD, des humains qui nagent et qui traînent des objets... et plus d'une centaine de changements. Bref, ça bouge pas mal pour un projet indé !

Après, le problème avec ce genre de jeu, c'est que le côté "lâcher des trucs et voir ce qui se passe" est hyper addictif. C'est le genre de jeu où vous vous dites "allez, 5 minutes" et quand vous relevez la tête 2 heures plus tard avec un volcan en fusion au milieu d'un lac d'acide, c'est déjà l'heure de partir du taf... hahaha.

En tout cas, si vous aimez bidouiller, expérimenter et observer des réactions en chaîne, c'est exactement ce qu'il vous faut pour vous relaxer !

Le fichier national qui recense toutes les armes détenues en France vient de se faire trouer en version XXL !

En effet, un affreux pirate a réussi à exfiltrer les données liées à la possession de plus de 62 000 armes, et parmi elles, les noms, prénoms, dates de naissance, adresses email et surtout les adresses postales de leurs propriétaires. Mais ce n'est pas tout puisque le fichier contiendrait également le détail complet de chaque arme (modèle, calibre, numéro de série, classement) ainsi que l'historique des transactions (ventes, cessions, réparations, destructions).

Donc on a maintenant dans la nature un joli tableur Excel avec en colonne A le numéro de série de votre Beretta, et en colonne B votre adresse.

J'vois vraiment pas ce qui pourrait mal tourner... 🤡

Alors pour ceux qui débarquent, le SIA (Système d'Information sur les Armes) c'est LA base de données du ministère de l'Intérieur dans laquelle tous les détenteurs d'armes doivent obligatoirement s'enregistrer. Que vous soyez chasseur avec votre Browning, tireur sportif avec votre Glock ou que vous ayez hérité du vieux Manufrance de papy, vous êtes dedans !!

Le ministère a d'ailleurs confirmé l'intrusion dans un courrier envoyé aux personnes concernées (environ 41 000 détenteurs selon les dernières estimations).

En fait, le cybercriminel a compromis les identifiants d'un armurier situé dans le département 84 (c'est le Vaucluse pour les nuls en géo) et a accédé à son Livre de Police Numérique (LPN), le registre dématérialisé qui liste toutes les transactions d'armes du professionnel et qui est directement interconnecté avec le SIA.

Les identifiants de l'armurier auraient pu être récupérés via du phishing, un logiciel espion ou même le vol d'un ordinateur... bref, les classiques, et cerise sur le gâteau, le pirate affirme même avoir été interrompu en pleine exfiltration, ce qui veut dire qu'il aurait pu aspirer encore plus de données s'il n'avait pas été coupé dans son élan.

Le ministère se veut rassurant (lol) en précisant que "le système d'information sur les armes n'a pas été atteint" directement. Mouais... techniquement c'est vrai, c'est le compte pro de l'armurier qui a sauté et pas le SIA en lui-même. Mais en vrai le résultat est le même pour les gens dont l'adresse postale se balade maintenant sur un forum du dark web.

Côté butin, le pirate revendique pas moins d'un listing de 62 511 armes se composant de 46% de carabines, 29% de fusils de chasse, 11% de fusils à pompe et 8% d'armes de poing, le tout allant de la catégorie B (soumise à autorisation) à la catégorie C (sur déclaration).

L'Union Française des amateurs d'Armes (UFA) tempère en rappelant que la base contient plusieurs millions d'armes, et que ces chiffres "tendent à faire penser que la fuite ne concerne pas l'ensemble du système". Heureusement les gars ! Après 41 000 détenteurs avec leurs adresses et le numéro de série de leurs joujoux dans la nature, c'est quand même pas rien non plus.

Et surtout c'est pas la première fois. C'est même la troisième fuite liée au milieu des armes en 6 mois. En octobre 2025, la Fédération Française de Tir (FFTir) s'était déjà fait trouer, puis en janvier 2026 c'était au tour de la Fédération Nationale des Chasseurs (FNC), et maintenant le SIA. Le trio gagnant !!

Les conséquences avaient d'ailleurs été très concrètes après la fuite FFTir puisque la préfecture de police avait alerté sur des repérages et prises de renseignement suspects signalés aux forces de l'ordre, avec des cambrioleurs qui débarquaient chez des tireurs sportifs pour récupérer leurs armes.

Le ministère a déposé plainte et notifié la CNIL et recommande de changer régulièrement de mot de passe et ne jamais communiquer ses identifiants. Merciiiii on n'y avait pas pensé ! Mais le plus beau c'est la mesure d'urgence annoncée en réaction car à partir du 1er avril 2026 (oui, demain), tous les professionnels devront activer la double authentification pour accéder à leur compte SIA. Oui, y'en n'avait pas... un simple identifiant + mot de passe suffisait pour accéder à une base qui gère les données de millions de détenteurs d'armes en France. Ça laisse rêveur.

Après, si vous êtes inscrit au SIA et que vous n'avez pas reçu le courrier du ministère, ça ne veut pas forcément dire que vous n'êtes pas touché alors dans le doute, méfiez-vous de tout appel ou visite prétendument officielle vous demandant de remettre ou montrer vos armes car la police, la gendarmerie et les douanes ne viendront jamais chez vous récupérer vos armes suite à une fuite de données. Donc si quelqu'un sonne à votre porte avec ce prétexte, c'est forcément une arnaque (ou pire...) comme ça s'est passé après la fuite FFTir.

Bref, entre le pistage permanent de nos données en ligne et toutes ces bases gouvernementales qui fuient comme des passoires , j'imagine que la prochaine étape, ça sera le vol et la diffusion du fichier des codes nucléaires mis à dispo sur un forum de script kiddies...

Source

Vous pensiez que le hackintosh, c'était un truc des années 2000, quand Apple est passé sur Intel ? Raté les amis ! Hé oui, dès 1988, des bidouilleurs assemblaient des Mac-compatibles avec des pièces de PC, bien moins chères que le matos Apple officiel.

Et un youtubeur vient justement d'en recréer un de A à Z !

Le gars de la chaîne This Does Not Compute avait récupéré un Macintosh SE dont la carte mère originale avait été remplacée par un accélérateur CPU pour une autre vidéo. Du coup, comme la carte mère d'origine traînait dans un tiroir, il s'est dit que ce serait cool de s'en servir pour explorer la scène du clone Mac DIY de la fin des années 80.

Parce qu'à l'époque, un Macintosh SE neuf coûtait dans les 2 500 dollars. Et la carte mère avec son processeur Motorola 68000, c'était le seul composant vraiment indispensable pour faire tourner System 6. Tout le reste, boîtier, alimentation, lecteur de disquette, moniteur, pouvait venir de fournisseurs tiers. Des revues spécialisées publiaient carrément des guides pour construire sa propre machine compatible... Donc il fallait juste une carte mère Apple + des composants PC à trois francs six sous, et vous aviez un Mac fonctionnel pour une fraction du prix officiel !

Le youtubeur a donc repris ce concept... version 2026. Le boîtier est imprimé en 3D avec du PLA beige (obligatoire pour le look années 80, faut pas déconner). Côté modernisation, il a ajouté une carte de sortie VGA, un BlueScsi qui émule un disque dur SCSI avec une simple carte SD de 32 Go (parce que bonne chance pour trouver un disque SCSI 50 broches fonctionnel en 2026), et une alimentation compacte qui ne prend pas la moitié du boîtier. Le lecteur de disquette 3,5 pouces, par contre, est bien d'époque.

Sans oublier évidemment une carte mère Apple d'origine pour que ça fonctionne. Pas moyen de tricher avec un clone chinois, désolé ! Mais ça permet de garder l'âme du truc !

Votre manette qui drift comme dans Fast & Furious, votre clavier qui enfonce des touches fantômes, ou encore votre souris qui double-clique toute seule... Avant de tout balancer par la fenêtre parce que l'esprit malfaisant de papi est revenu hanter votre machine, sachez qu'il y'a peut-être moyen de diagnostiquer le problème facilement !

Comment ? Hé bien avec ControllerTest.io, qui est une suite de trois outils en ligne permettant de tester tout votre matos gaming directement dans le navigateur. C'est gratuit, sans pub et que vous ayez une manette Xbox, une DualSense, des Joy-Con ou un clavier mécanique de bobo à 150 balles, tout se gère depuis Chrome ou Edge sans rien télécharger. Suffit juste d'avoir un navigateur et un câble USB (ou une connexion Bluetooth).

Côté manette, le site détecte le drift des sticks en temps réel. Vous branchez votre pad en USB ou Bluetooth, ensuite vous appuyez sur un bouton, et l'écran affichera alors la position X/Y de vos sticks analogiques. Et si ça bouge alors que vous ne touchez à rien, c'est que c'est un souci de drift.

Y'a aussi un test de vibration avec quatre modes (heavy, light, burst, pulse) qui fait tourner les moteurs gauche et droit séparément. Le polling rate compare filaire vs Bluetooth, par exemple autour de 125 Hz en Bluetooth contre 500 Hz en USB sur une manette Xbox. Le mapping de tous les boutons et axes passe par l'API Gamepad de Chrome.

Pour les claviers, direction KeyboardTest.io . Le test de N-Key Rollover montre visuellement quelles touches sont en conflit quand vous appuyez sur plusieurs en même temps, ce qui est pas mal pour vérifier que votre clavier Cherry MX gère bien les combos en jeu ! Y'a aussi la détection de "chatter" qui se passe quand une touche s'enregistre deux fois d'affilée. C'est d'ailleurs souvent le signe d'un clavier fatigué.

Et pour la souris, MouseTester.io fait bien le boulot aussi. Polling rate en temps réel (le site affiche jusqu'à 8000 Hz, même si dans le navigateur c'est plus une estimation et pas une mesure de labo), détection de double-clic involontaire, et test CPS (test de clics par seconde). Par contre, attention, le test de polling rate ne marche pas toujours sur Firefox, et n'est pas forcément fiable non plus sur Safari, donc utilisez bien Chrome ou Edge pour vos tests. Et surtout ça tourne sur Windows, macOS et Linux sans problème, évidemment, vu que tout passe par le navigateur.

Le gros plus c'est que tout est traité localement dans le navigateur. Aucune donnée n'est envoyée à un serveur extérieur. Le JavaScript tourne en local via les API natives du navigateur, pas via un backend distant. Après y'a quand même une limitation qui est que les triggers adaptatifs de la DualSense ne sont pas supportés parce que l'API Gamepad standard ne le permet pas encore. C'est pas la faute du site, c'est juste le W3C qui traîne à faire évoluer la spec.

Si vous cherchez à tester spécifiquement votre manette, j'avais déjà parlé de Gamepad Tester mais ControllerTest.io va clairement plus loin avec la détection de drift, le polling rate et les tests de vibration séparés par moteur, donc autant passer à celui-là.

Voilà, la prochaine fois que votre gamepad fait des siennes, branchez le câble USB, ouvrez Chrome et allez sur ControllerTest.io . Comme ça, si c'est du drift, vous pouvez toujours tenter d'augmenter la deadzone dans les paramètres Steam ou dans les options du jeu avant de sortir la carte bleue !

Niels Leenheer a porté le mythique Doom de 1993 dans un navigateur web, mais sans WebGL ni Canvas. Tout le rendu 3D repose sur des div et des transformations CSS. Le résultat est jouable, open source, et un brin absurde. On adore.

Doom en div

Le principe est aussi fou qu'il en a l'air. Chaque mur, chaque sol, chaque tonneau et chaque ennemi est une balise div, positionnée dans l'espace 3D grâce aux transformations CSS. Le jeu lit les données du fichier WAD original de 1993, celui-là même qui contenait les niveaux du Doom d'id Software, et en extrait les coordonnées des murs, des secteurs et des textures.

La logique du jeu, elle, tourne en JavaScript. Mais côté affichage, c'est 100 % CSS : pas de Canvas, pas de WebGL, pas de bibliothèque graphique. Juste des div, des calculs trigonométriques en CSS et des propriétés personnalisées.

Pour simuler une caméra, le développeur a trouvé une astuce assez maline : plutôt que de déplacer le joueur dans la scène, c'est la scène entière qui bouge dans le sens inverse. Le CSS ne gère pas nativement la notion de caméra, du coup Leenheer a tout simplement inversé le problème.

Des fonctions CSS qu'on ne soupçonnait pas

Le projet exploite des fonctions CSS relativement récentes : hypot() pour le théorème de Pythagore, atan2() pour les angles de rotation, clip-path pour découper les sols en polygones complexes, et @property pour animer des propriétés personnalisées qui servent à gérer les portes, les ascenseurs et même la chute du joueur.

Les ennemis utilisent des spritesheets classiques avec un effet de billboard, c'est-à-dire qu'ils font toujours face à la caméra. Les effets de lumière passent par un filtre brightness sur chaque secteur, et le fameux ennemi invisible Spectre utilise un filtre SVG pour reproduire l'effet de distorsion du jeu original.

Leenheer a même ajouté un mode spectateur avec caméra libre, absent du Doom de 1993, et les calculs de positionnement de cette caméra reposent eux aussi sur les fonctions trigonométriques du CSS.

Les limites du CSS poussé à fond

Le jeu est jouable sur cssdoom.wtf, et le code source est disponible sur GitHub sous licence GPL 2. Par contre, les performances restent limitées. Sur Safari iOS, le jeu peut planter au bout de quelques minutes, et les gros niveaux font souffrir le navigateur.

Leenheer le reconnaît lui-même : le projet ne remplacera jamais WebGL ou WebGPU pour du rendu 3D sérieux. Le but était avant tout de montrer jusqu'où le CSS moderne peut aller, et sur ce point, la démonstration est plutôt convaincante.

C'est le genre de projet complètement absurde qui force le respect. Doom a déjà été porté sur à peu près tout ce qui contient un processeur, des calculatrices aux tests de grossesse, et voilà qu'il tourne maintenant dans une feuille de style.

L'air de rien, ça montre que le CSS de 2026 n'a plus grand-chose à voir avec celui qu'on utilisait pour centrer un div il y a dix ans.

Source : Huckster.io

Quand on gère un serveur, y'a un truc qui rend dingue, c'est le bruit de fond de ces dizaines de milliers d'IPs qui scannent vos ports, qui tentent du bruteforce sur le port 22, qui cherchent des failles WordPress ou des phpMyAdmin oubliés... et surtout qui font tourner Fail2ban à plein régime dans les logs pour stopper ce qui peut l'être.

Fail2ban est d'ailleurs hyper réactif mais il attend qu'une IP fasse une connerie dans vos logs Apache ou SSH avant de la bloquer. Donc c'est quand même un peu tard.. Alors si on pouvait carrément virer le gros du trafic pourri avant même qu'il arrive à nos services ? Ce serait pas mieux ?

Hé bien c'est exactement ce que fait Data-Shield IPv4 Blocklist , un projet open source qui maintient une liste d'environ 100 000 adresses IP identifiées comme malveillantes. Le principe est simple... on colle l'URL RAW de la liste dans la config de son firewall (genre dans les alias d'OPNsense ou les External Block Lists de Fortinet) et hop, tout ce beau monde est filtré au niveau périmétrique. La liste (un simple fichier texte avec une IP par ligne) est rafraîchie toutes les 6 heures avec une fenêtre de rétention de 15 jours, du coup les IPs qui ne sont plus actives finissent par sortir automatiquement.

Côté compatibilité, c'est plutôt large : OPNsense, Fortinet, Palo Alto, F5 BIG-IP, Stormshield, Synology NAS, BunkerWeb... donc clairement, la plupart des pare-feu et WAF du marché peuvent ingérer la liste directement via une URL. Et pour les équipements un peu anciens qui ont des limites sur le nombre d'entrées, y'a même des listes splittées en paquets de 30 000 IPs.

Le projet est maintenu depuis 2023 par Duggy Tuxy, un CISO qui a visiblement décidé que ses week-ends aussi seraient consacrés à la threat intelligence. Presque déjà 4 000 commits sur le dépôt Git, soit des mises à jour quasiment tous les jours. Et c'est impressionnant car le taux de faux positifs affiché est de moins de 2 par mois, ce qui franchement, pour une liste de cette taille, est plutôt fou.

D'ailleurs, si vous utilisez déjà FireHOL pour vos listes de blocage, Data-Shield peut très bien venir en complément. L'idée c'est d'empiler les couches de défense... blocklist périmétrique au niveau iptables ou nftables en première ligne, puis CrowdSec ou Fail2ban pour le trafic qui passe quand même. Un défense en profondeur donc !

Attention par contre, la liste est pensée uniquement pour le trafic entrant (WAN vers LAN). L'appliquer en sortie bloquerait vos propres connexions légitimes. Et sauf si votre firewall gère le rechargement dynamique, pensez également à automatiser le refresh via un cron toutes les 6 heures.

Et pour assurer une haute disponibilité, le projet est distribué sur 5 miroirs : GitHub, GitLab, jsDelivr CDN, BitBucket et Codeberg. Du coup même si une source tombe, vos firewalls continuent à se mettre à jour.

Bref, si vous cherchez à réduire le bruit sur vos serveurs sans vous prendre la tête, allez, c'est gratuit, c'est sous licence GPLv3 et ça se configure en 2 minutes. Merci à Duggy Tuxy pour le tuyau !

Un épisode de la série suédoise High Chaparral, uploadé le 25 mars 2004 sur The Pirate Bay, est toujours partagé aujourd'hui. Vingt-deux ans plus tard, des pirates le seedent encore, non pas pour le contenu, mais juste pour le symbole. Un record de longévité qui en dit long sur la culture du torrent, et sur la résistance du site le plus traqué du web.

Un fichier devenu culte

Tout a commencé par un épisode d'une émission de télé suédoise, High Chaparral, avec un passage du célèbre Uri Geller. Le fichier a été uploadé sur The Pirate Bay le 25 mars 2004, quelques mois après le lancement du site. Et il est toujours là. Selon les données d'OpenTrackr.org, quatre seeders partagent encore le fichier complet en 2026. Personne ne le télécharge pour le contenu, on est d'accord.

C'est devenu un trophée, un petit monument du piratage. Quelques semaines après la mise en ligne, des utilisateurs se plaignaient déjà de rester bloqués à 99 %. Le fichier a failli disparaître, mais des irréductibles l'ont maintenu en vie, année après année.

Des torrents qui refusent de mourir

Le deuxième plus vieux torrent du site date du 31 mars 2004, six jours après. C'est une copie du documentaire Revolution OS, qui retrace l'histoire de Linux et du logiciel libre. Plus de 33 personnes le partagent encore activement. Son réalisateur, J.T.S. Moore, avait d'ailleurs exprimé son mécontentement face au piratage de son film, tout en reconnaissant que ça lui avait donné une longévité inattendue.

Et puis il y a The Fanimatrix, un fan-film inspiré de Matrix, créé en septembre 2003. Celui-là n'est pas hébergé sur The Pirate Bay mais il détient le record du plus vieux torrent actif au monde, avec des dizaines de seeders fidèles au poste. Tourné en Nouvelle-Zélande avec 800 dollars de budget, dont la moitié partie dans un blouson en cuir, il avait été téléchargé 70 000 fois la première semaine.

Si vous vous demandez pourquoi BitTorrent a eu autant de succès à l'époque, voilà un début de réponse : le protocole leur avait économisé environ 550 000 dollars de bande passante.

The Pirate Bay, le survivant

The Pirate Bay a enterré à peu près tous ses concurrents. TorrentSpy, Mininova, isoHunt, KickassTorrents, ExtraTorrent, RARBG, TorrentGalaxy, la liste est longue. Le site tourne encore, même si on ne peut pas dire qu'il soit en grande forme.

L'inscription ne fonctionne plus, les commentaires non plus, et l'interface n'a pas bougé depuis des années. Mais il reste debout, ce qui en soi est un exploit. Ses trois fondateurs, Gottfrid Svartholm, Fredrik Neij et Peter Sunde, ont tous été condamnés en 2009 à un an de prison et 30 millions de couronnes suédoises d'amende. Le site a changé de mains, de serveurs, de pays, mais il est toujours là.

Internet a changé dix fois depuis 2004, les services de streaming se sont multipliés, et des gens continuent de partager un épisode de télé suédoise que personne ne regarde. Juste parce que c'est le plus vieux. On est quelque part entre la résistance numérique et la collection de timbres, version geek. The Pirate Bay lui-même est devenu une sorte de vestige, un site qui fonctionne à moitié mais que personne n'arrive à faire disparaître. Difficile de ne pas trouver ça un peu fascinant.

Source : Torrent Freak

Des milliers de faux messages imitant des notifications de sécurité Visual Studio Code ont été postés sur GitHub. Le but : rediriger les développeurs vers un site malveillant qui collecte leurs données système. La méthode est franchement vicieuse.

Une campagne massive sur GitHub Discussions

Les chercheurs en sécurité de Socket viennent de mettre le doigt sur une opération d'ampleur. Des centaines, voire des milliers de messages quasi identiques ont été publiés en quelques minutes sur la section Discussions de nombreux dépôts GitHub.

Chaque message reprend le même modèle : un titre alarmiste du type "Vulnérabilité grave Mise à jour immédiate requise", un faux identifiant CVE pour faire sérieux, et un lien vers une prétendue extension VS Code corrigée hébergée sur Google Drive.

Les comptes utilisés sont soit tout neufs, soit quasi inactifs, mais ils se font passer pour des mainteneurs de projets ou des chercheurs en sécurité. Et comme GitHub envoie des notifications par e-mail aux personnes qui suivent un dépôt ou qui sont taguées, les fausses alertes arrivent directement dans la boîte mail des développeurs. Vous pouvez donc vous faire avoir sans même ouvrir GitHub.

Un système de filtrage avant le malware

Bien sûr, le lien Google Drive ne vous amène pas d'un coup vers un fichier infecté. Il déclenche avant une série de redirections qui vous emmènent inlassablement vers un domaine bien foireux, où un script JavaScript va se charger du sale boulot.

Ce script collecte automatiquement le fuseau horaire, la langue, le système d'exploitation, l'identifiant du navigateur et même des indicateurs d'automatisation. Tout est envoyé vers un serveur de commande sans que vous n'ayez à cliquer sur quoi que ce soit.

L'idée derrière ce dispositif, c'est de trier les visiteurs. Les robots et les chercheurs en sécurité sont écartés, et seuls les vrais humains reçoivent la suite de l'attaque. Les chercheurs de Socket n'ont d'ailleurs pas réussi à capturer le malware de deuxième étape, ce qui montre que le filtrage fonctionne plutôt bien.

Ce n'est pas la première fois

GitHub a déjà été ciblé par ce genre de campagne. En mars 2025, une attaque similaire avait touché 12 000 dépôts avec de fausses alertes de sécurité qui poussaient les développeurs à autoriser une application OAuth malveillante.

Cette fois-là, les pirates obtenaient un accès direct aux comptes GitHub des victimes. En juin 2024, c'était via des commentaires et des demandes de fusion bidon que les attaquants redirigeaient vers des pages d'hameçonnage.

Le procédé est malin. Utiliser les notifications GitHub pour donner une apparence officielle à des messages bidons, c'est le genre d'astuce qui marche bien sur des développeurs pressés. 

Bon par contre, un lien Google Drive dans une alerte de sécurité, ça devrait quand même mettre la puce à l'oreille. Si vous recevez ce type de message, vérifiez toujours le CVE sur le site du NVD ou de MITRE avant de cliquer où que ce soit. Et si le lien pointe ailleurs que sur la boutique officielle de VS Code, passez votre chemin.

Source : Bleeping Computer