La puissance de calcul inutilisée autour de nous

Parfois, une grande question d’infrastructure commence par une toute petite image : un smartphone recharge pendant la nuit. L’ordinateur portable est fermé. La console de jeu attend dans le salon. La voiture est au garage. Partout, il y a de la puissance de calcul déjà payée, alimentée en électricité, et qui ne fait presque rien.

En même temps, de nouveaux centres de données apparaissent, aussi grands que des sites industriels. Des halls remplis de GPU, de fibre, de transformateurs, de refroidissement et de contrats d’électricité. Nous construisons une nouvelle couche d’infrastructure numérique, censée porter notre écriture, nos recherches, notre programmation, nos analyses et peut-être un jour aussi nos décisions.

Et si une petite partie de cette puissance ne se perdait pas simplement ? Pas comme une fantaisie où chaque téléphone remplacerait soudain un centre de données. Mais comme une expérience de pensée sérieuse : pourrait-il exister une sorte de réseau intelligent du calcul, dans lequel des appareils apporteraient volontairement, de façon limitée et rémunérée, de la puissance de calcul ?

Dans l’article De PRISM aux prompts, il est question de l’autre côté de cette évolution : la dépendance croissante envers quelques plateformes d’IA, surtout venues des États-Unis et de Chine. Ici, c’est l’idée inverse qui m’intéresse. Pas comme une rêverie P2P naïve, mais comme une question technique : quelle quantité de puissance de calcul est déjà répartie autour de nous, quelles tâches d’IA pourraient vraiment être distribuées, et que faudrait-il pour que les gens soient rémunérés équitablement ?

L’expérience de pensée

L’IA n’est pas seulement du logiciel. L’IA, c’est de l’électricité, du refroidissement, de la fibre, des GPU, du terrain, de l’eau et du capital. L’Agence internationale de l’énergie estime que les centres de données ont consommé environ 415 TWh d’électricité dans le monde en 2024, soit environ 1,5 pour cent de la consommation électrique mondiale. D’ici 2030, cela pourrait atteindre environ 945 TWh.

Ce n’est pas seulement un chiffre pour rapports de durabilité. C’est un sujet de politique d’infrastructure. Les services d’IA sont disponibles 24/7. Chaque résumé, chaque question de code, chaque image, chaque exécution d’agent est un calcul. Et quand des milliards de personnes et d’entreprises placent du travail dans des boucles d’IA, cela devient une charge de base.

C’est pourquoi je comprends la fascination pour les grandes solutions centrales. Les centres de données sont contrôlables : même matériel, mêmes racks, mêmes réseaux, zones de sécurité claires, SLA, monitoring, facturation. Du point de vue de l’exploitation, c’est attractif. Mais politiquement, économiquement et architecturalement, cela recrée exactement ce qui nous a toujours rendus vulnérables sur le réseau : quelques centres de pouvoir.

L’expérience de pensée commence donc par une contre-question simple : qu’est-ce qui existe déjà avant que nous construisions le prochain centre de données ?

Quelle est la taille de la capacité inutilisée ?

L’idée naît en réalité dans un moment très ordinaire. Le smartphone est posé la nuit sur la table de chevet, branché, et ne fait presque rien. Mais à l’intérieur se trouve une puce qui offre plus de puissance de calcul spécialisée pour l’IA que beaucoup d’ordinateurs n’en avaient, en tout, il y a dix ans. Un iPhone 15 Pro avec A17 Pro atteint environ 35 billions d’opérations Neural Engine par seconde. Même si l’on n’en prend qu’une moyenne prudente, c’est absurde pour un appareil qui attend pendant la plus grande partie de la nuit.

La même chose se produit sur le bureau. Les nouveaux ordinateurs portables n’ont plus seulement un CPU et un GPU, mais aussi des NPU ou des Neural Engines. Apple intègre depuis des années une Neural Engine dans ses puces. Les ordinateurs portables Windows arrivent comme AI PCs avec des processeurs IA dédiés. Une console de jeu dans le salon possède une puissance GPU qui aurait autrefois évoqué une station de travail. Et pourtant, nous utilisons cette puissance locale surtout par courts pics : un jeu, un export, un appel vidéo, un effet local, une recherche. Ensuite l’appareil retombe en idle.

C’est exactement là que commence l’expérience de pensée. Pas : “Puis-je louer mon iPhone demain comme centre de données ?” Ce serait absurde. Mais : si autant de silicium est déjà payé, connecté et branché chaque nuit, quelle serait la capacité théorique si l’on ne pouvait utiliser que de petites fenêtres sûres et adaptées ?

