AgentKit et l'Agents SDK : OpenAI arme l'écosystème des agents

Le 6 octobre 2025, sur la scène de son DevDay annuel, OpenAI a dévoilé AgentKit : un ensemble de briques logicielles présenté par Sam Altman comme la manière la plus directe de faire passer un agent conversationnel du prototype à la production. Un canvas visuel où l'on assemble des étapes par glisser-déposer, une bibliothèque de composants d'interface prêts à intégrer, un registre de connecteurs et un outillage d'évaluation. Sept mois plus tôt, en mars 2025, l'entreprise avait déjà posé les fondations avec la Responses API et l'Agents SDK open source. Vu de loin, l'ensemble raconte une intention claire : abaisser la barrière technique pour quiconque veut construire un agent. Vu de près, il raconte aussi une bataille de positionnement, dont l'issue restait ouverte au moment de l'annonce — et qui a d'ailleurs connu un rebondissement notable depuis.

Cet article propose une lecture posée de cette séquence. Pas un tutoriel, pas un panégyrique : une grille d'analyse des choix industriels d'OpenAI, de leur logique, et de ce qu'ils révèlent d'un marché en pleine structuration. Nous partirons des faits établis — les annonces, leurs dates, leurs composants — avant d'en proposer une interprétation stratégique, toujours présentée comme telle. Car sur un sujet aussi mouvant que l'outillage des agents, la prudence n'est pas une coquetterie : c'est une condition de justesse.

Un mot de méthode. Ce texte distingue systématiquement ce qui est documenté (une annonce officielle, une date, une fonctionnalité) de ce qui relève de la lecture (une intention prêtée, une dynamique de marché anticipée). Les chiffres d'adoption cités par les entreprises et par OpenAI sont rapportés comme des déclarations, non comme des vérités indépendamment mesurées. Le lecteur pressé retiendra ceci : l'histoire d'AgentKit est autant celle d'une ambition d'infrastructure que celle d'un pari dont OpenAI a lui-même infléchi la trajectoire quelques mois plus tard.

Le constat : ce qu'OpenAI a réellement livré

Avant toute interprétation, il faut poser les faits avec précision. La séquence se déroule en deux temps, séparés par près de sept mois, et chacun mérite d'être décrit pour ce qu'il est.

Mars 2025 : la Responses API et l'Agents SDK

Le 11 mars 2025, OpenAI a publié deux éléments complémentaires. D'un côté, la Responses API, présentée comme une synthèse : elle combine la simplicité de l'API de complétion de chat avec la capacité d'utiliser des outils qu'offrait l'API Assistants. Elle intègre nativement trois outils — recherche web, recherche de fichiers et utilisation d'ordinateur (« computer use ») — accessibles à l'ensemble des développeurs, facturés aux tarifs standard d'OpenAI par token et par outil.

De l'autre, l'Agents SDK : une boîte à outils open source, successeur d'un projet expérimental nommé Swarm qu'OpenAI avait diffusé en octobre 2024 à visée pédagogique. Le SDK propose une approche légère, d'abord en Python puis en TypeScript, pour orchestrer des agents capables d'utiliser des outils, de se transmettre des tâches les uns aux autres (les « handoffs »), de valider entrées et sorties via des garde-fous, et d'être suivis grâce à un traçage intégré.

Un détail mérite d'être souligné, car il éclaire la suite : dès l'origine, l'Agents SDK a été conçu pour piloter aussi des modèles concurrents ou ouverts — ceux d'Anthropic, de Google, ou des familles DeepSeek, Qwen, Mistral et Llama. Autrement dit, l'outil d'orchestration ne se limite pas à l'écurie maison. Ce choix d'ouverture, nous y reviendrons, n'est pas anodin.

