6 cas d'usage de Hermes Agent que j'exploite comme main-d'œuvre 24h/24

6 cas d'usage de Hermes Agent que j'exploite comme main-d'œuvre 24h/24

Le projet Godot a fini de compiler à 4h42 du matin. Je n'étais pas réveillé pour le voir. Ce que j'ai vu, en déverrouillant mon téléphone à 8h11, c'est un message Telegram de mon Hermes Agent : « Build terminé. Shooter stealth jouable depuis ~/projects/godot-tps. Pickups de loot fonctionnels (munitions, bandages). Bascule vision à travers les murs sur les ennemis. IA de patrouille basique sur trois gardes. Dernier commit 04:42:13. Aucune erreur dans l'éditeur. Tu veux que je rédige le brief de la prochaine itération ? »

J'avais donné un seul prompt la veille au soir. J'étais allé me coucher. Pendant mon sommeil, il a livré un shooter à la troisième personne dans Godot 4.

Je veux être clair sur un point avant que ça ne devienne un paragraphe de hype. Le shooter n'est pas un jeu fini. L'IA des ennemis est bête. Les textures sont provisoires. Le rig d'animation est à moitié fait. Mais le truc est jouable. On peut déplacer un personnage dans un niveau, ramasser des munitions, utiliser un bandage pour se soigner, voir les ennemis briller à travers les murs en mode vision furtive, et tirer avec une arme qui inflige des dégâts. Le squelette est réel. La prochaine itération, avec des assets générés par IA et quelques passes supplémentaires par le même agent, sera un vrai jeu.

Le point essentiel est ce que le slashgoal a prouvé. Je suis passé d'une « idée vague » à un « projet Godot compilé et jouable » sans m'asseoir au clavier. L'agent ne résumait pas ce que je devais faire. Il le faisait. Pendant vingt-trois heures. En continu. Pendant que je cuisinais, regardais un film, dormais et faisais du café.

C'est l'article que je voulais écrire depuis des mois. Pas l'article « Hermes Agent est génial » — j'ai déjà écrit celui sur le branchement de Hermes dans Claude Code comme un OS IA partagé et celui sur le couplage avec OpenClaw pour la redondance. Cet article porte sur ce que Hermes Agent fait réellement pour moi au quotidien. Six cas d'usage spécifiques. Des workflows réels. Ceux qui ont transformé un buzzword d'« agent auto-améliorant » en une main-d'œuvre IA 24h/24 dont je serais sincèrement en peine de me passer.

Si vous êtes curieux de Hermes mais ne savez pas vers quoi le diriger, voici votre manuel.

Pourquoi « main-d'œuvre IA » est le bon cadrage, pas « assistant IA »

La plupart des gens installent Hermes et essaient de l'utiliser comme ChatGPT avec des étapes en plus. Taper un prompt. Obtenir une réponse. Fermer la fenêtre. Recommencer.

C'est le mauvais modèle mental. Ça gaspille 90 % de ce qui rend Hermes intéressant.

Le Hermes Agent (Nous Research, actuellement en v0.13 en mai 2026) a été conçu autour de trois décisions architecturales qui changent tout sur la façon dont on l'utilise :

1. Il persiste. Hermes tourne sur un serveur, un VPS ou un processus local à longue durée de vie. Vous pouvez lui parler depuis Telegram, WhatsApp, Slack ou le terminal — mais l'agent lui-même ne s'arrête pas quand vous fermez la fenêtre. Il continue de tourner, de mémoriser et d'exécuter les tâches que vous avez déléguées des heures ou des jours plus tôt.
2. Il s'auto-améliore. Chaque tâche réussie est extraite en une compétence. Chaque compétence est affinée au fur et à mesure de l'utilisation. Cela signifie qu'un pipeline de recherche que vous avez configuré en février est mesurablément meilleur en recherche en mai que le jour où vous l'avez construit. L'agent compose.
3. Il est multi-instance. Vous pouvez faire tourner plusieurs profils Hermes en parallèle — un orchestrateur, un chercheur, un codeur, un rédacteur — et ils se passent le travail via un tableau Kanban intégré. Ce n'est pas une métaphore. Il y a littéralement un tableau de bord Kanban. Des cartes se déplacent entre les colonnes. Des profils sont assignés. Le travail avance.

