Les 3 articles les plus chauds de la veille du 24 octobre 2026. 🔥

🔥 Top 3

1. Rapidly scaling online storage to serve over 1 billion ChatGPT users (Part II)

12 fois plus vite. Voilà ce qu’OpenAI annonce pour les lectures de données de ChatGPT, sur une base qui sert plus d’un milliard d’utilisateurs. Le deuxième volet de son retour d’expérience porte sur Habitat, la couche de stockage qui garde l’historique des conversations.

Le problème est simple à poser. Chaque requête doit retrouver la bonne conversation, appartenir au bon compte, et revenir en quelques millisecondes. À cette échelle, la moindre latence se paie en millions de requêtes ralenties.

Deux leviers techniques. D’abord le multi-tenant : plusieurs clients partagent la même infrastructure, mais leurs données restent strictement cloisonnées. Pensez à un immeuble de bureaux, mêmes murs, mêmes ascenseurs, portes fermées à clé. C’est ce cloisonnement qu’OpenAI décrit comme fiable, autrement dit sans fuite entre comptes, ce qui reste le vrai point dur.

Ensuite le cache global. Une donnée lue souvent est recopiée près de l’utilisateur plutôt que d’être rappelée à la source à chaque fois. Le stockage s’appuie sur Azure Cosmos DB, la base distribuée de Microsoft.

Reste une question que la communication laisse ouverte : 12× plus vite, mesuré sur quel percentile ? Une moyenne flatteuse peut cacher des lectures lentes sur les grosses conversations, celles qui comptent le plus.

Le chiffre à retenir n’est pas le facteur 12, mais ce qu’il sous-entend : chez OpenAI, optimiser le stockage est devenu un travail d’infrastructure à part entière, pas un détail de plomberie.

🔗 OpenAI

2. Quick Study

Un prompt. Une photo. Et Claude Opus 5.5 pond un simulateur de peinture à l’huile qui tourne dans le navigateur.

Simon Willison a demandé au modèle de construire un « artifact » (un petit programme autonome qui s’exécute dans la page, sans installation) capable d’ouvrir une image et de la repeindre en quelques secondes, au pinceau simulé, sur un élément canvas.

Le résultat s’appelle Quick Study. En peinture, une étude rapide, c’est le croquis qu’un artiste torche en une séance pour capter l’essentiel avant d’attaquer la grande toile. Le programme fait exactement ça avec vos fichiers.

La mécanique tient en deux étages. D’abord la détection de contours de Sobel, un vieil algorithme qui compare la luminosité des pixels voisins : là où le contraste saute d’un coup, il trace une frontière. C’est du calcul matriciel basique, et ça suffit à repérer l’arête d’un nez ou le bord d’une table. Ensuite, le programme pose des coups de pinceau le long de ces lignes, en variant l’angle et l’épaisseur, puis remplit les zones plates avec des aplats.

Détail qui en dit long sur l’état des modèles : aucune bibliothèque externe, à part Google Fonts. Pas de moteur graphique, pas de dépendance à installer. Du JavaScript, un canvas, rien d’autre.

Willison avait déjà tenté l’aquarelle en P5.js avec un autre modèle. La nouveauté, ici, c’est le temps : quelques secondes pour transformer une photo en toile.

Quand un modèle solo sort ce genre d’outil sur une seule phrase de consigne, la frontière entre la démo de blog et le logiciel qu’on garde devient difficile à situer.

🔗 Simon Willison

3. a quarter of YC’s winter 2025 batch had 95% of their code written by AI. that was march 2025. writing code fast stopped…

Un quart de la promotion hiver 2025 de Y Combinator avait fait écrire 95 % de son code par une IA. C’était en mars 2025. Y Combinator, le plus célèbre accélérateur de startups américain, a donc vu débarquer des équipes dont le produit tournait sur du code qu’elles n’avaient presque pas tapé.

Le signal est net : la vitesse d’écriture n’est plus un avantage compétitif. Quand un agent, comprenez un modèle capable de produire et modifier des fichiers de code de façon autonome, sort une fonctionnalité en quelques minutes, tout le monde va à la même vitesse. Ce qui reste rare, c’est de savoir quoi construire.

Le second point de l’auteur du post, c’est le contexte. Un agent ne devine pas l’architecture d’un projet, les conventions d’une équipe, les contraintes d’un client. Il faut lui fournir la bonne documentation, les bons fichiers, les bonnes règles. Les startups qui réussissent avec ces outils passent moins de temps à écrire du code qu’à préparer le terrain pour la machine. C’est un travail moins spectaculaire, plus proche de la rédaction de spécifications que du développement.

Reste une question que personne ne tranche vraiment : quand 95 % du code sort d’une boîte noire, qui comprend encore ce qui casse en production à 3 heures du matin ? Les juniors formés sur du code généré sauront-ils un jour déboguer sans lui ?

🔗 x.com

📦 Le reste de la veille