Recherche Automatique Avec Claude Code : La Boucle Karpathy Qui Tourne Pendant Que Vous Dormez

Andrej Karpathy a poussé un script Python de 630 lignes sur GitHub le 7 mars 2026. Il est allé se coucher. Quand il s'est réveillé, son agent IA avait exécuté plus de 100 expériences de machine learning, découvert 20 optimisations qui fonctionnaient réellement, et compilé les résultats dans un journal propre — le tout sans une seule frappe humaine pendant la nuit. Le dépôt a atteint 25 000 étoiles en cinq jours. Le PDG de Shopify, Tobi Lutke, l'a pointé vers leur moteur de templates et a obtenu un rendu 53 % plus rapide grâce à 93 commits automatisés. Et soudain, un concept qui circulait dans les cercles de recherche en IA — la boucle d'amélioration autonome — avait un nom dont tout le monde pouvait se souvenir : auto research. J'observe tout cela depuis mon terminal Claude Code. Et ce qui m'enthousiasme, ce ne sont pas les expériences de ML. C'est ce qui se passe quand on prend le même schéma — changer une chose, mesurer le résultat, garder ou écarter, répéter — et qu'on le dirige vers des problèmes business. Conversions de landing pages. Objets d'e-mails. Textes publicitaires. Mises en page de pages de tarifs. Tout ce qui a un chiffre attaché. C'est la version que Jack Roberts a récemment détaillée dans un walkthrough complet, et c'est la version que je teste depuis deux semaines. Les résultats ne sont pas aussi spectaculaires que ceux de Karpathy — je n'entraîne pas de modèles de langage la nuit. Mais je regarde Claude améliorer de façon autonome mes textes de conversion via une boucle structurée qui tourne chaque semaine sans que j'y touche. Et les mathématiques composées de tout ça sont véritablement saisissantes. Voici comment l'ensemble du système fonctionne, comment j'ai configuré le mien, et les erreurs précises que j'ai commises pour que vous ne les répétiez pas.

Le Modèle Mental : Pourquoi 1 % Composé Donne 37x

Avant de toucher à la moindre ligne de code, vous devez intérioriser pourquoi cette approche fonctionne — car l'instinct de la plupart des gens est erroné. L'essentiel de l'optimisation se fait par à-coups. On refait une landing page tous les six mois. On réécrit les séquences d'e-mails une fois par trimestre. On met à jour les textes publicitaires quand les performances s'effondrent. Entre ces à-coups ? Rien ne change. On fait tourner les mêmes textes, la même mise en page, les mêmes titres pendant des semaines ou des mois. L'auto research inverse ce modèle. Au lieu de grands changements peu fréquents, on fait de petits changements continus. Et les mathématiques de l'amélioration continue sont contre-intuitives. Une amélioration de 1 % par jour — composée sur un an — ne donne pas un gain de 365 %. Elle donne un gain de 37x. C'est 1,01 élevé à la puissance 365. James Clear a popularisé cela dans Atomic Habits, mais Karpathy en a fait un patron d'ingénierie. La boucle d'auto research est le mécanisme qui rend l'amélioration composée mécanique plutôt qu'aspirationnelle. L'inverse est tout aussi brutal. Un déclin de 1 % par jour composé aboutit à une perte de 97 %. La stagnation n'est pas neutre — c'est une érosion lente pendant que vos concurrents itèrent autour de vous. Le chiffre de 37x est théorique. Vous ne maintiendrez pas des améliorations de 1 % par jour sur une seule métrique indéfiniment. Les rendements décroissants sont réels. Mais le schéma d'itération automatisée continue ? C'est là que réside la percée. Même une amélioration moyenne de 0,1 % par itération, deux fois par semaine, produit des gains significatifs sur un trimestre. Et le point crucial : c'est l'IA qui gère l'itération, pas vous. L'histoire du WD-40 illustre parfaitement cela. Le produit tient son nom du fait qu'il a fallu 40 tentatives pour trouver la bonne formule de déplacement d'eau. Quarante itérations. La plupart des gens auraient abandonné à cinq. L'auto research élimine la tendance humaine à abandonner trop tôt en rendant chaque itération quasi gratuite. Voilà pour la théorie. Voici à quoi ressemble le système réel.

Trois Composants, Une Boucle : L'Architecture Auto Research

