Confier un long travail à des agents, sans perdre la main.

1. 01 Des projets, et les dossiers qu’ils confient

   Un projet donne ses permissions globales : les dossiers en lecture et en écriture que recevront toutes ses tâches, choisis avec le sélecteur du système. Une tâche peut ajouter ses propres dossiers, jamais en retirer, et ils ne changent pas pendant qu’elle s’exécute.

2. 02 Composer un graphe d’agents

   Chaque agent a sa mission, ses ressources, son livrable, son modèle et son effort. Un agent déterministe garde une place fixe ; un agent dynamique répartit son travail entre des sous-agents qu’il crée en cours de route. Les liaisons vont d’une sortie à une entrée, et les cycles sont refusés. Un contexte commun et une méthode de travail s’ajoutent au message de chaque agent.

3. 03 Estimer la durée avant de lancer

   À chaque agent, effort ou liaison changé, l’éditeur rejoue le graphe avec la session typique de chaque modèle et de chaque effort, tirée des exécutions passées, sous les limites de parallélisme : une durée typique et sa fourchette.

4. 04 Créer ou planifier avec un agent

   Un assistant compose la tâche par les outils MCP que Sillage lui ouvre, un agent par appel, dans un brouillon visible en direct. Un autre écrit un plan dans le dépôt du projet ; plan, création et exécution peuvent s’enchaîner sans moi.

5. 05 Suivre une exécution en direct

   Le graphe montre les agents actifs et les sous-agents dès leur création, avec leur consommation. Le suivi distingue les sessions, les attentes datées et leurs causes ; le journal des erreurs réunit ce qui a échoué ; les échanges montrent, dans l’ordre, le message exact reçu par chaque agent et sa réponse.

6. 06 Donner un navigateur aux agents

   Un agent dont la mission parle de navigateur reçoit un Chromium sans interface, à lui seul, par les outils de Playwright MCP : il ouvre les pages du projet, clique, saisit et capture l’écran. Les retours visuels montrent l’exécution en images, étape par étape.

7. 07 Reprendre, relancer, restaurer

   Après une coupure, un arrêt ou un échec, la reprise relance les étapes non abouties et se rattache aux sessions restées actives chez Relais. « Relancer depuis cet agent » repart de n’importe quelle étape ; « Voir ce qui a changé » compare la tâche à son exécution, et une définition exécutée se restaure.

8. 08 Retrouver le résultat et l’historique

   Le récapitulatif désigne le résultat final, worktree, branche et commit, puis ce que chaque agent a fait, et se copie en Markdown pour une pull request. Les exécutions se comparent et se regroupent en sprint ; l’historique du projet donne la durée, les tokens et l’équivalent API de chaque action.

9. 09 Un assistant pour chaque projet

   Une conversation gardée par projet : il répond sur le projet, ses tâches et ses exécutions, et ses actions s’affichent en cartes, une idée notée, un fait retenu, un plan ou une exécution lancés.

10. 10 Garder la machine éveillée, nettoyer derrière

    Tant qu’un agent travaille, Sillage empêche la mise en veille et le dit. À la fin d’une exécution aboutie, il supprime les worktrees propres et fusionnés, jamais les branches ; un panneau liste les autres, avec ce qui les retient.

Architecture

1. 01 Un serveur Rust, une interface Angular, un flux SSE aperçu

   Le serveur, en Rust (Axum et Tokio), garde l’état en mémoire et le persiste dans un SQLite embarqué. Il n’écoute que la boucle locale : toutes les routes de l’API demandent un jeton, et les en-têtes Host et Origin doivent être locaux. L’interface Angular reçoit l’état par un flux SSE, un instantané après chaque modification enregistrée, quatre envois par seconde au plus.

   interface Angular 22
    ↓ HTTP + jeton
    ↑ SSE : l’état,
      ≤ 4 envois par seconde
   serveur Rust (Axum, Tokio)
   ├▶ SQLite embarqué
   ├▶ Relais, par HTTP + jeton
   └▶ assistants, par outils MCP
      (création, plan)
   agents ◀ Playwright MCP :
      un navigateur chacun

2. 02 Un coordinateur planifie, le serveur vérifie

   Un agent dynamique inventorie les unités de travail de sa mission et les répartit entre le plus petit nombre de sous-agents utile. Avant d’en lancer un seul, le serveur contrôle le plafond, la couverture des unités, les champs délégués et les couples modèle et effort autorisés ; un plan refusé revient au coordinateur, dans la même session, deux fois au plus. Un sous-agent perdu rend le groupe partiel, sans perdre le travail des autres.

