Asana: agent navigateur 76x moins cher avec GPT-6.1 Sol

Contexte

Le 9 octobre 2026, OpenAI a publié un témoignage client consacré à Asana, l'éditeur de logiciels de gestion du travail. Selon ce récit, Asana a utilisé Codex pour rendre son agent de navigation 76 fois moins coûteux à exécuter et 5 fois plus rapide lors de tests. Le titre du cas cite aussi GPT-6.1 Sol comme modèle concerné. OpenAI explique que la baisse du coût et de la latence permet à Asana de proposer des modèles plus performants à ses clients, au lieu de se rabattre sur des modèles plus faibles pour maîtriser les dépenses.

Ces chiffres demandent une lecture prudente. Ils proviennent de tests, et c'est un partenaire qui les a publiés. Ils ne représentent pas la moyenne de l'ensemble du trafic en production. Le résumé ne précise ni la référence de comparaison, ni la taille du jeu de tâches, ni l'évolution éventuelle du taux de réussite. Ces trois éléments déterminent la valeur réelle du facteur 76.

Qu'est-ce qu'un agent de navigation, et pourquoi son coût compte-t-il ? Un agent de navigation est un logiciel qui pilote une interface web à la place de l'utilisateur. Il lit la page, demande à un modèle quelle action mener, clique ou saisit du texte, puis relit la page. Pour un produit comme Asana, un tel agent peut automatiser des étapes répétitives entre plusieurs écrans et outils connectés. Si les clients l'utilisent souvent, le coût de chaque tâche pèse directement sur la marge du produit.

Analyse approfondie

La structure de coût d'un agent de navigation explique pourquoi une telle économie est envisageable. L'agent fonctionne en boucle, et chaque passage dans la boucle appelle le modèle. Le contenu des pages est souvent long, de sorte que chaque appel peut transporter un grand nombre de jetons en entrée. Une tâche de plusieurs dizaines d'étapes coûte le nombre d'étapes multiplié par le coût d'une étape. Les deux facteurs augmentent avec la difficulté de la tâche. Aucune mesure isolée ne produit vraisemblablement une baisse de 76 fois. Une combinaison de leviers est plus plausible, même si la source n'indique pas lesquels Asana a employés. Parmi les pistes possibles : réduire la représentation de la page envoyée au modèle, limiter les étapes inutiles et les nouvelles tentatives, transformer les parcours récurrents en programmes fixes, mettre en cache le contexte qui ne change pas, et laisser un modèle plus récent accomplir le même travail en moins d'étapes. Ce sont des déductions tirées du fonctionnement de ces agents, pas des affirmations du cas.

Le rôle de Codex relève lui aussi de l'inférence. Codex est l'agent de code d'OpenAI, et le cas porte cette étiquette. Sa contribution probable est du travail d'ingénierie : lire les traces de l'agent, réécrire des outils et des scripts, vérifier les modifications. Si c'est bien le cas, le changement notable est qu'un agent de code a optimisé un autre agent. Auparavant, les équipes réduisaient les coûts en ajustant à la main les consignes et les flux. Ici, un agent semble avoir assuré ce réglage. La répartition exacte des tâches doit être vérifiée dans le texte d'origine. Une réduction de coût de 76 fois a-t-elle un sens sans données sur le taux de réussite ? Pas en soi. Cette baisse pour l'agent de navigation d'Asana n'a de valeur que si l'agent mène toujours ses tâches à bien de façon fiable. Si le taux de réussite est resté stable ou a progressé, le résultat est solide. S'il ne vaut que pour des tâches simples, la portée de l'annonce se réduit. La source mentionne aussi un gain de vitesse de 5 fois, ce qui suggère moins d'appels au modèle, ou des appels plus légers, par tâche.

Impact sur l'industrie

Pour Asana, des exécutions moins chères changent ce que l'entreprise peut livrer. Un agent qui coûte beaucoup moins par tâche peut passer de quelques usages à forte valeur à des usages quotidiens et fréquents. Les économies peuvent aussi financer un modèle plus puissant, ce qui est précisément le résultat que le cas met en avant. L'arbitrage est meilleur que de conserver l'ancien modèle et d'empocher la marge. Pour OpenAI, ce témoignage sert de vitrine à la fois pour le modèle et pour Codex. Le modèle exécute la tâche, et l'agent de code optimise le système autour de lui. Ce duo appuie l'argument selon lequel les agents peuvent être déployés à grande échelle en entreprise. L'exemple est choisi par le fournisseur : il montre ce qui est possible, il ne constitue pas une mesure de référence des résultats habituels. Les concurrents subissent une pression sur deux fronts. Les éditeurs de solutions d'automatisation de navigateur et d'utilisation de l'ordinateur partagent la même structure de coût : beaucoup d'étapes et un contexte long. Sans trajectoire crédible de réduction des coûts, leurs offres peuvent paraître chères dans les achats des entreprises. Les autres fournisseurs de modèles devront aussi présenter des cas clients reproductibles, et pas seulement des scores de benchmark.

Les acheteurs peuvent en tirer une leçon pratique. Pour juger un projet d'agent, il faut mesurer le coût et la latence réels d'une seule tâche, et pas seulement les capacités du modèle. Ces deux valeurs décident si une fonction peut rester activée pour tous les utilisateurs.

Perspectives

Plusieurs signaux méritent d'être suivis. D'abord, OpenAI ou Asana publieront-ils des détails de méthode : configuration de référence, types de tâches, taux de réussite, comportement de repli en cas d'échec de l'agent, et validité des facteurs 76 et 5 en production ? Ensuite, l'approche est-elle transposable ? Si elle repose sur des techniques générales, comme la compression du contexte, les parcours fixes et l'optimisation pilotée par un agent, elle devrait se diffuser vite. Si elle dépend fortement de la structure du produit Asana, la marge de réutilisation sera plus étroite.

La tarification et la gamme de modèles pourraient aussi évoluer si les fournisseurs proposent des modèles plus puissants à un prix effectif plus bas pour les usages d'agents. Enfin, moins cher ne veut pas dire plus sûr. Un agent de navigation agit dans des systèmes réels au nom de l'utilisateur. Les limites de permissions, la traçabilité des erreurs et les étapes de confirmation humaine restent des exigences fermes pour un déploiement en entreprise.

Le cas Asana indique un déplacement de la question centrale pour les agents d'entreprise : il ne s'agit plus de savoir si l'agent sait faire la tâche, mais si l'entreprise peut l'assumer financièrement, l'accélérer et lui faire confiance à grande échelle. Le facteur 76 est un début prometteur, mais il lui manque la référence de comparaison et les données de réussite pour devenir une conclusion ferme.