Le logiciel d’IA orbitale de Satlyt a choisi la voie ouverte rejetée par SpaceX et Google

Le logiciel d’IA orbitale de Satlyt entre dans l’espace après que SpaceX et Google ont rejeté les propositions internes de son fondateur, Rama Afullo, concernant l’informatique distribuée en orbite. Satlyt a désormais levé un tour de table d’amorçage de 8 millions de dollars et obtenu des emplacements pour son logiciel sur plusieurs missions satellitaires.

Ce retournement est devenu particulièrement visible lorsque le logiciel de Satlyt a atteint l’orbite via SpaceX, aux côtés de matériel destiné au Project Suncatcher de Google. Les deux anciens employeurs soutiennent aujourd’hui des stratégies d’informatique orbitale, mais ils poursuivent une architecture différente de celle choisie par Afullo.

Satlyt veut fournir une couche logicielle capable de fonctionner sur des engins spatiaux de nombreux fabricants. SpaceX incarne l’approche inverse : une entreprise unique qui contrôle les lancements, les satellites, la connectivité, le matériel informatique et une grande partie de l’environnement opérationnel.

Cette différence compte davantage que la coïncidence d’un même lancement. Elle dessine une compétition précoce pour le contrôle de la couche informatique au-dessus de la Terre : des propriétaires d’engins spatiaux verticalement intégrés ou une plateforme indépendante reliant des flottes hétérogènes.

Le logiciel d’IA orbitale de Satlyt a dépassé le stade de la proposition

Le changement immédiat est que Satlyt dispose désormais de financements, d’une expérience en vol et de charges de travail réelles, plutôt que d’une proposition interne rejetée.

Afullo a travaillé dans l’organisation cloud de Google avant de rejoindre l’activité Starlink de SpaceX en 2024. Il a déclaré à TechCrunch avoir proposé l’informatique orbitale au sein des deux entreprises. Chacune a alors rejeté l’idée.

Il a ensuite cofondé Satlyt, qui opère depuis Sunnyvale, en Californie, et Nairobi, au Kenya. L’entreprise développe un logiciel permettant aux satellites de traiter les données localement et, à terme, de partager des tâches de calcul entre engins spatiaux.

Le tour d’amorçage de 8 millions de dollars de Satlyt a été mené par Non Sibi Ventures, basé à Houston. Parmi les associés de l’investisseur figure l’ancien astronaute de la NASA Bernard Harris, dont l’expérience a aidé le fonds à évaluer la proposition technique et commerciale.

Le financement n’est qu’un aspect de l’événement. Satlyt affirme que son logiciel a déjà volé lors de deux missions de démonstration, donnant à l’entreprise une expérience du calcul sous contraintes au-delà des tests en laboratoire.

Son dernier déploiement signalé concerne du matériel construit par TakeMe2Space, une entreprise indienne qui développe des systèmes informatiques pour satellites. La mission embarque trois charges de travail clients différentes à bord de l’engin spatial.

La NASA finance des tests de protocoles pour le cloud computing dans l’espace. Stellerian, qui travaille sur la surveillance orbitale, prévoit d’évaluer le traitement d’images. TakeMe2Space veut démontrer que son satellite peut héberger des logiciels provenant d’entreprises externes.

Ces clients représentent trois niveaux importants de demande. Une agence gouvernementale souhaite une validation technique, un opérateur commercial veut une analyse plus rapide et un constructeur spatial cherche un produit plus flexible.

Cette combinaison offre à Satlyt un test plus solide qu’une simple démonstration logicielle. Sa plateforme doit prendre en charge des charges de travail distinctes tout en fonctionnant dans les limites d’un seul engin spatial en matière d’énergie, de mémoire, de température et de communications.

L’entreprise a également déployé un modèle Gemma 3 quantifié à bord d’un satellite exploité par Momentus. La quantification réduit la précision numérique d’un modèle, ce qui l’aide à fonctionner avec moins de mémoire et de puissance de calcul.

