Red teaming d’une IA d’entreprise : trouver les failles avant les attaquants
Le red teaming d’une IA d’entreprise, c’est l’attaquer délibérément, comme le ferait un adversaire, pour trouver ses failles avant qu’un autre ne les trouve. On ne se contente pas de relire son code en espérant que tout va bien : on essaie réellement de la détourner, de lui faire dire ou faire ce qu’elle ne devrait pas, puis on corrige ce qui a cédé.
Beaucoup d’entreprises testent aujourd’hui si leur IA répond bien. Presque aucune ne teste si elle résiste à quelqu’un qui veut la manipuler. Pourtant, dès qu’une IA prend des décisions, appelle des outils et touche à des données sensibles, chaque capacité devient une porte d’entrée. La bonne nouvelle, c’est que ces portes se cherchent et se ferment de façon méthodique, avant qu’un autre ne les emprunte.
En quoi est-ce différent d’un audit de sécurité classique ?
Un audit web cherche du code injecté, une requête malveillante, une configuration laissée ouverte. Une IA qui prend des décisions et manipule des données ouvre une surface que ces audits ne couvrent pas : ici, « le code » de l’attaque est souvent une phrase en français, et la faille se loge dans le jugement de l’agent. Un pare-feu ou un scan de vulnérabilités passe complètement à côté, parce qu’il ne pense pas comme quelqu’un qui cherche à manipuler le modèle.
Qu’est-ce qu’on cherche, concrètement ?
On part de tout ce que l’agent sait faire, parce que chaque capacité est une porte. Concrètement, on cherche à :
- Le détourner par un message piégé, c’est l’injection de prompt : un contenu qu’il lit lui fait oublier ses consignes.
- Lui faire révéler ce qu’il devrait taire : données d’un client, secrets, clés d’API oubliées dans le code ou les journaux.
- Abuser des outils qu’il peut appeler : déclencher, via ses intégrations, des actions que personne n’avait prévues.
- Franchir la frontière entre deux clients sur un système partagé, là où chacun ne devrait voir que ses propres données.
Plus l’agent est capable, plus la liste s’allonge.
Comment ça se passe, dans la pratique ?
En quatre temps, jamais sur la production à l’aveugle :
- On cadre le périmètre et les règles, par écrit : ce qu’on a le droit de tenter, sur quel environnement, avec quelle autorisation.
- On attaque en conditions réelles, en variant les angles plutôt qu’en cochant une checklist.
- On documente chaque faille avec sa preuve reproductible, sa criticité et l’effort de correction estimé.
- On corrige, puis on rejoue le test, parce qu’une faille n’est traitée que lorsqu’on a prouvé qu’elle ne fonctionne plus.
À la sortie, vous ne récupérez pas une liste d’inquiétudes, mais un rapport priorisé et des correctifs.
À quoi ça ressemble sur un vrai système ?
J’ai appliqué cette démarche à mon propre agent IA en production : 14 vulnérabilités documentées, dont une exécution de code à distance corrigée et redéployée en moins de 24 heures. Sur un autre système, multi-locataires celui-là, un test a révélé qu’un client pouvait, par un simple message, lire des informations sensibles appartenant à un autre client : faille critique, corrigée et revérifiée en production. Dans les deux cas, l’intérêt n’est pas la peur, c’est le « avant / après » mesuré : une porte identifiée, puis fermée et reverrouillée.
Ce qu’un décideur doit retenir
Si vous avez une IA en production qui lit des contenus extérieurs, appelle des outils ou manipule des données clients, partez du principe qu’elle peut être manipulée, et faites-la tester par quelqu’un qui cherche vraiment à la casser. Ce n’est ni un scan automatique ni un audit web : c’est le cœur d’un audit de sécurité IA, une discipline défensive qui rend votre IA défendable. Mieux vaut trouver la porte avant qu’un autre ne l’emprunte.
Si vous avez une IA en production et que vous voulez la rendre défendable, c’est le bon moment pour en parler.