00:00:00Ralph Wiggum est en train de tout casser. On a fait une vidéo à ce sujet l'année dernière et depuis,
00:00:04tout le monde ne parle plus que de ça sur Twitter. Matt Pocock a sorti plein de vidéos
00:00:09sur le sujet, Ryan Carson a écrit un article très populaire et Razmike a approfondi l'idée
00:00:13avec son script Ralphie Bash. Mais est-ce qu'on s'y prend tous mal ? Le créateur a déjà affirmé
00:00:19que certaines implémentations sont incorrectes.
00:00:21Alors, quelle est la bonne méthode ? Et pourquoi Ralph est-il actuellement la meilleure façon de coder
00:00:26avec l'IA ? Abonnez-vous et découvrons cela ensemble.
00:00:30La boucle Ralph a été créée par Jeff Huntley et documentée dès juin de l'année dernière.
00:00:35Il s'agit essentiellement d'une boucle bash qui soumet à un agent IA exactement le même prompt
00:00:40encore et encore. C'est du génie à plusieurs niveaux car cela permet à l'IA de travailler
00:00:46dans son mode le plus intelligent : celui où elle a le moins de contexte possible. Regardez.
00:00:51Imaginons que ceci soit la fenêtre de contexte totale d'un agent. De 0 à environ 30 %,
00:00:57c'est ce qu'on appelle la "zone intelligente", là où l'agent est le plus performant. De
00:01:0130 à 60 %, il reste efficace. Mais à partir de 60 %, donc 60, 70, 80, 90,
00:01:08ses performances se dégradent. C'est la "zone bête". Bien sûr, ces chiffres ne sont pas
00:01:12gravés dans le marbre et varient selon les modèles. La zone intelligente peut aller jusqu'à
00:01:1640 ou 50 %, mais au-delà de 80 % de la fenêtre, c'est là que les erreurs commencent.
00:01:21Pour Claude Sonnet ou Opus, la fenêtre de contexte typique est de 200 000 tokens. On peut
00:01:28dire que les 60 premiers k sont la zone intelligente. Les 60 k suivants sont corrects, mais moins bons.
00:01:33Et pour les 80 k restants, les performances chutent. C'est mon expérience personnelle
00:01:38avec ce modèle, la vôtre peut être différente. La raison
00:01:43est que le modèle est dit "autorégressif" : il doit analyser les
00:01:47tokens précédents pour prédire le suivant. S'il y en a énormément, il doit en
00:01:52parcourir beaucoup trop pour identifier les éléments cruciaux pour la tâche en cours.
00:01:56Concentrons-nous sur les premiers 30 %. Avant même d'écrire votre premier prompt,
00:02:01certains éléments sont ajoutés automatiquement au contexte. D'abord le "system prompt",
00:02:06puis les outils système. Sur un modèle Claude type, cela occupe 8,3 % et 1,4 % du contexte.
00:02:12Soit presque 10 % de ces 30 %. S'ajoutent ensuite les compétences (skills) et aussi
00:02:16vos outils MCP personnalisés. Enfin, si vous avez un fichier agent.md, il est aussi inclus.
00:02:21Plus ces éléments sont volumineux, plus ils consomment de tokens.
00:02:25Et tout cela se passe avant même d'avoir ajouté votre propre consigne. En général,
00:02:30il vaut mieux garder cette section aussi légère que possible. Moins d'outils, moins
00:02:35de compétences et un fichier agent.md concis pour que le modèle reste optimal.
00:02:40Pour visualiser ce que représentent 60 k tokens : le script entier du film Star Wars "Un nouvel espoir"
00:02:44compte environ 54 000 tokens dans GPT-5. C'est à peu près cette quantité.
00:02:51Vous vous demandez peut-être : et la compaction ? Est-ce que ça peut aider ? On en
00:02:56reparlera plus tard. Voyons d'abord comment Ralph aide concrètement.
00:03:00L'avantage de Ralph est de se focaliser sur un seul objectif par fenêtre de contexte. On peut
00:03:05dédier l'intégralité des 200 k tokens à une seule tâche. Pour cela,
00:03:10on écrit un prompt qui va d'abord inspecter le fichier plan.md. Celui-ci contient
00:03:15la liste des tâches à accomplir : créer le front-end, le back-end, la base de données, etc.
00:03:19C'est un exemple très général. Avec Ralph, on serait normalement bien plus détaillé
00:03:23et granulaire, mais restons sur cet exemple. Ce prompt va
00:03:28dire aux agents de choisir la tâche prioritaire, puis d'effectuer les changements.
00:03:33Ensuite, il doit lancer les tests, puis valider et pusher les modifications.
00:03:38Une fois terminé et les tests réussis, l'agent coche la tâche dans
00:03:42le fichier plan.md et recommence. L'agent cherchera systématiquement la tâche
00:03:46prioritaire jusqu'à ce qu'il n'y en ait plus. En fait, je rectifie :
00:03:52on peut laisser la boucle Ralph tourner indéfiniment, même si tout est fini.
00:03:57L'avantage, c'est qu'il peut trouver des bugs à corriger ou des fonctionnalités
00:04:02à ajouter qui n'étaient pas prévues. Si ça dérape, l'avantage de Ralph est que
00:04:08vous pouvez arrêter le processus à tout moment, ajuster le prompt et relancer.
00:04:12C'est extrêmement simple car tout s'exécute dans une seule boucle "while" en bash.
00:04:16Ici, le script fait un "cat" du prompt.md pour l'envoyer à l'agent et lance Claude
00:04:22en mode "YOLO". Évidemment, le vrai flag n'est pas "YOLO" mais
00:04:26"dangerously-skip-permissions", mais j'ai raccourci par manque de place.
00:04:31Ce qui rend Ralph spécial, c'est qu'il est hors du contrôle du modèle.
00:04:36Le modèle ne peut pas décider d'arrêter Ralph ; ça continue tout seul. Ainsi, on garantit que
00:04:41chaque nouvelle tâche ou chaque nouveau prompt démarre avec un contexte
00:04:46totalement vierge, comme si on venait d'ouvrir l'agent. Pas de compaction,
00:04:50rien n'est accumulé. Chaque tâche dispose du maximum de contexte et utilise
00:04:55le modèle dans son état le plus performant. La compaction, pour rappel,
00:05:01c'est quand l'agent analyse tous les tokens déjà écrits dans la fenêtre
00:05:05pour n'en garder que l'essentiel pour la suite. Il choisit ce qu'il "pense"
00:05:11être important, mais il peut se tromper. Par conséquent, la compaction
00:05:16peut faire perdre des informations critiques et casser votre projet. Bref,
00:05:21cette implémentation canonique nous aide à comprendre pourquoi les autres diffèrent.
00:05:27Regardons celle d'Anthropic : elle utilise une commande "slash" pour lancer Ralph,
00:05:33avec un nombre max d'itérations et une promesse de complétion. Le souci avec ce plugin
00:05:38Ralph Wiggum précis, c'est qu'il compacte les infos en passant à la tâche suivante.
00:05:43S'il termine une tâche et relance le prompt, au lieu de réinitialiser complètement
00:05:48le contexte, il compacte ce qui a été fait, risquant de perdre des données vitales.
00:05:54Avoir un max d'itérations peut aussi être contraignant, car il est parfois
00:05:59utile de laisser Ralph tourner. Il peut dénicher des solutions surprenantes auxquelles
00:06:04on n'aurait jamais pensé. Et en restant observateur (le "human in the loop"),
00:06:08on peut repérer des schémas de comportement du modèle pour affiner le prompt initial.
00:06:14Si on regarde l'approche de Ryan Carson pour la boucle Ralph, on voit qu'elle
00:06:19n'est pas tout à fait canonique car à chaque itération, elle peut
00:06:24modifier ou enrichir le fichier agent.md. Selon le system prompt
00:06:29ou vos propres consignes, les modèles peuvent être très bavards.
00:06:33Si vous alimentez agent.md à chaque tour, et que ce fichier est réinjecté
00:06:39au début de chaque prompt utilisateur, vous saturez inutilement le contexte,
00:06:44poussant le modèle vers cette fameuse "zone bête".
00:06:48Mais le fait que chacun crée ses propres scripts à partir de cette base en bash
00:06:53prouve à quel point le concept est simple et accessible. Même s'il existe une
00:06:57méthode canonique, c'est une bonne chose que les développeurs et les entreprises
00:07:03l'adaptent à leurs besoins. Par exemple, j'adore le fait que dans le script Ralphie de
00:07:08Raz Mike, on puisse lancer des Ralphs en parallèle ou utiliser l'outil de
00:07:13navigation de Vercel pour faire des tests de navigateur. Dans la version de
00:07:18Matt Pocock, il ajoute les tâches sous forme d'issues GitHub ; la boucle Ralph
00:07:23sélectionne la plus importante, la traite et la marque comme terminée avant de passer
00:07:28à la suivante, ce que je trouve très ingénieux. La puissance et la simplicité de Ralph
00:07:32vont le faire durer longtemps. On va sûrement voir beaucoup d'améliorations.
00:07:37J'aime beaucoup la direction que prend Jeffrey avec son projet Loom and Weaver,
00:07:42qui vise à créer des logiciels de manière autonome et fiable. Mais avec tous ces
00:07:47Ralphs créant du code en autonomie, il faut pouvoir détecter et corriger les erreurs.
00:07:52C'est là qu'intervient Better Stack : il peut ingérer les logs et filtrer les erreurs,
00:07:56mais aussi assurer le suivi des erreurs côté front-end. Avec ce serveur MCP,
00:08:01vous pouvez demander à l'agent de cibler précisément les erreurs front ou back
00:08:06au lieu de lire tout le log, ce qui réduit considérablement la consommation
00:08:11de contexte.
00:08:16Allez jeter un œil à Better Flux et dites-moi ce que vous en pensez en commentaire.
00:08:17So go and check out Better Flux, and let me know what you think in the comments.