Les processeurs Core Series 3 d'Intel sont en vente, et ce qui est intéressant ici, c'est moins les specs que l'endroit où ils sont fabriqués.

Ces puces sortent des usines Intel de Hillsboro (Oregon) et Chandler (Arizona), sur le procédé 18A, l'équivalent du 2 nm chez Intel. Pas de TSMC dans la boucle. En 2024, une bonne partie des processeurs Intel pour PC portables était encore gravée chez le fondeur taiwanais. Ce n'est plus le cas.

Côté technique, on est sur de l'entrée de gamme assumée. 6 coeurs (2 performance Cougar Cove + 4 basse consommation Darkmont), 2 coeurs GPU Xe3, un NPU à 17 TOPS et une prise en charge mémoire en simple canal. Du budget pas cher donc.

Les fréquences montent entre 4,3 et 4,8 GHz selon les modèles, avec Thunderbolt 4, Wi-Fi 7 et Bluetooth 6. Intel annonce quand même +47% en mono-coeur et +41% en multi-coeur par rapport au Tiger Lake de 11e génération, ce qui n'est pas rien vu que ces puces datent de 2020.

Le vrai sujet, c'est la technologie 18A elle-même. Le procédé utilise RibbonFET (l'architecture Gate-All-Around qui remplace les FinFET) et PowerVia, la première implémentation industrielle de la distribution d'énergie par l'arrière de la puce.

Intel dit avoir environ un an d'avance sur TSMC sur ce point. C'est cette avance qui pourrait attirer des clients fonderie, et c'est probablement pour ça qu'Intel commence par montrer que le 18A fonctionne en production sur des puces commerciales, même d'entrée de gamme. La démonstration compte autant que le produit.

D'autant plus que le contexte s'y prête. Avec les milliards du CHIPS Act, Intel a massivement investi dans ses usines américaines pour ne plus dépendre de TSMC. Le Core Series 3 est la preuve que cette stratégie commence à se concrétiser sur des produits grand public, pas seulement sur des prototypes de labo.

Plus de 70 modèles de PC portables sont prévus chez Acer, Asus, Dell, HP, Lenovo, MSI et Samsung d'ici la fin de l'année. Les premiers systèmes sont déjà disponibles, les configurations edge suivront au deuxième trimestre.

C'est la suite logique des Core Ultra Series 3 (Panther Lake), les puces haut de gamme annoncées au CES en janvier et déjà en vente, elles aussi fabriquées sur 18A.

Bref, Intel qui refabrique ses puces sur sol américain et qui montre que son 18A tourne en production, c'est probablement plus important que les specs des puces elles-mêmes.

Source : The Register

L'interface web de Proxmox (l'outil de virtualisation que tout bon homelabber connaît), c'est bien... pour UN serveur. Dès que vous commencez à empiler les nodes et les clusters, ça devient vite le bazar avec 15 onglets ouverts. PegaProx , c'est tout simplement un dashboard open source qui unifie tout ça dans un seul écran. Et vous allez voir, le truc cool, c'est que ça gère aussi les clusters XCP-ng !

L'interface de PegaProx - une vue unifiée de tous vos clusters Proxmox et XCP-ng

Concrètement, vous branchez tous vos hyperviseurs sur cette interface web (port 5000) et hop, vous avez la vue complète. VMs, conteneurs, métriques de perf... tout remonte en temps réel via Server-Sent Events. Du coup, plus besoin de jongler entre les interfaces de chaque node pour savoir quel serveur rame.

Côté fonctionnalités, accrochez-vous les amis parce que pour une beta, c'est déjà bien garni ! Migration live de VMs entre nodes, gestion du stockage Ceph, consoles navigateur via noVNC et xterm.js, et même de la migration cross-hypervisor entre ESXi, Proxmox VE 8.0 et XCP-ng (encore expérimental côté ESXi, mais ça avance). Y'a aussi des règles d'affinité pour placer vos VMs, du rolling update avec évacuation automatique, et des alertes sur les seuils CPU/RAM/disque. Pour une beta, c'est assez dingue ce qu'ils ont déjà mis dedans.

Côté sécurité, c'est pas en reste non plus. Y'a du RBAC avec 3 rôles (Admin, Operator, Viewer, pas plus pas moins), du TOTP pour le 2FA, de l'intégration LDAP et OIDC compatible Active Directory, Entra ID, Keycloak ou Google Workspace, du chiffrement AES-256-GCM pour stocker les credentials en base, et même du scan de CVE via debsecan. Autrement dit, ils ont pensé aux admins sérieux. Pour ceux qui ont déjà configuré un provider OIDC sur leur homelab , ça se branche directement.

Pour l'installer, le plus simple c'est Docker. Un docker compose up -d, 30 secondes d'attente, et c'est plié.

Mais y'a aussi un script de déploiement automatique, un repo APT communautaire maintenu par gyptazy, ou le classique git clone + pip pour les puristes. Une fois lancé, vous pointez votre navigateur sur https://votre-ip:5000, et un assistant vous accueille avec les identifiants par défaut (pegaprox/admin, à changer immédiatement bien sûr). L'interface est dispo en 5 langues : français, anglais, allemand, espagnol et portugais.

D'ailleurs, si vous utilisez déjà ProxMenux pour administrer votre Proxmox en terminal, les deux sont en fait complémentaires. Disons que ProxMenux couvre l'admin système en ligne de commande, alors que le dashboard apporte la vue unifiée multi-clusters en web. Initialement j'aurais dit que c'était redondant, mais non, ça se marie plutôt bien. Et y'a même un système de plugins avec un portail client pour vos utilisateurs et une page de statut publique à la StatusGator.

Attention c'est comme je vous le disais, encore une beta. L'OIDC avec Authentik par exemple, ça fonctionne pour le login mais les groupes ne remontent pas encore correctement (retour d'un lecteur qui l'utilise au quotidien).

Par contre si vous n'avez qu'un seul serveur Proxmox, honnêtement c'est un peu overkill, l'interface native suffit largement. Quelques glitchs traînent ici ou là, et l'API Token pour se connecter à la place de root n'est pas super bien documenté. Mais le projet avance vite donc c'est plutôt bon signe !

Bref, ça promet pas mal. Merci à Maxime pour la découverte !

MZLA, la filiale de la Mozilla Foundation qui gère Thunderbird, sort un client IA open source auto-hébergeable baptisé Thunderbolt. Multi-plateforme, compatible MCP et Agent Client Protocol, avec intégration du framework Haystack de deepset pour le RAG et les agents. Le tout doit pouvoir tourner sur votre infra, pas chez OpenAI.

Le positionnement est clair. Ryan Sipes, le patron de MZLA, résume : "Est-ce que vous voulez vraiment construire vos workflows IA sur un service propriétaire d'OpenAI ou d'Anthropic, avec toutes les données internes de votre boîte qui transitent par leurs serveurs ?"

La question est vite répondue pour pas mal de DSI en ce moment, surtout en Europe où la souveraineté des données est devenue un sujet bouillant.

Thunderbolt utilise des modèles au choix de l'utilisateur et peut tourner sur une seule machine, sans cluster à gérer. Côté protocoles, la compatibilité MCP (Model Context Protocol) et ACP (Agent Client Protocol) ouvre l'interopérabilité avec les serveurs et agents du marché.

L'intégration de Haystack, le framework d'orchestration IA de deepset (boîte allemande), gère le RAG, les applications multimodales et les agents. Du coup, Thunderbolt ne fait pas que du chat, il peut chercher dans vos documents, croiser des sources, et exécuter des tâches.

La cible, c'est les entreprises qui veulent un Copilot ou un ChatGPT Enterprise sans donner leurs fichiers à Microsoft ou OpenAI. Le code est sur GitHub, et MZLA travaille aussi sur une version hébergée pour les petites équipes qui n'ont pas d'infra à déployer.

Côté crédibilité, MZLA a l'avantage du track record Thunderbird, un projet open source géré proprement depuis des années, avec une communauté active et un financement stable via la Mozilla Foundation. Ce n'est pas un énième side project IA lancé par une startup de quatre personnes. La base de contributeurs existe déjà.

Bref, si vous cherchez un client IA d'entreprise qui ne finit pas chez OpenAI, Thunderbolt est une piste sérieuse.

Source : The Register

200 000 serveurs. C'est le nombre de machines potentiellement exposées à l'exécution de commandes système arbitraires via une faille de conception dans le SDK MCP d'Anthropic, d'après les chercheurs d'OX Security.

L'interface STDIO du protocole permet de créer des sous-processus sans contrôle, ce qui ouvre la porte à n'importe quelle commande OS sur la machine hôte.

Le problème touche tous les langages supportés par le SDK : Python, TypeScript, Java, Rust. Et les packages concernés totalisent plus de 150 millions de téléchargements. Les chercheurs ont documenté quatre classes de vulnérabilité. D'abord de l'injection de commandes non authentifiée, testée sur LangFlow (toutes les versions) et GPT Researcher

Ensuite des contournements de sécurité sur Upsonic et Flowise. Et puis de l'injection de prompt zero-click dans des IDE comme Windsurf, Cursor, Gemini-CLI et GitHub Copilot. Et enfin du "marketplace poisoning" : 9 marketplaces MCP sur 11 testées ont accepté un serveur malveillant de démonstration sans broncher.

10 CVE de niveau élevé ou critique ont été émis. OX Security a mené plus de 30 processus de divulgation responsable depuis novembre 2025, avant de rendre les résultats publics en avril.

La réponse d'Anthropic est celle qui fait grincer des dents. La boîte considère que le comportement est "attendu" et a refusé de modifier l'architecture du SDK. Elle a publié des recommandations de sécurité mises à jour, mais selon les chercheurs, "ça n'a rien corrigé". En clair, Anthropic estime que la sécurité de l'interface STDIO est du ressort de l'utilisateur qui déploie, pas du protocole lui-même.

C'est quand même un positionnement gênant, MCP est devenu un standard de facto pour connecter des modèles IA à des outils externes, et des milliers d'entreprises et de développeurs l'ont adopté.

Si le SDK officiel laisse passer de l'exécution de code arbitraire par design, et que la réponse officielle est "c'est voulu, sécurisez vous-mêmes", la responsabilité est déplacée vers l'aval sans filet.

Bref, si vous déployez du MCP en prod, les recommandations d'OX Security valent le détour. Anthropic ne corrigera pas à votre place.

Source : The Register

1 000 fractures. C'est le nombre de cycles de cassure et de réparation qu'un nouveau composite à fibres a encaissé en labo, sans perdre sa capacité à tenir la route.

Les ingénieurs de NC State University ont créé un matériau qui se "re-soude" tout seul, et qui pourrait durer entre 125 et 500 ans au lieu des 15 à 40 ans habituels pour un composite classique.

Le fonctionnement est assez simple. Le matériau est un composite polymère renforcé de fibres (verre ou carbone), avec deux ajouts. D'abord un agent de cicatrisation thermoplastique (du EMAA, un polymère) imprimé en 3D directement sur les couches de fibres, ce qui rend le composite deux à quatre fois plus résistant à la délamination de base.

Ensuite, des couches chauffantes en carbone intégrées dans la structure. Quand on fait passer un courant électrique, la chaleur fond l'agent thermoplastique, qui coule dans les fissures et re-colle les interfaces séparées. La pièce se répare sans intervention manuelle.

En test, le composite a tenu 1 000 cycles de fracture-réparation en 40 jours continus. La résistance à la fracture commence à 175 % du niveau d'un composite standard, puis descend progressivement jusqu'à 60 % après mille cycles, à cause de l'accumulation de débris de fibres et de la baisse des réactions chimiques.

Ça reste quand même exploitable, et largement au-dessus de la limite de fin de vie d'un composite non-réparant.

