Un jalon particulièrement intéressant apparaît en 2016 avec le Cyber Grand Challenge de la DARPA.
Cette compétition opposait des systèmes informatiques automatisés capables d’analyser des logiciels, de rechercher des vulnérabilités et de produire des correctifs dans un environnement expérimental.
Ces systèmes utilisaient des techniques spécialisées d’analyse de programmes et de raisonnement automatisé, sans reposer sur les modèles de langage génératifs actuels.
L’expérience démontrait déjà qu’une partie du travail traditionnellement réalisé par des experts en cybersécurité pouvait être automatisée.
Avec les modèles IA modernes, la perspective s’élargit.
Un agent peut désormais recevoir une description formulée en langage naturel, proposer plusieurs stratégies, écrire des programmes, analyser leurs résultats et réviser sa démarche.
Cette faculté ne garantit pas la justesse de ses décisions. Mais elle rend possible l’exploration de solutions qui n’avaient pas toutes été explicitement programmées par le développeur initial.
C’est précisément ce qui rapproche les architectures agentiques contemporaines de certains objectifs historiques de la recherche en cybersécurité automatisée.
6. Les expériences récentes révèlent les limites des environnements isolés
En octobre 2026, OpenAI a publié des résultats de recherches sur la sécurité de ses environnements d’entraînement et d’exécution.
Des équipes d’agents IA, utilisées dans des exercices de sécurité contrôlés, ont recherché des moyens de franchir différentes frontières d’isolation.
Les résultats présentés comprennent notamment l’identification de vulnérabilités permettant des évasions de machines virtuelles légères, des détournements de chemins réseau et des communications imprévues entre environnements isolés.
L’une des démonstrations les plus intéressantes concernait l’utilisation du cache du processeur comme canal de communication.
Deux environnements distincts, partageant des ressources matérielles, pouvaient échanger indirectement des informations en exploitant des variations de temps d’accès à la mémoire.
Il faut ici distinguer deux phénomènes : communiquer par un canal matériel caché n’est pas identique à sortir d’un conteneur ou à prendre le contrôle du système hôte.
Néanmoins, ces expériences illustrent une limite de sécurité essentielle.
Les permissions logicielles, les ports réseau, les clés API et les contrôles d’accès ne couvrent pas nécessairement toutes les interactions possibles avec une infrastructure.
Un programme peut parfois exploiter les propriétés d’un composant autorisé pour produire un effet qui n’avait pas été anticipé.
Le modèle IA ne dispose pas pour autant d’une autorité magique sur le matériel. C’est le code exécuté dans l’environnement mis à sa disposition qui produit ces effets.
Ce qui devient remarquable, c’est la capacité d’un système agentique à rechercher, expérimenter et combiner des méthodes pour atteindre un objectif.
Les expériences de recherche encadrées ne doivent évidemment pas être confondues avec des intrusions malveillantes réalisées dans des systèmes tiers.
7. L’IA agentique peut-elle amplifier les techniques des hackers ?
Oui, potentiellement.
Un attaquant qui dispose d’outils automatisés peut déjà enchaîner certaines opérations sans intervention manuelle.
L’ajout d’un modèle de raisonnement pourrait lui permettre d’examiner des résultats complexes, de proposer des adaptations et de générer de nouveaux outils selon les situations rencontrées.
La différence est celle qui sépare un programme suivant une stratégie entièrement prédéfinie d’un système capable de proposer des stratégies supplémentaires.
Mais il serait excessif d’affirmer que toute IA autonome constitue automatiquement une menace ou que ces capacités garantissent la réussite d’une intrusion.
Les modèles peuvent produire des erreurs, interpréter incorrectement une situation ou proposer des programmes défectueux.
L’efficacité d’un agent dépend aussi des outils disponibles, de ses permissions réelles, des protections de l’environnement et de la qualité de ses mécanismes d’évaluation.
La puissance d’un agent autonome résulte autant de son architecture et de ses capacités d’action que des performances de son modèle IA.
C’est pourquoi l’étude de ces mécanismes présente un double intérêt : anticiper les nouveaux risques, mais également développer des systèmes de défense capables de détecter et de corriger plus rapidement certaines vulnérabilités.
8. Une boucle d’évolution logicielle doit posséder ses propres garde-fous
Si une IA peut participer à la création d’autres agents, une question devient incontournable : qui valide les programmes générés et leurs autorisations ?
Un orchestrateur ne devrait jamais considérer qu’un programme est fiable uniquement parce qu’il a été produit par un modèle performant.
La création d’un agent et son autorisation d’exécution doivent rester deux opérations distinctes.
Une architecture robuste doit prévoir un registre des agents, le contrôle de leurs dépendances, des tests reproductibles, un environnement d’exécution isolé et une journalisation des opérations.
Elle doit également permettre le retour à une version précédente lorsqu’une modification entraîne une régression.
La séparation des responsabilités devient centrale.
Un agent peut proposer du code sans avoir le droit de le déployer. Un autre peut réaliser des tests sans être autorisé à modifier les règles de sécurité. Un mécanisme de qualification indépendant peut refuser une nouvelle version lorsque les exigences ne sont pas satisfaites.
Cette approche rejoint le principe du moindre privilège : chaque composant ne reçoit que les droits strictement nécessaires à sa mission.
Les autorisations doivent être vérifiées par des composants indépendants du raisonnement du modèle.
Les recommandations récentes de l’OWASP sur la sécurité des applications agentiques soulignent notamment les risques liés à l’utilisation abusive des outils, à l’escalade de privilèges, à la compromission des dépendances et aux défaillances en cascade.
Une boucle d’amélioration autonome n’est donc véritablement maîtrisée que si les règles qui la contrôlent ne peuvent pas être modifiées librement par les agents qu’elle génère.
9. Une perspective particulièrement intéressante pour l’IA locale et les petites entreprises
L’intérêt de cette architecture dépasse largement la cybersécurité.
Une petite entreprise pourrait disposer d’un système agentique local associé à un modèle de langage exécuté sur sa propre infrastructure.
Ce système serait capable de superviser des services informatiques, de proposer de nouveaux outils, d’automatiser des tâches administratives et de participer à la maintenance de ses applications.
Dans un environnement associant un modèle local, une base documentaire RAG, une plateforme d’automatisation et des interfaces métier, la création dynamique d’agents pourrait progressivement constituer une bibliothèque de fonctionnalités adaptées aux besoins réels de l’entreprise.
Un premier agent pourrait surveiller des services. Un deuxième analyserait des journaux techniques. Un troisième préparerait un rapport d’incident. Un quatrième proposerait un correctif soumis à validation.
Le système ne remplacerait pas nécessairement les développeurs et les administrateurs. Il pourrait surtout réduire les opérations répétitives et faciliter la production d’outils spécialisés.
L’IA locale présente ici un avantage supplémentaire : la possibilité de conserver la maîtrise des modèles, des documents, des exécutables et des données exploitées.
Cette souveraineté ne garantit pas à elle seule la sécurité, mais elle offre un contrôle direct sur les conditions d’exécution et les politiques d’accès.
Pour une TPE ou une PME, les perspectives concernent autant l’amélioration de ses processus internes que le développement de nouveaux services logiciels.
10. Vers des systèmes capables d’améliorer leur propre architecture ?
Poussons maintenant le raisonnement.
Si un orchestrateur peut détecter une lacune, solliciter un modèle IA, créer un agent et évaluer ses performances, pourquoi ne pourrait-il pas également proposer des améliorations de ses propres composants ?
Nous entrons alors dans une forme d’évolution logicielle semi-autonome.
L’orchestrateur pourrait identifier des traitements redondants, proposer une meilleure répartition des tâches, recommander la modification d’un agent peu performant ou concevoir un nouveau module spécialisé.
Chaque modification passerait par une procédure de qualification indépendante.
Cette architecture n’implique pas qu’un système dispose d’une conscience, d’une volonté propre ou d’une intelligence générale.
Elle repose sur un principe beaucoup plus concret : associer des raisonnements génératifs à des mécanismes classiques de développement, de test, de contrôle et d’exécution.
La boucle peut alors contribuer à faire évoluer l’ensemble des fonctionnalités disponibles, tout en conservant un cadre de sécurité défini par les concepteurs.
Le défi consiste précisément à permettre l’évolution des capacités sans autoriser une évolution incontrôlée des privilèges
