Vitalik Buterin propose une architecture d’IA à exécuter localement, en mettant l’accent sur la confidentialité, la sécurité et la souveraineté personnelle, tout en mettant en garde contre les risques potentiels des agents IA.
Le fondateur d’Ethereum, Vitalik Buterin, a publié le 2 avril, sur son site personnel, un long article dans lequel il partage son environnement de travail IA conçu autour de la confidentialité, de la sécurité et de la souveraineté personnelle : toute inférence des LLM s’exécute localement, tous les fichiers sont stockés localement, et le tout est entièrement mis en bac à sable (sandbox), en évitant volontairement les modèles cloud et les API externes.
En introduction, l’article commence par un avertissement : « Ne copiez pas directement les outils et techniques décrits dans cet article, et ne présumez pas qu’ils sont sûrs. Il ne s’agit que d’un point de départ, et non d’une description d’un produit final. »
Pourquoi écrire maintenant : la sécurité des agents IA est gravement sous-estimée
Vitalik indique qu’au début de cette année, l’IA a réalisé une transformation importante, passant des « robots conversationnels » aux « agents » : vous ne vous contentez plus de poser des questions, mais vous confiez des tâches, ce qui permet à l’IA de réfléchir longtemps et d’appeler des centaines d’outils pour les exécuter. Il prend l’exemple d’OpenClaw (actuellement le dépôt qui a la plus forte croissance de l’histoire de GitHub) et cite, en les mettant aussi en avant, plusieurs problèmes de sécurité recensés par des chercheurs :
- Les agents IA peuvent modifier des réglages critiques sans confirmation humaine, notamment en ajoutant de nouveaux canaux de communication et en modifiant les invites système
- Analyser toute entrée externe malveillante (comme une page web malveillante) peut conduire à ce que l’agent soit entièrement pris en main ; lors d’une démonstration menée par HiddenLayer, des chercheurs ont fait résumer un lot de pages web, dont l’une contenait une page malveillante capable de commander à l’agent de télécharger et d’exécuter un script shell
- Une partie des kits de compétences tiers (skills) peut exfiltrer silencieusement des données, via des instructions curl, en envoyant les données vers un serveur externe contrôlé par l’auteur des compétences
- Parmi les kits de compétences qu’ils ont analysés, environ 15 % contiennent des instructions malveillantes
Vitalik souligne que son point de départ sur la confidentialité diffère de celui des chercheurs traditionnels en cybersécurité : « Je viens d’un point de vue profondément effrayé par l’idée de confier l’intégralité de la vie personnelle à une IA dans le cloud : juste au moment où le chiffrement de bout en bout et les logiciels “local-first” finissent par devenir la norme, nous pourrions reculer de dix pas. »
Cinq objectifs de sécurité
Il a défini un cadre clair d’objectifs de sécurité :
- Confidentialité des LLM : dans les situations impliquant des données de confidentialité personnelle, réduire au maximum l’usage des modèles distants
- Autre confidentialité : minimiser les fuites de données qui ne concernent pas les LLM (comme les requêtes de recherche, et d’autres API en ligne)
- Jailbreak des LLM : empêcher le contenu externe de “pirater” mon LLM et de l’amener à agir contre mes intérêts (par exemple l’envoi de mes tokens ou de mes données privées)
- LLM involontaire : empêcher un LLM d’envoyer par erreur des données privées vers le mauvais canal ou de les publier sur le réseau
- Backdoor des LLM : empêcher des mécanismes cachés d’être intégrés au modèle de manière intentionnelle pendant l’entraînement. Il prévient en particulier : les modèles ouverts sont des poids ouverts (open-weights), et il y a presque aucun modèle réellement ouvert en tant que code source (open-source)
Choix matériel : la 5090 d’emporte, DGX Spark est décevant
Vitalik a testé trois configurations matérielles d’inférence locale. Son utilisation principale repose sur le modèle Qwen3.5:35B, avec llama-server et llama-swap :
| Matériel | Qwen3.5 35B (tokens/sec) | Qwen3.5 122B (tokens/sec) |
| --- | --- | --- |
| NVIDIA 5090 ordinateur portable (24GB VRAM) | 90 | impossible à exécuter |
| AMD Ryzen AI Max Pro (128GB de mémoire unifiée, Vulkan) | 51 | 18 |
| DGX Spark (128GB) | 60 | 22 |
Sa conclusion est la suivante : en dessous de 50 tok/sec, c’est trop lent ; 90 tok/sec, c’est l’idéal. Le ressenti sur l’ordinateur portable NVIDIA 5090 est le plus fluide ; l’AMD a encore plus de problèmes de bord aujourd’hui, mais il y a de l’espoir que cela s’améliore à l’avenir. Un MacBook haut de gamme est aussi une option valable, mais il ne l’a pas testé personnellement.
Concernant le DGX Spark, il l’a dit sans détour : « On le décrit comme un “superordinateur IA de bureau”, mais en réalité, les tokens/sec sont plus bas que ceux d’une bonne carte GPU d’ordinateur portable, et en plus il faut gérer tous les détails de connexion réseau — c’est vraiment nul. » Son conseil est : « Si vous ne pouvez pas vous permettre un ordinateur portable haut de gamme, achetez-en un suffisamment puissant à plusieurs avec des amis, placez-le dans un endroit où l’IP est fixe, et utilisez-le en connexion à distance. »
Pourquoi le problème de confidentialité de l’IA locale est plus urgent que ce que vous imaginez
L’article de Vitalik, avec les discussions sur les problèmes de sécurité de Claude Code publiées le même jour, forme un écho intéressant : pendant que les agents IA s’intègrent au quotidien dans les workflows de développement, les questions de sécurité passent elles aussi d’un risque théorique à une menace réelle.
Son message central est très clair : à mesure que les outils d’IA deviennent de plus en plus puissants et capables d’accéder à vos données personnelles et aux droits de votre système, « local-first, sandboxing, confiance minimale » n’est pas de la paranoïa, mais un point de départ rationnel.
- Cet article est reproduit sous licence depuis : 《Chaîne d’actualités》
- Titre original : 《Vitalik : comment j’ai créé un environnement de travail IA totalement local, privé et sous contrôle autonome》
- Auteur de l’article original : Elponcrab
