Aller au contenu principal
InApp-Agent

Fonctionnalités

Un agent qui s'améliore grâce aux usages.

La Vigie regarde comment l'agent est réellement utilisé dans votre application — ce qui aboutit, ce qui bloque, ce qui revient — et transforme ces constats en améliorations vérifiées. C'est un retour d'usage permanent sur votre propre produit.

Ce que fait la Vigie

Chaque jour, hors des sessions de vos utilisateurs, la Vigie relit ce que l'agent a fait : les demandes reçues, les réponses données, les corrections apportées par les utilisateurs, les actions exécutées et leurs effets dans l'application. Elle rapproche ces signaux pour repérer les difficultés récurrentes et les besoins non couverts.

Chaque constat vient avec ses preuves — les échanges concernés, les actions en cause, les effets observés — et une hypothèse sur la cause : une consigne mal comprise, une information absente des sources, un droit trop restrictif, une fonction qui manque dans l'application elle-même.

Elle affiche aussi sa couverture : ce qui a été analysé, ce qui est en attente, ce qui n'a pas pu l'être. Un silence n'est jamais pris pour une satisfaction.

Ce qu’elle repère

Six familles de constats, chacune rattachée à des échanges et des actions précis.

  • Les questions qui reviennent

    La même demande formulée de dix façons par des utilisateurs différents signale une information à rendre accessible, ou un raccourci à créer.

  • Les tâches abandonnées

    Une demande commencée puis laissée au même endroit par plusieurs personnes désigne l'étape où l'agent perd l'utilisateur.

  • Les demandes réalisables refusées

    Un refus alors que la fonction existe et que le droit est ouvert est un défaut, pas une prudence. La Vigie les suit comme tels.

  • Les corrections répétées

    Quand les utilisateurs reprennent la même chose — une date, une formulation, une préférence non appliquée —, l'agent doit changer, pas eux.

  • Les sources manquantes ou mal exploitées

    Une réponse qui échoue faute d'un document, ou qui cite le mauvais, révèle un trou dans les sources ou un découpage à revoir.

  • Ce qui manque à votre application

    Certaines demandes ne peuvent pas être servies parce que la fonction n'existe pas. Pour un éditeur, c'est une feuille de route qui s'écrit à partir des usages réels.

Ce que vous voyez

La Vigie n'est pas un rapport mensuel : ses constats et ses améliorations sont visibles au fil de l'eau, à trois niveaux.

  • Pour vos utilisateurs

    Leur travail en cours, ce que l'agent a retenu pour eux, les tâches confiées et leur état.

  • Pour votre organisation

    Usage, résultats, coûts et qualité par équipe ; les constats ouverts, les améliorations retenues et leur effet mesuré.

  • Pour l’exploitation

    Couverture de l'analyse — volume éligible, analysé, en attente, non analysable —, incidents et versions. Pas de voyant vert quand le dénominateur est inconnu.

Trois garde-fous

  • Rien ne change sans votre validation

    Les améliorations sont des changements décidés, testés et activés avec votre accord. Une correction de mémoire autorisée peut être automatique ; un changement de comportement partagé est toujours versionné et réversible.

  • On observe des usages, pas des personnes

    L'analyse porte sur les difficultés d'usage et les résultats d'action, jamais sur l'évaluation des utilisateurs. Le périmètre des données analysées se définit avec vous.

  • Rien ne circule entre clients

    Un constat né chez un client ne transporte ni ses contenus ni ses données chez un autre. Ce qui se partage, c'est une correction de produit, versionnée et documentée.

Du constat à l'amélioration

Chaque étape produit quelque chose de constatable et reste reliée à la précédente : une amélioration peut toujours être ramenée au constat qui l'a motivée, et annulée si elle régresse.

  1. 01

    Observer

    Analyse quotidienne des échanges, demandes, corrections, actions et effets autorisés, selon une cadence et un budget que vous fixez.

  2. 02

    Constater, avec preuves

    Regrouper les signaux, écarter le bruit, ouvrir un constat sourcé et hiérarchisé. Certains constats concluent qu'aucune modification n'est souhaitable.

  3. 03

    Proposer une correction

    Selon la cause : une consigne ajustée, une source ajoutée ou redécoupée, un droit à ouvrir, une documentation complétée, une évolution d'outil — ou une fonction à ajouter à votre application.

  4. 04

    Tester

    La correction candidate passe par le vrai chemin d'exécution, avec le cas qui l'a motivée et des cas adverses. Ce qui ne tient pas la recette ne sort pas.

  5. 05

    Publier et mesurer

    Diffusion contrôlée, versionnée, avec retour arrière possible. L'effet est suivi sur les usages suivants ; une amélioration sans effet observable est réexaminée.

Aujourd'hui : le repérage et le tri des difficultés fonctionnent dans BANANA-CONTENT, en usage réel. La boucle complète — constat relié à la correction, à sa vérification et à la mesure de son effet — se met en place sur les parcours choisis avec vous pendant le pilote.