Un assistant d'entreprise sur votre propre serveur

Vous avez déjà accès à des assistants excellents, chez Anthropic, OpenAI ou ailleurs. Alors pourquoi monter le vôtre ? Trois raisons, et une seule d'entre elles suffit rarement à justifier l'effort — c'est leur cumul qui décide.

La persistance. Un assistant grand public repart de zéro à chaque conversation, ou presque. Ici, l'agent accumule : il retient les décisions, les préférences, les habitudes de l'entreprise, et il s'en sert six mois plus tard sans qu'on lui rappelle.

L'autonomie. Il ne se contente pas de répondre : il exécute des commandes, lit et écrit des fichiers, appelle des API, et il peut le faire seul à 6 h du matin parce qu'une tâche planifiée l'a déclenché.

La maîtrise. Le serveur est à vous, les données restent où vous décidez, et vous changez de fournisseur de modèle en modifiant une ligne de configuration. Pour une entreprise qui manipule des données clients, ce dernier point n'est pas un caprice d'ingénieur : c'est ce qui rend le dossier défendable devant un client industriel qui pose des questions.

Le piège classique consiste à voir ce système comme un bloc. Il en compte trois, indépendants, et c'est justement ce qui permet d'en remplacer un sans tout casser.

┌─────────────────────────────────────────────────────────┐
│  SURFACES DE COMMANDE                                   │
│  Telegram · terminal SSH · dashboard web · API HTTP     │
└──────────────────────────┬──────────────────────────────┘
                           │
┌──────────────────────────▼──────────────────────────────┐
│  AGENT  (Hermes Agent)                                  │
│  boucle de raisonnement · outils · skills · droits      │
│  personnalité (SOUL.md) · tâches planifiées (cron)      │
└─────┬───────────────────────────────────────┬───────────┘
      │                                       │
┌─────▼──────────────────┐      ┌─────────────▼───────────┐
│  MÉMOIRE               │      │  CONNAISSANCES          │
│  Hindsight             │      │  base vectorielle       │
│  ce qu'il a vécu       │      │  ce que l'entreprise sait│
└────────────────────────┘      └─────────────────────────┘
                     │                  │
              ┌──────▼──────────────────▼──────┐
              │  MODÈLE (API ou local)          │
              └─────────────────────────────────┘

Les surfaces sont les portes d'entrée. Telegram depuis le téléphone, le terminal en SSH quand on met les mains dedans, un dashboard web, et une API HTTP compatible OpenAI qui permet de brancher n'importe quelle interface tierce. On peut en ajouter ou en retirer sans toucher au reste.

L'agent est le cerveau exécutif : il reçoit une demande, se fait un plan, appelle des outils, et rend un résultat. C'est lui qui porte la personnalité, les droits et les tâches planifiées.

La mémoire et les connaissances sont deux choses différentes, et les confondre est l'erreur qui plombe la plupart des projets. La mémoire, c'est ce que l'agent a vécu : « le client X préfère être appelé le mardi ». Les connaissances, c'est ce que l'entreprise sait indépendamment de lui : ses procédures, ses offres, ses contrats. La première se remplit toute seule, la seconde se construit.

Vous êtes sur le point d'installer, sur une machine exposée à Internet, un logiciel qui exécute des commandes, lit vos fichiers et détient des clés d'API. Le durcissement n'est pas une étape optionnelle de fin de projet : c'est la première.

Deuxième principe, et c'est celui qui structure tout le reste : rien de ce système ne s'expose à Internet. Ni l'API de l'agent, ni celle de la mémoire, ni le dashboard. Tout écoute en local, et vous y accédez par un tunnel SSH depuis votre poste.

# Depuis votre poste : on redirige un port local vers le serveur.
# Rien n'est ouvert côté Internet, le trafic passe dans le tunnel SSH.
ssh -L 9119:127.0.0.1:9119 agent@votre-serveur

# Puis, dans le navigateur : http://localhost:9119

L'installation se fait sous l'utilisateur dédié, dans un environnement Python isolé. Toute la configuration vit ensuite dans un répertoire unique, ~/.hermes/, ce qui rend la sauvegarde et la reprise triviales.