La filiation avec Swarm éclaire l'esprit de l'outil. Swarm, diffusé fin 2024, n'était pas destiné à la production : c'était une démonstration pédagogique, volontairement minimaliste, qui illustrait deux idées — la notion d'agent doté d'instructions et d'outils, et celle de « handoff », le transfert d'une conversation d'un agent à un autre selon la nature de la demande. L'Agents SDK reprend ce squelette conceptuel en le durcissant pour un usage réel : traçage des exécutions, garde-fous de validation, gestion des erreurs. On peut y voir la maturation d'un prototype d'idée en outil de travail. Cette continuité n'est pas qu'anecdotique : elle montre qu'OpenAI a d'abord testé publiquement des concepts d'orchestration légers, observé leur réception, puis consolidé ce qui fonctionnait. Une démarche itérative, assez éloignée de l'image d'un plan d'ensemble parfaitement arrêté d'avance.

Le contexte de l'annonce d'octobre 2025 compte également. Le DevDay est le rendez-vous où OpenAI s'adresse spécifiquement à sa communauté de développeurs — un public exigeant, qui juge sur la substance technique plus que sur l'effet de scène. Présenter AgentKit à cette occasion plutôt que dans une communication grand public envoie un signal : la cible prioritaire, ce sont les constructeurs, pas les utilisateurs finaux. Ce cadrage confirme que l'enjeu n'était pas de vendre un usage, mais d'équiper ceux qui fabriquent les usages.

Octobre 2025 : AgentKit, le paquet complet

Sept mois plus tard, au DevDay du 6 octobre 2025, OpenAI a rassemblé et étendu cette offre sous la bannière AgentKit. Le paquet réunit plusieurs composants distincts :

• Agent Builder : un canvas visuel où l'on compose la logique d'un agent en reliant des nœuds par glisser-déposer, en connectant des outils et en configurant des garde-fous personnalisés. Il prend en charge les exécutions de prévisualisation, la configuration d'évaluations en ligne et une gestion complète des versions. Il était proposé en version bêta.
• ChatKit : un ensemble de composants d'interface conversationnelle prêts à intégrer, que les développeurs habillent aux couleurs de leur produit pour insérer une expérience de discussion dans leurs applications.
• Evals for Agents : un outillage de mesure de la performance des agents, avec notation pas à pas des traces d'exécution, jeux de données pour évaluer des composants isolés, optimisation automatisée de prompts, et possibilité d'exécuter des évaluations sur des modèles externes.
• Connector Registry : un registre de connecteurs permettant de relier les agents à des outils internes et à des systèmes tiers via un panneau d'administration, dont le déploiement en bêta débutait auprès de certains clients API, ChatGPT Enterprise et Edu.

OpenAI a précisé que l'ensemble de ces outils était inclus dans la tarification standard des modèles via l'API. Il ne s'agissait donc pas d'une couche payante distincte, mais d'un habillage et d'une orchestration posés au-dessus des appels de modèles déjà facturés.

« Un ensemble complet de briques » pour mener un agent du prototype à la production avec moins de friction : telle était la formule employée pour présenter AgentKit au DevDay 2025.

Des retours d'adoption à manier avec des pincettes

Plusieurs entreprises pilotes ont été mises en avant lors de l'annonce. Il importe de rapporter ces éléments pour ce qu'ils sont — des déclarations relayées par OpenAI ou par les intéressés, non des mesures indépendantes. La société Ramp aurait construit un agent d'achat en quelques heures là où l'orchestration classique demandait auparavant plusieurs mois, en réduisant ses cycles d'itération d'environ 70 % selon le communiqué. HubSpot a indiqué s'appuyer sur AgentKit pour enrichir son assistant Breeze, capable de naviguer dans des bases de connaissances complexes. Le groupe Carlyle a évoqué, à propos de l'outillage d'évaluation, une baisse de plus de 50 % du temps de développement d'un dispositif multi-agents, assortie d'un gain de précision de l'ordre de 30 %.

