OpenAI vient de lancer AgentKit à DevDay, et les démos sont soignées : constructeur de workflows visuels, interfaces de chat embarquées, frameworks d’évaluation. Ramp est passé d’une page blanche à un agent acheteur en quelques heures au lieu de plusieurs mois. LY Corporation a construit un workflow multi-agent en moins de deux heures.

Mais voici ce que l’article de lancement ne vous dit pas : la plupart de ces démos vont se heurter à un mur avant la production.

Ce qu’AgentKit embarque vraiment

AgentKit, c’est trois choses regroupées :

Agent Buildervous offre un canvas visuel pour composer la logique de vos agents. Des nœuds en glisser-déposer, une configuration d’évaluation inline, un versioning complet. Vous visualisez l’ensemble du workflow au lieu de déboguer du code d’orchestration à 2h du matin.

ChatKitgère les parties pénibles de l’interface de chat : réponses en streaming, gestion des fils de conversation, indicateurs de réflexion. Intégrez-le dans votre produit, personnalisez le thème, livrez.

Evals + RFTvous permet de mesurer les performances des agents avec des jeux de données, la notation de traces et l’optimisation automatique des prompts. Le fine-tuning par renforcement sur o4-mini et GPT-5 (bêta privée) permet aux modèles d’appeler les bons outils au bon moment.

C’est une vraie avancée pour la vélocité de développement des agents. Des workflows qui prenaient des mois se construisent maintenant en quelques heures.

Le mur de l’authentification et de l’autorisation

Voilà le problème : AgentKit facilite la façon deconstruiredes agents. Il ne résout pas la façon dont ces agents s’authentifient et s’autorisent réellements’authentifient et s’autorisenten production.

AgentKit embarque un support natif de MCP (Model Context Protocol), le protocole qui standardise la façon dont les agents se connectent aux outils et sources de données. Dropbox, Google Drive, SharePoint, Microsoft Teams : tout est disponible via le Connector Registry.

Mais MCP a été conçu pour des scénarios locaux, mono-utilisateur. Votre Claude Desktop personnel qui se connecte à votre système de fichiers personnel. Un utilisateur, une machine, aucune complexité d’auth.

99 % des serveurs MCP aujourd’hui sont encore construits ainsi, même les versions hébergées. Parfaits pour les démos, mais ces configurations présentent de sérieux risques de sécurité pour lesworkflows non supervisés comme Claude Code RoutinesIls tombent en production dès que vous avez besoin de :

  • Authentification : des flux OAuth sécurisés pour que les agents accèdent aux API tierces au nom des utilisateurs
  • Autorisation : des permissions par utilisateur garantissant que les agents n’accèdent qu’à ce que chaque utilisateur est autorisé à voir
  • Gestion des tokens : logique de rafraîchissement en conditions réelles, stockage sécurisé et validation des scopes
  • Pistes d’audit : des logs indiquant quelle action IA s’est produite au nom de quel utilisateur, avec quelles permissions

C’est ce qui tue 70 % des projets IA avant qu’ils ne soient livrés. Pas la logique des agents. La couche d’auth.

Ce que requiert vraiment une auth d’agent prête pour la production

L’écart entre « ça marche en démo » et « ça part en production » se résume à quelques problèmes difficiles :

Des flux OAuth qui ne donnent pas envie de tout plaquer. Votre agent doit accéder à Gmail, Slack, Salesforce (des outils qui exigent OAuth). Construire et maintenir des intégrations OAuth pour des dizaines de services représente des mois de travail. Puis il faut gérer le rafraîchissement des tokens, les changements de scopes, le versioning des API et les cas limites qui n’émergent qu’à l’échelle.

Une autorisation par utilisateur, pas des tokens de bot. La plupart des démos d’agents utilisent une seule clé API ou un token de bot avec un accès admin. C’est acceptable pour un prototype. En production, chaque action d’agent doit correspondre à un utilisateur précis avec les permissions appropriées. Votre équipe juridique va demander : « Quel utilisateur a autorisé cette action ? Quelles étaient ses permissions ? Peut-on le prouver lors d’un audit ? »