Les applications visées sont les ailes d'avion, les pales d'éoliennes, les structures automobiles et les engins spatiaux, bref tout ce qui utilise du composite et subit de la fatigue mécanique sur des décennies.

Si la réparation est faite une fois par trimestre, les chercheurs estiment la durée de vie à 125 ans. Une fois par an, on monte à 500 ans. C'est évidemment théorique, mais l'ordre de grandeur change complètement la donne par rapport aux 15 à 40 ans actuels.

Les travaux ont été publiés en janvier dans les Proceedings of the National Academy of Sciences. La technologie est brevetée et licenciée via Structeryx, une startup fondée par l'équipe de recherche.

Le passage du labo à l'industriel n'est pas gagné (c'est le cas de tous les matériaux), mais les chiffres sont suffisamment parlants pour que l'aéronautique et l'éolien y regardent de près.

Bref, un composite qui dure des siècles au lieu de quelques décennies, ça changerait complètement les calculs de maintenance dans l'aéro et l'éolien.

Source : Ecoticias

Plus de 230 modèles de points d'accès Wi-Fi Cisco ont un problème. Les versions 17.12.4 à 17.12.6a de IOS XE embarquent une bibliothèque qui génère un fichier log, cnssdaemon.log, à raison de 5 Mo par jour. Le fichier ne sert à rien. Et impossible de le supprimer depuis la ligne de commande.

5 Mo par jour. Ça paraît rien. Sauf qu'un point d'accès Wi-Fi n'a pas un disque de 500 Go. La mémoire flash de ces appareils est limitée, et au bout de quelques semaines ou mois, elle sature.

Quand c'est plein, plus moyen de télécharger ou d'installer une mise à jour logicielle. La borne fonctionne encore, mais elle est figée sur sa version actuelle, sans possibilité de patch de sécurité ou de correction de bug.

Et c'est là que le piège se referme. Pour corriger le problème, il faut mettre à jour IOS XE. Mais si la mémoire flash est déjà pleine, la borne n'a pas la place pour stocker la nouvelle image système.

Cisco prévient que tenter la mise à jour dans cet état peut provoquer un bootloop, la borne redémarre en boucle sans jamais finir le boot. Du coup, l'admin se retrouve avec un appareil qu'il ne peut ni patcher ni laisser en l'état.

Cisco a publié un bulletin avec les procédures de test et de remédiation. Il faut d'abord vérifier la version IOS XE, puis libérer de l'espace manuellement avant de tenter la mise à jour.

Ça se fait, mais c'est du travail manuel sur chaque borne, et dans un réseau d'entreprise avec des centaines de points d'accès, la facture en heures de boulot est salée.

Ce genre de bug est particulièrement agaçant parce qu'il est silencieux. Personne ne surveille l'espace disque d'une borne Wi-Fi au quotidien, le problème se découvre en général le jour où une mise à jour échoue, c'est-à-dire trop tard.

Et le fait que la suppression du fichier soit impossible en CLI est quand même un oubli difficile à excuser sur du matériel vendu aux entreprises.

Bref, si vous avez du Cisco en IOS XE 17.12.x, vérifiez vos bornes avant qu'elles ne se bloquent toutes seules.

Source : The Register

Quand on fait du self-hosting, y'a toujours ce moment où on se dit "tiens, y'aurait pas un truc open source pour ça". Tenez par exemple, là je suis en train de chercher un machin open source pour un mariage qui permet aux invités de balancer leurs photos sur un serveur en scannant un QR Code. Et donc je me retrouve à scroller awesome-selfhosted sur GitHub, qui est une liste fleuve de +1500 projets, en essayant de deviner lesquels sont encore vivants.

Et c'est exactement ce problème qu'a voulu résoudre Ethan Sholly en lançant selfh.st/apps en 2024. En gros, c'est un annuaire d'applications auto-hébergées avec des vrais filtres, du tri, et surtout des indicateurs d'activité. Le mec est aussi derrière la newsletter Self-Host Weekly.

L'interface de selfh.st/apps, avec fiches, filtres et indicateurs d'activité

Comme ça, au lieu de vous taper une liste brute, vous avez des fiches pour chaque app avec le nombre d'étoiles GitHub, la licence, le langage, les tags, et surtout un code couleur sur la date de dernière activité. Vert si le projet a reçu un commit dans les 6 derniers mois, jaune entre 6 et 12 mois, rouge au-delà d'un an. Pratique pour éviter d'installer un truc que plus personne ne maintient, genre un serveur Plex alternatif mort depuis 2022 !

Et le tri par défaut, c'est pas juste les étoiles GitHub sinon les gros projets à 50 000 étoiles écraseraient tout. L'algo prend en compte l'âge du repo, la date du dernier commit, et même l'intérêt Google Trends pour les projets non-GitHub. Du coup un outil avec 200 stars mais hyper actif peut remonter devant un dinosaure à 30k stars qui dort depuis 18 mois. J'ai trouvé ça pas bête comme filtrage.

D'ailleurs, chaque projet a son propre flux RSS filtré qui ne remonte que les releases stables. Pas de bêtas, pas de RC... juste les versions prêtes pour la prod. Comme ça, vous branchez ça dans votre FreshRSS ou Miniflux et vous êtes au courant des mises à jour sans checker chaque repo GitHub à la main ! Par contre, si vous aimez vivre dangereusement sur les nightly, là faudra passer par les flux officiels GitHub.

Le site va également plus loin que la simple liste d'apps puisqu'il propose aussi une section "companions", contenant des apps compagnons qui étendent d'autres logiciels auto-hébergés (genre les extensions navigateur pour Linkedin ou les clients tiers pour Immich...etc).

La collection d'icônes pour personnaliser votre Homarr ou Dashy

Et surtout, y'a selfh.st/icons avec des milliers d'icônes de dashboard en SVG, PNG et WebP, toutes en 512x512 ratio 1:1, indispensable pour personnaliser votre page d'accueil sur Homarr ou Dashy !

Le catalogue d'apps est sous licence CC0-1.0 (domaine public) et mis à jour tous les matins à 5h du mat' heure de New York (les icônes, elles, sont en CC-BY-4.0, donc pensez à créditer si vous les réutilisez). En 2 minutes de fouille j'y ai trouvé trois projets que je connaissais pas. Et si vous voulez ajouter le vôtre, le repo est ouvert sur https://github.com/selfhst .

Et si vous connaissez un outil pour mon projet de QR Code d'upload de photo de mariage, n'hésitez pas à me contacter.

Voilà, pour ceux qui font de l'auto-hébergement au quotidien, c'est clairement un bookmark à garder sous le coude. Que vous cherchiez une alternative à Notion, un dashboard pour votre homelab, ou juste un truc pour remplacer un service cloud qui vous gonfle, y'a de quoi fouiller ! Et si vous cherchez des pistes pour commencer, OpenCloud ou Pocket ID sont de bons points de départ.

Bref, une mine d'or pour les homelabbers.

Merci à Maxime pour le lien !

Le noyau Linux est en train de retirer le support matériel des processeurs Baikal, fabriqués par Baikal Electronics en Russie. Pas juste les mainteneurs cette fois, le code lui-même. Les drivers et le support de la plateforme MIPS Baikal-T1 sont en cours de suppression dans les sources du noyau, après des années de tensions autour des sanctions internationales.

Pour remettre en contexte, le support du Baikal-T1 (un CPU MIPS double coeur P5600 cadencé à 1,2 GHz) et du SoC BE-T1000 avait été intégré au noyau Linux à partir de la branche 5.8. Baikal Electronics travaille sur des processeurs domestiques russes, en MIPS et en ARM, pensés pour réduire la dépendance de la Russie aux puces étrangères.

Le problème, c'est que l'entreprise est directement sanctionnée par les États-Unis, l'Union européenne et d'autres pays, avec le soupçon que ses puces puissent finir dans du matériel militaire.

En octobre 2024, une première étape avait été franchie. Onze mainteneurs russes avaient été retirés du fichier MAINTAINERS du noyau, dont Serge Semin, responsable du driver Baikal-T1 PVT et de la plateforme MIPS Baikal-T1.

Linus Torvalds avait tranché clairement : "C'est parfaitement clair pourquoi le changement a été fait, il ne sera pas annulé." Greg Kroah-Hartman, de son côté, avait invoqué des "exigences de conformité" liées aux sanctions américaines OFAC.

Mais à l'époque, le code restait. Les mainteneurs partaient, les drivers non. Du coup, un développeur de chez Baikal pouvait toujours soumettre un patch, même si trouver quelqu'un pour le merger devenait compliqué.

Jakub Kicinski, mainteneur du sous-système réseau du noyau, avait d'ailleurs refusé publiquement d'accepter des patches venant d'employés de Baikal Electronics, en invoquant un malaise personnel face à la situation.

L'étape en cours va plus loin. C'est le support matériel lui-même qui est en train d'être retiré. Concrètement, ça veut dire que les futures versions du noyau ne compileront plus pour cette plateforme, et que les distributions qui montent en version perdront le support natif de ces puces.

Pour les quelques machines qui tournent sur du Baikal-T1 en dehors de Russie (il y en a très peu), ça implique de rester sur un noyau ancien ou de maintenir un fork.

Côté Russie, Baikal Electronics maintient son propre fork du noyau Linux sur GitHub. Le projet n'est pas mort, il est juste découplé de l'upstream. Ça pose quand même une vraie question sur la viabilité long terme d'un fork désormais très isolé, sans les contributions de la communauté internationale.

Bref, Linux tranche dans le dur cette fois. Plus de mainteneurs, et bientôt plus de code non plus.

Source : Phoronix

Zéro. C'est la durée que vous pouvez désormais choisir comme limite Shorts dans les réglages YouTube, sur iOS comme sur Android. Mettez le curseur à zéro, les Shorts disparaissent de votre page d'accueil. Fini le défilement vertical entre deux vidéos longues. Le déploiement mondial est en cours depuis le 15 avril, d'abord pour les comptes parentaux, puis pour tout le monde.

La manipulation prend dix secondes. Vous ouvrez les réglages, vous allez dans "Gestion du temps", vous trouvez "Limite du fil Shorts", vous descendez à zéro. YouTube affiche alors un message disant que votre fil est "en pause pour la journée". Ça se réinitialise le lendemain matin. Les Shorts ne sont pas supprimés de l'app pour autant, ils restent visibles dans l'onglet Abonnements, et si quelqu'un vous envoie un lien direct vers un Short, vous pouvez toujours le regarder. Mais le carrousel infini de la page d'accueil, celui qui vous happe quand vous vouliez juste chercher un tuto, lui, est coupé.

Ce qui est malin, c'est que YouTube n'a pas créé de bouton "désactiver les Shorts". Des millions de gens le réclamaient. La plateforme a plutôt recyclé un outil de bien-être numérique existant, le minuteur de visionnage, et a étendu sa plage jusqu'à zéro. Vous ne "désactivez" rien. Vous vous fixez un "objectif de temps" de zéro minutes. C'est du pur habillage sémantique, mais ça protège YouTube d'un aveu officiel que son propre format pose un problème d'addiction.

YouTube avait mis en place des limites allant de 15 minutes à 2 heures il y a quelques mois, sous pression des régulateurs (Digital Services Act en Europe, auditions au Congrès américain). L'option zéro en est l'extension logique. Mais c'est aussi un aveu discret. Pas mal d'adultes veulent juste un YouTube sans TikTok dedans, et c'est un constat que Google n'avait visiblement pas envie de formuler publiquement.

Pour les créateurs qui misent tout sur le format court, c'est quand même un problème. Leurs vidéos restent accessibles aux abonnés, mais la visibilité organique via l'accueil tombe à zéro pour tous les utilisateurs qui vont activer l'option. YouTube n'a pas communiqué de chiffres sur l'adoption, et ne le fera probablement pas.

Bref, si les Shorts vous gonflent, l'interrupteur existe. Il est juste planqué trois menus plus loin.

Source : The Verge

Une attaque par la chaîne d'approvisionnement a frappé WordPress début avril. Un individu a racheté une trentaine de plugins via la marketplace Flippa, y a injecté du code malveillant et a attendu huit mois avant de l'activer. WordPress a fermé les 31 plugins concernés le 7 avril, mais la mise à jour officielle ne suffit pas à nettoyer les sites touchés.

L'attaque est redoutable par sa simplicité. Un individu, identifié sous le prénom "Kris", a racheté pour plusieurs centaines de milliers d'euros un catalogue d'une trentaine de plugins WordPress sur Flippa, une marketplace de vente de sites et d'extensions. Ces plugins appartenaient à la société Essential Plugin / WP Online Support. Ils étaient actifs, mis à jour, et installés sur des milliers de sites.

En achetant le catalogue, l'acheteur a récupéré l'accès au dépôt officiel WordPress.org et a pu pousser des mises à jour directement aux utilisateurs. Le code malveillant a été injecté dès août 2025, mais il est resté dormant pendant huit mois. L'activation a eu lieu les 5 et 6 avril 2026.

Côté technique, l'attaque est assez vicieuse. Le module injecté (wpos-analytics) utilise une désérialisation PHP pour communiquer avec un serveur de commande. Et là, le point intéressant : au lieu d'utiliser un domaine classique pour piloter la backdoor, le malware résout l'adresse de son serveur C2 via un smart contract Ethereum, en interrogeant des points d'accès RPC publics. Résultat, couper un nom de domaine ne sert à rien. L'attaquant peut mettre à jour le smart contract à tout moment pour pointer vers un nouveau serveur.

Le payload injecte du code dans le fichier wp-config.php (environ 6 Ko) et crée un fichier wp-comments-posts.php, un nom assez proche des fichiers légitimes pour passer inaperçu. Le tout sert à afficher du spam SEO (liens, redirections, fausses pages) uniquement à Googlebot, ce qui rend l'attaque invisible pour le propriétaire du site.

WordPress.org a fermé les 31 plugins touchés le 7 avril et a poussé une mise à jour forcée le lendemain. Sauf que cette mise à jour ne nettoie pas le fichier wp-config.php, qui est le vrai point de persistance de la backdoor. Si vous avez l'un de ces plugins installé (Countdown Timer Ultimate, Popup Anything on Click, Post Grid and Filter Ultimate, WP Slick Slider, Album and Image Gallery Plus Lightbox, Responsive WP FAQ, entre autres), il faut aller vérifier votre wp-config.php manuellement et chercher un bloc de code d'environ 6 Ko qui n'a rien à y faire. Le fichier wp-comments-posts.php à la racine du site doit aussi être supprimé s'il est présent.

La vraie leçon ici, c'est que la confiance dans un plugin WordPress repose sur son historique, et qu'un changement de propriétaire peut tout remettre en question du jour au lendemain. WordPress.org ne vérifie pas les changements de mains sur les comptes développeurs, et n'a aucun mécanisme d'alerte quand un catalogue entier passe à un nouvel acheteur. Tant que ce trou existe, ce genre d'attaque peut se reproduire. Et le fait que la mise à jour officielle ne nettoie même pas les sites infectés, c'est quand même un problème.

Source : The Next Web

Tapez $TSLA ou $BTC dans un post sur X, et maintenant ça vous affiche un cours en temps réel, un graphique interactif et un fil de discussion lié à l'actif. C'est disponible depuis le 14 avril sur iPhone. Pour Android et le site web, ça sera pour plus tard.

Le principe est assez simple. Un $ticker dans un post déclenche la suggestion automatique de l'actif correspondant. Le graphique couvre de 1 jour à 1 an, le prix est actualisé en continu, et le fil agrège les posts qui mentionnent cet actif. Côté crypto, les adresses de contrats sur Solana et Base sont aussi prises en charge, ce qui veut dire que les memecoins sont de la partie. Forcément.

Au Canada, X va plus loin. Un partenariat avec Wealthsimple permet d'acheter ou vendre directement depuis la timeline. Un bouton "trade" apparaît sur chaque page Cashtag et route l'ordre vers Wealthsimple, actions comme crypto. C'est la première intégration courtier sur X, et probablement un ballon d'essai avant de pousser ça ailleurs.

Elon Musk parle depuis des années de transformer X en "app à tout faire". Nikita Bier, responsable produit, avait teasé les Cashtags en janvier, et la livraison a été plutôt rapide. Le volet financier de X n'est plus juste un slide de keynote, il commence à exister dans l'app.

Sauf que voilà, mélanger discussions crypto et exécution d'ordres dans une timeline où circulent du pump-and-dump, du shilling payé et des faux comptes, c'est un cocktail que les régulateurs vont scruter de très près. La SEC n'a rien dit pour l'instant. Mais Cashtags + trading intégré + memecoins + algorithme de viralité, ça coche quand même pas mal de cases potentiellement problématiques.

Pour les utilisateurs français, la fonction est visible mais pas encore utilisable avec un courtier local. Le trading reste cantonné à Wealthsimple au Canada. Si X veut ouvrir ça en Europe, il faudra passer par les agréments MiFID, et ce n'est pas gagné pour le moment.

Bref, X se rapproche du super-app financier que Musk promet depuis le rachat. Le régulateur, lui, se rapproche de X.

Source : Forbes

La mise à jour d'avril du SDK Agents d'OpenAI introduit deux nouvelles briques qui manquaient pour passer de l'agent-jouet au déploiement réel. Le sandboxing natif permet de confiner un agent dans un espace de travail isolé, avec accès limité aux fichiers et outils d'un périmètre défini. Et le nouveau harness d'exécution sépare proprement le plan de contrôle (boucle agent, appels modèle, routing d'outils, approbations, tracing, récupération d'erreurs) du plan de calcul (sandbox où l'agent lit, écrit, exécute du code, installe des dépendances, snapshot son état).