Combinez ces trois propriétés et « assistant IA » cesse d'être le bon mot. Ce que vous avez réellement, c'est une petite main-d'œuvre. Toujours active. Toujours en apprentissage. Coordonnée par un tableau. Ce recadrage est ce qui déverrouille les cas d'usage ci-dessous.

Voici ce que la mienne fait pour moi, dans l'ordre où je les ai mis en place.

Cas d'usage 1 : Slashgoal pour les tâches de plus de 24 heures

Le slashgoal — /goal dans le CLI Hermes — est la fonctionnalité unique qui m'a fait arrêter de traiter Hermes comme un chatbot. Selon la documentation officielle de Hermes, /goal fixe un objectif permanent que l'agent continuera de poursuivre au fil des échanges jusqu'à ce qu'il soit atteint, en utilisant ce que Nous appelle une boucle Ralph. En termes pratiques : vous donnez une cible, et il bosse.

La première fois que j'ai essayé, j'ai fait ce que fait tout développeur. J'ai tapé /goal construis-moi une app et je suis allé me coucher en me sentant malin.

Je me suis réveillé avec un serveur Express à moitié cassé, trois readme contradictoires et une facture de tokens qui m'a fait grimacer. L'agent avait sincèrement essayé. Il n'avait juste aucune idée de ce que je voulais.

Cet échec m'a enseigné la leçon que j'enseigne désormais à chaque utilisateur de Hermes : le slashgoal n'est pas un souhait. C'est un contrat. Et les contrats fonctionnent quand les deux parties sont spécifiques.

La solution a été le métaprompting. Au lieu de taper mon objectif à l'aveugle, j'ai commencé à co-écrire l'objectif avec une IA d'abord. Je m'asseyais avec Claude ou Codex et répondais à des questions comme :

• Quel est le livrable cible, décrit comme si je le transmettais à un développeur ?
• Quelles sont les contraintes dures (langage, framework, dépendances, structure de fichiers) ?
• Quelles sont les préférences souples (style, conventions de nommage, bibliothèques à éviter) ?
• À quoi ressemble le « terminé » ? Quelle est la preuve minimale viable d'achèvement ?
• Qu'est-ce que l'agent peut décider ? Sur quoi doit-il me consulter ?
• Quel est le budget — tokens, temps, périmètre ?

Quand j'ai fini, j'ai un slashgoal de deux ou trois pages. Pénible à écrire. Magique à exécuter.

Le projet Godot qui a ouvert cet article est venu d'un de ces longs slashgoals. Le prompt spécifiait Godot 4 comme moteur, une caméra troisième personne reliée à un CharacterBody3D, deux pickups consommables (munitions et bandages), une mécanique furtive où les ennemis deviennent visibles à travers les murs quand le joueur s'accroupit, et une IA de patrouille pour trois PNJ ennemis. Il listait la structure exacte des répertoires. Il disait à l'agent quelles API Godot utiliser et lesquelles éviter. Il donnait la permission à l'agent de commiter dans un dépôt git local à chaque jalon et de me ping sur Telegram quand il était bloqué.

L'agent a tourné pendant 23 heures. Il a atteint la limite de budget que j'avais fixée pour les itérations maximales. Il m'a consulté deux fois, les deux parce qu'il avait correctement identifié une ambiguïté dans ma spec. Le résultat est le prototype jouable décrit dans l'introduction.

Le même schéma fonctionne pour des choses qui ne sont pas des jeux. J'ai utilisé le slashgoal pour :

• Un long document technique (un playbook de 60 pages pour un client). L'agent a rédigé, auto-revu contre une grille de critères, et itéré jusqu'à ce que chaque section passe. Temps total : ~14 heures.
• Une migration d'une app Laravel legacy vers une base de code Laravel 13 neuve. L'agent a lu l'ancien code, cartographié les routes et modèles, généré la nouvelle structure, et produit un diff pour que je le relise. Temps total : ~11 heures.
• Un site de documentation statique entier pour un projet open-source que je maintiens. Hermes a écrit le contenu, généré la config Astro, configuré le déploiement sur un VPS, et m'a prévenu quand le DNS nécessitait une intervention manuelle. Temps total : ~6 heures.

Il y a un pattern dans ces exemples qui mérite d'être nommé. Le slashgoal est meilleur pour le travail borné, vérifiable et à longue traîne. Borné parce que les objectifs vagues échouent. Vérifiable parce que l'agent doit savoir quand il a terminé. À longue traîne parce que si une tâche prend 15 minutes, vous devriez simplement la faire.

