Ingénierie en boucle de Claude Code : quatre méthodes d'automatisation du travail au-delà des invites uniques

Ne jamais déclarer une modification de l'interface utilisateur comme terminée uniquement sur la base d'une édition réussie.

1. Démarrer le serveur de développement et ouvrir la page modifiée.
2. Interagir avec le contrôle modifié pour confirmer l'état attendu.
3. Prendre des captures d'écran avant-après si nécessaire.
4. Vérifier la console du navigateur pour détecter d'éventuelles nouvelles erreurs ou avertissements.
5. Exécuter une trace des performances et examiner les indicateurs clés du Core Web Vitals.

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 :

• Aucune erreur dans la console
• Tous les tests réussis
• Le score Lighthouse dépasse le seuil
• Aucun changement visuel en dehors de la zone spécifiée
• Le temps de réponse est inférieur à la limite
• Un nombre spécifique de critères d'acceptation est rempli

Plus le processus de vérification est quantifiable, moins l'intervention humaine est fréquente.

2. Mécanisme de boucle basé sur les objectifs (commande /goal)

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.

Conditions de déclenchement

L'utilisateur lance un objectif dans la session en cours.

Conditions d'arrêt

La boucle se termine lorsque :

• L'évaluateur confirme que les conditions sont remplies, ou
• La limite de tours configurée est atteinte.

Cas d'utilisation optimaux

La boucle basée sur les objectifs convient aux tâches avec un point de terminaison vérifiable, par exemple :

• Réussir tous les tests d'authentification
• Atteindre un score de performance spécifique
• Migrer tous les points d'appel vers une nouvelle API
• Vider la file d'attente des problèmes marqués
• Limiter chaque fichier à une taille prédéfinie
• Remplir tous les critères d'acceptation dans le document de conception

Syntaxe de base

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.

Comment l'évaluateur modifie le mécanisme de boucle

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 :

• Observable
• Spécifique
• Difficile à satisfaire par hasard
• Liée à un utilisateur réel ou à un résultat système
• Dotée d'un nombre maximum de tentatives ou d'autres limites strictes

Objectifs faibles vs objectifs forts

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 autorisations

L'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.

3. Boucle basée sur le temps : /loop et /schedule

Certains 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 :

• Un nouveau message Slack arrive.
• Une demande de tirage reçoit un avis.
• L'état CI passe de réussi à échoué.
• Une dépendance publie une nouvelle version.
• Le tableau de bord opérationnel signale un nouvel événement.

Conditions de déclenchement

Chaque exécution est lancée par un intervalle de temps configuré ou une planification.

Conditions d'arrêt

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.

Cas d'utilisation optimaux

La boucle basée sur le temps convient pour :

• Surveillance des demandes de tirage.
• Résumés quotidiens ou hebdomadaires.
• Tri régulier des problèmes.
• Vérification des dépendances.
• Exécution périodique des tests.
• Vérification de la dérive de la documentation.
• Systèmes de surveillance qui ne fournissent pas de déclencheurs d'événements.

Boucle d'intervalle locale

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.

Planification cloud

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 :

• Planification cyclique.
• Planification unique future.
• Appels API.
• Événements GitHub pris en charge.

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.

Choisir l'intervalle avec soin

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.

4. Boucle proactive

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)

Déclencheur

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.

Condition d'arrêt

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.

Meilleurs cas d'utilisation

Le cycle actif est adapté aux flux de travail répétitifs bien définis :

• Tri des rapports de bugs.
• Catégorisation des problèmes.
• Mise à jour des dépendances.
• Migrations courantes.
• Révisions de code récurrentes.
• Investigation d'alertes.
• Validation de déploiement.
• Maintenance du backlog.

Exemple complet de mode actif

L'exemple d'Anthropic combine plusieurs fonctionnalités de Claude Code :

1. /schedule pour vérifier les nouveaux rapports.
2. /goal pour définir ce qui doit être accompli en une seule exécution.
3. Les compétences décrivent comment chaque tâche doit être validée.
4. Les flux de travail dynamiques coordonnent plusieurs agents.
5. Le mode automatique réduit les interruptions interactives pour les autorisations.

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.

Flux de travail dynamiques

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 :

