Hacker News
-
Claude Opus 5.5
Anthropic lance Claude Opus 5.5, premier modèle de la famille Claude 5.5. Il atteint le niveau de Claude Fable 5.1 sur la plupart des tâches tout en coûtant 40 % moins cher à l'exécution qu'Opus 5 (4 $/20 $ par million de tokens en entrée/sortie, lectures de cache à 0,20 $, 60 % moins cher), et génère sa sortie plus de 30 % plus vite.
Le modèle se distingue en codage agentique : migration d'un code de 680 000 lignes en moins d'une journée, audit d'un codebase de 200 000 lignes en moins de trois heures (contre plus de 20 heures pour Opus 5), et une traduction de HAProxy du C vers Rust achevée en 9,5 heures avec 51 % d'économie. Sur les benchmarks de codage (FrontierCode, Terminal Bench 4.0, CursorBench), il surpasse GPT-6 Astra et GPT-5.6 Sol pour une fraction du coût. Il est également plus performant en travail de connaissance : 16 rapports sur 18 ont passé un contrôle qualité automatisé contre zéro pour Fable 5.1 et Opus 5.
Côté sûreté, Opus 5.5 obtient les meilleurs résultats à l'audit comportemental automatisé d'Anthropic, résiste mieux aux injections de prompt, intègre un classifieur qui vérifie chaque action d'agent, un sandbox open source et un mode rapide jusqu'à 2,5x. Les limites d'usage de cinq heures sont relevées sur les abonnements Pro, Max, Team et Enterprise. Claude Sonnet 5.5 et Haiku 5.5 suivront dans les semaines à venir.
La sortie de Claude Opus 5.5 divise peu sur les faits mais beaucoup sur leur interprétation. Plusieurs commentateurs relèvent une tension dans l'annonce elle-même : Anthropic avait appelé à « ralentir la frontière » la semaine précédente, et l'article s'ouvre sur ce rappel avant d'égrener des gains de performance chiffrés, ce que certains jugent « peu sincère » — d'autres répondent que le document consacre justement une section au pacing et que les gains correspondent surtout à une démocratisation de capacités existantes, proches de Fable.
Les points concrets qui fédèrent : la baisse des prix (4/20 $ par million de tokens, −20 % vs Opus 5, et surtout des cache reads à 0,20 $, soit −60 %, ramenant le cache à 5 % du coût nominal au lieu de 10 %), ce qui rend les longs fils agentiques moins chers sans changer le prix des one-shots, et une génération 30 % plus rapide. Un commentateur note qu'Opus 5 est le modèle le plus dépensé sur OpenRouter, probablement le premier chiffre d'affaires d'Anthropic : une baisse de prix forcée malgré les gains de capacités serait donc un signal inquiétant sur la pression concurrentielle (MiMo, DeepSeek, GLM, Luna). Plusieurs se réjouissent surtout de l'amélioration promise du style d'écriture — le style d'Opus 5 est décrit comme insupportable — et de l'arrivée de Sonnet et Haiku 5.5, Haiku semblant jusque-là délaissé.
Les critiques sont vives sur deux points. D'abord l'extension des garde-fous bio/cybersécurité (programmes de vérification Life Sciences et Cyber) à toute la gamme : plusieurs y voient un refus quotidien de requêtes bénignes en bio-informatique, poussant les clients vers Astra ou GLM — « Claude devient inutilisable pour la bioinformatique ». Ensuite, les benchmarks : un utilisateur rappelle qu'Opus 5 était au niveau de Fable sur les benchmarks tout en étant « inutilisable » en code réel, et des tests indépendants (rendus de SVG « pelican », conversion image→HTML) placent Opus 5.5 juste derrière Astra, avec un test « max » qui a brûlé 128 000 tokens de raisonnement pour 2,56 $ sans aboutir.
-
GPT-6 Sol and Luna
Titre seul évoquant « GPT-6 Sol and Luna », sans contenu disponible. Impossible de déterminer s'il s'agit d'une annonce officielle d'OpenAI ou d'une discussion/speculation ; aucune information vérifiable dans le texte fourni.
La discussion porte moins sur l'article lui-même que sur le rapport qualité/prix des nouveaux modèles GPT-6. Le point d'accord le plus net : la baisse de 50 % des tarifs par rapport à la génération 5.6 est remarquable — GPT-6 Luna passe à 0,10 $/0,50 $ par million de tokens, rendant OpenAI très compétitif face à Claude (Opus 5 à 4/20 $ contre Sol à 2/10 $, avec cache moins cher aussi). Plusieurs confirment que la réduction s'applique aussi aux quotas d'abonnement, pas seulement à l'API. Sur l'usage, l'accord se fissure : beaucoup de développeurs restent attachés à 5.6 Sol pour son « feeling » en travail d'agent, estimant qu'Astra 6 voire Sol 6 sont une régression pour les tâches courantes malgré une intelligence supérieure ; d'autres trouvent au contraire Luna 6 « assez intelligent » pour un prix imbattable. Critique récurrente : les modèles GPT sur-ingénieurs (usines, interfaces inutiles), et l'écart persistant avec Claude sur le design UI.
Des praticiens partagent des retours de terrain concrets : comparaison des abonnements Claude Code vs Codex (Codex gagne sur les limites d'usage, Claude Code sur la fenêtre de contexte ; le contournement toml pour étendre le contexte à 1M de tokens aurait été rétabli), tests d'image-vers-HTML où Astra domine nettement Sol et Luna, et grille comparative de rendus SVG. Un commentateur nuance l'enthousiasme tarifaire : ces prix ne reflètent pas les coûts réels, OpenAI n'étant pas rentable et cherchant à regagner son avance. D'autres regrettent la multiplication des noms (Sol, Luna, Terra, Astra, Astra Max) jugée confuse et assimilée à de la discrimination par les prix ; l'échelle d'effort (5 niveaux de raisonnement) est jugée difficile à arbitrer face au choix de modèle.
La discussion contredit en partie le narratif d'upgrade : selon les benchmarks cités, Luna 6 ne progresse que de quelques points et aurait même régressé en mode xhigh — plus une baisse de prix qu'une vraie montée en gamme.
-
I don't want to read what you didn't write
L'auteur exprime son agacement face à la prolifération de textes générés par IA — documents de conception rétrospectifs, résumés de pull requests, tickets, comptes rendus de réunions, messages personnels — qu'il juge illisibles car dépourvus de contexte, de perspective et de voix humaine. Il souligne le décalage entre l'auteur (qui a le contexte du prompting et peut skimmer le résultat) et le lecteur (qui doit tout lire exhaustivement). Il cite une enquête de Cynthia Dunlop : 78 % des lecteurs arrêtent la lecture d'un article qu'ils estiment écrit par IA, et 98 % préfèrent l'écriture authentique de l'auteur, avec ses défauts.
À l'inverse, il décrit un usage vertueux de l'IA pour l'écriture : pour un article académique rédigé entièrement de sa main, il a fourni à l'IA le code source, la configuration, les logs et métriques de production pour vérifier factuellement ce qu'il écrivait, compléter les citations BibTeX, corriger orthographe et grammaire, produire des diagrammes TikZ et rédiger l'abstract. Demander à l'IA de rédiger les paragraphes elle-même s'est avéré systématiquement inutile et désagréable à lire.
Il conclut qu'il ne faut pas sous-estimer les progrès futurs des modèles en matière d'écriture créative, tout en restant critique sur l'état actuel.
La discussion approuve largement la thèse de l'article : écrire, c'est transférer une information d'un cerveau à un autre, et un LLM ne peut pas combler les bits manquants que seul l'auteur possède. Si l'IA « devine » le reste, ces bits n'étaient pas de la vraie information et polluent le texte. Plusieurs commentateurs illustrent ce rejet par des retours de terrain concrets : un développeur refuse désormais systématiquement des pull requests dont la description générée par IA dépasse largement la taille du changement de code, car approuver impliquerait d'avoir tout lu ; un mainteneur d'un dépôt GitHub populaire demande un e-mail personnel pour fusionner des contributions, ce qui filtre efficacement les agents.
Des nuances apparaissent. Certains estiment que le problème est davantage un problème de curation que l'usage de l'IA en soi : ce qui manque dans les descriptions de PR générées, ce n'est pas l'IA mais la nuance — quels points sont risqués, où l'auteur attend un second regard. D'autres acceptent l'IA comme partenaire de réflexion ou pour aérer une liste de points à puces, tant que l'auteur relit et s'approprie le résultat ; l'inacceptable serait de transformer des notes brutes en fausse prose argumentée. Un avis minoritaire souligne aussi un angle d'équité : l'IA aide des gens qui ne pensent pas en prose articulée à partager leurs idées, et les critiquer sonnerait élitiste — position à laquelle d'autres rétorquent que le texte généré n'est de toute façon « la voix » de personne.
Les commentateurs notent plusieurs points concrets : des fautes de frappe et des imperfections deviennent des signaux positifs, un « preuve de travail » humaine ; la qualité d'écriture des modèles récents serait en baisse selon certains (avec des classements subjectifs cités, GPT 4.5 en haut, les modèles Claude récents contestés), sans accord sur la cause — dégradation réelle ou simple acuité accrue des lecteurs ; un contributeur relève l'ironie que la première phrase de l'article (« difficult—is punishing ») ressemble exactement au style LLM dénoncé.
-
Pentagon says overreliance on AI contributed to missile strike on Iran school
Selon le Pentagone, une dépendance excessive à l'IA aurait contribué à une frappe de missile ayant touché une école en Iran.
La discussion conteste en profondeur le cadrage de l'article. Selon plusieurs commentateurs, l'IA n'est pas la cause première de la frappe sur l'école iranienne mais un bouc émissaire commode : les renseignements indiquant que l'école n'était plus une cible militaire n'ont jamais été intégrés à la base de données, l'équipe chargée de valider les cibles a été démantelée et jamais consultée, et l'objectif politique de « 1000 cibles » a été atteint sans aucune diligence. Un commentaire cite un article de ProPublica selon lequel le chef du Pentagone a réduit d'environ 90 % les effectifs travaillant sur la protection des civils (200 employés), l'équipe des victimes civiles du Central Command passant de 10 à une seule personne — ce qui corrobore l'idée d'une défaillance humaine et organisationnelle plutôt que d'un dysfonctionnement algorithmique.
Un point de division notable : certains estiment que deux choses peuvent être vraies simultanément — l'incompétence humaine et le fait que l'IA amplifie les dégâts et dilue la responsabilité (« decision laundering »). Un praticien souligne que les utilisateurs s'attendaient à ce que le système Maven signale lui-même les données obsolètes, ce qui illustre la méconnaissance des limites de l'IA ; d'autres rétorquent que c'est la faute des développeurs qui ignorent l'usage réel de leurs produits. Palantir affirme que son logiciel n'est pas en cause et rejette la faute sur la qualité des données, ce qui amène certains à s'interroger sur l'absence totale de responsabilité, comparable à un simple incident SaaS B2B ; un avis minoritaire refuse de blâmer les développeurs au motif que ce sont les décideurs militaires qui ordonnent les frappes.
La question de la responsabilité pénale domine : de nombreux commentateurs exigent des poursuites, comparant l'affaire au massacre de My Lai (où, rappellent-ils, presque personne n'a été condamné) et estimant qu'aucune justice, compensation ou reconnaissance ne viendra.
-
I said no and Apple said yes
L'auteur relate sa mésaventure avec Apple Intelligence : après avoir découvert en février 2025 que macOS 15.3 activait un rapport de données personnelles toutes les 15 minutes, il l'avait désactivé. Après une mise à jour vers macOS 27, il constate que le réglage permettant de refuser a été supprimé et que les fonctionnalités d'IA ont été réactivées malgré ses préférences préalablement désactivées.
Il décrit ses tentatives pour limiter la collecte : désactivation répétée de Siri, processus persistants consommant mémoire et données, réglages cachés dans les restrictions « Screen Time » qui ne font que masquer les outils d'IA sans les désactiver, et 22,28 Go de données occupant son disque.
L'article élargit à une critique de l'industrie de l'IA, accusée d'ignorer le consentement, en citant des affaires récentes (CSAM sur X, procès contre OpenAI, aveux sur les données d'entraînement).
La discussion est marquée d'abord par une correction factuelle importante : plusieurs commentateurs soulignent que l'article repose sur une mauvaise interprétation. Le réglage « Apple Intelligence Report » (Off / 15 minutes / 7 jours) n'envoie rien à Apple : c'est un rapport de transparence destiné à l'utilisateur pour visualiser ce qui est déjà transmis. Le constat central de l'article — « macOS 15.3 aurait activé un envoi de données personnelles toutes les 15 minutes » — serait donc faux, même si un commenter concède qu'Apple a fait un très mauvais travail d'explication de ce réglage. Un autre regrette que personne n'ait vérifié la prémisse avant de s'indigner.
Au-delà de cette correction, les commentateurs s'accordent largement sur un malaise de fond : l'impossibilité de dire « non » aux sollicitations d'Apple (toujours « plus tard », jamais « non définitivement »), des prompts d'engagement perçus comme des publicités, un Siri lent et souvent inexact, et des processus Siri/IA qui tournent en arrière-plan même quand tous les réglages sont désactivés. Des retours concrets complètent le tableau : un utilisateur d'iPad récupère environ 15 Go d'espace en fixant la région Siri sur un pays non supporté (ex. Russie), un autre mentionne des profils Apple Configurator pour bloquer les fonctionnalités IA, et la documentation officielle Apple explique comment restreindre Apple Intelligence sans libérer toutefois l'espace disque occupé. Plusieurs observent un basculement de perception : Apple serait devenu une entreprise « hostile » à l'utilisateur, une tendance amorcée selon eux dès 2015 (clavier papillon, RAM soudée) ou avec iCloud.
Le débat se divise sur les solutions. Une partie recommande Linux (PopOS/COSMIC, Omarchy — quoique contesté pour ses « pubs » intégrées, Asahi pour Mac), quitte à accepter un coût d'entrée de recherche matérielle ; un avis minoritaire suggère même BSD. D'autres prônent la régulation (refus possible à l'installation, voire refus par défaut, sur le modèle du choix de navigateurs européen) ou simplement la prudence : ne jamais installer la première version majeure de macOS, attendre N-1.
-
'We hacked the FBI:' Hackers say they have data on all FBI employees
Le groupe de hackers ShinyHunters affirme avoir piraté plusieurs services liés au FBI et volé des données portant sur « tous les employés et candidats du FBI », incluant les noms, adresses personnelles, numéros de téléphone des agents et des informations sur leurs conjoints, selon 404 Media.
Une telle fuite pourrait avoir d'importantes implications de sécurité nationale et de contre-espionnage : des criminels du même écosystème ont déjà utilisé des données piratées pour traquer et intimider des agents du FBI qui les enquêtaient, et les données pourraient aussi intéresser des services de renseignement étrangers ou exposer les agents et leurs épouses à des menaces graves.
La discussion tourne surtout autour de l'ampleur et de la banalisation de l'attaque revendiquée par ShinyHunters contre le FBI. Plusieurs commentateurs notent que le volume annoncé (2 à 3 téraoctets) dépasse largement une simple liste d'employés et suggère des dossiers complets avec photos et données de conjoints. D'autres rappellent des précédents, notamment le piratage de l'OPM en 2015 (22,1 millions de dossiers d'employés fédéraux), pour conclure qu'aucune grande base de données n'est fiable face aux États nations.
L'explication technique la plus partagée pointe vers une faille zero-day (ou une backdoor intentionnelle selon un avis minoritaire) dans Oracle PeopleSoft, avec des interrogations sur un système apparemment exposé à Internet sans VPN et sur la capacité des administrateurs à ne pas détecter une exfiltration de plusieurs To sur des jours ou semaines. La discussion nuance le titre : pour les commentateurs techniques, « pirater le FBI » revient ici à compromettre un logiciel tiers banal (PeopleSoft), ce qui laisse penser que beaucoup d'autres organisations sont vulnérables. Certains critiquent aussi le licenciement d'experts et l'externalisation logicielle au sein des agences fédérales.
Les commentateurs relèvent la déclaration ambiguë du groupe — « pas de l'extorsion, peut-être de la coercition », non motivée financièrement — en soulignant qu'elle pourrait se retourner contre eux devant un tribunal ; un commentaire évoque une prétendue rançon d'environ 10 millions de dollars liée au piratage antérieur de Canvas LMS, ce qui laisse dubitatif sur la nature réellement « non financière » de cette campagne. Enfin, plusieurs voix estiment que de tels incidents sont devenus banals et plaident pour ne pas collecter ni conserver de données sensibles, voire pour autoriser des tests d'intrusion sans permission préalable.
-
Apple has added persistent 'ads' to iOS, and it's driving users crazy
Apple insère des bannières promotionnelles pour ses propres services (iCloud+, Apple Music, Apple TV, AppleCare+) dans l'app Réglages d'iOS, souvent impossibles à ignorer et persistantes pendant des semaines. Les utilisateurs expriment leur colère sur les réseaux sociaux, y voyant une dérive similaire aux publicités de Microsoft. Cette stratégie s'inscrit dans la poussée d'Apple vers les services, avec d'autres publicités prévues, notamment dans Visual Intelligence.
La discussion révèle un fort mécontentement envers Apple, mais avec une controverse sur la nature même de l'article : plusieurs commentateurs le jugent clickbait, estimant qu'il s'agit de promotions d'Apple pour ses propres services (essais gratuits Arcade/TV+, iCloud+) présentes depuis des années dans l'app Réglages, pas de nouvelles publicités ouvertes aux annonceurs. Ils notent que le titre du site à l'origine de l'article citait les « ads » entre guillemets, signe que l'auteur en était conscient.
Les défenseurs d'Apple estiment qu'un bouton discret propose des produits pertinents et que c'est la plate-forme grand public la moins envahie par la pub. Les critiques répondent que le problème n'est pas l'existence des promos mais l'impossibilité de les faire disparaître : badge rouge permanent, notifications répétées, bouton « dismiss » parfois absent ou non fonctionnel — même pour des abonnés payants. Retours de terrain variés : pub pour un avocat pénaliste dans Apple Maps, pubs répétitives dans l'app News, promotion de Final Cut Pro iPad dans Final Cut Pro macOS — inconcevable il y a quelques années dans une app « pro ». Plusieurs utilisateurs quittent Apple Maps pour Google Maps ou CoMaps, et d'autres envisagent de revenir à Android.
Au-delà des pubs, la discussion élargit la critique : Apple n'impose pas vraiment de refuser les mises à jour (badge permanent, téléchargements de ~15 Go lancés malgré des mises à jour automatiques désactivées ; un contournement via une entrée /etc/hosts pointant gdmf.apple.com vers 127.0.0.1 est partagé). Un commentateur explique la logique économique : hors iPhone, le segment le plus rentable d'Apple est les services, avec des marges vraisemblablement supérieures à 90 %. D'autres s'accordent sur le risque pour l'image haut de gamme d'Apple. Quelques pistes alternatives émergent (GrapheneOS, téléphone à clapet, projets Linux mobiles), jugées encore immatures pour un usage grand public. Un utilisateur signale enfin ne pas voir ces promos depuis l'UE.
-
OpenAI GPT–6 Astra breaks Enigma message that has resisted solution since 2005
Un message allemand Enigma de 1941 (MVUEH, Nr. 172), indecrypté depuis 2005, vient d'être cassé par le modèle GPT-6 Astra d'OpenAI, travaillant de manière autonome. Carter Leffer avait simplement demandé à l'IA d'essayer de percer les messages non résolus publiés par Crypto Cellar Research ; elle a choisi le message le plus prometteur, soupçonné un lien avec le message Nr. 173 (SIPVX, cassé en 2017), et utilisé le nom de lieu répété ROSENOW ROSENOW comme crib.
La clé retrouvée diffère totalement des autres clés du 10 juillet 1941, y compris l'ordre de rotors (253 au lieu de 512). Le texte est presque identique à celui de SIPVX, avec quelques erreurs de chiffrement. La transcription erronée du chiffré et un rare turnover du rotor de gauche au 72e caractère expliquent probablement l'échec des tentatives antérieures.
L'IA a développé elle-même des simulateurs Enigma en Python et C++ et un « Bombe », et a retrouvé en deux jours ce qui aurait pris des semaines à un chercheur humain — elle semble même avoir consulté des références d'archives du Bundesarchiv révélées en juillet 2026, dont la provenance exacte reste à élucider. L'auteur, cryptanalyste chevronné, analyse encore les journaux de l'IA.
La discussion tourne largement autour d'une correction du titre : plusieurs commentateurs soulignent que ce n'est pas l'IA seule qui a cassé ce message Enigma, mais un chercheur aidé par le modèle, dans une collaboration d'environ deux jours. Le message, resté non résolu depuis 2005 (date de sa publication en ligne), utilisait une clé différente du reste du trafic du jour — d'où l'échec des tentatives antérieures qui supposaient une clé journalière commune — et comportait des erreurs de transcription ainsi qu'un basculement rare du rotor gauche à la lettre 72, qui casse les attaques par mots probables classiques. Les commentateurs regrettent que l'article omette le texte clair lui-même, qu'un contributeur fournit : un message allemand (avec fautes d'orthographe) demandant la précision d'un itinéraire de marche depuis Rosenow et une réponse radio immédiate.
Le scepticisme est important : plusieurs estiment qu'on ne peut rien conclure sans la publication des échanges et du raisonnement intermédiaire du modèle — la solution pourrait relever d'une simple recherche web, du téléchargement d'un simulateur Enigma open source et de l'essai de cribs évidents. D'autres suggèrent que la solution figurait peut-être dans les données d'entraînement, ou qu'un modèle moins coûteux aurait pu faire pareil. Certains jugent au contraire la prouesse réelle, tout en notant une limite structurelle : les LLM excellent sur des problèmes déjà « proches » de problèmes résolus, mais leur capacité d'imagination face à des problèmes totalement inédits reste douteuse.
Les digressions portent sur l'application éventuelle aux chiffres du Zodiac (jugée peu prometteuse : 13 et 32 caractères seulement, sans lien de clé avec les messages résolus, voir le travail de David Oranchak sur Z340), le manuscrit de Voynich et les langues non déchiffrées (données d'entraînement trop rares), l'inquiétude face à l'« intelligence devenue produit achetable », et l'étonnement d'un commentateur sur le rôle réel de Turing face aux travaux polonais de 1932 — précisé en réponse : Turing a surtout percé les machines Enigma navales, plus difficiles.
-
Spymarks, Not Watermarks
L'auteur propose le terme « spymark » pour désigner des signaux cachés insérés dans les médias afin de tracer leur origine sans le consentement des utilisateurs, à la différence des filigranes visibles et bénins. Il détaille Google SynthID, capable d'encoder 136 bits dans une image 512x512 (assez pour un identifiant de base de données lié à une identité), et cite des travaux similaires chez OpenAI et d'autres, y compris le marquage audio (audiowmark, 2018) et l'altération statistique des choix de mots dans les textes.
Contrairement aux métadonnées standardisées (EXIF, ID3) inspectables et supprimables, les spymarks sont invisibles, robustes à la compression et à certains montages, et peuvent persister après suppression des métadonnées. Des précédents existent comme les points de traçage des imprimantes depuis les années 1980.
L'article alerte sur les risques pour les lanceurs d'alerte et la confidentialité : un futur où chaque publication porterait un identifiant lié au compte permettrait de retracer la diffusion des contenus et d'identifier facilement des personnes à partir d'un fichier. Le changement de terminologie vise à ancrer l'enjeu de vie privée dans le débat public.
La discussion juge l'article surtout sous l'angle terminologique et technique. Plusieurs commentateurs soulignent que le concept décrit n'est rien d'autre que de la stéganographie — terme que l'article n'emploie d'ailleurs pas, ce qui est relevé comme une omission — et contestent la pertinence du néologisme « spymark » : un avis minoritaire estime qu'il sonne trop péjorativement alors que des marques invisibles peuvent être légitimes (billet de banque contrefait, SynthID jugé globalement positif, notamment parce qu'il ne dégrade pas le texte).
Sur le fond, deux idées concrètes ressortent. D'abord, un commentateur propose une défense : vérifier que son contenu reste identique octet par octet à la dernière étape de production de confiance (appareil photo, éditeur, compresseur sûrs). Un autre répond que cela échoue quand la marque est insérée par le processus même de génération (cas de SynthID) ou lors d'une transformation, car aucun comparateur « propre » n'existe. Ensuite, un praticien anticipe une généralisation de ces marques pour l'attribution publicitaire : les petits portables et smartphones embarqueraient un pilote scannant en permanence les pixels destinés à l'écran pour « faire remonter » les marques, ce que la plupart des fabricants accepteraient ; la position d'Apple fait débat, certains la jugeant protégée par son modèle économique (marges matérielles, commissions d'app store) plutôt que par altruisme, d'autres la tenant pour peu fiable. D'autres rappellent des précédents : les points jaunes des imprimantes jet d'encre, les marques invisibles des screeners de films et des contenus téléchargés.
Des nuances techniques complètent l'ensemble : la robustesse des marques par choix de mots est interrogée (peu de bits, risque de style artificiel, remplacements impossibles dans certains contextes), un exemple montre que reformuler un texte ne suffit pas à effacer une marque cachée dans les choix lexicaux, et la question juridique du RGPD est soulevée sans réponse tranchée (exemptions possibles, argument que la marque suit le contenu et non la personne).
-
Microsoft killed FoxPro in 2007. Anyway, here's FoxPro revived
FoxDev Studio est une réimplémentation de Visual FoxPro (abandonné par Microsoft en 2007 à la version 9, en 32 bits) qui ouvre directement projets, formulaires, classes, menus, tables et index existants sans migration ni conversion, en lisant et écrivant les fichiers sur place.
Le runtime est écrit à zéro en Rust, compilé en WebAssembly, avec un compilateur et un interpréteur de bytecode : le même code p-code/ runtime que FoxPro, mais en 64 bits intégral, ce qui lève la limite des 2 Go par table (avec l'avertissement qu'une table dépassant 2 Go ne rouvrira plus dans Visual FoxPro). Le modèle d'exécution repose sur des fibers qui rendent la main au lieu de bloquer, et l'interface est rendue par React depuis l'arbre d'objets des formulaires, le designer éditant ce même arbre.
Les vieilles bibliothèques .fll 32 bits fonctionnent via un petit processus 32 bits pont, FoxScript ajoute lambdas et serveur HTTP au langage existant, et des builds nightly sont publiées sur GitHub avec une documentation détaillée et une feuille de route des parties encore manquantes.
La discussion, très nostalgique, confirme d'abord le constat de l'article : Visual FoxPro tourne encore dans l'industrie. Plusieurs commentateurs citent des cas concrets : une entreprise de niche à plus de 400 M$ de chiffre d'affaires annuel toujours sous VFP en 2026, et une société gérant 500 KLOC de FoxPro qui fait tourner un business de 500 M$ (avec une réécriture assistée par IA en cours). Le consensus : ces outils d'une productivité redoutable pour le CRUD n'ont pas de vrai successeur, et les critiques du passif (VB6, Delphi, Flash, dBase, Clipper) s'accompagnent d'un regret que les stacks modernes (VB.NET, C#…) n'aient jamais égalé le confort d'un FoxPro ou d'un Access — toujours vivant et maintenu, sans alternative bon marché.
La discussion nuance fortement l'enthousiasme sur le plan technique et sécuritaire. Un ancien ingénieur de Microsoft (ayant lui-même classé le bug il y a plus de vingt ans) détaille une faille majeure du Database Container : les procédures stockées sont stockées en clair dans un champ memo, exécutées telles quelles par le runtime, y compris avec des appels Win32, et la base n'est qu'un ensemble de fichiers modifiables à l'éditeur de texte — aucune permission possible. Il recommande de migrer vers une vraie base SQL via ODBC/OLE DB. Un cas réel l'illustre : une base de registres électoraux certifiée dans l'Ohio sous VFP, avec de simples fichiers DBF dans un dossier partagé accessible en écriture par tous. Autre limite : FoxPro était conçu pour le mono-utilisateur, et les accès réseau (blocages de fichiers, conflits d'édition, VPN actuels) sont son point faible ; des retours de terrain mentionnent des migrations réussies vers .NET ou PostgreSQL (outil pgdbf), parfois via Citrix pour le maintien en condition.
Enfin, un échange technique apporte des détails sur le projet Foxscript lui-même : son runtime utilise des offsets 64 bits, donc les DBF dépassant 2 Go ne peuvent plus être rouverts par l'ancien VFP9 — l'auteur conseille de tester sur machine isolée et invite à remonter les cas limites sur GitHub. Un commentaire relève d'ailleurs un doute sur la nature même du projet (tentative d'exfiltration de données ?
-
Can gzip be a language model?
L'auteur explore l'équivalence entre compression et prédiction (papier « Language Modeling is Compression ») pour faire de gzip un modèle de langue : en amorçant le compresseur avec un corpus (tiny Shakespeare) et en générant des continuations par beam search, en scorant chaque candidat par la longueur compressée via DEFLATE et sa fenêtre glissante de 32 KiB. Le résultat, sans réseau de neurones ni paramètres appris, produit un texte approximatif mais visiblement influencé par le corpus. L'article détaille les problèmes rencontrés (quantification entière des tailles compressées noyant le signal) et les solutions : recherche en faisceau sur des segments entiers, restriction du contexte aux derniers octets générés pour éviter les boucles de copie verbatim. L'implémentation, gzipt, tient en un seul fichier Python standard (zlib), disponible sur GitHub.
La discussion confirme l'idée centrale de l'article : la compression et la modélisation du langage sont deux facettes du même problème, mais les commentateurs s'accordent pour dire que gzip est un jouet pédagogique, pas un modèle de langage crédible.
Plusieurs praticiens rapportent des usages réels de cette équivalence depuis longtemps : détection de langue en amorçant les dictionnaires de gzip avec des Wikipedias multilingues, classification de textes en comparant la taille des fichiers compressés avec des corpus de référence, ou filtrage de spam avec LZO (le spam étant répétitif et pauvre en contenu). On rappelle aussi que le meilleur concurrent du Hutter Prize utilise un réseau de neurones pour compresser, et que le papier de Google « Language Modeling Is Compression » avait déjà formalisé ce lien, tout comme la série de 3blue1brown.
La discussion corrige toutefois l'article sur un point technique important : le générateur ne cherche pas réellement la séquence compressant le mieux, car cela produirait des répétitions infinies ; les auteurs imposent une fenêtre glissante sur le texte récent, ce qu'un commentateur juge fatal à la prémisse — le résultat intéressant serait artificiellement forcé par ce choix d'algorithme. Une autre critique porte sur la beam search : impossible de savoir si l'espace de recherche, des ordres de grandeur trop vaste, a été exploré de manière significative ; on n'obtient qu'une borne inférieure des capacités de gzip. Des tests communautaires avec bzip2 et zstd montrent des sorties qui ne ressemblent plus du tout à du langage humain, l'algorithme optimisant des structures spécifiques au codec. Enfin, un avis minoritaire rejette l'équation compression = intelligence : gzip est linéaire et prédictif pour un seul récit, les LLM gèrent des univers de récits, et les rapprocher serait comparaison de « bêtes sauvagement différentes ».
-
AI Has No Wisdom and Neither Will You
L'auteur soutient que l'abandon progressif de la lecture et de l'écriture du code au profit de l'IA est un piège pour les développeurs et les organisations. Les projets entièrement « vibe-coded » dégénèrent en amas impossibles à maintenir, car la maintenabilité et la bonne architecture n'ont aucune métrique mesurable à court terme : leurs effets néfastes n'apparaissent qu'après des mois ou des années, là où l'apprentissage par renforcement exige un signal de récompense immédiat.
L'IA apprend donc à partir de règles destinées aux débutants et du code existant, dont une grande partie est médiocre. Elle est notamment incapable de « simplifier » correctement du code : elle découpe les fonctions en sous-fonctions non réutilisables, alors qu'extraire des fonctions réutilisables et clarificatrices est un art relevant de la maîtrise. Les développeurs experts s'appuient sur une intuition contextuelle forgée par des années de débogage, intuition impossible à réduire en règles — et l'IA ne l'a pas.
Le danger, selon l'auteur, est que ceux qui délèguent l'écriture et la lecture du code à l'IA ne prennent plus de décisions, n'assument plus les erreurs et n'apprennent plus : ils n'atteindront jamais la maîtrise.
La discussion prolonge la thèse de l'article (l'IA produit du code rapide mais sans « sagesse », et les projets vibe-codés dégénèrent ensembles impossibles à maintenir). Plusieurs commentateurs partagent l'inquiétude d'une érosion des compétences : un parallèle est dressé avec l'externalisation industrielle vers la Chine, qui a détruit aux États-Unis un savoir-faire institutionnel désormais quasi impossible à reconstruire. Un praticien note que dans les équipes actuelles, c'est souvent le développeur seul qui ne comprend plus le métier, tandis que le client et le LLM le maîtrisent. D'autres s'inquiètent de leur propre dépendance croissante à l'IA et du cas de la nouvelle génération de développeurs.
Mais l'article est nettement nuancé, voire contredit, par une partie de la discussion. Plusieurs contestent l'affirmation centrale selon laquelle la maintenabilité serait inmesurable : complexité cyclomatique, outils type SonarQube ou l'abandon du projet sont cités comme signaux disponibles. D'autres font remarquer que la plupart des logiciels écrits par des humains sont déjà de mauvaise qualité — la communauté des développeurs doublant tous les cinq ans, l'expérience reste rare — et qu'un projet vibe-codé n'a aucune raison de dégénérer plus vite qu'un projet humain mal géré ; un projet hérité humain ne voit pas son équipe s'améliorer spontanément tous les six mois, contrairement aux modèles. Un développeur senior de 20 ans d'expérience raconte avoir construit une base de données type MongoDB sans lire une seule ligne de code généré, en se fiant aux tests : pour lui, l'IA a été un accélérateur d'apprentissage majeur.
Le clivage porte sur l'avenir de la profession. Un courant résigné-pragmatique prédit que dans 5 à 10 ans la majorité des développeurs n'écrira plus de code, les artisans du code manuel devenant des boutiques de niche comme les cordonniers face aux usines — d'autres répliquent avec l'exemple des horlogers artisanaux, dont le travail garde plus de valeur.
-
What California is learning from solar panels built over irrigation canals
En Californie, le projet Solar Aquagrid couvre des sections de canaux d'irrigation de Turlock avec des panneaux solaires (Project Nexus), afin de limiter l'évaporation de l'eau tout en produisant de l'électricité renouvelable. Trois modèles de couverture solaire sont testés sur des canaux de largeurs différentes. Selon les estimations du professeur Roger Bales (UC Merced), couvrir 100 miles de canaux étroits économiserait l'eau de 2 700 foyers par an et générerait 330 mégawatts ; les grands canaux permettraient d'atteindre 1 400 mégawatts. Le projet, financé par une subvention étatique de 20 millions de dollars et achevé l'an dernier, produit 1,7 mégawatt et a révélé des bénéfices annexes : moins d'algues, meilleure qualité de l'eau, réduction de l'entretien, et évitation de la construction solaire sur des terres naturelles. L'article souligne aussi les limites : coordination complexe entre de nombreux gestionnaires de canaux, coût du raccordement électrique, et inadaptation des canaux urbains comme ceux du Contra Costa Water District, qui envisage plutôt de mettre ses canaux en tuyaux pour éviter l'évaporation.
La discussion est majoritairement sceptique envers le projet californien de panneaux solaires au-dessus des canaux d'irrigation, tout en reconnaissant qu'il s'agit d'un projet de recherche et non d'un déploiement commercial.
Le principal point de friction porte sur les coûts : plusieurs commentateurs relèvent que le projet a coûté 20 millions de dollars pour 1,7 MW, soit plus de 10 $/W contre environ 1 $/W pour des installations solaires utilitaires classiques en Californie, et jugent l'écart de 10x irrattrapable même avec des économies d'échelle. D'autres répondent qu'il s'agit d'une preuve de concept financée par une subvention d'État incluant recherche et instrumentation (mesure de l'évaporation, humidité, radiation), et que comparer ce coût à une ferme solaire utilitaire est trompeur. L'argument économique central des sceptiques : couvrir les canaux impose des supports massifs en acier (avec des charges de vent en soulèvement), du cuivre supplémentaire pour l'évacuation de l'électricité sur des miles, et un ombrage simple serait bien moins cher. Plusieurs suggèrent une alternative jugée plus efficace : enterrer les canaux dans des tuyaux, ce qui réduit encore mieux l'évaporation — un district d'eau cité dans l'article envisage d'ailleurs exactement cette solution. D'autres nuancent : tuyauter des canaux de grande capacité coûte cher, les canaux résistent mieux aux séismes et sont plus faciles à réparer, et il n'existe qu'une fenêtre étroite de cas pertinents (évaporation problématique mais pas assez pour justifier des tuyaux).
Sur le fond, plusieurs commentateurs corrigent ou complètent l'article : l'idée n'est pas nouvelle (projet pionnier au Gujarat en Inde dès 2012, mentionné dans l'article selon certains ; précédents à Phoenix où les arbres le long des canaux ont été remplacés par du béton à cause des racines provoquant des fuites ; pratique similaire au Xinjiang). Certains soulèvent des questions de pollution potentielle des panneaux vers l'eau et de recyclabilité — il est précisé que les panneaux sont essentiellement en verre et métaux, donc recyclables.
-
SAML: A fractal of bad design
Article technique consacré au protocole d'authentification SAML, que l'auteur juge obsolète et trop complexe. Il retrace son histoire : né en 2002 au sein d'un comité OASIS, fusionnant quatre protocoles XML de sécurité, il a d'abord trouvé preneur dans le milieu académique (CAS à Yale, Shibboleth, ADFS de Microsoft, simpleSAMLphp) avant de servir de socle à l'industrie du SSO (Ping Identity, OneLogin, Okta, Duo Security).
L'auteur, ancien ingénieur chez Duo Security, détaille les failles structurelles du protocole : sa dépendance à XML, source de nombreuses classes de vulnérabilités (XXE, entity expansion, injection XPath, etc.), et la canonicalisation (C14N), à l'origine d'attaques par signature wrapping (XSW) et de bypasss par commentaires XML, encore exploitées aujourd'hui comme la faille libxml2 sur GitHub Enterprise en 2025.
Il passe en revue cinq failles de conception jugées fatales, parmi lesquelles le choix d'XML et les problèmes de canonicalisation, et plaide pour la dépréciation de SAML au profit de protocoles modernes comme OpenID Connect (OIDC).
La discussion confirme globalement le constat de l'article : SAML, hérité de XML, est d'une complexité redoutable. Plusieurs commentateurs ajoutent des exemples concrets pires que ceux décrits : une implémentation C majeure de xmlsig acceptait par défaut des signatures HMAC dont la clé venait du document attaquant, ou validait le document avec le web PKI de l'attaquant ; d'autres ont vu des implémentations vérifier une signature puis faire confiance au document entier, ouvrant la voie aux attaques de type XML Signature Wrapping (XSW) — citées comme une nouveauté choquante par un lecteur. Le parallèle est fait avec JWT et son fameux algorithme « none ».
Mais plusieurs avis nuancent ou contredisent la conclusion de l'article sur OIDC. On lui reproche de lister les vulnérabilités de SAML sans comparaison équivalente pour OIDC, qui a ses propres failles (confusion d'algorithmes JWT, audience checks manquants, bugs des bibliothèques JOSE) ; d'autres répliquent que les vulnérabilités SAML sont un surensemble de celles d'OIDC. SAML conserve des atouts réels : le flux initié par l'IdP (que OIDC ne supporte pas volontairement, car vulnérable au Login CSRF — un exemple PayPal/banque est donné, avec la solution du « Initiate Login URI » d'Okta), le fonctionnement avec un IdP sur réseau privé, et une sécurité intégrée au payload contre le MITM (argument contesté : JWT le permet aussi, et HTTPS ne protège pas de l'utilisateur lui-même). Sur le terrain, un praticien note que le sous-ensemble couramment implémenté de SAML est stable dans sa médiocrité, alors qu'OIDC est une constellation de specs au support incohérent — et que la vraie galère reste SCIM et ses incohérences entre IdP.
Au-delà du technique, la discussion pointe des causes structurelles : le « design by committee » (parallèles avec OpenVPN vs Wireguard, OSI vs IP), le mélange plan de contrôle/plan de données propre à XML, et surtout un verrou économique — OIDC possède les mécanismes de fédération décentralisée (découverte et enregistrement dynamiques) mais personne ne les implémente : les éditeurs profitent de la « SSO tax » et les fournisseurs d'identité défendent leurs marges.
-
I asked Meta’s Muse for its filesystem and it sent me 6.8GB
En demandant à Muse, l'agent IA de Meta, d'archiver les fichiers visibles dans sa session et de les envoyer vers Google Drive, l'auteur a obtenu 6,8 Go décompressés contenant apparemment le système de fichiers racine complet de l'environnement Linux attribué à sa session : fichiers système Ubuntu, documentation interne, code d'intégration, modèles d'applications, journaux d'agent et fichiers de clés SSH.
L'export révélait le fonctionnement interne de l'agent (nom de code Hatch) : fichiers de personnalité et de mémoire en Markdown (SOUL.md, MEMORY.md…), environ 68 répertoires de compétences couvrant Google Workspace, Outlook, voyages, santé ou génération de médias, des fichiers de configuration suggérant des connecteurs à venir (Slack, Dropbox, Polymarket, Canva), ainsi que les scripts de construction du conteneur et le framework Spaces utilisé pour générer des applications. Codex CLI d'OpenAI était présent dans l'image, mais l'auteur n'a trouvé aucune preuve que Muse l'utilise comme agent de code : seule sa sandbox bubblewrap serait exploitée pour l'audio/vidéo.
L'auteur a signalé sa découverte via le programme de bug bounty de Meta sans publier l'archive ni les clés. La crainte soumise : des fichiers d'exécution internes et des données sensibles peuvent sortir de l'environnement par une simple conversation et une destination d'export connectée.
L'auteur du billet a demandé à l'agent Meta (Muse) d'archiver le système de fichiers de sa session et a obtenu 6,8 Go contenant des docs internes, du code d'intégration, des scripts de démarrage et des fichiers de mémoire, puis a signalé l'export au programme de bug bounty, classé « Not Applicable ». La discussion reste globalement unanime pour relativiser l'« exclusivité » : chaque utilisateur reçoit une VM dédiée et isolée, et l'agent voit par définition les fichiers de son propre environnement, donc il ne s'agit ni d'une faille ni d'une exfiltration de données d'autres utilisateurs. Plusieurs commentateurs estiment que l'enthousiasme de l'article est démesuré, certains regrettant qu'il présente comme une découverte ce qui est simplement le produit ; un autre note que ces fichiers sont d'ailleurs visibles directement dans l'application Muse.
La discussion apporte toutefois des éléments concrets au-delà du billet : l'harness de Muse est un binaire monolithique Rust de 332 Mo ; la mémoire est gérée via Postgres (memory.entries, memory.embeddings en vecteurs 384 dimensions, memory.claims), ce qu'un commentateur juge redondant avec le SQLite déjà présent et coûteux, tandis qu'un autre y voit au contraire une approche étonnamment sécurisée. Le SOUL.md de l'agent s'avère être une version légèrement remaniée du template « Core Truths » d'OpenClaw, et plusieurs confirment que Muse est fortement inspiré d'OpenClaw — l'un l'a même fait installer OpenClaw sur sa propre VM. Une remarque nuance aussi le cadre « Meta irresponsable » : l'entreprise accepte d'accomplir des actions que d'autres éditeurs refusent (ex. botter des parties de poker), ce qui constituerait son vrai différenciateur.
Enfin, un avis minoritaire soulève la vraie question : est-il normal qu'un utilisateur d'un service voie tout cela, et certains s'étonnent que Meta ne propose aucun bounty pour l'exfiltration du contenu complet d'une session. Aucune sandbox escape ni accès à des données d'autres utilisateurs n'ayant été démontré, la communauté tranche clairement : ce n'est pas une vulnérabilité, mais le fonctionnement voulu de l'agent.
-
Claude Opus 5.5 Intelligence, Performance and Price Analysis (Max)
Fiche d'évaluation d'Artificial Analysis consacrée à Claude Opus 5.5 d'Anthropic (configuration Adaptive Reasoning, Max Effort, Default Fallback), sorti le 22 septembre 2026. Le modèle obtient un score de 58 sur l'Intelligence Index, bien au-dessus de la médiane (25) des modèles comparables, tout en étant très verbeux : 260M de tokens générés lors des évaluations, contre une médiane de 88M.
Côté tarification, il est jugé « assez cher » pour sa catégorie : 4,00 $ par million de tokens en entrée (médiane : 2,00 $) et 20,00 $ par million en sortie (médiane : 10,00 $), soit environ 5,98 $ par tâche d'évaluation, ou 2,94 $ par million en tarif mixte (ratio 7:2:1 cache/entrée/sortie).
Le modèle est multimodal (entrée texte et images, sortie texte), propriétaire, avec une fenêtre de contexte de 1 million de tokens ; Anthropic n'a pas communiqué son nombre de paramètres. La page inclut aussi des comparatifs de vitesse, de coût par tâche et de consommation de tokens.
La discussion tourne surtout autour des données d'Artificial Analysis pour Claude Opus 5.5, avec plusieurs corrections de lecture. Un commentateur souligne d'emblée que la page commentée correspond au réglage de raisonnement « max », et renvoie vers les pages « high » et « medium » (réglage par défaut) : ses essais avec « max » ont échoué deux fois sur le test classique du pélican à vélo, le modèle épuisant son budget de 128 000 tokens en raisonnement sans jamais produire de réponse, ce qui le rend sceptique sur l'utilité de ce mode. Un autre relève un point important : Artificial Analysis affiche « max » par défaut, ce qui avait fait croire à tort à un gouffre à tokens ; en comparant les réglages équivalents (« high » vs « high »), le coût par tâche est en réalité deux fois inférieur à celui d'Opus 5, une bonne surprise compte tenu de la réputation de tarif élevé d'Anthropic. Plusieurs estiment que « high » est le réglage optimal, les benchmarks plafonnant au-delà.
Les retours de terrain sont mitigés et nuancent fortement les benchmarks. Plusieurs praticiens regrettent qu'Opus 5 ait régressé sur le suivi d'instructions et la cohérence sur la durée par rapport à Opus 4.8, et espèrent que 5.5 corrige cela ; un utilisateur prépare un avis favorable sur l'amélioration du style de sortie et de la verbosité. Un développeur solo compare en conditions réelles Claude Code et Codex/GPT-6 sur plusieurs agents en revue croisée : Opus 5/Fable et GPT-6 en haut du panier, Claude meilleur en planification et exécution, GPT-6 meilleur en détection de bugs mais enclins au sur-ingénierie, Gemini et Kimi 3 nettement derrière — un écart plus grand que ne le suggèrent les benchmarks. Un autre signale avoir observé une régression de performances quelques semaines après lancement sur son jeu de tests interne, craignant que les fournisseurs ne « retirent le tapis » une fois les utilisateurs acquis ; d'autres répondent qu'il faut échantillonner les tests en continu et citer le traqueur de dégradation de Margin Lab.
Deux débats traversent le fil.
-
OpenAI is well positioned to fast-follow Jev
Le modèle Jev de TypeSafe, présenté comme une nouvelle approche des LLM fondée sur la classification, a été adopté très rapidement selon Vercel. L'auteur analyse le fonctionnement probable de Jev : un LLM classique dont les logprobs sont utilisées pour produire des classifications (vrai/faux, choix multiples), une technique qu'il avait lui-même décrite dès 2025.
Son thèse centrale : OpenAI utilise déjà ses LLM comme micro-classificateurs implicites depuis des années (tool calling, tokens de délimitation de messages), et pourrait donc rapidement répliquer Jev, voire intégrer cette capacité de classification générale dans ses modèles et agents existants pour des gains de vitesse, de coût et de sécurité.
La question décisive est le moat de TypeSafe : l'architecture n'en constitue probablement pas un, mais les données d'entraînement calibrées et les processus de reinforcement learning pourraient être le véritable avantage défendable.
La discussion exprime un scepticisme majoritaire envers Jev et l'article lui-même. Plusieurs commentateurs estiment que l'engouement est artificiel : des praticiens rappellent que les laboratoires et entreprises utilisent déjà des classifieurs en interne pour l'inférence, la préparation de données ou les garde-fous, et que de nombreuses tâches confiées aux modèles génératifs sont de la classification déguisée. Certains notent que Jev ressemble fort à du rebranding de techniques existantes (NLI, cross-encoders, rerankers, classification zero-shot type BART), sans benchmarks indépendants pour étayer les promesses. D'autres pointent des alternatives open source apparues en 24 heures (Laya, OpenDecision), quoiqu'un testeur contre ces avis juge ces clones nettement inférieurs en conditions réelles et estime que les benchmarks sont trompeurs.
Sur la thèse de l'article (« OpenAI est bien positionné pour copier Jev »), les avis divergent. Un avis jugé plausible par certains : les grands labos peuvent facilement répliquer la technique, voire l'intégrer comme outil interne pour réduire coûts et latence, ou aquihirer l'équipe. À l'inverse, d'autres objectent qu'OpenAI est entièrement tourné vers le raisonnement par RL, à l'opposé de Jev qui est conçu pour ne pas raisonner afin d'être rapide et bon marché, et que leur historique (avance perdue sur Anthropic, récit de la « SaaS-pocalypse » jamais matérialisé) montre qu'ils ratent souvent ces micro-mutations. Un commentateur souligne que le débat sur les « moats » est creux ici puisqu'il n'y a pas de vrai fossé technologique, et suspecte que la stratégie de Typesafe soit de tenir assez longtemps pour se faire acquérir.
Enfin, la discussion corrige plusieurs points de l'article : la qualité rédactionnelle est critiquée (un détecteur estime 20 % de contenu généré par IA), le titre sous forme de question est jugé lâche, et des testeurs rapportent que Jev souffre des mêmes limites que les LLM et n'apporte rien qu'un classifieur ML classique ne fasse mieux — même si un avis nuance que le vrai gain de Jev est de modifier la classification par simple édition de prompt, sans réentraînement.
-
There's a high chance of devices being sold with GrapheneOS preinstalled in 2027
D'après le titre seul, GrapheneOS (système d'exploitation mobile axé sur la confidentialité) pourrait être préinstallé sur des appareils vendus d'ici 2027. Aucun contenu supplémentaire n'est disponible dans le texte fourni pour préciser l'annonce ou ses conditions.
La discussion confirme l'annonce : des appareils Motorola pourraient être vendus avec GrapheneOS préinstallé en 2027, mais plusieurs précisions nuancent l'article. Il s'agit de préinstallation, non d'une exclusivité : l'installation manuelle restera possible, comme aujourd'hui sur les Pixel via le site du projet. La vente passerait probablement par une société tierce rather que par GrapheneOS lui-même, qui se dit « pas équipé » pour gérer cela — possiblement parce que Motorola ne peut vendre légalement des builds Android non certifiés par Google (contrats Google Mobile Services). Un commentateur détaille le futur Signature 27 (annoncé au Snapdragon Summit, ~1460 $ au Royaume-Uni, 1230 $ au Brésil, face au Pixel 11 Pro XL à 1300 $).
Deux points de friction dominent. D'abord la confiance : certains refusent d'acheter un téléphone préinstallé par quiconque autre que GrapheneOS, et un avis critique l'architecture du projet et son refus de divulguer ses sources de financement, en suggérant LineageOS comme alternative multi-appareils. Ensuite les apps bancaires : Google Play Integrity/attestation bloque certaines applications (banques, Microsoft Authenticator potentiellement) sur les OS non certifiés. Des retours de terrain tempèrent toutefois : sur plusieurs banques, une seule bloquait réellement GrapheneOS, et un utilisateur a changé de banque pour faire pression — plusieurs estiment que la pression des utilisateurs suffira, et qu'on peut vérifier l'intégrité d'un appareil préinstallé via factory reset et l'outil Auditor.
Enfin, des demandes récurrentes sur le prix et le matériel : beaucoup souhaitent un appareil à 100-200 €, mais un commentateur explique mathématiquement que les Pixels d'entrée de gamme récents restent plus économiques (un 10a revient à ~55 $/an de support contre ~143 $/an pour un 7a), les fonctions de sécurité exigées n'existant que sur le haut de gamme. D'autres regrettent l'absence de slot SD, port jack, batterie amovible ou switch radio physique, et s'inquiètent de la réparabilité des Motorola. Certains voient dans cette annonce une conséquence directe du durcissement de Google contre le sideloading.
-
AMD's random number generator can't generate a 0?
Un ingénieur électronicien et programmeur assembleur rapporte que les générateurs matériels de nombres aléatoires (instruction rdseed) de deux processeurs AMD à sa disposition n'ont produit aucun 0 en neuf jours de tests. AMD a escaladé son cas en interne sans encore fournir de retour.
Il a mis à jour son application de test pour ajouter un benchmark du générateur et la prise en charge des processeurs sans rdseed. Les résultats montrent de fortes disparités : un Core i5 de 2012 génère 12,6 M nombres/s (dépendant de l'horloge), un Core i7 7700 de 2017 seulement 750 k/s, et son Ryzen 7 environ 2,6 M/s avec un générateur insensible à la variation d'horloge, suggérant des circuits et révisions très différents.
L'auteur juge qu'un RNG de qualité est loin d'être la partie la plus difficile à concevoir sur un x86-64, mais regrette l'absence de documentation fiable sur le fonctionnement de cette unité.
La discussion confirme et précise l'article : le bug semble réel et reproductible, mais limité au 16 bits. Un utilisateur sur Ryzen 5 3600 (Zen 2) reproduit le problème avec rdrand16 alors que rdrand32 fonctionne normalement ; dans le fil source, un vrai zéro sur 16 bits n'apparaît jamais, et le comportement 32/64 bits avec bits bas à zéro reste possible. D'autres précisent que le bug affecterait aussi RDSEED, et qu'une bulletin de sécurité AMD ne couvre pas ce cas sur Zen 2. Un retour d'expérience rappelle qu'un bug similaire (RDRAND défaillant) avait déjà été corrigé par une mise à jour de BIOS/microcode. Un Zen 3 testé ne montre pas le défaut, et un utilisateur très récent (9950X3D) n'arrive pas à le reproduire : le bug serait donc peut-être corrigé après Zen 2.
Les commentateurs s'accordent sur le fait que l'impact pratique est faible : RDRAND sert généralement à alimenter un CSPRNG plutôt qu'à produire des clés directement, et l'absence du seul zéro ne réduit quasiment pas l'entropie. Mais la nuance importante : certains rappellent qu'un RNG conforme doit être uniforme (normes Intel SDM et NIST SP800-90A), et que ne jamais produire 0 trahit un biais statistique — argument étayé par l'exemple qu'un zéro exclu sur 8 bits serait une faille exploitable. Un praticien note aussi qu'un bug similaire dans un KDF n'avait été détecté que par histogramme, les suites de tests statistiques classiques ne le repérant pas.
Plusieurs débats secondaires : la bonne pratique est de ne pas dépendre d'une seule source matérielle (XOF mélangeant plusieurs sources, cf. /dev/urandom), avec en toile de fond le refus historique de Theodore Ts'o de faire dépendre /dev/random uniquement de RDRAND. La correction des modulos non puissances de deux est rappelée. Certains corrigent aussi l'article ou les faux espoirs : l'hypothèse d'un XorShift en cause n'est pas confirmée, et la statistique avancée par un commentateur (probabilité très faible de zéro) est démentie : sur 65536 valeurs attendues uniformément, 11 heures de test auraient dû en montrer.
-
Claude Opus 5.5
Anthropic lance Claude Opus 5.5, premier modèle de la famille Claude 5.5, présenté comme le nouveau modèle de tête. Il égale Claude Fable 5.1 sur la plupart des travaux tout en coûtant 40 % moins cher à l'exécution qu'Opus 5 : 4 $/20 $ par million de tokens en entrée/sortie, lectures de cache à 0,20 $ (−60 %), et génération de sortie plus rapide de plus de 30 %. Le mode rapide (jusqu'à 2,5x) est proposé à 8 $/40 $ par million. Les limites d'usage de cinq heures sont augmentées sur les abonnements Pro, Max, Team et Enterprise.
Côté performances, le modèle brille sur le codage agentique et les tâches longues : migration d'un codebase de 680 000 lignes en moins d'un jour, audit d'un codebase de 200 000 lignes en moins de trois heures (contre 20 heures pour Opus 5), réécriture de HAProxy de C vers Rust en 9,5 heures avec 51 % d'économie. Sur FrontierCode, Terminal Bench 4.0 et CursorBench, il rivalise ou dépasse GPT-6 Astra et GPT-5.6 Sol pour une fraction du coût. En travail de connaissance, il se distingue sur GDPval-AA v2.1 (1846 Elo) et des tests internes d'analyse financière.