On ne peut pas mesurer précisément la puissance de calcul inutilisée du monde. Trop d’appareils sont différents, trop sont hors ligne, trop ne peuvent pas participer pour des raisons de batterie, de chaleur, de sécurité ou de plateforme. Pourtant, une estimation grossière aide à sentir l’ordre de grandeur.

Prenons pour cela quelques blocs volontairement simples. Point important : je ne calcule pas comme si chaque appareil était disponible à pleine puissance à tout moment. Je calcule avec des fenêtres de temps, des taux de participation et des décotes prudentes. Cela reste une expérience de pensée, mais une expérience qui repose sur des chiffres.

Tesla : du silicium sur roues

En juin 2025, Tesla a annoncé son huit millionième véhicule produit. Tous ne sont plus actifs, tous n’ont pas le même matériel Autopilot, et tous les propriétaires n’autoriseraient pas leur voiture à participer à un réseau de calcul. Je calcule donc de façon conservatrice :

• Sur 8 millions de véhicules produits, peut-être 80 pour cent sont encore réalistement actifs et techniquement pertinents. Cela ferait 6,4 millions de véhicules.
• Pour Hardware 3, donc le FSD Computer depuis 2019, on cite souvent un ordre de grandeur de 144 TOPS pour le système.
• Hardware 4 se trouve dans des véhicules plus récents et est plus moderne, mais Tesla ne publie pas pour lui une valeur TOPS simple et propre comme pour les anciens chiffres de l’Autonomy Day. Pour ce calcul, je prends donc malgré tout 144 TOPS comme base conservatrice.
• Une voiture reste certes souvent 23 heures par jour à l’arrêt, mais la fenêtre intéressante est la charge. Si elle est branchée 6,5 heures la nuit, cela correspond en moyenne sur 24 heures à environ 27 pour cent de disponibilité.

Si seulement 25 pour cent de ces propriétaires Tesla actifs s’inscrivaient, cela ferait 1,6 million de véhicules et environ 62 exa-opérations par seconde en équivalent journalier. Avec 50 pour cent de participation, ce serait environ 125 exa-opérations par seconde. Si, en théorie, tous les véhicules actifs participaient, le chiffre serait d’environ 250 exa-opérations par seconde. Dans la fenêtre nocturne elle-même, la puissance instantanée serait plus élevée ; le chiffre équivalent journalier est simplement la comparaison la plus juste avec un centre de données qui fonctionne 24 heures.

iPhones : la plus grande surprise

Pour les iPhones, le calcul est à la fois plus simple et plus difficile. Plus simple, parce qu’Apple livre chaque année des volumes énormes. Plus difficile, parce qu’Apple ne publie pas de tableau public clair indiquant quelles générations d’iPhone sont encore actives dans le monde. Je prends donc les livraisons publiées des dernières années et j’y ajoute une part active restante plausible.

Ce calcul mixte donne environ 885 millions d’iPhones probablement encore actifs sur seulement cinq années de livraisons. Ce n’est pas toute la base iPhone, mais volontairement un extrait limité. Les anciennes générations A14/A15 étaient dans le bas des dizaines de TOPS, A16 juste sous 17 TOPS, A17 Pro autour de 35 TOPS. Il est donc plus raisonnable de prendre une moyenne par année que de faire comme si tous les appareils avaient la même puce.

Même jeu maintenant : 6,5 heures la nuit branchés, pas toute la journée. Si 25 pour cent de ces appareils participaient, on arriverait à environ 1'437 exa-opérations par seconde en équivalent journalier. Avec 50 pour cent de participation, ce serait environ 2'875 exa-opérations par seconde. Si tous les appareils participaient théoriquement, le chiffre serait d’environ 5'750 exa-opérations par seconde.

Cela paraît fou. Mais c’est précisément le sujet. Non pas parce qu’un iPhone serait un serveur. Mais parce que la masse d’appareils est si grande que même des quotas prudents atteignent soudain un ordre de grandeur que l’on attribue d’habitude aux centres de données.

La comparaison

Comme autres points de référence, je prends :

• 50 millions de GPU de bureau, stations de travail ou petits serveurs, qui pourraient fournir en moyenne 20 TFLOPS FP32. Si seulement 20 pour cent étaient utilisables en pratique, il resterait environ 200 exa-opérations par seconde dans des fenêtres adaptées.
• xAI Colossus comme comparaison issue du monde des centres de données. Avec 200'000 GPU Hopper et environ 3'958 INT8 TOPS par GPU de classe H100, on arrive à environ 792 exa-opérations par seconde de performance IA théorique de pointe. C’est le pic avec sparsity ; la performance dense et durablement utilisable est plus basse.