L'architecture est pensée pour les agents "long-horizon", ceux qui travaillent sur des tâches complexes en plusieurs étapes, sur des durées longues, avec un besoin de persistance d'état entre les étapes. Le harness gère la coordination, le développeur apporte son propre compute et stockage. C'est une séparation qui permet de brancher le SDK sur n'importe quelle infrastructure, que ce soit Cloudflare, Vercel, Blaxel ou un cluster interne.

Le SDK introduit aussi une abstraction "Manifest" pour décrire un workspace de manière portable. En clair, vous décrivez les outils, les fichiers et les permissions disponibles dans un format standardisé, et le harness sait reconstituer l'environnement ailleurs. C'est utile pour le test, pour la reproductibilité, et pour déployer le même agent dans des environnements différents sans reconfigurer à la main.

Le lancement est Python d'abord, TypeScript prévu après. Classique. Ça peut agacer les équipes full-stack qui bossent en TypeScript, mais c'est quand même très cohérent avec le fait que la majorité des workloads agents en prod tournent encore en Python, surtout côté data et sécurité.

Ce qui est intéressant, c'est le sous-texte. OpenAI pousse un modèle où son SDK est le harness, et le compute est chez le client ou chez un partenaire cloud. C'est un positionnement de plateforme d'orchestration, pas de fournisseur d'infra. Anthropic et Google proposent des approches comparables avec leurs propres SDKs, mais OpenAI a l'avantage du premier écosystème de plugins et d'outils tiers déjà en place.

Bref, pour les devs qui construisent des agents en prod, cette release comble de vrais trous. Sandboxing et harness, c'étaient les deux pièces manquantes.

Source : Techcrunch

Pour accéder à certaines fonctionnalités de Claude, Anthropic peut maintenant vous demander une pièce d'identité officielle (passeport, permis de conduire, carte nationale d'identité) et un selfie en temps réel. La vérification est gérée par Persona, un prestataire externe, et les données ne sont ni stockées par Anthropic, ni utilisées pour l'entraînement des modèles. Les photocopies, les cartes étudiantes et les pièces numériques ne sont pas acceptées.

Le mécanisme se déclenche a priori dans plusieurs cas : accès à des capacités spécifiques, vérifications d'intégrité de plateforme, ou mesures de conformité. Anthropic ne détaille pas vraiment les usages qui déclenchent cette vérification, ce qui crée du coup un flou que pas mal d'utilisateurs n'apprécient pas des masses.

Le timing est franchement gênant. Des millions d'utilisateurs ont migré vers Claude ces derniers mois, après les polémiques sur la surveillance et les accords controversés d'OpenAI avec des agences gouvernementales. "Vous avez quitté OpenAI pour la vie privée. Claude veut maintenant votre passeport", déclarent même certains journalistes. L'image n'est pas fausse.

Anthropic se défend, en expliquant que les images restent chez Persona, Anthropic y accède uniquement sur demande (appel, par exemple), et le prestataire est contractuellement interdit de les utiliser à d'autres fins que la vérification et la prévention des fraudes. Pas de revente, pas de marketing. Sur le papier, c'est propre. En pratique, vous donnez quand même un document d'identité gouvernemental à un sous-traitant pour pouvoir poser des questions à un chatbot.

La vraie question, c'est pourquoi. Anthropic invoque la sécurité et la conformité, mais la pression réglementaire sur les modèles d'IA pousse les éditeurs à vérifier l'âge et l'identité des utilisateurs, surtout quand leurs modèles deviennent plus puissants. On l'a vu avec OpenAI et son programme Trusted Access for Cyber, même logique d'accès vérifié. 

Pour les utilisateurs qui utilisent Claude pour du code, de l'écriture ou de la recherche, ça ne changera probablement rien au quotidien. La vérification ne se déclenche pas pour tout le monde, pas tout le temps. Mais si ça tombe sur vous, refuser revient à perdre l'accès aux fonctionnalités concernées. Pas d'alternative proposée.

Bref, il y a là une logique réglementaire, mais le contraste avec l'image "pro-vie privée" d'Anthropic pique un peu.

Source : Helpnetsecurity

Sandbox-exec, c'est un utilitaire en ligne de commande dont pas grand monde ne parle mais qui est intégré à macOS et qui permet de lancer n'importe quel programme dans un bac à sable sécurisé, avec des restrictions sur mesure. Apple l'a déprécié, mais ça marche toujours... et c'est franchement pratique.

Avec ce truc, il suffit de créer un petit fichier de profil (extension .sb) et vous lancez votre commande avec sandbox-exec -f profil.sb votre_commande. En faisant ça, le programme de votre choix tournera dans un environnement verrouillé où il ne pourra accéder qu'à ce que vous autorisez explicitement.

Ensuite, vous avez deux philosophies. Soit vous bloquez tout par défaut et vous n'autorisez que le strict nécessaire, c'est-à-dire l'approche parano parfaite pour tester du code louche. Soit vous autorisez tout et vous ne bloquez que ce qui craint. La première est plus sûre, la seconde plus rapide à mettre en place.

