API Managed Agents d’OpenAI : environnements de test hébergés contre exécution auto-hébergée

Les aspects préalables à la création d’un agent

Tout ceux qui ont développé un agent autonome savent à quel point une grande partie du travail n’a rien à voir avec la fonction réelle de l’agent. Avant d’aborder la logique intéressante, une équipe doit écrire le cycle d’exécution, stocker l’état de la conversation, choisir l’outil à exécuter ensuite, se remettre des pannes, compresser le contexte à mesure que les sessions s’allongent, et fournir un endroit sécurisé pour exécuter du code et accéder à des fichiers. Ce n’est qu’alors que la tâche principale peut être abordée.

Le service d’agents gérés d’OpenAI, actuellement en bêta public, vise à alléger cette charge. Les développeurs n’ont pas besoin d’ajouter un nouvel endpoint de modèle à un framework d’orchestration ; ils disposent plutôt d’un environnement d’exécution géré pour les agents. Quatre éléments décrivent l’ensemble du travail : la tâche, le modèle, les outils et l’environnement dans lequel le travail s’effectue. La plateforme prend ensuite en charge une grande partie du matériel nécessaire à son exécution.

Le moteur qui se trouve en dessous mérite une attention particulière. OpenAI transforme l’infrastructure derrière son propre agent de codage, Codex, en une plateforme destinée aux développeurs externes. Il s’agit de bien plus qu’une couche superficielle par-dessus une API de chat ou de complétion : il gère l’orchestration qui fait avancer l’agent à travers des étapes répétées, décide de l’utilisation des outils, administre une session en expansion et assure l’exécution, tout en pouvant coordonner simultanément d’autres agents pour résoudre des parties d’un problème.

La ligne de départ évolue en conséquence. Les équipes n’ont plus besoin de consacrer la phase initiale d’un projet à la reconstruction des mécanismes permettant au fonctionnement de l’agent, et elles peuvent commencer bien plus tôt, en se concentrant directement sur l’application. Ce qui permet à un agent de fonctionner, agir, se remettre en état et coordonner devient alors une capacité gérée.

Ce que couvre l’infrastructure gérée

Le pari derrière cette sortie est que la plupart des exigences relatives à des agents fiables sont communes à tous les produits et non spécifiques à l’un d’eux. Quel que soit le problème métier, un agent a besoin d’un historique de ce qui s’est passé au cours de la session, d’un moyen de associer l’étape suivante au bon outil, d’une méthode pour réduire une conversation qui dépasse la limite de la fenêtre de contexte, ainsi que d’un moyen de diviser de gros travaux en parties indépendantes. Il s’agit pour l’essentiel de problèmes déjà résolus, et chaque entreprise qui les résout à nouveau dans son propre code gaspille du temps qui devrait être consacré au produit.

Centraliser cette logique dans un framework géré fournit aux développeurs une base sur laquelle s’appuyer, au lieu de devoir la créer eux-mêmes. Le framework gère le cycle du modèle : le contexte est envoyé au modèle, une décision revient, elle est exécutée, et le résultat est renvoyé en tant que nouvelle entrée. Il conserve l’état de la session afin que les tâches longues ne perdent pas les progrès réalisés précédemment. Il compresse automatiquement le contexte lorsque la session approche de la capacité maximale du modèle. De plus, il choisit quelles définitions d’outils sont pertinentes à un moment donné, épargnant ainsi au modèle des options irrelevantes.

Choisir l’endroit où l’agent travaille

Une fois la tâche, le modèle et les outils définis, une seule décision reste à prendre : où a lieu l’exécution ? Le service offre ici un véritable choix, et les compromis entre ces deux options sont plus importants que presque tout autre aspect lors de la configuration.

Espace de travail hébergé

Dans le premier scénario, OpenAI crée un environnement de travail Linux complet pour chaque session et le met en marche. Python, Node.js ainsi que des outils courants en ligne de commande sont préinstallés, ce qui permet à l’agent d’exécuter du code, de travailler avec des fichiers et de produire des résultats, sans que le développeur ait à gérer de machine virtuelle, d’image de conteneur ou de pipeline de déploiement. Les résultats des tâches terminées peuvent être convertis en artefacts immuables, utiles pour les équipes souhaitant conserver un enregistrement permanent et inaltérable de ce que chaque exécution a produit exactement.

Comme OpenAI gère l’allocation des ressources ainsi que tout le cycle de vie du environnement de test, de sa création à sa suppression, cette solution convient à un déploiement rapide. Une équipe souhaitant mettre en place un agent rapidement, sans devoir attendre des jours d’approbations internes concernant l’infrastructure ou sans avoir à écrire de scripts de déploiement, bénéficie grandement en orientant une session vers les ressources informatiques d’OpenAI. Elle convient également aux charges de travail élastiques, où le nombre d’exécutions des agents peut augmenter de manière imprévisible, et où l’équipe préfère ne pas s’occuper de la logique de mise à l’échelle. Pour l’utiliser, il suffit de définir un petit bloc d’environnement indiquant le type d’hébergement et un répertoire pour les fichiers de fonctionnalités.