Le compromis honnête : les exécutions de slashgoal sont chères quand on se trompe d'estimation. Une exécution de 23 heures sur Opus 4.7 via OpenRouter m'a coûté environ 38 $ pour le projet Godot. Ça vaut le coup pour un vrai prototype. Douloureux si le prompt était mauvais et que le résultat est inutilisable. Limitez toujours votre paramètre de max-iterations dans hermes init avant de déléguer quelque chose d'ambitieux.

Avant de continuer, voici le fil ouvert que je bouclerai plus tard : un excellent slashgoal a encore besoin d'un excellent endroit pour livrer son output. C'est là qu'intervient le Kanban.

Cas d'usage 2 : Le tableau Kanban comme contrôleur de trafic humain-IA

Le Kanban Hermes est la deuxième fonctionnalité qui a changé ma façon de travailler. Il est livré comme plugin de tableau de bord inclus dans plugins/kanban/, tourne localement et expose des colonnes pour triage, à faire, prêt, en cours, bloqué, terminé et archivé. Vous le lancez avec hermes dashboard depuis le terminal, et un onglet de navigateur s'ouvre sur l'URL du kanban.

Cette phrase sous-vend ce qui se passe réellement. Le Kanban n'est pas une to-do list. C'est une file de délégation avec routage intégré.

Voici le flux quotidien que je suis.

Matin, vers 8h30. J'écris ma liste de tâches du jour. Stylo et papier, en général. Une douzaine d'éléments : travail client, revues de code, deux articles à écrire, trois appels à passer, un truc de facturation pour mon comptable, des courses.

Je trie la liste en deux piles. La pile A est le travail que moi seul peux faire. La pile B est le travail qu'un agent peut raisonnablement commencer. La répartition est généralement 60/40 certains jours, 30/70 d'autres. Tout ce qui implique un appel téléphonique, une décision créative, une réunion en personne ou un jugement qui dépend d'un contexte que l'agent n'a pas — c'est la pile A. Tout ce qui est recherche, rédaction, scaffolding de code, refactoring, collecte de données ou documentation routinière — pile B.

La pile B va dans le Kanban. J'ouvre le hermes dashboard, clique sur le bouton de création en ligne de la colonne Triage et dépose des cartes courtes. « Rechercher trois concurrents du produit X, output en rapport markdown. » « Refactorer le module d'auth dans le repo Y pour utiliser le nouveau pattern middleware. » « Rédiger les 1 500 premiers mots de l'article de la semaine prochaine sur le sujet Z. »

Le dispatcher prend le relais. Par défaut, Hermes tourne avec kanban.auto_decompose: true. Le dispatcher lit chaque carte dans la colonne Triage, consulte ma liste de profils et route la tâche. Une carte de recherche va à mon profil Chercheur. Une carte de code va à mon profil Codeur. Une carte de rédaction va à mon profil Rédacteur. Les cartes longues sont décomposées en un graphe de sous-tâches via l'action Décomposer. Les cartes courtes reçoivent une réécriture de spec en tâche unique via Spécifier.

Les cartes coulent. Triage → à faire → prêt → en cours → terminé. Je ne les déplace pas. Les agents le font. Je regarde le tableau évoluer tout au long de la journée comme je regardais autrefois les pipelines CI tourner.

La première fois que ça a fait tilt pour moi, c'était un mardi en mars. J'avais posé sept cartes sur le tableau à 9h. À midi, j'avais avancé sur trois de mes tâches humaines uniquement. Quand j'ai vérifié le tableau de bord, quatre des sept cartes étaient passées à terminé. Une était bloquée — l'agent avait touché un mur et laissé un commentaire me posant une question. Deux étaient encore en cours. J'ai répondu à la question de la carte bloquée en quinze secondes. L'agent s'est débloqué et a repris.

C'est le moment où j'ai cessé d'avoir l'impression de gérer des tâches. Je relisais le travail d'une équipe dont j'étais, techniquement, le seul membre humain.

Quelques détails qui comptent quand vous l'utilisez vraiment :