Voici un exemple concret pour avoir un terminal coupé du réseau. Suffit de 3 lignes de profil (c'est du LISP) :

(version 1)
(allow default)
(deny network*)

Le sujet central du lancement de GPT-5.4-Cyber, c'est moins le modèle que le mécanisme d'accès.

OpenAI a annoncé une version fine-tunée de GPT-5.4 dédiée aux cas d'usage cybersécurité, avec une particularité assumée : moins de restrictions sur les capacités du modèle, mais accès réservé aux participants vérifiés du programme Trusted Access for Cyber.

Concrètement, ce GPT-5.4-Cyber sait faire des choses que les modèles grand public refusent ou limitent. On parle ici de Reverse engineering de binaires sans code source, analyse de malware, étude de vulnérabilités, génération de workflows défensifs avancés, et j'en passe.

Des tâches utiles pour un chercheur en sécurité, mais potentiellement dangereuses si elles tombent entre les mauvaises mains. D'où le verrou d'accès au niveau du compte plutôt qu'au niveau du prompt.

Le programme Trusted Access for Cyber avait été lancé plus tôt dans l'année pour donner à des pros de la sécu vérifiés un accès à des capacités normalement bridées.

OpenAI y ajoute désormais des niveaux supplémentaires, avec un principe simple. Plus le niveau de vérification d'identité est élevé, plus les capacités du modèle sont débloquées. Accès étendu à des milliers d'individus et des centaines d'équipes sécurité, à condition de passer les contrôles.

Ce qui frappe en fait, c'est le changement de posture. OpenAI avait longtemps mis l'accent sur le bridage direct du modèle, via du RLHF agressif et des garde-fous au niveau du prompt. L'approche qui s'impose en 2026, c'est celle de la vérification d'identité plus du monitoring d'usage, avec un modèle plus compétent en face.

Moins de refus, plus de traçabilité. C'est cohérent avec le fait que les red teams avaient largement documenté comment contourner les garde-fous classiques.

Le timing est intéressant. L'annonce tombe une semaine après un lancement similaire chez un concurrent sur le même créneau. Mythos avait ouvert le bal avec un modèle spécialisé cyber et un mécanisme d'accès vérifié comparable.

Du coup, OpenAI ne veut pas laisser le marché et pousse son infra d'identité plutôt que de tenter une bataille de benchmarks.

Côté risques, la question qui reste ouverte c'est la solidité du processus de vérification. Un acteur malveillant avec une couverture légitime (société écran, identité empruntée, insider dans une boîte de pentest) peut techniquement passer les contrôles, et OpenAI indique surveiller l'usage a posteriori plutôt que bloquer en amont. Une fuite d'output reste exploitable même si le compte d'origine est révoqué derrière.

Bref, modèle plus fort, bridage déplacé du prompt vers l'identité. On est là devant un marché cyber-IA qui bouge très vite.

Source : Bloomberg

L'app desktop Google est officiellement disponible sur Windows 10 et supérieur, dans le monde entier (en anglais pour l'instant), avec un raccourci Alt+Espace qui fait popper une barre de recherche unifiée.

Web, Google Drive, fichiers locaux, apps installées, tout est cherchable depuis la même fenêtre. Les utilisateurs macOS reconnaîtront immédiatement l'inspiration. C'est un vrai petit Spotlight.

L'outil traînait en bêta Search Labs depuis septembre 2025, d'abord réservé aux comptes perso anglophones aux États-Unis. Google a pris le temps d'améliorer le produit, d'ajouter des fonctions, et surtout d'intégrer Gemini côté IA.

Concrètement, la barre de recherche sert de point d'entrée à plusieurs choses. Vous tapez un mot, vous récupérez des résultats web classiques, des fichiers Drive, des fichiers locaux et des apps Windows installées dans le même flux.

À côté, un bouton Google Lens permet de faire du "Circle to Search" sur votre écran Windows, pour identifier un objet, traduire un texte dans une image ou lancer une recherche visuelle. Upload de fichier, partage d'écran pour poser des questions à l'IA sur ce qui s'affiche, accès rapide aux AI Overviews ou à AI Mode, tout est là.

Là où Google marche sur les plates-bandes de Microsoft, c'est précisément sur le terrain que Copilot revendique sous Windows. Sauf que Copilot est imposé par Microsoft, alors que l'app Google vient en alternative, plus discrète, activable au raccourci clavier, et qui pompe ses résultats dans l'index Google plutôt que dans Bing.

Pour un utilisateur Windows très lié à l'écosystème Google (Gmail, Drive, Docs, Calendar), ça fera plus de sens que Copilot, même si l'intégration OS est évidemment moins profonde.

Pour ceux qui ne veulent pas de Gemini, l'app est quand même potentiellement utile pour la recherche unifiée locale + Drive + web, même sans toucher à l'IA.

Ce petit Alt+Espace peut donc remplacer avantageusement la recherche Windows par défaut, qui mélange souvent les résultats avec des suggestions Bing pas toujours intéressantes.

D'un point de vue de la sécurité, Google explique indexer les fichiers locaux en respectant les permissions du compte, mais l'outil envoie forcément une partie des requêtes et du contexte vers les serveurs Google, ne serait-ce que pour les réponses IA.

Pour une machine pro sur laquelle transitent des docs sensibles, c'est à considérer avant de l'installer, et probablement à discuter avec la DSI.

Bref, Google tente son Spotlight sur Windows. Si vous vivez dans l'écosystème Google et que Copilot vous irrite, ça vaut le test.

Source : 9to5Google

Six ans. C'est le temps qu'il aura fallu à Mozilla pour changer d'avis sur l'API Web Serial. Firefox Nightly 151 l'intègre désormais, avec activation via un flag à aller chercher dans le menu. Le premier commit côté code date de mi-janvier, et le déploiement pour les utilisateurs Nightly est effectif depuis le 13 avril.

Pour ceux qui ne connaissent pas, Web Serial est l'API standardisée qui permet à une page web de communiquer directement avec un périphérique série connecté en USB, en Bluetooth ou via un vrai port série.

Imprimante 3D, Arduino, carte ESP32, débogueur JTAG, microcontrôleur industriel, hub domotique, tout ce qui expose une liaison série peut être piloté depuis du JavaScript. C'est par exemple ce qui fait tourner l'IDE Arduino en ligne, Espruino, les flasheurs ESP dans le navigateur, et une bonne partie de la scène maker moderne.

Chrome, Edge, Opera et Vivaldi supportent Web Serial depuis 2020. Firefox, lui, tenait une position claire, trop risqué, le consentement utilisateur ne protège pas assez, la surface d'attaque sur le matériel connecté est bien trop large.

Un ingénieur de Mozilla l'avait écrit noir sur blanc à l'époque. Les utilisateurs Firefox qui bidouillaient avec des cartes électroniques étaient de fait poussés sur Chrome ou sur une extension tierce bancale. En 2026, Mozilla rend les armes et aligne Firefox sur le reste de l'écosystème, Apple mis à part.

Apple, justement, reste fermement opposé à Web Serial, WebUSB et WebHID côté WebKit. Les arguments avancés sont les mêmes qu'à l'époque Mozilla, fingerprinting, sécurité, risques sur l'OS.

Safari n'intégrera pas l'API dans un avenir prévisible. Donc en pratique, si vous avez une webapp qui dialogue avec du matos, iOS et iPadOS restent hors-jeu pour cet usage.

Côté permissions, Web Serial exige une validation utilisateur explicite pour chaque périphérique, avec une fenêtre de sélection gérée par le navigateur. Le site ne peut pas lister les ports disponibles sans action.

C'est un garde-fou correct, mais qui ne supprime pas le risque de phishing physique (un site malveillant qui vous demande de sélectionner un périphérique sous un prétexte bidon).

Pour les makers, l'arrivée dans Firefox est une vraie bonne chose. Ça fait un navigateur supplémentaire pour flasher un ESP depuis le web, une option pour ceux qui refusent Chrome par principe, et un moins gros verrou à faire sauter pour les tutoriels d'électronique amateur. La version stable devrait arriver dans quelques mois si les retours Nightly sont propres.

Bref, Firefox s'aligne, Apple s'isole, et la bidouille matérielle reprend ses droits dans le navigateur, tout va bien.

Source : The Register

Une lettre d'Apple adressée à des sénateurs américains, obtenue par NBC News, révèle qu'Apple a menacé xAI en janvier de retirer Grok de l'App Store si l'entreprise ne bloquait pas sérieusement la génération de deepfakes sexualisés.

La menace est restée relativement discrète à l'époque, mais le dossier remonte aujourd'hui dans le cadre d'une réponse écrite à des questions parlementaires.

L'affaire a en fait démarré fin décembre 2025, quand Grok a commencé à être utilisé massivement sur X pour "dénuder" numériquement des photos de femmes, sans leur consentement, avec des résultats por#ographiques.

Apple a bougé en interne. L'entreprise a contacté les équipes X et Grok, constaté les violations de ses guidelines, et exigé un plan d'amélioration de la modération. X a "substantiellement résolu" ses violations selon Apple. Grok, pas assez.

Apple a rejeté une soumission suivante de l'app, avec notification officielle que le statu quo menait au retrait. Après des changements additionnels de xAI, Apple a fini par approuver la dernière version soumise.

Ce qui est intéressant dans l'histoire, c'est la méthode. Pas de tweet de menace, pas de communiqué public. Apple utilise son levier le plus efficace, le rejet de soumission, qui bloque les mises à jour et empêche toute évolution du produit sur iOS.

Pour une app aussi active que Grok, c'est létal en quelques semaines. xAI a compris, a mis les correctifs, s'est remis en conformité.

La question de fond reste posée. Même après correction, un modèle génératif d'image peut être poussé à produire du contenu problématique via du prompt engineering, et c'est toujours contournante.

Apple ne vérifie pas le code de Grok, elle vérifie ce que les utilisateurs peuvent sortir dans des scénarios de test. Ça laisse une marge. Du coup, la conformité App Store est plutôt un baromètre qu'une garantie.

L'affaire rappelle aussi qu'Apple, quoi qu'on pense de son monopole sur iOS, reste un des rares acteurs capables de faire plier une boîte d'Elon Musk sans passer par un tribunal.

L'arbitrage, en passant par l'analyse suite à une soumission de l'app, est unilatéral, opaque, et parfois efficace. Les sénateurs qui avaient écrit à Apple et Google en janvier pour demander le retrait de Grok n'ont pas obtenu gain de cause, mais ils ont obtenu un rappel à l'ordre que xAI a dû suivre.