"environment": {
  "type": "openai_hosted",
  "capability_directories": ["/workspace/capabilities/skills"]
}

Exécution auto-hébergée

La deuxième approche consiste à laisser l’exécution sur l’infrastructure détenue par le développeur, qu’il s’agisse d’un conteneur, d’une machine virtuelle ou d’un environnement sandbox distant fourni par un fournisseur tiers. Dans cet environnement se trouve un composant appelé serveur d’exécution, qui se connecte à OpenAI via un WebSocket. Les commandes arrivent depuis l’outil de gestion par ce lien, et le serveur d’exécution exécute des opérations en shell ainsi que des interactions via le Model Context Protocol sur la machine du développeur avant d’envoyer les résultats en retour.

Un aspect de sécurité particulièrement important est le fait que la connexion utilise une clé restreinte créée à cet effet, de sorte que la clé API au niveau de l’application, plus générale, n’a jamais besoin d’être présente dans l’environnement d’exécution. Si cet environnement était compromis, un attaquant ne trouverait qu’une identifiante ayant une portée plus restreinte que la clé d’application complète.

Le self-hébergement donne à une équipe un contrôle bien plus grand sur le matériel informatique utilisé, sur la manière d’accéder aux réseaux privés et sur l’emplacement des données. Les organisations réglementées, ainsi que les équipes dont les agents doivent accéder à des systèmes internes inaccessibles depuis Internet, ont généralement besoin de cela. Cependant, ce contrôle s’accompagne de tâches supplémentaires : l’équipe doit gérer l’isolation et les correctifs de sécurité de l’environnement, l’adaptation à la charge, la surveillance et le nettoyage une fois les sessions terminées. Lorsque l’orchestration est gérée ailleurs, tout cela reste inchangé.

Ce qui reste sous le contrôle d’OpenAI dans tous les cas

Il est tentant de penser que l’exécution auto-hébergée signifie que l’agent fonctionne entièrement au sein de l’entreprise, coupé d’OpenAI après la première requête au modèle. C’est faux. Même en mode auto-hébergé, OpenAI continue de gérer l’orchestration du côté du modèle qui décide de ce que fait l’agent à chaque étape. Seule la couche d’exécution change, c’est-à-dire les commandes réelles, la gestion des fichiers et les calculs. La boucle de raisonnement, la gestion des sessions et la logique de coordination restent du côté d’OpenAI, quel que soit l’environnement choisi par l’équipe.

Sessions longues et catalogues de outils importants

Tout système dépassant une simplicité élémentaire rencontre rapidement deux problèmes. Le premier concerne les sessions dont la longueur dépasse la fenêtre de contexte du modèle. Le second concerne des catalogues de outils si volumineux que l’envoi de chaque définition avec chaque requête consomme des tokens et ralentit le modèle. Le système géré prend en charge ces deux problèmes.

Pour les sessions longues, il compacte automatiquement le contexte précédent à mesure que la conversation approche de sa limite, en conservant ce dont l’agent a encore besoin et en éliminant ce qui est devenu irrelevant. Un flux de travail peut donc s’étendre bien au-delà d’une seule fenêtre de contexte, sans avoir recours à une synthèse manuelle ou à une logique de troncature.

Pour les tâches nécessitant de nombreux outils, une fonctionnalité appelée recherche d’outils ne présente que les définitions applicables à l’étape actuelle, ce qui réduit l’utilisation de tokens et les coûts, tout en aidant à préserver l’intégrité du cache du modèle. Une fois les outils appropriés chargés, une capacité associée permet des appels d’outils de manière programmée. L’agent peut effectuer plusieurs appels en parallèle, enchaîner des opérations liées, et filtrer ou fusionner les résultats en code, de sorte que seule la partie utile parvienne au contexte du modèle. Avec de gros volumes de données, c’est un avantage considérable, car l’agent n’a pas besoin d’analyser chaque résultat brut pour trouver les quelques faits pertinents.

La configuration énumère les outils dans le bloc agent, y compris une entrée pour un serveur MCP.

"agent": {
  "tools": [
    {
      "type": "mcp",
      "server_label": "internal_docs",
      "transport": {
        "type": "http",
        "server_url": "https://docs.example.com/mcp"
      }
    }
  ]
}

Plusieurs agents sur une tâche

La fonctionnalité la plus remarquable est sans doute le support natif pour plusieurs agents travaillant en parallèle sur une même tâche. Au lieu de faire en sorte qu’un seul agent résolve progressivement un problème complexe, le développeur peut activer le mode multi-agents et permettre à l’outil de diviser la tâche en éléments indépendants. Chacun de ces éléments est attribué à un sous-agent disposant de son propre contexte.