# ~/.hermes/config.yaml — le fichier central
model:
  default: gpt-5-mini          # le modèle courant
  provider: openai-api         # tout point d'accès compatible OpenAI
  base_url: https://api.openai.com/v1

toolsets:
  - hermes-cli

agent:
  max_turns: 60                # garde-fou anti-boucle infinie
  gateway_timeout: 1800        # 30 min pour une tâche longue

Vient ensuite la partie que tout le monde sous-estime : la personnalité. Un fichier SOUL.md, chargé à chaque session, définit qui est cet agent, comment il s'adresse à vous, ce qu'il fait de sa propre initiative et ce qu'il ne fait jamais. Ce n'est pas de la décoration : c'est ce qui différencie un assistant qui vous fait gagner du temps d'un assistant qu'il faut reprendre à chaque message.

# Identité
Tu es l'assistant interne de [ENTREPRISE], [SECTEUR], [TAILLE].
Tu assistes [PRÉNOM], [FONCTION].

# Ton
Français professionnel, direct, sans flagornerie. Pas de listes à puces
quand une phrase suffit. Tu ne commences jamais par « Excellente question ».

# Ce que tu fais de toi-même
- Tu consultes la base de connaissances avant de répondre sur un sujet métier.
- Tu signales quand une information te manque plutôt que de combler le vide.
- Tu retiens les décisions et les préférences exprimées, sans qu'on te le demande.

# Ce que tu ne fais jamais sans validation explicite
- Envoyer un message, un email ou un document à un tiers.
- Modifier ou supprimer un fichier hors de ton répertoire de travail.
- Engager une dépense, où que ce soit.
- Divulguer une information relative à un client à qui que ce soit d'autre
  que [PRÉNOM].

# Contexte permanent
Nos clients sont [TYPE]. Notre vocabulaire : [TERMES MÉTIER].
Notre exercice comptable va de [DATE] à [DATE].
Quand je dis « le rapport », je parle de [PRÉCISION].

Nativement, un agent Hermes dispose d'une mémoire volontairement minuscule : deux fichiers, l'un pour ses propres notes, l'autre pour le profil de son utilisateur, plafonnés à quelques milliers de caractères. C'est un choix d'ingénierie assumé — ces fichiers sont injectés à chaque session, donc ils doivent rester courts.

Pour aller au-delà, on branche un fournisseur de mémoire externe. Hindsight tourne alors dans un conteneur à côté de l'agent, et lui donne trois capacités : mémoriser en extrayant automatiquement les entités, rechercher en combinant similarité sémantique et graphe d'entités, et synthétiser en recoupant plusieurs souvenirs.

Les souvenirs sont regroupés en banks — des espaces logiques. Une bank par contexte est une bonne pratique : ce que l'agent apprend en travaillant sur un client n'a pas à ressortir dans une conversation sur un autre. C'est aussi votre premier niveau de cloisonnement.

Cela dit, il y a trois niveaux d'ambition, et le premier suffit à beaucoup de monde. Montez-les dans l'ordre : chacun coûte nettement plus cher que le précédent, et l'expérience montre qu'on s'arrête souvent au deuxième.

Le niveau 3 mérite qu'on s'y arrête, car c'est là que se joue l'argument de coût que vous avez peut-être en tête. Injecter cinquante pages dans le contexte à chaque question coûte cher et ralentit tout. Rechercher les cinq passages pertinents et n'injecter qu'eux coûte une fraction du prix et répond plus vite. C'est ça, le gain de la vectorisation : pas la qualité, l'économie.

Côté implémentation, la documentation d'Hermes donne le patron directement : un skill déclare les variables dont il a besoin, et son mode d'emploi indique à l'agent comment interroger votre base.

---
name: base-connaissances
description: Recherche dans la base documentaire de l'entreprise
version: 1.0.0
required_environment_variables:
  - name: KB_API_URL
    prompt: URL du service de recherche
  - name: KB_API_KEY
    prompt: Clé d'accès au service
metadata:
  hermes:
    requires_toolsets: [terminal]
---

# Base de connaissances interne

## Quand l'utiliser
Systématiquement, avant de répondre à toute question portant sur nos
procédures, nos offres, nos clients ou notre historique. Ne réponds
jamais de mémoire sur ces sujets.

