Integuru v0 : générer du code d'intégration à partir d'un fichier HAR

Le problème visé : agir sur une plateforme qui n'expose pas d'API

Beaucoup de services web n'offrent aucune interface documentée pour déclencher une action par programme. Le navigateur, lui, envoie déjà tout ce qu'il faut : une suite de requêtes HTTP vers des endpoints internes, avec des identifiants glissés dans les URL, les en-têtes ou le corps. Integuru v0 part de ce constat et vise un public précis : un développeur ou un intégrateur qui doit reproduire une action existante (télécharger une facture, récupérer un document) sans passer par l'interface graphique. Le README annonce la promesse sans détour : produire du code Python exécutable qui frappe les endpoints internes de la plateforme pour réaliser l'action demandée. Il ne s'agit donc pas d'un framework d'automatisation généraliste, mais d'un générateur de script dont l'entrée est une trace réseau et une phrase en langage naturel. Le dépôt porte la mention v0, et le README le dit explicitement : il conserve la première version publiée, l'approche d'origine, tandis que la version courante est hébergée ailleurs, sur integuru.com.

Du fichier HAR au graphe de dépendances : la mécanique décrite

Le déroulé est exposé étape par étape dans le README, avec l'exemple du téléchargement de factures de services publics. L'agent commence par repérer la requête qui réalise l'action voulue, par exemple une URL de la forme https://www.example.com/utility-bills?accountId=123&userId=456. Il isole ensuite les fragments dynamiques de cette URL, ici accountId et userId, et cherche les requêtes qui fournissent ces valeurs. Il crée alors des liens de dépendance vers ces requêtes, par exemple GET https://www.example.com/get_account_id et GET https://www.example.com/get_user_id, et rattache ces nœuds à la requête d'origine. Le processus se répète jusqu'à ce que la requête examinée ne dépende plus de rien d'autre que des cookies d'authentification. À ce moment, l'agent remonte le graphe depuis les nœuds sans arête sortante jusqu'au nœud maître, en convertissant chaque nœud en fonction exécutable. Cette remontée ascendante est le cœur de l'outil : on ne génère pas un script linéaire, on génère un ordre d'appel déduit de la structure des dépendances observées. Le paramètre max_steps, dont la valeur par défaut est 20, borne cette exploration, ce qui laisse deviner qu'un graphe profond ou bruité peut ne pas être résolu entièrement.

Mise en route : les commandes réelles du dépôt

L'installation passe par Poetry. Le README demande d'abord de définir la variable d'environnement OPENAI_API_KEY, puis d'exécuter poetry install, d'ouvrir un shell avec poetry shell, et d'enregistrer le noyau Jupyter via poetry run ipython kernel install --user --name=integuru. La capture se fait avec poetry run python create_har.py : un navigateur s'ouvre, vous vous connectez à la plateforme et vous effectuez l'action à reproduire, ce qui produit un fichier network_requests.har et un fichier cookies.json. L'agent s'exécute ensuite avec poetry run integuru --prompt "download utility bills" --model <gpt-4o|o3-mini|o1|o1-mini>. Les options documentées incluent --har-path (par défaut ./network_requests.har), --cookie-path (par défaut ./cookies.json), --max_steps, --input_variables au format clé valeur, et --generate-code pour produire l'intégration complète. Le README recommande gpt-4o pour la génération du graphe, car ce modèle prend en charge le function calling, et indique qu'Integuru bascule automatiquement sur o1-preview pour la génération de code si le compte OpenAI y donne accès. Les tests s'exécutent avec poetry run pytest, et le dépôt contient un workflow GitHub Actions dans .github/workflows/ci.yml, déclenché à chaque push et pull request sur main, qui installe Python 3.12, les dépendances Poetry et lance pytest.

Variables d'entrée : une fonctionnalité à moitié livrée

C'est le point où la documentation est la plus claire sur ses propres manques. La liste des fonctionnalités mentionne la prise en charge de variables d'entrée, par exemple le choix de l'année dans un téléchargement de document, puis ajoute immédiatement : actuellement pris en charge uniquement pour la génération du graphe, la prise en charge pour la génération de code étant annoncée comme à venir. Autrement dit, l'option --input_variables existe dans l'interface en ligne de commande, mais le code produit ne paramètre pas encore ces valeurs. Un lecteur qui construit un pipeline autour de cette option se retrouvera avec des scripts où l'année, l'identifiant de compte ou tout autre paramètre sont figés dans la trace capturée. C'est une limite de conception assumée à ce stade du projet, pas un détail d'implémentation. Elle conditionne directement l'usage : Integuru v0 génère un script pour une action et un contexte donnés, pas une bibliothèque réutilisable.

