Risque lié aux contrats intelligents : code, oracles, gouvernance et clés de mise à niveau

Un tableau de bord peut donner l’impression que le risque lié aux contrats intelligents se résume à un seul événement. En réalité, définir les droits et les invariants, auditer le système déployé, puis intervenir et assurer la gouvernance sont des changements d’état distincts, pris en charge par différents participants. C’est dans ces passages de relais invisibles que s’introduisent le temps, les coûts et les risques.

Le risque lié aux contrats intelligents désigne la possibilité que le code, les dépendances ou la gouvernance produisent un résultat financier différent de celui auquel s’attendent les utilisateurs. La surface d’attaque comprend la logique métier, le contrôle d’accès, les calculs et la comptabilité, les oracles, les jetons, la composabilité, les interfaces, les clés privées, les mises à niveau et les engagements juridiques entourant le code.

Un audit constitue une preuve issue d’un examen défini, et non une garantie. Un code source correct peut être déployé avec des paramètres différents, mis à niveau ultérieurement ou interagir avec un oracle manipulé. Un code immuable ne réduit le risque de modification que si le comportement immuable et les dépendances sont eux-mêmes sûrs.

Pour situer le risque lié aux contrats intelligents dans la couverture plus large de Securities.io, comparez le modèle de référence de la pile DeFi, les entreprises d’audit de contrats intelligents et la sécurité des contrats intelligents et l’IA. Ensemble, ces guides montrent comment la même question concernant l’infrastructure des actifs numériques évolue selon que changent l’émetteur, l’actif, le droit de l’investisseur ou l’infrastructure opérationnelle.

De la définition des droits et des invariants à l’intervention et à la gouvernance : la chaîne de risque des contrats intelligents

La définition des droits et des invariants établit que les soldes, les pouvoirs, les limites et les conditions qui doivent toujours être respectés sont définis. Le résultat devient ensuite une entrée pour la mise en œuvre et les tests, qui s’appuient sur des composants examinés et des tests unitaires, d’intégration, de propriétés et contradictoires. Ce passage de relais est le premier point où mettre à l’épreuve le risque lié aux contrats intelligents : la partie destinataire doit pouvoir distinguer un changement d’état achevé d’un message, d’une estimation ou d’un enregistrement provisoire. Le même test s’applique à chaque flèche suivante, jusqu’à ce que l’intervention et la gouvernance produisent un résultat pouvant être rapproché de manière indépendante.

Remontez le diagramme à partir de l’intervention et de la gouvernance. L’état final doit renvoyer à la spécification, au code source et au bytecode déployés, aux tests et aux audits, aux paramètres et aux rôles d’administration, à la cartographie des oracles et des dépendances, aux événements surveillés, à la réponse aux incidents et à la répartition des pertes ; puis aux pouvoirs mobilisés lors de l’exploitation et de la surveillance, à l’exposition créée lors de l’audit du système déployé, et aux données d’entrée acceptées lors de la définition des droits et des invariants. Si cette chaîne se rompt, un bogue de contrôle d’accès peut donner l’apparence d’une transaction achevée, même lorsqu’un appelant non autorisé obtient le pouvoir de créer des jetons, de retirer des fonds, de mettre en pause ou de mettre à niveau le système. Cette analyse à rebours permet de se concentrer sur l’invariant financier promis et sur chaque dépendance du code, des données et de la gouvernance susceptible de le modifier, plutôt que sur le nom d’un fournisseur ou l’état d’une interface.

Qui contrôle les données essentielles au risque lié aux contrats intelligents ?

Le développeur du protocole et l’auditeur interviennent à des étapes différentes de la chaîne opérationnelle. Le développeur du protocole conçoit et met en œuvre la logique économique et technique, tandis que l’auditeur examine une version dont le périmètre est défini et rend compte de ses conclusions. Leurs dossiers — spécification, code, tests, commits, dépendances et déploiement, d’une part, et périmètre, méthodes, hypothèses, gravité, corrections et risque résiduel, d’autre part — devraient concorder sur un même événement, sans être des copies d’une base de données appartenant à un seul prestataire. L’oracle ou le protocole externe, la gouvernance et les détenteurs des clés, ainsi que l’utilisateur ou l’intégrateur apportent des décisions ou des éléments de preuve distincts ; traiter ces fonctions comme interchangeables masque le point où interviennent le pouvoir discrétionnaire, la liquidité ou la responsabilité juridique.

