Comment l’API Agents d’OpenAI modifie l’économie du travail basé sur l’IA

L’API Agents d’OpenAI a été conçue pour exécuter des agents cloud au cours de sessions prolongées, dotés d’outils, de sandbox, de fichiers, de mécanismes de gestion du contexte ainsi que de sous-agents fonctionnant en parallèle. Un agent peut analyser un problème, exécuter du code, confier des tâches à d’autres, conserver des résultats intermédiaires et continuer jusqu’à ce que le travail soit terminé.

Cela modifie non seulement la manière dont les développeurs créent des agents, mais aussi la façon dont une entreprise doit évaluer leur coût.

Une seule demande peut désormais déclencher une série d’opérations : utilisation de modèles, appels d’outils, exécutions dans des sandbox, tentatives de répétition, stockage d’artefacts et approbations humaines. Les tokens apparaissent toujours sur la facture, mais ils ne reflètent plus vraiment le coût réel du travail. L’unité à suivre est la tâche achevée : correcte, récupérable, auditable, et équivalente au coût de sa réalisation.

Une demande n’est plus une unité de travail

Une simple invocation d’un modèle présente des limites évidentes : l’application envoie des données d’entrée, le modèle renvoie des résultats, puis l’application reprend ses activités normales.

L’API Agents est conçue pour un type d’exécution différent. L’agent reçoit un objectif et décide de la manière de l’atteindre. Supposons que vous lui demandiez d’examiner une augmentation des erreurs de type 5xx :

Découvrez pourquoi service-api a connu une augmentation inhabituelle des erreurs au cours des 30 dernières minutes et proposez des mesures correctives sûres.

Un assistant conventionnel décrirait comment un ingénieur procéderait à une enquête. Un agent connecté aux bons systèmes peut commencer à agir immédiatement : il vérifie les déploiements récents, consulte les journaux de l’application, compare les versions des dépendances, examine les métriques d’infrastructure, délègue des analyses spécifiques, exécute du code de diagnostic, enregistre les preuves et attend l’approbation avant de modifier quoi que ce soit.

L’utilisateur ne voit qu’une seule demande. Le système a exécuté tout le flux de travail.

Le guide pratique d’OpenAI pour la création d’agents qualifie cela de « run » : une boucle qui se poursuit jusqu’à ce que l’agent termine la tâche, produise une sortie finale, rencontre une erreur ou atteigne une limite prédéfinie. Le coût s’accumule au sein de cette boucle.

Le temps d’exécution comporte une facture cachée

Les tokens font partie de la facture. Ce ne sont que la partie la plus facile à voir.

Revenons à l’incident de production. D’abord, l’agent récupère les taux d’erreur récents à partir d’un outil de surveillance, puis il lit l’historique des déploiements, enfin il recherche dans les journaux. Chacune de ces opérations a un coût, un délai, un ensemble de permissions et sa propre manière de rencontrer des problèmes.

Alors l’outil de journalisation renvoie 500 enregistrements. Cela semble utile jusqu’à ce que l’on voie ce qui se passe ensuite. Ces enregistrements doivent être déplacés, traités et intégrés dans le contexte du modèle. La plupart sont irrelevants, et le modèle passe du temps à analyser du bruit avant de trouver les cinq événements qui expliquent l’incident.

Ainsi, la conception d’un outil revient à une conception des coûts. Un outil de recherche qui renvoie un résumé structuré et concis peut être moins cher et plus fiable qu’un outil qui affiche tous les enregistrements correspondants. La réponse de l’API consiste en une recherche d’outils associée à des appels programmatiques, ce qui permet de ne révéler les définitions des outils qu’en cas de besoin et de filtrer ou de combiner les résultats avant qu’ils n’atteignent le modèle.

La même logique s’applique à l’exécution dans un environnement isolé. Un script de diagnostic consomme de la puissance CPU, de la mémoire, de l’espace de stockage, du temps pour l’installation de paquets, et éventuellement un accès réseau. S’il génère un rapport ou un ensemble de preuves, ces éléments doivent être stockés, indexés, examinés ou conservés.

Les exécutions prolongées des agents produisent également plus que du texte. Lors de l’enquête sur un incident, les preuves à l’origine d’un diagnostic peuvent avoir plus d’importance que le résumé écrit. Dans le travail de codage, le correctif constitue une partie des résultats, tandis que les résultats des tests et une analyse des dépendances peuvent être tout aussi précieux.

Un petit exemple de l’Agents SDK montre où se situe la limite d’exécution :

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

La fonction est minuscule. L’aspect économique, lui, ne l’est pas. Tout cela dépend de l’agent : savoir s’il est appelé, s’il est appelé une seconde fois, comment son résultat est lu, et s’un autre outil ou l’approbation d’un humain est nécessaire.

Fiabilité, contrôle et acceptation définissent le succès

Le SDK fournit les éléments nécessaires au fonctionnement de ce cycle : agents, exécutants, outils, transferts de données, sessions, mécanismes de contrôle et outils de suivi. Ils sont importants car les flux de travail réels réussissent rarement en une seule tentative.

