Loops
Workflows en boucle fermée pour agents de codage IA
Un « loop », ici, désigne un workflow que l'on confie à un agent de codage (Claude Code, Cursor, Codex, Gemini CLI...) pour qu'il s'auto-régule sur une tâche répétitive, sans qu'un humain doive relancer la commande à chaque itération.
Pourquoi confier une tâche à une boucle plutôt qu'à un prompt unique ?
Un prompt classique produit une réponse, une fois. Un agent de codage moderne peut faire mieux : exécuter une commande, lire le résultat, corriger, recommencer, jusqu'à ce qu'un critère objectif soit atteint. C'est ce mécanisme d'auto-régulation, pas seulement l'exécution d'une commande en boucle, qui distingue un loop d'un simple script répété. La différence pratique : au lieu de relancer manuellement une commande de test après chaque correction, on décrit une seule fois la boucle complète (quoi vérifier, comment corriger, quand s'arrêter), et l'agent s'en charge jusqu'au bout, ou jusqu'à la limite qu'on lui a fixée.
Cette approche vient du monde du CI/CD, où un pipeline relance des vérifications jusqu'à un état stable, mais elle s'applique tout aussi bien à des tâches qui n'ont rien de technique : dans ce répertoire, la boucle de publication d'article vérifié que j'utilise pour ce blog en est un exemple direct, où la « porte de feedback » n'est pas un test automatisé mais une vérification de fait contre une source primaire.
L'anatomie d'un loop
Chaque loop de ce répertoire se décrit avec la même structure en trois temps, à la fois pour rester lisible et pour être directement transposable d'un outil à un autre.
Déclencheur
Ce qui démarre la boucle : un événement (un commit, l'édition d'un fichier) ou un intervalle de temps régulier. Sans déclencheur clair, l'agent ne sait pas quand entrer en action.
Portes de feedback
Les vérifications que l'agent exécute pendant la boucle : lancer les tests, lire les logs du CI, interroger un endpoint. Chaque porte renvoie un signal vrai/faux qui guide l'itération suivante.
Conditions de sortie
Ce qui arrête la boucle : un succès (tous les tests passent) ou une limite (nombre maximal d'itérations atteint). Sans condition de sortie, un agent bloqué peut boucler indéfiniment sans jamais le signaler.
Un exemple concret
Prenons la loop déploiement avec garde-fou de build de ce répertoire. Le déclencheur : toute modification de code, avant commit. Les portes de feedback : le type-check TypeScript, puis le build de production complet. La condition de sortie : les deux commandes passent sans erreur, sinon la boucle s'arrête sur l'échec et exige une correction avant de reprendre, jamais un déploiement forcé. Rien de sophistiqué dans cet exemple précis, et c'est volontaire : une bonne boucle décrit une discipline simple et non négociable, pas un mécanisme complexe.
Deux origines de contenu
Les loops marquées « utilisé pour ce site » sont des workflows que j'exécute réellement dans ma pratique, documentés tels quels. Les autres sont des loops curatées et reformulées à partir d'inspirations externes, avec attribution explicite à leur source, jamais une reprise brute d'un contenu qui n'est pas le mien.
Questions fréquentes
Un loop remplace-t-il un test automatisé classique ?
Non, il s'appuie souvent dessus. Un test automatisé donne un résultat unique (passe/échoue) ; un loop décrit ce que l'agent fait de ce résultat : corriger, recommencer, ou s'arrêter selon une condition de sortie définie à l'avance.
Faut-il un outil spécifique pour utiliser ces loops ?
Non, la structure trigger / portes de feedback / conditions de sortie est transposable à la plupart des agents de codage actuels (Claude Code, Cursor, Codex, Gemini CLI). La commande exacte peut varier légèrement selon l'outil utilisé.
Quelle est la différence entre un loop et un simple script en boucle ?
Un script en boucle répète une action sans jugement. Un loop confié à un agent inclut une étape d'interprétation à chaque itération : lire un résultat, décider quoi corriger, avant de relancer. C'est cette capacité de décision qui distingue les deux.
Comment sont choisies les loops qui ne viennent pas de ma propre pratique ?
Elles sont sélectionnées pour leur utilité réelle, reformulées avec mon propre commentaire (avantages, limites, démarrage) plutôt que copiées telles quelles, et systématiquement attribuées à leur source d'inspiration.
Tous les loops
17 loops
WebSearch/WebFetch pour la recherche et la vérification croisée → rédaction → génération de l'image et de l'audio → publication via l'API NotionPublication d'article vérifié
Aucun article ne part en publication tant que chaque fait chiffré n'est pas confirmé par une source primaire ou au moins deux sources indépendantes.
npx tsc --noEmit && npm run buildDéploiement avec garde-fou de build
Aucun commit ni déploiement sans que le type-check et le build de production passent d'abord, sur ce projet Next.js.
vercel --target=preview --yesPreview avant prod
Un déploiement en production n'a jamais lieu sans passage préalable par un environnement de preview et confirmation explicite.
WebFetch de la source d'origine, puis WebSearch de vérification croiséeVérification croisée d'une source de veille
Un lien partagé pour publication (X, LinkedIn, article) n'est jamais relayé tel quel : ses chiffres sont recherchés indépendamment avant décision.
Création d'une tâche de suivi datée, revue manuellement à l'approche de la publicationRevalidation avant publication programmée
Un article programmé pour une date future avec des faits volatils (prix, tarifs API) déclenche une tâche de revérification avant sa mise en ligne.
playwright: page.goto(url) puis page.screenshot(path=..., full_page=True)Vérification visuelle par capture d'écran
Aucune modification visuelle n'est considérée terminée sans une capture d'écran automatisée du rendu réel, en local ou sur l'environnement de preview.
Recherche interne (Notion/site) des sujets connexes, puis mise à jour des articles concernésMaillage rétroactif et indexation à la publication
Chaque nouvel article publié déclenche deux actions systématiques : relier les anciens articles pertinents vers le nouveau, et en demander l'indexation.
Recherche de photos, puis vérification de la page produit pour confirmer le statut de licenceSourcing d'image libre de droits vérifiée
Chaque image d'illustration passe par une vérification explicite de licence avant intégration, jamais une simple recherche visuelle suivie d'un copier-coller.
Découpage du texte → appels de synthèse vocale par segment → concaténation ffmpeg → mesure de duréeGénération audio avec vérification de durée
La synthèse vocale d'un article est découpée, générée par lot, ré-assemblée, puis sa durée finale est vérifiée avant intégration au site.
gh pr checksPR jusqu'au vert
Implémente sur une branche, lance les tests, pousse, ouvre une PR, et boucle sur les retours du CI jusqu'à ce que tous les checks passent.
npm testGarde pré-commit
Un hook qui lance la suite de tests avant chaque commit et bloque l'opération si elle est rouge.
/loop 5m puis gh run list --branch $(git branch --show-current)Veille des échecs CI
Interroge le CI à intervalle régulier, investigue dès qu'un check passe au rouge, et pousse des corrections jusqu'au retour au vert.
/loop 15m puis curl -fsS <url-de-sante>Vérification post-déploiement
Après un déploiement, interroge à intervalle régulier les endpoints de santé et de fumée jusqu'à ce que tous répondent correctement.
npm run build && npm run lint && npm testRelecteur indépendant
Quand l'implémentation se déclare terminée, une passe de vérification séparée relance build, lint et tests, sans accès au raisonnement de celui qui a codé.
npm test -- --findRelatedTests <fichiers édités>Garde de tests post-édition
Après chaque édition de fichier, relance automatiquement les tests liés pour attraper une régression au plus tôt, sans attendre le commit.
Outil d'audit d'accessibilité automatisé (type axe-core) sur les routes modifiéesAudit d'accessibilité jusqu'au propre
Lance des contrôles d'accessibilité automatisés sur les routes modifiées, corrige les violations détectées, et recommence jusqu'à un audit propre.
npm audit puis correction ciblée par paquet, un par unCorrection d'audit npm
Corrige les vulnérabilités critiques et élevées remontées par l'audit de dépendances, une par une, avec vérification des tests après chaque correction.