Je reviens sans cesse à une gêne simple dans la crypto : nous avons passé des années à rendre les transactions plus rapides, moins coûteuses et plus programmables, mais la question la plus difficile n’a jamais disparu. La vitesse n’a jamais été le vrai problème. Le vrai problème, c’était la confiance après l’automatisation. Une fois qu’un portefeuille, un bot ou un agent peut agir de lui-même, qui décide de ce qu’il est autorisé à faire, qui vérifie qu’il est resté dans les limites, et quelle preuve existe quand quelque chose tourne mal ? Cette question a refait surface à chaque cycle de la finance onchain, puis s’est effacée derrière un nouveau récit, avant de revenir plus tranchante plus tard.
Je pense que c’est pour cela que le protocole Newton me paraît suffisamment sérieux pour qu’on s’y intéresse, même s’il reste encore dans une catégorie expérimentale qui mérite la prudence. Il essaie de combler un manque structurel récurrent en crypto : nous avons de fortes couches d’exécution, mais de faibles couches de politique. On peut dire à un contrat de déplacer de la valeur, mais on ne peut souvent pas exprimer les règles humaines qui devraient gouverner ce déplacement d’une manière native au système. Les limites, les autorisations, les approbations, les contrôles de sanctions, les règles d’acheminement, les fenêtres temporelles et les frontières des agents sont généralement ajoutés de l’extérieur. Ils vivent dans des tableaux de bord, des accords juridiques, des contrôles de garde ou des procédures hors chaîne. Cet arrangement fonctionne tant que l’automatisation reste périphérique, et non centrale.
Cet écart a été visible pendant longtemps dans la DeFi institutionnelle, l’automatisation de trésorerie et l’infrastructure de trading. Un fonds peut vouloir une exécution algorithmique, mais avoir quand même besoin de contraintes autour des contreparties, de limites de taille, de listes blanches, ou de budgets de risque. Un développeur peut construire un agent autonome, mais dès que cet agent peut détenir des clés ou soumettre des transactions, l’utilisateur commence à poser une question plus sérieuse que « est-ce qu’il peut le faire ? ». Il demande « puis-je définir ce qu’il a le droit de faire, et puis-je le vérifier après coup ? ». Les tentatives précédentes ont souvent résolu une couche au détriment de l’autre. Les smart contracts purs nous ont donné une exécution transparente, mais pas une politique humaine flexible. Les systèmes de garde nous ont donné le contrôle, mais au prix de l’ouverture. Les plateformes middleware nous ont donné de l’orchestration, mais pas une garantie cryptographique que la politique a été appliquée là où l’action a réellement eu lieu.
C’est justement l’ouverture que Newton essaie d’occuper. Tel que je le lis, le projet ne cherche pas à remplacer les couches d’exécution existantes. Il cherche à s’installer au-dessus ou à côté d’elles comme un cadre de politique et d’autorisation pour une activité pilotée par la machine. L’idée de base est facile à saisir, même si la mise en œuvre ne l’est pas. Au lieu de traiter chaque agent d’IA ou stratégie automatisée comme un acteur entièrement autonome avec des autorisations étendues, Newton essaie de rendre les actions conditionnelles. Une stratégie devrait pouvoir demander si une transaction est autorisée, pas seulement si la transaction peut être signée. Cela peut sembler subtil, mais, dans la pratique, c’est la différence entre une automatisation brute et une automatisation gouvernée.
Je trouve que cette distinction est importante parce qu’elle reflète la manière dont les organisations fonctionnent réellement. Les humains ne fonctionnent que rarement avec des autorisations infinies. Ils agissent au sein de départements, de chaînes d’approbation, de comités de risque, de règles de conformité et d’accès limités. La version crypto de l’automatisation a souvent ignoré cette réalité et supposé que l’autorité totale est l’aboutissement naturel de la décentralisation. Je ne pense pas que cette hypothèse ait bien vieilli. À mesure que le capital, les agents et les stratégies deviennent plus autonomes, l’absence de politique ressemble de moins en moins à de la liberté et de plus en plus à de la négligence. Newton semble être une tentative d’encoder le “milieu manquant” : assez de structure pour rendre l’automatisation utilisable dans des contextes sérieux, sans transformer tout le système en gardien centralisé.
C’est aussi pour cela que la formulation du “secure rollup” compte. Je la comprends moins comme un langage marketing et plus comme un choix architectural. Un rollup peut regrouper l’activité, imposer des règles et créer un environnement partagé où les contrôles de politique ont lieu avant que les actions ne soient finalisées. Si le système est conçu correctement, il peut rendre les règles lisibles pour les développeurs et auditables pour les utilisateurs. La logique n’est pas que chaque décision devrait être prise par un humain en temps réel. La logique est que la politique approuvée par les humains devienne une infrastructure exécutable par machine. C’est un changement significatif si cela fonctionne : l’exécution se rapproche de l’action, au lieu de vivre dans une couche de conformité séparée qui peut ou non être respectée.
La dimension “marché” est tout aussi intéressante, même si je me méfie de la tentation habituelle de trop la décoder. Un marché pour développeurs d’IA semble vaste, mais la version réellement pertinente est plus étroite. Ce n’est pas seulement un endroit où les gens listent des agents ou des outils. C’est un endroit où les développeurs peuvent publier des comportements contraints par une politique, et rendus utilisables par d’autres personnes qui ne veulent pas bâtir une gouvernance à partir de zéro. Cela compte parce qu’un des coûts cachés de l’IA en crypto n’est pas la qualité du modèle ; c’est la confiance opérationnelle. Un développeur peut réussir à construire une stratégie solide, mais si chaque utilisateur doit inspecter le système, définir des limites et comprendre seul le modèle de risque, l’adoption reste faible. Un cadre de politique partagé peut réduire ce fardeau. Il peut aussi créer de la dépendance, et la dépendance, c’est là que commence la vraie infrastructure.
Pour autant, je ne veux pas faire semblant que ce soit un chemin facile. La critique la plus forte d’un projet comme Newton est que la politique n’est jamais aussi simple que ce qu’elle paraît sur le papier. Un ensemble de règles qui semble propre dans une démo peut devenir chaotique dès qu’il rencontre la volatilité du marché, la fragmentation de la chaîne, ou des préférences utilisateurs contradictoires. Que se passe-t-il lorsque la politique est trop restrictive et bloque une activité légitime ? Que se passe-t-il lorsqu’elle est trop souple et ne protège pas les utilisateurs contre les abus ou les erreurs ? Plus le système devient expressif, plus il peut être difficile de raisonner dessus, de le tester et de le sécuriser. Il y a toujours une tension entre flexibilité et auditabilité. Un moteur de politique trop rigide devient inutilisable ; un moteur trop ouvert devient peu digne de confiance.
Il y a aussi la question de savoir qui définit la politique. Cette question n’est pas purement esthétique. C’est le cœur du modèle. Si les utilisateurs définissent leurs propres règles, le système risque de rester fragmenté et difficile à standardiser. Si des institutions définissent les règles, alors le cadre peut absorber discrètement les hypothèses des plus grands participants. Si la gouvernance définit les défauts, alors le protocole hérite des problèmes familiers de capture, d’ambiguïté et d’adaptation lente. Je ne pense pas que Newton puisse éviter ces arbitrages. Au mieux, il peut les exposer honnêtement et fournir une structure dans laquelle ils sont visibles plutôt que cachés.
Je pense aussi que la friction à l’adoption sera réelle. Les créateurs disent souvent vouloir la sécurité, mais ils veulent aussi la vitesse, la composabilité et une faible surcharge. Chaque couche supplémentaire d’autorisation ajoute de la complexité. Chaque contrôle de politique ajoute de la latence, un coût de coordination et des difficultés de débogage. Le projet devra prouver que ses protections sont non seulement séduisantes sur le plan conceptuel, mais aussi tolérables en pratique. Si l’expérience utilisateur devient trop lourde, les gens continueront à utiliser des outils plus simples et accepteront le risque. C’est le destin de nombreuses idées crypto dites “sérieuses” : elles sont correctes en principe et incommodes dans la pratique.
Le risque d’exécution est tout aussi important. Si Newton se positionne comme une infrastructure pour des stratégies pilotées par l’IA, alors il entre dans un espace où les échecs de confiance peuvent être immédiats et publics. Un moteur de politique mal configuré, un bug dans la logique d’exécution, un différend de gouvernance, ou un cas limite dans le comportement d’un agent peuvent tous endommager la confiance rapidement. L’infrastructure n’a pas droit à une grâce infinie. Elle doit gagner la confiance par la répétition, pas par la rhétorique. C’est pourquoi je m’intéresse davantage à savoir si le système peut être “ennuyeux” qu’à savoir s’il peut impressionner. Dans cette partie de la crypto, “ennuyeux” est généralement un meilleur signe que le spectacle.
Et pourtant, je vois pourquoi le modèle séduit. S’il fonctionne, les bénéficiaires les plus évidents seront probablement les utilisateurs qui savent déjà qu’ils ont besoin de structure : fonds, protocoles, DAO, équipes gérant des trésoreries partagées, et développeurs qui construisent des systèmes autonomes qui ne peuvent pas, de manière responsable, opérer avec une autorité sans limites. Ce sont les gens pour qui « il suffit de donner une clé à l’agent » n’est pas une réponse acceptable. Ils ont besoin d’autorisations limitées, de l’exécution des politiques, et d’un moyen de prouver que les règles ont été respectées. Pour eux, Newton pourrait devenir une couche pratique plutôt qu’une couche abstraite.
Mais je soupçonne qu’une grande partie du marché restera hors de sa portée. Les utilisateurs particuliers qui veulent une automatisation simple ne se soucieront peut-être pas assez d’adopter une infrastructure tenant compte des politiques, tant qu’il ne se passe rien de fâcheux. Les petits constructeurs pourraient ne pas vouloir la surcharge. Certains écosystèmes pourraient préférer des hypothèses de confiance flexibles plutôt que des contraintes formelles. Et de nombreux utilisateurs, même avertis, pourraient continuer à privilégier des outils qui paraissent sans friction plutôt que gouvernés. C’est la vérité inconfortable derrière de nombreux projets d’infrastructure : leur valeur est la plus claire pour les personnes qui comprennent déjà le coût de ne pas les avoir.
Donc, quand je regarde le protocole Newton, je ne vois pas une réponse finale. Je vois une tentative sérieuse de rendre l’automatisation on-chain compatible avec des limites du monde réel. Je vois un effort pour traiter la politique comme quelque chose de natif à l’exécution plutôt que comme quelque chose d’externe à celle-ci. Je vois aussi les questions habituelles encore sans réponse concernant la gouvernance, la complexité, et la question de savoir si le marché récompensera la discipline plutôt que la commodité. C’est suffisant pour capter mon attention, mais pas assez pour considérer que le problème est résolu. Dans un espace qui continue d’automatiser avant d’être pleinement d’accord sur les règles, la question plus profonde pourrait être de savoir si des systèmes comme Newton peuvent rendre la politique suffisamment naturelle pour qu’on cesse de la traiter comme une simple réflexion a posteriori. Ou si l’industrie continuera de choisir la vitesse d’abord, puis de redécouvrir le besoin de règles seulement après que les dégâts soient déjà faits.