Une gestion des tokens qui ne fait pas fuiter les identifiants. Stocker les tokens OAuth de façon sécurisée, les rafraîchir avant expiration, gérer la révocation : c’est un travail de fond indifférencié. Faites-le mal et vous enfreignez vos obligations de conformité. Faites-le bien et vous avez construit quelque chose que toutes les autres équipes IA doivent aussi construire.

Infrastructure de production. Surveiller quelles actions des agents ont réussi ou échoué. Limiter les requêtes pour ne pas saturer les API. Logger pour déboguer. Des hooks d’évaluation pour mesurer les performances. Rien de tout cela n’est glamour, mais tout est obligatoire pour un déploiement en production.

Comment Arcade.dev résout ça

C’est précisément pour ça qu’Arcade.dev a été conçu : donner aux agents IA un accès sécurisé et authentifié à desvrais outils d’entreprise.

Intégrations OAuth préconstruitespour Gmail, Slack, Notion, Stripe, Salesforce et plus de 100 autres services. Construites et maintenues par l’équipe qui a livré l’auth à l’échelle (Okta, Stormpath). Vous n’écrivez pas de code OAuth. Vous configurez les scopes et laissez Arcade.dev s’occuper du reste.

Autorisation par utilisateur par défaut. Chaque action d’agent s’exécute en tant qu’utilisateur final, avec ses permissions, via sa connexion autorisée. Pas de tokens de bot partagés, pas de contournements avec des accès admin.

Gestion des tokens en conditions réelles. Logique de rafraîchissement, stockage sécurisé, validation des scopes, gestion des erreurs. Votre code d’agent ne touche jamais les identifiants bruts.

Observabilité et évaluation. Monitoring, logging, limitation de débit et hooks d’évaluation intégrés. Tout ce qu’il faut pour faire tourner des agents à l’échelle.

L’architecture est simple : vous construisez vos workflows d’agents (dans AgentKit, LangGraph, CrewAI, ou autre), et Arcade fournit la couche d’outils authentifiés en dessous. Que vous construisiez un agent acheteur ou unassistant pour les astreintes SREvotre agent appelle arcade.send_email() et Arcade gère le flux OAuth, le rafraîchissement des tokens et l’autorisation utilisateur.

Pourquoi c’est important maintenant

AgentKit vient de rendre beaucoup plus facile la façon deconstruiredes workflows d’agents. Ça va provoquer une vague d’équipes qui vont se heurter au mur de l’authentification dans les prochaines semaines.

Vous le verrez quand vous essaierez de connecter votre agent au compte Gmail d’un utilisateur. Ou quand votre équipe conformité vous demandera comment vous gérez le stockage des tokens OAuth. Ou quand vous réaliserez que votre démo fonctionne très bien avec vos propres clés API mais plante dès que vous essayez de la déployer pour plusieurs utilisateurs.

La bonne nouvelle : c’est un problème résolu. Vous n’avez pas besoin de construire votre propre infrastructure OAuth. Vous n’avez pas besoin de maintenir des intégrations pour des dizaines de services. Vous n’avez pas besoin de concevoir une autorisation par utilisateur from scratch.

Arcade.dev gère la couche d’auth pour que vous puissiez vous concentrer sur la construction de vos workflows d’agents.

*Nous livrons le support MCP pour Arcade.dev la semaine prochainepour connecter encore plus facilement des frameworks d’agents comme AgentKit à des outils authentifiés.* Rejoignez notre Discord pour les mises à jour ou inscrivez-vous sur Arcade.dev*pour rejoindre notre liste de diffusion.*

Si vous construisez des agents aujourd’hui et que vous vous heurtez déjà à des problèmes d’auth, nous sommes là. Démarrez avec notre guide de démarrage rapide ou contactez-nous directement, nous aidons des équipes à livrer des agents en production chaque jour.