Exécutions d'agents gérées

Les exécutions d'agents gérées vous permettent de lancer des agents IA autonomes directement depuis Archyl. Donnez-leur une tâche, choisissez le profil qui définit leur comportement, connectez-les à des services externes via des connecteurs MCP, définissez un calendrier récurrent, et laissez-les travailler sur votre codebase avec un contexte architectural complet.

Rendez-vous dans Hub Agent → Exécutions dans la barre latérale pour gérer vos exécutions, dans Hub Agent → Profils pour définir le comportement des agents, ou dans Hub Agent → Planifications pour l'automatisation récurrente.

Présentation

Une exécution gérée correspond à une seule invocation d'agent. L'agent :

1. Clone le dépôt de votre projet dans un espace de travail vierge sur le worker d'agents
2. Reçoit votre contexte architectural (modèle C4, ADRs, règles de conformité, contrats d'API, pile technologique) ainsi que le briefing de sa session de travail : les éléments touchés par la tâche, ce que les sessions précédentes ont appris à leur sujet et le verdict du preflight
3. Exécute la tâche que vous avez définie, en appelant des outils et en prenant des décisions dans les limites de son profil
4. Publie ses modifications de code sous forme de pull request et rend compte avec une trace complète de chaque action

Les exécutions peuvent être déclenchées manuellement (ponctuelles) ou automatiquement via des planifications.

Lancer une exécution

1. Allez dans Hub Agent → Exécutions
2. Sélectionnez votre projet dans le menu déroulant
3. Cliquez sur Nouvelle exécution
4. Choisissez un profil
5. Rédigez une description de tâche (par exemple, "Vérifier les dépendances obsolètes et créer un résumé")
6. Attachez éventuellement des connecteurs (voir ci-dessous)
7. Cliquez sur Lancer l'exécution

L'agent commence à travailler immédiatement. Vous pouvez suivre la progression en temps réel sur la page de détail de l'exécution.

Profils d'agents

Un profil est une définition réutilisable du comportement d'un agent. Chaque exécution et chaque planification en utilise un. Archyl crée un profil backend-fixer pour votre organisation lors de votre première visite ; créez-en d'autres dans Hub Agent → Profils.

Supprimer un profil conserve l'historique des exécutions qu'il a produites. Les planifications qui l'utilisaient sont mises en pause et marquées Profil supprimé ; choisissez un autre profil dans la planification pour la reprendre.

Skills

Les skills sont des playbooks maintenus par Archyl, toujours alignés sur les outils dont les agents disposent réellement. Activez-les par profil plutôt que de recopier des instructions dans le prompt.

Un profil avec une skill inconnue ou un motif d'outils autorisés invalide est refusé à l'enregistrement.

Le profil par défaut backend-fixer active Architecture memory, Conformance first et Decision records.

Page de détail d'une exécution

Chaque exécution dispose d'une page de détail affichant :

Le fil d'événements affiche des cartes dépliables pour chaque action :

• Appels d'outils — Affiche le nom de l'outil, les paramètres d'entrée et la sortie. Chaque carte indique un libellé de source précisant de quel connecteur l'outil provient (par exemple, github, archyl, linear).
• Messages — Le raisonnement et les décisions de l'agent.
• Résultat — L'issue, la consommation de tokens, la pull request et les fichiers modifiés par l'agent.
• Erreurs — Mises en évidence pour une identification rapide.

Orienter un agent en cours d'exécution

Pendant qu'une exécution est en cours, tapez un message dans la zone d'orientation pour réorienter l'agent sans l'annuler ("laisse tomber la migration, concentre-toi sur le handler"). Le message est mis en file immédiatement et injecté dans la conversation de l'agent à son étape suivante ; le fil affiche Message de pilotage transmis à l'agent une fois que l'agent l'a reçu.

Quand une exécution s'arrête avant la fin

Si une exécution échoue, atteint sa limite de coût ou de temps, ou épuise ses itérations, le travail déjà accompli n'est pas perdu : Archyl le publie sous forme de pull request en brouillon qui explique pourquoi l'exécution s'est arrêtée. Voir Pull request plus bas. Une exécution que vous annulez ne publie rien.

Garanties de fiabilité

• Les workers tombés sont détectés. Le worker d'agents donne signe de vie toutes les 10 secondes. Une exécution dont le worker est silencieux depuis 3 minutes, ou qui tourne encore 10 minutes après sa limite de temps, est automatiquement marquée failed et sa place est libérée.
• Les exécutions bloquées n'occupent pas de place. Une exécution qu'aucun worker d'agents n'a prise en charge dans les 10 minutes échoue, de même qu'une exécution qui a attendu la réponse d'un humain pendant plus d'1 heure et 10 minutes.
• Les identifiants ne survivent pas aux exécutions. Chaque exécution reçoit sa propre clé d'API Archyl à courte durée de vie, révoquée dès la fin de l'exécution.
• L'annulation atteint l'agent. Une exécution annulée s'arrête à son prochain signal de vie, même si la demande d'arrêt directe n'a jamais atteint le worker.

Sessions de travail et coordination

Chaque exécution est encadrée par une session de travail Archyl, le protocole que le harness Archyl apporte aux agents de code locaux. La plateforme ouvre et ferme la session ; l'agent ne la gère jamais.

La session de travail d'une exécution

Au lancement d'une exécution, Archyl ouvre une session sur les éléments d'architecture que touche la tâche. Il pose des réservations sur ces éléments, calcule le verdict du gate de preflight (allow, warn ou deny) et place les décisions, garde-fous et mémoires pertinents dans le briefing de l'agent. Le verdict apparaît dans le fil d'événements sous la forme d'un événement Contrôle.

Respecter le travail des autres agents

Respecter le travail des autres agents est un paramètre de profil, dans la rubrique Coordination, désactivé par défaut. Lorsqu'il est activé, la session est ouverte en exclusivité :

• Quelqu'un d'autre détient les éléments. Si un autre agent détient une réservation sur les mêmes éléments, qu'il s'agisse d'un agent de code comme Claude Code ou d'une autre exécution gérée, l'exécution est refusée. Le motif indique qui travaille dessus.
• Le gate ne fait qu'avertir, par exemple parce qu'un garde-fou de niveau erreur s'applique. L'exécution passe au statut En attente d'approbation, sans occuper de place d'exécution simultanée. La page de l'exécution affiche les motifs, avec Approuver et démarrer et Annuler l'exécution.

L'approbation vérifie à nouveau le gate : un conflit apparu entre-temps refuse quand même l'exécution. Une exécution que personne n'approuve sous 24 heures est annulée.

Paramètre désactivé, l'exécution démarre quel que soit le verdict du gate ; l'agent en lit les motifs dans son briefing.

Guard sur les écritures de fichiers

Dès que l'agent travaille dans un dépôt, lié au projet ou ouvert via le connecteur GitHub, chaque appel à write_file et edit_file est vérifié par rapport aux règles de conformité du projet avant que la modification ne soit appliquée :

Si la vérification elle-même échoue, l'écriture passe : le Guard ne bloque jamais un agent à cause de ses propres erreurs. Il se comporte comme le hook Guard des agents de code locaux, décrit dans le guide du harness.

Bilan de la session de travail

Avant de terminer, l'agent rend compte de son résultat : un résumé, ses décisions, les suites à donner et les mémoires sur lesquelles il s'est appuyé. À la fin de l'exécution, Archyl :

1. Attribue les fichiers modifiés à la session, ce qui montre sur quels éléments réservés le travail a réellement porté
2. Ferme la session et enregistre le résumé comme mémoire sur ces éléments
3. Enregistre les décisions comme mémoire du projet et ouvre une demande de changement d'architecture en brouillon pour relecture. Seule une exécution réussie enregistre des décisions

La page de l'exécution affiche une carte Bilan de la session de travail avec le résumé, les décisions, les suites à donner, les éléments touchés et un lien vers la demande de changement. Les éléments détenus par une autre session sont signalés Détenu par une autre session de travail.

Suivre une exécution en direct

Une page d'exécution propose deux vues : Activité, le fil d'événements, et Modifications, les fichiers écrits par l'agent. Quand l'agent a besoin de vous, un bandeau au-dessus indique ce qu'il attend (En attente de votre relecture du plan ou L'agent a une question) et vous y amène.