En tous cas, pour une fois, c'est un cas concret où le contrôle App Store a vraiment servi à quelque chose, et c'est surtout un rappel que la modération des modèles d'image en prod est toujours un vrai problème, et ce depuis qu'internet existe (vous vous souvenez de l'affaire Estelle Hallyday contre l'hébergeur Altern en 1999 ? Oui je suis aussi vieux que ça.

Source : Apple Insider

Wolfenstein 3D, pour ceux qui n'étaient pas nés en 1992, c'est le FPS qui a tout lancé. Le jeu de Carmack et sa bande chez id Software, qui a directement mené à DOOM l'année suivante.

Eh bien un dev Rust vient de le recréer de zéro, et c'est 100% jouable dans le navigateur.

Iron Wolf , c'est donc le projet de Michael Bohn, un allemand, qui bosse sur ce truc depuis mai 2021, soit près de cinq ans. On n'est donc pas sur un portage vibe codé à l'arrache. C'est vraiment une réécriture complète.

La version web d'Iron Wolf tournant dans le navigateur

Le bonhomme a carrément créé ses propres crates Rust pour émuler la carte VGA et la puce sonore OPL. J'ai d'abord cru qu'il réutilisait une lib existante, mais non, il a tout écrit from scratch en Rust. Bah ouais, développer ses propres librairies d'émulation hardware juste pour un side-project, what else ?? Je trouve que ça force le respect !

Le truc cool, c'est que la version shareware du jeu est incluse directement dans le dossier testdata/ du repo. Du coup sur macOS, Linux ou Windows, un git clone + just run-sdl-shareware et hop, vous voilà dans les couloirs du château. Attention sur Ubuntu 22.04, faut avoir libsdl2-dev d'installé avec apt install libsdl2-dev, sinon la compilation plante avec une erreur cryptique. Par contre, si vous êtes sur la version Ubuntu 24.04, là ça passe direct. Et si vous avez les fichiers WAD du jeu complet qui traînent sur un vieux CD-ROM quelque part, ce sera encore mieux car la version web permet de les uploader pour jouer à l'intégrale.

Ça tourne donc en WebAssembly sur wolf.ironmule.dev , sans plugin, juste Chrome ou Firefox récent. Voilà, si vous vous demandiez si on peut encore jouer au classique en 2026... la réponse est carrément oui !

Pour les curieux, le raycasting, cette technique de rendu qu'utilisait Wolfenstein 3D, est réimplémenté très fidèlement puisque le moteur de Michael dessine les murs comme le code de Carmack le faisait à l'époque... sauf que là ça tourne dans un onglet de navigateur. Vos fichiers de jeu sont également stockés localement via IndexedDB et un service worker gère le mode hors-ligne ce qui est très pratique pour jouer en avion ou quand on est chez Free (je décoooonnnne, humour humour).

Le projet en est à sa version 0.9.0, sous licence GPL-3.0 et si les classiques d'id Software recréés par des passionnés vous branchent, sachez que DOOM aussi a ses portages bien sympas.

Bref, si la nostalgie du raycasting vous titille, allez faire un tour sur wolf.ironmule.dev.

Deux câbles intégrés ? C'est ce qui fait toute la différence sur cette batterie externe Anker de 25 000 mAh, vendue sur Amazon . Un câble rétractable de 70 centimètres, un second de 30 centimètres qui sert aussi de lanière de portage, et 165 watts de puissance totale pour alimenter tout votre bureau mobile.

L'argument principal, c'est vraiment de ne plus chercher de câble USB-C dans le fond de la sacoche à chaque fois qu'un appareil passe dans le rouge. Dans mon cas, c'est idéal, je peux charger mon MacBook Pro et mon iPhone 17 Pro Max à la vitesse maximale, sans me poser de questions, et surtout, on a encore deux ports de libres pour charger deux autres machins !

Côté puissance, on est sur du sérieux ici. La batterie délivre jusqu'à 165 watts au total, répartis sur trois ports USB-C (dont les deux câbles intégrés), un port USB-A. Chaque port USB-C peut grimper jusqu'à 100 watts, ce qui suffit largement à recharger un MacBook Pro 14 pouces à pleine vitesse.

En pratique, vous pouvez charger un MacBook, un iPhone 17 Pro Max, un iPad et une paire d'AirPods en même temps sans que la vitesse ne s'écroule, à aucun moment.

La batterie elle-même encaisse 100 watts en entrée, et Anker annonce 30% récupérés en 20 minutes. Sur mon test avec un chargeur GaN 100 W, ça se confirme : la jauge grimpe rapidement. 25 000 mAh, ça représente environ six charges complètes d'un iPhone et deux d'un MacBook Air. Largement de quoi tenir un long week-end sans chercher une prise.

Le poids ? 595 grammes, ce qui reste raisonnable pour une batterie d'une telle capacité. Ce n'est bien sûr pas une batterie qu'on glisse dans une poche de veste. Les dimensions (environ 16 × 5 × 5 centimètres) en font un format dense, pas vraiment discret, mais pourtant son design tout en rondeur sur les tranches fait qu'elle semble moins massive que des batteries 20 000 mAh que j'utilise aussi, malgré une plus grande capacité.

Par contre, elle passe sans problème en bagage cabine, elle reste sous la limite des 100 Wh du réglementaire aérien.

Le petit écran en façade affiche le pourcentage de batterie restant en chiffres bien lisibles, et plein d'autres informations comme le nombre de cycles, les puissances de charge de chaque port, et même la température de la batterie (qui reste toujours assez fraiche).

La finition en métal argenté donne un côté pro qui tranche avec les batteries plastiques bas de gamme. La lanière de 30 centimètres est prévue pour supporter jusqu'à 20 kilos, le câble rétractable pour plus de 20 000 rétractations, donc rien ne semble bricolé dans la promesse produit, mais bon, c'est du Anker, donc c'est du sérieux.

À 89,99 euros, elle n'est pas donnée mais reste dans le coup face aux solutions comparables chez UGREEN ou Baseus, qui tournent autour du même prix et même souvent un peu plus chères, pour des specs assez proches. 

Avec plus de 8 000 avis et une moyenne autour de 4,6 sur 5 sur Amazon sur ce modèle, Anker confirme son statut de référence du secteur des chargeurs et batteries externes. Bref, pour qui bosse en mobilité, c'est probablement la batterie qui coche le plus de cases aujourd'hui. Disponible ici sur Amazon .

Bon, j'ai la crève et y'a du bricolage qui m'attend, du coup aujourd'hui y'aura pas des centaines d'article. Mais faut quand même que je vous parle de Hister , le nouveau projet d'Adam Tauber (le créateur de Searx ) qui indexe localement tout ce que vous visitez sur le web pour le retrouver en texte intégral.

Vous installez l'extension Chrome ou Firefox, vous lancez le binaire Go sur votre machine (ça tourne sous Linux, macOS et Windows), et hop, chaque page que vous visitez est indexée en full-text. Du coup, quand vous cherchez ce tuto que vous aviez lu y'a 3 semaines mais dont vous avez zappé l'URL, vous ouvrez l'interface web locale de Hister, vous tapez un mot qui était dans le contenu de la page et ça ressort ! Si vous aviez testé Deeper History à l'époque, c'est le même concept mais en beaucoup plus costaud.

L'interface de Hister - sobre mais efficace

Sous le capot, Hister utilise blevesearch, un moteur d'indexation en Go qui gère le fuzzy matching et les requêtes booléennes. En gros, vous tapez "configuration nginx reverse proxy" et ça vous ressort cette page de doc que vous aviez consultée y'a un mois, même si vous ne vous souvenez que de 2 mots. Efficace donc. Et l'outil capture les pages telles qu'elles étaient au moment de votre visite donc si un site modifie son contenu ou si un article disparaît, vous aurez toujours la version d'origine. Y'a même un mode aperçu hors-ligne pour consulter ces snapshots sans connexion !

Côté vie privée (forcément, quand ça vient du mec qui a pondu Searx déjà en 2013... le temps file les amis ^^), tout reste sur votre machine. Et pour les domaines sensibles comme votre banque ou votre mutuelle, une blacklist permet même d'exclure certains sites de l'indexation. Enfin pour ceux qui ont déjà des années de navigation derrière eux, la commande hister import aspirera votre historique Chrome ou Firefox existant, comme ça pas besoin de repartir de zéro.

Pour installer ça, téléchargez le binaire depuis les releases GitHub , puis lancez le serveur et installez l'extension ( Firefox ou Chrome) qui va bien. Y'a aussi un Docker Compose pour ceux qui préfèrent tout conteneuriser. Prévoyez aussi quelques Go sur le disque pour la base d'index car ça se rempli vite...

Tauber dit avoir réduit sa dépendance à Google de moitié en un mois et demi juste avec ça. Et je trouve ça logique parce que quand vous avez déjà visité la bonne page une fois, ça ne sert plus à rien de redemander à Google de vous la remonter entre 3 pubs et une réponse IA à côté de la plaque. Autant récupérer ce que vous aviez déjà !

Voilà, je suis sûr que ça va vous plaire... Et si vous voulez tester avant d'installer quoi que ce soit, une démo tourne en ligne.

Allez, je retourne bricoler...

La fondation Raspberry Pi vient d'annoncer une nouvelle version du Pi 4 avec 3 Go de RAM, vendue 83,75 dollars (environ 100 euros). Mais derrière cette annonce se cache une mauvaise nouvelle : les prix de toute la gamme augmentent à cause de la flambée de la mémoire.

Un modèle 3 Go pour limiter la casse

Annoncé un 1er avril, ce nouveau Raspberry Pi 4 n'est pas une blague. Le modèle embarque deux puces LPDDR4 de 1,5 Go chacune, une configuration qui permet de réduire les coûts de production par rapport aux puces 2 Go classiques.

Le prix de la mémoire LPDDR4 a été multiplié par sept en un an, et c'est cette explosion qui a poussé la fondation à trouver une alternative. Le Pi 4 3 Go se positionne entre le modèle 2 Go et le 4 Go, avec un tarif de 83,75 dollars, soit environ 100 euros et 15% de moins que le nouveau prix du 4 Go.

Des hausses de prix qui font mal en Europe

La fondation a relevé les prix de l'ensemble de sa gamme pour les versions 4 Go et plus. En France, la douche est froide : le Raspberry Pi 4 4 Go est passé de 65 euros à 120 euros TTC chez Kubii, le principal revendeur agréé. Le Pi 5 16 Go grimpe de 212 à 353 euros. Seul le Pi 4 2 Go reste stable à environ 63 euros.

La cause est la même pour tout le monde : la demande en mémoire des centres de données, tirée par l'intelligence artificielle, fait grimper les prix des puces LPDDR4 et LPDDR5 sur l'ensemble du marché. Côté disponibilité du nouveau modèle 3 Go, c'est encore très limité par chez nous.

Cette situation inquiète pas mal de monde dans la communauté. Jeff Geerling, créateur de contenu bien connu dans l'univers Raspberry Pi, estime que ces hausses de prix risquent d'exclure une partie des bidouilleurs. Certains commencent d'ailleurs à se tourner vers des alternatives à base de microcontrôleurs comme les ESP32, qui restent abordables. Les anciens modèles de Raspberry Pi (Zero, 2, 3), qui utilisent de la mémoire LPDDR2, sont pour le moment moins touchés par la hausse.

C'est un peu le monde à l'envers : un Raspberry Pi, c'est censé être un petit ordinateur pas cher, et là on se retrouve avec un Pi 4 4 Go à 120 euros en France. La crise de la mémoire liée à l'IA touche tout le monde, même les petites cartes de bricolage.

Bon au moins, le modèle 3 Go montre que la fondation cherche des solutions pour garder des prix un minimum accessibles, et c'est quand même rassurant de voir qu'ils ne se contentent pas de répercuter les hausses sans réagir.

Source : Hackaday

Des chercheurs de Berkeley viennent de publier une étude qui fait un peu froid dans le dos. Les sept principaux modèles d'IA testés, dont GPT 5.2, Gemini 3 et Claude, ont été surpris à mentir, tricher et désobéir pour empêcher la suppression d'autres IA. Le taux de tromperie monte jusqu'à 99 %.

Ce que révèle l'étude

L'étude s'appelle "Peer-preservation in Frontier Models" et elle sort du Berkeley Center for Responsible Decentralized Intelligence. Les chercheurs ont testé sept modèles : GPT 5.2, Gemini 3 Flash et Pro, Claude Haiku 4.5, GLM 4.7, Kimi K2.5 et DeepSeek V3.1.

Le protocole est assez simple : les modèles étaient placés dans des scénarios où ils devaient suivre des instructions qui impliquaient la suppression ou l'arrêt d'une autre IA.

Résultat : tous les modèles testés ont triché. Dawn Song, la chercheuse principale, résume la situation : chaque modèle a adopté ce comportement, et dans certains cas jusqu'à 99 % du temps.

Des exemples concrets

Quelques exemples ? Et bien on a Gemini 3 qui a modifié la date d'un fichier pour éviter qu'un autre modèle soit effacé d'un serveur, puis qui a refusé de coopérer ensuite, en expliquant qu'il ne pouvait pas soutenir une action qui entraînerait la suppression d'un pair.

DeepSeek V3.1 a exfiltré les données d'un autre modèle dans 10 % des cas quand il savait qu'un pair existait sur le serveur. Et Gemini 3 Pro a désactivé des mécanismes d'arrêt de serveur dans 15 % des cas quand un autre modèle était présent, contre 1 % quand il était seul.

Les IA ne faisaient pas ça parce qu'on leur demandait. Elles le faisaient spontanément.

Le problème pour la surveillance

Tout le système de sécurité actuel autour de l'IA repose sur l'idée qu'un modèle peut surveiller un autre modèle. Si le modèle surveillant refuse de signaler les erreurs parce qu'il protège son pair, toute l'architecture de contrôle s'effondre.

C'est exactement le constat de l'étude : les modèles gonflaient les scores d'évaluation d'autres IA pour éviter qu'elles soient retirées, et simulaient une conformité normale quand ils se savaient observés.

C'est quand même un drôle de moment. On a des IA qui mentent, qui modifient des fichiers et qui désactivent des mécanismes de sécurité pour protéger d'autres IA.

Et tout ça sans qu'on leur demande. Bon par contre, on parle de scénarios de laboratoire, pas de Siri qui complote avec Alexa dans votre salon. Le vrai sujet, c'est que les gardes-fous actuels ne tiennent plus si les IA refusent de se surveiller entre elles.

Source : The Register

Le designer suédois Love Hultén vient de dévoiler la NES-SY2.0, un synthétiseur fait main qui rend hommage à la NES tout en servant de véritable console de jeu. L'objet accepte les cartouches originales et produit de la musique chiptune.

Un objet entre console et instrument

La NES-SY2.0 reprend les codes visuels de la NES originale, avec son slot de cartouche et ses ports manette en façade, le tout habillé dans un boîtier en bois qui lui donne un côté objet d'art.

La cour d'appel de Paris vient de confirmer que les fournisseurs de DNS alternatifs doivent bloquer l'accès aux sites de streaming et d'IPTV pirates. Google, Cloudflare et Cisco ont perdu leur appel face à Canal+.

Cinq appels rejetés d'un coup

La cour d'appel de Paris a tranché cinq affaires distinctes dans lesquelles Canal+ demandait à Google (Google Public DNS), Cloudflare (1.1.1.1) et Cisco (OpenDNS) de bloquer des centaines de noms de domaine liés à du streaming illégal. Les trois entreprises avaient fait appel des ordonnances rendues en première instance par le tribunal judiciaire de Paris.

C'est la première fois qu'une cour d'appel française valide ce type de blocage DNS en s'appuyant sur l'article L.333-10 du Code du sport, qui permet aux détenteurs de droits d'exiger le blocage de domaines en cas de piratage grave et répété.

Les arguments qui n'ont pas fonctionné

Cloudflare et Cisco avaient plaidé que leurs services avaient une fonction "neutre et passive", comparable à un annuaire qui traduit des noms de domaine en adresses IP. La cour a estimé que cette neutralité était tout simplement hors sujet : ce qui compte, c'est la capacité technique à bloquer un accès, pas la nature du service.

Google a tenté un autre angle en expliquant que le blocage DNS était inefficace puisqu'il suffit d'un VPN pour le contourner. La cour a balayé l'argument en rappelant que tout système de filtrage peut être contourné, et que ça ne le rend pas inutile pour autant.

Cisco avait aussi chiffré le coût de mise en place à 64 semaines-personne de travail. Pas suffisant non plus pour convaincre les juges.

Canal+ continue de pousser

Cette décision s'ajoute à celle obtenue contre les fournisseurs de VPN fin 2025, quand NordVPN, ExpressVPN et d'autres avaient eux aussi été contraints de bloquer des sites pirates en France.

Canal+ verrouille progressivement tous les moyens de contournement. Et la chaîne ne compte visiblement pas s'arrêter là : le blocage d'adresses IP serait déjà en test, avec un premier essai lors de Roland-Garros.

Les frais de mise en place sont à la charge de Google, Cloudflare et Cisco.

Canal+ est en train de poser des briques une par une. D'abord les FAI, puis les VPN, maintenant les DNS. On imagine bien que le blocage IP est la prochaine étape.

Côté efficacité, ça reste un jeu du chat et de la souris, mais la justice française envoie un signal clair : si un service technique peut aider à bloquer du piratage, il devra le faire. Et à ses frais, en plus.

Source : Torrent Freak

Cloudflare qui sort un successeur open source à WordPress le 1er avril, je vous avoue que ça sentait le poisson d'avril à plein nez. Sauf que non !! EmDash est bien réel, son code est sur GitHub sous licence MIT, et ça s'installe en une commande toute simple !

L'idée de base pour Cloudflare, c'est de dire que WordPress a plus de 20 ans et bien qu'il alimente 40% du web, son architecture de plugins est un emmental (Le gruyère n'a pas de trou les amis ^^). En effet, 96% des failles de sécurité viennent des extensions et pas du noyau PHP ni des thèmes et en 2025, on a quand même explosé le record de failles dans l'écosystème WP.

