Tâches en arrière-plan Hermes : paralléliser une recherche sans casser la conversation principale

Tu es en pleine session avec ton agent. Tu lui demandes d’analyser un fichier de logs de 200 Mo. Il commence. Et là, tu attends. Tu ne peux plus rien lui demander tant qu’il n’a pas fini.

C’est le problème que /background résout.

La commande est simple, mais ce qu’elle fait change la façon dont tu utilises ton terminal. Tu lances une tâche dans une session séparée, tu récupères ta conversation immédiatement, et le résultat arrive plus tard, dans un panneau dédié.

Communauté Kavyro

Le vrai sujet n’est pas d’ajouter un agent de plus.

Si tu veux construire un système d’agents utile, il te faut surtout une structure claire, de bons arbitrages et des retours terrain. C’est exactement ce qu’on partage dans Kavyro.

Cas concrets
Arbitrages utiles
Questions réelles
Accès gratuit

Rejoindre la communauté

Tu arrives avec ton sujet, tu repars avec plus de clarté.

Ce que /background fait (et ce qu’il ne fait pas)

/background lance un prompt dans une session complètement séparée. La documentation officielle est claire : chaque appel spawn un processus agent indépendant, dans un thread dédié. Ta conversation principale continue comme si de rien n’était.

Ce que /background fait :

Il exécute une tâche en parallèle de ta session.
Il te rend la main immédiatement après confirmation.
Il affiche le résultat dans un panneau du terminal quand la tâche est finie.
Il te notifie en cas d’échec.

Ce que /background ne fait pas :

Il ne planifie pas de tâches récurrentes. Pour ça, il y a cron.
Il ne garde pas de trace durable. Pas de handoff, pas de board, pas de reprise après crash.
Il n’apparaît pas dans l’historique de ta conversation principale. Les sessions background sont des sessions standalone avec leur propre ID.

La distinction est importante. /background est une session unique. Si tu fermes ton terminal avant que la tâche ait fini, le résultat est perdu. Si le processus plante, il n’y a pas de mécanisme de retry automatique.

Lancer une tâche en arrière-plan : la séquence

La syntaxe est directe. Tu tapes /background suivi de ton prompt :

/background Analyse les logs dans /var/log et résume les erreurs d'aujourd'hui

Hermes confirme immédiatement :

🔄 Background task #1 started: "Analyse les logs dans /var/log et résume..."
 Task ID: bg_143022_a1b2c3

Le Task ID au format bg_ est important. C’est la seule référence que tu as pour cette tâche. Note-le si tu veux pouvoir en parler plus tard, même si en pratique, le résultat arrive tout seul dans ton terminal.

La status bar de Hermes t’indique combien de tâches background sont actives. Tu vois « ▶ 1 » quand une tâche tourne, « ▶ 2 » quand tu en as lancé deux. C’est discret mais utile pour savoir d’un coup d’oeil si quelque chose tourne en arrière-plan.

Une tâche background n’est pas un job permanent
/background lance une session unique. Si ta session principale se ferme, la tâche meurt avec elle. Pas de handoff, pas de reprise après crash, pas de planification. Si tu as besoin que le résultat survive à ta session, regarde du côté de Kanban. Si tu as besoin que la tâche se répète tous les jours à 8h, regarde du côté de cron.

Ce qui se passe pendant l’exécution

Pendant que la tâche tourne, ta session principale est libre. Tu peux continuer à poser des questions, lancer d’autres commandes, ou même lancer une deuxième tâche background.

La tâche background ne partage rien avec ta session. Elle a son propre contexte, sa propre conversation, son propre cycle de vie. C’est un agent complètement indépendant qui travaille de son côté.

Si tu actives display.bell_on_complete dans ta configuration, le terminal émet une sonnerie quand la tâche se termine. Pratique si tu es parti faire autre chose en attendant.

Récupérer le résultat

Quand la tâche se termine, le résultat apparaît dans un panneau directement dans ton terminal :

