<h2>OpenAI AgentKit Deep Dive : Une évaluation technique</h2>
Perspective de l'auteur : Pourquoi est-il « puissant mais pas parfait » ? Comment coexiste-t-il avec Dify/n8n, et dans quels scénarios excelle-t-il ?
<h3>1. Résumé exécutif (Conclusions d'abord)</h3>
<ul>
<li>
« Dify est mort / n8n sera remplacé » est un jugement émotionnel. Le « workflow » d'OpenAI s'apparente davantage à une plateforme intégrée pour le développement, l'évaluation, le déploiement et l'intégration d'Agents (AgentKit + Agent Builder + Evals + UI intégrée), positionnée non pas comme un bus d'automatisation d'entreprise universel.
</li>
<li>
Avantages concrets : Composants d'Agents natifs, orchestration visuelle avec gestion des versions, évaluation intégrée (Evals), UI intégrée, connecteurs officiels et gouvernance de la sécurité, réduisant considérablement les frictions du « prototype à la production ».
</li>
<li>
Mais ce n'est pas un remplaçant direct de Dify/n8n : Coûts de migration et d'apprentissage élevés pour les systèmes existants ; le paradigme reste celui du « workflow basé sur des nœuds », ce qui n'est pas une rupture fondamentale avec l'orchestration traditionnelle.
</li>
<li>
Les utilisateurs réels se trouvent principalement dans le « marché incrémental » : Nouveaux projets, équipes implémentant des Agents pour la première fois, équipes ayant besoin d'une mise sur le marché rapide et de boucles d'évaluation.
</li>
<li>
L'avenir appartient à l'architecture de code native de l'IA (AI-native) ; les workflows ne sont qu'un état temporaire.
</li>
</ul>
<h3>2. Qu'est-ce que le nouveau « Workflow » d'OpenAI exactement ?</h3>
Officiellement appelé AgentKit (incluant Agent Builder, etc.). Le cœur du concept est de regrouper la chaîne de valeur, auparavant dispersée, de « l'orchestration, l'intégration d'outils, l'évaluation et l'intégration front-end » dans une plateforme unifiée : vous pouvez construire des processus basés sur des nœuds sur un canevas (double approche code/visuel), connecter des outils et des connecteurs, exécuter des évaluations intégrées (Evals) et produire rapidement des formes de produits avec une interface utilisateur intégrée.
<ul>
<li>
Agent Builder : Canevas visuel avec des nœuds comprenant des appels de modèles, des outils/MCP/connecteurs, des conditions/boucles et des garde-fous (guardrails), avec prise en charge du versioning et des simulations (dry-runs).
</li>
<li>
Agents SDK : Approche orientée code, isomorphe au canevas ; les deux sont basés sur la même abstraction de réponse/runtime (facilitant la collaboration d'équipe « WYSIWYG vs code »).
</li>
<li>
Evals for Agents : Évaluation intégrée dans la boucle de développement, prenant en charge les comparaisons de référence (baseline), de régression et A-B, évitant la « mise en production au feeling ».
</li>
<li>
UI intégrée (comme ChatKit/Apps SDK) : Réduit l'ingénierie front-end de l'interface, permettant d'intégrer rapidement des Agents dans des produits existants ou de les exécuter au sein de ChatGPT.
</li>
<li>
Connecteurs et Sécurité : Écosystème géré officiellement, réduisant les risques de conformité et de sécurité liés aux scripts non officiels.
</li>
</ul>
<h3>3. Différences de positionnement et comparaison avec Dify/n8n</h3>
<ol>
<li>
Positionnement : OpenAI poursuit une « plateforme de développement native d'Agents » ; Dify/n8n sont davantage des hubs universels d'automatisation et d'orchestration avec une connectivité plus large.
</li>
<li>
Limites : OpenAI excelle dans le « guichet unique pour transformer les Agents en produits » (orchestration → évaluation → intégration → production) ; Dify/n8n excellent dans « l'intégration systématique à l'intérieur et à l'extérieur de l'entreprise et l'écosystème de déclencheurs (triggers) ».
</li>
<li>
Ingénierie : Les Evals et le versioning rendent la convergence de la qualité des Agents mesurable, ce qui est un point faible des plateformes d'automatisation traditionnelles.
</li>
<li>
Migration : Pour les équipes disposant d'un grand nombre de nœuds/processus personnalisés, le ratio valeur/risque d'une migration à court terme n'est pas élevé ; une approche plus réaliste consiste à accéder aux nouvelles capacités par contournement.
</li>
</ol>
<h3>4. Pourquoi est-il « fort mais pas un remplaçant » ?</h3>
<ul>
<li>
Dépendance au sentier des systèmes existants : Des années de bibliothèques de nœuds accumulées, d'opérations et de normes organisationnelles ne migreront pas entièrement à cause d'une nouvelle plateforme.
</li>
<li>
Le paradigme n'a pas fondamentalement changé : Toujours piloté par des « nœuds + graphes orientés » ; les processus métier complexes nécessitent toujours que les développeurs encapsulent des nœuds personnalisés et des règles de gouvernance.
</li>
<li>
Étendue de l'écosystème : En termes de « connexion à plus de 1000 SaaS sur le web », il est difficile d'égaler l'étendue des plateformes d'automatisation établies à court terme.
</li>
</ul>
<h3>5. Qui sont les utilisateurs réels (Marché incrémental) ?</h3>
<ul>
<li>
Nouveaux projets/équipes abordant les Agents pour la première fois : Besoin de transformer rapidement un PoC en une forme prête pour la production.
</li>
<li>
Organisations mettant l'accent sur les boucles d'évaluation et l'hébergement sécurisé : Besoin de prioriser la « qualité et la gouvernance ».
</li>
<li>
Équipes espérant distribuer/exécuter des applications directement dans ChatGPT : Exploiter les Apps/UI intégrées pour atteindre les utilisateurs plus rapidement.
</li>
</ul>
<h3>6. Analyse technique : Comment fonctionne le workflow ?</h3>
Couche de processus : Nœuds du canevas = appels (LLM/outils/connecteurs) + flux de contrôle (conditions/boucles/parallèle) + garde-fous (contraintes/validation).
Couche Runtime : Qu'elle soit visuelle ou en code, elle correspond finalement à une abstraction unifiée de réponse/exécution (facilitant le versioning et la traçabilité).
Couche d'évaluation (Evals) : Établir des ensembles de tâches et des métriques d'assertion pour les chemins clés ; tout changement fait d'abord l'objet d'un test de référence/régression ; les artefacts intermédiaires des conversations/appels d'outils sont également archivés pour comparaison.
Couche d'intégration : Basée sur des composants (comme ChatKit/Apps SDK), elle expose les Agents sous une « forme produit » aux utilisateurs finaux, avec gestion de l'état de la conversation et contrôle d'accès.
<h3>7. « Le No-Code est pour les novices » est une proposition fausse</h3>
Les interfaces graphiques abaissent le seuil de construction mais ne génèrent pas automatiquement une décomposition raisonnable des tâches et une gouvernance des limites. Des processus stables et maintenables nécessitent toujours que les développeurs contrôlent l'abstraction, le retour en arrière (rollback), l'observabilité et l'évaluation. Le workflow d'OpenAI réduit les frictions d'ingénierie mais n'élimine pas l'ingénierie elle-même.
<h3>8. Ce n'est pas encore véritablement AI-Native : Lacunes et perspectives</h3>
<ul>
<li>
Considère toujours les « processus pré-câblés » comme des citoyens de première classe : Espace limité pour l'auto-organisation/l'auto-évolution.
</li>
<li>
Les nœuds personnalisés restent lourds : Les besoins métier complexes nécessitent de maintenir des bibliothèques de fonctions/politiques, les coûts de gouvernance ne sont pas négligeables.
</li>
<li>
Direction plus AI-Native : Faire de l'approche « objectif—politique—preuve » des citoyens de première classe, introduire une sémantique comportementale vérifiable et un runtime piloté par des contraintes.
</li>
</ul>
Idées de référence et pratique continue : Axon (cœur : planification auto-réflexive, piloté par les contraintes, sémantique vérifiable) — <a href="https://github.com/nxcode-io/Axon">https://github.com/nxcode-io/Axon</a>
<h3>9. Recommandations de mise en œuvre pour différentes équipes</h3>
Équipes utilisant déjà Dify/n8n : Ne vous précipitez pas pour migrer. Utilisez d'abord l'évaluation et l'UI intégrée d'OpenAI comme « capacités externes », accédez-y depuis la plateforme d'origine, et mesurez les bénéfices avant d'envisager de migrer les chaînes liées aux Agents.
Nouveaux projets/équipes incrémentales : Si l'objectif est de « livrer des agents comme des produits », priorisez la voie AgentKit pour obtenir rapidement des formes prêtes pour la production et des systèmes de métriques.
Équipes poursuivant l'AI-Native : Concevez des mécanismes d'« évaluation comme gouvernance », affaiblissez le « pré-câblage », renforcez les « objectifs et preuves », avec un runtime privilégiant les politiques/contraintes comme noyau central.
<h3>Références et liens</h3>
[1] OpenAI | Introducing AgentKit: <a href="https://openai.com/index/introducing-agentkit/">https://openai.com/index/introducing-agentkit/</a>
[2] OpenAI | Build every step of agents on one platform (Agent Platform): <a href="https://openai.com/agent-platform/">https://openai.com/agent-platform/</a>
[3] OpenAI | DevDay 2025: <a href="https://openai.com/devday/">https://openai.com/devday/</a>
[4] OpenAI | New tools for building agents: <a href="https://openai.com/index/new-tools-for-building-agents/">https://openai.com/index/new-tools-for-building-agents/</a>
[5] OpenAI Agents SDK Documentation: <a href="https://openai.github.io/openai-agents-python/">https://openai.github.io/openai-agents-python/</a>
[6] Wired | OpenAI Wants ChatGPT to Be Your Future Operating System: <a href="https://www.wired.com/story/openai-dev-day-sam-altman-chatgpt-apps">https://www.wired.com/story/openai-dev-day-sam-altman-chatgpt-apps</a>
[7] The Verge | OpenAI will let developers build apps that work inside ChatGPT: <a href="https://www.theverge.com/news/793039/openai-chatgpt-apps-developers-sdk-canva-zillow-devday-2025">https://www.theverge.com/news/793039/openai-chatgpt-apps-developers-sdk-canva-zillow-devday-2025</a>
[8] TechCrunch | OpenAI launches AgentKit to help developers build and ship AI agents: <a href="https://techcrunch.com/2025/10/06/openai-launches-agentkit-to-help-developers-build-and-ship-ai-agents/">https://techcrunch.com/2025/10/06/openai-launches-agentkit-to-help-developers-build-and-ship-ai-agents/</a>
[9] VentureBeat | OpenAI unveils AgentKit that lets developers drag and drop to build AI agents: <a href="https://venturebeat.com/ai/openai-unveils-agentkit-that-lets-developers-drag-and-drop-to-build-ai">https://venturebeat.com/ai/openai-unveils-agentkit-that-lets-developers-drag-and-drop-to-build-ai</a>
[10] Box Blog | Box enables the agentic enterprise with support for OpenAI's new AgentKit: <a href="https://blog.box.com/box-enables-agentic-enterprise-support-openais-new-agentkit">https://blog.box.com/box-enables-agentic-enterprise-support-openais-new-agentkit</a>
[11] The Tech Portal | OpenAI integrates third-party apps and introduces AgentKit: <a href="https://thetechportal.com/2025/10/07/openai-integrates-third-party-apps-in-chatgpt-and-introduces-agentkit-for-developers/">https://thetechportal.com/2025/10/07/openai-integrates-third-party-apps-in-chatgpt-and-introduces-agentkit-for-developers/</a>
[12] Axon (nxcode-io): <a href="https://github.com/nxcode-io/Axon">https://github.com/nxcode-io/Axon</a>

Pourquoi est-il « puissant mais pas parfait » ? Comment coexiste-t-il avec Dify/n8n, et dans quels scénarios excelle-t-il ?

OpenAI AgentKit Deep Dive : Une évaluation technique

<h2>Le Piège du Workflow</h2>
Octobre 2025
Nous avons besoin d'un nom pour ce nouveau type d'application d'IA que tout le monde semble construire avec des outils visuels comme Agent Builder. Elles ressemblent à de l'IA, elles utilisent de l'IA, mais elles ne sont pas de l'IA là où ça compte vraiment. Appelons-les des "Workflows Intelligents" (Smart Workflows).
Un Workflow Intelligent est un organigramme prédéfini où certains points de décision sont alimentés par un modèle de langage. C'est différent d'un Agent Réel. Un Agent Réel a un objectif et crée son propre plan. Un Workflow Intelligent se contente d'exécuter un plan que vous avez déjà créé pour lui.
La différence semble subtile, mais elle change tout. C'est la différence entre embaucher un stagiaire pour suivre une liste de tâches et embaucher un manager pour diriger un département. Le stagiaire peut être très efficace pour cocher des cases. Le travail du manager est de déterminer quelles cases doivent figurer sur la liste en premier lieu.
Les Workflows Intelligents sont séduisants car ils constituent une évolution directe de quelque chose que nous comprenons déjà : l'automatisation des flux de travail. Depuis vingt ans, des outils comme Zapier nous permettent de connecter des applications avec une logique <code>if/then</code>. Un Workflow Intelligent n'est qu'un Zapier avec un <code>if</code> beaucoup plus intelligent. Au lieu de "si l'objet de l'e-mail contient 'facture'", cela peut être "si le ton de l'utilisateur semble urgent". C'est une amélioration réelle. Mais c'est une amélioration incrémentale. On améliore l'ancien paradigme au lieu d'en créer un nouveau.
Le danger des Workflows Intelligents est qu'ils donnent une impression de progrès tout en vous menant dans une impasse. Ils vous offrent un maximum local de capacité tout en vous aveuglant sur le sommet bien plus élevé des Agents Réels. C'est le Piège du Workflow.
<hr>
Pourquoi ce piège est-il si efficace ? Il y a trois raisons principales.
Premièrement, les constructeurs visuels donnent un sentiment de productivité. Faire glisser une boîte qui dit "Appeler l'API" et la connecter à une boîte qui dit "Résumer la sortie" procure une gratification instantanée. Vous avez fait quelque chose. Vous pouvez le voir à l'écran.
Mais cette clarté visuelle est une illusion qui s'effondre avec la complexité. Essayez de représenter un processus métier réel de cette manière. Un processus de support client qui implique la vérification de l'historique des commandes, du niveau d'abonnement de l'utilisateur, des tickets de support précédents, puis une logique de branchement pour les remboursements, les escalades ou les remises. À cinq nœuds, c'est clair. À cinquante, c'est un nœud illisible.
C'est pourquoi nous avons inventé les langages de programmation. Le code est du texte, et le texte est le meilleur outil dont nous disposons pour gérer la complexité. Nous pouvons masquer des détails dans des fonctions, réutiliser la logique avec des bibliothèques et comprendre les changements avec <code>git diff</code>. Vous ne pouvez pas faire un <code>git diff</code> sur un glisser-déposer. Vous ne pouvez pas écrire un test unitaire pour une seule connexion. Vous abandonnez les outils les plus puissants jamais conçus pour gérer la complexité en échange d'un sentiment de facilité à court terme. [1]
Deuxièmement, Agent Builder est un chef-d'œuvre de verrouillage propriétaire (lock-in). La raison pour laquelle vous ne pouvez pas remplacer son LLM ou auto-héberger ses outils n'est pas une limitation technique. C'est une stratégie commerciale.
Le scénario est classique :
<ol>
<li>Vous attirer avec une expérience simple et intégrée qui est véritablement meilleure pour les tâches simples.</li>
<li>Vous rendre dépendant de fonctionnalités propriétaires et performantes (comme l'Interpréteur de Code) qui ne sont pas disponibles ailleurs.</li>
<li>Une fois que la logique de votre application est profondément liée à ces fonctionnalités propriétaires, le coût du changement devient prohibitif.</li>
<li>Toutes vos dépenses profitent à un seul fournisseur.</li>
</ol>
Cela ressemble à une plateforme unifiée, mais cela fonctionne comme une cage dorée. Vous échangez votre liberté future contre une commodité présente. Les startups meurent lorsqu'elles perdent leurs degrés de liberté. Céder volontairement le contrôle de votre logique de base et de votre infrastructure à un fournisseur unique et monolithique est une erreur catastrophique.
Troisièmement, et c'est le plus important, les Workflows Intelligents vous enseignent les mauvaises choses. Ils vous entraînent à penser comme un micromanager. Vous passez votre temps à dessiner des organigrammes de plus en plus élaborés, en essayant d'anticiper chaque éventualité possible. C'est un jeu perdu d'avance. Le monde réel est infiniment plus complexe que n'importe quel organigramme que vous puissiez dessiner.
Travailler sur un Agent Réel vous oblige à penser différemment. Vous arrêtez de définir le processus et commencez à définir l'objectif. Vous arrêtez de spécifier le comment pour vous concentrer sur le quoi. Au lieu de construire une carte détaillée, vous construisez un véhicule intelligent avec un GPS. Vous lui donnez une destination, et il détermine l'itinéraire, recalculant lorsqu'il rencontre des embouteillages ou une impasse.
Cela nécessite un ensemble de compétences différent. Vous n'êtes plus un concepteur de workflow. Vous devenez un concepteur de méta-cognition. Vous vous souciez de choses comme :
<ul>
<li>La Planification : Comment l'agent décompose-t-il un grand objectif en étapes plus petites et gérables ?</li>
<li>L'Utilisation des Outils : Comment sait-il quel outil utiliser, et comment récupère-t-il lorsqu'un outil échoue ou renvoie n'importe quoi ?</li>
<li>La Mémoire : Comment se souvient-il de ce qu'il a fait et de ce qu'il a appris, à la fois au sein d'une seule tâche et à travers plusieurs tâches ?</li>
<li>L'Auto-Correction : Comment sait-il quand son plan ne fonctionne pas et quand essayer une approche différente ?</li>
</ul>
Ce sont là des problèmes difficiles et intéressants. Ce sont des problèmes algorithmiques et architecturaux. Et ils ne peuvent être résolus qu'avec du code.
<hr>
Alors, qu'est-ce que cela signifie en pratique ?
Cela ne signifie pas que vous ne devriez jamais toucher à Agent Builder. C'est un outil de prototypage extraordinaire. Vous pouvez probablement l'utiliser pour construire un MVP pour une nouvelle idée plus rapidement qu'avec n'importe quelle autre méthode. Et cela a de la valeur. Une idée testée auprès de vrais utilisateurs en vaut cent qui ne l'ont pas été.
Mais vous devez le traiter comme un prototype. Soyez prêt à le jeter. Une fois que vous avez trouvé votre "product-market fit", vous devez construire la véritable V2 en code. Le prototype vous a mené au camp de base ; il ne vous mènera pas au sommet.
Le piège consiste à croire au marketing. Le piège est de penser que vous construisez un "vrai" agent sur ces plateformes. Ce n'est pas le cas. Vous construisez un Workflow Intelligent. Et si vous passez tout votre temps à devenir le meilleur constructeur de Workflows Intelligents au monde, vous serez laissé pour compte lorsque le monde passera aux Agents Réels.
Ne confondez pas la fin d'une ère avec le début de la suivante. Le vrai travail se fait dans le code, dans des frameworks open-source qui permettent au plan de l'agent d'être un objet dynamique et calculable. C'est plus désordonné. C'est plus dur. Cela vous demande d'être un programmeur, pas un dessinateur de diagrammes. Mais c'est là que l'avenir se construit. Les plus grandes opportunités ne se trouvent jamais sur la route bien pavée.
<hr>
Notes
[1] On essaie de remplacer la programmation par des outils visuels depuis au moins 40 ans. Cela ne fonctionne jamais pour des applications sérieuses. La raison en est que la complexité est inhérente au problème, pas à la notation. Une représentation visuelle ne supprime pas la complexité ; elle ne fait que la cacher, la rendant souvent plus difficile à raisonner et à gérer. Le code, malgré sa difficulté perçue, est la représentation la plus honnête de la logique d'un programme dont nous disposons.
[2] Un modèle mental utile est de considérer le "plan" de l'agent comme du code. Un Workflow Intelligent est comme un binaire compilé ; vous pouvez l'exécuter, mais vous ne pouvez pas facilement le modifier. Un Agent Réel est comme un interpréteur tournant dans une REPL. Il peut inspecter, modifier et étendre son propre code (le plan) pendant son exécution. Cette mutabilité du plan au moment de l'exécution est la différence clé.
[3] Vous pouvez voir cette distinction dans les types d'erreurs que chaque système commet. Un Workflow Intelligent échoue lorsqu'il rencontre une situation que le concepteur humain n'a pas anticipée. Il heurte une impasse dans son organigramme. Un Agent Réel échoue lorsque son processus de planification ou de raisonnement est défectueux. Il peut rester bloqué dans une boucle ou choisir un chemin sous-optimal. Le second type d'échec est beaucoup plus intéressant et corrigible. C'est un bug dans "l'esprit" de l'agent, pas seulement un trou dans son script.

Comprendre la différence cruciale entre les Workflows Intelligents et les Agents Réels, et pourquoi le paradigme du workflow visuel pourrait vous mener dans une impasse.

NxCode

Notre Blog

OpenAI AgentKit Deep Dive : Une évaluation technique

Le Piège du Workflow