MitigéEXP-06iones lab
Jarvis & OpenClaw : des agents autonomes sur nos tickets de support
La questionUn agent IA peut-il prendre en charge seul le premier niveau de nos tickets de maintenance sans dégrader la qualité de service ?
Verdict
Le triage et la qualification sont fiables et rapides. La résolution autonome reste trop imprévisible : on garde l’agent comme copilote, jamais comme décideur.
DécisionAdopté pour le triage avec validation humaine. Résolution autonome écartée pour l’instant.
- Statut
- Mitigé
- Durée
- 6 semaines
- Équipe
- 2 développeurs, 1 lead run, 1 chef de projet
- Stack
- OpenClaw
- Jarvis
- MCP
- Redmine
- Claude
- Postgres
91 %tickets correctement qualifiéscatégorie + priorité, sur 412 tickets
34 %résolus sans interventionuniquement sur les cas simples
6,8 slatence médiane par ticketde la lecture à la proposition
7actions risquées bloquéespar les garde-fous, sur 6 semaines
Contexte
Nos équipes run reçoivent chaque semaine plusieurs centaines de tickets : bugs, demandes d’évolution mineures, questions d’usage, incidents. Le premier niveau consiste à lire, qualifier, prioriser et router ces tickets avant qu’un développeur ne s’en occupe. C’est un travail répétitif, mais qui exige de comprendre le contexte du projet et l’historique du client.
Nous avions déjà un assistant interne, Jarvis, capable de répondre à des questions sur nos projets à partir de notre documentation. La question du lab était de passer d’un assistant qui répond à un agent qui agit : lire le ticket, consulter le dépôt et la base, proposer une qualification, et, pour les cas simples, appliquer la correction.
Ce qu’on a testé
Nous avons monté deux configurations en parallèle sur une copie de notre instance Redmine, alimentée par de vrais tickets anonymisés de trois projets de maintenance.
- Jarvis en mode agent : un seul modèle, accès en lecture aux tickets, au code et à la doc via des serveurs MCP, aucune action d’écriture.
- OpenClaw en orchestration : un agent planificateur qui délègue à des sous-agents spécialisés (lecture du code, reproduction du bug, rédaction de la réponse), avec droits d’écriture sur une branche dédiée.
- Un jeu de garde-fous communs : liste blanche d’actions, budget de tokens par ticket, blocage de toute commande touchant à la base de production, validation humaine obligatoire avant tout commentaire client.
Chaque ticket traité par un agent était ensuite relu par un développeur qui notait la qualification proposée (catégorie, priorité, composant) et, le cas échéant, la correction. Nous avons traité 412 tickets sur six semaines, dont 138 avec correction tentée.
Résultats
91 %
qualification correcte (catégorie et priorité)
34 %
corrections acceptées sans modification
22 %
corrections acceptées après retouche
0,04 €
coût moyen par ticket trié
Sur le triage, le résultat dépasse nos attentes. Les deux configurations qualifient correctement plus de neuf tickets sur dix, et la priorité proposée est celle que le lead aurait choisie dans 87 % des cas. Le temps de première réponse interne passe de plusieurs heures à quelques secondes, ce qui permet de router un incident critique avant même qu’un humain ne l’ait lu.
Sur la résolution, c’est une autre histoire. OpenClaw résout proprement un tiers des tickets simples (texte à corriger, règle de validation, configuration). Mais sur les 138 tentatives, 18 corrections étaient techniquement fonctionnelles et pourtant fausses : l’agent corrigeait le symptôme sans comprendre la règle métier, ou modifiait un comportement volontaire. Ces cas sont les plus dangereux, parce qu’ils passent les tests.
- Latence médiane de 6,8 s pour un triage, mais jusqu’à 4 minutes pour une tentative de correction avec reproduction du bug.
- Les garde-fous ont bloqué 7 actions en six semaines, dont deux suppressions de données de test que l’agent considérait comme « obsolètes ».
- OpenClaw consomme en moyenne 11 fois plus de tokens que Jarvis pour un gain de qualification marginal (+2 points).
- Les agents sont excellents pour rédiger le résumé technique d’un ticket mal décrit par le client : gain de temps unanime chez les développeurs.
“L’agent m’a fait gagner du temps sur tous les tickets, sauf ceux où il m’a fait perdre confiance. Et ceux-là, on ne les repère pas au premier coup d’œil.”
Ce qu’on en conclut
L’autonomie n’est pas un interrupteur, c’est un curseur. Sur la partie lecture, compréhension et qualification, l’agent est déjà meilleur qu’un humain pressé, et nous n’avons aucune raison de nous en priver. Sur la partie décision et modification, la fiabilité n’est pas suffisante pour un client qui nous paie justement pour ne pas avoir de surprises.
L’orchestration multi-agents d’OpenClaw est séduisante sur le papier, mais son coût et sa complexité ne sont pas justifiés pour du triage. Elle devient intéressante uniquement quand la tâche demande vraiment plusieurs étapes indépendantes (reproduire, corriger, tester). Nous la gardons pour ces cas, en mode branche isolée et revue obligatoire.
Et maintenant
- Jarvis en triage est déployé sur nos projets de run internes depuis septembre, avec validation humaine avant tout commentaire visible par le client.
- Les corrections proposées par OpenClaw arrivent sous forme de pull request, jamais fusionnées automatiquement.
- Prochaine itération : mesurer si un agent entraîné sur l’historique complet d’un projet réduit les corrections « fonctionnelles mais fausses ».