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.

L’enquête annuelle Solidity, publiée en 2026, dresse le portrait de ceux qui écrivent ce langage. Elle est déclarative, donc à lire comme une photo de ce que les développeurs disent faire, pas comme une mesure.

La branche 0.8 du compilateur reste la norme. Le langage n’a toujours pas atteint sa version 1.0. C’est un signal à connaître avant de bâtir dessus, même s’il n’empêche personne de travailler.

Relisez la 2e ligne du contrat plus haut, pragma solidity ^0.8.20. Le symbole ^ veut dire au moins la version 0.8.20, et strictement avant la prochaine version majeure. Donc 0.8.21 compile, 0.9 ne compile pas. Retirer le ^ fige une version unique, ce que font beaucoup d’équipes juste avant une mise en production, pour être certaines que le code relu est bien celui qui part.

Foundry s’est imposé comme cadre de test, cité par 57 % des répondants contre 51 % l’année précédente. Un test s’y écrit en Solidity, dans le même langage que le contrat, ce qui supprime l’aller-retour mental avec JavaScript.

Hardhat V3 sait exécuter les tests écrits pour Foundry. Le choix de l’outil n’enferme donc plus une équipe, et changer de cadre ne repart pas de zéro.

L’erreur la plus signalée s’appelle Stack too deep. Elle frappe surtout les développeurs expérimentés sur des contrats complexes, pas les débutants. Et l’amélioration la plus demandée au langage tient en une phrase, de meilleurs messages d’erreur.

⚠ La population déclarée est jeune. Majorité de 18 à 34 ans, 1 à 5 ans d’expérience. Sur un sujet où une faute se paie en argent réel, c’est un point à garder en tête au moment de choisir qui écrit votre code.

Dernier signal de l’enquête, le déploiement revient vers Ethereum lui-même, le coût du gaz ayant beaucoup baissé. L’argument des frais, longtemps décisif dans le choix du réseau, pèse moins qu’avant.

La même enquête interroge les développeurs sur l’intelligence artificielle, et la réponse est plus nuancée que le discours ambiant.

88 % d’entre eux utilisent un outil d’IA au moins une fois par mois. L’adoption est quasi générale, personne ne travaille plus sans.

Et 45 % déclarent ne pas faire confiance à ses réponses. Presque 1 sur 2. Ce n’est pas de la méfiance de principe, c’est de l’expérience accumulée.

Ce qu’une IA rate le plus souvent sur ce langage. Elle produit volontiers du code écrit pour une version ancienne du compilateur, parce que c’est ce qu’elle a le plus vu pendant son apprentissage. Et elle reproduit des erreurs de sécurité de niveau débutant, du genre contrôle d’accès oublié, la faute que nous détaillons dans sécurité des smart contracts, la faille qui coûte le plus cher.

D’où l’usage réel qu’ils en font. Le test, la documentation, l’apprentissage et le débogage arrivent devant. L’écriture du code n’est pas le premier usage, alors que c’est celui que tout le monde imagine.

Les 2 réflexes qui changent le résultat. Indiquez explicitement à l’outil la version de compilateur visée, sinon il vous rendra du code d’il y a 3 ans. Et faites-lui écrire les tests plutôt que le contrat, c’est là qu’il est bon et c’est là qu’il fait gagner des heures.

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.

Nous faisons du développement sur mesure en Symfony et Laravel. La question qu’on nous pose est donc légitime. Est-ce que ce métier prépare à écrire un smart contract ?

Ce qui se transpose tel quel. La rigueur de conception, l’écriture des tests avant la livraison, la revue du code par un second regard, la gestion de versions. Ce sont les mêmes gestes, et ce sont eux qui séparent un contrat qui tient d’un contrat qui se fait vider. Une équipe qui travaille déjà ainsi part avec l’essentiel.

Ce qui ne se transpose pas, et qui s’apprend vraiment. 3 contraintes changent la nature du travail.

1. Le code déployé est public. N’importe qui lit votre logique métier, la compare à d’autres, cherche la faille. Sur un projet web classique, le code reste chez vous et l’erreur reste privée.

2. Il est pratiquement immuable. Pas de correctif poussé le lendemain matin. Ce que vous déployez, vous le gardez, ce que nous expliquons dans smart contract, ce que c’est et ce que ça ne fait pas.

3. Chaque exécution se paie. Une boucle mal écrite ne ralentit pas un serveur, elle coûte de l’argent à chaque appel, et c’est l’utilisateur qui règle la note. Optimiser cesse d’être une élégance, ça devient une ligne de facture.

Pourquoi les 45 % qui se méfient de l’IA sont notre argument. Nous utilisons ces outils, comme presque tout le monde. Nous ne livrons pas ce qu’ils produisent sans le relire, et c’est encore plus vrai ici qu’ailleurs. Sur un site, une erreur générée se corrige en 10 minutes. Sur une chaîne, elle est publique, définitive, et rentable pour celui qui la trouve avant vous.

Ce qu’un client peut nous demander aujourd’hui, sans que nous promettions la lune. Le cadrage honnête du besoin, à commencer par la question de savoir si une blockchain sert vraiment à quelque chose dans votre cas. La lecture d’un contrat existant et de son rapport d’audit avant que vous ne signiez. Le raccordement de votre outil métier à une chaîne, lecture d’état, suivi des transactions, tableau de bord. Et l’écriture de contrats simples, testés et relus, sur un périmètre défini avec vous.

Ce que nous ne vendons pas, et c’est aussi une information. L’audit de sécurité certifiant, qui est un métier à part entière avec ses propres cabinets. Et la conservation de crypto-actifs pour le compte d’un tiers, qui relève d’un agrément et pas d’un savoir-faire technique.

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.