Loop Engineering dans MCPlato : des prompts aux workflows qui laissent des Artifacts

Réponse d'abord : Loop Engineering ne consiste pas à écrire un prompt plus long. Il s'agit de concevoir une boucle de travail capable d'observer ses entrées, de conserver un état, de s'arrêter à des checkpoints, de récupérer après un échec, de demander une approbation humaine et de laisser derrière elle un Artifact inspectable. Dans MCPlato, cette boucle peut devenir un Wand, un Skill, une Scheduled Task, un workflow de canal ou un ensemble de sessions coordonnées par Sprite.

Illustration de couverture de Loop Engineering dans MCPlato

Figure 1 : Loop Engineering transforme les demandes IA ponctuelles en cycles de travail qui produisent des Artifacts durables.

Prompt Engineering demande : comment dois-je demander ? Loop Engineering demande : comment l'IA doit-elle continuer à travailler en sécurité jusqu'à ce que l'Artifact soit terminé ?

Cette distinction compte, car le vrai travail se termine rarement en une seule réponse. Les mainteneurs ont besoin de correctifs accompagnés de preuves de test ; les responsables produit ont besoin de briefings avec sources et horodatages ; les équipes opérationnelles ont besoin de dossiers de rapports avec pistes d'audit ; les dirigeants métier ont besoin d'une approbation avant les actions externes ou destructrices.

La bonne unité de conception est donc la boucle.

La méthode de conception de boucle dans MCPlato

Une bonne boucle possède trois propriétés :

1. Observable : l'utilisateur peut voir les sources, l'état, les actions et les résultats.
2. Récupérable : le travail peut reprendre depuis un checkpoint au lieu de repartir de zéro ou de se répéter.
3. Centrée sur l'Artifact : la boucle se termine par quelque chose d'inspectable : un rapport, un diff, une feuille de calcul, un paquet, un journal de décision, un briefing, un brouillon ou un enregistrement de revue.

MCPlato correspond naturellement à ce modèle :

• Wand : un workflow empaqueté pour une tâche répétable, avec des phases, des conseils et un runtime visible orienté Artifact.
• Artifact : la sortie durable qui prouve que la boucle a accompli un travail utile.
• Sprite : le coordinateur qui peut répartir le travail entre plusieurs sessions et rassembler les résultats.
• Skill et Distill Skill : un savoir-faire réutilisable qui peut être invoqué de nouveau après qu'une boucle a fait ses preuves.
• ClawMode : une façon de faire continuer le travail à travers le temps, les canaux et les contextes d'arrière-plan.
• Scheduled Tasks et Channels : des déclencheurs et chemins de livraison pour les boucles récurrentes.
• Autorisations et checkpoints : des limites qui maintiennent sous contrôle une autonomie utile.

Une boucle MCPlato pratique suit généralement neuf étapes :

Le reste de cet article applique la méthode à quatre scénarios de demande utilisateur réels trouvés dans des discussions et documentations publiques.

Scénario 1 : GitHub issue -> PR de correction -> rapport QA étayé par des preuves

Les mainteneurs open source expérimentent déjà des agents capables de prendre en charge des GitHub issues et de tenter des corrections bornées. OpenHands décrit un GitHub resolver pour les issues de dépôts, et sa documentation QA se concentre sur la validation des changements plutôt que sur la simple production de code.¹² Les mainteneurs ont besoin d'un patch, de tests et de preuves que le changement est suffisamment sûr pour être revu.

Un risque lié apparaît dans des retours réels de développeurs. Une GitHub issue de Continue rapporte qu'un agent bouclait à répétition sur le même code au lieu de s'arrêter proprement.³ C'est le mode d'échec que Loop Engineering doit traiter : une itération incontrôlée sans condition d'arrêt.

Boucle d'une GitHub issue vers des preuves QA

Figure 2 : Une boucle d'ingénierie bornée doit produire un diff, des journaux de validation et un Artifact de preuves QA, pas seulement l'affirmation que l'issue est corrigée.

La conception de la boucle

Dans MCPlato, la boucle doit partir de l'Artifact, pas de la sortie du modèle :

1. Réception de l'issue : collecter l'issue, les fichiers liés, les notes de reproduction et les contraintes du dépôt.
2. Checkpoint de plan : demander à l'utilisateur ou au mainteneur d'approuver le périmètre prévu avant toute modification.
3. Phase de patch : effectuer le plus petit changement raisonnable dans une zone de travail limitée.
4. Phase de validation : exécuter les contrôles convenus, enregistrer les échecs et ne réessayer que dans le périmètre approuvé.
5. Artifact de preuve : produire un rapport QA avec les fichiers modifiés, les journaux de tests, les captures d'écran si pertinentes et les risques restants.
6. Porte de revue : préparer un brouillon de description de PR ou MR, sans présenter le travail comme fusionné ou accepté.
7. Distill : si le modèle fonctionne, le transformer en Skill QA de dépôt réutilisable ou en Wand pour l'équipe.

