Bien démarrer avec les boucles

• Au lieu de piloter un agent de code en lui donnant des instructions à chaque prompt, on passe à un modèle d’exploitation où l’agent répète un cycle de travail jusqu’à ce qu’une condition d’arrêt soit remplie
• L’équipe Claude Code classe les boucles selon quatre critères : le mode de déclenchement, le mode d’arrêt, les primitives utilisées et le type de tâche le plus adapté
• Les principaux types de boucles sont au nombre de quatre : Turn-based, Goal-based, Time-based et Proactive
• Toutes les tâches n’ont pas besoin de boucles complexes ; il faut commencer par la solution la plus simple puis appliquer ces patterns de manière sélective
• La qualité de sortie d’une boucle dépend du système qui l’entoure ; maintenir la qualité du code et maîtriser l’usage des tokens est donc essentiel

---

Définition des boucles et critères de classification

• L’équipe Claude Code définit une boucle comme un agent qui répète un cycle de travail jusqu’à ce qu’une condition d’arrêt soit satisfaite
• Quatre critères sont proposés pour classer les boucles
  • comment elles sont déclenchées
  • comment elles s’arrêtent
  • quelles primitives Claude Code elles utilisent
  • pour quels types de tâches elles sont les plus adaptées
• Une boucle complexe n’est pas toujours nécessaire ; il faut privilégier une solution simple puis n’utiliser les patterns que de façon sélective

Boucles Turn-based

• Elles sont déclenchées par un prompt utilisateur et s’arrêtent quand Claude juge la tâche terminée ou quand un contexte supplémentaire est nécessaire
• Elles conviennent aux tâches courtes qui ne relèvent pas d’un processus régulier ni d’un planning
• Pour les gérer, on peut rédiger des prompts précis et améliorer la vérification via des skills afin de réduire le nombre de tours
• Chaque prompt lance une boucle manuelle où l’utilisateur dirige chaque tour ; cela est appelé une agentic loop
  • Claude collecte le contexte → exécute une action → vérifie le travail → recommence si nécessaire → répond
  • Exemple : pour une demande de création d’un bouton like, Claude lit le code, l’édite, exécute les tests puis renvoie le résultat ; l’utilisateur vérifie ensuite manuellement avant d’écrire le prompt suivant
• L’étape de vérification peut être encodée dans SKILL.md pour élargir la capacité d’auto-vérification de Claude
  • Il faut inclure des outils ou connecteurs permettant d’observer, mesurer ou interagir avec le résultat
  • Plus la vérification est quantitative, plus l’auto-vérification est facile

• Exemple de SKILL.md (verify-frontend-change)

  • Règles pour valider de bout en bout une modification d’interface avant de la déclarer terminée
  • Interdiction d’annoncer la fin du travail sur la seule base d’une édition réussie ; vérifier comme le ferait un relecteur humain
    • démarrer le serveur de dev puis ouvrir dans le navigateur la page modifiée
    • manipuler directement les éléments modifiés (cliquer sur les boutons, champs de saisie, bascules), vérifier les changements d’état, et prendre des captures avant/après
    • vérifier dans la console du navigateur qu’il y a zéro nouvelle erreur ou avertissement
    • exécuter une trace de performance et un audit Core Web Vitals avec Chrome Devtools MCP
  • Si une étape échoue, corriger puis recommencer depuis l’étape 1 ; ne jamais renvoyer un état partiellement vérifié

Boucles Goal-based (/goal)

• Elles sont déclenchées par un prompt manuel en temps réel, puis s’arrêtent quand l’objectif est atteint ou que le nombre maximal de tours est atteint
• Elles conviennent aux tâches avec des critères de fin vérifiables
• Pour les gérer, il faut définir des critères d’achèvement précis et une limite explicite de tours, par exemple « s’arrêter après 5 tentatives »
• Sur les tâches complexes qu’un seul tour ne suffit pas à résoudre, l’agent gagne en performance lorsqu’il itère
• Si l’on définit l’état d’achèvement avec /goal, Claude ne s’arrête pas prématurément en décidant seul si c’est « suffisamment bien »
  • Chaque fois que Claude tente de s’arrêter, un modèle évaluateur vérifie les conditions et relance le travail jusqu’à l’atteinte de l’objectif ou du nombre de tours défini
  • Des critères déterministes comme le nombre de tests réussis ou un seuil de score précis sont efficaces
• Exemple
  • /goal get the homepage Lighthouse score to 90 or above, stop after 5 tries.

Boucles Time-based (/loop et /schedule)

• Elles sont déclenchées à des intervalles de temps définis et s’arrêtent quand l’utilisateur les annule ou quand la tâche est terminée (fusion de PR, file d’attente vide)
• Elles conviennent aux tâches répétitives ou aux interactions avec des environnements et systèmes externes
• Pour les gérer, on peut allonger l’intervalle ou préférer une réaction basée sur les événements plutôt que sur le temps
• Certaines tâches agentiques sont répétitives : le travail reste le même et seuls les inputs changent, par exemple résumer chaque matin les messages Slack
• Pour les tâches dépendantes de systèmes externes, l’interface consiste à vérifier à chaque intervalle puis réagir aux changements, par exemple lorsqu’une PR reçoit une revue ou qu’une CI échoue
• /loop relance le prompt à chaque intervalle
  • /loop 5m check my PR, address review comments, and fix failing CI
