Agent IA au quotidien : piloter son business web en autonomie

233 compétences. 7 connecteurs MCP. 4 profiles spécialisés. 2 cronjobs actifs, ~10 historiques. C’est ce que mon agent IA gère au quotidien sur mon serveur. Pas un chatbot. Un vrai système opérationnel qui pilote mes projets web pendant que je me concentre sur la stratégie.

J’ai nommé cet agent Hermes. Voici exactement comment il fonctionne, avec les vrais chiffres tirés d’un audit en direct de l’installation, pas d’estimations.

Pourquoi un agent IA pour piloter mes projets

Je gère plusieurs projets web : sites de contenu, pipelines de génération de leads, projets d’affiliation, recherche de niches. Chacun demande de la surveillance technique, des tâches répétitives, de la production de contenu, du reporting.

Avant, c’était moi sur chaque terminal, chaque API, chaque tableur. Aujourd’hui Hermes gère 80% de l’opérationnel. Je garde le contrôle sur la stratégie et les décisions à impact.

Le résultat concret : plus de 2 000 sessions de travail enregistrées, une mémoire qui persiste entre les conversations, et des automatisations qui tournent 24h/24 sans que j’intervienne.

Le serveur : un VPS à 10€ par mois

Hermes tourne sur un VPS standard (OVH, Hetzner, Oracle Cloud free tier, ou n’importe quel provider). Pas de GPU, pas de machine dédiée. Specs réelles à l’instant où j’écris :

Rien d’exotique. N’importe quel VPS dans la fourchette 8-15€/mois fait l’affaire.

L’architecture : un stack polyglotte, pas “juste Python”

Hermes n’est pas un script Python avec des connexions réseau. C’est un ensemble de services qui tournent côte à côte. Le ps réel donne ça :

hermes-gateway              <- orchestrateur principal (Node.js)
hindsight-api               <- serveur de mémoire vectorielle (Python)
redis                       <- couche de cache
nginx                       <- reverse proxy
discord-scrapper            <- extraction de données Discord (Node.js)
firecrawl                   <- service de crawling web

Node.js pour le harness de l’agent, Python pour la mémoire et la recherche, Docker pour isoler les services externes, Nginx comme reverse proxy. Polyglotte, par choix : chaque pièce est l’outil le mieux adapté à son rôle.

Les 7 connecteurs MCP

MCP (Model Context Protocol) est le standard qui permet à l’agent de se connecter à des outils externes. J’en ai 7 configurés :

Chaque connecteur est un serveur indépendant. L’agent peut les interroger en parallèle. Pendant que je discute sur Discord, il peut vérifier un problème dans GlitchTip et mettre à jour une tâche dans Linear, le tout dans le même tour de conversation.

Routage des modèles : optimisé par conception

Faire tourner un modèle frontier 24/7 coûte vite cher. L’astuce c’est d’envoyer le bon modèle sur la bonne tâche.

Modèle principal : mimo-v2.5-pro (Xiaomi). C’est lui qui gère chaque tour de conversation. Contexte de 1M tokens, solide en raisonnement, disponible via API.

Les modèles auxiliaires gèrent les tâches annexes : analyse d’images, résumé de pages web, titres de sessions, compression de contexte, curation de skills. Avant l’optimisation, tout tournait sur le modèle principal, du gaspillage de tokens premium sur des tâches basiques. Maintenant :

Les 12 tâches auxiliaires routées vers DeepSeek : extraction web, compression de contexte, hub de compétences, flux d’approbation, routage MCP, génération de titres, triage, décomposition kanban, description de profil, curator, recherche de sessions, et flush mémoire.

Le smart model routing ajoute une couche : les messages de moins de 160 caractères ou 28 mots sont automatiquement routés vers DeepSeek au lieu de mimo-v2.5-pro. Les questions simples reçoivent des réponses économiques. Les travaux complexes restent sur le modèle premium.

Chaîne de fallback : si le provider principal tombe, Hermes bascule vers Hermes 3 405B (Nous Research) sur le tier gratuit d’OpenRouter. Dernier recours : un petit Granite 3B local qui peut encore répondre et reconfigurer même quand tous les providers API sont en panne.

Résultat : réduction significative des coûts sans perte de qualité sur les conversations qui comptent.

Profiles : agents spécialisés, un seul canal

La meilleure optimisation n’est pas technique, elle est organisationnelle. Au lieu d’un seul agent qui fait tout, j’ai 4 profiles spécialisés qui partagent un unique channel Discord :

Chaque profile a son propre config.yaml, .env, SOUL.md, répertoire de skills, et store mémoire. Le profile coding ne charge que terminal, file, web, browser, delegation, vision, et session search. Pas de surcharge mémoire, pas de connexions MCP inutiles.

Comment ça marche depuis Discord :

• Délégation (synchrone, moins de 5 min) : je demande un truc de code, l’agent default délègue vers un sous-agent avec uniquement le toolset coding. Le résultat revient immédiatement.
• Orchestration kanban (asynchrone, long-running) : les tâches complexes sont décomposées et routées vers le bon worker automatiquement, basé sur la description de chaque profile. Le dispatcher kanban tourne dans le gateway, vérifiant toutes les 60 secondes les tâches prêtes.

Pas de switching manuel. Pas de channels séparés. Une seule conversation, routage intelligent.

Le système de mémoire en 4 couches

C’est la partie la plus sous-estimée d’un agent IA. Sans mémoire, un LLM oublie tout à chaque message. J’ai configuré 4 couches en parallèle, chacune avec un rôle distinct :

