Des pipelines rigides aux bots agentiques : pourquoi j'ai remplacé n8n par Hermes
Pendant des années, mon automatisation tournait sur n8n : des workflows déterministes, pensés pour scaler. Chaque évolution demandait quand même une refonte d'architecture. Quand le coût des tokens a chuté, les agents sont devenus le meilleur compromis. Voici pourquoi j'ai bougé, et comment tourne l'hybride.
Le problème
Pendant des années, mon automatisation personnelle tournait sur n8n. Des workflows déterministes : veille, prospection, emails, publication. Des nodes propres, des templates, une architecture pensée pour scaler.
Le design était juste. Le problème n'a jamais été l'échelle. C'était la flexibilité.
Le mur : une refonte à chaque évolution
Chaque changement, une nouvelle source, un nouveau format, une nouvelle règle, imposait une refonte d'architecture. Parfois petite, parfois lourde. Même quand la structure était pensée pour scaler, le jour où la boucle changeait, c'était moi qui rebranchais les morceaux à la main.
Prenez la veille. Ajouter une source : recâbler le node. Changer le format de sortie : recâbler le node. Les flux de données étaient corrects, mais chaque évolution avait un coût en architecture, pas en logique. Le workflow faisait exactement ce que je lui avais dit. C'est le fait de lui dire qui ne scalait pas.
Un workflow, c'est un circuit imprimé : fiable, et rigide. Le chemin est tracé une fois, pour toujours. Un agent, c'est autre chose : il porte le contexte, il s'adapte, il décide dans le cadre que vous lui donnez. La boucle peut plier sans être redessinée.
L'économie a changé
Le second facteur était économique. Longtemps, les agents autonomes ont été un luxe : tokens chers, coûts imprévisibles. L'équation a changé quand le coût des tokens est descendu au point où la question n'était plus « est-ce que je peux me payer un agent ? » mais « où doit vivre l'intelligence, en local ou dans le cloud ? »
C'est à cette question que répond cet article.
Le remplacement : un hybride, pas une migration
J'ai remplacé une partie de mes boucles n8n par Hermes. Pas une migration d'un outil vers un autre : une architecture à deux étages.
La règle en une phrase : le local pour la charge lourde, le cloud pour l'intelligence agentique, la validation humaine à la frontière.
Étage local · Linux + Ollama (Qwen)
Charge lourde : veille, crawl, tâches de dev. Coût marginal = électricité.
Étage cloud · VPS + DeepSeek
Couche agentique : comprendre, décider, enchaîner, garder le contexte.
Validation humaine à la frontière
Brouillons, candidats de prospection et digests de veille sont relus avant toute sortie.
Sortie · email envoyé, contact pris, article publié
Local · Ollama + Qwen
L'étage local tourne sur mes propres machines (Linux). Ollama avec des modèles Qwen prend en charge la veille et le développement. C'est là que vont les tâches intenses, lourdes, celles qui brûleraient des tokens pour rien dans le cloud.
J'ai le matériel. Le coût marginal d'un run local lourd, c'est de l'électricité, pas des tokens.
Cloud · DeepSeek pour les agents
Les agents tournent sur un VPS, propulsés par DeepSeek. Pas pour les tâches lourdes : pour la couche agentique, comprendre, décider, enchaîner les étapes. Le cloud là où l'agent a besoin de réactivité et de capacité ; le local là où la charge est constante et intense.
Ce découpage n'est pas une question de performance. C'est une question de maîtrise des coûts. DeepSeek me donne une intelligence de niveau agent à un prix qui rend l'architecture soutenable, et l'étage local garde le travail gourmand en tokens hors compteur.
La règle qui fait tenir l'ensemble : autonomie avec validation humaine
Les agents sont autonomes. Ils ne sont pas sans supervision.
- Les emails sont produits en brouillon, relus avant envoi.
- Les candidats de prospection sont collectés et validés avant tout contact.
- Les résultats de veille arrivent dans un chat, ils ne sont pas publiés automatiquement.
L'agent propose. Je dispose. Autonomie dans le cadre, humain à la frontière. C'est cette ligne qui rend le système suffisamment fiable pour tourner sans surveillance : l'agent fait le travail, la décision reste la mienne.
Ce qui a changé en pratique
Un changement est devenu une instruction, plus un refactor. Quand une boucle doit évoluer, je le dis à l'agent. L'architecture reste.
Le contexte survit. L'agent sait ce qu'il a fait hier. La boucle ne repart plus de zéro à chaque run.
Les échecs se discutent. Quand une sortie est fausse, on en parle, c'est corrigé, la boucle continue. Plus d'erreur silencieuse enfouie dans un node.
Le système est devenu un produit. C'est la leçon design ops : un système que l'on fait évoluer est un produit. Un système que l'on recâble est une dette. La même logique vaut pour les design systems, pour l'automatisation, pour tout ce qui doit survivre à sa première version. L'architecture est ennuyeuse volontairement. Elle n'a pas besoin d'être élégante. Elle a besoin de plier.
Le pipeline derrière ce blog : de la veille à l'article publié
Ce blog ne s'écrit pas dans le vide. C'est le résultat d'un pipeline, le même type de système que je conçois pour mes clients, appliqué à mon propre contenu. Voici comment une idée voyage de la veille à l'article publié.
Veille
Je collecte des signaux dans des sources que je juge fiables : newsletters design, lancements produits, papiers de recherche, rapports d'industrie, conversations. L'agent ne lit pas tout. Il scanne, filtre et signale ce qui correspond à mes sujets du moment.
Vault
Les éléments signalés atterrissent dans un vault : un dépôt structuré de signaux bruts avec tags, sources et un score de confiance. Tout n'est pas bon. Tout n'est pas utile. Le vault me permet de parcourir avant de m'engager.
Idées
Je revois le vault régulièrement et transforme les signaux en idées. Certains deviennent des articles. Certains deviennent des références. Certains meurent. L'agent m'aide à regrouper les thèmes et à faire remonter des patterns que j'aurais pu manquer.
Draft
Quand une idée vaut le coup, j'écris le premier draft, souvent à la main, parfois avec l'agent comme partenaire d'entraînement. Le draft est volontairement brouillon. C'est là que se fait la pensée.
Validation
L'agent relit le draft : structure, clarté, cohérence, arguments faibles. Il propose aussi des améliorations. Je décide ce que je garde. C'est la couche de validation humaine à la frontière.
Publication
Une fois validé, le draft est mis en forme, les métadonnées sont ajoutées, et l'article est publié. L'agent gère les parties répétitives : front matter, tags, checks SEO, optimisation des images.
Documentation
Après publication, le pipeline documente ce qui s'est passé : ce qui a fonctionné, ce qui n'a pas fonctionné, quelles sources ont mené à l'idée. Cela ferme la boucle et améliore le cycle suivant.
Pourquoi ça compte
Ce pipeline ne sert pas seulement à écrire plus vite. Il sert à garder la boucle intacte : du signal à la décision, de la sortie à l'apprentissage. La même architecture s'applique à la product discovery, aux design systems, aux projets clients. C'est le principe Hermes appliqué au contenu.
Où j'en suis
La migration n'est pas terminée. D'autres parties de l'écosystème rejoindront Hermes avec le temps, c'est la direction, pas l'annonce d'un état final.
Le principe tient : le local pour la charge, le cloud pour l'intelligence agentique, la validation humaine à la frontière.