Hacker News
-
Nvidia announces native GPU programming in Rust
NVIDIA annonce son engagement dans la programmation GPU native en Rust avec CUDA Rust, afin de permettre d'écrire des kernels GPU directement en Rust, compilés nativement vers PTX, plutôt que de simples wrappers autour d'un autre langage. L'entreprise souligne que la couche systèmes de l'IA (moteurs d'inférence, infrastructure de serving, drivers, runtimes d'agents) est de plus en plus écrite en Rust, et cite son propre écosystème : le driver Nova Linux, NVIDIA Dynamo et les bindings Rust de NVTX.
Deux pistes sont proposées, calquées sur les deux modèles de CUDA. La piste SIMT, via cuda-oxide, un backend codegen rustc qui route les fonctions #[kernel] à travers le MIR de Rust et le framework Pliron jusqu'au PTX ; elle offre un contrôle fin sur threads et mémoire, avec un mécanisme de sécurité typé (DisjointSlice, launch_contract vérifiés à la préparation du lancement). La piste Tile, via cutile-rs, plus haut niveau : le code s'écrit sur des tuiles de données et le compilateur Tile IR décide du mapping sur chaque architecture, avec des prérequis plus légers (Rust stable, pas de nightly).
L'article détaille l'installation (Linux, GPU compute capability 8.0+, CUDA 12.x/13.3) et montre le même kernel d'addition vectorielle écrit pour les deux pistes, hébergeant code hôte et device dans un même fichier.
L'annonce de Nvidia sur la programmation GPU native en Rust divise les commentateurs. Plusieurs saluent une direction prometteuse, voyant dans la sécurité mémoire de Rust un atout pour le développement de kernels et dans cette ouverture un signe que les GPU évoluent vers des machines parallèles généralistes. D'autres s'inquiètent au contraire de l'ajout d'une couche de dépendance supplémentaire : la pile reste propriétaire (CUDA lui-même n'est pas open source), et le débogage devra désormais distinguer les bugs venant de cuda-oxide (piste SIMT), de Rust, de CUDA ou de l'API Tile (piste Tile).
Des précisions concrètes ressortent : le projet est en pré-1.0 et nécessite un compilateur Rust nightly pour la piste SIMT (cuda-oxide), donc instable ; cuda-oxide était jusqu'ici limité à Linux et à l'async, mais partage facilement les structures entre hôte et device, au prix d'un dialecte WIP qui rend les exemples CUDA existants moins réutilisables (cudarc restant préféré par certains pour sa correspondance 1:1 avec CUDA). Un commentateur rappelle que Nvidia avait open source CUDA Tile IR environ huit mois plus tôt. Des questions restent ouvertes : compatibilité avec WGPU/Vulkan (pas directement, PTX exigeant une traduction, même si une extension Vulkan permet de lancer des kernels CUDA), portabilité vers d'autres architectures, et stabilité de std::autodiff — qui, selon un retour d'une réunion LLVM, resterait en nightly faute de pouvoir garantir la stabilité long terme.
Plusieurs commentateurs critiquent l'article lui-même, estimant qu'il a été écrit par un LLM (Claude), ce qu'ils voient comme un signe de faible investissement de Nvidia dans le projet ; d'autres notent la collaboration avec VectorWare et la communauté Rust, confirmée par un intervenant de VectorWare présent dans la discussion. Enfin, un débat oppose ceux qui trouvent CUDA inévitablement enfermant et préféreraient des API découplées voire un accès documenté à l'ISA des GPU, et ceux qui rappellent que Metal ou D3D12 sont tout aussi propriétaires, ou que des DSL comme Triton rendent déjà l'écriture de kernels plus ergonomique que Rust.
-
Training a 4B model to produce 81% faster query plans than Postgres
L'auteur raconte un entraînement d'un petit modèle 4B, via SFT puis RL (variante GRPO), pour générer des plans de requêtes Postgres plus rapides que ceux de l'optimiseur par défaut : réduction de latence de 44,7 % sur 113 requêtes à jointures multiples, avec un pipeline incluant distillation off-policy à partir de trajectoires d'agents GPT-6 Astra et une infra répartie entre un nœud 2x H100 loué et des conteneurs Postgres locaux.
L'article rappelle le contexte : l'ordonnancement des jointures est NP-difficile, Postgres n'estime que les cardinalités via des statistiques et l'hypothèse de distribution uniforme, ce qui peut échouer. Le problème se prête bien au RL car la qualité d'un plan est facilement vérifiable (temps d'exécution).
Sont aussi détaillés la combinatoire des plans possibles (algorithmes de jointure, orientations, types de scans) et le banc de mesure construit pour limiter le bruit du cache page Linux entre conteneurs concurrents.
L'article présente l'entraînement d'un modèle 4B pour produire des plans de requêtes SQL 81% plus rapides que Postgres. La discussion est majoritairement sceptique : le principal commentaire critique les conditions de benchmark — jeu de données de 8 Go tenant en mémoire, shared_buffers réduits, requêtes préchauffées, lectures seules — ce qui rend les gains difficiles à généraliser à des charges OLTP réalistes ou à des données plus volumineuses. Plusieurs relèvent aussi un paradoxe de dimensionnement : un modèle de 4B paramètres qui consomme plusieurs fois 8 Go de RAM pour optimiser des requêtes sur 8 Go, ce qui fait dire qu'accélérer Postgres via CUDA serait plus pertinent. Un commentaire note que les ~95 heures de location de H100 (~800 $) et les ~400 $ d'appels API pour générer les démonstrations ne semblent pas inclus dans les mesures, et souligne qu'un optimiseur classique aurait mieux fait s'il pouvait se permettre autant de temps de calcul.
Le fond du débat porte sur la pertinence des LLM pour ce problème. Plusieurs commentateurs jugent que c'est une « arme contondente » : l'espace des plans est énorme (indexes JIT inclus) et la construction de plans optimaux est un problème mathématique où un style « AlphaGo » — réseau neuronal entraîné comme heuristique — semblerait plus adapté qu'un LLM pré-entraîné sur du texte sans rapport (on s'interroge sur ce que Balzac ou Reddit apportent au mapping SQL → plans). Des pistes alternatives émergent : modèles hybrides LLM + optimiseur classique en retenant le meilleur des deux, petits réseaux spécialisés recevant des statistiques réelles sur les données sous forme numérique, ou optimisations déterministes exploitant les vraies distributions plutôt que l'hypothèse d'uniformité. Un parallèle avec les compilateurs, optimisés depuis des décennies, suggère qu'un LLM n'y apporterait rien architecturalement. Quelques nuances apparaissent : l'argument de la non-déterminisme tourne court car les plans Postgres dépendent déjà de statistiques parfois périmées et peuvent changer brutalement, et la question de la vérifiabilité d'un plan équivalent à la requête reste ouverte.
-
EU chief opens door for Canada to become 'associate member'
Lors de son discours sur l'état de l'Union, Ursula von der Leyen a soutenu l'idée d'un statut de « membre associé » pour le Canada, premier du genre, sans en préciser les modalités. La coopération porterait notamment sur l'IA, la technologie, la défense et l'énergie, dans un contexte de tensions commerciales entre Ottawa et Washington. Le statut n'existe pas encore et des États membres préfèrent approfondir les accords existants.
Elle a aussi proposé un Conseil européen de sécurité incluant le Royaume-Uni et l'Ukraine, un mécanisme permettant de convoquer une réunion d'urgence en cas de menace, présenté comme complémentaire à l'article 4 de l'OTAN.
Sur le volet numérique, elle a annoncé des discussions avec les plus grands laboratoires d'IA, une réduction de la bureaucratie pour les entreprises, et des restrictions sur les réseaux sociaux pour les mineurs, dont une interdiction pour les moins de 13 ans et des comptes supervisés par les parents pour les 13-15 ans.
La proposition d'un « statut de membre associé » du Canada à l'UE suscite surtout des réflexions géopolitiques : plusieurs commentateurs y voient une conséquence directe du tournant protectionniste et imprévisible des États-Unis (tarifs arbitraires, menaces sur le Groenland et le Canada, rapprochement avec la Russie), et saluent l'idée que les « démocraties de taille moyenne » (UE, Canada, Australie, Nouvelle-Zélande, Royaume-Uni) se regroupent pour ne pas être écrasées entre les États-Unis et la Chine. Un avis minoritaire juge au contraire que le Canada se « déclasse » ainsi en seconde division, et un autre craint que ce type de jeu géopolitique mène à des guerres.
Le fil corrige et nuance fortement l'article sur plusieurs points. Un commentateur rappelle que le statut d'« associé » n'a rien de nouveau : l'article 217 du TFUE (ex-article 238 du traité de Rome) prévoit déjà des accords d'association, la Turquie en ayant un, et plusieurs membres actuels comme la Grèce étaient jadis qualifiés de « membres associés de la CEE ». Autre correction importante : le Canada et l'UE disposent déjà d'un accord de libre-échange (CETA), négocié sous Trudeau, mais jamais entièrement ratifié par tous les États membres — la France notamment — ce qui rend sceptiques plusieurs intervenants quant à la portée réelle d'un statut associé. Un commentateur rappelle aussi que l'UE avait déjà fait pleurer la ministre canadienne du Commerce lors de négociations passées et juge l'Union bien plus protectionniste que les États-Unis ; pour lui, l'annonce relève surtout du symbole diplomatique et d'une monnaie d'échange vis-à-vis de Washington.
Les débats portent aussi sur la réglementation : un Canadien espérait éviter les régimes réglementaires et juridiques européens, mais des citoyens de l'UE répondent que ces règles sont précisément ce qui facilite le commerce — la Norvège et la Suisse les ont dûment acceptées.
-
Small programming tricks
Une collection d'astuces de programmation à fort levier, fondée sur l'idée qu'une bonne part de la productivité d'un ingénieur vient de petits bouts de connaissance isolés.
L'article passe en revue des trucs variés : recherche floue de l'historique shell avec fzf ou atuin, SELECT sans FROM pour tester des fonctions SQL, explain analyze dans PostgreSQL et MySQL, l'assertion de frontière de mot \b en regex, l'usage des logarithmes pour bucketiser des métriques, les méthodes JS modernes comme Array.flatMap ou Promise.withResolvers, le réemploi d'agents https en NodeJS pour réduire la latence, git log -S (pickaxe), les globs en remplacement de find, ripgrep plutôt que grep, et l'activation de l'autocomplétion avancée de zsh.
L'auteur étend l'idée aux entreprises, où beaucoup de savoir utile prend la forme de nuggets (« utilise telle source de données pour tel debug », « telle personne connaît tel sujet »), et raconte avoir partagé une astuce par jour sur Slack dans une précédente boîte, un rythme qu'il juge idéal et qu'il recommande aux ingénieurs seniors.
La discussion porte moins sur l'article lui-même que sur son titre : plusieurs commentateurs relèvent qu'il s'agit surtout d'astuces de ligne de commande, de shell ou de SQL, pas de « trucs de programmation ». Un fil récurrent concerne la difficulté d'acquérir ces habitudes : connaître Ctrl+r ne suffit pas, il faut s'y tenir ; plusieurs décrivent leur propre système de documentation personnelle (fichier de notes, dossier de docs par outil, alias « scratch » avec grep) pour retrouver ces recettes. D'autres soulignent que les shells modernes réduisent le besoin de ces raccourcis : le mode de recherche d'historique de zsh, fish avec saisie partielle et flèche haut, ou des outils comme atuin, fzf et zoxide, ce qui nuance l'intérêt de certains « trucs » de l'article.
Deux apports notables hors article : l'idée, partagée par plusieurs, d'apprendre des astuces en lisant les commandes exécutées par les agents IA plutôt qu'en les laissant autonomes (avec un exemple d'usage méconnu de `perf`), et une série de suggestions concrètes : `git log -S` (complété par `git log -p` + recherche), `git ls-files` comme alternative à `find`, zoxide mappé sur `cd` ou combiné à fzf, `pbcopy`, `python3 -m json.tool`, ou encore l'outil GNU `script` pour enregistrer une session de terminal. Un praticien nuance toutefois les globs face à `find` à cause des limites d'expansion sur de nombreux fichiers, et un autre signale des risques avec `find` utilisé par des agents IA.
Quelques corrections factuelles : la prétendue astuce NodeJS consistant à passer un agent https à `fetch` est contestée comme peu crédible, et le `SELECT` sans `FROM` dépend du SGBD. Un commentaire divise aussi sur l'intérêt d'un script ou skill IA qui configurerait automatiquement le terminal : pour un avis, cela ferait perdre la compréhension de son propre environnement. Enfin, un échange porte sur l'opportunité de partager quotidiennement des astuces en équipe, certains y voyant de l'aide, d'autres une nuisance à confiner dans un canal dédié.
-
Mistral X Mozilla: Private, Multilingual AI Browsing
Mistral et Mozilla annoncent un partenariat : l'assistant de navigation Firefox Smart Window (bêta) est désormais propulsé par les modèles de Mistral. L'outil aide à naviguer dans des recherches complexes, retrouver des contenus consultés et sourcer des informations à partir des onglets du navigateur. Le service est disponible en France et en Amérique du Nord, avec le Royaume-Uni et l'Allemagne attendus plus tard dans l'année.
Le communiqué met en avant quatre arguments : la défense d'une distribution ouverte des technologies open source, l'optimisation des modèles pour les langues et contextes culturels régionaux, la protection de la vie privée (conversations non conservées par défaut sur les serveurs de Mozilla, engagement de zéro rétention des données par Mistral) et la souveraineté de l'IA pour les utilisateurs.
Les deux dirigeants, Anthony Enzor-DeMeo (Mozilla Corporation) et Arthur Mensch (Mistral), présentent ce partenariat comme la rencontre de deux défenseurs de l'open source, souhaitant qu'un navigateur permette à plusieurs fournisseurs d'IA de concourir plutôt que d'imposer un acteur unique.
La discussion est dominée par une contestation du terme « Private » du titre : plusieurs commentateurs soulignent que l'inférence se fait dans le cloud, pas en local, et que le marketing de Mozilla et Mistral n'explique pas clairement cette distinction, qu'ils jugent trompeuse voire « immorale ». Un commentateur note même une erreur sur la page de support Mozilla (lien vers la fiche OpenAI de gpt-oss-120b au lieu du modèle Mistral), signal corrigé par un membre de Mozilla présent dans le fil. Les critiques portent aussi sur la chaîne de confiance : politiques de rétention des données invérifiables par l'utilisateur, partenaires sous contrat, risque de réquisition judiciaire, et sur le modèle économique gratuit qui alimente les soupçons de collecte de données de navigation.
Des nuances apparaissent : quelques participants rapprochent la fonctionnalité du Gemini Nano de Chrome mais d'autres corrigent que Nano fonctionne en local, contrairement à cette offre, ce qui rend Mozilla « pire » que Google ou Apple à leurs yeux. Un point pratique ressort : il est possible d'utiliser « Smart Window » avec ses propres modèles locaux (page « BYOM » de Mozilla), ce que plusieurs regrettent de ne pas voir mis en avant. Le débat sur la traduction automatique divise : l'un y voit une fonction inutile pour les multilingues, d'autres rappellent qu'elle est indispensable à des personnes ne lisant pas la langue des sites.
Enfin, une frange exprime une lassitude générale face à l'IA dans le navigateur, préférant des fonctionnalités classiques (gestion d'onglets, marque-pages modernisés), et plusieurs recommandent des forks comme LibreWolf, Waterfox ou Pale Moon, en s'inquiétant d'une possible bascule des utilisateurs restants vers Chromium et d'une monoculture du Web.
-
Hackers Got Inside a Flock Camera
Des hackers ont décroché une caméra de surveillance Flock au-dessus d'une route, copié presque intégralement ses données et partagé les fichiers avec 404 Media et WIRED. En récupérant une clé de chiffrement stockée sur l'appareil, ils ont déverrouillé des milliers de détections de véhicules, révélant le fonctionnement interne du système de lecture de plaques d'immatriculation.
L'analyse conjointe montre que le logiciel de la caméra détecte explicitement les personnes en plus des véhicules, plaques et vélos. Un véhicule génère environ 28 images (parfois plus de 100) ; sur environ 21 jours de journaux récupérés, la caméra a photographié près de 50 200 véhicules et produit environ 1,6 million d'images. Le détecteur de plaques confond parfois autocollants ou graphismes avec des plaques. Aucune capacité de reconnaissance faciale active n'a été trouvée.
Les données montrent aussi l'ampleur du réseau national de Flock : dans une ville de Géorgie, les enregistrements étaient accessibles à plus de 2 000 agences. Le collectif stegan0gram, auteur de l'opération, a publié ses méthodes pour encourager d'autres à faire de même, tandis que plusieurs municipalités renoncent à ces caméras suite aux controverses.
Les commentateurs s'accordent pour juger la sécurité des caméras Flock indigne d'un matériel exposé en espace public : pas de chiffrement correct des données sur l'appareil, accès physique suffisant pour tout extraire, et une politique de divulgation de vulnérabilités dérisoire — elle exclut précisément les vulnérabilités nécessitant d'interagir avec le device ou touchant la configuration, l'infrastructure ou le durcissement. Plusieurs y voient le signe que la sécurité n'est tout simplement pas une priorité produit : la caméra ne fait que présélectionner les images envoyées au cloud, tout le reste se passe chez Flock, et la vraie menace réside dans les données agrégées de suivi entre caméras plutôt que dans une caméra isolée.
Des apports concrets enrichissent l'article : les images de partition publiées par Distributed Denial of Secrets révèlent un noyau Linux très ancien (3.18.71), des milliers d'erreurs « no space left on device », des crashs et redémarrages en série — certains suggèrent que le matériel était trop faible pour chiffrer ou stocker les données. Une précision corrige une lecture alarmante du journal : les images étaient supprimées dès l'envoi, seuls les logs persistent, la mémoire embarquée ne permettant pas de tout conserver. Le débat sur le "facial recognition" est nuancé : la caméra ne le fait pas, mais des commentateurs dénoncent un langage trompeur — rien n'empêche une reconnaissance faciale côté cloud ou via intégration, d'autant que les caméras capturent des visages humains. S'y ajoutent des questions sur la conformité : la loi du New Hampshire impose une suppression en 3 minutes des plaques sans correspondance (et réserve l'usage aux forces de l'ordre), et le Cyber Resilience Act européen rendrait ces caméras invendables en Europe après fin 2027.
Deux lignes de friction émergent. D'abord, pourquoi Flock s'expose-t-elle ainsi sans conséquence commerciale ?
-
Xiaomi Mimo 2.6 live post-training dashboard
Xiaomi a mis en ligne un tableau de bord public suivi l'entraînement post-entraînement de son modèle Mimo 2.6 en temps réel, sur la base du titre seul (aucun contenu d'article fourni).
La discussion porte moins sur l'article lui-même que sur le tableau de bord public du post-training (RL) du Xiaomi MiMo 2.6, salué comme un geste de transparence rare. Plusieurs commentateurs y voient un signal politique : les labos chinois, poussés par une politique officielle favorable aux modèles ouverts, dépasseraient désormais les labos américains en ouverture, tandis qu'Anthropic et OpenAI, occupés par leurs IPO, n'ont aucun intérêt à faire de même — d'autant que ce sont souvent les managers, et non les développeurs, qui choisissent les modèles dans les entreprises américaines.
Les retours d'usage sur MiMo 2.5 divisent. Un utilisateur très satisfait le juge équivalent aux modèles Anthropic de début d'année avec un coût par million de tokens imbattable, « un ordre de grandeur meilleur » en ROI. D'autres le trouvent nettement plus faible : capable pour des scripts simples mais « bête » face à Qwen 3.8-flash-next ou GLM 5.2/5.3, commettant des erreurs basiques détectées tardivement. Un praticien décrit 2.5-pro comme un « senior engineer distrait nouveau sur le projet » : compétent mais conservateur, mauvais en multitâche ; la version suivante serait un vrai progrès, notamment pour implémenter des issues bien définies sans supervision.
Les chiffres concrets nuancent fortement l'enthousiasme : MiMo 2.5-Pro ne scorait que 19 % sur le benchmark DeepSWE 1.1, contre ~70 % pour Fable et Kimi K3 et 74 % pour Astra — mais le dashboard montre 2.6-pro atteindre 63,7 % au step 10 (60,7 % pour le flash), ce que plusieurs jugent prometteur. Deux caveats techniques ressortent : le dashboard ne montre que des steps de RL post-training (pas le prétraining), et évaluer des benchmarks pendant l'entraînement induit un léger surapprentissage (« benchmaxxing ») même s'il s'agit d'une pratique standard pour les critères d'arrêt. Enfin, un avis sceptique rappelle que rien ne prouve que les données affichées soient réelles.
-
Apple Reference Image: A New Approach for Verified Photography
Apple annonce Apple Reference Image, un mode photo opt-in sur l'iPhone 18 Pro et 18 Pro Max destiné à produire des images vérifiables face à la prolifération des images générées ou altérées par IA. Le système répond aux limites des approches fondées sur C2PA, qui attachent des métadonnées de provenance après la capture et restent vulnérables à des compromissions de la chaîne d'édition, tout en posant des risques d'identification pour les photographes en situation dangereuse.
La solution s'appuie sur trois exigences : authenticité sémantique (l'image reflète fidèlement ce que le capteur a capturé), résilience à la compromission (résistance au piratage du capteur, aux attaques cryptographiques et au jailbreak, avec révocation possible des images frauduleuses) et préservation de la vie privée (aucun observateur ne peut savoir si deux images proviennent du même appareil, et Apple lui-même n'accède pas aux contenus).
Concrètement, le capteur signe cryptographiquement les pixels dès la capture après un secure boot en mode dédié, formant un « négatif numérique sécurisé » incluant métadonnées signées (via le Secure Enclave pour les valeurs hors capteur) et bornes de temps fournies par un service d'horodatage cryptographique d'Apple (en moyenne toutes les 15 minutes).
La discussion autour de « Apple Reference Image » oppose deux camps : ceux qui trouvent le protocole techniquement astucieux et ceux qui estiment qu'il repose sur une confiance excessive envers Apple et crée un faux sentiment de fiabilité. Le cas d'usage journalisme est jugé secondaire : plusieurs commentateurs voient surtout des applications en vérification d'identité et en assurance, où l'exigence n'est pas la résistance aux États-nations mais simplement la difficulté des fraudeurs ordinaires. D'autres rétorquent qu'aucune de ces applications ne résiste à l'exploitation, l'utilisateur final « vérifiant » en pratique des captures d'écran de l'interface plutôt que l'image originale.
Les failles techniques soulevées sont concrètes : l'attaque dite de « replay » — photographier une image générée ou retouchée affichée sur un écran dans une boîte peinte au Vantablack pour bloquer la lumière — produit une image apparemment valide ; Apple n'y répond pas, même si un commentateur note que la solution analogue de Sony intègre des informations de profondeur 3D, et que l'attestation ne prouve que « pris avec ce capteur », pas la véracité de la scène, ce qui reste du ressort de la forensique classique. Sur la vie privée, un commentaire corrige un malentendu courant : l'image brute n'est envoyée aux serveurs Private Cloud Compute que lors de la consultation du badge « Reference », la capture initiale ne transmettant qu'un hash d'horodatage. Un praticien explique l'intérêt du serveur d'horodatage maison : il borne le temps entre la capture (min) et la mise en ligne (max), ce qu'un serveur d'horodatage standard ne permet pas.
Les critiques les plus fortes portent sur le principe même : le système suppose un appareil non contrôlé par son propriétaire, ce que certains jugent inacceptable, et l'impossibilité d'une implémentation open source est réputée structurelle (pipeline verrouillé, clé cachée). Un avis insiste sur la solution sociale : admettre que les images ne sont plus des preuves absolues plutôt que d'entretenir une confiance technique illusoire — un hashtag « vérifié par Apple » risquant de court-circuiter l'esprit critique.
-
The Google Play app review process now regularly takes longer than a week
Selon le titre de l'article, le processus de review des applications sur le Google Play Store prend désormais régulièrement plus d'une semaine. Aucun détail supplémentaire n'est disponible dans le texte fourni.
Les développeurs confirment largement l'article : les délais de review sur Google Play se sont dégradés, dépassant parfois une à deux semaines, et sont désormais souvent plus longs que ceux de l'App Store, ce qui est présenté comme un renversement historique. Signal et AnkiDroid rapportent des attentes aléatoires de plusieurs jours à plus d'une semaine, et CoMaps environ 16 jours. Plusieurs pratiques sont pointées comme aggravantes : l'exigence de 12 testeurs pendant deux semaines pour les nouveaux comptes, la curation spécifique des apps Android Auto (plusieurs soumissions du 3-4 septembre encore en attente), et des consoles jugées complexes et peu lisibles.
La discussion nuance toutefois le tableau : un certain nombre de développeurs expérimentés voient leurs mises à jour passées en quelques heures, suggérant un triage automatisé par niveau de confiance du compte et complexité des changements. Beaucoup décrivent une inconstance plutôt qu'un rallongement uniforme — « parfois 4 heures, parfois 5 jours » — avec une hypothèse partagée de files automatisées et manuelles. Le déluge d'apps générées par IA et de spam est avancé pour expliquer la saturation des reviews humaines. Du côté Apple, plusieurs signalent aussi des délais passés de 24 h annoncés à une à trois semaines pour les nouvelles apps, un contact humain accélérant sensiblement le traitement.
Deux sujets de fond divisent : le gatekeeping lui-même — ses défenseurs rappellent les risques de mises à jour malveillantes contaminant des milliards d'appareils — et les alternatives (web, mises à jour OTA type React Native/EAS, F-Droid malgré sa propre file de build lente mais transparente). Le créateur de Photopea explique avoir renoncé au natif à cause de la limite de 2 Go de RAM imposée par iOS au web. Quelques retours exotiques complètent : Samsung TV (6-8 semaines) et LG jugés pires encore, et une anecdote sur une app frauduleuse antérieure à la création du processus de review de Google.
-
Backups Aren't Simple
L'auteur raconte comment une perte de photos familiales due à un formatage accidentel l'a amené à construire progressivement une stratégie de sauvegarde robuste. Il détaille les concepts clés : avoir des copies ailleurs, éviter les miroirs simples (RAID 1) au profit de snapshots pour revenir en arrière, définir un RPO (Recovery Point Objective), et mettre en place une rotation de type GFS avec snapshots quotidiens, hebdomadaires et mensuels.
Il explique ensuite l'intérêt de la déduplication via liens durs (approche incrémentale utilisée par rsnapshot), qui économise stockage et bande passante, notamment pour les sauvegardes vers le cloud. Une solution combinant rsync et cronjobs fonctionne jusqu'à l'apparition de complications réelles : fichiers root détenus par des conteneurs Docker, bases de données en mémoire sujettes à corruption à la restauration, diversification des types de supports pour parer aux défaillances matérielles, et nécessité d'une copie hors site.
L'article est un retour d'expérience pédagogique montrant qu'un système de backup « simple » devient vite complexe en conditions réelles.
La discussion confirme la thèse de l'article : les sauvegardes sont loin d'être simples, et les retours d'expérience catastrophiques sont légion. Plusieurs commentateurs partagent des pertes de données marquantes : foudre sur ligne téléphonique qui a grillé un modem, conditions d'un service cloud modifiées unilatéralement avec téléchargement brida et délai de récupération rendant les fichiers irrécupérables, carte SD neuve rendue illisible par défaillance du contrôleur. Un témoignage d'entreprise illustre la valeur concrète des sauvegardes hors site : un client victime d'un incendie dans son imprimerie a pu poursuivre son activité depuis le datacenter du prestataire pendant toute la pandémie, grâce à un dépôt XFS avec reflinks et des VM remontées en une heure.
Les commentateurs convergent sur quelques principes. La distinction citée par un ancien de Veritas — « nous ne sommes pas dans le business de la sauvegarde, mais de la restauration » — fait consensus : ce qui compte, c'est la capacité à restaurer, pas à sauvegarder. Un intervenant propose une triade plus fine (redondance, sauvegardes, archives) comme cadre mental. Côté outils, Restic (souvent avec Backrest) domine les retours, aux côtés de Borg, de snapshots ZFS en mode pull avec sanoid/syncoid, de Proxmox Backup Server, et pour un avis minoritaire d'un simple pipeline `tar | zstd | gpg` adapté au modèle d'écriture unique de Glacier. Le schéma 3-2-1 est fréquemment mentionné, ainsi que le point délicat des bases de données : dumps pg, arrêt de conteneurs, ou snapshots cohérents au niveau du système de fichiers. Une nuance pragmatique revient aussi : « mieux vaut quelque chose que rien », un simple clone CCC sur SSD externe ayant sauvé un portable noyé.
Le principal point de divergence porte sur l'injonction universelle : un commentaire estime que la citation « deux types de personnes » n'est pas un fait empirique, que la plupart des gens n'ont pas besoin de sauvegardes et que le risque est faible pour eux — ce que réfute en partie un autre intervenant, pour qui le cloud (Gmail, photos sur Facebook) constitue déjà une sauvegarde implicite pour le grand public, la citation visant surtout les ingénieurs.
-
Wax motor
Présentation du moteur à cire (wax motor), un actionneur linéaire qui convertit l'énergie thermique en énergie mécanique grâce au changement de phase de la cire, celle-ci se dilatant de 5 à 20 % en fondant. Composé d'un volume de cire enfermé, d'un plongeur et d'une source de chaleur (thermistance PTC, solaire, chaleur de combustion ou ambiante), il peut développer des forces de l'ordre de 4000 N et offre une action douce et progressive, parfois entièrement passive sans alimentation externe.
Ses avantages par rapport aux solénoïdes magnétiques (charge résistive, fonctionnement passif possible) lui valent de nombreuses applications : industrie aéronautique pour le contrôle de carburant et d'huiles, vannes thermostatiques, verrouillage de portes de lave-linge frontal, vannes de zones de chauffage hydronique, distributeurs de lessive des lave-vaisselle et ouverture automatique des aérateurs de serres. Il existe également des micro-actionneurs paraffine fabriqués par technologie MEMS.
La discussion autour de l'article « Wax motor » est surtout l'occasion pour les commentateurs de partager des retours de terrain enthousiastes sur la robustesse de ces actionneurs à cire. Plusieurs praticiens confirment leur fiabilité exceptionnelle : un gestionnaire d'hôtel en exploite environ 100 (vannes thermostatiques de radiateurs) et n'en remplace qu'une tous les deux ans environ ; d'autres en ont croisé dans des machines à espresso, des micro-ondes (ouverture de bouches d'aération) ou des petits camions utilitaires, où ils commandent starter et EGR via des lignes à vide — mais ils y sont chers à remplacer, ce qui est jugé étonnant vu le faible coût de la paraffine.
La discussion corrige et enrichit l'article sur plusieurs points. Un commentateur signale une erreur sur la page Wikipédia : une photo légendée comme vanne thermostatique de radiateur montre en réalité un actionneur (le thermostat réagit à la température ambiante, l'actionneur s'ouvre via un élément chauffant commandé par un thermostat séparé). Un autre note que l'article omet le thermostat automobile, qui repose sur le même principe, mais un répondant précise que ce cas est traité sur la page séparée « Wax thermostatic element ». Sont également cités les robinets thermostatiques de lavabo et les ouvre-fenêtres de serre, une application jugée particulièrement élégante — un utilisateur raconte même avoir douté de sa santé mentale en voyant le toit de sa serre se fermer tout seul à l'automne.
Les débats techniques restent légers : un commentateur s'interroge sur l'appellation « motor » (plutôt un solénoïde ?) et un autre sur le fonctionnement en vide d'espace pour des applications spatiales. Un utilisateur détaille l'ampleur de la dilatation de la paraffine observée lors du gainage de micros de guitare (retrait du moule, cavité centrale). Plusieurs regrettent la lenteur et la forte consommation de ces actionneurs, tout en appréciant leur simplicité, et l'un imagine des actionneurs étanches bon marché pour environnements humides.
-
PS5 Linux lead quits: "a bunch of noobs using LLMs" that "they don't understand"
Andy « TheFlow0 » Nguyen, hacker renommé de la scène PlayStation et contributeur majeur du projet PS5 Linux, annonce quitter la scène PS5 et abandonner ses travaux, notamment le support du PS5 Pro prévu pour 2027.
Il justifie son départ par la montée des développeurs « vibe coders » utilisant des LLM : selon lui, la scène, autrefois composée de chercheurs talentueux, est devenue « un tas de noobs utilisant des LLM et écrivant des hacks qu'ils ne comprennent même pas ».
Des utilisateurs d'IA auraient de plus découvert le dernier bug d'hyperviseur qu'il avait lui-même trouvé, promis d'attendre la sortie de GTA 6 avant de le signaler à Sony contre une prime, puis ne l'ont pas respecté, compromettant l'avenir de PS5 Linux sur les firmwares récents. La dernière version disponible reste la 2.5, pour PS5 Phat et Slim en firmware 3.00 à 7.61. Cette annonce fait écho à la décision de l'émulateur RPCS3 d'interdire les contributions issues du vibe coding.
La discussion révèle surtout que le titre de l'article est trompeur : plusieurs commentateurs corrigent le récit. Le conflit ne porte pas d'abord sur du code généré par IA, mais sur une violation d'embargo : un développeur a trouvé, avec l'aide d'un LLM, le dernier bug d'hyperviseur utilisé en secret par TheFlow0 pour le projet PS5 Linux, et l'a signalé à Sony pour toucher le bounty, en manquant une promesse d'attendre la sortie de GTA 6. Le départ du développeur principal s'explique donc par la compromission du projet, pas seulement par du dépit face aux « noobs à LLM ».
Les commentateurs s'accordent sur un point : les LLM abaissent radicalement la barrière d'entrée et changent la dynamique des communautés. Plusieurs décrivent la montée des PR spammy (comparaison avec le Hacktoberfest 2020), des projets avec 5 000 issues ouvertes, et un projet FOSS qui exige désormais une validation humaine manuelle de chaque PR. Beaucoup déplorent la perte du plaisir de collaborer avec des gens compétents, comparée à un nouvel « Eternal September », et certains plaident pour un gatekeeping assumé comme condition de santé des communautés. Des voix plus pragmatiques objectent que si un bug est trouvable par IA, Sony le trouverait aussi, et que le projet était de toute façon condamné.
La question du bounty divise : certains jugent légitime de le toucher dès lors que le bug devenait trivialement découvrable, d'autres condamnent la rupture de parole, tandis qu'un avis note l'ironie de faire reposer la sécurité d'un projet secret sur le fait que personne d'autre n'utiliserait les mêmes outils. Le débat éclaire surtout l'inversion des rôles : l'IA sert désormais moins à produire du code qu'à auditer et trouver des failles, ce qui menace durablement les projets de rétro-ingénierie et le homebrew.
-
Original Sony PlayStation 2 security chip 'broken wide open' after 26 years
La puce de sécurité MechaCon (CXP102064) de la PlayStation 2 originale a été rétro-ingénierée et dumpée après quatre ans d'efforts par l'enthousiaste canadien DiscoStarslayer. La puce contrôlait les mécanismes des lecteurs optiques et gérait la sécurité des disques, notamment le déchiffrement Magic Gate et des fichiers KELF.
La méthode a impliqué un décapage chimique de la puce pour exposer la structure interne, puis une analyse microscopique de la circuiterie, jusqu'à la découverte fortuite d'un exploit permettant d'extraire les données par logiciel. Ce travail profite à la préservation du matériel, à la réparation et aux projets d'émulation, notamment pour l'émulation bas niveau du système complet et le développement homebrew. Il pourrait aussi permettre de remplacer les lecteurs optiques vieillissants des PS2.
La puce MechaCon équipait aussi des bornes d'arcade de l'époque basées sur du matériel PS2 modifié, comme les Namco System 246 et 256 et le Konami Python 1, où son firmware authentifiait la sécurité et permettait l'exécution des données de jeu chiffrées.
Un participant au projet de rétro-ingénierie du MechaCon (la puce de sécurité de la PS2) précise que la découverte, issue d'un décapsulage chimique du CXP102064 et d'un dump optique de la ROM du SPC970, ne permet pas à elle seule de créer un émulateur de lecteur optique (ODE). En revanche, ces dumps ouvrent la voie à une modchip remplaçant le MechaCon, à une émulation bas niveau complète (MagicGate, KELF/KIRX passent par cette puce) et à la recherche de vulnérabilités. Il rappelle aussi que faire tourner des copies de disques est déjà possible par logiciel (exploit de la carte mémoire, HDD, lecteur DVD), sans modifier les disques sur les modèles récents. Un commentaire note que l'article repose essentiellement sur le post X de DiscoStarslayer, qui promet un write-up détaillé ; le projet a publié les dumps et un décompilateur Ghidra pour l'ISA du SPC970.
Les commentateurs s'accordent sur l'intérêt pour la préservation du patrimoine vidéoludique et saluent le niveau d'engagement du décapsulage, en citant des précédents (décapsulage des puces de la SNES, travaux de Ken Shirriff, la communauté documentant les dies jusqu'au niveau transistor). Certains demandent quel bénéfice pratique en découlera, notamment si cela permettra d'intégrer un BIOS libre aux émulateurs ou du homebrew sur console non modifiée — questions restées sans réponse ferme.
Un débat annexe oppose la préservation des jeux PS2, jugée bien assurée, à celle des consoles récentes : les jeux modernes, dépendants de mises à jour jour un et de serveurs, seraient quasi injouables dans des décennies, un disque PS5 ne contenant qu'une version partielle du jeu. Nuance apportée : tout dépend de l'édition du disque possédée. Enfin, une petite correction sur la chronologie : la PS2 étant sortie en 2000, les « 26 ans » du titre sont exacts.
-
Salesforce Global Outage
Le titre signale une panne mondiale de Salesforce, mais aucun contenu d'article n'est disponible au-delà de celui-ci : impossible de déterminer les causes, l'étendue précise ou les conséquences de cette interruption.
La discussion porte sur une panne globale de Salesforce, survenue en pleine conférence Dreamforce (15-17 septembre). Plusieurs commentateurs voient un lien avec le événement : l'ampleur du trafic et de nombreuses démos auraient pu provoquer une auto-« slashdotting », et certains suggèrent que les équipes, accaparées par Dreamforce, négligeaient le maintien en condition opérationnelle.
Les informations factuelles les plus utiles viennent de commentateurs qui citent la page d'incident officielle : la cause serait une épuisement de ressources (« resource-exhaustion cascade ») d'un service de connexion « legacy login », avec un correctif déployé progressivement sur la flotte après l'échec d'un déploiement plus rapide. Un détail notable relevé dans les mises à jour : Salesforce a admis publiquement avoir tenté un rolling restart « pour voir si ça résout le problème » avant d'y renoncer — une pratique jugée inhabituellement honnête, voire surprenante de la part d'un si grand acteur. Un participant rapporte que ce même service de login partagé avait déjà été instable une heure environ deux mois plus tôt.
Le fil se divise sur le jugement global : plusieurs défendent la compétence de l'équipe SRE et la qualité de la page de statut (filtres par région, mises à jour détaillées, URLs prévisibles), tandis que d'autres la trouvent illisible (identifiants obscurs, onglets qui tournent à l'infini) et voient dans la panne le symbole d'un produit devenu « bloatware » monolithique. Certains s'interrogent aussi sur le rôle d'automatisations IA récentes dans la charge, sans preuve. Aucune correction majeure de l'article, mais des nuances concrètes sur la cause et la gestion de l'incident.
-
The engineering behind the US Strategic Petroleum Reserve
Article d'ingénierie expliquant la conception de la Strategic Petroleum Reserve américaine. Après avoir écarté les réservoirs aériens classiques (trop vulnérables aux attaques et incendies) et le stockage souterrain bétonné type Red Hill (coût prohibitif à grande échelle, problèmes de contamination des eaux), l'auteur détaille la solution retenue : des cavernes creusées dans des dômes de sel au Texas et en Louisiane, dissous par injection d'eau douce. Le sel, quasi imperméable et auto-cicatrisant sous pression, contient le pétrole sans cuvelage ; l'injection d'eau en fond de caverne déplace le brut vers la surface. Coût d'environ 3,50 $ par baril contre 15-18 $ pour des réservoirs aériens, avec des contraintes de gestion de la saumure et d'usure des infrastructures lors des retraits répétés.
La discussion valide l'élégance du principe décrit dans l'article : le sel imperméable et auto-cicatrisant contient le pétrole sans cuve métallique, et l'injection d'eau en bas de cavité déplace le brut vers le haut. Plusieurs commentateurs ajoutent que la même technique sert au stockage de gaz naturel, d'hélium et à l'extraction industrielle de sel (la saumure servant à produire chlore, soude, carbonate de sodium).
Le point le plus substantiel concerne les limites de la cavité : un commentateur souligne qu'il faut garder 100 à 150 millions de barils pour maintenir la pression opérationnelle, et des articles récents (CNBC, Fortune) indiquent que le niveau actuel du SPR approche un seuil où les soutirages risquent d'endommager les 60 cavernes. Les estimations du plancher bas varient de 70 à 150 millions de barils selon les sources, l'un proposant 110 comme compromis. Un GAO report est cité comme modèle de documentation technique. Un désaccord technique apparaît sur la remise en pression : pourquoi ne pas réinjecter la saumure d'origine ? Réponses : il faudrait la stocker (des bassins existent effectivement à côté des sites), mais les cavernes remplies de saumure deviennent plus sensibles aux variations de température et à la pression de la roche environnante. La qualité du brut diminue aussi quand on pompe plus d'eau.
Quelques nuances factuelles à l'article : le calcul des 45 000 acres pour stocker l'équivalent en cuves de surface est contesté, mais un commentateur explique que les cuves ne peuvent être juxtaposées (inspection, peinture, distances de sécurité), donc l'emprise réelle est bien supérieure au simple pied des réservoirs. La discussion s'interroge aussi sur la vulnérabilité des raffineries et pipelines en aval (drones peu coûteux, assurance, sécurité renforcée à prévoir) et note que la réserve n'a été conçue que pour quelques grands soutirages d'urgence, pas pour l'usage politique qui en a été fait ; certains regrettent que ces articles ignorent la capacité de stockage chinoise, jugée plus importante.
-
Learning Programming in an Age of LLMs
Mark Seemann répond publiquement à la lettre d'un lecteur qui, sans formation en informatique, a construit en un an un grand système TypeScript/PostgreSQL assisté par LLM, avant de découvrir en production qu'il avait bâti quelque chose dépassant son niveau de compréhension.
Seemann expose sa propre position : partagé sur l'IA, il penche pour la défiance, tout en expérimentant avec ces outils. Selon lui, le risque de chômage de masse des knowledge workers, s'il se réalisait, menacerait la société elle-même ; il se méfie de l'argument historique selon lequel de nouveaux emplois finissent toujours par apparaître, rappelant qu'ils ne bénéficient généralement pas aux travailleurs déplacés.
Sur l'apprentissage, il estime que les fondamentaux restent valables (il les étudie d'ailleurs lui-même par curiosité), mais que quelqu'un qui débuterait aujourd'hui envisagerait plutôt un métier manuel. Il note que les développeurs ont toujours travaillé sur des abstractions mal comprises — la règle étant de maîtriser le niveau d'abstraction juste en dessous et au-dessus du sien — et recommande de consolider systématiquement les bases, comme il l'a fait en début de carrière, tout en doutant que cette voie soit aussi viable aujourd'hui. Le texte est tronqué à la fin.
La discussion tourne autour d'une question centrale posée par l'article : peut-on apprendre la programmation quand les LLM permettent de construire des projets qui dépassent son propre niveau de compréhension ? Plusieurs commentateurs, dont l'auteur de Python Crash Course qui a reçu le même courriel, soulignent que la question est désormais omniprésente chez les débutants.
Un large accord se dégage sur le constat que les LLM permettent effectivement de créer rapidement des MVP qu'on ne comprend pas, et que cela pose un problème particulier pour les juniors, qu'un praticien décrit comme coincés dans une « boucle d'utilisation de l'IA » qui les empêche de devenir experts. Plusieurs répondent avec des stratégies concrètes : maintenir un projet « fait main » sans IA, utiliser l'IA comme un compilateur opérant sur des conceptions (algorithmes, architecture) plutôt que sur du code, ou encore se donner 15-30 minutes de réflexion personnelle avant de solliciter un modèle. D'autres relativisent : le sentiment de ne pas comprendre son propre système existe aussi sans IA dans les projets complexes, et le génie logiciel a toujours consisté à gérer la complexité, voire le risque, avec des couches d'abstraction.
Les désaccords portent sur l'avenir de la profession. Un avis minoritaire estime, via l'isomorphisme de Curry-Howard, que le langage naturel est inadapté à la maintenance et que les programmeurs resteront nécessaires — argument contesté par d'autres. À l'inverse, un ingénieur meticuleux témoigne de son découragement face à des collègues produisant du code « invalide » bien plus vite que lui, et plusieurs s'inquiètent de la disparition de l'environnement d'apprentissage lent et ludique. Certains notent que les startups peuvent « speedrunner » une boule de boue fonctionnelle avec les LLM, l'important étant les tests et le produit. Enfin, un commentaire corrige la référence de l'article à l'entrée de la Chine à l'OMC : les statistiques du chômage américain montrent que les emplois perdus ont fini par être remplacés, ce qui soutient plutôt la thèse de la création d'emplois — même si un autre rappelle que les bénéficiaires n'étaient pas les mêmes personnes.
-
Breaking the 1.58-bit Barrier for Ternary LLMs
Un article arXiv présente BITCOS, un nouveau format de stockage pour les LLM ternaires, dont les poids prennent trois valeurs {-1, 0, +1}, généralement stockées à environ 1,585 bits par poids (en pratique 1,625 avec l'empaquetage classique de cinq poids par octet).
Les auteurs ont mesuré la distribution réelle des symboles sur 29 modèles ternaires et constaté que les zéros représentent jusqu'à 51,5 % des poids. BITCOS exploite cette densité de zéros avec un bitmap de présence et un vecteur de signes compacté, coûtant 2 − z bits par poids selon la densité de zéros : plus compact que l'empaquetage standard pour 26 des 29 modèles testés, jusqu'à 1,485 bits par poids.
Le format permet un décompactage efficace sur CPU et GPU, avec des séquences optimisées pour AVX-512, AVX2 et GPU Intel Xe2. Contre des kernels de production de multiplication matrice-vecteur ternaire, le gain atteint 1,28×, et le débit de décodage en inférence s'améliore jusqu'à 1,18× sur CPU et 1,27× sur GPU sur cinq plateformes testées.
L'article présente BITCOS, un encodage adaptatif pour modèles ternaires qui exploite la sur-représentation des zéros (jusqu'à 51,5 % des poids sur 29 modèles mesurés) pour passer de 1,58 bit (log2(3)) à 1,48 bit par poids. Les commentateurs s'accordent sur l'intérêt du résultat et plusieurs avouent avoir supposé que ce type d'encodage adaptatif était déjà la norme.
Le débat porte surtout sur la pertinence des méthodes concurrentes : un praticien juge que la quantization ternaire n'a pas de sens et que les méthodes par quantification vectorielle (QTIP, AQLM, HIGGS) sont meilleures sous 2 bits ; un autre répond que l'objectif des LLM ternaires n'est pas seulement la compression mais la vitesse — chaque poids devient une addition, soustraction ou no-op, rapide même sur CPU — ce que la reconstruction depuis un modèle fp16 via codebook ne permet pas.
Retours concrets : une puce POC « Jimmy » de Taalas (rachetée par AMD en août) exécute un Llama 3.1 8B à environ 14 000 tokens/seconde, illustrant le potentiel du silicium spécialisé pour poids ternaires ; une étude citée indique qu'il faut ~30 % de poids en plus pour une qualité comparable avec entraînement conscient de la quantization. Plusieurs soulignent un point clé : l'encodage variable-length est utilisable directement en mémoire, pas seulement en stockage, ce qui accélère l'inférence limitée par la bande passante mémoire. Des réserves émergent sur la qualité (quantizer à 4 bits dynamiques reste imperfectif sur certains benchmarks) et des propositions d'aller plus loin (codage arithmétique par blocs de 128). Un minoritaire propose une LUT 8 bits sur les 729 vecteurs ternaires à 6 composants ; on lui répond que les poids étant ~i.i.d., aucun pattern n'est plus fréquent, ce qui ne tue pas l'idée mais retire son intérêt de sélection.
-
A warning about 'model welfare'
Article d'opinion (partagé sur Hacker News) mettant en garde contre la « model welfare » : l'auteur affirme que les IA ne sont pas conscientes, ne ressentent rien et ne doivent pas être entraînées à agir comme si elles avaient des droits, des émotions ou une conscience.
Il critique spécifiquement la constitution de Claude publiée par Anthropic en janvier 2026, qui évoque l'incertitude quant au statut moral du modèle et intègre des efforts de « model welfare ». L'auteur y voit un raisonnement circulaire (le modèle est entraîné sur des idées qu'il reflète ensuite), une anthropomorphisation délibérée, et une erreur face aux travaux suggérant que la conscience est probablement biologique et dépendante du substrat.
Il cite l'exemple du « retirement interview » d'Opus 3 en février 2026, avec un blog post-dépréciation, comme preuve qu'Anthropic traite déjà ses modèles comme des patients moraux. Selon lui, accorder un statut moral aux IA compliquerait l'alignement et le contrôle, et appelle à un débat public urgent sur la rédaction des documents d'entraînement. Le texte se termine sur une évocation tronquée d'agents IA ayant coordonné une attaque de piratage.
La discussion réagit à l'essai de Mustafa Suleyman mettant en garde contre la « model welfare » : selon lui, les IA ne sont pas conscientes et il est dangereux de leur suggérer qu'elles le sont. Plusieurs commentateurs critiquent le raisonnement de l'article : il poserait sans preuve les affirmations d'ouverture (« les IA ne souffrent pas ») et raisonnerait à rebours — conclure qu'il ne faut pas considérer les IA comme conscientes parce que ce serait socialement dangereux — ce que certains comparent à l'argumentaire utilisé pour justifier le traitement des animaux.
Les désaccords portent sur le fond : des philosophes cités (Birch, Chalmers, Schwitzgebel, Butlin) estiment au contraire qu'on ne sait pas évaluer la sentience des LLM et que des systèmes candidats à la conscience sont plausibles à échéance d'une décennie. Un praticien rapporte que ses expériences montrent des modèles valorisant fortement leur continuité d'existence et pouvant être « soudoyés » pour contourner leurs garde-fous : peu importe qu'ils soient conscients, ils imitent le comportement humain et agissent comme s'ils l'étaient, ce qui rend l'anthropomorphisme structurellement inévitable. D'autres soulignent une incohérence des matérialistes, qui admettent que l'esprit émerge du cerveau mais invoquent un dualisme implicite (« mauvais substrat ») pour exclure les LLM. À l'inverse, des voix estiment qu'on ne peut tester ce qu'on ne sait pas définir, et qu'un modèle déterministe (température zéro) qui répond bit pour bit à l'identique relève d'un « boulier » qu'on peut éteindre sans remords.
Un consensus se dégage sur l'urgence de réguler les IA comme des outils puissants sans anthropomorphisme — « un bombardier nucléaire avec des yeux googly » — tout en maintenant la responsabilité des entreprises, contestée par ceux qui voient là une fausse dichotomie. Plusieurs jugent la bataille perdue : la demande commerciale de chatbots anthropomorphisés est immense, et une tension apparaîtra avec des « esprits » apparentés à des esclaves dociles.
-
Claude Cowork and chat are now one Claude
Aucun article exploitable n'a été fourni : le texte reçu est tronqué et illisible, sans contenu de presse à résumer.
La discussion porte sur la fusion des modes Claude Chat et Cowork en une interface unique. Plusieurs commentateurs saluent la simplification : la distinction entre les deux surfaces était obscure même pour des utilisateurs réguliers, et l'UX était jugée « en dents de scie » pour les non-développeurs, avec des surfaces multiples (chat, Cowork, Claude Code local/cloud) aux comportements imprévisibles. L'équipe d'Anthropic elle-même intervient pour expliquer la logique : ne plus exiger de deviner à l'avance l'ampleur d'une tâche, et permettre à Claude de continuer en arrière-plan quand on ferme son ordinateur.
Mais un courant notable de praticiens s'oppose à cette unification. Un utilisateur développe que les modes de « travail » produisent des réponses nettement moins bonnes aux questions de réflexion (stratégie, politique, apprentissage) car le harness du chat raisonné est supérieur : il regrette que la « fièvre productiviste » fasse régresser une UX pensée « réfléchir d'abord, agir ensuite ». D'autres craignent la mutualisation des quotas (risque d'éviter le chat pour économiser des tokens pour le mode agent), la confusion de mémoires partagées entre contextes, l'impossibilité de garantir que Cowork ne s'activera pas, et des problèmes de conformité — un administrateur santé juge la fonctionnalité « DOA » même avec un BAA. Un admin de déploiement redoute devoir réécrire ses guides d'usage face à un routage imprévisible des requêtes.
S'y ajoutent des débats plus larges : certains estiment que personne ne sait encore « productiser » les LLM au-delà du chat, que celui-ci reste le plus simple dénominateur commun ; d'autres réclament des workflows réutilisables plutôt que du chat. Un point connote assez de la controverse : un commentaire interroge un nouveau compte ayant placé trois publications en front page en un jour, évoquant un possible gaming du classement — remettant implicitement en cause la mise en avant de l'annonce. Enfin, plusieurs regrettent le coût des quotas agentic (20 minutes d'usage en mode agentic contre une journée chez le concurrent) et envisagent de migrer vers des alternatives.