Ce n’est pas une capacité globale exacte. C’est un modèle de pensée. Et c’est précisément ici qu’il faut freiner : les TOPS ne se versent pas comme des litres d’eau dans un réservoir commun. Les TOPS d’une Neural Engine d’iPhone, les TOPS INT8 d’un GPU et la performance FP32 d’une station de travail sont des choses différentes. Beaucoup de jobs utiles n’ont pas seulement besoin d’opérations, mais de RAM, de VRAM, de bande passante mémoire, d’un temps d’exécution stable, d’un accès logiciel et d’un système d’exploitation qui autorise ces jobs.

Malgré cela, le calcul montre pourquoi l’idée n’est pas ridicule. Même une combinaison conservatrice de PC, de véhicules et de smartphones atteint, comme silicium théorique, un ordre de grandeur qui ne paraît plus absurdement petit à côté de l’un des centres de données IA les plus visibles du monde.

Le chiffre des iPhones est particulièrement intéressant parce qu’il ne regarde que cinq années de livraisons, pas toute la base installée active. En même temps, c’est le meilleur exemple de la raison pour laquelle la performance de pointe ne suffit pas : un iPhone n’est pas un serveur. Il a des limites thermiques, une logique de batterie, des règles de système d’exploitation, des modèles de confidentialité et un propriétaire qui attend un appareil fonctionnel le matin. Pourtant, il y a là une puissance de calcul qui aurait ressemblé à de la science-fiction il y a quelques années.

Et même ces valeurs de pointe ne sont que des valeurs de pointe. Un smartphone, un ordinateur portable sans ventilateur ou un calculateur automobile ne peut pas simplement fournir cette puissance pendant six heures comme un GPU de centre de données. Les contraintes thermiques, le throttling et la logique de protection réduisent massivement la performance soutenue. Qui voudrait construire un vrai réseau à partir de cela devrait donc calculer avec la performance soutenue, pas avec le plus beau chiffre de la fiche technique.

On peut aussi le penser par l’électricité. Si 50 millions d’appareils apportaient en moyenne 150 watts pendant quatre heures par jour, cela ferait environ 11 TWh par an. Ce n’est qu’une petite fraction de la consommation actuelle des centres de données dans le monde. Mais ce serait assez pour porter beaucoup de tâches d’arrière-plan, embeddings, workloads scientifiques, rendu, tâches de vérification ou processus de stockage décentralisé.

L’objection désagréable est la suivante : cela ne doit pas automatiquement être plus efficace. Les centres de données ont un meilleur refroidissement, une meilleure utilisation, une électricité moins chère, du matériel plus récent et un batching professionnel. Un appareil domestique peut être moins bon par unité de calcul utile, surtout s’il y a beaucoup d’overhead ou si la batterie d’un smartphone vieillit plus vite pour quelques centimes de crédits. Un réseau de calcul décentralisé ne serait donc pas bon simplement parce qu’il est distribué. Il devrait avoir un sens net pour des workloads adaptés : techniquement, énergétiquement et économiquement.

Cela devient encore plus intéressant avec les nouveaux AI PCs. Canalys attendait environ 100 millions d’AI PCs livrés en 2025. Beaucoup de ces appareils apportent des NPU avec 40 TOPS ou plus. TOPS n’est pas la même chose que GPU-FLOPS, et une NPU ne remplace pas un centre de données. Mais même en regardant cette puissance avec beaucoup de prudence, une nouvelle classe de matériel IA local apparaît, pas seulement sur le papier, mais dans les bureaux et les logements.

La conclusion n’est donc pas : “Demain, nous remplaçons tous les centres de données par des PC gaming, des Teslas et des iPhones.” La conclusion est : nous construisons une énorme nouvelle capacité centrale alors qu’une immense quantité de capacité distribuée, déjà payée, se perd sans être utilisée.

La puissance de calcul se périme

Je peux stocker l’électricité. Pas parfaitement, pas sans perte, mais en principe. Si mon installation solaire produit plus à midi que ce dont j’ai besoin, l’énergie va dans une batterie ou dans le réseau. Le soir, je peux la réutiliser, ou mon voisin l’utilise. Les smart grids, batteries et modèles d’énergie peer-to-peer rendent cette façon de penser toujours plus concrète : parfois je produis, parfois je consomme, et la limite entre client et fournisseur devient plus souple.

