Bien démarrer avec les boucles dans Claude Code

Il y a beaucoup de discussions en ce moment sur la conception de « boucles » plutôt que sur le simple fait de donner des instructions à votre agent de codage. Si vous passez du temps sur X à essayer de définir ce qu'est une boucle, vous trouverez plusieurs réponses différentes.

Au sein de l'équipe Claude Code, nous définissons les boucles comme des agents qui répètent des cycles de travail jusqu'à ce qu'une condition d'arrêt soit remplie. Nous catégorisons plusieurs types de boucles en fonction de :

• Leur déclencheur
• Leur condition d'arrêt
• La primitive Claude Code utilisée
• Le type de tâche le plus approprié pour chacune.

Nous allons couvrir les principaux types de boucles, quand les utiliser, et comment maintenir la qualité du code tout en gérant l'utilisation des tokens. Toutes les tâches ne nécessitent pas des boucles complexes ; commencez par la solution la plus simple et utilisez ces motifs de manière sélective.

Boucles basées sur les tours

• Déclenchées par : Une instruction de l'utilisateur.
• Critère d'arrêt : Claude juge qu'il a terminé la tâche ou a besoin de contexte supplémentaire.
• Idéales pour : Les tâches courtes qui ne font pas partie d'un processus ou d'un calendrier régulier.
• Utilisation gérée par : Rédiger des instructions spécifiques et améliorer la vérification à l'aide de compétences pour réduire le nombre de tours.‍

Chaque instruction que vous envoyez démarre une boucle manuelle où vous dirigez chaque tour. Claude rassemble le contexte, agit, vérifie son travail, répète si nécessaire, et répond. Nous appelons cela la boucle agentique.

Par exemple, demandez à Claude de créer un bouton « J'aime ». Il lit votre code, effectue la modification, exécute les tests, et vous renvoie quelque chose qu'il croit fonctionnel. Vous vérifiez ensuite manuellement le travail et rédigez l'instruction suivante.

Vous pouvez améliorer l'étape de vérification en encodant vos étapes manuelles dans un fichier SKILL.md afin que Claude puisse vérifier davantage son propre travail, de bout en bout. Cela devrait inclure des outils ou des connecteurs permettant à Claude de voir, mesurer ou interagir avec le résultat. Plus les vérifications sont quantitatives, plus il est facile pour Claude de s'auto-vérifier.

Par exemple, dans votre fichier SKILL.md, vous pouvez spécifier :

1---
2name: verify-frontend-change
3description: Vérifier toute modification UI de bout en bout avant de la déclarer terminée.
4---
5
6# Vérification des modifications frontend
7Ne signalez jamais une modification UI comme terminée sur la seule base d'une édition réussie. Vérifiez-la comme le ferait un relecteur humain :
8
91. Démarrez le serveur de développement et ouvrez la page modifiée dans le navigateur.
10
112. Interagissez directement avec la modification. Pour un nouveau contrôle (bouton, champ de saisie, bascule) : cliquez dessus, confirmez le changement d'état attendu, et faites une capture d'écran avant/après.
12
133. Vérifiez la console du navigateur : zéro nouvelle erreur ou avertissement.
14
154. Utilisez le MCP des Devtools Chrome, exécutez un trace de performance et auditez les Core Web Vitals.
16
17Si une étape échoue, corrigez le problème et recommencez à partir de l'étape 1 — ne rendez pas un travail partiellement vérifié.

Boucle basée sur un objectif (/goal)

• Déclenchée par : Une instruction manuelle en temps réel.
• Critère d'arrêt : Objectif atteint OU nombre maximum de tours atteint.
• Idéale pour : Les tâches qui ont des critères de sortie vérifiables.
• Utilisation gérée par : Définir des critères d'achèvement spécifiques et des limites de tours explicites, « arrêter après 5 tentatives. »

Parfois, un seul tour ne suffit pas, surtout pour des tâches plus complexes. Les agents donnent de meilleurs résultats lorsqu'ils peuvent itérer. Vous pouvez prolonger la durée pendant laquelle Claude continue d'itérer en définissant à quoi ressemble la tâche terminée avec /goal.

Lorsque vous définissez les critères de succès, Claude n'a pas à décider ce qui est « assez bon » et à terminer la boucle prématurément. Chaque fois que Claude essaie de s'arrêter, un modèle évaluateur vérifie votre condition et le renvoie au travail jusqu'à ce que l'objectif soit atteint ou qu'un nombre de tours que vous avez défini soit atteint.

C'est pourquoi les critères déterministes, tels que le nombre de tests réussis ou le dépassement d'un certain seuil de score, sont si efficaces.

Par exemple :

1/goal obtenir un score Lighthouse de 90 ou plus pour la page d'accueil, arrêter après 5 tentatives.

Boucle basée sur le temps (/loop et /schedule)