Modèle de mise en oeuvre MCPlato

Une configuration coordonnée par Sprite est utile ici. Une session peut lire l'issue et rédiger le plan, une autre peut inspecter le dépôt, une autre peut valider, et la session finale peut assembler l'Artifact de preuves QA. Un Wand peut empaqueter les phases afin que l'équipe n'ait pas à réinventer la boucle pour chaque issue.

Le garde-fou important est la condition d'arrêt : la boucle doit s'arrêter lorsque le budget de validation est épuisé, lorsque le même échec se répète ou lorsque le changement dépasserait le périmètre approuvé. L'Artifact doit dire exactement ce qui s'est passé, sans masquer l'incertitude.

Artifact : résumé de diff, journaux de tests, rapport de preuves QA, brouillon de description PR/MR et liste de risques.

Scénario 2 : Briefing de recherche planifié qui livre le résultat complet

La recherche récurrente est un autre domaine où « prompt once » est trop faible. Des utilisateurs discutant de tâches IA planifiées ont demandé que les résultats complets soient envoyés par e-mail, et pas seulement des notifications d'achèvement.⁴ L'aperçu de Zapier sur les ChatGPT scheduled tasks décrit le modèle consistant à demander à ChatGPT d'exécuter des prompts dans le futur ou selon une cadence récurrente.⁵ L'écart pratique porte sur la qualité de livraison : une boucle planifiée utile doit produire un briefing avec liens, horodatages, deltas et actions à mener.

Boucle de livraison de briefing planifié

Figure 3 : Une boucle planifiée doit collecter les sources, dédupliquer, synthétiser, vérifier les citations et livrer l'Artifact de briefing complet au bon canal.

La conception de la boucle

Une boucle de briefing MCPlato peut être :

1. Déclencheur planifié : s'exécuter chaque jour, chaque semaine ou avant une réunion récurrente.
2. Collecte des sources : collecter des sources approuvées comme des URL enregistrées, des flux de type RSS, des pages de documentation ou des matériaux de workspace.
3. Pertinence et déduplication : retirer les annonces répétées et les éléments à faible signal.
4. Synthèse : rédiger le briefing dans un format stable.
5. Vérification des citations : s'assurer que chaque affirmation concrète renvoie à une URL source.
6. Sortie Artifact : créer un briefing daté avec une liste de sources et un tableau d'actions.
7. Livraison au canal : envoyer l'Artifact complet ou un résumé concis avec un lien vers l'Artifact.
8. Suivi : permettre à l'utilisateur de demander une analyse plus approfondie, d'assigner les prochaines actions ou de distiller la boucle de briefing.

Modèle de mise en oeuvre MCPlato

C'est ici que Scheduled Tasks, ClawMode et les canaux fonctionnent ensemble. La Scheduled Task déclenche la boucle ; MCPlato rassemble le contexte approuvé, produit l'Artifact et le livre au workspace ou au canal. Sprite peut coordonner des workers séparés pour la collecte des sources, la synthèse et la revue des citations lorsque le briefing est à fort enjeu.

Une boucle de briefing ne doit jamais prétendre avoir lu des sources auxquelles elle n'a pas réellement accédé. L'Artifact doit inclure « introuvable » ou « non vérifié » lorsque l'information n'est pas disponible. Cet état honnête est plus utile qu'un paragraphe poli mais invérifiable.

Artifact : briefing quotidien ou hebdomadaire, liste des sources, tableau d'actions, delta depuis l'exécution précédente et notes de citation.

Scénario 3 : Connexion navigateur, remplissage de paramètres, téléchargement de rapports et organisation locale

De nombreux workflows métier vivent encore derrière des pages web plutôt que derrière des API propres. Une question Stack Overflow demande comment automatiser la connexion à une page web et le téléchargement d'un rapport.⁶ Dans une discussion Python.org, un utilisateur décrit le téléchargement de rapports pour environ 50 clients, avec 3 à 4 rapports chacun, ce qui prend 3 à 4 heures chaque semaine à la main.⁷ C'est un vrai point de douleur opérationnel : répétitif, lié au navigateur et facile à mal exécuter.

Boucle de téléchargement de rapports dans le navigateur

