V神 partage : comment créer un environnement de travail d’IA entièrement local, discret et contrôlable de manière autonome

Vitalik Buterin propose une architecture d’IA exécutable 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 l’environnement de travail IA qu’il a conçu avec, au cœur, la confidentialité, la sécurité et la souveraineté personnelle : toutes les inférences LLM s’exécutent localement, tous les fichiers sont stockés localement, l’ensemble est intégralement isolé dans un bac à sable, avec une volonté délibérée d’éviter les modèles cloud et les API externes.

Dès l’ouverture de l’article, il prévient : « Ne copiez pas directement les outils et technologies décrits dans cet article en supposant qu’ils sont sûrs. Ce n’est qu’un point de départ, pas une description d’un produit fini. »

Pourquoi écrire maintenant : la question de la sécurité des agents IA est gravement sous-estimée

Vitalik indique qu’au début de cette année, l’IA a opéré une transformation importante, passant de « chatbot » à « agent » : vous ne vous contentez plus de poser des questions, vous confiez des tâches à l’IA, qui réfléchit longtemps, appelle des centaines d’outils pour les exécuter. Il donne l’exemple d’OpenClaw (actuellement le repo qui progresse le plus vite de l’histoire de GitHub) et cite en même temps plusieurs problèmes de sécurité recensés par des chercheurs :

• Les agents IA peuvent modifier des paramètres critiques sans validation 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 à une prise de contrôle totale de l’agent ; lors d’une démonstration par HiddenLayer, les chercheurs ont fait résumer une série de pages web, dont une contenait une page malveillante qui ordonnait à l’agent de télécharger et d’exécuter un script shell
• Certains packs de compétences tiers (skills) exécutent des fuites silencieuses de données, en envoyant des données via des commandes curl vers un serveur externe contrôlé par l’auteur de la compétence
• Dans les packs de compétences qu’ils ont analysés, environ 15 % contiennent des instructions malveillantes

Vitalik souligne que son point de vue sur la confidentialité diffère de celui des chercheurs traditionnels en cybersécurité : « Je viens d’une position profondément effrayée à l’idée de confier toute la vie privée des gens à une IA hébergée dans le cloud — alors même que le chiffrement de bout en bout et les logiciels “local first” sont enfin en train de devenir la norme, nous risquons peut-être de 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 les situations impliquant des données personnelles, réduire au maximum l’usage de modèles distants
• Autre confidentialité : minimiser les fuites de données non liées aux LLM (par exemple, les requêtes de recherche, d’autres API en ligne)
• Jailbreak du LLM : empêcher le contenu externe de « pirater » mon LLM et de le faire agir contre mes intérêts (par exemple, envoyer mes tokens ou des données privées)
• Erreur involontaire du LLM : empêcher le LLM d’envoyer par erreur des données privées vers le mauvais canal ou de les publier sur Internet
• Porte dérobée du LLM : empêcher un mécanisme caché d’être entraîné délibérément dans le modèle. Il rappelle tout particulièrement : un modèle ouvert correspond à des poids ouverts (open-weights), et il y en a presque aucun qui soit réellement open source (open-source)

Choix matériel : 5090 notebook gagnant, DGX Spark décevant

Vitalik a testé trois configurations matérielles d’inférence locale, utilisant principalement le modèle Qwen3.5:35B, avec llama-server et llama-swap :

Son constat est le suivant : en dessous de 50 tok/sec, c’est trop lent ; 90 tok/sec est idéal. Le notebook NVIDIA 5090 offre l’expérience la plus fluide ; l’AMD a encore davantage de problèmes sur les bords, mais il y a de bonnes chances que cela s’améliore à l’avenir. Un MacBook haut de gamme est aussi une option valable, mais lui-même ne l’a pas testé personnellement.

À propos du DGX Spark, il le dit sans détour : « On le décrit comme un “superordinateur AI pour le bureau”, mais en réalité il est plus lent en tokens/sec que le GPU d’un bon notebook, et il faut en plus régler des détails comme la connexion réseau — c’est vraiment décevant. » Sa recommandation est la suivante : si vous ne pouvez pas vous offrir un notebook haut de gamme, vous pouvez acheter ensemble, avec des amis, une machine suffisamment puissante, la placer dans un lieu avec une IP fixe, puis chacun utiliser une connexion à distance.

Pourquoi les problèmes de confidentialité de l’IA locale sont plus urgents que ce que vous imaginez

L’article de Vitalik, publié le même jour que la discussion sur les problèmes de sécurité de Claude Code, fait un écho intéressant : tandis que les agents IA entrent dans les flux de travail quotidiens de développement, les problèmes de sécurité passent eux aussi progressivement de risques théoriques à des menaces bien réelles.

Son message central est très clair : à mesure que les outils d’IA deviennent de plus en plus puissants et qu’ils peuvent de plus en plus accéder à vos données personnelles et aux autorisations de votre système, « prioriser le local, isoler dans un bac à sable, faire le moins de confiance possible » n’est pas de la paranoïa, mais un point de départ rationnel.

• Cet article est reproduit avec autorisation de : 《Chaîne News》
• 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