J’ai intégré Hermes Agent à notre support client : mon retour d’expérience

Répondre à un e-mail de support client prend parfois cinq minutes. Parfois beaucoup plus. Pas nécessairement parce que la question est compliquée, mais parce qu’il faut retrouver le bon contexte avant de pouvoir répondre correctement.

J’ai voulu voir si un agent IA pouvait nous aider à préparer des réponses pertinentes, directement dans notre outil de support. Depuis fin août 2026, j’expérimente Hermes Agent, avec un assistant baptisé Nova.

Premier bilan : 85 conversations ayant bénéficié d’au moins un brouillon sur 30 jours, seulement 1,50 € HT facturé par IONOS en septembre pour l’inférence, mais aussi parfois des réponses à reprendre et des difficultés techniques bien réelles. Le gain est réel, mais l’automatisation d’un support client reste beaucoup moins simple qu’une démonstration d’agent IA.

Voici mon retour d’expérience.

WebAnyOne : le défi du support de plusieurs centaines d’instances Mautic

Je suis le fondateur de WebAnyOne, une entreprise spécialisée dans l’hébergement et l’accompagnement autour de Mautic, une solution open source de marketing automation. Nous hébergeons et maintenons plusieurs centaines d’instances Mautic pour nos clients (c’est un défi en termes d’hébergement et de sécurité, j’en parlerai dans un article dédié).

Au quotidien, les demandes de support sont très variées : configuration de campagnes marketing, problèmes de délivrabilité, segmentation, synchronisation avec un CRM, erreurs techniques ou encore questions d’utilisation. Chaque environnement est différent. Les versions de Mautic, les réglages, les intégrations et les usages varient d’un client à l’autre.

Pour répondre correctement à une demande, il faut retrouver l’historique des échanges, identifier l’instance concernée, comprendre sa configuration, examiner plusieurs hypothèses et rédiger une réponse adaptée. Le problème n’est pas simplement le temps passé à écrire un e-mail. C’est le temps et l’effort nécessaires pour reconstituer le contexte avant de pouvoir répondre.

Mon objectif : ne plus partir d’une page blanche

C’est de là qu’est née mon envie d’utiliser un agent IA pour le support. Je ne cherchais pas un chatbot qui répond automatiquement aux clients avec des phrases génériques. Je voulais un assistant capable de lire une conversation, de comprendre la demande, de récupérer les informations disponibles sur l’environnement technique du client et de préparer une réponse que je pourrais relire.

Le gain attendu n’était pas seulement une réduction du temps de rédaction. Je voulais surtout faciliter le travail intellectuel qui précède chaque réponse. La nuance est importante ! Lorsqu’un brouillon est déjà structuré, avec une première analyse, des hypothèses et une proposition de réponse, il est souvent plus facile de compléter ou de corriger le texte que de repartir de zéro. Même lorsque le brouillon n’est pas parfait.

Pourquoi Hermes Agent ?

Pour cette expérimentation, j’ai choisi Hermes Agent, un agent IA open source développé par Nous Research. Hermes ne se limite pas à une interface de conversation. Il peut utiliser différents outils, interagir avec des systèmes externes et conserver des connaissances ou des procédures réutilisables. Autre avantage : il n’impose pas un unique fournisseur de modèles d’IA.

Je peux donc choisir mon infrastructure d’inférence indépendamment de la partie agent. J’ai baptisé notre assistant support Nova.

L’objectif est de construire progressivement un agent qui connaît suffisamment l’environnement WebAnyOne pour faciliter les tâches récurrentes du support. Mais disposer d’Hermes Agent ne suffit pas. L’essentiel du travail consiste à lui donner les bonnes capacités, les bons accès et les bonnes consignes.

Comment Nova fonctionne concrètement

Nous utilisons Front pour centraliser les échanges par e-mail avec nos clients. Je souhaitais conserver Front comme interface de travail, plutôt que d’obliger l’équipe à utiliser une application supplémentaire.

Le fonctionnement recherché est le suivant :

1. Nova récupère une conversation dans Front.
2. Elle identifie le client et analyse sa demande.
3. Elle recherche les informations techniques (via API) et documentaires auxquelles il est autorisé à accéder.
4. Elle prépare une réponse sous forme de brouillon dans Front.
5. Un humain relit, corrige et décide de l’envoyer ou non.

