Développeur Solidity : si l'audit a validé votre code, qui paie après l'exploit ?

Dans l'écosystème Web3, le rapport d'audit est devenu un sésame commercial. Un protocole ne déploie pas sans le logo d'un cabinet reconnu sur sa documentation, et beaucoup de développeurs en tirent une conclusion confortable : « si l'audit a validé mon code, je suis couvert ». C'est une erreur de raisonnement qui peut coûter cher le jour où un exploit survient.

Un audit de smart contract est, juridiquement, une prestation intellectuelle distincte de la vôtre. L'auditeur examine un code qui existe déjà — le vôtre — et émet un avis. Cet avis ne réécrit pas l'histoire : c'est vous qui avez introduit la faille de réentrance, l'erreur d'access control ou l'overflow. Le fait qu'un tiers ne l'ait pas détectée ne fait pas disparaître votre faute d'origine. Elle crée simplement une seconde responsabilité possible, à côté de la vôtre.

La nuance est capitale. Quand un protocole subit un drainage de fonds et cherche à récupérer ses pertes, il actionne en général tous les intervenants techniques : développeur, auditeur, parfois l'équipe de déploiement. À vous de démontrer, à ce moment, où s'arrête votre part.

Pour comprendre comment un juge — ou un arbitre, car ces missions sont souvent régies par des clauses d'arbitrage internationales — répartit la charge, il faut revenir à une distinction de droit civil français : l'obligation de moyens contre l'obligation de résultat.

Le développeur Solidity, comme l'auditeur, est presque toujours tenu d'une obligation de moyens. Vous ne garantissez pas un code mathématiquement inviolable — personne ne peut le faire dans un domaine où les techniques d'attaque évoluent en permanence. Vous vous engagez à mettre en œuvre la diligence, les outils et l'état de l'art attendus d'un professionnel compétent : tests unitaires, fuzzing, respect des checks-effects-interactions, revue des patterns connus.

Cette qualification a une conséquence directe : le client doit prouver votre faute, c'est-à-dire un écart par rapport à ce qu'un développeur diligent aurait fait. Si la faille exploitée relevait d'une classe de vulnérabilité connue et documentée que tout professionnel sérieux teste, votre faute sera retenue facilement. Si elle relevait d'un vecteur d'attaque inédit, apparu après votre livraison, votre position défensive est bien plus solide.

L'audit ne change pas la nature de votre obligation : il ajoute un second débiteur d'une obligation de moyens. Deux professionnels peuvent avoir manqué de diligence sur la même faille — ou un seul, ou aucun.

Quand l'exploit est consommé et que la réclamation arrive, la répartition entre vous et l'auditeur se cristallise autour de trois questions factuelles. Anticipez-les dès la mission, car les réponses se construisent avant le sinistre.

1. La faille était-elle dans le périmètre audité ? Les rapports d'audit délimitent précisément un commit, des fichiers, parfois des fonctions. Si la faille exploitée était hors périmètre — par exemple un module ajouté après la revue, ou une dépendance non auditée — l'auditeur s'exonère, et la charge revient vers vous.
2. L'auditeur a-t-il signalé le risque ? Un rapport qui classe une observation en « informational » ou « low » sur un point qui se révèle critique pose la question de la diligence de l'auditeur. Mais s'il a remonté la faille et que vous ne l'avez pas corrigée, la responsabilité bascule massivement vers vous.
3. Qu'avez-vous fait de la remédiation ? La phase de correction post-audit est le moment où les responsabilités se figent. Avoir corrigé, puis fait revalider, déplace la charge. Avoir ignoré un point « medium » par manque de temps vous expose frontalement.

Vous le voyez : dans la majorité des dossiers, la question n'est pas « audit ou pas audit », mais « qu'ont fait, et qu'ont écrit, chacun des intervenants à chaque étape ».

Beaucoup de freelances pensent que l'existence d'un audit déplace le risque assurantiel vers le cabinet. En réalité, votre assurance RC Pro reste votre bouclier de première ligne, pour une raison simple : le protocole vous assigne vous, et c'est à votre assureur de prendre en charge votre défense, puis d'exercer éventuellement un recours contre l'auditeur si sa part est établie.

Concrètement, la RC Pro intervient sur deux fronts dans ce scénario :

• Les frais de défense. Même si vous estimez la faute partagée, vous devez vous défendre — produire les commits, démontrer votre diligence, faire valoir le périmètre. Ces frais d'expertise et d'avocat, souvent lourds dans un litige technique international, sont pris en charge.
• L'indemnisation de la part qui vous est imputée. Si la décision retient 60 % de responsabilité à votre charge et 40 % à l'auditeur, c'est votre RC Pro qui couvre vos 60 % (dans la limite du plafond), à charge pour elle de se retourner ensuite.

Le tableau ci-dessous résume comment s'articulent les rôles selon les scénarios les plus fréquents :

Puisque tout se joue sur des éléments factuels documentés en amont, votre meilleure protection est méthodologique. Quelques réflexes simples réduisent fortement votre exposition au moment où le client cherchera un responsable.

1. Délimitez votre livrable par écrit. Indiquez le commit livré, les contrats concernés, et précisez que tout ajout ultérieur sort de votre périmètre de responsabilité.
2. Conservez la trace de la remédiation. Archivez le rapport d'audit, vos correctifs, et la confirmation de revalidation. Ce sont ces échanges qui prouveront, le cas échéant, que la faille relevait de l'auditeur et non de vous.
3. N'endossez jamais le résultat de l'audit. Si le client veut une garantie « code audité = code sûr », refusez cette formulation : vous transformeriez votre obligation de moyens en obligation de résultat impossible à tenir.
4. Calibrez votre plafond sur les montants en jeu. Un protocole DeFi gère parfois plusieurs millions en TVL. Un plafond de 500 K€ peut être insuffisant face à une class action d'utilisateurs.

Pour comprendre comment ces garanties s'articulent et quel plafond correspond à vos missions, notre page assurance développeur Solidity détaille la couverture RC Pro adaptée au développement de smart contracts. L'audit est un filet de sécurité technique : il ne remplace ni votre rigueur, ni votre couverture.