Le changelog Solana daté du 18 septembre 2026 récapitule plusieurs livraisons techniques et une évolution notable du réseau S1S2. Pour un lecteur francophone, l’enjeu n’est pas de suivre chaque numéro de version, mais de comprendre ce qui change concrètement pour les applications et pour l’usage quotidien. Voici une lecture ordonnée des faits sourcés, avec leurs limites et une action utile.
Outils et composants mis à jour
Côté outillage, plusieurs briques progressent. Solana Go, maintenu par la Solana Foundation, propose désormais les versions v2.1.0 et v1.24.0 S1. Le SDK Rust du Stake Program passe pour sa part à la version v5.0.0 S1. Le changelog hebdomadaire mentionne également de nouvelles versions publiées à travers l’outillage Solana, dont Agave, Firedancer, un SDK et LiteSVM S2.
Ce que cela signifie en pratique : ces mises à jour concernent d’abord les développeurs et les opérateurs qui intègrent ces bibliothèques. Un changement de version majeure, comme le passage à v5.0.0 S1, implique souvent des adaptations de code. Le changelog ne détaille pas ici de restriction particulière ni de calendrier d’obligation ; il faut donc s’en tenir aux notes de version de chaque projet avant toute migration.
| Composant | Version citée | Source |
|---|---|---|
| Solana Go (Solana Foundation) | v2.1.0, v1.24.0 | S1 |
| Stake Program Rust SDK | v5.0.0 | S1 |
Tableau de lecture établi à partir des éléments sourcés.
Réseau et transactions : ce qui bouge
Deux points ressortent sur le réseau. D’abord, une fonctionnalité de temps de slot à 300 ms a atteint le Mainnet via un feature gate, tandis que les transactions V1 approchent S2. Le changelog emploie ici le vocabulaire de l’anticipation : « approaching » pour les transactions V1, et « reached Mainnet » pour le mécanisme de slot à 300 ms S2. Ces deux formulations ne décrivent pas le même statut ; il convient de ne pas confondre une arrivée sur le réseau avec une généralisation d’usage.
Ensuite, la SIMD-0286 a été activée sur le Mainnet pour porter les limites de blocs à 100M CUs (compute units) S2. Une limite de bloc plus élevée peut permettre davantage de calcul par bloc, ce qui intéresse les applications gourmandes en ressources. Le changelog n’attribue toutefois aucune promesse chiffrée de performance à cette activation : il énonce le relèvement de la limite, pas un résultat mesuré côté utilisateur final S2.
Pour approfondir le contexte de fiabilité du réseau, voir notre article sur Solana et la confiance après la panne d’août 2026.
Débuter : le rôle du portefeuille
Pour l’utilisateur non technique, l’essentiel reste le portefeuille. Selon la documentation Solana, celui-ci détient les actifs, signe les transactions et connecte l’utilisateur aux applications S3. La même ressource recommande de vérifier les phrases secrètes, les liens, les autorisations et les connexions d’applications avant de signer fréquemment S3.
Exemple fictif pour illustrer : si une application demande une signature pour « optimiser » un solde, on relit d’abord l’adresse du site et l’autorisation demandée avant d’approuver. Ce réflexe, décrit par la documentation S3, ne dépend d’aucune version logicielle.
Limites et action utile
Ce changelog reste une communication de l’éditeur : ce ne sont pas des tests indépendants. Les versions S1 et les activations réseau S2 décrivent des livraisons, pas des mesures externes de performance ou de sécurité. Action concrète : lisez les notes de version avant de migrer un projet, et gardez le réflexe de vérification avant chaque signature S3. Pour situer l’écosystème plus largement, voir aussi MoneyGram devient validateur Solana en 2026.