Ces ordres de grandeur sont spectaculaires, et c'est précisément pourquoi il faut les traiter avec réserve. Ils émanent d'acteurs ayant intérêt à valoriser l'outil, et n'ont pas été reproduits par des tiers indépendants. On peut les lire comme des indices d'une réelle utilité dans certains contextes bien cadrés, sans en faire une loi générale. Un cycle d'itération raccourci sur un cas d'usage précis ne dit rien de la robustesse d'un agent en production sur la durée, ni de la diversité des situations où le gain se vérifie.

La lecture : une stratégie de plateforme, pas seulement d'outils

Passons maintenant de la description à l'interprétation. Ce qui suit est une grille de lecture parmi d'autres, proposée pour éclairer la logique industrielle — non pour clore le débat.

Abaisser la barrière, c'est élargir la base

La première clé de lecture tient en une phrase : en rendant la construction d'agents plus accessible, OpenAI cherche moins à séduire les seuls experts qu'à agrandir la population de ceux capables d'en fabriquer. Le canvas visuel d'Agent Builder ne s'adresse pas au développeur chevronné, déjà à l'aise avec un SDK en Python. Il vise l'équipe produit, la personne au profil hybride, l'organisation qui veut prototyper sans mobiliser d'emblée une escouade d'ingénieurs. C'est une logique bien connue de l'industrie logicielle : abaisser le coût d'entrée d'un outil, c'est multiplier le nombre de personnes qui l'adoptent, et donc le volume d'usage — ici, d'appels aux modèles facturés.

Cette lecture est cohérente avec le modèle économique affiché. Puisque AgentKit n'est pas vendu à part et repose sur la tarification des modèles, chaque agent construit et mis en service devient un générateur de consommation d'API. L'outillage n'est pas la source de revenus : il est l'entonnoir qui alimente la source de revenus. Vu sous cet angle, offrir en accès ouvert un SDK et un canvas visuel n'est pas de la générosité, c'est de la stratégie d'infrastructure — la même qui a poussé, en leur temps, tant d'acteurs à diffuser largement des outils pour verrouiller un usage payant en aval.

L'ouverture aux modèles tiers, un pari contre-intuitif

Le point le plus intéressant, dans une perspective d'analyse, est le choix d'avoir rendu l'Agents SDK compatible avec des modèles concurrents. À première vue, c'est paradoxal : pourquoi permettre à un développeur d'orchestrer, depuis votre boîte à outils, un modèle d'Anthropic ou de Google ? Une interprétation possible tient au niveau où OpenAI cherche à s'installer. En se plaçant à la couche d'orchestration — celle qui coordonne les agents, gère les handoffs, trace les exécutions — l'entreprise vise un terrain plus stratégique que la seule fourniture de modèles.

Cette lecture suggère un déplacement du centre de gravité. Si le SDK d'OpenAI devient la manière standard d'assembler des agents, peu importe à la marge quel modèle tourne en dessous : la couche qui compte, celle qui capte l'habitude et la dépendance des développeurs, c'est l'orchestration. On peut y voir un pari sur la valeur du « chef d'orchestre » plutôt que sur celle de chaque instrumentiste. C'est un pari élégant sur le papier ; reste que la couche d'orchestration est aussi la plus disputée du marché, comme nous le verrons.

Les trois briques qui trahissent la vraie douleur : le passage en production

Un dernier angle de lecture concerne le choix précis des composants. Agent Builder, ChatKit, Evals, Connector Registry : ce quatuor ne répond pas au problème de « faire un agent qui marche une fois en démonstration », déjà largement résolu. Il répond au problème, autrement plus rude, de l'industrialisation. Trois briques sont particulièrement révélatrices :

• Evals attaque la question de la mesure. Un agent qui enchaîne plusieurs étapes, appelle des outils et prend des décisions est difficile à évaluer : où, précisément, la chaîne a-t-elle dévié ? La notation pas à pas des traces vise exactement cette opacité.
• Connector Registry attaque la question de l'intégration au système d'information. Un agent utile doit se brancher sur les outils réels de l'entreprise — et le faire de manière gouvernée, avec un panneau d'administration.
• ChatKit attaque la question du dernier kilomètre : l'interface. Beaucoup de projets échouent non sur le raisonnement du modèle, mais sur l'expérience conversationnelle livrée à l'utilisateur final.

