For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/fr/articles/claude-code-loop-engineering-four-ways.md.
Cet article présente quatre modèles de boucles Claude Code — par tours, par objectifs, planifiées et proactives — ainsi que leurs déclencheu...
Ne jamais déclarer une modification de l'interface utilisateur comme terminée uniquement sur la base d'une édition réussie.
Si l'une des vérifications échoue, corriger le problème et reprendre à partir de l'étape 1.
L'idée centrale ne réside pas dans la formulation elle-même, mais dans le fait que cette compétence permet à Claude d'obtenir les mêmes preuves qu'un réviseur humain.
Les contrôles quantitatifs sont particulièrement efficaces :
Plus le processus de vérification est quantifiable, moins l'intervention humaine est fréquente.
Lorsqu'un seul tour d'opération peut ne pas suffire mais qu'il est possible de décrire clairement le point d'arrivée, le mécanisme de boucle basé sur les objectifs est particulièrement utile.
Claude Code ne laisse pas l'agent d'opération juger lui-même si le résultat est « assez bon », mais utilise un évaluateur indépendant après chaque tour d'opération.
L'utilisateur lance un objectif dans la session en cours.
La boucle se termine lorsque :
La boucle basée sur les objectifs convient aux tâches avec un point de terminaison vérifiable, par exemple :
L'exemple officiel d'Anthropic est le suivant :
/goal Atteindre un score Lighthouse de 90 ou plus pour la page d'accueil, arrêter après 5 tentatives.
Autre exemple pratique :
/goal Tous les tests dans le répertoire test/auth réussissent et l'étape lint est sans erreur
Selon la documentation actuelle de Claude Code, la commande /goal nécessite Claude Code version 2.1.139 ou ultérieure.
Lorsque Claude termine un tour d'opération, un modèle évaluateur léger et rapide vérifie si les conditions sont remplies.
Si les conditions ne sont pas remplies, un nouveau tour d'opération commence automatiquement ; si les conditions sont remplies, l'objectif en cours est effacé et le contrôle de la session est rendu à l'utilisateur.
Cette séparation est importante car le modèle de travail ne doit pas être le seul juge de sa propre sortie.
Une condition de complétion efficace doit être :
Objectif faible :
/goal Améliorer la page d'accueil
Le terme « améliorer » ne définit pas un point de terminaison mesurable.
Objectif fort :
/goal Augmenter le score de performance Lighthouse mobile à au moins 90,
maintenir l'accessibilité à 95 ou plus, et arrêter après 5 tentatives
Objectif faible :
/goal Réparer les tests
Objectif fort :
/goal Tous les tests dans le répertoire test/payments réussissent, aucun test sauté,
et la commande npm run lint se termine avec un code de sortie de 0
Le modèle ne doit pas deviner ce que signifie la réussite.
/goal ne modifie pas les autorisationsL'objectif s'étend sur plusieurs tours, mais n'approuve pas automatiquement tous les appels d'outils.
En mode d'autorisation par défaut, Claude peut toujours demander une confirmation pour les commandes non autorisées.
Pour les objectifs non supervisés, Anthropic recommande de combiner /goal avec le mode automatique lorsque cela est disponible et approprié. Cela doit être fait après avoir examiné les outils autorisés, les limites du dépôt et les éventuels effets secondaires.
/loop et /scheduleCertains travaux ne sont pas déclenchés par la fin du tour précédent, mais par le temps.
La tâche reste similaire, mais l'entrée change :
Chaque exécution est lancée par un intervalle de temps configuré ou une planification.
La boucle locale s'arrête lorsque vous annulez, fermez l'environnement ou que le travail de surveillance est terminé.
La routine cloud continue de s'exécuter selon sa configuration jusqu'à ce qu'elle soit mise en pause ou désactivée.
La boucle basée sur le temps convient pour :
L'exemple officiel utilise /loop :
/loop 5m Vérifier mes demandes de tirage, traiter les avis, et corriger les CI en échec
Cette invite se réexécute à l'intervalle configuré.
La boucle locale dépend de la machine et de la session en cours. Si l'ordinateur est éteint ou le processus arrêté, la boucle s'arrête également.
Pour les travaux qui doivent continuer après la fermeture de l'ordinateur portable, Claude Code peut utiliser /schedule pour créer des routines cloud.
Une routine active peut commencer ainsi :
/schedule Toutes les heures : Vérifier les nouveaux rapports de bogues dans #project-feedback
Les routines Claude Code s'exécutent sur l'infrastructure cloud gérée par Anthropic et peuvent être déclenchées par :
Au moment de la rédaction de cet article, les routines sont en phase d'aperçu de recherche, donc le comportement, les limites et l'interface API peuvent changer. La disponibilité dépend également du plan Claude concerné, de la politique de l'organisation et de l'activation de Claude Code en ligne.
Une erreur courante est d'exécuter la boucle beaucoup plus fréquemment que la vitesse à laquelle le système externe change.
Si un nouveau problème n'apparaît que quelques fois par jour, vérifier la file d'attente des problèmes toutes les minutes n'est pas utile. Cela augmente l'utilisation des jetons, le nombre d'appels d'outils et —
N'affecte pas le résultat tout en ajoutant du bruit.
Faire correspondre l'intervalle de sondage à la fréquence de changement attendue :
| Modèle de changement externe | Fréquence de sondage raisonnable de départ |
|---|---|
| État CI après un push actif | Toutes les 5 à 10 minutes |
| Canal de feedback d'équipe | Toutes les 30 à 60 minutes |
| Résumé Slack quotidien | Une fois par jour le matin |
| Mise à jour de dépendance | Quotidien ou hebdomadaire |
| Dérive de documentation | Tous les soirs ou chaque semaine |
Ce sont des suggestions de départ, pas des règles universelles. Lorsque le système externe le permet, le déclenchement par événement est généralement préférable au sondage.
La boucle proactive est une combinaison des éléments de base précédents.
Elle s'exécute de manière non supervisée, répond à un travail planifié ou entrant, et fait passer chaque élément de tâche à travers un flux défini.
Voici la traduction en français :
Le contenu lié au cycle actif du code présente visuellement son flux de travail, incluant les étapes de déclenchement, d'exécution et de retour d'information, en écho avec les éléments mentionnés dans la documentation tels que le "déclencheur" et la "condition d'arrêt".](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/0106395e-ee08-41b8-bc17-2b28e0bbd11a-f55a5db1-fee1-4a0e-8ca9-96752a156eb0.png)
Une tâche planifiée, une requête API, un événement GitHub, un message, un problème ou tout autre signal externe lance le travail.
Chaque tâche indépendante se termine après avoir atteint son objectif.
Les routines environnantes continuent de recevoir des travaux futurs jusqu'à ce qu'une personne les désactive.
Le cycle actif est adapté aux flux de travail répétitifs bien définis :
L'exemple d'Anthropic combine plusieurs fonctionnalités de Claude Code :
/schedule pour vérifier les nouveaux rapports./goal pour définir ce qui doit être accompli en une seule exécution.La directive combinée pourrait ressembler à ceci :
/schedule toutes les heures : vérifier les rapports de bugs dans #project-feedback.
/goal : ne pas s'arrêter tant que chaque rapport trouvé lors de cette exécution
n'a pas été trié, traité et répondu.
Lors de la correction d'un bug, utiliser le workflow dans des arbres de travail parallèles
pour explorer trois solutions, avec un relecteur indépendant pour la révision.
Ce n'est plus simplement une invite répétée. C'est un petit système d'exploitation pour un flux de travail restreint.
Les flux de travail dynamiques sont des scripts pour coordonner des sous-agents à grande échelle.
Claude écrit un script d'orchestration JavaScript, et l'environnement d'exécution l'exécute en arrière-plan. Les résultats intermédiaires peuvent être conservés dans des variables de script sans remplir le contexte principal de la conversation.
Anthropic positionne les flux de travail dynamiques pour les tâches suivantes :
La documentation actuelle indique que les flux de travail dynamiques nécessitent Claude Code version 2.1.154 ou ultérieure. Ils peuvent coordonner des dizaines ou des centaines d'agents, il convient donc de les tester à petite échelle avant d'exécuter des tâches de production à grande échelle.
Les tâches planifiées, l'orchestration, les boucles de rétroaction et les files d'attente de travail ne sont pas des concepts d'ingénierie nouveaux.
La véritable transformation réside dans le fait que l'agent de codage peut désormais davantage participer à la boucle :
L'invite n'a pas disparu. Elle est devenue un composant intégré d'un système de contrôle plus vaste.
La question de conception la plus importante est désormais :
Une invite bien rédigée ne peut pas compenser l'absence de condition d'arrêt.
Anthropic insiste sur la validation : permettre à Claude d'examiner et de mesurer sa propre sortie.
Si un ingénieur humain devait construire une page sans accès à un navigateur, il travaillerait à l'aveugle. Il en va de même pour un agent.
Les outils de validation utiles comprennent :
Un script qui retourne un code de sortie 0 ou 1 est généralement moins coûteux et plus fiable que de demander au modèle de raisonner à partir de zéro pour savoir si une exigence est satisfaite.
Par exemple :
npm test
npm run lint
npm run typecheck
Un script de validation combiné pourrait être :
#!/usr/bin/env bash
set -euo pipefail
npm run typecheck
npm run lint
npm test
Claude peut exécuter ce script après chaque modification. La boucle n'a pas besoin de réinterpréter l'ensemble du processus d'acceptation à chaque fois.
Anthropic suggère également d'utiliser un relecteur avec un nouveau contexte.
L'agent d'implémentation a déjà vu son propre raisonnement et peut répéter les mêmes hypothèses. Un réviseur indépendant est moins contraint par ce chemin et peut examiner les résultats sous un autre angle.
Pour les modifications à haute valeur ajoutée, le système peut utiliser :
Plus d'agents n'est pas toujours mieux. N'en ajoutez que lorsque la valeur de la relecture justifie le coût supplémentaire.
Les boucles qui peuvent se poursuivre indéfiniment sont à la fois puissantes et dangereuses.
Il existe trois principaux modes de défaillance.
Chaque tour de boucle peut consommer des tokens d'entrée, des tokens de sortie, des appels d'outils et l'utilisation de modèles payants.
Sans limite de tours ou de budget, une boucle ouverte peut continuer à consommer des frais tout en produisant peu de valeur supplémentaire.
Le SDK de l'agent Claude prend en charge à la fois :
max_turns / maxTurnsmax_budget_usd / maxBudgetUsdLa documentation officielle du SDK indique :
Par défaut, aucune des deux limites n'est définie.
Pour les agents en production, des limites explicites sont une référence raisonnable.
L'agent peut modifier à plusieurs reprises le même fichier sans produire de nouveaux tests réussis ou d'améliorations mesurables.
Decrivez votre idee une fois, et We0 AI peut generer un site vitrine, des pages et un CMS, puis vous aider a attirer clients et trafic apres le lancement.
Une génération de projet complète pour une inscription gratuite
Idéal pour essayer un flux de génération complet et voir rapidement une première ébauche de projet.
Même si le système essaie différentes variantes de la même solution qui échoue, la journalisation peut sembler active.
Les signaux d'absence de progrès utiles comprennent :
Lorsque les progrès stagnent, une boucle robuste doit s'arrêter ou remonter le problème.
L'itération peut rendre une solution défectueuse plus complexe plutôt que plus correcte.
L'agent peut ajouter des couches autour d'hypothèses erronées, produisant un code qui semble de plus en plus complet mais qui s'éloigne du comportement attendu.
La relecture indépendante, les tests déterministes et des chemins de retour en arrière clairs aident à prévenir de tels échecs.
Une boucle pratique doit inclure au moins trois types de barrières.
L'état d'achèvement doit être observable via des tests, des scripts, des évaluateurs ou l'état externe.
Exemples :
Définissez au moins une limite stricte :
Une limite transforme un échec infini en un échec fini.
Arrêter l'exécution lorsque le système ne progresse plus vers l'objectif.
Par exemple :
Si trois tentatives consécutives ne produisent aucun nouveau test réussi
et modifient les mêmes fichiers, arrêter l'exécution et signaler le blocage.
Une implémentation de niveau production peut suivre cela via des scripts ou l'état du flux de travail, et pas seulement via des instructions.
Les boucles doivent être conçues pour allouer les ressources de raisonnement aux étapes de plus haute valeur.
Anthropic recommande les mesures de contrôle des coûts suivantes.
Les petites tâches ne nécessitent pas de flux de travail multi-agents.
Commencez par :
/goal lorsque davantage de tours sont nécessaires./loop ou /schedule pour un travail déclenché par le temps.Les modèles rapides et économiques peuvent gérer :
Réservez les modèles les plus puissants pour :
Les flux de travail dynamiques peuvent créer un grand nombre d'agents.
Exécutez d'abord sur un périmètre réduit :
Sur l'ensemble du backlog.
Les projets pilotes révèlent la consommation de jetons, les goulots d'étranglement des outils, les pannes courantes et les contrôles manquants.
Lorsque le processus est déterministe, écrivez simplement le code une fois et laissez Claude l'exécuter.
Par exemple :
Les boucles basées sur le temps doivent refléter la vitesse de changement du système sous-jacent.
Des intervalles trop courts augmentent les coûts sans améliorer les résultats.
Anthropic propose plusieurs commandes pour vérifier la consommation :
/usage
Cette commande affiche l'utilisation récente dans des domaines tels que les compétences, les sous-agents et l'intégration MCP.
Exécuter /goal sans argument affiche la consommation de tours et de jetons de l'objectif actuel, tandis que /workflows montre l'utilisation des agents de flux de travail et offre des options pour les arrêter.
La disponibilité peut varier selon la version de Claude Code et les fonctionnalités activées.
L'automatisation ne doit pas être confondue avec un accès illimité.
Claude Code prend en charge les modes de permissions qui contrôlent les outils et commandes pouvant être exécutés.
Pour le travail autonome sur une machine de développement, Anthropic recommande de conserver des règles d'autorisation explicites, ou d'utiliser un mode qui approuve automatiquement un nombre limité d'opérations courantes tout en gardant le contrôle sur les commandes à haut risque.
Les modes contournant les permissions ne doivent être utilisés que dans des environnements isolés, par exemple :
Une boucle proactive capable de modifier des fichiers, d'exécuter des commandes shell, d'accéder à des systèmes externes et de créer des pull requests doit également comporter :
L'objectif n'est pas d'éliminer toutes les décisions humaines, mais de réserver l'humain aux décisions qui nécessitent un véritable jugement.
Référez-vous au processus de décision suivant.
Anthropic recommande de commencer par une tâche pour laquelle vous êtes actuellement un goulot d'étranglement.
Posez trois questions.
Exemples :
Un objectif utile décrit un état, et non pas seulement une activité.
Meilleure formulation :
Tous les tests de paiement réussissent et aucune erreur TypeScript ne subsiste.
Formulation plus faible :
Continuer à améliorer le module de paiement.
Si la tâche apparaît toutes les heures, tous les jours, toutes les semaines, ou après un événement connu, elle peut convenir à une boucle ou une routine.
Si l'une des réponses est oui, vous avez un candidat pour votre première boucle.
Imaginez une équipe qui corrige de manière répétée les échecs des vérifications de pull request.
Vérifie la PR actuelle, corrige les tests CI qui échouent et explique les modifications.
Le développeur réexécute manuellement cette opération à chaque changement de CI.
Créez une compétence qui peut :
/goal Toutes les vérifications CI nécessaires réussissent, arrête après 4 tentatives
La session peut effectuer plusieurs tentatives de correction.
/loop 10m Vérifie les PR, traite les nouveaux commentaires de révision,
et corrige les vérifications obligatoires qui échouent.
L'agent vérifie les changements externes.
Créez une routine cloud déclenchée par un événement de pull request ou un planning.
Limitez-la à :
L'évolution est progressive. Chaque phase n'ajoute de l'automatisation qu'après avoir établi des vérifications fiables dans la phase précédente.
« Améliorer la base de code » peut se poursuivre indéfiniment.
Décomposez-le en résultats observables.
Utilisez des tests, des scripts ou des évaluateurs indépendants.
Un seul agent associé à un validateur puissant peut être meilleur qu'un vaste flux de travail mal coordonné.
Interroger toutes les minutes n'est pas fondamentalement plus réactif.
Les boucles sans limite supérieure peuvent entraîner des échecs coûteux.
Utilisez les permissions, les hooks, les sandbox et les environnements isolés pour une exécution déterministe.
Lorsque la même erreur se répète, améliorez la compétence, la règle, le validateur ou le flux de travail qui l'a produite.
L'ingénierie des boucles consiste à concevoir des flux de travail d'agents répétés jusqu'à l'atteinte d'une condition d'arrêt. Elle se concentre sur les déclencheurs, la validation, les limites, les permissions et l'escalade, et pas seulement sur le contenu du prompt.
Anthropic classe les boucles en tours, objectifs, temps et proactives.
Leur principale différence réside dans le mécanisme qui déclenche un nouveau cycle, ainsi que dans l'entité ou le facteur qui décide de l'arrêt du travail.
/goal dans Claude Code ?/goal définit une condition d'achèvement pour la session en cours. Après chaque tour, un évaluateur indépendant vérifie si cette condition est remplie ; si ce n'est pas le cas, un nouveau tour est lancé, jusqu'à ce que l'objectif soit atteint ou que les limites configurées soient dépassées.
/loop et /schedule ?/loop exécute une invite de manière répétée sur la machine locale, le cycle s'arrête donc lorsque la machine ou la session s'interrompt. /schedule crée une tâche récurrente dans le cloud, qui peut continuer à s'exécuter sur l'infrastructure gérée par Anthropic, même lorsque l'ordinateur portable est éteint.
Si le flux de travail manque de limites, la boucle peut s'exécuter plus longtemps que prévu. Avant d'autoriser une exécution sans surveillance, il convient de définir une condition d'achèvement quantifiable, un nombre maximum de tours ou un plafond de coûts, ainsi qu'une règle d'arrêt en l'absence de progression.
Non. Une simple session Claude Code, associée à des compétences de validation réutilisables, peut suffire. Les flux de travail dynamiques et les agents multiples sont plus utiles lorsque les tâches nécessitent un traitement parallèle à grande échelle ou un examen indépendant.
Utilisez le type de boucle le plus simple, optez pour des modèles plus petits pour les tâches courantes, testez sur des charges de travail réduites, remplacez le raisonnement déterministe par des scripts, évitez les interrogations inutiles, et fixez des limites claires en termes de tours ou de budget.
Elles peuvent être exécutées de manière responsable tant que leurs permissions, dépôts, identifiants, budget, conditions d'arrêt et voies d'escalade sont strictement contrôlés. N'utilisez pas de modes contournant les permissions sur des machines contenant des données sensibles ou de valeur.
SKILL.md./goal, le comportement d'évaluation, le contrôle d'état et les exigences.Les boucles Claude Code ne sont pas de simples invites répétées, mais des systèmes contrôlés où déclencheurs, outils, validation, permissions, budget et conditions d'arrêt fonctionnent en concertation.
Les boucles par tour confient le contrôle de chaque étape suivante à l'humain ; les boucles par objectif délèguent la condition d'achèvement à un évaluateur ; les boucles programmées délèguent le déclencheur. Les boucles proactives combinent ces éléments de base en flux de travail autonomes reproductibles.
L'amélioration la plus cruciale ne réside généralement pas dans l'augmentation du nombre d'agents, mais dans le fait de doter les agents existants de mécanismes d'auto-vérification fiables, de critères d'achèvement clairement définis, et d'un système capable de s'interrompre en temps utile lorsque la progression ou le budget vient à manquer.
Une boucle utile n'est pas celle qui peut tourner indéfiniment, mais celle qui peut démontrer quand elle doit s'arrêter.
Partez d’une phrase et obtenez un site complet en quelques minutes.
