Que devraient faire les utilisateurs d’Agent Builder maintenant que l’outil va disparaître?

Le 3 juin, OpenAI a ajouté une courte mise à jour à son annonce d’AgentKit : elle met fin graduellement à Agent Builder, le canevas visuel pour concevoir des agents, et à Evals, son outil hébergé pour les tester. À partir du 30 novembre 2026, ni l’un ni l’autre ne sera offert sur la plateforme d’OpenAI. OpenAI indique deux voies. Pour les flux de travail qui doivent continuer de tourner sous forme de code, elle recommande l’Agents SDK, sa bibliothèque Python pour construire des agents. Pour les tâches qu’il vaut mieux confier à des instructions en langage courant, elle recommande les Workspace Agents dans ChatGPT.

Inutile de paniquer, mais il y a une échéance. Un agent qui fonctionne aujourd’hui continuera de fonctionner jusqu’à la fin de novembre, ce qui vous laisse le temps de le migrer calmement, de tester la nouvelle version côte à côte avec l’ancienne, et de basculer seulement quand les résultats concordent.

D’abord, décidez où doit aller chaque agent

Commencez par dresser la liste de tous les agents que vous avez construits sur le canevas, puis triez-les avec une seule question : cet agent doit-il tourner à l’intérieur d’un autre logiciel, ou est-ce une personne qui le lance en demandant quelque chose?

Ensuite, consignez ce que fait le canevas

Avant de changer quoi que ce soit, documentez l’agent actuel pendant que vous pouvez encore l’ouvrir. Un canevas cache des décisions dans ses boîtes, et vous en aurez besoin par écrit. Pour chaque nœud, c’est-à-dire chaque boîte qui accomplit une tâche, notez :

1. Instructions : copiez le texte complet, pas un résumé.
2. Modèle et réglages : quel modèle, et les options de raisonnement ou de sortie.
3. Outils : recherche Web, recherche dans des fichiers, connecteurs ou vos propres fonctions.
4. Embranchements : les conditions qui envoient une demande d’un côté ou de l’autre.
5. Garde-fous : les vérifications qui bloquent ou masquent certaines entrées ou sorties.
6. Cas de test : de dix à vingt vraies demandes avec la réponse attendue pour chacune, y compris les cas délicats.

Cette dernière liste est la plus importante. C’est elle qui vous dira, plus tard, si l’agent reconstruit se comporte comme l’ancien.

Puis, remplacez Evals par votre propre script

Une évaluation (eval) est un test reproductible : un ensemble d’entrées, le résultat que chacune doit produire et une façon de noter la sortie. Vous n’avez pas besoin d’un service hébergé pour cela. Un petit script et une feuille de calcul enregistrée en CSV suffisent pour commencer. L’exemple ci-dessous suppose un agent de soutien qui classe les courriels des clients par catégorie. Le fichier cases.csv a deux colonnes, email et expected.

import csv
from pydantic import BaseModel
from agents import Agent, Runner

class Triage(BaseModel):
    category: str      # "billing", "technical" ou "other"
    reason: str

triage = Agent(
    name="Triage",
    instructions=("Lis le courriel du client. Choisis une catégorie : billing, "
                  "technical ou other. Donne une raison en une phrase."),
    output_type=Triage)

passed, failures = 0, []
with open("cases.csv", newline="", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        result = Runner.run_sync(triage, row["email"]).final_output
        if result.category == row["expected"]:
            passed += 1
        else:
            failures.append((row["email"][:60], row["expected"], result.category))

print(f"{passed} réussis, {len(failures)} échoués")
for email, want, got in failures:
    print(f"- attendu {want}, obtenu {got} : {email}...")

Deux fonctions du SDK rendent cela possible. Le réglage output_type fait renvoyer à l’agent des champs fixes que le code peut comparer, au lieu de texte libre. Et Runner.run_sync exécute une demande et renvoie le résultat dans final_output. Faites passer les mêmes cas à l’ancien agent du canevas et au nouvel agent en code, puis comparez les deux résultats.

Comment transposer un agent en code?

Reconstruisez un nœud à la fois. Chaque nœud d’agent du canevas devient un Agent en Python, avec les mêmes instructions collées et les mêmes outils rattachés. Le README du SDK décrit les bases : installez-le avec pip install openai-agents, définissez votre variable d’environnement OPENAI_API_KEY, créez un agent avec un nom et des instructions, et exécutez-le avec Runner. Vos propres fonctions Python deviennent des outils grâce au décorateur @function_tool.

Reconstruisez ensuite les flèches entre les nœuds. La documentation du SDK décrit deux styles. Dans l’orchestration par le code, votre programme appelle les agents dans un ordre fixe et vérifie chaque résultat, ce qui correspond le mieux à un canevas aux embranchements clairs. Dans l’orchestration par le modèle, un agent décide quel spécialiste appeler ou passe la conversation à un autre agent; le SDK appelle cela des transferts (handoffs). La documentation note que l’orchestration par le code est plus prévisible en vitesse, en coût et en performance : c’est donc le premier choix le plus sûr quand vous reproduisez une conception existante.

Un embranchement du canevas comme « si la catégorie est billing, envoyer à l’agent de facturation » devient une simple instruction if :

first = Runner.run_sync(triage, email).final_output
if first.category == "billing":
    reply = Runner.run_sync(billing_agent, email).final_output
else:
    reply = Runner.run_sync(general_agent, email).final_output

Enfin, faites tourner les deux versions en parallèle pendant un certain temps. Envoyez les mêmes vraies demandes à l’agent du canevas et à l’agent en code, gardez l’ancien en service et basculez seulement quand votre script d’évaluation montre que la nouvelle version réussit au moins autant de cas. Gardez le fichier CSV et le script dans le même dossier que le code de l’agent : ce sont maintenant vos Evals, et ils fonctionneront encore bien après le 30 novembre.