Cookies, 2FA et la fragilité d'un script fondé sur une session

Le README traite la question de l'authentification à deux facteurs en une remarque brève : le déroulé reste identique, il faut simplement terminer la procédure 2FA et récupérer les cookies ou jetons de session après coup, car ce sont eux qui seront utilisés. Cela signifie que les scripts générés transportent des artefacts de session. Un cookie qui expire, une rotation de jeton côté plateforme, et le code cesse de fonctionner sans que rien n'ait changé dans le graphe de requêtes. La politique de confidentialité du dépôt précise par ailleurs que les données collectées restent locales, dans network_requests.har et cookies.json, mais que l'outil s'appuie sur un LLM hébergé dans le cloud, les modèles GPT-4o et o1-preview d'OpenAI, et que ces modèles ne sont pas entraînés sur les données d'usage de l'outil. Il faut donc lire ces deux fichiers avant de les partager, puisqu'ils contiennent le trafic et les cookies en clair. Le fichier HAR, en particulier, peut inclure des en-têtes d'autorisation et des corps de requête que l'on n'a pas envie de voir circuler.

Ce que l'outil ne remplace pas : l'alternative par API officielle

La comparaison la plus utile n'est pas avec un autre agent, mais avec la voie classique : une API officielle documentée, ou un connecteur maintenu par l'éditeur de la plateforme. La différence d'approche est nette. Avec une API publique, le contrat est stable, versionné, et l'authentification repose sur une clé ou un jeton OAuth révocable. Avec Integuru v0, le contrat est une capture de trafic à un instant donné, et l'authentification repose sur des cookies de session. Le premier modèle survit à une refonte du front-end ; le second casse dès que la plateforme renomme un paramètre ou réorganise ses endpoints internes. L'approche par HAR a un avantage réel : elle fonctionne là où aucune API n'existe, et elle ne demande aucune coopération de la plateforme. Elle a un coût tout aussi réel : rien ne garantit que les endpoints internes restent stables, et le README ne promet aucune forme de surveillance ou de détection de rupture. Pour une action ponctuelle, l'échange est raisonnable. Pour un flux quotidien critique, il ne l'est pas.

Coût de maintenance et portée de la licence AGPL-3.0

Le dépôt est publié sous AGPL-3.0. Cette licence impose, lorsqu'une version modifiée est mise à disposition via un service en ligne, de rendre le code source correspondant accessible aux utilisateurs de ce service. Pour une équipe qui se contente d'exécuter l'outil en interne afin de produire des scripts, la question se pose différemment que pour quelqu'un qui intègre le code d'Integuru dans un produit exposé à des tiers. Je ne donne pas d'avis juridique ici : c'est un point à faire trancher par qui suit les licences dans votre organisation, en lisant le texte d'AGPL-3.0 plutôt qu'un résumé. Côté maintenance, le dépôt se présente lui-même comme une version figée : le README indique que l'équipe a continué à construire depuis, et que la version la plus récente se trouve sur integuru.com. Aucune release n'a été récupérée pour ce dépôt. Le coût d'adoption inclut donc une dépendance à un compte OpenAI et à des modèles nommés explicitement, dont la disponibilité et le comportement peuvent évoluer indépendamment du code du dépôt.

Conclusion éditoriale

Integuru v0 convient à un développeur qui doit automatiser une action ponctuelle sur une plateforme sans API publique et qui accepte de rejouer des cookies de session. Il ne convient pas aux équipes qui ont besoin d'un connecteur stable en production, puisque la documentation signale elle-même que les variables d'entrée ne sont pas encore prises en charge pour la génération de code. Avant d'adopter quoi que ce soit, vérifiez deux points dans le dépôt : la présence du fichier .github/workflows/ci.yml et le contenu de create_har.py, car c'est lui qui détermine quelles requêtes finissent dans network_requests.har.

Sources officielles

1. Integuru-AI/Integuru on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README