On peut lire dans ce choix une hypothèse forte d'OpenAI : la difficulté n'est plus de faire raisonner un modèle, mais de transformer ce raisonnement en produit fiable, mesurable, intégré et présentable. C'est un déplacement notable du discours. Il y a deux ans, l'attention portait sur la capacité brute des modèles ; l'outillage de 2025 déplace le projecteur vers la plomberie, la gouvernance et l'évaluation. Ce déplacement, à lui seul, en dit long sur la maturation du secteur.

Les garde-fous, révélateurs d'une préoccupation de confiance

Un élément mérite un examen à part : la place accordée aux garde-fous, ces mécanismes de validation des entrées et des sorties d'un agent. Leur présence, tant dans l'Agents SDK que dans le canvas d'Agent Builder, n'est pas décorative. Un agent qui agit — appelle des outils, effectue des transactions, écrit dans un système — n'est utile en entreprise que si l'on peut borner son comportement. Sans cadre, l'autonomie devient un problème plutôt qu'un atout.

On peut lire dans cette insistance une réponse à une objection récurrente des organisations : comment déléguer une tâche à un agent sans perdre le contrôle de ce qu'il fait ? Les garde-fous, la gestion des versions et la traçabilité pas à pas forment ensemble une réponse partielle à cette question. Elles ne suppriment pas le risque d'erreur, mais elles le rendent inspectable. Une interprétation possible : OpenAI a compris que l'adoption en entreprise se jouerait moins sur les prouesses de démonstration que sur la capacité à rassurer les directions techniques, juridiques et métier. Vendre un agent à une grande organisation, c'est d'abord lui vendre de la prévisibilité. Cette lecture rejoint le constat des entreprises pilotes, où l'un des bénéfices mis en avant tenait à la capacité de garder produit, juridique et ingénierie alignés autour d'un même plan de travail.

La bataille de l'IA agentique s'est déplacée : moins sur l'intelligence brute des modèles, davantage sur la fiabilité, la mesure et l'intégration des agents dans le réel.

La mise en perspective : OpenAI dans un marché encombré

Aucune stratégie ne se lit isolément. Pour apprécier la portée d'AgentKit, il faut le replacer dans le paysage des outils concurrents, qui s'est densifié à un rythme soutenu sur 2025 et 2026.

Une place au milieu d'un peloton fourni

Le marché des cadres d'orchestration d'agents s'est structuré autour de deux familles. D'un côté, les SDK dits « natifs », optimisés pour une famille de modèles : celui d'OpenAI, le Claude Agent SDK d'Anthropic, l'ADK de Google. De l'autre, les cadres indépendants, conçus pour fonctionner avec plusieurs fournisseurs : LangGraph, CrewAI, Smolagents, Pydantic AI, et les briques de Microsoft. Chacun cultive une spécialité.

Outil	Éditeur	Point fort mis en avant
Agents SDK	OpenAI	Simplicité, chaînes de handoffs légères
Claude Agent SDK	Anthropic	Contrôle du cycle de vie, intégration MCP poussée
ADK	Google	Multimodalité native, coopération inter-agents (A2A)
LangGraph	LangChain	Maturité en production, persistance des états
CrewAI	CrewAI	Taille de communauté, prototypage rapide
Agent Framework 1.0	Microsoft	Systèmes d'entreprise multi-langages (.NET, Python)

Ce tableau appelle une nuance immédiate : les « points forts » y sont des positionnements revendiqués, pas des verdicts de bancs d'essai indépendants. Ils donnent néanmoins une idée juste de la segmentation. Dans ce paysage, l'Agents SDK d'OpenAI est régulièrement décrit comme le plus simple — un atout pour démarrer vite, une limite éventuelle pour les orchestrations très complexes, où LangGraph et sa modélisation en graphe explicite sont souvent préférés. La simplicité est une proposition de valeur assumée, pas une supériorité universelle.