Le framework d'auto research — que vous l'appliquiez à l'entraînement ML comme Karpathy ou aux métriques business comme moi — se réduit toujours à trois composants : Une chose à changer. Une seule variable ou élément que vous êtes prêt à laisser Claude modifier. Un titre. Le texte d'un bouton CTA. Un objet d'e-mail. L'ordre des avantages d'une page de tarifs. Pas cinq choses à la fois — une chose. L'isolation est importante car si vous changez trois variables et que les performances s'améliorent, vous ne savez pas quel changement l'a causé. Une métrique à mesurer. Un chiffre objectif et quantitatif qui vous dit si le changement a aidé ou nui. Taux de conversion. Taux de clics. Taux de rebond. Taux d'ouverture. Pas des "impressions." Pas "ça semble mieux." Un chiffre. Une méthode pour lire les résultats. Un moyen pour Claude d'accéder réellement aux données de performance sans que vous les copiez manuellement dans un prompt. C'est là que la plupart des gens bloquent, et je vous montrerai la solution que j'ai trouvée dans la section implémentation. La boucle elle-même est d'une simplicité redoutable :

1. Claude lit les données de performance actuelles (le "contrôle")
2. Claude génère une variante (le "challenger")
3. Vous déployez le challenger
4. Attendre que les données s'accumulent
5. Claude lit les nouvelles données de performance
6. Si challenger > contrôle → le challenger devient la nouvelle baseline
7. Si contrôle > challenger → revenir en arrière, essayer une autre approche
8. Répéter depuis l'étape 1

C'est de la logique d'A/B testing, mais avec l'IA qui gère les étapes 1, 2, 5, 6, 7 et 8 de façon autonome. Votre travail se réduit à l'étape 3 (déployer le changement) et l'étape 4 (attendre). Et avec les bons outils — l'automatisation navigateur de Claude Co-work, par exemple — même le déploiement peut être automatisé. Le dépôt original de Karpathy implémente cela pour l'entraînement ML. Ses trois fichiers correspondent directement à ce framework :

• prepare.py — Préparation de données fixe et utilitaires. L'agent n'y touche jamais. C'est la fondation stable.
• train.py — Le seul fichier que l'agent modifie. Contient l'architecture du modèle, les hyperparamètres, l'optimiseur et la boucle d'entraînement. Tout peut être modifié.
• program.md — Le fichier d'instructions. Indique à l'agent quoi optimiser, comment mesurer le succès et quelles contraintes respecter. L'agent modifie train.py, exécute un cycle d'entraînement de 5 minutes, vérifie si la perte de validation s'est améliorée, conserve ou écarte le changement, et recommence. En deux jours, l'agent de Karpathy a exécuté 700 expériences et trouvé 20 optimisations authentiques. Quand ces 20 ajustements ont été appliqués à un modèle plus grand, la vitesse d'entraînement s'est améliorée de 11 %. La version business suit la même structure — des fichiers différents, le même schéma. Laissez-moi vous montrer comment je l'ai adapté.

Mettre en Place Votre Environnement Auto Research

Je vais décrire la configuration que j'utilise réellement, pas un idéal théorique. Certaines choses sont bricolées. Ça fonctionne.

Étape 1 : Définissez Votre Métrique et Créez un Fichier de Contexte Business

Choisissez une métrique. J'ai choisi le taux de clics sur un bouton CTA de landing page parce que la boucle de feedback est rapide (j'ai assez de trafic pour des lectures hebdomadaires) et la variable est isolée (texte du bouton et contexte environnant). Créez ensuite un fichier business.md qui donne à Claude le contexte nécessaire pour prendre des décisions intelligentes. C'est la partie que la plupart des gens sautent, et c'est la partie qui compte le plus. Sans contexte business, Claude génère du texte marketing générique. Avec, Claude génère du texte qui correspond réellement à votre audience. Voici une version simplifiée du mien :

# Business Context
## Who We Are
Ramlit Limited — software development agency serving B2B clients.
Primary service: custom web application development.
Average project size: $15K-$50K.
## Target Audience
- CTOs and engineering leads at mid-size companies (50-500 employees)
- Evaluating build-vs-buy for internal tools
- Pain points: slow development cycles, technical debt, unreliable freelancers
## Current Landing Page Performance
- Monthly visitors: ~2,400
- Current CTA click-through rate: 3.2%
- Primary CTA: "Get a Free Quote"
- Traffic sources: 60% organic, 25% referral, 15% direct
## Brand Voice
Professional but direct. No buzzwords. Results-focused.
Reference tone: ramlit.com existing copy.
## Constraints
- Do not change the core value proposition
- Do not use urgency tactics ("limited time", "act now")
- Keep CTA under 6 words
- All changes must maintain professional tone

