LOOP ENGINEERING
/goal, /loop et routines Claude

Objectifs, automatisations et workflows d’IA de longue durée

Les boucles d’IA couvrent un large éventail de niveaux de complexité : Elles vont de systèmes expérimentaux, comme Auto Research d’Andrej Karpathy et le concept de « golf des paramètres », jusqu’aux fonctionnalités directement utilisables dans Claude Code et Codex : /goal, qui permet à une tâche de s’exécuter de manière autonome jusqu’à son achèvement, et /loop, qui déclenche des exécutions à intervalles réguliers, par exemple toutes les cinq minutes.

Les objectifs peuvent prendre en charge des tâches s’étalant sur plusieurs jours, comme :

Ces mécanismes font évoluer l’usage de l’IA : au lieu de multiplier les prompts ponctuels, il devient possible de construire des workflows durables, capables d’exécuter, de vérifier et d’organiser le travail dans le temps. Les synthèses produites peuvent également constituer une mémoire structurée, réutilisable par le système et favorable à une forme d’apprentissage continu.

Définition et enjeu

Les boucles transforment la manière de travailler avec les modèles de langage. Au lieu de formuler successivement des prompts pour relancer une tâche, elles permettent de définir un objectif, une fréquence d’exécution et, éventuellement, une durée. Le système poursuit alors le travail de manière répétée jusqu’au résultat attendu ou jusqu’à la fin de la période définie.

Cette logique couvre un large spectre : exploration d’un projet, expérimentation technique, traitement d’une tâche délimitée pendant plusieurs jours, automatisation d’activités récurrentes ou constitution progressive d’une mémoire exploitable par le modèle.

L’enjeu n’est donc plus seulement de savoir formuler une demande ponctuelle. Il consiste à concevoir un cadre de travail dans lequel un agent peut avancer, vérifier ses résultats, conserver les informations utiles et reprendre périodiquement une activité.

Les différents niveaux d’utilisation des boucles

De l’expérimentation autonome à la progression contrôlée

Une boucle peut servir à conduire des expériences successives à intervalles réguliers :

Auto Research d’Andrej Karpathy illustre cette logique appliquée à l’entraînement d’un modèle : différentes expériences sont réalisées, leurs résultats sont évalués et les approches efficaces sont prolongées. Parameter Golf constitue une autre manière d’explorer ce principe.

Le mécanisme ne se limite toutefois pas à la programmation ou à l’entraînement de modèles. Il peut s’appliquer à toute activité dans laquelle un système doit progresser par essais successifs, examiner les résultats obtenus et ajuster la suite du travail.

Le goal comme tâche longue orientée vers un résultat

Un goal correspond à une tâche de longue durée. L’objectif est défini une fois, puis le mécanisme intégré à l’environnement permet au modèle de continuer à travailler sans qu’il soit nécessaire de le relancer manuellement avec de nouveaux prompts.

Dans Claude Code ou Codex, il est possible d’exécuter goal, puis de décrire le résultat recherché. Cette approche constitue une expérience relativement simple : l’utilisateur formule la destination, tandis que le système prend en charge la continuité du travail.

Un goal peut fonctionner pendant plusieurs jours lorsque la tâche est suffisamment délimitée. La création de parseurs destinés à traiter des ensembles complexes de documents provenant de plusieurs sites constitue un exemple de tâche pouvant bénéficier de cette durée d’exécution.

Cette autonomie dépend néanmoins de la possibilité de vérifier le travail réalisé. Lorsqu’une tâche possède des résultats contrôlables, notamment au moyen de tests unitaires ou d’autres mécanismes de validation, le système peut déterminer plus précisément s’il progresse réellement vers l’objectif.

La commande de boucle comme déclenchement périodique

Claude Code propose également une fonction de boucle accessible avec /loop. L’intervalle peut être exprimé en langage naturel, par exemple :

Loop every 5 minutes

Cette instruction est complétée par la description du résultat recherché. Il est également possible de limiter l’exécution à une période déterminée :

Loop every 5 minutes for the next 3 hours

Une tâche planifiée est alors créée. Pendant la durée indiquée, elle déclenche périodiquement un événement dans le contexte du fil de travail du modèle. Cette périodicité apporte un élément déterministe : le système est réactivé aux moments prévus pour poursuivre l’exploration demandée.

La boucle est particulièrement adaptée aux travaux exploratoires, aux expérimentations et aux projets entièrement nouveaux. Une question volontairement large peut être confiée au système afin qu’il examine différentes directions.

Le comportement obtenu ressemble à celui d’un ingénieur junior ambitieux auquel une exploration serait déléguée. Certaines directions pourront sembler peu pertinentes, mais leur intérêt réel ne peut parfois être évalué qu’après observation des résultats. La diminution du coût de l’expérimentation et du code permet ainsi de tester des approches plus ambitieuses.

Le goal reste néanmoins présenté comme plus fiable pour certaines tâches longues, tandis que /loop répond davantage à un besoin de réactivation périodique et d’exploration.

Les automatisations récurrentes du travail quotidien

Les environnements comme Codex, Claude Code et Cursor disposent d’espaces consacrés aux automatisations. D’autres IDE proposent des fonctions comparables, généralement organisées autour des automatisations actives et des automatisations suspendues.

