Au cours des vingt dernières années, la sécurité des entreprises s’est concentrée sur l’identité. Authentifier l’utilisateur. Autoriser l’action. Auditer la requête. L’IA agentique met en évidence les limites de ce modèle.
À mesure que les organisations s’appuient davantage sur les systèmes d’IA pour rechercher des informations, prendre des décisions et exécuter des tâches, il ne s’agit plus simplement de savoir qui est à l’origine de la demande. Il faut désormais déterminer à quel modèle faire confiance pour effectuer le travail en premier lieu.
Parallèlement, une deuxième tendance se dessine. Les capacités d’IA se déploient désormais sur les terminaux. Les PC sont équipés d’unités de traitement neuronal (NPU) et de modèles intégrés capables d’effectuer des inférences localement. Les petits modèles de langage deviennent des composants concrets des applications du quotidien, plutôt que des services exclusivement accessibles dans le cloud.
Ces deux tendances se rejoignent de manière intéressante.
À mesure que l’IA s’installe sur les terminaux, le routage des modèles pourrait passer d’un mécanisme d’optimisation des performances et des coûts à un élément fondamental de l’architecture de sécurité.
L’hypothèse actuelle : un modèle, de nombreuses autorisations
Aujourd’hui, la plupart des architectures d’agents reposent sur l’hypothèse d’un modèle généraliste ayant accès à un éventail croissant d’outils, d’API, de sources de données et de systèmes d’entreprise.
La sécurité est généralement organisée en plusieurs couches autour du modèle :
- Les systèmes de gestion des identités déterminent qui a initié une requête.
- Les contrôles d’accès déterminent quelles ressources sont disponibles.
- Les Guardrails visent à encadrer les comportements.
- L’audit assure le suivi des actions après leur exécution.
Cette approche reprend l’architecture traditionnelle des applications, dans laquelle une seule application reçoit des autorisations et des contrôles de sécurité déterminent ce qu’elle peut faire. Le défi réside dans le fait que les grands modèles de langage sont de plus en plus sollicités pour effectuer des tâches présentant des profils de risque radicalement différents.
Résumer un document, approuver une note de frais, modifier le dossier d’un client et supprimer une infrastructure de production ne sont pas des opérations équivalentes. Pourtant, de nombreuses architectures les considèrent comme de simples variantes d’une même interaction.
À mesure que les capacités des agents s’étendent, la pression s’accentue pour ajouter continuellement davantage de règles, de contrôles et de supervision autour de systèmes toujours plus performants.
Il en résulte une complexité croissante, tant en matière de gouvernance que de mise en application.
Une approche alternative : l’autorité par la spécialisation
Et si la solution ne consistait pas à renforcer les contrôles autour d’un modèle généraliste ? Et si elle consistait plutôt à limiter l’autorité accordée à chaque modèle ?
Historiquement, les systèmes distribués ont évolué vers la spécialisation, car celle-ci réduit la complexité et limite les domaines de défaillance. Les bases de données assurent les fonctions de gestion des données. Les proxys remplissent les fonctions d’intermédiation. Les répartiteurs de charge assurent la répartition de charge.
Les architectures d’IA pourraient suivre une voie similaire.
Au lieu d’un modèle unique doté de privilèges étendus, les organisations peuvent déployer des portefeuilles de modèles spécialisés :
- Modèles locaux pour la synthèse et la classification
- Modèles de recherche pour l’accès aux connaissances de l’entreprise
- Modèles de workflow pour l’orchestration
- Modèles d’action pour des processus métier spécifiques
- Modèles soumis à de fortes contraintes pour les opérations privilégiées
Chaque modèle ne disposerait que des capacités nécessaires à la fonction prévue. Plutôt que de s’appuyer uniquement sur l’application de politiques après la sélection du modèle, les architectes pourraient de plus en plus associer directement les autorisations au choix même du modèle.
Le modèle choisi devient partie intégrante de la décision de sécurité.
Le routage des modèles comme routage des politiques
Aujourd’hui, le routage des modèles est principalement abordé sous l’angle des coûts et des performances. Les organisations orientent les requêtes vers différents modèles en fonction des exigences de latence, du coût des jetons ou des capacités de raisonnement. À terme, les critères de routage pourraient s’élargir considérablement.
Une future décision de routage pourrait prendre en compte :
- Sensibilité des données
- Exigences réglementaires
- Niveau d’autorité requis
- Conditions d’accès aux outils
- Contraintes liées à la localisation des données
- Niveau de confiance de l’utilisateur
- Fonctionnalités du terminal
Dans ce modèle, le routage consiste moins à trouver le modèle le moins cher qu’à sélectionner l’environnement d’exécution le plus sûr.
- Une requête impliquant des données financières sensibles peut être limitée à un traitement local.
- Une requête nécessitant l’accès aux systèmes du client peut être acheminée vers un modèle hébergé par l’entreprise et doté d’outils approuvés.
- Une demande impliquant des actions destructrices peut nécessiter une escalade vers un environnement d’exécution soumis à des contrôles stricts.
La couche de routage devient de fait un point de décision en matière de politiques.
Pourquoi l’IA sur les terminaux change la donne
L’émergence de l’IA sur les terminaux pourrait accélérer cette évolution.
Historiquement, les modèles hébergés dans le cloud ont contraint les organisations à adopter des architectures relativement centralisées. Les données étaient acheminées vers le modèle, car celui-ci se trouvait dans le cloud. À mesure que des modèles performants deviennent directement disponibles sur les appareils des utilisateurs, de nouveaux modèles d’architecture voient le jour.
Les informations sensibles peuvent ne jamais avoir à quitter le terminal. Certains flux de travail peuvent être exécutés entièrement dans les limites du périmètre de confiance local.
Les organisations disposent de nouvelles options pour trouver le juste équilibre entre confidentialité, performances et gouvernance. Plus important encore, elles bénéficient d’un mécanisme de sécurité supplémentaire.
La possibilité de décider si une tâche doit être exécutée localement ou à distance devient un véritable levier de contrôle architectural. Dans certains cas, même le modèle cloud le plus sécurisé peut présenter davantage de risques qu’un modèle local suffisamment performant et totalement dépourvu d’accès au réseau.
Les arguments en faveur d’une passerelle d’IA locale
Cela ouvre la voie à une nouvelle couche d’infrastructure.
Au lieu de permettre aux applications d’invoquer directement les modèles, les organisations pourraient de plus en plus déployer des passerelles d’IA locales AI gateways chargées de :
- Sélection du modèle
- Application des politiques
- Autorisation des outils
- Contrôles des mouvements de données
- Génération d’audits
- Filtrage du contexte
Une approche de mise en œuvre possible consiste à utiliser un environnement d’exécution léger basé sur WebAssembly, faisant office de proxy local pour l’inférence et l’application des politiques. Une telle couche permettrait aux organisations d’appliquer une gouvernance cohérente, quel que soit le modèle qui effectue finalement le travail. Plus important encore, elle dissocie les décisions de sécurité du comportement du modèle.
Plutôt que d’espérer qu’un modèle respecte une politique, la passerelle détermine en amont si le modèle doit disposer de cette capacité.
Cette distinction devient de plus en plus importante à mesure que les modèles gagnent en autonomie.
Implications stratégiques
Ce changement a plusieurs implications plus larges.
Premièrement, le routage des modèles pourrait devenir une fonction architecturale essentielle plutôt qu’une fonctionnalité d’optimisation de la plateforme.
Deuxièmement, les modèles spécialisés de plus petite taille pourraient devenir plus précieux que les grands modèles généralistes dans les environnements d’entreprise, car ils offrent des limites d’autorité plus claires.
Troisièmement, l’IA sur les terminaux pourrait devenir une stratégie de gouvernance autant qu’une stratégie de performance.
Enfin, les organisations pourraient commencer à considérer le choix du modèle comme faisant partie intégrante du contrôle d’accès.
Dans ce futur, les décisions de sécurité ne se limiteront plus aux questions relatives aux utilisateurs et aux ressources. Elles porteront également sur le choix du modèle auquel confier une tâche donnée.
Perspectives d’avenir
Depuis des années, l’identité constitue le principal plan de contrôle de l’informatique d’entreprise. Les systèmes agentiques remettent en question ce postulat.
À mesure que l’IA s’intègre davantage aux processus métier, les architectures de sécurité devront se doter de nouveaux mécanismes pour restreindre les pouvoirs, limiter l’exposition aux risques et réduire la complexité opérationnelle.
La spécialisation des modèles constitue une piste possible. Plutôt que de bâtir des cadres de sécurité toujours plus vastes autour de modèles de plus en plus performants, les organisations peuvent choisir de répartir les pouvoirs entre des modèles spécialisés et d’utiliser une infrastructure de routage pour faire respecter ces limites.
Si cela se produit, le routage des modèles ne servira plus seulement à optimiser les performances : il deviendra un outil d’application des politiques. Or, le routage fondé sur des politiques a toujours fait partie de l’infrastructure de sécurité.
À propos de l’auteur

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés

