• claude code
• codex
• goal
• loop
• routines
• agents ia

Pendant longtemps, utiliser un agent IA consistait à enchaîner les prompts : une instruction, une réponse, une correction, puis une nouvelle instruction.

Le Loop Engineering modifie cette logique. Au lieu de piloter directement l’agent à chaque étape, l’utilisateur construit un système capable de relancer l’IA, de vérifier son travail et de décider quand la tâche est terminée.

Trois mécanismes illustrent cette évolution :

• /goal, pour poursuivre un objectif jusqu’à ce qu’une condition soit remplie ;
• /loop, pour répéter une action à intervalles réguliers ;
• les routines, pour exécuter durablement une tâche selon un calendrier ou un événement.

Ces mécanismes sont proches, mais ils ne répondent pas au même besoin.

Qu’est-ce que le Loop Engineering ?

Le Loop Engineering consiste à remplacer une succession manuelle de prompts par une boucle de travail autonome.

Une boucle élémentaire suit généralement ce cycle :

1. l’agent observe la situation ;
2. il choisit une action ;
3. il exécute cette action ;
4. il vérifie le résultat ;
5. il recommence si l’objectif n’est pas atteint ;
6. il s’arrête lorsqu’une condition précise est satisfaite.

L’utilisateur ne décrit donc plus nécessairement toutes les étapes. Il définit plutôt :

• le résultat attendu ;
• les ressources accessibles ;
• les contraintes à respecter ;
• la méthode de vérification ;
• la condition d’arrêt.

Le travail se déplace ainsi du prompt isolé vers la conception du système qui produit les prompts suivants.

Différence entre /goal, /loop et les routines

Mécanisme	Déclenchement	Condition d’arrêt	Durée	Utilisation principale
/goal	À la fin de chaque étape	Un résultat vérifiable est atteint	Jusqu’à réussite ou interruption	Terminer une tâche complexe
/loop	Selon un intervalle de temps	Arrêt manuel ou fin détectée	Tant que la session reste active	Surveiller ou vérifier régulièrement
Routine	Selon une heure, une API ou un événement	Définie dans le workflow	Indépendante de la session	Automatiser un processus récurrent

Dans Claude Code :

• /goal relance le travail après chaque tour tant qu’un évaluateur distinct ne considère pas la condition comme satisfaite.
• /loop repose au contraire sur le temps : le prompt est relancé après un intervalle donné.
• Les routines Claude Code sont des configurations enregistrées qui s’exécutent sur une infrastructure cloud gérée par Anthropic. Elles peuvent être déclenchées par un calendrier, un appel API ou un événement GitHub, même lorsque l’ordinateur de l’utilisateur est éteint.

Codex (openAi) propose également /goal pour conserver un objectif actif sur plusieurs étapes, ainsi que des tâches planifiées pour exécuter des workflows récurrents. ([OpenAI Developers][3])

/goal : travailler jusqu’à l’obtention d’un résultat

La commande /goal est adaptée aux tâches qui possèdent une fin identifiable.

Au lieu de demander successivement :

Analyse le problème. Corrige le fichier. Lance les tests. Corrige les erreurs. Relance les tests.

Il devient possible de définir directement le résultat final :

/goal Corrige le système d’authentification jusqu’à ce que tous les tests
du dossier test/auth réussissent et que le lint ne retourne aucune erreur.
Ne modifie pas les autres fonctionnalités.

L’agent peut alors :

1. examiner le code ;
2. identifier la cause du problème ;
3. effectuer une modification ;
4. lancer les tests ;
5. analyser les échecs ;
6. modifier de nouveau le code ;
7. recommencer jusqu’à réussite.

Dans Claude Code, une évaluation est effectuée après chaque tour. Si la condition n’est pas démontrée, un nouveau tour commence automatiquement. La condition doit donc pouvoir être vérifiée à partir d’un test, d’une commande, d’un fichier ou d’un autre résultat observable. ([Claude Platform Docs][1])

Dans Codex, /goal permet également de conserver un objectif durable. La commande peut être consultée, interrompue, reprise ou supprimée avec les variantes prévues à cet effet. ([OpenAI Developers][3])

Exemple de /goal mal défini

/goal Améliore le site jusqu’à ce qu’il soit meilleur.

Le mot « meilleur » ne correspond à aucune condition mesurable. L’agent ne sait pas clairement quand il doit s’arrêter.

Exemple de /goal correctement défini

/goal Optimise la page d’accueil jusqu’à obtenir les résultats suivants :

- aucune erreur dans la console ;
- score Lighthouse Performance supérieur ou égal à 90 ;
- aucune modification visuelle du menu ;
- tous les tests Playwright réussissent ;
- arrêt après 15 itérations si le score reste bloqué.