Plus votre fichier de contexte est spécifique, plus les suggestions de Claude deviennent pertinentes. J'ai appris cela de mon travail sur les systèmes IA auto-améliorants — la qualité du document de contexte détermine directement la qualité de l'output de l'IA. Un contexte générique produit des résultats génériques.

Étape 2 : Mettez en Place Votre Pipeline de Données

C'est là que ça devient sérieux — et là où la plupart des configurations d'auto research échouent. La version de Karpathy a la vie facile. La métrique (perte de validation) est calculée par le script d'entraînement lui-même. L'agent exécute le script, lit la sortie et sait immédiatement si les performances se sont améliorées. Propre, contenu, pas de dépendances externes. Les métriques business ne sont pas aussi nettes. Vos données de conversion vivent dans Google Analytics. Ou Stripe. Ou un tableau de bord de plateforme qui n'a pas d'API. Obtenir ces données dans un format que Claude peut lire est le premier vrai défi technique. J'ai testé trois approches : Option A : Intégration API directe. Si votre plateforme d'analytics a une API (Google Analytics 4, Mixpanel, Amplitude), vous pouvez écrire un script qui récupère la métrique pertinente et la déverse dans un fichier que Claude peut lire. C'est l'approche la plus propre mais nécessite un peu de configuration.

# Example: Pull GA4 data into a metrics file
from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import RunReportRequest
import json
from datetime import datetime
client = BetaAnalyticsDataClient()
request = RunReportRequest(
    property=f"properties/YOUR_PROPERTY_ID",
    dimensions=[{"name": "pagePath"}],
    metrics=[
        {"name": "screenPageViews"},
        {"name": "conversions"},
    ],
    date_ranges=[{"start_date": "7daysAgo", "end_date": "today"}],
)
response = client.run_report(request)
# Format for Claude consumption
metrics = {
    "date_pulled": datetime.now().isoformat(),
    "period": "last_7_days",
    "landing_page": "/services",
    "pageviews": int(response.rows[0].metric_values[0].value),
    "conversions": int(response.rows[0].metric_values[1].value),
    "conversion_rate": round(
        int(response.rows[0].metric_values[1].value)
        / int(response.rows[0].metric_values[0].value) * 100, 2
    )
}
with open("metrics/current_performance.json", "w") as f:
    json.dump(metrics, f, indent=2)

Option B : Automatisation navigateur avec Claude Co-work. Quand les APIs ne sont pas disponibles — et pour un nombre surprenant de plateformes, elles ne le sont pas — Claude Co-work peut scraper les données du tableau de bord directement. J'ai couvert cela dans mon article sur les tâches planifiées Claude Co-work. Vous configurez une tâche planifiée qui ouvre votre tableau de bord analytics, lit les chiffres pertinents et les écrit dans un fichier ou une page Notion. Option C : Assistée manuellement (la version honnête). Pendant mes deux premières semaines, j'ai simplement copié les chiffres dans un fichier metrics.json chaque lundi matin. Ça prenait 90 secondes. Pas glamour. Mais ça m'a permis de valider la boucle elle-même avant d'investir du temps dans l'automatisation. Ne laissez pas l'infrastructure parfaite vous empêcher de commencer. J'ai commencé avec l'Option C et suis passé à l'Option B après le premier mois quand j'ai confirmé que la boucle produisait de vrais gains. Si vous débutez, faites pareil. Automatisez le pipeline de données après avoir prouvé que la boucle d'optimisation fonctionne.

Étape 3 : Créez Votre Fichier Programme

C'est votre program.md — l'ensemble d'instructions qui dit à Claude comment faire tourner la boucle. Voici la structure que j'utilise :

# Auto Research: Landing Page CTA Optimization
## Objective
Improve the click-through rate on the /services landing page CTA.
## Current Baseline
- Control CTA: "Get a Free Quote"
- Control CTR: 3.2% (last 7 days, from metrics/current_performance.json)
## Rules
1. Read the current metrics from metrics/current_performance.json
2. Read the business context from business.md
3. Analyze why the current CTR might be underperforming
4. Generate ONE challenger variant — a new CTA copy and 2-3 sentences
   of surrounding context