Une panne touchant la gouvernance et les détenteurs des clés constitue un test concret de la responsabilité dans le domaine des risques liés aux contrats intelligents. Ils peuvent modifier les paramètres, mettre le système en pause, le mettre à niveau ou déplacer des actifs. La question est de savoir si le développeur du protocole et l’auditeur peuvent encore reconstituer la situation à partir des rôles, du quorum, du délai de verrouillage, des votes, de la garde des clés et de l’historique des événements. Les contrats peuvent répartir les tâches, mais la partie qui assume l’engagement envers le client, l’actif ou l’obligation ne peut remplacer des preuves par une clause de sous-traitance. Une conception résiliente désigne le dossier de secours et la personne habilitée à résoudre toute divergence.

Comment les risques liés aux contrats intelligents évoluent concrètement

1. Définir les droits et les invariants : établir l’état initial des risques liés aux contrats intelligents

Définissez les soldes, les pouvoirs, les limites et les conditions qui doivent toujours être respectés. Dans cette partie consacrée aux risques liés aux contrats intelligents, cette étape établit les conditions sur lesquelles la mise en œuvre et les tests peuvent s’appuyer. Le développeur du protocole joue un rôle central, car il conçoit et met en œuvre la logique économique et technique. Le dossier de travail devrait conserver la spécification, le code, les tests, les commits, les dépendances et le déploiement.

La défaillance à rechercher à cette étape est une faille de contrôle d’accès : un appelant non autorisé obtient le pouvoir de créer des jetons, de retirer des fonds, de mettre le système en pause ou de le mettre à niveau. Pour tester cette étape, consignez le résultat en vous fondant sur le même moment, le même périmètre et les mêmes conditions applicables, puis modifiez une hypothèse avant la mise en œuvre et les tests. Pour les risques liés aux contrats intelligents, un transfert de responsabilité défendable précise qui a approuvé l’opération, quel dossier a été modifié, ce qui peut encore être annulé et qui assume la perte si le participant suivant rejette les éléments de preuve.

2. Mettre en œuvre et tester : déterminer la règle de décision pour les risques liés aux contrats intelligents

Utilisez des composants vérifiés ainsi que des tests unitaires, d’intégration, de propriétés et adversariaux. Dans cette partie consacrée aux risques liés aux contrats intelligents, cette étape vérifie les conditions sur lesquelles l’audit du système déployé peut s’appuyer. L’auditeur joue un rôle central, car il examine une version dont le périmètre est défini et rend compte de ses conclusions. Le dossier de travail devrait conserver le périmètre, les méthodes, les hypothèses, la gravité, les corrections et le risque résiduel.

La défaillance à rechercher à cette étape est une exploitation comptable : les arrondis, la réentrance, la tarification des parts ou l’ordre des opérations sur l’état créent de la valeur à partir de rien. Pour tester cette étape, recalculez le résultat en vous fondant sur le même moment, le même périmètre et les mêmes conditions applicables, puis modifiez une hypothèse avant l’audit du système déployé. Pour les risques liés aux contrats intelligents, un transfert de responsabilité défendable précise qui a approuvé l’opération, quel dossier a été modifié, ce qui peut encore être annulé et qui assume la perte si le participant suivant rejette les éléments de preuve.

3. Auditer le système déployé : mesurer le transfert des risques liés aux contrats intelligents

Vérifiez le code source, le bytecode, les paramètres, les dépendances, les clés et les contrôles opérationnels. Dans cette partie consacrée aux risques liés aux contrats intelligents, cette étape réattribue les conditions sur lesquelles les activités d’exploitation et de surveillance peuvent s’appuyer. L’oracle ou le protocole externe joue un rôle central, car il fournit des prix, des messages, des jetons ou des liquidités. Le dossier de travail devrait conserver les sources, les mises à jour, les mesures de résistance à la manipulation, les renseignements sur l’administration et les incidents.

La défaillance à rechercher à cette étape est une manipulation de l’oracle : un prix temporaire ou provenant d’un marché peu liquide détermine les emprunts, les échanges ou les liquidations. Pour tester cette étape, soumettez le résultat à des scénarios de tension en vous fondant sur le même moment, le même périmètre et les mêmes conditions applicables, puis modifiez une hypothèse avant l’exploitation et la surveillance. Pour les risques liés aux contrats intelligents, un transfert de responsabilité défendable précise qui a approuvé l’opération, quel dossier a été modifié, ce qui peut encore être annulé et qui assume la perte si le participant suivant rejette les éléments de preuve.

4. Exploiter et surveiller : rapprocher le registre faisant autorité pour les risques liés aux contrats intelligents

