Asana divise par 76 le coût de son agent de navigation avec GPT-6.1 Sol : une optimisation menée par Codex

Le 9 octobre 2026, OpenAI a publié un témoignage client consacré à Asana. Les chiffres frappent. Dans une série de tests d'agent de navigation, Asana a divisé par 76 le coût estimé du modèle et multiplié la vitesse d'exécution par cinq. Le flux optimisé tourne sur GPT-6.1 Sol. Il coûte en moyenne 0,47 dollar en modèle, selon les estimations, et dure environ quatre minutes par exécution. La référence est la configuration de production d'origine, sur le Modèle B. Un calcul simple à partir de ces deux chiffres situe l'ancien coût autour de 36 dollars par exécution. Une réserve d'abord. Il s'agit d'un cas publié par un éditeur. Les coûts sont des estimations. La comparaison provient d'une étude de 144 exécutions conçue par Asana elle-même. C'est un signal d'ingénierie sérieux, mais pas encore une référence sectorielle que toute équipe pourrait reprendre telle quelle.

Le contexte, c'est StackAI, une plateforme qu'Asana a rachetée. Ses clients y construisent, sans écrire de code, des flux où un agent navigue sur des sites, remplit des formulaires et rassemble des informations. Une exécution isolée paraît anodine. À l'échelle d'Asana, chaque petite inefficacité est multipliée par un volume d'appels considérable. Frank Hidalgo, docteur et CTO de StackAI, a donc voulu rendre l'agent plus rapide et moins coûteux. Il n'a pas mené un audit manuel avec son équipe. Il a chargé GPT-6 Astra, dans Codex, d'enquêter sur l'agent, de tester des améliorations et de comparer les résultats. Selon son estimation, ce travail aurait demandé un à deux mois à la main. Il a pris environ une semaine.

Le diagnostic est la partie la plus instructive. Hidalgo a d'abord demandé à GPT-6 Astra de cartographier le code et d'expliquer comment l'agent construisait chaque requête au modèle. Résultat : l'agent mettait en cache ses instructions fixes et ses définitions d'outils, mais pas l'historique croissant du texte des pages et des captures d'écran. Voyons ce que cela implique. À chaque pas, un agent de navigation transmet au modèle tout ce qu'il a vu jusque-là, plus une nouvelle capture. Plus l'historique s'allonge, plus l'entrée à traiter à chaque étape grossit. Si cette partie de la requête ne touche pas le cache, le même contenu est facturé plein tarif, encore et encore, au sein d'une seule exécution. Le délai avant le premier jeton s'allonge aussi à chaque fois. Le gaspillage s'accumule étape après étape, et l'entrée totale croît plus vite que le nombre d'étapes. C'est notre lecture du mécanisme, et elle est raisonnable. L'extrait public d'OpenAI ne liste pas tous les changements ultérieurs, et nous ne devons pas inventer ceux qui manquent.

Passons au plan d'étude. Asana a réalisé 144 exécutions, avec GPT-6.1 Sol et trois autres modèles de pointe, nommés Modèle A, B et C dans le texte. La force de ce plan est de placer le choix du modèle et la refonte du flux dans une même comparaison. Il pose aussi un problème d'interprétation qu'il faut énoncer clairement. Le facteur 76 oppose le flux Sol optimisé à la configuration de production d'origine sur le Modèle B. Deux variables ont bougé en même temps. Attribuer les 76 fois au seul modèle surestimerait son rôle. Les attribuer au seul flux ignorerait les écarts réels de prix et de vitesse entre modèles. L'extrait ne montre pas de témoin qui sépare les deux, et c'est là qu'un lecteur attentif doit insister. Les coûts sont en outre des estimations, qui bougeront si les éditeurs changent leurs tarifs. Et 144 exécutions forment un échantillon modeste : la stabilité du résultat demande davantage de répétitions.

La seconde portée concerne la manière de travailler. Arnab Bose, directeur produit d'Asana, y voit ce à quoi ressemblent, en pratique, les équipes mêlant humains et agents : un ingénieur a fixé la direction, GPT-6 Astra a mené les expériences, et les résultats sont passés par Command jusqu'à la production. Cette phrase trace une ligne de partage nette. La direction, les arbitrages et la décision de livrer sont restés aux personnes. Les tâches les plus longues, lire le code, formuler des hypothèses, lancer les comparaisons et mettre les données en ordre, sont allées à l'agent. Quand le coût marginal d'une expérience baisse, l'optimisation n'a plus à attendre une semaine libre. Elle peut devenir un geste courant. Mais le centre de gravité de la valeur se déplace alors vers l'évaluation. Dispose-t-on de tâches répétables ? De métriques comparables ? Quelqu'un lit-il les résultats avec soin ? Sans cela, des expériences plus rapides ne produisent que davantage de bruit.

Pour le secteur, ce cas envoie trois signaux. D'abord, la concurrence entre agents de navigation passe de la question de savoir si la tâche est faisable à celle de son prix en dollars et en minutes. Passer de dizaines de dollars à moins d'un dollar rend plausibles des milliers d'exécutions en entreprise chaque jour. Ensuite, la structure des succès de cache devrait figurer en permanence dans les revues d'architecture d'agents, surtout pour les contextes qui grandissent à chaque étape. Enfin, l'un des buts affichés était de permettre à Asana de proposer à ses clients des modèles plus capables : la baisse de coût achète de la marge pour la capacité. Pour le lecteur, la démarche saine consiste à emprunter la méthode plutôt que le chiffre. Auditez la part de vos requêtes qui n'est pas mise en cache. Menez une comparaison contrôlée sur un jeu de tâches fixe. Testez séparément le changement de modèle et celui de flux. Puis publiez le coût à côté du taux de réussite. Une économie de 76 fois impressionne, mais elle ne vaut que si l'agent fait toujours correctement son travail.