Avant de préparer les questions d'entretien d'un développeur blockchain Rust, précisez la plateforme visée, Solana ou Substrate. Les deux utilisent Rust et se ressemblent peu sur le reste. Sur Solana, le développeur écrit des programmes, le plus souvent avec le framework Anchor, et souvent le client TypeScript qui construit les transactions. Avec le Polkadot SDK, il assemble des pallets FRAME qui forment le runtime d'une chaîne et prépare des mises à jour sans fork.
Un CV Rust solide ne garantit rien sur ces postes. Les failles Solana viennent rarement du langage. Elles viennent d'un compte substitué par l'attaquant, d'une signature non vérifiée ou d'un appel vers un programme dont l'identifiant n'est pas contrôlé. Un candidat expérimenté explique ce qu'Anchor vérifie pour lui et ce qu'il doit encore vérifier à la main. Côté Substrate, il parle de poids, de benchmarks et de migrations de stockage.
Les outils bougent vite. Anchor est passé en version 1.0, avec un nouveau paquet TypeScript et LiteSVM comme modèle de test par défaut. Polkadot Hub exécute aussi des contrats Solidity. Les offres publiées en France sont peu nombreuses et portent souvent un intitulé anglais. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
Solana, Anchor, Polkadot SDK : la pile d'un développeur blockchain Rust
Rust on-chain
Le langage des programmes Solana et des runtimes Substrate. Un runtime Substrate se compile sans bibliothèque standard (no_std) vers WebAssembly, et un programme Solana tourne dans une machine virtuelle limitée, sans accès au système. Dans les deux cas, le code doit rester déterministe et traiter chaque dépassement d'entier.
Modèle de comptes Solana
Sur Solana, tout est compte : programmes, jetons, données des utilisateurs. Un programme ne stocke rien en lui-même. Il lit et écrit les comptes passés à chaque instruction, et ne peut modifier que ceux dont il est propriétaire. Chaque compte bloque un dépôt de loyer (rent) proportionnel à sa taille, rendu à sa fermeture.
Anchor
Le framework courant pour écrire des programmes Solana. Il génère la désérialisation, l'IDL lu par les clients et une grande partie des contrôles de sécurité à partir de contraintes déclarées sur les comptes (signer, has_one, seeds). La version 1.0 a renommé le paquet TypeScript en @anchor-lang/core et refuse par défaut les comptes mutables en double.
PDA et appels entre programmes (CPI)
Une PDA est une adresse dérivée d'un programme et de graines (seeds), sans clé privée, pour laquelle seul ce programme peut signer. Elle sert aux coffres, aux comptes de configuration et aux comptes par utilisateur. Les CPI permettent d'appeler un autre programme, par exemple pour transférer des jetons.
SPL Token et Token-2022
Les programmes standard des jetons sur Solana. Un solde vit dans un compte de jeton distinct, souvent le compte associé (ATA) déterminé par le portefeuille et le mint. Token-2022, aussi appelé Token Extensions, ajoute frais de transfert, hooks de transfert et métadonnées, que le programme doit savoir traiter.
Polkadot SDK : Substrate et FRAME
Substrate, intégré au Polkadot SDK, sert à construire une blockchain complète. Le runtime, qui porte la logique de la chaîne, s'assemble à partir de pallets FRAME, se compile en WebAssembly et se met à jour sur la chaîne sans fork. Cumulus rend le runtime compatible avec Polkadot, et XCM fait communiquer les chaînes entre elles.
Poids, benchmarks et migrations
Sur Substrate, chaque appel déclare un poids, mesuré par des benchmarks, qui borne le temps d'exécution d'un bloc. Une mise à jour du runtime qui change le format du stockage doit embarquer une migration. Demandez une migration déjà écrite par la personne et la façon dont elle l'a testée.
Tests, vérification et déploiement
Côté Solana, LiteSVM et Mollusk exécutent les programmes en tests rapides, Surfpool remplace le validateur local dans Anchor 1.0, et solana-verify permet de vérifier qu'un programme déployé correspond au code publié. Côté Polkadot, les pallets se testent sur un runtime simulé, et Chopsticks rejoue une chaîne réelle en local.
Le développeur blockchain Rust travaille sur des programmes Solana, sur le runtime d'une chaîne construite avec le Polkadot SDK, ou sur l'infrastructure autour : indexeurs, nœuds, outils de portefeuille. Les profils Solana écrivent souvent aussi le client TypeScript qui construit les transactions. Les profils Substrate se rapprochent du développement système, avec des contraintes de déterminisme et de performance. Le poste porte souvent un intitulé anglais (Rust engineer, Solana developer, smart contract engineer). Un programme déployé et vérifié, ou une contribution acceptée sur un projet du Polkadot SDK, en dit plus qu'une liste de chaînes sur le CV.
Les points à vérifier chez un développeur blockchain Rust
- Rust pour le code on-chain
- Modèle de comptes Solana et Anchor
- Sécurité des programmes Solana
- Runtime Substrate et pallets FRAME
- Transactions, unités de calcul et frais
- Tests, déploiement et mises à jour
Cinq questions pour un développeur Solana ou Substrate
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Votre instruction reçoit un compte de configuration qui contient l'adresse de l'administrateur. Qu'est-ce qui empêche un attaquant de passer son propre compte à la place ?
Une bonne réponseLa vérification du propriétaire du compte, qui doit être notre programme, et de son type, grâce au discriminateur de 8 octets qu'Anchor écrit en tête de chaque compte. Si le compte est une PDA, la vérification de ses graines et de son bump canonique. Avec Anchor, le type Account<'info, Config> et la contrainte seeds font ces contrôles. La personne ajoute has_one pour lier l'administrateur stocké au signataire, et le type Signer sur ce dernier.
Signal d'alerte« Anchor s'en occupe » sans pouvoir dire quels contrôles il fait, ou un UncheckedAccount utilisé sans vérification manuelle.
Question 2 · junior à confirmé
Comment stockez-vous un solde par utilisateur dans un programme Solana ?
Une bonne réponseUn compte par utilisateur, à une PDA dérivée de graines comme un préfixe et la clé publique de l'utilisateur, créé avec la contrainte init et payé par l'utilisateur, qui verse le dépôt de loyer. Une taille calculée à l'avance (InitSpace) et un champ bump conservé dans le compte. Pour des jetons, un compte de jeton détenu par une PDA du programme. La personne sait qu'un programme Solana n'a pas de variables d'état comme un contrat Solidity.
Signal d'alerteUn vecteur de tous les utilisateurs dans un seul compte qui grossit sans limite, ou une table de hachage « en mémoire du programme ».
Question 3 · junior à confirmé
Dans un calcul de récompenses, une multiplication de deux u64 peut déborder. Comment l'écrivez-vous ?
Une bonne réponsechecked_mul et checked_div avec une erreur explicite quand le résultat vaut None, ou un passage en u128 pour le calcul intermédiaire avant de revenir en u64 avec try_into. La personne sait qu'en compilation release un dépassement repart silencieusement de zéro si overflow-checks n'est pas activé dans le Cargo.toml, et que les fonctions saturating_* masquent l'erreur au lieu de la signaler. Elle pense aussi à l'ordre des opérations et au sens de l'arrondi.
Signal d'alerte« Rust protège des dépassements » sans condition, ou un unwrap() qui fait échouer la transaction sans message exploitable.
Question 4 · confirmé à senior
Vous modifiez la structure stockée par une pallet FRAME dans une mise à jour du runtime. Que devez-vous livrer avec ?
Une bonne réponseUne migration de stockage qui convertit les anciennes valeurs, écrite avec OnRuntimeUpgrade ou sous forme de migration versionnée, et protégée par la version de stockage de la pallet pour ne pas s'exécuter deux fois. La personne vérifie le poids de la migration, qui doit tenir dans un bloc, ou passe à une migration en plusieurs blocs. Elle la teste sur l'état réel de la chaîne avec try-runtime ou Chopsticks avant de proposer la mise à jour.
Signal d'alerteChanger le type et compter sur une remise à zéro, ou ignorer que le nouveau code devra décoder les données écrites par l'ancien.
Question 5 · confirmé
Une transaction de votre programme échoue sur le réseau principal pour dépassement d'unités de calcul, alors qu'elle passe en local. Que faites-vous ?
Une bonne réponseMesurer la consommation réelle en simulation et dans les journaux du programme, puis demander une limite plus haute avec l'instruction SetComputeUnitLimit du programme Compute Budget, jusqu'à 1,4 million d'unités par transaction, et fixer un prix par unité (frais de priorité) quand le réseau est chargé. Côté programme, réduire les journaux msg!, la désérialisation de gros comptes (zero-copy), les appels à find_program_address dans des boucles et les CPI inutiles.
Signal d'alerteRenvoyer la transaction en boucle sans mesurer, ou ignorer qu'une instruction a une limite par défaut.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Avant de recruter un développeur blockchain Rust
Solana ou Substrate : faut-il un profil qui connaît les deux ?
Rarement. Les deux plateformes partagent Rust et peu d'autres choses : comptes et transactions côté Solana, runtime, pallets et gouvernance côté Polkadot SDK. Un développeur Rust solide peut passer de l'une à l'autre, mais les failles typiques et l'outillage diffèrent et demandent un vrai temps d'apprentissage. Rédigez l'offre pour la plateforme réelle du poste, posez les questions de cette plateforme, et comptez l'autre comme un plus.
Un développeur Rust back-end peut-il devenir développeur Solana ?
Oui, à condition d'apprendre le modèle d'exécution. Le Rust d'un programme Solana est souvent plus simple que celui d'un service back-end asynchrone, mais la sécurité repose sur des contrôles de comptes qu'aucun compilateur ne fait. En entretien, donnez une instruction Anchor avec un compte non vérifié et demandez ce qui manque. Sans expérience blockchain, prévoyez une relecture par un profil Solana pendant les premiers mois.
Quel test technique proposer à un développeur blockchain Rust ?
Une revue de code de 30 minutes fonctionne bien. Pour Solana, une instruction Anchor de retrait avec un signataire non vérifié et un appel vers un programme non contrôlé. Pour Substrate, un appel de pallet avec un vecteur non borné et un poids fixe écrit à la main. La personne commente à voix haute et propose ses corrections. Pour un senior, ajoutez la conception d'une mise à jour avec migration et tests.
Que regarder sur le CV d'un développeur Solana ou Polkadot ?
Des programmes déployés et vérifiés, avec leur adresse, ou des contributions publiques au Polkadot SDK, à Anchor ou à des projets audités. Les noms d'outils datent aussi l'expérience : un CV qui ne cite que @project-serum/anchor, l'ancien paquet TypeScript d'Anchor, décrit une pratique de plusieurs années, à faire actualiser en entretien. Un rapport d'audit portant sur le code de la personne est un bon point de départ pour la discussion.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