Cette version précise :

• le résultat attendu ;
• les tests à effectuer ;
• les éléments à préserver ;
• la limite maximale de la boucle.

Quand utiliser /goal ?

/goal convient notamment pour :

• corriger un bug jusqu’à ce que les tests passent ;
• réaliser une migration technique ;
• appliquer l’ensemble des critères d’un cahier des charges ;
• améliorer une performance jusqu’à un seuil donné ;
• traiter une liste d’issues jusqu’à ce qu’elle soit vide ;
• produire un prototype fonctionnel à partir d’un fichier de spécifications.

La commande est moins adaptée à une demande vague, à une exploration sans critère de réussite ou à une liste de tâches sans rapport entre elles.

/loop : répéter une action à intervalles réguliers

La commande /loop ne poursuit pas directement une condition finale. Elle relance un prompt selon une fréquence.

Exemple :

/loop 5m vérifie si le déploiement est terminé et analyse les éventuelles erreurs

Le contrôle est exécuté toutes les cinq minutes.

Claude Code accepte également une boucle sans intervalle explicitement défini :

/loop vérifie l’état de la pull request et traite les nouveaux commentaires

Dans ce cas, Claude peut choisir lui-même le délai avant l’itération suivante selon la situation observée. La commande /loop fonctionne dans la session en cours et sert principalement aux opérations de surveillance ou d’attente active. ([Claude][4])

Exemples d’utilisation de /loop

Surveiller un déploiement

/loop 10m vérifie le déploiement de staging.

Si le déploiement échoue :
- récupère les logs ;
- identifie la cause probable ;
- prépare une correction minimale.

Si le déploiement réussit :
- vérifie les pages principales ;
- résume le résultat.

Surveiller une pull request

/loop 20m vérifie la pull request actuelle.

- analyse les nouveaux commentaires ;
- traite les remarques techniques ;
- vérifie l’état de la CI ;
- n’effectue aucun merge automatiquement.

Maintenir une branche

Un fichier .claude/loop.md peut contenir les instructions utilisées lorsqu’une commande /loop est lancée sans prompt supplémentaire.

Vérifie la branche de préproduction.

Si la CI échoue, analyse les logs et prépare une correction minimale.

Si de nouveaux commentaires de revue sont présents, traite-les un par un.

Si tout fonctionne, réponds uniquement avec un résumé de l’état.

Le fichier devient alors une définition réutilisable de la boucle. Claude Code recherche notamment ce fichier dans le projet ou dans la configuration générale de l’utilisateur. ([Claude][4])

Quand utiliser /loop ?

/loop convient lorsque le prochain contrôle doit être déclenché par le temps :

• vérifier un déploiement toutes les cinq minutes ;
• surveiller l’arrivée de commentaires ;
• attendre la fin d’un traitement ;
• contrôler régulièrement l’état d’une CI ;
• examiner périodiquement une file de tâches ;
• poursuivre la maintenance d’une branche pendant une session.

La distinction essentielle est la suivante :

/goal recommence parce que l’objectif n’est pas atteint. /loop recommence parce qu’un intervalle de temps s’est écoulé.

Les routines : automatiser un workflow durable

Une routine est plus persistante qu’un /loop.

Elle ne dépend pas nécessairement d’une conversation ouverte. Elle contient une configuration enregistrée comprenant généralement :

• un prompt ;
• un ou plusieurs dépôts ;
• un environnement d’exécution ;
• des connecteurs ;
• un ou plusieurs déclencheurs.

Dans Claude Code, une routine peut être déclenchée :

• chaque heure, chaque jour ou chaque semaine ;
• une seule fois à une date donnée ;
• par un appel API ;
• par un événement GitHub.

Elle s’exécute dans une session cloud autonome et peut utiliser les skills présents dans le dépôt ainsi que les connecteurs autorisés. Les routines Claude Code sont actuellement présentées comme une fonctionnalité en phase de recherche, susceptible d’évoluer. ([Claude Platform Docs][2])

Exemple de routine quotidienne

Nom : Analyse quotidienne du projet

Déclenchement : chaque jour ouvré à 8 h

Instructions :

1. Examine les commits intégrés depuis la dernière exécution.
2. Analyse les échecs récents de la CI.
3. Recherche les issues nouvellement ouvertes.
4. Classe les problèmes selon leur gravité.
5. Propose une action pour chaque problème important.
6. Enregistre le compte rendu dans reports/daily-review.md.
7. Ne modifie aucun fichier de production.
8. Crée une pull request uniquement lorsqu’une correction est clairement vérifiable.

Cette routine ne cherche pas nécessairement à terminer un objectif unique. Elle exécute régulièrement le même processus sur de nouvelles données.

Exemple de routine pour un site éditorial

