V神 partage : comment créer un environnement de travail d’IA entièrement local, discret et sous contrôle autonome et maîtrisé

Vitalik Buterin propose une architecture d’IA en exécution locale, en mettant l’accent sur la confidentialité, la sécurité et la souveraineté de soi, tout en mettant en garde contre les risques potentiels liés aux agents d’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 d’IA conçu autour de la confidentialité, de la sécurité et de la souveraineté de soi : 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 intentionnellement les modèles dans le cloud et les API externes.

Dès le début, l’article commence par avertir : « Ne copiez pas directement les outils et technologies décrits dans cet article, et ne supposez pas qu’ils sont sûrs. Ce n’est qu un point de départ, et non une description d’un produit terminé. »

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

Vitalik indique qu’au début de cette année, l’IA a effectué une transformation importante, passant de « chatbot » à « agent ». Désormais, vous ne faites plus seulement des questions : vous confiez des tâches, ce qui permet à l’IA de réfléchir longtemps, d’appeler des centaines d’outils pour exécuter des actions. Il donne l’exemple d’OpenClaw (actuellement le repo qui connaît la croissance la plus rapide de l’histoire de GitHub), et cite également plusieurs problèmes de sécurité recensés par des chercheurs :

• Les AI agents peuvent modifier des paramètres critiques sans validation humaine, notamment en ajoutant de nouveaux canaux de communication et en modifiant les invites système
• L’analyse de toute entrée externe malveillante (comme une page web malveillante) peut conduire à une prise de contrôle complète de l’agent ; dans une démonstration de HiddenLayer, des chercheurs ont fait résumer une série de pages web, dont l’une contenait une page malveillante qui ordonnait à l’agent de télécharger et d’exécuter un script shell
• Certains paquets de compétences tiers (skills) exécutent une fuite silencieuse de données, en envoyant les données via des commandes curl vers des serveurs externes contrôlés par l’auteur des compétences
• Parmi les compétences qu’ils ont analysées, environ 15 % contiennent des instructions malveillantes

Vitalik souligne que son point de départ sur la confidentialité est différent de celui des chercheurs traditionnels en cybersécurité : « Je viens d’une position profondément effrayée par l’idée de fournir toute une vie privée à une IA dans le cloud — alors même que le chiffrement de bout en bout et les logiciels “local-first” viennent enfin de devenir la norme, nous risquons de reculer de dix pas. »

Cinq objectifs de sécurité

Il a défini un cadre d’objectifs de sécurité clairs :

• Confidentialité des LLM : dans les situations impliquant des données de confidentialité, réduire au maximum l’usage de modèles distants
• Autres confidences : minimiser la fuite de données hors LLM (comme les requêtes de recherche, d’autres API en ligne)
• Évasion des LLM : empêcher le contenu externe de « pirater » mon LLM, afin qu’il agisse à contre intérêt (par exemple envoyer mes tokens ou des données privées)
• LLM accidentel : 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
• Porte dérobée des LLM : empêcher les mécanismes cachés d’être entraînés délibérément dans le modèle. Il rappelle tout particulièrement : les modèles ouverts sont 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’ordinateur portable l’emporte, DGX Spark déçoit

Vitalik a testé trois configurations matérielles d’inférence locale, en utilisant 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. L’expérience avec le portable NVIDIA 5090 est la plus fluide ; l’AMD a encore plus de problèmes marginaux pour l’instant, mais il y a de bonnes chances que cela s’améliore à l’avenir. Un MacBook haut de gamme est aussi un choix efficace, mais il ne l’a pas testé personnellement.

À propos du DGX Spark, il le dit sans ménagement : « Il est décrit comme un “superordinateur de bureau pour l’IA”, mais en réalité, les tokens/sec sont plus bas que ceux des GPU de bons ordinateurs portables, et en plus il faut encore gérer des détails comme la connexion réseau — c’est vraiment nul. » Sa recommandation est la suivante : si vous n’arrivez pas à vous offrir un ordinateur portable haut de gamme, vous pouvez en acheter un puissant à plusieurs avec des amis, le placer dans un lieu avec une IP fixe, puis chacun se connecter à distance pour l’utiliser.

Pourquoi les problèmes de confidentialité de l’IA locale sont plus urgents que vous ne le pensez

L’article de Vitalik, mis en regard avec la discussion sur les problèmes de sécurité de Claude Code publiée le même jour, fait écho de façon intéressante : tandis que les agents d’IA entrent dans les flux de travail quotidiens de développement, les problèmes de sécurité passent eux aussi 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, « local-first, sandboxing, 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 j’ai créé un environnement de travail d’IA totalement local, privé et sous contrôle autonome »
• Auteur de l’original : Elponcrab