Hacker News
-
Don't be a meat proxy
L'auteur critique la pratique consistant à relayer des réponses générées par IA (comme Claude) sans les comprendre, en les copiant-collant dans des discussions professionnelles ou personnelles. Il souligne que lire du texte d'IA demande un effort supplémentaire, contient parfois des absurdités plausibles et un jargon dense. Il recommande de lire, comprendre, valider puis reformuler les sorties d'IA, notamment en revue de code, afin d'apporter une vraie valeur ajoutée.
La discussion confirme le phénomène décrit dans l'article : des collègues, parfois ingénieurs seniors, transmettent des réponses brutes d'IA sans les lire ni les comprendre, en les préfixant de « Claude a dit ». Cela exaspère ceux qui doivent déchiffrer et valider le contenu à leur place. Plusieurs commentateurs racontent comment ils ont fait cesser cette pratique en répondant publiquement « demande à Claude toi-même » ou en exigeant un résumé rédigé par l'expéditeur ; l'un d'eux s'est fait signaler aux RH pour cela. D'autres expliquent refuser purement et simplement de lire ces messages.
Toutefois, un avis minoritaire nuance le rejet : avec une équipe mature qui assume et vérifie les sorties, partager une synthèse de 10 pages peut être un accélérateur, et une réponse issue d'un agent peut être plus riche que celle d'un humain pressé. Le « Claude a dit » est aussi vu comme une manière de ne pas s'attribuer le mérite ou d'indiquer qu'on n'a pas validé. Mais d'autres rétorquent que c'est une déresponsabilisation, et que « je ne sais pas » est préférable. Un commentaire rappelle que copier-coller sans comprendre s'appelait autrefois du plagiat, et que l'IA devient une autorité fallacieuse. Un autre note que certains utilisent l'IA comme réponse passive-agressive à des collègues qui ne font pas leur travail.
La discussion élargit le sujet à la perte de compétences fondamentales : l'utilisateur devient un « proxy » qui connaît les prompts mais plus les fondations. Plusieurs s'inquiètent d'une régression collective ou d'une dépendance à des agents personnels, comparant la situation à des Tech-Priests de Warhammer 40k. Un commentateur ajoute que les sorties IA sont souvent trop denses et qu'on peut demander un langage plus simple. La discussion contredit l'article principalement sur le cas où le proxy est fiable et où le partage est explicite ; sinon, elle renforce la critique en la généralisant : messages sans mention de l'IA, agents intégrés à Slack, abus dans les médias avec des détecteurs d'IA présentés comme fiables.
-
LLMs reward expertise
L'auteur argue que l'expertise dans un domaine est la compétence clé pour bien utiliser les LLM, plus que de simples techniques de prompt. Il illustre avec une conversation entre Terence Tao et ChatGPT sur la conjecture de Jacobian, montrant que Tao oriente le modèle grâce à sa compréhension mathématique profonde, pose des questions précises et corrige les réponses. L'article conclut que l'expertise humaine reste précieuse, car c'est elle qui permet d'extraire le meilleur du modèle en précisant exactement le type de solution souhaité.
La discussion converge largement avec l'article : l'expertise semble démultiplier l'efficacité des LLM, notamment parce qu'elle permet de savoir quels mots ajouter au prompt (une bibliothèque, un algorithme), de détecter les erreurs et d'itérer rapidement. Plusieurs commentateurs comparent le prompting à un conditionnement bayésien ou à la prise d'histoire clinique : l'expert guide la conversation et évite les biais, tandis que le novice se perd. Un avis majoritaire souligne que les LLM sont un miroir amplificateur : ils reflètent la qualité de l'interaction, et ceux qui les utilisent comme extension de leur esprit en tirent plus que ceux qui les utilisent comme substitut.
Cependant, des contre-exemples significatifs nuancent fortement cette position. Un commentateur raconte que des amis ivres, sans aucune compétence technique, ont produit une application web fonctionnelle avec des prompts simples. Un autre affirme pratiquer le « vibe coding » avec succès, considérant les sorties comme des documents de spécification. Ces expériences suggèrent que pour des projets personnels ou peu critiques, l'expertise n'est pas indispensable. Plusieurs intervenants notent aussi que l'interface de chat est défavorable aux non-experts : elle exige de savoir quoi demander, contrairement à une interface de type « navigation » qui présente des options. L'analogie médicale est retournée : des médecins expérimentés peuvent avoir des biais de diagnostic, tout comme un expert peut être aveuglé par ses hypothèses.
La discussion apporte des précisions pratiques et des nuances. Signaler son niveau d'expertise dans le prompt (« Je suis ingénieur logiciel professionnel ») change visiblement la qualité des réponses, tout comme l'utilisation d'un vocabulaire spécialisé qui comprime l'information et réduit le bruit. Un commentaire oppose le cas des mathématiques, où l'expertise est moins nécessaire car la preuve est auto-vérifiable, aux domaines où l'évaluation des sorties exige un jugement humain. Plusieurs appellent à une étude formelle, en reconnaissant que le lien entre expertise et résultats pourrait être un biais de confirmation.
-
Qwen3.8-Max: A New Bar for Coding and Cowork
Titre seul : Qwen3.8-Max promet un nouveau standard pour le codage et le travail collaboratif.
L'annonce de Qwen3.8-Max suscite surtout de l'enthousiasme pour la version open-weight 27B attendue pour la semaine prochaine. Plusieurs commentateurs considèrent déjà Qwen3.6-27B et 35B comme les meilleurs modèles locaux, certains ayant même annulé leur abonnement Claude. La décision d'ouvrir les poids d'un modèle Max est saluée comme une première. Un commentateur note toutefois que la preview était déjà disponible depuis le 19 juillet, et que l'annonce d'aujourd'hui ne fait que retirer le suffixe « Preview ».
Les débats portent sur la stratégie et la valeur des laboratoires. Certains estiment que les LLM sont devenus une commodité, ce qui remettrait en cause les valorisations d'OpenAI et d'Anthropic. D'autres répondent que le moat se déplace vers le harness et l'amélioration récursive. Un test pratique d'image vers HTML oppose Qwen3.8-Max (via OpenCode) à Opus 5 : si Qwen montre une bonne vision, les timeouts ont nécessité 2 heures d'accompagnement contre 16 minutes pour Claude. Plusieurs commentaires critiquent aussi la peur de la Chine et plaident pour l'open source, tandis que d'autres s'inquiètent d'une interdiction américaine des poids ouverts, tout en doutant de son efficacité.
Informations concrètes : le prix est de 2 $/million de tokens en entrée et 6 $ en sortie, avec un cache implicite à 0,25 $. La version 27B est très attendue pour l'inférence locale. Un commentateur déplore que AWS Bedrock ne supporte toujours pas les derniers modèles open weights, malgré la demande. Enfin, plusieurs voix regrettent que ces modèles ne soient pas spécialisables par langage, mais les réponses expliquent que la connaissance multi-langues aide la généralisation. La discussion nuance l'article en soulignant que la nouveauté est surtout l'ouverture des poids, plus que le modèle lui-même.
-
Critical CVE issued for hallucinated SQLite vulnerability
Une série de CVE critiques attribuées à SQLite s’avère être entièrement inventée par des outils d’IA. Un dépôt GitHub a publié plus de 50 avis de vulnérabilité, rapidement qualifiés de critiques par NVD et CISA, mais les vérifications de JFrog montrent que les preuves de concept ne fonctionnent pas et citent des fonctions absentes des versions concernées. Un CVE (CVE-2026-51302) a d’abord reçu un score de 10.0, puis a été abaissé à 7.6 après investigation.
L’article décrit comment le processus de soumission de CVE peut être abusé : depuis 2024, la NVD peine à analyser les signalements, et aucune étape ne requiert de preuve de concept fonctionnelle. Sur 55 avis provenant du même compte, 54 sont des fabrications complètes. Les signes d’alerte incluent l’absence de confirmation par l’éditeur, l’absence de commit lié, des contradictions de versions et des références à du code inexistant.
Cette situation fait peser une charge sur les équipes sécurité qui doivent trier de fausses vulnérabilités, d’autant plus si des systèmes automatisés s’appuient sur ces CVE.
Les commentateurs s'accordent largement sur le fait que cet incident illustre les limites des LLM dans la détection de vulnérabilités : ils produisent des sorties probabilitstes qui peuvent sembler plausibles sans être vraies. Plusieurs soulignent que le système de CVE ne demande aucune preuve de concept ni reproduction, ce qui a permis à un avis fictif d'être publié comme critique. La confiance aveugle dans les soumissions est pointée du doigt, et certains s'étonnent que ce soit aux mainteneurs de faire le tri. Certains commentateurs y voient même une attaque potentielle pour noyer le système sous de faux rapports, tandis que d'autres notent que des projets deviennent CNA pour reprendre le contrôle.
La discussion corrige ou nuance l'article sur plusieurs points. D'abord, le lien avec les coupes budgétaires à la NIST est contesté : un commentateur rappelle que le rôle de la NIST est purement administratif et qu'elle n'a jamais validé les CVE. Ensuite, le code cité n'existe pas dans les versions concernées et les PoC ne fonctionnent pas, ce qui rend le statut critique incompréhensible. Plusieurs participants signalent que de vrais rapports de vulnérabilité sont ignorés pendant que les mainteneurs traitent ce bruit. Un autre détail factuel : le dépôt mélange des CVE pour différents produits, ce qui est inhabituel.
Les avis divergent sur l'interprétation générale. Certains estiment que c'est un effet secondaire négatif d'une évolution positive (les LLM trouvent aussi de vraies vulnérabilités), alors que d'autres y voient la preuve que les LLM ne devraient pas être utilisés sans supervision humaine. Une suggestion récurrente est d'automatiser la vérification, avec une touche d'ironie : utiliser un LLM pour vérifier le travail d'un autre LLM. Enfin, plusieurs commentaires critiquent la forme de l'article, notamment son image générée par IA, et se demandent si l'article lui-même n'est pas partiellement rédigé par une IA, ce qui affaiblit le message initial.
-
Devtools must be open source
L'article de Bryan Mikaelian soutient que l'IA change fondamentalement le retour sur investissement de la personnalisation des logiciels open source. Là où il était coûteux d'adapter un programme à ses besoins, un agent peut désormais télécharger les sources, appliquer des modifications locales, et les re-synchroniser automatiquement avec les mises à jour upstream via une tâche nocturne. Cela rend la personnalisation accessible sans compétences avancées.
L'auteur illustre avec son outil meat.dev, qui réduit les diffs à l'aide d'un LLM pour ne montrer que les changements importants. Il l'a intégré dans son agent Shelley par une simple requête, avec traitement en arrière-plan des commits. Il oppose cette approche aux API d'extensions classiques (ex. VS Code), jugées trop rigides.
Il en déduit que les plugins et fichiers de configuration pourraient devenir obsolètes pour les logiciels open source, puisque l'agent peut modifier directement le code. Les produits logiciels destinés à être configurés par les utilisateurs devront être repensés, car une petite équipe peut désormais assembler les fonctionnalités voulues à partir de briques communes.
La discussion valide l'idée générale que les devtools doivent être open source, mais rejette en grande partie la vision concrète défendue par l'article. Plusieurs commentateurs estiment que l'utilisation d'IA pour modifier directement le code source, sans options ni fichiers de configuration, est inefficace et coûteuse en énergie : « autant faire exécuter une fois par un LLM la construction d'un parseur de config plutôt que de le faire des millions de fois pour chaque préférence utilisateur ». L'article suggère de maintenir un fork personnel via un cron job qui rebase chaque nuit les changements amont ; plusieurs commentateurs jugent cette approche intenable, citant l'imprévisibilité des agents, la difficulté à vérifier que tout fonctionne, et le problème des conflits UI récurrents. Un mainteneur de devtool explique que ce rêve est « trop idéaliste » : maintenir un fork est un vrai travail, et l'IA ne capture pas le sens du design UX. Un ancien PDG de société de devtools rappelle que l'open source rend difficile de bâtir une entreprise, citant Sendmail comme exemple d'échec commercial malgré un succès technique.
Plusieurs avis convergent sur le fait que les LLM abaissent réellement la barrière pour modifier des outils, et des exemples concrets sont donnés : personnaliser des applications pour un e-reader Kobo, envoyer de petites corrections à des outils existants. Cependant, un autre commentateur rétorque que moins de 1% des utilisateurs lisent ou modifient le code source des projets open source qu'ils utilisent, et que la nouvelle modalité d'ouverture passe plutôt par les poids ouverts et les agents personnalisables. Un intervenant nuance aussi l'affirmation de l'article selon laquelle « il y a cinq ans, les ingénieurs n'avaient aucun programme écrit pour eux-mêmes » : rien n'a changé, les gens ont toujours eu des outils personnels. Plusieurs mettent en garde contre la dépendance aux LLM pour configurer ses outils, d'autant que les modèles à poids ouverts ne sont pas vraiment open source. Enfin, la question de la responsabilité est soulevée : si une personnalisation casse une application critique, qui corrige ?
-
Ten advances in mathematics and theoretical computer science
Titre seul : « Ten advances in mathematics and theoretical computer science ». Aucun contenu supplémentaire n'est fourni.
Plusieurs commentateurs saluent la performance, tout en exprimant des réserves sur la transparence et la formulation. Les problèmes résolus (empilement de sphères, Ramsey multicolore, CVP, complexité des circuits) sont jugés importants, certains travaillés depuis 30 à 40 ans par des chercheurs de premier plan. Un intervenant souligne que les preuves sont formalisées en Lean et que les manuscrits ont été préparés avec l'aide du modèle, mais plusieurs s'interrogent sur la part réelle de l'IA et sur les conditions exactes de l'expérience : combien de problèmes ont été tentés, combien d'essais, quel coût complet ? Le chiffre de 2000 dollars avancé par OpenAI est cité, mais jugé potentiellement trompeur sans description du protocole.
Des corrections et nuances apparaissent. Un commentaire note que la phrase « nous prenons la responsabilité de l'exactitude » ne concerne pas la vérification interne de Lean, mais la traduction des mathématiques humaines en Lean, et la non-utilisation de « sorry ». Un autre affirme que les prompts exacts n'ont plus d'importance depuis environ un an. Plusieurs commentateurs contestent l'idée que les modèles ne peuvent pas « intuiter » des conjectures : ils les utilisent déjà pour générer des hypothèses et des questions de recherche. Un avis minoritaire estime que la comparaison avec les mathématiciens est exagérée.
Le débat porte aussi sur l'impact pour les mathématiciens : certains voient une expansion du champ et un rôle accru pour les humains dans le choix des directions, d'autres craignent une dynamique type échecs, où seuls quelques super-stars survivent. La vérification indépendante reste un point central : un chercheur cité (Henry Yuen) n'a pas personnellement vérifié les résultats, et l'on se demande qui valide ces preuves. Enfin, plusieurs commentaires appellent à publier davantage de détails sur le processus, notamment les prompts et l'architecture complète, afin d'évaluer réellement la portée de ces avancées.
-
More German than many Germans
Récit personnel d'un étudiant turc en informatique parti en stage à Hambourg en 2017. Il décrit son expérience très positive : accueil de son colocataire allemand, ambiance de travail chaleureuse, confiance accordée (pas de contrôle de tickets, congés proposés), opportunités professionnelles et intégration réussie. Il souligne la culture sociale-démocrate du pays, la mixité sociale et la méritocratie, contrastant avec les stéréotypes. L'article est un témoignage sur la vie en Allemagne, sans lien avec les thématiques technologiques suivies.
La discussion confirme largement le récit positif de l'article : plusieurs immigrés installés en Allemagne reconnaissent leur expérience, saluent la qualité de vie, la stabilité et la prévisibilité apportées par les règles, qu'ils perçoivent comme un gage d'équité et d'ordre. Un commentateur évoque son arrivée avec vingt euros en poche et une offre d'emploi, et dit avoir trouvé en Allemagne un confort et une stabilité qu'il n'aurait pas imaginés ailleurs. D'autres renchérissent en comparant avec des pays d'origine plus chaotiques, ou en rappelant que l'herbe est toujours plus verte ailleurs. Un Allemand se dit heureux de voir son pays apprécié, tout en espérant un recul de l'extrême droite.
Toutefois, des voix nuancées ou critiques apparaissent. Un immigré, pourtant privilégié, confie un désenchantement croissant face à la direction politique et économique, ainsi qu'un sentiment de distance culturelle : la littérature ou le cinéma allemands ne suscitent pas l'enthousiasme nécessaire à l'apprentissage de la langue. Plusieurs commentaires pointent les limites du règlement : complexité administrative (création d'une GmbH), rigidité des procédures, et une certaine hypocrisie quand l'État lui-même ne respecte pas les règles. Un participant dénonce le traitement des demandes de naturalisation, faites dans le désordre, obligeant certains à faire pression par la presse et les élus. D'autres s'inquiètent du rétrécissement de la classe moyenne et de la montée d'un « comportement NPC ».
Enfin, la discussion apporte des corrections factuelles et des compléments. L'anecdote du bus à Berlin est expliquée : les conducteurs n'ont pas le droit d'ouvrir les portes hors des arrêts, pour des raisons d'assurance. L'affirmation de l'article selon laquelle l'Allemagne serait le seul pays occidental à avoir affronté son histoire est contestée, notamment au vu de la période récente. Un commentateur relie le racisme allemand à l'absence d'empire colonial, contrairement à la France ou au Royaume-Uni. Plusieurs ressources gratuites pour apprendre l'allemand sont signalées, comme la Deutsche Welle ou Easy German.
-
Prevent cognitive debt by manually retyping LLM-generated code
L'auteur explique sa méthode pour utiliser les assistants de codage IA sans accumuler de dette cognitive : il demande au LLM de générer du code dans le chat, puis recopie manuellement chaque ligne dans son éditeur. Cette approche, volontairement inefficace, lui permet de comprendre le code, de détecter les hallucinations et d'adapter les solutions à son style.
Il compare cette pratique au conseil traditionnel de ne jamais copier-coller du code appris, et estime que l'industrie du logiciel accumule une dette cognitive dangereuse. Il préfère la compréhension à la productivité, même s'il n'atteint qu'un gain de vitesse de 2x au lieu de 10x.
La discussion nuance fortement l'idée de retaper manuellement le code généré par LLM. Plusieurs commentateurs jugent cette pratique inefficace pour apprendre : la recopie ne construit pas l'intuition, contrairement au fait d'écrire soi-même le code puis de demander un avis à l'IA. Un avis récurrent est qu'il vaut mieux « prendre d'abord sa propre crack » et utiliser le LLM comme relecteur ou pour générer des tests (Red tests) qu'on implémente soi-même. Certains mentionnent que taper le code à la main force à considérer le contexte et les interactions, tandis que le copier-coller laisse un « trou de mémoire ». D'autres rappellent que la recopie a pu marcher avec des listings de magazines, mais que ce n'est pas transposable au code de production.
Un point de désaccord majeur : la faisabilité et la pertinence économique. Un commentateur souligne que l'employeur ne se soucie pas de la santé cognitive du développeur, mais de la productivité ; maintenir des compétences à la main devient un luxe. À l'inverse, plusieurs estiment que les LLM augmentent les capacités cognitives (« je suis le général d'une armée ») et qu'il est naturel de déléguer le bas niveau. Certains comparent cette crainte à celle des programmeurs assembleur : le rôle évolue vers la spécification, la revue et l'arbitrage, pas la recopie. Un avis plus pessimiste prédit que l'industrie élimine déjà les postes de « preneurs de tickets Jira » et que ces stratégies ne font que retarder l'inévitable.
Des retours de terrain concrets : un commentateur utilise Claude Code en équipe uniquement pour des scripts bash complexes et privilégie ses compétences senior ; un autre est passé à l'abonnement à 20 $ pour poser des questions sans laisser l'IA écrire le code ; un praticien teste l'approche en révisant le code généré comme il le ferait avec un développeur junior, en acceptant, modifiant ou demandant des révisions. Plusieurs suggèrent de demander au LLM d'expliquer ou de réécrire ce qui n'est pas compris, et d'utiliser des techniques comme le « grillage » de Matt Pocock pour valider la conception technique.
-
Twenty Years of Pandoc
L'auteur de Pandoc raconte les vingt ans du logiciel de conversion de documents. Lancé en 2006 comme un petit programme Haskell de 3000 lignes, Pandoc est devenu un outil majeur supportant plus de cinquante formats, utilisé dans des outils académiques comme Quarto et Jupyter. L'article retrace les débuts, les choix techniques (parsing par combinateurs, AST), les contributions de développeurs, et l'évolution des fonctionnalités au fil des versions.
La discussion confirme largement le plaidoyer de l'article en faveur de Pandoc, perçu comme un outil fiable et indispensable au quotidien. De nombreux commentateurs partagent des cas d'usage concrets : génération de PDF à partir de HTML ou de Markdown, conversion de courriels Outlook, normalisation de documents binaires pour les différer dans git, ou encore utilisation comme générateur de site statique avec une simple boucle shell. Plusieurs témoignages expriment une gratitude appuyée envers John MacFarlane, saluant à la fois la longévité du projet et la propreté de son design. Un doctorant affirme même lui devoir sa carrière scientifique.
Le choix de Haskell est abondamment commenté. Plusieurs intervenants estiment que ce langage a façonné une culture de contribution exigeante mais de haute qualité, avec des échanges bienveillants et des PR acceptées même sans connaître Haskell. Un commentaire élargit la réflexion en comparant les cultures Java et .NET, pour illustrer l'impact d'une stack technique sur la qualité des discussions dans une communauté. Un avis plus nuancé préférerait utiliser des bibliothèques Rust pour un nouveau projet de conversion, tout en reconnaissant que Pandoc reste un choix pertinent. La question de la stabilité du format interne est soulevée en passant, sans réponse tranchée.
La discussion apporte aussi quelques compléments : l'intégration récente du reader/writer Typst est saluée, et djot est mentionné comme un projet connexe prometteur. Face à la montée des LLM, un commentateur souligne qu'un outil déterministe comme Pandoc reste bien plus efficace et écologique pour les traitements par lots. Dans l'ensemble, aucun commentaire ne contredit l'article ; ils en illustrent plutôt les points forts par des retours de terrain.
-
Bonsai: Janestreet's UI Library
Bonsai est une bibliothèque UI de Jane Street pour construire des applications web réactives en OCaml, inspirée d'Elm. Elle repose sur des machines à états purement fonctionnelles et composables, avec un rendu incrémental. L'état n'est pas lié à des composants explicites, ce qui permet une gestion avancée du cycle de vie et des tests automatisés réalistes. Outre Bonsai_web, il existe Bonsai_term pour les interfaces terminal. L'article illustre la syntaxe, les tests et l'écosystème de la bibliothèque.
La discussion nuance fortement l'article en rappelant que l'idée d'utiliser un langage backend pour le frontend n'est pas nouvelle : plusieurs commentateurs citent Scala.js, Fable, ou encore Ocsigen/Eliom (projet antérieur). Le débat technique porte surtout sur le choix de js_of_ocaml plutôt que Melange, ce dernier étant jugé plus apte à s'intégrer à l'écosystème JS. On apprend aussi que Bonsai n'est pas limité au web : une implémentation terminal existe, utilisée par un commentateur pour gérer sa base de contacts. Un point précis corrige l'article : js_of_ocaml supporte les appels terminaux récursifs mais pas les appels terminaux généraux, d'où le besoin d'une trampoline. Plusieurs intervenants relèvent la dépendance quasi totale à Core, ce qui limite la réutilisation hors de l'écosystème Jane Street, et renvoient au podcast Signals & Threads pour comprendre Bonsai comme un framework de « machines à états distribuées incrémentales ».
L'esthétique divise nettement. Une partie des commentateurs juge l'interface « moche », « années 90 », avec des marges mal réglées, et pense que les équipes produit seront limitées. D'autres au contraire louent la densité d'information et l'utilité, comparant le rendu à un terminal Bloomberg. La verbosité de l'API est critiquée, mais certains ironisent que les LLM compensent désormais ce boilerplate. Un commentateur rappelle que l'approche « un seul langage partout » existe aussi côté Elixir (LiveView), et que ce n'est pas un défaut en soi.
Enfin, le fil est parasité par des accusations répétées contre Jane Street concernant une interdiction sur des marchés asiatiques. Un commentateur apporte une contre-analyse (protection de fraudeurs locaux), et un autre signale la duplication suspecte du message. Sur le fond, plusieurs participants s'étonnent que Bonsai revienne si souvent sur HN, l'attribuant à l'attirance du site pour les langages de niche. Globalement, la discussion confirme l'intérêt technique mais relativise l'innovation, pointe les alternatives et corrige quelques affirmations de l'article, notamment sur le support web uniquement et l'intégration à l'écosystème JS.
-
Wind and solar overtake fossil fuels in Germany for the first time
En 2025, pour la première fois, l'éolien et le solaire ont produit plus d'électricité que les énergies fossiles en Allemagne : 225 TWh (44 %) contre 217 TWh (43 %), selon l'analyse de Carbon Brief sur les données de l'Energy Institute. L'UE dans son ensemble franchit également ce cap.
Ce basculement découle de la stratégie Energiewende et des objectifs nationaux : 115 GW d'éolien terrestre visés d'ici 2030, 20,8 GW de nouvelles capacités approuvés en 2025, 80 % de renouvelables dans la consommation électrique en 2030 et un système électrique « largement climatiquement neutre » en 2035. La sortie du nucléaire reste actée malgré les critiques du chancelier Friedrich Merz, tandis que le charbon, encore très présent, doit disparaître au plus tard en 2038.
Des oppositions émergent désormais côté AfD, et le gouvernement mise sur des centrales à gaz de transition, prévues pour fonctionner à l'hydrogène vert d'ici 2045. Une révision des calendriers doit être publiée en août.
Plusieurs commentateurs corrigent le titre de l'article : il s'agit précisément de la production d'électricité, pas de la consommation totale d'énergie. L'exploit est réel pour l'année 2025, mais certains notent que ce type d'annonce revient régulièrement avec des métriques différentes (puissance installée, production sur un trimestre, etc.). Ils rappellent aussi que l'Allemagne importe de l'électricité (notamment nucléaire depuis la France) et que la demande électrique stagne en raison de la crise industrielle, ce qui relativise la performance.
Sur le fond, un débat oppose ceux qui regrettent la sortie du nucléaire — avec des chiffres sur les capacités de charbon restantes et les anciennes capacités nucléaires — et ceux qui y voient un investissement dans le stockage par batteries, en pleine croissance en Europe. Plusieurs contributeurs évoquent les défis techniques de l'intermittence : l'inertie du réseau, les onduleurs « grid-forming » et le stockage par chaleur (sable, briques, eau chaude) sont présentés comme des solutions opérationnelles, même si un avis minoritaire doute de la fiabilité sur plusieurs jours.
Enfin, la portée mondiale est questionnée : l'Allemagne ne pèse que 1,5 % des émissions mondiales de CO2, et les énergies renouvelables restent marginales dans le bilan énergétique global. Certains commentateurs estiment néanmoins que ce jalon est un signal positif, d'autant que l'efficacité de l'électricité par rapport aux combustibles fossiles change la donne. La discussion n'apporte pas de contradiction frontale à l'article, mais elle le replace dans un contexte économique et technique plus nuancé.
-
Show HN: Isopolis – Isometric pixel map of SF
Isopolis, présenté sur Hacker News, est une carte isométrique en pixels de San Francisco. Aucune autre information n'est disponible.
La discussion est très positive, saluant la beauté et l'exploration ludique de la carte isométrique de San Francisco. Plusieurs commentateurs la comparent à SimCity 2000, à Floor796 ou au projet isometric.nyc, et un praticien évoque son propre projet de rendu voxel pour souligner la difficulté technique. L'auteur répond à de nombreux commentaires, expliquant avoir utilisé Google Photorealistic 3D Tiles, un scraper généré par Claude Code et three.js, avec des paires d'entraînement produites via Google Nano Banana. Il a documenté tout le processus dans un fichier dev.html. Un commentateur présume que les données LIDAR publiques américaines auraient pu être une alternative, mais l'auteur a privilégié les tuiles Google pour la qualité des textures.
Plusieurs défauts sont signalés : routes transformées en lacs ou rivières, étangs carrés dans le Tenderloin, un lac près de Buena Vista Park, ou encore Starr King Park devenu lac. L'auteur reconnaît un problème récurrent avec l'eau, qu'il attribue aux ombres, aux zones vertes plates et à un détecteur d'eau imparfait. Il note que de meilleures données d'entraînement devraient corriger ces artefacts. Il réagit aussi à la demande de zoom supplémentaire, d'abord avec réserve, puis en activant un zoom plus fort. Un commentaire critique, minoritaire, juge la carte comme un « brouillard bizarre et moche », sans valeur artistique.
La discussion apporte un regard de terrain sur les coulisses : l'auteur précise que des outils d'IA comme Codex/Claude lui ont permis de créer des outils de développement à chaque étape, et un commentateur suggère que ce projet pourrait servir de benchmark pour évaluer les progrès des modèles par rapport à isometric.nyc. Plusieurs souhaits émergent : une application de navigation basée sur cette carte, ou une intégration Google/Apple Maps. Un lien vers les images satellite obliques d'Ars Technica est partagé, apprécié pour son esthétique.
-
Andy Pavlo joins ClickHouse to establish ClickHouse Labs
Andy Pavlo, professeur à l'université Carnegie Mellon, rejoint ClickHouse pour créer et diriger ClickHouse Labs, une nouvelle équipe de recherche sur les bases de données. Il raconte son intérêt de longue date pour ClickHouse, depuis sa sortie open source en 2016, et son objectif de mener des recherches appliquées en collaboration avec les ingénieurs de l'entreprise. L'équipe travaillera notamment sur l'adaptation des SGBD aux technologies d'IA et d'agents, et ambitionne de devenir une référence dans le domaine, à l'image d'IBM Research ou Microsoft Research.
La discussion salue majoritairement la nouvelle, avec de nombreux commentaires de félicitations et d'enthousiasme. Plusieurs commentateurs disent apprécier les cours d'Andy Pavlo, notamment sa série de conférences à CMU, et espèrent qu'elle continuera sous le parrainage de ClickHouse ; un commentateur indique que ce sera le cas, une nouvelle série débutant le mois prochain. Un utilisateur raconte avoir réalisé son mémoire de bachelor autour de ClickHouse après avoir suivi ces cours, illustrant le lien entre le monde académique et l'entreprise. D'autres s'interrogent sur l'évolution technique : convergence des bases OLAP comme ClickHouse et StarRocks avec Trino, découplage calcul/stockage sur S3, ingestion et indexation, formats comme Iceberg ou Paimon. Un avis répond que les jointures de ClickHouse s'améliorent presque chaque mois, et qu'elles sont moins mauvaises qu'avant, tout en admettant qu'elles restent perfectibles.
Un point de divergence surgit à propos de la nature de ClickHouse Labs. Un commentateur sceptique y voit simplement un poste d'ingénieur dans une entreprise de bases de données, ce qui suscite une réponse expliquant que dans les domaines tech pointus, un « laboratoire de recherche » donne une licence pour explorer des idées dont l'adoption peut prendre des années, en citant IBM Research et Microsoft Research comme modèles. Un autre commentaire regrette que le financement public de la recherche en bases de données soit en déclin et demande à Andy Pavlo de convaincre ClickHouse de financer la recherche académique ; en réponse, un intervenant affirme qu'il y a toujours beaucoup de recherche à fort impact en bases de données dans les universités, tout en rappelant que la partie citée de l'article est en partie un argument marketing. La discussion corrige ou nuance ainsi l'article sur ce point : le laboratoire n'est pas forcément un organisme de recherche isolé, et le discours officiel doit être pris avec du recul.
Enfin, un commentaire conteste la phrase de l'article présentant le fait que ClickHouse soit écrit en C++ comme une fonctionnalité, en soulignant que « écrit en C++ » n'est pas en soi une caractéristique.
-
MiniMax H3 Day-0 Support in ComfyUI: Open Weights, Native Audio, and 2K Video
MiniMax a publié son modèle vidéo open-weights H3, avec support natif dès aujourd'hui dans ComfyUI. Ce modèle omni-modal génère des vidéos jusqu'en 2K et 15 secondes avec audio stéréo natif, à partir de texte, d'images, de vidéos ou de références audio. Il prend en charge plusieurs modes : text-to-video, image-to-video, contrôle première/dernière image, et transfert de mouvement via une vidéo de référence. Optimisé dans ComfyUI, il peut tourner localement sur une RTX 3060.
Les commentaires saluent la qualité des résultats pour un modèle ouvert, avec un retour concret : sur une RTX 4070 Ti Super, génération de 10 secondes en 480p en 10 minutes, jugée spectaculaire. Un point technique discuté : l'élagage des poids de modulation (~40 % des paramètres) remplacés par une table de correspondance. Un commentateur s'interroge sur l'extension aux LLM, mais on lui répond que ces poids adaLN sont spécifiques aux modèles de diffusion, absents des LLM classiques. D'autres notent que cela pourrait être pertinent pour des FPGA, qui sont essentiellement des LUT.
Sur la qualité esthétique, les avis divergent : certains trouvent les rendus très bons (la souris, par exemple), d'autres dénoncent un aspect générique et « lisse » typique de l'IA. Un commentaire rassure : c'est le pire que ce modèle sera jamais. Plusieurs notent que le mode reference-to-video est un atout pour la continuité entre plans. La comparaison avec Seedance 2.5 est évoquée : le MiniMax serait en retard d'un an et demi, mais son ouverture est un avantage pour la communauté, notamment face aux contrôles de sécurité des plateformes. Un utilisateur dit avoir supprimé LTX2 et WAN après les échantillons, malgré des doutes sur la licence.
Enfin, plusieurs commentaires corrigent ou nuancent l'article : la réduction de mémoire de 66 % ne signifie pas une génération rapide, comme l'atteste le temps de 10 minutes pour 10 secondes. Un commentateur souligne que la production réelle se fait dans le cloud avec des générations concurrentes, et que le hobbyiste peut attendre. Les inquiétudes sur la formation à partir d'œuvres existantes et l'impact créatif sont également présentes. Un avis minoritaire évoque l'AGI, mais il est contredit par la perception de « slop » générique. En résumé, la discussion valide la performance technique tout en tempérant l'enthousiasme sur l'usage pratique et l'originalité.
-
Show HN: Run an 80B Qwen in 4.3 GB of RAM on a Mac, and a 35B on an iPhone
Swiftlet est un runtime Swift + Metal pour la famille de modèles hybrides MoE Qwen3-Next et Qwen3.5/3.6. Il ne garde en mémoire que le cœur dense du modèle et diffuse les poids des experts routés depuis le stockage à la demande : 80B tourne sur Mac dans ~4,3 Go de RAM, 35B sur iPhone 17 dans ~2,5 Go à ~1 tok/s. Environ 3B de paramètres sont actifs par token, ce qui rend ces modèles bons pour discuter mais faibles en rappel de faits.
Le projet fournit une bibliothèque, un CLI, un serveur compatible OpenAI et une app iOS (Priv AI). Il repackage les checkpoints MLX en conteneurs .qpack avec experts à pas fixe pour un pread par expert, cache à éviction LFU+recency, shaders compilés à la volée, et validation contre mlx-lm. Code source ouvert sous Apache 2.0, fonctionne sur Apple Silicon (macOS 14+ / iOS 17+).
Plusieurs commentateurs saluent l'expérimentation comme un progrès nécessaire, même si les performances actuelles sont limitées. Certains imaginent un futur où de très gros modèles tourneront sur du matériel grand public, et un commentaire évoque l'hypothèse qu'Apple parie sur des modèles locaux très efficaces. D'autres doutent de l'intérêt économique face aux serveurs centralisés, notant que la plupart des usages resteront en ligne et que le web index ne sera pas téléchargeable localement.
Les critiques techniques portent sur la lenteur du préfill et l'usure des disques. Un commentateur souligne que les débits annoncés masquent le goulot d'étranglement du traitement initial, rendant l'outil inadapté aux interactions temps réel mais acceptable pour des tâches de fond. Un autre met en garde contre le swap sur disque qui use le SSD, mais on lui répond que seules les écritures sont nocives. Plusieurs suggèrent d'augmenter le cache RAM pour accélérer, avec la limite de ne pas savoir quels experts garder en mémoire.
La discussion corrige l'article : l'affirmation de « première fois » est contestée, un lien vers un projet similaire (400B sur iPhone) étant donné. Un commentaire pointe aussi la mention « Hello Claude » dans le README, qui s'explique par l'utilisation de Claude Code pour générer le code, et non une collaboration officielle. Enfin, un remerciement à l'auteur pour avoir cité TurboFieldfare.
-
Taylor Farms has rewritten its cyclospora statement four times in sixteen days
En pleine épidémie de cyclospora, Taylor Farms a réécrit quatre fois son communiqué public en seize jours, sans jamais corriger les versions précédentes. La première version (17 juillet) attribuait le retrait de produits aux données de traçage de la FDA pointant vers une ferme indépendante représentant moins de 1% de l'offre de laitue iceberg. La version du 19 juillet affirmait que la FDA s'était excusée auprès de l'entreprise, ce que la FDA n'a jamais confirmé, tout en recadrant le rappel comme une précaution. Les versions suivantes ont mis en avant les protocoles de sécurité, la suspension de la production au Mexique et la création d'un hub d'information, avec des incohérences internes sur la liste des États concernés (28 dans la FAQ, 27 dans le texte).
L'auteur rappelle qu'en 2013, une épidémie de cyclosporiase liée aux salades en sachet de Taylor Farms de Mexico avait touché 631 personnes. L'évaluation environnementale de la FDA n'avait pas retrouvé le parasite mais recommandait à l'entreprise de déterminer si Cyclospora était un danger raisonnablement probable dans la région de culture, et de mettre en place un plan d'échantillonnage à la reprise d'activité. Selon l'auteur, aucun résultat publié de ce plan n'existe.
La discussion porte principalement sur la fiabilité de l'article et sur l'interprétation des réécritures successives des déclarations de Taylor Farms. Plusieurs commentateurs estiment qu'il est normal de mettre à jour une communication à mesure que les informations évoluent, surtout quand les symptômes mettent des semaines à apparaître, et citent la phrase attribuée à Keynes sur le changement d'avis. D'autres, au contraire, voient ces modifications comme suspectes, notamment parce qu'une rétractation est intervenue juste après une visite du PDG à la Maison-Blanche. Un commentaire pointe toutefois que l'article lui-même est probablement rédigé par une IA (un outil de détection donne 100 %) et émane d'un avocat spécialisé dans les poursuites, ce qui jette un doute sur son objectivité. Un avis minoritaire rappelle que l'article n'apporte aucune preuve que les coupes budgétaires au laboratoire CDC aient eu un impact sur la réponse à l'épidémie.
Plusieurs informations pratiques ressortent : les salades en sachet Taylor Farms sont identifiables par un code alphanumérique commençant par TF près de la date de péremption, et la marque Dole est citée comme une alternative qui n'est pas de Taylor Farms. Un commentateur s'interroge sur la transparence des restaurants quant à la provenance de leurs ingrédients, tandis qu'un autre défend l'idée que les grandes exploitations « familiales » ne méritent pas la sympathie qu'on leur accorde, car elles représentent une part énorme de la production agricole et bénéficient d'avantages. Des échanges plus anecdotiques concernent le lavage de la laitue, certains affirmant que le risque vient surtout de la surface, et un témoignage personnel fait état de maux d'estomac après un produit Taylor Farms.
La discussion nuance donc l'article de deux manières : d'une part, les réécritures de communiqués ne sont pas forcément une preuve de dissimulation, d'autre part, la qualité de l'article et ses motivations sont contestées. Par ailleurs, le lien avec les coupes de DOGE est évoqué mais sans démonstration de causalité.
-
Smaller, faster, safer: running Kimi and GLM at scale
Cloudflare Workers AI détaille comment il sert efficacement les grands modèles open source Kimi (Moonshot) et GLM (Z.ai) sur GPU, en combinant trois techniques : quantification du cache KV en FP8, compression des poids en INT4, et vérification d'intégrité du cache partagé.
Quantifier le cache KV de 16 à 8 bits double la capacité de contexte de Kimi K2.6 (686 000 à 1,37 million de tokens) et augmente le débit maximal de 41 % en décodage, à coût réduit. Les poids de GLM 5.2 passent en INT4, réduisant le checkpoint de 40 % et libérant de la mémoire pour le cache KV, avec un décodage plus rapide et une précision inchangée. Ces optimisations sont appliquées différemment en préfill (FP8) et en décodage (INT4).
Le troisième volet protège le cache KV partagé entre des centaines de requêtes via des contrôles par tags, avec un surcoût de moins de 1 % en débit et latence. Cloudflare indique poursuivre ce travail avec l'extension du cache KV FP8, la validation de poids NVFP4 sur Blackwell et l'objectif d'activer les vérifications d'intégrité sans coût notable.
Plusieurs commentateurs saluent la transparence de Cloudflare sur la quantification du cache KV, mais estiment que cette transparence reste insuffisante. Ils pointent que seul Kimi K2.6 a été testé, que les benchmarks ne couvrent pas le codage (où les erreurs de tool call peuvent s'accumuler) et que l'affirmation « cela ne change pas les réponses du modèle » est trop forte ; ils suggèrent de mesurer la distance entre distributions de probabilités. Une étude vLLM est citée comme contre-exemple avec des benchmarks incluant LiveCodeBench 6. Un commentateur va jusqu'à qualifier de fraude le fait de ne pas signaler la quantification sur la page du modèle, mais une réponse nuance en distinguant quantification des poids et des activations.
Sur la confidentialité, un commentateur accuse Cloudflare d'être un honeypot faute de ZDR, mais des réponses démentent ce FUD en citant la politique de confidentialité (pas d'entraînement sur les contenus clients) et précisent que le ZDR existe avec la facturation unifiée. D'autres discussions concernent les taux de hit du cache, où un commentateur rapporte des différences entre usage direct et via OpenRouter, tandis qu'un autre précise qu'un taux structurellement nul peut ressembler à un taux cassé. Le choix du format INT4 est débattu : un commentateur demande pourquoi pas NF4, mais une réponse estime que INT4 est suffisant et rapide.
Enfin, plusieurs commentaires jugent l'article trop superficiel et rédigé comme du texte généré par IA ; l'un d'eux note que les blogs Cloudflare sont destinés à être consommés par des agents, pas par des humains. Une question sur les métiers liés au serving reçoit des réponses évoquant MLOps ou des rôles SRE/Infra avec compétences GPU. La discussion apporte donc des corrections importantes sur la rigueur des tests, la transparence réelle et les implications pratiques pour les développeurs.
-
ICE Collected Nearly 1M People's DNA Last Year–Including Young Children
L'article de WIRED révèle une expansion massive de la collecte d'ADN par l'immigration américaine (ICE) auprès des personnes détenues pour des infractions civiles. En 2025, ICE aurait ajouté environ 920 000 profils génétiques au système CODIS du FBI, devenant la plus grande source de nouveaux profils dans la base de données criminelle. Des enfants et des familles détenus sont concernés, suscitant des critiques de parlementaires. Un homme, Hugo Moreno-Mendez, a été poursuivi pour avoir refusé de fournir un échantillon d'ADN et condamné.
En 2020, le ministère de la Justice a supprimé une exemption qui limitait ces prélèvements, et ICE a émis une directive exigeant l'ADN de presque tous les détenus. Les données de Georgetown Law estiment qu'à ce rythme, le DHS fournira plus d'un tiers des profils CODIS d'ici 2030. L'agence défend cette pratique comme une mesure d'identification, mais les critiques y voient un détournement d'une base destinée aux criminels.
La discussion HN autour de l'article sur la collecte de près d'un million d'ADN par ICE, dont celui de jeunes enfants, est très polarisée. Plusieurs commentateurs expriment une profonde méfiance envers la conservation de données génétiques par l'État, évoquant le précédent allemand (lois strictes) et un parallèle historique avec le traitement des Amérindiens par les États-Unis, notamment le « blood quantum ». Un avis minoritaire estime qu'un tel fichier pourrait être utile médicalement et pour résoudre des crimes, mais concède que la réalité des abus rend l'idée impraticable. Un commentaire sarcastique suggère que ces données serviront bientôt à entraîner des IA discriminatoires.
Plusieurs intervenants défendent au contraire la collecte, y voyant un outil légitime : identifier les criminels et valider les liens familiaux lors des contrôles, ce qui aiderait à lutter contre le trafic d'enfants. L'un d'eux affirme que l'article omet ce bénéfice et ne mentionne que des « arguments vagues ». Une réponse à ce commentaire le ridiculise en le comparant à une justification de l'apartheid, montrant un clivage net entre ceux qui voient une protection et ceux qui voient une dérive autoritaire. Un autre commentaire souligne que la crainte de voir les règles changer est le vrai problème : « je n'ai rien à cacher » ne protège pas si le gouvernement modifie les lois ensuite.
La discussion corrige un point de grammaire : le titre devrait dire « y compris celui de jeunes enfants » (including that of) plutôt que « y compris de jeunes enfants », car la collecte porte sur l'ADN et non sur les enfants eux-mêmes. Un commentaire note que ce volume massif coïncide avec la hausse des passages frontaliers. Enfin, plusieurs commentateurs estiment que ces pratiques ne cesseront « qu'une vraie conséquence soit introduite », exprimant leur scepticisme quant à l'absence de sanctions. Globalement, les avis sont tranchés : certains voient dans cette collecte une mesure de sécurité nécessaire, d'autres un dangereux précédent, sans qu'un consensus ne se dégage.
-
Rust project goals: Immobile types and guaranteed destructors
Proposition pour Rust : introduire des traits comme Move, Forget et Destruct afin de permettre aux types de refuser d'être déplacés en mémoire ou oubliés via mem::forget. L'objectif est de simplifier la gestion des types auto-référentiels et de garantir l'exécution des destructeurs, en s'appuyant sur le précédent de la hiérarchie Sized. Le travail vise à terme à rendre Pin obsolète, mais exclut toute modification du trait Future cette année.
La discussion précise d'abord qu'il s'agit d'un objectif de projet, pas d'une modification acceptée du langage : la conception peut évoluer, voire être abandonnée. Plusieurs commentateurs relèvent d'ailleurs que cet objectif est explicitement en concurrence avec un autre, « pin ergonomics », ce qui le rend risqué. L'enthousiasme est réel pour combler une lacune ancienne (les types immobiles) qui a conduit au hack Pin, mais des inquiétudes portent sur l'intégration avec le code existant utilisant Pin
: sans compatibilité, la fracture de l'écosystème serait inévitable. Le débat de fond oppose deux approches : celle de l'article, des types immobiles par propriété du type, et une autre proposition de withoutboats, les « pinned places » où l'immobilité est une propriété de la référence. L'objectif se positionne comme une alternative à pin ergonomics, mais ne résout pas le problème de la duplication des traits (Trait vs PinnedTrait), sauf pour Drop avec une surcharge spéciale. Un commentateur apprécie l'extension aux types linéaires (!Destruct) pour des API comme les transactions, qui évitent le recours aux closures ; un autre souligne que cela demande un travail considérable sur les collections standard, en citant Mojo comme exemple. Plusieurs évoquent la complexité des destructeurs garantis en C++, et un commentateur fournit le contexte historique : la « leakpocalypse » et les limites du modèle de Rust.
Des corrections et nuances techniques apparaissent : le contrat de Pin ne concerne pas seulement l'emplacement de l'objet, mais aussi les projections de pin (comme Pin
-
AirLLM 70B inference with single 4GB GPU
AirLLM est une bibliothèque d'inférence qui réduit drastiquement l'empreinte mémoire des LLM, permettant de faire tourner des modèles 70B sur une seule carte GPU 4 Go, sans quantification, distillation ni élagage. Elle prend en charge des modèles encore plus gros : Llama 3.1 405B sur 8 Go, DeepSeek-V3 (671B) sur ~12 Go et Kimi K3 (2.8T) sur moins de 4 Go grâce à un streaming expert par expert pour les modèles MoE.
La version 3.0 ajoute le support FP8 et les modèles récents, avec une API simple via AutoModel.from_pretrained. L'installation se fait par pip install airllm. Une option de compression par quantification en 4/8 bits accélère l'inférence jusqu'à 3x. Le projet supporte de nombreux modèles (Llama, Qwen, DeepSeek, etc.) et fonctionne aussi sur MacOS (Apple Silicon) et CPU.
Le contenu est un README détaillé avec exemples de code et notes de version.
Plusieurs commentateurs saluent l'exploit technique de faire tourner un modèle 70B sur une GPU 4 Go, mais s'accordent à dire que la latence rend l'outil inutilisable pour de l'interactif. Le chiffre clé cité est de 292 secondes par token sur une RTX 6000 Ada, ce qui a d'abord trompé certains lecteurs qui croyaient lire des tokens par seconde. La distinction entre « peut tourner » et « utile en pratique » revient souvent : pour du batch ou des tâches de nuit, cela peut avoir un intérêt, mais pour du chat ou de l'agentique, le temps de première réponse est rédhibitoire. Un commentateur souligne qu'à cette vitesse, même des petits modèles sur du matériel correct ne suffisent pas pour un usage interactif confortable, loin des performances des modèles propriétaires.
Les avis divergent sur l'utilité réelle de ces projets. Certains y voient une nécessité face à la flambée des prix du hardware, d'autres les jugent « vibe codés » et non maintenus, et plusieurs s'interrogent sur l'avantage par rapport à des solutions existantes comme llama.cpp avec quantification et streaming d'experts. Un commentateur critique sévèrement le manque de documentation et d'exemples concrets, préférant l'outillage mature de llama.cpp. Une réponse nuance en affirmant que la maintenance importe peu, car des assistants comme Claude Code permettent de faire fonctionner ces projets sans aide. Un autre clarifie le mécanisme : le modèle est téléchargé depuis Hugging Face, mais le RAM est économisé en ne chargeant que le noyau et la couche active, les autres étant streamées depuis le disque.
Concrètement, un utilisateur rapporte ses propres chiffres : sur deux GPU 32 Go (Radeon Pro V620), il obtient environ 20 tokens/s sur des modèles 27-31B, ce qui reste trop lent pour un usage agentique confortable, et estime qu'il faudrait du matériel plus récent à plusieurs milliers de dollars pour approcher la réactivité de Claude Code.