/goal est une commande d’Agentic Coding, popularisée par Claude Code, qui applique la programmation déclarative aux agents IA. Plutôt que de décrire à l’agent la suite d’étapes à suivre, on lui donne un objectif mesurable à atteindre. L’agent gère lui-même le chemin pour y parvenir, itère tant que nécessaire, et s’arrête dès que le but est vérifié comme atteint.
De l’instruction à l’objectif : programmation impérative vs déclarative
La plupart des interactions avec un agent de coding restent impératives : le développeur détaille les étapes (“ouvre ce fichier, modifie cette fonction, lance ces tests”), un peu comme il écrirait lui-même le code pas à pas. Cette approche fonctionne bien pour des tâches courtes, mais elle demande une supervision constante dès que la tâche s’étale sur plusieurs itérations.
/goal inverse la logique : on ne décrit plus le “comment” mais le “quoi”. On formule une ligne d’arrivée — par exemple “réduire le temps d’exécution de la suite de tests de 30 %” ou “supprimer les faux positifs de ce skill sans casser les tests existants” — et l’agent explore lui-même les moyens d’y parvenir. C’est le même changement de paradigme que celui qui distingue un langage déclaratif (SQL, Terraform) d’un langage impératif (Python, Bash) : on spécifie le résultat souhaité, pas la séquence d’opérations pour y arriver.
Comment fonctionne /goal
Techniquement, /goal met en place une boucle d’itérations pilotée par un évaluateur. À chaque tour, l’agent produit une tentative, puis l’évaluateur détermine si l’objectif est atteint :
- Si oui, la boucle s’arrête : l’objectif mesurable a été vérifié comme atteint.
- Si non, l’itération continue : l’évaluateur transmet à l’agent la raison précise du dernier échec, qui sert de contexte pour la tentative suivante.
Ce mécanisme de feedback ciblé — ne renvoyer que la dernière raison d’échec plutôt que l’historique complet — permet de garder chaque itération concentrée sur ce qui reste à corriger, plutôt que de saturer le contexte de l’agent avec des tentatives précédentes déjà résolues. Le détail du fonctionnement de l’évaluateur est décrit dans la documentation officielle de Claude Code.
Un objectif mesurable, condition indispensable
/goal n’est pas adapté à toutes les tâches. Son efficacité dépend entièrement de la capacité à formuler un objectif vérifiable automatiquement par l’évaluateur : un test qui passe, une métrique chiffrée, un nombre de tokens, un temps d’exécution. Un objectif flou (“améliore la qualité du code”) ne donne à l’évaluateur aucun critère d’arrêt fiable, et la boucle risque de tourner sans converger ou de s’arrêter prématurément sur une fausse impression de réussite.
Dans la pratique, on borne aussi la boucle par des garde-fous explicites : nombre maximal d’itérations, périmètre de fichiers autorisés, tolérance zéro sur certains critères (aucune violation de test, aucun faux positif). Ces contraintes évitent qu’un agent laissé à lui-même ne dérive en cherchant à satisfaire l’objectif par des moyens non désirés.
Cas d’usage concrets
/goal trouve sa place sur des tâches d’optimisation bornées, où le succès se mesure objectivement :
- Amélioration des performances : réduire le temps d’exécution d’une suite de tests ou d’un pipeline de build jusqu’à un seuil cible.
- Optimisation de la consommation de tokens : fiabiliser un skill ou un agent en réduisant ses appels d’outils et sa consommation de tokens, sans dégrader sa justesse.
- Correction bornée : faire converger un agent vers un état “tests verts” ou “zéro régression” sur une fonctionnalité donnée.
Liens avec l’écosystème agentic engineering
/goal s’inscrit dans une famille plus large de mécanismes de pilotage des agents IA, aux côtés de commandes complémentaires orientées temps ou événement plutôt qu’état à atteindre. Son évaluateur reprend les principes de l’évaluation IA (LLM-as-a-judge, critères de réussite explicites) appliqués non plus à une réponse isolée mais à une boucle d’agent complète. La gestion fine du feedback transmis à chaque itération relève du context engineering : on choisit délibérément de ne renvoyer que l’information la plus utile — la dernière raison d’échec — plutôt que tout l’historique. Et lorsque l’objectif dépasse les capacités d’un agent unique, /goal peut piloter une orchestration multi-agents, chaque itération pouvant déléguer des sous-tâches à des agents spécialisés.
Vous souhaitez approfondir ce sujet ?
Voir la formation