Le plan

Avant de modifier quoi que ce soit, l'agent partage un plan : un résumé en une phrase et une poignée d'étapes concrètes, 12 au maximum. Le panneau Plan, en haut de la page de l'exécution, en fait une checklist. L'agent marque chaque étape En cours, Terminée ou Ignorée, parfois avec une courte note, et le panneau affiche l'étape en cours et la progression (3/7).

Relire le plan d'abord est un paramètre de profil, dans la rubrique Coordination, désactivé par défaut. Lorsqu'il est activé, l'agent attend une relecture avant de modifier quoi que ce soit :

1. Le panneau passe en mode Relire le plan. Vous pouvez renommer les étapes, ajouter des détails, et ajouter, supprimer ou réordonner des étapes.
2. Approuver le plan (Approuver le plan modifié une fois que vous l'avez modifié) laisse l'agent poursuivre. Votre version modifiée devient le plan que l'agent suit et que la checklist reflète.
3. Demander des modifications transmet vos remarques. L'agent révise le plan et vous propose une nouvelle révision à relire. Les révisions précédentes restent dans le fil.

Tant qu'aucun plan n'est approuvé, l'agent peut lire mais ne peut rien modifier : l'écriture de fichiers et tout outil qui crée, met à jour, supprime, lie, importe, pousse ou fusionne (sur Archyl et sur chaque connecteur, par exemple linear__create_issue) sont refusés, tout comme remember. L'agent est invité à attendre la relecture.

Questions

Lorsqu'une décision demande l'avis d'un humain, par exemple une exigence ambiguë, un compromis sans option clairement meilleure ou une opération destructrice, l'agent pose la question. Elle apparaît au-dessus du fil, avec des Réponses suggérées lorsque l'agent en propose, et une zone de réponse libre (Cmd/Ctrl + Enter pour l'envoyer). Toute personne pouvant modifier le projet peut répondre, et le fil indique qui l'a fait.

