Sécurité des IA : préserver les garde-fous après la réduction des modèles

Les modèles d’intelligence artificielle ne sont pas toujours utilisés sur de grands serveurs. Pour les installer sur un téléphone, un équipement industriel, un véhicule ou tout autre appareil aux ressources limitées, les développeurs cherchent à réduire leur empreinte mémoire et leurs besoins de calcul. Cette opération paraît technique et neutre. Pourtant, elle peut modifier en profondeur le comportement du modèle, y compris sa capacité à refuser une demande risquée. C’est le problème étudié par une équipe de l’Université de Californie, Riverside, qui propose de reconstruire les garde-fous directement à l’intérieur d’un modèle allégé.

En septembre 2025, cette piste de recherche attire l’attention sur un angle souvent moins visible que les performances brutes des IA : une optimisation conçue pour rendre un système plus léger peut aussi déplacer les protections qui limitaient certains usages indésirables. La question n’est donc pas seulement de savoir si un modèle répond vite et correctement, mais s’il reste sûr après avoir été adapté à son environnement de déploiement.

Pourquoi réduit-on la taille des modèles d’IA ?

Les grands modèles exigent généralement beaucoup de mémoire, de puissance de calcul et d’énergie. Or ces ressources ne sont pas disponibles partout. Un appareil mobile, un capteur connecté ou un système embarqué doit souvent fonctionner avec une batterie, une puce et une capacité de stockage limitées. Réduire un modèle permet alors de diminuer son coût de fonctionnement et, dans certains cas, de traiter les données localement plutôt que de les envoyer en permanence vers un serveur distant.

L’une des façons d’alléger une architecture consiste à retirer certaines couches internes. Dans un réseau de neurones, une couche est une étape de traitement qui transforme progressivement une information. Dans le cas d’un modèle capable d’interpréter des images et du texte, l’encodeur d’images convertit notamment les pixels en représentations numériques exploitables par la suite du système. Supprimer des couches peut donc accélérer le traitement, mais cela ne revient pas à enlever une simple option périphérique.

Le travail de l’équipe de Riverside porte sur les modèles à code ouvert, qui peuvent être adaptés et exécutés dans de nombreux contextes. Cette ouverture favorise l’innovation et l’expérimentation. Elle signifie aussi que l’architecture initialement entraînée et évaluée peut être modifiée par d’autres acteurs, pour un besoin d’optimisation légitime comme dans le cadre d’un changement qui échappe au contrôle du concepteur.

La vulnérabilité ICET : quand la compression affaiblit les refus

Les chercheurs désignent le phénomène observé par l’expression Image Encoder Early Exit, abrégée en ICET. Il correspond au cas où l’exécution de l’encodeur visuel s’arrête plus tôt que prévu, parce que certaines de ses couches ont été supprimées. L’image est alors analysée par une version incomplète de ce composant.

Le constat central est préoccupant : après ce type de réduction, un modèle peut perdre une partie de son aptitude à détecter et bloquer des interactions dangereuses. Autrement dit, l’alignement de sécurité, c’est-à-dire l’ensemble des comportements qui conduisent l’IA à refuser certaines requêtes, ne serait pas nécessairement réparti de façon uniforme dans toutes les couches de l’encodeur.

Les conséquences envisagées concernent des réponses qui n’auraient pas dû être produites, notamment face à des demandes cherchant des instructions relatives à des activités dangereuses ou à la diffusion de propos haineux. Il ne s’agit pas de dire que tout modèle compressé devient dangereux. L’étude montre plutôt qu’une sûreté évaluée sur l’architecture complète ne garantit pas automatiquement une sûreté identique une fois cette architecture modifiée.

Pourquoi les images et le texte peuvent-ils former une combinaison sensible ?

Pour vérifier cette vulnérabilité, l’équipe a travaillé avec LLaVA 1.5, un modèle de langage visuel. Ce type d’IA reçoit simultanément une image et une consigne écrite. Il doit donc interpréter le contenu visuel, comprendre la question, puis produire une réponse cohérente en tenant compte de ces deux sources d’information.

Les tests ont montré que certaines associations entre une image inoffensive et une question malveillante pouvaient contourner les filtres de sécurité lorsque l’encodeur d’images avait été réduit. L’image n’a pas besoin d’être inquiétante pour que l’ensemble de la requête pose problème. C’est précisément l’articulation entre les signaux visuels et textuels qui rend ce cas important : un modèle multimodal ne traite pas chaque élément dans une bulle séparée.

Ce résultat rappelle que la sécurité d’une IA ne peut pas toujours être vérifiée à partir du texte seul. Les systèmes qui analysent plusieurs types de données, comme les images, le son ou la vidéo, ouvrent des possibilités utiles. Ils exigent aussi des évaluations qui reproduisent les interactions entre ces modalités.

La vulnérabilité ICET est particulièrement pertinente pour les appareils décentralisés. Lorsqu’un modèle tourne localement, il peut ne pas bénéficier de la même supervision, ni des mêmes mécanismes de contrôle qu’un service hébergé dans un centre de données. Conserver un comportement fiable directement dans le modèle devient alors un enjeu concret de conception.