• /loop s’exécute sur l’ordinateur de l’utilisateur et s’arrête à la fermeture ; avec /schedule, il est possible de créer une routine et de la déplacer dans le cloud

Boucles Proactive

• Elles sont déclenchées par des événements ou des plannings, sans intervention humaine en temps réel
• Chaque tâche se termine quand l’objectif est atteint, mais la routine elle-même continue jusqu’à ce que l’utilisateur la coupe
• Elles conviennent à des flux de travail répétitifs et bien définis comme les bug reports, la catégorisation d’issues, les migrations ou les mises à niveau de dépendances
• Pour les gérer, on peut router la routine vers des modèles plus petits et plus rapides, et réserver le modèle le plus puissant aux étapes qui demandent du jugement
• En combinant les primitives ci-dessus avec le mode auto, les dynamic workflows (research preview), etc., on peut construire des boucles de longue durée

• Exemple d’architecture pour le traitement des retours

  • exécuter avec /schedule (research preview) une routine de vérification des nouveaux signalements
  • définir l’achèvement avec /goal et documenter la méthode de vérification avec des skills
  • orchestrer avec Dynamic workflows des agents de classification, de correction et de revue pour chaque signalement
  • exécuter la routine en mode auto sans confirmation d’autorisation
  • Exemple de prompt intégré : /schedule every hour: check the project-feedback channel for bug reports. /goal: don't stop until every report found this run is triaged, actioned, and responded to. When fixing a bug, use a workflow to explore three solutions in parallel worktrees and have a judge adversarially review them.

Maintenir la qualité du code

• La qualité de sortie d’une boucle dépend du système environnant ; la conception du système est donc importante
• Garder le codebase propre : Claude suit les patterns et conventions du codebase existant
• Fournir des moyens d’auto-vérification : encoder avec des skills ce que l’équipe considère comme un « bon état »
• Faciliter l’accès à la documentation : les bonnes pratiques les plus récentes se trouvent dans la documentation des frameworks et bibliothèques
• Utiliser un second agent pour la revue de code : un relecteur avec un contexte neuf est moins biaisé et moins influencé par le raisonnement de l’agent principal ; on peut utiliser le skill intégré /code-review ou Code Review pour GitHub
• Si des résultats individuels sont en dessous du niveau attendu, il ne faut pas seulement corriger chaque problème, mais encoder une amélioration du système lui-même

Gérer l’usage des tokens

• Les boucles doivent avoir des limites claires et les principes suivants s’appliquent
• Choisir la bonne primitive et le bon modèle : pour les petites tâches, les agents multiples ou les boucles sont inutiles ; certaines tâches peuvent utiliser des modèles moins chers et plus rapides
• Définir clairement les critères de réussite et d’arrêt : préciser l’état d’achèvement pour éviter une fin prématurée
• Faire un pilote avant un déploiement à grande échelle : les dynamic workflows peuvent créer des centaines d’agents ; il faut d’abord mesurer la consommation sur un petit périmètre
• Utiliser des scripts pour les tâches déterministes : exécuter un script coûte moins cher que raisonner sur chaque étape ; par exemple, un skill PDF peut fournir un script de remplissage de formulaire à exécuter au lieu de régénérer le code à chaque fois
• Ne pas faire tourner une routine plus que nécessaire : ajuster l’intervalle à la fréquence réelle des changements à surveiller
• Examiner la consommation : /usage analyse l’usage par skills, subagents et MCPs ; /goal sans argument affiche le nombre de tours actuel et la consommation de tokens ; /workflows affiche la consommation de tokens de chaque agent et permet de les arrêter à tout moment

Bien démarrer

• Résumé par type de boucle
  • Turn-based : déléguer la vérification (check), à utiliser pour l’exploration et la décision, avec des skills de vérification personnalisés
  • Goal-based : déléguer la condition d’arrêt, à utiliser quand l’état d’achèvement est connu, avec /goal
  • Time-based : déléguer le déclenchement, à utiliser quand les tâches arrivent selon un planning extérieur au projet, avec /loop et /schedule
  • Proactive : déléguer le prompt, à utiliser pour les tâches répétitives et bien définies, avec tout ce qui précède et les dynamic workflows
• Pour commencer, regarder les tâches déjà réalisées, choisir celle où vous êtes le goulot d’étranglement, puis déterminer ce qui peut être délégué
  • pouvez-vous écrire des checks de vérification ?
  • l’objectif est-il suffisamment clair ?
  • la tâche arrive-t-elle selon un planning ?
• Une fois une idée trouvée, lancer la boucle et observer les points de blocage ou de sur-exécution ; n’ayez pas peur d’améliorer par itérations