V神 partage : 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 en local, 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 la configuration de son environnement de travail IA, construit autour de la confidentialité, de la sécurité et de la souveraineté personnelle : toutes les inférences LLM s’exécutent en local, tous les fichiers sont stockés en local, et l’ensemble est entièrement sandboxé, avec une volonté délibérée d’éviter les modèles dans le cloud et les API externes.

Dès l’ouverture de l’article, il prévient : « Veuillez ne pas copier directement les outils et techniques décrits dans cet article, et ne partez pas du principe qu’ils sont sûrs. Ceci n’est qu’un point de départ, et non une description d’un produit final. »

Pourquoi écrire maintenant ? Les problèmes de sécurité des AI agents sont largement sous-estimés

Vitalik souligne qu’au début de cette année, l’IA a franchi une transformation majeure, passant des « chatbots » 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 exécuter le travail. Il donne l’exemple d’OpenClaw (actuellement le repo qui a la croissance la plus rapide de l’histoire de GitHub) et cite 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 en ajoutant de nouveaux canaux de communication et en modifiant les invites système
• L’analyse de n’importe quelle entrée externe malveillante (comme une page web mal intentionnée) peut conduire à une prise de contrôle totale de l’agent ; lors d’une démonstration d’HiddenLayer, des chercheurs ont fait résumer un lot de pages web, dont l’une contenait une page malveillante qui ordonne à l’agent de télécharger et d’exécuter un script shell
• Certains packs de compétences tierces (skills) exécutent des fuites silencieuses de données, en envoyant les données via des instructions 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 insiste sur le fait que son point de départ en matière de confidentialité diffère de celui des chercheurs classiques en cybersécurité : « Je viens d’une position profondément effrayée par l’idée de donner toute la vie privée d’une personne à une IA dans le cloud. — Alors même que le chiffrement de bout en bout et les logiciels qui privilégient le local deviennent enfin la norme, nous pourrions pourtant 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 des scénarios impliquant des données personnelles, réduire au maximum l’usage des modèles distants
• Autres confidenti(al)ités : minimiser les fuites de données non liées aux LLM (par ex. les requêtes de recherche, d’autres API en ligne)
• Jailbreak des LLM : empêcher le contenu externe de « pirater » mon LLM, de sorte qu’il agisse à l’encontre de mon intérêt (par exemple, envoyer mes tokens ou des données privées)
• Erreur imprévue des LLM : 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’être entraînés intentionnellement dans le modèle. Il rappelle tout particulièrement : les modèles ouverts sont des poids ouverts (open-weights), et il y en a presque aucun qui soit réellement open-source

Choix matériel : la 5090 d’ordinateur portable l’emporte, DGX Spark déçoit

Vitalik a testé trois configurations matérielles d’inférence en local. Son principal modèle est Qwen3.5:35B, avec l’association de llama-server et llama-swap :

Sa conclusion est la suivante : en dessous de 50 tok/sec c’est trop lent, 90 tok/sec est l’idéal. L’expérience avec la NVIDIA 5090 d’ordinateur portable est la plus fluide ; l’AMD a encore plus de problèmes de bord actuellement, mais il y a espoir d’amélioration à l’avenir. Un MacBook haut de gamme est aussi une option efficace, mais il ne l’a pas essayé personnellement.

À propos du DGX Spark, il l’exprime sans détour : « Présenté comme un “superordinateur de bureau pour l’IA”, 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 encore gérer des détails comme la connexion réseau — c’est plutôt nul. » Sa recommandation est la suivante : si vous ne pouvez pas vous permettre un ordinateur portable haut de gamme, achetez-en un suffisamment puissant avec des amis, installez-le dans un endroit disposant d’une IP fixe, puis utilisez-le à distance avec tous.

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

L’article de Vitalik, mis en regard avec la discussion sur la sécurité du lancement le même jour de Claude Code, fait écho de manière intéressante : pendant que les agents IA entrent dans les flux de développement du quotidien, les problèmes de sécurité passent eux 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 et capables d’accéder à vos données personnelles et aux droits de votre système, « priorité au local, sandboxing, confiance minimale » n’est pas de la paranoïa, mais un point de départ rationnel.

• Cet article est reproduit sous licence de : 《Chaîne d’actualités》
• Titre original : 《Vitalik : Comment je conçois un environnement de travail IA entièrement local, privé et contrôlable de manière autonome》
• Auteur de l’article original : Elponcrab