Publicité dans les chats IA & MicroGPT: GPT en 200 lignes - Actualités Hacker News (1 mars 2026)

On commence par l’éléphant dans la pièce: le coût de calcul des assistants IA… et la tentation de le financer par la publicité. 99helpers vient de lancer une “Ad-Supported AI Chat Demo”. Le ton est satirique, mais l’interface est entièrement fonctionnelle et surtout très pédagogique: elle montre à quoi ressemblerait un chat IA si on le traitait comme une page web monétisée. On y voit un éventail assez complet de formats: une pub plein écran avant même de commencer, avec un compte à rebours; des bannières et des encarts latéraux qui restent autour de la conversation; et surtout des “réponses sponsorisées”, où l’assistant tisse des recommandations de produits dans sa réponse. Plus subtil: des annonces textuelles contextuelles, insérées entre deux blocs de réponse, calées sur le sujet en cours. Et quand l’utilisateur montre une intention d’achat, l’outil affiche des “cartes produit” avec image, prix et bouton d’action — comme un mini comparateur dans le chat. Le clou du spectacle, c’est la barrière freemium: cinq messages gratuits, puis soit vous “regardez” une pub simulée de cinq secondes pour débloquer quelques messages, soit on vous pousse vers l’abonnement sans pub. Le site met aussi en regard l’économie pub versus abonnement: interruption et incitations parfois perverses (optimiser le clic plutôt que l’aide), besoin de ciblage donc questions de données et de vie privée, et modèles de revenus type CPM/CPC/CPA face au forfait mensuel. 99helpers précise que le modèle de langage est bien réel, mais que les marques sont fictives; les conversations seraient loggées pour améliorer le service, sans être revendues aux annonceurs. Au-delà de la blague, c’est une excellente maquette pour discuter produit, UX et éthique sans rester dans l’abstrait.

Restons sur l’IA, mais côté “comment ça marche” plutôt que “comment ça se vend”. Andrej Karpathy a présenté microgpt, un projet minimaliste et très didactique: l’entraînement et l’inférence d’un GPT… dans un seul fichier Python d’environ 200 lignes, sans dépendances. Ce qui est fascinant, c’est que tout ce qui compte est là, version compacte: un petit dataset (environ 32 000 prénoms, une ligne par prénom), une tokenisation au niveau caractère avec un token spécial de début de séquence, un mini moteur d’autodifférentiation “scalar” appelé Value, un Transformer simplifié façon GPT-2 (RMSNorm, pas de biais, ReLU), Adam, la boucle d’entraînement et la boucle de génération. Le modèle est minuscule — embeddings 16 dimensions, 4 têtes d’attention, 1 couche, contexte de 16 tokens — soit 4 192 paramètres. Et contrairement aux implémentations vectorisées, microgpt avance token par token et maintient explicitement un cache clés/valeurs, y compris pendant l’entraînement, en rétropropageant à travers ce cache parce qu’il reste dans le graphe de calcul. Après 1 000 itérations, la perte descend sensiblement, puis le modèle “hallucine” des prénoms plausibles en échantillonnant la prochaine lettre jusqu’au token BOS. Le code est fourni via gist, page web et Colab, avec une progression train0 à train5 pour voir naître un GPT étape par étape. Pour apprendre, c’est presque un laboratoire de poche.

Dans la même veine “apprendre en construisant”, Carnegie Mellon lance 10-202: Introduction to Modern AI, enseigné par Zico Kolter. Le cadrage est intéressant: “IA moderne” ici veut dire ML et grands modèles de langage, ceux qui propulsent ChatGPT, Gemini ou Claude, pas l’IA au sens large historique. Le cours a aussi une version en ligne gratuite, décalée de deux semaines: vidéos et devoirs autogradés, mais sans quiz ni examens. Et la structure est très orientée pratique: une suite de devoirs de programmation qui vous fait monter les marches, depuis des modèles linéaires et PyTorch, jusqu’aux Transformers, un LLM minimal, du fine-tuning de chat, puis des approches de type renforcement pour certains comportements. Le message implicite: les briques fondamentales ne sont pas magiques, et on peut en implémenter une base en quelques centaines de lignes. Côté règles, c’est carré: Python et calcul différentiel en prérequis; algèbre linéaire et proba utiles mais rattrapées. Et détail très actuel: les assistants IA sont autorisés pour les devoirs, mais l’équipe encourage à rendre une version finale faite sans IA; en revanche, IA et supports externes sont interdits en quiz et examens en classe.