La puissance de calcul fonctionne autrement.

Une heure de GPU inutilisée hier, je ne peux pas la sortir aujourd’hui d’un tiroir. Un processeur qui n’a rien fait pendant une nuit n’a pas gardé de puissance de calcul pour plus tard. Ce temps est parti. Irrécupérable. La puissance de calcul est périssable.

C’est exactement ce qui rend les appareils inutilisés intéressants. Nous n’avons pas seulement du matériel. Nous avons des possibilités qui se périment en permanence. Le pool réaliste à court terme, ce sont surtout les GPU de bureau, stations de travail, consoles de jeu, petits serveurs, stockages NAS et ressources de campus ou de fournisseurs. Les smartphones et les voitures sont plutôt des cas limites à long terme : techniquement fascinants, mais beaucoup plus difficiles à cause de la batterie, de la chaleur, des règles de plateforme, de la sécurité et du contrôle des fabricants.

Cela ne bloque donc pas seulement sur les mathématiques, mais aussi sur l’incitation. Les appareils dotés du silicium inutilisé le plus intéressant appartiennent justement à des plateformes fermées : Apple construit avec Private Cloud Compute sa propre infrastructure pour les grandes requêtes Apple Intelligence, Tesla avec Cortex sa propre capacité d’entraînement pour FSD et Optimus. Pourquoi ces entreprises ouvriraient-elles leur flotte d’appareils à un marché du calcul indépendant du fabricant, alors que le contrôle du matériel, du logiciel et du cloud constitue justement leur fossé défensif ?

La question de fond demeure pourtant : pourquoi traitons-nous la puissance de calcul distribuée comme si elle était sans importance, pendant que nous construisons des installations centrales toujours plus grandes ?

L’IA peut-elle vraiment calculer de façon décentralisée ?

Ici, il faut être honnête : pour beaucoup de ce qui est visible aujourd’hui comme IA, la décentralisation est difficile.

Un grand modèle de langage n’est pas simplement une liste de petites tâches que l’on peut distribuer librement à des appareils étrangers. Les modèles ont besoin de RAM ou de VRAM. Ils ont besoin de bande passante mémoire. Ils ont parfois besoin d’interconnexions rapides. Lors de la génération de tokens, le modèle est parcouru encore et encore, et chaque saut réseau supplémentaire ralentit la réponse. Découper un modèle frontier entre des smartphones étrangers, de vieux portables et des voitures serait généralement absurde pour une réponse de chat interactive.

Mais cela ne signifie pas que l’IA décentralisée est impossible. Cela signifie seulement qu’il faut choisir les bonnes tâches.

Les travaux qui n’ont pas besoin d’être terminés en deux secondes conviennent très bien : embeddings pour de grandes archives, résumés par lots, rendu, simulations scientifiques, données synthétiques, tests, crawling, tâches de vérification, réparation de stockage décentralisé, petits modèles locaux, prétraitement et tâches dont on peut vérifier ou recalculer les résultats.

En pratique, il faudrait séparer les tâches beaucoup plus proprement :

Les grands modèles ne sont pas totalement exclus non plus, mais ils ont besoin d’une autre architecture. Petals a montré que l’inférence collaborative et le fine-tuning de grands modèles sur des ressources distribuées sont possibles en principe. Prime Intellect va encore plus loin avec INTELLECT-2 et montre comment le reinforcement learning distribué peut fonctionner avec des workers non fiables si les résultats sont vérifiés. Ce n’est pas encore le monde où votre iPhone entraîne secrètement GPT-7 la nuit. Mais c’est un indice que le problème n’est pas fondamentalement impossible.

Le point de départ réaliste ne serait donc pas : “Nous distribuons un modèle géant partout.” Le point de départ réaliste serait : modèles locaux d’abord, pools régionaux pour jobs batch adaptés, tâches vérifiables, zones de données claires et centres de données centraux seulement là où ils sont vraiment nécessaires.

Le vieux rêve des systèmes distribués

Il existe une autre histoire d’Internet. Une histoire qui évoque moins la cathédrale que l’essaim.

Calcul volontaire

SETI@home a toujours été pour moi l’un des plus beaux exemples. Des millions de personnes laissaient leurs ordinateurs calculer en arrière-plan des données de radioastronomie. Pas parce qu’elles recevaient un dashboard SaaS, mais parce que l’idée était assez grande : nous cherchons ensemble des signaux dans le bruit de l’univers. Depuis mars 2020, SETI@home ne distribue plus de nouvelles work units et se trouve dans une sorte d’hibernation. Mais comme preuve que le calcul volontaire peut fonctionner globalement, il reste important.

