Découvrez les raisons, les étapes et les compromis pour AKT, les validateurs et le cloud décentralisé.
Posséder son bâtiment, c’est agréable. Jusqu’au jour où l’on passe la majorité de ses journées à entretenir la chaudière, passer la tondeuse et remettre des tuiles sur le toit.
À la fin du mois, une question finit par s’inviter : tout ce travail aide-t-il vraiment notre activité à avancer ?
Akash prépare un virage de cet ordre. Ce réseau de cloud décentralisé envisage de quitter sa propre blockchain Cosmos pour installer sa marketplace sur Solana.
L’objectif affiché : alléger les charges liées à l’exploitation d’une blockchain et consacrer davantage de ressources à son métier, la mise à disposition de capacités de calcul.
Le choix soulève une question qui dépasse largement Akash : jusqu’où faut-il posséder ses fondations pour rester maître de son projet ?
Akash : un marché du calcul avant d’être une blockchain
Akash Network met en relation des utilisateurs qui cherchent des ressources informatiques et des fournisseurs indépendants qui disposent de serveurs.
CPU, mémoire, stockage, GPU : ces ressources permettent d’héberger des applications, des API ou des services d’intelligence artificielle.
Le fonctionnement ressemble à un appel d’offres. Un développeur décrit ses besoins, des fournisseurs proposent leurs conditions et une offre est sélectionnée. Un contrat de location, appelé lease, formalise ensuite la relation.
Une distinction est essentielle : les calculs sont exécutés sur les machines des fournisseurs. La blockchain coordonne les offres, les contrats et les mécanismes de règlement. Elle ne fait pas tourner un modèle d’IA à la place des GPU.
Les validateurs sécurisent la blockchain. Les fournisseurs hébergent les applications. Ces activités peuvent être exercées par un même opérateur, mais elles répondent à deux besoins différents.
Cette séparation explique pourquoi Akash peut changer de socle blockchain tout en conservant sa mission.
Les serveurs restent chez les fournisseurs. C’est le système qui coordonne le marché qui devrait changer.
Pourquoi Akash veut migrer vers Solana
La souveraineté a une facture
Akash exploite actuellement sa propre blockchain, construite avec le Cosmos SDK et CometBFT.
Cette architecture lui donne une autonomie importante : le réseau dispose de son consensus, de ses règles et de ses mécanismes d’évolution.
Mais cette liberté demande du travail. Il faut maintenir les logiciels, coordonner les mises à niveau, entretenir la sécurité économique et accompagner les validateurs.
Dans son rapport du 26 octobre 2026, l’équipe explique que la marketplace ne mobilise pas de fonctionnalités de consensus suffisamment spécifiques pour justifier, selon elle, cette charge.
C’est le diagnostic d’Akash sur ses propres besoins. Il ne démontre pas que toutes les blockchains souveraines sont inutiles.
Il pose cependant une question raisonnable : quand le métier consiste à proposer du calcul, quelle part des ressources doit-on consacrer à entretenir une blockchain ?
Être souverain a un coût. Encore faut-il que les pouvoirs conservés apportent une valeur à la hauteur de cet effort.
Solana apporte aussi des outils et un écosystème
La réduction des charges n’explique pas tout.
Akash met également en avant l’environnement technique de Solana, la présence de projets DePIN et l’accès à des utilisateurs, des développeurs et de la liquidité.
Le DePIN regroupe des réseaux qui utilisent des mécanismes blockchain pour coordonner des infrastructures physiques : calcul, stockage, connectivité ou autres ressources.
Pour Akash, rejoindre un environnement où ces activités sont déjà présentes pourrait faciliter certaines intégrations et rapprocher le produit de nouveaux utilisateurs.
Le rapport souligne aussi l’adéquation de plusieurs outils avec les besoins de sa marketplace, notamment les flux de prix Pyth, les crédits de calcul non transférables et la prise en charge des frais par des relais.
Ces avantages restent à traduire en résultats.
S’installer dans une rue fréquentée ne garantit pas que les clients pousseront la porte. Une migration ne crée ni demande de GPU ni qualité de service par magie.
La direction se précise, la migration reste à réaliser
Le soutien exprimé à la proposition #346 donne une direction au projet. Il faut néanmoins distinguer le choix de migrer, la clôture formelle du scrutin et l’exécution technique.
Au 29 octobre 2026, Akash n’a pas encore transféré sa marketplace sur Solana.
Le plan publié prévoit plusieurs étapes : migration du token, développement des programmes, audits, tests avec les fournisseurs et répétitions de la bascule.
Le transfert effectif de la marketplace, appelé cutover, doit faire l’objet d’une décision de gouvernance distincte, une fois les conditions techniques remplies.
Cette précision permet de comprendre où commence désormais le travail : transformer une orientation stratégique en infrastructure opérationnelle.
Changer de consensus déplace les dépendances
En utilisant Solana, Akash n’aurait plus à exploiter son propre consensus. Il dépendrait en revanche du fonctionnement, des frais et des évolutions de cette infrastructure commune.
Le projet conserverait des leviers sur ses programmes et leur gouvernance. Il ne pourrait plus décider seul des règles du consensus sous-jacent.
La décentralisation doit donc être examinée à plusieurs niveaux : les fournisseurs de calcul, l’accès à la marketplace, les logiciels, les interfaces, la gouvernance et la sécurité blockchain.
Posséder sa chaîne ne garantit pas l’indépendance de chaque couche. Utiliser une chaîne commune ne dispense pas non plus d’examiner les dépendances qu’elle introduit.
Le plan reconnaît notamment la perte de la connectivité IBC native de la chaîne actuelle. Les échanges futurs avec Cosmos devraient utiliser d’autres mécanismes, avec leurs propres hypothèses de sécurité.
Le compromis mérite d’être regardé en face : certaines responsabilités disparaissent du périmètre d’Akash, tandis que d’autres sont confiées à un réseau extérieur.
AKT, validateurs, fournisseurs : chacun son déménagement
AKT conserverait son identité
Le plan annoncé prévoit une migration d’AKT vers un token natif Solana, avec une conversion d’un pour un.
AKT ne serait donc pas remplacé par SOL.
Le lancement du token et la migration de la marketplace constituent deux étapes distinctes. Les modalités annoncées restent soumises aux audits et aux validations prévues.
Les validateurs perdraient leur rôle sur l’ancienne chaîne
L’arrêt final de la blockchain Akash mettrait fin au rôle de ses validateurs dans ce consensus et aux revenus associés.
Le plan évoque d’autres activités possibles pour ces opérateurs. Elles ne constituent toutefois ni une compensation équivalente ni une source de revenus garantie.
Derrière la simplification technique se trouvent aussi des équipes qui ont contribué au fonctionnement du réseau. Leur transition fait partie du coût du changement.
Les fournisseurs et les utilisateurs devront se préparer
Les fournisseurs de calcul devront adapter leurs logiciels et se réenregistrer dans le nouvel environnement.
Pour les utilisateurs, les applications existantes ne sont pas censées s’interrompre au simple vote d’orientation. Le plan prévoit une période de transition après la bascule, pendant laquelle les locataires devront organiser leurs redéploiements.
Une continuité temporaire ne signifie pas une absence de démarches. Le déménagement doit être préparé, même lorsque les cartons sont numériques.
Un vote donne un mandat ; les tests doivent tenir la promesse
Permettre à une communauté de se prononcer sur l’avenir de sa propre blockchain est un exercice de gouvernance important.
Les intérêts ne sont pas identiques pour tous : détenteurs d’AKT, validateurs, fournisseurs et utilisateurs ne supportent pas les mêmes coûts et n’attendent pas les mêmes bénéfices.
Un soutien massif donne un mandat politique. Il ne remplace pas les audits, les essais et les vérifications économiques.
La réussite devra se mesurer à des résultats concrets : fiabilité des règlements, capacité disponible, expérience de déploiement et coûts réellement observés.
Il faudra notamment éviter un raccourci : des transactions blockchain moins coûteuses ne garantissent pas des locations de GPU moins chères dans les mêmes proportions.
Le matériel, l’électricité, la connectivité et la demande continuent de peser dans la facture.
La souveraineté doit pouvoir durer
Attaché à Cosmos, je trouve forcément cette direction un peu amère. Mais je préfère voir un projet chercher son équilibre que défendre une architecture par nostalgie.
Pour certains réseaux, maîtriser leur propre chaîne répond à une nécessité technique ou politique. Pour d’autres, cette autonomie peut absorber des ressources qui seraient plus utiles au service proposé.
La souveraineté, aussi belle et louable soit-elle, doit pouvoir se soutenir dans la durée.
Ce choix mérite d’être réfléchi dès la conception, puis réévalué lorsque le projet évolue. Une architecture pertinente au lancement peut devenir moins adaptée quelques années plus tard.
Le curseur ne devrait pas se régler au gré des modes. Il demande de savoir quels pouvoirs on accepte de déléguer, lesquels on veut garder et pourquoi ils sont essentiels.
C’est sur cet équilibre qu’Akash sera attendu. Et, derrière lui, bien d’autres projets DePIN.
FAQ — Le déménagement sans cartons magiques
Les GPU vont-ils prendre un aller simple pour Solana ?
Non. Les GPU restent dans les infrastructures des fournisseurs. Solana accueillerait les programmes qui coordonnent la marketplace. On change le système de gestion des locations, pas l’emplacement de toutes les machines.
AKT va-t-il se réveiller avec un badge SOL ?
Non. Le plan prévoit de conserver AKT sous une forme native Solana, avec une conversion d’un pour un. SOL servirait aux frais du réseau, que certains outils pourraient prendre en charge pour l’utilisateur. Les deux tokens garderaient des fonctions distinctes.
Si la direction est choisie, pourquoi les déménageurs ne sont-ils pas déjà partis ?
Parce qu’une décision de gouvernance ne déplace pas une infrastructure à elle seule. Les programmes, les outils et les mécanismes de migration doivent être testés et audités. Une décision distincte doit encadrer la bascule effective de la marketplace.
Les validateurs peuvent-ils simplement devenir fournisseurs de GPU ?
Certains pourraient développer cette activité, mais les métiers et les investissements diffèrent. Exploiter un validateur ne signifie pas disposer de GPU adaptés, de clients ou d’une activité cloud rentable. La reconversion n’a rien d’automatique.
Les GPU seront-ils moins chers une fois la chaudière mutualisée ?
Ce n’est pas garanti. Réduire certaines charges blockchain peut améliorer l’efficacité du système, mais le prix du calcul dépend aussi des équipements, de l’énergie, de la disponibilité et de la concurrence entre fournisseurs.
Utiliser Solana transforme-t-il Akash en cloud centralisé ?
Pas automatiquement. Les fournisseurs peuvent rester indépendants alors que la coordination repose sur une blockchain commune. Il faut examiner chaque couche du système et les pouvoirs qui y sont exercés.
Faut-il absolument posséder sa blockchain pour être souverain ?
Cela dépend des pouvoirs dont le projet a besoin. Contrôler son consensus peut être essentiel dans certains cas. Dans d’autres, une infrastructure commune peut être acceptable si les dépendances sont comprises et compatibles avec la mission. La souveraineté se juge aussi à ce qu’on peut réellement contrôler et maintenir.
Sources
- Akash — Why We Selected Solana for Akash, Greg Osuri, 26 octobre 2026. Rapport officiel sur le choix de Solana, les compromis et les étapes annoncées.
- Akash — Core Concepts. Documentation sur les fournisseurs, les déploiements, les contrats de location et le fonctionnement de la marketplace.
- AEP-79 — Akash on Shared Security. Proposition et documentation technique du programme de migration.
- Akash — Chain Migration Program. Dossier technique consacré à l’architecture cible, à la migration et aux contrôles de sécurité.
- Akash — Proposition de gouvernance #346. Suivi du scrutin et de son statut officiel.
Article arrêté au 29 octobre 2026. Les étapes techniques décrites correspondent au plan annoncé et ne doivent pas être confondues avec des fonctionnalités déjà déployées.
