Looptor transforme n'importe quelle tâche en boucle FIABLE, OBSERVABLE et AUTO-TERMINANTE. Deux principes ne se négocient jamais.
Les 2 règles cardinales
1. Jamais de boucle sans but vérifiable. 2. Jamais de boucle sans condition d'arrêt.
But vérifiable, pas but flou
Un but se formule « terminé quand <check observable> » — un statut, une valeur, la présence d'un fichier. Jamais « quand ça marche ».
| ❌ Flou | ✅ Vérifiable |
|---|---|
| « jusqu'à ce que ça marche » | « terminé quand les tests sortent en code 0 » |
| « surveiller la CI » | « terminé quand statut CI ∈ {success, failure} » |
| « attendre le rapport » | « terminé quand rapport.pdf est présent » |
Les 4 primitives réelles (Claude Code)
Règle d'honnêteté : on n'enseigne que ce qui existe vraiment. Ces primitives appartiennent à Claude Code — ChatGPT et Gemini n'ont pas d'équivalent cron/monitor natif.
| Primitive | Rôle |
|---|---|
/loop | Cadence fixe (cron) ou mode dynamique auto-cadencé. |
ScheduleWakeup | Réveil temporel programmé ; sert aussi de filet de sécurité. |
Monitor | Réveil sur événement (CI, log, fichier, PR). |
/schedule | Boucle cloud durable, survit à la fermeture de session. |
Fenêtre de cache (5 min) : 270s pour rester « chaud », 1200–1800s sinon. On évite 300s — le pire des deux mondes.
Les 8 champs de conception
- 1. But vérifiable — « terminé quand <check observable> ».
- 2. Unité d'itération — ce qui se passe à chaque tour.
- 3. Signal de réveil — temporel/événementiel + justification du délai.
- 4. Condition d'arrêt + plafond — anti-boucle-infinie.
- 5. Politique d'échec — relance bornée (×3) puis escalade/arrêt. Jamais de relance aveugle.
- 6. Garde-fous — point de contrôle pour toute action sortante.
- 7. Commande —
/loop …ou/schedule …(Claude Code) ; prompt itératif ailleurs. - 8. Risques résiduels — 1 à 3 points de vigilance.
Boucles vs Graphes
Il y a quelques semaines, tout le monde parlait de boucles. Aujourd'hui, ce sont les graphes. Les deux vivent ou meurent selon une seule chose : le cerveau de votre entreprise — le contexte partagé. Cette semaine, Shann Holmberg a partagé comment il pilote son marketing avec des graphes. Voici la différence, sur un même travail : résoudre un ticket de support.
| — | 🔁 Boucle | ⁝⁚ Graphe |
|---|---|---|
| Qui trace le chemin | L'agent — vous donnez un objectif et une barre | Vous — vous dessinez les nœuds |
| Déroulé (ticket) | rédige → vérifie → corrige, et boucle jusqu'à résolu | lire → trier → rédiger → QA → envoyer, un point de contrôle à chaque étape |
| Étapes choisies par | l'agent (vous ne les choisissez pas) | vous — la carte est la vôtre, l'agent remplit chaque boîte |
| Quand | travail ponctuel, chemin pas encore clair → explorer | travail répétable, étapes connues → verrouiller & scaler |
Le cerveau de l'entreprise (contexte partagé)
Chacun de ces nœuds puise au même endroit. Le tri a besoin des tickets passés ; la rédaction, de la politique et des docs produit. Ce contexte partagé — le cerveau de votre entreprise — est ce que chaque boîte atteint au fur et à mesure que le travail avance. Le cerveau détient la carte ; le graphe est ce processus, rendu explicite.
Alors, quand utiliser quoi ?
Boucle → travail ponctuel, sans chemin clair encore : laissez l'agent le découvrir.
Graphe → travail répétable dont vous connaissez déjà les étapes : verrouillez-les.
Les boucles servent à explorer. Les graphes servent à scaler.
Composez l'un ou l'autre : Loop générateur pour une boucle, Graph générateur pour dessiner un graphe (nœuds + points de contrôle).
Exemple résolu
Cas « dev » — surveiller la CI d'une PR
CI = intégration continue (contrôle automatique qui rend success/failure). PR = pull request (proposition de modification soumise à validation).
| Champ | Valeur |
|---|---|
| But vérifiable | statut CI ∈ {success, failure} via gh |
| Réveil | événementiel (Monitor sur le run) + filet ScheduleWakeup(1500) |
| Arrêt | dès statut terminal OU 20 itérations |
| Garde-fous | lecture seule → aucun point de contrôle |
| Commande | /loop surveille la CI de la PR #123 et préviens-moi à la fin |
Équivalent métier — surveiller le Journal Officiel
Même logique, sans jargon dev : « Surveiller la parution d'un texte au JO et prévenir dès qu'il paraît. » But vérifiable = le texte correspondant au mot-clé est présent ; réveil temporel ou événementiel ; arrêt à la détection.
⚠ Pas d'hallucination de mécanisme
Seul Claude Code possède /loop, Monitor & co. Pour ChatGPT ou Gemini, le générateur produit un patron de prompt itératif (but vérifiable + condition d'arrêt) — il n'invente jamais une commande inexistante.