En mars 2026, Karpathy a publié autoresearch sur GitHub : un système où un agent IA tourne toute la nuit, modifie son propre code, teste, garde ce qui marche, jette ce qui rate. Et recommence. Tu programmes le programme qui se programme. Je t'explique le concept — et ce que tu peux en tirer, même si tu ne fais pas de recherche en IA.
program.md qui guide l'agent
Karpathy publie autoresearch en mars 2026 pour montrer une idée : les chercheurs en IA peuvent déléguer une partie de leur travail à des essaims d'agents IA qui font la recherche à leur place. Autoresearch, c'est la preuve de concept : tu donnes à un agent un mini-laboratoire, et il cherche tout seul comment faire mieux.
Concrètement : le repo contient un modèle GPT miniature qui s'entraîne en 5 minutes sur un seul GPU. L'agent IA peut modifier le code d'entraînement (architecture, optimiseur, hyperparamètres, tout), le lancer, voir si le résultat est meilleur, et décider de garder ou revert. Et boucler. Indéfiniment.
Les résultats publics sont parlants, sans être magiques : Karpathy a laissé tourner son agent pendant environ 48h sur un modèle taille depth=12. L'agent a retenu 20 changements additifs qui, une fois appliqués à un modèle plus gros (depth=24), ont réduit le Time-to-GPT-2 de 2h02 à 1h48 — soit ~11% plus rapide (source : tweet Karpathy, 9 mars 2026). C'est un gain réel mais borné — et obtenu sur un mini-modèle, donc à ne pas extrapoler naïvement à du GPT-4.
On parle beaucoup d'"IA qui code". Autoresearch va un cran plus loin : l'IA fait de la recherche. Elle pose des hypothèses, teste, apprend, itère. Karpathy n'est pas seul sur ce chantier :
Autoresearch s'inscrit dans ce mouvement : ce n'est pas un gadget isolé, c'est un pattern qui va se généraliser.
L'idée forte, c'est la simplicité. Seulement 3 fichiers importants dans tout le repo :
C'est le code que l'agent ne touche pas. Il prépare les données, le tokenizer, les utilitaires. C'est le cadre stable qui garantit que les expériences sont comparables.
Le seul fichier que l'agent a le droit de modifier. Il contient tout : l'architecture du modèle, l'optimiseur, la boucle d'entraînement, les hyperparamètres. Tout est libre. L'agent peut tout remettre en question.
Le fichier que toi tu édites. Tu y écris, en langage naturel, comment l'agent doit travailler : "Essaye différentes tailles de batch", "Garde uniquement si val_bpb est plus bas", "Fais des tests courts d'abord, longs ensuite". C'est là que tu mets ton intelligence.
Tu ne codes plus. Tu écris des instructions en français (ou anglais) pour un agent qui, lui, écrit le code. C'est ce que Karpathy appelle "writing the program that writes the program" — le même mouvement que son concept de Software 3.0. Ton vrai travail devient d'écrire un meilleur program.md, pas d'écrire du code Python.
train.pyval_bpb (bits per byte — plus bas = mieux)Tu te lèves le matin, tu lis le log. Tu as peut-être un meilleur modèle. Ou pas. Mais tu as des dizaines d'expériences que tu n'aurais jamais eu le temps de faire toi-même.
Beaucoup de gens te vendent en ce moment "ton agent qui tourne la nuit = +300% de résultats, tu dors, l'IA travaille, tu deviens riche". La vérité que je vois sur mes propres tests : tu vas passer 2-3 weekends à comprendre comment ça fonctionne, tu vas rater tes 10 premiers runs (métrique mal définie, budget mal calibré, agent qui boucle dans le vide), et tu auras peut-être 10 à 30% d'amélioration sur une tâche précise — pas 300%. Ça vaut toujours le coup parce que cette amélioration, une fois trouvée, elle tourne 24/7. Mais promets-toi de mesurer avant / mesurer après, sinon tu confondras le bruit et le signal.
Tu ne vas pas entraîner de modèle GPT. Mais le principe autoresearch s'applique à n'importe quel domaine où tu veux itérer. Voici 3 façons de l'appliquer à ton business.
Tu as un template de cold email. Au lieu de tester 2-3 variantes, tu écris un email-program.md qui dit : "Génère une variante de mon template, envoie à 10 prospects, mesure le taux de réponse. Si meilleur, garde. Sinon revert. Boucle 50 fois.". L'agent tourne 1 semaine, tu récupères un email qui peut être nettement meilleur que ton template de départ. Combien mieux ? Honnêtement : je ne sais pas à l'avance. Dans mon cas, j'ai gagné quelques points de taux de réponse. Ça peut être zéro chez toi si ton template est déjà bon, ou beaucoup plus si tu partais de loin.
Même principe. L'agent génère des variantes de ta landing, lance un split-test sur tes visiteurs réels, garde la meilleure, recommence. Plus tu as de trafic, plus vite tu apprends. Attention : tu auras rarement un résultat exploitable en-dessous de 1 000 visiteurs par variante — sinon c'est du bruit statistique, pas une vraie amélioration.
Tu veux comprendre un marché, une technologie, un concurrent. Tu écris un research-program.md qui dit : "Cherche 10 sources sur [sujet], résume, identifie les patterns, cherche 10 nouvelles sources sur les patterns, re-synthétise.". Tu laisses tourner la nuit. Tu as le lendemain un rapport que tu n'aurais jamais eu le temps de produire.
Je te partage ce que j'ai testé sur mes propres cas. Ce n'est pas une science, c'est un témoignage. Ton contexte (ta liste de prospects, ton trafic, ton sujet) va donner des résultats différents des miens. La seule règle universelle : mesure avant / mesure après. Sinon tu ne sais pas si ça a marché.
(1) Métrique mal définie : si ton agent ne sait pas bien mesurer le "meilleur", il tourne en rond. Sois très précis dans ton program.md sur ce qui compte. (2) Budget temps mal calibré : si tu lui donnes 5h par expérience, tu en auras 4 dans la nuit. Pense en nombre d'itérations, pas en heures totales.
Même si tu ne clones jamais ce repo, garde ces 3 idées :
Ton travail de plus haut levier aujourd'hui, ce n'est plus d'écrire du code. C'est d'écrire des instructions en langage naturel à des agents IA. Investis ton temps à maîtriser le "prompting avancé" — c'est le nouveau métier.
Dans autoresearch, prepare.py est intouchable (cadre). train.py est 100% libre (zone de jeu). Cette séparation est géniale. Applique-la à ton business : quels sont tes piliers non-négociables ? Et où laisses-tu l'expérimentation totale ?
Tu ne peux pas travailler 24/7. Un agent si. La vraie question : qu'est-ce que tu aimerais qu'il fasse pendant que tu dors ? Lance 3 loops cette semaine, tu verras.
J'adapte autoresearch à ma veille auto : un agent qui scanne mes sources, propose des angles d'article, en rédige 3 variantes, me choisis la meilleure au réveil. On en reparle dans un prochain tuto.
Tu n'as pas besoin de cloner le repo de Karpathy pour appliquer l'idée. Quatre outils accessibles qui font tourner la boucle "essai → mesure → ajuste" :
program.md bien écrit + une commande en boucle, et tu fais du "poor man's autoresearch" en 30 minutes.Commence simple : un program.md + Claude Code + une métrique mesurable. Passe à CrewAI ou LangGraph seulement si le cas l'exige vraiment.
Si tu veux tester le concept sans cloner le repo de Karpathy, commence simple : optimiser un cold email. Voici un program.md de 30 lignes que tu peux copier, coller dans Claude Code (ou Codex), et lancer dès aujourd'hui.
# program.md · Optimisation cold email ## Objectif Maximiser le taux de réponse d'un cold email B2B sur une liste de 50 prospects qualifiés. ## Variables à optimiser - Objet (max 60 caractères) - Hook (1re phrase, max 15 mots) - CTA (question finale, max 12 mots) - Longueur totale (viser 70 à 110 mots) ## Cadre fixe (ne pas modifier) - Signature, mon nom, mon contexte pro - Nom du prospect, nom de son entreprise - Bénéfice concret que je propose ## Boucle 1. Lire l'email actuel dans `email-v1.md` 2. Générer UNE variante qui change UNE seule variable 3. Envoyer à 10 prospects (via mon outil d'envoi) 4. Attendre 48h, mesurer le taux de réponse 5. Si taux > baseline → garder, continuer 6. Si taux < baseline → revert, essayer autre variable 7. Recommencer, 20 itérations max ## Métrique taux de réponse = (réponses reçues) / (emails envoyés) Baseline actuelle : 4% (à battre) ## Garde-fous - Jamais plus de 10 prospects par variante - Stop si 3 variantes consécutives sous baseline - Log chaque run dans `runs.md` (date, variable, taux)
Ce fichier est volontairement court. C'est ça le travail : écrire des instructions claires, mesurables, avec des garde-fous. Pas du code. L'agent fait le reste.
Les 2 premières semaines, mes program.md étaient trop vagues → l'agent partait dans tous les sens. Depuis que je force UNE variable modifiée à la fois + une métrique chiffrée + un garde-fou, les runs sont enfin exploitables. Si ton agent tourne dans le vide, c'est presque toujours ton program.md qui est flou, pas l'agent qui est en cause.
Une info obsolète, un chiffre qui a bougé, une source périmée ? Écris-moi à sagnier.jeremy@gmail.com · je corrige en 48h max et je note la date de MAJ en haut de l'article. Les retours terrain valent mille fois les articles — je lis tout, je réponds.
Je prépare un tuto pratique : comment adapter le concept d'autoresearch à ton cold email. Si tu ne veux pas manquer ça, inscris-toi à AI Playbook.
Voir les newsletters →