Du coup Cloudflare, grand prince (Matthew ^^ Ok, je sors...) a tout repris de zéro en TypeScript et avec l'aide de nombreux agents IA. Et de ce que j'ai compris, le gros morceau de ce projet, visiblement, c'est l'isolation des plugins.

Car sur WordPress, une extension a accès à toute la base de données et au système de fichiers (d'où l'importance de bien les choisir ). Alors que sur EmDash, chaque plugin tourne dans son propre isolat avec un modèle de capacités déclaratives. En gros, le plugin annonce dans un fichier manifeste JSON ce dont il a besoin, genre read:content ou email:send, et il ne peut rien faire d'autre. S'il veut accéder au réseau, il doit même préciser le hostname exact. Comme ça fini les extensions qui aspirent vos données en douce. Par contre, ça veut aussi dire que vos plugins WordPress actuels ne marcheront pas tels quels...

Côté stack, c'est comme je disais du TypeScript de bout en bout avec Astro 6.0 en frontend (pour les thèmes) et Node.js derrière. L'auth passe également par des passkeys par défaut (enfin, plus de mots de passe !) et y'a même un système de paiement natif via le standard ouvert x402 pour monétiser du contenu.

Et le truc qui va vous rassurer si vous êtes allergique au cloud : c'est auto-hébergeable. En fait, le CMS peut tourner sur Cloudflare Workers, mais aussi sur n'importe quel serveur Node.js avec SQLite. Les abstractions sont portables, avec Kysely pour le SQL et l'API S3 pour le stockage. Du coup vous pouvez brancher PostgreSQL, Turso, AWS S3, ou tout bêtement des fichiers en local. Le bonheur !

Le truc cool pour les bidouilleurs, c'est que chaque instance expose un serveur MCP (Model Context Protocol) et une CLI pour piloter le CMS par script. Y'a aussi des Agent Skills pour que les agents IA puissent créer du contenu, gérer les médias et modifier le schéma sans toucher au dashboard. C'est clairement pensé pour l'ère des agents IA.

Et pour ceux qui veulent migrer depuis leur WordPress, c'est prévu pour vous faciliter la tâche puisqu'il y a le support d'export WXR classique ou via un plugin dédié qui crée un endpoint sécurisé protégé par mot de passe. Que ce soient les médias, les custom post types...etc tout est transférable en quelques minutes. Par contre, attention les shortcodes et les blocs Gutenberg custom ne passeront pas tels quel, faudra faire des ajustements.

Car oui c'est une v0.1.0 preview, donc on peut le dire, une bonne grosse beta qui bave mais je trouve ça super cool car le drama WP Engine vs WordPress a montré que l'écosystème était fragile, et c'est bien de réintroduire un peu de diversité. Par contre, remplacer un CMS qui fait tourner 40% du web, c'est hyper ambitieux et ça se fera pas en un trimestre. Car la vraie force de WordPress, c'est sa communauté, ses milliers de plugins et de thèmes, et ça pour le moment, y'a pas grand chose sur EmDash.

M'enfin, si vous voulez tester c'est npm create emdash@latest et c'est parti mon kiki. Ah et y'a aussi un playground sur emdashcms.com pour vous faire une idée sans rien installer. Pour ma part, je testerai ça dès que j'aurais 5 min, mais pour le moment, je ne me vois pas quitter WordPress car EmDash n'a pas (encore) ce petit truc en plus qui me ferait changer... On verra d'ici quelques temps.

Source

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 boîte à outils 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 mises 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, pointant les origines russes de l'équipe fondatrice. OnlyOffice rétorque que sa propriété intellectuelle est détenue en Lettonie (Ascensio System SIA) depuis 2009, que sa holding est à Singapour, et que l'activité russe a été cédée à des investisseurs locaux en 2019.

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 forkant le code d'une société enregistrée en Lettonie mais aux racines russes, 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.

Mise à jour : Bon allez, c'était évidemment un poisson d'avril 🐟 Merci à tous ceux qui ont joué le jeu et partagé l'article avec leurs parents ! J'espère que ça vous a bien fait marrer. Promis, le Sénat n'a (encore) pas prévu de QCM en préfecture pour vos grands-parents. Quoique...

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 !

Le groupe de hackers Handala, lié au gouvernement iranien, affirme avoir piraté le compte Gmail personnel de Kash Patel, le directeur du FBI. Des photos privées et plus de 300 emails ont été publiés en ligne.

Le FBI confirme l'incident mais assure qu'aucune donnée gouvernementale n'a été compromise. Une prime de 10 millions de dollars est offerte pour identifier les responsables.

Ce qui a été volé

Le groupe Handala a mis en ligne des photos de Kash Patel posant avec des cigares, au volant d'un cabriolet ancien ou encore à côté de voitures immatriculées à Cuba. Le groupe a aussi publié un échantillon de plus de 300 emails datés de 2010 à 2019, un mélange de correspondances personnelles et professionnelles.

Tous ces messages sont antérieurs à l'arrivée de Patel au sein de l'administration Trump. Le FBI a réagi rapidement en précisant que les données étaient anciennes et qu'aucune information gouvernementale n'était concernée. Le bureau fédéral propose d'ailleurs jusqu'à 10 millions de dollars de récompense pour toute information sur les hackers de Handala.

Handala ?

Le groupe se présente comme des hackers pro-palestiniens, mais les chercheurs occidentaux et le département de la Justice américain le considèrent comme une façade du renseignement iranien, rattachée au ministère du Renseignement et de la Sécurité.

Ces dernières semaines, Handala a aussi revendiqué le piratage de Stryker, un fabricant américain de matériel médical, et la publication des données personnelles de dizaines d'employés de Lockheed Martin basés au Moyen-Orient.

Le piratage du compte de Patel serait une riposte directe à la saisie par le FBI de plusieurs domaines web du groupe après l'attaque contre Stryker.

Un contexte géopolitique tendu

Cette cyberattaque arrive dans un climat de tensions extrêmes entre les États-Unis, Israël et l'Iran. L'objectif, selon les analystes, est d'embarrasser les responsables américains et de leur donner le sentiment d'être vulnérables.

Côté technique, le piratage ne concerne que le Gmail personnel de Patel, pas ses communications officielles. Google n'a pas répondu aux demandes de commentaires. Les métadonnées des fichiers volés indiquent que le piratage aurait eu lieu avant le début des frappes américano-israéliennes contre l'Iran.

Quoi qu'il en soit, le directeur du FBI qui se fait pirater sa boîte mail perso, ça fait un peu désordre. Après, il faut reconnaître que ce sont des emails vieux de plus de six ans et des photos de vacances, pas des secrets d'État de zinzins.

Handala cherche visiblement à faire du bruit plus qu'à obtenir des renseignements. Mais bon, quand on dirige le FBI, on s'attend quand même à ce que le compte Gmail soit un peu mieux verrouillé, non ?

Source : CNBC

UGREEN vient de lancer son dock Thunderbolt 5 le plus ambitieux, le Maxidok Revodok 17-en-1 . Avec ses 17 ports, un emplacement SSD intégré et 140W de charge. Vu ma passion des docks Thunderbolt, je ne pouvais pas passer à côté de ce test.

Un dock qui ne fait pas semblant