Nom : Contrôle hebdomadaire des contenus

Déclenchement : chaque lundi à 7 h

Instructions :

1. Analyse les articles modifiés au cours des sept derniers jours.
2. Vérifie les titres, descriptions et liens internes.
3. Signale les pages sans meta description.
4. Repère les liens internes cassés.
5. Prépare un rapport classé par priorité.
6. Ne publie aucune modification automatiquement.

Une routine peut ainsi servir à surveiller un site, une documentation, un dépôt de code ou une file de tickets.

Comment combiner /goal, /loop et les routines ?

Ces trois mécanismes ne sont pas concurrents. Ils peuvent former les différents niveaux d’un même système.

Niveau 1 : la routine détecte le travail

Chaque matin, une routine analyse :

• les erreurs de production ;
• les tests échoués ;
• les nouvelles issues ;
• les modifications récentes.

Elle produit ensuite une liste de problèmes à traiter.

Niveau 2 : /goal résout un problème

Pour chaque problème suffisamment précis, un objectif est lancé :

/goal Corrige l’erreur de validation du formulaire jusqu’à ce que :

- le bug ne soit plus reproductible ;
- les tests existants réussissent ;
- un test de non-régression soit ajouté ;
- aucun autre comportement du formulaire ne soit modifié.

Niveau 3 : /loop surveille les opérations externes

Après l’ouverture d’une pull request :

/loop 15m vérifie la CI et les nouveaux commentaires de revue

Le système complet devient alors :

Routine
    ↓
Détection d’un problème
    ↓
/goal
    ↓
Correction et vérification
    ↓
Pull request
    ↓
/loop
    ↓
Surveillance de la CI et de la revue

Les composants d’une boucle fiable

Une boucle autonome ne repose pas uniquement sur une commande. Elle doit disposer de plusieurs éléments structurants.

1. Un objectif précis

L’agent doit savoir exactement ce qui doit être obtenu.

Le formulaire doit refuser les adresses électroniques invalides.

2. Une preuve de réussite

Le résultat doit être vérifiable.

Le test npm run test:form doit retourner un code de sortie égal à 0.

3. Des contraintes

Les parties qui ne doivent pas être modifiées doivent être mentionnées.

Ne modifie ni le schéma de la base de données ni l’API publique.

4. Une mémoire persistante

Une longue boucle ne doit pas dépendre uniquement du contexte de la conversation.

Elle peut conserver son état dans :

• un fichier progress.md ;
• un fichier PLAN.md ;
• un tableau de tickets ;
• une base de données ;
• un outil comme GitHub Issues ou Linear.

Cette mémoire peut contenir :

## Objectif actuel

Corriger les erreurs du module d’authentification.

## Déjà essayé

- modification du validateur ;
- ajout d’un contrôle côté serveur ;
- mise à jour de deux tests.

## État actuel

23 tests réussis sur 25.

## Prochaine action

Analyser les deux échecs liés aux sessions expirées.

5. Des instructions réutilisables

Les règles du projet peuvent être placées dans un skill.

Un skill contient généralement un fichier SKILL.md, accompagné si nécessaire de scripts, de références ou de modèles. Il évite de répéter les mêmes instructions à chaque exécution. Codex et Claude Code disposent tous deux de systèmes de skills permettant de formaliser des workflows réutilisables. ([OpenAI Developers][5])

6. Des environnements isolés

Lorsque plusieurs agents travaillent parallèlement, ils risquent de modifier les mêmes fichiers.

Les worktrees Git permettent de créer plusieurs copies de travail isolées à partir d’un même dépôt. Chaque agent peut ainsi intervenir sur sa propre branche sans perturber les autres tâches en cours. Codex intègre notamment les worktrees dans l’application de bureau et peut les utiliser pour les tâches planifiées. ([OpenAI Developers][6])

7. Une vérification indépendante

L’agent qui produit une modification ne devrait pas être le seul à décider si elle est correcte.

Une architecture plus fiable sépare les rôles :

• un agent analyse ;
• un agent réalise ;
• un autre agent vérifie ;
• les tests automatiques confirment le résultat.

Claude Code et Codex permettent de créer ou d’utiliser des sous-agents spécialisés pour répartir ces fonctions. ([Claude Platform Docs][7])

Les risques du Loop Engineering

L’autonomie ne supprime pas les erreurs. Elle peut au contraire les multiplier plus rapidement.

Une mauvaise condition d’arrêt

Une condition trop vague peut provoquer :

• une boucle interminable ;
• des modifications inutiles ;
• une consommation excessive de tokens ;
• une dégradation progressive du projet.

Il est donc utile de définir une limite :

Arrête-toi après 15 itérations si aucune amélioration mesurable n’est obtenue.

Une consommation importante