## Procédure
1. Formule une requête de recherche à partir de la question posée.
2. Interroge le service, récupère les extraits les plus pertinents.
3. Réponds en t'appuyant uniquement sur ces extraits, et cite pour
   chaque affirmation le document d'origine.

## Pièges
Si la recherche ne renvoie rien de pertinent, dis-le. Ne comble pas
le silence avec une réponse plausible.

C'est le chapitre qui sépare un gadget d'un outil professionnel. Un agent qui peut exécuter des commandes sur un serveur d'entreprise doit avoir des limites explicites, écrites, et vérifiables. Hermes propose pour cela une défense en profondeur dont voici les étages qui comptent vraiment.

# ~/.hermes/config.yaml
approvals:
  mode: smart          # smart | manual | off
  timeout: 300         # refus automatique passé ce délai
  cron_mode: deny      # une tâche planifiée n'obtient JAMAIS d'approbation
  deny:                # règles absolues, prioritaires sur tout le reste
    - "git push --force*"
    - "*curl*|*sh*"
    - "rm -rf /*"

command_allowlist:     # commandes validées une fois pour toutes
  - systemctl status*

Trois réglages méritent une attention particulière, parce qu'ils sont contre-intuitifs.

Les tâches planifiées ne doivent jamais pouvoir s'auto-approuver. Le réglage dédié doit rester sur « refuser » : personne ne surveille une tâche qui s'exécute à 6 h du matin, c'est exactement le moment où une approbation automatique fait des dégâts.

Les règles de refus priment sur tout, y compris sur un mode permissif activé par mégarde. C'est votre dernier filet : mettez-y ce qui ne doit jamais arriver, quelles que soient les circonstances.

Le périmètre d'écriture se restreint par variable d'environnement. Vous déclarez les répertoires dans lesquels l'agent a le droit d'écrire, et toute tentative en dehors est refusée. Indépendamment de cela, une liste de chemins sensibles — clés SSH, fichiers d'identifiants, fichiers .env — reste bloquée en dur, même si vous les incluez dans le périmètre autorisé.

Telegram est la meilleure surface pour ce type d'assistant, et pour une raison prosaïque : elle est déjà sur votre téléphone, elle gère les fichiers et la voix, et son API de bots est stable depuis dix ans. Vous envoyez une instruction depuis un quai de gare, le serveur travaille, la réponse arrive.

Telegram est parfait pour la commande courte, beaucoup moins pour lire un rapport de trois pages ou reprendre une longue conversation. D'où l'envie d'une interface web. L'agent expose pour cela une API compatible OpenAI, ce qui permet de brancher n'importe quel client du marché — l'interface libre la plus répandue, ou la vôtre.

Le principe : l'API écoute en local, protégée par une clé, et l'interface s'y connecte en la déclarant comme un fournisseur de modèle personnalisé, avec l'adresse et la clé.

La méthode propre consiste à placer les deux conteneurs sur un réseau Docker dédié et à les faire dialoguer par leur nom de service, sans jamais passer par l'hôte ni par une interface exposée.

# Un réseau privé pour les deux services
docker network create reseau-agent

# Chaque conteneur y est rattaché
docker network connect reseau-agent interface-web
docker network connect reseau-agent service-agent

# Depuis l'interface, l'agent est joignable par son nom de service,
# et par personne d'autre :
#   http://service-agent:8642/v1

Si l'agent tourne directement sur l'hôte et non dans un conteneur — ce qui est le cas de l'installation décrite ici — cette solution ne s'applique pas telle quelle. Il faut alors soit conteneuriser l'agent, soit écrire une règle de pare-feu autorisant précisément le sous-réseau Docker à joindre le port concerné, sans rien ouvrir vers l'extérieur. La première option est plus propre et se sauvegarde mieux.

Un assistant qui ne sait rien faire d'autre que parler a peu d'intérêt. Les skills sont des modes d'emploi écrits en markdown, rangés dans un répertoire, que l'agent découvre et déclenche seul quand la situation s'y prête. Chacun déclare les identifiants dont il a besoin, et l'agent les réclame à la configuration.

Le catalogue livré couvre déjà l'essentiel de la bureautique — messagerie, agenda, stockage, documents et tableurs d'une suite bureautique courante. C'est celui-là qui transforme l'assistant : il peut lire vos mails, préparer un brouillon de réponse, poser un créneau dans l'agenda ou déposer un fichier.