Selon les tests de Gemma, le modèle d’un milliard de paramètres a analysé localement la télémétrie, les journaux d’applications et les erreurs logicielles. Il a été exécuté via llama.cpp, un framework d’inférence conçu pour une exécution efficace des modèles.

Lors de deux tests d’injection de pannes, le système a réduit les charges de diagnostic de 1 319 octets à 469 octets et de 1 318 octets à 464 octets. Ces réductions atteignaient 64,4 % et 64,8 %.

Le modèle a également produit de courts diagnostics et recommandé des actions à partir du contexte technique disponible. Ce résultat ne démontre pas la fiabilité d’opérations autonomes d’engins spatiaux, mais il illustre un usage immédiat de l’IA embarquée.

Au lieu de transmettre chaque journal brut vers la Terre, un satellite peut résumer une erreur avant d’utiliser une fenêtre de liaison descendante limitée. Les contrôleurs au sol reçoivent alors un message plus petit et plus utile.

Les progrès de Satlyt reposent donc sur une charge de travail concrète, et non uniquement sur l’idée lointaine d’immenses centres de données orbitaux. L’entreprise commence par les diagnostics logiciels, l’analyse de télémétrie et le traitement d’images sur du matériel déjà en route vers l’orbite.

C’est là que se situe la tension centrale de l’article. SpaceX et Google peuvent poursuivre l’informatique orbitale au moyen de systèmes étroitement contrôlés, tandis que Satlyt doit prouver qu’un logiciel partagé peut fonctionner sur les machines d’autres entreprises.

Le marché à court terme est le traitement embarqué, pas les gigantesques centres de données spatiaux

Satlyt n’a pas besoin d’un cloud orbital à grande échelle pour créer de la valeur, mais les opérateurs de satellites doivent considérer le logiciel comme une décision d’achat indépendante.

La plupart des satellites dépendent encore largement des stations au sol. Ils collectent des images, des relevés de capteurs, des données opérationnelles et des journaux d’erreurs, puis transmettent certaines informations lors de fenêtres de communication planifiées.

Ce modèle crée un goulet d’étranglement. Un engin spatial peut générer davantage de données qu’il ne peut en envoyer économiquement vers la Terre, en particulier lorsque les fenêtres de contact sont brèves ou que la bande passante est disputée.

Le traitement embarqué rapproche une partie de la décision du capteur. Un satellite peut écarter des images inutilisables, prioriser des objets suspects, résumer des pannes ou compresser des observations avant transmission.

L’idée rappelle l’edge computing sur Terre. L’edge computing exécute l’analyse près de la source des données, réduisant la nécessité d’envoyer l’ensemble vers un cloud centralisé.

Dans l’espace, le compromis est plus sévère. Un appareil terrestre distant peut retrouver une connexion réseau en quelques minutes. Un engin spatial peut être confronté à une couverture limitée, à des budgets énergétiques stricts, aux radiations et à l’absence de toute possibilité de réparation physique.

C’est pourquoi l’exemple diagnostique de Satlyt compte. Réduire un rapport d’erreur de plus de 60 % peut sembler modeste face aux visions de clusters d’IA en orbite. Mais cela répond à un coût auquel les opérateurs sont déjà confrontés.

L’entreprise affirme que l’analyse locale peut réduire le travail de traitement au sol et raccourcir les délais de réponse aux anomalies. Les économies financières exactes varieront selon le satellite, la mission, le modèle de personnel et le contrat de communications.

Le traitement d’images offre un autre cas immédiat. Un satellite d’observation de la Terre peut identifier les images couvertes de nuages avant de les transmettre, ou donner la priorité aux images contenant une condition cible.

Les charges de travail de surveillance spatiale suivent la même logique. Un satellite peut filtrer les images à la recherche d’objets potentiels ou de mouvements inhabituels, puis transmettre d’abord les données les plus pertinentes.