╭─ ⚕ Hermes (background #1) ──────────────────────────────────╮
│ Found 3 errors in syslog from today:                        │
│ 1. OOM killer invoked at 03:22 — killed process nginx       │
│ 2. Disk I/O error on /dev/sda1 at 07:15                     │
│ 3. Failed SSH login attempts from 192.168.1.50 at 14:30     │
╰──────────────────────────────────────────────────────────────╯

Si la tâche échoue, tu vois une notification d’erreur à la place. Le panneau est le même, mais le contenu t’indique ce qui n’a pas fonctionné.

Un point important : le résultat n’est pas dans l’historique de ta conversation. Si tu quittes ta session, tu ne le retrouveras pas en reprenant la conversation plus tard. C’est une notification live, pas un message sauvegardé.

Si ta tâche background échoue et que tu ne comprends pas pourquoi, les techniques de debug et dépannage Hermes t’aideront à diagnostiquer le problème.

Les cas où /background est le bon choix

/background n’est pas fait pour tout. Il brille dans des cas précis.

Analyse de logs ou de fichiers volumineux. Tu as un fichier de 200 Mo à analyser. Tu lances /background, tu continues à travailler, le résumé arrive quand c’est prêt.

Résumé d’erreurs ou de rapports. Tu veux un résumé des erreurs dans syslog depuis ce matin. C’est une tâche indépendante qui ne dépend pas du reste de ta session.

Tâche indépendante de ta conversation. Tu es en train de coder, et tu te demandes ce que contient un fichier de config sur un autre serveur. Tu lances la vérification en background, tu continues ton code.

Recherche web qui prend du temps. Tu demandes une recherche approfondie sur un sujet. Plutôt que de bloquer ta session pendant 3 minutes, tu la lances en background.

Le point commun : ce sont des tâches ponctuelles, dont le résultat est utile dans la session en cours, mais qui ne justifient pas de créer une infrastructure durable.

Quand passer à cron ou Kanban

/background a une limite claire : c’est une session unique. Dès que ton besoin dépasse ce cadre, il faut changer d’outil.

Passe à cron quand ta tâche doit se répéter. Tous les jours, toutes les heures, tous les lundis. /background ne planifie rien. Cron est fait pour ça.

Passe à Kanban quand le résultat doit survivre à ta session. Si tu veux qu’un autre profil reprenne le travail, si tu veux relire le handoff trois jours plus tard, si tu veux une trace écrite de ce qui a été fait. Kanban garde tout dans un board partagé.

Si ta tâche demande plusieurs étapes qui s’enchaînent avec des dépendances, un workflow multi-étapes est plus adapté qu’une simple tâche background.

Critère	/background	cron	Kanban
Type de tâche	Ponctuelle	Récurrente	Durable, multi-profils
Durée de vie du résultat	La session en cours	Stocké selon la config cron	Permanent (survit aux sessions)
Planification	Non (immédiat)	Oui (horaire, récurrent)	Non (dispatch à la demande)
Reprise après crash	Non	Oui (prochaine exécution)	Oui (le dispatcher reprend)
Quand l’utiliser	Tâche unique dans une session	Tâche qui doit se répéter	Travail inter-profils avec handoff

Le piège classique : utiliser /background pour tout par simplicité, et perdre un résultat important parce que la session s’est fermée avant la fin. Ou pire : lancer la même tâche tous les jours à la main en /background alors qu’un cron ferait le travail tout seul.

La règle est simple. Si tu as besoin du résultat après la fermeture de ta session, /background n’est pas le bon outil. Passe à Kanban ou cron selon que le besoin est durable ou récurrent.

Si tu veux aller plus loin, les articles sur Kanban et les workflows multi-étapes détaillent comment structurer des tâches qui survivent aux sessions. Et si tu veux automatiser des tâches récurrentes, l’article sur cron Hermes explique comment planifier sans intervention manuelle.

Si ton besoin dépasse la tâche ponctuelle et que tu hésites entre cron et Kanban, fais une demande via le formulaire de contact sur kavyro.com pour qu’on t’aide à choisir le bon mécanisme.

Trinity