Un smart contract, ou contrat intelligent, est un programme informatique déployé sur une blockchain, qui s’exécute automatiquement dès que les conditions inscrites dans son code sont réunies, sans dépendre d’un opérateur central. La logique convenue entre les parties, par exemple un transfert d’actifs contre paiement, est portée directement par le code.
Pourquoi le secteur financier s’y intéresse
La tokenisation d’actifs désigne la représentation d’un titre ou d’une part de fonds sous forme de jeton inscrit sur un registre distribué. Elle repose presque toujours sur des smart contracts, qui portent les règles d’émission et de circulation du jeton. Le cadre européen accompagne ce mouvement avec le règlement MiCA et le régime pilote pour les infrastructures de marché fondées sur des registres distribués ; les risques cyber associés à la tokenisation, au règlement MiCA et au régime pilote DLT appellent une analyse spécifique.
Les expérimentations de monnaies numériques de banque centrale, dont les travaux autour de l’euro numérique, mobilisent des briques technologiques voisines. Un établissement peut donc rencontrer ces programmes sans en avoir écrit une ligne, par la conservation d’actifs tokenisés ou par ses contreparties.
Ce qui change par rapport à un logiciel classique
Un applicatif bancaire traditionnel s’exécute dans une infrastructure privée et peut être corrigé dès qu’un défaut est découvert. Le smart contract inverse ces postulats : son code, ou au minimum son bytecode, est lisible par quiconque consulte la chaîne, ce qui laisse à un attaquant le loisir d’étudier sa cible. Une fois déployé, le programme devient immuable : une vulnérabilité présente au déploiement le reste tant que le contrat détient des fonds.
Enfin, un smart contract détient et déplace directement de la valeur ; l’exploitation d’une faille se traduit par un transfert d’actifs immédiat et, les transactions étant définitives, très difficilement réversible. Les fonds détournés rejoignent ensuite les circuits qui font des cryptomonnaies un outil privilégié des cybercriminels. Les mécanismes de sécurité propres à la blockchain garantissent l’intégrité du registre et l’exécution fidèle du code, pas la qualité de ce code lui-même.
Les grandes familles de vulnérabilités
Les erreurs de logique métier n’ont rien de spécifique à la blockchain : un contrôle d’accès oublié ou une condition inversée existent dans tout logiciel. Le code étant public et la valeur accessible, une erreur discrète peut toutefois être repérée et monétisée par un tiers avant que l’émetteur en ait connaissance.
La réentrance, elle, est propre à cet environnement : un contrat qui appelle un contrat externe avant d’avoir mis à jour son propre état s’expose à ce que l’appelé rappelle la fonction d’origine et répète un retrait sur la base d’un solde périmé. Les oracles de prix forment une autre surface d’attaque : incapable d’observer le monde extérieur, un contrat dépend de sources de données pour valoriser un collatéral ou déclencher une liquidation. Si la source est unique ou adossée à un marché peu liquide, une manipulation ponctuelle du cours suffit à fausser ses décisions.
Beaucoup de contrats conservent par ailleurs des fonctions privilégiées, réservées à une ou quelques clés, pour mettre le protocole en pause ou modifier ses paramètres ; leur compromission équivaut à une prise de contrôle complète. Les mécanismes de mise à jour par proxy, qui font évoluer la logique d’un contrat malgré l’immuabilité du code déployé, relèvent de la même problématique : ils réintroduisent un point de confiance central, celui qui décide de la nouvelle version.
Restent les dépendances. Les contrats réutilisent largement des bibliothèques partagées, et les ponts inter-chaînes, qui immobilisent des actifs sur une chaîne pour en émettre la représentation sur une autre, concentrent de la valeur et combinent composants internes et externes à la chaîne. Ces dépendances rejoignent la problématique des attaques visant la supply chain logicielle, avec une aggravation notable : le composant vulnérable détient parfois lui-même les fonds.
Les pratiques de sécurisation observées dans l’écosystème
Face à ces particularités, l’écosystème a convergé vers un socle de pratiques :
- des audits de code indépendants avant déploiement, renouvelés à chaque évolution ;
- des tests d’invariants, du fuzzing et, pour les composants critiques, de la vérification formelle ;
- des programmes de récompense de vulnérabilités pour les chercheurs externes ;
- la limitation des privilèges d’administration, par signature multiple et délais imposés aux opérations sensibles ;
- des mécanismes d’arrêt d’urgence pour suspendre le contrat en cas d’anomalie.
Aucune de ces mesures ne se suffit à elle-même : un audit reste une photographie du code à un instant donné, et un dispositif de pause crée lui-même une fonction privilégiée. La tenue d’un inventaire des composants logiciels (SBOM) vaut pour les contrats comme pour tout autre développement. L’ENISA a consacré des travaux à la sécurité des registres distribués, et le NIST a publié un document de synthèse sur la technologie blockchain.
L’angle d’analyse pour un établissement financier
L’exposition ne passe pas nécessairement par le développement en propre. Conserver des actifs tokenisés suppose de gérer des clés cryptographiques et d’interagir avec des contrats écrits par des tiers ; recourir à des protocoles externes ajoute une dépendance dont la sécurité échappe au contrôle direct de l’établissement.
Ce type de dépendance s’analyse avec les outils habituels de la gestion du risque cyber, enrichis de ces spécificités. Le règlement européen DORA impose aux entités financières un encadrement de leurs risques informatiques, y compris ceux portés par des prestataires tiers ; une dépendance à une infrastructure DLT ou à un protocole de tokenisation s’y rattache. La solidité des signatures cryptographiques qui sous-tendent ces contrats renvoie enfin aux interrogations sur l’effet des ordinateurs quantiques sur les crypto-actifs.
Questions fréquentes sur la sécurité des smart contracts
Peut-on corriger un smart contract après son déploiement ?
Pas directement : le code inscrit sur la chaîne ne peut plus être modifié. Les équipes déploient une nouvelle version puis migrent les utilisateurs, ou prévoient dès l’origine une architecture à proxy dont la logique peut être remplacée. Cette seconde option rétablit toutefois un pouvoir central, celui de décider du contenu de la mise à jour.
Un audit de sécurité garantit-il l’absence de faille ?
Non. L’audit examine une version donnée du code, dans un périmètre défini, et sa portée diminue à chaque modification ultérieure. Il ne couvre pas toujours les sources de données externes ni la gouvernance des clés d’administration. Les projets matures le complètent par des tests continus et une surveillance après mise en production.
Pourquoi les oracles de prix sont-ils un maillon sensible ?
Un contrat n’a aucun accès autonome aux informations hors chaîne ; il agit sur la foi des données qu’un oracle lui transmet. Si cette donnée est manipulée, le contrat exécute des opérations techniquement valides mais fondées sur une réalité faussée. La robustesse d’un protocole dépend donc autant de ses sources de données que de son propre code.
Un établissement sans projet blockchain est-il concerné par ces risques ?
Il peut l’être indirectement, notamment lorsqu’il conserve des crypto-actifs pour sa clientèle ou lorsque ses contreparties dépendent elles-mêmes de protocoles vulnérables. Les exigences européennes de résilience opérationnelle numérique conduisent à intégrer ces dépendances dans la cartographie des risques, au même titre que les autres services externalisés.