Surveillez la valeur, les anomalies, les oracles, les actions privilégiées et les changements apportés aux dépendances. Dans cette partie consacrée aux risques liés aux contrats intelligents, cette étape rapproche les conditions sur lesquelles les activités de réponse et de gouvernance peuvent s’appuyer. La gouvernance et les détenteurs des clés jouent un rôle central, car ils peuvent modifier les paramètres, mettre le système en pause, le mettre à niveau ou déplacer des actifs. Le dossier de travail devrait conserver les rôles, le quorum, le délai de verrouillage, les votes, la garde des clés et l’historique des événements.

La défaillance à rechercher à cette étape est une défaillance de dépendance : un jeton, un pont, un pool ou une chaîne ne se comporte pas comme prévu. Pour tester cette étape, comparez le résultat en vous fondant sur le même moment, le même périmètre et les mêmes conditions applicables, puis modifiez une hypothèse avant les activités de réponse et de gouvernance. Pour les risques liés aux contrats intelligents, un transfert de responsabilité défendable précise qui a approuvé l’opération, quel dossier a été modifié, ce qui peut encore être annulé et qui assume la perte si le participant suivant rejette les éléments de preuve.

5. Réagir et gouverner : évaluer le résultat final des risques liés aux contrats intelligents

Suspendre, mettre à niveau, indemniser, migrer ou accepter l’immuabilité sous une autorité déclarée. Dans cette partie du risque lié aux contrats intelligents, cette étape clôt les conditions sur lesquelles le résultat consigné peut s’appuyer. L’utilisateur ou l’intégrateur est au cœur du processus, car il accepte l’exposition au code et à ses dépendances. Le dossier de travail doit conserver l’adresse, la version, les autorisations, la simulation de transaction, les limites et les possibilités de sortie.

Le risque qu’il faut contester à ce stade est l’abus de la clé d’urgence : un mécanisme de récupération devient une voie d’attaque ou n’est pas disponible en situation de crise. Pour tester cette étape, vérifiez le résultat en vous fondant sur les mêmes délais, le même périmètre et les mêmes conditions applicables, puis modifiez une hypothèse avant de consigner le résultat. Dans le cas du risque lié aux contrats intelligents, un transfert de responsabilité défendable précise qui l’a approuvé, quel dossier a été modifié, ce qui reste réversible et qui supportera les pertes si le participant suivant rejette les éléments de preuve.

Trois états souvent confondus dans le risque lié aux contrats intelligents

Le risque lié au code signifie que l’implémentation ne respecte pas les invariants prévus ou gère mal un cas limite. Le risque lié aux oracles et à la composition désigne plutôt une situation où un code local correct dépend d’un prix, d’un message, du comportement d’un jeton ou d’un état externe erroné. Le risque lié à la gouvernance et aux mises à niveau ajoute une troisième condition : des acteurs privilégiés peuvent modifier le comportement, les paramètres ou les actifs après l’examen. Ces distinctions sont importantes, car deux utilisateurs peuvent voir une confirmation similaire tout en disposant de droits différents, en étant soumis à des délais différents ou en dépendant d’institutions différentes. Pour évaluer le risque lié aux contrats intelligents, il est utile de préciser, pour chaque état, quel dossier fait autorité et qui supporte les pertes.

Comparez le risque lié au code, le risque lié aux oracles et à la composition, ainsi que le risque lié à la gouvernance et aux mises à niveau selon une même base : montant, durée, liquidités consommées, réversibilité, recours juridique et pertes résiduelles. Dans le cas du risque lié aux contrats intelligents, une qualification plus rapide ne signifie pas automatiquement que l’état est plus définitif, et un rendement déclaré plus régulier ne signifie pas automatiquement que le risque économique est moindre. Utiliser un même cadre de mesure évite de prendre des différences de calendrier ou de comptabilisation pour de véritables améliorations.

Coûts, incitations et effets sur le bilan du risque lié aux contrats intelligents

Les dépenses de sécurité doivent être proportionnelles à la valeur maximale en jeu et à l’irréversibilité, et non au cours du jeton ou à sa visibilité marketing. Les audits, les méthodes formelles, la surveillance et les programmes de primes aux bogues sont des mesures complémentaires dont les champs de couverture diffèrent.

La composabilité crée de la valeur pour le réseau, car les contrats peuvent réutiliser les liquidités et les services. Elle crée aussi des dépendances corrélées : la défaillance d’un seul oracle ou jeton peut se propager à de nombreux protocoles avant que la gouvernance ne réagisse.