Le rythme des annonces : une rivalité qui s'accélère

La densité de ce calendrier mérite qu'on s'y arrête, car elle révèle l'intensité de la concurrence. En avril 2026, Microsoft a rendu généralement disponible son Agent Framework 1.0, fusionnant deux projets antérieurs (AutoGen et Semantic Kernel) en un SDK unique. Anthropic, de son côté, a fait évoluer la structure économique de son Claude Agent SDK au fil de 2026. La cadence est telle que certains observateurs ont noté qu'OpenAI et Anthropic avaient livré des réponses très proches au même problème d'orchestration à quelques jours d'intervalle.

Une interprétation raisonnable de cette synchronie : les grands acteurs convergent vers une même lecture du besoin. Tous ont compris, à peu près en même temps, que la valeur se déplaçait vers l'outillage de production. Cette convergence est plutôt bon signe pour les utilisateurs — elle promet des standards partagés et une interopérabilité croissante, notamment autour de protocoles communs comme le MCP pour brancher des outils, ou l'A2A pour faire dialoguer des agents entre eux. Mais elle signifie aussi qu'aucun acteur ne dispose d'un avantage durable garanti sur cette couche. La position d'OpenAI y est forte, sans être imprenable.

Le protocole plutôt que le produit ?

Cette dynamique de convergence invite à une hypothèse plus large. Peut-être la question centrale n'est-elle pas « quel outil va s'imposer », mais « quels protocoles vont s'imposer ». Si l'industrie s'accorde sur des standards ouverts de connexion d'outils et de communication entre agents, l'orchestration devient un terrain interchangeable, et la différenciation se déplace ailleurs — vers la qualité des modèles, la gouvernance, ou l'expérience développeur. Dans cette lecture, la vraie bataille se joue à un niveau que les canvas visuels et les SDK ne font qu'effleurer. C'est une hypothèse, pas une prédiction ; elle a le mérite de rappeler que le nom du gagnant compte peut-être moins que la nature des règles du jeu.

Le protocole MCP (Model Context Protocol) illustre bien ce mouvement. Conçu pour normaliser la manière dont un agent se branche sur des outils et des sources de données, il a été adopté à des degrés divers par la plupart des cadres du marché — nativement chez certains, via des adaptateurs chez d'autres. L'intérêt d'un tel standard est double. Pour le développeur, il évite de réécrire des connecteurs à chaque changement d'outil. Pour l'écosystème, il crée un langage commun qui rend les briques interopérables. Or le Connector Registry d'AgentKit s'inscrit précisément dans cette logique de branchement gouverné. On peut y lire une reconnaissance implicite : même un acteur en position de force a intérêt à jouer la carte de l'interopérabilité, parce que c'est l'interopérabilité qui rassure les entreprises et accélère l'adoption. Fermer complètement son écosystème serait, à ce stade, contre-productif.

Une nuance s'impose toutefois. L'adhésion à des protocoles partagés n'abolit pas toute différenciation. Un standard fixe une interface commune, pas une qualité commune. Deux implémentations d'un même protocole peuvent offrir des performances, une sécurité ou une ergonomie très différentes. La standardisation déplace la concurrence, elle ne l'abolit pas. C'est une distinction essentielle, souvent négligée dans les analyses trop rapides : parler la même langue ne rend pas les interlocuteurs équivalents.

La question du verrouillage, sans procès d'intention

Une objection revient dès qu'un grand acteur diffuse largement un outil : ne cherche-t-il pas, in fine, à enfermer les développeurs dans son écosystème ? La question est légitime, et mérite une réponse équilibrée plutôt qu'un procès d'intention. D'un côté, l'ouverture de l'Agents SDK aux modèles tiers et l'adhésion aux protocoles partagés jouent contre l'hypothèse d'un enfermement pur et dur : un développeur peut, en théorie, migrer une partie de son architecture. De l'autre, l'habitude, la documentation, l'intégration fine avec la Responses API et l'écosystème d'outils maison créent une force d'inertie réelle. Le coût de sortie n'est jamais nul.

