Asana réduit de 76x les coûts avec GPT-6.1 Sol

Contexte

Selon un cas publié par OpenAI le 9 octobre 2026, Asana, l'éditeur de logiciels de gestion de projet, a repensé son agent de navigateur à l'aide de Codex. Les deux résultats mis en avant proviennent de tests : l'agent remanié est devenu 76 fois moins cher et 5 fois plus rapide. Asana indique que cette économie lui permet de proposer à ses clients des modèles plus performants. Le modèle cité dans l'article est GPT-6.1 Sol.

La source reste brève, et ses limites comptent. Elle rapporte une comparaison réalisée en environnement de test. Elle ne décrit ni le jeu de tâches, ni la configuration de référence, ni la base de facturation. Le chiffre de 76 fois doit donc se lire comme un résultat obtenu sur la charge de travail testée par Asana. Ce n'est pas un gain universel pour tous les agents de navigateur.

Combien coûte l'exécution d'un agent de navigateur, et pourquoi une refonte peut-elle réduire ce coût aussi fortement ? Un agent de navigateur fonctionne en boucle : il lit la page, décide de l'action suivante, clique ou saisit du texte, puis lit le nouvel état de la page. Chaque passage consomme des jetons en entrée et en sortie. Le coût total correspond à peu près au nombre de jetons par étape, multiplié par le nombre d'étapes, multiplié par le prix du modèle choisi. La source ne dit pas lequel de ces facteurs Asana a modifié.

Analyse approfondie

La même boucle explique le gain de vitesse. Chaque étape supplémentaire ajoute un appel au modèle et du temps d'attente. Raccourcir le parcours d'une tâche, ou réduire ce qui est envoyé au modèle à chaque tour, améliore en général le coût et la latence en même temps. Cela correspond au couple annoncé : 76 fois sur le coût, 5 fois sur la vitesse. L'écart entre ces deux chiffres suggère plusieurs leviers, mais la source ne fournit aucun détail. Toute lecture des changements précis d'Asana relève ici de l'inférence, non d'un fait rapporté.

L'outillage mérite aussi l'attention. La refonte a été menée dans Codex, l'agent de programmation d'OpenAI. Un agent a donc aidé à reconstruire un autre agent, avec le coût et la vitesse comme critères d'acceptation mesurables. La cible n'était pas une nouvelle fonctionnalité. C'était un système existant, en production, dont l'économie pouvait être vérifiée par un test comparatif.

La destination des économies est le détail le plus parlant. Asana n'a pas présenté la baisse de coût comme une marge supplémentaire. L'entreprise affirme qu'elle lui donne de la place pour offrir des modèles plus capables à ses clients. Cela suppose une séquence délibérée : réduire le coût par l'ingénierie, puis consacrer une partie du budget à un modèle plus puissant, ici GPT-6.1 Sol. L'objectif affiché est d'éviter un arbitrage forcé entre prix et qualité.

Impact sur l'industrie

Pour les éditeurs de logiciels d'entreprise, ce cas touche un verrou très concret. Une fonction d'agent n'est déployée largement que si le coût d'une tâche tient dans le prix de l'abonnement. Asana vend des logiciels à des équipes. Si chaque exécution d'agent entraîne une lourde facture d'inférence, la fonction pèse sur la marge brute à mesure que l'usage progresse. Une réduction de cette ampleur, si elle se confirme en production, rend une disponibilité par défaut plus réaliste qu'un simple essai limité.

Pour OpenAI, l'histoire relie trois produits dans un seul exemple client : un modèle, Codex et un déploiement en entreprise. Le message est que l'offre comprend les outils pour rendre un agent moins cher et plus rapide, et pas seulement un modèle plus puissant. La source n'indique aucune condition commerciale entre les deux sociétés. Aucune affirmation de ce type n'est donc faite ici.

Les concurrents, comme Anthropic, Google et les jeunes pousses de l'automatisation de navigateur, voient la comparaison se déplacer. Les scores de référence comptent toujours. Le coût par tâche menée à terme et la latence entrent désormais dans la même discussion. Les acheteurs peuvent poser une question directe : combien coûte l'achèvement de ce flux de travail, et en combien de temps ?

Perspectives

Plusieurs points méritent d'être suivis. Le premier est la transparence. Si Asana ou OpenAI publient davantage de détails, comme les types de tâches, le nombre d'étapes et l'usage de jetons avant et après, ou un changement dans la représentation du contenu des pages, les lecteurs pourront juger quelle part des 76 fois relève d'une méthode réutilisable. Le deuxième est la donnée de production. Les résultats de test ne se transposent pas toujours au trafic réel. Les tâches réelles sont plus désordonnées, les pages moins stables, et les nouvelles tentatives ajoutent du coût.

Le troisième concerne les clients. Asana affirme que les économies permettent des modèles plus capables. Reste à savoir si cela se traduira par un meilleur taux de réussite, des flux plus complexes ou des changements d'offres et de tarifs. Rien n'est encore rapporté à ce sujet. Le quatrième est l'imitation. Si d'autres éditeurs utilisent aussi des agents de programmation pour reconstruire leurs propres agents, avec le coût et la latence comme objectifs stricts, la concurrence se déplacera vers l'efficacité d'ingénierie. Dans ce cas, l'éditeur qui continuera d'abaisser le coût par tâche disposera de la plus grande marge pour confier des modèles plus puissants à ses utilisateurs.