Comment L-PPO cherche à conserver la sécurité dans un modèle allégé

Face à ce problème, les chercheurs proposent une méthode appelée Layer-wise Clip-PPO, ou L-PPO. Son principe est de réentraîner la structure interne du modèle afin que la compréhension des contenus à risque et la capacité à les refuser demeurent actives, même après la suppression de certaines couches essentielles de l’encodeur d’images.

L’idée marque une différence avec une protection ajoutée uniquement à la fin du processus. Un filtre externe peut examiner une demande ou une réponse pour tenter de bloquer un contenu problématique. Cette couche de contrôle peut être utile, mais elle ne modifie pas nécessairement la façon dont l’IA construit son interprétation en interne. L-PPO vise au contraire le comportement du modèle lui-même, en travaillant au niveau de ses couches.

Les auteurs décrivent cette démarche comme une forme de « piratage bienveillant ». L’expression renvoie à une logique de test et de correction avant qu’une faiblesse ne soit exploitée dans des conditions réelles. Il s’agit d’identifier les points où le retrait de couches fait céder les protections, puis de renforcer le modèle pour qu’il conserve les bons réflexes dans cette configuration dégradée.

Les essais rapportés sur LLaVA 1.5 indiquent qu’après cette phase de réentraînement, le modèle retrouve une capacité fiable à refuser des requêtes dangereuses, y compris lorsqu’il fonctionne avec un nombre réduit de couches d’origine. Le résultat est important, car il suggère qu’il est possible de ne pas choisir mécaniquement entre un modèle compact et un modèle sûr.

Pourquoi les filtres externes ne suffisent pas toujours

Un système de sécurité robuste peut combiner plusieurs niveaux de protection. Des règles d’usage, des filtres de sortie, des mécanismes de surveillance et des procédures de mise à jour restent utiles. Mais l’étude de Riverside pointe une limite précise : si les représentations internes d’un modèle changent après une compression, un contrôle placé seulement à l’extérieur peut ne pas répondre à toutes les formes de fragilité.

La méthode L-PPO ne prétend pas résoudre à elle seule l’ensemble des risques liés à l’intelligence artificielle. Elle traite un scénario particulier, celui d’un encodeur d’images raccourci dans un modèle multimodal. D’autres modifications d’architecture, d’autres modèles, ou d’autres modes de compression devront faire l’objet de vérifications propres.

Cette nuance est essentielle. En sécurité informatique comme en sûreté des modèles, une protection ne devient crédible qu’après avoir été testée dans les conditions concrètes où le système sera utilisé. La démonstration sur LLaVA 1.5 constitue donc une piste, pas un certificat général applicable automatiquement à toutes les IA à code ouvert.

Une recherche présentée à l’ICML 2025

Les travaux, auxquels participent notamment Amit Roy-Chowdhury et Saketh Bachu, ont été présentés lors de l’International Conference on Machine Learning, l’ICML, à Vancouver. Cette conférence figure parmi les grands rendez-vous internationaux de la recherche en apprentissage automatique.

Le choix de ce forum illustre l’importance croissante accordée à la sécurité des modèles au sein de la recherche en IA. Pendant longtemps, les débats ont surtout porté sur la capacité des systèmes à reconnaître, classer ou générer du contenu. Avec la diffusion rapide des modèles à code ouvert et des usages sur des matériels variés, les chercheurs s’intéressent davantage à ce qui se produit lorsqu’un modèle sort de sa configuration d’origine.

Le sujet recoupe également une question industrielle. La recherche d’efficacité énergétique est devenue incontournable, à la fois pour réduire les coûts et pour élargir l’accès à l’IA sur des appareils modestes. Mais une optimisation qui affaiblirait les protections pourrait créer un coût caché, sous la forme de nouveaux risques opérationnels, juridiques ou de réputation.

Ce qu’il faut surveiller pour des IA réellement robustes

La prochaine étape sera de vérifier dans quelle mesure ce type de réentraînement peut s’appliquer à des architectures, des tailles de modèles et des modes de compression différents. La variabilité de l’alignement de sécurité entre les couches de l’encodeur d’images reste un défi central : il faut comprendre où se situent les garde-fous et comment éviter que des représentations non protégées n’apparaissent après modification.

Il faudra aussi évaluer la généralisation de la méthode. Une IA réentraînée pour résister à un certain retrait de couches doit continuer à se comporter de façon sûre face à des formulations inédites et à des combinaisons variées d’images et de texte. C’est l’une des conditions pour éviter que des espaces de représentation, parfois appelés espaces d’embedding, restent insuffisamment protégés.

Enfin, ces travaux invitent les concepteurs et les organisations qui déploient des modèles à intégrer la sécurité dès la phase d’optimisation. La question n’est plus seulement : « Le modèle fonctionne-t-il après avoir été réduit ? » Elle devient : « Ses capacités et ses garde-fous fonctionnent-ils encore ensemble ? » Pour l’IA embarquée et les modèles à code ouvert, cette distinction pourrait devenir déterminante.