La lecture la plus juste est probablement intermédiaire. OpenAI ne construit pas une prison, mais un environnement confortable dont on ne sort pas sans effort. C'est le propre de toute plateforme réussie : moins retenir par la contrainte que par la commodité. Cette observation vaut d'ailleurs pour l'ensemble des grands fournisseurs, pas pour OpenAI en particulier. Elle invite simplement le praticien à garder à l'esprit, au moment de choisir un outillage, la question du coût de réversibilité — un réflexe de prudence, ni plus ni moins.

Le rebondissement : quand l'éditeur infléchit son propre pari

Un article d'analyse écrit à chaud aurait pu s'arrêter là. Mais le recul permis par plusieurs mois change la donne — et illustre pourquoi la prudence s'imposait dès le départ.

Le 3 juin 2026 : l'arrêt programmé d'Agent Builder et d'Evals

Le 3 juin 2026, OpenAI a publié des avis de dépréciation pour deux des composants phares d'AgentKit : le canvas visuel Agent Builder et la plateforme Evals. Le calendrier annoncé prévoyait le passage d'Evals en lecture seule le 31 octobre 2026 — avec invitation à exporter ses jeux de données avant cette date — puis le retrait des deux produits de la plateforme au 30 novembre 2026. ChatKit, en revanche, restait maintenu. Les chemins de migration recommandés pointaient vers l'Agents SDK, plus orienté code, pour remplacer le canvas visuel, et vers des outils tiers pour l'évaluation.

Ce fait est capital pour toute lecture honnête d'AgentKit. Le composant le plus emblématique de l'annonce d'octobre 2025 — celui qui incarnait le mieux la promesse « construire un agent sans coder » — a été mis en extinction moins de huit mois après son lancement. Il faut le dire sans dramatiser ni pavaner : ce genre d'ajustement rapide n'a rien d'exceptionnel dans un secteur qui expérimente à grande vitesse, et l'existant continuait de fonctionner pendant toute la fenêtre de transition. Mais le fait est là, et il recadre l'interprétation.

Ce que ce recul enseigne

Quelle leçon en tirer, avec mesure ? Plusieurs lectures cohabitent, et il serait présomptueux d'en imposer une seule.

• Une lecture « recentrage » : OpenAI aurait constaté que le canvas visuel séduisait moins durablement que le SDK orienté code, et choisi de concentrer ses efforts sur ce dernier. Le pari « no-code » aurait été un test de marché, jugé moins porteur que l'approche par le code.
• Une lecture « standardisation » : en renvoyant l'évaluation vers des outils tiers, OpenAI reconnaîtrait implicitement que cette couche a vocation à être partagée plutôt que captée. Cela rejoint l'hypothèse des protocoles ouverts évoquée plus haut.
• Une lecture « prudence d'analyste » : elle confirme surtout qu'aucune annonce, si soigneusement mise en scène soit-elle, ne vaut engagement pérenne. Ce qui est présenté un jour comme une brique fondatrice peut être réorienté le lendemain.

La troisième lecture est sans doute la plus solide, parce qu'elle ne parie sur rien. Elle rappelle une discipline salutaire : distinguer l'effet d'annonce de la trajectoire réelle, et se garder de transformer un lancement en certitude d'avenir. C'est précisément la promesse d'une lecture par les signaux faibles — observer les mouvements sans les surinterpréter, et accepter que la carte se redessine.

Ce qu'on peut en retenir

Au terme de ce parcours, quelques enseignements se dégagent, tous formulés avec la nuance qu'impose un sujet aussi vivant.

