Le poste visé doit guider les questions d'entretien d'un développeur Solidity. Au quotidien, il écrit des contrats, les teste avec Foundry ou Hardhat, prépare les audits et déploie sur Ethereum, sur un layer 2 ou sur une chaîne privée compatible EVM comme Hyperledger Besu. Il suit ensuite les contrats en production. Selon l'équipe, il travaille avec un développeur front qui branche les portefeuilles et avec des auditeurs externes.
Les CV citent ERC-20, OpenZeppelin et Hardhat, ce qui ne dit rien du niveau. Un profil qui a déjà eu des fonds en jeu parle de réentrance au-delà du cas d'école, de prix d'oracle périmé, de collision de stockage entre deux versions d'un proxy et de tests d'invariants. Demandez le dernier rapport d'audit reçu sur son code et ce qu'il a corrigé.
Le langage et la plateforme changent vite. Solidity sort plusieurs versions par an. La mise à jour Pectra de 2025 permet à un compte classique de déléguer son exécution à un contrat (EIP-7702), ce qui rend caducs d'anciens contrôles sur tx.origin. OpenZeppelin Contracts 5 a changé la façon de ranger le stockage des contrats évolutifs. Le PDF contient 30 questions sur six axes et un cas de 20 minutes.
L'outillage d'un développeur Solidity sur EVM
Solidity et l'EVM
Le langage principal des contrats sur Ethereum et les chaînes compatibles EVM, dans sa branche 0.8 depuis fin 2020. Depuis la 0.8, un dépassement d'entier fait échouer la transaction, sauf dans un bloc unchecked. Le développeur doit savoir ce que l'EVM fait de son code : stockage, mémoire, calldata, appels entre contrats.
Foundry
Une boîte à outils écrite en Rust. forge compile et teste en Solidity, avec fuzzing et tests d'invariants, anvil lance une chaîne locale et cast interroge un contrat déployé. Les tests sur une copie du réseau principal (fork) font tourner le contrat contre les vrais protocoles qu'il appelle.
Hardhat
L'autre environnement courant, en TypeScript. Hardhat 3 ajoute des tests écrits en Solidity, au format de Foundry, et la simulation de plusieurs types de réseaux. Des projets plus anciens tournent encore sous Hardhat 2, avec ethers.js ou viem pour les scripts.
OpenZeppelin Contracts
La bibliothèque de référence pour les jetons (ERC-20, ERC-721, ERC-1155, ERC-4626), le contrôle d'accès, les proxys et les signatures. La version 5 a modifié plusieurs API et range le stockage des contrats évolutifs dans des espaces de noms (ERC-7201). Un candidat qui réécrit un ERC-20 à la main sans raison mérite une question de plus.
Proxys et contrats évolutifs
Un contrat déployé ne change plus, sauf à passer par un proxy qui délègue l'exécution (delegatecall) à une implémentation remplaçable. Les modèles courants sont le proxy transparent, l'UUPS et le beacon. Les risques portent sur la disposition du stockage entre versions, l'initialisation et la personne qui détient le droit de mise à jour.
Layers 2 et chaînes EVM
Arbitrum, Optimism, Base, zkSync, Polygon et les chaînes privées comme Besu exécutent du code EVM avec des écarts : coût des données, valeur de block.number, opcodes pris en charge, délai de retrait vers Ethereum. Demandez sur quelles chaînes la personne a déployé et ce qu'elle a dû adapter.
Analyse et audit
Slither pour l'analyse statique, Echidna ou Medusa pour le fuzzing par propriétés, Certora ou Halmos pour la vérification formelle des contrats les plus sensibles. Un projet qui garde des fonds passe par un audit externe avant le déploiement, souvent suivi d'un programme de bug bounty.
Oracles, signatures et portefeuilles
Les contrats lisent des prix par des oracles comme Chainlink, vérifient des signatures EIP-712 et des autorisations ERC-2612 (permit), et sont appelés par des portefeuilles via ethers.js ou viem. Chacun de ces points a ses failles connues : prix périmé, signature rejouée, jeton au comportement non standard.
Le poste porte plusieurs intitulés : développeur Solidity, smart contract engineer, développeur blockchain ou Web3. Il peut se limiter aux contrats ou aller jusqu'au back-end qui indexe les événements et au front qui branche les portefeuilles. Certains postes visent des chaînes publiques, d'autres des réseaux permissionnés compatibles EVM (Hyperledger Besu, Quorum), où la gestion des droits et de la gouvernance pèse plus que le coût du gas. Un dépôt GitHub, des contrats vérifiés sur un explorateur ou un rapport d'audit commenté en entretien en disent plus que la liste des chaînes citées sur le CV.
Ce que l'entretien doit établir chez un développeur Solidity
- Langage Solidity et fonctionnement de l'EVM
- Sécurité des contrats
- Optimisation du gas
- Standards de jetons et OpenZeppelin
- Contrats évolutifs et déploiement
- Tests, fuzzing et audit
Cinq questions pour un développeur Solidity qui a déjà déployé
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 · junior à confirmé
Votre fonction de retrait envoie l'ETH à l'utilisateur, puis remet son solde à zéro. Qu'est-ce qui ne va pas ?
Une bonne réponseUne réentrance : le contrat appelé peut rappeler la fonction de retrait pendant l'envoi, avant la remise à zéro, et vider le contrat. La correction suit l'ordre vérifications, effets, interactions (checks-effects-interactions) : solde remis à zéro avant l'appel externe, plus un verrou nonReentrant d'OpenZeppelin, en version transitoire (ReentrancyGuardTransient) sur les chaînes qui prennent en charge EIP-1153. Les bons profils citent aussi la réentrance entre fonctions et la réentrance en lecture, qui touchent des contrats protégés sur une seule fonction.
Signal d'alerte« J'utilise transfer, qui limite le gas à 2 300 » comme seule protection, alors que cette limite casse les portefeuilles multisig et que le coût des opcodes peut changer. Ou ne pas voir le problème.
Question 2 · confirmé
Vous ajoutez une variable à la version 2 d'un contrat placé derrière un proxy. Qu'est-ce qui peut casser ?
Une bonne réponseLa disposition du stockage. L'implémentation s'exécute dans le stockage du proxy, donc insérer, supprimer ou réordonner une variable décale les emplacements et corrompt les données existantes. La nouvelle variable va après les autres, ou dans un espace de noms ERC-7201 comme le fait OpenZeppelin 5. La personne vérifie avec le plugin de mise à jour d'OpenZeppelin, qui compare les deux dispositions, et parle de l'initialiseur de la v2 (reinitializer) et de _disableInitializers dans le constructeur de l'implémentation.
Signal d'alerte« On redéploie et on migre » sans savoir où vivent les données, ou une variable ajoutée au milieu de la chaîne d'héritage.
Question 3 · confirmé
Votre contrat lit un prix Chainlink pour calculer un prêt. Que vérifiez-vous avant d'utiliser la valeur ?
Une bonne réponseQue le prix est positif, que la date de mise à jour (updatedAt) n'est pas trop ancienne au regard de la fréquence du flux, et le nombre de décimales du flux. Sur un layer 2, l'état du séquenceur avec le flux Sequencer Uptime de Chainlink, et un délai de grâce après sa reprise. La personne refuse un prix calculé à partir des réserves d'un pool à l'instant de la transaction, manipulable par un prêt éclair (flash loan).
Signal d'alertelatestRoundData utilisé sans aucun contrôle, ou le prix au comptant d'un DEX pris comme source.
Question 4 · confirmé
Une fonction coûte trop cher en gas. Où cherchez-vous en premier ?
Une bonne réponseDans les accès au stockage, qui pèsent le plus : lectures répétées d'une même variable à mettre en cache en mémoire, écritures inutiles, variables mal rangées qui occupent plusieurs emplacements au lieu d'un. Puis constant et immutable pour les valeurs fixes, calldata plutôt que memory pour les paramètres en lecture seule, erreurs personnalisées à la place des messages de require, et suppression des boucles sans borne. Il mesure avec forge snapshot ou le rapport de gas avant et après chaque changement.
Signal d'alerteDe l'assembleur dès le départ, sans mesure, au prix de la lisibilité et de la sécurité. Ou aucune idée de ce qui coûte cher.
Question 5 · confirmé à senior
Comment testez-vous un contrat de coffre qui reçoit les dépôts de centaines d'utilisateurs ?
Une bonne réponseDes tests unitaires par fonction, cas d'erreur compris, puis du fuzzing sur les entrées et surtout des tests d'invariants avec Foundry : la somme des soldes égale les actifs détenus, personne ne retire plus qu'il n'a déposé, la valeur d'une part ne baisse pas après un dépôt. Des tests sur un fork du réseau pour les intégrations réelles, Slither dans la CI, et un taux de couverture lu avec recul.
Signal d'alerteQuelques tests du chemin nominal avec une seule adresse, ou « l'audit trouvera les bugs ».
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
Recruter un développeur Solidity, en quelques réponses
Faut-il exiger une expérience sur le réseau principal ?
Pour un poste qui déploie des contrats gardant des fonds, oui, ou au moins une contribution à un projet audité. Un développeur qui n'a travaillé que sur testnet connaît la syntaxe, rarement la pression d'un déploiement irréversible, la gestion des clés et la lecture d'un rapport d'audit. Demandez l'adresse d'un contrat vérifié sur un explorateur et faites expliquer une de ses fonctions. C'est rapide et difficile à improviser.
Développeur Solidity ou auditeur de smart contracts : quelle différence ?
Le développeur conçoit, écrit et teste les contrats, puis les déploie et les fait évoluer. L'auditeur relit le code d'autres équipes pour y trouver des failles, en missions courtes ou dans des concours d'audit publics. Les deux partagent la culture de la sécurité. Un bon développeur sait lire un rapport d'audit et corriger, alors qu'un auditeur n'a pas toujours mené un projet jusqu'à la production.
Comment organiser le test technique d'un développeur Solidity ?
Un exercice de revue fonctionne bien : un contrat de 80 lignes avec une réentrance, un contrôle d'accès oublié et un oracle non vérifié, à commenter en 30 minutes. Vous voyez ce que la personne repère et comment elle classe les problèmes par gravité. Pour un senior, ajoutez l'écriture d'un test d'invariant Foundry. Un long exercice à faire chez soi ajoute peu à ce que montre cette revue.
Un développeur Rust ou TypeScript peut-il passer sur Solidity ?
La syntaxe s'apprend vite. Le modèle d'exécution demande plus de temps : stockage payant, appels externes qui rendent la main à un code inconnu, aucun correctif possible sans proxy, transactions visibles avant leur inclusion. Un développeur back-end confirmé peut prendre en charge des contrats simples s'il est relu par un profil expérimenté. Pour un poste seul sur des contrats qui gardent des fonds, cherchez une expérience Solidity en production.
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.