• Les cartes acceptent des commentaires. Je laisse le contexte dans les commentaires des cartes plutôt que de l'entasser dans le titre. L'agent les lit. Le contexte long appartient aux commentaires, pas aux titres.
• Les cartes acceptent des liens. Vous pouvez attacher un chemin de fichier, une URL ou une référence à une autre carte. Hermes les utilise comme inputs.
• Le décomposeur automatique de triage est opiniâtre. Si vous n'aimez pas comment il a découpé une tâche, cliquez à nouveau sur le bouton Décomposer avec un prompt plus clair dans un commentaire d'abord. Il re-routera en fonction du commentaire.
• Utilisez les descriptions de profil. Le dispatcher route en fonction des descriptions de profil, pas des noms. Un profil appelé coder sans description reçoit un routage générique. Un profil appelé coder décrit comme « Spécialiste TypeScript / Next.js / Tailwind, vit dans ~/projects/web » reçoit exactement le travail qu'il devrait.

Le Kanban est ce qui transforme Hermes de « un agent qui fait une chose » en « une main-d'œuvre qui fait plein de choses. » Une fois que c'est lancé, vous cessez de l'ouvrir pour vérifier l'avancement et commencez à l'ouvrir pour déléguer.

Mais la partie la plus contre-intuitive de mon utilisation de Hermes n'est ni la commande goal ni le Kanban. C'est le moteur de recherche autonome que j'aborderai ensuite — qui produit un output si détaillé qu'il facilite le travail de Claude Code.

Cas d'usage 3 : Recherche technique et analyse concurrentielle qui se transmettent proprement

Je lance une analyse concurrentielle sur chaque produit que j'évalue. Avant, je faisais ça manuellement. Ouvrir un onglet. Lire le copy marketing. Ouvrir un autre onglet. Naviguer dans le produit. Ouvrir les DevTools. Regarder la taille du bundle. Noter la page de tarifs. Noter les scripts analytics. Noter le processeur de paiement. Rédiger les conclusions.

Ça prenait une heure minimum par produit. Parfois une demi-journée si le produit était profond.

Maintenant c'est une carte Kanban.

La carte ressemble à ceci : « Analyser le produit concurrent Creator Buddy (creatorbuddy.ai). Produire un rapport markdown couvrant la stack technique, la liste des fonctionnalités, les paliers tarifaires, la configuration analytics, le processeur de paiement, les claims de positionnement clés et les lacunes par rapport à des outils comparables. Output dans ~/research/competitors/creator-buddy-2026-05.md. »

L'agent fait ce travail comme je le ferais, sauf plus vite et plus minutieusement. Il ouvre le site. Il lit chaque page. Il inspecte les requêtes réseau. Il regarde les bundles JavaScript chargés et note quels frameworks sont visibles. Il lit le code source de la page pour les balises analytics. Il vérifie la page de tarifs. Il compare le langage de positionnement entre les pages. Il produit un rapport markdown — généralement de 1 500 à 2 500 mots — que je peux injecter directement dans Claude Code ou Codex comme input pour une tâche de construction.

L'analyse Creator Buddy a tourné pendant environ 40 minutes. Le résultat contenait :

• Identification de la stack technique. Next.js 14, Tailwind, déployé sur Vercel, utilisant Stripe pour les paiements, Mixpanel pour l'analytics produit, Intercom pour le support. Tout déduit des headers, des scripts chargés et du code source de la page.
• Inventaire des fonctionnalités. Vingt-trois fonctionnalités, chacune décrite en une phrase, organisées par les quatre surfaces du produit (tableau de bord, éditeur, bibliothèque, paramètres).
• Matrice tarifaire. Trois paliers, avec les différences de fonctionnalités surlignées. Extraits directement de la page de tarifs et de quelques documents de support liés dans le pied de page.
• Claims de positionnement. Six claims centraux du marketing, classés par proéminence.
• Lacunes. L'évaluation propre de l'agent — basée sur la comparaison avec deux outils de référence que je lui avais mentionnés — de ce que Creator Buddy ne fait pas que des outils comparables font.

Cette dernière section a été le point clé. L'agent n'a pas juste décrit le produit. Il l'a analysé. La section lacunes m'a donné trois opportunités concrètes qu'un outil dans le même espace pourrait poursuivre.

Ce qui rend ce cas d'usage particulièrement précieux : le résultat est structuré pour des agents en aval. Comme le rapport est un fichier markdown propre à un emplacement connu, je peux l'injecter comme contexte dans Claude Code avec un slashgoal de suivi : « Lis ~/research/competitors/creator-buddy-2026-05.md. Construis un prototype Next.js 15 qui adresse les trois lacunes identifiées dans le rapport. Utilise la même stack technique. Output dans ~/projects/prototype-x. »