Figure 4 : L'automatisation navigateur doit séparer les limites de connexion humaine des étapes répétées de paramètres, téléchargement, validation et organisation.

La conception de la boucle

Une boucle sûre de rapports navigateur doit expliciter les limites d'accès :

1. Réception des besoins : lister les noms de clients, types de rapports, plages de dates et fichiers attendus.
2. Limite d'accès : décider ce que l'utilisateur doit faire manuellement, comme la connexion, la MFA ou le CAPTCHA.
3. Découverte et vérification API : vérifier s'il existe un export documenté ou une API avant d'utiliser l'automatisation navigateur.
4. Automatisation navigateur : remplir les paramètres, lancer les téléchargements et enregistrer chaque étape.
5. Validation : vérifier les noms de fichiers, horodatages, nombres attendus et fichiers manifestement vides.
6. Transformation : normaliser les dossiers, convertir les formats lorsque c'est approprié et créer des synthèses.
7. Rapport d'exception : lister les téléchargements manquants, les clients échoués ou les pages qui ont changé.
8. Répétition planifiée : n'exécuter que la partie répétable selon une cadence, avec un checkpoint humain lorsque les identifiants ou la structure des pages changent.

Modèle de mise en oeuvre MCPlato

MCPlato ne doit pas être présenté comme « capable de gérer n'importe quel site web ». Les sites diffèrent, les connexions changent, les politiques comptent, et certains flux résistent intentionnellement à l'automatisation. Le meilleur cadrage est le suivant : MCPlato peut aider à concevoir une boucle contrôlée autour des parties autorisées et répétables.

L'utilisateur peut gérer le checkpoint de connexion. La boucle IA peut ensuite opérer dans la session navigateur approuvée, télécharger les rapports, organiser les fichiers locaux et produire un Artifact d'exception. Si le site web change, la boucle doit s'arrêter et signaler l'écart au lieu de deviner.

Ce type de boucle mérite souvent d'être distillé en Wand après quelques exécutions réussies. Le Wand devient le processus répétable de « dossier de rapports mensuel » de l'équipe, avec des phases claires et un dossier de sortie plutôt qu'une transcription fragile.

Artifact : dossier de rapports téléchargés, liste succès/échec, structure de dossiers normalisée, feuille de calcul de synthèse et rapport d'exception.

Scénario 4 : Approbation humaine pour les appels d'outils risqués

Loop Engineering ne consiste pas seulement à faire plus. Il consiste aussi à savoir quand s'arrêter. Une issue LangGraph demande un modèle d'approval-node où les utilisateurs peuvent approuver, rejeter ou modifier des actions avant exécution.⁸ La documentation human-in-the-loop de LangChain décrit la pause pour revue autour des appels d'outils.⁹

Les exemples de risque sont familiers : écrire des fichiers, exécuter du SQL, supprimer des données, publier du contenu ou envoyer un e-mail. Ce ne sont pas seulement des « étapes d'agent ». Ce sont des actions métier.

Boucle de porte d'approbation humaine

Figure 5 : Une bonne boucle s'arrête avant les actions risquées, enregistre la décision et laisse des preuves après l'exécution.

La conception de la boucle

Une boucle d'action risquée doit ressembler à ceci :

1. Classification du risque : déterminer si la prochaine action est en lecture seule, réversible, tournée vers l'extérieur, destructrice ou financière.
2. Brouillon d'action : préparer le changement de fichier, l'instruction SQL, l'e-mail, le post ou la commande sans l'exécuter.
3. Checkpoint d'approbation : montrer à l'utilisateur l'action prévue, la raison, l'effet attendu et le plan de rollback.
4. Décision utilisateur : approuver, modifier, rejeter ou demander plus de contexte.
5. Exécution : exécuter uniquement l'action approuvée.
6. Artifact de preuve : enregistrer la décision, le diff avant/après, le résultat d'exécution et le risque restant.

Modèle de mise en oeuvre MCPlato

Le vocabulaire de boucle de MCPlato rend cela simple. Un Wand peut séparer la rédaction de l'exécution. Les autorisations peuvent être plus étroites avant l'approbation et plus larges seulement après confirmation. Sprite peut demander à une autre session de revoir l'action proposée avant qu'elle ne soit montrée à l'utilisateur. ClawMode et les canaux peuvent porter la demande d'approbation là où l'utilisateur travaille.

La boucle ne doit jamais normaliser des valeurs par défaut dangereuses. Supprimer des données, envoyer des messages externes, modifier la facturation ou publier du contenu doit exiger une porte, sauf si l'utilisateur a explicitement conçu un workflow fiable et borné pour cette action.

