/goal, /loop et Routine : la différence

Ces trois outils servent à faire continuer Claude sans rédiger manuellement chaque prompt, mais ils répondent à trois questions différentes :

/goal : jusqu’à quand Claude doit-il travailler ?
/loop : à quel intervalle Claude doit-il revenir sur la tâche ?
Routine : quand une nouvelle exécution autonome doit-elle être lancée ?

/goal = continuer jusqu’au résultat /loop = recommencer après un délai Routine = lancer automatiquement une mission enregistrée

Comparaison rapide

Fonction	/goal	/loop	Routine
Logique	Orientée résultat	Orientée temps	Orientée automatisation
Déclenchement suivant	Dès que l’étape précédente finit	Après un intervalle	Selon horaire, API ou événement GitHub
Condition d’arrêt	Objectif vérifié	Arrêt manuel, décision de Claude ou expiration	La session se termine lorsque la mission est finie
Portée	Session actuelle	Session actuelle	Configuration persistante
Ordinateur allumé	Oui, sauf session distante	Oui, sauf session passée en arrière-plan	Non
Accès aux fichiers locaux	Oui	Oui	Non, dépôt cloné dans le cloud
Durée typique	Minutes, heures ou jours	Surveillance périodique courte	Jours, semaines ou activité permanente
Usage principal	Produire un résultat complet	Surveiller ou réexaminer	Automatiser une responsabilité récurrente

1. /goal : travailler jusqu’à atteindre un résultat

Principe

Avec /goal, on ne donne pas seulement une tâche. On définit l’état final qui permettra de considérer la tâche comme terminée.

Après chaque tour de travail, un modèle évaluateur distinct vérifie si la condition est satisfaite :

Claude travaille
→ il présente ses résultats
→ l’évaluateur contrôle la condition
→ NON : Claude continue immédiatement
→ OUI : la boucle s’arrête

La prochaine itération commence donc parce que la précédente est terminée, et non parce qu’un délai s’est écoulé. Un seul objectif peut être actif dans une session.

Exemple simple

/goal tous les tests du dossier test/auth passent,
npm run lint se termine sans erreur
et aucun fichier de test n’a été modifié

Claude peut alors :

lancer les tests ;
analyser les erreurs ;
modifier le code ;
relancer les tests ;
continuer jusqu’à ce que les critères soient prouvés.

Exemple : créer un parseur documentaire

/goal le parseur extrait correctement le titre,
la date, l’auteur et le contenu des 500 documents,
tous les tests réussissent,
ou arrêter après 30 tours

Cette tâche convient à /goal parce qu’elle possède :

un périmètre défini ;
un état final mesurable ;
un moyen de vérification ;
une limite de sécurité.

Bon usage

/goal convient à :

terminer une migration ;
corriger une suite de tests ;
traiter une file de tickets jusqu’à ce qu’elle soit vide ;
appliquer toutes les exigences d’un cahier des charges ;
convertir un corpus complet de fichiers ;
refactoriser un module jusqu’à respecter certaines contraintes.

Mauvais usage

/goal améliorer mon site

Le mot « améliorer » ne permet pas à l’évaluateur de savoir objectivement quand s’arrêter.

Version plus précise :

/goal obtenir un score Lighthouse supérieur à 90,
sans régression sur les tests,
sans modifier le contenu visible
et en conservant toutes les fonctionnalités

---

2. /loop : revenir périodiquement sur une tâche

Principe

Avec /loop, Claude réexécute un prompt après un délai donné.

Claude vérifie
→ il attend
→ l’intervalle arrive
→ il vérifie à nouveau
→ il attend

Ce mécanisme répond aux situations dans lesquelles le temps ou un système extérieur doit évoluer : déploiement, tests distants, commentaire sur une pull request, import en cours ou surveillance de logs.

/loop 5m check the deploy

Le prompt est relancé toutes les cinq minutes. /loop fonctionne dans la session actuelle et les tâches récurrentes expirent automatiquement après sept jours.

Exemple : surveiller un déploiement

/loop 5m vérifie si le déploiement est terminé.

S’il échoue :
- lis les logs ;
- identifie la cause ;
- propose une correction.

S’il réussit :
- exécute les smoke tests ;
- résume le résultat.

Ici, Claude ne peut pas simplement « travailler davantage » pour faire apparaître le résultat. Il doit attendre que le déploiement évolue.

Exemple : surveiller une pull request

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

- Examine les nouveaux commentaires.
- Contrôle l’état de la CI.
- Corrige les erreurs simples.
- Signale les décisions nécessitant une validation humaine.

Intervalle choisi automatiquement

On peut omettre la fréquence :

/loop vérifie si la CI passe
et traite les nouveaux commentaires

Claude choisit alors lui-même un délai compris entre une minute et une heure selon la situation : attente courte pendant un traitement actif, attente plus longue lorsque rien ne change.

Exemple exploratoire

/loop 20m explore une nouvelle manière
de simplifier l’architecture de ce projet.

À chaque passage :
- examine une zone différente ;
- formule une hypothèse ;
- réalise un prototype limité ;
- teste-le ;
- documente le résultat ;
- ne fusionne rien automatiquement.

Ce type de boucle permet de confier une exploration ouverte à l’agent, mais il faut conserver des limites claires.

Bon usage

/loop convient à :

contrôler périodiquement un déploiement ;
surveiller une CI ;
suivre une pull request ;
inspecter des logs ;
vérifier l’avancement d’un processus extérieur ;
reprendre régulièrement une exploration ;
exécuter un entretien temporaire du projet.

Mauvais usage

/loop 5m corrige tous les tests

