Un workflow Hermes Agent efficace garde le contexte chez vous et n’envoie au LLM que le strict nécessaire. Le vrai sujet, c’est moins le prompt magique que l’architecture autour. Stockage local, skill library, extracteur minimal, c’est là que les coûts tokens baissent vraiment.
Besoin d'aide ? Découvrez les solutions de notre agence d'agents IA.
Pourquoi les workflows IA coûtent vite cher ?
Les workflows IA coûtent cher parce qu’on renvoie trop souvent le même contexte au modèle, tâche après tâche.
Je le vois souvent chez des clients qui testent des agents IA. Au début, tout marche bien. On demande à l’agent de consulter Salesforce, d’interroger un entrepôt de données, de produire une synthèse, de rédiger un rapport, puis de préparer une réponse commerciale. C’est séduisant, parce que ça donne l’impression d’un assistant autonome qui avance tout seul.
Le problème, c’est que chaque appel au LLM consomme des tokens. Un token, c’est un petit morceau de texte lu ou généré par le modèle. Il y a les tokens en entrée, c’est-à-dire tout ce qu’on lui envoie. Et les tokens en sortie, c’est-à-dire ce qu’il répond. Le vrai gaspillage vient rarement de la réponse elle-même. Il vient surtout du contexte qu’on répète encore et encore.
Quand on branche le CRM, la CDP, les documents internes et les règles métier, les coûts montent vite. La CDP, pour faire simple, c’est la base qui centralise les données client. Et là, beaucoup d’équipes tombent dans une approche trop prompt-centric. On demande au modèle de tout comprendre à chaque fois, comme s’il repartait de zéro. C’est pratique pour prototyper, mais mauvais pour passer à l’échelle.
| Approche classique | Approche Hermes Agent-style |
| On envoie beaucoup de contexte au LLM | On envoie uniquement les extraits nécessaires |
| Le modèle reconstitue tout à chaque appel | Le contexte est préparé avant l’appel |
| Coûts tokens élevés | Coûts tokens mieux maîtrisés |
| Données sources plus exposées | Données gardées sur l’infrastructure propriétaire |
Pour moi, un workflow Hermes Agent-style ne commence pas par le prompt. Il commence par le contexte stocké, nettoyé, réutilisable et contrôlé. Le prompt arrive à la fin, quand on sait déjà quelles données sont utiles.
C’est proche du RAG, pour Retrieval Augmented Generation. En clair, on récupère les bons fragments dans ses sources, on les assemble proprement, puis seulement là on appelle le modèle. Moins de bruit. Moins de tokens. Moins de données sensibles envoyées n’importe où. Et surtout, un agent beaucoup plus stable.
Quels sont les trois composants clés ?
Les trois composants clés sont le magasin de contexte local, la bibliothèque de compétences et l’extracteur de prompt minimal. Ces trois briques servent le même objectif : garder les données sur votre infrastructure, sous votre contrôle, et réduire au strict nécessaire ce qui part vers le LLM, le grand modèle de langage.
Le magasin de contexte local, c’est la base commune. Ça peut être une base partagée, un entrepôt cloud, ou un stockage contrôlé où arrivent les données utiles issues du CRM, de la CDP, c’est-à-dire la plateforme de données client, du data warehouse ou d’autres outils métier. Le point important, c’est que le LLM ne lit pas directement Salesforce, votre CDP ou votre entrepôt de données. Il reçoit seulement des extraits sélectionnés depuis ce magasin. Ça change beaucoup de choses côté sécurité, gouvernance et coûts, parce qu’on évite d’envoyer des données sensibles ou inutiles à chaque demande.
La bibliothèque de compétences vient se poser à côté. C’est un répertoire local avec vos règles, guides de ton, documents de marque, consignes éditoriales, standards business, exemples validés et références internes. L’agent ne balance pas tout ça dans le prompt. Il cherche par mots-clés ou par similarité vectorielle, donc par proximité de sens, pour récupérer uniquement les passages utiles. Si je demande un rapport pour une cible B2B, inutile d’envoyer tout le brand book. Il suffit de récupérer les règles liées au ton, au format du rapport et aux interdits de langage.
L’extracteur de prompt minimal fait le tri entre ces sources. C’est la logique qui choisit les bons fragments avec du scoring par mots-clés, une similarité vectorielle ou une requête en base. Il assemble ensuite un paquet court : objectif de la tâche, extraits de contexte, règles utiles, contraintes de sortie. Cette étape ne nécessite pas d’appel au LLM, donc elle coûte peu. Chez un client, c’est souvent là qu’on gagne le plus vite : moins de tokens, moins de bruit, moins de réponses bancales.
Si des données manquent, l’extracteur peut déclencher un appel MCP, pour Model Context Protocol, ou une API vers le CRM, la CDP ou l’entrepôt. Il stocke ensuite la réponse dans le magasin de contexte, pour éviter de refaire le même appel inutilement.
| Composant | Rôle | Exemple de contenu | Impact sur les tokens |
| Magasin de contexte local | Centraliser les données utiles sous contrôle | Données CRM, segments CDP, ventes, tickets support | Réduit l’envoi de données brutes au LLM |
| Bibliothèque de compétences | Stocker les règles et références internes | Ton de marque, consignes, exemples validés | Évite d’envoyer toute la documentation |
| Extracteur de prompt minimal | Sélectionner et assembler les bons fragments | Objectif, contexte, règles, contraintes | Garde un prompt court, ciblé et moins coûteux |
Comment circule la donnée dans le workflow ?
La donnée circule d’abord vers le magasin de contexte, puis l’extracteur prépare le minimum utile avant l’appel au LLM. Les données fraîches viennent des systèmes métier : CRM, CDP, entrepôt de données, outil support, facturation, produit, parfois même fichiers internes. Elles atterrissent dans un magasin de contexte contrôlé par l’entreprise, pas directement dans le modèle.
Quand une tâche arrive, l’agent ne balance pas tout au LLM. C’est une erreur que je vois souvent chez des clients au début, et ça coûte cher pour rien. L’extracteur interroge le magasin de contexte, récupère les morceaux vraiment utiles, puis complète avec les règles de la bibliothèque de compétences. Une compétence, ici, c’est une règle réutilisable : ton à respecter, format attendu, contrainte métier, politique de réponse, logique de priorisation.
Le LLM reçoit donc un paquet compact. Une demande ciblée. Pas une masse de données brutes. Sa réponse est ensuite stockée dans le magasin de contexte, avec les métadonnées utiles, pour pouvoir être réutilisée plus tard sans tout recalculer.
Le vrai gain économique est là. Tout ce qui se passe avant l’appel au LLM évite des coûts en tokens. Une requête SQL, une recherche vectorielle ou un scoring local coûte généralement beaucoup moins cher qu’un gros prompt envoyé à un modèle. À ce stade, le design d’architecture devient plus important que l’optimisation cosmétique des prompts.
Exemple de logique Python commentée
context_store = {}
def ingest_context(source_name, records):
# Stocke les données métier dans un magasin de contexte fictif
context_store[source_name] = records
def retrieve_context(task):
# Récupère uniquement les extraits pertinents pour la tâche
customer_id = task["customer_id"]
crm_records = context_store.get("crm", [])
return [r for r in crm_records if r["customer_id"] == customer_id]
def retrieve_skills(task_type):
# Récupère les règles utiles depuis une bibliothèque de compétences
skills = {
"email_support": [
"Répondre avec un ton clair et professionnel",
"Ne pas promettre de geste commercial sans validation",
"Résumer le problème en une phrase"
]
}
return skills.get(task_type, [])
def build_minimal_prompt(task, context, skills):
# Assemble un prompt court avec seulement le nécessaire
return {
"instruction": task["instruction"],
"context": context,
"rules": skills
}
def call_llm(prompt):
# Appel fictif au LLM, sans dépendre d'un fournisseur précis
return "Réponse générée à partir du contexte minimal."
def store_response(task_id, response):
# Stocke la réponse pour réutilisation ou audit
context_store.setdefault("responses", {})[task_id] = response
crm_data = [
{"customer_id": "C123", "name": "Nadia", "plan": "Premium", "last_ticket": "Problème de facturation"}
]
ingest_context("crm", crm_data)
task = {
"id": "T001",
"task_type": "email_support",
"customer_id": "C123",
"instruction": "Préparer une réponse au client"
}
context = retrieve_context(task)
skills = retrieve_skills(task["task_type"])
prompt = build_minimal_prompt(task, context, skills)
response = call_llm(prompt)
store_response(task["id"], response)Comment construire un extracteur minimal fiable ?
Un extracteur minimal fiable sélectionne les bons fragments sans demander au LLM de faire le tri à sa place. C’est la brique la plus sensible du workflow Hermes Agent. Si l’extracteur récupère trop de contenu, on perd l’intérêt économique. Si l’extracteur récupère trop peu, le modèle manque de contexte et produit une réponse fragile.
Je garde trois méthodes simples, parce qu’elles couvrent déjà beaucoup de cas terrain.
- Le scoring par mots-clés marche très bien pour des cas lisibles et rapides. Par exemple retrouver les comptes Salesforce qui contiennent un nom d’entreprise, un segment ou une région.
- La similarité vectorielle sert à retrouver des documents proches d’une intention ou d’une question. Un vecteur, c’est juste une représentation numérique du sens d’un texte. Deux textes proches auront des vecteurs proches.
- La requête base de données est idéale quand on connaît précisément les champs nécessaires : chiffre d’affaires, statut client, dernière date de contact, pipeline, segment.
L’extracteur ne doit pas juste coller des bouts de texte les uns derrière les autres. Il doit produire un paquet structuré. Je sépare toujours l’objectif, le contexte métier, les contraintes, les règles de style et le format attendu. Ça évite au modèle de deviner ce qui est important.
# Exemple pédagogique : récupération hybride minimale
top_k = 5
question = "Prépare une synthèse du compte Acme en région Europe"
documents = [
{"id": 1, "text": "Acme est un compte stratégique Europe avec pipeline élevé."},
{"id": 2, "text": "BetaCorp est en phase de renouvellement aux États-Unis."},
{"id": 3, "text": "Acme a eu un dernier contact commercial le 12 janvier."}
]
base_clients = {
"Acme": {
"ca": "2,4M€",
"statut": "Client actif",
"dernier_contact": "12 janvier",
"pipeline": "850k€",
"segment": "Enterprise"
}
}
def score_mots_cles(doc, mots_cles):
# Compte simplement les mots-clés présents dans le texte
texte = doc["text"].lower()
return sum(1 for mot in mots_cles if mot.lower() in texte)
def similarite_simulee(doc, question):
# Simulation volontairement simple pour garder l’exemple lisible
mots_question = set(question.lower().split())
mots_doc = set(doc["text"].lower().split())
return len(mots_question.intersection(mots_doc)) / max(len(mots_question), 1)
mots_cles = ["Acme", "Europe", "pipeline"]
resultats = []
for doc in documents:
score = score_mots_cles(doc, mots_cles) + similarite_simulee(doc, question)
resultats.append((score, doc))
extraits = [
doc["text"]
for score, doc in sorted(resultats, reverse=True, key=lambda x: x[0])[:top_k]
]
infos_client = base_clients.get("Acme", {})
prompt_final = f"""
Objectif:
Répondre à la demande suivante: {question}
Contexte métier:
{chr(10).join(extraits)}
Données structurées:
CA: {infos_client.get("ca")}
Statut: {infos_client.get("statut")}
Dernier contact: {infos_client.get("dernier_contact")}
Pipeline: {infos_client.get("pipeline")}
Segment: {infos_client.get("segment")}
Contraintes:
Ne pas inventer d’information absente du contexte.
Style:
Réponse courte, claire, orientée business.
Format attendu:
Synthèse en 5 lignes maximum.
"""
print(prompt_final)Dans mes projets, le plus gros gain vient souvent de la discipline sur ce qui n’est pas envoyé au modèle. C’est moins sexy qu’un prompt parfait, mais c’est beaucoup plus durable.
Quel changement de mentalité adopter ?
Il faut arrêter de penser prompt d’abord et commencer à penser contexte réutilisable. C’est vraiment le basculement à faire avec un workflow Hermes Agent efficace.
Dans une approche prompt-centric, on pose une question au modèle, il répond, puis on recommence presque à zéro. On recopie du contexte, on reformule les règles, on ajoute trois contraintes oubliées, on colle un extrait de document, et on espère que le LLM va trier tout ça correctement. Ça marche pour un besoin ponctuel. Mais dès que le sujet revient souvent, ça devient fragile et coûteux.
Dans une approche context-centric, le prompt arrive beaucoup plus tard. Avant lui, on a déjà ingéré les sources, sélectionné le bon contexte, appliqué les règles de la skill library, c’est-à-dire la bibliothèque de règles, méthodes et consignes réutilisables. Le LLM n’est plus là pour aspirer toutes les données et deviner ce qui compte. Il est là pour raisonner, synthétiser, rédiger ou décider à partir d’un contexte propre.
Les conséquences sont très concrètes :
- Moins de redondance dans les prompts, parce que les règles vivent ailleurs.
- Moins de tokens envoyés, donc moins de coût et moins de bruit.
- Un contexte persistant, qu’on peut réutiliser entre plusieurs tâches.
- Des réponses plus cohérentes, parce que les mêmes règles sont appliquées partout.
- La possibilité de stocker des résultats intermédiaires au lieu de tout recalculer.
Je le vois souvent chez les équipes business. Le vrai sujet n’est pas “Quel prompt magique utiliser ?”. Le sujet, c’est “Où sont nos sources fiables, qui les met à jour, quelles règles de marque doivent s’appliquer, et quand est-ce qu’on rafraîchit les données ?”. Là, on sort du simple usage IA. On touche au data engineering, à la gouvernance et à l’automatisation.
Une grille simple aide à décider quoi faire sans sur-ingénierie :
| Situation | Décision |
| Question simple, faible enjeu, pas besoin de réutiliser la réponse | Utiliser un prompt direct |
| Tâche récurrente, règles métier, sources multiples | Passer par un workflow Hermes Agent-style |
| Donnée externe à jour nécessaire, CRM, ERP, base produit, calendrier | Ajouter un appel API ou MCP |
| Résultat utile pour une prochaine étape ou un autre agent | Stocker la réponse dans le contexte persistant |
Le bon réflexe, c’est de demander : est-ce que je veux juste une réponse maintenant, ou est-ce que je construis un actif réutilisable pour les prochaines fois ?
Et si le vrai levier n’était pas le prompt ?
Le workflow Hermes Agent-style remet les choses dans le bon ordre. Je garde le contexte sur mon infrastructure, je récupère seulement les fragments utiles, j’ajoute les règles métier pertinentes, puis j’appelle le LLM avec un prompt court et ciblé. C’est plus propre, plus économique et plus simple à gouverner. Le modèle ne sert plus à fouiller partout, il sert à raisonner, synthétiser, rédiger. Pour une entreprise, c’est souvent le passage obligé entre un prototype IA sympa et un système utilisable à l’échelle. Le bénéfice pour vous est clair : moins de tokens gaspillés, plus de contrôle, et des workflows IA vraiment réutilisables.
FAQ
- Qu’est-ce qu’un workflow Hermes Agent-style ?
C’est une architecture d’agent IA qui garde le contexte sur votre infrastructure et n’envoie au LLM que les informations minimales nécessaires. L’idée n’est pas de faire un prompt énorme, mais de préparer le contexte avant l’appel au modèle. - Pourquoi cette approche réduit les coûts en tokens ?
Elle évite de renvoyer les mêmes données à chaque appel. Le magasin de contexte, la skill library et l’extracteur minimal sélectionnent les bons fragments en amont. Le LLM reçoit moins de texte, donc consomme moins de tokens. - Le LLM accède-t-il directement au CRM ou à l’entrepôt de données ?
Non, dans cette architecture, le LLM ne lit pas directement les systèmes sources. Les données utiles sont d’abord stockées dans un magasin de contexte contrôlé, puis seuls des extraits sélectionnés sont envoyés au modèle. - À quoi sert la skill library ?
Elle contient les règles de ton, les guides de marque, les consignes de style, les références et les standards métier. L’agent récupère uniquement les règles pertinentes pour la tâche, au lieu d’envoyer toute la documentation au LLM. - Quand faut-il utiliser ce type d’architecture ?
Je l’utiliserais dès qu’un workflow IA doit enchaîner plusieurs tâches, réutiliser du contexte, interroger des systèmes métier ou fonctionner à l’échelle. Pour une question simple et isolée, un prompt direct peut suffire. Pour un process business récurrent, le contexte stocké devient vite indispensable.
A propos de l’auteur
Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, analytics engineering, automatisation no/low code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes data, marketing et business sur des architectures concrètes, pas des démos qui tiennent trois jours. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez construire des workflows IA fiables, mesurables et maîtrisés, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.