Nova ne répond pas de manière autonome aux clients. C’est un choix volontaire : il travaille en préparation des réponses, sous supervision humaine. L’agent Nova n’a tout simplement pas accès au bouton pour envoyer la réponse lui-même (merci l’API Front).

La mécanique est exécutée par un service automatisé. Celui-ci est configuré pour redémarrer un cycle deux minutes après la fin du précédent. Ce n’est pas une cadence de traitement de 30 demandes par heure : certains cycles n’ont rien à traiter et d’autres rencontrent des erreurs. La première utilisation que j’ai pu retrouver avec certitude date du 25 août 2026 : un brouillon préparé par Nova, suivi d’une réponse humaine envoyée. Les journaux montrent également le démarrage du rapprochement des réponses Front ce jour-là.

Les connexions réellement opérationnelles

Nova peut, sous réserve que les services soient disponibles :

• Lire les conversations et commentaires internes dans Front.
• Créer et mettre à jour des brouillons de réponse.
• Interroger l’API du Backoffice WebAnyOne.
• Consulter les API Mautic des instances enregistrées pour lesquelles les accès sont valides.
• Récupérer les identifiants nécessaires via 1Password.
• Exploiter une base de connaissances et des documents locaux.

Cela représente déjà plusieurs intégrations. Mais ces accès ont des limites précises : Nova ne dispose pas d’un accès SSH autonome et général à tous les serveurs clients. Elle n’a pas non plus d’accès SQL universel aux bases de données Mautic.

Il faut distinguer les outils disponibles pour administrer l’infrastructure et ceux que l’agent est effectivement autorisé à utiliser. C’est essentiel lorsqu’on travaille sur des environnements qui contiennent des données clients.

J’ai appris à ne pas faire confiance aux instructions seules

Lors de mes premiers tests, j’ai essayé de donner directement à Nova des accès aux API. Je me suis rapidement rendu compte qu’elle tentait régulièrement d’effectuer des opérations qui dépassaient le cadre de ce que je lui avais demandé. C’est un point important : demander à un agent IA de ne pas effectuer une action ne garantit pas qu’il respectera cette instruction.

J’ai donc changé d’approche. Pour les instances Mautic, Nova ne communique pas librement avec l’ensemble des API. J’ai intercalé une interface entre l’agent et les instances, une sorte de « passe-plat », qui contrôle les opérations autorisées.

J’applique le même principe à Front. Nova peut lire les conversations et préparer des brouillons, mais les permissions de son accès API ne lui permettent pas d’envoyer lui-même un e-mail.

Ainsi, même si elle interprète mal une consigne ou tente une opération non prévue, ses permissions techniques doivent l’empêcher de dépasser les limites définies. La sécurité ne repose donc pas uniquement sur les instructions données au modèle, mais sur les droits réellement accordés à ses outils.

C’est probablement l’une des leçons les plus importantes de cette expérimentation : plus un agent a accès au système d’information, plus les garde-fous techniques deviennent indispensables.

L’inférence des modèles d’IA chez IONOS

Pour la partie modèle d’IA, j’utilise l’AI Model Hub d’IONOS, notamment avec GPT-OSS-120B. IONOS propose d’accéder à différents modèles à travers une API compatible avec celle d’OpenAI. Le fournisseur assure par contrat que les traitements de son AI Model Hub sont réalisés dans ses centres de données européen (France et Allemagne) et que les données envoyées ne sont pas utilisées pour entraîner les modèles. Ce sont deux éléments essentiels dans un contexte B2B opéré depuis la France.

Je suis bien conscient que le recours à ce service ne règle pas à lui seul toutes les questions de conformité ou de sécurité. L’ensemble de nos données d’exploitation sont gérées en dehors de IONOS. Ce dernier nous fournissant, à ce jour seulement l’inférence d’un modèle Open Source. Pour le coup, l’agent Nova tourne sur une machine virtuelle chez Hetzner Cloud en Allemagne.

On distingue donc bien trois couches dans le cadre de la création de cet Agent IA : Hermes pour l’orchestration, Hetzner pour l’exécution de l’agent, et IONOS pour l’inférence des modèles.

La boucle de feedback : permettre à Nova de progresser

C’est l’une des parties qui m’intéressent le plus dans ce projet. Mon objectif n’est pas seulement que Nova prépare des réponses. J’aimerais qu’elle apprenne progressivement de mes corrections. J’utilise pour cela deux mécanismes complémentaires.