5. Explain WHY you expect the challenger to outperform (hypothesis)
6. Write the challenger to variants/challenger_[date].md
7. After deployment and data collection, compare challenger vs control
8. If challenger wins: update baseline in this file
9. If control wins: log the failed hypothesis and try a different approach
## Change Constraints
- CTA must be under 6 words
- Surrounding copy changes limited to the 3 sentences nearest the CTA
- No urgency language, no discount offers
- Maintain professional B2B tone
## Experiment Log
| Date | Variant | Hypothesis | Result | CTR |
|------|---------|-----------|--------|-----|
| Baseline | "Get a Free Quote" | — | Control | 3.2% |

Le journal d'expériences en bas est critique. Il donne à Claude une mémoire d'une itération à l'autre. Sans lui, l'agent pourrait suggérer le même changement deux fois ou ne pas tirer les leçons des échecs précédents. Chaque fois que la boucle tourne, Claude lit le journal, voit ce qui a été essayé, ce qui a marché et ce qui n'a pas marché — puis génère une variante qui s'appuie sur ces connaissances accumulées.

Étape 4 : Configurez la Fréquence de la Boucle

À quelle fréquence la boucle devrait-elle tourner ? Cela dépend de votre trafic et de la vitesse de feedback. Pour ma landing page avec ~2 400 visiteurs mensuels, des itérations hebdomadaires me donnent assez de données pour mesurer des différences significatives. Les sites à fort trafic (10 000+ visiteurs quotidiens) pourraient tourner quotidiennement. Les campagnes e-mail pourraient tourner par envoi. La contrainte clé : vous avez besoin de suffisamment de données entre les itérations pour distinguer le signal du bruit. Si vous testez un changement de CTA et que seulement 50 personnes le voient avant la prochaine itération, vos données n'ont aucun sens. Attendez la significativité statistique — ou au moins la significativité pratique. J'ai configuré le mien comme une tâche planifiée hebdomadaire dans Claude Co-work. Chaque lundi à 8h, Claude lit les dernières métriques, compare avec le contrôle de la semaine précédente et génère le prochain challenger si les données sont concluantes. Si vous êtes curieux au sujet de la mécanique de planification, je détaille la configuration exacte de Claude Co-work dans mon guide d'automatisation des tâches planifiées. La version courte : vous créez une tâche planifiée dans le panneau Co-work, vous la pointez vers votre répertoire de projet et vous configurez la récurrence.

Ce Qui S'est Réellement Passé Quand J'ai Fait Tourner Ça Pendant Deux Semaines

C'est ici que j'arrête de parler théorie et que je vous montre la réalité. Y compris les parties embarrassantes. Semaine 1 : La Baseline Métriques de départ : 3,2 % CTR sur "Get a Free Quote." 587 pages vues. 19 clics sur le CTA. Claude a lu le contexte business, analysé la baseline et généré son premier challenger :

CTA Challenger : "See What We'd Build For You" Hypothèse : Le CTA actuel implique une interaction commerciale transactionnelle ("devis"). L'audience cible (CTOs, responsables techniques) est en mode évaluation, pas en mode achat. Reformuler le CTA comme une invitation à voir une solution sur mesure réduit l'engagement perçu et augmente la curiosité. J'ai changé le texte du CTA lundi après-midi. Ça a pris deux minutes dans le CMS. Résultats Semaine 1 : 612 pages vues. 27 clics. 4,4 % CTR. Une amélioration de 37,5 % par rapport à la baseline. Ma réaction immédiate a été la méfiance. Une hausse de 37,5 % en changeant cinq mots ? Ça semblait trop élevé. Ça pouvait être du bruit. Ça pouvait être un mix de trafic différent cette semaine-là. Je l'ai noté et je suis passé à autre chose. Semaine 2 : Le Challenger Trop Confiant Claude a lu les résultats de la Semaine 1, noté l'amélioration et est devenu — je vais anthropomorphiser ici — ambitieux. La suggestion suivante : CTA Challenger : "Your Custom Build Starts Here" Hypothèse : En s'appuyant sur le succès du cadrage de personnalisation ("What We'd Build For You"), cette variante ajoute un élan vers l'avant ("Starts Here") tout en maintenant un faible engagement. Le possessif "Your" renforce la psychologie de propriété. Hypothèse raisonnable. Je l'ai déployé. Résultats Semaine 2 : 591 pages vues. 22 clics. 3,7 % CTR. Mieux que la baseline originale, mais moins bien que le challenger de la Semaine 1. Donc Claude est revenu au gagnant de la Semaine 1 ("See What We'd Build For You") comme nouvelle baseline, a enregistré l'expérience ratée et a noté dans le journal d'expériences : "Le cadrage possessif + langage d'action a moins bien performé que le cadrage de curiosité. La prochaine itération devrait explorer des variations de l'approche curiosité plutôt que de basculer vers le langage d'action." Cette note — cette analyse auto-corrective — est ce qui distingue l'auto research d'un humain faisant des tests A/B. Je n'aurais pas écrit cette synthèse. J'aurais regardé le chiffre, pensé "ça n'a pas marché," et je serais passé à autre chose sans en extraire la leçon. Claude capture systématiquement pourquoi quelque chose a échoué et l'utilise pour orienter la tentative suivante. Les Résultats Courants Après Deux Semaines : | Semaine | CTA | CTR | vs. Baseline | |------|-----|-----|-------------| | 0 (Contrôle) | "Get a Free Quote" | 3,2 % | — | | 1 | "See What We'd Build For You" | 4,4 % | +37,5 % | | 2 | "Your Custom Build Starts Here" | 3,7 % | +15,6 % | | 3 (en cours) | "See What We'd Build For You" (revenu) | En cours | — | Deux itérations. Un gagnant, un perdant. Le système a appris des deux. Et ma nouvelle baseline est 37,5 % au-dessus de mon point de départ. Maintenant imaginez ça tournant pendant 26 semaines — six mois — avec l'effet composé où chaque variante gagnante devient le nouveau plancher. Ça, c'est l'auto research.

