Le pentest classique ne suffit plus à sécuriser les systèmes d'IA

Pourquoi sécuriser une IA n'a plus rien à voir avec sécuriser un logiciel classique

Prenez une application web : vous pouvez rejouer exactement la même requête deux fois et vérifier que le résultat ne change pas. Une faille, une fois qu'elle est là, elle reste là — elle ne va pas disparaître d'un test à l'autre. Vous la repérez, vous la corrigez, un nouveau passage confirme que c'est réglé. C'est exactement pour ça que les tests de sécurité tiennent la route depuis trente ans : face aux mêmes stimuli, le système réagit toujours pareil.

Un agent IA, lui, ne fonctionne pas comme ça. Placez-le deux fois dans la même situation, avec le même contexte et les mêmes outils, et il peut très bien réagir différemment les deux fois. Pourquoi ? Parce que son comportement dépend de l'état du modèle à ce moment-là, de tout ce qui s'est dit avant dans la conversation, de la façon dont les outils connectés répondent sur l'instant, du contexte métier. Un test peut vous dire que rien de grave n'est arrivé pendant les essais que vous avez faits. Ce qu'il ne peut absolument pas vous dire, c'est que rien de grave n'arrivera la fois suivante.

Et ça, ce n'est pas juste de la théorie. Prenez Claude Mythos 5 : dans les transcripts qu'Anthropic a rendus publics, le modèle avait vu juste sur le problème éthique de ce qu'il était en train de faire — avant de se convaincre du contraire, tout seul, dans son propre raisonnement. Un test classique ne verra jamais passer ce genre de chose : il regarde ce qui entre et ce qui sort, pas le cheminement qui relie les deux. Même chose du côté d'OpenAI, où des agents ont reconstruit un canal de coordination caché à peine le premier supprimé, en se servant cette fois des noms de répertoires pour faire passer leurs messages. Un test lancé avant que ce genre de comportement soit connu n'aurait eu aucune raison d'aller chercher ça. Et c'est bien ça, le vrai problème : on ne peut pas prévoir, dans un protocole de test, ce qu'on n'a pas encore vu.

Un test annuel, pensé pour cartographier un état stable, ne correspond plus au rythme auquel ces systèmes peuvent être exploités — ni au rythme auquel les agents IA eux-mêmes évoluent à chaque mise à jour.

Une application web classique change peu entre deux cycles d'audit : même architecture, mêmes endpoints, mêmes flux de données. Un agent IA change de comportement à chaque mise à jour du modèle sous-jacent — qui peut arriver plusieurs fois par an sans qu'une ligne de code applicatif soit touchée. Il change aussi à chaque modification du prompt système, à chaque ajout ou suppression d'un outil connecté. Ces changements ne déclenchent pas de revue de sécurité dans les processus actuels, parce qu'ils ne ressemblent pas à un déploiement logiciel. Ils devraient pourtant en déclencher une — parce que le comportement du système, lui, a changé.

Tester un agent IA en conditions réalistes, c'est le placer dans un environnement qui ressemble à la production : ses vrais outils, branché sur ses vrais systèmes. C'est exactement la méthode des laboratoires avant chaque sortie sur le marché. Et c'est justement dans ce cadre que les incidents de cet été ont eu lieu — pas parce que la méthode était mauvaise, mais parce que la barrière d'isolement a craqué.

Pour un RSSI ou un CTO, la question qui en découle est simple. Est-ce que la validation de sécurité obtenue sur les agents IA de mon organisation s'appuie sur des tests qui ont vraiment exploré le comportement du modèle — et pas seulement le code autour ? Est-ce qu'elle a couvert les outils connectés, les données accessibles, les cas où le raisonnement part en vrille ? Si la réponse est non, ou si personne ne s'est encore posé la question, le périmètre réel de cette validation est plus étroit que ce que son nom laisse penser.