« Loop engineering » : nouvelle discipline ou re-marketage des cron jobs ?

Le terme monte, l'enquête du Pragmatic Engineer conclut à un mélange de triggers, de cron jobs et de slop LLM. Reste une vraie question de fond : qui possède la robustesse d'une boucle observe-décide-agit alimentée par LLM ?

Le fait

Le Pragmatic Engineer (Gergely Orosz) publie le 14/07/26 une enquête sur le terme « loop engineering », qui remonte dans le vocabulaire des équipes IA. Sa conclusion, telle que résumée en tête d'article : sous le mot, on retrouve un mélange de triggers, de cron jobs, d'orchestration LLM et de « slop » - et une part d'effet de mode.

Notre lecture

Le mot n'est pas neuf. Ce qu'il condense l'est un peu plus : quand un système répète en boucle un cycle observe → décide → agit alimenté par un LLM, qui porte la responsabilité de la robustesse de la boucle ? Pas le modèle, qui n'a pas d'état entre tours. Pas le devops classique, qui ne connaît pas la non-déterminisme fine. Un nouveau créneau émerge : instrumenter les runs, contenir les dérives, gérer les retries idempotents, mesurer le coût par tour, prévoir le rollback quand une décision engage un système externe. Ces sujets sont déjà traités par le SRE d'agent - le vocabulaire cherche seulement à les nommer, ce qui est un signe d'adoption plutôt qu'un signe de mode.

À surveiller

Le vrai signal ne sera pas la profusion d'outils portant le mot « loop » sur leur landing page. Ce sera l'apparition de postmortems publics qui parlent explicitement de « loop failure » - dérive, retry-storm, boucle coûteuse - plutôt que d'« hallucination ». Ce jour-là, la discipline aura pris.