Publicité et traçage dans ChatGPT & Souveraineté numérique et forges publiques - Actualités Hacker News (29 avr. 2026)

On commence par l’info la plus sensible côté vie privée et web moderne : un chercheur en sécurité dit avoir observé comment des publicités seraient livrées dans ChatGPT, et surtout comment les conversions seraient attribuées ensuite sur des sites marchands. L’idée, c’est qu’une annonce ne serait pas juste un lien “posé là” : elle s’insèrerait pendant la réponse, et le clic transporterait un identifiant chiffré. Ensuite, côté site marchand, un SDK de tracking lirait ce jeton, poserait un cookie first-party et renverrait des événements vers des serveurs d’OpenAI pour mesurer ce qui se passe après le clic. Pourquoi c’est intéressant ? Parce que ça décrit un circuit de mesure cross-site assez classique dans la pub… mais appliqué à un assistant conversationnel, avec un contexte d’usage où les gens s’attendent plutôt à “une réponse” qu’à une mécanique d’attribution. Et pour les défenseurs de la vie privée comme pour les équipes sécurité, ça donne des points concrets à auditer, bloquer ou encadrer.

Dans le même esprit — mais cette fois côté souveraineté et infrastructure — le gouvernement néerlandais a mis en ligne code.overheid.nl en “soft launch”. C’est une plateforme centrale pour publier et développer du logiciel open source au sein des administrations, auto-hébergée de bout en bout. Le pilote tourne sur Forgejo, présenté comme une alternative open source européenne aux grandes forges commerciales. Ce qui compte ici, ce n’est pas seulement l’outil : c’est le signal politique et opérationnel. Héberger soi-même son code et sa collaboration, c’est réduire la dépendance à des fournisseurs privés, mieux contrôler ses données, et créer un lieu commun où les organismes publics peuvent mutualiser. Pour l’instant l’accès est limité pendant la phase pilote, mais les développeurs sont invités à contribuer à la forme que prendra la plateforme.

Restons sur les forges et la collaboration : le mainteneur de Ghostty, Mitchell Hashimoto, annonce qu’il va sortir son projet de GitHub après dix-huit ans d’utilisation quotidienne de la plateforme. Il décrit une décision pénible sur le plan personnel — mais, selon lui, devenue nécessaire car la fiabilité se serait dégradée : des pannes et incidents quasi quotidiens bloqueraient des tâches essentielles comme la revue de pull requests et les pipelines CI. Le point clé, c’est qu’il ne critique pas Git en tant que tel, mais l’écosystème autour : issues, PR, intégrations, automatisation. Autrement dit, le “travail d’équipe” plus que le dépôt. Sa stratégie est prudente : migration progressive, miroir GitHub en lecture seule, et annonce plus tard du nouvel hébergeur après évaluation d’options commerciales et open source. Au-delà de Ghostty, c’est une question qui revient : que se passe-t-il si l’infrastructure sociale du logiciel libre dépend trop d’un seul acteur — et que cet acteur devient instable ?

Et justement, un autre billet fait le lien avec cette inquiétude : Armin Ronacher revient sur l’époque d’avant GitHub — SourceForge, Trac auto-hébergé, Subversion — puis sur la manière dont GitHub a fini par devenir un hub à la fois technique et social. Son argument principal : GitHub n’a pas seulement hébergé du code, il a aussi constitué une mémoire collective — discussions, décisions, historiques, artefacts — qui sert d’archive de facto. Ce qu’il redoute, c’est un retour à la dispersion sans filet : plus d’autonomie, oui, mais aussi le risque de perdre le “contexte” qui permet de comprendre pourquoi un projet est comme il est, et de vérifier une chaîne de responsabilité. Sa proposition est intéressante car très pragmatique : un archive publique, robuste et financée, qui préserve code, releases et métadonnées indépendamment des intérêts d’une entreprise. En clair : traiter l’open source comme un bien commun qui mérite une bibliothèque.

Dans une version plus radicale de la décentralisation, HardenedBSD annonce avoir déplacé son hébergement de code vers Radicle, et considère la plateforme désormais utilisable pour le projet, même si tout n’est pas encore lisse. Les dépôts principaux commencent à y apparaître, et l’équipe met en place des ponts pour que certains éléments du système puissent récupérer des ressources via l’infrastructure Radicle. Pourquoi ça compte ? Parce que Radicle vise un modèle où la distribution du code et la collaboration peuvent être plus résilientes face aux pannes, aux blocages, ou aux changements de règles d’une forge centralisée. On est encore dans une phase où l’expérience n’est pas aussi “clé en main” que les géants du secteur, mais c’est typiquement le genre de mouvement qui peut inspirer d’autres projets sensibles à la dépendance plateforme.

Passons sécurité logicielle. Un consultant Rust, Matthias Endler, commente la divulgation par Canonical de quarante-quatre CVE trouvées dans uutils — la réimplémentation en Rust de GNU coreutils — après un audit externe en vue d’Ubuntu 26.04 LTS. Son message est nuancé : Rust aide énormément contre toute une classe de bugs mémoire, mais ces failles montrent “où la sécurité Rust s’arrête”. Ici, les problèmes viennent surtout de la frontière avec l’OS et des sémantiques : des erreurs de logique autour des chemins de fichiers, des courses entre vérification et action, des permissions mal posées au mauvais moment, des confusions entre “deux chaînes identiques” et “deux chemins qui pointent vraiment vers la même chose”. Il souligne aussi des risques plus terre-à-terre : des conversions UTF-8 qui cassent sur des octets Unix, des panics qui deviennent des dénis de service, ou des erreurs ignorées qui font croire à des scripts que tout s’est bien passé. Le fond, c’est que pour des outils ultra-scriptés comme coreutils, la compatibilité n’est pas un luxe : c’est parfois une propriété de sécurité. Et ça rappelle une leçon simple : choisir un langage sûr ne remplace pas la rigueur sur les invariants système.

Petit détour par la culture web, mais avec une vraie question de mémoire numérique : Rip.so vient de lancer un “cimetière digital”, un site fait à la main qui catalogue des services autrefois dominants, aujourd’hui fermés ou vidés de leur substance. On y croise des noms que beaucoup n’ont pas oubliés : ICQ, Internet Explorer, Vine, GeoCities, Google Reader… avec des épitaphes courtes et une esthétique volontairement “early web”, jusqu’à un livre d’or et un webring. Pourquoi ça vaut le coup d’œil ? Parce que notre histoire en ligne disparaît vite, souvent sans archives durables. Entre acquisitions, pivot produits, abandon ou simple obsolescence, des pans entiers de culture numérique s’éteignent et ne laissent que des captures éparses. Ce genre de projet amateur rappelle que le web n’est pas une bibliothèque par défaut : il faut l’entretenir.

On termine avec une histoire plus “économie des makers” : Tindie, une marketplace importante pour les vendeurs indépendants de matériel électronique, a envoyé un email d’excuses après une longue indisponibilité et une communication jugée mauvaise pendant une transition de propriété. Les nouveaux propriétaires disent avoir dû migrer une plateforme vieillissante, et promettent de stabiliser le site et de traiter les problèmes de commandes, remboursements et paiements au cas par cas. Dans les discussions, on voit surtout une chose : quand il s’agit d’argent et de logistique, la confiance part vite, et revient lentement. Pour un marché de niche, quelques semaines de flou peuvent suffire à pousser vendeurs et acheteurs ailleurs. Et plus largement, ça rappelle que les “petites” plateformes, même très utiles, restent fragiles quand la continuité opérationnelle n’est pas béton.