BOINC, la plateforme derrière et à côté, décrit sobrement pourquoi cela fonctionne : beaucoup de jobs indépendants et intensifs en calcul, pour lesquels le débit compte plus que la faible latence. C’est la différence décisive. Un système distribué n’a pas besoin de livrer chaque réponse de chat interactive en deux secondes. Il peut être fort là où le travail est divisible, vérifiable et pas immédiatement dû.

Stockage sans lieu fixe

IPFS porte la même idée dans le domaine du stockage. Les fichiers ne sont pas d’abord adressés par un lieu, mais par leur contenu. Le contenu possède une empreinte. Celui qui l’a peut le livrer. C’est une autre façon de penser que “ce fichier se trouve sur ce serveur à cette URL”.

Argent sans comptabilité centrale

Bitcoin, indépendamment de la façon dont on évalue spéculation et consommation d’énergie, a popularisé une idée première similaire : un système sans comptabilité centrale, dans lequel le consensus ne dépend pas d’une seule institution. Toute idée décentralisée n’est pas automatiquement bonne. Mais Bitcoin a montré qu’un protocole peut être politiquement puissant lorsqu’il supprime le point de contrôle central.

Storage comme réseau

Dans le stockage aussi, il y a eu des tentatives intéressantes. Symform était un fournisseur de cloud storage décentralisé, où du stockage excédentaire pouvait être apporté à un réseau. En 2014, la plateforme a été reprise par Quantum ; à ce moment-là, on parlait de 45'000 utilisateurs et petites entreprises dans 170 pays. Storj, Sia, Filecoin et d’autres variantes montrent également que l’idée n’est pas nouvelle. Elle n’arrive simplement jamais tout à fait dans le quotidien.

Aujourd’hui, cette idée continue sous de nouvelles formes. Storj découpe les fichiers côté client, les chiffre et répartit des morceaux sur de nombreux storage nodes. C’est plus proche de l’infrastructure que du romantisme : dans le meilleur cas, l’utilisateur ne voit pas l’essaim, mais un service de stockage qui fonctionne.

Le calcul comme place de marché

Golem et Akash veulent rendre accessible la puissance de calcul inutilisée sous forme de marché. Pour moi, c’est le pont direct vers cet article : il n’y a pas seulement de l’espace de stockage réparti, mais aussi des processeurs, des GPU et de petits serveurs qui restent souvent inactifs aujourd’hui.

IA dans l’essaim distribué

Andrej Karpathy réapparaît aussi dans cet environnement : Prime Intellect le cite comme soutien notable, et avec INTELLECT-2, Prime Intellect a lancé un entraînement RL distribué et décentralisé pour un modèle de 32B paramètres, auquel des ressources de calcul hétérogènes et permissionless peuvent contribuer.

Ce n’est pas encore la réponse parfaite. Mais cela montre que le rêve n’a pas disparu. Il cherche simplement encore et encore une forme qui survive à l’exploitation réelle.

Apprendre de la centrale virtuelle

Ce qui est intéressant, c’est que cette façon de penser paraît déjà beaucoup moins exotique dans le domaine de l’électricité.

Tesla décrit son Virtual Power Plant comme un réseau de ressources énergétiques distribuées : des maisons avec installations solaires et Powerwalls sont considérées ensemble comme une centrale électrique. Quand le réseau a besoin de soutien, les batteries peuvent injecter de l’électricité. Le propriétaire met une ressource à disposition et reçoit de l’argent ou d’autres avantages. Une Powerwall individuelle est petite. Ensemble, elles peuvent devenir pertinentes pour le réseau.

C’est exactement l’analogie qui me fascine pour la puissance de calcul. Un seul GPU dans un home office, un seul NAS, un seul iPhone ou une seule voiture n’est pas un centre de données. Mais beaucoup d’appareils ensemble pourraient former une nouvelle couche : pas pour tout, pas à tout moment, pas sans règles, mais pour certaines tâches.

L’analogie a ses limites. L’électricité est beaucoup plus fongible que le travail de calcul. Un kilowattheure ne dépend pas du fait qu’il doit exécuter un modèle avec 80 GB de VRAM, une pipeline d’embeddings ou une réparation de storage chiffrée. Le calcul dépend du workload. C’est précisément pourquoi il faut des classes de jobs, du scheduling et des exclusions strictes.