Ce sont deux opérations Hermes chaînées. Recherche → prototype. Les deux autonomes. Les deux produisant des artefacts réels que je peux relire. Le même schéma de transmission fonctionne pour tout workflow recherche-puis-construction.

Une note sur l'éthique, parce que je prends ça au sérieux : l'agent n'inspecte que des pages publiquement accessibles. Pas de scraping derrière un paywall. Pas de contournement d'authentification. Pas de simulation d'utilisateurs. L'agent lit ce qu'un navigateur non connecté verrait et rend compte de ce qui est visible. C'est une contrainte que je pose dans la description du profil et que je renforce dans chaque carte de recherche.

Si vous écrivez beaucoup de contenu pratique sur l'IA comme moi, la chaîne recherche-puis-construction rembourse l'abonnement Hermes toute seule. Les heures que je passais à rassembler du contexte sont maintenant des heures que je passe à écrire.

Cas d'usage 4 : Un wiki mémoire personnel qui devient plus intelligent au fil du temps

Il y a une catégorie de cas d'usage Hermes qui n'apparaît dans aucun article « 10 cas d'usage » que j'ai lu, et c'est celui dont je me passerais le plus difficilement.

J'ai un wiki mémoire personnel. C'est un site privé, hébergé sur un domaine accessible uniquement par moi, maintenu automatiquement par Hermes. Chaque conversation que nous avons, chaque décision que je prends dans un journal quotidien, chaque artefact de recherche, chaque jalon de projet — tout atterrit comme une entrée cliquable, cherchable et reliée sur ce wiki.

Le configurer a pris un prompt et environ 25 minutes.

J'ai demandé à Hermes de me construire un site statique avec trois choses : une page d'accueil listant mes projets actifs avec des badges de statut, une section journal quotidien avec une entrée par jour, et une section thématique où chaque thème est une page markdown qui se met à jour automatiquement quand une conversation pertinente a lieu. Je lui ai dit où l'héberger (un sous-domaine privé sur mon VPS), je lui ai donné accès en écriture au vault Obsidian où vivent mes notes, et je l'ai pointé vers le répertoire des logs de conversation.

C'était l'installation. Maintenant le wiki se maintient tout seul.

