D'OpenClaw à Hermes : quand un cabinet d'assurance passe de l'assistant IA à l'agent IA

·12 min de lecture
Mis à jour le 6 juillet 2026

Un dirigeant m'a dit récemment une phrase que j'entends de plus en plus souvent : "mon assistant IA marche bien, mais il ne progresse plus".

Ce dirigeant est agent général d'assurance. Il est indépendant, il représente une compagnie, et il gère cinq agences avec leurs équipes. Il y a plusieurs mois, nous avions déployé pour lui un assistant OpenClaw : un copilote IA joignable sur WhatsApp, avec de la mémoire, capable de retrouver une information, préparer une réponse ou résumer un dossier.

L'assistant rendait service. Ce n'est pas une histoire d'échec.

Mais au bout de quelques mois, deux limites sont devenues visibles. D'abord, l'assistant ne s'améliorait plus : il répondait toujours aussi bien, mais le cabinet, lui, ne travaillait pas mieux qu'avant. Ensuite, il ne suivait pas la croissance : cinq agences, des dizaines de demandes clients par jour, et un assistant qui ne travaille que quand on pense à le solliciter.

Nous avons fini par faire la migration qui s'imposait : passer de l'assistant OpenClaw à un agent Hermes. Pas parce que l'un est "meilleur" que l'autre. Parce que ce ne sont pas les mêmes outils : un assistant IA répond quand on le sollicite, un agent IA prend en charge un processus. Et son usage avait changé de nature.

Cet article raconte cette transition. Si vous dirigez une PME et que votre IA vous donne cette même impression de plafond, vous devriez vous y reconnaître.

Le point de départ : un assistant OpenClaw qui rendait service

Commençons par être honnête : OpenClaw n'était pas une erreur.

Pendant des mois, cet assistant a été utile exactement comme prévu. Le dirigeant lui écrivait sur WhatsApp comme à un collaborateur. Un brief le matin avec les rendez-vous et les sujets chauds. Une question sur un contrat pendant un déplacement. Un brouillon de réponse pour un client mécontent. Un résumé d'un long échange d'emails avant de rappeler un sociétaire.

L'assistant connaissait son contexte. Sa façon d'écrire, ses priorités, ses agences, ses habitudes. C'est le principe d'OpenClaw : un copilote personnel qui vit dans vos messageries, garde la mémoire de vos échanges et prépare le travail à la demande.

Pour un dirigeant qui passe sa journée entre cinq agences, une compagnie mandante et des clients, ce copilote a une vraie valeur. Il évite de rouvrir dix onglets pour reconstituer un contexte. Il fait gagner du temps sur la rédaction. Il permet de décider plus vite.

Le problème n'est donc pas ce que l'assistant faisait. Le problème est ce qu'il ne pouvait pas faire, par construction.

Pourquoi un assistant IA cesse de progresser

Un assistant IA plafonne parce que toute sa valeur passe par les demandes qu'on lui fait. Une fois qu'il connaît son utilisateur, il n'a plus grand-chose à apprendre, et personne ne lui confie ce qu'on ne pense pas à demander. La remarque "il ne progresse plus" décrit donc un phénomène précis, pas une impression vague.

Concrètement, un assistant s'améliore vite les premières semaines. Il apprend vos préférences, votre ton, vos raccourcis. Chaque conversation le rend plus pertinent. Puis la courbe s'aplatit.

Et c'est là que beaucoup de dirigeants font un mauvais diagnostic. Ils pensent que l'outil a atteint ses limites techniques. En réalité, l'outil a atteint les limites de son rôle.

Un assistant travaille quand on le sollicite. Toute sa valeur passe par la personne qui pose la question. Si le dirigeant ne pense pas à demander, rien ne se passe. Si un collaborateur d'agence ne sait pas formuler la demande, rien ne se passe non plus. L'assistant amplifie la personne qui l'utilise, mais il n'améliore pas le fonctionnement du cabinet.

Concrètement : le dirigeant demandait chaque semaine les mêmes types de brouillons, les mêmes résumés, les mêmes vérifications. L'assistant les produisait très bien. Mais personne ne demandait à l'assistant de traiter les demandes d'attestation qui arrivaient dans les boîtes email des agences, de relancer les pièces manquantes d'un dossier sinistre, ou de préparer les renouvellements du mois. Ce n'était pas son rôle, et ce n'est pas comme ça qu'on l'avait cadré.