Le Dépôt Karpathy : Traduire les Expériences ML en Usage Business

Laissez-moi combler l'écart entre ce que Karpathy a construit et ce que vous utiliserez réellement, car les implémentations ont beau paraître différentes, le schéma est identique. Le dépôt autoresearch de Karpathy se concentre sur l'optimisation de l'entraînement de réseaux neuronaux. L'agent modifie les décisions d'architecture, les hyperparamètres, les configurations d'optimiseur — des choix techniques qui affectent une seule métrique : la perte de validation. La boucle de feedback entière est autonome. train.py tourne pendant 5 minutes, produit une valeur de perte, et l'agent décide s'il conserve le changement. Le dépôt a explosé (49 800+ étoiles GitHub au moment où j'écris) parce qu'il a démontré quelque chose que les gens avaient théorisé mais n'avaient jamais vu fonctionner proprement : un agent IA qui améliore véritablement un système par l'expérimentation autonome, pas uniquement par le prompting. Mais à moins que vous n'entraîniez des réseaux neuronaux, vous devez adapter le schéma. Voici la table de correspondance :

Le Problème de Données Dont Personne Ne Parle (Et Ma Solution)

Voici la vérité inconfortable sur l'application de l'auto research aux métriques business : la majorité de vos données importantes se trouve derrière des tableaux de bord qui n'ont pas été conçus pour un accès programmatique. Google Analytics a une API. Stripe a une API. Mais Skool ? Les données d'engagement détaillées de ConvertKit ? Votre tableau de bord WordPress ? Votre éditeur de thème Shopify ? La moitié des outils que les fondateurs utilisent réellement n'exposent pas les métriques dont vous avez besoin via des APIs propres. Jack Roberts a souligné exactement ce problème dans son walkthrough, et sa solution est la bonne : l'automatisation navigateur. Les capacités navigateur de Claude Co-work peuvent naviguer vers un tableau de bord, lire les chiffres et les écrire dans un fichier. Ce n'est pas élégant. Ce n'est pas une intégration en bonne et due forme. Mais ça fonctionne de façon fiable pour l'étape "lire la métrique" de la boucle. La configuration ressemble à ceci :

1. Créez une tâche Co-work qui navigue vers votre tableau de bord analytics
2. Connectez-vous avec des identifiants sauvegardés (ou, mieux, une session qui reste authentifiée)
3. Lisez la métrique spécifique sur la page — Claude peut identifier et extraire des chiffres depuis les interfaces de tableaux de bord
4. Écrivez la métrique dans un fichier JSON ou une page Notion que votre boucle principale d'auto research lit J'ai testé ça avec un tableau de bord Google Analytics et une base de données Notion. Claude Co-work a ouvert la page GA, trouvé le taux de conversion pour ma page cible, extrait le chiffre et l'a écrit dans une table Notion. Environ 45 secondes par exécution. Pas rapide, mais pour une cadence hebdomadaire ? Largement suffisant. Pour les plateformes qui nécessitent une navigation plus complexe — clics multiples, filtres déroulants, sélections de plages de dates — vous devrez être plus explicite dans les instructions de votre tâche Co-work. Décrivez chaque clic. Spécifiez l'élément avec lequel interagir. Plus vos instructions sont précises, plus l'automatisation est fiable. Si vous préférez que quelqu'un construise l'intégralité de ce pipeline de données et de cette boucle d'auto research à partir de zéro, j'accepte exactement ce type de projets d'automatisation IA. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD. Une alternative qui mérite d'être mentionnée : Google Sheets comme couche intermédiaire. Vous pouvez configurer une feuille Google qui importe des données de diverses sources (via des connecteurs intégrés, Zapier ou saisie manuelle), puis faire lire la feuille à Claude via l'API Google Sheets. C'est un adaptateur universel. Pas propre, mais universellement compatible.

Choisir la Bonne Métrique : Où l'Auto Research Fonctionne (et Où Non)

Toutes les métriques ne sont pas de bonnes candidates pour l'auto research. J'ai appris cela en essayant d'abord d'optimiser la mauvaise chose. Candidats à haute valeur :

• Taux de conversion des landing pages — Feedback rapide, métrique claire, variable isolée. Ma recommandation numéro un pour votre première boucle d'auto research.
• Taux d'ouverture des objets d'e-mail — Chaque envoi est une nouvelle expérience. Volume de données élevé si votre liste compte 1 000+.
• Taux de clics des textes publicitaires — Des plateformes comme Google Ads et Meta fournissent déjà la métrique. Vous avez juste besoin que Claude génère des variantes et lise les résultats.
• Taux de complétion de page de paiement — Impact business élevé, mesurable, et de petits changements de texte/mise en page peuvent faire bouger l'aiguille de façon significative.
• Taux d'adoption de fonctionnalités en SaaS — Si vous pouvez mesurer combien d'utilisateurs activent une fonctionnalité, vous pouvez optimiser le texte d'onboarding ou l'UI qui y mène. Candidats à faible valeur (à éviter pour l'auto research) :
• Rankings SEO — Le cycle de feedback est trop lent (semaines à mois). Trop de variables confondantes. Vous ne pouvez pas isoler ce qui a causé un changement de classement.
• Notoriété de marque — Pas quantifiable de façon significative pour des boucles d'itération.
• Scores NPS — Trop subjectifs et trop peu fréquents pour une itération rapide.
• Chiffre d'affaires — Trop haut niveau. Le CA est un résultat de nombreux intrants. Optimisez les intrants individuellement.
• Engagement sur les réseaux sociaux — Trop bruité. Les changements d'algorithme, l'aléatoire viral et l'humeur de l'audience faussent les données. La métrique idéale pour l'auto research possède quatre propriétés :

1. Volume élevé — Assez d'événements par cycle pour mesurer des différences
2. Feedback rapide — Résultats disponibles en jours, pas en mois
3. Variable isolée — Vous pouvez changer une chose et mesurer l'impact
4. Données accessibles — Vous pouvez lire la métrique de façon programmatique (ou via automatisation navigateur) Si votre métrique choisie ne remplit pas les quatre critères, choisissez-en une autre. La boucle ne fonctionne que si les données sont propres, rapides et attribuables.

La Qualité des Questions Compte Plus Que la Qualité des Réponses

C'est quelque chose que Jack Roberts a souligné et qui mérite sa propre section, car c'est l'insight le plus sous-estimé de tout le framework d'auto research. Quand vous écrivez votre program.md, vous ne donnez pas simplement des instructions à Claude. Vous définissez l'espace du problème. Et la qualité de cette définition du problème détermine le plafond de ce que Claude peut découvrir. Mauvaise définition du problème :

"Améliorer le taux de conversion de notre site web." Bonne définition du problème : "Améliorer le taux de clics sur le CTA de la page /services. L'audience cible sont des CTOs évaluant des décisions build-vs-buy. Le CTR actuel est de 3,2 % avec 600 pages vues hebdomadaires. Le CTA apparaît sous une section avantages et au-dessus d'un bloc de témoignages. Le trafic est à 60 % de recherche organique." La différence ? La seconde version donne à Claude assez de contexte pour former des hypothèses intelligentes. Il connaît l'état d'esprit de l'audience. Il connaît la structure de la page. Il connaît la source de trafic, ce qui donne des indices sur l'intention de recherche. Chacun de ces détails façonne les suggestions que Claude génère. J'ai constaté que passer 30 minutes à rédiger un business.md et un program.md approfondis produit de meilleurs résultats sur 10 itérations que passer 5 minutes sur un brief vague et lancer 50 itérations. Le contexte est un levier. Cela rejoint un principe plus large que j'ai observé dans tout mon travail avec Claude Code : le goulot d'étranglement n'est presque jamais la capacité de l'IA. C'est la capacité de l'humain à définir le problème précisément. L'auto research amplifie n'importe quel signal que vous lui donnez — donc si le signal est vague, vous obtenez une optimisation vague. Si le signal est précis, vous obtenez des gains précis.

Monter en Échelle au-delà d'une Seule Métrique : L'Architecture Multi-Boucle

Une fois que votre première boucle d'auto research fonctionne et produit des gains, la question naturelle est : puis-je faire tourner plusieurs boucles simultanément ? Oui. Mais avec prudence. Le risque avec plusieurs boucles d'optimisation simultanées, ce sont les effets d'interaction. Si vous optimisez le CTA de votre landing page et votre titre hero et votre section de témoignages en même temps, un changement dans l'un peut affecter la performance d'un autre. Votre amélioration du CTA pourrait ressembler à une régression parce que le changement de titre au-dessus a déplacé l'attention des utilisateurs. Mon approche : séquentielle, pas parallèle. Faites tourner une boucle jusqu'à ce qu'elle se stabilise (c'est-à-dire que les améliorations plafonnent et que les challengers ne battent plus le contrôle de façon constante). Puis verrouillez cette variable, définissez la version gagnante comme permanente et lancez une nouvelle boucle sur la variable suivante. Pour ma landing page, la séquence ressemble à ça :

1. Texte du CTA (en cours)
2. Titre hero (suivant)
3. Section preuve sociale (après stabilisation du titre)
4. Ordre du bloc avantages (en dernier) Chaque boucle tourne pendant 4-8 semaines avant que je passe à la variable suivante. Patient ? Oui. Mais cela préserve la clarté causale qui rend les données fiables. Si vous devez absolument faire tourner des boucles parallèles, faites-le sur des pages différentes ou des canaux différents. Optimisez le CTA de votre landing page et les objets de vos e-mails simultanément — ce sont des systèmes indépendants avec des métriques indépendantes. Simplement, n'optimisez pas deux éléments sur la même page en même temps.

Ce Que la Plupart des Gens Feront Mal

Je teste ça depuis deux semaines et je parle avec trois autres builders qui font la même chose. Voici les schémas que je vois échouer : Changer trop de variables par itération. La tentation de "faire mieux" en changeant cinq choses à la fois est forte. Résistez-y. Vous avez besoin d'isolation pour savoir ce qui fonctionne. Un changement. Une mesure. Une décision. Ignorer la significativité statistique. Si 50 personnes ont vu votre nouveau CTA et 3 ont cliqué (6 % CTR) contre 2 clics sur l'ancien (4 % CTR), ce n'est pas une différence significative. Vous avez besoin de suffisamment de volume de données par itération pour faire confiance au résultat. Pour les sites à faible trafic, cela signifie des cycles d'itération plus longs — hebdomadaires au minimum, bimensuels pour un trafic très faible. Utiliser des métriques subjectives. "La page semble mieux" n'est pas une métrique. "Le nouveau texte est plus conforme à la marque" n'est pas une métrique. La boucle d'auto research nécessite un chiffre. Si vous ne pouvez pas exprimer votre objectif sous forme de chiffre, la boucle ne peut pas optimiser pour lui. Sauter le contexte business. Faire tourner l'auto research sans fichier business.md revient à embaucher un rédacteur sans lui dire qui sont vos clients. Claude va générer quelque chose. Il ne va rien générer de particulièrement utile. Abandonner après la première itération ratée. Le challenger de la Semaine 2 dans mon test a moins bien performé que le gagnant de la Semaine 1. Si j'avais arrêté là, j'aurais raté l'apprentissage qui a éclairé l'approche de la Semaine 3. Les expériences ratées ne sont pas des échecs — ce sont des points de données qui réduisent l'espace de recherche pour l'itération suivante. L'agent de Karpathy a exécuté 700 expériences. Beaucoup ont empiré les choses. C'est le processus.

La Vue d'Ensemble : Pourquoi Cela Change Ma Façon de Penser l'Optimisation

Avant l'auto research, mon processus d'optimisation ressemblait à ça : avoir une idée, l'implémenter, vérifier les résultats deux semaines plus tard, oublier de vérifier, vérifier un mois après, ne plus me souvenir de ce que j'avais changé, recommencer. Après l'auto research, mon processus d'optimisation ressemble à ça : définir la métrique, définir les contraintes, laisser Claude faire tourner la boucle, consulter le journal d'expériences chaque semaine, n'intervenir que si quelque chose semble anormal. La différence de charge cognitive est énorme. Je ne dépense plus d'énergie mentale sur "que devrais-je tester ensuite ?" C'est le travail de Claude. Je dépense mon énergie mentale sur "le framework est-il correctement défini ?" — ce qui est une question bien plus puissante. Et l'effet composé est réel. Pas le théorique 37x. Mais une amélioration de 37,5 % en deux semaines sur une seule métrique, avec un système qui continuera d'itérer ? Projetez ça sur six mois. Même avec des rendements décroissants, l'impact cumulé sur une métrique business qui compte — conversions, clics, inscriptions — est significatif. Le schéma d'auto research n'est pas compliqué. Trois fichiers. Une métrique. Une boucle. La partie difficile n'est pas de le construire. La partie difficile est de choisir la bonne métrique, d'écrire un contexte précis et d'être assez patient pour laisser l'effet composé faire son travail. Karpathy a montré que ça fonctionne pour la recherche ML à une échelle qui a stupéfié l'industrie. La version business est plus lente, plus désordonnée et moins dramatique. Elle est aussi accessible à quiconque possède un abonnement Claude et une métrique qui lui tient à coeur. Commencez avec une métrique. Écrivez votre fichier de contexte ce soir. Mettez en place la boucle ce week-end. Puis laissez-la tourner pendant que vous dormez. Dans six mois, vous souhaiterez avoir commencé aujourd'hui — ou vous serez content de l'avoir fait.

Questions Fréquemment Posées

Qu'est-ce que l'auto research dans Claude Code ?

L'auto research est une boucle d'optimisation autonome où Claude Code teste itérativement des changements par rapport à une métrique mesurable, conserve les améliorations, écarte les échecs et répète. Andrej Karpathy a popularisé le schéma en mars 2026 avec son dépôt autoresearch sur GitHub, qui a exécuté 700 expériences ML en deux jours. Pour les applications business, le même schéma optimise les taux de conversion, les taux de clics et d'autres métriques quantifiables.

Ai-je besoin d'expérience en programmation pour mettre en place une boucle d'auto research ?

La gestion basique de fichiers et l'aisance avec un éditeur de texte suffisent pour une configuration assistée manuellement où vous copiez des métriques dans un fichier JSON chaque semaine. Pour une automatisation complète — intégrations API, scraping navigateur, tâches planifiées — vous aurez besoin de compétences intermédiaires en Python ou de familiarité avec les fonctionnalités d'automatisation navigateur de Claude Co-work. Les fichiers program.md et business.md sont du Markdown simple.

De combien de trafic ai-je besoin pour que l'auto research fonctionne ?

Vous avez besoin de suffisamment d'événements par cycle d'itération pour distinguer le signal du bruit. Pour l'optimisation de landing page avec des cycles hebdomadaires, 500+ pages vues par semaine est un minimum raisonnable. L'optimisation e-mail nécessite 1 000+ destinataires par envoi. Les tests de textes publicitaires fonctionnent avec des volumes plus faibles car les plateformes publicitaires offrent une mesure robuste. Les sites à faible trafic devraient utiliser des cycles bimensuels ou mensuels.

Puis-je faire tourner l'auto research sur plusieurs métriques en même temps ?

Faites tourner des boucles parallèles sur des systèmes indépendants — optimisez votre landing page et vos objets d'e-mail simultanément. Évitez les boucles parallèles sur la même page ou le même tunnel, car les changements sur un élément peuvent affecter la performance d'un autre, rendant impossible l'attribution des résultats. L'optimisation séquentielle avec une variable à la fois produit des données plus propres et plus fiables.

Quel est le lien entre le dépôt autoresearch de Karpathy et l'optimisation business ?

Le dépôt de Karpathy optimise l'entraînement de réseaux neuronaux en laissant un agent IA modifier train.py, exécuter un cycle d'entraînement, mesurer la perte de validation et conserver ou écarter les changements. La version business utilise le même schéma contrôle-vs-challenger mais remplace l'entraînement ML par des textes business, la perte de validation par le taux de conversion, et les sessions d'entraînement de 5 minutes par la collecte hebdomadaire de données. Le framework central — changer, mesurer, décider, répéter — est identique.

Travaillons Ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure tech ? Je serais ravi de vous aider.

• Fiverr (développements sur mesure et intégrations) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io