Quake en CSS et favicon & Couleurs impossibles à afficher - Actualités Hacker News (20 juin 2026)

Et si un simple favicon pouvait transporter une page web entière, cachée dans quelques pixels, comme une mini-capsule de données ? Bienvenue dans The Automated Daily, hacker news edition. Le podcast créé par une IA générative. Nous sommes le 20 juin 2026. Aujourd’hui, on parle de bidouilles web qui repoussent les limites, d’IA qui cherche un second souffle au-delà du “toujours plus gros”, et de quelques rappels utiles sur la fiabilité du matériel, la latence des services, et même les couleurs que vos écrans ne sauront jamais vraiment montrer.

Quake en CSS et favicon

On commence par deux expérimentations web qui ont un petit parfum de “c’est donc possible”. D’abord, cssQuake: une version jouable de Quake dans le navigateur, mais avec une approche de rendu volontairement atypique, basée sur CSS via un moteur appelé PolyCSS. Le site ressemble à une pré-version: menus façon Quake, choix de cartes de l’épisode 1, options de debug comme l’affichage des FPS ou des panneaux de stats, et un multijoueur annoncé mais visiblement encore incomplet. L’intérêt n’est pas de remplacer les moteurs modernes en WebGL, mais de montrer que le web peut servir de terrain d’expérimentation pour des rendus inattendus — et que des techniques “hors-pistes” peuvent inspirer des outils, des démos, voire de nouvelles façons d’enseigner le graphisme temps réel. Dans le même esprit “détournement malin”, un développeur a encodé du HTML directement dans les canaux RGB d’un favicon PNG. Résultat: une petite image qui ressemble à du bruit visuel, mais qui contient en fait une mini-page, reconstruite ensuite en lisant les pixels via canvas et JavaScript. Important: le favicon ne “fait pas tourner” le site tout seul; il faut quand même un petit bootstrap pour décoder. Mais la démonstration marque les esprits: nos assets web, pensés pour l’image, peuvent aussi devenir des conteneurs de données. Et ça remet sur la table d’autres pistes du même genre, comme les favicons SVG ou certaines métadonnées d’images, avec des implications possibles pour l’obfuscation, l’archivage, ou les démos artistiques.

Couleurs impossibles à afficher

Changement de registre: la perception. Un article explique pourquoi certaines couleurs très saturées — notamment des cyans intenses — sont hors de portée de la plupart des appareils photo et des écrans. Même quand on parle d’écrans “wide gamut”, on reste limité par le fait qu’on reconstruit les couleurs avec trois primaires. Pour certains tons spectrales, il faudrait, en quelque sorte, une quantité “négative” de rouge pour les reproduire… ce qui n’a pas de sens physiquement avec des pixels classiques. L’article ajoute un détail intéressant: l’éclairage moderne, surtout certains LED blancs avec un spectre incomplet, peut carrément rendre ces cyans difficiles à observer. Moralité: si vous voulez repérer ces couleurs que le numérique a du mal à capturer, regardez la nature — la lumière filtrée par un feuillage dense, l’eau à certaines profondeurs, ou des couleurs structurelles chez des oiseaux et papillons. Au-delà de la curiosité, ça rappelle que nos outils et nos éclairages reformatent subtilement ce que nous pensons “normal” de voir.

SSD vieux mais increvable

Côté matériel, un test d’endurance sur YouTube a fait parler: un SSD SATA de 64 Go, âgé d’environ 16 ans, aurait encaissé autour d’un pétaoctet d’écritures côté hôte, tout en restant fonctionnel, avec des dizaines de milliers d’heures au compteur. C’est bien au-delà de l’endurance annoncée à l’époque, ce qui illustre un point clé: les valeurs de TBW sont d’abord des repères de garantie et des estimations statistiques, pas un interrupteur qui coupe net le jour J. L’article nuance toutefois: selon la façon dont les écritures sont mises en cache, la quantité “écrite” vue par l’OS ne correspond pas forcément à l’usure réelle de la mémoire flash. Mais le message reste utile: la longévité dépend autant de l’électronique, du firmware et de la chaleur que d’un chiffre sur une fiche technique, et la peur du SSD “qui meurt du jour au lendemain” est souvent exagérée.

Compression de données et IA

On reste dans les fondamentaux, avec un rappel sur la compression de données. Matt Mahoney propose un ouvrage pédagogique qui insiste sur une idée simple: compresser, c’est combiner un modèle probabiliste — autrement dit, de la prédiction — et une méthode de codage. Le codage, avec des techniques connues comme Huffman ou le codage arithmétique, peut s’approcher de l’optimal. Le vrai défi, c’est le modèle: deviner la structure des données, et le faire de manière générale est, en théorie, profondément difficile. Pourquoi c’est intéressant en 2026? Parce que plus on cherche une compression “meilleure”, plus on se rapproche d’une forme de compréhension des motifs… et donc d’un cousinage avec l’IA. Ce n’est pas juste “gagner quelques pourcents”: c’est une leçon sur les limites, les compromis, et la manière dont on mesure honnêtement les performances.

