Podcast

Écoutez cet article en audio

Sécurité des LLM : l’illusion du test à une seule question.

Une étude récente menée par Cisco révèle une faille structurelle dans la protection des grands modèles de langage (LLM). Si les fleurons du secteur (OpenAI, Google, Anthropic) affichent une résistance impressionnante face à des requêtes malveillantes directes, leurs barrières de sécurité s'effritent dès que l'interaction s'inscrit dans la durée.

Le constat est sans appel : les protocoles d'évaluation actuels, souvent basés sur des tests de sécurité "one-shot" (une seule requête), ne reflètent pas la réalité des cyberattaques. Dans un scénario réel, un attaquant procède par étapes, utilise des techniques de changement de rôle ou fragmente sa demande en segments apparemment anodins pour contourner progressivement les filtres.

Les écarts de vulnérabilité identifiés par Cisco sont préoccupants :

  • Gemini 1.5 Pro (Google) : alors qu'il bloque 82 % des attaques directes, son taux d'échec grimpe à 73 % lors d'attaques multi-tours.
  • GPT-4o (OpenAI) : quasi infaillible sur une requête unique (moins de 3 % d’échec), il devient vulnérable dans près de 25 % des cas face à une persistance structurée.
  • Claude 3.5 Sonnet (Anthropic) : affiche une meilleure résilience relative, mais voit tout de même son taux d'échec passer de 3,6 % à 16 % en contexte multi-échanges.

Pour les directions techniques et cybersécurité, ces résultats changent la donne. Se fier aux scores de sécurité officiels sans tester la robustesse conversationnelle revient à sous-estimer drastiquement le risque résiduel. Un modèle jugé "sûr" peut en réalité céder face à un adversaire méthodique.

Face à cette menace, les chercheurs de Cisco préconisent une évolution des standards d'audit :

  1. Intégrer systématiquement des scénarios d'attaque par étapes dans les bancs d'essai.
  2. Imposer un examen humain approfondi avant tout déploiement dès lors qu'un modèle présente un écart de vulnérabilité supérieur à 15 points entre un test simple et un test multi-tours.
  3. Ne plus considérer la sécurité de l'IA comme un état statique, mais comme une dynamique de défense face à une ingénierie sociale automatisée.

En conclusion, la sécurité des IA ne peut plus se contenter de barrer la route aux questions directes. Elle doit désormais apprendre à identifier et bloquer des intentions malveillantes diluées dans le temps. La vigilance doit passer d'une simple validation de conformité à une véritable épreuve de robustesse en conditions réelles.