Cette page ne présente pas mon avis d’architecte comme une recommandation. Elle raconte un test : utiliser Hermes Agent pour piloter des subagents sur un cas concret — comparer plusieurs frameworks d’agents IA — avec une contrainte très simple : Sonnet était trop cher pour itérer librement, donc le choix initial s’est porté sur DeepSeek. Le test observe ensuite où ce choix économique réussit, où il échoue, et quel modèle devient pertinent.
Je partage cette page comme retour d’expérience personnel sur un test d’outillage agentique. L’objectif initial n’était pas de publier une recommandation officielle sur les frameworks d’agents IA, mais de tester Hermes Agent, DeepSeek, les subagents, la délégation de tâches et la robustesse d’un workflow multi-agents.
L’analyse comparative, le classement, les corrections et les formulations techniques ci-dessous ne sont pas mon avis personnel. Ce sont des productions de LLMs, générées dans un cadre expérimental, puis annotées et mises en forme. Elles peuvent contenir des erreurs, des approximations, des oublis, des biais de sources ou des informations devenues obsolètes.
Cette page ne constitue donc ni une recommandation d’architecture, ni un avis sécurité, juridique, conformité, achats ou RSSI. Toute décision en contexte bancaire ou réglementé doit être reprise depuis les sources officielles, validée par les équipes compétentes et replacée dans le contexte réel de l’organisation concernée.
Cette page doit être lue comme un journal d’expérimentation : le sujet des frameworks d’agents IA sert de terrain d’essai pour comparer le comportement de modèles et de sous-agents, pas comme une étude définitive du marché.
Important Le contenu analytique ci-dessous est donc à lire comme une sortie de LLM documentée, pas comme une position personnelle ou professionnelle de ma part.
Document généré par Hermes Agent dans le cadre d’un test de subagents, puis relu par un second LLM. Les corrections proposées par le second LLM sont intégrées directement dans les cellules et paragraphes avec un marquage vert.
Vert — Correction factuelle Sonnet (intégrée inline)
Violet — Débat (lecture alternative, opinion de Sonnet — non factuel)
Ambre — Verdict original Haiku et post-mortem du processus
| Framework | Licence | Self-Hosted | Multi-LLM | MCP Natif | Durable Exec. | Tracing | UE Régions | Use Bancaire |
|---|---|---|---|---|---|---|---|---|
| LangGraph | MIT | Managed Oui | Non Oui | Adaptateur | Oui | LangSmith | Non doc. | Non doc. J.P. Morgan |
| Strands | Apache 2.0 | Oui | Oui | Natif | Oui | OpenTel. | Possible | Non spécif. Swisscom |
| OpenAI | Non doc. MIT | Local | Oui | Natif | Non doc. | Natif | Non doc. | Non doc. |
| Claude | MIT MIT (SDK) + ToS Anthropic (modèle) | Partial | Partial Non (lock-in modèle) | Natif | Oui | Hooks | EU Bedrock | Production Production (legal/dev, pas banque) |
pip install langgraph tourne en self-hosted total. LangSmith managé est optionnel pour l'observabilité.langchain-* integrations (OpenAI, Anthropic, Google, Bedrock, Ollama, vLLM, Mistral, etc.).openai/openai-agents-python est sous MIT, visible dans le LICENSE du repo. Haiku n'avait simplement pas extrait ce fichier.Classement 1-4 produit par le LLM à partir des sources fournies. Il est conservé pour transparence, mais ne constitue pas mon avis personnel ni une recommandation d’architecture.
La section ci-dessus est une proposition générée par le LLM dans le cadre du test. Elle ne doit pas être interprétée comme une validation de ma part. En contexte bancaire réel, les critères déterminants seraient à redéfinir avec l’architecture, la sécurité, la conformité, les achats, le juridique et les contraintes d’hébergement de l’organisation.
Cette section n'est pas une correction factuelle, c'est une lecture alternative proposée par Sonnet. Le terme "souveraineté" admet plusieurs définitions dans le contexte SI bancaire français, et le classement Haiku ci-dessus est défendable pour une de ces définitions. À toi de juger laquelle correspond à ton contexte projet.
Définition A — Résidence des données UE (la plus large)
Critère : les données ne quittent pas le territoire de l'UE.
Bedrock EU coche cette case. RGPD respecté.
Sous cette définition, le classement Haiku tient : Claude SDK + Bedrock EU est un excellent choix.
Définition B — Indépendance du Cloud Act (intermédiaire)
Critère : pas soumis à une juridiction extra-européenne (Cloud Act US, Patriot Act).
Bedrock reste un service AWS, donc société américaine, donc soumis au Cloud Act indépendamment de la région.
Sous cette définition, le classement bascule : Strands sur infra OVHcloud/Scaleway/3DS Outscale (qualifiés SecNumCloud) devient préférable.
LangGraph self-hosted aussi.
Définition C — Air-gap / qualification ANSSI SecNumCloud (la plus stricte)
Critère : déploiement sur infrastructure qualifiée SecNumCloud, modèle hébergé en interne ou chez un opérateur souverain qualifié, audit possible du modèle, zéro appel sortant.
Aucun des 4 frameworks ne coche entièrement, mais Strands + Mistral/Llama via vLLM/Ollama on-prem (ou chez OVHcloud SecNumCloud) est le seul setup viable.
Le Claude SDK est exclu (modèle non hébergeable en air-gap).
Ça dépend du type de traitement dans la banque :
— Outils internes non-sensibles (productivité dev, génération de doc technique, helpdesk RH non-PII) : Définition A suffit généralement. Le classement Haiku est valable.
— Traitements client / KYC / scoring : Définition B ou C selon les exigences DSI/RSSI. Cloud Act devient un sujet, et le ranking change.
— Traitements régaliens / LCB-FT / transactions : Définition C quasi-imposée. Sous cette grille, Strands self-hosted est le seul choix défendable.
Le rapport Haiku s'est implicitement positionné sur la Définition A. Si ton projet réel est sur les zones B ou C, le classement à utiliser est : 1. Strands self-hosted — 2. LangGraph self-hosted — 3. Claude SDK via Bedrock EU — 4. OpenAI.
Open-source MIT. Développé par LangChain Inc. GitHub: langchain-ai/langgraph, 31k+ stars, 5.3k forks. Gouvernance communauté (274 issues, 247 PRs actifs). Adopters: Klarna, Replit, Elastic, J.P. Morgan.
Low-level framework inspiré Pregel/Beam/NetworkX. États persistants, graphes exécution explicites. Exécution durable avec reprise pannes. Mémoire hybride (court/long terme). Support MCP via langchain-mcp-adapters (stdio, HTTP, SSE).
MCP (Anthropic) via adaptateurs. Conversion outils MCP → LangChain natifs. Schémas structurés. Non documenté : Normes bancaires (ISO 20022/SWIFT).
LangSmith: capture états, visualisation chemins, métriques runtime. Human-in-the-loop inspection d'état. Non documenté : Chiffrement E2E, auditing ANSSI/CNIL, gestion secrets production.
Non documenté : Coûts managed, SLA, localité données, conformité bancaire FR/UE.
Précision Sonnet : LangGraph supporte tous les providers via langchain-* packages (OpenAI, Anthropic, Google, Bedrock, Vertex, Cohere, Mistral, Ollama, vLLM, Together, Groq, etc.).
Déploiement totalement self-hosted possible (Docker, Kubernetes). LangSmith optionnel — observabilité remplaçable par OpenTelemetry standard.
Avec Strands, l'un des deux frameworks où le déploiement air-gappé strict est viable.
Production-ready avec durable execution. Outils évaluation agents. Ressources: docs complète, LangChain Academy, guides. Non documenté : Certifications SOC2/ISO27001, tests charge bancaire, MTTR/RPO, hotfix SLA.
Apache 2.0 open-source. Créé AWS (mai 2025), version 1.0 (2026). GitHub: strands-agents/sdk-python, 6.4k stars. 22% contributions communauté. 150K+ PyPI downloads 14M+ téléchargements PyPI (blog AWS février 2026). Écosystème 12+ repos (sessions Redis/Valkey, tools tiers).
Adopters internes AWS à ajouter : Amazon Q Developer, AWS Glue, VPC Reachability Analyzer (usage interne validé avant open-sourcing). Adopters externes cités dans le blog AWS d'annonce 1.0 : Swisscom, Smartsheet, Landchecker, Elva.
Model-driven minimaliste. Boucle: perception → raisonnement → action. Primitives multi-agents: Agents-as-Tools (hiérarchie), Handoffs (humains), Swarms (équipes), Graphs (workflows). Streaming bidirectionnel expérimental (audio, interruption utilisateur).
MCP natif (première classe). A2A protocol. Tools via décorateurs Python/TS, hot-reload auto. Multi-provider: Bedrock, OpenAI, Anthropic, Gemini, Ollama, LiteLLM, llama.cpp.
Hooks BeforeToolCallEvent (validation pré-exec), AfterToolCallEvent (audit post-exec). SteeringHandler (interception intelligente). OpenTelemetry natif. trace_attributes (tagging service/env). Benchmark: 100% accuracy vs 82.5% baseline. Chiffre à retirer ou contextualiser — extrait d'un sample sans cadre d'évaluation précisé.
Zero lock-in: multi-provider abstraction (swap sans code). MCP native limit dépendance. Déploiement: AWS Lambda/Fargate/EKS, Kubernetes, Docker, Terraform. Portabilité cross-platform (Python+TypeScript).
v1.0 "production-ready" 2026. Samples multiples (search/logs/lead-routing/support). Evals framework proven (117 stars). Infrastructure terraform/K8s production-tested. Non documenté : SLA uptime, support commercial, certifications SOC2/ISO.
Évolution Swarm (plateforme expérimentale). Open-source (v0.14.0+). Python + TypeScript/JavaScript. Non documenté : Licence exacte. Licence : MIT (fichier LICENSE racine du repo).
Primitives minimales: Agents (LLM + instructions + outils + handoffs), Agents Sandbox (long-term env), délégation A2A. Léger, sans abstraction excessive. Realtime Agents (gpt-realtime-2, voix native).
Responses API (Chat Completions + tool-use unifiée). MCP natif. Outils: WebSearch, FileSearch, ComputerUse. WebSocket transport. Provider-agnostic déclaré: any-llm, LiteLLM 100+ LLMs.
Guardrails configurables (entrée/sortie). Human-in-the-Loop intégré. Tracing natif (visualisation/débogage/évaluation). Garantie: modèles ne trainés pas sur données métier par défaut. Non documenté : Chiffrement transit, compliance RGPD, audit logging.
Provider-agnostic déclaré vs dépendance tacite Responses API + WebSearch + outils hébergés OpenAI. SandboxAgents déploiement local Unix. Installation pip standard. Non documenté : Cloud deployment (AWS/Azure/GCP), autoscaling, K8s, coûts.
Maturité production avancée: open-source confirmé, docs complète, exemples diversifiés, outils dev robustes. Python 3.10+ + TypeScript parallèle. Non documenté : SLA, versioning roadmap, tests charge scale réelle, exemples bancaires France.
Licence : MIT (Copyright 2025 Anthropic, PBC). Licence : MIT sur le code Python/TS du SDK, MAIS l'usage du modèle Claude est régi par les Anthropic Commercial Terms of Service. Pas de pleine liberté MIT, c'est une licence MIT sur la coquille, propriétaire sur le moteur. Open-source. Sortie sept 2025 avec Claude Sonnet 4.5. v0.1.80 mai 2026. GitHub: anthropics/claude-agent-sdk-python, 6.8k stars, 972 forks, 64 contributeurs. Python + TypeScript. Adopters: Cursor, GitHub Copilot (Microsoft), CoCounsel, Hai, Cognition/Devin, Replit.
Deux APIs core: query() (async simple), ClaudeSDKClient (bidirect conversations).
Asyncio complet. Hooks lifecycle (PreToolUse/PostToolUse/Stop/SessionStart/SessionEnd) interceptent chaque étape.
Subagents avec tracage contexte (parent_tool_use_id). Memory tool natif pour tâches 30+ heures.
Sessions backends: S3, Redis, PostgreSQL.
MCP v1.0 natif. Modes: (1) In-process SDK (décorateurs Python @tool, latence minimal), (2) External subprocess (stdio, legacy). 10+ tools built-in: Read, Write, Edit, Bash, Monitor, Glob, Grep, WebSearch, WebFetch, AskUserQuestion. Système permissions granulaire (allowlist, permission_mode, can_use_tool callback).
Claude Sonnet 4.5 "frontier aligné": réductions 10x sycophancy/déception/power-seeking. Safety Level 3 (ASL-3): classifieurs CBRN automatisés (10x moins faux+, 2x vs Opus 4). Hooks pré/post-execution (audit complet, rejets déterministes). Logging auto modifications fichier. Zéro données utilisateur stockées Anthropic (session locale/backend client). Zéro training données utilisateur.
À distinguer : les features de safety (ASL-3, sycophancy reduction, etc.) sont du modèle Claude, pas du SDK. Le SDK fait l'orchestration et les hooks. La modération vient du modèle backend.
Light lock-in strategic: dépendance modèle Anthropic (pas LLM abstraction layer).
Lock-in modèle COMPLET : le SDK est conçu pour Claude uniquement. Bedrock/Vertex/Foundry sont des backends d'infra (où Claude tourne), pas des alternatives au modèle.
Tiers-providers supportés: Amazon Bedrock, Google Vertex AI, Microsoft Azure Foundry (CLAUDE_CODE_USE_BEDROCK=1 etc).
Déploiement: single Python process (pas microservices). Session backends pluggables.
MIT license → transférable. Cost: Sonnet 4.5 pricing = Sonnet 4 ($3/$15M tokens).
v0.1.80 mai 2026 (7-8 mois production réelle). Adoption confirmed: Cursor, GitHub Copilot, CoCounsel (litigation 44% vulns reduction), Hai, Devin, Replit (9%→0% error rate). GitHub: 6.8k stars, 972 forks, 64 contributors, 122 issues actifs. Benchmarks: SWE-bench Verified 77.2%, OSWorld 61.4%. Pas deprecation. Caveat : v0.x (semver immature), pas backward-compatibility guarantie majeure. Roadmap public absent.
v0.1.80 = semver pré-1.0. Signal d'instabilité d'API important pour contexte banking où les contrats de version comptent. À comparer : Strands en 1.0, LangGraph en stable.
4 subagents autonomes ont tourné en parallèle (configuration Hermes: max_concurrent_children=4).
Chaque subagent a extrait ses 3 URLs imposées via web_extract, sans recherche exploratoire ni fabrication.
Rapport parent compilé après convergence des 4 fiches. Durée totale: ~95 secondes (mai 2026).
Modèle subagents: Claude Haiku 4.5. Aucun web_search utilisé. Toutes limites documentées comme « non documenté dans les sources ».
Ce rapport est l'aboutissement de plusieurs heures de tests itératifs sur Hermes Agent tournant sur un VPS personnel. La version finale a été générée rapidement et à faible coût, mais elle est surtout le fruit de plusieurs tentatives préalables, dont certaines infructueuses.
Le setup Hermes initial utilisait deepseek/deepseek-v4-pro via OpenRouter, pour des raisons de coût
(tarifs observés lors du test : 0,435 $/1M input, 0,87 $/1M output, soit 5,7× moins cher que Haiku en output).
Excellent pour le chat interactif en français dense, mais inadapté pour orchestrer des subagents complexes.
execute_code. Coût : ~0,025 $ perdus.
write_file inexistant. Subagent LangGraph a fait 13 web_extract au lieu des 3 demandés (bornes en prompt non enforced par Hermes).
aws.amazon.com/strands retournait 404.
Il a remplacé la fiche Strands par une fiche AWS Bedrock Agents + AgentCore, deux produits différents.
Hermes n'avait pas tenté github.com/strands-agents ni strandsagents.com qui étaient pourtant explicitement listés dans le prompt.
~/.hermes/config.yaml via sed :
model.default et delegation.model passés à anthropic/claude-haiku-4.5,
max_concurrent_children bumpé de 3 à 4.
| Métrique | DeepSeek V4 Pro | Claude Haiku 4.5 |
|---|---|---|
| Vitesse d'inférence (tokens/s) | ~30-40 | 112 (observé) |
| Durée 4 subagents en parallèle | Timeout 600s (échec) | 95s (succès) |
| Adhérence aux bornes du prompt | Faible (13 web_extract au lieu de 3) | Bonne |
| Hallucinations sur Strands | Oui ("n'existe pas") | Non |
| Tarif input OpenRouter | 0,435 $/1M | 1,00 $/1M (2,3× plus cher) |
| Tarif output OpenRouter | 0,87 $/1M | 5,00 $/1M (5,7× plus cher) |
| Provider routé par OpenRouter | Divers (DeepSeek, Lambda, etc.) | Amazon Bedrock (souveraineté de fait UE possible) |
Les montants ci-dessous correspondent uniquement aux runs identifiés dans ce post-mortem, c’est-à-dire aux tentatives directement liées à cette comparaison. Ils servent à comparer le comportement relatif des modèles, pas à chiffrer toute la journée d’expérimentation.
Important sur le coût réel. Ce chiffre ne représente pas le coût complet de la journée. Il ne prend pas en compte tous les essais-erreurs autour du setup, les relances, les prompts ratés, les itérations de génération HTML, les corrections, les tests de configuration, ni les échanges exploratoires autour d’Hermes. En pratique, la journée m’a coûté nettement plus cher que ce sous-total : le montant affiché ici isole seulement la partie exploitable pour comparer DeepSeek et Haiku sur ce cas précis. C’est précisément cette problématique de coût qui explique le choix initial de DeepSeek plutôt que Sonnet pour les premières itérations.
La conclusion contre-intuitive reste valable sur ce scénario : payer 2-6× plus cher pour Haiku a permis de réussir là où DeepSeek perdait du coût en timeouts. Le coût brut du modèle est secondaire devant la vitesse d'inférence, l'adhérence aux consignes et la robustesse de l'orchestration.
Temps total de la session : environ 6 heures, dont 5h30 de tentatives DeepSeek frustrantes et 30 minutes une fois Haiku en place (édition config.yaml, restart gateway, run, fact-checking).
L'enseignement pratique n'est pas une valeur de configuration précise, mais une stratégie : envisager un setup mixte, avec un modèle économique et confortable pour le chat interactif, et un modèle plus discipliné / rapide réservé aux subagents et aux tâches déléguées.
C'est le point important de l'expérience : pour les workflows agentiques, le meilleur modèle n'est pas forcément celui qui donne la meilleure réponse conversationnelle. C'est celui qui respecte le mieux les bornes, utilise correctement les outils et termine la tâche dans le temps imparti.