Hacker News
-
AI;DR (AI; Didn't Read)
L'auteur, pourtant pro-AI, exprime son exaspération face aux contenus générés par IA envoyés sans relecture ni édition. Il adopte le principe « AI;DR » : si l'expéditeur ne prend pas la peine de vérifier et éditer le texte, il ne le lira pas. Il reconnaît des exceptions comme le support client, mais pour les discussions entre collègues, newsletters et contenus sociaux, il préfère s'adresser directement à l'IA. Il plaide pour un retour à une touche humaine dans les communications.
Plusieurs commentateurs partagent le ras-le-bol exprimé dans l'article face à la prolifération de contenus générés par IA, notamment dans le contexte professionnel. Des anecdotes reviennent sur des collègues qui déversent des centaines de lignes de commentaires et de documentation IA dans les PR, ou qui répondent aux revues de code par des réponses IA. Le problème n'est pas tant la provenance que l'absence de réflexion réelle : l'IA produit du texte verbeux, surconfiant et sans nuance, ce qui rend la lecture irritante et fait perdre du temps. Un commentateur résume le sentiment général : si l'auteur n'a pas pris le temps d'écrire, pourquoi le lecteur prendrait-il le temps de lire ? La confiance est érodée, et certains disent qu'ils ne liront désormais plus rien qui semble généré par IA, même si c'est factuellement correct.
La discussion nuance toutefois l'article. Pour plusieurs, le critère reste la qualité : un bon article écrit par IA est préférable à un mauvais article humain. D'autres proposent des solutions concrètes : partager le prompt plutôt que le résultat, car c'est là que se trouve l'information voulue ; ou traiter l'IA comme une tierce personne qu'on intègre à la conversation au lieu de servir d'intermédiaire. Un avis minoritaire défend l'usage de l'IA pour les non-anglophones, qui peuvent ainsi exprimer des idées complexes, mais même dans ce cas, on préfère souvent un anglais imparfait mais authentique. Un commentateur conteste fermement l'idée de l'article selon laquelle le support client serait un cas où le 100% IA est acceptable.
Plusieurs commentaires corrigent ou approfondissent le propos. L'un signale que le problème existait déjà il y a trois ans, et qu'on tourne en rond. Un autre renvoie à une réflexion d'Oxide sur les LLM comme écrivains, qui souligne le danger de la dissonance cognitive quand le texte ne correspond à aucune pensée réelle. Enfin, une expérience de terrain relate l'utilisation d'IA pour répondre à une revue de code elle-même générée par IA, une escalade qui a mis fin à la pratique.
-
Israel creates fake think tank in likely attempt to dupe AI chatbots
Le Hanover Institute for Public Policy, présenté comme un think tank sur Israël/Palestine, est en réalité une création fictive du cabinet Piro, Inc, mandaté par l'agence publicitaire du gouvernement israélien. Ses rapports, sans auteurs, imitent le style des think tanks américains pour influencer les chatbots IA comme Claude, Gemini ou ChatGPT, en fournissant des données et citations que les LLM jugent crédibles. L'entreprise Piro a reçu 900 000 dollars du gouvernement israélien et décrit son service comme « AI Story Optimization », une pratique de « LLM poisoning ».
L'analyse de 12 articles par le détecteur GPTZero a identifié 11 comme rédigés par IA avec « haute confiance ». Plusieurs rapports contredisent parfois les récits officiels israéliens, mais beaucoup concluent en reliant le sujet à l'antisémitisme. Cette opération s'inscrit dans un contrat plus large de 46,5 millions de dollars incluant Brad Parscale, ancien directeur de campagne de Trump, pour créer des sites pro-israéliens destinés à influencer les IA. Des chatbots comme Copilot et Gemini ont déjà été influencés par ces contenus, selon une enquête de Drop Site.
Plusieurs commentateurs estiment que cette tactique n'a rien de nouveau et s'inscrit dans un phénomène plus large de manipulation par l'IA. Ils citent notamment l'opération américaine « Earnest Voice » (2010-2011) et l'usage de bots lors du procès Depp/Heard. Un avis répandu : la plupart des think tanks sont déjà des véhicules de propagande, et cet article publié par le Quincy Institute (lui-même un think tank) est « une poêle qui traite la bouilloire de noire ». Certains s'accordent sur le fait que l'objectif n'est pas vraiment de persuader, mais de fournir une « feuille de vigne » pour l'inaction ou la complicité, tout en sachant que l'opinion publique est déjà largement informée.
La discussion est très polarisée. Beaucoup condamnent les actions d'Israël, citant les déclarations d'Itamar Ben-Gvir sur le meurtre de 30 à 40 Palestiniens par nuit, et jugent toute opération d'influence dérisoire face à ces propos. D'autres relativisent, rappelant que des hommes politiques américains tiennent aussi des propos scandaleux, ou que les deux camps dans le conflit sont fanatiques. Un débat oppose ceux qui pensent que cette propagande échouera (montée du sentiment antisioniste, y compris à droite) à ceux qui estiment qu'elle sert uniquement à créer un faux équilibre. Un commentateur s'interroge sur la focalisation sur Israël alors que d'autres pays (Qatar, Russie) mènent des opérations similaires ; un autre lui répond qu'Israël dispose d'une infrastructure de propagande unique (AIPAC, hasbara), avec des preuves tangibles.
Plusieurs corrections à l'article émergent. Un commentateur conteste l'affirmation selon laquelle le travail du think tank synthétique serait parfois en désaccord avec la ligne officielle : l'article ne fournit qu'un exemple insignifiant et omet que la société Piro, Inc. a reçu 900 000 dollars du gouvernement israélien ; l'exemple cité sert en réalité à blanchir des « incidents antisémites » à l'université Columbia. Un autre précise que le « Hanover Public Policy Institute » n'a rien à voir avec Hanover, n'est pas un institut et est un bras déguisé du gouvernement israélien via une agence publicitaire allemande.
-
Universal Health Coverage Could Save $1T and 114k Lives a Year, Yale Study
Une étude de Yale estime qu'un système de santé universel de type Medicare for All pourrait économiser plus de 1 000 milliards de dollars et sauver 114 000 vies par an aux États-Unis. Les économies proviendraient notamment de la baisse des prix pharmaceutiques, de la réduction des frais administratifs et des visites aux urgences évitables. L'étude projette également que la couverture universelle éviterait environ 62 863 décès par an, dont près de la moitié chez des personnes déjà assurées mais en situation de sous-assurance.
La discussion porte moins sur l'article lui-même que sur sa crédibilité et sa faisabilité politique. Un long commentaire décrit le système suisse, jugé le plus proche du modèle américain mais universel : prime d'environ 500 $/mois, franchise annuelle de 2500 $, ticket modérateur plafonné, assureurs de base sans but lucratif, subventions pour les bas revenus et découplage total de l'emploi. Plusieurs intervenants y voient un bénéfice pour le marché du travail (mobilité, création d'entreprise) et rappellent que dans des pays comme le Royaume-Uni, le système de santé est devenu politiquement intouchable, ce qui contraste avec l'impasse américaine.
Le point le plus vif est une critique de la méthodologie de l'étude. Un commentateur décompose le chiffre de 1000 milliards : 1300 milliards d'économies brutes moins 304 milliards de dépenses supplémentaires pour couvrir plus de gens. Il juge fragiles les postes d'économies, notamment la baisse des paiements aux hôpitaux au niveau Medicare : ceux-ci ont des marges de 2 à 5 % et Medicare paie 50 % de moins que le privé, ce qui impliquerait licenciements ou baisses de salaires. Un autre affirme que la méthodologie est connue pour être problématique, que l'effet disparaît après correction et que les auteurs ont déjà publié des études similaires contestées : « ce n'est pas une source crédible ». Cela contredit directement l'article. D'autres estiment que le vrai problème n'est pas qui paie, mais le coût élevé des soins, et qu'une couverture universelle pourrait aggraver les choses en s'attaquant au symptôme plutôt qu'à la cause.
Enfin, beaucoup doutent de la faisabilité politique : intérêts bien installés, lobbying, capture réglementaire, et le fait que des millions d'emplois dépendent du système actuel. L'exemple canadien est cité en contrepoint avec des temps d'attente longs (chirurgie de la vésicule biliaire, IRM, médecin traitant), mais d'autres rétorquent que le Canada a de meilleurs résultats de santé et que les États-Unis ont des taux de refus élevés. Globalement, même les partisans de la couverture universelle jugent l'étude trop optimiste et le débat réellement politique.
-
Qwen 3.8 27B is excellent, but it defaults to overthinking things
Qwen 3.8 27B, un modèle vision-langage de 27B paramètres sous licence Apache 2, est excellent mais son paramètre par défaut de raisonnement 'xhigh' entraîne une sur-réflexion spectaculaire. L'auteur l'a testé sur MacBook Pro et DGX Spark via LM Studio. Avec ce réglage, il a fallu 21 minutes et 22 276 tokens de raisonnement pour générer un SVG de pélican, contre 137 secondes sans raisonnement. Le modèle excelle pour les boîtes englobantes et la création d'outils, mais sur-ingénierie par défaut. Recommandation : baisser le niveau de raisonnement.
Plusieurs commentateurs confirment que Qwen 3.8 27B sur-réfléchit, mais en attribuent la cause aux incitations d'entraînement (RL) et au compromis taille de modèle vs temps de calcul. Ils notent que le comportement par défaut est réglable : le template GGUF met le paramètre reasoning_effort sur xhigh, et on peut passer à medium ou none pour limiter la réflexion sur les tâches simples. Un praticien a testé les modes et n'en distingue que trois (none, low, xhigh), low et medium étant équivalents. Plusieurs proposent des contournements : prompts guidés, Jinja templates, ou un fork de llama.cpp qui injecte du texte pour contrôler le raisonnement. L'article est donc nuancé : le sur-raisonnement n'est pas une fatalité, c'est un choix de configuration.
Côté matériel, les retours sont contrastés : un utilisateur avec 32 Go de RAM n'a pas réussi à lancer le modèle, tandis qu'un autre sur un Mac M5 Max 48 Go le fait tourner confortablement, et un troisième a acheté une 7900 XT 20 Go après des essais CPU. Les vitesses relevées varient de 15 à 42 tokens/s selon la configuration et la fenêtre de contexte. Un benchmark indépendant le place proche d'Opus 4.6, un résultat jugé remarquable pour un modèle local, mais un autre utilisateur rapporte une tâche ayant pris 11 heures sur un double GPU, bien plus que GPT 5.5 (20 minutes). Plusieurs signalent que le default xhigh est responsable de cette lenteur et conseillent de réduire l'effort de raisonnement pour les tâches simples.
Des avis divergent sur l'avenir du reasoning : certains y voient une impasse coûteuse, d'autres une étape nécessaire, en rappelant que les modèles propriétaires cachent leurs pensées mais les font aussi. Une comparaison avec le modèle Glimmer 30B montre que celui-ci utilise 17 fois moins de tokens de raisonnement pour une tâche équivalente, ce qui relativise l'efficacité de Qwen. Enfin, plusieurs commentateurs soulignent que le coût électrique local peut dépasser celui d'une API, selon le tarif du kWh. La discussion apporte donc des correctifs importants à l'article : le problème est contournable, dépend du réglage, et n'est pas spécifique à Qwen.
-
Incident with Github.com
GitHub connaît un incident majeur affectant de nombreux services : erreurs d'environ 20 % sur le web et l'API, environ 50 % sur les téléchargements d'archives et de contenus bruts. L'authentification SAML/OIDC, SCIM, Team Sync, Actions, Pull Requests, Issues, Webhooks et Copilot sont également dégradés. Les investigations sont en cours.
Plusieurs commentateurs expriment leur exaspération face aux pannes répétées de GitHub, certains y voyant un point de bascule et comparant la plateforme à Twitter en perte de vitesse. La cause est débattue : beaucoup invoquent l'afflux massif de code généré par IA (jusqu'à 50 fois plus de trafic) qui saturerait les serveurs, tandis que d'autres incriminent une mauvaise gestion chez Microsoft, citant des données d'uptime historique et un statut page peu fiable. Un commentateur relève que la page de statut ne mentionne pas la panne de la veille, et un autre note que le taux d'erreur de 20% annoncé ne correspond pas à son expérience d'indisponibilité totale.
La discussion s'oriente fortement vers les alternatives et le self-hosting. Plusieurs praticiens décrivent leur migration réussie vers Gitea, Forgejo ou GitLab auto-hébergés, avec des coûts mensuels modestes (environ 30 dollars pour une infra complète avec CI). Un avis minoritaire propose même de remplacer les issues GitHub par un simple dossier dans le dépôt Git. Certains se demandent si le moment est venu de quitter GitHub pour la CI/CD, et des outils comme Woodpecker CI ou des clones open-source d'Actions sont mentionnés. Néanmoins, d'autres rappellent que GitHub reste difficile à remplacer car c'est là que se trouve la communauté, et que les services concurrents n'ont pas la même capacité de stockage.
Sur le plan économique, plusieurs commentateurs s'étonnent que GitHub ne profite pas de la situation pour facturer les utilisateurs non payants ou limiter les abus, mais la réponse dominante est qu'une tarification ferait fuir les utilisateurs vers d'autres plateformes, détruisant la valeur de réseau. Un commentateur compare la situation à la bulle dot-com, tandis qu'un autre ironise sur une newsletter marketing reçue pendant la panne. Globalement, les commentaires n'ajoutent pas de faits nouveaux par rapport à l'article, mais ils apportent des témoignages concrets sur les pannes et les stratégies de contournement.
-
A Preview of DuckDB v2.0
DuckDB v2.0, prévu pour l'automne, marque une version majeure avec un nouveau parser SQL, un nouveau format de stockage et une API C retravaillée. Les principales nouveautés incluent le mode client/serveur via l'extension Quack, le type VARIANT pour les données semi-structurées, les triggers SQL, les E/S asynchrones, et de nouvelles fonctionnalités SQL comme les jointures NEAREST, les DML dans les CTE, les schémas imbriqués, les variables avec syntaxe $x, et les fonctions de mutation JSON.
De nombreux commentateurs se félicitent de cette annonce et partagent leurs usages concrets de DuckDB : analyse locale, pipelines de données, ETL, traitement de flux en temps réel (un utilisateur mentionne des milliers d'événements par seconde), ou encore plateformes multi-tenant s'appuyant sur DuckDB avec des tailles de données allant de 5 à 150 Go. L'arrivée de Quack (mode client/serveur) et du support asynchrone est très attendue, notamment pour interroger des milliers de fichiers Parquet. Le type VARIANT est également perçu comme un atout majeur pour manipuler du JSON hétérogène. Plusieurs commentateurs soulignent la simplicité d'utilisation et la portabilité de l'outil, comparé à SQLite ou à des bases plus lourdes.
Mais des divergences apparaissent sur l'aptitude de DuckDB à remplacer une base transactionnelle classique. Certains doutent de sa capacité à gérer la concurrence et les garanties ACID (write skew, SELECT FOR UPDATE), et recommandent des solutions comme MySQL ou Firebird pour des besoins OLTP. D'autres s'interrogent sur la stabilité, évoquant des OOM kills malgré la configuration de memory_limit, ou encore comparant à ClickHouse. La question du rythme de développement (10 000 commits en moins de six mois) est soulevée : un commentateur suggère que cela peut s'expliquer par des historiques de commits brouillons plutôt que par l'IA, citant une PR remplie de renames. Quelques commentateurs relèvent des manques fonctionnels, comme les vues matérialisées incrémentales (une extension externe existe) ou le support des tables ordonnées.
La discussion apporte des corrections et nuances à l'article. Un commentateur avait initialement critiqué la relation DuckDB/MotherDuck puis a retiré son commentaire, reconnaissant être mal informé. Plusieurs praticiens confirment que DuckDB est utilisé comme moteur de requêtes sur des data lakes (Parquet, Iceberg), et que le mode serveur/client de Quack pourrait réduire les compromis liés à l'utilisation de DuckDB comme base de données partagée. Un commentateur note que la taille du binaire WASM est d'environ 10 Mo, avec des extensions optionnelles maintenant la taille réduite.
-
Memory prices climb 500% in 12 months
Les prix de la mémoire explosent : les kits DDR5 ont augmenté de près de 500 % sur un an, un kit 64 Go (2×32 Go) DDR5-5600 passant d'environ 200 $ à plus de 1 100 $. La DDR4 n'est pas épargnée (+120 à 180 %), et l'Europe subit une hausse moyenne de 345 % sur la RAM, avec des SSD et disques durs en hausse de plus de 125 %. La cause est la demande massive des datacenters IA, qui a conduit les hyperscalers à réserver presque toute la production de DRAM 2027. Les quatre grands fabricants (SK hynix, Samsung, Micron, CXMT) voient leurs revenus multipliés par deux ou trois, et les dirigeants du secteur prévoient une pénurie durable, certains évoquant une crise qui pourrait durer dix ans.
La discussion confirme l'ampleur de la hausse des prix de la mémoire et du stockage, avec des exemples concrets : un module DDR5 RDIMM 16 Go facturé entre 500 et 1000 dollars, une barrette 32 Go RDIMM Dell à plus de 4500 dollars, ou encore un kit DDR4 32 Go à près de 200 dollars. Plusieurs commentateurs indiquent renoncer à mettre à niveau leur matériel, prolonger la durée de vie de leurs machines ou se rabattre sur des plateformes plus anciennes comme la DDR4. Certains se félicitent d'avoir acheté de la mémoire avant la flambée, tandis que d'autres cherchent à vendre des stocks de secours pour financer leurs opérations.
Le débat porte principalement sur les causes : beaucoup attribuent la hausse à la demande pour l'IA et au fait que les fabricants privilégient la mémoire pour serveurs, tandis que d'autres soupçonnent une entente implicite entre les trois grands producteurs, d'autant que la hausse touche aussi des produits plus grand public comme les clés USB ou les disques durs. Certains rappellent le caractère cyclique du secteur, en citant la flambée de 2016-2018 suivie d'un effondrement en 2019 ; d'autres doutent que la chute profite aux consommateurs, car le matériel d'entreprise en fin de vie ne se recycle pas en composants grand public. Un avis minoritaire évoque même une volonté délibérée de faire sortir l'informatique du cadre domestique au profit de terminaux connectés.
Plusieurs informations concrètes complètent l'article : l'ouverture prochaine d'une usine chinoise CXMT qui pourrait desserrer l'étau, la décision d'un développeur de publier une bibliothèque de compression de modèles d'IA pour réduire les besoins en mémoire, et le conseil de rester sur du matériel précédent pour les joueurs. La discussion nuance l'article en montrant que la hausse n'est pas limitée à la RAM, mais touche aussi les SSD, les disques durs et même les graveurs Blu-ray, ce qui laisse penser à une combinaison de demande réelle et de marge accrue des fabricants.
-
Ask HN: Alternatives to GitHub
Demande d'alternatives à GitHub publiée sur Hacker News (Ask HN).
La discussion HN sur les alternatives à GitHub converge fortement vers Forgejo et Gitea, souvent via l'instance hébergée Codeberg. Plusieurs commentateurs les décrivent comme rapides, faciles à auto-héberger et suffisants pour l'essentiel (dépôts, API, CI légère). Un praticien vante Forgejo après avoir migré tout son studio : « un de nos meilleurs choix », notamment grâce à son API et sa légèreté. Codeberg est recommandé pour l'open source, avec un avertissement : son uptime est faible (un « 9 » sur deux semaines) et sa modération ou sa politique anti-IA peuvent ne pas convenir à tous. D'autres alternatives citées incluent SourceHut (pour sa CI et son refus d'imiter GitHub), Fossil (adapté aux petites équipes, mais hors git) et des projets naissants comme tangled.sh ou radicle.
Sur GitLab auto-hébergé, les retours sont contrastés. Un retour de terrain sur six ans d'utilisation en entreprise relate des difficultés concrètes : mises à jour majeures cassant les pipelines, patchs de sécurité presque hebdomadaires, problèmes de configuration PostgreSQL par défaut. Malgré tout, ce commentateur estime que son instance auto-hébergée avait « beaucoup moins de downtime que GitHub » et regrette la migration. Un autre utilisateur de GitLab auto-hébergé s'en dit satisfait, mais un avis minoritaire souligne la complexité des runners personnalisés. Plusieurs commentateurs notent que GitHub ne propose toujours pas de « branch viewer » par dépôt, un manque que les alternatives comblent.
Le débat de fond oppose les défenseurs de la décentralisation à ceux qui rappellent pourquoi GitHub domine. Un commentaire argue que le vrai problème est le point de défaillance unique et propose des forges fédérées ; mais un autre répond que la valeur de GitHub réside dans ses fonctionnalités (PR, issues, actions) et que la décentralisation ne suffit pas : « si c'était si facile de partir, les gens le feraient ». Plusieurs intervenants choisissent un compromis : pousser vers GitHub et leur propre Forgejo en parallèle. Enfin, un projet personnel de forge minimaliste (fierj) montre qu'il est possible de bâtir son propre outil, mais cela reste marginal.
-
GPT-5.6 Sol Pricing Cut by 50%
OpenAI a réduit de 50 % le prix de GPT-5.6 Sol, son modèle phare, conçu pour le raisonnement complexe, le codage et les workflows agentiques. Les tarifs passent à 2,50 $ en entrée et 15 $ en sortie par million de jetons, avec un contexte de 1M, une connaissance arrêtée en février 2026, un débit de 54 jetons/s et une latence de 2,81 s. L'article mentionne également la gestion des erreurs via le routage vers d'autres fournisseurs et des options de personnalisation via l'API Endpoints.
Plusieurs commentateurs corrigent d'emblée l'article : la baisse de 50 % ne concerne pas l'API officielle d'OpenAI, mais une promotion limitée sur OpenRouter, avec des conditions (route non-BYOK, sans Zero Data Retention). Certains s'interrogent sur la véracité du titre et évoquent une possible manœuvre marketing. La cause de cette baisse est largement attribuée à la concurrence des modèles chinois ouverts : Kimi K3 est cité comme équivalent ou supérieur à Opus/Sol pour une fraction du prix, et DeepSeek v4 Flash est donné comme meilleur que Gemini pour le texte, forçant Google à baisser ses prix.
Sur le fond, les avis divergent. Plusieurs commentateurs se réjouissent de cette guerre des prix, y voyant un bénéfice pour les utilisateurs. D'autres décrivent une « course vers le bas » et prédisent la faillite d'OpenAI ou d'Anthropic si elles ne trouvent pas un avantage produit, car les modèles sont à 1-5 % les uns des autres. Un commentateur estime que la vraie muraille est le produit, pas le modèle. Un autre voit dans ces baisses la preuve de marges énormes, mais on lui répond que la comptabilité des coûts est opaque. Un avis minoritaire juge que cette promo ne suffira pas à changer les habitudes, d'autant que des modèles comme Grok 4.6 sont déjà moins chers à intelligence comparable.
Des retours de terrain émaillent la discussion : un utilisateur ayant consommé plus d'un milliard de jetons par jour avec Sol via l'offre à 200 $/mois la juge imbattable ; un autre a vu une session de codage chiffrée à 680 $ détruire sa base de code et annonce son départ vers DeepSeek. Plusieurs signalent que la réduction ne s'applique pas aux abonnements (les quotas hebdomadaires restent les mêmes), et qu'elle est réservée à certains modes (sans ZDR notamment). Enfin, un commentateur s'étonne que la vitesse annoncée de 32 jetons/seconde soit si faible, ce qui n'est pas expliqué. La discussion contredit donc le titre : il s'agit d'une promotion ciblée, pas d'une baisse tarifaire générale.
-
Cursor launches Origin, GitHub alternative
Cursor annonce Origin, une alternative à GitHub pour héberger du code, déployée en bêta anticipée sur tous les forfaits payants. Origin propose des dépôts, des pull requests, la navigation dans le code et une synchronisation bidirectionnelle avec GitHub. Les dépôts GitHub peuvent être importés et synchronisés en temps réel, et les PR sont synchronisées dans les deux sens.
Origin est conçu pour s'intégrer aux agents : poser des questions sur le code, modifier des PR ou pousser des branches depuis Cursor. Des intégrations avec Vercel, Depot et Buildkite sont déjà disponibles. Les dépôts hébergés par Cursor portent l'URL cursor.com/codebase/…, et les organisations Enterprise peuvent refuser la bêta.
La discussion est dominée par la méfiance envers le rachat de Cursor par Elon Musk. Plusieurs commentateurs refusent de confier leur code à une entreprise liée à SpaceX/X, évoquant des risques de fuite de données, d'entraînement de modèles (Grok) et une chaîne d'approvisionnement fragile. D'autres relativisent en rappelant que GitHub appartient à Microsoft et que Copilot utilise déjà le code hébergé. Un avis minoritaire défend le choix : « GitHub est un désastre, mais autant ne pas passer d'un enfer à un autre ». Certains notent que l'alternative proposée n'en est pas une : c'est une bêta pour plans payants, et le site consomme 100% de CPU, tandis que la valorisation de Cursor (60 Mds$) dépasse celle de Mercedes Benz.
Les commentateurs s'accordent sur le besoin d'innovation autour du contrôle de version et des workflows agents, mais jugent Origin décevant : « un clone de GitHub » sans primitives nouvelles. Un développeur de Cursor répond que c'est une bêta et que des différenciateurs arrivent. Plusieurs voix poussent vers des solutions décentralisées : Radicle, Forgejo fédéré, Tangled (basé sur ATProto), ou même le retour à Mercurial. Un praticien explique que Git est déjà un excellent support pour le décentralisé, et qu'il utilise un « Excel pour worktrees » en local. En revanche, un commentateur critique Tangled pour imposer Nix/Rust.
La discussion corrige fortement le titre de l'article : Origin n'est pas une alternative à GitHub, mais un produit conçu pour capter les développeurs et leurs données, avec un risque que x.ai s'entraîne sur le code hébergé. Certains s'inquiètent aussi de l'ambiguïté du nom « origin » pour les LLM. Globalement, le débat se concentre sur la confiance, la propriété et le manque d'ambition technique, plutôt que sur les fonctionnalités annoncées. Les commentaires les plus factuels proviennent de praticiens qui testent des alternatives ou qui pointent les limites du modèle économique de Cursor.
-
Incident with Github.com
Incident sur GitHub.com ayant entraîné une dégradation de nombreux services. Des erreurs élevées (~20 % pour l'expérience web et l'API, ~50 % pour les téléchargements d'archives et de contenus bruts) ont touché Git Operations, Actions, Issues, Pages, Pull Requests, Webhooks, ainsi que l'authentification SAML/OIDC, SCIM et Team Sync. L'authentification de Copilot a été sporadiquement affectée, mais l'utilisation via CLI et l'app GitHub est restée fonctionnelle. Les équipes ont appliqué des correctifs et la plupart des services sont repassés à un fonctionnement normal, avec une surveillance en cours.
La panne de GitHub suscite une vive colère et une remise en question de la dépendance à la plateforme. De nombreux commentateurs expriment leur exaspération face à la lenteur des correctifs (près de 3 heures pour identifier le composant en cause) et aux dégradations successives (API, Actions, Git, Issues). Certains annoncent vouloir migrer leurs projets personnels ou professionnels, évoquant des alternatives comme GitLab, Gitea ou Forgejo. Un commentateur rapporte que même les runners d'actions de GitHub sont victimes de rate limiting (429), ce qui rend la plateforme inutilisable pour la CI. D'autres soulignent que l'interface web est en panne mais que les opérations git en ligne de commande fonctionnent, permettant par exemple de merger via gh.
La cause de la panne divise. Plusieurs attribuent la surcharge à l'afflux massif de code généré par IA (LLM), qui aurait multiplié le trafic par 50. Mais d'autres rejettent cette excuse : ils citent la page historique de disponibilité de GitHub, qu'ils jugent falsifiée (remplie de 100 % de disponibilité depuis 1996), et y voient un problème de mauvaise gestion chez Microsoft. Un commentaire pointe l'absurdité économique : GitHub vend aussi les outils d'IA qui produisent ce code, et facturer les utilisateurs pour limiter le trafic ferait fuir la communauté. Plusieurs notent que GitHub est devenu trop gros pour échouer, et que les alternatives ne peuvent pas rivaliser sur le stockage ou le réseau social des développeurs.
Les solutions concrètes évoquées incluent le self-hosting : un praticien héberge Gitea et Woodpecker CI depuis 6 ans pour environ 30 $/mois, et propose même des services de migration. Un autre a déployé Forgejo en un après-midi. Cependant, beaucoup reconnaissent que remplacer GitHub ne se limite pas à la forge : c'est aussi un réseau social et un écosystème (Actions, Pages, registry). La comparaison avec Twitter (fail whale) revient : la communauté risque de se disperser faute d'une alternative unique. Un commentateur imagine un système décentralisé où les issues seraient des simples fichiers dans le dépôt git.
-
AI-Generated GitHub Copilot “Autofix” Allowed Compromise of Snowflake's Jira
L'outil autonome de sécurité Wiz Red Agent a découvert et exploité une vulnérabilité d'injection de script dans un workflow GitHub Actions du dépôt public snowflakedb/snowflake-connector-net. Introduite par une PR fusionnée le 18 juin 2026, co-écrite par « Copilot Autofix powered by AI », la faille permettait à tout utilisateur d'exécuter des commandes arbitraires via un titre d'issue GitHub. L'agent a pu exfiltrer des identifiants Jira de Snowflake et accéder en lecture aux projets d'ingénierie, de conformité sécurité et de bug bounty.
La vulnérabilité est devenue active cinq jours avant sa découverte. Wiz a utilisé un payload contournant une erreur de syntaxe bash, puis a signalé le problème via HackerOne le 23 juin 2026. Snowflake a patché le jour même, révoqué le token Jira et vérifié par journaux d'audit qu'aucun tiers externe n'avait accédé aux données. L'article souligne que l'IA de révision de GitHub n'a pas détecté la faille et recommande des garde-fous pour empêcher les agents IA de remplacer des parseurs sécurisés par une interpolation directe de chaînes.
Plusieurs commentateurs voient dans cet incident la démonstration des dangers propres aux GitHub Actions : interpolation de template dans un `run:` shell, conditions `if` qui échouent ouvert (sur un événement `issues`, `github.event.pull_request` est null, donc la condition est toujours vraie), et YAML lui-même décrit comme un « cauchemar » truffé de pièges. Un outil comme `zizmor` est recommandé pour détecter ces injections en CI.
La discussion corrige néanmoins le titre de l'article : le commit vulnérable n'est pas issu de l'autofix Copilot mais d'un commit humain, Copilot n'ayant qu'un commit co-auteur sans rapport. Plusieurs commentateurs notent que l'autofix a remplacé une variable d'environnement avec `jq` par une chaîne interpolée dans un shell, introduisant une injection par guillemet. L'un d'eux juge aussi l'article « LLM slop » sur la condition présentée comme « protective » alors qu'en réalité elle n'excluait qu'un seul bot. Un autre mentionne que le bot GitHub Advanced Security a signalé un élément non pertinent, renforçant une fausse sécurité.
Le débat porte sur la responsabilité : certains estiment que Snowflake est fautif d'avoir activé des autofix sans revue humaine, d'autres que la revue humaine reste cruciale mais ne peut pas repérer de tels détails. L'idée qui revient le plus : l'IA réduit le coût de génération du code mais pas celui de sa vérification, déplaçant le goulot d'étranglement vers la validation. Quelques voix minoritaires relativisent en rappelant que le code insécurisé existait avant l'IA et qu'il manque un dénominateur pour accuser les outils IA.
-
Qwen3.8 27B scores 52 on Artificial Analysis
Qwen3.8 27B, modèle open-weights d'Alibaba (27B paramètres, multimodal texte+image, raisonnement), obtient 52 à l'indice d'intelligence d'Artificial Analysis, très au-dessus de la médiane (9). Il est proposé gratuitement (0$ par million de tokens) et dispose d'un contexte de 256k tokens. Sorti le 14 août 2026, il est comparé aux autres modèles ouverts de taille similaire.
La discussion confirme l'exploit de Qwen 3.8 27B (score 52 sur Artificial Analysis) mais apporte un contexte essentiel : ce score est probablement obtenu avec le mode Max, qui produit des traces de raisonnement extrêmement longues. Plusieurs commentateurs chiffrent cette surconsommation : environ 2,3× les tokens de GPT Luna Max et presque 2× Kimi K3. Ils nuancent donc la performance brute en rappelant que le modèle est lent et coûteux à servir, malgré sa taille compacte. Certains s'interrogent d'ailleurs sur le prix élevé des API (0,45 $/M en entrée chez OpenRouter), alors que des modèles plus gros comme DeepSeek V4 Flash sont moins chers. Un commentateur explique cela par une efficacité KV inférieure à celle de DeepSeek, et par la politique tarifaire d'Alibaba.
Les retours d'utilisation réelle sont très positifs : plusieurs testeurs le décrivent comme intelligent, obstiné, voire « obsessionnel » dans la résolution de problèmes, à l'image de GPT-5.6-Sol-max. Un praticien qui a construit un benchmark interne reproduisant son workflow affirme que le modèle n'est pas « benchmaxxé » et que la performance se vérifie en conditions réelles. D'autres partagent des expériences de code quotidien et le trouvent excellent, même si un avis minoritaire relativise : le modèle produirait presque deux fois plus de tokens par tâche que Qwen 3.6, et son score AA-Omniscience Accuracy est légèrement inférieur, suggérant un arbitrage entre connaissance du monde et capacité de raisonnement.
La discussion nuance aussi la portée des benchmarks : certains les jugent de plus en plus « benchmaxxés » et préfèrent des tests personnalisés, tandis que d'autres estiment que le classement Artificial Analysis reste un repère utile. Le point le plus frappant reste que ce modèle de 27B, exécutable sur un PC de gaming, se hisse au niveau de modèles de très grande taille comme Opus 4.6 ou DeepSeek V4 Flash, ce qui suscite à la fois enthousiasme et interrogation sur l'utilité des data centers massifs.
-
GPT 5.6 Sol is the best "vision" model OpenAI ever released
Un benchmark de Roboflow évalue les capacités de vision des modèles GPT-5.6 (Sol, Terra, Luna) annoncés par OpenAI. Sol est le meilleur modèle de vision jamais publié par OpenAI, avec un bond spectaculaire en détection d'objets (46,2 mAP@50 contre 13,8 pour GPT-5.5). Comptage en nette progression (73,0 % pour Sol contre 64,9 %). OCR quasi stable (90,7 % de similarité), extraction de texte légèrement en baisse (82,5 % contre 87,6 %).
Terra et Luna progressent aussi sur la détection et le comptage, mais restent en dessous de Sol. Le modèle est instable sur les images de plus de 2 000×2 000 pixels, avec des boîtes aléatoires ; réduire l'image est contournement conseillé. Coût et latence : Sol environ 2,5 cents/image et 10 s, Terra 1 cent et 6 s, Luna <0,5 cent et 5 s. Gemini 3.5 Flash reste moins cher (0,8 cent) et plus performant en détection/comptage. Malgré ces limites, OpenAI rattrape les meilleurs VLM en vision.
La discussion contredit nettement le titre de l'article : plusieurs commentateurs soulignent que GPT 5.6 Sol, bien que meilleur modèle de vision d'OpenAI, est surpassé sur presque tous les benchmarks par Gemini 3.5 Flash, et pour un tiers du coût. L'auteur de l'article intervient lui-même pour admettre que son billet, écrit quatre semaines plus tôt, est déjà dépassé et que Gemini 3.7 Flash serait désormais un meilleur choix. Un commentaire rappelle que le titre précise bien « OpenAI released », ce qui ne fait pas de Sol le meilleur modèle global. Plusieurs praticiens confirment que Gemini reste leur outil privilégié pour la détection et le comptage à grande échelle, notamment dans un contexte professionnel.
Les retours de terrain sont variés : un commentateur salue la qualité de Sol pour la génération de légendes vidéo, notamment les mouvements sub-secondes, là où d'autres modèles échouent ; un autre rapporte une transcription réussie de partitions musicales ; un autre l'a utilisé au supermarché pour identifier des produits avec succès. Mais des échecs sont aussi mentionnés : hallucination sur une image noire, mauvaise diagnose d'une maladie de plante, et des erreurs dans les benchmarks eux-mêmes (pièce pivotée à 90°, annotation incorrecte) que l'auteur promet de corriger. Plusieurs intervenants notent que pour des tâches simples comme compter des pilules, un modèle traditionnel ou OpenCV reste plus rapide et moins cher, mais que l'intérêt du LLM est sa généralité et sa capacité à générer des données d'entraînement.
Un point de divergence concerne le choix du modèle : certains préfèrent Sol pour la planification et l'usage de l'ordinateur, d'autres lui préfèrent des modèles open-weight comme Qwen3.8 pour la vision. Le coût et la latence sont des freins récurrents. Un avis minoritaire suggère d'utiliser plusieurs modèles selon leurs points forts. Dans l'ensemble, la discussion nuance fortement le caractère « best vision model » du titre, tout en reconnaissant des progrès réels sur certains usages de niche.
-
How to disable or avoid intrusive AI
Guide pratique pour désactiver ou éviter les IA intrusives dans son environnement numérique. Il détaille des procédures pour de nombreux logiciels : Adobe (Acrobat, Reader), Android (Gemini), Amazon (Alexa for Shopping), Apple Intelligence/Siri, navigateurs (Chrome, Edge, Firefox, DuckDuckGo), Google Workspace, Slack, Windows 11/Copilot, Office 365, Yahoo Mail et Zoom. L'article fournit des étapes précises, comme désactiver des paramètres, utiliser des extensions ou des navigateurs alternatifs, et liste des ressources complémentaires. Il est publié à l'adresse NoToAI.org et accepte les contributions.
La discussion confirme le constat de l'article : l'IA intrusive est imposée par les éditeurs, souvent sans état de repli. Plusieurs commentateurs rapportent ainsi que Siri est obligatoire pour utiliser CarPlay, même pour saisir une adresse au clavier, et que bloquer les fonctions IA verrouille des fonctionnalités de base. D'autres y voient une stratégie délibérée : rendre l'IA si envahissante qu'il deviendra impossible de revenir en arrière, tout en pariant sur le fait que peu d'utilisateurs l'utilisent vraiment. Un commentateur émet la théorie, minoritaire, que la vague anti-IA serait alimentée par des comptes achetés pour propager de la propagande, mais elle est isolée.
Concrètement, les commentaires enrichissent la liste de l'article. Sont recommandés : les navigateurs LibreWolf et Waterfox (qui retirent l'IA), ou encore Zen et Helium, avec uBlock Origin pour masquer les boutons IA. Pour Google, l'astuce du paramètre `udm=14` supprime le résumé IA. Sur Mac, l'outil wairy.app permet de révoquer les permissions IA, mais il est payant. L'auteur de l'article, présent dans le fil, ajoute son lien NoToAI.org et intègre plusieurs suggestions. Un commentateur propose de passer à Linux (Debian+KDE) pour échapper à l'IA, solution jugée trop radicale par certains.
La discussion corrige aussi l'article : il omettait des alternatives grand public (LibreOffice, VSCodium, Codeberg, etc.) et l'auteur reconnaît que la liste n'est pas exhaustive. Plusieurs commentateurs expriment leur frustration face à l'absence de moyen simple de désactiver l'IA dans des produits comme Rovo ou le lecteur PDF, et suggèrent d'utiliser des bloqueurs de publicité. Un avertissement ressort : désactiver les fonctions de surveillance pourrait être interprété comme un signal par les systèmes, ce qui n'est pas mentionné dans l'article. Enfin, un avis nuancé : on peut aimer l'IA tout en refusant qu'elle soit imposée dans chaque outil.
-
An update on leaving Gmail for Fastmail
Retour d'expérience après quelques mois passés de Gmail à Fastmail. L'auteur se dit satisfait de son choix, appréciant notamment l'organisation par sous-domaines, la prise en charge de multiples domaines et les adresses masquées. Il note un délai de mise en confiance des domaines récents par les fournisseurs de messagerie, et recommande le passage à une adresse sur son propre domaine pour faciliter d'éventuels futurs changements.
La discussion confirme globalement le récit de l'article : de nombreux commentateurs sont des clients de longue date de Fastmail (10 à 25 ans) et louent sa fiabilité, son support réactif et son côté « ennuyeux » qui fonctionne. Plusieurs soulignent que la migration depuis Gmail est moins pénible que prévu, surtout si l'on utilise un nom de domaine personnalisé, ce qui rend le changement de fournisseur presque transparent. Ils recommandent de mettre à jour ses comptes via un gestionnaire de mots de passe et de laisser une redirection Gmail en filet de sécurité. Un point fort souvent cité est la gestion des alias et des adresses masquées, ainsi que le respect de la vie privée sans compromis sur les standards.
Cependant, les commentaires nuancent fortement l'article sur plusieurs points. Le plus récurrent est la qualité du filtrage anti-spam : plusieurs utilisateurs ayant migré ont constaté une augmentation massive du spam, que Gmail interceptait silencieusement, et ils regrettent l'absence de catégorisation automatique (Promotions, Social, etc.). D'autres mentionnent que la recherche de Fastmail est nettement moins performante que celle de Gmail, même si l'un d'eux a contourné le problème via une intégration MCP. Un autre point critique : les emails envoyés depuis un domaine Fastmail finissent parfois en spam chez Outlook ou Gmail, ce qui a fait manquer des opportunités professionnelles à un commentateur. Enfin, l'adressage par sous-domaine, vanté par certains, est jugé peu portable si l'on veut changer de fournisseur plus tard.
Un avis minoritaire se démarque : un ancien utilisateur de Fastmail explique être retourné chez Gmail, non pour la qualité du client, mais parce que l'organisation implicite (notifications de colis, cartes d'embarquement) lui manquait. Plusieurs commentaires regrettent aussi l'absence de fonctionnalités d'entreprise (SSO, 2FA obligatoire, audit logs) qui compliquent la conformité SOC-2.
-
GitHub down again? no PR access
GitHub a connu une panne, les utilisateurs ne pouvaient pas accéder aux pull requests.
-
The federal keyword lists that canceled billions in research funding
Listes de mots-clés fédérales ayant entraîné l'annulation de milliards de financements de recherche.
Les commentaires convergent sur l'absurdité et l'ampleur des dégâts. Plusieurs exemples concrets : des professeurs de maths ont dû retirer le mot « inégalités » (≤, ≥) de leurs propositions, des biologistes ont remplacé « cancer de l'ovaire chez la souris » par « souris non mâles », un géologue a vu un problème pour « inclusion minérale ». La liste inclurait aussi « sciences humaines », « énergie solaire », « géothermie », « bornes de recharge ». Un commentateur souligne que le déficit américain bat des records, ruinant l'argument d'économies. Un autre évoque l'inverse au Canada, où il fallait auparavant glisser « climat » et « équité » dans chaque demande.
Les interprétations divergent. Certains y voient une incompétence grossière, d'autres une stratégie délibérée : « l'administration trouve cela brillant, nos objectifs sont différents ». Sur le plan juridique, un avis minoritaire défend le droit d'un gouvernement élu à ne pas financer des recherches désapprouvées, la liberté d'expression ne garantissant pas un droit au financement. La réponse dominante rappelle que les listes de mots-clés génèrent des faux positifs massifs et que personne n'a voté pour cela. Un commentateur relativise en affirmant que les subventions ont toujours été politiques, mais un autre lui demande des preuves. La comparaison avec le lyssenkisme est évoquée.
La discussion corrige aussi l'article sur un point : la liste contient des formulations conspirationnistes comme « ingénierie sociale du Green New Deal », ce qui laisse penser à une génération par IA ou par des militants, plutôt qu'à une simple maladresse. L'idée de contourner par des fautes de frappe ou des homoglyphes est écartée : « ce n'est pas le sujet ». Enfin, un commentateur isolé reproche à la gauche d'avoir provoqué ce retour de bâton, mais cette position reste très minoritaire.
-
Sun Clock
Sun Clock est une horloge 24 heures qui affiche la position du soleil, les heures de lever, midi solaire, coucher, heure dorée et crépuscule selon la localisation, ainsi que la position et les phases de la lune. Son sens de rotation s'adapte à l'hémisphère. L'application est gratuite, sans publicité, disponible en PWA, avec mode sombre et options de personnalisation.
La discussion autour de Sun Clock est largement positive et foisonne de retours de praticiens et de développeurs. Plusieurs commentateurs demandent la possibilité de choisir manuellement sa position (coordonnées ou code postal), ce que l'auteur précise être déjà possible via le panneau de réglages. D'autres suggestions reviennent souvent : un curseur temporel pour faire défiler l'année, une carte interactive pour comparer des lieux, ou encore une version widget. L'auteur de la bibliothèque SunCalc, utilisée par l'application, signale d'ailleurs une refonte majeure améliorant la précision des calculs, et l'auteur de Sun Clock promet de mettre à jour son code.
Plusieurs commentaires apportent des nuances techniques ou corrigent l'article. La principale critique porte sur la « golden hour », jugée trop simpliste si elle est codée comme une heure avant le coucher du soleil : dans les hautes latitudes, elle peut durer des heures, comme en Islande. Un commentateur expérimenté dans les calculs solaires détaille les cas limites (jours sans lever ou coucher de soleil) et explique son choix de recalculer à minuit, tout en admettant que le passage au changement d'heure provoque un saut visuel important. Un autre rappelle l'équation du temps, qui fait varier l'heure solaire réelle indépendamment des fuseaux. Enfin, plusieurs liens vers des projets similaires ou complémentaires sont partagés (WeatherSpark, Sun Path, Dayspiral, etc.), illustrant un écosystème riche autour des horloges solaires et des visualisations de la lumière du jour.
-
Linear algebra done right
Annonce de la quatrième édition de « Linear Algebra Done Right », manuel d'algèbre linéaire désormais en accès libre (licence Creative Commons BY-NC) en anglais, chinois, farsi, grec et portugais. L'édition compte plus de 250 nouveaux exercices et 70 exemples. L'ouvrage adopte une approche originale qui relègue les déterminants en fin de volume et privilégie la structure des opérateurs linéaires.
La discussion confirme que *Linear Algebra Done Right* est un ouvrage de référence, mais elle en nuance fortement la prétention du titre. Plusieurs commentateurs le recommandent comme un excellent « second cours », après une première approche plus accessible comme celle de Strang ou de Boyd & Vandenberghe. Les exercices sont jugés difficiles mais très formateurs. Cependant, le titre « Done Right » est perçu par certains comme un accroche-clic : il laisse entendre que les autres approches sont fausses, ce que plusieurs professeurs de mathématiques contesteraient. Un commentaire va jusqu'à qualifier le livre de « surfait et tendancieux », critiquant sa présentation formelle et son manque de motivation.
Le principal point de divergence est le traitement des déterminants, hérité du pamphlet d'Axler « Down With Determinants! ». Certains y voient une « haine subjective » et une polémique mal motivée, tandis que d'autres rappellent que définir le déterminant comme une forme multilinéaire alternée est tout à fait standard, et que l'intuition géométrique est effectivement difficile à relier à la définition combinatoire. Un avis minoritaire défend donc la démarche d'Axler, tandis que d'autres la jugent contre-productive et distrayante.
Des retours concrets émaillent la discussion : la 4e édition a une mise en page jugée atroce, le lien Kindle renvoie une erreur 404, et un étudiant raconte avoir réussi son cours grâce à ce livre. Plusieurs alternatives sont proposées : Hefferon, Shilov (pour une approche théorique dense), le « No Bullshit Guide to Linear Algebra », ou encore « The Dark Art of Linear Algebra » comme préalable. Un commentateur note qu'en IA/ML, cinq concepts suffisent et que de longs prérequis sont décourageants, ce qui relativise l'utilité d'un tel ouvrage pour les débutants. Enfin, un commentaire signale que le livre est « un livre saint » pour beaucoup de développeurs de jeux vidéo, sans plus de détail.