Des corrections explicites

Je peux donner directement des instructions à Nova dans Front, notamment au moyen d’un commentaire interne à destination de Nova. Je peux lui expliquer qu’une réponse est trop affirmative, qu’il aurait dû vérifier un paramètre Mautic ou qu’il manque une information importante. Ces indications contribuent à faire évoluer son comportement et ses connaissances.

La comparaison avec les réponses réellement envoyées

En parallèle, j’ai mis en place une boucle de rapprochement. Nova conserve le texte de ses propositions et recherche ensuite les réponses humaines envoyées dans les conversations correspondantes. Elle peut ainsi comparer ce qu’il avait proposé avec ce qui a finalement été envoyé, en extraire des exemples et certaines règles rédactionnelles. Le processus cherche à transformer les corrections du quotidien en apprentissages réutilisables.

Mais il faut être précis : comparer deux textes ne permet pas de savoir automatiquement pourquoi un brouillon a été modifié. Une formulation différente n’est pas nécessairement meilleure. Ce mécanisme n’implique pas de ré-entraînement du modèle : on travaille sur les connaissances, les instructions et les procédures de l’agent et non directement sur les poids du LLM. C’est le harnais autour du LLM qui est mis à jour en continu grâce à cette boucle de feedback. L’intérêt est réel, j’ai déjà constaté une amélioration dans la qualité des réponses entre début et fin septembre : sur le ton, les formules de politesse, la manière de reformuler la demande et d’amener une solution.

Deux cas réels : entre une réponse presque parfaite et une réponse à reprendre

Pour illustrer concrètement ce que Nova m’apporte, mais aussi ses limites, j’ai sélectionné deux conversations. Dans la première, la proposition de Nova a été presque intégralement conservée. Dans la seconde, il a fallu reprendre une grande partie de la réponse. Deux situations qui montrent pourquoi je considère aujourd’hui Nova comme un copilote plutôt que comme un support autonome.

Exemple 1 : un litige d’abonnement, une réponse presque entièrement réutilisée

Dans un échange avec un fournisseur de services d’e-mailing, je devais répondre à un désaccord concernant un changement d’abonnement.

Le sujet nécessitait de reprendre l’historique des échanges, de comprendre la chronologie des événements, de vérifier les éléments de facturation et de formuler une réponse adaptée. Nova a réalisé une bonne partie de ce travail préparatoire. Elle a reconstitué la chronologie, identifiée les factures à vérifier et proposé une réponse structurée avec la question à poser au fournisseur.

Résultat : le message que j’ai finalement envoyé présentait 99,6 % de similarité avec le brouillon préparé par Nova.

Attention, cela ne signifie pas que Nova a résolu le litige à ma place ni que j’ai économisé 99,6 % de mon temps. Cela signifie simplement que sa proposition était suffisamment exploitable pour que je la conserve presque intégralement. C’est précisément ce que j’attends de cet assistant : retrouver le contexte et préparer une réponse pertinente, pour que je puisse me concentrer sur sa vérification et sur la décision finale.

Exemple 2 : une campagne envoyée trop tôt, une réponse largement reprise

Un client nous signale qu’une campagne marketing est partie un jour plus tôt que prévu. Nova prépare une première réponse, principalement centrée sur les paramètres de programmation des campagnes dans Mautic. Sur le papier, l’explication semble techniquement plausible.

Mais en relisant sa proposition, je constate qu’elle est passée à côté de plusieurs éléments importants. D’abord, il fallait reconnaître une mauvaise compréhension de la situation et présenter des excuses au client. Ensuite, Nova avait oublié une condition technique importante : la publication de l’e-mail, qui intervient dans son processus d’envoi. J’ai donc dû reprendre une grande partie de la réponse pour apporter une explication plus complète et mieux adaptée à la situation.

Résultat : seulement 36,5 % de similarité entre le brouillon de Nova et le message finalement envoyé. Ce cas illustre une limite importante : l’agent sait expliquer des fonctionnalités, mais ne comprend pas toujours suffisamment la situation et les attentes de son interlocuteur.

Une réponse de support ne consiste pas uniquement à donner une explication technique. Il faut aussi savoir reconnaître une erreur, rassurer son interlocuteur et prendre ses responsabilités. C’est précisément pour cette raison que je conserve une validation humaine avant chaque envoi.

