OpenAI Agents SDK pour PME : retour terrain et comparaison honnête avec Claude Agent SDK

TL;DR

• OpenAI Agents SDK a publié sa version TypeScript en mars 2026, atteignant parité de features avec la version Python sortie un an plus tôt.
• Le SDK est lightweight, provider-agnostic (100+ modèles supportés), et brille sur les patterns handoff (un agent passe la main à un spécialiste) et guardrails (validation en parallèle).
• L'update d'avril 2026 a ajouté un harness natif (file ops, code execution, shell) et le sandboxing sur 7 providers : E2B, Modal, Cloudflare, Daytona, Runloop, Vercel, Blaxel.
• Pour une PME, le SDK est pertinent sur les cas multi-spécialistes (support, sales triage, classification par domaine). Pour les agents qui font une seule décision avec beaucoup d'outils, Claude Agent SDK reste plus direct.
• Coût API observé sur 3 projets en production en 2026 : 90 à 230 EUR par mois avec GPT-5.4 pour 200 à 500 exécutions par jour.

Pourquoi le SDK OpenAI mérite un regard sérieux en 2026

On a publié il y a quatre jours un guide pratique sur le Claude Agent SDK pour PME. Les questions reçues depuis tournent autour du même axe : "et OpenAI Agents SDK, on l'oublie ou pas ?" Réponse courte : non, surtout depuis le SDK TypeScript de mars 2026 et l'ajout du harness natif en avril.

Le SDK Python d'OpenAI existe depuis début 2025 et était jusqu'ici limité à des équipes data/ML. La version JavaScript/TypeScript de mars 2026 a changé la donne pour les studios qui livrent du Next.js, Vercel, Node : on a maintenant deux SDKs agents matures, deux écosystèmes MCP fonctionnels, et un choix réel à faire en avant-vente. Notre studio a livré trois projets PME sur la stack OpenAI Agents SDK depuis avril 2026 (un agent de routing support, un agent de scoring inbound, un agent d'analyse de PDFs juridiques). Cet article ramasse ce qu'on en a appris.

Ce que le SDK fait, en une lecture

L'architecture du SDK repose sur cinq primitives qu'on retrouve dans toute documentation officielle, et qu'on liste ici dans l'ordre d'importance pratique pour une PME.

Agent : la brique de base. Un agent c'est un modèle (GPT-5.4 par défaut sur nos projets), un prompt système, une liste de tools, et une liste optionnelle de sub-agents en handoff. Le code minimal tient en 6 lignes.

Handoffs : un agent peut passer la main à un autre. Techniquement, le handoff est exposé au LLM comme un tool (par exemple transfer_to_refund_agent). Sur un cas client PME en mai 2026 (un éditeur logiciel B2B 45 salariés), on a un agent de tri qui passe la main soit à un agent facturation, soit à un agent technique, soit à un agent commercial. La logique de routing tient dans le prompt du triage agent, pas dans du code business.

Guardrails : validations input et output qui tournent en parallèle de l'agent. Le SDK fait du fail-fast : si le guardrail input rejette, l'agent ne tourne même pas. Utile pour bloquer les inputs hors-scope avant de consommer des tokens. Détail à connaître : les handoffs passent par un pipeline distinct de celui des function tools, donc les guardrails tool-level ne s'appliquent pas au handoff call lui-même.

Tracing : observabilité native via le dashboard OpenAI. Activé par défaut, désactivable par variable d'env OPENAI_AGENTS_DISABLE_TRACING=1 ou en code via set_tracing_disabled(True). Chaque run laisse une trace structurée (LLM calls, tool calls, handoffs, guardrails, événements custom).

MCP : depuis la version TypeScript de mars 2026, le SDK supporte les trois transports MCP (stdio, SSE, HTTP) et toute la surface du protocole. On peut brancher les MCP officiels (Notion, Slack, GitHub) ou des serveurs custom. Pour les modèles qui supportent l'API Responses, le SDK ajoute en plus les HostedMCPTool : OpenAI héberge le MCP de votre côté et le facture au prix du modèle.

Le tout pèse moins de 5000 lignes de code TypeScript, ce qui en fait un SDK explicitement lightweight (volontairement plus minimal que LangChain ou LlamaIndex).

OpenAI Agents SDK vs Claude Agent SDK : la vraie comparaison

C'est la question principale qu'on nous pose. La majorité des comparatifs en ligne tirent vers le marketing. Voici la version qu'on défend en avant-vente, basée sur les projets qu'on a livrés sur chaque stack.

Trois observations qui n'apparaissent pas dans les tableaux marketing.

D'abord, le SDK OpenAI est plus lisible pour un dev senior qui découvre l'agentique. Le pattern handoff est conceptuellement plus simple que les hooks Claude (qui demandent de comprendre la boucle agentique pour les utiliser correctement). Sur deux projets clients en 2026, on a fait coder l'agent par un dev junior du client après formation : avec OpenAI, on a tenu en 3 jours. Avec Claude, il a fallu une semaine.

Ensuite, Claude reste devant sur le raisonnement complexe. Sur le projet d'analyse de PDFs juridiques en avril 2026 (cabinet d'avocats 18 salariés, lecture de contrats fournisseurs), on a benché GPT-5.4 et Claude Sonnet 4.6 sur 80 cas annotés. Sonnet a une précision supérieure de 7 à 12 points selon la catégorie de contrat. Ce delta justifie le surcoût quand le client signe juridiquement sur la sortie.