Ces applications n’exigent pas un centre de données de la taille d’un entrepôt en orbite. Elles nécessitent de petits modèles dont le comportement reste prévisible sur des ordinateurs contraints et qui produisent des résultats utiles dans des budgets de ressources stricts.

Cette distinction a également attiré l’investisseur principal de Satlyt. Kent Lucas, associé de Non Sibi, a déclaré à TechCrunch que l’entreprise n’avait pas besoin de gigantesques centres de données spatiaux pour réussir. La croissance du secteur satellitaire peut à elle seule élargir son marché adressable.

L’argument est logique, mais il repose encore sur plusieurs hypothèses. Davantage d’engins spatiaux doivent embarquer des processeurs généralistes, les opérateurs doivent autoriser les logiciels tiers et les concepteurs de missions doivent consacrer une énergie rare aux charges de travail d’IA.

Afullo s’attend à ce que les processeurs avancés deviennent courants dans les satellites. Il s’est fixé l’objectif ambitieux d’atteindre 20 % des satellites d’ici la fin de cette décennie.

Cet objectif reste une ambition de l’entreprise, et non une prévision indépendante. Les flottes de satellites diffèrent fortement, et de nombreux engins utilisent des ordinateurs spécialisés conçus pour une mission unique soigneusement validée.

L’opportunité reste néanmoins plus facile à comprendre que le vaste récit du cloud orbital. Satlyt peut vendre un traitement embarqué utile avant que les satellites ne commencent à partager les plus grandes charges de travail d’IA.

Les développeurs devraient considérer cette phase comme un test de portabilité logicielle. La question centrale est de savoir si une même couche opérationnelle peut prendre en charge différents processeurs, charges utiles, systèmes de communication et exigences de sécurité des engins spatiaux.

Les acheteurs d’entreprise devraient se concentrer sur les résultats plutôt que sur la rhétorique. Une réduction du volume de liaison descendante, une réponse plus rapide aux anomalies et des images à plus forte valeur sont des bénéfices mesurables, même si le système sous-jacent ne devient jamais un gigantesque centre de données.

Ces mesures concrètes expliquent également pourquoi les entreprises spatiales établies subissent une pression. Si les clients accordent de la valeur aux logiciels portables, les fournisseurs de matériel perdent une partie du contrôle sur les applications exécutées sur leurs satellites.

SpaceX construit l’iPhone tandis que Satlyt veut construire Android

La compétition principale n’oppose pas Satlyt et SpaceX par leur taille ; elle oppose une couche logicielle ouverte à une infrastructure informatique fermée et verticalement intégrée.

Afullo utilise une analogie familière pour expliquer la différence. Si SpaceX devient l’iPhone des centres de données orbitaux, il veut que Satlyt devienne Android.

La comparaison est imparfaite, mais elle résume la fracture stratégique. Apple combine matériel, logiciel d’exploitation, services et distribution au sein d’un système étroitement géré. Android prend en charge des appareils de nombreux fabricants.

SpaceX contrôle déjà une part plus importante de l’infrastructure physique que la plupart des concurrents potentiels. L’entreprise construit des fusées, exploite des infrastructures de lancement, fabrique des satellites, gère une constellation de communications et fournit des services de connectivité.

Cette intégration peut réduire les coûts de coordination. Les ingénieurs peuvent optimiser ensemble le matériel et le logiciel, maintenir des interfaces cohérentes et avancer rapidement sans devoir négocier des normes entre des fournisseurs d’engins spatiaux sans lien entre eux.

Elle crée aussi une dépendance. Un client qui s’appuie sur une plateforme orbitale propriétaire peut se retrouver lié au calendrier de lancement, à la feuille de route technique, aux prix, aux interfaces et aux décisions d’accès d’une seule entreprise.

Satlyt fait le pari inverse. L’entreprise ne prévoit pas de fabriquer des satellites. Son logiciel est conçu pour fonctionner sur des engins spatiaux appartenant à différents opérateurs et transformer leurs ressources informatiques en un service partagé.

