Le problème de l’IA locale a longtemps été facile à résumer : il faut assez de GPU et assez de mémoire.

Ce problème n’a pas disparu. Mais une autre couche commence à devenir tout aussi visible. Une fois la machine achetée, comment la transformer en quelque chose qu’une personne peut réellement utiliser tous les jours sans devenir administrateur système de son propre grille-pain à 4 000 euros ?

Un message publié le 10 août par Samuel Cardillo autour de son projet Cloudless donne un bon point de départ.1

Cardillo explique que Cloudless atteint selon lui un état « très stable » sur DGX Spark et qu’il prépare une extension vers des ordinateurs équipés de GPU, sous Linux mais aussi sous Windows via WSL. Il insiste sur un détail : l’objectif est de ne pas demander aux utilisateurs de réinstaller complètement leur système.1

À ce stade, ce sont les déclarations de l’auteur. Nous n’avons pas trouvé de dépôt public ou de documentation technique de Cloudless permettant de vérifier indépendamment son architecture, ses performances ou son niveau réel de maturité.

Mais la direction est intéressante parce qu’elle correspond à un problème beaucoup plus large et parfaitement vérifiable : le hardware de l’IA locale devient puissant plus vite que son expérience d’installation ne devient banale.

DGX Spark essaie déjà de vendre une machine, pas un GPU

NVIDIA ne présente plus DGX Spark comme une simple carte graphique très musclée.

La machine combine un processeur Grace Blackwell, 128 Go de mémoire unifiée, un stockage NVMe de 4 To et une pile logicielle préinstallée. NVIDIA la présente comme capable de travailler localement avec des modèles allant jusqu’à 200 milliards de paramètres dans certaines conditions.6

Le mot important n’est peut-être pas « 200 milliards ».

C’est préinstallée.

Le guide officiel décrit DGX OS, les drivers, CUDA, Docker, NVIDIA Container Runtime, NGC, JupyterLab, un dashboard, des outils de synchronisation et différents mécanismes de mise à jour.2 DGX OS lui-même est une distribution basée sur Ubuntu, adaptée au matériel NVIDIA avec les pilotes, réglages et diagnostics nécessaires.3

Autrement dit, NVIDIA a déjà compris qu’un « ordinateur IA personnel » ne peut pas être vendu uniquement comme une somme de TOPS et de gigaoctets. Il faut contrôler une partie du chemin entre le bouton d’alimentation et le premier modèle qui répond.

C’est exactement le rôle historique d’un appliance : prendre un ensemble compliqué de composants et en faire une machine avec une fonction identifiable.

Sauf qu’un ordinateur personnel est déjà occupé

DGX Spark bénéficie d’un avantage : c’est une machine dédiée. Son système peut être construit autour de son usage.

Un PC Windows avec une GeForce ou une workstation Linux existe déjà pour autre chose. Il contient des projets, des jeux, des logiciels Adobe, des environnements de développement, des drivers, des VPN d’entreprise, trois versions de Python et probablement un dossier appelé final_final_v2 quelque part.

Demander à son propriétaire de reformater la machine pour essayer une nouvelle pile d’IA locale est donc une très mauvaise proposition.

C’est ce qui rend la mention de WSL dans le message de Cloudless plus intéressante que le nom du projet lui-même.

WSL 2 permet depuis plusieurs années aux applications Linux d’accéder au GPU NVIDIA à travers le pilote Windows. La documentation CUDA précise que les applications CUDA Linux peuvent fonctionner dans cet environnement sans installer un second pilote NVIDIA à l’intérieur de WSL.5

Cette couche transforme Windows en terrain beaucoup plus crédible pour les outils IA conçus d’abord pour Linux.

Elle ne supprime pas les problèmes. Elle déplace la frontière.

Le nouveau produit est peut-être l’environnement

Regardez ce qui est nécessaire pour « faire tourner un modèle » aujourd’hui.

Il faut choisir un runtime. Choisir un format de poids. Comprendre si le modèle attend CUDA, ROCm, Metal ou autre chose. Installer les bons drivers. Gérer Python ou des conteneurs. Télécharger parfois plusieurs dizaines de gigaoctets. Choisir une quantification. Configurer un serveur. Régler le contexte. Décider où les modèles sont stockés. Puis recommencer lorsqu’un composant change de version.

Les outils comme Ollama, LM Studio ou llama.cpp ont déjà énormément réduit cette friction à différents niveaux. Mais dès qu’on sort du chemin heureux, la pile réapparaît.

Le récent projet Model Serving Minefield que nous avons couvert sur IRZ documente précisément cette face cachée : un modèle peut répondre normalement alors qu’un template, un kernel, un parser ou un runtime fausse la mesure finale.

