La plupart des équipes d’ingénierie ne rencontrent pas d’abord des problèmes de montée en charge avec leurs fournisseurs de LLM. Ils rencontrent des problèmes de montée en charge avec leurs fournisseurs d’identité.
À mesure que les fonctionnalités d’IA évoluent, passant de simples chatbots en barre latérale à des agents capables d’agir, elles s’ajoutent à des architectures d’application conçues pour une autre époque. Ces systèmes ont été conçus pour un monde prévisible. Un utilisateur clique sur un bouton, un frontend envoie une requête avec un cookie de session, et un backend valide ce cookie par rapport à une base de données. C’est linéaire, synchrone et facile à auditer.
Les agents d’IA ne suivent pas ces règles. Ils fonctionnent de manière asynchrone, déclenchent des workflows pilotés par des événements et interagissent sur différents services distribués, sans qu’aucune intervention humaine ne soit nécessaire. Si votre couche d’identités repose encore sur le modèle « humain devant un navigateur », vos fonctionnalités d’IA ne seront pas seulement limitées : elles représenteront un risque majeur pour la sécurité.
Avant que l’IA ne bouleverse votre modèle de données, elle mettra à mal votre authentification. Pour concevoir des applications qui favorisent la conversion et la confiance, l’identité doit passer d’une fonctionnalité périphérique à un pilier architectural central.
L’authentification n’est plus une fonctionnalité, c’est une infrastructure
L’authentification se situait autrefois à la périphérie de votre application. C’était le gardien auquel vous aviez affaire une seule fois au début d’une session. Mais à mesure que nous évoluons vers des systèmes distribués et des agents autonomes, l’identité s’inscrit désormais dans le « chemin de requête » de chaque microservice.
Le paysage a évolué de trois manières fondamentales :
- Des applications aux systèmes distribués : Nous ne protégeons plus un seul monolithe. Nous protégeons un web interconnecté d’API, de lambdas et de conteneurs.
- Des utilisateurs aux acteurs : votre système gère désormais un ensemble composé de personnes, de comptes de service machine-to-machine (M2M) et d’agents d’IA agissant avec une autorité déléguée.
- Des requêtes aux interactions continues : une seule intention de la part d’un utilisateur ou d’une utilisatrice peut déclencher dix actions en arrière-plan en une heure.
Dans de nombreux environnements de développement, l’identité n’a pas évolué pour s’adapter à cette réalité. Il est probable que vous ayez des rôles codés en dur dans votre middleware, une logique d’authentification dupliquée sur trois services différents, ainsi qu’une méthode peu claire pour gérer les tokens de service. Cela aboutit à des systèmes fragiles où la modification d’une seule autorisation impose un redéploiement complet.
Lorsque l'identité est considérée comme une fonctionnalité, vous créez une dette d'authentification. Lorsque vous le considérez comme une infrastructure, vous posez les bases nécessaires pour évoluer à grande échelle. Lorsque l’identité fait partie de l’infrastructure, elle devient le socle de la responsabilisation. À l’ère de l’IA, il est facile d’ajouter des fonctionnalités d’IA ; c’est la responsabilité qui pose problème.
Pourquoi l'identité constitue le goulet d'étranglement pour la rapidité (et pas seulement pour la sécurité)
Il existe un mythe tenace selon lequel « bien gérer l’identité » ralentit le développement. Cependant, c’est l’inverse qui se produit : une architecture d’identité défaillante explique souvent pourquoi les équipes rencontrent des difficultés à lancer des fonctionnalités.
La nouvelle taxe sur les fonctionnalités
Dans une configuration héritée, chaque fois que vous développez une nouvelle fonctionnalité, vous devez définir qui peut l’utiliser. Si cette logique est codée en dur, if (user.role == ’manager’ && user.dept == ’sales’), vous créez en réalité un moteur d’authentification personnalisé pour chaque route. Très vite, vous aurez un problème de maintenance.
Une architecture d’identité moderne utilise Policy-as-Code. Vous définissez la règle une seule fois dans un moteur centralisé, et votre code se contente de demander : « Cet acteur est-il autorisé à effectuer cette action sur cette ressource ? ». Cette approche dissocie la sécurité du déploiement, ce qui vous permet de lancer des fonctionnalités sans modifier la logique d’authentification.
Le mur de l’intégration de l’IA
Les agents d’IA ont besoin de trois éléments pour fonctionner : un token, un accès limité et du contexte. Si votre socle d’identité repose uniquement sur des cookies et des sessions, vous finissez par coller des comptes de service de façon artisanale pour donner accès à l’IA. Cela conduit à des agents à privilèges excessifs qui peuvent accéder à plus de données qu’ils ne le devraient, simplement parce que le système d’identité n’était pas suffisamment flexible pour leur attribuer un token à usage limité.
La charge de maintenance
Une gestion fragmentée de l’identité entraîne un travail en double. Vos contrôles de sécurité prennent plus de temps, car la réalité des accès est dispersée sur différents référentiels. En centralisant l’identité comme pilier de votre architecture, vous réduisez la charge cognitive de vos développeurs. Ils n'ont pas à se préoccuper du « comment » de l'authentification ; ils se contentent d'utiliser le « qui » fourni par un service de confiance.
L’IA transforme entièrement l’authentification
L’IA n’augmente pas seulement le volume des demandes, elle modifie aussi la nature de l’interlocuteur. L’identité traditionnelle repose sur le concept de session : un lien temporaire entre un utilisateur et un appareil.
Les agents d’IA interrompent la session.
Les agents sont asynchrones et continus
Un copilote d’IA peut commencer une tâche pendant que l’utilisateur est en ligne, mais la terminer trois heures plus tard. Si votre modèle d’authentification repose sur un token utilisateur à durée de vie courte, l’agent échouera en cours de tâche. Si vous donnez à l’agent un token administrateur à durée de vie longue, vous créez une faille de sécurité. Vous avez besoin d’un moyen de prendre en charge l’autorisation déléguée qui permet à un utilisateur d’accorder à un agent des identifiants valables uniquement pour une tâche précise et une période déterminée.
Nouvelles exigences pour la pile
Pour prendre en charge l’IA, votre couche d’identités doit être capable de répondre à quatre questions en temps réel :
- Qu’est-ce que cet agent ? (Identification du modèle ou de la version de l’agent concerné).
- Est-ce un humain ou une machine ? (Faire la distinction entre les actions directes des utilisateurs et l’automatisation autonome).
- À quoi peut-il accéder à l’instant ? (Évaluation des autorisations dynamiques selon le contexte actuel).
- Sous l’autorité de qui ? (Remonter l’action jusqu’à la personne à l’origine de son déclenchement).
Une distinction essentielle : l’identité contrôle l’accès et définit les limites de ce qu’une IA peut faire. Elle ne décide pas de ce que l’IA doit faire ; cela relève de la logique du modèle. L’identité constitue la barrière de sécurité qui fait que, même si un LLM « hallucine » une demande de suppression de base de données, le système la rejette parce que le token de l’agent n’a pas le champ d’application requis.
À quoi ressemble réellement une « authentification prête pour l’IA »
Concevoir une authentification adaptée à l’IA implique d’intégrer l’identité dès le premier jour afin de combler la faille de confiance entre les utilisateurs et utilisatrices et les agents. Une seule autorisation erronée ou la fuite d’un token peut nuire à la réputation de la marque du jour au lendemain. Pour créer des systèmes d’IA dignes de confiance, votre couche d’identités doit être sécurisée dès la conception, en offrant des fonctionnalités pour :
1. Accès adaptatif et fluide
Pour les utilisateurs, cela signifie des flux sans mot de passe et des clés d’accès. Pour les agents d’IA, cela signifie une authentification M2M transparente. L’objectif est de réduire au maximum l’abandon tout en veillant à ce que l’échange entre l’utilisateur et l’agent soit cryptographiquement sécurisé.
2. Contexte d'identité unifié
Vous ne pouvez pas avoir une base de données utilisateur à un endroit et une liste de clés API à un autre. Vous avez besoin d’une vue unifiée de l’acteur, de la session et des autorisations. Ce contexte doit être partagé entre tous les services afin que, lorsqu’un agent d’IA appelle une API en aval, cette API sache précisément qui était l'utilisateur.
3. Autorisation dynamique basée sur les relations
Le contrôle d’accès basé sur les rôles (RBAC) est trop rudimentaire pour l’IA. Le fait qu’une personne soit éditrice ou éditeur ne signifie pas que son agent d’IA doive pouvoir modifier tous les fichiers. Il vous faut une autorisation granulaire, la fonction Fine-Grained Authorization (FGA) qui prend en compte les relations. Par exemple : « Cet agent (A) peut‑il modifier ce document (B) parce qu’il a été créé par l’utilisateur ou l’utilisatrice (C) ? ».
4. Traçabilité et justification
Dans un système agentique, « Qui a fait cela ? » est la question la plus fréquente. Votre couche d’identités doit fournir un journal d’audit immuable qui relie chaque action machine à une intention humaine. Ce n’est pas uniquement pour la sécurité : c’est aussi pour le débogage. Si un agent d’IA modifie une configuration, vous devriez pouvoir consulter la chaîne de tokens qui l’a autorisé.
Modèles concrets auxquels les développeurs sont confrontés
Copilotes d’IA intégrés aux applications
Lorsque vous créez un copilote capable de résumer vos e-mails ou de mettre à jour votre CRM, ce copilote agit en votre nom. Le modèle ici est celui des autorisations déléguées. Le développeur doit veiller à ce que l’agent d’IA reçoive un token limité à la lecture seule pour les e-mails et à l’écriture seule pour certains champs du CRM. Sans cela, une attaque par injection de prompt pourrait permettre à l’IA d’exfiltrer l’intégralité de la base de données.
Agents en arrière-plan et automatisation
Prenons l’exemple d’un agent qui s’exécute chaque nuit pour optimiser les dépenses cloud. Cet agent n’a pas de session utilisateur. Il a besoin d’une identité non humaine (NHI). Le risque ici réside dans des actions invisibles. Si la couche d’identités ne surveille pas le comportement de cet agent, il pourrait lancer des instances coûteuses sans aucune piste d’audit.
SaaS multitenant avec des fonctionnalités d’IA
C’est le modèle le plus difficile à maîtriser. Vous exécutez des modèles d’IA qui traitent des données pour l’entreprise A et l’entreprise B en même temps. Si votre architecture d'identité n'est pas conçue pour prendre en compte les tenants à tous les niveaux, vous vous exposez à des risques de fuite entre tenants. La couche d’identités doit constituer une barrière infranchissable, de sorte que le contexte de l’agent d’IA reste strictement limité aux données d’un seul tenant.
De l’idée à l’implémentation
Vous n’avez pas besoin de reconstruire toute votre stack pour être prêt·e à adopter l’IA, mais il est essentiel de cesser de considérer l’identité comme une simple bibliothèque et de commencer à la traiter comme un service.
- Centraliser l’identité : Extraire la logique d’authentification de chaque microservice pour la regrouper dans un plan d’identité partagé. Cela élimine les doublons et garantit une source fiable unique.
- Passer à une autorisation basée sur des politiques : ne plus coder en dur
if. Utilisez un moteur de politiques qui permet de modifier les règles à la volée, sans déploiement de code. - Concevoir pour plusieurs types d’identité : votre système doit considérer un compte de service et un utilisateur comme des entités de premier ordre, soumises à des exigences de gouvernance similaires.
- Rendre la gestion des identités extensible : lorsque vous ajoutez de nouveaux modèles d’IA ou des intégrations tierces, votre couche d’identités doit prendre en charge Token Exchange (RFC 8693) afin de transmettre le contexte de façon plus sécurisée entre différents systèmes.
- Concevoir avec des normes : respectez OIDC, OAuth 2.0 et les modèles FGA. Évitez les « bricolages » propriétaires en matière d’authentification qui vous enfermeraient et rendraient tout audit impossible.
L’identité, fondement des systèmes adaptés à l’IA
L’IA ne fait pas qu’accroître la complexité ; elle révèle la complexité déjà présente. Si votre couche d’identités était désorganisée avant l’IA, elle sera dysfonctionnelle après.
L’identité constitue votre couche de contrôle, votre couche de sécurité, et, pour les développeurs et développeuses, votre couche de rapidité. Lorsque l’identité est considérée comme une infrastructure, vous cessez de vous préoccuper de « comment sécuriser l’agent » pour vous concentrer sur « ce que l’agent peut apporter à l’utilisateur ou l’utilisatrice ».
Si vous développez votre application sur une base d’authentification fragmentée, vous passerez la moitié de vos sprints à corriger des bugs de connexion et des failles de sécurité. Lorsque l’identité constitue un pilier de l’architecture plutôt qu’une réflexion secondaire, vous lancez plus rapidement, évoluez en toute confiance et proposez des systèmes d’IA auxquels les utilisateurs et utilisatrices font confiance, car chaque action repose sur une intention humaine vérifiable.
Vous souhaitez découvrir en détail comment créer des applications d'IA prêtes pour la production ? Explorez le guide du développeur pour des applications et des agents d'IA prêts pour la production.
About the author
Saad Rahman
Staff Product Marketing Manager, Auth0 Solutions