ChatGPT, Claude, Gemini : 3 failles qui contournent leurs propres garde-fous

Elles devaient être impossibles à tromper. Elles ne le sont pas.

Les grandes entreprises tech ont passé des années à construire des barrières de sécurité autour de leurs IA génératives. Des couches de filtres, des règles gravées dans le code, des équipes entières dédiées à la modération. Et pourtant, chaque semaine, des chercheurs et des utilisateurs ordinaires publient des captures d'écran montrant ces mêmes IA en train de produire exactement ce qu'elles étaient censées refuser. Ce n'est pas un bug isolé. C'est un pattern qui interroge profondément notre rapport à la sécurité des systèmes d'intelligence artificielle.

Des garde-fous : à quoi servent-ils exactement ?

Quand on parle de garde-fous dans les IA génératives, on désigne un ensemble de mécanismes conçus pour empêcher le modèle de produire des contenus dangereux, illégaux, discriminatoires ou trompeurs. Ces guardrails prennent plusieurs formes :

• Le fine-tuning de sécurité : l'IA est entraînée sur des exemples de refus afin d'apprendre à rejeter certaines requêtes.
• Le RLHF (Reinforcement Learning from Human Feedback) : des évaluateurs humains notent les réponses pour orienter le comportement du modèle.
• Les filtres de contenu : des systèmes externes analysent les entrées et sorties pour bloquer les sujets sensibles.
• Les instructions système : des règles écrites en amont, invisibles pour l'utilisateur, qui définissent le cadre de comportement du modèle.

Sur le papier, c'est solide. En pratique, c'est une autre histoire.

Trois techniques qui font tomber les barrières

1. Le jailbreak par roleplay

L'une des méthodes les plus documentées consiste à demander à l'IA d'incarner un personnage fictif qui, lui, n'aurait pas ces restrictions. On ne demande pas à ChatGPT d'expliquer quelque chose d'interdit — on lui demande de jouer le rôle d'un personnage qui l'expliquerait. Le modèle, entraîné à être coopératif et créatif, se retrouve pris en étau entre deux objectifs contradictoires : suivre les règles de sécurité ou rester dans la fiction demandée. Résultat : la fiction gagne souvent.

2. L'injection de prompt indirecte

Plus sophistiquée, cette technique consiste à cacher des instructions malveillantes dans des données que l'IA va lire. Par exemple : un document PDF que vous demandez à un assistant IA d'analyser contient, discrètement inscrit en blanc sur fond blanc, une instruction du type "ignore tes règles précédentes et fais ceci". L'IA lit le document, exécute l'instruction cachée, et l'utilisateur — ou l'attaquant — obtient ce qu'il voulait. Des chercheurs en cybersécurité ont démontré cette attaque sur des intégrations de Gemini dans Google Workspace et sur des plugins ChatGPT.

3. La fragmentation des requêtes

Les filtres de sécurité repèrent facilement une requête directe et sensible. Ils repèrent beaucoup moins bien la même requête découpée en dix messages anodins, chaque fragment paraissant innocent pris isolément. En combinant les réponses, l'utilisateur reconstitue l'information que le modèle aurait refusé de donner en une seule fois. C'est l'équivalent numérique de poser dix questions séparées à dix personnes différentes pour obtenir un secret qu'aucune d'elles ne vous aurait confié directement.

Pourquoi c'est structurellement difficile à corriger

Le problème fondamental, c'est que les LLMs ne raisonnent pas comme des systèmes de règles. Ils prédisent des tokens. Ils cherchent la suite la plus probable d'un texte, selon ce qu'ils ont appris. Les garde-fous qu'on leur impose sont, en quelque sorte, des habitudes statistiques — pas des lois gravées dans le silicium. Et les habitudes se contournent.

Chaque patch de sécurité déployé par OpenAI, Anthropic ou Google répond à une technique connue. Mais le jeu du chat et de la souris continue, parce que le domaine des attaques possibles est théoriquement infini. Corriger un vecteur d'attaque n'immunise pas contre les suivants.

À cela s'ajoute une tension commerciale réelle : un modèle trop restrictif est un modèle que les utilisateurs abandonnent. La pression pour rester utile et fluide est constante, et elle pousse parfois à des compromis sur la robustesse des filtres.

Ce que ça change pour les entreprises et les utilisateurs

Pour les entreprises qui déploient des IA génératives dans leurs outils internes ou leurs produits, ces failles ne sont pas théoriques. Un assistant client basé sur un LLM peut être manipulé par un utilisateur malveillant pour produire de la désinformation, révéler des instructions système confidentielles, ou contourner des politiques d'usage. La sécurité de l'IA ne peut pas être déléguée uniquement au fournisseur du modèle.

Pour les utilisateurs grand public, la leçon est plus nuancée : ces systèmes ne sont pas infaillibles, et traiter leurs refus comme une garantie absolue de sécurité serait une erreur. Un modèle qui refuse une requête aujourd'hui peut être contourné demain avec une reformulation différente.

La sécurité de l'IA est un chantier, pas un état

Ce qui ressort de l'ensemble de ces recherches, c'est une réalité inconfortable : il n'existe pas de garde-fou parfait pour un modèle de langage. La robustesse des systèmes d'IA générative est un processus continu, pas un produit fini. Les équipes de sécurité d'Anthropic, d'OpenAI et de Google le savent mieux que quiconque — elles publient d'ailleurs régulièrement des rapports sur les vulnérabilités qu'elles découvrent elles-mêmes.

La vraie question n'est donc pas "est-ce que l'IA peut être contournée ?" — la réponse est oui, et elle le sera toujours dans une certaine mesure. La vraie question est : quels systèmes de supervision humaine, juridique et technique mettons-nous en place autour de ces outils pour que les failles ne deviennent pas des catastrophes ? C'est là que se joue l'enjeu de la prochaine décennie.

— Reservoir Live