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ébérgé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.

Hé 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 .

Le mouvement Stop Killing Games a officialisé son soutien à la Protect Our Games Act, un projet de loi californien qu'il a contribué à rédiger avec le député américain Chris Ward.

Le texte a été déposé sous la référence AB-1921 ("Digital games: ordinary use"), et il cible directement un des points douloureux du jeu vidéo moderne, les titres serveur-dépendants qui deviennent inutilisables quand l'éditeur décide de débrancher les serveurs.

La logique du texte est simple. Pour un jeu connecté vendu en Californie, l'éditeur aura deux options en fin de vie. Soit il remplace le jeu par une alternative comparable, sans coût supplémentaire pour le client.

Soit il publie un plan de fin de vie détaillant les étapes prises pour permettre aux joueurs de continuer à faire tourner leur jeu après l'arrêt du support officiel. Mode offline, serveur privé documenté, patch communautaire autorisé, c'est à l'éditeur de choisir le mécanisme. Mais il doit choisir quelque chose.

Pour rappel, Stop Killing Games est né en 2024 sous l'impulsion de Ross Scott, après l'arrêt brutal de The Crew par Ubisoft. Un jeu acheté, joué, puis tout simplement rendu injouable. Sans contrepartie.

Le mouvement a depuis bien grandi. En Europe, une Initiative citoyenne a recueilli un peu plus de 1,3 million de signatures validées, et la Commission européenne a jusqu'à fin juillet pour rendre sa réponse officielle. Une audition publique au Parlement européen est prévue le 16 avril.

L'angle californien est intéressant parce que la Californie a longtemps servi de laboratoire réglementaire pour le reste des États-Unis sur les questions consommateur et numérique.

Si AB-1921 passe, les éditeurs ne pourront plus faire semblant que le problème n'existe pas sur le marché américain. Et comme les équipes juridiques préfèrent rarement gérer 50 législations différentes, un texte californien peut aisément devenir une norme de facto pour l'ensemble des US.

Évidemment, la loi n'est qu'un projet pour l'instant, et l'industrie du jeu vidéo a des lobbyistes qui savent tuer ce genre de texte en commission. Mais l'énergie du mouvement est réelle, et le timing avec l'offensive européenne est bien calibré. Ça met la pression des deux côtés de l'Atlantique en même temps.

Bref, Stop Killing Games continue d'avancer sur plusieurs fronts, et forcer les éditeurs à penser à la fin de vie dès la conception, c'est plutôt sain.

Source : Techspot

OBS Studio 32.1 est donc disponible, environ cinq mois après la 32.0, avec deux changements structurants pour les streamers et créateurs de contenu.

Tout d'abord, un mixeur audio entièrement repensé. Ensuite le support du simulcast WebRTC, qui change la donne pour quiconque diffuse en WHIP.

Le nouveau mixeur audio propose désormais des dispositions horizontale et verticale, un bouton dans la barre d'outils pour basculer de l'une à l'autre, et la mise en page verticale est devenue le défaut. Un bouton permet aussi d'activer ou couper le monitoring audio directement depuis le mixeur, sans passer par le menu des sources.

C'est un ajustement qui n'a l'air de rien, sauf qu'en live avec une dizaine de sources audio, gagner deux clics à chaque manipulation change vraiment la vie. Les anciens utilisateurs garderont la disposition horizontale s'ils la préfèrent. Rien ne leur est imposé.

Côté diffusion, le support du simulcast WebRTC est la grosse nouveauté technique que beaucoup attendaient. Dans les faits, la sortie obs-webrtc peut désormais envoyer plusieurs niveaux de qualité sur une seule piste WHIP. Les spectateurs sur des connexions plus lentes reçoivent automatiquement un flux adapté, sans avoir à configurer quoi que ce soit côté streamer.

C'est exactement ce que YouTube et Twitch font depuis des années en fait avec leurs encodeurs cloud propriétaires, sauf qu'ici c'est géré en local, open source, sur le protocole standard WebRTC/WHIP. Pour les indépendants qui diffusent sur leur propre infra, c'est plutôt pas mal.

Le changelog de la mise à jour mentionne aussi le retour des actions undo et redo pour les éléments de scène, plusieurs améliorations de sécurité, et un bitrate par défaut remonté à 6000 kbps (en phase avec ce que demandent aujourd'hui les plateformes 1080p60). Rien de spectaculaire donc, mais l'accumulation de petites nouveautés fait une vraie montée de version.

OBS est probablement le logiciel open source le plus influent du monde du streaming, utilisé par quasiment tous les créateurs qui ne veulent pas payer un encodeur propriétaire.

Cette version 32.1 confirme que le projet avance bien, à un rythme soutenu, après une période où certains s'inquiétaient d'un ralentissement.

Pour les streamers qui ont déjà un setup complet, l'upgrade se fait sans problème. Pour ceux qui diffusent en WebRTC/WHIP et qui galéraient avec l'absence de simulcast, c'est l'upgrade à faire dès maintenant.

Bref, une très bonne release pour un outil qu'on a tendance à tenir pour acquis.

Source : Phoronix