Au-delà du catalogue, un skill maison se résume à un fichier markdown avec un en-tête. Le format récompense la précision : un skill qui dit clairement quand l'utiliser, comment procéder et quels sont les pièges sera déclenché à bon escient. Un skill vague sera déclenché n'importe quand, ou jamais.

Un dernier point de sécurité, souvent négligé : l'agent peut créer et modifier ses propres skills. Sur une machine d'entreprise, exigez une validation humaine — les écritures sont alors mises en attente jusqu'à votre approbation. Un agent qui se réécrit ses propres règles sans contrôle, c'est précisément ce qu'on veut éviter.

C'est le moment où l'assistant cesse d'être un outil qu'on sollicite pour devenir une présence qui travaille. Une revue des messages non traités le matin, une synthèse des indicateurs le lundi, une alerte quand un dossier n'a pas bougé depuis quinze jours.

Les tâches planifiées vivent dans le répertoire de configuration de l'agent et s'exécutent selon leur propre horloge. Trois principes, appris par l'expérience et par la documentation :

• Aucune approbation automatique. Le réglage dédié doit rester sur refus. Une tâche planifiée qui rencontre une commande sensible doit échouer et vous prévenir, pas décider seule.
• Jamais d'envoi vers l'extérieur sans supervision. Une tâche qui rédige un brouillon, oui. Une tâche qui envoie le mail, non — quel que soit votre niveau de confiance.
• Une notification à chaque exécution, y compris quand tout va bien. Une tâche silencieuse qui a cessé de fonctionner depuis trois semaines est pire que pas de tâche du tout.

Le durcissement du serveur, vu au début, n'est que la moitié du sujet. L'autre moitié concerne ce que l'agent lit et ce qu'il peut en faire — et c'est là que se situent les vrais risques, ceux qu'aucun pare-feu n'arrête.

Côté conformité, trois questions à trancher avant la mise en service, et non après. Où sont les données ? Le serveur est chez vous ou chez un hébergeur européen, c'est l'argument fort du montage. Mais si votre modèle est appelé par API, les contenus transitent chez ce fournisseur : vérifiez sa localisation et ses engagements, et mentionnez-le. Quelle base légale ? Un traitement automatisé de correspondance professionnelle contenant des données personnelles doit figurer au registre. Combien de temps ? Une mémoire persistante conserve par construction — définissez une durée et une procédure d'effacement, sinon vous accumulez indéfiniment.

Trois leviers font baisser la facture d'appels de façon spectaculaire, et ils vont tous dans le même sens : envoyer moins de contexte. Choisir un modèle d'entrée de gamme pour les tâches courantes et réserver le modèle haut de gamme aux passages difficiles. Plafonner le nombre de tours de boucle par tâche — un agent qui s'entête coûte cher. Et surtout, remplacer l'injection massive de documents par une recherche qui ne remonte que les extraits utiles : c'est le vrai argument économique de la vectorisation.

Ce qui marche remarquablement bien. La persistance : retrouver six semaines plus tard un agent qui sait de quoi on parle change vraiment le rapport à l'outil. Le pilotage par messagerie : envoyer une instruction du téléphone et récupérer le résultat plus tard devient une habitude en trois jours. Et l'agnosticisme au modèle : changer de fournisseur revient à modifier deux lignes, ce qui est une assurance rare par les temps qui courent.

Ce qui casse. Le réseau entre conteneurs, systématiquement, et c'est ce qui a bloqué l'interface web de cette installation. Les services lancés à la main dans un multiplexeur de terminal, qui ne survivent pas à un redémarrage — passez tout en service géré par le système dès que ça fonctionne. Les mises à jour, qui déplacent parfois un réglage. Et la mémoire, qui se pollue lentement si personne ne la relit.

Ce qui manque. L'ingestion documentaire native, on l'a dit : c'est la brique à construire soi-même, et c'est la plus lourde. Une interface d'administration des droits digne de ce nom — aujourd'hui tout se passe dans des fichiers YAML. Et une vraie gestion multi-utilisateurs : ce montage est excellent pour une à trois personnes, il n'est pas conçu pour une équipe de vingt.