• Déclenchée par : Un intervalle de temps spécifié.
• Critère d'arrêt : Vous l'annulez, ou le travail se termine (la PR est fusionnée, la file d'attente est vide).
• Idéale pour : Les travaux récurrents, ou l'interface avec des environnements/systèmes externes.
• Utilisation gérée par : Définir des intervalles plus longs ou réagir en fonction d'événements plutôt que du temps.

Certains travaux agentiques sont récurrents : la tâche reste la même et seules les entrées changent. Par exemple, résumer les messages Slack chaque matin. D'autres travaux dépendent de systèmes externes, et une façon simple d'interfacer avec l'un d'eux est de le vérifier à intervalles réguliers et de réagir à ce qui a changé. Par exemple, une PR qui peut recevoir des revues de code ou échouer à la CI.

Pour ces cas, vous pouvez déclencher l'exécution de Claude avec \/loop`` qui ré-exécute une instruction à intervalles réguliers. Par exemple :

1/loop 5m vérifier ma PR, répondre aux commentaires de revue, et corriger la CI qui échoue

\/loop` s'exécute sur votre ordinateur, donc si vous l'éteignez, il s'arrête. Vous pouvez déplacer la boucle vers le cloud en créant une routine avec \/schedule\`.

Boucles proactives

• Déclenchées par : Un événement ou un planning, sans intervention humaine en temps réel.
• Critère d'arrêt : Chaque tâche se termine lorsque son objectif est atteint. La routine elle-même s'exécute jusqu'à ce que vous la désactiviez.
• Idéales pour : Des flux récurrents de travail bien défini : rapports de bugs, triage de tickets, migrations, mises à jour de dépendances, etc.
• Utilisation gérée par : Router les routines vers des modèles plus petits et plus rapides et utiliser le modèle le plus performant pour les décisions.

Les primitives ci-dessus, ainsi que d'autres fonctionnalités de Claude Code comme le mode automatique et les workflows dynamiques (aperçu de recherche) peuvent être composées en une boucle pour un travail de longue durée.

Par exemple, pour gérer les retours entrants, vous pouvez utiliser :

1. `/schedule` (aperçu de recherche) pour exécuter une routine qui vérifie les nouveaux rapports
2. `/goal` pour définir à quoi ressemble la tâche terminée et les compétences pour documenter comment la vérifier
3. Les workflows dynamiques pour orchestrer les agents qui trient chaque rapport, le corrigent, et examinent la correction
4. Le mode automatique pour que la routine s'exécute sans demander la permission

En assemblant le tout, une instruction pourrait ressembler à ceci :

1/schedule toutes les heures : vérifier le canal project-feedback pour les rapports de bugs. /goal : ne pas s'arrêter tant que chaque rapport trouvé lors de cette exécution n'est pas trié, traité et auquel il n'a pas été répondu. Lors de la correction d'un bug, utiliser un workflow pour explorer trois solutions dans des worktrees parallèles et faire examiner ces solutions de manière contradictoire par un juge.

Maintenir la qualité du code

La qualité de la sortie d'une boucle dépend du système qui l'entoure. Lors de la conception du système :

• Gardez la base de code elle-même propre : Claude suit les motifs et conventions qui existent déjà dans votre base de code.
• Donnez à Claude un moyen de vérifier son propre travail : Encodez ce qui est « bien » pour vous et votre équipe avec les compétences.
• Rendez la documentation facile d'accès : La documentation des frameworks et bibliothèques contient les meilleures pratiques à jour.
• Utilisez un deuxième agent pour les revues de code : Un relecteur avec un contexte frais est moins biaisé et n'est pas influencé par le raisonnement de l'agent principal. Vous pouvez utiliser la compétence intégrée \/code-review`` ou Code Review pour Github.

Lorsqu'un résultat individuel n'atteint pas le niveau attendu, ne vous arrêtez pas à la correction du problème individuel, essayez de l'encoder pour améliorer le système pour toutes les itérations futures.

Gérer l'utilisation des tokens

Pour gérer l'utilisation des tokens, les boucles doivent avoir des limites claires :

• Choisissez la bonne primitive et le bon modèle pour le travail : Les petites tâches n'ont pas besoin de plusieurs agents ou de boucles. Certaines tâches peuvent utiliser des modèles moins chers et plus rapides.
• Définissez des critères de succès et d'arrêt clairs : Soyez précis sur ce à quoi ressemble la tâche terminée afin que Claude puisse arriver à la solution plus tôt (mais pas trop tôt).
• Faites un pilote avant un déploiement à grande échelle : Les workflows dynamiques peuvent générer des centaines d'agents. Évaluez d'abord l'utilisation sur une plus petite partie du travail.
• Utilisez des scripts pour les tâches déterministes : Exécuter un script est moins coûteux que de raisonner à travers les étapes. Par exemple, une compétence PDF peut fournir un script de remplissage de formulaire que Claude exécute à chaque fois, au lieu de redériver le code.
• N'exécutez pas les routines plus souvent que nécessaire : Faites correspondre l'intervalle à la fréquence à laquelle la chose que vous surveillez change.
• Examinez l'utilisation : La commande \/usage` décompose l'utilisation récente par compétences, sous-agents et MCPs, \/goal\ sans arguments montre le nombre de tours et l'utilisation des tokens jusqu'à présent, \/workflows\` montre l'utilisation des tokens de chaque agent et vous pouvez arrêter un agent à tout moment.

Pour commencer

Pour résumer :

Boucle

Vous déléguez

Utilisez-la quand

Recourez à

Basée sur les tours

La vérification

Vous explorez ou décidez

Compétences de vérification personnalisées

Basée sur un objectif

La condition d'arrêt

Vous savez à quoi ressemble la tâche terminée

/goal

Basée sur le temps

Le déclencheur

Le travail se produit en dehors de votre projet selon un planning

/loop

,

/schedule

Proactive

L'instruction

Le travail est récurrent et bien défini

Tout ce qui précède, et les workflows dynamiques

Pour commencer avec les boucles, regardez le travail que vous faites déjà. Choisissez une tâche où vous êtes le goulot d'étranglement et demandez-vous quelle partie vous pourriez déléguer : pouvez-vous rédiger la vérification ? L'objectif est-il suffisamment clair ? Le travail arrive-t-il selon un planning ?

Une fois que vous avez une idée, exécutez la boucle, observez les résultats, comme les endroits où elle bloque ou dépasse les limites, et n'ayez pas peur d'itérer dessus.

Pour plus d'informations, lisez la documentation de Claude Code sur l'exécution d'agents en parallèle, ainsi que les pages sur la boucle, le planning, l'objectif, et les workflows dynamiques.

Cet article a été écrit par @delba_oliveira