La requête de journalisation peut expirer, ce qui pousse l’agent à réessayer. La deuxième requête fonctionne mais renvoie des données incomplètes. L’agent réécrit alors la requête, récupère un ensemble de données plus important et demande à un agent spécialisé d’examiner l’historique du déploiement. Finalement, l’enquête aboutit.

Pour l’utilisateur, l’agent a terminé la tâche. En termes économiques, cette tâche inclut également des tentatives infructueuses, plusieurs itérations du modèle, davantage d’appels à des outils et plus de temps écoulé.

Les tentatives de réessai ne sont pas automatiquement une perte de temps. Un réessai qui permet de surmonter une panne temporaire peut être précisément ce qui rend un agent fiable. Le problème survient lorsque ces tentatives de réessai sont regroupées dans un seul chiffre global de succès.

Les agents parallèles échangent du temps contre des coûts

L’API peut distribuer des tâches complexes entre des sous-agents qui fonctionnent en parallèle. Une enquête sur un incident peut fournir à un spécialiste l’historique des déploiements, à un autre les erreurs de l’application et à un troisième les modifications des dépendances, tandis qu’un coordinateur fusionne leurs résultats.

Le temps écoulé peut diminuer puisque tout s’exécute en même temps. Cependant, la facture totale peut augmenter, car vous payez désormais pour plusieurs contextes de modèle distincts, plusieurs chaînes d’appels d’outils, la coordination, une étape de synthèse, et il est même possible que le même travail soit effectué deux fois.

C’est pourquoi les systèmes multi-agents ressemblent à des systèmes distribués dotés de modèles de langage intégrés dans le processus. Le coordinateur agit comme planificateur, les spécialistes sont des travailleurs, les outils externes constituent des services, et les fichiers ainsi que les bases de données deviennent un état partagé. Les problèmes habituels apparaissent alors : échecs partiels, tentatives de réessai, état incohérent, travail redondant, limites de concurrence et attribution floue des coûts. Plus il y a d’agents, cela ne signifie pas automatiquement une meilleure capacité de raisonnement. Le parallélisme doit être justifié par la manière dont la tâche est structurée et par la valeur du temps consacré.

L’acceptation est la ligne d’arrivée

La génération peut s’achever bien avant que le travail réel ne soit terminé. Dans le cas d’un support client, l’acceptation peut signifier que le problème du client a été résolu sans escalade inutile. Pour une tâche de codage, cela peut signifier que les tests sont réussis, que les normes de révision sont respectées et que la modification est intégrée. En réponse à un incident, cela peut signifier qu’une diagnosis a été étayée par des preuves et a conduit à une atténuation sûre. La métrique qui en découle est :

cost per accepted task =
    total execution cost / tasks accepted without rework

Si un agent répond en dix secondes et qu’une personne passe ensuite dix minutes à le résoudre, cette réponse en dix secondes n’était pas la solution la moins coûteuse. C’était simplement la tentative la moins coûteuse.

Le fait qu’une personne examine le résultat ne signifie pas pour autant que l’automatisation a échoué. Pour les tâches à haut risque, l’approbation finale peut être ce qui rend l’automatisation acceptable. Ce que l’on souhaite, c’est l’effort humain le plus minimal tout en maintenant un contrôle humain réel.

Le SDK propose des contraintes pour les entrées, les sorties et les outils, et sa documentation sépare les vérifications au niveau de l’agent de celles au niveau de l’outil : les configurations utilisant des spécialistes délégués peuvent nécessiter des contrôles concernant les opérations fonction-outil individuelles et les opérations MCP. Ces contraintes exigent des efforts et parfois des appels de modèle supplémentaires. Elles peuvent également éviter des coûts bien plus élevés dus à des actions erronées, à une exposition de données, à des violations de politiques ou à des problèmes réglementaires. La sortie n’est considérée comme une tâche terminée qu’après des contrôles de qualité et un degré adéquat de contrôle humain.

Des traces à la valeur commerciale

Chaque nouvel outil élargit les capacités de l’agent. Il élargit également les permissions du système, sa latence, ses modes de défaillance et ses besoins en gouvernance.

L’API prend en charge des fonctions personnalisées, des outils intégrés et des serveurs MCP. Le standard MCP normalise la manière dont les applications d’IA se connectent à des outils externes, à des ressources et à des instructions. Cela réduit les difficultés d’intégration, mais cela ne rend pas automatiquement un outil distant fiable. La spécification MCP met en garde contre le fait que les descriptions et annotations d’outils provenant de serveurs non fiables ne doivent pas être considérées comme crédibles automatiquement, et elle recommande une invocation visible des outils ainsi qu’une approbation humaine pour les opérations. L’autorisation à distance soulève des préoccupations supplémentaires telles que la validation du public autorisé par le jeton, le stockage sécurisé des jetons, le PKCE et la prévention des attaques de type confused-deputy. Chaque fonctionnalité ajoutée crée de nouvelles frontières en matière d’autorisation, d’audit et de gouvernance.

Les traces sont des données comptables

