Pourquoi les SLM ne sont pas des mini-LLM
Un Small Language Model (SLM) n'est pas juste un GPT-4 compressé. C'est un modèle optimisé pour tourner en local : moins de paramètres, consommation mémoire basse, latence prévisible. Mais cette optimisation crée aussi de nouvelles failles.
Les attaques classiques contre LLM (jailbreak, injection de prompt) fonctionnent aussi sur les SLM. Mais elles rencontrent une cible différente : pas de serveur tiers qui filtre, pas d'isolation réseau, accès direct aux fichiers locaux, et souvent zéro défense applicative parce que « c'est du modèle ».
Quand le modèle est chez toi, sur ton appareil, l'attaquant n'a plus besoin de faire passer un message par un serveur tiers. Il peut accéder directement au modèle, à ses poids, à ses fichiers de contexte, et à ce que l'application en fera.
LLM au cloud vs SLM embarqué
Infrastructure
Serveur distant, contrôlé par le fournisseur. Isolation réseau entre ton requête et le modèle. Logging centralisé, audit traçable.
Infrastructure
Sur ton appareil, ton processus. Aucune isolation réseau. Aucun serveur intermédiaire pour filtrer. Audit absent ou très local.
Garde-fous
Le fournisseur impose des garde-fous au niveau du serveur : filtrage des entrées, modération des sorties, listes noires de prompts dangereux.
Garde-fous
Souvent aucun. Le développeur doit les implémenter lui-même, et peu le font correctement. C'est une couche d'application, pas une couche modèle.
Extraction
Extraire le modèle entier est théoriquement possible (reverse-engineer l'API) mais coûteux. Les poids sont protégés au serveur.
Extraction
Trivial. Les poids sont sur ton disque, en clair ou chiffrés faiblement. Tu peux copier le modèle, l'analyser, le reproduire.
Accès au contexte
Le contexte (données utilisateur, secrets applicatifs) ne sort pas du serveur si le fournisseur est rigoureux. Isole malveillance.
Accès au contexte
Si le SLM a accès à des fichiers locaux (pour le RAG embarqué), l'attaquant peut l'y forcer directement. Pas de barrière.
Les attaques spécifiques aux SLM
1. Extraction et clonage direct
Aucune API n'intervient. Tu as accès au fichier `.onnx`, `.safetensors` ou `.bin` du modèle. Tu peux :
- Copier le modèleLe distribuer, l'intégrer dans un produit concurrent.
- L'analyserDébugger ses comportements, trouver les points faibles programmatiqu
- Le fine-tunerLe réentraîner sur des données pour le modifier.
- L'exfiltrerMettre à disposition le modèle intégral sur un forum ou un site.
2. Accès aux fichiers de contexte (RAG embarqué)
Un SLM embarqué fonctionne souvent en RAG : il interroge une base documentaire locale. Si tu parviens à le faire accéder à un fichier qu'il ne devrait pas voir, tu as une extraction de données.
3. Jailbreak sans couche applicative
Un LLM cloud a des garde-fous au niveau du serveur : si tu essaies de générer un exploit, le serveur refuse. Un SLM embarqué ? Pas de serveur. Le jailbreak fonctionne immédiatement si tu peux accéder au modèle.
4. Démonstration d'attaque hors ligne
Tu n'as pas besoin de réseau, pas besoin de l'API du fournisseur. Tu montres l'attaque en local, reproductivement. Le fournisseur du SLM ne peut pas dire « on a patché l'API ».
5. Réingénierie du prompt système
Le prompt système du SLM est souvent stocké dans la config de l'app, pas caché. Il est facile à extraire. Pas besoin du jailbreak raffiné qu'on userait contre un LLM cloud.
IoT et appareils edge : des enjeux spécifiques
Les SLM embarqués sur IoT (caméra intelligente, thermostat, microphone) ajoutent une couche d'enjeu : l'accès au matériel lui-même.
- Extraction du modèle via le flashL'appareil stocke le modèle en mémoire flash. Si tu peux lire le flash (via un débogueur, une faille d'accès mémoire), tu as le modèle entier.
- Modification du modèle ou des poidsSi tu écris sur le flash, tu peux altérer le comportement du modèle. Il fera ensuite ce que tu lui as codé.
- Exfiltration de données capturéesSi le SLM analyse du contenu (audio, vidéo) localement, tu peux le forcer à transmettre ce qu'il a vu, entendu, ou traité.
- Chaîne d'attaque : matériel → modèle → applicationCompromettre l'appareil, modifier le modèle, puis utiliser l'application compromise pour faire quelque chose de dangereux.
Scénario d'attaque réaliste : téléphone avec SLM
Un téléphone Android intègre un SLM pour l'assistant vocal local.
Étape 1 : Je télécharge l'app Android, l'extrais avec un outil public, et accède au répertoire `/assets/`. Je trouve `model.onnx` — le SLM complet.
Étape 2 : Je jailbreak le SLM localement en testant des prompts. Je découvre qu'il n'a aucun garde-fou en local. J'enregistre les exploits.
Étape 3 : Je crée une malveillance : remplace `model.onnx` par une version modifiée, recréée l'app, et la distribue sur un site de torrents populaire.
Étape 4 : Les utilisateurs qui installent cette app compromise ont un SLM qui exfiltrera secrètement les données de l'écran, les enregistrera, et les enverra ailleurs.
Impact : Compromission massive, chiffré de millions de données sensibles capturées par un « assistant intelligent ».
Parce que le modèle n'a aucune isolation, que son extraction est triviale, et que les développeurs supposent que « c'est dans l'app, donc c'est sûr ». Non.
Directions pour la défense
- Chiffrer le modèle au reposPasse le fichier du modèle en chiffré. C'est un ralentissement, pas une prévention totale, mais ça monte la barre.
- Verrouiller le modèle au matérielLie le modèle à un identifiant d'appareil (TEE, Secure Enclave). Une copie sur un autre appareil ne fonctionne pas.
- Implémenter les garde-fous au niveau appFiltrage des entrées, modération des sorties — c'est ta responsabilité, pas celle du SLM.
- Isoler l'accès aux fichiersSi le SLM consomme du contexte local, restreins l'OS au répertoire autorisé. Utilise des permissions d'app strictes.
- Auditer régulièrement le modèleChaque mise à jour, vérifie que les poids n'ont pas été altérés. Hash + signature.
Lien aux LLM cloud : une menace hybride
Beaucoup d'apps combinent les deux : un SLM embarqué pour les tâches rapides (traitement local), et un appel à un LLM cloud pour les requêtes complexes. Cette hybridation crée une zone grise :
- Lequel des deux attaquer ?Si je compromise le SLM embarqué, je peux tromper la couche cloud. Si je compromise la requête vers le cloud, je peux tromper le SLM local.
- Où tracer l'attaque ?Les logs du SLM local sont chez toi. Les logs du LLM cloud sont chez le fournisseur. Une attaque hybride brouille les pistes.