La règle d’or : chaque type d’information a sa couche. Les conventions non critiques restent dans MEMORY.md, injecté à chaque tour. Les credentials de production ne quittent jamais AWS Secrets Manager : l’agent y accède au moment où il en a besoin, via IAM scopé à l’instance. Si MEMORY.md fuite par accident dans une trace ou un dump, rien de critique ne sort.

Un skill memory-router décide automatiquement où stocker chaque nouvelle information. Pas de doublons, pas d’incohérences.

La compression est réglée pour le contexte de 1M tokens : seuil à 0,65 (compresse plus tôt), ratio cible 0,3 (préserve 300K tokens). Le TTL du prompt caching est à 15 minutes pour une meilleure efficacité sur les sessions longues.

Outils et credentials : tout sous AWS Secrets Manager

Mon agent a accès à un écosystème complet d’outils. Les chiffres réels :

Total : plus de 80 éléments de credentials gérés via AWS Secrets Manager. Un seul vault, IAM scopé à l’instance, rotation automatique sur les secrets sensibles. C’est ce qui me permet de dormir tranquille quand un disque crashe ou qu’un dépôt fuite.

Les 233 compétences

L’agent n’improvise pas. Il suit des procédures précises stockées dans 233 fichiers de compétence répartis dans 51 catégories :

Chaque skill est un fichier markdown avec des règles précises : ton, structure, interdictions, sources officielles, schémas de sortie. L’agent charge le bon skill en fonction de la demande.

Exemple concret : quand je demande de rédiger un article de blog, l’agent charge le skill blog-writer qui contient les règles anti-IA (pas de tirets longs, vocabulaire banni, variété de longueur de phrases), la méthode de recherche (sources officielles uniquement), et le template de sortie (frontmatter MDX, FAQ collapsible, meta description optimisée).

Cronjobs : actifs pendant que je dors

Deux cronjobs tournent en ce moment, sans intervention :

À côté de ça, Hermes a accumulé une dizaine de cronjobs historiques sur la recherche de niches et l’opérationnel business :

• Boucles d’automatisation SEO sur des sites de niche (bien-être, éducation, affiliation)
• Monitoring quotidien d’indexation et de crawl via l’API Google Search Console
• Cycles SEO complets sur des sites de contenu d’affiliation (recherche de mots-clés, génération de contenu, maillage interne)
• Surveillance de domaines via RDAP (drops, transferts, expirations, utile pour la chasse aux domaines de niche)
• Scan périodique des erreurs applicatives via l’API GlitchTip
• Nettoyage de la mémoire long terme, deux fois par jour (déduplication Hindsight + Atomic)
• Digest des nouvelles versions vers le channel Discord

Chaque cronjob historique a laissé son output dans l’archive cron. Quand une niche change d’angle ou qu’un projet se termine, je désactive le cron mais je garde les artefacts. C’est aussi comme ça que j’évalue ce qui mérite d’être relancé.

Gestion des sessions

Le timeout d’inactivité des sessions : 7 jours. Ça évite la perte de contexte sur les projets qui s’étalent sur plusieurs jours, tout en nettoyant les sessions inactives. Les snapshots de checkpoints préservent l’état des fichiers entre les resets.

Quand une session se reset, le mécanisme de resume injecte les 10 derniers échanges dans le contexte pour que l’agent reprenne là où il en était. Combiné avec les mémoires persistantes (Honcho, Hindsight, Atomic), l’agent maintient la continuité même après un reset.

Les plateformes que j’utilise vraiment

Hermes peut parler sur 8 plateformes (Discord, Matrix, Telegram, WhatsApp, Slack, Mattermost, Signal, SMS). Dans les faits, j’en utilise deux :

Les six autres sont configurées et fonctionnelles, mais elles ne servent à rien dans mon workflow. Le multi-plateforme est utile si l’équipe grossit ou si je veux un canal d’astreinte distinct. Aujourd’hui, Discord suffit.

La décision autonome : la commande /goal

Pendant longtemps, Hermes faisait un tour, rendait sa réponse, et attendait ma relance. Depuis l’arrivée de /goal (notre take sur la Ralph loop, inspirée du /goal de Codex CLI), je peux lui fixer un objectif et il itère tout seul jusqu’à le valider :

/goal Corrige toutes les erreurs ruff dans src/ et vérifie que scripts/run_tests.sh passe

Ce qui se passe sous le capot :

1. Objectif accepté : budget de 20 tours alloué
2. Tour 1 : Hermes attaque comme un message normal
3. Juge : après le tour, un petit modèle auxiliaire (DeepSeek) répond strict JSON {"done": bool, "reason": "..."}
4. Boucle : si c’est pas fini, Hermes enchaîne un nouveau tour automatiquement
5. Terminaison : Goal achieved ou Goal paused - N/20 turns used

Pour les actions à impact (déploiement, suppression, modification de données critiques), /goal ne court-circuite rien : l’agent continue de demander confirmation. La boucle reste fermée, c’est moi qui décide ce qui mérite la confiance, l’agent exécute.

Les chiffres bruts

Récap complet, sans filtre, extrait à l’instant :

Ce que ça change pour l’entrepreneur web

Avant Hermes, je passais 3 à 4 heures par jour sur des tâches opérationnelles : vérification d’erreurs, mise à jour de données, rédaction de contenu, suivi de déploiements, reporting KPI.

Aujourd’hui, ces tâches sont soit automatisées (cronjobs), soit déléguées à l’agent (exécution à la demande, ou via /goal pour les boucles longues). Mon temps se concentre sur la stratégie, l’identification de nouvelles niches, et les décisions de direction.

L’agent ne remplace pas la pensée. Il libère du temps pour penser.

Article mis à jour le 29 mai 2026. Tous les chiffres sont tirés d’un audit en direct de l’installation réelle, pas d’estimations.