L'agent pose au plus 5 questions par exécution, et a pour consigne de ne jamais demander ce qu'il peut trouver lui-même.

Quand l'agent vous attend

Pendant que l'agent attend une relecture du plan ou une réponse, l'exécution affiche En attente de vous et apparaît sous Action requise dans la liste des exécutions, avec les exécutions retenues au statut En attente d'approbation.

• L'attente ne compte pas dans la limite de temps de l'exécution : son échéance est repoussée du temps passé à attendre. L'exécution conserve sa place d'exécution simultanée.
• Une question sans réponse au bout d'une heure : l'agent continue selon son propre jugement et indique dans son bilan l'hypothèse qu'il a retenue.
• Un plan que personne ne relit dans l'heure : l'exécution échoue, sans avoir rien modifié.

Où travaille l'agent

L'agent lit et modifie le code dans son espace de travail, un clone du dépôt :

• Dépôt lié au projet : Archyl le clone au démarrage de l'exécution.
• Pas de dépôt lié, connecteur GitHub attaché : l'agent clone lui-même le dépôt dont parle la tâche, avec les identifiants du connecteur, avant de toucher au moindre fichier. Seul le serveur MCP hébergé de GitHub (api.githubcopilot.com) est pris en charge. Le connecteur doit s'authentifier avec un en-tête Authorization: Bearer, et son jeton doit avoir accès au dépôt.

Une fois un espace de travail ouvert, l'agent ne modifie des fichiers que là : pousser des fichiers ou ouvrir des pull requests via les outils d'un connecteur est refusé. C'est ce qui fait passer chaque modification par le Guard, dans la vue Modifications et dans une seule pull request.

Modifications

Modifications liste chaque fichier écrit par l'agent, au moment où il l'écrit, avec le statut Ajouté, Modifié ou Bloqué et les lignes ajoutées et supprimées par fichier et pour l'ensemble de l'exécution. Sélectionnez un fichier pour voir ce que chaque écriture a changé.

• Une écriture refusée par le Guard porte le statut Bloqué : le diff montre ce que l'agent a tenté d'écrire, avec la règle enfreinte. Une écriture que le Guard a seulement signalée passe, avec un avertissement sur le fichier.
• Les diffs longs sont tronqués au-delà de 600 lignes, et les fichiers de plus de 128 Ko apparaissent sans diff.

Commenter une ligne

Relisez le diff pendant que l'agent travaille. Dans Modifications, cliquez sur un numéro de ligne pour commenter cette ligne, puis sur Envoyer à l'agent (Cmd/Ctrl + Entrée). L'agent reçoit le fichier, la ligne et son contenu, traite le commentaire, puis reprend son plan.

