Quotidien suisseMardi 22 septembre 2026Édition de 13h, technologie
Prochaine publication le 22 septembre 2026 à 17h
Une · Cloudflare · Python
Python Workers en GA : Cloudflare fait du Python une langue de premier plan
Cloudflare a annoncé lundi 21 septembre la disponibilité générale des Python Workers. Le langage devient une citoyenneté de premier rang sur la plateforme Workers : bindings natifs (Queues, R2, D1, Hyperdrive, Durable Objects, Workers AI, Workflows…), frameworks FastAPI / Django / Flask via workers.asgi et workers.wsgi, et sockets TCP pour les drivers de bases. Auteurs : Gyeongjae Choi, Dominik Picheta et Hood Chatham.
Jusqu’ici, passer un dictionnaire Python à une Queue exigeait encore du glue JavaScript (to_js / Object.fromEntries). La GA encapsule la conversion de types dans le runtime et le SDK Python : self.env.QUEUE.send({"key": "value"}) « juste marche ». Côté web, la plateforme Workers joue le rôle du serveur ; les connecteurs asgi / wsgi traduisent la requête native vers les structures ASGI/WSGI attendues par FastAPI, Django ou Flask — sans uvicorn ni gunicorn dans le Worker. Les sockets TCP passent par l’API Workers connect : asyncpg et aiomysql peuvent parler à Hyperdrive (support Python documenté dès le 16.09 dans le changelog Hyperdrive). Côté packages, Cloudflare a poussé PEP 783 (plateforme PyEmscripten) et le support cibuildwheel pour des wheels Wasm ; openai, langchain et mcp routent désormais via fetch. Dynamic Workers permet aussi d’instancier un Worker Python depuis un autre Worker.
Contexte : Python Workers existaient depuis deux ans sur Pyodide / Wasm. La GA ne change pas le modèle d’isolation ; elle retire la friction JS et ouvre les bindings « comme en TypeScript ». Distinguer : production-ready annoncé pour le langage et les bindings ; l’écosystème wheels PyEmscripten reste en adoption progressive — un paquet C/Rust absent n’est toujours pas magiquement disponible.
AMD a brièvement dépassé 1 000 milliards de dollars de capitalisation
Lundi 21 septembre, la capitalisation d’AMD a brièvement franchi le seuil du trillion de dollars, rapporte The Register (21:59 UTC). Nvidia reste loin devant (~5,5 T$), Intel autour de 640 milliards. Le boom IA (Instinct MI300 / MI350, rack Helios) et les gains Epyc nourrissent la valorisation ; Wall Street reste partagé sur la concentration du risque IA.
Côté accélérateurs, AMD revendique pour Helios +50 % de HBM4 et de bande passante scale-out, +15–25 % en entraînement et +30 % en perf/$ face aux racks Blackwell — chiffres « durs à valider », note The Register. Anthropic a accepté jusqu’à 2 GW d’Instinct ; OpenAI, Oracle, Microsoft et Meta prévoient des déploiements Helios. Côté CPU : part desktop > 35 %, datacenter 34,5 % (46,4 % si l’on ne compare qu’Epyc vs Xeon SP). Lisa Su a indiqué aux investisseurs attendre un chiffre d’affaires datacenter plus que doublé en 2027. Les workloads agents (code généré, outils) poussent aussi la demande CPU — terrain où Intel, Arm, Qualcomm et Nvidia concurrencent.
Google AX v0.3 : l’état des tâches agents quitte etcd pour Redis Streams
Google a publié AX v0.3.0 (20.09, Apache-2.0, Go) : orchestrateur open source « style Kubernetes » pour agents IA. Le changement architectural confirmé par AI/TLDR et Origins AI : l’état des tâches sort des CRD Kubernetes / etcd et passe dans Redis Streams, pour absorber des millions de tâches courte durée sans saturer le plan de contrôle. Trois binaires structurants : ax-server (API gRPC), ax-controller (réconciliation via consumer groups Redis), ax-task-runner (entrypoint sandbox / Agent Substrate). Primitives déclaratives : Task, Workspace, Gateway, Model.
Attention au cadre : le quickstart et les manifests d’install supposent toujours un cluster Kubernetes (plus Redis, registre, Agent Substrate). Origins AI rappelle que les chiffres Substrate (densité ×10, restore <500 ms) sont des assertions vendeur, sans benchmark indépendant publié, et que le projet se déclare non production-ready avec breaking changes attendus. Distinguer : déplacement confirmé de l’état tâches vers Redis ; promesses de densité / hibernation des acteurs = à traiter comme claims Google, pas comme mesures croisées.
io_uring + mémoire : pourquoi le plus gros gain n’était pas dans le ring
Evan Chan (Conviva, 2.09, partie 2) raconte la suite d’une réécriture Rust : remplacer mmap par io_uring + O_DIRECT avait d’abord rendu le moteur de requêtes plus lent. Le déblocage n’est pas venu d’un réglage de chunk size, mais de trois corrections d’architecture — dont la plus importante concerne les page faults à l’écriture, pas le ring.
Un SQE géant par colonne. Les logs montraient ~40 lectures concurrentes qui finissaient toutes ensemble après ~7 s, loin du plafond fio (~20 Go/s sur RAID NVMe). Cause structurelle : une seule SQE monstrueuse par colonne (parfois 650 Mo). Le noyau découpe en sous-requêtes, mais le driver RAID stripe bien mieux des SQE indépendantes que les fragments d’une seule. fio saturait avec beaucoup de petites SQE (typ. 4 Mo) en profondeur de file. Leçon : découper pour laisser le stripe travailler — la taille exacte du chunk (128 Kio à quelques Mio) importe peu sur un ring chaud.
Un thread I/O dédié, style fio. Empiler futures async, sémaphores et exécuteur (compio) sur un pipeline à une requête + un producteur I/O ajoutait du coût sans parallélisme utile. La refonte : un thread I/O qui ne fait que soumettre / poller des SQE (pas de wakers), buffers mmap round-robin, décodage/memcpy côté Tokio (spawn_blocking) avec concurrence bornée. Isoler la couche I/O dans un utilitaire type fio a permis de retrouver d’abord le plafond matériel avant de recoller Arrow et le cache applicatif.
La mémoire : MADV_POPULATE_WRITE et HUGETLB. Sur le chemin critique, perf montrait « memcpy » en tête — en réalité des minor faults sur un tas frais. Chaque page 4 Kio touchée la première fois coûte quelques microsecondes ; sur 300 Mo, ~75 000 faults. MADV_POPULATE_WRITE ne rend pas le memcpy plus cheap en absolu : il déplace les faults hors du chemin critique (préchauffage pendant que le chunk précédent arrive du disque). HUGETLB (pages 2 Mio) divise le nombre de faults et améliore le TLB. Résultat interne Conviva : le plus gros gain end-to-end, une fois le ring correct, n’était pas io_uring — c’était la stratégie mémoire une fois qu’on quitte le page cache du noyau.
Leçon Atelier. Séparer observation (métriques, traces de soumission / complétion) et contrôle (thread I/O minimal, arène préchauffée). Passer à io_uring + O_DIRECT, c’est accepter de posséder ordonnancement, cache et politique mémoire que le noyau gérait sous mmap. Sans couche de mesure isolée et sans stratégie de pages explicite, le ring seul ne sauve rien — il peut même perdre face à mmap.
Cloudflare ADLC : @cloudflare/ci sur Workflows + Trust Ratchet
InfoQ (21.09) : Cloudflare présente l’Agent Development Lifecycle — CI/CD portée par Workflows via @cloudflare/ci, observabilité OpenTelemetry dédiée aux agents, et Agent Access Model : credentials courts, liés à la tâche, avec « Trust Ratchet » qui réduit les capacités dès qu’une ressource protégée est touchée.
Après 23.1.1 (8.09), qui corrigeait la casse d’ABI LLDB SB API sur GetValueForVariablePath (modes DIL déplacés vers GetValueForVariablePathWithMode), la 23.1.2 était annoncée pour le mardi 22 septembre. Le tag llvmorg-23.1.2 est sorti ce matin sur GitHub (publication vers 08:49 Europe/Zurich).
