Loop Engineering : comment créer des agents IA qui travaillent sans être relancés

Pendant longtemps, utiliser une intelligence artificielle signifiait enchaîner les demandes :

• écrire un prompt
• lire la réponse
• corriger
• puis rédiger le prompt suivant.

Le Loop Engineering change cette organisation. L’humain ne pilote plus chaque étape :* Il construit une boucle capable de donner du travail à l’IA, d’en contrôler le résultat et de décider automatiquement de la suite.

L’objectif n’est donc plus seulement d’écrire un bon prompt, mais de concevoir un système qui peut fonctionner plusieurs heures, chaque jour ou à chaque apparition d’un événement précis.

Une boucle IA observe une situation, agit, contrôle le résultat, puis recommence jusqu’à atteindre un objectif ou jusqu’à sa prochaine exécution programmée.

L’article source présente cette évolution à travers trois notions : le Loop Engineering, la commande /goal et les routines de Claude Code.

Du prompt ponctuel à la boucle autonome

Dans une utilisation classique, l’humain constitue lui-même la boucle :

L’humain donne une instruction

• l’IA répond
• l’humain vérifie
• l’humain donne l’instruction suivante

Même lorsque l’IA exécute correctement la tâche, elle s’arrête et attend. Le travail ne continue que si une personne revient dans la conversation.

Avec le Loop Engineering, cette logique est intégrée au système :

Un déclencheur lance la tâche

• l’agent observe l’état actuel
• il réalise une action
• le résultat est vérifié
• l’état est mémorisé
• une nouvelle action est lancée si nécessaire

La fonction de l’utilisateur change. Il ne décrit plus chaque opération. Il définit :

• le résultat recherché ;
• les ressources accessibles ;
• la manière de vérifier le travail ;
• les actions interdites ;
• le moment auquel la boucle doit s’arrêter.

La qualité du système dépend alors moins de la formulation d’un prompt isolé que de la précision de ses règles de fonctionnement.

Les différents niveaux d’autonomie

Toutes les boucles ne présentent pas le même degré de complexité. Il existe un continuum entre une simple répétition et un agent autonome connecté à plusieurs outils.

1. Répéter une instruction avec /loop

La commande /loop permet de réexécuter un prompt à intervalles réguliers dans une session Claude Code.

Elle peut servir à :

• surveiller un déploiement ;
• vérifier régulièrement une pull request ;
• suivre un traitement long ;
• inspecter périodiquement des logs ;
• explorer plusieurs pistes sur un projet.

Ces tâches sont liées à la session en cours : elles cessent lorsque celle-ci prend fin. Les tâches planifiées nécessitent actuellement Claude Code 2.1.72 ou une version ultérieure. ([Claude][1])

Exemple :

Toutes les dix minutes pendant trois heures :

• examiner l’état du projet ;
• identifier une amélioration possible ;
• tester cette amélioration ;
• enregistrer le résultat ;
• poursuivre avec une autre piste.

Ce fonctionnement convient particulièrement aux travaux exploratoires. L’agent ne reçoit pas nécessairement une méthode précise : il dispose d’un sujet, d’une durée et de limites à respecter.

2. Continuer jusqu’à un résultat avec /goal

La commande /goal répond à un besoin différent. Elle ne relance pas l’agent selon une fréquence : elle lui donne une condition d’achèvement.

Après chaque étape, un modèle rapide examine si cette condition est satisfaite. Si la réponse est négative, Claude poursuit le travail. S’il considère l’objectif atteint, la boucle s’arrête. La fonction est documentée à partir de Claude Code 2.1.139. ([Claude][2])

Exemple :

/goal classer tous les fichiers du dossier Téléchargements dans les sous-dossiers Images, Documents, Vidéos et Autres, continuer jusqu’à ce qu’aucun fichier ne reste à classer, ne rien supprimer et s’arrêter après 30 étapes.

Cette instruction contient les trois éléments d’une bonne boucle :

1. Un état final précis : aucun fichier ne doit rester à classer.
2. Une vérification possible : compter les fichiers encore présents.
3. Des limites : ne rien supprimer et ne pas dépasser trente étapes.

