Transformer une web app en outil pour agents IA sans toucher au code

Le 9 juillet 2026, un Show HN repéré sous le pseudonyme pancomplex a mis en avant un problème que beaucoup d'équipes qui construisent des agents IA connaissent bien : l'application que vous voulez piloter n'a ni API publique, ni serveur MCP, et son code source vous est fermé. Le projet propose une réponse directe : un agent qui observe une web app authentifiée pendant son usage normal, capture ses appels réseau internes, et les transforme automatiquement en outils utilisables par n'importe quel agent IA.

En quelques heures sur Hacker News, le post a rassemblé 17 points et 5 commentaires, avec des démonstrations sur des produits que vous connaissez sûrement : Jira, Spotify, Hacker News lui-même, et Airbnb ajouté en réponse à une demande de la communauté. On décortique la mécanique, ses limites assumées, et ce qu'elle change concrètement si vous développez ou pilotez des outils internes sans API exploitable.

Le problème que ça résout : l'absence quasi générale de MCP

Le Model Context Protocol promet un monde où chaque application expose une interface propre et documentée pour les agents IA. Dans les faits, même les logiciels les plus modernes cachent, selon les auteurs du projet, une toile d'araignée d'API confuses et de services internes jamais pensés pour être consommés par une machine. Pire : chaque application sécurise ses points d'accès à sa manière, avec un mélange de JWT, de cookies de session, ou des deux, sans standard commun.

Face à ce constat, l'alternative la plus utilisée aujourd'hui reste l'agent de type computer-use : un navigateur piloté par IA qui clique, tape et navigue comme un humain. Les auteurs du projet la jugent trop lente, trop fragile face au moindre changement d'interface, et beaucoup trop coûteuse en tokens pour un usage répété.

Comment fonctionne la « recipe » : anatomie d'un outil auto-généré

Le cœur du projet tient dans un concept que ses créateurs appellent la recipe. Concrètement, quand l'agent navigue dans une application authentifiée, il observe les appels que l'app fait vers ses propres API et en extrait cinq éléments :

• L'endpoint et la méthode HTTP appelés par l'application.
• La méthode d'authentification utilisée, avec la façon de récupérer ou de rafraîchir les jetons ou les cookies.
• Le schéma de la réponse renvoyée par l'API.
• Le schéma des données d'entrée pour les requêtes POST ou PUT.
• Une description en langage naturel de ce que fait l'outil.

Assemblées, ces recipes deviennent des outils réutilisables par un LLM, sans qu'une seule ligne de code de l'application cible n'ait été écrite ou modifiée. Et si l'API change côté application, l'agent le détecte et met à jour la recipe correspondante tout seul. C'est, dans les mots de ses créateurs, l'équivalent d'un serveur MCP généré automatiquement et qui s'actualise en continu.

Le workflow concret, de l'entraînement à l'action

Le processus se résume en trois étapes. L'agent s'entraîne d'abord sur l'application et construit sa bibliothèque de recipes. L'éditeur de l'application active ensuite les outils découverts depuis un tableau de bord. L'agent peut enfin agir pour le compte de l'utilisateur directement dans l'application.

L'exemple donné dans le post illustre bien l'intérêt : demander à l'agent d'« inviter mon collègue dans mon espace de travail » déclenche un appel sécurisé et direct vers le véritable endpoint d'invitation de l'application, sans passer par un relais ou un proxy tiers. Les démonstrations publiées (Jira, Spotify, Hacker News, Airbnb) montrent des actions réalisées plus vite qu'en cliquant manuellement dans l'interface.

Les limites assumées : GraphQL, sécurité et cas bespoke

L'auteur du projet est transparent sur les difficultés rencontrées. Chaque application est, selon ses mots, intrinsèquement différente malgré la multitude de standards qui existent sur le papier. Il cite un exemple précis : GraphQL a été de loin l'API la plus compliquée à faire rentrer dans le format recipe, la faute à des schémas trop souples pour être généralisés simplement.

Un commentaire sous le post, signé robszumski, pointe une question légitime : la démo fonctionne bien sur des outils SaaS relativement standards, mais qu'en est-il d'une application bien plus spécifique, comme un compte bancaire, une billetterie de cinéma ou un compte constructeur automobile ? La réponse de pancomplex a été d'ajouter une démo Airbnb, mais la question de fond reste ouverte pour les cas les plus atypiques ou les plus sensibles.

Ce que ça implique pour un dev ou une PME française

Pour une équipe technique qui gère des outils internes sans budget pour construire et maintenir un serveur MCP dédié (un CRM maison, un outil de ticketing interne, un back-office e-commerce), l'approche a un attrait évident : brancher un agent IA sans toucher au code existant, sur des applications parfois vieilles de plusieurs années.

Mais elle soulève aussi une question de confiance qu'il faut trancher avant de connecter quoi que ce soit à des données sensibles. Laisser un agent tiers observer et rejouer vos flux d'authentification, y compris les jetons JWT et les cookies de session, revient à lui confier une capacité d'action directe sur vos systèmes. Pour un outil interne à faible enjeu, c'est un gain de temps réel. Pour une application qui touche à des données clients, des paiements ou des données personnelles au sens RGPD, la question de l'hébergement de ces recipes, de leur audit et de leur révocation mérite d'être posée avant tout déploiement.

Notre lecture chez CZSyn

Ce projet illustre bien un écart que nous constatons régulièrement chez nos clients : la promesse d'un web entièrement pensé pour les agents IA se heurte à la réalité d'applications, parfois critiques pour l'activité, qui n'ont jamais été conçues pour être consommées par une machine. Rétro-ingénierer les appels réseau pour combler ce vide est une idée maligne, et le concept de recipe auto-actualisée est élégant sur le papier.

Notre position reste néanmoins prudente sur le déploiement en production sur des applications sensibles. Pour des outils internes à faible risque, l'approche mérite d'être testée. Pour tout ce qui touche à des données clients ou à des flux de paiement, nous continuons de recommander la construction d'une intégration maîtrisée (un serveur MCP ou une API dédiée avec un périmètre d'action explicitement défini), plutôt que de confier à un tiers la capture et le rejeu de vos jetons d'authentification. C'est le type d'arbitrage que nous aidons nos clients à trancher lors de nos audits techniques.

Sources primaires

• Hacker News, « Show HN: Reverse-engineering web apps into agent tools », 9 juillet 2026.
• Démonstrations officielles du projet, demo.frigade.com/hn (Jira, Spotify, Hacker News, démo complète).
• Démonstration Airbnb, demo.frigade.com.