Ces deux situations résument assez bien mon expérience avec Nova : parfois, le brouillon est quasiment prêt à envoyer ; parfois, il nécessite une reprise importante. Ce qui compte, ce n’est donc pas uniquement que l’agent produise une réponse. C’est qu’il apporte suffisamment de contexte et de pertinence pour faciliter réellement le travail de l’équipe support.

Les premiers résultats : 85 conversations avec un brouillon sur 30 jours

Pour dépasser ces deux cas particuliers, j’ai examiné les métriques de Nova sur les 30 derniers jours observés. Voici ce que les journaux permettent réellement de mesurer :

• 85 conversations distinctes avec au moins un brouillon créé ou modifié
• 87 brouillons créés
• 20 mises à jour de brouillons
• 162 appels aux modèles IA (le LLM chez IONOS)
• Tokens en entrée : 2 909 803
• Tokens en sortie : 99 009

La réalité est plus complexe qu’une litanie de chiffres : les 85 conversations ne correspondent pas à 85 demandes résolues automatiquement. Elles ne représentent pas non plus la totalité du support WebAnyOne.

Les journaux font également apparaître 419 tentatives de manipulation de brouillons, dont 71 en échec. Il est trompeur de présenter ces chiffres comme 419 demandes traitées ou 71 clients concernés par un problème. Une seule conversation problématique peut générer de nombreuses tentatives techniques.

Dans tous les cas les e-mails du support sont traités au fil de l’eau par notre équipe support. La plupart du temps avec une proposition fournie par l’agent IA ce qui permet un gain de temps non négligeable et nous pousse à une meilleure qualité de réponse car l’IA est capable d’aller chercher les méta données de chaque instance Mautic en quelques secondes là où notre temps d’action humain est beaucoup plus long (de l’ordre de quelques minutes).

Cela nous permet aussi de créer petit à petit une base de connaissance de cas d’usages métier et de questions/réponses. Et donc d’affiner notre connaissance client et d’améliorer le service rendu au fil du temps.

Combien coûte Nova ?

C’est probablement l’un des résultats les plus surprenants de cette expérimentation. Pour tout le mois de septembre 2026, la facture IONOS s’élève à : 1,50 € HT, soit 1,80 € TTC. Ces chiffres montrent que l’inférence peut coûter très peu cher dans cette configuration. À ce jour une conversation client a un coût de quelques centimes d’euros pour un gain de temps et de contexte certains.

Le véritable coût est ailleurs

Le modèle d’IA est loin d’être le seul coût du système. Il faut aussi compter :

• L’hébergement de l’agent chez Hetzner (quelques dizaines d’euros mensuels).
• Le temps consacré au développement des connecteurs (autour de 30h).
• La configuration des autorisations et des outils.
• La maintenance et la correction des dysfonctionnements (cela arrive encore trop souvent).
• La relecture des réponses proposées (au fil de l’eau).
• Le travail nécessaire pour améliorer les connaissances de l’agent (au fil de l’eau).

Pour l’instant, je retiens surtout ceci : la consommation des modèles IA n’est pas le principal frein économique que j’observe. Le véritable investissement se trouve dans leur intégration au système d’information et dans la fiabilité des automatisations.

J’ai dépensé très peu en inférence, mais j’ai passé une trentaine d’heures à construire les connexions et à faire fonctionner le système. Et la maintenance n’est pas terminée.

Est-ce que je gagne vraiment du temps ?

Je ne suis pas encore en mesure de chiffrer précisément le temps que Nova me fait économiser. Je n’ai pas chronométré suffisamment de demandes comparables, avec et sans l’agent, pour produire une mesure fiable.

En revanche, je constate une vraie différence dans ma manière de travailler. Lorsque Nova fonctionne correctement, je ne pars plus systématiquement d’une page blanche. Elle me propose un angle de réponse, rassemble une partie du contexte technique et identifie parfois des éléments auxquels je n’aurais pas immédiatement pensé.

Je peux alors consacrer mon attention à vérifier son analyse, corriger les éventuelles erreurs et adapter le message à la situation du client. La qualité reste très variable : certains brouillons nécessitent environ 10 % de reprise, d’autres jusqu’à 80 %. Et parfois, repartir de zéro reste préférable.

Le premier bénéfice que j’observe n’est donc pas seulement le temps potentiellement économisé, mais la réduction de l’effort nécessaire pour construire une réponse pertinente.

