En juin 2026, Boris Cherny, le créateur de Claude Code chez Anthropic, a déclaré à The New Stack qu'il ne promptait plus Claude directement : il écrit des loops. Ce sont elles qui promptent Claude, décident quoi faire, et enchaînent les étapes. Addy Osmani (Google Chrome) a baptisé cette pratique loop engineering, et le terme a immédiatement pris dans les cercles dev.

Bon timing. Parce que la pratique elle-même existait déjà.

La généalogie du prompt

Avant de parler de loops, il faut parler de prompts. D'où viennent-ils ?

Les interfaces de chat ont imposé un modèle précis : on tape une instruction, on attend une réponse, on retape. Les développeurs ont naturellement commencé à sauvegarder leurs instructions répétitives : les prompts système, les formats d'output attendus, les contraintes récurrentes. C'était déjà un loop manuel. "On tape ça, puis ça, puis ça." L'interface de chat limitait juste ce qu'on pouvait faire au-delà.

Le prompt n'a jamais été une unité atomique d'IA. C'était une unité d'interface. Une instruction dans un formulaire de chat.

n8n avait déjà les loops

Des outils comme n8n ont des loops depuis des années : trigger, nœuds, output récurrent. Ce qui manquait, c'étaient des nœuds agentiques. Ils les ont ajoutés.

La structure reste identique. Ce qui change, c'est la nature de certains nœuds : non-déterministes, ils décident eux-mêmes quelle branche prendre selon le contexte. Ce n'est pas une révolution d'architecture. C'est une évolution de la nature des nœuds.

Le loop engineering n'invente pas une nouvelle topologie. Il équipe une topologie existante avec des nœuds capables de raisonner.

Claude Code démocratise la mécanique

Ce que Claude Code change, c'est l'accessibilité. On peut maintenant créer une loop sans configurer n8n, sans dessiner de workflow, sans connecteur entre outils. Le principe reste identique : étapes scriptées ou LLM, trigger récurrent, résultat automatisé. La barrière d'entrée disparaît.

C'est un gain réel. Un développeur solo peut aujourd'hui orchestrer plusieurs agents en parallèle sur plusieurs projets sans infrastructure dédiée. Ce qui prenait une stack DevOps entière se script en quelques fichiers.

KittyClaw n'est pas né d'une vision loop

KittyClaw n'est pas né d'une réflexion théorique sur le loop engineering. Il est né d'un besoin concret : capturer des idées sans les perdre, les prioriser, déléguer (rédaction, tests, fact-check, images, conflits de merge), et savoir instantanément, en regardant le Kanban, ce qui avance, ce qui bloque, ce qui est passé en prod.

Pas une vision. Un besoin.

Et c'est là que la plupart des discours actuels sur le loop engineering passent à côté de quelque chose d'essentiel.

Le cockpit est la pièce manquante

Le débat actuel se concentre sur l'automatisation des prompts. Ce qu'il oublie, c'est l'autre moitié du problème : une loop autonome sans interface humaine de feedback est une boîte noire.

Sans retour, on ne sait pas ce qui est passé en prod. On ne sait pas ce qui attend un déblocage. On ne sait pas ce qui n'aurait pas dû être fait. C'est l'équivalent de dire à un employé de faire tourner la boutique sans jamais lui donner le moindre retour, sans jamais regarder ce qu'il produit.

Le loop engineering résout le problème amont : automatiser l'exécution. Il ne résout pas le problème aval : comprendre ce qui s'est passé et décider de la suite.

KittyClaw est exactement cette pièce manquante. Le cockpit de la loop.

Deux niveaux de feedback

La distinction est importante, parce qu'il ne s'agit pas d'un seul type de feedback.

Feedback opérationnel : le Kanban. Tick à tick. En temps réel. Est-ce que l'agent a progressé ? Est-il bloqué ? Qu'est-ce qu'il attend ? Le Kanban répond à ces questions sans avoir à aller lire les logs. C'est le feedback de l'exécution en cours.

Feedback stratégique : le Dashboard. Métriques, KPIs, calendrier éditorial. Est-ce que le rythme de publication tient ? Est-ce que les tickets s'accumulent ? Est-ce qu'un projet stagne ? Le Dashboard répond à ces questions pour les décisions de fond, pas pour le suivi tick à tick.

Les deux ensemble ferment vraiment la boucle. Sans l'un, on perd le fil en cours d'exécution. Sans l'autre, on perd la direction.

Ce que le loop engineering est, et ce qu'il n'est pas

Le loop engineering est une discipline d'ingénierie réelle. Concevoir une loop, c'est un travail de fond : définir les agents, les triggers, les conditions d'arrêt, les cas de blocage, les transitions. Ce n'est pas configurer un chatbot. C'est concevoir un système autonome qui va prendre des décisions.

Mais l'autonomie n'est pas une fin en soi. Une loop sans cockpit n'est pas une loop mature. C'est une loop aveugle.

Fermer la boucle de feedback, c'est ce qui transforme une expérience d'automatisation en système de production. Et c'est exactement ce que le discours actuel oublie.