Si Claude peut immédiatement corriger les tests puis les relancer, l’attente de cinq minutes ne sert à rien. Cette tâche correspond plutôt à /goal.

---

3. Routine : lancer automatiquement une mission persistante

Principe

Une Routine est une configuration enregistrée contenant notamment :

un prompt ;
un ou plusieurs dépôts ;
des connecteurs ;
des permissions ;
un ou plusieurs déclencheurs.

Elle fonctionne sur l’infrastructure cloud d’Anthropic. L’ordinateur peut être éteint. La Routine peut démarrer :

selon un calendrier ;
après un appel API ;
après un événement GitHub.

Elle crée à chaque déclenchement une session Claude Code autonome. Les Routines sont actuellement présentées comme une fonctionnalité en research preview.

Exemple : synthèse quotidienne des e-mails

Chaque jour à 9 heures :

- lire les e-mails non lus dans Gmail ;
- sélectionner les trois plus importants ;
- produire une synthèse d’une ligne par message ;
- envoyer la synthèse dans Slack ;
- ne répondre à aucun e-mail.

Architecture :

Déclencheur quotidien
→ Claude Code dans le cloud
→ connecteur Gmail
→ sélection des e-mails
→ connecteur Slack
→ publication du résumé
→ fin de l’exécution

La Routine reprend automatiquement le travail le lendemain, sans conserver une session ouverte sur l’ordinateur.

Exemple : nettoyage quotidien des tickets

Première Routine, à 8 heures :

- Lire tous les tickets ouverts dans Intercom.
- Appliquer la skill cleanup-tickets.
- Traiter les tickets admissibles.
- Publier un résumé dans Slack.
- Fournir un lien complet vers chaque conversation.
- Ne supprimer aucun ticket.

Deuxième Routine, à 11 heures :

- Examiner les tickets fermés automatiquement ce jour.
- Vérifier si le problème du client est clairement résolu.
- Rouvrir les tickets mal résolus.

On obtient deux agents avec deux fonctions différentes :

Routine 1 : producteur
→ traite et ferme certains tickets

Routine 2 : contrôleur
→ vérifie les décisions
→ rouvre les tickets incorrectement fermés

La seconde Routine forme le mécanisme de vérification de la première.

Autres exemples de Routine

Veille hebdomadaire

Chaque lundi à 7 heures :

- rechercher les nouveaux articles sur le sujet ;
- éliminer les doublons déjà enregistrés ;
- classer les informations par thème ;
- produire une synthèse ;
- publier le rapport dans Slack.

Maintenance documentaire

Chaque vendredi :

- examiner les pull requests fusionnées ;
- identifier les pages de documentation devenues obsolètes ;
- préparer les mises à jour ;
- ouvrir une pull request ;
- ne jamais fusionner automatiquement.

Réaction à un incident

Lorsque l’outil de surveillance appelle l’API :

- récupérer l’alerte ;
- analyser les logs ;
- rapprocher l’incident des derniers commits ;
- préparer un correctif ;
- ouvrir une pull request en brouillon ;
- prévenir l’équipe.

Anthropic cite précisément les routines de triage d’alertes, d’entretien de backlog, de revue de code, de vérification de déploiement et de correction documentaire parmi les usages adaptés. ([Claude Platform Docs][3])

La distinction fondamentale

/goal : événement interne

Le prochain tour commence lorsque Claude vient de terminer le précédent.

Travail → évaluation → travail → évaluation → résultat

/loop : événement temporel

Le prochain tour commence lorsqu’un délai s’est écoulé.

Vérification → attente → vérification → attente

Routine : événement externe ou planifié

Une nouvelle session commence lorsqu’un déclencheur survient.

Horaire / API / GitHub
→ nouvelle session autonome
→ travail
→ résultat
→ fin

---

Quel outil choisir ?

Cas 1 : « Continue jusqu’à ce que tout soit correct »

Utiliser /goal.

/goal tous les fichiers ont été traités
et le rapport final ne contient aucune erreur

Cas 2 : « Vérifie régulièrement si quelque chose a changé »

Utiliser /loop.

/loop 10m vérifie si le déploiement est terminé

Cas 3 : « Fais cette tâche automatiquement tous les jours »

Utiliser une Routine.

Chaque matin à 8 heures :
analyse les nouveaux tickets
et publie un rapport dans Slack

Cas 4 : « Travaille maintenant, puis attends une réponse extérieure »

Utiliser /loop.

Exemple : Claude corrige une PR, puis revient vérifier quinze minutes plus tard si la CI ou les reviewers ont répondu.

Cas 5 : « Une tâche longue doit être terminée sans nouvelle intervention »

Utiliser /goal.

Exemple : créer un parseur jusqu’à ce que tous les formats du corpus soient correctement reconnus.

Cas 6 : « Le processus doit fonctionner pendant plusieurs mois »

Utiliser une Routine, et non /loop, puisque /loop reste attaché à une session et expire après sept jours.

---

Les trois peuvent représenter trois niveaux d’un même système

Routine
= quand lancer le travail

/goal
= quelle condition doit être atteinte pendant le travail

/loop
= quand revenir vérifier un événement extérieur

Exemple conceptuel de maintenance d’un site :

Routine chaque matin
→ lance l’audit du site

Objectif de la mission
→ toutes les anomalies détectées sont classées
→ les corrections simples sont testées
→ les cas risqués sont placés en attente humaine

Boucle temporelle éventuelle
→ vérifier périodiquement l’état de la CI
→ reprendre lorsque les résultats arrivent

La formule la plus simple est donc :

/goal vise un état final.
/loop organise une attente répétée.
Une Routine automatise le lancement d’une responsabilité complète.