Chaque soir vers minuit, une tâche planifiée tourne sur Hermes. Elle récupère les conversations du jour, extrait les points substantiels (décisions, leçons, références utiles, choses que j'ai dit vouloir retenir) et les écrit dans les pages thématiques appropriées. Elle met à jour le journal quotidien avec un résumé propre. Elle crée des liens croisés entre les nouvelles entrées et les thèmes existants où le contenu se recoupe. Le matin, le wiki a grandi d'une journée entière de mémoire précise et navigable — sans que je touche quoi que ce soit.

Pourquoi est-ce important ? Deux raisons.

Ça renforce ma propre mémoire. J'oubliais des choses. Des décisions prises il y a trois semaines. Des conversations avec des clients sur des changements de périmètre. La raison précise pour laquelle j'ai choisi une bibliothèque plutôt qu'une autre dans un projet du mois dernier. Maintenant j'ouvre le wiki et je cherche. L'acte de consigner — même quand c'est l'agent qui consigne — ramène les informations dans la mémoire à court terme accessible.

Ça donne à l'agent un meilleur contexte long terme. C'est la partie que je n'avais pas prévue. Comme le wiki est aussi la source de vérité de l'agent, chaque conversation que j'ai avec Hermes est informée par toutes les conversations précédentes. Posez une question à Hermes sur un projet du trimestre dernier et il ne bafouille pas — il ouvre la page thématique, lit ses propres notes et répond avec le contexte complet. Le wiki est, en fait, la mémoire à long terme externalisée de l'agent sous une forme que je peux parcourir et auditer.

Un exemple concret. Il y a deux semaines, j'étais en call avec un client sur un projet Laravel. Ils ont référencé une décision prise en février sur l'authentification. Je n'en avais aucun souvenir. J'ai ouvert le wiki sur mon second écran, tapé « auth » dans la recherche, et l'entrée est apparue : « 2026-02-14 — Décision auth Client X. Choisi Laravel Sanctum plutôt que Passport parce que l'équipe mobile utilise une auth par tokens et le modèle de token API de Sanctum correspond mieux. Mejba a signalé le coût de migration. Client a accepté. » J'ai lu ça au client. Ils ont confirmé. L'appel a continué.

Sans le wiki, ce sont quinze minutes de « laissez-moi vérifier et revenir vers vous » gêné. Avec le wiki, c'est six secondes. Multipliez par chaque conversation qui dépend d'un contexte antérieur — ce qui est, au final, chaque conversation — et vous comprenez pourquoi je me battrais pour garder ce setup.

La configuration est plus simple qu'il n'y paraît. Hermes construit le site avec la stack de votre choix (le mien est Astro parce qu'il compile vite et a une bonne allure avec un styling minimal). La tâche planifiée est une seule entrée cron dans la config Hermes. Les liens croisés se font via une petite compétence que l'agent a apprise avec le temps — et qui est maintenant dans ma bibliothèque de compétences, prête à partager si vous demandez.

Construisez ça. Sérieusement. C'est le cas d'usage qui rapporte le plus sur la plus longue durée.

Cas d'usage 5 : Un réseau mesh Tailscale qui transforme chaque appareil en terminal Hermes

Voici le cas d'usage qui a transformé ma collection d'appareils en un seul système fonctionnel.

J'ai un MacBook Pro sur le bureau. Un Mac Mini sur une étagère qui fait tourner les jobs longs. Un iPhone dans la poche. Un iPad dans un sac. Une machine Linux de spare que je garde pour les tests. Avant ce setup, chaque appareil était sa propre île. Les fichiers sur le Mac Mini restaient sur le Mac Mini. Les modèles tournant sur la machine Linux tournaient sur la machine Linux. Pour déplacer un fichier ou interroger un service entre appareils, je bricolais avec Dropbox, SSH ou un câble USB.

Tailscale a avalé tout ça.

Tailscale est un VPN mesh. Vous l'installez sur chaque appareil que vous possédez. Ils s'authentifient sur votre tailnet. Ils forment des connexions pair-à-pair chiffrées en WireGuard. Chaque appareil obtient un nom stable (via MagicDNS) et une adresse IP accessible uniquement depuis votre mesh privé. Téléphones, laptops, serveurs, tablettes — tous sur un réseau, tous adressables par hostname, tous sécurisés par SSO en périphérie.

La mise en place prend vingt minutes et c'est gratuit pour un usage personnel jusqu'à 100 appareils. Installez l'app. Connectez-vous avec Google ou GitHub. C'est fait. Chaque appareil apparaît dans la console admin Tailscale avec un nom et une IP. Depuis n'importe quel appareil du mesh, vous pouvez atteindre n'importe quel autre par hostname.

Ce que ça déverrouille pour Hermes est déraisonnable.

Accès aux fichiers entre appareils. Un processus Hermes tournant sur mon Mac Mini peut lire des fichiers sur mon MacBook Pro en les référençant via macbook-pro:/Users/mejba/projects/... à travers le mesh. Pas besoin de synchroniser, copier ou télécharger. L'agent lit les fichiers là où ils vivent.

Services type localhost depuis n'importe où. Je fais tourner un LLM local (un modèle Llama quantifié) sur la machine Linux. Depuis mon MacBook, je peux l'atteindre à linux-box:11434 — le port d'Ollama — comme si c'était localhost. Depuis Hermes sur le Mac Mini, pareil. Le mesh entier traite chaque appareil comme une seule machine logique.

Exécution de tests entre appareils. Si Hermes construit une webapp sur mon MacBook et veut la tester depuis un « autre réseau », il peut lancer un curl depuis l'iPhone (oui, avec iSH ou a-Shell) ou depuis la machine Linux. Même code, chemin réseau différent, test réel.

Le téléphone comme télécommande du Mac Mini. Celui-ci est légèrement absurde mais utile. Le tableau de bord Hermes sur le Mac Mini est accessible depuis le navigateur de mon iPhone via le nom MagicDNS du Mac Mini. Je peux être au café, voir mon Kanban se mettre à jour en temps réel sur mon téléphone et glisser des cartes entre les colonnes depuis l'écran de l'iPhone. Le Mac Mini bosse. Le téléphone est le volant.

La vidéo qui a inspiré une partie de ce texte écrivait le produit « Tailcale. » C'est en fait Tailscale, avec le S. Même produit, bonne orthographe, disponible sur tailscale.com. Gratuit pour un usage personnel. À installer aujourd'hui même si vous ne faites jamais tourner Hermes — mais si vous faites tourner Hermes, ça transforme ce qu'un agent sur une machine peut atteindre.

Une note de sécurité : quand vous mettez des appareils sur un tailnet, ils deviennent accessibles depuis tous les autres appareils de votre tailnet. C'est tout l'intérêt. Mais ça signifie qu'une compromission sur un appareil expose potentiellement les services sur les autres. Utilisez les ACL Tailscale pour délimiter ce que chaque appareil peut toucher. Ne faites pas tourner des services non authentifiés sur une IP tailnet juste parce que le mesh semble privé. Le mesh est privé. Les services doivent quand même s'authentifier.

Si ce genre de setup distribué vous intéresse, j'ai déjà écrit sur le déploiement d'agents autonomes sur un VPS avec notifications Discord — même philosophie, mesh différent.

Cas d'usage 6 : Le prompt de priorité matinal à 9h qui pilote ma journée

Le dernier cas d'usage est le plus petit de l'article, et celui que je défendrais avec le plus de véhémence.

Chaque matin à 9h, Hermes m'envoie un message sur Telegram avec une question : « Quelle est ta priorité numéro un aujourd'hui ? »

C'est tout. C'est le prompt entier.

Je réponds par une phrase. Parfois deux. Généralement quelque chose comme « livrer le redesign de la landing page de l'agence » ou « finir le deuxième brouillon de l'article sur Hermes » ou « appeler mon comptable et régler la facturation de la semaine dernière. »

Hermes fait trois choses avec ma réponse.

Il met à jour le wiki. Une nouvelle entrée arrive dans mon journal quotidien : la date du jour, la priorité, mes mots exacts. En fin de semaine, il y a une colonne que je peux scanner pour voir ce que je me suis dit important chaque jour. Des patterns émergent que je ne peux pas voir en temps réel.

Il génère des tâches de soutien. Si j'ai dit « livrer le redesign », Hermes dépose des cartes dans le Kanban : rechercher ce qui est actuellement sur la page, rassembler les assets de marque, rédiger trois variantes de hero, écrire trois options de meta description, préparer une checklist de déploiement. Je peux garder, supprimer ou modifier n'importe laquelle. La première fois j'en ai supprimé la moitié. Dès la deuxième semaine, j'en gardais la plupart. L'agent a appris quelles tâches de soutien je valorise et lesquelles non.

Il adapte son comportement. Au fil des semaines, l'agent construit un modèle de ce que je priorise, quand et pourquoi. Les lundis tendent vers les tâches de rédaction. Les mercredis vers le travail client. Les vendredis vers l'expédition ou la finalisation. L'agent utilise ce pattern pour orienter les tâches de soutien qu'il génère. Demandez-moi ma priorité du lundi et les tâches de soutien penchent vers recherche et plan. Demandez-moi ma priorité du vendredi et elles penchent vers vérifications de livraison et relecture.

La boucle d'auto-amélioration est tout le point. Le prompt matinal est le plus petit signal de feedback possible que vous pouvez donner à un agent qui veut apprendre votre workflow, et il produit le plus grand changement de comportement possible au fil du temps. Après trois mois, mon profil Hermes me connaît d'une manière que la première semaine d'utilisation n'aurait pas pu prédire.

Vous pouvez construire ce prompt en cinq minutes. Configurez une tâche cron dans Hermes (hermes cron create --time "09:00" --message "Quelle est ta priorité numéro un aujourd'hui ?"), pointez-la vers votre bot Telegram, donnez-lui une petite compétence appelée daily-priority-handler qui fait les trois choses ci-dessus, et laissez tourner.

La première semaine, c'est une question qui interrompt votre café. La troisième semaine, c'est un petit rituel que vous attendez avec impatience. Au troisième mois, c'est l'habitude la plus importante de votre journée.

Ce qui relie ces six cas d'usage

Six cas d'usage. Un pattern.

Chacun prend le même primitif — un Hermes Agent qui peut persister, apprendre et exécuter — et le transforme en une fonction de production différente. Le slashgoal est l'ouvrier de longue durée. Le Kanban est le dispatcher. Le moteur de recherche est l'analyste. Le wiki mémoire est la mémoire institutionnelle. Le mesh Tailscale est le réseau du bureau. Le prompt matinal est le standup meeting.

Faites-les tourner ensemble et vous n'avez pas un assistant IA. Vous avez une organisation. D'un humain et d'autant de profils Hermes que vous en créez.

Il y a un vrai inconvénient dont il faut être honnête. Le coût de maintenance n'est pas nul. Hermes publie des mises à jour fréquemment. Le décomposeur automatique du dispatcher Kanban devient opiniâtre de manières qui agacent occasionnellement. Le slashgoal touche parfois des murs et brûle du budget avant d'échouer utilement. La tâche cron du wiki a besoin d'un élagage occasionnel quand les pages thématiques deviennent volumineuses. Rien de tout ça n'est rédhibitoire. Tout est réel.

Mais la question n'est pas « est-ce que Hermes est parfait ? » C'est « est-ce que la main-d'œuvre produit plus qu'elle ne coûte ? » Pour moi, clairement oui. J'ai livré plus de code, écrit plus d'articles, mené plus de recherches et retenu plus de décisions ces six derniers mois avec Hermes que les douze mois précédents sans.

La nuit où le projet Godot a fini de compiler à 4h42 est la nuit où j'ai arrêté de me demander si je garderais ce setup.

Voici la seule question qui vaut la peine d'être méditée ce soir : si vous aviez une main-d'œuvre en standby maintenant — une qui ne dort jamais, n'oublie jamais, ne perd jamais le contexte — qu'auriez-vous déjà délégué ?

C'est le slashgoal que vous devriez taper ensuite.

Foire Aux Questions

Qu'est-ce que la commande slashgoal de Hermes Agent ?

Le slashgoal (/goal) est une commande de Hermes Agent qui fixe un objectif permanent que l'agent continuera de poursuivre au fil des échanges jusqu'à ce qu'il soit atteint, en utilisant ce que Nous Research appelle une boucle Ralph. Elle est conçue pour les tâches autonomes de longue durée — de quelques heures à plusieurs jours — avec un livrable clair. Pour le workflow complet du slashgoal et le pattern de métaprompting que j'utilise, voir la section slashgoal ci-dessus.

Comment fonctionne le tableau Kanban de Hermes Agent ?

Le Kanban Hermes est livré comme plugin de tableau de bord inclus et expose des colonnes pour triage, à faire, prêt, en cours, bloqué et terminé. Les cartes déposées dans la colonne Triage sont auto-routées par un dispatcher vers le bon profil d'agent en fonction des descriptions de profil que vous avez configurées. Vous le lancez avec hermes dashboard depuis le terminal.

Hermes Agent peut-il tourner de manière autonome pendant que je dors ?

Oui — c'est le cœur du design. Hermes tourne comme processus persistant sur un serveur, VPS ou machine locale à longue durée de vie, et continue d'exécuter les slashgoals ou les tâches Kanban même quand vous êtes hors ligne. Vous pouvez le consulter via Telegram, WhatsApp ou le tableau de bord web quand vous voulez un point de situation.

Ai-je besoin de Tailscale pour utiliser Hermes Agent ?

Non. Tailscale est optionnel, mais il élargit considérablement ce qu'un processus Hermes peut atteindre. Le VPN mesh de Tailscale permet à votre agent Hermes d'accéder aux fichiers et services sur chaque appareil que vous possédez — téléphone, tablette, laptop, serveur — comme s'ils étaient une seule machine. Voir le cas d'usage Tailscale ci-dessus pour la configuration.

Combien coûte le fonctionnement de plusieurs profils Hermes ?

Les coûts dépendent du modèle vers lequel vous routez chaque profil. Un profil Hermes tournant sur le Claude Sonnet 4.7 d'Anthropic est considérablement moins cher qu'un sur Opus 4.7. Mon setup mélange Opus pour l'orchestration et la relecture avec des modèles moins chers pour l'exécution routinière, et tourne confortablement pour moins de 200 $/mois entre plusieurs profils et un ou deux slashgoals de 23 heures par semaine.

Travaillons Ensemble

Vous cherchez à construire des systèmes IA, automatiser des workflows ou faire évoluer votre infrastructure technologique ? Je serais ravi de vous aider.

• Fiverr (builds et intégrations sur mesure) : fiverr.com/s/EgxYmWD
• Portfolio : mejba.me
• Ramlit Limited (solutions entreprise) : ramlit.com
• ColorPark (design et branding) : colorpark.io
• xCyberSecurity (services de sécurité) : xcybersecurity.io