Chez Tesla, on voit même la même idée à deux endroits. Les Powerwalls peuvent faire partie d’une centrale virtuelle. Les voitures devraient à terme faire partie d’une flotte autonome de robotaxis, donc gagner de l’argent quand leur propriétaire ne les utilise pas lui-même. Que cela passe vraiment à l’échelle, et à quelle vitesse, est une autre question. Mais l’idée de base est importante : un appareil privé n’est plus seulement consommé, il peut travailler comme infrastructure dans des fenêtres libres.

La puissance de calcul pourrait se penser de manière similaire. Pas comme une vente d’électricité au voisin, mais comme une vente de temps de calcul vérifiable, d’espace de stockage ou de travail de modèle à une cellule régionale. L’utilisateur paie au final l’électricité, la chaleur, l’usure matérielle et le risque. Il doit donc aussi être rémunéré. Sans ce point, l’idée n’est qu’une jolie expérience technique.

Pourquoi l’essaim gagne si rarement

Si la décentralisation sonne si bien, pourquoi ne s’impose-t-elle pas simplement ?

Parce que la centralisation est souvent le meilleur paquet produit.

Un centre de données est contrôlable. Un essaim se compose d’appareils étrangers, de différents systèmes d’exploitation, d’une disponibilité changeante, d’une mauvaise prévisibilité et de propriétaires qui éteignent, vendent, mettent à jour ou déconnectent leur appareil. Pour un product manager, ce n’est pas du romantisme, mais un mal de tête.

S’ajoute l’économie. Beaucoup de projets décentralisés ont tenté de résoudre les incitations par des tokens. C’est compréhensible, parce qu’un réseau sans entreprise centrale a tout de même besoin de rémunération. Mais dès que les coûts de stockage ou de temps de calcul sont liés à une monnaie volatile, cela devient peu attrayant pour des entreprises normales. Je ne veux pas que mon téraoctet de backup devienne soudain plus cher parce qu’un coin est pumpé sur Twitter. Je ne veux pas non plus que mon budget d’heures GPU dépende d’un marché qui ressemble plus à un casino qu’à une infrastructure.

Et l’adversaire tarifaire n’est pas le GPU on-demand le plus cher du cloud. La vraie comparaison, ce sont les offres spot et preemptible, donc de la capacité excédentaire de centres de données que les fournisseurs vendent avec un fort rabais. Un réseau de calcul décentralisé ne devrait donc pas seulement être philosophiquement plus beau. Il devrait tenir face à une capacité cloud très bon marché, bien intégrée, même si elle est interruptible.

Le deuxième frein est la commodité. S3 n’a pas gagné parce qu’il est philosophiquement beau. Il a gagné parce qu’il est assez simple, assez documenté et intégré partout. Si des réseaux de stockage ou de calcul décentralisés veulent devenir pertinents, ils doivent paraître presque ennuyeux aux développeurs et aux admins : entrer une API key, créer un bucket, monitoring, facture, SLA, test de restore, terminé.

Puis vient la sécurité. Dans un réseau d’entreprise, il ne faut pas qu’un job de calcul étranger arrive soudain en entrée sur des stations de travail. Tout firewall raisonnable le bloquerait, et les systèmes de threat intelligence le trouveraient suspect. En pratique, un tel système devrait plutôt fonctionner de l’intérieur vers l’extérieur : le nœud se signale à une cellule, récupère des jobs vérifiés, tourne dans une sandbox et ne voit que les données qu’il a le droit de voir. Sinon, au niveau réseau, un réseau de calcul légitime ressemble vite à un botnet formulé très poliment.

La confiance est le prochain point dur. Les systèmes décentralisés doivent pouvoir prouver que le travail a été correctement effectué sans que chaque nœud ait le droit de tout voir. Pour le stockage, il existe des briques connues : chiffrement, erasure coding, audits, mécanismes de réparation. Pour l’IA et le calcul, cela devient plus difficile. Comment vérifier qu’un appareil étranger a exécuté correctement un modèle ? Comment empêcher les fuites de données ? Comment protéger l’appareil du participant contre du code étranger ?

L’usure matérielle est aussi plus que de l’électricité. Les SSDs et stockages NVMe ont des limites d’écriture. Écrire constamment des poids de modèles, des données temporaires, des batches d’embeddings ou des fichiers swap sur des appareils grand public consomme une vraie durée de vie. S’ajoute le problème de bande passante : si le téléchargement d’un grand modèle ou dataset dure plus longtemps et crée plus d’overhead réseau que le calcul lui-même, le calcul économique bascule. Les données sont plus lourdes que ne le laisse croire la simple métaphore du smart grid.