Une demande comme « range correctement mon dossier » serait trop subjective. Une boucle fiable doit pouvoir déterminer concrètement si le travail est terminé.

Les routines : faire fonctionner la boucle sans ordinateur allumé

Une routine est une configuration enregistrée contenant notamment une instruction, des ressources, des connecteurs et des déclencheurs.

Contrairement à /loop, elle fonctionne sur l’infrastructure cloud d’Anthropic. Elle peut donc continuer même lorsque l’ordinateur de l’utilisateur est éteint. Une routine peut être déclenchée selon un calendrier, par un appel API ou par certains événements GitHub. Cette fonctionnalité est encore présentée comme un aperçu de recherche susceptible d’évoluer. ([Claude][3])

La routine transforme une tâche ponctuelle en responsabilité permanente :

Tous les matins à 9 heures
→ consulter les nouveaux éléments
→ appliquer les règles prévues
→ produire un résultat
→ envoyer un compte rendu

Exemple : sélectionner les e-mails importants

L’une des captures de l’article présente une routine intitulée Daily Email Cleanup.

Son fonctionnement est simple :

Chaque matin à 9 heures :

- lire les e-mails non consultés ;
- identifier les trois messages les plus importants ;
- envoyer dans Slack une synthèse d’une ligne par message ;
- ne répondre à aucun e-mail.

La routine utilise deux connecteurs : Gmail pour lire les messages et Slack pour transmettre la synthèse.

Emplacement conseillé pour l’image : après ce paragraphe. Texte alternatif : Routine Claude Code analysant Gmail et envoyant les e-mails importants dans Slack.

Cet exemple montre qu’un agent autonome n’est pas obligé de prendre toutes les décisions. Il peut simplement préparer l’information et laisser l’action finale à l’utilisateur.

Le cas avancé : traiter puis contrôler des tickets de support

L’exemple le plus complet de l’article repose sur deux routines distinctes.

Première routine : effectuer le nettoyage

Chaque matin à 8 heures, un premier agent :

• récupère les tickets ouverts dans Intercom ;
• applique une *skill* appelée cleanup-tickets ;
• traite les demandes selon les règles de l’entreprise ;
• publie un résumé dans le canal Slack du support ;
• fournit les liens directs vers les conversations ;
• ne supprime aucun ticket.

La *skill* contient la méthode de traitement permanente. La routine ne reprend donc pas toutes les règles dans son instruction : elle appelle un savoir-faire enregistré et réutilisable.

Emplacement conseillé pour l’image : capture « Daily Support Ticket Cleanup ». Texte alternatif : Routine Claude Code traitant quotidiennement les tickets Intercom et publiant un résumé dans Slack.

Seconde routine : vérifier les décisions de la première

À 11 heures, un second agent examine tous les tickets automatiquement fermés dans la journée.

Sa consigne est différente :

Vérifier que chaque ticket fermé doit réellement le rester.

Lorsque les réponses fournies ne résolvent pas clairement
le problème du client, rouvrir le ticket.

Le premier agent est le producteur. Le second est le contrôleur.

Cette séparation est essentielle : un système ne devrait pas seulement produire une action puis déclarer lui-même qu’elle est correcte. Un agent indépendant doit pouvoir remettre en cause la décision.

Emplacement conseillé pour l’image : capture « Daily Support Ticket Cleanup Checker ». Texte alternatif : Agent de contrôle vérifiant les tickets de support automatiquement fermés.

La boucle complète devient alors :

Agent principal
→ traite les tickets
→ ferme les demandes apparemment résolues
→ publie son compte rendu

Agent contrôleur
→ réexamine les tickets fermés
→ détecte les résolutions insuffisantes
→ rouvre les demandes problématiques
→ laisse les cas ambigus à l’équipe humaine

Les composants d’une véritable boucle IA

Une automatisation planifiée ne constitue pas nécessairement une boucle complète. Plusieurs composants doivent travailler ensemble.

Le déclencheur

Il détermine quand le système doit fonctionner :

• chaque matin ;
• une fois par semaine ;
• à la réception d’un événement ;
• après une modification d’un dépôt ;
• à la demande d’une API.