L’entreprise compare son rôle à VMware et Snowflake. VMware a dissocié les applications de serveurs physiques spécifiques, tandis que Snowflake a offert aux clients une couche de données gérée à travers l’infrastructure cloud.

En orbite, cette abstraction est bien plus difficile. Les serveurs cloud terrestres utilisent des processeurs, réseaux, alimentations, systèmes de stockage et pratiques de maintenance relativement standardisés.

Les satellites sont des machines sur mesure exposées aux radiations, aux cycles thermiques, à une énergie limitée, à des liaisons intermittentes et au mouvement orbital. Même le redémarrage d’un processus défaillant peut avoir des conséquences à l’échelle de la mission.

Une plateforme orbitale ouverte doit donc faire plus qu’installer le même package sur différents ordinateurs. Elle doit s’adapter aux différences matérielles sans affaiblir les contrôles de sécurité ni interférer avec les fonctions essentielles de l’engin spatial.

La plateforme a également besoin d’une méthode sécurisée pour planifier les tâches. Une application tierce ne peut pas consommer l’énergie, la mémoire ou la capacité réseau nécessaires à la navigation, aux communications ou à la charge utile principale.

Ces défis renforcent l’argument en faveur de l’intégration verticale. SpaceX peut concevoir son matériel informatique, ses liaisons inter-satellites, son environnement opérationnel et ses systèmes d’alimentation comme un produit coordonné.

Toutefois, l’intégration ne garantit pas que les clients préféreront un système fermé. Les fabricants et opérateurs de satellites peuvent vouloir accéder à plusieurs fournisseurs de lancement, processeurs, modèles et fournisseurs d’analytique.

Une couche logicielle indépendante devient précieuse lorsque la diversité augmente. Chaque vaisseau spatial compatible supplémentaire élargit le pool potentiel de ressources informatiques sans obliger Satlyt à financer une flotte de satellites.

C’est le même effet de réseau qui a favorisé la croissance des plateformes logicielles sur Terre. Une base matérielle plus large attire les développeurs, tandis que davantage d’applications rendent la plateforme sous-jacente plus attrayante pour les fournisseurs de matériel.

L’orbite introduit un difficile problème de démarrage à froid. Satlyt a besoin de satellites compatibles avant que les développeurs n’investissent, mais les constructeurs de vaisseaux spatiaux ont besoin d’applications utiles avant d’allouer des ressources à Satlyt.

Ses premières missions tentent de résoudre ce problème au moyen de charges de travail concrètes. La NASA fournit un cas d’usage de validation, Stellerian fournit une application et TakeMe2Space fournit le matériel d’hébergement.

L’approche de Google offre un autre point de comparaison. Project Suncatcher envisage des satellites interconnectés embarquant des Google Tensor Processing Units, ou TPUs, alimentés par une énergie solaire abondante.

Les premières étapes du programme se concentrent sur le propre matériel informatique de Google. Son prototype, construit avec Planet, a été conçu pour mesurer la réaction des TPUs aux forces du lancement, aux radiations et à l’environnement thermique de l’espace.

Google a confirmé que le prototype a atteint l’orbite à bord de la mission Transporter-18 de SpaceX, le 1er octobre 2026. Le satellite a établi le contact et commencé son programme de tests.

Google teste donc si ses puces spécialisées peuvent survivre et fonctionner dans l’espace. Satlyt teste si un logiciel peut rendre utiles à des clients externes des ordinateurs orbitaux variés.

Les entreprises ne sont pas aujourd’hui des concurrentes directes. Leurs architectures pourraient même devenir complémentaires si une plateforme indépendante exécutait un jour des charges de travail sur des processeurs conçus par Google ou d’autres processeurs spécialisés.

Leurs priorités révèlent toutefois des centres de contrôle concurrents. Google commence avec du matériel qu’il possède et comprend. Satlyt commence par la portabilité entre des matériels qu’il ne contrôle pas.

