Un workflow Hermes Agent réduit les coûts LLM en gardant le contexte chez vous et en envoyant au modèle seulement l’extrait utile. Je vais montrer comment structurer ça avec un magasin local, une skill library et un extracteur de prompt minimal.
Pourquoi sortir le contexte du prompt ?
Il faut sortir le contexte du prompt parce que le LLM n’a pas besoin de tout voir pour bien raisonner, il a besoin du bon morceau au bon moment.
Quand un agent IA commence à travailler sérieusement, il ne discute plus juste avec un utilisateur. Il appelle un CRM, une CDP, c’est-à-dire une plateforme de données clients, un data warehouse, des fichiers partagés, des APIs internes, parfois même des outils métiers un peu bricolés mais critiques. Et là, si on pousse tout dans le prompt, ça dérape vite.
Comment créer un agent IA local en streaming ?
On se retrouve avec des prompts énormes. Plus chers. Plus lents. Plus difficiles à relire. Et surtout plus risqués, parce qu’on expose au modèle des données qu’il n’avait pas forcément besoin de voir. Des emails clients, des notes commerciales, des segments marketing, des informations RH, des contrats. Bref, tout ce qu’on préfère éviter d’envoyer “au cas où”.
Entre nous, on le sait bien, faire appel à un consultant en automatisation intelligente et en agent IA, c’est souvent le raccourci le plus malin. On en parle ?
L’approche Hermes Agent inverse cette logique. Au lieu d’empiler du contexte dans le prompt, je garde les données dans l’infrastructure de l’entreprise. Je filtre localement. Je sélectionne uniquement ce qui est utile. Puis seulement après, j’appelle le modèle avec un contexte court, propre, contrôlé.
Chez des clients, je vois souvent que le vrai sujet n’est pas seulement le prix du token. Oui, le coût compte. Mais ce qui bloque vraiment en production, c’est la traçabilité, la répétabilité, et la capacité à expliquer pourquoi l’agent a utilisé telle donnée plutôt qu’une autre. Quand un métier demande “Pourquoi l’agent a répondu ça ?”, il faut autre chose qu’un énorme prompt impossible à auditer.
Les bonnes pratiques vont dans ce sens. Le NIST AI Risk Management Framework, un cadre américain de gestion des risques IA, pousse à documenter, contrôler et gouverner les systèmes IA. L’OWASP, connu pour ses référentiels de sécurité applicative, liste aussi des risques propres aux applications LLM, avec un message assez clair : il faut limiter l’exposition des données, des outils et des prompts.
| Sujet | Approche prompt classique | Approche Hermes Agent |
| Coût | Beaucoup de tokens envoyés à chaque appel. | Contexte réduit, donc appels moins chers. |
| Sécurité | Données sensibles souvent exposées trop largement. | Données filtrées avant l’appel au LLM. |
| Contexte | Tout est mis “au cas où”. | Seulement le bon morceau au bon moment. |
| Industrialisation | Difficile à auditer et à reproduire. | Plus traçable, plus contrôlable, plus stable. |
Quels sont les trois blocs à prévoir ?
Un workflow Hermes Agent tient sur trois blocs simples, un magasin de contexte local, une skill library et un extracteur de prompt minimal.
Je le vois comme une architecture très pragmatique. Pas besoin de mettre un LLM partout. Le LLM, c’est le moteur de génération ou de raisonnement, pas le vide-ordures de toute votre donnée.
Le magasin de contexte local, c’est le réservoir contrôlé par l’équipe. Il reçoit les données brutes venant du CRM, de la CDP, du data warehouse, des fichiers partagés ou des systèmes live. Une CDP, pour faire simple, c’est une base qui centralise les données clients venant de plusieurs canaux. Le point important, c’est que les réponses d’API n’atterrissent pas directement dans le prompt. Elles passent d’abord dans ce magasin, où on peut filtrer, nettoyer, historiser et limiter ce qui sera exploitable.
La skill library, c’est le répertoire local qui contient tout ce qui aide l’agent à bien travailler. Guides de voix, règles de style, anciens articles, documents de marque, règles métier, exemples validés. L’agent ne charge pas tout, sinon on explose les coûts et on dilue le contexte. Il recherche par mots-clés ou par similarité vectorielle, puis il extrait seulement les passages utiles. La similarité vectorielle, c’est juste une façon de retrouver des textes proches en sens, pas seulement avec les mêmes mots.
L’extracteur de prompt minimal, c’est la couche peu coûteuse entre vos données et le LLM. Elle fait du scoring par mots-clés, de la recherche vectorielle ou des requêtes en base de données. Son rôle est simple : composer le paquet minimal à transmettre au modèle.
Comment réussir son écoute client avec l’IA ?
Le piège classique, je l’ai vu chez un client, c’est d’appeler un LLM pour décider quoi envoyer au LLM. Ça marche en démo, puis la facture grimpe et le comportement devient flou. L’extracteur ne doit pas appeler le LLM pour décider quoi envoyer au LLM. C’est là qu’on gagne en coût, en stabilité et en contrôle.
Côté développeur, je démarre souvent simple. Le stockage local peut être une base SQL, un stockage documentaire ou un bucket interne. La recherche peut être textuelle au début, avec des filtres propres. Quand le volume augmente, on ajoute une recherche vectorielle. Pas avant.
| Composant | Rôle | Erreur fréquente à éviter |
| Magasin de contexte local | Centraliser et contrôler les données brutes avant usage dans le prompt. | Envoyer directement les réponses d’API au LLM sans filtrage. |
| Skill library | Stocker les règles, exemples, contenus validés et documents utiles à l’agent. | Charger toute la bibliothèque dans chaque prompt. |
| Extracteur de prompt minimal | Sélectionner le contexte utile avec mots-clés, vecteurs ou requêtes simples. | Utiliser un LLM pour décider quoi envoyer au LLM. |
Comment circule la donnée dans le workflow ?
La donnée circule toujours dans le même ordre : collecte locale, filtrage, assemblage, appel LLM, puis journalisation du résultat. C’est simple, et c’est justement ce qui rend le workflow Hermes facile à contrôler.
Une tâche arrive. Ça peut être rédiger une réponse client, produire une synthèse CRM, ou préparer une recommandation marketing. L’extracteur commence par vérifier si les données utiles existent déjà dans le magasin local. Si elles sont là, il les filtre. Si elles manquent, il appelle les systèmes sources, comme le CRM, l’outil support ou la base produit, stocke le résultat en local, puis reprend son filtrage.
Ensuite, l’assemblage commence. L’extracteur récupère un extrait de données opérationnelles dans le magasin de contexte. Il ajoute les morceaux pertinents de la skill library, c’est-à-dire la bibliothèque de méthodes, règles, exemples ou consignes métier que l’agent peut réutiliser. Puis il construit un prompt court avec trois choses : une consigne claire, les faits nécessaires, et les contraintes de sortie.
Le point important, c’est que le modèle ne reçoit pas tout l’historique, pas tout le CRM, pas tous les documents de marque. Il reçoit un paquet contextualisé et limité. C’est moins cher, plus rapide, et franchement plus propre à auditer.
async function handleTask(task) {
// Vérifie si le contexte utile existe déjà en local
let context = await contextStore.find({
customerId: task.customerId,
topic: task.topic
});
// Si le contexte manque, appelle les systèmes live
if (!context || context.isIncomplete) {
const liveData = await sourceSystems.fetch({
customerId: task.customerId,
topic: task.topic
});
// Stocke les données récupérées pour éviter de rappeler les sources
await contextStore.save(liveData);
// Relance la recherche locale après stockage
context = await contextStore.find({
customerId: task.customerId,
topic: task.topic
});
}
// Récupère les compétences utiles pour cette tâche
const skills = await skillLibrary.findRelevant({
taskType: task.type,
topic: task.topic
});
// Construit un prompt minimal, sans historique inutile
const minimalPrompt = {
instruction: task.instruction,
facts: context.summary,
skills: skills.map(skill => skill.content),
outputConstraints: task.outputConstraints
};
// Appelle un LLM générique, sans dépendre d’un fournisseur précis
const response = await llm.generate(minimalPrompt);
// Journalise la réponse pour audit, réutilisation ou amélioration
await contextStore.saveResult({
taskId: task.id,
prompt: minimalPrompt,
response,
createdAt: new Date()
});
return response;
}Je commence souvent par une version simple avec recherche mots-clés et règles métier, parce que c’est plus facile à auditer avant d’ajouter de la recherche vectorielle. La recherche vectorielle, c’est utile quand on veut retrouver des contenus proches par le sens, pas seulement par les mots exacts. Mais au début, je préfère voir clairement pourquoi une donnée a été sélectionnée.
Comment éviter les dérives en production ?
On évite les dérives en traitant le prompt comme la dernière étape du système, pas comme le système lui-même.
L’erreur classique, je la vois souvent chez des clients, c’est de faire une requête, puis une réponse, avec un énorme prompt qui essaie de tout porter. Le prompt contient les règles métier, les exemples, les exceptions, les données, parfois même des bouts de documentation copiés à la main. Ça marche en démo. Ça devient fragile en production.
Avec une approche Hermes Agent, je prépare le terrain avant d’appeler le LLM. Le LLM, c’est le modèle de langage qui génère ou raisonne sur la réponse. Il ne doit pas recevoir tout votre système d’information en vrac. Il doit recevoir le bon contexte, au bon moment, avec une origine claire.
La qualité vient surtout de ce qu’on fait avant le modèle : collecte, filtrage, sélection du contexte, traçabilité. Un bon workflow doit garder une trace des fragments envoyés au modèle, versionner la skill library, c’est-à-dire la bibliothèque de compétences ou d’actions disponibles, et conserver l’origine des données utilisées. Sinon, impossible de comprendre pourquoi une réponse a changé.
Je limite aussi les champs sensibles. Moins on envoie de données au modèle, moins on expose d’informations. Ça paraît évident, mais en pratique beaucoup de workflows balancent trop large “au cas où”. Mauvais réflexe. Je préfère définir une taille maximale de contexte, filtrer les données inutiles, puis tester les cas où l’information manque. Si le score de pertinence est trop faible, le workflow doit avoir un fallback. Par exemple demander une précision, répondre qu’il manque une donnée, ou basculer vers une revue humaine.
Ces contrôles servent aussi la sécurité, sans dramatiser. Plus le contexte est préparé, plus le workflow devient répétable. Et quand c’est répétable, on peut comparer les résultats, détecter les écarts, faire des tests de non-régression et corriger proprement.
- Données sources identifiées.
- Stockage local prêt.
- Règles de filtrage documentées.
- Skill library structurée.
- Logs activés.
- Seuils de pertinence définis.
- Tests de non-régression.
- Revue des données sensibles.
Le LLM doit raisonner, pas faire le ménage dans votre système d’information.
Et si le meilleur prompt était surtout le mieux préparé ?
Un workflow Hermes Agent, ce n’est pas un prompt magique. C’est une architecture plus saine : les données restent dans votre environnement, l’extracteur choisit le contexte utile, la skill library apporte les règles et le LLM reçoit seulement ce qu’il doit traiter. On réduit les tokens, on limite l’exposition des données et on obtient un workflow plus facile à auditer. C’est souvent là que les projets IA deviennent vraiment industrialisables. Pas parce que le modèle est plus intelligent, mais parce que le système autour de lui est mieux conçu. Le bénéfice pour vous est simple : moins de coût, plus de contrôle, plus de fiabilité.
FAQ
- Qu’est-ce qu’un workflow Hermes Agent ?
C’est une façon de construire un agent IA où le contexte reste principalement dans l’infrastructure de l’entreprise. Le modèle reçoit seulement les extraits utiles pour la tâche. L’idée est simple : moins de contexte envoyé, moins de tokens consommés, plus de contrôle sur les données. - Pourquoi cette approche réduit les coûts LLM ?
Parce qu’on évite d’envoyer de gros blocs de données à chaque appel modèle. Un extracteur local sélectionne le fragment pertinent avant l’appel LLM. Le modèle travaille donc sur un prompt plus court, mieux préparé, avec moins de tokens inutiles. - Est-ce que cette architecture remplace le RAG ?
Pas forcément. Elle peut utiliser des mécanismes proches du RAG, comme la recherche vectorielle, mais elle va plus loin dans la logique d’architecture. Le sujet n’est pas seulement de retrouver un document, c’est d’orchestrer le contexte, les règles métier, les données fraîches et la sortie du modèle. - Faut-il forcément une base vectorielle pour commencer ?
Non. Je préfère souvent commencer simple avec des requêtes SQL, des mots-clés et des règles de scoring lisibles. Quand le volume ou la variété des documents augmente, la recherche vectorielle devient intéressante. Mais elle ne doit pas masquer la logique métier. - Quels sont les risques à surveiller en production ?
Les principaux risques sont l’envoi excessif de données sensibles, l’absence de logs, une skill library non versionnée, des seuils de pertinence flous et des appels LLM utilisés pour compenser un mauvais filtrage. Le bon réflexe, c’est de tracer ce qui est envoyé au modèle et pourquoi.
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 qui veulent passer de prototypes IA sympas à des workflows fiables, gouvernés et utiles au business. J’ai travaillé pour 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 cadrer ou industrialiser vos workflows IA, contactez-moi.
⭐ Data Analyst, Analytics Engineer et expert dans l’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 propre RGPD, entrepôt de données (GTM server, BigQuery…), modèles (dbt/Dataform), dashboards décisionnels (Looker, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, Make, 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.