C’est exactement là qu’INTELLECT-2 devient intéressant. Dans son paper, Prime Intellect décrit TOPLOC comme une brique qui vérifie des rollouts de workers d’inférence non fiables. Cela ne résout pas soudain tous les problèmes de calcul. Ce n’est pas une protection magique de la confidentialité pour des données d’entreprise arbitraires sur du matériel étranger. Mais cela montre un mécanisme réel pour une classe précise de travail IA distribué : les jobs sont construits de sorte que les résultats soient vérifiables, au lieu de faire confiance aveuglément à chaque worker.

Pour les données confidentielles, cela ne suffit pas. Il faudrait d’autres briques : Confidential Computing, Trusted Execution Environments, Remote Attestation, sandboxes propres, classification claire des données et, en cas de doute, la décision dure de ne pas faire tourner certains jobs sur du matériel étranger. À cela s’ajoutent des questions ennuyeuses mais décisives : fiscalité, responsabilité, protection des données, résidence des données et conditions des fournisseurs d’accès Internet. L’infrastructure échoue rarement seulement à cause des mathématiques. Souvent, elle échoue à cause de l’exploitation.

Un réseau intelligent du calcul

Je n’imagine pas un naïf “tout est P2P et tout ira bien”. L’infrastructure ne fonctionne pas comme cela. Ce qui pourrait fonctionner, ce serait un réseau intelligent du calcul avec des couches claires.

La première couche s’appelle : local d’abord. Tout ce qui est personnel, confidentiel ou critique en latence devrait, autant que possible, tourner sur l’appareil lui-même ou dans son propre espace de confiance. Petits modèles, recherche locale, résumés privés, classification simple, prétraitement, chiffrement, embeddings pour données personnelles. Chaque e-mail, chaque note et chaque recherche n’a pas besoin d’aller vers un hyperscaler.

La deuxième couche serait régionale et fédérée. Une ville, un quartier, un campus, une entreprise, une coopérative ou un fournisseur pourrait exploiter une cellule. Dans cette cellule, des appareils mettent volontairement des ressources à disposition, mais seulement sous conditions claires : seulement branchés, seulement en idle, seulement dans des limites thermiques, seulement avec une puissance maximale définie, seulement pour certaines classes de jobs.

Le point de départ ne serait pas les smartphones et les voitures, mais les appareils plus ennuyeux : GPU de bureau, stations de travail, consoles de jeu, petits serveurs, systèmes NAS et capacité libre chez des fournisseurs locaux. Les smartphones pourraient plus tard prendre de petites tâches de vérification. Les voitures seraient imaginables encore plus tard, dans des limites très étroites et contrôlées par les fabricants. Comme pour le réseau électrique, il faudrait commencer par les ressources fiables, mesurables et contrôlables.

La troisième couche reste centrale. Entraînement frontier, temps réel strict, modèles extrêmement grands, cas particuliers réglementaires sensibles et workloads fortement couplés appartiennent toujours à des centres de données professionnels. La décentralisation n’a pas besoin de tout remplacer. Elle doit seulement empêcher que tout le travail quotidien passe automatiquement par les cinq mêmes centres de pouvoir.

Si l’on voulait tester cela, je commencerais petit. Pas avec des millions d’iPhones, mais avec une cellule régionale de peut-être 500 à 2'000 GPU de bureau volontaires, stations de travail, systèmes NAS et petits serveurs. Seuls quelques types de jobs seraient autorisés : embeddings pour données non sensibles, jobs scientifiques par lots, morceaux de stockage chiffrés et tâches de vérification. Le succès ne se mesurerait pas à un joli chiffre en exa, mais à trois indicateurs ennuyeux : jobs terminés par $1 de coût électrique, taux d’erreur et de répétition, paiement après usure matérielle.

La partie la plus difficile serait la rémunération. L’utilisateur paie l’électricité, la chaleur et l’usure matérielle. Il lui faut donc quelque chose en retour. Il faudrait probablement un token ou un crédit. Mais pas comme objet de spéculation. Comme crédit d’infrastructure.

Un tel crédit de calcul devrait représenter quelque chose de réel : une minute GPU d’une certaine classe, un GB-mois de stockage, une inférence vérifiée, une unité de batch embedding ou une unité de calcul équivalente à un kWh. Celui qui donne des ressources gagne des crédits. Celui qui a plus tard besoin de puissance IA les consomme. Celui qui ne veut rien consommer pourrait les convertir en fiat, comme dans une centrale virtuelle où l’on ne veut pas être payé en “Powerwall-Coins”, mais en argent réel ou en avoir clair.

