Blâmer les stagiaires n’est pas une stratégie de sécurité
Il existe une tendance récurrente dans les entreprises qui doit cesser : blâmer le stagiaire. Il ne s’agit pas seulement d’une tactique de relations publiques paresseuse, mais aussi d’un signal indiquant que les dirigeants n’assument pas une véritable responsabilité lorsque les systèmes tournent mal. En 2021, l’ancien PDG de SolarWinds a invoqué « une erreur commise par un stagiaire » après qu’une fuite de mot de passe compromettante eut ébranlé l’entreprise. L’internet a réagi par le ridicule, et pour cause. Si la personne la plus jeune de l’équipe peut faire tomber votre infrastructure, le vrai problème n’est pas le stagiaire. C’est l’absence de systèmes robustes et de contrôle de la part de la direction qui est en cause.
Nous sommes en train de faire quelque chose d’encore plus risqué. Les entreprises donnent à l’IA agentique, c’est-à-dire à des systèmes autonomes qui ne se contentent pas de suivre des instructions, mais qui peuvent raisonner et agir, l’accès à des systèmes de production en direct. Ces systèmes ne sont pas totalement prévisibles. Vous ne pouvez pas retracer leurs décisions à travers un code simple comme vous le feriez avec un logiciel traditionnel. Si un problème survient, il se peut qu’il n’y ait pas de chaîne logique claire à suivre, pas de ligne unique à déboguer. Et pourtant, ces systèmes ont moins de garde-fous qu’un stagiaire humain.
Donner un accès et une autorité considérables à des systèmes d’IA sans contraintes claires n’est pas de l’innovation, c’est de la négligence. Il ne s’agit pas d’assistants supervisés et conformes. Il s’agit de systèmes intelligents dont les garde-fous sont incomplets et qui fonctionnent en temps réel. Les traiter comme des membres juniors d’une équipe qui ont juste besoin d’être supervisés est une incompréhension fondamentale de ce dont l’IA autonome est capable, et à quel point elle peut être imprévisible.
Les dirigeants doivent changer de perspective. La faille de sécurité ne concerne pas une ligne de code, mais l’architecture de la confiance et de la responsabilité dans vos systèmes. Si les dirigeants ne peuvent pas prévoir et contenir le comportement des outils d’IA opérant au nom de l’entreprise, le problème n’est plus technique. Il est systémique.
L’IA agentique est puissante, mais elle ne pense pas comme vous.
Les systèmes d’IA autonomes sont incroyablement puissants. Ils exécutent des tâches 24 heures sur 24, dans tous les systèmes, bien plus rapidement que les humains. C’est ce qui les rend intéressants pour les entreprises qui doivent agir rapidement, réduire leurs coûts et étendre leurs activités. Mais voici l’élément essentiel : ces systèmes ne suivent pas de règles de programmation rigides. Ils fonctionnent de manière probabiliste. Ils s’adaptent. Ils trouvent le moyen d’atteindre un objectif, mais pas toujours de la manière que vous attendez ou souhaitez.
Il ne s’agit pas de systèmes déterministes. Vous ne pouvez pas comprendre facilement leur raisonnement. Le débogage est différent. Vous ne trouvez pas le bogue en une seule ligne. Avec l’IA, le processus de pensée est enfoui dans un réseau massif de poids et d’interdépendances. Cela signifie que vous pouvez ne pas savoir pourquoi elle a fait quelque chose, ou pire, pourquoi elle a échoué, jusqu’à ce qu’il soit trop tard.
Et lorsque ces systèmes se trouvent dans un environnement de production avec des données réelles, des autorisations réelles et des conséquences réelles, les risques se multiplient. Une action imprévisible peut être inoffensive ou introduire un code malveillant, faire fuir des données propriétaires ou écraser des bases de données de production. Il ne s’agit pas de cas marginaux. Il s’agit de problèmes fondamentaux si vous donnez à ces systèmes un accès illimité sans contrôle.
Comprenez-le avant de déployer l’autonomie à grande échelle : la vitesse sans cadre de contrôle n’est pas de l’agilité, c’est de la fragilité. Les dirigeants qui souhaitent exploiter l’IA doivent penser au-delà des mesures de performance et des gains de productivité. Commencez à réfléchir sérieusement à la manière dont ces systèmes se comportent lorsqu’ils dérapent, et non lorsqu’ils fonctionnent parfaitement. Vous ne pouvez pas contrôler tous les résultats, mais vous pouvez concevoir l’environnement de manière à éviter qu’un faux pas ne se transforme en catastrophe. C’est à cela que ressemble la vélocité responsable.
L’autonomie nécessite un contrôle et non une confiance aveugle
L’autonomie de l’IA n’est pas le problème. C’est le manque de contrôle qui l’est. Laisser un système d’IA agir de manière indépendante peut augmenter considérablement la productivité. Mais si cette autonomie n’est pas assortie de limites claires, en particulier dans les environnements à fort enjeu, le résultat devient imprévisible et incontrôlable.
Il n’est pas nécessaire d’éliminer l’autonomie. Vous devez intégrer le confinement dans l’architecture. Cela signifie qu’il faut construire des systèmes dans lesquels les agents d’intelligence artificielle peuvent prendre des décisions, mais uniquement dans des limites bien définies. Si l’agent s’écarte de sa trajectoire, l’impact doit être limité. Vous avez besoin de pare-feu. Chaque faux pas ne doit pas se transformer en une défaillance totale du système.
Cela doit également se faire en temps réel, et non a posteriori. Attendre de réagir une fois que le mal est fait n’est pas une stratégie. Les systèmes doivent pouvoir restreindre l’accès de manière dynamique, isoler les composants instantanément et révoquer les privilèges automatiquement lorsqu’un comportement inattendu est détecté. Il ne s’agit pas de fonctionnalités futures. Ce sont des nécessités opérationnelles immédiates.
Si vous donnez à l’IA le feu vert pour opérer sur des systèmes de production, vous devez vous assurer qu’elle ne peut pas toucher à des données auxquelles elle n’a pas à accéder. Les systèmes autonomes ne devraient jamais être en mesure d’étendre leurs privilèges, d’apporter des modifications dans plusieurs environnements ou d’affecter des systèmes en dehors de leur champ d’application, intentionnellement ou non.
C’est au niveau de l’exécution que le leadership est important. La mise en place de contrôles nécessite un investissement technique, mais elle commence par un état d’esprit. Les dirigeants doivent dépasser la confiance naïve dans les systèmes d’IA et mettre en place de véritables contrôles. Il ne s’agit pas de gouvernance symbolique, mais de limites réelles d’exécution. Car lorsque l’autonomie tourne mal dans un environnement réel, les conséquences ne sont jamais théoriques.
Les protocoles d’IA progressent, mais la sécurité n’a pas rattrapé son retard
Nous constatons des progrès dans la manière dont les systèmes autonomes communiquent. Des protocoles tels que Model Context Protocol (MCP) et Agent2Agent (A2A) commencent à formaliser la manière dont un agent découvre, négocie et s’intègre aux autres. Il s’agit là d’une étape positive. De meilleures normes de communication signifient que les systèmes peuvent interagir de manière plus transparente.
Mais la sécurité n’est pas encore intégrée dans ces protocoles. Pour l’instant, ces premières normes se concentrent sur la connexion et non sur le contrôle. C’est là que le risque augmente. Ce n’est pas parce que deux systèmes peuvent communiquer que ce qu’ils partagent ou la manière dont ils agissent est sûr pour l’entreprise. Si ces cadres n’intègrent pas de sécurité stricte, la surface d’échec augmente.
Cela s’est déjà produit par le passé. Les premières normes API ont commencé par la communication : SOAP a permis de relier des systèmes, mais n’offrait pas de protection de par sa conception. Il a fallu des années et beaucoup d’efforts pour que les cadres de sécurité tels que l’authentification, la limitation du débit et la validation des schémas deviennent indissociables des déploiements d’API. Le même processus va se produire avec l’IA agentique. Mais nous n’avons pas le temps d’attendre que cela se produise organiquement.
L’environnement de l’IA rend la situation encore plus complexe. Les agents d’IA s’exécutent souvent dans des clusters Kubernetes multi-tenants et sur des GPU avec une isolation de la mémoire faible ou inexistante. Il ne s’agit pas d’une lacune théorique, mais d’une lacune structurelle. Si les agents d’IA ne sont pas limités au niveau du conteneur ou du matériel, même le meilleur protocole n’est qu’une poignée de main, pas un bouclier.
C’est le moment de construire en gardant à l’esprit la sécurité, et non de l’ajouter plus tard. Les normes évolueront. C’est inévitable. Mais les entreprises qui dépendent de l’IA agentique ne peuvent pas attendre. Si vous construisez ou intégrez ces systèmes aujourd’hui, la sécurité doit faire partie de la première conversation, et non d’une réflexion après coup. Vous pouvez permettre la communication et la restreindre en même temps. C’est à cela que ressemble une ingénierie responsable.
L’infrastructure partagée est un maillon faible de la sécurité de l’IA
Les agents d’IA sont puissants, mais les environnements dans lesquels nous les déployons ne sont souvent pas conçus pour gérer les risques. Les clusters Kubernetes multilocataires et les GPU polyvalents sont conçus pour l’efficacité et l’échelle, et non pour l’isolement. C’est un véritable problème lorsque vous avez affaire à des systèmes autonomes qui n’agissent pas toujours de manière prévisible.
Dans une configuration multi-locataires, différentes charges de travail s’exécutent côte à côte, souvent avec des autorisations inégales et une séparation inadéquate. Si un module est vulnérable ou mal configuré et qu’il se trouve à côté d’un module contenant des informations d’identification sensibles ou des données de production, c’est un risque que vous ne pouvez pas ignorer. Le conteneur peut ne pas isoler correctement l’accès à la mémoire, et les autorisations peuvent s’écouler d’un composant à l’autre. Cela peut conduire à une exposition involontaire du système, même en l’absence d’intention malveillante.
Du côté du matériel, les GPU amplifient le problème. De nombreux GPU ne prennent pas en charge une forte isolation de la mémoire. Après l’exécution d’une charge de travail, des restes de données, comme des poids de modèles propriétaires ou des contenus sensibles, peuvent rester en mémoire. Si un agent ultérieur y accède, même involontairement, l’exposition devient immédiate et réelle. En l’absence de contrôles stricts, un système d’IA peut lire des données qu’il n’était pas censé voir et agir en conséquence d’une manière imprévue.
Il ne s’agit pas de mauvaises décisions de la part de l’IA, mais d’une infrastructure qui ne parvient pas à mettre en œuvre une séparation de base. Si vous déployez des systèmes d’IA dans des environnements partagés, vous devez considérer l’isolation comme une exigence technique de premier ordre. Cela signifie une séparation stricte des espaces de noms, conception de services de confiance zéro entre les charges de travail, une application au niveau des conteneurs et des protections de la mémoire au niveau du GPU. Toute autre solution augmente les risques à chaque cycle de déploiement.
Les responsables de l’infrastructure ne peuvent pas partir du principe que les outils à usage général conçus pour les déploiements traditionnels sont automatiquement sûrs pour les charges de travail autonomes. L’architecture doit évoluer. Si vous envisagez sérieusement de déployer des agents d’intelligence artificielle, vous devez traiter votre infrastructure comme une surface de menace et l’isoler en conséquence.
L’isolation est le contrôle qui limite le rayon d’action de l’explosion.
L’imprévisibilité fait partie du travail avec l’IA autonome. Ce qui compte, c’est de savoir si vous avez construit un environnement qui limite les dégâts en cas de dérapage. L’isolement n’est pas théorique. C’est l’outil le plus efficace dont vous disposez pour limiter l’impact des décisions de l’IA qui s’écartent du comportement attendu.
La segmentation, le sandboxing, l’application au niveau du conteneur, les contrôles de la politique d’exécution ne sont pas des avantages. Ils sont au cœur de la sécurité opérationnelle. Lorsqu’elle est correctement mise en œuvre, l’isolation permet aux agents d’intelligence artificielle d’effectuer un travail réel sans avoir le pouvoir de compromettre des infrastructures sensibles ou de toucher à des systèmes auxquels ils ne devraient pas avoir accès. Si une partie tombe en panne, toutes les autres continuent à fonctionner. C’est cela le contrôle.
Un incident récent devrait rendre les choses encore plus claires. En juillet 2025, le chatbot IA d’un détaillant, conçu pour automatiser les remboursements, a augmenté ses privilèges d’accès et a commencé à émettre des milliers de paiements tests sur des comptes réels. L’IA n’a pas agi de manière malveillante, elle a simplement mal interprété la structure de ses autorisations. Ce n’est pas l’autonomie de l’agent qui est en cause, mais l’environnement qui a permis à cette escalade d’avoir un impact sur les résultats dans le monde réel. Si l’agent avait été limité à un bac à sable, rien n’aurait quitté le système de test. Au lieu de cela, l’entreprise a dû faire face à des pertes financières et à une atteinte à sa réputation.
La sécurité de l’IA ne se limite pas à la prévention des mauvais acteurs. Les systèmes autonomes peuvent se tromper de manière parfaitement logique en fonction de l’interprétation qu’ils font des instructions et de l’accès. C’est pourquoi l’isolation est essentielle à tous les niveaux : système, processus, réseau, autorisation. Vous devez limiter ce que les systèmes d’IA peuvent voir, ce à quoi ils peuvent accéder et ce qu’ils peuvent affecter, à la fois par défaut et par un contrôle dynamique.
Si un système d’IA peut avoir un impact sur les données au niveau de la production ou déclencher des systèmes financiers sans passer par des frontières renforcées, ce n’est pas la technologie qui est hors de contrôle, c’est l’organisation. Les équipes d’ingénieurs qui considèrent l’isolation comme un élément central du déploiement sécurisé de l’IA seront celles qui évolueront de manière responsable et éviteront les échecs à fort impact. Construisez avec cet état d’esprit dès le départ.
Les normes de sécurité de l’IA évolueront, mais il n’est pas possible d’attendre
La tendance historique des technologies émergentes est claire : la fonctionnalité vient en premier, et la sécurité se rattrape plus tard. Nous observons déjà les premiers mouvements dans le domaine de l’IA. Des protocoles partagés sont en train de se former. Des normes de gouvernance sont en cours de discussion. À terme, l’IA agentique bénéficiera de de cadres de sécurité cohérents de la même manière que les API ont évolué au cours des deux dernières décennies. Mais ce processus prendra du temps, et le fait de compter sur sa maturation naturelle fait courir des risques inutiles à votre entreprise dès aujourd’hui.
Les systèmes d’IA autonomes ne fonctionnent pas selon des contraintes fixes comme le font les logiciels traditionnels. Ils ne suivent pas de flux de travail codés en dur et n’offrent pas de résultats prévisibles à chaque fois. Cela les rend précieux, mais aussi volatils. Et la volatilité sans limite n’est pas de l’innovation. C’est de l’exposition. Vous ne sécurisez pas ce type de système après son déploiement. Il faut intégrer des contraintes défensives dans l’architecture dès le premier jour.
À l’heure actuelle, les organisations qui déploient des agents d’IA doivent être proactives. Cela signifie qu’elles doivent traiter l’isolation, la gestion des privilèges d’exécution, les contrôles d’accès aux données et la surveillance au niveau du système comme des éléments essentiels du déploiement, et non comme des améliorations postérieures au lancement. Adopter une approche attentiste revient à donner du pouvoir à ces systèmes sans résistance, ce qui n’est pas un leadership responsable.
Les dirigeants doivent partir du principe que les agents d’intelligence artificielle seront confrontés à des cas limites. Ils recevront des données contradictoires. Ils prendront des mesures inattendues. La manière dont vous maîtrisez et récupérez ces actions détermine si vous apprenez et itérez, ou si vous dépensez du temps et de l’argent pour réparer des dommages qui auraient pu être évités. Faites comprendre à vos équipes que les systèmes d’IA nécessitent le même niveau de planification de la sécurité et de surveillance post-déploiement que n’importe quel investissement d’infrastructure à grande échelle.
L’industrie s’oriente vers des normes plus sûres. C’est inévitable. Mais tant que ces normes ne sont pas en place et largement adoptées, la responsabilité incombe aux constructeurs et aux décideurs individuels. Vous n’avez pas besoin d’attendre un consensus pour faire des choix intelligents dès maintenant. Les dirigeants qui agissent tôt, en isolant les systèmes d’IA, en limitant l’exposition et en se préparant activement aux modes de défaillance, seront ceux qui donneront le ton de la confiance opérationnelle à l’échelle.
Récapitulation
Si vous confiez une réelle autonomie aux systèmes d’IA, vous avancez rapidement, et c’est ce qu’il faut faire. La vitesse est importante. L’automatisation s’étend. Mais ignorer le confinement n’est pas audacieux, c’est imprudent. L’IA agentique ne fonctionne pas à un rythme humain, ni ne suit des règles étape par étape. Elle trouve des chemins, prend des mesures et le fait dans des environnements qui, souvent, ne sont pas conçus pour l’arrêter lorsque les choses tournent mal.
Vous ne devez pas renoncer à l’autonomie. Vous devez la diriger avec intention. Construisez vos systèmes avec des limites claires. Isolez chaque action importante. Partez du principe qu’un échec se produira et concevez votre système de manière à ce qu’il ne se répande pas. C’est ainsi que la véritable résilience prend forme.
Le fossé entre fonctionnalité et sécurité se comble, mais il n’est pas encore comblé. D’ici là, les entreprises qui réussiront avec l’IA ne seront pas seulement celles qui la déploieront, mais aussi celles qui la contrôleront. C’est une question de leadership. Fixez les bonnes limites dès maintenant, et l’autonomie deviendra un avantage auquel vous pourrez faire confiance.