Ce qui coince encore

Après ces premières semaines, trois limites ressortent.

1. L’agent a besoin de beaucoup de contexte

Pour répondre correctement à un client, il faut connaître son environnement. Une IA très performante sans accès aux bonnes informations risque de produire une réponse générique, ou de formuler avec assurance une hypothèse non vérifiée.

Le vrai travail consiste donc à connecter les outils, organiser les connaissances et encadrer les accès. Et chaque connexion augmente la complexité de l’ensemble. C’est aussi un enjeu de sécurité. Un agent capable d’accéder à de nombreuses instances marketing doit utiliser des permissions adaptées et rester sous contrôle, notamment pour les opérations sensibles.

2. La fiabilité technique n’est pas encore au niveau attendu

Les interruptions et les erreurs d’autorisation peuvent empêcher Nova de produire ses brouillons. J’ai notamment rencontré des boucles d’appels API qui finissent par épuiser les quotas disponibles et bloquer certaines fonctions de l’agent pendant plusieurs heures. Bonjour les centaines de requêtes inutiles !

C’est probablement le principal obstacle à une utilisation quotidienne durable. Un agent qui fonctionne correctement lorsqu’on le teste, mais qui cesse de préparer les réponses sans que le problème soit immédiatement détecté, reste fragile. La supervision, les alertes et la capacité à reprendre après un incident comptent autant que la qualité du modèle d’IA.

3. La boucle de feedback doit prouver son efficacité

La capacité à conserver des corrections et à enrichir les procédures est prometteuse. Mais il reste à mesurer si Nova reproduit moins souvent les mêmes erreurs, si elle devient plus pertinent sur les demandes récurrentes et si les informations mémorisées restent fiables. Aujourd’hui, il serait prématuré de parler d’un agent qui s’améliore automatiquement à chaque interaction. Nous sommes sur le bon chemin. Reste à vérifier, dans la durée, que Nova progresse réellement. 😉

Ce que je ferais différemment

Avec le recul, je commencerais par un périmètre plus restreint. Je sélectionnerais quelques catégories de demandes récurrentes, avec les informations nécessaires pour y répondre et des critères de réussite précis.

Je mettrais également en place, dès le départ, quatre indicateurs :

• Le taux de demandes pour lesquelles un brouillon exploitable est produit.
• Le niveau réel de correction humaine.
• Le temps total de traitement, avant et après introduction de l’agent.
• La disponibilité du service et les causes d’échec.

Je donnerais aussi la priorité à la stabilité des connexions avant d’ajouter de nouveaux outils. Une nouvelle capacité est intéressante, mais elle n’apporte aucune valeur lorsqu’elle rend l’ensemble trop fragile.

Mon bilan : un copilote utile, pas une martingale

Après ces premières semaines d’expérimentation, je ne considère pas Nova comme un système capable d’automatiser notre support client. C’est un assistant qui, lorsqu’il fonctionne correctement, facilite la préparation des réponses. Il rassemble des informations, propose une première analyse et permet à l’équipe de se concentrer davantage sur la vérification et la relation client.

Le coût d’inférence est dérisoire. En revanche, les dizaines d’heures passées à développer les intégrations, les problèmes de connexion et les corrections humaines me rappellent une réalité : faire fonctionner un agent IA est relativement accessible. En faire un outil fiable au quotidien est une autre histoire.

Si je devais poursuivre ce projet avec une seule priorité, ce serait la fiabilité. Avant de multiplier les compétences de Nova, je dois m’assurer qu’il utilise correctement celles dont il dispose déjà.

Ensuite, je souhaite mesurer plus précisément le temps gagné et vérifier si la boucle de feedback améliore réellement la qualité de ses réponses dans la durée.

Le gain est réel, mais ce n’est pas la martingale. En tout cas, pas pour le moment.

Cette expérience m’a surtout appris une chose : la difficulté n’est plus de faire rédiger un e-mail à une IA. C’est de lui donner le bon contexte, de contrôler ce qu’elle peut faire et de construire un système suffisamment robuste pour l’intégrer durablement dans le travail d’une équipe.

Je partagerai un nouveau bilan dans quelques mois, avec une question en tête : une fois les problèmes de fiabilité corrigés, Nova sera-t-elle réellement capable de produire des réponses de meilleure qualité avec moins d’interventions humaines ?