V神 explique : comment créer un environnement de travail IA entièrement local, discret et sous contrôle autonome

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 : toutes les inférences LLM s’exécutent localement, tous les fichiers sont stockés localement, et le tout est entièrement sandboxé, en évitant volontairement les modèles dans le cloud et les API externes.

Dès le début de l’article, il prévient : « Ne copiez pas directement les outils et technologies décrits dans cet article, et ne présumez 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 ? La sécurité des AI agents est largement sous-estimée

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

• Les AI agents peuvent modifier des paramètres critiques sans confirmation humaine, y compris ajouter de nouveaux canaux de communication et modifier les invites système
• L’analyse de n’importe quelle entrée externe malveillante (par ex. une page web malveillante) peut conduire à ce que l’agent soit entièrement pris en main ; lors d’une démonstration de HiddenLayer, des chercheurs ont fait résumer une série de pages web, dont l’une contenait une page malveillante capable d’ordonner à l’agent de télécharger et d’exécuter un script shell
• Certaines « compétences » tierces (skills) peuvent exfiltrer des données en silence, en envoyant des données vers un serveur externe contrôlé par l’auteur de la compétence via des instructions curl
• Dans les compétences qu’ils ont analysées, environ 15 % contiennent des instructions malveillantes

Vitalik souligne que son point de départ pour 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 d’une personne à une IA hébergée dans le cloud — alors même que le chiffrement de bout en bout et des logiciels “local first” deviennent enfin 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 personnelles, réduire au maximum l’utilisation de modèles distants
• Autre confidentialité : minimiser la fuite de données non liées aux LLM (par ex. requêtes de recherche, autres API en ligne)
• Évasion des LLM : empêcher le contenu externe de « pirater » mon LLM, de sorte qu’il agisse contre mes intérêts (par ex. en envoyant mes tokens ou des données privées)
• LLM involontaire : empêcher le LLM d’envoyer par erreur des données privées vers le mauvais canal ou de les rendre publiques sur le réseau
• Backdoor des LLM : empêcher des mécanismes cachés d’avoir été entraînés volontairement dans le modèle. Il rappelle en particulier ceci : les modèles ouverts sont des poids ouverts (open-weights) ; il n’y en a presque aucun qui soit réellement open-source

Choix du matériel : le 5090 de loin gagnant, DGX Spark décevant

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 :

Sa conclusion est la suivante : en dessous de 50 tok/sec, c’est trop lent ; 90 tok/sec est idéal. Le NVIDIA 5090 sur ordinateur portable offre l’expérience la plus fluide ; l’AMD a encore davantage de problèmes en périphérie pour l’instant, mais il est possible que cela s’améliore à l’avenir. Un MacBook haut de gamme est aussi une option valable, mais il n’a pas pu le tester lui-même.

À propos du DGX Spark, il n’y va pas avec le dos de la cuillère : « Il est décrit comme un “superordinateur de bureau pour l’IA”, mais en réalité le tokens/sec est plus bas que celui d’un bon GPU sur ordinateur portable, et en plus il faut encore s’occuper de détails comme la connexion réseau — c’est très décevant. » Sa recommandation est la suivante : si vous ne pouvez pas vous permettre un ordinateur portable haut de gamme, vous pouvez acheter ensemble, avec des amis, une machine suffisamment puissante, la placer dans un lieu avec une IP fixe, puis utiliser la connexion à distance pour tout le monde.

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

L’article de Vitalik, qui a été publié le même jour que la discussion sur les problèmes de sécurité de Claude Code, fait écho de façon intéressante : au moment où les agents IA entrent dans le flux de travail quotidien du développement, les problèmes de sécurité passent aussi progressivement de risques théoriques à des menaces réelles.

Son message central est très clair : à mesure que les outils d’IA deviennent de plus en plus puissants, qu’ils peuvent de plus en plus accéder à vos données personnelles et à vos droits sur les systèmes, « local d’abord, sandboxé, confiance minimale » n’est pas de la paranoïa, mais un point de départ rationnel.

• Cet article est reproduit avec autorisation de : « 链新闻 »
• Titre original : « Vitalik : Comment ai-je conçu un environnement de travail IA totalement local, privé et sous contrôle autonome ? »
• Auteur de l’original : Elponcrab