3. 03 Une session ne part jamais deux fois aperçu

   Chaque demande de session à Relais porte un identifiant choisi par Sillage. Si la réponse se perd, Sillage renvoie la même demande, et Relais rend la session déjà créée au lieu d’en lancer une seconde.

   POST /api/sessions                      (chez Relais)
   { "client_session_id": "<UUID v4>", "application_name": "Sillage",
     "model": "…", "effort": "…", "workspace": "…", "ttl_seconds": … }
   
   → 201  la première fois
   → 200  la même session, quand la demande est rejouée à l’identique
   → 409  le même identifiant pour une autre demande

Décisions

1. 04 Un résultat court, corrigé dans la même session aperçu

   Contrainte

   Les agents rendent de 10 000 à 27 000 caractères, quelle que soit la cible qu’on leur annonce, et une seule réponse mal formée peut casser la chaîne.

   Choix

   Chaque agent rend un résultat court et structuré : résumé, décisions, contrôles, blocages, suite. Une réponse hors du format attendu lui revient dans la même session, avec l’erreur, deux fois au plus.

   Effet

   Les agents suivants reçoivent des faits et des références, pas des conversations entières ; un blocage arrête la suite.

   Le récapitulatif ↓

   {
     "outcome": "partial",
     "summary": "Interfaces examinées ; raccordement restant.",
     "decisions": [],
     "checks": [{ "kind": "runtime_test", "status": "not_run" }],
     "blockers": [],
     "next_action": "Effectuer les essais dans le navigateur."
   }

2. 05 Sillage crée lui-même le worktree de l’agent

   Contrainte

   Des agents en parallèle dans un même dossier se gênaient : 26 commandes Git bloquées sur un verrou, des commits réécrits par un autre agent. Enfermés dans leur bac à sable, d’autres agents ne pouvaient ni committer, ni ouvrir un navigateur, ni joindre le réseau : 39 blocages en trois exécutions.

   Choix

   Quand un agent en a besoin (sa mission le demande, ou un autre agent écrit en même temps dans le même dossier), Sillage crée lui-même son worktree avant sa première session, le garde pour les suivantes, committe pour l’agent si besoin, puis fusionne.

   Effet

   Le même mécanisme committe pour les agents enfermés et sépare ceux qui écrivent en parallèle. Seuls les worktrees propres et fusionnés sont nettoyés, jamais les branches.

3. 06 Une fenêtre de compaction pour chaque session aperçu

   Contrainte

   À chaque appel, toute la conversation de l’agent était relue : 2,19 milliards de tokens, les unités de texte que lit le modèle, sur 79 sessions de trois tâches, et rien ne bornait une session.

   Choix

   Chaque session demande à Relais une fenêtre de compaction, de 300 000 tokens par défaut, réglable ou désactivable : au-delà, sa conversation est résumée.

   Effet

   Une session est résumée vers 270 000 tokens au lieu de grossir jusqu’à la limite du modèle.

   // Demande de session à Relais, réglage par défaut
   { "autocompact_tokens": 300000 }

4. 07 Relais n’expose que des capacités génériques aperçu

   Contrainte

   Des notions propres à Sillage étaient entrées dans Relais, et Sillage allait lire le jeton de Relais dans son dossier : trois lectures dans le code exécuté.

   Choix

   Relais n’expose que des capacités génériques. Sillage garde son schéma de création de tâche et ses validations, et reçoit le jeton par ses paramètres.

   Effet

   Plus aucune lecture du dossier voisin : deux applications qui s’installent séparément, et un point d’accès que d’autres outils utilisent.

   Relais →

   // GET /api/status chez Relais : les capacités dont Sillage se sert
   { "capabilities": {
       "working_context": true, "filesystem_scope": true,
       "idempotent_session_creation": true, "mcp_http": true, "mcp_http_auto": true } }

Garde-fous, tests et limites

1. 08 Des consignes et des contrôles, pas une isolation

   Une tâche qui écrit donne aux agents un terminal, dont chaque commande passe par le classificateur de l’agent ; une tâche sans dossier d’écriture reste en lecture seule stricte, chaque lecture contrôlée par Relais. Les sous-agents héritent des permissions sans pouvoir les élargir. Aucun de ces modes n’isole le système des autres processus de la machine : c’est écrit.

2. 09 Une panne du fournisseur ne fait pas échouer l’agent

   Sur une erreur temporaire de l’API (529, 5xx), l’agent attend 30 s, puis le double, sans dépasser 240 s par défaut, et reprend dans la même session si elle le permet. Une authentification expirée ou un quota atteint met ses agents en attente : l’exécution repart seule à la reconnexion ou à la réinitialisation.

3. 10 643 tests du serveur, et des parcours complets

   643 tests en Rust, 206 tests des scripts, 22 parcours d’interface Playwright et 14 scénarios de bout en bout, tous contre un faux fournisseur : aucun abonnement consommé. L’intégration continue les joue sous Windows et sous macOS, sur processeurs Apple et Intel.