L'amélioration qu'attendait ce dirigeant ne pouvait pas venir d'un assistant plus intelligent. Elle devait venir d'un système qui prend en charge des processus, sans attendre qu'un humain le sollicite.

Cinq agences, un assistant : le mur de la scalabilité

Un assistant personnel ne tient pas la charge d'un cabinet multi-agences, parce qu'il n'est branché ni sur les canaux où arrivent les demandes clients, ni sur les équipes qui les traitent. C'est la deuxième limite qu'a rencontrée ce dirigeant, et elle est encore plus concrète que la première.

Dans un cabinet d'agent général, les demandes entrantes sont massives et répétitives. Des attestations d'assurance pour un propriétaire, une école ou un employeur. Des déclarations de sinistre. Des demandes de devis auto, habitation ou santé. Des changements de véhicule, des déménagements, des ajouts de conducteur. Des questions sur une échéance ou un prélèvement. Des demandes de résiliation. Des relevés d'information.

Multipliez cela par cinq agences, et vous obtenez un flux permanent qui arrive par email, par téléphone et au guichet, traité par des équipes dont ce n'est qu'une partie du travail.

Face à ce flux, l'assistant du dirigeant ne pouvait rien faire, pour une raison simple : il était l'assistant du dirigeant. Un copilote personnel, branché sur ses conversations à lui. Les demandes des clients n'arrivaient pas dans ses canaux. Les équipes des agences n'avaient pas le réflexe, ni le cadre, pour passer par lui.

On aurait pu ouvrir l'assistant aux équipes. Nous y avons réfléchi. Mais on se serait heurté à des questions qui dépassent le copilote : qui a le droit de voir quoi entre les agences, comment garantir des réponses cohérentes d'une agence à l'autre, comment tracer ce qui a été envoyé à un client, comment gérer cinquante demandes simultanées quand l'assistant fonctionne par conversation.

En assurance, ces questions ne sont pas du confort. Le devoir de conseil impose de garder une trace de ce qu'on dit à un client. Une réponse approximative sur une garantie peut engager le cabinet. Un document envoyé au mauvais destinataire est un incident RGPD. Ce niveau d'exigence ne se gère pas dans un fil de discussion WhatsApp.

Le besoin avait changé de nature : il ne s'agissait plus d'aider un dirigeant à travailler, mais de faire fonctionner un traitement des demandes à l'échelle de cinq agences. C'est exactement la frontière entre un assistant et un agent.

Assistant IA ou agent IA : quelle est la différence ?

La différence tient en deux phrases. Un assistant IA travaille quand une personne le sollicite, et sa valeur dépend des questions qu'on lui pose. Un agent IA est déclenché par le flux de travail lui-même, et sa valeur dépend des règles métier qu'on lui a données.

Détaillons. Un assistant IA répond quand on le sollicite. Il aide la personne qui lui parle : recherche, rédaction, synthèse, préparation. Sa valeur dépend de la qualité des demandes qu'on lui fait. OpenClaw est dans cette famille : un copilote multi-canal avec de la mémoire, au service d'une personne ou d'une petite équipe.

Un agent IA prend en charge un processus. Il est déclenché par le flux lui-même : un email qui arrive, un formulaire rempli, une échéance qui approche. Il lit le contexte, applique des règles métier, exécute ce qui est cadré et fait valider ce qui est sensible. Hermes est dans cette famille : un agent connecté aux outils du cabinet, qui travaille, que quelqu'un le regarde ou non.

Voici la grille que j'utilise avec les dirigeants pour situer leur besoin :

Question Assistant IA (type OpenClaw) Agent IA (type Hermes)
Qui déclenche le travail ? Vous, en posant une question Le flux : email entrant, formulaire, échéance
Pour qui travaille-t-il ? La personne qui le sollicite Le processus, donc toute l'équipe
Que se passe-t-il si personne ne demande ? Rien Le travail avance quand même
Comment progresse-t-il ? Il apprend vos préférences On affine ses règles métier au fil des cas réels
Traçabilité Historique de conversation Journal d'actions : lu, préparé, envoyé, remonté
Bon premier usage Brief, recherche, rédaction, synthèse Traitement des demandes entrantes récurrentes

