Hermès est mon assistant personnel. Le mien, pas le gros projet open source du même nom qui a fait parler de lui ensuite : j’avais déjà baptisé le dossier ~/Hermes avant qu’il sorte. Le nom était surtout évident pour un système qui transporte des messages, des signaux et des décisions, et le code n’a pas vocation à devenir un produit générique. C’est précisément parce qu’il est très personnel qu’il m’est utile.
Je l’ai construit parce qu’une partie de mon quotidien professionnel ressemble à celui de beaucoup d’indépendants et de petites équipes : des choses importantes sont éparpillées dans Gmail, GitHub, Sentry, Pennylane, Things (mon gestionnaire de tâches), des fichiers Markdown, des dashboards internes et quelques coins de cerveau qui auraient préféré servir à autre chose. Une CI qui tombe, une erreur Sentry qui revient, un devis à relancer, une facture à suivre, un projet presque fini qui risque de rester coincé : aucune de ces tâches n’est très compliquée seule. Leur accumulation, en revanche, finit par créer une charge mentale assez médiocre.
Le pitch ridicule serait de dire que j’ai créé un “operating system agentique personnel”. On pourrait même ajouter “augmenté par l’IA” pour être sûr de perdre tout le monde sauf deux consultants LinkedIn et un vendeur de formation prompt engineering. La réalité est plus simple : Hermès est un ensemble de petits agents locaux, lancés sur mon Mac, avec des fichiers d’état, des scripts Python, un dashboard privé, quelques intégrations métier, et surtout des règles assez strictes sur ce qu’ils ont le droit de faire.
Certains agents utilisent un LLM. Beaucoup n’en utilisent pas. C’est un détail important, parce que le bon usage de l’IA n’est pas de remplacer tous les if par une prière tarifée au million de tokens. Quand une tâche est déterministe, un script bête et fiable est souvent supérieur. Quand il faut résumer des signaux hétérogènes, proposer un arbitrage ou formuler trois options claires, un LLM peut être utile. La difficulté n’est pas d’ajouter de l’IA partout, mais de savoir où elle mérite vraiment d’entrer dans la boucle.
Un outil personnel, pas un framework générique
Je pense de plus en plus que l’IA devient réellement efficace quand elle est intégrée dans un outil très personnel, au sens strict : un outil fait pour une personne, avec ses réflexes, ses angles morts, ses priorités et sa manière de décider. Hermès n’est pas un greffon extérieur posé sur mon travail. C’est une extension de ma façon de travailler : mes sources d’information, mes seuils de risque, mes habitudes de décision, et les endroits précis où je veux reprendre la main.
C’est pour ça que je suis assez méfiant avec les frameworks d’agents génériques vendus comme des raccourcis. Ils peuvent être utiles pour prototyper, mais leur structure embarque déjà une vision du travail : comment la mémoire fonctionne, comment les tâches sont routées, ce qui compte comme une réussite, quand escalader, comment notifier, ce qu’on considère comme une action. Utiliser le framework d’un autre sans le remettre en question, c’est souvent adopter la logique d’un autre. Parfois elle colle à votre problème. Souvent elle colle surtout à la démo de celui qui l’a écrite.
On a déjà vu ce film avec les SPA React. Pendant des années, des sites vitrines, des back-offices minuscules et des formulaires assez banals ont absorbé la complexité de Facebook en pensant devenir Facebook. Ils ont surtout récupéré le coût mental, les bundles trop lourds, les états clients fragiles et les bugs d’hydratation, sans avoir le problème qui justifiait l’architecture. L’IA prend exactement le même chemin quand on commence par choisir une stack d’agents avant de comprendre le travail réel à automatiser.
Hermès est donc volontairement construit autour de mes contraintes. Mon inbox est ma todo-list. Things est l’endroit des vraies actions. Le dashboard porte les informations passives. Telegram sert aux arbitrages urgents. Les clients, les devis, les incidents et les projets ont déjà des sources de vérité. Le système n’a pas à inventer un monde parallèle ; il doit relier ce qui existe et me déranger seulement quand ça vaut le coût.
Ce que le système doit résoudre
Le besoin de départ n’était pas “avoir un agent”. Je n’avais pas besoin d’un chatbot de plus à qui il faut penser à parler, auquel il faut redonner le contexte, puis dont il faut vérifier la réponse. C’est parfois utile pour réfléchir ou produire un brouillon, mais ça ne retire pas vraiment la charge opérationnelle. Ça la déplace dans une fenêtre de chat, avec une interface plus polie et le même problème derrière.
Ce que je voulais, c’était savoir chaque matin ce qui mérite mon attention, éviter de découvrir trop tard une PR bloquée ou une erreur de production, suivre les devis sans transformer mon cerveau en CRM low-cost, garder le contexte client disponible avant un call, et surtout terminer les sujets proches de la fin au lieu d’ouvrir quinze fronts en parallèle. La plupart de ces besoins sont prosaïques. C’est justement pour ça qu’ils sont importants : un outil utile commence souvent par retirer de la friction banale, pas par annoncer qu’il va réinventer le travail.
La frontière que j’ai posée dès le départ est simple : Hermès peut observer, classer, résumer, préparer, signaler et proposer. Il ne doit pas se prendre pour moi. Il ne publie pas un devis, n’envoie pas un mail client, ne prend pas une décision d’architecture, ne modifie pas un projet au-delà de correctifs triviaux, et ne crée pas de bruit pour prouver qu’il travaille. J’ai déjà assez de logiciels qui confondent activité et utilité.
Vue d’ensemble anonymisée : le dashboard garde les actions, les signaux et l’état des agents au même endroit, sans transformer chaque information en notification.
Une architecture volontairement ordinaire
Hermès tourne localement sur mon Mac. Un scheduler géré par launchd lit un fichier schedule.toml, regarde quels agents sont dus, applique des préconditions simples, puis lance les jobs. Les runs écrivent leurs logs, leur état, et une page HTML de dashboard. Les états partagés sont des fichiers JSON ou JSONL, les notes plus humaines sont en Markdown, et les tâches déterministes passent par des scripts Python.
Cette architecture n’impressionnera personne dans une conférence sur l’IA, et c’est très bien. Je préfère un système que je peux comprendre à 23 h, quand quelque chose ne tourne plus, à une plateforme magique où trois abstractions propriétaires masquent un cron, une queue et un prompt. Le jour où ça casse, je veux ouvrir un fichier, lire un log, comprendre quel agent a écrit quoi, et corriger. Le reste est souvent de la décoration vendue au prix du SaaS.
Le scheduler limite aussi la concurrence. Il ne lance pas vingt agents parce que vingt agents existent. Certains jobs tournent en Python pur, notamment quand la logique est stable et que l’appel LLM ne ferait qu’ajouter du coût et de l’aléatoire. D’autres passent par un modèle quand ils doivent agréger des signaux moins structurés. Ce mélange n’est pas très dogmatique, mais il a le mérite d’être honnête : l’IA est un composant, pas une religion d’architecture.
Des agents avec un métier précis
Chaque agent a un périmètre étroit. C’est probablement le choix le plus important du projet. Un agent “assistant général” finit vite par avaler tout le contexte disponible et agir avec une confiance inversement proportionnelle à sa compréhension réelle. Un agent qui lit une queue précise, produit un état précis et écrit un dashboard précis est beaucoup plus ennuyeux, mais il est aussi beaucoup plus exploitable.
Le morning briefing prépare la synthèse de début de journée : PRs à revoir, tâches échouées, activité de nuit, signaux Sentry, queue de travail. Inbox triage lit l’inbox Gmail parce que mon inbox est volontairement une todo-list ; il classe les threads, détecte ceux qui vieillissent, peut préparer des brouillons administratifs simples, mais il ne touche pas aux mails client ou prospect. Project focus choisit les trois projets à pousser dans la journée en favorisant ce qui est proche du fini, ce qui a reçu un signal client ou ce qui risque de se bloquer.
Dev agent est encore plus encadré. Il peut traiter quelques erreurs Sentry évidentes, des merges Dependabot sans risque, ou des corrections CI mécaniques. Il n’a pas le droit de faire du produit, de l’architecture, du refactoring ou des bugs applicatifs ambigus. Le moindre doute sort du scope. C’est frustrant pour une démo, mais très sain pour un outil qui touche à de vrais repos.
Les agents business suivent le même principe. Pennylane sync récupère les factures, transactions et soldes pour maintenir une vision de trésorerie, mais il reste en lecture seule. Estimates suit les devis et prépare des propositions, mais aucun envoi ou upload public ne part sans validation explicite. Client context keeper reconstruit des dossiers clients vivants à partir des devis, factures, conversations récentes, PRs et incidents, en préservant les notes manuelles. Le but n’est pas de remplacer le jugement humain ; c’est d’arriver devant une décision avec le bon contexte.
Project Focus ne cherche pas le projet le plus séduisant. Il pousse ce qui doit avancer : projets presque finis, signaux clients récents, blocages explicites.
L’attention comme contrainte produit
Le plus gros piège de l’automatisation n’est pas l’échec complet. C’est le système qui marche assez pour produire du bruit. Une alerte inutile devient une interruption, une interruption répétée devient un réflexe d’ignorance, et un système ignoré finit par être pire qu’un système absent : il donne l’impression qu’une surveillance existe alors que plus personne ne l’écoute.
Hermès sépare donc les canaux. Le dashboard contient les informations passives, Things contient les actions que je dois réellement faire, Telegram sert aux urgences ou aux arbitrages courts, et les fichiers d’état gardent l’historique pour les prochains runs. Une facture attendue dans trois jours n’est pas forcément une action. Un client à relancer, oui. Une PR déjà mergée ne doit pas recréer un todo parce qu’un agent a relu un vieux JSON avec l’enthousiasme administratif d’un formulaire Cerfa sous amphétamines.
Il y a de la déduplication, des fenêtres anti-spam, des règles “un sujet = un todo”, et des cas où Hermès choisit explicitement de ne rien me pousser. C’est moins spectaculaire qu’une avalanche de notifications, mais c’est ce qui rend le système utilisable. L’attention est une ressource limitée ; un assistant qui la gaspille travaille contre moi, même si ses intentions sont statistiquement bienveillantes.
Les refus sont une fonctionnalité
La partie la plus importante d’Hermès n’est pas la liste de ce qu’il peut faire, mais celle de ce qu’il refuse. Pas d’envoi automatique de mail client. Pas de publication de devis sans validation explicite. Pas de modification de code au-delà d’un périmètre trivial. Pas de décision d’architecture. Pas de todo Things pour la cuisine interne. Pas de “je pense que…” quand le système peut poser une question claire avec trois options actionnables.
C’est là que l’approche produit compte vraiment. Quand on découvre les agents, le réflexe naturel est d’ajouter des capacités : répondre aux clients, publier les devis, merger les PRs, décider du prochain chantier, réorganiser le planning. Certaines de ces capacités peuvent être pertinentes un jour. Mais la bonne question n’est pas “est-ce possible techniquement ?”. La bonne question est “quelle erreur devient possible si je l’autorise ?”.
Un agent qui peut tout faire n’est pas nécessairement puissant. C’est souvent une surface d’accident avec une bonne UX. Hermès est utile parce qu’il sait s’arrêter aux endroits où mon jugement reste nécessaire : arbitrer un besoin client, accepter un risque commercial, valider une proposition, décider qu’une demande contredit la raison d’être d’un logiciel. Ces décisions ne sont pas des détails gênants à automatiser ; ce sont précisément les endroits où se trouve la valeur.
Une mémoire inspectable
La mémoire d’Hermès n’est pas magique. Ce sont des fichiers. JSON, JSONL, Markdown. C’est basique, versionnable, inspectable et réparable. Chaque agent lit ce dont il a besoin et écrit dans des zones précises : queue de dev, mémoire des PRs, tâches échouées, signaux projet, réponses aux questions, dossiers clients.
Je n’ai rien contre la recherche sémantique ; Hermès en utilise quand elle apporte quelque chose. Mais la mémoire opérationnelle d’un système de travail doit rester lisible. Un agent qui justifie une décision par “j’ai trouvé ça dans ma mémoire” sans qu’on puisse inspecter la source n’est pas intelligent. Il est pénible à auditer, ce qui est une manière très moderne d’être dangereux.
Le dashboard joue le même rôle. Il ne sert pas à faire joli, même si j’ai fini par lui donner une forme correcte parce que je suis faible devant une interface propre. Il permet surtout de vérifier qu’un agent a tourné, ce qu’il a vu, ce qu’il a fait, et parfois ce qu’il a refusé de faire. Les dates sont absolues, pas relatives, parce qu’un “il y a deux heures” devient vite faux dans une page mise en cache ou une capture. Les timestamps viennent du système, pas de l’imagination du modèle. Un agent qui écrit une date future n’est pas visionnaire, il est juste cassé.
Ce que ça montre vraiment
Hermès est un side project, mais ce n’est pas un caprice technique. C’est une manière de traiter mon activité comme un produit interne. Le besoin n’était pas d’utiliser de l’IA ; le besoin était de réduire les oublis, prioriser le travail réellement utile, garder une vision financière exploitable, éviter les tâches administratives répétitives, rendre le contexte client disponible au bon moment et préserver les décisions humaines là où elles ont de la valeur.
Cette logique ressemble beaucoup à celle que j’applique chez mes clients. Avant de développer, il faut comprendre le travail réel : qui fait quoi, avec quelles informations, dans quel ordre, avec quels risques, et quelles décisions ne doivent surtout pas être automatisées. Ensuite seulement on choisit l’outil. Parfois il faut un logiciel sur mesure complet. Parfois il faut automatiser trois étapes pénibles. Parfois il faut surtout arrêter de demander à Excel de jouer l’ERP, le CRM, le planning, le reporting et la conscience collective de l’entreprise. Excel est très fort, mais il a lui aussi droit à une retraite digne.
Je ne vais pas publier Hermès tel quel. Il contient ma vie professionnelle, mes clients, mes finances, mes emails et assez de chemins internes pour faire tousser n’importe quel RSSI normalement constitué. Les principes, eux, sont réutilisables : partir d’une friction récurrente, distinguer information, action et décision, donner un périmètre étroit à chaque automatisation, garder l’état inspectable, mettre l’humain dans la boucle aux bons endroits, et utiliser un LLM pour l’ambiguïté plutôt que pour remplacer un script fiable.
Si ce genre de situation vous parle
Hermès est personnel, mais le problème est très courant : informations dispersées, processus manuels, relances oubliées, décisions prises sans vue d’ensemble, outils SaaS trop génériques, Excel qui tient encore debout par patriotisme local. Dans ces situations, la bonne question n’est pas “comment mettre de l’IA dans l’entreprise ?”, mais plutôt : quelles tâches reviennent tout le temps, quelles décisions demandent vraiment un humain, quelles informations arrivent trop tard, et quels outils existants peuvent être reliés au lieu d’être remplacés.
C’est le genre de travail que je fais chez SXN Labs : comprendre le métier, trouver les vraies frictions, construire le logiciel ou les automatisations qui couvrent le besoin, puis laisser derrière un système simple à utiliser, observable et maintenable. Pas une démonstration magique. Un outil qui sert, avec suffisamment de limites pour rester fréquentable.