Premier enseignement : la valeur s'est déplacée vers l'outillage de production. La séquence Responses API, Agents SDK puis AgentKit montre qu'en 2025, l'enjeu affiché n'était plus la seule puissance des modèles, mais la capacité à en faire des produits fiables, mesurables et intégrés. Ce déplacement est probablement l'observation la plus robuste de tout ce dossier, car plusieurs acteurs l'ont opéré en parallèle. Il traduit une maturation authentique du secteur.

Deuxième enseignement : l'accessibilité est une arme d'infrastructure. En proposant SDK et canvas en accès ouvert, adossés à la tarification des modèles, OpenAI a articulé son outillage à son modèle économique. On peut lire l'ensemble comme un entonnoir cohérent : élargir la base des constructeurs d'agents pour nourrir l'usage payant des modèles. Cette logique reste valable même après le retrait du canvas visuel, puisque le SDK, lui, demeure.

Troisième enseignement : la couche d'orchestration est disputée, et le restera. Entre les SDK natifs des grands fournisseurs et les cadres indépendants, aucun acteur ne tient de position acquise. La convergence des annonces sur 2025-2026 suggère que la différenciation pourrait, à terme, se déplacer vers les protocoles partagés plutôt que vers les outils propriétaires. C'est une piste, pas un verdict.

Quatrième enseignement, le plus important : l'humilité analytique paie. Le retrait d'Agent Builder, annoncé en juin 2026 pour un composant lancé en octobre 2025, rappelle qu'il faut lire ces stratégies au présent, sans les figer en prophéties. Un article écrit le jour de l'annonce aurait pu célébrer une brique fondatrice qui n'a pas tenu un an. La bonne posture n'est pas de prédire, mais d'observer, de sourcer, et de laisser la réalité corriger les hypothèses.

Reste une question, pour qui n'est ni développeur ni stratège : que faut-il concrètement retenir de tout cela ? Sans doute l'idée que la construction d'agents entre dans une phase d'outillage, où l'accès s'élargit mais où la fiabilité reste le vrai défi. Pour une organisation qui envisage de se lancer, la leçon utile n'est pas de courir vers le dernier outil annoncé, mais d'évaluer d'abord ses besoins réels : quel processus mérite d'être confié à un agent, comment en mesurer la qualité, comment le brancher sur l'existant sans tout reconstruire. Les briques comme AgentKit rendent ces questions plus faciles à explorer ; elles ne les remplacent pas. Et l'épisode du retrait rappelle qu'il vaut mieux miser sur des compétences et des méthodes durables que sur un produit particulier, dont la trajectoire échappe à ceux qui l'adoptent. Bâtir sur du sable un peu plus meuble reste bâtir sur du sable ; c'est l'ossature qui tient, pas le décor.

AgentKit et l'Agents SDK resteront, quoi qu'il advienne, un marqueur : celui d'un moment où l'industrie de l'IA a cessé de ne parler que de modèles pour commencer à parler de plomberie, de mesure et de mise en service. C'est peut-être là le vrai signal faible de cette séquence — moins spectaculaire qu'un nouveau modèle, mais bien plus structurant. Reste à voir quelles briques, parmi toutes celles posées ces deux dernières années, tiendront la distance. Sur ce point, la seule réponse honnête est : observons.

Sources

• OpenAI — Introducing AgentKit (annonce officielle, 6 octobre 2025)
• OpenAI — New tools for building agents : Responses API et Agents SDK (11 mars 2025)
• TechCrunch — OpenAI launches AgentKit to help developers build and ship AI agents
• VentureBeat — OpenAI unveils Responses API and open source Agents SDK
• OpenAI — Deprecations (avis de dépréciation Agent Builder et Evals, juin 2026)
• TheRouter.ai — OpenAI Evals, Agent Builder and Prompts deprecation (calendrier novembre 2026)
• Requesty — Best AI Agent SDKs Compared 2026 (LangGraph, CrewAI, OpenAI, Anthropic, Google ADK)
• VentureBeat — OpenAI unveils AgentKit that lets developers drag and drop to build AI agents (retours Ramp, HubSpot, Carlyle)