Chaque nouvelle itération utilise du contexte, des appels de modèles et éventuellement des outils externes.

Les sous-agents augmentent également la consommation puisqu’ils effectuent leurs propres analyses.

Une boucle doit être réservée aux tâches dont la valeur justifie ce coût.

Une erreur exécutée automatiquement

Une routine mal configurée peut :

• modifier des fichiers ;
• lancer des commandes ;
• publier un commentaire ;
• créer une branche ;
• ouvrir une pull request ;
• appeler un service externe.

Les permissions, les dépôts, les connecteurs et les accès réseau doivent donc être limités au strict nécessaire.

Une perte de compréhension

Plus l’agent produit de travail sans intervention humaine, plus l’utilisateur risque de ne plus comprendre son propre système.

Le rôle humain se déplace, mais ne disparaît pas. Il reste nécessaire de :

• définir l’objectif ;
• choisir les critères de réussite ;
• examiner les modifications ;
• contrôler les décisions importantes ;
• valider le résultat final.

Quelle solution choisir ?

Utilisez /goal lorsque vous pouvez compléter la phrase :

Continue jusqu’à ce que…

Exemple :

Continue jusqu’à ce que tous les tests réussissent.

Utilisez /loop lorsque vous pouvez compléter la phrase :

Vérifie de nouveau dans…

Exemple :

Vérifie de nouveau dans dix minutes.

Utilisez une routine lorsque vous pouvez compléter la phrase :

Exécute automatiquement ce processus chaque…

Exemple :

Exécute automatiquement ce contrôle chaque lundi.

Conclusion

Le Loop Engineering marque le passage d’une utilisation conversationnelle des agents IA à une logique d’orchestration.

/goal permet de poursuivre une tâche jusqu’à un résultat vérifiable. /loop relance une action selon un intervalle. Les routines rendent un workflow durable et indépendant d’une session ponctuelle.

La qualité du résultat ne dépend cependant pas uniquement du modèle utilisé. Elle dépend surtout de la conception de la boucle :

• un objectif précis ;
• une condition d’arrêt vérifiable ;
• des contraintes explicites ;
• une mémoire persistante ;
• des permissions limitées ;
• une vérification indépendante ;
• une validation humaine finale.

L’enjeu n’est plus seulement de savoir écrire un bon prompt. Il consiste à construire un système capable de décider quel prompt doit être exécuté ensuite, pourquoi il doit l’être et à quel moment le travail peut réellement être considéré comme terminé.

Questions fréquentes

Quelle est la différence entre /goal et /loop ?

/goal relance l’agent après chaque étape jusqu’à ce qu’une condition soit satisfaite. /loop relance un prompt selon un intervalle de temps.

Une routine fonctionne-t-elle lorsque l’ordinateur est éteint ?

Une routine Claude Code exécutée sur l’infrastructure cloud d’Anthropic peut continuer à fonctionner lorsque l’ordinateur est éteint. Une tâche locale ou un /loop dépend en revanche de l’environnement local ou de la session active. ([Claude Platform Docs][2])

Peut-on utiliser /goal dans Claude Code et Codex ?

Les versions récentes de Claude Code et de Codex proposent toutes deux une commande /goal, avec des modalités de contrôle propres à chaque produit. ([Claude Platform Docs][1])

Le Loop Engineering est-il réservé au développement informatique ?

Non. Le principe peut s’appliquer à toute tâche possédant des données accessibles, des actions réalisables et des critères de vérification : contrôle de contenus, production de rapports, veille, classement de tickets ou maintenance documentaire.

Une boucle peut-elle fonctionner sans intervention humaine ?

Elle peut exécuter de nombreuses étapes sans intervention, mais les objectifs, les permissions et les résultats sensibles doivent rester contrôlés. Une boucle autonome ne transforme pas une réponse probable en résultat automatiquement fiable.

Le front matter reprend la structure utilisée précédemment sur le site.

[1]: https://docs.anthropic.com/en/docs/claude-code/goal "Keep Claude working toward a goal - Claude Code Docs" [2]: https://docs.anthropic.com/en/docs/claude-code/routines "Automate work with routines - Claude Code Docs" [3]: https://developers.openai.com/codex/use-cases/follow-goals/?export=pdf " Follow a goal | ChatGPT use cases " [4]: https://code.claude.com/docs/en/scheduled-tasks "Run prompts on a schedule - Claude Code Docs" [5]: https://developers.openai.com/codex/skills " Build skills | ChatGPT Learn " [6]: https://developers.openai.com/codex/app/worktrees " Worktrees | ChatGPT Learn " [7]: https://docs.anthropic.com/en/docs/claude-code/sub-agents?utm_source=chatgpt.com "Create custom subagents - Claude Code Docs"