L’objectif

Il décrit le résultat attendu, et non simplement l’activité à effectuer.

Mauvais objectif :

Examiner mes e-mails.

Objectif plus exploitable :

Identifier les trois e-mails non lus nécessitant une action aujourd’hui et produire pour chacun une synthèse d’une ligne.

La *skill*

Une *skill* formalise une méthode réutilisable : quand l’utiliser, quelles étapes suivre, quel résultat produire et quelles règles ne jamais enfreindre.

La structure présentée dans l’une des images comprend notamment :

• un nom ;
• une description indiquant quand l’utiliser ;
• un objectif ;
• les étapes ;
• le format du résultat ;
• les règles permanentes ;
• les interdictions ;
• des exemples corrects et incorrects ;
• une règle de gestion de l’incertitude.

Les *skills* permettent d’ajouter à Claude Code des procédures spécialisées et partageables. ([Claude Platform Docs][4])

Emplacement conseillé pour l’image : schéma « The Anatomy of a Claude Skill ». Texte alternatif : Structure d’une skill Claude avec objectif, étapes, format, règles et exemples.

Les connecteurs

Les connecteurs donnent accès aux systèmes utilisés dans le travail réel :

• Gmail ;
• Slack ;
• Intercom ;
• GitHub ;
• Jira ;
• Google Drive ;
• bases documentaires internes.

Claude Code peut également se connecter à des services externes au moyen du Model Context Protocol. ([Claude][5])

La mémoire

Une boucle doit conserver ce qui a déjà été réalisé.

Cette mémoire peut prendre la forme :

• d’un fichier Markdown ;
• d’un dépôt GitHub ;
• d’un tableau de tâches ;
• d’un historique de tickets ;
• d’une base de données.

Sans mémoire, l’agent risque de recommencer le même travail à chaque exécution.

Le contrôleur

Le contrôleur vérifie si le résultat répond réellement aux critères définis.

Il peut s’appuyer sur :

• un test automatisé ;
• un nombre d’éléments restants ;
• un format attendu ;
• une liste de critères ;
• un second agent ;
• une validation humaine.

D’autres usages concrets

La même architecture peut être appliquée à de nombreuses activités.

Produire un rapport mensuel

Le premier jour du mois
→ récupérer les données
→ contrôler les valeurs manquantes
→ calculer les indicateurs
→ rédiger une première synthèse
→ signaler les anomalies
→ soumettre le document à validation

Réaliser une veille régulière

Chaque lundi
→ collecter les nouveautés sur un sujet
→ éliminer les doublons
→ classer les informations
→ produire une synthèse courte
→ enregistrer les sources déjà traitées

Transformer un ensemble de documents

→ lire chaque PDF d’un dossier
→ produire une synthèse standardisée
→ vérifier que chaque document a été traité
→ continuer jusqu’à ce que la file soit vide

Entretenir un projet informatique

Chaque nuit
→ vérifier les tests en échec
→ examiner les nouveaux tickets
→ sélectionner une correction limitée
→ modifier le code
→ lancer les tests
→ ouvrir une proposition de modification
→ attendre la revue humaine

Comment construire une première boucle

La méthode la plus sûre consiste à commencer par une tâche petite et facilement contrôlable.

Étape 1 : choisir une tâche répétitive

La tâche doit déjà exister dans votre travail :

• trier des messages ;
• produire une synthèse ;
• contrôler des fichiers ;
• préparer un rapport ;
• surveiller une liste de tickets.

Étape 2 : définir précisément l’état final

Compléter cette phrase :

La tâche est terminée lorsque…

Par exemple :

La tâche est terminée lorsque tous les nouveaux e-mails importants ont été résumés dans Slack et qu’aucune réponse n’a été envoyée.

Étape 3 : définir la preuve

La boucle doit pouvoir vérifier le résultat :

• zéro ligne vide ;
• tous les fichiers possèdent une synthèse ;
• tous les tests passent ;
• chaque ticket traité dispose d’un statut ;
• le nombre de résultats correspond au nombre d’éléments d’origine.