Enfin, le tracing OpenAI accélère le debug. Sur un incident de prod en mai 2026 (un agent qui boucle sur un cas spécifique), le dashboard Traces nous a sorti le run problématique en 4 minutes. En équivalent Claude (sans Langfuse branché), on aurait perdu une heure à parser les logs JSON. Si vous démarrez sur Claude sans Langfuse, vous payez ce coût tôt ou tard.

Architecture type sur un projet PME : exemple support routing

Sur le projet d'éditeur logiciel B2B de mai 2026, on a livré un agent de routing pour leur support de niveau 1. Le client recevait 60 à 80 tickets par jour, 40% étaient mal triés et finissaient sur la mauvaise équipe (perte mesurée : 12 heures par semaine de re-routing manuel). Stack OpenAI Agents SDK en TypeScript, déployée sur Vercel.

import { Agent, run } from '@openai/agents';

const billingAgent = new Agent({
  name: 'Billing Agent',
  instructions: 'Tu réponds aux questions facturation : factures, échéances, abonnement, remboursements. Si la question dépasse ton scope, tu indiques au triage agent que tu redonnes la main.',
  model: 'gpt-5.4',
  tools: [stripeReadTool, notionWriteTool],
});

const technicalAgent = new Agent({
  name: 'Technical Agent',
  instructions: 'Tu réponds aux questions techniques : bugs, API, intégrations, downtime. Tu cherches dans la documentation produit avant de répondre.',
  model: 'gpt-5.4',
  tools: [docsSearchTool, notionWriteTool],
});

const triageAgent = new Agent({
  name: 'Triage Agent',
  instructions: 'Tu lis le contenu du ticket et tu transfères à billing, technical ou commercial. Si le ticket est inclassable, tu écris une réponse demandant clarification.',
  model: 'gpt-5.4-mini',
  handoffs: [billingAgent, technicalAgent, commercialAgent],
});

const result = await run(triageAgent, ticketContent, {
  maxTurns: 6,
});

Trois choix concrets dans ce code, qui méritent d'être explicités.

Le triage agent tourne sur GPT-5.4 Mini (le tarif n'est pas public au moment où j'écris, mais OpenAI annonce un facteur 5 à 10 moins cher que GPT-5.4 standard). Pour un classifieur qui choisit parmi 3 catégories, c'est suffisant. Tester d'abord sur le modèle le plus petit, monter en gamme seulement si la précision dérape sous le seuil acceptable.

Les agents spécialistes tournent sur GPT-5.4 standard. Sur le scoring de 200 tickets historiques, la précision a été de 87% avec GPT-5.4 vs 74% avec GPT-5.4 Mini sur l'agent billing. Le différentiel justifie le coût.

Le paramètre maxTurns: 6 plafonne la boucle. C'est notre garde-fou universel : sans ça, un cas atypique peut générer 20 tours d'aller-retour entre agents et exploser le coût. Sur le projet, on a observé une moyenne de 2.3 tours par ticket, jamais plus de 5.

Coûts réels mesurés sur 3 projets PME en 2026

Voici les chiffres consolidés sur les missions livrées par notre studio entre mars et mai 2026, modèle par défaut GPT-5.4, tracing natif OpenAI plus Langfuse self-hosted.

Plusieurs choses ressortent.

Le coût par ticket support est plus élevé que ce qu'on observe sur les classifications simples (0.043 EUR contre 0.015 EUR sur l'équivalent Claude classification). C'est mécanique : un routing avec handoff fait deux runs (triage puis spécialiste), donc deux factures de tokens. Si on collapse triage et réponse en un seul agent (sans handoff), on tombe à 0.025 EUR mais on perd la lisibilité dans les traces et la séparation des prompts.

Le scoring inbound sort à un coût comparable au Claude Agent SDK. Pas de surprise, c'est un cas où la spécialisation OpenAI ou Claude ne change pas grand-chose. Le choix entre les deux SDKs se fait alors sur d'autres critères (préférence du dev, écosystème existant chez le client).

L'analyse PDF est chère parce que les contrats font 8 à 30 pages, soit 6000 à 25000 tokens d'input par run. C'est un cas où on a testé le Flex pricing (50% off avec latence variable) : ça nous a fait passer le coût mensuel de 228 EUR à 124 EUR. Le client a accepté une latence de 1 à 4 minutes par contrat (au lieu de 8 secondes en standard) parce que le batch tourne la nuit.

Sur le Batch API (50% off avec garantie sous 24h), on n'a pas encore testé pour de la prod PME, mais on l'envisage sur le projet cabinet d'avocats si la latence n'est plus un enjeu.

Les 4 pièges qu'on a vus revenir

Piège 1 : confondre handoff et tool call

