Pour choisir un auditeur de smart contract, vérifiez d'abord qu'il a publié des rapports sur du code comparable au vôtre (même blockchain, même type de projet), qu'il décrit sa méthode, qu'il nomme les personnes qui liront réellement votre code, qu'il précise les conditions du réaudit et qu'il est totalement indépendant de votre développeur. La notoriété et le prix comptent, mais après l'adéquation au projet. Le meilleur auditeur pour un protocole de prêt sur une chaîne EVM n'est pas forcément le meilleur pour un jeton en Move ou un programme Rust sur Solana. Ce guide détaille les critères, les questions à poser et les signaux d'alerte.
Ce qui compte le plus dans le choix d'un auditeur
Le facteur décisif est l'expérience pertinente : un auditeur qui a déjà relu du code proche du vôtre, sur la même chaîne, sait où ce type de code casse habituellement. Un relecteur très à l'aise avec la DeFi en Solidity peut passer à côté de problèmes propres à la validation des comptes sur Solana, et inversement.
Gardez aussi en tête ce qu'est un audit, et ce qu'il n'est pas. C'est une revue experte, limitée dans le temps, d'une version précise de votre code. Elle réduit le risque et le documente. Elle ne garantit pas l'absence de bugs. Bien choisir, c'est donc retenir les relecteurs les plus susceptibles de trouver l'essentiel dans le temps que vous payez, avec un rapport exploitable.
C'est pourquoi les classements des « meilleurs auditeurs de smart contracts » sont d'une utilité limitée. Une bonne présélection est propre à votre projet : trois à cinq auditeurs dont les travaux passés correspondent à votre langage, à votre type de projet et à votre taille de code.
Les critères à vérifier
Évaluez chaque candidat sur les mêmes sept critères, et demandez des preuves plutôt que des affirmations.
1. Des rapports publics pertinents
Demandez deux ou trois rapports publics portant sur des projets comparables : même chaîne ou même langage, même type de projet (jeton, NFT, staking, DeFi, bridge, tokenisation), taille similaire. Lisez-les. Un bon rapport précise le périmètre, décrit chaque constat clairement, en évalue la gravité, propose une correction et indique si celle-ci a été vérifiée. Une longue liste de remarques informatives et peu de constats de fond n'est pas, à elle seule, un gage de qualité.
2. La méthode
Un auditeur sérieux sait expliquer comment il travaille : relecture manuelle ligne à ligne, modélisation des menaces sur la logique économique du protocole, outils automatiques comme l'analyse statique et, selon les cas, fuzzing (tests par entrées aléatoires massives), tests d'invariants ou vérification formelle. Demandez ce qui est manuel et ce qui est automatisé. Les outils sont utiles, mais ils ne remplacent pas un relecteur qui comprend votre logique métier.
3. L'équipe qui relit vraiment
Demandez le nom et le parcours des personnes qui liront votre code, et le nombre de jours que chacune y consacrera. Certaines structures vendent sous le nom d'un profil senior puis confient le travail à des juniors. Deux relecteurs travaillant séparément trouvent généralement plus de choses qu'un seul relecteur pendant deux fois plus longtemps.
4. La disponibilité et le calendrier
Faites confirmer la date de démarrage, la durée et la date de remise du rapport. Beaucoup d'auditeurs sont réservés plusieurs semaines à l'avance. Le modèle indicatif du site applique une majoration d'urgence (x1,25 pour démarrer sous deux semaines, x1,5 sous une semaine) : anticiper fait souvent gagner de l'argent, et du calme.
5. Les conditions du réaudit
Le réaudit est la vérification, par l'auditeur, des corrections apportées par votre développeur. Demandez s'il est inclus, combien de tours sont prévus, dans quel délai, et ce qui se passe si les corrections introduisent du code nouveau. Dans le modèle indicatif du site, un réaudit non inclus représente environ 20 % du prix du premier audit.
6. Le format du rapport et l'échelle de gravité
Demandez un rapport type et l'échelle de gravité utilisée (par exemple critique, élevée, moyenne, faible, informative), avec la définition de chaque niveau. Il vous faut des constats que votre développeur peut reproduire, idéalement avec une preuve de concept, et un rapport final qui cite le commit exact relu.
7. L'indépendance vis-à-vis du développeur
L'auditeur ne doit avoir aucun intérêt dans le code : pas de travaux de développement sur le même projet, pas de capital commun avec le développeur, pas de commission versée par celui-ci. Un auditeur qui relit le code de sa propre équipe, ou d'un partenaire, est en conflit d'intérêts manifeste. Ce point est traité en détail dans le guide sur l'indépendance entre développeur et auditeur.
Les questions à poser avant de signer
Envoyez les mêmes questions écrites à tous les candidats, pour obtenir des réponses comparables.
- Quels rapports publics sont les plus proches de notre projet, et qu'y avez-vous trouvé ?
- Qui relira précisément le code, et combien de jours chaque personne y passera-t-elle ?
- Quelle est votre méthode, et quelles parties sont manuelles ?
- De quoi avez-vous besoin avant le démarrage (commit figé, documentation, tests, scripts de déploiement) ?
- Quel est le périmètre exact : quels fichiers, quel commit, qu'est-ce qui est exclu ?
- Le réaudit est-il inclus ? Combien de tours, et dans quel délai ?
- Quelle échelle de gravité utilisez-vous, et pouvons-nous voir un rapport type ?
- Le rapport final sera-t-il public, et pouvons-nous le publier nous-mêmes ?
- Avez-vous, ou avez-vous eu, une relation avec notre développeur ?
- Comment communiquez-vous pendant la revue, et comment les constats critiques nous sont-ils signalés ?
Des réponses claires et précises sont bon signe. Des réponses floues sur le périmètre, l'équipe ou le réaudit annoncent en général des désaccords plus tard.
Les signaux d'alerte
Certains signaux justifient de retirer un candidat de votre liste.
- Aucun rapport public, ou des rapports impossibles à rattacher à des revues réelles.
- Un prix forfaitaire donné sans avoir vu le code, ni même mesuré sa taille. L'effort dépend du nombre de lignes, du langage et de la complexité.
- Une durée sans rapport avec le périmètre : quelques jours pour un code DeFi volumineux doivent vous interroger.
- Des relecteurs anonymes, ou le refus de dire qui fera le travail.
- Des promesses de sécurité, du type « zéro bug » ou « sécurité garantie ». Aucun auditeur honnête ne les fait.
- Un rapport sans référence de commit, qui empêche de savoir ce qui a réellement été relu.
- Un lien quelconque avec le développeur : même groupe, partage de revenus, ou proposition « d'auditer ce que nous avons construit ».
- Une pression pour sauter la préparation, par exemple démarrer avant le gel du code.
Un signal isolé n'est pas toujours rédhibitoire, mais il mérite une question directe et une réponse écrite.
Auditeurs indépendants, cabinets, concours d'audit et bug bounties
Ces options sont complémentaires, pas interchangeables : chacune répond à un besoin différent, à un moment différent.
| Option | Ce que vous obtenez | Pour quel besoin | Limites |
|---|---|---|---|
| Auditeur indépendant ou petite structure | Un à quelques relecteurs seniors, contact direct | Périmètres petits à moyens, budgets serrés, chaînes spécialisées | Capacité limitée, peu de relecteurs en parallèle |
| Cabinet d'audit établi | Plusieurs relecteurs, contrôle qualité interne, rapport reconnu | Protocoles importants ou à forte valeur, exigences d'investisseurs ou de plateformes | Prix plus élevé, délai de réservation plus long |
| Concours d'audit | De nombreux relecteurs en parallèle sur une période fixe | Couverture complémentaire après un audit privé | Qualité variable, tri important, peu de dialogue |
| Bug bounty | Récompense permanente pour signaler des failles après le lancement | Code déployé, protection continue | Ne remplace pas la revue du code avant déploiement |
Dans le modèle indicatif du site, les auditeurs indépendants et les petites structures facturent en général 800 à 1 400 EUR par jour-auditeur et couvrent environ 350 nSLOC par jour, tandis que les cabinets établis facturent 1 800 à 3 500 EUR et couvrent environ 250 nSLOC par jour, avec une revue plus approfondie. Pour un code DeFi de 1 500 nSLOC en Solidity, cela donne des fourchettes indicatives de 4 800 à 8 400 EUR (indépendant) et de 15 000 à 30 000 EUR (cabinet établi). Les devis réels dépendent de votre périmètre, et vous pouvez estimer le vôtre avec le calculateur de coût d'audit.
Pour un protocole d'une certaine taille, un enchaînement courant consiste à faire un audit privé, les corrections et le réaudit, puis éventuellement un concours d'audit pour élargir la couverture, et un bug bounty dès le lancement. Un simple jeton peut se contenter d'une revue indépendante. L'essentiel est que chaque étape soit choisie pour une raison, et non empilée pour l'affichage.
Faire le choix final
Comparez les auditeurs présélectionnés sur la même base : même périmètre, même commit, mêmes questions. Pesez ensuite l'expérience pertinente et la qualité des rapports types en premier, l'équipe nommée et la méthode en second, le prix et la disponibilité en troisième.
Si deux candidats sont proches, un court échange avec le relecteur principal est souvent décisif : un bon relecteur pose vite des questions précises sur votre architecture, vos hypothèses et votre modèle de menaces. Des plateformes comme smart-contract.com appliquent l'indépendance dans leur base de données, si bien qu'une société engagée pour développer votre projet ne peut pas être invitée à l'auditer, mais vérifiez ce point vous-même, quel que soit le canal utilisé.
Enfin, mettez les termes essentiels par écrit : périmètre et commit, relecteurs, dates, livrables, échelle de gravité, tours de réaudit et droits de publication.
À retenir
- Choisissez d'abord sur l'adéquation : des rapports publics sur la même chaîne et le même type de projet pèsent plus que la notoriété générale.
- Demandez qui relira réellement le code, pendant combien de jours, avec quelle méthode, et obtenez les réponses par écrit.
- Clarifiez les conditions du réaudit et le format du rapport, y compris l'échelle de gravité et la référence du commit, avant de signer.
- Considérez tout lien entre l'auditeur et le développeur comme éliminatoire : l'indépendance est une condition, pas un bonus.
- Audit privé, concours d'audit et bug bounty sont complémentaires, et aucun ne garantit l'absence de bugs.