Pour compléter le bloc “pédagogie ML”, un article MLU-Explain revient sur les arbres de décision. C’est un classique, mais rarement expliqué avec autant de clarté: un arbre de décision, au fond, c’est une suite de règles if-then imbriquées, qui partitionnent l’espace des variables. L’article illustre avec un mini dataset de “fermier”: diamètre du tronc et hauteur pour classer des arbres en Apple, Cherry ou Oak. On voit comment un premier seuil, par exemple Diamètre ≥ 0,45, isole une zone majoritairement “Oak”, puis des splits supplémentaires affinent les régions. Le point clé, c’est la sélection des splits: on introduit l’entropie comme mesure d’impureté, puis le gain d’information comme réduction d’entropie après un découpage. L’algorithme ID3 est présenté comme une approche gloutonne et récursive: on teste des partitions, on choisit le meilleur gain, et on s’arrête selon des règles pratiques (profondeur max, taille minimale des feuilles…). L’article rappelle aussi le piège: pousser jusqu’à des feuilles parfaitement “pures” conduit souvent à un arbre trop profond qui apprend le bruit — le surapprentissage, lié au compromis biais-variance. Et comme les arbres sont instables, de petites variations dans les données peuvent donner un arbre très différent, d’où l’intérêt de l’élagage et des ensembles comme les random forests.

Changement de registre: produit IA grand public. Anthropic met en avant une fonctionnalité “Import Memory” pour Claude, pensée pour faciliter la migration depuis d’autres assistants. L’idée est simple: si vous avez passé des mois à “éduquer” un autre outil sur vos préférences — ton, format de réponses, contexte de travail — vous pouvez transférer ce contexte pour que la première conversation avec Claude ressemble à la centième. Le mécanisme est basé sur un copier-coller: vous prenez un prompt fourni par Anthropic, vous l’exécutez chez votre assistant actuel pour extraire un résumé structuré de vos préférences, puis vous collez le résultat dans les paramètres de mémoire de Claude. Anthropic insiste sur deux aspects: d’une part, la séparation des contextes par projet pour éviter que tout se mélange; d’autre part, la transparence, avec la possibilité de voir et d’éditer tout ce que Claude “se souvient”. C’est réservé aux offres payantes, ce qui souligne au passage que la mémoire persistante devient une vraie différenciation produit — et un sujet sensible sur le plan des données.

Côté systèmes Linux, on a une enquête qui résout un petit mystère récurrent: pourquoi, quand on surcharge malloc via LD_PRELOAD pour logger les allocations, la première allocation dans beaucoup de programmes fait très souvent 73 728 octets, soit environ 72 KB. L’auteur a pris soin d’éviter les pièges habituels (logger sans déclencher d’allocations récursives, donc avec buffers sur la pile et syscalls bas niveau), puis a observé le phénomène sur des outils comme ls. Avec gdb et un breakpoint au bon endroit, la pile d’appels montre que ça ne vient pas du programme lui-même ni directement de libc, mais de libstdc++. Et plus précisément: du code de gestion des exceptions (libsupc++), qui alloue paresseusement un “emergency pool”. Ce pool sert de filet de sécurité: même si malloc échoue plus tard, l’exécution peut encore allouer les objets d’exception et lancer une exception. Sa taille par défaut est calculée à partir de constantes (taille et nombre d’objets), ce qui tombe autour de 72 KB sur beaucoup de systèmes 64-bit. Et on peut le vérifier en modifiant GLIBCXX_TUNABLES: réduire le nombre d’objets réduit immédiatement la première allocation; mettre à zéro peut le désactiver. Moralité: ce “gros malloc” initial n’est pas forcément une fuite, et explique aussi certains rapports Valgrind “still reachable” sur des programmes C++ qui semblent ne rien faire.

