Google s’apprête à lancer, ce 1er octobre, son premier satellite expérimental « MVP » dans le cadre du Project Suncatcher, destiné à valider la faisabilité technique de data centers IA en orbite basse, alimentés par le soleil. Derrière l’effet d’annonce, se dessine un arbitrage brutal : contourner les contraintes terrestres (énergie, foncier, raccordement, acceptabilité) au prix de défis redoutables (refroidissement, radiation, latence, coût du kilo en orbite, maintenance).
Le calendrier – lancement du premier satellite expérimental « MVP », deux prototypes en 2027, constellation potentielle dans les années 2030 – et les ordres de grandeur (1 kW par satellite MVP, 4 TPU, durée de vie courte) trahissent une phase de R&D avancée, pas un déploiement industriel.
Un premier vol test, pas un data center opérationnel
Le satellite MVP, de la taille d’un réfrigérateur, embarque quatre accélérateurs TPU (Tensor Processing Units) de Google, conçus pour l’entraînement et l’inférence IA. Il sera lancé depuis Vandenberg (Californie) à bord d’un Falcon 9 de SpaceX, dans le cadre d’un vol rideshare Transporter-18 en partenariat avec Planet Labs.
Il ne s’agit pas d’un data center orbital fonctionnel : le satellite ne fonctionnera que par sessions de 15 minutes, sur une durée de vie de quelques mois à un an, avec une puissance solaire disponible de l’ordre de 1 kW. L’objectif est de mesurer la survie des TPU aux vibrations du lancement, aux radiations, aux cycles thermiques extrêmes et à l’absence de convection classique pour le refroidissement.
Google prévoit ensuite, début 2027, le lancement de deux satellites supplémentaires pour tester les liaisons laser inter-satellites (free-space optical links), condition incontournable d’une future constellation capable de former un cluster de calcul distribué.
Pourquoi l’orbite ? La promesse énergétique et foncière
Le narratif de Suncatcher repose sur un constat terrestre de plus en plus tendu : les data centers IA butent sur l’énergie, le foncier et les délais de raccordement. Google met en avant trois avantages structurels de l’orbite basse (LEO, environ 640 km) :
- Solaire quasi continu : en orbite héliosynchrone « dawn-to-dusk », les panneaux voient le soleil en quasi-permanence, sans nuit, sans nuages, sans atmosphère. Google avance un facteur 8 sur la production solaire par rapport au sol.
- Zéro conflit d’usage du sol : pas de mitage agricole, pas de tensions locales sur l’eau de refroidissement, pas de procédures d’urbanisme interminables.
- Scalabilité « hors grille » : la constellation devient sa propre centrale, sans dépendre des gestionnaires de réseau électriques terrestres ni des autorisations de raccordement HT.
Dans un contexte où les hyperscalers s’arrachent des centaines de MW à quelques années d’intervalle et où les délais de raccordement explosent, l’argument est politiquement puissant.
Les goulots d’étranglement techniques : refroidissement, radiation, liaison
Mais l’orbite déplace les contraintes plus qu’elle ne les supprime.
- Refroidissement : pas d’air, pas de convection
Sur Terre, un data center dissipe la chaleur via des tours de refroidissement, de l’eau, de l’air. En orbite, seul le rayonnement thermique permet d’évacuer la chaleur. Cela impose : - Des radiateurs de grande surface, orientables, avec des revêtements à émissivité maîtrisée.
- Une architecture thermique très fine pour éviter les points chauds sur les TPU.
- Une limitation sévère de la densité de puissance : à 1 kW pour quatre TPU, on est très loin des dizaines de kW voire du MW d’un rack terrestre.
Google reconnaît explicitement que la conception des systèmes de refroidissement est l’un des verrous majeurs de Suncatcher.
En LEO, les ceintures de radiation, les particules énergétiques et les événements singuliers (SEU, single-event upsets) dégradent les semi-conducteurs. Les TPU doivent être durcis, redondants, et capables de corriger les erreurs en temps réel. Cela alourdit la masse, complexifie l’architecture et réduit le rendement calcul/watt.
Le test MVP vise justement à cartographier les modes de défaillance en conditions réelles, pas à prouver la viabilité d’un data center de production.
Liaisons laser : la clé du « cluster » orbital
Pour qu’une constellation fonctionne comme un data center, les satellites doivent échanger des flux massifs à très faible latence relative. Google mise sur des liaisons optiques inter-satellites (laser) à très haut débit.
Mais ces liens exigent :
- Un pointage ultra-précis et un maintien de formation serrée (quelques mètres à quelques dizaines de mètres).
- Une gestion fine des occultations (Terre, Soleil, autres satellites).
- Une redondance importante pour garantir la disponibilité du service.
Le test de 2027 avec deux satellites est l’étape critique : sans lien optique fiable, pas de cluster, pas de data center.
Économie du kilo en orbite : un modèle encore hors de portée industrielle
Même avec des lancements réutilisables (Falcon 9, Starship à terme), le coût du kilo en orbite reste un paramètre dominant. Un data center terrestre se mesure en centaines de MW et en dizaines de milliers de tonnes d’infrastructures. Transposer cela en orbite, même partiellement, implique des centaines, voire des milliers de lancements.
Les ordres de grandeur actuels :
- MVP : environ 1 kW, 4 TPU, quelques centaines de kg (estimation).
- Concept de constellation : environ 81 satellites en formation serrée à 640 km, toujours au stade de la recherche.
À ce stade, le coût du watt-orbital et du FLOP-orbital est plusieurs ordres de grandeur au-dessus du terrestre. Suncatcher est un programme de recherche, pas un business plan.
Souveraineté, régulation et géopolitique : l’angle caché
Au-delà de la technique, Suncatcher touche à des enjeux de souveraineté :
- Régulation spectrale et orbitale : les fréquences des liaisons laser et radio, les slots orbitaux, la coordination avec l’UIT et les agences spatiales nationales sont des sujets sensibles.
- Débris spatiaux et durabilité : une constellation dense de « data centers » augmente les risques de collision et la complexité du trafic en LEO. La conformité aux règles de désorbitation et de fin de vie sera scrutée.
- Géopolitique du calcul : un cloud orbital contrôlé par un acteur privé américain pose des questions de juridiction, d’accès, de contrôle des flux de données et de résilience face à des conflits ou des sanctions.
Si Google insiste sur le caractère « moonshot » et recherche – un pari à 10 ans, pas une réponse à la crise de capacité 2026-2029 –, le message politique porté par le projet contourne les terres et les réseaux électriques, et l’orbite devient un plan B stratégique.
Points de fragilité
Plusieurs éléments méritent une lecture critique :
- Puissance dérisoire vs besoins IA : 1 kW par satellite MVP est infinitésimal face aux centaines de MW d’un cluster d’entraînement. La montée en puissance suppose des sauts technologiques majeurs en dissipation thermique et en masse lançable.
- Maintenance quasi impossible : en orbite, pas de remplacement de carte, pas de mise à jour physique. La fiabilité doit être extrême, ce qui renchérit encore le système.
- Latence et architecture applicative : même en LEO, la latence et la topologie du réseau orbital imposent de repenser les workloads. Tous les usages IA ne sont pas portables tels quels.
- Risque de greenwashing orbital : présenter l’orbite comme une solution « propre » à la soif énergétique de l’IA masque la réalité des lancements, des matériaux, des débris et du cycle de vie.
Project Suncatcher est une démonstration de force technologique face à des contraintes terrestres qui se durcissent trop, qui offre aux hyperscalers des cartes à jouer hors sol. Mais à ce jour, rien ne vient remplacer la logique terrestre des data centers : densité de puissance, proximité des fibres, accès à l’eau et à l’électricité, acceptation locale, conformité environnementale. L’orbite reste, pour l’instant, un laboratoire à très haut risque, à très long terme, et à très faible densité de calcul.
