
a16z : Pourquoi l'action du ministère de la Justice américain contre la DeFi est-elle une catastrophe ?
TechFlow SélectionTechFlow Sélection

a16z : Pourquoi l'action du ministère de la Justice américain contre la DeFi est-elle une catastrophe ?
Les acteurs du secteur et les législateurs doivent collaborer étroitement d'ici 2025 afin de garantir que la loi reflète correctement les notions précises de conservation et de contrôle, ainsi que les responsabilités qui en découlent.
Rédaction : Miller Whitehouse-Levine, Amanda Tuminelli
Traduction : 0xjs@Jinse Finance
Si quelqu’un franchit un feu rouge et provoque un accident, qui est responsable : le conducteur ou le constructeur automobile ? Presque certainement le conducteur. Bien sûr, le constructeur a l’obligation d’utiliser des matériaux appropriés et d’installer des équipements de sécurité comme les ceintures de sécurité et les airbags, mais ses responsabilités s’arrêtent là. Il n’a aucun sens de tenir le constructeur responsable des comportements imprudents des utilisateurs de ses véhicules, tout comme il serait absurde de faire porter au conducteur la responsabilité de la fabrication du véhicule.
De même, si une personne utilise le véhicule d’un constructeur comme moyen de fuite lors d’un braquage bancaire, vous ne tiendriez pas pour responsable le développeur d’une voiture autonome. Comme l’a souligné un juge dans un scénario hypothétique : « Vous n’intentez pas de procès à une entreprise automobile pour complicité d’acte illégal ; [vous] poursuivez l’individu fautif. »
Dans le domaine automobile, ces principes semblent évidents, mais dans le monde numérique, ils restent largement contestés. Déterminer qui exerce un contrôle dans un système donné, et à quel degré, constitue la question fondamentale autour de laquelle doivent s’articuler toutes les autres questions juridiques et politiques. Les mêmes principes intuitifs qui régissent notre compréhension de la responsabilité du constructeur et du conducteur devraient servir de base à une politique éclairée dans le contexte des réseaux et protocoles décentralisés. (En réalité, le juge cité ci-dessus parlait de savoir si Uniswap, un exchange décentralisé de cryptomonnaies, devait être tenu responsable de l’achat par un plaignant d’un jeton frauduleux créé par une personne anonyme.)
L’élaboration de politiques raisonnables en matière de cryptomonnaies doit toujours commencer par une analyse du « contrôle » dans un système donné : qui contrôle un système ou les actifs d’autrui ? Comment exerce-t-il ce contrôle ? Et quand ? Répondre à cette question permet d’établir qui peut ou ne peut pas être tenu responsable des activités au sein de l’écosystème des actifs numériques.
Tenir les individus responsables d’activités ou de systèmes sur lesquels ils n’exercent aucun pouvoir ou contrôle entraîne des conséquences néfastes. Malheureusement, le ministère de la Justice américain (DOJ) ignore cette distinction et cherche à tenir les développeurs de logiciels responsables des usages faits par des tiers d’outils neutres qu’ils ont initialement créés mais qu’ils ne contrôlent plus.
En 2024, le DOJ a commencé à poursuivre des développeurs de logiciels dans l’industrie blockchain – des acteurs comparables à des constructeurs automobiles qui produisent des technologies neutres – dans deux affaires connues : États-Unis contre Storm et États-Unis contre Rodriguez. La portée étendue des accusations formulées par le DOJ dans ces actes d’accusation indique que de nombreux autres acteurs du secteur pourraient également être visés, mettant en œuvre une politique équivalente à celle qui obligerait les constructeurs automobiles à répondre des accidents de la route.
C’est pourquoi, alors que nous entrons dans une nouvelle ère en 2025, la priorité politique majeure pour l’industrie des actifs numériques consiste à codifier dans la loi une compréhension correcte et légitime du « contrôle », notamment la définition de l’activité de « transfert de fonds » selon l’article 1960. L’activité de transfert de fonds est soumise à certaines obligations d’enregistrement et de déclaration prévues par la Loi sur la confidentialité bancaire (31 USC § 5312), ainsi qu’à des dispositions pénales (18 USC § 1960), sanctionnant ceux qui n’enregistrent pas leur activité. Les sanctions sont sévères : l’article 1960 prévoit jusqu’à 250 000 dollars d’amende et cinq ans d’emprisonnement maximum pour violation.
Clarifier et codifier une interprétation correcte des lois sur le transfert de fonds implique nécessairement d’intégrer dans la loi les concepts de détention et de contrôle. Cela signifie aussi garantir que les organismes gouvernementaux interprètent la loi de manière cohérente avec ces concepts. Nous estimons qu’il s’agit de la question la plus cruciale pour l’industrie américaine des cryptomonnaies, car en l’absence de solution, le DOJ pourrait continuer à inculper les développeurs de logiciels non dépositaires – qu’il s’agisse de protocoles de finance décentralisée (DeFi), du protocole Bitcoin ou d’autres protocoles neutres – pour « exercice illégal d’une activité de transfert de fonds », même si ces accusations sont infondées, puisque ces développeurs n’ont aucun contrôle sur le logiciel ni sur les actifs des utilisateurs.
La définition des termes liés au « transfert de fonds » doit être interprétée sans ambiguïté. La Loi sur la confidentialité bancaire définit le « service de transfert de fonds » comme l’« acceptation de monnaie, de fonds ou de valeur monétaire alternative, et le transfert, de quelque manière que ce soit, de monnaie, de fonds ou de valeur monétaire alternative ». Par ailleurs, l’article 1960 définit le « transfert de fonds » comme incluant le fait de « transférer des fonds, de quelque manière que ce soit, pour le compte du public ». D’un point de vue strictement textuel et d’après toute analyse juridique pertinente, tous, sauf le DOJ, reconnaissent clairement qu’une activité de « transfert de fonds » doit impliquer un contrôle effectif sur les fonds des utilisateurs.
Prenons un exemple pour illustrer cette différence. Imaginons une personne échangeant des actifs numériques : elle peut utiliser les services d’un exchange centralisé ou d’un protocole DeFi. Pour utiliser un exchange centralisé, la personne transfère d’abord ses actifs numériques vers l’exchange, qui les détient et les contrôle. L’exchange effectue ensuite les transactions selon les instructions de l’utilisateur. En d’autres termes, l’exchange « accepte » et « transfère » les fonds de l’utilisateur en son nom. Le contrôle exercé par l’exchange sur les fonds personnels comporte certains risques (par exemple, perte ou mauvaise utilisation) – les réponses politiques visant à définir ce que l’exchange peut ou ne peut pas faire avec ce contrôle peuvent atténuer ces risques. Si l’exchange perd les actifs qu’il contrôle pour le compte de l’utilisateur, il doit en assumer la responsabilité.
Dans le cas de la DeFi, on peut obtenir un résultat similaire sans jamais transférer le contrôle des actifs à un tiers. Lorsqu’on utilise un protocole logiciel décentralisé pour échanger des actifs numériques, la personne conserve le contrôle de ses actifs et ne l’abandonne jamais. Au lieu de cela, elle utilise un nouveau type d’outil logiciel – un protocole d’échange DeFi – pour exécuter unilatéralement des échanges selon ses propres directives. Contrairement aux exchanges centralisés, les développeurs initiaux d’un protocole DeFi ne conservent aucun contrôle sur le protocole et ne peuvent pas influencer la manière dont des tiers l’utilisent. Seuls les utilisateurs du protocole DeFi contrôlent leurs propres actifs. Bien que l’utilisation d’un protocole DeFi comporte des risques (par exemple, technologie complexe, taux d’erreur utilisateur plus élevé), le risque de perte d’actifs par un tiers est moindre, car l’utilisateur ne délègue jamais la custody. (Si vous détenez vos propres actifs, la faillite d’une banque ne vous affecte pas.)
La compréhension fondamentale du contrôle – c’est-à-dire la capacité effective d’un tiers à transférer les fonds des utilisateurs – est essentielle. C’est pourquoi des activités comme les exchanges centralisés décrits ci-dessus sont à juste titre régulées comme des « services de transfert de fonds », tandis que les développeurs de protocoles intelligents non dépositaires et immuables ne le sont pas. Cela met aussi en lumière les dangers d’une mauvaise interprétation ou d’une mauvaise attribution du contrôle. D’un côté, il faut identifier et atténuer les sources de risque ; de l’autre, il faut correctement attribuer la responsabilité lorsque des problèmes surviennent, en identifiant qui dispose du contrôle nécessaire sur le système pour réduire les risques, ou qui porte la plus grande part de responsabilité quant à un acte nécessitant réparation.
L’industrie et les législateurs doivent collaborer étroitement en 2025 afin de garantir que la loi reflète fidèlement les notions précises de custody et de contrôle, ainsi que les responsabilités qui en découlent – que ce soit dans le cadre de lois sur la structure des marchés, les obligations de déclaration des courtiers, ou la réforme de l’article 1960. Actuellement, l’industrie fait face à une menace réelle posée par l’interprétation excessive et erronée du DOJ concernant ce qui constitue une activité de virement non autorisée, une des nombreuses incompréhensions existant dans le domaine de la politique cryptographique.
Comme le montre notre analogie ci-dessus, si les constructeurs automobiles devaient être tenus responsables de chaque collision échappant à leur contrôle, l’automobile n’aurait probablement jamais réussi. Une telle politique risquerait d’étouffer l’innovation automobile et de figer l’industrie américaine. Si politiques et législateurs parviennent à s’entendre sur la réalité du contrôle et de la régulation dans le contexte du développement logiciel, nous créerons aux États-Unis une base claire et équitable pour les entrepreneurs et développeurs de cryptomonnaies.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News