Sécurité web maintenant, avec un sujet qui va compter: Chrome annonce un programme pour rendre les certificats HTTPS résistants aux futurs ordinateurs quantiques, sans exploser les coûts en bande passante et en latence du TLS. Le problème, c’est que si on met des algorithmes post-quantiques directement dans des chaînes X.509 classiques, tout grossit: certificats, signatures, chaîne de confiance, et en plus il faut Certificate Transparency. Google dit clairement: pas de plan immédiat pour intégrer massivement des certificats X.509 post-quantiques dans le Root Store de Chrome, car ce serait trop lourd. À la place, ils poussent un nouveau modèle: les Merkle Tree Certificates, en cours de standardisation à l’IETF via le groupe PLANTS. Le principe: une autorité de certification signe une “tête d’arbre” qui représente potentiellement des millions de certificats, et le navigateur ne reçoit qu’une preuve Merkle d’inclusion — compacte — plutôt qu’une chaîne complète de signatures volumineuses. Bonus: la transparence devient native, puisqu’un certificat doit être dans l’arbre public pour exister. Côté déploiement, Google décrit trois phases: une étude de faisabilité avec Cloudflare déjà en trafic réel, adossée à un X.509 traditionnel en secours; puis en 2027, une implication des opérateurs de logs CT “éligibles” pour amorcer des arbres MTC publics; et enfin un Chrome Quantum-resistant Root Store, en parallèle du programme actuel, avec des protections contre le downgrade en option. Ils évoquent aussi des évolutions de politique CA: ACME-only, révocation modernisée centrée sur la compromission de clé, preuves publiques de validation de domaine, et monitoring continu plutôt que audits annuels. C’est ambitieux, et ça montre que la transition post-quantique ne sera pas juste “changer un algorithme”, mais revoir une partie du modèle de certificats.

Finissons avec performance et dev web. D’abord PostgreSQL: Tomas Vondra remet en question un réglage historique, random_page_cost, par défaut à 4.0 depuis environ 25 ans. Il mesure concrètement le coût relatif du random I/O versus séquentiel sur une table de 4,4 Go, avec direct I/O pour limiter l’effet du cache OS. Résultat: dans son scénario, le coût effectif du random serait plutôt autour de 25 à 35 sur SSD local, et encore plus sur stockage distant. Dit autrement: même sur SSD, l’écart latence/random vs séquentiel reste énorme, et sous-estimer random_page_cost peut pousser le planner à choisir des index scans trop souvent, parfois jusqu’à 10 fois plus lent sur certaines sélectivités. Il nuance toutefois: dans la vraie vie OLTP, si la donnée est en cache, le raisonnement change; et les bitmap scans, plus séquentiels, réduisent l’impact. Sa recommandation: ne pas “baisser parce que SSD”, mais ajuster avec mesure et observation, par exemple via pg_stat_statements. Et côté front-end, Float64 Vertex présente Vertex: un framework SPA en une seule page, environ 1 000 lignes, sans build step, compatible jQuery. On y trouve un wrapper DOM façon jQuery (sélection, events, attributs), un Vertex.ajax basé sur fetch mais avec une API “à l’ancienne” et des callbacks, un moteur de templates Mustache avec re-render sur set/update et du data-bind, un router hash, et même un reconciler “fiber” à la React avec createElement, render, Fragment, lazy et des hooks type useState/useEffect. C’est le genre de projet qui vise les équipes qui veulent une ergonomie moderne, mais une distribution ultra simple: un fichier, on l’inclut, et on code.