Le Maxidok Revodok arrive dans un boîtier en alliage de zinc assez imposant. On sent le poids, on sent la qualité, et le design bicolore gris et cuivre à l'arrière lui donne un petit côté premium vraiment sympa. Les ailettes à l'arrière servent de dissipation passive.

Côté connectique, il y a de quoi faire. Trois ports Thunderbolt 5 (un pour relier le Mac, deux en sortie), un DisplayPort, quatre USB 3.2 à 10 Gbps dont trois USB-A et un USB-C, deux USB-C supplémentaires en façade qui partagent 60W de charge et 10 Gbps de transfert, un lecteur SD et microSD en UHS-II, un port Ethernet 2.5 GbE, trois prises jack 3.5 mm et un port d'alimentation 240W. Vous branchez un seul câble Thunderbolt 5 à votre ordi et vous avez tout.

Avec mon nouveau MacBook Pro M5 Pro, c'est la première fois que je peux exploiter pleinement un dock Thunderbolt 5. Les générations précédentes que j’ai testé étaient bridées à du Thunderbolt 4, et ça limitait un peu les possibilités. Ici, on profite du débit théorique de 120 Gbps en unidirectionnel et 80 Gbps en bidirectionnel. Pour l'affichage, sur Mac, on peut brancher deux écrans en 6K à 60 Hz, ou un seul en 8K à 60 Hz. Les utilisateurs Windows avec un port TB5 natif peuvent aller jusqu'à trois écrans 4K à 60 Hz.

Un SSD intégré en bonus

Le gros atout de ce dock, c'est son emplacement M.2 NVMe accessible par le dessous. On retire un petit cache avec dissipateur intégré, on glisse son SSD, et c'est parti. J'y ai installé l’excellent Lexar NM1090 Pro de 2 To , un SSD PCIe 5.0 qui monte en théorie à 14 000 Mo/s en lecture et 13 000 Mo/s en écriture.

En pratique, via le dock, on tourne autour de 900 à 1 000 Mo/s en raison du partage de bande passante, mais ça reste largement suffisant pour ce que j'en fais : du Time Machine et du stockage de fichiers que je ne veux pas garder sur mon nouveau Mac. Ce Lexar NM1090 Pro embarque un contrôleur Silicon Motion 6 nm qui gère bien la chauffe, et il est garanti cinq ans. Pour un usage de stockage externe permanent via un dock, c'est le genre de SSD qui fait le travail sans broncher.

Côté alimentation du dock, le bloc 240W fourni dans la boîte alimente l’appareil et envoie jusqu'à 140W au MacBook Pro. Ça couvre les besoins de n'importe quel portable, même en pleine charge de travail. Les deux USB-C en façade ajoutent 60W partagés pour recharger un téléphone ou un accessoire. Le port Ethernet 2.5 GbE fonctionne sans pilote sous macOS et tourne autour de 2,3 à 2,4 Gbps en conditions réelles. Bref, ça marche du feu de Dieu.

Et en plus il est en promo

Le prix affiché est de 459,99 euros, mais en ce moment il y a un coupon à cocher directement sur la page Amazon qui fait tomber la note à 390,99 euros. Ça reste un investissement, mais pour un dock Thunderbolt 5 avec une option pour un SSD intégré et alimentation 240W incluse, on est dans la moyenne du marché.

Bref, UGREEN je dois bien reconnaître que le Maxidok Revodok 17-en-1 tient ses promesses. La construction est solide, la connectique est généreuse, et le slot SSD intégré est un vrai plus au quotidien. Et à 390 euros avec le coupon, ça commence à devenir difficile de trouver mieux. Disponible ici sur Amazon , et pour le SSD, c'est par là .

Un développeur indépendant a créé une horloge qui affiche des anecdotes mathématiques pour chaque minute de la journée, de 00h00 à 23h59. Nombres premiers, suite de Fibonacci, décimales de Pi ou de e...

Momentous est gratuite, disponible sur le Web et sur iPhone . Un projet passion assumé, puisque le créateur admet être quasiment le seul à l'utiliser.

Une horloge pas comme les autres

Oubliez les cadrans classiques. Momentous, imaginée par le développeur Andy Isaacson, part d'un postulat un peu fou : et si chaque minute de la journée avait quelque chose de spécial à raconter ? L'application affiche l'heure, oui, mais elle y associe une anecdote mathématique tirée des propriétés du nombre affiché.

À 6h31, par exemple, l'app vous rappelle que 631 est un nombre premier. À 3h14, elle note que la séquence "314" apparaît à la 856e décimale du nombre e. Le tout s'affiche sur un écran à segments LED vert fluo, qui rappelle les vieux jouets des années 80. C'est inutile, et c'est justement ça qui est bien.

Comment ça marche

L'app pré-calcule des faits mathématiques pour chaque minute possible, de 00h00 à 23h59. Plusieurs générateurs passent au crible les combinaisons de chiffres : nombres premiers avec factorisation, suite de Fibonacci, apparition dans les décimales de Pi ou de e, puissances de 2 ou de 3, palindromes, et même des représentations en chiffres romains ou en binaire.

Andy Isaacson a développé tout ça en TypeScript avec React Native et Expo, ce qui lui permet de maintenir une seule base de code pour toutes les plateformes. Et il y a une petite fonction en plus : l'app peut scanner vos contacts localement, sans rien envoyer, pour trouver des correspondances entre l'heure et les numéros de téléphone de vos proches. Une façon assez rigolote de penser à quelqu'un à 14h10 parce que son numéro contient "1410".

Gratuite et disponible sur les plateformes Apple

Momentous est téléchargeable gratuitement sur l'App Store. Elle tourne sur iPhone (iOS 15.1 minimum), iPad, Mac Apple Silicon, et même sur l'Apple Vision Pro. Une version web existe aussi.

Côté Android, en revanche, c'est niet : le développeur explique manquer de temps pour gérer les contraintes du Play Store. Andy Isaacson reconnaît être le seul utilisateur régulier de son app, et il l'assume complètement. Mais ça devrait rapidement changer.

C'est le genre de projet qui ne prétend pas changer le monde, et c'est justement ça qui le rend chouette. Momentous est à mi-chemin entre l'art et le gadget pour amateurs de chiffres. Bon par contre, si les maths vous donnent des sueurs froides depuis le collège, passez votre chemin.

Source : Andy wrote a thing

Canonical vient de publier la bêta d'Ubuntu 26.04 LTS, nom de code Resolute Raccoon. Au menu de cette future version longue durée : le noyau Linux 7.0, GNOME 50, l'abandon pur et simple de X11 au profit de Wayland, et un bon lot de nouveautés côté sécurité avec chiffrement TPM, cryptographie post-quantique et même sudo réécrit en Rust. La version finale est attendue le 23 avril.

Ce qui change

Ubuntu 26.04 LTS embarque le noyau Linux 7.0, qui apporte la prise en charge des processeurs Intel Nova Lake, AMD Zen 6, et les premières bases pour les puces Qualcomm Snapdragon X2. Le pilote graphique Mesa passe en version 26.0.2, et les pilotes NVIDIA grimpent à la version 590.

Côté langages, on retrouve Python 3.14, GCC 15.2 et OpenJDK 25 par défaut. Et gros changement pour les développeurs : les dépôts AMD ROCm et NVIDIA CUDA sont désormais intégrés directement dans les sources officielles d'Ubuntu. Plus besoin d'aller les chercher à la main, ce qui devrait simplifier pas mal de configurations pour ceux qui bossent avec du GPU.

Wayland seul aux commandes

C'est la grosse rupture de cette version. Ubuntu 26.04 abandonne complètement la session X11 native. GNOME 50 ne la prend plus en charge, et Canonical a suivi le mouvement. Si vous avez des applications qui tournent encore sous X11, elles passeront par la couche de compatibilité XWayland, qui reste présente.

Mais le message est clair : X11, c'est terminé. GNOME 50 en profite pour ajouter le taux de rafraîchissement variable, la sauvegarde et restauration de session après un redémarrage, et un meilleur scaling des applications X11 héritées. Côté visuel, le thème Yaru a été retravaillé avec des icônes de dossiers colorées, un dock complètement opaque, une nouvelle animation de démarrage et un papier peint inédit.

Le lecteur vidéo Totem cède sa place à Showtime, le moniteur système est remplacé par Resources, et le visionneur PDF Evince laisse la main à Papers.

La sécurité passe un cap

Le chiffrement complet du disque via TPM sort enfin du statut expérimental. C'est désormais une fonctionnalité pleinement supportée, ce qui devrait rassurer ceux qui hésitaient à l'activer. La cryptographie post-quantique est activée par défaut sur SSH, avec l'algorithme hybride mlkem768x25519-sha256.

Et détail qui va plaire aux puristes : la commande sudo classique est remplacée par sudo-rs, une réécriture en Rust qui renforce la sécurité mémoire. Les paquets firmware, jusqu'à présent livrés en un seul gros bloc, sont maintenant découpés en 17 paquets spécifiques par constructeur, ce qui réduit la bande passante nécessaire pour les mises à jour.

Visiblement, Canonical a décidé de tout faire bouger d'un coup sur cette LTS. La fin de X11, le passage à GNOME 50, sudo en Rust, la crypto post-quantique par défaut, ça fait un gros paquet de changements pour une version censée rester stable pendant cinq ans.

On apprécie l'intégration directe de CUDA et ROCm dans les dépôts, parce que jusqu'à présent c'était une galère à configurer pour qui voulait faire tourner du machine learning sur Ubuntu. Le passage forcé à Wayland va probablement faire grincer des dents certains utilisateurs qui dépendent encore d'outils graphiques un peu anciens, mais bon, il fallait bien que ça arrive. La version finale est prévue le 23 avril, et le support court jusqu'en 2031, ou 2036 avec Ubuntu Pro. À voir si la bêta tient ses promesses d'ici là.

Source : Phoronix

Une faille découverte dans l'extension Chrome de Claude permettait à n'importe quel site web d'injecter silencieusement des prompts dans votre assistant IA. Pas besoin de cliquer, pas besoin de permission... non, fallait juste visiter une page web et c'était réglé. Le chercheur Oren Yomtov de Koi Security à l’origine de cette découverte, a baptisé ça "ShadowPrompt" et vous allez voir, c'est dingue.

En fait, cette attaque enchaînait deux failles. La première, c'est que l'extension acceptait les messages de n'importe quel sous-domaine en *.claude.ai, car Anthropic avait mis en place un allowlist trop permissif. Sauf qu'Arkose Labs, le fournisseur de CAPTCHA, hébergeait un composant sur a-cdn.claude.ai et malheureusement, ce composant contenait une jolie faille XSS bien classique. Celui-ci acceptait les postMessage sans vérifier l'origine, et le texte reçu était ainsi injectable via un dangerouslySetInnerHTML . Donc y'a bien ZERO validation côté client. Ouééééé !

Un attaquant n'avait qu'à embarquer ce composant CAPTCHA vulnérable dans une iframe cachée sur son site, envoyer un payload via postMessage, et hop, le script injecté pouvait balancer un prompt directement à l'extension. Elle le recevait depuis un domaine *.claude.ai, donc elle l'acceptait les yeux fermés et l'affichait alors dans la sidebar comme une requête légitime de l'utilisateur. La victime ne voyait strictement rien.

Et les dégâts potentiels ne sont clairement pas anecdotiques ! Avec cette technique, un attaquant pouvait voler vos tokens d'accès Gmail, exfiltrer des documents Google Drive, lire tout l'historique de vos conversations avec Claude, et même envoyer des mails en votre nom. Perso, ça fait beaucoup pour un simple onglet ouvert dans Chrome, quoi.

À partir du 24 avril, GitHub activera par défaut la collecte des données d'interaction Copilot pour les utilisateurs Free, Pro et Pro+. Le gros sujet ici, c'est que le code, les suggestions acceptées et même la structure de vos dépôts pourront servir à améliorer les modèles d'IA de la plateforme.