Chaque sous-agent se concentre sur une tâche précise sans devoir gérer l’ensemble de la tâche, tandis qu’un agent principal coordonne les efforts et fusionne les résultats en une réponse finale. Pour la recherche, les analyses à grande échelle ou le codage qui se divise en flux indépendants, cette structure permet de réduire considérablement le temps de traitement, et il n’est pas nécessaire de concevoir et de créer une couche d’orchestration pour des agents concurrents.

Pour l’activer, il suffit d’utiliser un paramètre dans la configuration de l’agent, en plus du choix du modèle.

"agent": {
  "model": "gpt-6-astra",
  "multi_agent": {
    "enabled": true,
    "max_concurrent_subagents": 3
  }
}

Quel chemin pour quelle équipe

Les deux chemins d’exécution correspondent parfaitement à deux ensembles de priorités. Les équipes qui placent la vitesse en premier et préfèrent ne pas se soucier des ressources informatiques bénéficient de sandboxes gérés. Ceux qui valident une nouvelle idée d’agent ou lancent un projet sans négocier les budgets d’infrastructure adopteront probablement plus rapidement la solution hébergée, ce qui leur fera gagner du temps en ingénierie.

L’hébergement autonome devient plus judicieux lorsque les besoins dépassent ce qu’un sandbox partagé et polyvalent peut offrir. On pense notamment aux réseaux privés auxquels l’agent doit avoir accès, aux images de machine personnalisées avec des outils propriétaires, aux ressources de calcul spécialisées telles que des configurations GPU spécifiques, ainsi qu’aux contraintes liées aux données qui empêchent l’information de quitter une juridiction ou un réseau. Dans de tels cas, la responsabilité opérationnelle supplémentaire n’est rien d’autre que le prix à payer pour agir correctement.

Qui devrait attendre

Chaque équipe n’est pas obligée de se précipiter pour adopter cette solution. Si un mécanisme existant basé sur un SDK fonctionne de manière fiable, gère correctement les tentatives répétées et ne crée que peu de difficultés pour ses mainteneurs, il y a peu de raisons de migrer. Remplacer un système qui fonctionne simplement parce qu’une alternative gérée existe a tendance à augmenter les risques sans apporter d’avantages équivalents.

La situation change lorsque l’état de session, la gestion des tentatives répétées et la logique de récupération en cas d’échec deviennent une source de consommation de ressources importante. En confiant ces tâches à un service géré qui s’en occupe déjà et qui s’améliore à chaque nouvelle version, on libère une capacité considérable pour des activités qui permettent véritablement de différencier un produit.

Une règle pratique : transférez tout ce que vous n’avez pas besoin de contrôler, et maintenez un contrôle strict sur tout ce dont dépend l’activité de l’entreprise. Cela est particulièrement important pour la topologie de déploiement, la gestion des données sensibles ainsi que pour le comportement en production d’un agent, qui doit être précis et prévisible. L’infrastructure que personne dans l’équipe ne souhaite gérer doit être déléguée. En revanche, le comportement qui définit la fiabilité d’un produit ou la position de conformité d’une entreprise ne doit pas l’être.

Fondations ouvertes

Un élément confère crédibilité à cette version : le système repose sur des fondements open source. OpenAI gère et maintient la version de production au sein du service géré, tandis que le code sous-jacent reste accessible au public. Toute personne souhaitant comprendre le fonctionnement du cycle du modèle, du choix des outils et de la coordination des sous-agents peut consulter la logique directement, sans avoir recours à la documentation. Cette transparence compense le caractère généralement fermé d’un service cloud entièrement géré et aide les équipes à avoir confiance en ce qui exécute leurs charges de travail de production.

Prix et statut bêta

La bêta publique est ouverte à tous les développeurs, sans frais de abonnement supplémentaires par rapport à l’utilisation normale. Les coûts dépendent des tokens utilisés par une session ainsi que des outils qu’elle invoque, selon les tarifs standard déjà en vigueur pour les modèles de base. Étant donné que les retours des développeurs continueront d’influencer l’évolution du service en vue de sa disponibilité générale, les premiers adoptants devraient s’attendre à des changements dans le comportement, les paramètres par défaut et les fonctionnalités au cours des prochains mois.

Une API d’Agents gérés, construite sur l’infrastructure déjà utilisée par Codex, représente un véritable changement quant à la quantité d’infrastructure qu’une équipe doit mettre en place avant qu’un agent autonome ne puisse effectuer des tâches utiles. En offrant un environnement entièrement hébergé ainsi qu’une option d’hébergement autonome bénéficiant néanmoins d’une orchestration gérée de manière centralisée, OpenAI permet aux développeurs de choisir le compromis qui convient à leur situation, sans imposer un modèle de déploiement unique à tous.

L’appel à l’adoption se résume à une question valable pour toute nouvelle couche d’infrastructure : élimine-t-elle du travail que personne ne voulait assumer, et permet-elle à l’équipe de rester pleinement en charge de ce qui définit le produit ?