Contexte et problème

Les agents d'intelligence artificielle intégrés aux SaaS peinent souvent à fournir une assistance précise lorsqu'une tâche requiert une interaction directe avec l'interface utilisateur. Les solutions classiques reposent sur la récupération de documents (RAG) ou sur des recherches externes, ce qui introduit une latence importante et expose les réponses à l'obsolescence des articles d'aide. Le manque de corrélation entre la question de l'utilisateur et l'état réel de l'application entraîne des réponses génériques, peu exploitables.

Fonctionnement de l'Assist API

L'Assist API de Frigade comble ce fossé grâce à un appel d'outil unique, défini comme suit :

const frigade_guide_tool = {
  description: 'Call this tool to answer product questions or guide the user through a task.',
  parameters: {
    query: {
      type: 'string',
      description: 'What the user is asking or wants to do',
    },
  },
  run: ({ query }) => frigade.assist({ query }),
};

Lors de l'exécution, le service collecte le contexte visuel de l'utilisateur (capture d'écran, permissions, drapeaux de fonctionnalité) puis applique une logique à trois branches : (a) génération d'un guide visuel si la tâche est réalisable, (b) renvoi d'une description textuelle pour les problèmes conceptuels, ou (c) rejet si aucune solution n'est disponible. La décision repose sur un modèle entraîné à partir d'une carte interne de l'interface.

Cette carte est construite par un agent navigateur dédié. L'opérateur fournit un compte de test (souvent un environnement de staging) ; l'agent se connecte, parcourt chaque écran, identifie les composants UI, les actions possibles et les relations entre eux. Le résultat est un graphe de navigation enrichi de métadonnées (rôles d'utilisateur, flags, flux de travail). Le graphe est mis à jour périodiquement ou déclenché par des pipelines CI/CD, garantissant une synchronisation avec les évolutions du produit.

Intégration avec le SDK Vercel AI

Frigade propose un exemple d'intégration avec le Vercel AI SDK, démontré dans une vidéo de démonstration. L'appel d'outil s'insère dans le flux de génération de texte du SDK : le modèle LLM interroge frigade.assist dès qu'il détecte une requête liée à l'interface. Cette architecture minimise le nombre d'appels réseau (un seul appel d'outil) et évite le recours à des bases de connaissances externes, réduisant ainsi la latence moyenne de réponse de plusieurs secondes à quelques centaines de millisecondes, selon les mesures internes de Frigade.

Le modèle LLM conserve son rôle de raisonnement linguistique, tandis que l'Assist API fournit le raisonnement spatial et fonctionnel. Cette séparation des responsabilités améliore la robustesse du système : les erreurs de compréhension du texte sont isolées des erreurs de navigation UI.

Limites et perspectives

Le principal point de friction réside dans la nécessité d'un compte de test complet. Si les permissions du compte de test diffèrent de celles des utilisateurs finaux, le graphe UI peut ne pas refléter les restrictions réelles, entraînant des guides inapplicables. De plus, la génération de guides visuels dépend de la capacité du modèle à synthétiser des annotations graphiques à partir du graphe, ce qui peut être limité par la résolution des captures d'écran et par la complexité des flux multi‑étapes.

Sur le plan de la sécurité, le stockage du graphe UI expose potentiellement la structure interne du produit. Frigade recommande de chiffrer les artefacts et de restreindre l'accès aux environnements de staging uniquement. Enfin, l'approche reste dépendante de la stabilité du DOM : les changements dynamiques non détectés par l'agent peuvent créer des points morts dans le graphe, nécessitant une fréquence de rescannage adaptée aux cycles de déploiement.