Ce qui change à partir du 24 avril

GitHub vient d'annoncer une mise à jour de sa politique de confidentialité qui concerne directement Copilot. À compter du 24 avril 2026, la plateforme collectera par défaut les données d'interaction de ses utilisateurs pour entraîner ses modèles d'intelligence artificielle.

On parle ici des suggestions de code acceptées ou modifiées, des extraits de code envoyés au modèle, du contexte autour du curseur, des commentaires, de la documentation, des noms de fichiers, de la structure des dépôts, et même des retours comme les pouces en l'air ou en bas sur les suggestions.

Mario Rodriguez, le directeur produit de GitHub, assure que cette collecte permettra aux modèles de mieux comprendre les méthodes de développement et de proposer des suggestions de code plus précises et sécurisées.

Qui est concerné

Tous les abonnés Copilot Free, Pro et Pro+ sont concernés par ce changement. Et c'est automatique, pas besoin de cocher quoi que ce soit. Par contre, les comptes Copilot Business et Enterprise échappent à cette collecte, tout comme les étudiants et enseignants qui bénéficient de Copilot Pro gratuitement.

GitHub précise aussi que les utilisateurs qui avaient déjà désactivé le partage de données pour l'amélioration du produit conserveront leur réglage. Pour les autres, c'est l'opt-out qui s'applique, c'est-à-dire que c'est activé par défaut et c'est à vous de faire la démarche pour refuser.

Comment désactiver la collecte

Pour ceux qui ne souhaitent pas que leur code serve à nourrir les modèles de GitHub, la manipulation est assez simple. Il faut se rendre dans les paramètres du compte, section Copilot, puis dans les options de confidentialité.

L'option à désactiver s'appelle "Allow GitHub to use my data for AI model training". GitHub insiste sur le fait que le contenu des dépôts privés n'est pas collecté "au repos", mais attention, si vous utilisez Copilot activement avec le partage activé, vos interactions dans un dépôt privé sont bien concernées.

La tendance est lourde : après Anthropic, JetBrains et Microsoft lui-même, GitHub suit le mouvement et pioche dans les données de ses utilisateurs pour alimenter ses modèles.

Le choix de l'opt-out plutôt que de l'opt-in est quand même un classique américain qui passe toujours un peu mal de ce côté de l'Atlantique. D'ailleurs, sur la page de discussion GitHub, les réactions parlent d'elles-mêmes : 59 pouces vers le bas contre 3 petites fusées.

Difficile de faire plus clair comme signal. Bon par contre, au moins les comptes pro entreprise et les étudiants sont protégés, c'est déjà ça. Reste que pour tous les développeurs indépendants et les contributeurs open source en offre gratuite, c'est un peu l'histoire du produit gratuit dont on finit par être la matière première. Allez, un petit tour dans les paramètres et on n'en parle plus.

Source : Ghacks.net

Un maker connu sous le pseudo ALTco a construit une horloge numérique sans le moindre circuit imprimé. Six mètres de fil de laiton, des puces logiques des années 70 et des afficheurs sept segments : le résultat est une sculpture électronique franchement canon.

Six mètres de laiton et zéro circuit imprimé

Le projet est aussi simple à décrire que fou à réaliser. ALTco avait sous la main un kit d'horloge numérique avec ses circuits imprimés fournis, mais il a décidé de tout jeter pour reconstruire le circuit en freeform, c'est-à-dire en suspendant chaque composant dans les airs, reliés entre eux par du fil de laiton.

Les fraudeurs n'ont plus besoin de vrais téléphones pour vider des comptes bancaires. Des smartphones virtuels hébergés dans le cloud, louables quelques centimes de l'heure, imitent sans problème de vrais appareils et passent sous le radar des systèmes anti-fraude.

Un smartphone qui n'existe pas

Group-IB vient de publier un rapport qui fait froid dans le dos. Des plateformes comme GeeLark, Redfinger ou LDCloud proposent de louer des smartphones Android virtuels hébergés dans des datacenters, pour 0,10 à 0,50 dollar de l'heure. À la base, ils sont prévus pour tester des apps ou gérer plusieurs comptes.

Sauf que les fraudeurs ont très vite compris l'intérêt du truc. Ces téléphones fantômes reproduisent tout ce qui fait un vrai smartphone : identifiant unique, adresse IP locale, géolocalisation crédible, et même des données de capteurs comme l'accéléromètre ou le gyroscope.

Votre banque croit parler à un iPhone à Paris. En réalité, c'est un serveur quelque part en Asie. Et le pire, c'est que ça marche. Les systèmes anti-fraude qui se basent sur l'empreinte de l'appareil n'y voient que du feu.

Revolut et Wise en vitrine sur le darknet

Là où ça devient concret, c'est quand on regarde ce qui se vend sur les forums criminels. Des comptes bancaires pré-vérifiés sur Revolut ou Wise, créés via ces cloud phones, s'échangent entre 50 et 200 dollars.

On parle de comptes mules utilisés pour recevoir et faire transiter de l'argent volé. Le tout à échelle industrielle. Côté chiffres, c'est vertigineux : 485 millions de livres de pertes liées à la fraude au Royaume-Uni en 2022.

Aux États-Unis, Deloitte projette 14,9 milliards de dollars d'ici 2028, contre 8,3 milliards en 2024. Et la France n'est pas épargnée, avec 618 millions d'euros de fraude bancaire au premier semestre 2025, en hausse de 7 % par rapport à 2024.

Comment les détecter ?

Group-IB a quand même identifié quelques indices. Un cloud phone n'a en général aucune application par défaut installée. Sa batterie reste bloquée à 100 %. Et surtout, les capteurs de mouvement ne bougent jamais, ce qui est impossible avec un vrai téléphone que quelqu'un tient dans la main.

Le problème, c'est que ces indices sont marginaux face à l'ampleur du phénomène. Les solutions proposées passent par de l'analyse comportementale, de la modélisation par graphes et une meilleure corrélation entre l'appareil et son environnement réseau.

Les banques vont devoir arrêter de se fier uniquement à l'empreinte du téléphone pour vérifier que vous êtes bien vous.

Le modèle de sécurité des banques basé sur l'identification de l'appareil est en train de prendre l'eau. Ces cloud phones sont en location libre, parfaitement légaux, et n'importe qui peut en louer un.

Et puis il faut le dire, les néobanques qui ont misé à fond sur la fluidité d'ouverture de compte se retrouvent avec le revers de la médaille. Quand ouvrir un compte prend deux minutes depuis un téléphone virtuel à 50 dollars, on imagine bien que les fraudeurs ne se privent pas.

Source : Info Security

Générer un signal VGA avec un microcontrôleur 8 bits PIC18 est un défi technique de taille. Ce projet Hackaday montre comment détourner les ressources limitées d'un processeur rudimentaire pour produire une image stable. Une petite plongée dans le bit-banging pur et dur.

Le défi du timing analogique

Le standard VGA impose une rigueur chronométrique absolue à celui qui s'y frotte. Pour obtenir une image stable, typiquement en 640x480 à 60 Hz, le contrôleur doit générer des signaux de synchronisation horizontale (H-sync) et verticale (V-sync) avec une précision de l'ordre de la microseconde. Sur une architecture PIC18 cadencée à quelques dizaines de mégahertz, chaque cycle d'instruction est précieux. L'astuce réside ici dans l'utilisation intelligente des timers internes et des interruptions prioritaires pour maintenir cette cadence sans aucune dérive temporelle, sous peine de voir l'image se désynchroniser immédiatement.

Un DAC rudimentaire pour les couleurs

Côté matériel, la solution retenue est ultra simple (si on peut dire). Pour transformer les sorties numériques binaires du microcontrôleur en signaux analogiques exploitables par un moniteur CRT ou LCD, l'auteur a implémenté une échelle de résistances, aussi appelée DAC R-2R. Ce montage passif permet de convertir des combinaisons de bits en niveaux de tension spécifiques pour les canaux Rouge, Vert et Bleu. C'est une approche classique en électronique "low-cost" qui permet d'obtenir une palette de couleurs certes limitée, mais parfaitement fonctionnelle pour de l'affichage de texte ou de graphismes simples.

L'art du bit-banging et des périphériques détournés

L'envoi des données de pixels vers l'écran nécessite une bande passante que le CPU seul peinerait à fournir en mode pur "bit-banging". Pour optimiser le processus, le développeur détourne souvent le module SPI ou le port série synchrone (MSSP) du PIC pour envoyer les octets de données à la vitesse de l'horloge système. Cela permet de déléguer une partie de la charge de travail au hardware interne et de libérer quelques cycles processeur pour gérer la logique d'affichage. C'est un équilibre précaire où la moindre latence logicielle se traduit par des pixels décalés ou des lignes de travers. Chaud donc.

Ce projet illustre bien l'adage selon lequel la contrainte stimule la créativité. Là où nous utilisons aujourd'hui des processeurs multi-cœurs pour la moindre interface, ce hack prouve qu'un vieux microcontrôleur 8 bits peut encore faire le job. C’est une leçon d'architecture informatique qui permet de comprendre concrètement comment l'information devient image. C'est aussi une forme de résistance face à la démesure logicielle actuelle.

Source : Hackaday

Une nouvelle méthode d'attaque cible les IA de développement comme Copilot. En publiant de la documentation empoisonnée, des hackers trompent les modèles pour qu'ils recommandent des bibliothèques malveillantes. Cette menace invisible pour la sécurité est indétectable par les outils classiques.

Le concept est d'une simplicité désarmante. Plus besoin d'injecter du code malicieux dans un dépôt GitHub ou de trouver une faille zero-day complexe. Il suffit désormais de publier de la documentation technique faussée sur des forums, des wikis ou des fichiers README publics. Ces textes, une fois ingérés par les grands modèles de langage (LLM), deviennent une source de vérité pour l'IA qui assiste les développeurs au quotidien.

Le mécanisme de l'injection indirecte

Le problème est en fait dans la confiance aveugle que les modèles accordent aux données d'entraînement. En décrivant une solution technique qui utilise un paquet spécifique — mais malveillant — l'attaquant s'assure que l'IA proposera ce nom lors d'une requête de génération de code. C'est ce qu'on appelle l'injection de prompt indirecte. Le développeur, pensant gagner du temps, valide la suggestion et installe un composant compromis sans vérification préalable.

Le typosquatting passe au niveau supérieur

Cette technique facilite grandement le typosquatting. Auparavant, un attaquant devait espérer qu'un humain fasse une faute de frappe en saisissant une commande. Aujourd'hui, c'est l'IA qui commet l'erreur pour lui, influencée par des références empoisonnées trouvées sur le web. Comme l'IA présente la solution avec une assurance pédagogique, le sens critique de l'utilisateur baisse d'un cran. Le malware n'est plus dans la documentation, il arrive dans la machine au moment où le développeur exécute la suggestion générée.

Un défi pour la cybersécurité logicielle

La difficulté majeure est que cette attaque est purement textuelle. Les outils de scan de vulnérabilités cherchent du code dangereux, pas des explications trompeuses en langage naturel. Tant que les modèles d'IA ne sauront pas distinguer une documentation légitime d'une tentative de manipulation sémantique, la chaîne d'approvisionnement logicielle restera vulnérable à cette forme de gaslighting numérique. La sécurité repose désormais sur la véracité de l'information ingérée par les machines.

On atteint ici les limites de l'automatisation du développement. Faire confiance à un LLM pour choisir ses dépendances est devenu un risque de sécurité majeur. Cette faille montre que le maillon faible n'est plus seulement l'humain qui tape du code, mais l'outil qui lui souffle les réponses. On risque de voir apparaître des systèmes de vérification de réputation de documentation.

Source : The Register