Si l’informatique orbitale se développe, cette distinction façonnera les marges, le choix des clients et l’accès des développeurs. Le vainqueur final ne possédera peut-être pas le plus grand nombre de satellites, mais il influencera la façon dont les applications circulent entre eux.

Le cloud orbital ouvert doit encore résister à la réalité

L’argument le plus solide de Satlyt est la flexibilité, mais cette flexibilité devient un handicap lorsque les vaisseaux spatiaux diffèrent trop ou que les clients refusent de partager leurs ressources.

L’entreprise a montré qu’un petit modèle de langage peut traiter des données de diagnostic à bord d’un matériel contraint. Cela n’équivaut pas à exploiter un cloud distribué entre plusieurs satellites.

Le prochain grand objectif technique de Satlyt consiste à connecter des capacités de calcul entre deux vaisseaux spatiaux différents. L’entreprise prévoit de tenter cette démonstration l’année prochaine.

Un test concluant serait important, car l’informatique distribuée exige une coordination entre machines. Le logiciel doit répartir le travail, transférer les données, gérer les délais, se remettre des interruptions et vérifier que les résultats restent corrects.

Ces tâches sont courantes au sein des centres de données terrestres disposant d’une alimentation fiable et de réseaux à haut débit. Elles deviennent plus difficiles lorsque les deux ordinateurs orbitent autour de la Terre et ne communiquent que dans certaines conditions orbitales.

La latence n’est pas le seul problème. Les satellites peuvent avoir des processeurs, systèmes d’exploitation, exigences de sécurité, puissances disponibles et priorités de mission différents.

Les liaisons intersatellites peuvent également varier considérablement. Certains vaisseaux spatiaux disposent de communications laser, d’autres utilisent des liaisons radio, et beaucoup n’ont jamais été conçus pour échanger de lourdes charges de travail informatiques avec des satellites voisins.

Google a décrit la précision requise pour ses liaisons laser prévues comme l’équivalent de viser une cible de la taille d’une pièce à des kilomètres de distance, alors que les deux points se déplacent.

Ses tests illustrent également le défi matériel. Google indique que les composants lors du lancement peuvent subir des forces atteignant 50 à 100 fois la gravité, tandis que les radiations peuvent modifier les données stockées dans les systèmes électroniques.

Le contrôle thermique reste tout aussi important. Un processeur produit de la chaleur, mais un vaisseau spatial ne peut pas la refroidir avec une circulation d’air ordinaire, car l’espace est un vide.

Le logiciel de Satlyt ne peut pas supprimer ces limites physiques. Il ne peut les contourner par la planification que lorsque les vaisseaux spatiaux exposent une télémétrie précise et accordent à la plateforme un contrôle opérationnel suffisant.

La cybersécurité crée un autre obstacle. Un logiciel qui gère des charges de travail sur plusieurs satellites pourrait devenir une cible intéressante, car une compromission pourrait affecter plusieurs opérateurs.

Les clients exigeront une isolation entre les applications, des mises à jour signées, des contrôles d’accès, des registres d’audit et une autorité clairement définie concernant les arrêts d’urgence. Ces protections consomment des ressources informatiques supplémentaires.

Les sorties d’IA ajoutent un risque différent. Un modèle peut résumer une erreur de manière incorrecte ou mal classer une image, notamment lorsque ses entrées diffèrent de celles utilisées lors de son entraînement et de ses tests.

Pour cette raison, l’usage diagnostique actuel de Satlyt semble plus sûr qu’une commande autonome. Un modèle peut recommander une action aux opérateurs au sol sans recevoir l’autorité de modifier le comportement d’un vaisseau spatial.

L’entreprise affirme que les opérateurs conserveront l’autorité de commande à mesure qu’elle s’étendra vers la détection d’anomalies et les décisions multi-agents. La frontière pratique entre assistance et contrôle exigera une validation minutieuse.