• Auditer de nombreux fichiers pour un même problème.
• Migrer des centaines de fichiers.
• Effectuer des explorations de recherche indépendantes.
• Comparer plusieurs solutions proposées.
• Revoir chaque fichier modifié et générer un rapport final.

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.

Ce qui change réellement : la validation et la condition d'arrêt

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 :

• Lire l'état actuel
• Choisir un outil
• Effectuer des modifications
• Interpréter les erreurs
• Comparer les résultats aux objectifs
• Essayer une autre approche
• Ne remonter le problème que lorsque le système ne peut pas fonctionner en toute sécurité

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 :

• Que signifie "terminé" ?
• Qui décide que la condition est remplie ?
• Quelles vérifications sont déterministes ?
• Quelles preuves l'agent peut-il examiner ?
• Quel est le nombre maximal de tentatives ?
• Quel est le budget de tokens ou de coût ?
• Comment détecter l'absence de progrès ?
• Quelles opérations nécessitent une approbation humaine ?
• Que faire en cas d'échec d'exécution ?

Une invite bien rédigée ne peut pas compenser l'absence de condition d'arrêt.

La validation est l'amélioration la plus impactante

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 :

• Suites de tests
• Vérificateurs de types
• Outils de linting
• Commandes de compilation
• Automatisation de navigateur
• Captures d'écran et comparaisons visuelles
• Traçage des performances
• Requêtes de base de données
• Assertions de réponses API
• Scanners de sécurité
• Analyse statique
• Scripts d'acceptation reproductibles

Privilégier autant que possible les vérifications déterministes

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.

Utiliser un deuxième agent pour la relecture

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 :

• Un agent pour l'implémentation
• Un agent pour vérifier l'exactitude
• Un agent pour vérifier la sécurité
• Une suite de tests déterministes comme dernier garde-fou

Plus d'agents n'est pas toujours mieux. N'en ajoutez que lorsque la valeur de la relecture justifie le coût supplémentaire.

Le danger des boucles sans garde-fous

Les boucles qui peuvent se poursuivre indéfiniment sont à la fois puissantes et dangereuses.

Il existe trois principaux modes de défaillance.

1. Dérive des coûts

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 / maxTurns
• max_budget_usd / maxBudgetUsd

La 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.

2. Progrès factices

L'agent peut modifier à plusieurs reprises le même fichier sans produire de nouveaux tests réussis ou d'améliorations mesurables.

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 :

• Les mêmes tests échouent systématiquement sur plusieurs cycles consécutifs.
• Aucun nouveau critère d'acceptation n'est satisfait.
• Les mêmes fichiers sont annulés ou réécrits de manière répétée.
• Le score reste inchangé.
• La taille de la file d'attente ne diminue pas.
• L'agent revient à des solutions précédemment rejetées.

Lorsque les progrès stagnent, une boucle robuste doit s'arrêter ou remonter le problème.

3. Confiance croissante dans une solution erronée

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.

Les trois barrières à établir pour chaque boucle

Une boucle pratique doit inclure au moins trois types de barrières.

1. Condition d'achèvement vérifiable par machine

L'état d'achèvement doit être observable via des tests, des scripts, des évaluateurs ou l'état externe.

Exemples :

• Tous les tests réussissent.
• La file d'attente est vide.
• La pull request est fusionnée.
• Le score atteint au moins 90.
• Tous les éléments de la liste de contrôle sont marqués comme terminés.
• Aucun problème de haute sévérité restant.

2. Limites strictes

Définissez au moins une limite stricte :

• Nombre maximal de cycles.
• Nombre maximal de tentatives.
• Durée maximale.
• Utilisation maximale de tokens.
• Coût monétaire maximal.
• Nombre maximal de fichiers modifiés.
• Nombre maximal d'agents parallèles.

Une limite transforme un échec infini en un échec fini.

3. Détection d'absence de progrès

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.

Gérer l'utilisation des tokens

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.

Utiliser les primitives les plus simples

Les petites tâches ne nécessitent pas de flux de travail multi-agents.

Commencez par :

1. Opérations par tours classiques.
2. Modules de compétences reproductibles.
3. Utilisez /goal lorsque davantage de tours sont nécessaires.
4. Utilisez /loop ou /schedule pour un travail déclenché par le temps.
5. N'utilisez les flux de travail proactifs que lorsque le flux de tâches est périodique et bien défini.

