Solidity ou Rust, lequel choisir pour la blockchain

Avant tout comparatif, une mise au point qui règle la moitié des malentendus.

Solidity n’est pas une blockchain, c’est un langage. C’est l’outil avec lequel on écrit des programmes destinés à Ethereum, exactement comme on écrit un site en PHP ou en JavaScript.

Solana n’est pas un langage, c’est un réseau. Pour y déposer un programme, on écrit en Rust, un langage généraliste qui existait bien avant.

La comparaison honnête est donc celle-ci. Solidity contre Rust côté langage. Ethereum contre Solana côté réseau. Et c’est le second choix qui commande le premier, jamais l’inverse.

Rien ne vaut de voir la même chose écrite des 2 façons. Voici un compteur, l’exemple le plus dépouillé qui soit. Il stocke un nombre et sait l’augmenter de 1.

En Solidity, pour Ethereum et les réseaux compatibles.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Compteur {
    uint256 public valeur;

    function incrementer() external {
        valeur += 1;
    }
}

En Rust, pour Solana, avec le cadre Anchor qui est le standard du réseau.

use anchor_lang::prelude::*;

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod compteur {
    use super::*;

    pub fn initialiser(ctx: Context<Initialiser>) -> Result<()> {
        ctx.accounts.compteur.valeur = 0;
        Ok(())
    }

    pub fn incrementer(ctx: Context<Incrementer>) -> Result<()> {
        // Sur Solana, la donnee ne vit pas dans le programme.
        // Elle vit dans un compte separe qu'il faut declarer et passer a chaque appel.
        ctx.accounts.compteur.valeur += 1;
        Ok(())
    }
}

#[account]
pub struct Compteur {
    pub valeur: u64,
}

9 lignes contre 25, et ce n’est pas une question de verbosité. La différence de fond est ailleurs. En Solidity, le programme contient ses données. Sur Solana, le programme et les données sont séparés, et il faut déclarer explicitement à quels comptes chaque appel touche.

⚠ Ce détail est la vraie marche à monter. Ce n’est pas la syntaxe de Rust qui fait tomber les débutants, c’est ce modèle de séparation.

Un seul chiffre décide pour la plupart des projets, et il n’a rien à voir avec l’élégance du code.

Solidity vise plus de 1 000 réseaux. Tous ceux qui sont compatibles avec la machine virtuelle d’Ethereum, ce qui inclut Polygon, Arbitrum, Base, BNB Chain et beaucoup d’autres. Un même code se redéploie de l’un à l’autre.

Rust vise moins de 5 % des réseaux. Solana principalement, et quelques autres.

Ce que ça veut dire pour un projet. Écrire en Solidity, c’est écrire une fois pour un très grand nombre de destinations possibles. Écrire en Rust pour la blockchain, c’est s’engager sur une destination précise.

Et pour une carrière, la lecture s’inverse en partie. Rust sert aussi hors blockchain, sur des serveurs, des outils système, de l’embarqué. Solidity ne sert qu’à ça.

L’argument commercial de Solana est réel, il faut simplement savoir ce qu’on en fait.

Ethereum traite de l’ordre de 15 à 30 opérations par seconde sur sa couche principale, avec des frais qui grimpent quand le réseau est chargé.

Solana annonce jusqu’à 65 000 opérations par seconde, avec des frais qui restent sous le centime.

⚠ Et voilà pourquoi ça ne tranche pas toujours. Pour une séquestre entre 2 entreprises, ou une règle de gouvernance déclenchée 3 fois par mois, la différence est nulle. 15 opérations par seconde, c’est déjà 1,3 million par jour.

La vitesse compte quand le volume compte. Micropaiements, jeu, échanges à haute fréquence. Pour tout le reste, l’écosystème et les partenaires pèsent plus lourd que le débit.

C’est l’angle que les comparatifs techniques oublient, et c’est souvent celui qui décide.

Le vivier n’est pas le même. Solidity existe depuis 2014, la communauté est vaste, les ressources abondantes, et un développeur web sérieux s’y met en quelques semaines.

Rust demande un investissement autrement plus lourd. Il faut apprendre le langage, puis le cadre Anchor, puis le modèle de comptes de Solana. Les profils juniors y sont rares, et les seniors se paient en conséquence.

La question à vous poser n’est donc pas quel langage est le meilleur. C’est qui maintiendra ce code dans 3 ans. Un choix technique brillant que personne dans votre équipe ne sait relire est un mauvais choix.

Dans l’ordre, et pas dans un autre.

1. Sur quel réseau vos utilisateurs et vos partenaires sont-ils déjà ? Si vos interlocuteurs travaillent sur un réseau compatible Ethereum, la question est réglée avant d’être posée.

2. Combien d’opérations par jour, réellement ? Comptez, ne devinez pas. En dessous de quelques milliers, l’argument de la vitesse ne vous concerne pas.

3. Qui écrira, puis relira ce code ? Si la réponse est un prestataire, demandez-lui sur quel réseau il a déjà livré, et faites-vous montrer un contrat déployé.

Et le conseil qui vaut pour les 2 langages. Le langage ne vous protège pas. La grande majorité des vols sur blockchain viennent d’une erreur de logique, un contrôle d’accès oublié, une condition mal écrite. Ça se code aussi mal dans un langage que dans l’autre, et ça se rattrape par la relecture, pas par la syntaxe. Nous détaillons ce point dans smart contract, ce que c’est et ce que ça ne fait pas.