• Le commentaire s'affiche sous sa ligne, En file d'attente jusqu'à ce que l'agent le lise, puis Transmis. Il apparaît aussi dans Activité, et chaque fichier indique son nombre de commentaires.
• Vous pouvez commenter les lignes ajoutées, inchangées et supprimées. Les écritures bloquées par le Guard ne se commentent pas.
• Les commentaires sont acceptés pendant que l'agent travaille ou vous attend. Un commentaire encore En file d'attente à la fin de l'exécution s'affiche Non transmis.

Sur une exécution terminée, un commentaire devient une note pour la suite : Garder pour la suite le conserve dans votre navigateur, et la barre au-dessus des fichiers (3 commentaires pour une suite) poursuit l'exécution avec eux (Poursuivre avec ces commentaires).

Pull request

À la fin de l'exécution, Archyl commite les modifications de l'espace de travail sur une branche nommée archyl/agent- suivi des 8 premiers caractères de l'ID de l'exécution, et ouvre une pull request vers la branche dont le clone est parti. Son lien apparaît en haut de Modifications (Ouvrir la pull request) et dans le résultat.

Sur GitLab, le brouillon est une merge request Draft:. Sur Bitbucket, la branche est poussée sans pull request. Une exécution qui n'a modifié aucun fichier ne publie rien.

Les pull requests sont ouvertes sur github.com, gitlab.com et bitbucket.org. Archyl n'envoie vos identifiants Git qu'à ces hôtes : un dépôt sur un serveur Git auto-hébergé (GitHub Enterprise, un GitLab privé, Azure DevOps, Gitea) est cloné sans identifiants, si bien qu'un dépôt privé ne peut pas être cloné, et aucune pull request n'est ouverte.

Poursuivre une exécution

Une exécution terminée, quelle que soit son issue, propose deux boutons :

• Poursuivre lance une nouvelle exécution qui reprend le travail de celle-ci. Écrivez ce que l'agent doit faire ensuite : vos commentaires pour la suite préremplissent les instructions, un par ligne (chemin:ligne — commentaire). Le profil est par défaut celui de l'exécution, et vous pouvez choisir les connecteurs.
• Relancer ouvre la fenêtre de lancement avec la même tâche et le même profil, pour repartir de zéro.

Une suite sait ce qui a été demandé à l'exécution précédente et ce qu'elle a fait. Elle part de la branche publiée par cette exécution, commite dessus et ajoute ses modifications à la même pull request au lieu d'en ouvrir une autre. Si l'exécution précédente a poussé sa branche sans ouvrir de pull request, la suite en ouvre une, vers la branche que viserait une nouvelle exécution. Si l'exécution précédente avait ouvert un dépôt via le connecteur GitHub, la suite le rouvre sur cette branche.

• Si la branche n'existe plus (fusionnée puis supprimée, par exemple), la suite part de la branche dont partirait une nouvelle exécution, la branche liée au projet ou la branche par défaut du dépôt, et ouvre une nouvelle pull request. Le fil l'indique.
• Une pull request en brouillon le reste : marquez-la comme prête pour la revue une fois le travail terminé.
• Archyl ne poursuit que sur les branches créées par ses agents, jamais sur les vôtres.

La page de la nouvelle exécution renvoie à celle qu'elle poursuit (Suite de l'exécution), et l'exécution précédente renvoie à ses suites (Poursuivie dans). Une exécution encore en cours ne peut pas être poursuivie : commentez plutôt ses lignes.

Connecteurs MCP

Les connecteurs vous permettent d'attacher des services externes à vos exécutions d'agents. Tout service exposant un serveur MCP (Model Context Protocol) peut être connecté.

Services pris en charge

Créer un connecteur

1. Allez dans Hub Agent → Connecteurs
2. Cliquez sur Nouveau connecteur
3. Saisissez un nom (par exemple, "github")
4. Collez l'URL du serveur MCP
5. Ajoutez des en-têtes d'authentification si nécessaire
6. Cliquez sur Créer le connecteur — Archyl interroge le serveur et affiche les outils disponibles

Espacement de noms des outils

Lorsqu'un connecteur est attaché à une exécution, ses outils sont préfixés par le nom du connecteur :

Les outils du serveur MCP intégré d'Archyl ne sont pas préfixés (par exemple, get_agent_context, list_conformance_rules).