Utilisez de petits modèles pour le travail courant

Les modèles rapides et économiques peuvent gérer :

• La découverte de fichiers.
• La classification simple.
• Les modifications répétitives.
• Le formatage.
• Les contrôles déterministes.
• La synthèse de résultats structurés.

Réservez les modèles les plus puissants pour :

• Les décisions architecturales.
• Le diagnostic d'erreurs ambiguës.
• Les jugements de sécurité.
• Les examens contradictoires.
• Les solutions aux conflits d'évaluation.

Testez d'abord à petite échelle, puis étendez

Les flux de travail dynamiques peuvent créer un grand nombre d'agents.

Exécutez d'abord sur un périmètre réduit :

• Traitez dix fichiers avant d'en étendre à cinq cents.
• Résolvez d'abord une catégorie de problèmes avant un déploiement complet.

Sur l'ensemble du backlog.

• Traitez un dépôt avant les autres.
• Traitez un jour de messages avant un mois.

Les projets pilotes révèlent la consommation de jetons, les goulots d'étranglement des outils, les pannes courantes et les contrôles manquants.

Remplacez le raisonnement par des scripts

Lorsque le processus est déterministe, écrivez simplement le code une fois et laissez Claude l'exécuter.

Par exemple :

• Analyser des journaux.
• Vérifier le nombre de fichiers.
• Comparer les structures de sortie.
• Remplir des formulaires connus.
• Trouver des fichiers correspondant à des règles.
• Tester une liste d'URL.
• Calculer des seuils de performance.

Évitez les interrogations excessives

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.

Vérifiez l'utilisation pendant l'exécution

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.

Permissions et sécurité

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 :

• Conteneurs jetables.
• Workers CI sandboxés.
• Machines virtuelles temporaires.
• Environnements sans informations d'identification sensibles ni données montées importantes.

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 :

• Des permissions de dépôt restreintes.
• Un accès réseau aussi limité que possible.
• Une liste blanche d'outils auditable.
• Des points de contrôle de version.
• Des informations d'identification indépendantes et limitées.
• Une approbation humaine pour les déploiements en production ou les opérations destructrices.

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.

Comment choisir la boucle appropriée

Référez-vous au processus de décision suivant.

Choisissez une boucle basée sur les tours lorsque :

• Vous êtes encore en phase d'exploration du problème.
• L'étape suivante dépend d'un jugement humain.
• La tâche est petite et irrégulière.
• Les critères d'achèvement sont subjectifs.
• Les modifications échouées sont faciles à vérifier manuellement.

Choisissez une boucle basée sur les objectifs lorsque :

• Le résultat a des critères d'acceptation mesurables.
• L'agent peut nécessiter plusieurs tentatives.
• Chaque tentative peut être vérifiée.
• Vous pouvez définir des limites strictes de tours ou de coûts.
• Le travail appartient à une session active.

Choisissez une boucle basée sur le temps lorsque :

• La même tâche se répète.
• Seule l'entrée change.
• Vous devez vérifier périodiquement un système externe.
• L'utilisation d'un plan est plus simple qu'une intégration par événement.
• Vous pouvez tolérer le délai dû à l'interrogation.

Choisissez une boucle proactive lorsque :

• Le travail arrive en continu.
• Chaque élément suit un processus stable.
• Les résultats peuvent être vérifiés.
• Le flux de travail est exécuté avec des permissions limitées.
• Les échecs peuvent être escaladés, non masqués.
• Les budgets de jetons et d'outils ont été testés.

Première boucle pratique

Anthropic recommande de commencer par une tâche pour laquelle vous êtes actuellement un goulot d'étranglement.

Posez trois questions.

1. Puis-je rédiger une vérification de validation ?

Exemples :

• Une commande de test.
• Une interaction navigateur.
• Un seuil de score.
• Une vérification de taille de file d'attente.
• Une comparaison de motifs.
• Une règle de différence visuelle.

2. L'objectif est-il suffisamment clair ?

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.

3. Le travail se présente-t-il à un rythme prévisible ?

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.

Exemple : Du prompt manuel à la boucle sécurisée

Imaginez une équipe qui corrige de manière répétée les échecs des vérifications de pull request.

Phase 1 : Mode tour

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.

