Écrire des smart contracts n’est qu’une moitié du défi. Concevoir la manière dont ils prennent des décisions devient tout aussi important.
J’espérais que Newton me ferait réfléchir à de meilleurs smart contracts. Au lieu de cela, il m’a fait réfléchir aux systèmes de permissions. Le défi caché n’est pas d’écrire du code : c’est de définir les conditions dans lesquelles le code doit s’exécuter. Un système d’exploitation n’exécute pas simplement chaque application qui demande des ressources. Il vérifie les permissions, authentifie les identités, applique des politiques et décide de ce qui doit être autorisé avant l’exécution. Ma thèse est que la DeFi s’approche de la même transition d’architecture. Le prochain avantage concurrentiel ne viendra pas de l’écriture de smart contracts plus sophistiqués. Il viendra de la séparation de l’exécution et de l’autorisation.
J’ai d’abord supposé que les outils de développement continueraient d’évoluer grâce à de meilleures machines virtuelles, à des exécutions moins coûteuses et à des langages plus expressifs. En creusant, j’ai constaté que ces améliorations répondent à la computation, pas au jugement. Le vrai goulot d’étranglement, c’est ce que j’appelle la « dette décisionnelle » : chaque protocole reconstruit sans cesse sa propre logique d’autorisation pour les limites de dépenses, les approbations multisig, le filtrage des sanctions, les permissions du wallet et la gestion des risques. Le code fonctionne, mais la couche de décision reste fragmentée.
Cette fragmentation crée des incitations que la plupart des concepteurs sous-estiment. Chaque protocole écrit des hypothèses de sécurité, des règles de gouvernance et des contrôles de politique légèrement différents. Chaque audit devient plus coûteux parce que la logique d’autorisation est intégrée de façon différente d’une application à l’autre. Chaque mise à niveau risque d’introduire un comportement incohérent. Le coût caché n’est pas l’exécution : c’est le maintien de milliers de moteurs de politique indépendants, qui tentent tous de résoudre des problèmes de coordination presque identiques.
Le SDK Vault de Newton suggère une architecture différente. Au lieu d’intégrer directement les règles d’autorisation dans chaque smart contract, les développeurs définissent des politiques programmables évaluées à l’extérieur avant exécution. Le smart contract reste responsable du règlement, tandis que l’autorisation devient une couche d’infrastructure dédiée. Cela ressemble à la façon dont l’infrastructure cloud a séparé la gestion d’identité de la logique applicative via des services comme l’IAM, plutôt que d’obliger chaque application à implémenter son propre cadre d’authentification.
L’implication technique est plus importante qu’il n’y paraît. Un coffre peut exiger des limites de transaction, des signataires désignés, des contrôles de sanctions, des délais, une validation par wallet matériel, ou des politiques organisationnelles personnalisées avant exécution. Le réseau d’autorisation de Newton évalue ces conditions et produit un résultat d’autorisation cryptographique que les contrats peuvent vérifier. Plutôt que de remplacer les smart contracts, il réduit la quantité de code spécifique aux politiques que les développeurs doivent maintenir à répétition.
Dans le monde réel, ces cas d’usage rendent cette distinction plus claire. Un trésor DAO peut exiger des seuils d’approbation différents selon la taille des transactions. Un émetteur de stablecoin peut avoir besoin d’un filtrage des sanctions avant les transferts. Un prestataire de custody institutionnel peut imposer des restrictions géographiques et des fenêtres de trading. Un family office peut limiter les retraits quotidiens tout en exigeant plusieurs approbations au-delà de certains seuils. Aujourd’hui, ces règles sont souvent reconstruites indépendamment. Newton cherche à en faire une infrastructure réutilisable.
Le compromis mérite une attention équivalente. Externaliser l’autorisation introduit une dépendance supplémentaire. Si l’infrastructure de politique devient critique, la gouvernance autour des mises à jour de politiques, des incitations des validateurs et de la disponibilité devient aussi importante que la sécurité des smart contracts elle-même. Une meilleure modularité peut aussi créer de nouveaux risques de coordination si les règles d’autorisation évoluent différemment de la logique applicative.
Par rapport aux alternatives, cela correspond à une philosophie différente. Les bibliothèques classiques de contrôle d’accès placent toujours l’autorisation dans le code applicatif. Les wallets multisig résolvent l’approbation collective, mais pas l’évaluation dynamique des politiques. Les fournisseurs de conformité fonctionnent souvent entièrement hors chaîne, obligeant les institutions à faire confiance à l’application centralisée de l’exécution. Newton essaie de créer une couche d’autorisation vérifiable : les décisions de politique elles-mêmes deviennent observables et attestables de manière cryptographique avant le règlement.
Ce qui m’intéresse le plus, c’est le changement de comportement que cette architecture encourage. Les développeurs cessent de penser exclusivement à écrire du code exécutable et commencent à concevoir des systèmes de décision. Les équipes de sécurité passent de la réaction aux exploits à la définition de politiques préventives. Les institutions obtiennent une gouvernance programmable sans réécrire des applications cœur. La responsabilité passe de « Ce contrat peut-il s’exécuter ? » à « Dans quelles conditions doit-il s’exécuter ? »
Si ce modèle se généralise, la DeFi pourrait discrètement dépasser un monde où chaque protocole invente ses propres hypothèses de sécurité. La question ouverte est de savoir si les développeurs accepteront une couche d’infrastructure supplémentaire en échange d’une complexité réduite. L’avenir appartiendra peut-être non pas aux smart contracts les plus ingénieux, mais aux systèmes qui prennent les décisions d’autorisation les plus pertinentes avant même qu’une seule ligne de code de contrat ne s’exécute.