Karpathy publie autoresearch : des agents IA s'attaquent à la recherche en IA

En mars 2026, Andrej Karpathy a publié sur GitHub un petit projet open source, autoresearch. En octobre, le média chinois Jiqizhixin en a fait le point de départ d'une longue analyse de l'auto-amélioration récursive de l'IA, c'est-à-dire la situation où des modèles participent à la création des modèles suivants. Le dépôt reste modeste, mais sa mise en scène en dit long.

Un souvenir venu du futur

Le README ne s'ouvre pas sur un guide d'installation, mais sur une courte scène stylisée « venue du futur ». La recherche de pointe en IA y apparaît comme l'activité d'« ordinateurs de viande ». Ceux-ci avaient besoin de manger et de dormir, et se synchronisaient de temps en temps par « ondes sonores » lors d'une cérémonie appelée « réunion de groupe ».

Karpathy plaisante, mais la plaisanterie est juste. Il décrit la routine d'un laboratoire : une hypothèse, une modification du code, le lancement d'une expérience, la lecture des métriques, puis l'hypothèse suivante. Les modèles de langage et les agents de code savent déjà exécuter chaque étape de ce cycle. Si l'on relie ces étapes en boucle fermée, l'humain en sort peu à peu.

L'auto-amélioration récursive, un problème d'ingénierie

Pendant longtemps, l'auto-amélioration récursive a été discutée comme un scénario philosophique : un jour, un système deviendra assez intelligent pour s'améliorer lui-même, et tout s'enchaînera ensuite de façon exponentielle. Le titre de l'article de Jiqizhixin, « Quand l'IA commence à créer l'IA », propose un autre regard. Le processus se décompose en opérations étroites et vérifiables, et chacune est automatisée séparément : écriture du code, lancement des expériences, analyse des résultats.

Ici, ce sont les métriques, et non l'intuition, qui fixent l'échelle. L'agent a besoin d'un objectif clair, d'une boucle de vérification rapide et d'une protection contre l'auto-illusion, lorsqu'une amélioration sur le papier ne se traduit par aucun gain réel. Ce sont ces conditions qui déterminent où l'automatisation de la recherche fonctionnera en premier, et où elle butera sur un plafond.

Le fragment d'article disponible ne donne que peu d'informations :

• auteur du projet : Andrej Karpathy ;
• nom : autoresearch ;
• plateforme : GitHub, dépôt open source ;
• date de publication : mars 2026 ;
• cadrage : le chercheur humain comme étape historique, et non comme constante ;
• source de l'analyse : Jiqizhixin, article du 10 octobre 2026.

L'extrait disponible ne contient ni résultats chiffrés, ni benchmarks, ni description de l'architecture. Il ne permet donc pas d'évaluer l'efficacité du projet lui-même ; on ne peut juger que le cadre annoncé.

Pourquoi cela compte maintenant

Le projet de Karpathy est intéressant précisément parce qu'il est petit. L'automatisation de la recherche évoque d'ordinaire des laboratoires fermés et d'immenses clusters. Un dépôt ouvert, que l'on peut lire en une soirée, ramène le sujet sur un terrain pratique : n'importe quel développeur peut faire tourner une telle boucle sur sa propre tâche et voir où elle casse.

Les questions restent les mêmes. Qui vérifie les décisions de l'agent si le vérificateur est lui aussi un modèle ? Comment éviter d'optimiser la métrique au lieu de l'objectif ? Quelle part du calcul part dans des expériences qui ne donnent rien ? L'extrait ne répond à aucune d'elles, et c'est normal : le projet pose un cadre, il ne clôt pas le sujet.

Que faire côté équipes

Si vous construisez des produits ML ou des pipelines de recherche internes, il est utile de décomposer votre cycle d'expériences en étapes et de repérer celles qui sont formalisables : budget de lancement fixe, métrique univoque, reproductibilité. Ce sont ces étapes-là qu'il convient de confier aux agents en premier. Pour les autres, il faut un relecteur humain.

Il est aussi conseillé de lire le dépôt lui-même et le texte intégral de Jiqizhixin. On y trouve probablement des détails d'implémentation et des exemples qui ne figurent pas dans cet extrait. Il est raisonnable de ne tirer de conclusions sur la force réelle de l'approche qu'après l'avoir testée sur vos propres tâches.