Phase 2 : Ajout de la validation

Créez une compétence qui peut :

1. Lire les résultats CI.
2. Reproduire l'échec localement.
3. Exécuter les tests associés.
4. Vérifier la suite de tests complète.
5. Examiner la diff finale.

Phase 3 : Ajout d'un objectif

/goal Toutes les vérifications CI nécessaires réussissent, arrête après 4 tentatives

La session peut effectuer plusieurs tentatives de correction.

Phase 4 : Ajout d'une boucle temporelle locale

/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.

Phase 5 : Déplacement vers une routine

Créez une routine cloud déclenchée par un événement de pull request ou un planning.

Limitez-la à :

• Un dépôt pertinent.
• Une branche de fonctionnalité.
• Des pull requests en brouillon.
• Un ensemble de commandes défini.
• Un coût ou une taille d'exécution maximum.

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.

Erreurs courantes

Utiliser une boucle pour des tâches floues

« Améliorer la base de code » peut se poursuivre indéfiniment.

Décomposez-le en résultats observables.

Laisser l'agent de travail être le seul juge

Utilisez des tests, des scripts ou des évaluateurs indépendants.

Ajouter trop tôt une complexité multi-agents

Un seul agent associé à un validateur puissant peut être meilleur qu'un vaste flux de travail mal coordonné.

Planifier le travail trop fréquemment

Interroger toutes les minutes n'est pas fondamentalement plus réactif.

Ignorer les limites de coûts ou de tours

Les boucles sans limite supérieure peuvent entraîner des échecs coûteux.

Considérer les instructions d'un prompt comme un contrôle de sécurité absolu

Utilisez les permissions, les hooks, les sandbox et les environnements isolés pour une exécution déterministe.

Corriger manuellement chaque échec

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.

Questions fréquentes

Qu'est-ce que l'ingénierie des boucles dans Claude Code ?

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.

Quels sont les quatre types de boucles dans Claude Code ?

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.

Quel est le rôle de /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.

Quelle est la différence entre /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.

Les boucles Claude Code tournent-elles indéfiniment ?

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.

Ai-je besoin de plusieurs agents pour créer une boucle ?

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.

Comment réduire le coût des boucles d'agents ?

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.

Les boucles Claude Code en mode proactif sont-elles sûres ?

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.

Outils connexes

• Claude Code : l'environnement de codage agentique d'Anthropic pour lire les dépôts, éditer des fichiers, exécuter des commandes et automatiser le travail de développement.
• Claude Agent SDK : un kit de développement logiciel pour intégrer la boucle agentique utilisant des outils de Claude Code dans des applications personnalisées.
• Claude Code Skills : instructions procédurales, scripts et ressources réutilisables stockés dans SKILL.md.
• Dynamic Workflows : outils d'orchestration basés sur des scripts pour coordonner de nombreux sous-agents dans des tâches volumineuses.
• Claude Code Hooks : outils d'automatisation de cycle de vie déterministes pour valider, bloquer ou répondre aux actions des outils.
• Model Context Protocol : une norme ouverte pour connecter des agents IA à des outils et sources de données externes.
• Chrome DevTools MCP : un serveur MCP pour le débogage de navigateur, utile pour les boucles de validation frontend.

Liens connexes

• Ingénierie des boucles : guide de démarrage : définition officielle par Anthropic des quatre modèles de boucle et leurs cas d'usage recommandés.
• Faire fonctionner Claude en continu : documentation officielle sur la syntaxe de /goal, le comportement d'évaluation, le contrôle d'état et les exigences.
• Exécution programmée de prompts : documentation sur les invites périodiques locales et les tâches Claude Code planifiées.
• Routines de travail automatisées : guide officiel des routines cloud déclenchées par planning, API et événements GitHub.
• Principes des boucles agentiques : documentation technique sur les appels d'outils, tours, permissions, contexte et limites budgétaires.
• Orchestration de sous-agents par flux dynamiques : architecture officielle des flux de travail, limites, exemples et solutions de maîtrise des coûts.
• Contrôle de Claude Code : guide de sélection par Anthropic sur les compétences, hooks, règles, sous-agents et autres mécanismes de contrôle.
• Page communautaire BAAI originale : article chinois de reproduction fourni comme référence initiale.

Points essentiels

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.