La possibilité de mettre à niveau un système permet de corriger les défauts et de s’adapter, mais les utilisateurs paient une prime de risque liée à la gouvernance. Les délais de verrouillage, la diversité des signataires multisignatures, la limitation des rôles, les plafonds et la transparence des événements peuvent réduire cette prime sans prétendre que les administrateurs n’existent pas.

Où le risque lié aux contrats intelligents se manifeste — et quoi tester en premier

• Bogue de contrôle d’accès : Un appelant non autorisé obtient le pouvoir de créer des jetons, de retirer des fonds, de mettre le système en pause ou de le mettre à niveau. Interrompez le processus pour préciser les droits et les invariants, tandis que le développeur du protocole conserve son obligation habituelle, puis vérifiez si le risque lié au code conserve le sens décrit ci-dessus.
• Exploitation comptable : Les arrondis, la réentrance, la fixation du prix des parts ou l’ordre des opérations sur l’état créent de la valeur à partir de rien. Interrompez le processus pour mettre en œuvre les mesures et les tester, tandis que l’auditeur conserve son obligation habituelle, puis vérifiez si le risque lié aux oracles et à la composition conserve le sens décrit ci-dessus.
• Manipulation d’oracle : Un prix temporaire ou associé à une faible liquidité détermine les emprunts, les échanges ou les liquidations. Interrompez l’audit du système déployé, tandis que l’oracle ou le protocole externe conserve son obligation habituelle, puis vérifiez si le risque lié à la gouvernance et aux mises à niveau conserve le sens décrit ci-dessus.
• Défaillance d’une dépendance : un jeton, un pont, un pool ou une chaîne se comporte différemment de ce qui était prévu. Interrompez l’exploitation et la surveillance alors que la gouvernance et les détenteurs des clés continuent d’assumer leurs obligations habituelles, puis vérifiez si le risque lié au code conserve le sens décrit ci-dessus.
• Abus d’une clé d’urgence : un mécanisme de récupération devient un vecteur d’attaque ou est indisponible en cas de crise. Interrompez la réponse et la gouvernance alors que l’utilisateur ou l’intégrateur continue d’assumer ses obligations habituelles, puis vérifiez si les risques liés aux oracles et à la composition conservent le sens décrit ci-dessus.

Pour évaluer utilement les risques liés aux contrats intelligents, il faut combiner une faille de contrôle d’accès et une manipulation d’oracle, plutôt que de les tester séparément. Bloquez ou retardez l’audit du système déployé, rendez la gouvernance et les détenteurs des clés indisponibles, puis demandez à l’utilisateur ou à l’intégrateur de reconstituer le résultat à partir de l’adresse, de la version, des autorisations accordées, de la simulation de transaction, des limites et des possibilités de sortie. La conception n’est satisfaisante que si la réponse et la gouvernance aboutissent à un état unique et explicable, préservent les droits associés aux risques liés aux oracles et à la composition, et attribuent toute perte selon des règles établies avant la perturbation.

Exemple détaillé : suivre de bout en bout un incident lié aux risques des contrats intelligents

Un contrat de prêt a été audité, mais le prix de son collatéral provient d’un seul pool peu liquide. Un attaquant fait temporairement varier le prix dans ce pool, emprunte davantage que la valeur réelle du collatéral, puis se retire avant que l’oracle ne corrige le prix. Le code du contrat de prêt a fonctionné exactement comme prévu ; c’est le système qui a échoué, car les hypothèses relatives à la fiabilité de l’oracle et à la liquidité n’étaient pas sûres. Un examen rigoureux modéliserait l’ensemble du graphe des dépendances et plafonnerait l’exposition au collatéral dont le prix peut être manipulé.

On peut réfuter l’exemple en modifiant l’hypothèse contrôlée lors de l’implémentation et des tests, ou en supprimant les éléments probants fournis par l’oracle ou le protocole externe. Suivez les effets de cette modification tout au long de l’audit du système déployé, de l’exploitation et de la surveillance, puis de la réponse et de la gouvernance ; ne passez pas directement de l’entrée au résultat mis en avant. Si le nouveau résultat concernant les risques liés aux contrats intelligents ne peut pas être reproduit à partir des spécifications, du code source et du bytecode déployés, des tests et audits, des paramètres et des rôles d’administration, de la cartographie des oracles et des dépendances, des événements surveillés, de la réponse aux incidents et de la répartition des pertes, le processus repose sur un jugement ou un document non consigné.

