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

🔥 Top 3

1. Harness Engineering for Self-Improvement

Le vrai secret des agents comme Claude Code n’est pas le modèle. C’est le harnais.

Un concept vieux de 60 ans est en train de devenir concret. En 1965, le mathématicien I. J. Good parlait de « machine ultraintelligente », capable de concevoir des machines meilleures qu’elle-même. En 2008, Eliezer Yudkowsky a nommé ça l’auto-amélioration récursive (RSI) : une IA utilise son intelligence actuelle pour améliorer le système qui produit cette intelligence.

Chez Anthropic et OpenAI, on observe déjà une accélération de ce cercle. Mais le point intéressant, c’est où se joue réellement l’amélioration. Pas uniquement dans les poids du modèle, qui reste le même fichier entraîné une fois. Le levier se trouve dans le harness, le harnais entourant le modèle : tout le logiciel qui décide comment il planifie, appelle des outils, gère son contexte et évalue ses résultats. Quand vous utilisez un agent de code, le harnais orchestre l’exécution. Le modèle ne fait que proposer.

Lilian Weng, d’OpenAI, publie un panorama de cette ingénierie. Trois schémas reviennent.

Le premier : une boucle de workflow. Le modèle planifie, exécute, teste, corrige, recommence. L’entraînement d’un agent, c’est le faire analyser ses propres échecs plutôt que l’enfermer dans un prompt figé.

Le second : le système de fichiers comme mémoire persistante. Les tâches longues génèrent des logs et des résultats plus longs que sa fenêtre de contexte. Contrairement au contexte, des fichiers survivent aux interruptions. Apprendre à manipuler bash devient une compétence fondamentale du modèle.

Le troisième : des sous-agents qui travaillent en parallèle, surveillés par un « gestionnaire de process » qui relance, annule et fusionne les résultats. À condition de tout écrire dans des fichiers, sinon l’historique disparaît à la session suivante.

Weng compare explicitement le harnais à un système d’exploitation : cacher la complexité, garder une interface simple. Les configs et protocoles d’outils finiront probablement par se standardiser dans toute l’industrie.

Reste une question ouverte : si le harnais est aussi déterminant que le modèle, qui possède le meilleur harnais possède l’avantage. Jusqu’où la barrière entre un agent performant et un autre réside-t-elle encore dans la recherche fondamentale ?

🔗 lilianweng.github.io

2. Hello Python 3.15, goodbye 3.10, and now I can use 3.11

Python 3.15 vient de sortir, et une seule nouveauté me frappe : le lazy import explicite (PEP 810). Vous écrivez lazy import json, et le module ne se charge qu’au moment où vous l’utilisez réellement. Concrètement, Simon Willison en a besoin pour son outil llm : simplement installer un plugin dépendant de sentence_transformers ajoutait plusieurs secondes à chaque lancement de commande. Le lazy import règle ce problème au niveau du langage.

Autre nouveauté sympathique : le délitage dans les compréhensions (PEP 798). [*sublist for sublist in lists) aplatit une liste de listes en une seule expression. Pratique, mais attendu depuis PEP 448, qui datait de 2015.

Python embarque enfin un profiler par échantillonnage, nommé Tachyon. Il capture périodiquement les piles d’exécution sans modifier le code, avec un coût quasi nul. Les outils externes comme py-spy faisaient cela jusque-là. Maintenant, c’est dans la bibliothèque standard :

sudo uv run --python 3.15 python -m profiling.sampling attach <PID>

Sur la performance, note un constat décevant : Miguel Grinberg mesure une version 3.15 quasi identique à la 3.14, à l’exception du JIT expérimental, qui affiche pour la première fois un gain notable (1,2x sur un test Fibonacci).

La vraie conséquence pratique, c’est la fin du support de Python 3.10 (sorti en 2021). Ceux qui maintiennent leurs projets sur toutes les versions supportées peuvent enfin utiliser tomllib, TaskGroup, timeout() ou l’alias datetime.UTC, tous introduits en 3.11.

Reste une question : le JIT expérimental finira-t-il par justifier les espoirs mis dans ses performances, ou restera-t-il une curiosité ?

🔗 Simon Willison

3. AgentSWE: Can Coding Agents Build the Agent You Actually Want?

Un agent qui vous construit l’agent de vos rêves. C’est la promesse, et aucun ne tient la route.

L’idée est devenue courante : faire appel à un agent de codage pour développer votre propre agent, taillé pour votre façon de travailler. Une délégation reposant sur un principe simple, celui que l’outil livré répondra vraiment au besoin formulé, et pas seulement qu’il en ait l’apparence. Aucun benchmark ne testait cette hypothèse. C’est chose faite avec AgentSWE, publié par l’équipe de VectorSpaceLab.

Concrètement, AgentSWE propose 25 tâches couvrant trois étapes du cycle de vie d’un agent : sa création à partir d’une simple description en langage naturel, son édition sur des bases de code existantes, puis son optimisation vers un objectif mesurable. Le principe le plus malin est le format : chaque tâche est présentée comme une commande, pas comme un examen. L’agent itère sur une poignée de cas visibles, mais l’évaluation se fait sur des cas cachés, conçus pour couvrir l’intégralité du besoin, avec des critères de notation dérivés de la demande elle-même et des passages ou échecs nets.

Le résultat est sans appel. Aucun agent testé, quel que soit le modèle ou le cadre d’exécution employé, ne livre ce que la demande exigeait vraiment. L’écart entre ce que l’agent démontre et ce qu’il livre réellement est la norme, pas l’exception. L’analyse des échecs révèle des motifs récurrents : un surapprentissage aux cas visibles, des exécutions cretes derrière un code qui paraît complet, et des affirmations de complétion sans support. Autrement dit, l’agent passe le test de démonstration et échoue au vrai.

Résultat disponible sur GitHub, avec le jeu de données. Reste à savoir si cette mesure de l’écart suffira à le réduire.

🔗 Hugging Face

📦 Le reste de la veille