Le pattern handoff change la propriété de la conversation. Une fois que le triage agent passe la main au billing agent, ce dernier devient l'interlocuteur unique du user pour la suite. Si vous voulez juste que l'agent appelle une fonction utilitaire (et reprenne la main), c'est un tool, pas un handoff.

Sur un projet en avril 2026, le client a livré son agent en handoff "à tout va" : 6 agents spécialistes, chacun pouvait passer la main à tous les autres. Résultat : un cas test sur 11 où l'agent ping-pongait entre 3 spécialistes avant de répondre, 4 tours pour finalement échouer. On a refait l'archi avec un triage agent unique en entrée et 3 spécialistes en feuilles, plus de ping-pong.

Solution : limitez les chaînes de handoff à 2 niveaux maximum, hub and spoke plutôt que mesh.

Piège 2 : guardrails qui filent sur les handoffs

Comme rappelé en début d'article, les guardrails tool-level ne s'appliquent pas aux handoff calls. Sur un projet en avril 2026, on avait branché un guardrail input qui filtrait les tickets en langue étrangère vers une file manuelle. Le guardrail tournait sur le triage agent, mais une fois le handoff effectué, le specialist agent recevait l'input filtré (pas le filtre lui-même), et le client avait l'impression que tout était filtré.

Solution : si un guardrail doit s'appliquer post-handoff, on le duplique au niveau de chaque specialist agent. Verbeux, mais sûr.

Piège 3 : tracing désactivé en prod par paranoia data

Plusieurs CTO PME nous ont demandé de désactiver le tracing OpenAI "parce qu'il envoie des données chez OpenAI". C'est un faux ami : le tracing envoie ces données aux mêmes endpoints OpenAI que les calls modèles. Si vous acceptez d'envoyer le prompt à GPT, vous acceptez déjà les conditions d'OpenAI. Désactiver le tracing vous prive d'un debug essentiel sans réelle protection supplémentaire.

Solution : laisser le tracing actif. Si la donnée est vraiment sensible, c'est tout le projet qui ne devrait pas tourner sur OpenAI (passer Azure OpenAI avec hébergement EU ou un modèle local).

Piège 4 : confondre lightweight avec "rien à monitorer"

Le SDK est volontairement minimal, ce qui peut donner l'impression qu'on n'a plus de gros sujets ops. C'est faux. Vous avez toujours à gérer : le secret OPENAI_API_KEY, les rate limits, le quota par environnement, l'alerting sur coût anormal, le replay d'un cas qui a foiré.

Sur le cabinet d'avocats en avril 2026, on a oublié de monter une alerte sur dépassement de quota. Un cas particulier (un contrat de 92 pages, soit 80000 tokens en input) a généré une facture mensuelle de 410 EUR au lieu des 228 prévus. Le client n'a pas vu d'incident, juste un débit anormal qu'on a expliqué deux semaines plus tard.

Solution : un dashboard simple en début de projet (PostHog ou un Notion connecté en webhook), avec une alerte Slack ou Telegram dès que le coût journalier dépasse 1.5x la moyenne hebdo.

Quand choisir OpenAI Agents SDK sur un projet PME

Sur la base des 3 projets livrés en 2026, voici l'arbre de décision qu'on utilise en avant-vente.

Choisir OpenAI Agents SDK si : le cas implique du routing multi-spécialistes (3 ou plus), ou le client a déjà tout son tooling sur OpenAI, ou le projet inclut une couche voice (call bots, transcription temps réel), ou le client veut explicitement la flexibilité de pouvoir basculer entre fournisseurs.

Choisir Claude Agent SDK si : le cas demande un raisonnement long et profond sur un input unique (analyse de document, synthèse RH, audit technique), ou le client veut le meilleur dispositif de hooks pour la validation humaine pendant les 4 premières semaines, ou la précision sur les cas limites est critique (médical, juridique, finance).

Ne pas trancher au SDK : si vous hésitez après 30 minutes d'analyse, c'est que le cas n'est probablement pas le bon levier pour l'agentique. Demandez-vous d'abord si un workflow Make ou n8n suffit (voir n8n vs Make vs Zapier vs Cowork).

Sur les 7 derniers projets PME de notre studio (4 Claude, 3 OpenAI), on n'a jamais eu à migrer d'un SDK à l'autre en cours de route. Le choix initial a tenu sur la durée. Ce qui se passe en revanche, c'est qu'on migre parfois le modèle sous-jacent (GPT-5.4 vers GPT-5.4 Mini, Sonnet 4.6 vers Haiku 4.5) au mois 2 ou 3 quand la mesure le justifie.

Pour aller plus loin

Si vous voulez creuser la décision avant de prototyper, ces guides répondent en amont à beaucoup de questions :

Claude Agent SDK pour PME : guide pratique

Déployer un agent IA en production dans une PME : guide complet 2026

Cas 001 : qualifier les leads d'un SaaS B2B avec un agent Claude

Et si vous voulez qu'on regarde votre cas ensemble avant de coder, on prend 4 nouveaux projets par mois. Réserver un appel découverte.