Les incitations économiques sont tout aussi incertaines. Un propriétaire de satellite peut disposer de temps processeur inutilisé, mais le prêter à une charge de travail externe peut introduire une responsabilité sans générer suffisamment de revenus.

Le propriétaire doit également réserver de la capacité pour sa mission principale. Un satellite d’imagerie terrestre ne peut pas retarder les images de ses clients parce qu’une autre application a consommé de l’énergie ou saturé le stockage.

La stratégie « Android » de Satlyt ne fonctionne que si les fabricants de vaisseaux spatiaux prennent en charge des interfaces communes. Sans normalisation significative, chaque intégration devient un projet d’ingénierie sur mesure.

Cela affaiblirait l’économie d’une plateforme indépendante. Les marges logicielles dépendent de la répétition du même produit auprès de nombreux clients, et non de sa reconstruction pour chaque satellite.

La concurrence pourrait également venir d’entreprises qui possèdent le matériel. SpaceX, Google, Starcloud et d’autres initiatives d’informatique orbitale peuvent exposer des interfaces pour développeurs tout en conservant leurs systèmes sous-jacents propriétaires.

Une plateforme fermée gérée pourrait s’avérer plus facile à acheter qu’un réseau ouvert. Les clients acceptent souvent la dépendance envers un fournisseur lorsqu’un seul prestataire offre un déploiement plus simple, un meilleur support et des performances prévisibles.

Satlyt n’a donc pas établi que le modèle Android dominera. L’entreprise a établi que la voie ouverte est suffisamment crédible pour recevoir des financements et atteindre des missions actives.

La phase suivante doit démontrer la reproductibilité. Un modèle sur un satellite démontre la faisabilité, tandis que des charges de travail portables sur différents vaisseaux spatiaux étayeraient l’affirmation plus large de la plateforme.

Trois signaux montreront si Satlyt peut devenir une plateforme orbitale

Les prochaines preuves devront venir de l’informatique intersatellites, de clients récurrents et d’une valeur opérationnelle mesurable, plutôt que d’une nouvelle comparaison ambitieuse.

Le premier signal est la démonstration de cloud à deux satellites prévue par Satlyt. Il s’agit du test le plus direct de son affirmation technique centrale.

Les observateurs devraient rechercher une confirmation que les vaisseaux spatiaux proviennent de plateformes différentes. Deux satellites identiques sous un même opérateur testeraient l’informatique distribuée, mais pas une large interopérabilité.

La démonstration devrait également indiquer quel travail circule entre les satellites. Un petit échange de messages est moins significatif qu’un traitement coordonné avec une latence, une utilisation des ressources et un comportement de récupération documentés.

Une exécution réussie renforcerait l’argument de Satlyt selon lequel l’entreprise peut abstraire les différences matérielles. Un retard ou une démonstration plus limitée montrerait que la plateforme ouverte demeure moins avancée que ne le suggère son marketing.

Le deuxième signal est la récurrence des clients. La NASA, Stellerian et TakeMe2Space fournissent à l’entreprise des charges de travail initiales utiles, mais les pilotes n’établissent pas une demande durable.

Un signe plus fort serait qu’un client passe d’une expérience à plusieurs vaisseaux spatiaux. Cela indiquerait que le logiciel a créé suffisamment de valeur pour passer l’examen de la mission et les arbitrages budgétaires.

Une autre mesure importante est le nombre de constructeurs indépendants de vaisseaux spatiaux intégrant Satlyt. L’analogie avec Android exige plusieurs fabricants, et non plusieurs missions sur le matériel d’un seul partenaire.

Satlyt affirme disposer de logiciels préparés pour jusqu’à 50 déploiements sur des vaisseaux spatiaux en 2026. Une capacité préparée ne correspond pas à des déploiements activés, de sorte que les installations achevées comptent davantage.

Les lecteurs devraient distinguer les accords signés, les systèmes lancés, les charges de travail actives et les renouvellements payants. Chaque étape apporte un niveau différent de preuve commerciale.

