Un agent IA dans le Telegram du dirigeant : retour d'expérience Hermes

Pourquoi un agent auto-hébergé plutôt qu'un abonnement ChatGPT

Un dirigeant qui a testé ChatGPT a en général le même retour : c'est impressionnant, et ça ne change rien à sa journée. Il faut ouvrir un onglet, tout réexpliquer à chaque fois, copier-coller les mails, et au bout du compte c'est encore lui qui fait l'action. Le problème n'est pas l'intelligence de l'outil. C'est qu'il n'est branché sur rien.

Un agent auto-hébergé inverse les quatre points qui bloquent.

Hermes Agent en deux minutes

Hermes Agent est un agent IA open source publié par Nous Research début 2026, sous licence MIT. Il s'installe sur un serveur Linux, se connecte aux messageries courantes, garde une mémoire persistante, sait planifier des tâches récurrentes, piloter un navigateur et exécuter des commandes dans un environnement isolé. Il ne dépend d'aucun fournisseur de modèle : on lui donne l'accès qu'on veut, cloud ou local.

Surtout, il parle MCP, le protocole qui connecte un agent à des outils externes. C'est ce point qui le rend intéressant pour une entreprise, et c'est aussi là que le travail commence, parce que le protocole ne fournit pas les connecteurs. Il fournit la prise.

L'installation chez le dirigeant, et la boîte mail

Le dirigeant pilote une dizaine de sociétés. Il n'a pas le temps d'un onglet de plus, ni d'un outil à apprendre. Le point de départ était donc simple : il parle à l'agent sur Telegram, le plus souvent en vocal, et l'agent lui répond là.

Côté modèle, on a retenu DeepSeek V4 Pro via OpenRouter, pas de modèle local. Le raisonnement est économique : un agent qui trie des mails chaque nuit et répond à des vocaux toute la journée consomme beaucoup de jetons, et à qualité équivalente sur ces tâches, l'écart de prix avec les modèles premium est important. Si demain le client veut un modèle hébergé en Europe ou un modèle Anthropic pour certaines tâches, c'est une ligne de configuration. L'agent, sa mémoire et ses connecteurs ne bougent pas.

Première tâche : 26 000 messages

Sa boîte mail contenait 26 000 messages. Pas un archivage, une boîte de réception vivante, où les factures, les devis, les demandes de ses directeurs et les newsletters arrivaient au même endroit depuis des années. On n'a pas demandé à l'agent de tout ranger d'un coup. On lui a fait proposer un classement sur un premier lot, on l'a fait valider, puis on a automatisé.

Les 40 messages non classés ne sont pas un échec, c'est le comportement qu'on voulait. Un agent qui range 100 % des mails est un agent qui a rangé des choses qu'il ne comprenait pas. Ceux qu'il laisse en boîte de réception sont ceux sur lesquels le dirigeant tranche en dix secondes le matin. Et chaque décision qu'il prend devient une règle pour les nuits suivantes.

Le mur des outils métier, et les MCP qu'on a écrits

Hermes sort de la boîte avec les messageries, le web, un navigateur et un terminal. C'est déjà beaucoup. Mais dès qu'on veut qu'il lise la boîte mail professionnelle, regarde la compta, suive les projets, publie sur les pages de l'entreprise ou consulte la téléphonie, il n'y a rien. Aucun agent open source ne livre les connecteurs vers les outils d'une PME française, et les catalogues de connecteurs tout faits couvrent surtout des SaaS américains.

On a comblé de deux façons. Pour la compta et le CRM, qui tournent sous Odoo, des compétences Hermes, c'est-à-dire des procédures que l'agent sait suivre avec les accès qu'on lui donne. Pour tout le reste, des serveurs MCP écrits en Go par nos soins, que nous réutilisons d'une installation à l'autre.

Cette liste n'est pas figée, et c'est le point important : un connecteur pour un outil qui a une API s'écrit en quelques jours. Quand un client arrive avec un logiciel qu'on n'a jamais branché, on l'ajoute, en lecture d'abord, et le code lui est livré. La question MCP ou simple API se pose à chaque connecteur, et la réponse n'est pas toujours MCP.

Pourquoi Go ? Parce qu'un connecteur MCP est un petit serveur qui doit tourner des mois sans surveillance, avec une empreinte minuscule, et c'est exactement ce que Go fait bien. Et parce qu'un client qui nous confie sa messagerie doit pouvoir faire relire, par qui il veut, le programme qui la touche : un code court et lisible compte autant que le protocole.

Ce qui a cassé, et ce qu'on en a tiré

Un jour, le serveur s'est figé. En remontant les traces, on a trouvé la cause dans la mémoire de l'agent. Il s'y était noté, seul, une règle du type « si le cloud échoue, installer un modèle vocal local ». Et il l'a appliquée. Sur un serveur à 15 € par mois, télécharger et charger un modèle de reconnaissance vocale, c'est le geler.

Cette panne est la meilleure chose qui soit arrivée au projet. Elle a fixé la liste des garde-fous qu'on pose maintenant avant même de brancher le premier outil.

Les garde-fous qu'on pose systématiquement

• Un serveur par entreprise. Jamais de mutualisation entre clients. Les données, la mémoire et les accès d'un dirigeant ne cohabitent avec rien d'autre.
• Des droits outil par outil. Le protocole MCP permet de n'exposer que certaines actions d'un connecteur. Lire et déplacer des mails, oui. Supprimer, non. Envoyer, seulement après validation dans la conversation.
• La lecture avant l'écriture. Un connecteur commence toujours en lecture seule. On n'ouvre l'écriture qu'une fois que le dirigeant a vu l'agent travailler et qu'il sait ce qu'il fait.
• Une mémoire relue. Ce que l'agent se note lui-même est vérifié à intervalle régulier, et les règles structurantes sont écrites par nous, pas par lui.
• Un modèle interchangeable. Le choix du modèle est un réglage, pas une architecture. Si le contexte réglementaire ou la sensibilité des données l'exige, on bascule sur un modèle hébergé en Europe sans rien réinstaller.
• Quelqu'un qui répond. Un agent qui agit sur des outils réels a besoin d'un humain joignable quand il sort du cadre. Ça fait partie de l'offre, pas de l'option.

À qui ça convient, à qui ça ne convient pas

Pour voir à quoi ressemblerait la même approche dans d'autres situations, on a détaillé douze cas d'usage d'un agent connecté, par type d'entreprise, avec pour chacun les connecteurs qu'on a déjà et ceux qu'il faudrait écrire.

Questions fréquentes