Recruter un développeur Solidity : le brief avant l’audit
EN 30 SECONDES
Un brief Solidity prêt pour l’audit est un court document qui précise ce que vos smart contracts détiennent, qui les contrôle et ce qui doit être livré avant une revue externe. Sans lui, un code qui compile peut laisser ouverts les points à risque.
À RETENIR
- Jugez un développeur Solidity sur sa façon de concevoir les permissions, de tester les comportements interdits et d’assumer le déploiement, pas sur le seul nombre de contrats écrits.
- Avant de demander un devis, précisez quels actifs circulent, qui peut agir sur eux et qui peut mettre à jour les contrats.
- La préparation à l’audit, la revue indépendante et les vérifications de déploiement sont des livrables distincts. Prêt pour l’audit ne veut jamais dire audité.
Sur cette page
Le problème : recruter pour le contrat, pas pour le système
EN BREF Un code qui compile ne dit presque rien de sa sûreté. La question difficile, c’est qui peut déplacer les actifs.
J’ai travaillé sur des tokens à permissions chez Tokeny. Puis j’ai dirigé l’ingénierie blockchain chez Biconomy, notamment sur les smart accounts modulaires. Je suis aussi l’un des auteurs nommés d’ERC-3643.
Ce parcours change la première question que je poserais à un candidat Solidity. Avant d’aborder les frais de gas, je voudrais savoir trois choses. Qui peut déplacer un actif ? Qui peut changer ce pouvoir ? Et comment l’équipe repérera-t-elle une erreur ?
Pour recruter un développeur Solidity, jugez tout le travail, pas seulement le code. Autrement dit : la conception de chaque Smart contract Un programme déployé sur une blockchain, qui peut détenir ou déplacer des actifs selon des règles fixes. Son comportement ne change plus, sauf s’il a été conçu pour. Voir le glossaire, qui détient quel pouvoir, les tests qui tentent de casser les règles, la préparation de l’audit et le déploiement.
Compter les contrats
Des preuves sur le code et sur le système
Les mots à connaître
EN BREF Un bon brief fixe qui détient quelle clé avant la première ligne de code, un peu comme le plan des clés d’un immeuble.
LES MOTS À CONNAÎTRE
- Smart contract
- Un programme déployé sur une blockchain, qui peut détenir ou déplacer des actifs selon des règles fixes. Son comportement ne change plus, sauf s’il a été conçu pour.
- Modèle de permissions
- La liste écrite de qui peut faire quoi (mettre en pause, mettre à jour, déplacer des actifs) et de qui peut accorder ou retirer ces pouvoirs.
- Invariant
- Une propriété qui doit rester vraie quoi que fassent les utilisateurs, par exemple « ce que le contrat doit aux utilisateurs ne dépasse jamais ce qu’il détient ».
- Droit de mise à jour
- Le compte ou le groupe autorisé à faire passer un contrat sur un nouveau code après son lancement, quand il a été conçu pour le permettre.
- Audit indépendant
- Une revue de sécurité d’une version figée du code, menée par des personnes qui n’ont pas écrit ce code.
- Prêt pour l’audit
- Un code et des documents sur lesquels un relecteur peut travailler sans deviner : version figée, conception, tests, plan de déploiement. Ça ne veut pas dire audité.
Décrire les flux d’actifs et les pouvoirs
EN BREF Écrivez le modèle de permissions avant la liste des fonctionnalités : c’est lui qui dit qui peut déplacer, mettre en pause ou modifier.
« Faites-nous un token » laisse presque tout dans le flou. Peut-on le mettre en pause ? Le mettre à jour ? Le récupérer ? Un opérateur peut-il le déplacer ? De quels pouvoirs le produit a-t-il besoin ? Votre Modèle de permissions La liste écrite de qui peut faire quoi (mettre en pause, mettre à jour, déplacer des actifs) et de qui peut accorder ou retirer ces pouvoirs. Voir le glossaire y répond par écrit.
La doc d’OpenZeppelin sur le contrôle d’accès couvre les propriétaires et les rôles. Mais quels rôles prévoir, et qui les gère, reste un choix. Le produit et la technique le font ensemble.
Pour les tokens à permissions, ERC-3643 définit des contrôles d’identité et de conformité sur les transferts. Voyez-les comme des briques. Un responsable juridique ou conformité doit fixer les règles réelles du produit. Le standard n’est pas, en soi, une validation juridique.
Quatre questions pour l’entretien technique
EN BREF Donnez un petit extrait de code pertinent et demandez au candidat de commenter les modifications qu’il y ferait.
On en apprend plus qu’avec un test de vocabulaire. Un développeur senior peut aussi expliquer ses compromis. Et personne n’a à montrer le code d’un client.
La première ligne parle de réentrance. C’est quand un autre contrat rappelle le vôtre avant la fin de votre premier appel. Le danger vient quand vos données ne sont pas encore à jour. La doc Solidity la décrit, avec le motif checks-effects-interactions.
La doc de Foundry explique les tests d’invariants sur des suites d’appels aléatoires. Ce sont de bons repères pour l’entretien. Aucun ne prouve qu’un contrat donné est sûr.
Un Invariant Une propriété qui doit rester vraie quoi que fassent les utilisateurs, par exemple « ce que le contrat doit aux utilisateurs ne dépasse jamais ce qu’il détient ». Voir le glossaire ne se vérifie que sur les cas que le banc de test sait atteindre. Demandez donc ce que le test pourrait rater. Un bon candidat cite des états hors de portée, un comportement de token non modélisé ou un service externe. Cette réponse vaut plus qu’un taux de couverture à lui seul.
Ça vous en dit plus qu’un taux de couverture à lui seul.
Un exemple concret : le test qui passait
EN BREF Un test d’invariant au vert peut quand même rater un comportement de token qu’il n’a jamais modélisé.
Le coffre, le token et les montants ci-dessous sont fictifs. Ils montrent la réponse qu’on espère entendre à « que pourrait rater le test ? ».
UN EXEMPLE CONCRET
Chiffres illustratifs
VALIDÉUn coffre de dépôt, testé avec un token simple
ENTRÉE
- Token du test
- token ERC-20 de test simple (un mock)
- Invariant
- tokens détenus ≥ dépôts enregistrés
- Dépôt d’Alice
- 100
CE QUI SE PASSE
- L’outil de test (un fuzzer) enchaîne des dépôts et des retraits au hasard.
- Après chaque appel, le test compare le solde du coffre à ses registres.
- Détenu 100, enregistré 100 : l’invariant tient.
SORTIE
- Invariant
- respecté
- Test
- passe
NON DÉTECTÉMême test, mais le token réel prélève 1 % à chaque transfert
ENTRÉE
- Token en production
- token à frais de transfert
- Dépôt d’Alice
- 100
CE QUI SE PASSE
- Le coffre enregistre 100 mais reçoit 99 après les frais.
- Le test passe toujours : il n’a utilisé que le mock simple.
- Alice demande à retirer 100. Le coffre détient 99, donc l’appel échoue (il est annulé).
SORTIE
- Invariant
- violé en production
- Correction
- compter ce que le coffre reçoit réellement, ou refuser ce type de token
Ce que contient une livraison prête pour l’audit, étape par étape
EN BREF Prêt pour l’audit veut dire qu’un relecteur peut commencer sans deviner. Ça ne veut pas dire audité, et encore moins exempt de failles.
Inscrivez la liste exacte des livrables Prêt pour l’audit Un code et des documents sur lesquels un relecteur peut travailler sans deviner : version figée, conception, tests, plan de déploiement. Ça ne veut pas dire audité. Voir le glossaire dans le contrat de prestation. Les deux parties sauront alors quand la préparation est finie.
ÉTAPE PAR ÉTAPE
Étape 1 sur 6. Figer le périmètre. Notez le commit du dépôt (la version exacte enregistrée du code), les contrats concernés, les versions du compilateur et des dépendances, les commandes de build et les exclusions connues.
- Figer le périmètre Notez le commit du dépôt (la version exacte enregistrée du code), les contrats concernés, les versions du compilateur et des dépendances, les commandes de build et les exclusions connues.
- Écrire la conception Décrivez le comportement attendu, dessinez les flux d’actifs et ajoutez la matrice des rôles, les hypothèses de confiance et les dépendances externes.
- Tester Tests unitaires, cas de permission refusée, tests de fuzzing ou d’invariants adaptés, et la marche à suivre pour reproduire un échec.
- Planifier mise à jour et déploiement Consignez les arguments d’initialisation, les hypothèses sur le stockage et les transferts d’administration, plus les contrôles par rapport au build relu.
- Remettre au relecteur Transmettez les problèmes connus et vos questions pour l’auditeur. Désignez qui corrige les constats, et tenez la liste des changements à faire relire.
- Après la revue Un changement important après la revue appelle une décision explicite sur une nouvelle revue. Le feu vert au déploiement reste distinct de la réception de la livraison.
Réservez l’Audit indépendant Une revue de sécurité d’une version figée du code, menée par des personnes qui n’ont pas écrit ce code. Voir le glossaire sur un périmètre convenu. Laissez le feu vert au déploiement à l’équipe qui fera tourner le système. Elle doit savoir ce qu’elle autorise.
Un contrat qu’on peut mettre à jour demande un soin particulier autour du Droit de mise à jour Le compte ou le groupe autorisé à faire passer un contrat sur un nouveau code après son lancement, quand il a été conçu pour le permettre. Voir le glossaire. Le guide d’OpenZeppelin sur les mises à jour explique les limites des initialiseurs et les pièges de la disposition du stockage. Demandez au développeur de vous les montrer sur vos propres contrats, migrations et état déjà déployé compris.
Choisir la formule selon la responsabilité qui manque
EN BREF Nommez la responsabilité qui vous manque avant de comparer les propositions.
Un freelance Solidity peut livrer un lot de contrats bien borné. Un senior en poste peut faire vivre un protocole dans la durée. Un auditeur indépendant apporte un regard extérieur.
Pour des smart accounts, précisez les permissions des modules et les intégrations voulues. ERC-7579, encore à l’état de brouillon (Draft), définit des interfaces pour les comptes modulaires. Il ne dit pas ce que peut faire un module donné une fois installé : ça, il faut le vérifier.
Je travaille sur Solidity, les smart accounts et les systèmes de tokenisation. Vous recrutez pour une mission ou un poste en CDI ? Envoyez-moi le contexte du dépôt, la chaîne visée et le périmètre.
Si un agent IA doit appeler ces contrats, le guide pour recruter un ingénieur IA couvre aussi le côté application.
TESTEZ-VOUS
Cas fictif : après l’audit, l’équipe change qui peut attribuer le rôle de pause. La modification tient en dix lignes. L’audit couvre-t-il encore le code déployé ?
Voir la réponse
TESTEZ-VOUS
Vous avez un cahier des charges écrit et une équipe interne qui maintiendra les contrats. Faut-il confier leur écriture à un auditeur ?
Voir la réponse
Ce qu’il faut faire ensuite
- Avant le devis : écrivez le modèle de permissions dans les quatre parties du brief, en soignant surtout qui peut agir sur les actifs.
- En entretien : sur un petit extrait de code, demandez ce que les tests du candidat pourraient rater.
- Dans le contrat : listez les livrables prêts pour l’audit, puis réservez la revue indépendante à part.
ÉTAPE SUIVANTEComparer ERC-3643, ERC-1400 et CMTAT
Questions sur le recrutement d’un développeur Solidity
Demandez du code pertinent ou une démo anonymisée, des tests d’actions interdites, une explication des droits d’administration et une expérience du déploiement. Pour plus de preuves, payez un exercice court et borné. Visez une expérience proche de votre système : smart accounts, tokens à permissions, protocoles de prêt.
Non. Le développement conçoit et construit le système. Un audit indépendant relit une version et un périmètre définis, en général à un commit figé. Les tests et la préparation aident le relecteur. Ils ne remplacent pas cette revue et ne garantissent pas l’absence de failles.
Les contrats visés, les réseaux, les intégrations, le modèle de permissions, les tests, la doc, le déploiement, une enveloppe pour les corrections d’audit et les exclusions. Prix et délai en dépendent. Demandez qui paie la revue indépendante et qui assume les changements une fois le périmètre fixé.
Non. ERC-3643 définit des outils techniques pour les tokens à permissions, comme les contrôles d’identité et de conformité. Il ne dit pas si une émission donnée respecte le droit applicable. Les équipes produit et juridique doivent fixer les règles ; les ingénieurs les codent et les testent.
Adam est prêt à discuter de missions Solidity et de postes d’ingénieur senior. Il a travaillé sur ERC-3643, la tokenisation et les smart accounts modulaires. Pour voir si ça colle, donnez la chaîne visée, l’état du dépôt, le rôle attendu et le calendrier.
Recruter pour la production
Episode 2 · 2 publies
Ancien CTO d'Integra. Auteur nommé (1 sur 5) d'ERC-3643, premier auteur d'ERC-6960, co-auteur d'ERC-7410 et co-auteur d'ERC-8203, encore à l'état de brouillon. Conçoit des systèmes d'IA en production et des systèmes Web3 régulés.
Un projet à livrer ou un poste à pourvoir ?
Parlons de votre besoinSuivre les notes techniques
Recevez les nouveaux articles sur l’IA en production et les smart contracts par email.