Le vrai levier pour déployer des agents IA en production, ce n’est pas un meilleur modèle : c’est d’accepter que les agents ne sont que des applications.
Ça paraît évident. Peut-être même banal. Mais cette seule prise de conscience dissipe des années de confusion, élimine des catégories entières de « nouveaux » problèmes de sécurité, et rend le déploiement multi-utilisateur vraiment faisable.
Voici pourquoi c’est important.
Le piège de l’identité non humaine
Quand les agents ont commencé à s’inviter dans les discussions en entreprise vers 2023, les acteurs de l’identité se sont précipités pour définir le problème. « Les agents ont besoin d’une identité non humaine », ont-ils dit. « Ce sont des employés au silicium. Ils ont besoin de leurs propres comptes utilisateurs, de leurs propres permissions, de leur propre univers. »
Sur le moment, ça avait du sens. Si les agents sont autonomes, intelligents et prennent des décisions, ne devraient-ils pas avoir leur propre identité ? Leur propre fiche dans votre système IAM ?
Non.
Parce que dès qu’on essaie de mettre en œuvre l’identité non humaine concrètement (pour des agents agissant au nom d’utilisateurs), on se heurte immédiatement à un mur : quelle est l’identité quand l’agent accède à Gmail ?
Est-ce l’agent ? Est-ce vous ? Une entité hybride en superposition quantique de permissions ? Ça devient vite le bazar, et ce bazar s’amplifie quand on veut construire des systèmes fiables, sécurisés et qui passent à l’échelle.
L’insight qui change tout
Voici ce qu’on a réalisé après avoir construit des dizaines d’agents en production : les agents ne sont que des applications avec des grands modèles de langage insérés à des endroits précis du workflow.
Pas une nouvelle catégorie. Pas un grand bouleversement paradigmatique. Juste de l’automatisation de workflow très sophistiquée, qui utilise du raisonnement non déterministe à certains endroits.
Réfléchissez-y :
- Cursor est VS Code avec un agent intégré dans le workflow d’édition
- ChatGPT est une app dans l’App Store (parmi les plus téléchargées)
- Spotify utilise des modèles pour les recommandations (ce n’est pas un agent, mais il embarque du non-déterminisme)
La frontière entre « app » et « agent » est déjà floue. Les apps traditionnelles ajoutent des interfaces conversationnelles. Les produits agent-first s’étoffent pour devenir de vraies applications. Au bout du compte, c’est toujours de l’automatisation de workflow, ce que le logiciel fait depuis les mainframes.
Pourquoi c’est important pour la sécurité
Une fois qu’on accepte que les agents sont des applications, l’infrastructure de sécurité existante fonctionne. Pas besoin de nouveaux concepts. Pas besoin d’inventer une identité non humaine. Vous savez déjà faire de la sécurité applicative.
Voici comment OAuth fonctionne pour les agents : l’application obtient son propre client ID et secret (cela identifie l’app elle-même, pas l’utilisateur). Quand un utilisateur autorise l’app à accéder à une ressource (Gmail ou Slack, par exemple), il accorde des scopes représentant l’intersection de deux choses : ce que l’app veut faire et ce que l’utilisateur est réellement autorisé à faire. Si l’agent n’a pas encore été autorisé, on déclenche un flux OAuth. Une fois autorisé, si l’utilisateur peut effectuer l’action, on l’exécute. Sinon, on bloque.
Ce qui compte, ce n’est pas seulement commentl’autorisation fonctionne, mais quandelle se produit. Au lieu de pré-approuver toutes les actions possibles en amont (comme la plupart des apps et agents gèrent encore OAuth), Arcade.dev autorise aprèsque le modèle a décidé ce qu’il veut faire. Cette approche « post-prompt » permet la autorisation juste-à-temps : l’accès est accordé uniquement pour l’action précise en cours, exactement au moment où elle est nécessaire. C’est plus rapide, plus sûr, et ça semble naturel pour l’utilisateur. Inutile de connecter quinze services avant de faire quoi que ce soit : l’agent demande ce dont il a besoin, quand il en a besoin.
C’est ce qu’on appelle l’autorisation déléguée par l’utilisateur. Elle fonctionne pour les apps web depuis plus d’une décennie. Et elle fonctionne tout aussi bien pour les agents.
Le problème que tout le monde résout mal
La plupart des créateurs d’agents utilisent aujourd’hui l’une de ces deux approches bancales :
1. Les comptes de service (le problème RAG)
On donne à l’agent un compte de service avec un accès large. Cela crée une vulnérabilité d’élévation de privilèges. Que se passe-t-il quand un stagiaire utilise l’agent pour accéder à des données sensibles auxquelles il ne devrait pas avoir accès ?
La plupart des entreprises règlent ça en bridant sévèrement l’agent, en le limitant à des informations quasi publiques. C’est pourquoi la plupart des chatbots de support sur les sites web peuvent réciter leur base de connaissance publique, mais ne peuvent pas vous dire où est votre commande. Parce qu’ils n’ont aucun moyen de garantir que je ne peux pas faire du prompt engineering pour accéder à vos données de compte, autrement dit, il n’existe pas de façon claire d’établir ce à quoi j’ai accès via l’agent.
2. Les credentials utilisateur directs
On stocke les credentials de l’utilisateur directement dans la configuration de l’agent. C’est ainsi que fonctionnent la plupart des serveurs MCP desktop. Techniquement, ça marche pour les scénarios mono-utilisateur, mais ça ne passe pas à l’échelle. Et si c’est sécurisé, ce n’est pas sûr : si l’agent hérite entièrement de vos credentials, il pourrait supprimer des fichiers et des emails parce que vous en avez aussi la capacité. Dans Cursor, je l’ai vu tenter de supprimer mon répertoire racine. Heureusement, il n’avait pas l’accès sudo et a été bloqué. Il s’est confondu en excuses, ce qui était très aimable de sa part.
Réessayer
À quoi ressemble vraiment une authentification d’agent en production
Chez Arcade.dev, nous avons construit le premier système permettant aux agents de traverser des flux OAuth à l’intérieur de la boucle agent, après le prompt utilisateur.
Concrètement :
- L’agent dispose de sa propre inscription d’application OAuth
- L’agent obtient des permissions scopées (lire les emails, pas les supprimer)
- L’utilisateur conserve ses permissions existantes
- L’autorisation se produit en temps réel, à chaque appel d’outil
- Aucun compte de service avec accès god-mode
- Aucun credential codé en dur attendant de fuiter
Quand un agent tente d’accéder à Slack en votre nom, on vérifie : cet agent, au nom de cet utilisateur, peut-il effectuer cette action sur cette ressource ?
Si l’agent n’a pas encore été autorisé, on met la requête en pause et on déclenche un flux OAuth, un écran d’autorisation standard que votre équipe sécurité connaît déjà. Une fois autorisé, on vérifie les permissions de l’utilisateur. Si l’utilisateur peut effectuer l’action, on l’exécute. Sinon, on bloque.
L’agent ne stocke jamais de credentials. Le modèle non plus : il reçoit uniquement les sorties autorisées, jamais les secrets eux-mêmes. L’agent émet simplement des requêtes, et nous appliquons la politique sur la base de l’intersection des scopes de l’agent et des permissions de l’utilisateur.
Pourquoi ça réduit la complexité
Traiter les agents comme des apps signifie :
Votre équipe sécurité n’a pas besoin d’apprendre de nouveaux concepts. OAuth, OIDC, SAML : tout fonctionne encore. Aucun nouveau paradigme d’identité à architecturer.
Votre agent n’a pas besoin d’un accès superutilisateur. Les permissions scopées vous permettent de déployer des agents en production sans créer de risques d’élévation de privilèges.
Votre stack IAM n’a pas besoin de changer. Que vous utilisiez Okta, Active Directory ou Saviynt, vos politiques d’accès existantes s’appliquent. On aide simplement à les faire respecter au niveau de la couche d’appel d’outils.
Vos développeurs peuvent se concentrer sur la création d’agents, pas sur la résolution des problèmes d’auth. Au lieu de passer six mois à chercher comment connecter un agent à Gmail de façon sécurisée, ils câblent un toolkit et livrent.
Le futur est déjà là
Les entreprises qui construisent des agents en production convergent déjà vers ce modèle, souvent sans s’en rendre compte.
Elles commencent par insérer un grand modèle de langage dans un workflow. Super, c’est maintenant un agent. Puis elles réalisent qu’il doit se connecter en sécurité aux systèmes internes. Elles implémentent donc OAuth. Puis elles construisent un autre agent qui doit parler au premier. Elles ajoutent une interface MCP. Puis un outil a besoin de plus de logique, et elles intègrent du raisonnement directement dans l’outil.
Avant d’avoir eu le temps d’y penser, elles ont construit un système multi-agents sophistiqué qui est en réalité une application bien architecturée avec des LLMs à des endroits précis.
Elles ne cherchaient pas à défendre une thèse philosophique. Elles ont juste résolu le problème devant elles. Et la solution ressemblait à… une app.
Ce que ça signifie pour vous
Si vous construisez des agents :
- Arrêtez d’essayer d’inventer de nouveaux concepts d’identité
- Utilisez OAuth comme il a été conçu
- Traitez votre agent comme une application dans votre stack de sécurité
- Scopez les permissions finement et appliquez-les au runtime
Si vous évaluez des plateformes d’agents :
- Demandez comment elles gèrent l’auth multi-utilisateur
- Évitez tout ce qui requiert des comptes de service ou des credentials codés en dur
- Recherchez un MCP runtime proposant une autorisation déléguée avec application de politiques en temps réel
Si vous êtes responsable sécurité :
- La bonne nouvelle : votre modèle de sécurité existant fonctionne
- Le défi : l’appliquer au niveau de la couche d’appel d’outils nécessite une nouvelle infrastructure
- Le gain : aucune élévation de privilèges, aucun nouveau paradigme d’identité, aucune refonte de l’IAM
La conclusion
Les agents ne sont pas une nouvelle catégorie d’identité. Ce sont des applications qui utilisent du raisonnement non déterministe dans certaines parties de leur workflow.
Accepter cela ne rend pas la sécurité des agents triviale : il reste du vrai travail à faire autour de la gestion des tokens, de l’application des scopes et de l’autorisation au runtime. Mais ça rend le problème soluble grâce à des patterns et une infrastructure que votre équipe connaît déjà.
Vous n’avez pas besoin d’attendre que l’industrie invente des standards d’identité non humaine. Vous n’avez pas besoin de refondre votre stack IAM. Il vous suffit d’appliquer l’autorisation au niveau applicatif sur la couche d’appel d’outils.
C’est pour ça que nous avons construit Arcade.dev. Et c’est pourquoi des entreprises livrent des agents en production en quelques semaines, plutôt que d’attendre des années que le problème de « sécurité des agents » soit résolu.
*Vous voulez voir comment ça fonctionne en pratique ? Consultez notre* docs ou parlez-nous *du déploiement d’agents avec OAuth réel dans votre environnement.*