L’étape suivante de l’IA locale n’est donc pas seulement un meilleur moteur d’inférence. C’est peut-être une couche d’exploitation capable de répondre à des questions beaucoup moins sexy :

  • quel matériel est présent ;
  • quel runtime est réellement compatible ;
  • quel modèle peut tenir en mémoire ;
  • comment le télécharger et le mettre à jour ;
  • comment exposer une API locale stable ;
  • comment démarrer et arrêter proprement les services ;
  • comment revenir en arrière lorsqu’une mise à jour casse quelque chose ;
  • comment faire tout cela sans demander à l’utilisateur de sacrifier son installation existante.

Ce produit ressemble moins à un chatbot qu’à un mélange de gestionnaire de paquets, de Docker Desktop et de console de jeu.

C’est probablement une bonne nouvelle.

Le hardware lui-même devient plus appliance

Les notes de version de DGX Spark montrent que NVIDIA travaille déjà sur des détails qui n’ont rien d’un benchmark spectaculaire.

La mise à jour de juillet 2026 améliore notamment la gestion des situations de mémoire insuffisante sur l’architecture unifiée du GB10 et permet de modifier la quantité de mémoire réservée à l’affichage. La documentation précise même que les utilisateurs en « appliance mode » n’ont normalement pas besoin de toucher au réglage par défaut.4

Cette phrase est révélatrice.

Quand un constructeur commence à distinguer l’usage « appliance » de l’usage poste de travail, il reconnaît deux attentes différentes. Le développeur veut pouvoir ouvrir le capot logiciel. L’utilisateur veut que la boîte accomplisse sa fonction et revienne demain dans le même état.

L’IA locale a besoin des deux.

Windows est le test difficile

Linux est naturel pour beaucoup de stacks IA parce que les outils de serveur, conteneurs et GPU y vivent depuis longtemps.

Windows est plus intéressant comme test produit parce qu’il force une question : peut-on ajouter l’IA locale à un ordinateur existant sans lui demander de devenir une autre machine ?

WSL offre une réponse partielle. Il donne un environnement Linux et l’accès CUDA tout en laissant Windows rester Windows.5

Mais une bonne couche produit doit ensuite cacher une partie de cette dualité. L’utilisateur ne devrait pas avoir à savoir si son serveur tourne dans WSL, où se trouve le filesystem virtuel, quel port traverse quelle couche ou pourquoi un modèle téléchargé deux fois occupe soudain 90 Go.

C’est ici que Cloudless devra être jugé lorsqu’il deviendra réellement inspectable : pas sur sa capacité à lancer une commande que quelqu’un pouvait déjà lancer dans un terminal, mais sur la quantité de décisions techniques qu’il retire sans retirer le contrôle.

« Sans cloud » ne veut pas dire « sans infrastructure »

Le nom Cloudless porte enfin une petite ironie utile.

Faire disparaître le cloud ne fait pas disparaître l’infrastructure. Cela la déplace chez vous.

Le stockage doit toujours être géré. Les modèles doivent toujours être versionnés. Les services doivent démarrer. La mémoire peut toujours manquer. Les dépendances peuvent toujours se contredire. Les ports peuvent toujours être occupés par quelque chose d’absurde que vous avez lancé il y a six mois.

Le cloud masquait une partie de ces problèmes derrière une API et une facture.

L’IA locale doit construire son propre équivalent de cette simplicité sans reconstruire la dépendance qu’elle cherchait précisément à éviter.

Le prochain benchmark pourrait être le temps jusqu’au premier usage

Nous comparons beaucoup les machines locales en tokens par seconde, taille maximale de modèle et bande passante mémoire.

Il manque une mesure beaucoup plus humaine : combien de temps entre “j’ai cette machine” et “mon outil fonctionne de manière fiable” ?

Puis une seconde : combien de temps faut-il pour le remettre en état lorsqu’il casse ?

DGX Spark tente de répondre en contrôlant hardware et OS. WSL rend possible une autre approche sur les PC Windows existants. Des projets comme Cloudless semblent vouloir occuper l’espace entre les deux : transformer un GPU disponible en service local sans transformer l’utilisateur en mainteneur de distribution Linux.

Cloudless est encore trop opaque pour savoir s’il réussira.

Mais son objectif pointe vers un changement important. Le matériel local commence à être assez puissant pour que la friction d’exploitation devienne le prochain goulot d’étranglement visible.

À ce moment-là, gagner l’IA locale ne voudra plus seulement dire faire tourner le plus gros modèle.

Cela voudra dire construire la machine que l’on oublie enfin d’administrer.