Les paquets empoisonnés sont en train de tuer notre industrie
L’open source ne dispose pas d’un registre central recensant les paquets malveillants, alors même que l’IA et l’automatisation accélèrent les attaques contre la chaîne d’approvisionnement. L’écosystème a besoin d’un moyen fiable de signaler et de suivre les compromissions.

Top 10 des risques liés à la mise en production d’applications d’IA : manque de sécurité et de conformité réglementaire
L’IA étend la conformité au-delà de la sécurisation des chemins d’accès et des espaces de stockage pour englober la gouvernance du comportement à l’exécution — accès aux modèles, contexte de récupération, résultats et actions des agents —, de sorte que les contrôles doivent être rapprochés de l’inférence.

Top 10 de la livraison d’applications d’IA : politiques de livraison incompatibles
Les divergences de politiques deviennent des sources de pannes pour l’IA : des mécanismes de basculement, des délais d’expiration, des limites et des contrôles de sécurité incohérents entraînent des défaillances silencieuses, des résultats partiels et des résultats différents selon le point de terminaison.

Top 10 de la mise à disposition d’applications d’IA : orientation du trafic non optimisée
L’IA remet en cause les principes traditionnels de répartition du trafic : les backends ne sont pas interchangeables, les coûts varient et les agents multiplient les requêtes de manière imprévisible. Le routage doit donc tenir compte du modèle, de l’état des GPU et de la localisation des données.

Top 10 de la livraison d’applications d’IA : contrôles du trafic insuffisants
Les limites de débit et les mécanismes de régulation traditionnels ne tiennent pas compte de l’étendue réelle des répercussions. Les charges de travail d’IA se répartissent entre les modèles, les bases de données vectorielles et les services, provoquant des pics de latence, des défaillances en cascade et des nouvelles tentatives.

La gestion des fenêtres de contexte en IA n’a rien de magique. C’est une question d’architecture.
Découvrez pourquoi les créateurs d’applications d’IA doivent gérer le contexte, la mémoire et l’infrastructure, tout en faisant évoluer les processus de livraison et la sécurité afin d’éviter la dérive, la latence et les attaques par injection de prompts.