Piloter un navigateur avec un LLM via des modèles d'utilisation informatique est environ 45 fois plus coûteux que d'appeler le même fournisseur via une API structurée. OUI.
Ce guide décortique ce chiffre de 45x, explique quand l'utilisation informatique reste pertinente et montre comment maintenir ces deux approches rapides et économiques lorsque vous construisez avec Apidog. Le cadre qui suit fonctionne pour OpenAI Operator, l'utilisation informatique d'Anthropic, l'utilisation de navigateurs, Skyvern et tout futur outil de la semaine livré avec une boucle de captures d'écran.
bouton
Si vous écrivez des API pour des agents IA, vous devriez également lire notre guide complémentaire sur comment écrire des fichiers agents.md ; les conventions qui y sont présentées font du chemin d'API structurée le choix par défaut évident pour vos appelants.
En bref
- L'utilisation informatique signifie qu'un LLM examine des captures d'écran et émet des clics, des frappes de clavier et des défilements ; les API structurées signifient que le LLM émet des appels d'outils JSON que votre backend exécute.
- Pour la même tâche, l'utilisation informatique consomme 30 à 50 fois plus de tokens car chaque étape envoie une nouvelle capture d'écran, plus les tentatives.
- Choisissez l'utilisation informatique uniquement lorsqu'aucune API n'existe, que l'API est soumise à des limites de débit, ou que le flux de travail est protégé par une authentification qui résiste au scriptage.
- Choisissez une API structurée pour tout le reste : paiements, recherche, mises à jour CRM, outils internes, tout ce que vous pouvez documenter avec OpenAPI.
- L'approche hybride est la réponse réaliste : les API structurées gèrent les 90 % qui ont des points de terminaison, l'utilisation informatique couvre la longue traîne.
- Téléchargez Apidog pour concevoir les schémas d'outils JSON, simuler les points de terminaison pendant que vous itérez, et rejouer l'ensemble du flux sans consommer de crédits d'agent.
Pourquoi l'écart de coût est si important
Le chiffre 45x n'est pas une référence astucieuse ; il découle de la manière dont chaque approche utilise les tokens.
Un appel d'API structurée envoie une invite avec la requête de l'utilisateur et un schéma d'outil, puis reçoit un objet JSON que l'exécution exécute. Aller-retour : quelques centaines de tokens en entrée, cinquante tokens en sortie, un saut réseau.
Une boucle d'utilisation informatique envoie la même invite plus une capture d'écran, reçoit une coordonnée de clic, l'exécute, prend une nouvelle capture d'écran, et répète. Une tâche typique de « réservation de vol » exécute 12 à 30 de ces boucles. Chaque capture d'écran coûte environ 1 500 tokens à une résolution typique. Multipliez.
La propre documentation d'Anthropic sur l'utilisation informatique indique ouvertement le coût des tokens de capture d'écran ; la surcharge réelle est encore plus élevée car les modèles relancent en cas de mauvais clics, défilent au-delà de l'élément correct et consomment des tours pour fermer les bannières de cookies. Le fil de discussion HN mentionné L'utilisation informatique est 45 fois plus chère que les API structurées a estimé la pénalité typique à 30 à 50x, ce qui correspond à ce que nous observons lorsque nous rejouons la même tâche via les deux chemins dans Apidog.
Quand le chemin d'API structurée est gagnant
Privilégiez les API structurées lorsque l'une des conditions suivantes est remplie.
Le fournisseur publie une spécification OpenAPI, un schéma GraphQL, ou même une simple page REST. Si une forme JSON existe, le LLM peut la remplir. La précision des appels d'outils sur GPT-5.5, Claude 4.5 et DeepSeek V4 dépasse 95 % sur les points de terminaison documentés ; le mode de défaillance est rare, peu coûteux à détecter et facile à relancer.
La tâche tient en un ou deux points de terminaison. « Créer un client Stripe », « mettre à jour le statut d'une transaction HubSpot », « publier un message Slack », « déclencher une nouvelle exécution CI » sont tous des appels uniques. Les acheminer via un navigateur est l'équivalent technique d'envoyer une carte postale depuis l'autre bout de la pièce.
Le flux de travail s'exécute sans surveillance. Les tâches cron, les webhooks et les workers de file d'attente ne peuvent pas superviser une boucle de capture d'écran qui décide de défiler dans la mauvaise direction. Les appels structurés sont déterministes au niveau de la couche réseau.
La latence est importante. Un appel structuré retourne en 200 à 800 millisecondes. Une boucle d'utilisation informatique avec 15 tours prend 30 à 90 secondes, plus longtemps lorsque des tentatives sont nécessaires.
Vous devez le tester avant de le déployer. Simuler un point de terminaison JSON prend quelques secondes dans Apidog. Simuler une boucle de captures d'écran de navigateur est un projet de recherche.
Quand l'utilisation informatique s'avère utile
Quelques cas favorisent encore la boucle de capture d'écran.
Portails fournisseurs hérités. Certains portails d'approvisionnement, de fret et d'avantages sociaux sont antérieurs à REST. Ils sont derrière des sessions ASP.NET sans interface machine. L'utilisation informatique remplace un script Selenium fragile qui se cassait chaque trimestre ; échanger un coût 45x contre zéro maintenance est parfois le bon choix.
Outils internes que vous ne pouvez pas modifier. Le CRM que votre client a payé en 2014, l'ERP hérité, le tableau de bord SharePoint. Si vous ne pouvez pas livrer une intégration et que l'équipe ne veut pas payer pour un iPaaS, la boucle de capture d'écran est une option réelle.
Tâches ponctuelles de l'opérateur. Un fondateur demandant à un agent de « rechercher ces 50 concurrents et de mettre les points saillants dans Notion » n'est pas un flux de travail qui nécessite un contrat structuré. L'utilisation informatique le gère une fois et disparaît.
Rétro-ingénierie protégée par les CGU. Ignorez cela. La plupart des requêtes de « scraper ce site avec l'utilisation informatique » se situent du mauvais côté des conditions du fournisseur ; le coût est le moindre de vos problèmes.
Un cadre de décision simple
Passez la requête à travers ces quatre vérifications avant de recourir à l'utilisation informatique.
| Vérification | Si oui | Si non |
|---|---|---|
| Une API documentée existe-t-elle ? | Utilisez l'API. | Continuez. |
| Pouvez-vous livrer un adaptateur léger côté serveur qui encapsule un point de terminaison privé ? | Construisez l'adaptateur, exposez-le en JSON. | Continuez. |
| La tâche est-elle ponctuelle ou à faible volume (<100 exécutions/jour) ? | L'utilisation informatique est acceptable. | Continuez. |
| Êtes-vous prêt à payer un coût de token 30 à 50x à chaque exécution ? | Utilisation informatique. | Arrêtez. Négociez l'accès à l'API. |
Les trois quarts des flux de travail que nous voyons dans les bases de code des clients échouent à la vérification un ou deux ; l'utilisation informatique ne survit que lorsque les deux échouent.
À quoi ressemblent réellement les API structurées dans un agent
Voici la même tâche « récupérer les paiements échoués d'hier » exprimée de deux manières. La version structurée est celle que vous voulez que chaque agent utilise par défaut.
from openai import OpenAI
client = OpenAI()
tools = [{
"type": "function",
"function": {
"name": "list_failed_payments",
"description": "List failed payments in a date range",
"parameters": {
"type": "object",
"properties": {
"start": {"type": "string", "format": "date"},
"end": {"type": "string", "format": "date"},
},
"required": ["start", "end"],
},
},
}]
resp = client.chat.completions.create(
model="gpt-5.5",
messages=[{"role": "user", "content": "Show yesterday's failed payments."}],
tools=tools,
tool_choice="auto",
)
call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)
payments = stripe.PaymentIntent.list(
created={"gte": args["start"], "lte": args["end"]},
limit=100,
)
Deux invites en entrée, une réponse structurée en sortie, un appel HTTP à Stripe. L'agent ne voit jamais le tableau de bord.
L'équivalent en utilisation informatique démarre un navigateur, se connecte à Stripe, prend une capture d'écran du tableau de bord, clique sur le sélecteur de date, prend une autre capture d'écran, fait glisser une plage, prend une capture d'écran, défile jusqu'à « Échoué », prend une capture d'écran, et extrait finalement les chiffres des pixels. Chaque capture d'écran représente environ 1 500 tokens d'entrée. Douze tours sont typiques. La facture est 45 fois plus élevée et le taux de réussite est inférieur.
Concevoir le chemin structuré avec Apidog
La raison pour laquelle les équipes recourent à l'utilisation informatique est rarement le coût ; c'est généralement que personne n'a conçu une interface d'outil propre pour l'agent. Apidog vous offre un endroit pour faire ce travail correctement.
Première étape : modélisez les opérations dont l'agent a besoin en tant que points de terminaison dans un projet Apidog. Une poignée de requêtes POST couvrant « lister les factures », « mettre à jour l'affaire », « envoyer un message » suffit à remplacer 80 % des démonstrations d'opérateur. Apidog génère un document OpenAPI 3.1 directement depuis la vue de conception.
Deuxième étape : intégrez ce document OpenAPI dans votre framework d'agent. Le tableau tools d'OpenAI, le schéma d'utilisation d'outils d'Anthropic et le chargeur OpenAPI de LangChain consomment tous directement OpenAPI 3.1. L'agent dispose désormais d'appels de fonction typés qui reflètent votre conception.
Troisième étape : activez le serveur de maquette d'Apidog. La maquette renvoie un JSON réaliste pour chaque point de terminaison, ce qui vous permet d'exécuter l'agent de bout en bout sans toucher à la production ni payer les coûts de token pour une exécution réelle. Nous couvrons le même modèle dans le guide de développement contract-first d'Apidog.
Quatrième étape : rejouez le trafic. Apidog enregistre chaque requête et réponse pendant que l'agent s'exécute, afin que vous puissiez comparer une exécution réussie à une exécution échouée et voir quel appel d'outil a dérivé. C'est ainsi que vous coupez la longue traîne du « l'agent fonctionnait hier et est tombé en panne aujourd'hui ».
Cinquième étape : déployez. Le même projet sert à la fois de documentation publique, de banc d'essai QA et de tableau de bord de surveillance.
Hybride : quand vous avez besoin des deux chemins
En production, la plupart des agents finissent par être hybrides. Un comportement par défaut raisonnable ressemble à ceci.
- 90 % des opérations passent par une interface d'outil structurée que vous avez conçue.
- 10 % se rabattent sur une boucle d'utilisation informatique pour la longue traîne des portails hérités.
- Une invite de routage décide quel chemin prendre en fonction du nom de l'opération.
Le routeur est un petit message système : « Si tool_name in known_tools, appelez l'outil. Sinon, transférez à l'agent de navigateur. » Claude 4.5 d'Anthropic et GPT-5.5 d'OpenAI gèrent tous deux ce routage de manière fiable ; vous pouvez esquisser le même modèle dans DeepSeek V4. Consultez comment utiliser l'API DeepSeek V4 pour la forme de requête.
Suivez les deux chemins séparément dans votre pile d'observabilité. Les appels structurés devraient représenter 99 % du volume et 30 % du coût ; le recours à l'utilisation informatique devrait représenter 1 % du volume et 70 % du coût. Si le ratio s'inverse, quelqu'un a ajouté une opération de la mauvaise manière et vous devez concevoir un point de terminaison pour cela.
Erreurs courantes à éviter
Voici les modèles qui apparaissent dans les tickets de support.
- Oublier le schéma. Les équipes déploient des agents avec des invites système uniquement textuelles et s'étonnent que les appels structurés échouent. Passez toujours un JSON Schema ; Claude et GPT améliorent tous deux la précision des outils de manière significative lorsque le schéma est strict.
- Laisser l'agent concevoir le schéma à l'exécution. Un schéma est une surface produit. Créez-le dans Apidog, versionnez-le et traitez les changements comme vous traiteriez un changement d'API publique. Les schémas auto-modifiables sont la cause des pannes de production.
- Enregistrer les tokens, pas le coût. Les tokens d'utilisation informatique se cachent dans les entrées d'images, que la plupart des outils d'observabilité tarient différemment. Consultez la console de facturation de votre fournisseur, pas votre tableau de bord de traçage.
- Confondre l'utilisation informatique avec la RPA. L'automatisation des processus robotiques (RPA) exécute des clics scriptés sur des éléments DOM connus. L'utilisation informatique redécide où cliquer à chaque capture d'écran. Le premier est reproductible et bon marché ; le second est flexible et coûteux. Ne recourez pas à l'utilisation informatique lorsque la RPA est l'outil approprié.
- Oublier le coût de la latence. Une facture de tokens 45x est une taxe. La plus importante est qu'une boucle de capture d'écran de 60 secondes fait sortir l'agent du flux de l'utilisateur. Si l'utilisateur regarde, vous voulez presque toujours l'API.
Alternatives à considérer
Si un fournisseur manque d'API mais dispose d'une interface utilisateur bien connue, trois options intermédiaires se situent entre l'utilisation informatique complète et l'intégration complète.
- Les scripts de navigateur sans tête (Playwright, Puppeteer) ne coûtent rien par exécution après le développement. Ils se cassent lorsque l'interface utilisateur change ; prévoyez un budget pour cela.
- Connecteurs Zapier ou Make publiés par le fournisseur. Les plateformes iPaaS ont déjà payé la taxe d'intégration pour vous. Payez pour le siège, déployez plus rapidement.
- API privées rétro-ingénierées. Surveillez l'onglet réseau dans DevTools. De nombreux tableaux de bord de fournisseurs communiquent avec des points de terminaison JSON internes que vous pouvez appeler directement avec le même cookie d'authentification. Documentez-les dans Apidog et traitez-les comme semi-stables. Nous utilisons cette astuce dans les tests d'API sans Postman.
L'utilisation informatique est le dernier recours, pas le défaut.
Cas d'utilisation réels
Une équipe de conformité fintech a remplacé un rapport Stripe en 6 étapes basé sur l'utilisation informatique par trois appels structurés. Le coût des tokens a chuté de 92 % et l'exécution est passée de 41 secondes à 2.
Un agent de support SaaS B2B a conservé l'utilisation informatique pour un seul flux de travail : un portail d'approvisionnement fournisseur sans API. Tout le reste était acheminé via des appels d'outils OpenAPI conçus dans Apidog. Les dépenses totales en tokens de l'agent sont passées de 4 200 $ à 310 $ par mois.
Un fondateur solo utilisait l'utilisation informatique exactement une fois par semaine pour rafraîchir un tableau de bord Notion à partir d'un ERP hérité. Le coût 45x d'une exécution hebdomadaire n'était que de quelques centimes ; l'alternative était un projet d'intégration de plusieurs semaines. C'est le bon profil pour l'utilisation informatique.
Conclusion
Le chiffre 45x est réel, reproductible, et il devrait redéfinir la manière dont votre équipe choisit les outils. Privilégiez les API structurées conçues dans Apidog ; ne recourez à l'utilisation informatique que lorsqu'aucune API n'existe et que le flux de travail s'exécute suffisamment rarement pour que le coût des tokens soit une erreur d'arrondi.
Cinq points à retenir pour le déploiement :
- L'utilisation informatique coûte 30 à 50 fois plus de tokens que l'appel d'API structurée équivalent.
- Un point de terminaison documenté et un JSON Schema surpassent une boucle de captures d'écran en termes de coût, de latence et de fiabilité.
- Les architectures hybrides sont normales : concevez les 90 % dans Apidog, et revenez à l'utilisation informatique pour la longue traîne de 10 %.
- Simulez l'interface d'outil structurée avant de la connecter à un modèle réel. Cela économise les crédits d'agent et raccourcit la boucle.
- Suivez les deux chemins séparément dans l'observabilité afin de détecter quand le ratio dérive.
Étape suivante : ouvrez Apidog, créez un projet pour l'interface d'outil de votre agent et activez le serveur de maquette. Vous saurez en moins d'une heure si le flux de travail que vous comptiez déployer en utilisation informatique peut être réduit à deux appels structurés à la place.
bouton
FAQ
L'utilisation informatique est-elle parfois moins chère qu'une API structurée ?
Non, pas par exécution. Les tokens de capture d'écran dominent. L'utilisation informatique peut être moins chère au total lorsque le coût d'intégration dépasserait des années de coûts d'exécution, ce qui n'arrive que pour des flux de travail à très faible volume contre des API inexistantes.
Comment simuler une interface d'outil JSON pour un agent ?
Concevez les points de terminaison dans Apidog, activez le serveur de maquette intégré et dirigez votre agent vers l'URL de la maquette. Chaque requête renvoie un JSON réaliste sans coût de token. Nous couvrons le flux de travail de bout en bout dans les outils de test d'API pour les ingénieurs QA.
Puis-je utiliser OpenAPI pour les appels d'outils dans n'importe quel modèle ?
Oui. Le paramètre tools d'OpenAI, le bloc tool_use d'Anthropic et le point de terminaison d'appel d'outils de DeepSeek V4 consomment tous des schémas OpenAPI 3.1. Apidog exporte le schéma proprement. Consultez comment utiliser l'API DeepSeek V4 pour la forme de requête DeepSeek.
GPT-5.5 prend-il toujours en charge l'utilisation informatique ?
OpenAI propose l'utilisation informatique via le produit Operator et via l'API Responses. Le profil de coût correspond à celui d'Anthropic, à peu près capture d'écran par capture d'écran. La recommandation de cet article s'applique quel que soit le fournisseur.
Qu'en est-il de Skyvern, de l'utilisation de navigateurs et d'autres agents open source ?
Même logique. Ils réduisent le prix par appel en acheminant via des modèles ouverts moins chers, mais le nombre de tours et la taille des captures d'écran sont similaires. Les API structurées les surpassent toujours largement là où les API existent.
Comment savoir quand un point de terminaison manque pour une tâche d'agent ?
Observez quels appels d'outils échouent ou sont refusés. Si l'agent continue d'essayer de se rabattre sur un navigateur, cela signifie qu'il manque un point de terminaison dans votre interface d'outil. Ajoutez-le dans Apidog, régénérez le schéma, et l'agent cessera de se rabattre.