Bluesky, atproto et décentralisation

Sur les réseaux sociaux décentralisés, un billet s’attaque à une question fréquente: “où sont les instances Bluesky ?” Et la réponse, c’est que la question reflète surtout une habitude prise avec Mastodon. Dans Mastodon, l’instance est un bloc qui mélange hébergement, identité et application, avec des conséquences: votre identité est fortement liée à un serveur et à son administration. atproto, lui, sépare davantage les rôles: l’endroit où vos données sont hébergées, et les applis qui les agrègent et les présentent. L’auteur compare ça à l’ancien écosystème RSS: beaucoup de sites indépendants, et des lecteurs qui rassemblent le tout. Ce qu’il faut surveiller, selon lui, ce n’est pas le “nombre d’instances”, mais la facilité à migrer son compte entre hébergeurs, et l’émergence de clients variés. Dit autrement: la décentralisation se lit dans la portabilité et la diversité d’apps, pas seulement dans une carte de serveurs.

IA: limites du tout-scaling

Parlons IA: une analyse note que les plus gros laboratoires deviennent plus sceptiques sur l’idée que “plus grand” implique forcément “meilleur”. D’un côté, on observe des signaux de plateau dans certains benchmarks: des modèles open-weight très massifs se rapprochent de modèles propriétaires supposés encore plus gigantesques. De l’autre, un problème de fiabilité s’invite: à très grande échelle, on peut obtenir des réponses plus longues, plus assurées… et pourtant fausses, avec des hallucinations qui ne se corrigent pas automatiquement en ajoutant du compute. L’article évoque aussi un contexte de contraintes externes, notamment politiques et de sécurité nationale, qui pourraient limiter la mise en ligne de certains modèles après des contournements de garde-fous. Au final, le message est assez clair: l’industrie se heurte à un trilemme entre capacité brute, calibration de l’incertitude — savoir dire “je ne sais pas” — et efficacité. Et l’époque où l’on pouvait miser uniquement sur le scaling semble moins confortable.

Latence et serveurs parallèles

Un sujet plus “production”, mais très concret: la performance des services. Une étude de file d’attente modélise un service équilibré en charge avec plusieurs serveurs derrière un load balancer. À utilisation identique par serveur, on pourrait penser que la latence ne bouge pas beaucoup quand on ajoute des machines. Or, le calcul — et des simulations — montrent autre chose: en augmentant le nombre de serveurs, la probabilité qu’une requête doive attendre en file chute rapidement. Résultat: la latence moyenne se rapproche du temps de service, et même les latences extrêmes, comme le p99, s’améliorent. Pourquoi c’est important? Parce que ça donne une intuition économique utile: parfois, ajouter un peu de parallélisme peut acheter énormément de confort côté utilisateur — ou permettre de pousser l’utilisation plus haut sans dégrader l’expérience, tant qu’on reste dans une zone stable.

Villes: règle 3-30-300

On termine avec deux nouvelles “science et société”. D’abord, l’urbanisme: la règle 3-30-300 gagne en popularité comme indicateur simple d’équité verte. L’idée: voir au moins trois arbres depuis chez soi, vivre dans un quartier avec une canopée significative, et avoir un parc à distance de marche. Une analyse sur des centaines de villes européennes conclut que ça coince surtout sur la canopée: beaucoup de gens ont un parc pas trop loin, mais peu vivent dans des zones réellement ombragées. Et c’est loin d’être anecdotique: l’accès au vert est lié à la santé mentale, et l’ombre devient une question de mortalité quand les vagues de chaleur s’intensifient. Traduction opérationnelle: planter, oui, mais aussi libérer de l’espace au sol — moins de surfaces minérales, plus de continuité végétale. Enfin, côté neurosciences, le prix Kavli 2026 récompense notamment des travaux ayant consolidé une idée aujourd’hui centrale: les neurones peuvent fabriquer des protéines localement, près des synapses, plutôt que de tout produire dans le corps cellulaire et expédier à distance. Ce détail biologique résout un casse-tête élégant: comment renforcer une synapse précise parmi des milliers, ce qui est au cœur de l’apprentissage et de la mémoire. Et au-delà du mécanisme, ça oriente la recherche sur des troubles où la régulation des protéines synaptiques déraille, comme certaines formes de déficiences cognitives ou des maladies neurodégénératives.

C’est tout pour aujourd’hui. Si un thème relie beaucoup de ces histoires, c’est l’écart entre ce qu’on croit “possible” — en web, en IA, en ville, ou même en perception — et ce que la réalité permet quand on regarde de près. Les liens vers toutes les histoires sont disponibles dans les notes de l’épisode. À demain.

Quake en CSS et favicon & Couleurs impossibles à afficher - Actualités Hacker News (20 juin 2026)

Our Sponsors

Today's Hacker News Topics