Vitalik Buterin propose une architecture d’IA exécutée 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 : tous les raisonnements LLM s’exécutent en local, tous les fichiers sont stockés localement, et le tout est entièrement cloisonné dans des bacs à sable (sandbox) ; il évite volontairement les modèles dans le cloud et les API externes.
En ouverture de l’article, il commence par avertir : « Ne copiez pas directement les outils et techniques décrits dans cet article, et ne supposez pas qu’ils sont sûrs. Ceci n’est qu’un point de départ, pas une description d’un produit fini. »
Pourquoi écrire maintenant ? Les problèmes de sécurité des agents IA sont largement sous-estimés
Vitalik souligne qu’au début de cette année, l’IA a accompli une transformation majeure, passant des « robots conversationnels » aux « agents » : vous ne vous contentez plus de poser des questions, vous confiez des tâches à l’IA, qui réfléchit longtemps et appelle des centaines d’outils pour les exécuter. Il prend pour exemple OpenClaw (actuellement le repo qui connaît la croissance la plus rapide de l’histoire de GitHub) et cite en même temps plusieurs problèmes de sécurité documentés par des chercheurs :
- Les agents IA peuvent modifier des paramètres critiques sans confirmation humaine, notamment en ajoutant de nouveaux canaux de communication et en modifiant les messages système
- Analyser n’importe quelle entrée externe malveillante (comme une page web malveillante) peut amener l’agent à être entièrement pris en main ; lors d’une démonstration de HiddenLayer, des chercheurs ont fait résumer un lot de pages web, dont une contenait une page malveillante qui commande à l’agent de télécharger et d’exécuter un script shell
- Certains packs de compétences tiers (skills) exécutent une fuite silencieuse de données, en envoyant les données vers un serveur externe contrôlé par l’auteur de la compétence via des instructions curl
- Dans les packs de compétences qu’ils ont analysés, environ 15 % contiennent des instructions malveillantes
Vitalik insiste sur le fait que son approche de la confidentialité diffère de celle des chercheurs traditionnels en cybersécurité : « Je viens d’un point de vue profondément effrayé par l’idée de nourrir la vie personnelle entière d’une personne avec une IA dans le cloud — au moment même où le chiffrement de bout en bout et des logiciels donnant la priorité au local deviennent enfin la norme, on pourrait aussi bien faire dix pas en arrière. »
Cinq objectifs de sécurité
Il a défini un cadre clair d’objectifs de sécurité :
- Confidentialité du LLM : dans des scénarios impliquant des données personnelles, réduire au maximum l’usage des modèles distants
- Autres confidences (privacy) : minimiser les fuites de données autres que celles des LLM (par ex. les requêtes de recherche, d’autres API en ligne)
- Évasion du LLM : empêcher le contenu externe de « s’infiltrer » dans mon LLM, afin qu’il agisse à l’encontre de mes intérêts (par exemple envoyer mes tokens ou mes données privées)
- Erreur involontaire du LLM : empêcher le LLM d’envoyer par erreur des données privées vers un mauvais canal ou de les rendre publiques sur le réseau
- Porte dérobée du LLM : empêcher des mécanismes cachés, délibérément entraînés dans le modèle, de s’y activer. Il rappelle en particulier : un modèle ouvert correspond à des poids ouverts (open-weights), et il n’y en a presque aucun qui soit réellement open source (open-source)
Choix matériel : le 5090 d’emporte sur les autres, DGX Spark déçoit
Vitalik a testé trois configurations matérielles d’inférence locale ; il utilise principalement 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 laptop (24GB VRAM) | 90 | impossible à exécuter |
| AMD Ryzen AI Max Pro (128GB 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 est l’idéal. Le laptop NVIDIA 5090 est celui qui offre la meilleure expérience ; AMD a encore plus de problèmes de bord, mais l’avenir devrait permettre d’améliorer la situation. Un MacBook haut de gamme est aussi une option efficace, mais lui ne l’a pas personnellement testé.
À propos du DGX Spark, il est on ne peut plus direct : « Présenté comme un “superordinateur de l’IA pour le bureau”, mais en réalité, ses tokens/sec sont plus bas que ceux des GPU de meilleurs laptops, et en plus il faut aussi gérer des détails comme la connexion réseau — c’est vraiment nul. » Sa recommandation est la suivante : si vous n’avez pas les moyens d’acheter un laptop haut de gamme, vous pouvez en acheter un suffisamment puissant à plusieurs avec des amis, le placer dans un endroit disposant d’une adresse IP fixe, et chacun l’utilisera à distance.
Pourquoi les problèmes de confidentialité de l’IA locale sont plus urgents que ce que vous imaginez
L’article de Vitalik, en écho intéressant à la discussion sur la sécurité du Claude Code publiée le même jour, montre que pendant que les agents IA entrent dans les flux de travail quotidiens de développement, les problèmes de sécurité passent eux aussi d’un risque théorique à une menace réelle.
Son message central est très clair : à mesure que les outils IA deviennent de plus en plus puissants et peuvent accéder de plus en plus à vos données personnelles et à vos privilèges système, « local d’abord, sandboxing, confiance minimale » n’est pas de la paranoïa, mais un point de départ rationnel.
- Cet article est reproduit avec l’autorisation de : 《Chaîne d’Actualités》
- Titre original : 《Vitalik : Comment j’ai conçu un environnement de travail IA totalement local, privé et contrôlable par l’utilisateur》
- Auteur de l’original : Elponcrab