Cela ne résout pas magiquement la question du prix. La stabilité a besoin d’un ancrage : facturation en fiat, corridors de prix de l’énergie, chambres régionales de compensation, tarifs coopératifs ou opérateurs régulés. Sans gouvernance, des “crédits stables” redeviennent vite un token flottant librement. Et l’on retrouve l’ancien problème : l’infrastructure se ressent comme un casino.

Plus importante encore est la question des droits d’exploitation. Nous n’avons pas besoin d’entraîner nous-mêmes chaque grand foundation model. Peut-être achète-t-on ou licencie-t-on des modèles, des poids ouverts ou des familles de modèles pour les exploiter ensuite de façon décentralisée, fédérée et contrôlée régionalement. La vraie souveraineté ne serait alors pas seulement dans l’entraînement, mais dans l’exploitation : où tournent les modèles ? Où résident les données ? Qui peut auditer ? Existe-t-il un canal de retour vers le fournisseur ? Puis-je continuer à exploiter le modèle localement si la politique, les prix ou les terms changent ?

Pour que cela soit plus qu’un joli contrat d’achat, de telles licences devraient contenir de vrais droits d’exploitation : déploiements locaux, engagements de mise à jour et de sécurité à long terme, model cards compréhensibles, auditabilité, droits de sortie clairs et aucune obligation de repousser des données sensibles vers le cloud central du fabricant. Ce ne serait pas l’utopie décentralisée pure. Mais ce serait une voie réaliste entre autosuffisance naïve et lock-in total de plateforme.

La nuit où les appareils calculent

Imaginez qu’il est 22 h 43. Votre desktop avec GPU est en idle, le NAS est en ligne, le téléphone recharge. Dans les réglages, vous avez défini : maximum 80 watts, seulement au repos, seulement pour des workloads vérifiés de la région et seulement si la rémunération couvre les coûts d’électricité plus un forfait matériel.

Un agent local signale de la capacité libre. Pas avec votre nom et pas avec vos données privées, mais comme un nœud attesté avec certaines capacités. La cellule distribue de petits jobs : simulations, embeddings, morceaux de stockage chiffrés, tâches de vérification.

Le matin, il n’y a pas de fusée, pas d’histoire de Wall Street, pas de token hype. Juste une ligne sobre :

Cette nuit : 2,4 crédits GPU gagnés, 18 GB-mois de storage confirmés, $0.31 de coûts d’électricité estimés.

Plus tard, vous utilisez ces crédits pour un modèle local sur vos propres documents. Les données sensibles restent chez vous. Vous n’êtes pas seulement client. Vous êtes participant.

Cela paraît romantique. Oui. Mais parfois, c’est précisément la raison de prendre au sérieux un problème d’ingénierie difficile.

L’essaim et la montagne

Je ne crois pas que les centres de données centraux vont disparaître. Ils sont trop efficaces, trop importants et tout simplement nécessaires pour certaines tâches. La montagne reste. La seule question est de savoir si nous reconstruisons un sol à côté.

Un sol fait d’appareils locaux, de cellules régionales, de protocoles ouverts, de crédits stables et de modèles de sécurité clairs. Un sol sur lequel la puissance de calcul n’est pas seulement vendue de haut en bas, mais circule entre participants. Un sol sur lequel certains travaux d’IA tournent là où ils doivent tourner : le travail privé en local, le travail régional dans la région, les cas limites globaux dans le centre de données.

Peut-être est-ce naïf. Peut-être pas. Les centrales virtuelles étaient elles aussi autrefois une idée étrange : des milliers de petites batteries comme un grand réseau. L’argent décentralisé a longtemps semblé absurde. Des voitures qui roulent seules comme taxis semblaient relever de la science-fiction. Tout n’arrivera pas comme promis. Mais la direction est claire : les ressources qui restaient autrefois passives sont de plus en plus pensées comme faisant partie d’un système plus grand.

En ce moment même, des machines inutilisées se trouvent partout. Dans les appartements, les bureaux, les garages, les salles serveurs et les poches. Toutes ne conviennent pas aussi bien. Toutes ne devraient pas forcément exécuter du travail étranger. Mais beaucoup sont déjà là, payées et connectées. Et chaque seconde inutilisée disparaît.

Peut-être devrions-nous commencer à les écouter.

À la prochaine,
Votre Joe