Leur intérêt apparaît lorsqu’une première automatisation accomplit quotidiennement une tâche réellement utile. Elle révèle alors d’autres activités mineures, répétitives et chronophages qui peuvent être progressivement déléguées.

Un exemple consiste à examiner une boîte de réception, à reporter son contenu sur un tableau Linear, puis à comparer quotidiennement les nouveaux messages et les éléments déjà enregistrés afin d’identifier les actions prioritaires.

Cette logique peut aussi exploiter les fichiers internes disponibles dans Codex ou Claude Code. À une fréquence déterminée, une automatisation peut créer un fichier agent.md pour un projet ou produire des skills correspondant aux activités réalisées pendant la semaine.

Elle peut également analyser périodiquement un projet pour rechercher des vulnérabilités de sécurité. Le même mécanisme s’applique aux tâches exécutées chaque jour, toutes les six heures ou une fois par semaine.

Le critère déterminant est la répétition : lorsqu’une activité est régulièrement effectuée sur un ordinateur, une partie importante de son traitement peut probablement être confiée à une automatisation.

Les boucles comme mécanisme de mémoire

Les automatisations peuvent aussi servir à construire une mémoire. Le système revient alors sur les événements de la journée et en produit une représentation synthétique, plus compacte, cohérente et accessible.

Ces informations peuvent être organisées selon un principe de divulgation progressive. Le modèle ne charge pas nécessairement toute la mémoire en même temps : il dispose d’éléments lui permettant de savoir où chercher lorsqu’un sujet particulier devient pertinent.

Cette organisation rend possible un apprentissage continu. Le système ne reste plus limité au préentraînement du modèle et aux capacités initiales de son environnement. Il peut explorer des tâches, conserver les résultats utiles et s’appuyer sur eux au fil du temps.

La boucle relie ainsi trois fonctions :

  1. exécuter une activité
  2. en extraire une représentation réutilisable
  3. puis mobiliser cette représentation lors d’un travail ultérieur.

Un système organisé de cette manière peut progressivement devenir plus utile dans plusieurs domaines.

Une autonomie graduée plutôt qu’un traitement intégral

Une automatisation n’a pas besoin de prendre en charge l’intégralité d’un processus. L’utilisateur peut rester dans la boucle et conserver la responsabilité des décisions sensibles ou des actions finales.

La rédaction d’e-mails illustre cette séparation. Le système peut préparer les messages sans les envoyer. Les propositions obtenues peuvent manquer d’une partie du contexte nécessaire pour déterminer précisément la réponse appropriée, mais elles restent utiles comme première base de travail.

Les prompts associés peuvent ensuite être améliorés progressivement à partir des résultats observés. L’automatisation devient donc elle-même un objet d’optimisation : son comportement est examiné, ses limites sont identifiées et ses instructions sont affinées.

Mise en pratique

  1. Choisir une activité délimitée. Commencer par une tâche dont le résultat attendu peut être décrit clairement, plutôt que par une responsabilité générale sans critère d’achèvement.
  1. Déterminer le mode d’exécution. Utiliser un goal pour poursuivre une tâche longue jusqu’à un résultat, une boucle pour réactiver périodiquement une exploration, ou une automatisation planifiée pour une activité récurrente.
  1. Définir la cadence. Fixer un intervalle cohérent avec l’activité : quelques minutes pour une expérimentation, plusieurs heures pour un contrôle récurrent, une journée ou une semaine pour une opération régulière.
  1. Prévoir une vérification. Donner au système un moyen de contrôler ses résultats. Pour une tâche technique, cette vérification peut notamment reposer sur des tests unitaires ou sur tout autre aspect objectivement vérifiable.
  1. Organiser les informations produites. Lorsque la boucle sert de mémoire, créer des représentations synthétiques, cohérentes et progressivement accessibles afin que le modèle puisse retrouver les éléments pertinents sans tout charger indistinctement.
  1. Conserver une validation humaine lorsque le contexte l’exige. Automatiser la préparation d’un e-mail ne suppose pas d’en automatiser l’envoi. La boucle peut produire une proposition tandis que l’utilisateur conserve la décision finale.
  1. Améliorer les instructions à partir des résultats. Examiner les sorties, identifier les erreurs de contexte ou les directions peu utiles, puis ajuster progressivement les prompts qui pilotent l’automatisation.

Le principe décisif

Le passage du prompt ponctuel à la boucle déplace le travail vers un niveau supérieur d’organisation. Il ne s’agit plus uniquement de demander au modèle d’exécuter une action, mais de définir un objectif, un rythme, une durée, un mécanisme de vérification et un degré d’autonomie.

Les formes d’exécution répondent à des besoins différents :

La méthode correcte consiste à commencer par une tâche bornée et vérifiable, à choisir une cadence adaptée, puis à conserver une intervention humaine là où le contexte ou la décision finale l’exige. L’erreur principale serait d’assimiler l’automatisation à une délégation intégrale et incontrôlée.

Une activité répétitive réalisée sur ordinateur constitue le meilleur point de départ. Lorsqu’elle peut être décrite, planifiée, contrôlée et partiellement déléguée, elle peut être transformée en boucle capable de faire progresser le travail sans multiplication des relances manuelles.