retour d'XP · 20 mai 2026 · 6 min de lecture
Mon retour d'expérience sur OpenClaw
Plusieurs semaines de test d'un agent IA laissé en autonomie sur une tâche à enjeu commercial. Ce qui marche, ce qui dérape, et la grille de lecture que j'utilise désormais avant de confier quoi que ce soit à un agent en production.
Pendant plusieurs semaines, j'ai laissé un agent IA tourner en autonomie sur une tâche à enjeu commercial réel, avec un accès limité à un sous-ensemble de mes données pro. L'objectif n'était pas de produire une démo de salon : c'était de voir ce que ce type d'agent fait vraiment quand on le pose dans un workflow métier, au-delà du discours marketing des éditeurs.
Cette note est le bilan honnête de ce test. Ce qui m'a impressionné, ce qui m'a inquiété, et la grille de lecture qui en sort pour quiconque envisage d'en faire autant.
Le contexte du test
Pas un cas synthétique. Une vraie mission, avec un vrai enjeu commercial, avec accès à de la vraie donnée pro — mais via un sous-ensemble cloisonné, jamais l'intégralité. L'idée était de pousser l'agent suffisamment loin pour que les effets de bord sortent du laboratoire et apparaissent en conditions réelles : fatigue de l'opérateur, dérives de comportement, coûts qui s'accumulent, micro-bugs récurrents.
Les trois gardes-fous non négociables
Avant même de lancer l'agent, j'ai posé trois règles que je considère désormais comme un strict minimum. Si l'un des trois n'est pas tenable sur votre cas d'usage, n'allez pas plus loin.
1. Isolation système
L'agent s'exécute dans un environnement cloisonné. Jamais sur la machine personnelle. Jamais sur le serveur de production. S'il dérape — et il dérapera, au moins une fois — il dérape dans un bac à sable dont les dégâts sont contenus.
2. Cloisonnement des données
Aucun accès direct aux sources sensibles. J'ai mis en place une couche de filtrage en amont qui ne transmet à l'agent que le strict nécessaire à sa mission. Pas la boîte mail entière, pas la base CRM complète, pas les factures, pas les mots de passe. Juste les éléments dont la tâche a besoin, et rien d'autre. Cette couche n'est pas une option : c'est l'épine dorsale du dispositif.
3. Validation humaine systématique
Chaque action sortante passe par une approbation explicite avant exécution. Idéalement via un canal mobile — Telegram, une app dédiée, peu importe — pour permettre le pilotage en mobilité. On garde l'humain dans la boucle, mais sans le clouer à son bureau.
Les risques identifiés (sérieux)
Une fois le dispositif lancé, trois risques se sont matérialisés ou ont failli se matérialiser. Ils méritent d'être posés noir sur blanc.
Accès potentiel à toute la donnée sensible si la compartimentation est mal faite. Mails, factures, mots de passe, alertes de paiement, conversations clients — tout ce qui transite par les mêmes outils que votre agent devient accessible à votre agent si vous n'avez pas séparé proprement. Un seul mauvais réglage et l'isolation est trouée.
Hallucinations à valeur engageante. Un tarif inventé, un livrable promis, un délai annoncé : si l'agent l'écrit dans un échange avec un prospect ou un client, vous êtes juridiquement engagé. La nature probabiliste du modèle, qui est un atout sur de la synthèse, devient un risque majeur dès qu'il y a contrat à la clé. Ce risque-là, on ne le mitige pas avec un prompt système plus long — on le mitige avec une validation humaine sur tout ce qui sort.
Risque de réputation. Un dérapage public d'un agent mal encadré peut détruire en quelques minutes ce qui a pris des années à construire. C'est asymétrique : la valeur du gain potentiel est bornée par le temps économisé, la valeur de la perte ne l'est pas.
Les points forts observés
Le test n'aurait pas duré plusieurs semaines si rien ne fonctionnait. Trois choses m'ont vraiment marqué.
Auto-apprentissage en continu. L'agent édite sa propre mémoire et ses propres compétences à chaque feedback. À la longue, il se comporte comme un collaborateur qui n'oublie jamais une préférence, une correction, une exception métier. C'est, à mon sens, le vrai différenciateur de cette génération d'outils par rapport aux automatisations classiques. On ne réécrit pas une règle — on lui dit une fois, il l'intègre.
Mise en place très rapide. Une architecture complète, gardes-fous compris, peut être opérationnelle en quelques heures. Ce qui demandait six mois de projet IT il y a trois ans tient désormais dans une après-midi de configuration. C'est à la fois un atout (on peut tester vite) et un piège (on peut déployer en production sans avoir vraiment réfléchi).
Ergonomie de pilotage. La validation et la correction depuis le mobile changent complètement l'expérience. On peut littéralement manager l'agent en transit, entre deux rendez-vous, sans rester scotché à un écran. Cette portabilité du contrôle, je ne m'attendais pas à ce qu'elle pèse autant dans l'usage quotidien.
Les points de friction (qui ne se voient pas dans les démos)
Sur la durée, trois frictions sont remontées. Aucune n'est rédhibitoire prise isolément, mais cumulées elles expliquent pourquoi la majorité des projets d'agents IA s'éteignent en silence après quelques mois.
Coût en tokens élevé et opaque. À chaque interaction, l'agent recharge tout son contexte : prompt système, outils disponibles, instructions, mémoire. Sans une architecture pensée pour limiter ça (cache de prompt, segmentation des contextes, choix du bon modèle pour la bonne sous-tâche), la facture grimpe très vite. Et le risque réel, c'est que le coût finisse par dépasser celui d'un humain pour la même tâche. Si c'est le cas, le projet n'a aucune raison d'exister.
Essoufflement de l'opérateur sur la durée. La phase d'excitation dure une semaine, à la louche. Ensuite arrivent les petits bugs récurrents — formats non respectés entre couches d'IA, erreurs d'intégration, validations qui s'enchaînent au mauvais moment — et le désintérêt progressif. Si le ROI n'est pas évident, l'opérateur finit par valider sans lire, ou par couper le système. Personne ne le dit explicitement : il s'éteint juste, faute d'engagement.
Plafond psychologique du full-auto. Difficile, voire impossible, de couper l'humain de la boucle quand l'enjeu est sérieux. On reste donc bloqué dans un régime assisté plutôt que vraiment autonome. Les promesses marketing de l'agent qui tourne tout seul se heurtent à une réalité simple : on ne signe pas un devis client sans avoir relu. Et c'est sain.
Conclusion stratégique
La techno est bluffante. Elle est accessible. Mais elle ne résout pas mécaniquement les problèmes métier. Si la tâche déléguée à l'agent reste un irritant même une fois automatisée, le projet finit par mourir — pas pour des raisons techniques, mais parce que personne ne va s'astreindre à la maintenir.
Voici la grille de lecture que j'utilise désormais pour évaluer une mission candidate à ce type d'agent :
- Le gain doit justifier les tokens consommés. Sinon l'humain coûte moins cher. Et il dort la nuit sans qu'on s'inquiète de la facture du lendemain matin.
- Le pouvoir confié doit être strictement encadré et réversible à tout moment. Pas d'accès en écriture sans validation. Pas d'action engageante sans revue. Pas de droit que vous ne pourriez pas couper en trente secondes.
- L'opérateur doit rester intéressé par la boucle de validation sur la durée. Si vous savez d'avance que vous arrêterez de lire les notifications au bout de trois semaines, ne lancez pas le projet.
- Bon candidat : tâche à fort volume, faible enjeu unitaire, peu de risque réputationnel. Tri, classification, première synthèse, brouillon à relire.
- Mauvais candidat : tâche à enjeu contractuel, juridique, ou de réputation. Sur celles-là, garder l'humain dans la boucle n'est pas un échec d'automatisation — c'est le bon design.
OpenClaw m'a convaincu d'une chose : un agent IA en autonomie n'est pas un substitut à une décision d'organisation. C'est un amplificateur. Si l'organisation est claire, il l'accélère. Si elle est floue, il en révèle les angles morts — souvent au mauvais moment et devant le mauvais public.
Questions fréquentes
- Quels sont les trois gardes-fous minimums avant de lancer un agent IA en production ?
- Isolation système (environnement cloisonné, jamais sur la machine perso ou le serveur de prod), cloisonnement des données (accès filtré au strict nécessaire, pas d'accès direct aux sources sensibles), et validation humaine systématique sur chaque action sortante. Si l'un des trois n'est pas tenable, il ne faut pas y aller.
- Comment éviter que l'agent IA accède à des données sensibles ?
- Mettre en place une couche de filtrage en amont qui ne transmet à l'agent que le strict nécessaire à sa mission. Pas la boîte mail entière, pas la base CRM complète, pas les mots de passe — juste les éléments dont la tâche a besoin. Cette compartimentation n'est pas optionnelle.
- Quel est le risque majeur si l'agent invente des informations dans un échange client ?
- Un tarif inventé, un livrable promis, un délai annoncé : si l'agent l'écrit à un prospect ou un client, vous êtes juridiquement engagé. Ce risque se mitige uniquement par une validation humaine sur tout ce qui sort, pas par un prompt système plus long.
- Pourquoi les projets d'agents IA s'éteignent après quelques mois ?
- Trois frictions cumulées : coût en tokens qui grimpe vite sans architecture optimisée, essoufflement de l'opérateur après la phase d'excitation initiale (une semaine environ) face aux petits bugs récurrents, et l'impossibilité psychologique de vraiment couper l'humain de la boucle sur les enjeux sérieux.
- À quelles tâches confier un agent IA et lesquelles éviter ?
- Bon candidat : tâche à fort volume, faible enjeu unitaire, peu de risque réputationnel (tri, classification, première synthèse, brouillon à relire). Mauvais candidat : tâche à enjeu contractuel, juridique, ou de réputation — garder l'humain dans la boucle n'est pas un échec, c'est le bon design.