Le troisième signal est la performance opérationnelle. La réduction des transmissions vers le sol fournit un premier indicateur, mais les clients se soucieront également de la précision, de la consommation d’énergie, de l’utilisation de la mémoire et du temps de réponse.

Les tests de Gemma offrent une base de référence utile. Satlyt a indiqué des charges utiles de diagnostic environ 64 % plus petites et des vitesses de génération supérieures à 22 tokens par seconde dans deux scénarios.

Ses tests plus larges examinent environ 11 watts de puissance processeur pendant l’inférence et une augmentation de température comprise entre trois et cinq degrés Celsius. Il s’agit de mesures fournies par l’entreprise dans des conditions de test contraintes.

Les futures publications devraient relier ces résultats techniques aux résultats de mission. Les opérateurs ont-ils résolu les pannes plus tôt, transmis des images plus précieuses vers le sol ou réduit la charge de travail au sol ?

Une confirmation indépendante aurait plus de poids qu’un nouveau benchmark interne. Les données de vol spatial provenant de clients ou de partenaires de recherche clarifieraient si les avantages persistent hors de tests contrôlés.

SpaceX et Google ne devraient pas attendre. Google collecte déjà des données depuis son prototype orbital de TPU, notamment sur les performances sous rayonnement et à des températures extrêmes.

Sa prochaine étape prévue consiste à tester la communication entre deux satellites. Les progrès dans ce domaine renforceraient le modèle verticalement coordonné, même si Google ne propose pas de plateforme commerciale étendue.

SpaceX dispose d’un autre avantage : l’échelle de déploiement. Son contrôle du lancement et de la fabrication des satellites lui permet d’itérer sans attendre que des fournisseurs de vaisseaux spatiaux non liés adoptent une interface commune.

Satlyt ne peut pas égaler ces ressources en capital. Son opportunité consiste à faire fonctionner le reste du marché davantage comme une base informatique partagée.

Ce schéma a fonctionné dans d’autres secteurs. Un logiciel indépendant devient précieux lorsque les clients veulent le choix et qu’aucun fournisseur de matériel ne peut contrôler l’ensemble du marché.

L’espace n’est toutefois pas un marché logiciel normal. Les normes de fiabilité, les contraintes physiques, les préoccupations de sécurité nationale et les longs cycles d’approvisionnement ralentissent tous l’adoption des plateformes.

Les développeurs devraient surveiller les interfaces qui émergent des premières missions. Un modèle d’application stable faciliterait le développement unique et le déploiement sur plusieurs vaisseaux spatiaux.

Les acheteurs de satellites devraient demander qui contrôle les mises à jour, la planification des charges de travail, l’accès à la télémétrie et la récupération après défaillance. Ces détails déterminent si « ouvert » signifie portable ou simplement compatible grâce à un travail sur mesure.

Les équipes qui évaluent les preuves ont également besoin de dossiers rigoureux couvrant les rapports de mission, les résultats de tests, les contrats et les décisions d’ingénierie. Une base de connaissances consultable peut maintenir ces affirmations reliées à leurs documents justificatifs.

Le logiciel d’IA orbitale de Satlyt a atteint un seuil important. L’entreprise dispose désormais de capitaux, d’une expérience de vol, d’expériences clients et d’un adversaire architectural clairement identifié.

L’entreprise n’a pas encore construit un cloud orbital couvrant différents satellites. Elle n’a pas non plus montré que les fabricants céderont suffisamment de contrôle pour permettre à une plateforme indépendante de passer à l’échelle.

C’est ce qui rend cette histoire digne d’intérêt. L’idée rejetée n’est plus hypothétique, mais sa promesse fondamentale reste à démontrer.

Au cours des prochains mois, surveillez le test à deux satellites, les déploiements répétés et les données de performance à l’échelle des missions. Ensemble, ils montreront si Satlyt construit Android pour l’orbite ou un outil spécialisé pour un petit nombre d’engins spatiaux.