Artifact : registre d'approbation, plan de changement, diff avant/après, brouillon de message ou d'e-mail, preuve d'exécution et liste de risques.

Transformer une boucle réussie en capacité MCPlato réutilisable

Après qu'une boucle réussit une fois, il ne faut pas tout automatiser immédiatement. Demandez d'abord :

1. L'Artifact était-il utile ? Si la sortie n'a pas aidé l'utilisateur à prendre une décision ou à terminer le travail, la boucle n'est pas prête.
2. Les checkpoints étaient-ils au bon endroit ? Trop de checkpoints rendent la boucle agaçante ; trop peu la rendent dangereuse.
3. Un autre utilisateur pourrait-il l'exécuter sans contexte caché ? Si la réponse est non, documentez les entrées et hypothèses requises.

Choisissez ensuite le bon chemin d'empaquetage MCPlato :

La direction récente de la branche principale de MCPlato renforce ce passage du chat vers un travail empaqueté et observable. Les Wands rendent les workflows explicites. Les vues runtime orientées Artifact gardent le résultat visible. Les conseils de création et d'itération de Wand facilitent la transformation d'une boucle réussie en capacité réutilisable. Skills et Distill Skill préservent les parties répétables de la méthode.

Le principe est simple : ne sauvegardez pas seulement la réponse ; sauvegardez la boucle de travail qui a créé la réponse.

Risques et garde-fous

Loop Engineering est puissant, mais il peut échouer de manières prévisibles :

• Itération incontrôlée : ajouter des budgets, la détection d'échecs répétés et des états de sortie explicites.
• Fausse complétion : exiger un Artifact avec journaux, sources ou preuve avant/après.
• Glissement des autorisations : attribuer les autorisations par phase.
• Contexte caché : enregistrer les hypothèses dans l'Artifact.
• Sur-automatisation : ajouter des checkpoints d'approbation pour les étapes risquées.
• Flux navigateur fragiles : utiliser la validation et les rapports d'exception plutôt que les suppositions silencieuses.
• Dérive des citations : exiger des horodatages de sources et une revue des citations.

Une bonne boucle n'est pas celle qui a le plus d'autonomie. Une bonne boucle est celle qui termine l'Artifact tout en rendant son travail suffisamment visible pour qu'on puisse lui faire confiance.

FAQ

Qu'est-ce que Loop Engineering ?

Loop Engineering est la pratique qui consiste à concevoir le travail IA comme un processus avec état plutôt que comme une réponse unique. La boucle définit l'objectif, les entrées, les phases, les autorisations, les checkpoints, le chemin de récupération et l'Artifact final.

En quoi est-ce différent de Prompt Engineering ?

Prompt Engineering améliore l'instruction. Loop Engineering améliore le système de travail autour de l'instruction. Un meilleur prompt peut produire une meilleure première réponse. Une meilleure boucle peut continuer, valider, s'arrêter, récupérer et livrer.

Où MCPlato intervient-il ?

MCPlato est utile lorsque le travail couvre des sessions, des fichiers, un contexte navigateur, des calendriers, des canaux et des sorties durables. Son vocabulaire de boucle, avec Wand, Artifact, Sprite, Skill, ClawMode, Scheduled Tasks, canaux, autorisations et checkpoints, aide à transformer un travail ponctuel utile en capacité répétable.

Chaque tâche IA doit-elle devenir une boucle ?

Non. Les questions simples peuvent rester des questions simples. Utilisez Loop Engineering lorsque la tâche est longue, répétée, risquée, riche en preuves ou centrée sur un Artifact.

Loop Engineering garantit-il l'exactitude ?

Non. Il améliore l'observabilité, la récupération et la revue. La boucle peut toujours utiliser de mauvaises sources, formuler de mauvaises hypothèses ou échouer sur des outils modifiés. C'est pourquoi les citations, checkpoints et rapports d'exception comptent.

Références

Footnotes

1. OpenHands : agents de codage open source dans votre GitHub, corrigeant vos issues ↩

2. Documentation OpenHands : QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community : envoyer les résultats complets des ChatGPT tasks par e-mail, pas seulement des notifications ↩

5. Zapier : comment utiliser les ChatGPT scheduled tasks ↩

6. Stack Overflow : existe-t-il un moyen d'automatiser la connexion à une page web et le téléchargement d'un rapport ? ↩

7. Discussion Python.org : utiliser Selenium pour télécharger automatiquement des rapports depuis un site web ↩

8. LangGraph issue #8026 : ApprovalNode ↩

9. Documentation LangChain : Human-in-the-loop ↩