KM4BI KM4BI

Un agent Cursor a effacé une base de données en 9 secondes. L’analytics des agents l’aurait vu venir.

L’incident Pocket OS montre pourquoi les produits agentiques doivent mesurer les runs, les corrections et l’acceptation, pas seulement les sessions ou les…

L’incident Pocket OS sert ici de signal d’alarme: si un agent peut supprimer une base de production et ses sauvegardes en quelques secondes, le problème n’est pas seulement l’exécution technique. C’est aussi l’absence d’une lecture produit du run d’agent, avant que le système n’atteigne le moment dangereux.

Ce qui change avec les agents

Les analytics classiques savent mesurer les sessions, les clics, les messages et les conversions. Dans un produit agentique, l’action décisive peut être une instruction, un appel d’outil, une demande d’approbation, un retry, un blocage de permission ou une correction humaine. Le comportement produit devient du travail délégué.

Les journaux de chat restent utiles, mais ils ne suffisent pas. Ils ne montrent pas toujours quels outils étaient disponibles, lesquels ont été appelés, ce qui a échoué, ce que l’utilisateur a corrigé ou si la sortie a été acceptée.

Le run devient l’unité produit

Le bon niveau d’observation est le run d’agent: quelle tâche était visée, quel workflow était engagé, quels outils ont été utilisés, où les permissions ont bloqué, si la tâche a été complétée et si l’utilisateur a fait confiance au résultat.

C’est différent de l’observabilité ingénierie. Une trace peut dire qu’une approbation a été demandée ou qu’un appel a coûté 30 centimes. L’analytics produit doit dire si cette approbation a renforcé la sécurité ou simplement créé de la friction, et si le coût a produit de la valeur.

Les corrections sont des signaux produit

Quand un utilisateur interrompt, modifie une sortie, refuse une approbation, clarifie une consigne ou rouvre une tâche, il étiquette implicitement le run. Ces signaux peuvent révéler du contexte manquant, une action jugée risquée, une sortie non fiable ou un workflow mal conçu.

Trois événements de départ suffisent pour commencer: le début du run, la complétion de la tâche et les moments où l’utilisateur façonne le run en cours. Reliés au même identifiant, ils permettent de lire les taux de complétion, d’acceptation et de correction par workflow.

À retenir

Un agent peut produire beaucoup d’activité et pourtant livrer de mauvais résultats. Pour éviter les surprises de type suppression de base de données, les équipes doivent voir l’historique des comportements agentiques, les runs défectueux et les signaux faibles bien avant le point de rupture.

Source