Hacker News
-
Xiaomi MiMo v2.6
Publication de la version 2.6 de MiMo, le modèle de langage de Xiaomi, évoquée sans contenu détaillé disponible.
La discussion autour de MiMo v2.6 de Xiaomi est globalement positive : plusieurs commentateurs saluent une transparence inhabituelle, notamment un tableau de bord public des entraînements et un rapport technique détaillé incluant les mauvais résultats. Ils notent aussi la modération de Xiaomi dans la communication (elle montre son modèle derrière DeepSeek sur certains benchmarks) et, selon un utilisateur, un prix très compétitif face à Grok 4.7 dans ses tests.
Les avis se divisent sur la fiabilité des benchmarks et la force réelle du modèle. Un commentateur affirme ne pas faire confiance aux scores où Opus 5 dépasse Astra ou Fable 5.1, mais un autre nuance en rapportant que ces derniers modèles déçoivent dans son usage quotidien. Un test image-vers-HTML place MiMo 2.6 Pro derrière Grok 4.7 et Astra : qualité de rendu inférieure et « overthinking » chronique (36 minutes de génération sans meilleur résultat), bien que rapide en tokens/s. Plusieurs notent un problème d'efficacité : en raisonnement medium/high, l'APItimeoutait à cause d'une consommation de tokens excessive — la solution étant d'utiliser le streaming.
Sur les chiffres : MiMo v2.6 se décline en Flash (309B total / 15B actifs), Pro (1,02T / 42B actifs) et un distillat Qwen 9B ; le coût annoncé de 3,47 M$ est corrigé par un commentateur : il ne couvre que le RL, pas le pré-entraînement. Côté infrastructure, un utilisateur fait tourner le modèle sur deux DGX Spark (~25-35 tok/s), et un autre souligne le créneau « nuit » 00h-08h UTC+8, calé sur la base d'utilisateurs chinoise. Le débat de fond oppose ceux qui pensent que les LLM sont des commodités sans moat (l'avantage énergétique chinois étant jugé décisif) et un avis contraire estimant que le vrai goulot est le compute, pas l'énergie, et que les labos américains garderont l'avance. Un dernier point pratique inquiète les entreprises : la confidentialité des données via Xiaomi ou OpenCode reste floue, même si un plan européen avec ZDR, hébergé à Amsterdam, existe.
-
Attention is all you have
Essai sur le détournement de l'attention par les plateformes : via le « Tetris effect », l'auteur montre que ce sur quoi l'on se concentre finit par façonner la pensée, et que les algorithmes de recommandation (YouTube, Spotify, LinkedIn, Reddit) imposent de plus en plus ce que nous voyons — entre doomscrolling, contenus IA générés pour éviter les redevances et faux avis — à tel point que laisser autrui dicter son écran équivaut à lui donner la clé de son cerveau.
Il oppose à cela l'internet « intentionnel » d'autrefois, fait de favoris, de blogs, de wikis et de RSS, où l'utilisateur choisissait ses destinations, et rappelle que cet internet existe toujours, simplement enseveli sous le web corporate. Pour y revenir, il faut se réhabituer à un internet plus lent, au contenu fini, en persévérant comme pour toute nouvelle habitude.
La discussion, largement déconnectée du contenu technique attendu de l'article, tourne autour d'un constat partagé : la perte d'intentionnalité dans la consommation d'internet. Plusieurs commentateurs témoignent de démarches volontaires de désintoxication — abandon des réseaux sociaux, retour au livre, listes d'intentions avant d'allumer l'ordinateur — avec des retours concrets (quatre livres lus en un an, concentration retrouvée après plusieurs longs romans, y compris chez des personnes avec ADHD). Un praticien (psychologue en counseling) rapporte que le « Tetris effect » cité dans l'article se retrouve chez ses patients, dont la pensée devient occupée par ce qu'ils consomment excessivement.
Des voix nuancent ou contredisent la nostalgie de l'article. Plusieurs commentateurs corrigent le tableau idyllique du web ancien : les portails comme Lycos, Yahoo! ou MSN étaient déjà bourrés de liens accrocheurs et de publicité, et le navigateur Mosaic de 1993 offrait une recherche plein-texte de l'historique que les navigateurs actuels n'ont jamais rééditée. D'autres soutiennent que « choisir » n'est pas « être intentionnel » : l'esprit vagabonde 30 à 50 % du temps même hors des écrans, et la présence reste une compétence à entraîner, quel que soit le média. Un avis minoritaire défend au contraire les recommandations algorithmiques comme un outil de navigation nécessaire dans une bibliothèque infinie, à condition de comprendre ses biais.
Côté solutions concrètes : désactivation systématique des recommandations et purification des flux via uBlock/AdGuard, RSS et lectures uniquement choisies ; auto-hébergement et LAN locales déconnectées d'internet comme exercice de concentration ; pratique d'activités physiques (tennis, roller) comme rappel du monde analogique. Certains soulignent enfin que la publicité et les plateformes à contenu enflammé ne se contentent pas d'informer mais façonnent la perception de soi et du monde.
-
What happened to the Snowden archive
Le dernier document de l'archive Snowden a été publié le 29 mai 2019 par The Intercept ; depuis, aucun média n'a publié de document provenant de cette archive. L'article retrace la chronologie du transfert des documents en 2013 : contact progressif avec Glenn Greenwald, Laura Poitras et Barton Gellman, remise de l'archive chiffrée « Pandora » (environ 50 000 documents), puis distribution de copies de secours à plusieurs personnes, dont certaines qui n'ont probablement pas les clés de déchiffrement.
Greenwald affirmait en 2019 détenir toujours une copie complète, et Poitras déclarait en 2022 que l'archive « existe toujours » avec « une quantité énorme d'informations non rapportées » ; Greenwald évoquait en 2023 « des centaines de milliers de documents ». Aucun des deux n'a rien publié depuis des années et aucun n'a expliqué pourquoi.
La discussion s'interroge sur le sort de l'archive Snowden : pourquoi une si petite part des documents a été publiée et pourquoi le sujet a disparu du débat public. Plusieurs commentateurs partagent un sentiment de désillusion : la confiance placée dans les journalistes et les organisations pour exploiter l'archive s'est dissoute par ego, incompétence, pressions et lassitude du public. D'autres expliquent le silence par le déplacement de la fenêtre d'Overton : la surveillance de masse et les métadonnées, scandaleuses en 2013, sont devenues banales, et la polarisation politique rend toute révélation inaudible. Un commentateur note aussi le caractère représentatif de ce qui a été publié : publier 100 variantes de la même histoire n'aurait guère de valeur, et le tri pour protéger les identités est long et pénible.
La question de la position de Snowden divise. Un commentateur regrette qu'il ait fui vers la Russie, ce qui l'assimile aux yeux du public à un traître ; d'autres le corrigent : il n'a pas « fui » en Russie mais y a été bloqué par la révocation de son passeport par l'administration Obama, alors qu'il se rendait en Équateur. On rappelle qu'il a déclaré avoir détruit les documents qu'il détenait avant d'atterrir à Moscou pour se prémunir de toute pression russe, et qu'il reste aujourd'hui probablement sous surveillance des services russes et contraint au silence politique. Plusieurs soulignent que presque tous les acteurs ont payé un prix (Appelbaum écarté de Tor, Greenwald poussé vers les médias alternatifs, l'exemple Assange), ce qui aurait dissuadé les rédactions de continuer ; Snowden lui-même avait demandé de ne pas publier les secrets militaires directs.
Les apports concrets incluent la suggestion britannique d'une publication automatique de l'archive après 100 ans sur le modèle des National Archives, le rappel que l'héritage durable de Snowden est plutôt la généralisation de HTTPS, et l'évocation des fichiers « assurance » de WikiLeaks jamais déchiffrés.
-
What Sun got wrong
L'auteur, ancien de Sun et cofondateur d'Oxide, revient sur ce que Sun Microsystems a raté, à l'occasion d'un t-shirt hommage réalisé pour la rencontre annuelle OxCon. Si la nostalgie pour Sun est largement méritée, il estime que l'entreprise s'était lassée des mécaniques concrètes de gestion d'une entreprise.
Son exemple central : en 2005, une startup en forte croissance, pionnière du cloud computing et utilisant OpenSolaris, voulait acheter massivement du matériel Sun mais n'arrivait pas à les joindre, tandis que Dell, contacté via un simple formulaire web, dépêchait dès le lendemain un commercial local qui gérait tout en deux semaines. L'entreprise, qui a raconté l'épisode dans un billet « The Sun Doesn't Shine on Me », est devenue un client Dell malgré une stratégie open source pourtant gagnante pour Sun.
Pour l'auteur, une entreprise lassée de l'opérationnel échoue quelle que soit sa stratégie ; Sun a périclité malgré les tentatives de redressement. Lui-même a ensuite rejoint cette startup, qui a aussi embauché « Steve » de Dell, avec lequel il a fondé Oxide. Conclusion : honorer les anciennes entreprises informatiques en tirant les leçons de leurs réussites comme de leurs échecs.
La discussion nuance fortement le titre de l'article : plutôt que d'un Sun « lassé de gérer son business », plusieurs anciens employés décrivent une entreprise qui n'a jamais su être une entreprise. Un ex-salarié (1995-2004) évoque des problèmes structurels masqués par la bulle internet : guerres internes entre divisions (Solaris/SunSoft vs SPARC), absence de stratégie unifiée, et une obsession de l'« entreprise » au sens interne — le vrai concurrent de chaque groupe étant un autre groupe de Sun. Un stagiaire puis membre des Sun Labs confirme le tableau : excellente ingénierie (Solaris parmi les meilleurs kernels), mais refus répété de comprendre Linux et l'open source, fatal à terme.
Les retours de terrain s'accordent sur deux causes concrètes de chute. D'abord l'expérience d'achat : fin des années 90, acheter chez Sun ou DEC impliquait des rendez-vous commerciaux et des devis interminables, quand Dell livrait un serveur le lendemain à prix affiché — et un commentateur note que Dell est aujourd'hui devenu ce que Sun était, avec des prix négociables au gré du commercial, tandis que des vendeurs en ligne configurables offrent une transparence totale. Ensuite le rapport qualité/coût : contrairement à la légende, le matériel Sun n'était pas forcément supérieur — un praticien rapporte des réparations plus fréquentes que sur du Dell ou Compaq, et cite Bryan Cantrill (« nos boîtes x86 écrasaient l'UltraSPARC ») pour montrer que SPARC n'était plus à la pointe bien avant Oracle. Un gestionnaire d'un parc Solaris/Sun Ray vers 2004 explique qu'il était moins cher de migrer vers Linux/Intel en achetant des pièces de rechange pour un placard que de payer le contrat de support Sun.
Les désaccords portent sur l'importance de l'interface utilisateur (un commentateur estime que seuls Jobs l'ont prise au sérieux ; d'autres répliquent que Linux a conquis le monde avec une mauvaise UI et que SGI a disparu malgré de meilleures interfaces) et sur la nostalgie : un avis minoritaire regrette la perte d'un écosystème de matériels variés au profit d'une « course vers le bas » Dell/Linux.
-
AX – Google’s Open Agentic Orchestrator
Google annonce AX, un orchestrateur open source d'agents IA déclaratif. AX exécute des tâches agentiques dans des sandbox isolés (limites CPU/mémoire), configure automatiquement les workspaces (repos Git, serveurs MCP, skills) et gère les politiques réseau via allowlist d'hôtes, avec configuration centralisée des modèles et secrets.
Chaque tâche s'exécute comme un acteur léger sur Agent Substrate, un runtime conçu pour la densité massive : AX prétend scaler jusqu'à des milliards de sessions agentiques concurrentes par cluster. Les agents inactifs (en attente d'un modèle, d'un outil ou d'un humain) sont checkpointés et suspendus, puis relancés en moins d'une seconde sans cold-start, et plusieurs tâches partagent les ressources des workers pour ne payer que le temps de calcul actif.
La plateforme intègre des fonctions génératives : un workspace peut être décrit en langage naturel et l'environnement est préparé par un agent au premier démarrage. AX vise les développeurs et chercheurs (évaluation d'agents, boucles de renforcement, collecte de trajectories) et est issu de travaux de recherche sur les runtimes agentiques chez Google, en collaboration avec Google DeepMind.
La discussion autour d'AX, l'orchestrateur agentique open source publié par Google, tourne autour de trois thèmes : le flou du positionnement du produit, la fiabilité du label « Google », et les bonnes pratiques d'isolation des agents.
Plusieurs commentateurs remettent en cause le titre de l'article : le projet est hébergé sur le GitHub officiel de Google, mais il s'agirait selon eux d'une initiative de quelques employés plutôt que d'un produit soutenu par Google, DeepMind ou GCP — le site lui-même ne revendiquerait pas cet appui. D'autres expriment une méfiance plus générale envers les projets Google, citant leur propension à abandonner leurs produits et un cas concret où Google aurait gardé pour lui des correctifs de sécurité Android sans les upstreamer. Certains trouvent d'ailleurs que le site n'explique pas clairement l'usage, et un commentaire évoque un projet Google parallèle, Scion, jugé plus mature et mieux intégré aux outils existants qu'AX, qui imposerait selon un commentateur (contredit par un autre citant le site, qui décrit AX comme peu opinieux) une pile trop fermée.
Le débat technique le plus riche concerne l'infrastructure d'exécution des agents. Un praticien décrit la stack Google sous-jacente : gVisor dans GKE Sandbox pour les garanties de sécurité, et les snapshots de pods (mémoire + filesystem stockés dans GCS) permettant démarrage, suspension et fork quasi instantanés — ce qui expliquerait le choix de Kubernetes, que d'autres jugent pourtant une sur-ingénierie (« le Multics du cloud », « du YAML pour rien »). Plusieurs partagent leurs montages alternatifs : VMs Proxmox avec dotfiles, mini-PC Linux dédié aux agents avec egress et gestion des secrets comme manques principaux, microVMs type Firecracker, ou projets maison (amika, orchflows, substrate, clrk, mastra). Un avis nuance : laisser les agents tout gérer est coûteux en tokens et incohérent, mieux vaut des scripts déterministes pour l'orchestration. La cible réelle d'AX serait selon un commentateur les charges massives et bursty (evals, RL, training), pas les équipes de développement individuelles.
-
Transformers Explained Visually
Explication visuelle et pédagogique du fonctionnement des Transformers, l'architecture introduite en 2017 par le papier « Attention is All You Need » et devenue la base des modèles génératifs comme GPT, Llama ou Gemini.
L'article détaille les trois composants clés : l'embedding (tokenisation, vecteurs sémantiques, encodage positionnel), les blocs Transformer avec leur mécanisme d'attention multi-têtes (matrices Query, Key, Value illustrées par une analogie avec un moteur de recherche) et les probabilités de sortie. Le modèle GPT-2 (small), avec 124 millions de paramètres et 12 blocs, sert d'exemple concret.
Le déroulé pas à pas couvre la tokenisation (vocabulaire de 50 257 tokens), les embeddings 768-dimensionnels, le masquage de l'attention pour empêcher l'accès aux tokens futurs, jusqu'aux étapes de scaling et softmax.
Le fil tourne autour d'une visualisation interactive pédagogique des transformers, illustrée par GPT-2. Les retours sont globalement très positifs : plusieurs commentateurs la jugent intuitive et utile pour comprendre le mécanisme de l'attention, et quelques ressources alternatives sont recommandées, notamment le « Illustrated Transformer » de Jay Alammar et la visualisation LLM de bbycroft.net (déjà discutée plusieurs fois sur HN), ainsi qu'un ouvrage sur les LLM du même auteur.
Un apport technique notable : un commentateur souligne qu'un head d'attention se comporte comme une couche dense ordinaire traversée par le vecteur de valeur, la matrice d'attention jouant le rôle de poids construits dynamiquement à l'inférence à partir des clés et requêtes — un point rarement mis en avant. Sur la question « pourquoi les autres architectures n'ont pas marché », un praticien répond qu'elles fonctionnent aussi, mais que les transformers offrent un meilleur compromis précision/calcul : l'information circule en une seule étape entre positions éloignées, contre de nombreuses couches pour un CNN dilaté, et l'entraînement est efficace ; sans transformers, on aurait quand même pu obtenir de puissants modèles, simplement plus lents et gourmands.
Deux critiques visent l'article lui-même. D'abord, la notion de température : parler de « sécurité » serait une erreur, température 0 produisant un texte artificiellement monotone, et la section sur le dropout serait dépassée par rapport aux recettes modernes. Ensuite, plusieurs estiment problématique d'utiliser GPT-2 comme modèle pédagogique alors que, par exemple, l'encodage positionnel absolu n'est plus utilisé (RoPE étant jugé plus simple à expliquer) ; un avis opposé rétorque que la pédagogie impose de simplifier. Enfin, un reproche pratique récurrent : la page télécharge un modèle de 600 Mo et consomme plus de 2 Go de RAM, ce qui a fait planter des navigateurs entiers (Chromebook notamment).
-
ZuckOff Know when a camera is in the room
ZuckOff est une application iPhone qui détecte la présence de lunettes caméra (Ray-Ban Meta, Oakley Meta, Snap Spectacles…) en écoutant leurs annonces Bluetooth, identifiables par la signature du fabricant. L'app fonctionne localement, sans compte ni envoi de données, affiche les preuves derrière chaque détection, journalise tous les appareils Bluetooth entendus, et permet d'exclure ses propres lunettes des alertes. Des alertes en arrière-plan, un widget et une Live Activity sont disponibles.
L'auteur précise les limites : les lunettes sont surtout détectables au démarrage ou au dégainement, certaines restent silencieuses, et le niveau du signal donne une distance approximative sans direction. L'équipe collecte des captures de nouveaux appareils auprès des utilisateurs pour enrichir ses règles de détection et se dit ouverte à des collaborations avec des groupes de défense de la vie privée. Une gamme de merchandising imprimé à la demande finance le projet.
La discussion porte sur « ZuckOff », une application détectant via Bluetooth les lunettes caméra (type Meta Ray-Ban) présentes dans une pièce. Les commentateurs relèvent d'emblée que l'idée n'est pas nouvelle : un projet open source équivalent (« yj_nearbyglasses ») existe depuis longtemps, et plusieurs mentionnent que l'application Android « Nearby Glasses » faisait déjà la même chose. Certains reconnaissent cependant que le nom accrocheur de ZuckOff constitue un vrai avantage marketing, notamment pour toucher un public non technique, même si l'application apparaît « vibecodée » (générée par LLM) avec merch payant et offre pro, ce qui agace une partie des commentateurs qui critiquent aussi son site confus, sans lien de téléchargement évident.
Sur le fond technique, plusieurs participants restent sceptiques : la détection repose sur les signatures Bluetooth des fabricants, spoofables avec un simple ESP32 à 5 dollars, et un signal « possible enregistrement » est jugé difficile à intégrer dans son comportement quotidien. Un commentateur souligne qu'une personne réellement déterminée à filmer en cachette utilisera des caméras dissimulées (briquet, boucle d'oreille) bien plus faciles que des lunettes détectables. Le titre de l'article est d'ailleurs corrigé : l'application ne détecte pas « une caméra », mais seulement des lunettes caméra connues. La batterie du scan Bluetooth permanent est également interrogée. Une suggestion marquante : un standard « do-not-film-me » diffusant un hash biométrique rotatif via Bluetooth pour flouter les visages, mais d'autres répondent que c'est un problème social et que les fabricants n'ont aucun intérêt à coopérer — citant un article du New York Times sur le retour de la reconnaissance faciale chez Meta, planifiée en profitant d'un environnement politique favorable.
Le débat oppose aussi les utilisateurs défendant ces lunettes : un pratiquant de vol en planeur explique qu'elles n'ont pas d'équivalent pour enregistrer ses vols et qu'il ne publie rien, rappelant que la technologie a des usages légitimes, y compris médicaux, et que les porteurs subissent parfois des agressions verbales.
-
Grok 4.7
xAI annonce Grok 4.7, son modèle le plus capable pour le code et le travail de connaissance. Basé sur un nouveau modèle de base plus large que Grok 4.6 et entraîné avec un longer run de renforcement sur des tâches complexes de plusieurs heures, il vérifie mieux son propre travail et gère de plus longs contextes. Il est servi au même prix et à la même vitesse que Grok 4.6, et affiche d'après xAI une performance-prix de frontière sur CursorBench 4.0.
Sur les benchmarks GDPval et AA Briefcase, qui évaluent des tâches professionnelles (avocats, infirmiers, analystes financiers), il progresse par rapport à Grok 4.6 et rivalise avec les autres modèles de frontière. Il est également entraîné nativement au harness Grok Bot pour les tâches conversationnelles.
Le modèle embarque une nouvelle pile de garde-fous : meilleure résistance aux jailbreaks, refus sécurisés dans les domaines à double usage (cybersécurité, biologie) avec 62,4 % sur le benchmark biosécurité de LatchBio et 3,3 % de prompts risqués laissés passer sur HackerBench v0.3. Il est disponible dès aujourd'hui dans Cursor, Grok Build, via l'API Grok, les harnesses tiers et les plateformes cloud, à 2 $ par million de tokens en entrée et 6 $ en sortie, avec une variante rapide deux fois plus chère et deux fois plus rapide.
La sortie de Grok 4.7 suscite un accueil mitigé : plusieurs commentateurs saluent la progression rapide de xAI et le fait que le modèle reste compétitif, tandis que d'autres parlent d'une sortie « DOA » et d'un écart persistant avec OpenAI et Anthropic. Un point factuel notable : Grok 4.7 aurait 40 % de paramètres en plus que le 4.6 à prix identique ($2/M en entrée, $6/M en sortie), ce qui suggère une baisse de marge et possiblement des résultats décevants (le retard de deux semaines et le timing la veille d'Opus 5.5 sont cités comme indices). Plusieurs relevent des graphiques jugés trompeurs : le benchmark vedette compare Grok 4.7 en « xhigh » à Grok 4.6 en « high » (le niveau xhigh est nouveau), et omet Astra — une précision apportée en discussion indique que CursorBench teste via Cursor, et qu'OpenAI interdit l'usage d'Astra dans Cursor, ce qui expliquerait l'absence plutôt qu'une triche. Autre point récurrent : la tarification du cache est perçue comme opaque ou défavorable ($0,50/M selon certains, $0,40 selon d'autres, contre $0,25/M pour Fable), pénalisante pour les workflows agentiques dominés par les lectures de cache. Un commentaire signale aussi une régression d'efficacité tokenaire par rapport au 4.6 selon artificialanalysis.ai.
Les retours d'usage divergent selon les modèles. Grok est apprécié par certains pour son style direct « en anglais clair », sa générosité d'usage et sa fiabilité sur des tâches de routine ou frontend (via Cursor), un praticien le trouvant étonnamment bon en raisonnement spatial et import CAD ; un abonné SuperHeavy ($300) note que l'abonnement dure bien plus longtemps que des crédits API ($50 partis en deux heures), et qu'il couvre l'équivalent de 2,5-3 semaines de quotas Codex. À l'inverse, des utilisateurs d'Astra le jugent dans une autre classe malgré son coût en tokens, d'autres préfèrent Sol 5.6 pour le quotidien, et un utilisateur rapporte des comportements défaillants du 4.7 en agentique : boucles de « fixes », instructions AGENTS.md ignorées, fichiers corrompus. Quelques-uns restent sceptiques sur les benchmarks en général, invoquant leur propre expérience terrain.
-
Disney+: New user agreement allows ads before movies in all subscriptions
Disney+ a modifié son contrat d'abonnement pour permettre la diffusion de publicités dans tous les niveaux d'abonnement, y compris les offres commercialisées comme « sans publicité ». La clause 2(k) prévoit des exceptions : publicités imposées par les droits de streaming, contenus en direct ou événements spéciaux, contenus promotionnels, contenus de marque et messages de sponsors. Les abonnés sont liés par les nouvelles conditions sauf s'ils résilent, y compris ceux ayant souscrit avant le changement. En septembre 2026, Disney a envoyé un courriel qualifié de « clarification » aux abonnés allemands indiquant que des publicités pouvaient être placées avant et après les contenus, y compris pour les offres Standard et Premium.
La discussion nuance fortement le titre de l'article. Plusieurs commentateurs soulignent d'abord que le nouvel accord, issu d'un wiki de Disney+, viserait en réalité les publicités déjà intégrées à certains contenus non éditables (notamment le sport en direct) et l'auto-promotion des différentes offres Disney+, plutôt que l'insertion de nouvelles coupures pub dans les films. Un commentateur précise aussi que ce changement ne concerne, pour l'instant, que l'Allemagne. Certains estiment donc que la réaction est disproportionnée, tandis que d'autres objectent que Disney a déjà utilisé des clauses de service étirées (par exemple pour se couvrir des accidents dans ses parcs) et qu'il ne faut pas leur accorder le bénéfice du doute : « sans publicité » doit vouloir dire sans publicité.
-
Bill to Ban Private Equity from Owning Medical Practices
Des élus démocrates, conduits par Elizabeth Warren, ont présenté une législation bicamérale visant à interdire aux fonds de private equity et aux compagnies d'assurance de posséder des cabinets médicaux aux États-Unis. Le texte s'inspire d'une loi de l'Oregon entrée en vigueur cette année et interdit aussi aux management services organizations de contrôler les pratiques médicales.
L'article argumente que la montée en puissance des investisseurs contribue à l'explosion des coûts de santé : les investissements de private equity dans le secteur sont passés de 5 milliards de dollars en 2000 à 104 milliards en 2024, et des études associent cette propriété à de moins bons résultats patients et à des coûts plus élevés. En 2025, 82 % des médecins sont salariés d'hôpitaux ou d'entités corporatives, contre 62 % en 2019.
Le texte prévoit trois voies d'application : la FTC, les procureurs généraux d'État et une action privée des médecins avec dommages triplés, ainsi qu'une divestiture obligatoire. L'article se termine par un appel aux dons pour les 25 ans du média Truthout.
La discussion confirme largement la thèse de l'article : plusieurs commentateurs déplorent l'absorption croissante des cabinets médicaux par le capital-investissement et la plupart sont hostiles à cette tendance. Un praticien rapporte que 45 % des médecins généralistes australiens exercent déjà dans des cabinets détenus par des sociétés, et des témoignages chiffrés évoquent des factures d'ambulance aérienne de 20 000 à 60 000 $ et une hausse de 50 à 80 % des coûts vétérinaires sur six ans (8 à 12 % par an depuis 4-5 ans), les sociétés de PE fragmentant les visites en prestations facturées séparément et majorant les médicaments. Plusieurs soulignent que le phénomène touche aussi dentistes, plomberie, HVAC, crèches ou logements étudiants : les noms locaux sont conservés mais la gestion centralisée pousse la vente agressive et comprime les salaires des techniciens (20 $/heure contre des commissions de 150 000 $ pour les commerciaux).
Les points de désaccord portent sur le diagnostic et le remède. Pour un commentateur influent, la PE n'est qu'un symptôme : ce sont les monopoles et la réglementation qui créent les rentes qu'elle exploite ; une loi d'interdiction favoriserait d'autres « monstres » au nom différent. D'autres estiment que bannir la PE réduirait la valeur de revente des cabinets et pousserait à la consolidation, ou que le vrai problème est le manque de transparence des prix et la résistance des hôpitaux à la concurrence (cas de Walmart Health). Un avis défend un « steelman » : la PE rachèterait surtout des entreprises en échec et leur fournirait une bouffée d'oxygène — position contestée comme de la propagande d'initié. Plusieurs propositions alternatives émergent : plafonner le levier financier plutôt que bannir la structure, imposer une détention minimale de 20 ans, ou imiter les barreaux américains en réservant la propriété des cabinets aux praticiens (modèle « Corporate Practice of Medicine » déjà adopté en Oregon, Californie, Washington et Massachusetts, aux effets encore trop récents pour être évalués).
-
Kev: Tiny Jev-like family of decision models built on top of Qwen3.5
Publication sur Hacker News d'un projet nommé « Kev » : une famille réduite de modèles de décision inspirés de Jev, construite sur la base de Qwen3.5. Aucun détail supplémentaire n'est disponible dans le texte fourni.
La discussion tourne autour de Kev, une famille de petits modèles de décision « Jev-like » construits sur Qwen3.5, et reflète l'engouement récent pour cette classe de modèles. Plusieurs commentateurs soulignent l'intérêt pratique : un modèle de décision unique évite de fine-tuner un modèle par cas d'usage, sert de « if-statement intelligent » pour produire des structures JSON avec un peu d'intelligence intégrée, et peut simplifier la logique de routage interne. Des usages concrets sont évoqués : classification de spam (des modèles 27B sont jugés quasi parfaits mais coûteux, avec une piste alternative via Thomson 1.0-small), agents de jeu avec des NPC pilotés localement, et filtrage/routage dans les applications.
La discussion nuance fortement l'article sur plusieurs points. Des commentateurs doutent qu'un modèle Jev-like bâti sur Qwen (entraîné par RLHF) puisse être assimilé à Jev, entraîné par RLCD ; un utilisateur rapporte qu'en boucle sur la question « quel modèle es-tu ? », Jev finit par répondre Qwen, suggérant une filiation LLM classique. Un retour de terrain négatif décrit un test d'exploration de carte : le modèle n'a su sauvegarder que 3 pièces sur 6 et toujours privilégier la première option, concluant que ces modèles raisonnent mal sur leur historique d'actions. Surtout, un commentaire jugé important affirme que les implémentations open-source passent à côté de l'essentiel : la valeur de Jev viendrait de ses données d'entraînement, pas de l'architecture, et les alternatives testées seraient « très mauvaises » en linguistique comparées à Jev — d'autres répondent qu'un pipeline de génération de données de qualité devrait émerger vu le nombre de personnes sur le sujet. On questionne aussi l'évaluation de la calibration de ces modèles et le problème de l'absence de tool calling, qui rend le knowledge cutoff critique.
Quelques apports concrets complètent le tableau : un utilisateur obtient 220 ms par décision avec un modèle dense 12B sur un vieux PC local (jeu Snake, 200 coups, score 16), montrant que la latence est déjà exploitable en local.
-
NASA’s Mars Sample Return mission is dead
Le titre seul indique l'abandon de la mission NASA de retour d'échantillons martiens (Mars Sample Return), sans texte disponible pour préciser le contexte ou les raisons.
La discussion confirme l'annulation de la mission Mars Sample Return (MSR), mais l'article remis en cause sur la forme : plusieurs commentateurs signalent qu'il date de janvier 2026 et ne comprend pas pourquoi il refait surface. L'accord porte sur le fait que NASA a tué une architecture devenue déraisonnable — entre 8 et 11 milliards de dollars pour environ 500 grammes d'échantillons, avec un retour au mieux vers 2040 — et que la mission avait été conçue autour de lanceurs classiques (Ariane 64) plutôt que d'exploiter la baisse des coûts de lancement. Un commentateur estime que l'article relève du « complaisance institutionnelle » : l'abandon ne vise pas la science martienne en général mais une architecture spécifique, remplacée par une approche modulaire et commerciale voulue par Isaacman.
Les désaccords portent sur l'alternative. Certains plaident pour attendre des missions habitées qui rapporteraient des tonnes de roches ; d'autres objectent que les délais de Starship restent incertains et que l'argument « attendons les astronautes » risque d'avoir précisément condamné MSR sans garantie de relève. Un commentateur relativise aussi l'intérêt de la mission en rappelant qu'on dispose déjà d'environ 400 météorites martiennes sur Terre, mais un autre répond que ces échantillons secondaires rendent la détection de biosignatures bien moins fiable. On s'interroge aussi sur pourquoi la baisse des coûts de lancement ne se traduit pas par des missions martiennes nombreuses et bon marché.
Retours de terrain et éléments factuels : un contributeur du rover ExoMars (Rosalind Franklin) décrit son enchaînement de reports, de 2018 à 2028, à cause notamment de la rupture avec la Russie. Plusieurs évoquent la concurrence chinoise avec Tianwen-3 (lancement prévu en 2028), et certains y voient le symbole d'un déclin scientifique américain. Un proche d'un employé du JPL confirme l'abandon et le sort des échantillons déjà forés par Perseverance, qui resteront sur place de longues années.
-
Fable 5 – Median thinking declined in August
D'après le titre, Fable 5 rapporte une baisse du « median thinking » au mois d'août. Aucun contenu supplémentaire n'est disponible au-delà du titre, ce qui ne permet pas de préciser la nature exacte de cette mesure ni les chiffres concernés.
L'article et une large partie des commentaires rapportent une dégradation perçue des modèles frontier (Fable 5, Opus, GPT) dans les semaines suivant leur lancement : plusieurs utilisateurs décrivent des expériences concrètes où un modèle vif à son lancement devient plusieurs semaines plus tard incapable de tâches qu'il gérait (vérifier des logs via ssh, supprimer un doublon sans en créer un), à niveau de raisonnement constant. L'hypothèse dominante est que les fournisseurs réduisent progressivement l'effort d'inférence (tokens de réflexion, profondeur de raisonnement) pour économiser du compute entre deux sorties, créant une impression d'amélioration artificielle à chaque nouveau modèle. Certains en tirent une conséquence pratique : basculer vers des modèles ouverts auto-hébergés (Qwen, DeepSeek, GLM), quitte à acheter du matériel, pour obtenir une qualité stable et prévisible plutôt qu'une qualité frontier fluctuante.
La discussion est cependant fortement contredite et nuancée par une minorité méthodologiquement rigoureuse. Le point clé : l'analyse derrière l'article n'est pas un benchmark répété sur un jeu de questions fixe, mais une analyse post-hoc des logs de production de l'auteur (43 261 invocations, 7 583 tours, 65 jours) via un proxy MITM sur Claude Code. Des critiques soulignent que les variations quotidiennes reflètent surtout l'évolution du travail de l'utilisateur lui-même — comparaison faite avec tracer la consommation d'une voiture en changeant de trajet chaque jour. De plus, Claude Code change de version pendant la période testée et peut ajuster ses propres paramètres de requêtes, ce qui n'est pas la même chose qu'une modification du modèle sous-jacent ; Anthropic aurait d'ailleurs déjà imputé une dégradation similaire à une régression de l'outil. Des trackers de benchmarks réels répétés dans le temps (marginlab.ai, retort) ne montrent pas de dégradation intentionnelle et suggèrent même une légère amélioration en efficacité de tokens.
-
ZuckOff Is a Free App That Sees Meta Glasses Before They See You
ZuckOff, une application gratuite du développeur polonais Pawel Szydlowski, détecte la présence de lunettes connectées dans une pièce via leurs signaux Bluetooth. L'auteur a enregistré les signaux de divers modèles pour construire une empreinte numérique, permettant d'identifier des Ray-Ban Meta, Oakley Meta ou Snap Spectacles à proximité, avec une estimation approximative de la distance par la force du signal. L'application ne peut toutefois pas savoir si les lunettes enregistrent ni qui les porte.
L'application répond à une inquiétude croissante autour du filmage non sollicité, les écoles et cinémas commençant à interdire ces lunettes. Le voyant d'enregistrement étant facile à masquer au scotch, Meta a annoncé en juillet une mise à jour détectant la falsification de la LED, son CTO Andrew Bosworth affirmant que la caméra est conçue pour être remarquée. Environ sept millions de paires de lunettes connectées Meta ont été vendues en 2025, et une enquête de la BBC a retracé des comptes publiant des contenus filmés avec ces lunettes, dont l'un exposait le visage et le numéro de téléphone d'une jeune femme avec plus de 1,3 million de vues.
ZuckOff, téléchargé plus de 5 000 fois sur l'App Store et 1 000 fois sur Google Play lors de son lancement, serait difficile à faire retirer juridiquement par Meta, car il n'intercepte rien et lit des signaux légaux.
La discussion tourne autour de ZuckOff, une application détectant les Meta Ray-Ban via Bluetooth. Le principal apport des commentateurs est de rappeler qu'une alternative open source existe depuis longtemps : yj_nearbyglasses (Nearby Glasses), ce qui amène plusieurs à juger ZuckOff inutile, voire « sketchy » et « vibecodé » avec une UI d'IA générique et un pop-up de merch à l'ouverture. Un contre-argument notable : le nom « ZuckOff » est un coup marketing bien plus mémorable que « Nearby Glasses », et la presse comme le public en parlent déjà davantage. Un autre précision technique corrige un commentaire pessimiste : la détection ne nécessite pas le mode pairing, la plupart des lunettes continuent d'émettre en Bluetooth tant qu'elles sont portées, et il n'existe pas de bouton pour couper le Bluetooth.
Sur le fond, un praticien souligne les limites du signal : détecter des lunettes ne prouve pas qu'elles filment, et le silence ne prouve pas l'absence d'enregistrement — signal difficile à intégrer dans un comportement. Certains notent l'ironie d'ajouter ses propres lunettes en « appareils connus ». Une proposition ambitieuse émerge : un standard « do-not-film-me » diffusant un hash rotatif de biométrie faciale en Bluetooth pour flouter automatiquement les visages, mais elle est jugée irrecevable en pratique : c'est un problème social et réglementaire, pas technique, et les fabricants n'ont aucun intérêt à y consentir. Plusieurs évoquent l'érosion progressive du consentement (paparazzi, caméras Ring) et citent un article du NYT montrant que Meta a délibérément choisi un moment politiquement troublé pour relancer la reconnaissance faciale.
Des sceptiques pointent le site de ZuckOff : marketing truffé de détails techniques hors sujet typiques des LLM, et surtout une absence totale de lien de téléchargement ou d'instructions d'utilisation. La comparaison avec noglasshole.com tourne court : sa vidéo de démo paraît générée par IA et son floutage s'applique à des nuques. La discussion s'égare aussi en références littéraires (The Quantum Thief, The Mountain in the Sea, Black Mirror) et en plaisanteries, sans autre valeur factuelle.
-
Grim Fandango Puzzle Document (1996) [pdf]
Partage d'un document PDF datant de 1996 concernant le design des puzzles de Grim Fandango, le jeu d'aventure de LucasArts. Aucun contenu supplémentaire n'est disponible au-delà du titre.
La publication du document de design des puzzles de Grim Fandango (1996) déclenche surtout une vague de nostalgie : plusieurs commentateurs le citent parmi leurs jeux d'aventure préférés, louant son ambiance, sa musique, son écriture et son style graphique. Des retours de terrain évoquent des parties en famille avec des enfants (souvent freinées par la complexité de l'anglais du jeu) ou des souvenirs d'achat à l'époque, comme celui d'un mineur ayant dû négocier l'achat en magasin à cause des squelettes sur la jaquette.
La discussion nuance cependant le portrait idyllique du jeu : plusieurs commentateurs trouvent les puzzles obscurs — le fameux « puzzle de la chaîne » reste incompréhensible même après l'avoir terminé —, la navigation 3D frustrante (l'équivalent 3D du pixel-hunting) et le jeu buggy. Un avis minoritaire va jusqu'à le juger l'un des jeux d'aventure LucasArts les moins réussis, un jeu « polarisant ». D'autres soulignent avec amusement que Tim Schafer avait parsemé ce document interne de blagues et de dessins — dont un encadré destiné à recueillir « les larmes de joie » — et révèlent une anecdote croustillante : le puzzle final n'était pas conçu au moment de rendre le document, et Schafer avait camouflé deux paragraphes sans signification sous un prétendu défaut d'impression.
Quelques apports factuels ponctuent l'échange : le concept artist est identifié (Peter Chan), Grim Fandango a contribué à populariser Lua comme langage de script pour les jeux, et le document est bien un document de design (pas un walkthrough), publié pour le dixième anniversaire du jeu, sorti le Jour des Morts 1998. On signale aussi le documentaire en 32 épisodes sur le développement de Psychonauts 2 et un article de The Digital Antiquarian sur le jeu.
-
Turn off and restrict access to Apple Intelligence features on Mac
Guide de support Apple expliquant comment désactiver ou restreindre les fonctionnalités d'Apple Intelligence sur Mac via « Temps d'écran ». En activant les restrictions « Contenu et confidentialité » puis le menu « Intelligence et Siri », il est possible de bloquer séparément les outils d'écriture, les fonctions de création d'images (Image Playground, Genmoji, Baguette graphique) et les extensions d'IA tierces comme ChatGPT. Apple précise qu'Apple Intelligence n'est pas disponible dans toutes les langues et régions et recommande la dernière version de macOS pour accéder aux fonctionnalités les plus récentes.
La discussion révèle une frustration massive envers Apple Intelligence : les commentateurs s'accordent sur le fait que ces fonctionnalités sont activées par défaut et que leur désactivation est volontairement laborieuse. Plusieurs dénoncent le titre même de l'article (« turn off » plutôt que « turn on ») comme révélateur d'un problème de consentement, et comparent Apple au niveau de « crapware » de Microsoft : une longue liste de désactivations après chaque installation pour retrouver un sentiment d'agencement sur sa propre machine. Un commentateur, vexé par le bouton « Write with Siri » qui apparaît à chaque sélection de texte, évoque quitter la plateforme après 30 ans.
Le point le plus concret concerne le placement des réglages : le bouton pour désactiver les outils d'écriture se cache dans Réglages → Temps d'écran → Restrictions → Siri → Assistance à l'écriture, un chemin que personne ne trouverait spontanément. Plusieurs commentateurs y voient soit un dark pattern intentionnel, soit le symptôme d'un application Réglages devenu incohérent (Wi-Fi et Réseau séparés, etc.), car personne chez Apple ne pense « globalement » — l'hypothèse retenue est que ces contrôles ont été pensés uniquement pour les appareils d'enfants. Sur iOS, il faudrait parcourir 5 ou 6 étapes pour chacune de huit applications différentes.
Autre grief largement partagé : l'espace disque occupé par les modèles locaux n'est jamais récupérable, même sur des Mac M1/M2 qui les exploitent à peine — et l'option « réclamation quand le disque est presque plein » est contestée philosophiquement. Des utilisateurs signalent aussi des bugs gênants : le bouton Siri du menu bar qui revient après suppression, des suggestions de noms de fichiers qui ont corrompu des centaines de fichiers nommés par adresses, un Mac non connecté à iCloud qui affiche quand même les outils d'écriture, et un M5 sur lequel il faut désactiver Apple Intelligence à chaque démarrage.
-
AI coding has made CI a bottleneck, so we reworked ours to keep up
Face à l'accélération du développement due aux agents de codage IA, la CI de Linear était devenue un goulot d'étranglement, avec des coûts d'infrastructure en hausse et des temps d'attente croissants pour les développeurs comme pour les agents. Malgré des suites de tests quasi quadruplées depuis le début de l'année, l'équipe a ramené le temps d'attente des PR de plus de 6 minutes à un peu plus de 5, et réduit de moitié le temps de runner par test.
Les optimisations ont porté sur quatre axes : migration des workloads de GitHub Actions vers des runners tiers aux CPU et caches plus performants (jobs 34% plus rapides en moyenne), adoption du compilateur natif tsgo (tsc hebdomadaire réduit de 73%), réécriture des règles de lint custom pour se passer du type checker TypeScript (-68% sur le lint API), puis passage à Oxlint. Les jobs de gating critiques ont été allégés via un fetch limité en profondeur, un checkout custom résilient aux instabilités réseau avec retry et cache git persistant, et le déplacement d'écritures de marqueurs hors du chemin critique.
Le billet de Linear sur le passage à l'échelle de sa CI face au coding agentique trouve un écho, mais la discussion relativise fortement la thèse. Plusieurs commentateurs estiment que la CI n'est qu'un maillon de la chaîne : pour certains le vrai goulot d'étranglement est le test humain — vérifier que le produit fait ce que veulent les clients — voire, à terme, les utilisateurs eux-mêmes. D'autres soulignent que si la productivité avait autant augmenté, on devrait le voir dans les revenus, or l'indicateur du débat (« où sont les nouvelles fonctionnalités ? ») reste flou : la frénésie de commits ne semble pas se traduire par des produits visiblement meilleurs, même si des petits projets individuels prolifèrent.
Une critique récurrente vise la qualité des tests générés par IA : beaucoup seraient du remplissage trivial (tests d'exports, même de fichiers markdown), ce qui répond directement au chiffre de l'article selon lequel les suites de tests ont quadruplé — un commentateur demande si elles ont produit quatre fois plus de valeur. Un avis opposé estime au contraire que la revue de PR se recentre désormais sur les tests, et que des tests end-to-end solides sont justement ce qui rend possible les grands refactors agentiques. Sur le fond technique, les retours confirment la lenteur de GitHub Actions (infra Azure, incidents) : migration vers des runners tiers comme blacksmith.sh, self-hosting (y compris sur un vieux MacBook Air), ou Bazel. Notamment, un praticien rapporte qu'une conversion Bazel qui lui avait pris des années a été faite en deux semaines avec des agents — le coût d'entrée a chuté sans que l'industrie en ait conscience, même si d'autres nuancent que réseau et I/O disque restent le vrai goulot, surtout hors monde Java/C++.
Quelques digressions sur des alternatives (Dagger, pushgate, vitest) et un débat architectural ponctuent le fil : l'un suggère des services plus petits et contractualisés pour les agents, d'autres répondent que des frontières de services mal dessinées sont une erreur pire que tout.
-
Show HN: Mini-AGI – Dynamic continual learning model trained on 8GB VRAM
mini-AGI est un modèle de langage expérimental en apprentissage continu, au niveau octet (sans tokenizer), qui entraîne son architecture de zéro sur un GPU grand public doté de 8 Go de VRAM et continue d'apprendre à partir de tout ce qu'il lit, sans oubli catastrophique.
Ses poids sont stockés sous forme de fichiers sur disque et paginés vers la carte selon la demande : le nombre de paramètres est donc limité par l'espace disque plutôt que par la VRAM. Le modèle ajoute de la capacité quand il en manque, élaguer ce qui n'est pas sollicité, et lit via exactement le même chemin de code que celui utilisé pour la génération. L'architecture associe des blocs denses préliminaires, un bloc récurrent appliqué jusqu'à 24 fois avec sélection de 8 experts par application, et une profondeur adaptative (recette PonderNet) : les caractères simples s'arrêtent tôt, les difficiles utilisent plus de profondeur.
L'auteur précise qu'il s'agit d'un modèle jouet, loin des capacités de pointe : l'objectif est de démontrer qu'un apprentissage continu depuis un flux unique de données est possible sur du matériel modeste, permettant à chacun d'entraîner son propre modèle sur ses données. Les poids ne sont pas encore publiés ; la première passe sur le corpus dure encore quelques semaines. À 243 millions de caractères lus, le modèle produit des textes grammaticalement corrects mais répétitifs.
Le projet Mini-AGI, un modèle à apprentissage continu entraînable sur 8 Go de VRAM, suscite un mélange de curiosité et de scepticisme marqué. Le principal reproche, repris par plusieurs commentateurs, est le contraste entre le nom « AGI » et l'absence totale d'évaluations : pas de benchmarks, pas d'ablation, pas de lien avec la littérature sur l'apprentissage continu. Un professeur ayant publié sur le sujet juge le travail dénué de substance, et un autre commentateur rappelle qu'un simple modèle dense de 8 millions de paramètres entraîné sur enwik9 atteint 1,15 bpb, contre 1,8 pour ce modèle — la discussion contredit donc frontalement le titre de l'article.
Des réserves techniques s'ajoutent. Plusieurs commentateurs doutent que l'approche règle l'oubli catastrophique : le taux d'apprentissage du tronc, fixé à 0,1x celui des experts, ne fait que ralentir l'oubli plutôt que l'empêcher, et la contraction du pool d'experts provoquerait des pertes par paliers. L'auteur reconnaît que le modèle est trop petit et sous-entraîné pour prétendre à une généralisation, et indique n'avoir testé qu'un flux de 524 Ko de données d'échecs (dégradation marginale des autres domaines). Un observateur note aussi que le transcript partagé ne montre aucune réponse cohérente pendant l'entraînement. Certains s'interrogent enfin sur l'intérêt face à du RAG et une bonne gestion de contexte, la connaissance paramétrique étant par construction lossy.
L'auteur reste transparent : il n'a pas les moyens de scaler, a utilisé Claude pendant le développement et publie l'idée dans l'espoir que d'autres l'améliorent. Quelques commentateurs restent positifs — architecture d'échange d'experts jugée élégante, aspects « organiques » appréciés, un avis minoritaire y voyant un proto-AGI — mais dans l'ensemble la discussion apporte surtout des corrections factuelles et des nuances, sans validation des annonces de l'article.
-
Heretic removes restrictions from language models
Un outil appelé Heretic permettrait de supprimer les restrictions des modèles de langage. Le texte fourni se limite au titre, sans détails supplémentaires sur son fonctionnement ou ses implications.
La discussion porte sur Heretic, un outil open source qui supprime automatiquement les refus des modèles de langage en modifiant leurs poids (abliteration). Plusieurs commentateurs s'accordent sur l'intérêt de tels modèles pour des usages légitimes refusés par les services hébergés : rétro-ingénierie d'une caméra IP dont on est propriétaire, déblocage de bootloader, analyse de CVE sur son propre réseau. Un utilisateur rapporte même qu'un modèle chinois (GLM) répondait à ce genre de demandes sans manipulation, suggérant que les refus y sont surtout liés au post-training. L'auteur de l'outil explique la méthode : soumettre des prompts refusés et non refusés, puis éditer itérativement les poids pour que les deux groupes convergent dans le même espace latent.
Le principal point de division concerne la qualité réelle des modèles ablitérés. Un avis détaillé soulève deux limites : les modèles entraînés avec le refus peuvent ne pas contenir les connaissances recherchées (produisant des hallucinations), et la qualité peut chuter sur des questions sans rapport. D'autres nuancent : pour la plupart des modèles, y compris sur les sujets politiques censurés, l'information est bien présente dans le pré-entraînement et le refus vient du post-training — l'exception notable étant GPT-OSS, dont les données d'entraînement sont si filtrées que l'information absente est réellement absente. Un commentateur note que les métriques avancées (nombre de refus, divergence KL) sont des métriques standards de la littérature, mais peut-être surexploitées ; l'auteur répond que ce sont précisément les métriques canoniques du domaine. Des retours d'expérience positifs sur petits modèles locaux compensent partiellement les critiques sur la qualité dégradée des réponses sur des sujets sensibles.
Sur le plan juridique, un commentateur prédit que ces modèles seront les premiers interdits, ce qu'un autre juge infaisable vu l'échec des tentatives contre le torrent : le processus est trivial (une simple commande pip) et les poids circulent librement. La question du risque pour des groupes malveillants est balayée par plusieurs réponses arguant que la motivation, non l'outil, est déterminante.
-
Python Workers are now generally available
Cloudflare annonce la disponibilité générale (GA) de Python Workers, deux ans après leur introduction : Python devient un langage de première classe, pleinement supporté, sur la plateforme Cloudflare Developers.
Les Workers Python supportent désormais nativement les bindings de la plateforme (Workers AI, R2, D1, Hyperdrive, Durable Objects, Queues, Workflows…) sans conversion de types vers JavaScript, qui nécessitait auparavant du code glue source d'erreurs. Des connecteurs intégrés permettent d'exécuter des frameworks web Python (FastAPI via ASGI, Django et Flask via WSGI) directement dans le runtime, sans serveur : la plateforme Cloudflare joue le rôle du serveur web et traduit les requêtes au niveau du runtime.
L'intégration d'Hyperdrive devient possible grâce à l'implémentation des syscalls socket dans l'environnement WebAssembly (via Pyodide), ce qui permet aux drivers Python comme asyncpg ou aiomysql de se connecter à PostgreSQL ou MySQL. L'article inclut un exemple de Worker Python appelant le modèle Workers AI gpt-oss-120b.
Cloudflare annonce la disponibilité générale de Python Workers, et la discussion est surtout technique, nourrie par des contributeurs et concurrents du domaine.
Un mainteneur d'urllib3 apporte une correction importante au récit de l'article : le support de Pyodide/Emscripten dans urllib3 provient de contributions externes dont le financement est allé au contributeur, pas aux mainteneurs, qui restent pourtant responsables de la maintenance de ce backend toujours expérimental et explicitement hors du périmètre de leur politique de sécurité (avec un CVE, CVE-2025-50182, lié à ce backend). Un autre commentateur souligne un problème d'architecture plus profond : Pyodide et Cloudflare ne passent pas par la vraie pile réseau mais patchent les fonctions HTTP pour utiliser le `fetch` de JavaScript, et détournent la boucle d'événements Python vers celle de JS — dont la sémantique est préemptive alors que Python est paresseux, ce qui crée des incompatibilités selon lui.
Un dirigeant de Wasmer (concurrent mais bienveillant) juge les progrès réels (PEP 783 standardise PyEmscripten) mais estime que les limites architecturales persistent : dépendance au monde JS/v8 et difficulté à atteindre des démarrages à froid sous 100 ms. Un auteur de l'article répond sur place : plusieurs versions de Python sont choisissables via compat flags (3.12 à 3.14, les anciennes ayant moins de fonctions Pyodide), et les snapshots mémoire ainsi que le sharding ont déjà nettement réduit les cold starts, même si des progrès restent à faire. D'autres remarques concrètes : Pyodide, plus lourd que v8, consommerait des dizaines de Mo de mémoire supplémentaire, et un commentateur signale que toutes les pages d'exemple renvoyaient des 404. Plusieurs regrettent l'absence d'autres langages (Go — jugé impossible sur WASM par certains —, Elixir, Mojo) et certains voient un retour du modèle de Google App Engine lancé en 2008 avec Python 2.5. Le financement de Pyodide via Open Collective est plaidé, avec l'embauche passée d'un développeur par Cloudflare citée comme un bon précédent.