Étape 4 : installer des limites

Une première routine devrait fonctionner en lecture seule.

Les instructions peuvent inclure :

Ne répondre à aucun message.
Ne supprimer aucun fichier.
Ne publier aucun contenu.
Ne modifier aucune donnée source.
Arrêter après vingt étapes.
Transmettre les cas ambigus à un humain.

Étape 5 : ajouter progressivement les droits d’écriture

Après plusieurs exécutions satisfaisantes, la routine peut éventuellement recevoir des permissions supplémentaires :

Niveau 1 : lire et synthétiser
Niveau 2 : classer et étiqueter
Niveau 3 : préparer des actions
Niveau 4 : exécuter certaines actions réversibles
Niveau 5 : exécuter puis faire contrôler

Il n’est pas nécessaire d’atteindre le dernier niveau. Dans de nombreux cas, une routine qui prépare correctement le travail apporte déjà l’essentiel du gain.

Le véritable enjeu du Loop Engineering

Le Loop Engineering ne consiste pas seulement à faire fonctionner une IA plus longtemps.

Il consiste à transformer une compétence humaine en système explicite :

Quand commencer ?
Que faut-il observer ?
Quelle action entreprendre ?
Comment reconnaître un bon résultat ?
Que faire en cas d’incertitude ?
Quand faut-il s’arrêter ?
Quand l’humain doit-il intervenir ?

La difficulté principale n’est pas l’exécution. Elle réside dans la définition du contrôle.

Une IA peut produire rapidement des messages, des rapports, des classifications ou du code. Mais tant que personne ne définit précisément ce qui distingue un résultat acceptable d’un résultat incorrect, il n’existe pas de véritable boucle autonome.

FAQ

Qu’est-ce que le Loop Engineering ?

Le Loop Engineering consiste à concevoir un système qui déclenche, dirige, contrôle et relance une intelligence artificielle sans demander à l’utilisateur d’écrire chaque prompt intermédiaire.

Quelle différence entre /loop et /goal ?

/loop réexécute une instruction selon un intervalle. /goal poursuit le travail dès qu’une étape se termine et s’arrête lorsqu’un modèle confirme que la condition d’achèvement est satisfaite. ([Claude][2])

Quelle différence entre /goal et une routine ?

/goal pilote une tâche longue dans une session. Une routine enregistre un travail qui peut être relancé automatiquement dans le cloud selon un calendrier ou un événement. ([Claude][3])

Faut-il savoir programmer ?

Les routines simples peuvent être configurées en langage naturel depuis l’interface. Les intégrations personnalisées, les API, les tests automatiques et les boucles complexes nécessitent davantage de compétences techniques.

Une routine doit-elle agir automatiquement ?

Non. Elle peut uniquement lire, analyser et préparer un compte rendu. La validation, l’envoi ou la modification finale peuvent rester sous contrôle humain.

Comment éviter qu’une boucle fonctionne indéfiniment ?

Il faut prévoir une condition d’arrêt, un nombre maximal d’étapes, des restrictions explicites et une procédure d’escalade lorsqu’un cas reste incertain.

---

Hypothèses éditoriales

Cette version est conçue comme un article pédagogique francophone de 1 800 à 2 000 mots, destiné à un public non développeur mais déjà familier avec les outils d’intelligence artificielle. Les captures fournies sont intégrées comme illustrations pratiques plutôt que comme simples reproductions de l’article original.

[1]: https://code.claude.com/docs/en/scheduled-tasks?utm_source=chatgpt.com "Run prompts on a schedule - Claude Code Docs" [2]: https://code.claude.com/docs/en/goal?utm_source=chatgpt.com "Keep Claude working toward a goal - Claude Code Docs" [3]: https://code.claude.com/docs/en/routines?utm_source=chatgpt.com "Automate work with routines - Claude Code Docs" [4]: https://docs.anthropic.com/en/docs/claude-code/skills?utm_source=chatgpt.com "Extend Claude with skills - Claude Code Docs" [5]: https://code.claude.com/docs/en/overview?utm_source=chatgpt.com "Overview - Claude Code Docs"