Pourquoi les risques liés aux contrats intelligents sont importants aujourd’hui

La vérification formelle, la surveillance continue, les programmes de récompense pour la découverte de bogues, l’isolation modulaire et l’amélioration de la simulation dans les portefeuilles renforcent la sécurité des contrats intelligents. Dans le même temps, les mandataires évolutifs et les dépendances entre chaînes accroissent les risques de gouvernance. La divulgation la plus utile précise le code déployé, les pouvoirs privilégiés, le parcours de l’oracle, les limites de valeur et le plan de répartition des pertes, dans des termes que les utilisateurs peuvent vérifier.

La leçon durable concernant les risques liés aux contrats intelligents est que définir les droits et les invariants, d’une part, et répondre et gouverner, d’autre part, ne constituent pas le même événement. Les décisions prises entre ces deux étapes déterminent l’invariant financier promis ainsi que chacune des dépendances liées au code, aux données et à la gouvernance susceptibles de le modifier ; le développeur du protocole et l’utilisateur ou l’intégrateur peuvent, quant à eux, avoir accès à différentes parties du dossier. L’automatisation est utile lorsqu’elle facilite la vérification de ces décisions ; elle devient dangereuse lorsqu’elle les réduit à un statut unique qui masque l’abus d’une clé d’urgence.

Les éléments probants relatifs aux risques des contrats intelligents

Les principaux éléments probants relatifs aux risques des contrats intelligents proviennent du Cadre de cybersécurité du NIST, du BIS : risques de la finance décentralisée pour la stabilité financière et du rapport du comité consultatif de la CFTC sur la technologie consacré à la DeFi. Il faut les lire comme des sources complémentaires : règles et définitions, structure institutionnelle ou de marché, et éléments opérationnels nécessaires pour vérifier une affirmation concrète. Aucune ne saurait remplacer les documents sur les produits, les comptes ou les historiques de transactions décrits ci-dessus.

Questions à poser avant de se fier aux informations sur les risques des contrats intelligents

• Le développeur du protocole peut-il fournir les spécifications, le code, les tests, les commits, les dépendances et les informations de déploiement avant l’implémentation et les tests ?
• Quel document fait foi en cas de désaccord entre l’auditeur, la gouvernance et les détenteurs des clés ?
• Qui finance ou absorbe l’exposition créée lors de l’audit du système déployé ?
• En quoi les risques liés aux oracles et à la composition diffèrent-ils des risques liés au code sur les plans juridique et économique ?
• Comment le système détecterait-il une exploitation comptable avant la réponse et la gouvernance ?
• Que se passe-t-il lorsque l’oracle ou le protocole externe est indisponible, ou que ses éléments probants sont obsolètes ?
• Un examinateur indépendant peut-il rapprocher le résultat des spécifications, du code source et du bytecode déployés, des tests et audits, des paramètres et des rôles d’administration, de la cartographie des oracles et des dépendances, des événements surveillés, de la réponse aux incidents et de la répartition des pertes ?

Pour évaluer les risques liés aux contrats intelligents, remplacez les formules telles que « la plateforme s’en charge » par des comptes, des contrats, des horodatages, des règles d’approbation et des entités responsables clairement identifiés. Une réponse complète doit permettre à un examinateur de remonter de la réponse et de la gouvernance à la définition des droits et des invariants, d’identifier le responsable de chaque document et de calculer qui supportera la perte avant qu’une exception ne survienne.

Le principe fondamental des risques liés aux contrats intelligents

L’analyse du risque lié aux contrats intelligents est plus claire lorsqu’elle suit l’invariant financier promis et chaque dépendance du code, des données et de la gouvernance susceptible de le modifier au cours des cinq étapes opérationnelles, puis vérifie le résultat au regard de la spécification, du code source déployé et du bytecode, des tests et des audits, des paramètres et des rôles d’administration, de l’oracle et de la cartographie des dépendances, des événements surveillés, de la réponse aux incidents et de la répartition des pertes. Le déroulement montre ce qui change ; le tableau des participants indique qui peut autoriser ce changement ; la comparaison des trois états évite de confondre des affirmations qui ne sont pas comparables ; et la cartographie des défaillances montre où la confiance doit diminuer. Cette approche permet de distinguer une véritable amélioration d’une friction ou d’un risque déplacé vers un niveau moins visible.

Sources primaires sur les risques liés aux contrats intelligents

• Cadre de cybersécurité du NIST
• BIS : risques de la DeFi pour la stabilité financière
• Rapport du Comité consultatif technologique de la CFTC sur la DeFi