La réponse finale révèle peu de détails sur la manière dont elle a été obtenue. On ne sait pas quels outils ont été pris en compte, combien d’entre eux ont fonctionné, si un sous-agent a rencontré des problèmes, ou ce qui a incité quelqu’un à être impliqué.

Le SDK fournit un suivi qui couvre les générations, les appels d’outils, les transferts de responsabilités, les contraintes et les événements personnalisés. Ce suivi est généralement utilisé comme outil de débogage, mais il sert également de système de comptabilité. Un suivi peut révéler qu’un outil est responsable de la majeure partie de la latence, qu’un flux de travail répète constamment la même recherche, ou qu’un choix de modèle entraîne une plus grande acceptation avec moins de tentatives. Sans suivi, les équipes optimisent des moyennes ; avec lui, elles peuvent optimiser chaque étape du flux de travail individuellement.

Le tableau de bord doit relier les données d’exécution aux données de résultats : le coût de chaque tâche acceptée ainsi que le nombre de tentatives du modèle et d’appels d’outils utilisés, le temps passé dans l’environnement de test, la fréquence des tentatives de réessai et celle des récupérations, en plus des retouches nécessaires, du temps passé par les évaluateurs, des escalades et de la valeur apportée. Le tableau de bord exact dépend du flux de travail. Une équipe de support pourrait s’intéresser aux cas résolus sans escalade, une équipe de plateforme aux incidents atténués, une équipe de produit à la protection des revenus ou à l’économie de temps de travail. Ce qui change, c’est ce par quoi on divise.

La décision stratégique

Les organisations ne devraient pas commencer par se demander comment rendre un agent moins cher par appel. La question plus difficile doit être posée en premier :

Cet agent est-il capable de gérer ce type de travail de manière suffisamment fiable pour que le coût total reste inférieur à celui du processus actuel ?

Pour cela, il faut disposer d’une base fiable du processus actuel, couvrant le temps de travail du personnel, les temps d’attente en file d’attente, les transferts répétés, les infrastructures, les erreurs et leurs corrections, les opportunités perdues ainsi que les efforts de conformité. Un agent coûtant 2 dollars par tâche acceptée peut représenter un excellent investissement lorsque le processus existant coûte 20 dollars. Un agent coûtant 0,10 dollar par tentative peut être peu efficace si seuls la moitié de ses résultats sont acceptés et que chaque échec nécessite une correction manuelle.

Un plan d’optimisation judicieux commence par le système le plus simple capable d’accomplir la tâche. Utilisez des modèles plus petits pour le routage, le filtrage ou la simple validation, et passez à des modèles plus puissants lorsque des raisonnements plus approfondis sont nécessaires. Faites en sorte que les outils restituent des résultats compacts et structurés. Parallélisez uniquement les tâches indépendantes. Validez les actions qui en découlent. Conservez suffisamment de preuves pour faciliter l’examen et la récupération.

Le SDK s’avère utile lorsque le moteur de exécution lui-même doit gérer les tours de parole, les outils, les sessions, les transferts, les contraintes ou la coordination entre les agents. L’API Responses reste appropriée lorsque l’équipe préfère prendre en charge elle-même le cycle de traitement et la gestion de l’état. Ce choix est à la fois architectural et financier.

Évaluez le travail, pas les mots

L’API Agents facilite la création d’agents capables de fonctionner avec différents outils, environnements, sessions et sous-agents, tandis que le SDK fournit des primitives au niveau de l’application pour les coordonner, les protéger grâce à des contraintes et les examiner via des traces. Ensemble, ils ouvrent la voie à une nouvelle façon de penser l’économie de l’IA.

La demande qui arrive n’est qu’un point d’entrée, et non l’unité de compte. L’unité est la tâche terminée, celle qui peut être considérée comme correcte, récupérable en cas de problème, inspectée a posteriori et justifiée en termes de coût. Un tarif par token reste utile en tant qu’élément distinct. Tout le reste – outils, calculs, stockage, tentatives de réessai, latence, sécurité et intervention humaine – figure ailleurs sur la facture.

Les meilleurs systèmes d’agents ne seront pas ceux qui génèrent le moins de tokens. Ce seront ceux qui accomplissent le travail le plus précieux pour un coût total raisonnable.

Lectures complémentaires

• Construire des systèmes RAG fiables en production : de l’ingestion à l’observabilité — Du découpage en chunks et de la recherche hybride au réclassement, au contrôle d’accès, aux ensembles d’évaluation et au traçage : les étapes qui distinguent une démonstration RAG d’un système en production.
• Raisonnement à partir d’un arbre de documents plutôt que recherche de vecteurs — PageIndex crée un index hiérarchique permettant à un LLM de s’y déplacer, en évitant le découpage en chunks et les embeddings. Son fonctionnement, les résultats obtenus sur FinanceBench, et les cas d’usage appropriés.

GPT-6 Astra pour les développeurs : utilisation sur ordinateur, tarifs et modifications de l’API — Ce que GPT-6 Astra peut faire au-delà des conversations, comment l’appel d’outils modifie votre code API, et sa comparaison avec Claude et Gemini en préparation pour des postes dans le domaine de l’IA générative.