En 2026, la stratégie IA gagnante se résume aux boucles

Il y a un paradoxe au coeur des discussions actuelles sur les agents IA. D’un côté, des équipes entières s’emploient à construire des orchestrateurs multi-agents avec routage dynamique, mémoire persistante vectorielle et pipelines de validation en cascade. De l’autre, trois projets open source accumulent des étoiles GitHub en faisant exactement le contraire : répéter, boucler, recommencer.

Ralph, RLM et autoresearch ne partagent pas la même cible. Mais ils partagent la même intuition : distribuer du calcul dans le temps plutôt que dans l’espace.

La boucle la plus simple du monde

La commande au coeur de Ralph tient en une ligne :

while :; do cat PROMPT.md | claude-code ; done

Chaque itération démarre avec un contexte vierge. Le modèle ne traîne aucune session précédente, aucun état corrompu, aucune hallucination accumulée au fil des échanges. Ce que la session précédente a appris ne disparaît pas pour autant : ça s’écrit dans AGENTS.md. Au tour suivant, le modèle lit ce fichier et repart avec cette mémoire distillée.

L’élégance tient dans la séparation des rôles. Le contexte de la session est jetable. La connaissance accumulée, elle, est persistante et explicite. L’échec d’une itération n’est pas un problème à masquer : c’est une donnée que l’on consigne. Si la boucle tourne dix fois, les sept succès améliorent le code, et les trois échecs documentent pourquoi certaines approches ne marchent pas.

Il faut être honnête sur ce point. Lors des premières utilisations intensives de Ralph sur des tâches de refactoring, environ trois itérations sur dix brûlaient des tokens sur des erreurs déjà rencontrées. La cause : un AGENTS.md mal structuré, avec des notes trop génériques pour guider la session suivante. La boucle est puissante, mais elle est aussi bête que le fichier qu’elle relit. La qualité des apprentissages consignés détermine directement le taux de convergence.

RLM : quand le modèle décide lui-même quoi lire

RLM part d’un constat différent. Les fenêtres de contexte géantes ne résolvent pas le problème de la lecture intelligente. Charger 10 millions de tokens dans un LLM, c’est lui demander de trouver une aiguille en agrandissant indéfiniment la botte de foin.

L’approche RLM retourne le problème. Le corpus entier reste dans des variables Python, hors du contexte du modèle. Le LLM écrit du code pour y accéder sélectivement, traite environ 50K tokens pertinents à la fois, puis peut se rappeler lui-même récursivement via llm_query() pour traiter d’autres segments.

Le chiffre qui a retenu l’attention de la communauté : GPT-5-mini avec RLM surpasse GPT-5 en configuration standard sur le benchmark OOLONG par un facteur supérieur à deux. Ce n’est pas une amélioration marginale. C’est un modèle moins capable qui bat un modèle plus capable parce qu’il utilise mieux son budget de calcul.

La structure sous-jacente ressemble à une boucle d’inférence sur des données partielles plutôt qu’à une inférence unique sur données complètes. Le modèle explore, décompose, agrège, puis décide lui-même quand il a suffisamment d’information pour s’arrêter. La récursivité n’est pas une complication architecturale : c’est la propriété qui permet à un petit modèle d’outperformer un grand.

Un point de friction subsiste. Les appels récursifs imbriqués peuvent se propager en cascade si l’on ne fixe pas une profondeur maximale explicitement. Sans garde-fou, une requête sur un corpus dense peut engendrer des dizaines d’appels llm_query() non planifiés, avec une explosion des coûts à la clé. La profondeur de récursion n’est pas optionnelle.

autoresearch : la boucle qui modifie son propre entraînement

autoresearch cible un niveau d’abstraction plus profond. L’agent ne modifie pas seulement du code applicatif : il modifie train.py lui-même, lance un cycle d’entraînement de cinq minutes, mesure si les métriques s’améliorent, et commit si c’est le cas. Sinon, il reset et recommence avec une hypothèse différente.

C’est du search dans l’espace des hyperparamètres et des architectures, mais orchestré par un LLM qui formule des hypothèses et interprète les résultats plutôt que par un grid search aveugle. La contrainte des cinq minutes n’est pas arbitraire : elle calibre l’exploration pour rester dans un budget temps raisonnable sur une seule machine.

La limitation est réelle et le projet ne la cache pas. Le budget de cinq minutes élimine mécaniquement les expériences lentes. Une modification architecturale qui nécessite vingt minutes de convergence ne sera jamais évaluée correctement. Le dispositif est conçu pour une seule machine : la parallélisation sur plusieurs noeuds n’est pas intégrée. Pour des tâches qui demandent des heures d’entraînement, autoresearch ne s’applique pas en l’état.

Ce qui reste valide, c’est le principe. L’agent garde une trace des hypothèses tentées et de leurs résultats. Chaque run rate échoué informe le suivant. La boucle converge parce qu’elle capitalise sur ses propres expériences plutôt que de recommencer de zéro à chaque itération.

Le fil commun : le calcul au moment de l’inférence

Ces trois systèmes sont souvent rangés dans des catégories différentes. Ralph est un outil de développement. RLM est une méthode de lecture de corpus. autoresearch est un framework d’exploration scientifique. Mais la mécanique profonde est identique dans les trois cas.

Plutôt que d’allouer tout le budget de calcul à un unique passage de haute qualité, ils distribuent ce budget sur plusieurs passages de qualité standard. C’est ce que la littérature appelle le test-time compute scaling : dépenser des tokens supplémentaires au moment de l’inférence pour améliorer la qualité du résultat, sans modifier les poids du modèle.

L’implication pratique est contre-intuitive. Il est souvent plus efficace de faire tourner GPT-4o-mini en boucle dix fois que GPT-4o une fois, si la tâche se prête à la décomposition itérative. Le modèle moins cher converge vers une meilleure solution parce qu’il a le droit de se tromper et de corriger.

Ce que la complexité architecturale ne peut pas acheter

Les pipelines multi-agents sophistiqués ont leur utilité. Pour des workflows qui nécessitent une spécialisation par domaine, une parallélisation réelle sur des tâches indépendantes, ou une gestion d’état complexe entre agents, l’architecture distribuée s’impose.

Mais pour une large fraction des tâches réelles - écrire du code correct, lire un corpus pour répondre à une question, explorer un espace de paramètres - la boucle simple avec contexte frais gagne sur la complexité. Pas parce que c’est plus élégant. Parce que chaque nouvelle itération repart d’un état propre, corrigé des erreurs précédentes, avec des instructions enrichies de ce qui a déjà été appris.

La question pertinente n’est plus “comment construire le pipeline le plus sophistiqué ?”. C’est “combien d’itérations puis-je me permettre, et comment faire en sorte que chacune soit meilleure que la précédente ?”.