Cette distinction n'est pas académique. Elle détermine le budget, le cadrage, les garde-fous et le retour sur investissement. Beaucoup de PME achètent un "agent IA" alors qu'elles ont besoin d'un assistant. Ce cabinet avait le problème inverse : il utilisait un assistant là où il fallait un agent.

Ce que la migration vers Hermes a changé concrètement

La migration n'a pas commencé par la technique. Elle a commencé par une semaine de travail sur le protocole réel du cabinet.

Pour chaque type de demande entrante, il a fallu écrire noir sur blanc ce qui se passait vraiment : qui traite les attestations, quelles vérifications avant d'envoyer un relevé d'information, quelles pièces demander selon le type de sinistre, quelles demandes exigent un échange avec le client, ce qui varie d'une agence à l'autre et ce qui ne doit jamais varier.

Ce travail ressemble beaucoup à ce que je décrivais dans mon retour terrain sur l'agent Hermes d'un propriétaire multi-logements Airbnb : le coeur du projet n'est pas le modèle d'IA, c'est la mise en règles lisibles de ce que le métier sait déjà faire.

Détail intéressant : les mois passés avec OpenClaw n'ont pas été perdus, au contraire. L'historique des demandes du dirigeant à son assistant était une radiographie de ce qui manquait au cabinet. Les brouillons qu'il demandait le plus souvent sont devenus les premiers modèles de réponse d'Hermes. La mémoire accumulée par l'assistant a servi de base au cadrage. L'assistant a joué, sans qu'on l'ait prévu, le rôle de révélateur des processus.

Une fois le protocole posé, Hermes a été branché sur les canaux du cabinet, pas sur ceux du dirigeant : les boîtes email des cinq agences, l'agenda, et les outils métier utilisés pour les contrats et les sinistres. C'est le même principe d'automatisation de workflows que dans mes autres projets : l'IA comprend la demande et choisit l'action, le workflow exécute proprement dans les outils.

Aujourd'hui, quand une demande arrive dans une agence, Hermes l'identifie : client ou prospect, type de demande, contrat concerné, agence, urgence. Il rassemble le contexte depuis les outils autorisés. Puis il la classe selon trois niveaux.

Premier niveau, il traite seul : accusé de réception personnalisé, demande de pièces manquantes avec la liste exacte selon le type de dossier, réponse aux questions dont la réponse est cadrée et sans engagement.

Deuxième niveau, il prépare et un humain valide : brouillon de réponse à une déclaration de sinistre, dossier de devis pré-rempli pour le conseiller, relance d'un client dont le dossier est incomplet depuis plusieurs jours.

Troisième niveau, il remonte sans agir : réclamation, demande de résiliation, question qui touche au devoir de conseil, incohérence dans un dossier, client visiblement mécontent. Dans ces cas, Hermes regroupe les faits et transmet le dossier au bon collaborateur, avec le contexte déjà préparé.

Cette séparation en trois niveaux, je l'applique sur tous mes projets d'agents. J'ai détaillé pourquoi dans mon guide sur la validation humaine des agents IA en production : en secteur régulé, un agent sans garde-fous lisibles est un risque, pas un progrès.

Ce que le dirigeant voit, lui

Pour le dirigeant, le changement le plus visible n'est pas dans les agences. Il est dans son pilotage.

Chaque soir, il reçoit une synthèse par agence : les demandes traitées, celles en attente de validation, les dossiers qui traînent, les cas remontés et pourquoi. Là où son assistant lui répondait quand il posait une question, l'agent lui montre ce qu'il n'aurait pas pensé à demander.

C'est le point qui répond à sa remarque de départ. Hermes s'améliore dans le temps, non pas parce que le modèle apprend tout seul, mais parce que chaque cas remonté est une occasion d'affiner une règle. Une demande mal classée devient une règle de classement corrigée. Une réponse validée avec modification devient un meilleur modèle de réponse. Au bout de quelques semaines, la part des demandes traitées ou préparées correctement du premier coup augmente, et cela se voit dans la synthèse du soir.

Un assistant plafonne quand il vous connaît. Un agent progresse tant que vous affinez ses règles. C'est toute la différence de trajectoire.