Cet espacement de noms évite toute collision entre noms d'outils, rend le fil d'événements facile à parcourir et permet aux outils autorisés d'un profil de couvrir tout un connecteur avec un seul motif comme github__*.

Planifications

Les planifications vous permettent de définir des exécutions d'agents récurrentes à l'aide d'expressions cron standard.

Créer une planification

1. Allez dans Hub Agent → Planifications
2. Cliquez sur Nouvelle planification
3. Choisissez un profil et rédigez la description de la tâche
4. Sélectionnez une expression cron (des préréglages sont disponibles, ou saisissez une expression personnalisée)
5. Attachez des connecteurs si nécessaire
6. Cliquez sur Créer la planification

Gestion des planifications

Chaque planification affiche :

• Expression cron — Quand l'agent s'exécute
• Prochaine exécution — Date de la prochaine exécution prévue
• Dernière exécution — Date de la dernière exécution
• Statut — Active ou en pause, ou Profil supprimé lorsque son profil a été supprimé

Vous pouvez :

• Mettre en pause une planification sans la supprimer
• Reprendre une planification en pause
• Exécuter maintenant — Lancer immédiatement en dehors de la cadence normale
• Modifier le texte de la tâche, l'expression cron ou les connecteurs attachés
• Supprimer la planification

Une planification dont le profil a été supprimé reste en pause : la reprendre ou Exécuter maintenant est refusé tant que vous n'avez pas modifié la planification pour choisir un autre profil.

Exemples de planifications

Contexte architectural

Chaque exécution gérée reçoit automatiquement l'accès au serveur MCP de votre projet Archyl. L'agent peut :

• Interroger le modèle C4 pour comprendre les périmètres des systèmes
• Lire les ADRs pour comprendre les décisions architecturales passées
• Vérifier les règles de conformité pour savoir quels patterns suivre
• Consulter les contrats d'API pour comprendre les interfaces de services
• Rechercher les assignations technologiques pour choisir les bons outils
• Retrouver et mémoriser des faits sur les éléments grâce à la mémoire d'architecture

Ce contexte est injecté avant que l'agent ne commence à travailler — il n'a pas besoin de découvrir votre architecture de zéro. Chaque exécution est en outre encadrée par une session de travail du harness, si bien que son résultat devient de la mémoire pour les éléments qu'elle a touchés.

Fournisseur d'IA

Les exécutions utilisent le modèle géré par Archyl, sauf si votre organisation a activé Apportez votre propre fournisseur d'IA. Avec BYO activé, les exécutions tournent sur votre fournisseur avec vos identifiants : Anthropic, AWS Bedrock, OpenAI, ou un endpoint compatible OpenAI qui implémente l'API Responses. Google Gemini ne peut pas encore exécuter d'agents managés : les exécutions sont refusées avec un message explicite plutôt que de basculer en silence sur le modèle d'Archyl.

Quotas et concurrence

Les exécutions d'agents gérées sont disponibles sur les plans Scale et Custom. L'utilisation est suivie par organisation avec des quotas mensuels, affichés en haut des pages Exécutions et Planifications. Poursuivre une exécution et approuver une exécution retenue comptent aussi comme des exécutions. Les organisations qui ont activé BYO AI ne sont pas décomptées du quota, qu'il s'agisse d'exécutions manuelles ou planifiées.

Chaque exécution active (pending, running ou waiting_for_input) occupe l'une des places d'exécution simultanée de votre organisation. La place est libérée dès que l'exécution se termine, quelle qu'en soit la raison.

Bonnes pratiques

• Soyez précis dans les descriptions de tâches — "Vérifier les packages Go avec des CVE connues et les lister avec leur sévérité" fonctionne mieux que "vérifier les dépendances"
• Donnez à chaque tâche son propre profil — Un relecteur en lecture seule dont les allowedTools se limitent à list_*, get_* et read_file ne peut rien modifier par accident.
• N'attachez que les connecteurs nécessaires — Chaque connecteur ajoute des outils au contexte de l'agent. Moins d'outils signifie une exécution plus ciblée.
• Commencez par des exécutions manuelles — Testez votre description de tâche avec une exécution ponctuelle avant de créer une planification.
• Utilisez les règles de conformité conjointement — Définissez d'abord des garde-fous, puis activez la skill Conformance first pour que les exécutions les valident automatiquement.