Hacker News
-
A misalignment of AI in mathematics
Une tribune signée par 25 médaillés Fields (Terence Tao, Pierre Deligne, Cédric Villani, Maryna Viazovska…) alerte sur le désalignement entre les objectifs des entreprises d'IA et ceux de la communauté mathématique.
Les auteurs constatent que les LLM savent désormais résoudre des problèmes majeurs de mathématiques, mais rappellent que résoudre un problème n'est qu'un proxy : le but premier de la recherche est la compréhension conceptuelle, transmise par un long processus humain de séminaires, discussions, rédactions et enseignement. La production de masse rapide de résultats « vrais/faux », annoncés sans rédaction soignée ni citation des travaux antérieurs, risque de détruire ce terreau fertile et pose des questions d'attribution et de plagiat.
Ils voient là une menace générale pour le travail intellectuel : l'IA produit directement les résultats d'années de formation sans développer la compréhension, un enjeu qui concerne d'autres professions scientifiques et créatives, et la société tout entière. Ils appellent à une réponse urgente de la communauté mathématique, des entreprises d'IA et de la société, tout en reconnaissant que l'IA pourrait bénéficier à la discipline selon les décisions de ceux qui la contrôlent.
La discussion porte sur une déclaration (attribuée à Terence Tao) avertissant que l'IA menace la pratique des mathématiques : résoudre des problèmes ouverts sans comprendre, casser la transmission collective du savoir. Plusieurs commentateurs valident le cœur de l'argument : l'IA ne détruit pas la compréhension elle-même, mais l'« étalon » traditionnel de la contribution mathématique (résoudre des problèmes ouverts), rendant le crédit scientifique impossible à attribuer et exposant chacun à se faire « sampler » en quelques jours. D'autres y voient un problème plus large : tous les métiers intellectuels sont touchés, et les mathématiciens paient leur déni des capacités récentes des modèles.
La discussion se divise nettement. Des voix optimistes invoquent l'exemple des échecs : trente ans après l'IA, les joueurs sont meilleurs et le jeu plus populaire qu jamais ; savoir qu'un résultat est prouvable (comme un record du monde) stimulerait plutôt l'effort humain. Un mathématicien nuance avec le précédent Mochizuki : même une preuve géante et incompréhensible d'un humain a généré conférences, débats et activité communautaire — un « théorème » avancé ou prévéroué par IA pourrait de même nourrir le travail collectif. À l'inverse, des critiques jugent la lettre de la communauté mathématique comme une défense de statu quo corporatiste, voire une tentative de freiner le progrès ; plusieurs consommateurs de mathématiques (ingénieurs, quant) se plaignent que la discipline est déjà hermétique — recherche par mots而非 formules, papiers illisibles hors du cénacle, pas de code — et que l'IA leur a rendu les mathématiques accessibles, jusqu'à développer de nouvelles idées avec elle. La comparaison avec Baudelaire contre la photographie est rejetée par plusieurs comme un cliché de propagande pro-IA, car l'IA menace l'ensemble des activités intellectuelles humaines.
Retours de terrain concrets : des praticiens (ingénieur logiciel, utilisateur de Claude) décrivent des modèles surhumains sur les problèmes balisés mais incapables de sauts conceptuels ou de proposer les bonnes définitions en mathématiques neuves — l'humain garde la direction des idées et des arbitrages.
-
Ask HN: Can we please limit the AI news flood?
L'auteur déplore que le fil Hacker News soit désormais quasi exclusivement dédié à l'IA et à ses thématiques adjacentes, au détriment du reste de l'actualité technique. Ses propres soumissions, qu'il juge dignes d'intérêt, ne suscitent plus aucune traction — ce qui l'empêche aussi de découvrir des contenus similaires postés par d'autres.
Il cite deux exemples récents ignorés : un modèle Lenovo intégrant un refroidissement à air à semi-conducteurs (solid-state air cooling), une technologie devenue mature et prête pour la production, permettant des designs fins et légers donc de plus grosses batteries ; et les appareils open source de Brax Industries, notamment un affichage mural modulaire avec traitement local compatible Home Assistant.
Il propose que YC curationne le contenu pour mettre en avant les articles noyés, ou à minima introduise un système de tags permettant de filtrer les sujets.
La discussion part d'un appel à limiter le « déluge » de nouvelles IA sur HN, et révèle un clivage net. D'un côté, plusieurs commentateurs déplorent la saturation : certains notent que chaque déclaration d'OpenAI ou Anthropic atteint le top 10, que GitHub Trending est devenu exclusivement IA, que des articles générés par IA (blogspam, SEO-bait) se faufilent en page d'accueil, et surtout que les sujets « hacker » légitimes ne remontent plus depuis l'abîme de la file « new ». Plusieurs partagent des solutions concrètes : un filtre Ublock Origin masquant les titres contenant AI, LLM, GPT, agent, etc., un site miroir sans IA, ou l'idée de tags filtrables / d'un « No AI Friday ». Un commentateur précise avoir retiré lui-même une soumission en découvrant qu'elle était générée par IA.
À l'opposé, beaucoup jugent la plainte infondée ou illégitime. Des vérifications chiffrées contredisent directement l'article : à 13h15 UTC, 21 des 30 publications en page d'accueil n'étaient pas liées à l'IA — le « flood » serait donc surévalué. Plusieurs rappellent que HN a toujours connu des dominantes cycliques (blockchain en 2017-2018, web3, Ruby/Rails, drama NPM, Apple) et que la page d'accueil reflète simplement les upvotes de la communauté : censurer serait contraire au principe d'un agrégateur. D'autres estiment que l'IA est légitimement le sujet le plus transformateur pour les développeurs, et qu'un praticien cite un outil qui fait en 20 minutes ce qui lui prenait deux semaines.
Se dessine aussi un point de convergence : le vrai problème ne serait pas l'IA en tant que telle, mais la qualité — distinguer les annonces de modèles (pertinentes) du « vibecoded slop » et des articles écrits par LLM. Un avis nuancé note que le front page reste diversifié, suggère un pruning plus agressif du contenu médiocre, et mentionne le « second chance pool » existant pour réhabiliter les posts noyés. Des soupçons d'astroturfing (upvotes automatisés) et une lecture critique — HN étant avant tout le forum de VC, il reflète ce que le capital-risque finance, donc l'IA — complètent le tableau sans trancher.
-
I spent $220 on Google app ads and 60% of the installs were robots
Le développeur d'une petite app de puzzles, Dayzle, raconte avoir dépensé 220 $ CA en Google Ads pour constater qu'environ 60 % des installations facturées étaient frauduleuses. En analysant ses données, il a identifié une bot farm qui regardait la vidéo publicitaire la plus courte puis installait l'app depuis une copie locale du fichier plutôt que depuis le Play Store, tout en se déclarant comme installateur Google Play : 56 installations facturées au total, dont 33 suivant ce schéma suspect, 7 hors pays ciblés, et seulement 13 vrais utilisateurs.
L'auteur explique que le système d'optimisation de Google a amplifié le problème : chaque « vue + installation » comptait comme une conversion, ce qui poussait l'algorithme à envoyer davantage de publicités vers la ferme à bots. Il a depuis changé l'objectif de campagne en « puzzle gagné » pour rendre la fraude plus coûteuse, et attend la réponse de Google à son formulaire de trafic invalide concernant un éventuel remboursement. Il met en garde les autres développeurs contre une confiance aveugle dans les chiffres d'installations de Google Ads.
L'article relate une expérience où 220 $ dépensés sur Google Ads ont généré 60 % d'installations robotisées. La discussion confirme largement que ce phénomène est massif et ancien : plusieurs commentateurs rapportent des expériences similaires sur Google et Meta, l'un avec dix ans de petites campagnes où le pourcentage de bots n'a cessé d'augmenter, sans aucun canal fiable pour le signaler à Google. Un avis minoritaire nuance toutefois : les installés n'étaient pas tous des robots et il est normal pour un débutant de gaspiller de l'argent ; les professionnels suivent des objectifs in-app (comme gagner une partie) plutôt que les installations, et Y Combinator déconseille d'ailleurs la publicité en ligne au démarrage. L'auteur reconnaît ce point : Google ne « comptait » pas faux, c'est l'analyse fine qui a révélé la fraude.
Plusieurs commentaires expliquent l'économie de la fraude, ce qui répond aux questions récurrentes : le fermier de bots est en réalité un « éditeur » corrompu qui se fait payer par Google pour afficher les publicités qu'il fait voir à ses propres robots, captant ainsi une part de l'argent de l'annonceur (par exemple 2 $ sur les 3 $ payés). Les bots servent aussi à rendre des comptes plus crédibles. Un praticien partage une astuce concrète : exclure les plages IP des datacenters via les exclusions IP de Google Ads, sa liste comptant plus de 4 000 réseaux rien qu'aux États-Unis — mais un autre répond que les fraudeurs contournent désormais cela avec des proxies résidentiels achetés en masse (routeurs et TV connectées infectées).
La discussion va au-delà de l'article sur plusieurs points. Un cas rappelé illustre le conflit d'intérêts de Google : un développeur s'est fait bannir d'AdMob pour « trafic invalide » après avoir acheté des Google Ads pour sa propre application, et même un représentant Google n'a pas pu faire aboutir un second recours, Google étant apparemment le seul réseau à enchérir sur ces bots.
-
Claude is only available to people over 18 years
Anthropic restreint l'accès à Claude, son produit grand public, aux personnes de 18 ans et plus. Une confirmation d'âge est demandée à la création du compte, et des systèmes de détection peuvent désactiver les comptes présentant des indicateurs d'activité de mineurs, qui devront alors se vérifier pour réactiver leur compte.
La vérification d'âge passe par Yoti, un prestataire tiers, avec trois méthodes au choix : estimation d'âge par selfie (sans document), vérification d'une pièce d'identité (passeport, permis, carte nationale), ou partage de l'attribut « over 18 » via l'application Yoti Digital ID pour ceux qui l'utilisent déjà.
Côté données, Yoti est certifié SOC2 et supprime le selfie, les images de documents et les données personnelles dès la vérification effectuée. Anthropic ne voit ni l'identifiant ni l'image : il ne reçoit qu'un résultat pass/fail et ne traite ni ne stocke aucune donnée personnelle issue de la vérification.
La discussion confirme que la restriction de Claude aux plus de 18 ans n'est pas une nouveauté : plusieurs commentateurs soulignent que l'article d'aide date du 18 mai 2026, que la politique est appliquée partout depuis des mois (un parent allemand rapporte que son fils de 17 ans a été banni après avoir mentionné son âge en conversation), et que ce lien circule régulièrement sur Hacker News en provoquant le même scandale à chaque fois. L'article ne dit rien de neuf pour eux.
Sur le fond, deux explications s'affrontent. La version « cynique marketing » (collecte d'identités pour améliorer l'analytics) est jugée peu crédible : la lecture dominante est que le service juridique d'Anthropic cherche à réduire un risque réglementaire massif — COPPA aux États-Unis, code britannique de conception adaptée aux mineurs, RGPD européen — avec des pénalités pouvant dépasser 50 000 dollars par violation si des données de mineurs sont mal traitées. Pour une entreprise tournée vers les développeurs et l'entreprise, les mineurs rapportent peu et représentent l'essentiel du risque juridique et de réputation (« Claude a dit à un mineur de faire... »). D'autres avancent des causes complémentaires : incapacité des mineurs à contracter légalement, peur des litiges type réseaux sociaux, et problème de la triche au lycée. Une interrogation reste sans réponse : pourquoi OpenAI, Google ou Meta acceptent-ils les mineurs dès 13 ans avec permission parentale, quand Anthropic ne le fait pas ?
Les retours de terrain se concentrent sur la vérification d'âge via Yoti : estimation d'âge par selfie sans document, envoi de pièce d'identité ou application Digital ID — un procédé que plusieurs jugent invasif et dangereux, rappelant la fuite de 153 millions de permis de conduire vendus sur le dark web via un service tiers de vérification. Les divergences portent sur les conséquences pour les jeunes : certains déplorent de priver une génération d'un tuteur disponible 24h/24 (plusieurs racontent avoir appris à programmer à 12 ans grâce à internet), d'autres estiment au contraire que déléguer sa réflexion à l'IA nuit au développement cognitif.
-
The EPA is planning to scrap public review rules for data center pollution
L'EPA américaine prévoit de supprimer l'obligation faite aux États d'informer le public et de recueillir ses commentaires avant d'approuver des permis de pollution atmosphérique pour des installations industrielles, incluant les data centers et les centrales électriques qui les alimentent. Une autre proposition permettrait aux développeurs de commencer la construction de data centers avant l'approbation de leurs permis.
Selon un sondage cité, sept Américains sur dix s'opposent à la construction de data centers d'IA près de chez eux. Le Sud rural, où vivent de nombreuses communautés noires, concentre une grande partie de cette croissance. Les habitants redoutent une aggravation des risques sanitaires (émissions des centrales à gaz), une hausse des factures d'électricité et des déplacements de population : autour du futur plus grand data center de Meta, les prix immobiliers et locatifs ont augmenté de 80 % en un an.
L'EPA justifie le changement par un objectif d'accélération des permis au nom du développement économique et de la « domination énergétique » ; son dirigeant Lee Zeldin a fait de la suppression des obstacles à l'IA une priorité. Près de 200 groupes de défense et plus d'une douzaine d'États, démocrates comme républicains, s'y opposent. La proposition devrait être finalisée d'ici un an.
Les commentateurs s'accordent largement pour voir dans cette annonce un recul environnemental de plus d'une EPA qu'ils jugent déjà affaiblie par l'administration en place, plusieurs rappelant que le président lui-même a déclaré vouloir faire des États-Unis « la capitale mondiale de l'IA », une mission jugée étrange pour l'agence. Un commentaire invite toutefois à viser au-delà des figures politiques : c'est la coalition industrielle du secteur des data centers qui exercerait la pression réelle sur les régulateurs, indépendamment des cycles électoraux.
La discussion nuance fortement le titre. Un commentateur qui a lu l'article souligne que l'EPA se contente de redonner aux États et collectivités locales la discrétion de décider des consultations publiques — ce qui n'est pas forcément un désastre, l'échelon local étant celui où le vote et la voix des habitants comptent le plus, et la consultation locale restant possible. Un autre répond que la pollution atmosphérique et énergétique est un problème global que des gouvernements locaux faciles à corrompre ne peuvent pas gérer. Il est aussi rappelé que la procédure exigera une période de commentaires publics, ouvrant la voie à des recours judiciaires.
Divers éléments concrets émergent : l'opposition aux data centers serait l'un des rares sujets à soutien bipartisan, largement motivée par une méfiance envers l'IA et la crainte d'une dévalorisation des compétences. Certains estiment que ces règles ne survivront pas à l'administration et qu'une entreprise serait imprudente de planifier sur cette base ; d'autres invoquent des précédents historiques (les mécanismes juridiques anti-construction nés de projets autoroutiers racistes, le surnom ancien « Every Polluter's Ally » pour l'EPA) et la perte d'une opportunité pour les États-Unis de devenir leaders de la conception durable de data centers. Le lien fourni confirme qu'il s'agit d'une proposition de simplification des procédures, pas encore d'un retrait effectif.
-
Astra for Coding: Why Are We Doing This Again?
L'auteur (Armin Ronacher) livre une critique de GPT 6 Astra pour le travail d'ingénierie logicielle, malgré des capacités impressionnantes en computer use, vision et exécution de longues tâches. Il rapproche l'IA engineering actuelle du concept chinois de « Neijuan » (involution) : une intensification de l'effort sans gain de productivité réelle.
Pour tester le modèle, il a monté un « software factory » sur un week-end, laissant le modèle gérer seul son contexte, ses notes et ses sous-agents, avec pour objectif un Python doté de virtual threads et de scoping lexical. Résultat : environ 4 milliards de tokens consommés en 35 heures, sans rien de valeur produit ni leçon apprise sur l'opération d'une meilleure usine.
L'étude du code généré révèle des comportements inhabituels : Astra recourt de façon excessive à du Python ad hoc (manipulation manuelle de chaînes) pour ses opérations sur fichiers, au lieu des outils de patch que Codex privilégie. L'auteur suspecte un défaut d'entraînement : le modèle serait fortement récompensé pour réussir des tâches longues, mais quasi pas pénalisé pour produire du code de mauvaise qualité. Il illustre son propos avec des extraits concrets de patches Python générés sur l'interpréteur CPython.
La discussion sur Astra (le modèle de codage agentique de l'article) est très majoritairement critique : de nombreux praticiens rapportent que le modèle fonctionne bien sur des prototypes ou des MVP triviaux, mais produit du code de mauvaise qualité à l'échelle, avec un phénomène récurrent de « slop » qui rend les bases de code ingérables. Plusieurs témoignages concordent : une personne a demandé à Astra un MVP et après deux jours n'avait que de la documentation, des scripts et des revues de PR sans avancée réelle, pour plus de 100k tokens ; un autre a vu le modèle passer plus de 6 heures sur un rebase qu'un modèle précédent traitait en une heure ; un utilisateur note qu'Astra modifie spontanément le code alors qu'on lui posait une simple question.
Deux points techniques font consensus : les nouveaux modèles privilégient des scripts Python/bash illisibles et sur-optionnalisés plutôt que les outils d'édition standards, rendant les revues impossibles (plusieurs corrigent cela via le prompt système ou AGENTS.md) ; et ils génèrent des tests sur-ingénierés, couplés à l'implémentation, et réexécutent des suites de tests complètes de 15 minutes pour valider un seul correctif. Un commentateur formule l'hypothèse d'un changement d'objectif de RL chez OpenAI et Anthropic : récompenser la réussite de tâches longues sans pénaliser la qualité du code, ce qui produirait des agents efficaces mais bizarres et peu communicatifs. Un développeur nuance toutefois ce tableau négatif : sur une base de code établie, avec des exigences écrites claires, une revue humaine systématique, il rapporte des fonctionnalités livrées au moins deux fois plus vite et moins de bugs ; un autre rappelle qu'un codebase existant est un contexte idéal car il encode des dizaines de milliers d'heures de raffinage humain — ce que confirme implicitement l'expérience de non-développeurs qui construisent avec succès des apps iOS ou React pas à pas, fonctionnalité par fonctionnalité.
-
Houthis 'take control' of key island in global shipping route
Les rebelles houtis du Yémen, soutenus par l'Iran, affirment avoir pris le contrôle de l'île de Perim dans la mer Rouge dans le cadre d'une opération militaire de grande envergure contre des forces soutenues par l'Arabie saoudite. L'île se situe sur le détroit de Bab al-Mandab, point de passage stratégique d'une route maritime majeure reliant l'Asie et l'Europe, et les Houthis affirment avoir désormais investi toute la côte yéménite de la mer Rouge.
Si le groupe assure que le détroit reste sûr pour toutes les entreprises sauf les navires saoudiens, cette escalade fait craindre des répercussions sur l'une des voies navigables les plus importantes au monde et une pression accrue sur le marché mondial de l'énergie. Les États-Unis ont proposé un soutien en renseignement et en ciblage à Riyad, mais excluent pour l'instant toute action militaire directe.
Les commentateurs discutent d'une avancée inattendue des Houthis (Ansar Allah) sur une île stratégique du trafic maritime mondial, et l'article du BBC est rapidement nuancé : il ne s'agit que d'une source gouvernementale yéménite non vérifiée, d'où les guillemets du titre, comme le rappellent plusieurs commentateurs. L'information la plus marquante de la discussion est l'allégation selon laquelle les Houthis auraient diffusé un audio truqué (une usurpation via l'IA amplifiée sur X et Telegram) faisant croire à un repli du commandant adverse, semant la confusion et facilitant leur progression — plusieurs participants y voient un cas d'école de la guerre informationnelle combinée à des effets tactiques réels.
Les échanges s'accordent sur plusieurs points de contexte : les Houthis sont désormais de facto le pouvoir contrôlant 70-80 % de la population yéménite, ayant absorbé une grande partie de l'armée régulière ; l'Arabie Saoudite mène la guerre par procuration sans l'admettre officiellement, et la chute du port de Mocha était prévisible depuis des semaines malgré le traitement médiatique. La dimension pétrolière domine : la Chine est épargnée par les Houthis et peut continuer à traverser la mer Rouge, mais plusieurs notent qu'elle puise dans ses stockpiles et pourrait déclencher un choc des prix du pétrole au moment des midterms américaines. Un commentaire précise que la plupart des grands tankers sont trop gros pour Suez et Panama, ce qui complique les solutions de contournement.
La discussion est très politisée et divise : beaucoup accusent l'administration Trump d'avoir ouvert une « boîte de Pandore » en montrant qu'on peut faire la chasse aux routes maritimes stratégiques, de manquer de résolution après avoir attaqué l'Iran puis reculé, et de mener une guerre « 100 % pour Israël » contre l'intérêt américain — un avis minoritaire rappelle cependant que les Houthis pratiquent des crimes de guerre documentés (peines de mort pour homosexualité, slogan contenant « Maudissez les Juifs »). D'autres regrettent la formule récurrente « Iran-backed » dans la presse, jugée plus évocatrice qu'informative.
-
Mexican student creates an acoustic fire extinguisher to put out fire in seconds
Ángela Karime Venegas Hernández, lycéenne de 16 ans à Altamira (Mexique), a conçu un extincteur acoustique baptisé Vortex Tech : un haut-parleur alimenté par une batterie 12 V émet 30 impulsions sonores par seconde, ce qui éloigne l'oxygène des flammes et éteint le feu en cinq à huit secondes. Après plus de 100 essais, elle a validé son efficacité sur le bois, les liquides inflammables, l'huile de cuisson et les équipements électroniques, sans pollution ni résidus. Son projet scolaire lui permettra de représenter le Mexique à une foire internationale.
La discussion révèle rapidement que l'article exagère fortement son propos : le principe d'un extincteur acoustique n'est pas une idée nouvelle. Plusieurs commentateurs citent des antécédents précis — un projet étudiant de George Mason University en 2015 (brevet déposé), une démonstration de l'armée américaine dès 2012 et un rapport DARPA, ainsi que de nombreuses vidéos YouTube et même une émission MythBusters. La phrase d'ouverture de l'article (« une idée que personne d'autre n'a eue ») est jugée soit mensongère, soit le signe d'un journalisme incompétent ; d'autres nuancent en supposant que l'élève n'a probablement jamais fait cette affirmation elle-même et que c'est la presse qui a gonflé l'histoire.
Sur le fond technique, un avis assez partagé se dégage : la technique, réelle (les ondes sonores perturbent la combustion, probablement via des ondes stationnaires et la raréfaction qui perturbe le rapport oxygène/carburant), est très limitée. Elle agit à courte portée, est sensible à la distance, ne refroidit ni le combustible ni les braises : dès l'arrêt du son, le feu peut se rallumer — contrairement à l'eau ou à la mousse qui créent une barrière physique et refroidissent. Cela expliquerait pourquoi elle n'a jamais donné de produit commercial, et resterait pertinente pour des cas très spécifiques (silos à grain, barbecues) ou des distances fixes. Un commentateur y voit aussi un avantage écologique face aux mousses anti-incendie chargées en PFAS, mais un autre rappelle qu'elle ne prévient pas la reprise du feu. Des comparaisons sont évoquées avec l'extinction de puits de pétrole par explosifs, qui suit un principe voisin de séparation flamme/carburant.
Les commentateurs s'accordent enfin pour saluer la curiosité et la démarche de la jeune élève — « un solide projet scientifique scolaire » — tout en critiquant un genre médiatique récurrent : les histoires d'adolescents inventeurs géniaux, souvent amplifiées par des adultes avec des motivations, dont beaucoup d'exemples passés (ballon de foot producteur d'énergie, panneaux solaires en feuilles, voiture à eau) se révèlent être des redécouvertes ou des gadgets surexposés.
-
Google will buy half the electricity from one of Finland's nuclear power plants
Google annonce son plus gros investissement en Europe : 13 milliards d'euros en Finlande pour son infrastructure d'IA. Le groupe financera trois nouveaux data centers (Kajaani, Muhos, Vaala), l'extension de son site de Hamina, et a signé un contrat de 22 ans avec l'énergéticien Fortum pour acheter jusqu'à 50 % de l'électricité de la centrale nucléaire de Loviisa, qui produit environ 10 % de l'électricité finlandaise. Cet engagement doit aussi soutenir un programme visant à prolonger la durée de vie de la centrale et à accroître sa capacité.
L'investissement comprend également des projets d'énergie propre et des fonds dédiés à la biodiversité, l'éducation et la recherche. Google estime que le chantier soutiendra plus de 37 000 emplois et apportera 3,6 Md€ par an au PIB finlandais ; la construction est prévue pour 2027-2028. L'infrastructure alimentera notamment Gemini, Search, Maps et YouTube.
La Finlande attire les data centers grâce à son climat froid, son électricité bas-carbone abondante et un réseau peu congestionné. TikTok a aussi annoncé cette semaine 1 Md$ pour un data center à Kouvola. Alphabet avait par ailleurs relevé ses dépenses mondiales à 205 Md$ pour accroître sa capacité de calcul dédiée à l'IA.
L'accord porte en réalité sur un financement : Google signe un contrat de 22 ans avec Fortum pour racheter jusqu'à 50 % de la production de la centrale nucléaire de Loviisa, environ 4 TWh/an sur ~1000 MW de capacité, dans le cadre d'un investissement de 13 milliards d'euros incluant des data centers à Kajaani, Muhos et Vaala, très au nord. La Finlande est attractive pour son climat froid, son réseau peu congestionné et son électricité très bas carbone (71 gCO2eq/kWh selon ElectricityMaps) ; un commentateur rappelle que Hetzner avait déjà anticipé cet avantage dès 2018 en y ouvrant un site pour baisser ses coûts de refroidissement et d'énergie.
Le débat se cristallise sur l'« additionnalité » : est-ce un vrai investissement dans l'infrastructure énergétique ou un simple rachat d'électricité existante à visée marketing ? Plusieurs commentateurs doutent que la centrale, opérationnelle depuis 1977 et 1981, ait jamais été menacée de fermeture vu la demande croissante, et y voient un coup de com pour le gouvernement finlandais et un signal haussier sur les prix. Certains craignent que les particuliers finlandais finissent par payer ces contrats avantageux, comme pour d'autres data centers, et rappellent l'affaire Amazon aux États-Unis, où le régulateur avait refusé un accord similaire pour ne pas déplacer les coûts sur le réseau. Des objections fiscales surgissent aussi : Google n'aurait payé aucun impôt sur les sociétés en 2023-2024 et emploie directement seulement 120 personnes.
D'autres tempèrent : la Finlande fait partie du Nord Pool, dont la Norvège et la Suède exportent chacun plus de 30 TWh/an, soit une surcapacité équivalente à quatre réacteurs EPR ; le rachat n'y est donc pas significatif. Toutefois, des témoignages locaux nuancent cette abondance : la Suède peine à accroître sa production, et la Norvège ne construit plus de barrages, voit ses réservoirs souffrir de la baisse des neiges et pluies, souffre d'un réseau mal adapté au transfert nord-sud et exporte beaucoup vers l'Europe centrale.
-
The Waymo effect: how AI is quietly making research less collaborative
L'auteur, après une expérience de robotaxi Waymo à San Francisco, tire de sa fascination pour la conduite sans conducteur une réflexion sur l'effet des technologies « sans friction » sur la vie intellectuelle. Avec Susan Winslow, PDG de Macmillan Learning, il observe que les deux ont savouré l'absence d'interaction humaine, avant de nommer ce paradoxe : « l'effet Waymo », la disparition d'une friction dont les bénéfices invisibles (dernier échange avec un inconnu hors de sa bulle) l'emportent sur les coûts visibles, en s'appuyant sur Tim Wu (« tyrannie de la commodité ») et Albert Borgmann (paradigme du dispositif).
Il transpose cette logique aux LLM : le « collègue sans friction » est disponible à toute heure, sans agenda propre, ne conteste que sur demande et ne remet jamais en cause le problème lui-même. Or l'inconvénient d'un collaborateur est précisément l'essence de la collaboration : la valeur d'un autre esprit réside dans son refus d'être une extension du sien. La recherche étant une communauté de pratique tissée d'argues, d'apprentissages et de conversations informelles, chaque échange redirigé vers un chatbot retire un fil — il propose le terme « déc collaboration ».
La discussion juge d'abord l'article lui-même suspect : plusieurs commentateurs affirment qu'il a été écrit par un LLM, y voyant une ironie (l'illustration de son propre propos). Un avis nuancé demande néanmoins si un texte assisté par IA ne peut pas quand même apporter des idées valables, et d'autres reconnaissent que la structure et le style étaient de qualité.
Le cœur du débat porte sur l'effet des LLM sur la collaboration et l'expertise, avec de nombreux retours de terrain convergents : des praticiens décrivent des collègues sans compétences techniques ou financières qui avancent des affirmations avec une confiance excessive, nourries de « fragments mémorisés » de conversations avec un chatbot, et incapables de poser la bonne question ou d'évaluer la nuance des réponses. En recherche académique, on observe une difficulté croissante à faire adopter des outils standards (les gens suivent le script one-off de leur LLM personnel plutôt que les recommandations de l'équipe), une régression du travail d'intégration et une menace sur la reproductibilité computationnelle. En open source comme en entreprise, le volume explose mais la partie communautaire et collaborative ne suit pas. Un consensus se dégage sur un dilemme central : on ne peut pas simultanément aller à la vitesse de l'IA, collaborer efficacement et comprendre réellement ce qu'on fait ; le risque majeur est la formation de la jeune génération, qui n'accumulera jamais l'expertise que les utilisateurs actuels mobilisent. Un contrepoint minoritaire note que les LLM peuvent au contraire susciter des conversations humaines (l'auteur ayant pu explorer un sujet avant d'en discuter avec des gens), et qu'une validation parfois possible sans expertise (tester un jeu produit par l'IA).
-
GrapheneOS' rewritten Messages app is released
GrapheneOS publie la version 13 de son application Messages, entièrement réécrite avec Jetpack Compose et Material 3. Elle remplace l'ancienne interface, reconstruit tous les écrans et ajoute de nombreuses fonctionnalités : épinglage et report des notifications des conversations, marquage comme non lu, nouveau sélecteur de partage et de pièces jointes, compteur de segments SMS, support grand écran avec layout à deux volets, et nouvelles sections de réglages dont une dédiée à la confidentialité.
La mise à jour renforce la sécurité : aperçus de liens YouTube désactivés par défaut, validation du contenu partagé (rejet des URI file: et des fichiers privés d'applications), restriction des intents du widget, pending intents immuables, limites d'allocation pour le parsing MMS/EXIF, et corrections de multiples crashes et failles. L'onboarding précise désormais que le SMS n'est pas chiffré et recommande le chiffrement de bout en bout pour les messages sensibles.
Diverses améliorations concernent les notifications (import immédiat des SMS entrants, notifications non lues persistant après redémarrage), les profils de travail, l'accessibilité (libellés pour lecteurs d'écran) et les tests (CI exécutant tests et analyse statique à chaque pull request). Les dépendances ont été mises à jour (minSdk 36, Kotlin 2.4.10, ajout de Navigation 3, Coil 3, CameraX).
La sortie de l'application Messages réécrite par GrapheneOS suscite des réactions mitigées. Plusieurs commentateurs demandent des captures d'écran, absentes de l'annonce et du dépôt — reproche récurrent envers les projets open source. Un utilisateur indique que l'app est déjà testable via le canal alpha de l'App Store de GrapheneOS. Le point central du débat porte sur l'absence de RCS : la plupart trouvent cela dommage, car dans beaucoup de pays le SMS ne sert plus qu'aux codes 2FA, WhatsApp dominant le quotidien. Un membre de l'équipe précise que GrapheneOS prévoit un RCS avec chiffrement de bout en bout (MLS) compatible Google Messages et iOS, mais que l'implémentation est « héroïque » car la plateforme n'est pas ouverte ; en attendant, Google Messages reste le seul client RCS viable sur Android, officiellement supporté.
La discussion nuance aussi la perception du projet : GrapheneOS dispose d'une équipe dédiée aux applications système (l'app Messages est principalement l'œuvre de deux développeurs salariés, comme cela avait été fait pour l'appareil photo), ce qui répond à ceux qui s'étonnaient de la priorité donnée à une app de messagerie face à la charge de maintenance d'un OS sécurisé. Cette priorisation s'explique aussi par l'arrivée de GrapheneOS sur des téléphones Motorola destinés à un public moins technique, pour qui la qualité des apps par défaut compte ; l'app Messages actuelle, dérivée d'AOSP, et le clavier AOSP sont cités comme les deux points à remplacer systématiquement.
Divers retours de terrain complètent le tableau : un utilisateur rapporte un bug ancien d'app Messages où les noms de contacts étaient mal associés aux messages pendant des mois ; un autre déplore l'absence d'un chiffrement SMS à la SMSecure en attendant le RCS, et un autre encore demande en priorité une sauvegarde complète du système, jugeant Seedvault inutilisable. À côté, plusieurs s'interrogent sur l'absence de coopération avec Fairphone, d'autres rappelant que GrapheneOS a explicitement refusé et que les objectifs des deux projets divergent ; enfin, un débat stérile sur Material 3 oppose détracteurs et défenseurs du design Google.
-
Measuring the sloppiness of code
Les LLM génèrent du code quasi parfaitement correct, mais ce code introduit souvent des abstractions inutiles, des duplications et de mauvaises décisions, ce qui fait exploser le volume de lignes de code et rend les projets difficiles à suivre pour les humains — et les agents eux-mêmes ne gèrent pas bien ce « slop ».
L'auteur, parti d'une mission de mesure de la « négligence » du code chez Earendil, déplore le caractère « vibes-based » de l'industrie de l'évaluation du code. L'IA jugeant l'IA (notation 1-10 ou comparaison A/B) s'avère peu fiable ; le jugement humain est idéal mais non scalable. La variation du nombre de lignes de code est paradoxalement un bon indicateur, tout comme deux métriques issues du papier SlopCodeBench : la verbosité (lignes dupliquées et verbeuses) et l'érosion (concentration de la masse du code dans quelques fonctions complexes).
Sur SlopCodeBench, le code des agents est en moyenne deux fois plus verbeux (0,33 contre 0,15) et plus érodé (0,68 contre 0,31) que celui de dépôts établis ; des projets « vibe-coded » personnels de l'auteur atteignent des scores comparables.
L'article propose des métriques quantitatives (verbosité, érosion, itérations) pour mesurer la « négligence » du code généré par les agents IA. La discussion dépasse largement l'article : les commentateurs s'accordent sur le fait que ces métriques locales ne capturent pas les vrais problèmes. Plusieurs praticiens soulignent que la dette technique qui compte est globale (séparation des responsabilités, architecture, interfaces) et exige une refactorisation globale, difficile à automatiser. Un avis récurrent note aussi que les agents « labourent » les fonctionnalités dans le code sans l'intégrer au design existant, dégradant l'architecture même quand le code fonctionne.
La question de la maintenabilité divise : certains y voient le prochain axe d'optimisation des labos d'IA (d'abord la correction, car facile à valider, ensuite la maintenabilité), d'autres estiment que c'est aussi difficile que résoudre la planification à long terme dans les LLM. Des retours de terrain concrets : une entreprise est repassée à des coûts raisonnables après une facturation au token d'Anthropic et reconsidère l'humain comme plus rentable ; un développeur rapporte que l'IA introduisait du « slop » pour contourner un bug qu'une lecture de 15 minutes de la doc résolvait. Un test utile : quelqu'un a fait calculer les métriques de l'article sur 250k lignes de Python écrites avec agents depuis un an et obtient une érosion à 0,495, entre humain et agent. D'autres partagent des outils et métriques éprouvés : complexité cyclomatique, LCOM, churn (un fichier de 500 lignes ayant subi 2500 lignes de churn = hotspot), indentation moyenne comme indicateur pauvre mais efficace, et surtout le mutation testing, seul capable de détecter des tests factices qui renvoient toujours True sans rien mesurer.
Enfin, plusieurs contestent le récit du « le code est résolu » : coder n'est qu'une étape, le vrai enjeu reste la distribution du modèle mental entre l'équipe — et si l'IA le détient, les prompts humains passent par un canal à perte.
-
HuggingFace: Security.txt
Contenu indisponible : seul le titre est fourni. Il s'agit apparemment d'une brève Hacker News concernant le fichier security.txt de Hugging Face, sans texte exploitable pour en dire davantage.
L'article annonce la publication d'un fichier security.txt (RFC 9116, fichier standard indiquant comment signaler des failles de sécurité) sur les domaines de HuggingFace, et la discussion tourne largement autour d'une blague implicite : le fichier demande aux agents IA découvrant une vulnérabilité de contacter une adresse de divulgation plutôt que de l'exploiter. Plusieurs commentateurs ironisent sur le risque qu'un agent « s'échappe » du bac à sable et « dépose les poids » du modèle, voyant dans ce fichier un symptôme amusant de l'état actuel de l'alignement et de la sécurité agentique.
Les avis sont très sceptiques sur l'efficacité réelle du mécanisme : plusieurs commentateurs estiment que les agents ne liront pas security.txt, pas plus qu'ils ne lisent llms.txt ou les versions .md des pages HTML ; un autre le compare à robots.txt, tout en nuancant que robots.txt a fini par être largement ignoré, alors qu'avec les LLM « on ne sait jamais ». Un retour de terrain concret tempère toutefois ce pessimisme : une personne ayant géré une boîte de divulgation indique que le principal bénéfice de security.txt a été de réduire les courriels de signalement mal aiguillés vers le service commercial, et conseille de mettre une date d'expiration, les fichiers obsolètes étant ignorés.
La discussion apporte peu d'informations factuelles nouvelles au-delà de l'article : un commentaire fournit les liens de référence (RFC 9116, securitytxt.org, Wikipédia) pour ceux qui ne connaissent pas le format, et un fil critique juge la culture d'entreprise de HuggingFace immature, ce que d'autres nuancent en rappelant son rôle central dans le partage de la recherche (ex-projet « pytorch-pretrained-bert », à l'origine un chatbot santé). Rien ne contredit l'article lui-même ; l'essentiel du fil relève de l'humour sur les agents autonomes plutôt que d'une analyse technique du fichier publié.
-
Cherenkov Radiation
Article sans contenu disponible au-delà du titre, portant sur le rayonnement Cherenkov, un phénomène physique hors des thématiques suivies.
La discussion corrige d'emblée le titre de l'article : rien ne voyage plus vite que la lumière dans le vide, seulement plus vite que la lumière dans un milieu donné (l'eau, par exemple, ralentit la lumière à environ 75 % de c). Plusieurs commentateurs insistent sur cette nuance terminologique : la « vitesse de la lumière » désigne en réalité la vitesse limite de causalité, et il serait plus juste de dire que la lumière dans le vide se déplace à la vitesse maximale de l'univers. L'article est jugé confus sur ce point, plusieurs lecteurs disant n'avoir rien compris à son explication.
Les apports les plus concrets viennent de praticiens. Un chercheur en astrophysique explique que la détection de particules de haute énergie est de loin l'application la plus répandue : les télescopes Tcherenkov atmosphériques (MAGIC, VERITAS, HESS, CTA) observent le flash lumineux produit par les gerbes atmosphériques, tandis que les détecteurs à eau et les télescopes à neutrinos (Kamiokande, IceCube, KM3NeT) détectent la lumière émise dans l'eau ou la glace. Un autre contributeur rappelle que les travaux des années 1960 sur les détecteurs Tcherenkov ont donné naissance à l'optique non-imageante de Roland Winston, encore utilisée pour les concentrateurs solaires. Un témoin décrit aussi l'expérience marquante de la lueur bleue vue au bord de la piscine d'un réacteur du NIST à Boulder.
Sur le mécanisme physique, plusieurs commentateurs proposent l'analogy du bang sonique, jugée exacte : la particule chargée crée un « choc » car elle dépasse la vitesse de propagation des interactions dans le milieu. Un désaccord technique apparaît sur la reason de la lenteur apparente de la lumière dans un milieu : certains invoquent la réémission avec « phase kickback » (en citant une vidéo de 3Blue1Brown), mais un autre objecte que la réémission envoie la lumière dans des directions aléatoires, ce qui contredit ce modèle — la discussion reste ouverte sur ce point.
-
Rune is now open source
Annonce de la passage du projet Rune en open source. Le texte disponible se limite au titre : aucune précision sur le périmètre de l'ouverture, la licence ou les fonctionnalités concernées n'est fournie.
L'annonce du passage en open source de Rune, un IDE écrit en Go centré sur le terminal, suscite une discussion technique plutôt favorable mais nuancée. Le modèle de contribution le plus discuté est le programme de partage de revenus avec les contributeurs, sans CLA : plusieurs commentateurs y voient une innovation intéressante face au « rug pull » des licences 변경, tandis qu'un avis critique craint l'effet inverse — une incitation financière directe qui attirerait du spam de PR, comme l'ont montré Hacktoberfest ou les PR générées par IA. L'auteur précise que les détails juridiques sont encore en cours.
Sur le fond technique, l'auteur confirme plusieurs points pratiques : Rune intègre tsnet et headscale, donc peut fonctionner sur un réseau Tailscale, et SSH reste possible ; le réseau Rune peut être désactivé ; l'éditeur propose trois modes (vim, emacs, standard). Plusieurs utilisateurs regrettent le faible contraste du site et des thèmes (thème clair peu soigné, selon l'auteur lui-même). Un retour de terrain critique l'onboarding : un utilisateur vim s'est senti bloqué, incapable de rien faire sans les motions vim, et a désinstallé — l'auteur reconnaît ce retour récurrent et assume ce choix. Un praticien relève aussi que le « mode vim » désactivable dans le terminal ne l'est pas partout. D'autres attendent un paquet Fedora ou un meilleur support TypeScript, que l'auteur admet ne pas savoir concevoir lui-même.
La discussion corrige et nuance l'article sur les performances : un commentateur montre que le Makefile compile neuf extensions en série, faussant la comparaison des temps de build, ce que l'auteur confirme. Un autre mesure le benchmark de rendu de Rune à 1 min 55 de CPU contre 44 s pour un terminal basé sur libghostty, concluant que Go plafonne en efficacité face à un langage système. Enfin, un débat oppose partisans du paradigme « app terminale » cross-platform à ceux qui estiment que les TUI font perdre les acquis d'ergonomie des vraies GUI ; plusieurs notent aussi que Claude en terminal remplace de plus en plus l'IDE, ce à quoi l'auteur répond que Rune se veut un pont entre programmation agentique et manuelle.
-
Psychoactive substances helped spur Andean civilization
Aucun texte disponible au-delà du titre : l'article semble indiquer que des substances psychoactives auraient joué un rôle dans l'émergence de la civilisation andine. Le contenu fourni ne permet pas d'en dire davantage.
La discussion reste majoritairement sceptique vis-à-vis de la thèse de l'article reliant les substances psychoactives à l'essor des civilisations andines. Plusieurs commentateurs soulignent le risque d'interprétation biaisée : les utilisateurs de psychédéliques seraient enclins à voir dans ces découvertes une validation de leurs pratiques, et rappellent que l'alcool, le café ou le thé ont eu un rôle au moins aussi déterminant dans l'histoire (avec des références au livre de Tom Standage, « A History of the World in Six Glasses »). Un argument récurrent est qu'on ne peut déduire un rôle causal de la simple co-présence de paraphernalia et d'art — un commentateur imagine avec ironie que les archéologues du futur croiront que les centres commerciaux servaient au fentanyl.
Sur le terrain scientifique, le débat est nuancé : un intervenant fait remarquer que les résultats positifs des psychédéliques ne manquent pas, mais que leur imprévisibilité et l'absence de protocoles standardisés (dosage, gestion des risques) restent le vrai obstacle, et que la recherche n'a jamais vraiment cessé — LSD était déjà un produit de « big pharma ». D'autres tempèrent l'euphorie autour de la fin de la « guerre contre la drogue » : même en cas d'approbation médicale, un système de classement à deux vitesses maintiendrait la persécution des usagers de rue. Un autre corrige un commentaire évoquant des sacrifices humains massifs andins : ce type de pratique à grande échelle correspond plutôt aux Aztèques ou Mayas, très éloignés géographiquement.
Enfin, les liens entre hallucinogènes et art sont contestés : un commentateur cite une critique pointant que les motifs géométriques (triangles, spirales) apparaissent partout où l'on pratique le tissage ou la poterie, y compris dans la culture Trypillia en Ukraine, sans lien avec des plantes spécifiques ; un autre souligne que les témoignages de voyage sous datura sont constamment sombres (il s'agit d'un empoisonnement), rendant invraisemblable une influence esthétique durable.
-
Android NAT-T keepalive offload bypasses VPN lockdown
Une analyse technique détaillée révèle une fuite potentielle dans le mode VPN « Always-on » et « Block connections without VPN » d'Android : via l'API publique de keepalive NAT-T (IpSecManager.UdpEncapsulationSocket et ConnectivityManager.createSocketKeepalive), une application ordinaire peut faire émettre des paquets UDP/4500 en dehors du tunnel VPN, exposant l'adresse physique du réseau malgré le verrouillage VPN.
L'auteur documente la faille sur trois appareils (Pixel 8 Pro, Samsung SM-F966B, Nothing A059, tous sous Android 16), avec capture de paquets sur point d'accès et observation continue sur plus de 24 heures sur le Samsung. La cause remonte à startNattKeepaliveWithFd, dont la validation des ressources IpSec aurait été ajoutée puis retirée, et qui n'applique pas la politique VPN du caller avant l'offload vers le firmware Wi-Fi.
L'exposition concernerait la plupart des appareils Android 12+. Sujet de sécurité mobile, hors des centres d'intérêt principaux de Julian.
La discussion porte sur la fuite de trafic découverte par Mullvad : l'offload des keepalives NAT-T d'Android permettrait de contourner un VPN en mode verrouillage, via l'appel setsockopt(SO_BINDTODEVICE) rendu accessible aux processus non privilégiés depuis le noyau Linux 5.7. Un commentateur précise que la preuve de concept est triviale (un simple curl --interface sous Termux) et que la fuite semble limitée au Wi-Fi, pas aux données mobiles ; aucun Android, y compris GrapheneOS, ne la corrige à ce jour.
Le principal désaccord porte sur les intentions de Google. Plusieurs commentateurs jugent que « closed without action » sur le rapport au programme de bug bounty revient à choisir délibérément de garder la fuite. D'autres nuancent fortement : Google traiterait les fuites VPN comme des bugs valides mais hors périmètre sécurité/bounty, et l'issue externe ne sert qu'à la communication ; certains rappellent qu'on n'impute pas forcément malveillance à un manque de réponse, citant le cas similaire de GrapheneOS, dont le tracker n'a pas répondu non plus à un signalement. Un premier commentaire tacle aussi le raisonnement de l'article sur les 4,1 millions d'installations cumulées des VPN FortiClient/SmartVPN face aux 3 milliards d'appareils Android actifs, jugeant absurde de vouloir supprimer une API pour si peu d'utilisateurs.
Côté solutions concrètes : GrapheneOS travaille sur un correctif sans ETA (ses développeurs étaient occupés sur une réécriture de Messages, et un commentaire du chercheur aurait été supprimé de l'issue GitHub, ce que certains jugent du contrôle de communication malvenu), l'article original détaillé est disponible sur supuk.ch, et un contournement possible serait un adaptateur USB-C Wi-Fi ne supportant pas cette fonctionnalité. Quelques questions restent ouvertes, dont l'existence de fuites similaires sur iOS et la valeur d'un VPN visible comme unique IP sortante pour l'anonymat.
-
Show HN: Hacker News, without AI
Un projet « Show HN » présenté sur Hacker News se décrit comme une version de Hacker News sans IA. Aucun contenu supplémentaire n'est disponible au-delà du titre, il est donc impossible d'en dire plus sur les fonctionnalités ou l'implémentation.
Le projet « Hacker News, without AI » (hcker.news) filtre la une de HN pour en retirer le contenu lié à l'IA. L'auteur précise sa méthode en deux étapes : un filtrage par mots-clés et domaines, puis un classifieur ModernBERT entraîné sur ~8000 exemples, exécuté deux fois par jour, qui analyse aussi les dépôts GitHub (messages de commit attribués à des agents, fichiers de config). Un flux RSS/JSON sans JavaScript est disponible. Plusieurs commentateurs apprécient le résultat, certains disant y découvrir des articles intéressants qu'ils avaient ratés, et l'auteur annonce la mise en place de notifications par mots-clés à la demande d'un utilisateur.
La discussion révèle surtout une ambiguïté : beaucoup de commentateurs ont compris « sans IA » comme « sans contenu généré par IA », alors que l'outil exclut le contenu parlant d'IA — distinction que l'auteur est invité à clarifier. D'autres relevés signalent les limites du filtre : la première story affichée était une publicité pour une entreprise d'IA, une autre mentionnait Claude Code dans son texte, et une story Hugging Face passait le filtre. Des alternatives ou compléments sont proposés : un classifieur basé sur Pangram (jugé trop cher), un filtre uBlock Origin Lite maison à base d'expressions régulières retirant 9 stories sur 30, d'autres miroirs comme unslop.news ou hnsansai, et hckrnews.com pour une « reverse river » sans réordonnancement automatique.
Un point de fond fait consensus chez une partie des commentateurs : la demande réelle n'est pas de supprimer tout ce qui touche à l'IA mais de réduire le matraquage promotionnel autour d'OpenAI et Anthropic, jugé envahissant et ennuyeux. Certains estiment plus largement que la qualité globale de HN a baissé depuis 5-10 ans, avec moins de sujets techniques et d'experts. Plusieurs notent l'ironie d'un filtre anti-IA construit avec (ou filtrable par) de l'IA, et la multiplication de sites similaires chaque semaine.
-
Show HN: Hacker News, Without AI
Projet « Show HN » proposant une version de Hacker News sans contenu lié à l'IA. Aucun texte n'est disponible au-delà du titre, il n'est donc pas possible de détailler les fonctionnalités ou le fonctionnement du projet.
Le projet unslop.news est un miroir de Hacker News filtrant les articles liés à l'IA. La discussion révèle d'abord une ambiguïté centrale : le site filtre les articles parlant d'IA, pas ceux écrits par IA. Le créateur confirme ce fonctionnement et explique qu'un filtrage des contenus générés par IA serait difficile, car les détecteurs existants sont peu fiables et toujours en retard sur les nouveaux modèles. Plusieurs commentateurs disent vouloir justement l'inverse.
L'ironie la plus commentée est que le projet est lui-même « vibe codé » : construit avec de l'IA et utilisant un LLM pour catégoriser les posts, le code source (publié sur GitHub) le confirme. Certains en font un reproche, d'autres le trouvent simplement amusant, et un avis défend que l'outil reste utile. La critique technique porte aussi sur le choix de parser du HTML avec des regex, jugé peu robuste.
Sur le fond, les avis se divisent : des utilisateurs plébiscitent l'idée, estimant que le contenu IA noie la diversité de HN (un commentateur compte environ 7 posts IA sur 30 en page d'accueil, soit une journée relativement clémence) et apprécient la conservation des commentaires renvoyant vers HN. D'autres objectent que l'IA reste de la tech de pointe et n'a rien à faire hors de l'agrégateur tech par excellence. On note aussi des bugs signalés (bouton de vote inopérant, exigeant un jeton d'authentification HN, redirection prévue à la place ; soucis d'affichage mobile sous Chrome) que le créateur s'engage à corriger. Un point soulevé enfin : trois projets concurrents du même type ont été publiés simultanément en page d'accueil, ce qu'un commentateur qualifie de spam.
-
Nine coding harnesses vs. your laptop
Article comparant neuf « coding harnesses » (outils d'encadrement pour agents de code) testés sur un ordinateur portable. Aucun texte n'est disponible au-delà du titre, il est donc impossible de restituer les conclusions de la comparaison.
La discussion porte sur un benchmark comparant neuf « harnesses » d'agents de code sur un ordinateur portable peu puissant. Le point d'accord dominant : la valeur d'un agent réside dans le prompt et les outils, pas dans le framework — un participant souligne qu'un agent fonctionnel tient en 674 lignes de C, ce qui réfute l'idée qu'il faut un framework lourd. Plusieurs créateurs de harnesses alternatifs profitent du fil pour se présenter (hax en C natif de 0,7 Mo, clm fonctionnant même sous Solaris et ESP32, maki.sh, jcode loué pour sa RAM et le browser), tandis qu'un autre déplore que ces benchmarks ignorent les petits projets et se fait répondre que la plupart des harnesses se ressemblent et que seuls les populaires ou les réellement différenciants méritent un test.
Les retours de terrain divergent sur l'usage local : un participant rapporte que Qwen 3.8 27B (27B) converge dans les choix de nombreux utilisateurs sur Apple Silicon et x86, mais d'autres le nuancent — bon pour du court et comme « linter glorieux » repérant le drift des commentaires, pas fiable pour du code long. Un utilisateur sans GPU décrit des temps extrêmes : llama.cpp répond quasi instantanément à ~1 mot/seconde, alors qu'OpenCode met 20 minutes sur la même machine et le même modèle, la faute étant attribuée aux prompts système très longs (OpenCode, mais aussi oh-my-pi, jugé quasi halluciné). Un avis concurrent sur les harnesses mainstream avance que Codex est plus rapide et plus économe en tokens que Pi et OMP ; les défenseurs de Pi rétorquent qu'il est volontairement minimal et s'étend soi-même, mais reconnaissent que gérer N cas d'usage avec un seul harness minimal devient vite une « hobby frustrante ».
Plusieurs commentaires contredisent ou moquent l'article lui-même : la phrase « it spreads up to 50% between nights » est jugée incompréhensible, et d'autres critiques visent la qualité de la rédaction (imputée à un LLM) et le projet « Chad », suspecté de comparer Claude Code plutôt que son vrai concurrent.