Et OpenClaw dans tout ça ? Le dirigeant l'utilise toujours. Son brief du matin, ses brouillons personnels, ses recherches, ses synthèses avant un rendez-vous important. Les deux systèmes coexistent très bien, parce qu'ils ne font pas le même travail : l'assistant l'aide lui, l'agent fait tourner le traitement des demandes. La migration n'a pas remplacé un outil par un autre. Elle a mis chaque outil à sa place.

Cinq signes qu'il vous faut un agent IA plutôt qu'un assistant

Si vous utilisez déjà un assistant IA dans votre PME, cinq signaux indiquent que vous avez atteint la même frontière que ce cabinet.

Vous demandez chaque semaine les mêmes choses à votre assistant. Si vos demandes sont devenues répétitives et prévisibles, c'est que le besoin est un processus, pas une conversation.

La valeur dépend de qui pose la question. Si l'IA est très utile pour vous mais quasi inutilisée par vos équipes, le problème n'est pas l'adoption. C'est que l'outil est un copilote personnel, pas un système d'équipe.

Le volume de demandes entrantes croît plus vite que votre capacité à les traiter. Un assistant ne résorbe pas un flux : il aide celui qui le traite. Si le flux déborde, il faut un système déclenché par le flux lui-même.

Vous avez besoin de traçabilité. Dès qu'une réponse à un client peut engager votre responsabilité, l'historique d'une conversation ne suffit plus. Il faut un journal d'actions : ce qui a été lu, préparé, envoyé, validé, refusé.

Vous n'arrivez pas à dire ce que l'IA a fait pour l'entreprise ce mois-ci. Avec un assistant, cette question est presque sans réponse, car sa valeur est diluée dans le travail de chacun. Avec un agent, elle se lit dans les compteurs : demandes traitées, dossiers préparés, cas remontés.

Aucun de ces signaux ne veut dire que votre assistant était un mauvais choix. Dans ce cas précis, commencer par OpenClaw était même la bonne décision : coût maîtrisé, mise en route rapide, et des mois d'usage réel qui ont servi de cahier des charges pour l'agent. Le piège serait plutôt de rester bloqué au stade assistant en attendant qu'il se transforme tout seul en agent. Cela n'arrivera pas, quelle que soit la qualité du modèle.

Par quoi commencer si vous êtes dans ce cas

La bonne nouvelle, c'est que la transition n'est pas une refonte. Elle se fait flux par flux.

Je recommande de commencer par un seul processus, choisi avec trois critères : il revient toutes les semaines, il oblige à recouper plusieurs informations, et il coûte cher quand il est mal traité ou oublié. Dans ce cabinet, c'était le traitement des demandes entrantes par email. Dans une autre PME, ce sera les devis, les relances ou le suivi des dossiers incomplets.

Ensuite, écrire les règles réelles de ce processus, avec les équipes qui le font aujourd'hui. Pas un règlement parfait : juste assez de structure pour que l'agent sache quoi faire dans les cas courants et quoi remonter dans les autres.

Puis tester sur des cas réels, en commençant avec un niveau d'autonomie faible : l'agent prépare tout, les humains valident tout. L'autonomie s'élargit ensuite, règle par règle, là où l'agent a prouvé sa fiabilité.

Si vous voulez d'abord clarifier ce dont votre entreprise a besoin, assistant ou agent, c'est typiquement le genre de question qu'on tranche en quelques échanges dans une mission de conseil IA. Et si vous partez de zéro, sans assistant existant, la page agents IA décrit ma façon de cadrer ces projets.

Conclusion

Ce cabinet d'assurance n'a pas changé d'outil parce que le premier était décevant. Il a changé d'outil parce que son usage avait dépassé ce qu'un assistant peut faire.

Un assistant IA aide une personne à mieux travailler. Un agent IA fait avancer un processus pour toute une équipe. Le premier plafonne une fois qu'il vous connaît. Le second progresse tant qu'on affine ses règles sur des cas réels. Entre les deux, il n'y a pas une mise à jour logicielle, mais un vrai travail de cadrage : écrire les règles, choisir les niveaux d'autonomie, poser les garde-fous.

Si votre assistant IA vous donne cette impression de plafond, ou si vos demandes entrantes débordent vos équipes, les pages OpenClaw et Hermes décrivent les deux systèmes et leurs terrains respectifs. Et si vous hésitez entre les deux, c'est probablement la meilleure question à me poser.

Existe aussi : Lire en anglais