Sovereignty on Arem

3. La DeFi, laboratoire de la délégation

Mon, 13 Apr 2026 13:00:00 +0000

Dans cette série : Self-custody, mais jusqu’où ?

En DeFi, une idée devient vite une autorisation, une gestion du risque ou une signature.

C’est ce qui fait de la DeFi un terrain d’expérimentations.

Dans bien des environnements numériques, on peut encore vivre longtemps dans l’ambiguïté. Les gestes restent diffus, les conséquences se répartissent, les erreurs se rattrapent. En DeFi, beaucoup moins. Entre une lecture du marché, une recommandation, un clic, une approbation et une exécution, la distance est courte.

Un dashboard n’est donc pas seulement une interface. Il peut orienter une lecture. Un wrapper n’est pas seulement un service. Il peut reformuler la perception du risque. Un agent n’est pas seulement un assistant. Il peut surveiller, proposer, préparer, déclencher, voire exécuter dans certaines bornes.

C’est pourquoi la DeFi voit plus tôt que d’autres secteurs ce que devient la délégation lorsqu’elle cesse d’être un confort abstrait pour prendre la forme de permissions réelles.

Le protocole ne résume plus le système

On parle encore volontiers de « risque protocolaire », comme si le protocole suffisait à décrire l’objet.

Ce n’est plus vrai.

Entre l’utilisateur et le protocole s’intercale désormais tout un environnement logiciel : interfaces spécialisées, dashboards, wrappers, copilotes, outils treasury, couches de recherche, outils de monitoring, services de coordination, parfois déjà agents d’exécution.

Il ne s’agit pas de soupçonner indistinctement tous ces objets. Il s’agit de comprendre qu’ils déplacent la carte de la confiance. Même lorsqu’un protocole de base est robuste, l’environnement qui l’entoure peut devenir le lieu principal où se rejoue le problème : ce que l’on voit, ce que l’on comprend, ce que l’on croit comprendre, ce que l’on est poussé à faire.

Ce que l’IA change au contexte

Le changement n’est pas seulement conceptuel. Il est matériel.

L’IA abaisse fortement le coût de production des couches logicielles qui se branchent autour des protocoles : dashboards, assistants, wrappers, outils d’analyse, micro-services, couches d’orchestration. Des builders shipent plus vite, testent plus vite, itèrent plus vite. Dans certains cas, c’est une excellente nouvelle.

Mais le coût de la vérification, de la qualification et de la bonne intégration ne baisse pas au même rythme.

Le problème n’est donc pas que des outils soient développés avec l’aide de l’IA. Le problème commence lorsque la baisse du coût de production d’un service n’est pas accompagnée d’une baisse équivalente du coût de sa compréhension, de son contrôle et de son intégration prudente.

Nous n’avons alors pas seulement plus de software. Nous avons plus de surfaces de confiance à évaluer, sans avoir les outils pour le faire.

Vibe coding : loin du scandale, un révélateur

Le terme a parfois servi de raccourci polémique. Il vaut mieux le manier avec précision.

Tout code assisté par IA n’est pas du vibe coding au sens fort. Tout outil construit rapidement n’est pas pour autant peu sérieux. Et il serait absurde d’accuser sans preuve un dashboard, un service ou un projet donné.

Ce que le phénomène rend visible est plus structurel : un milieu où l’on peut produire très vite des couches d’accès, d’analyse, d’orientation et parfois déjà d’exécution ; un milieu où l’apparence de fluidité peut progresser plus vite que la capacité collective à juger ce qui a été réellement relu, compris, cerné et assumé.

Le sujet n’est donc pas la faute morale du builder. Le sujet est l’accélération du contexte dans lequel l’utilisateur doit discerner.

Deux protocoles pour rendre le problème visible

Money League et Polaris n’ont pas été retenus ici comme deux protocoles « à suivre » de plus, ni comme des objets déjà stabilisés.

Il s’agit, dans les deux cas, de protocoles encore en cours de maturation, dont les formes publiques peuvent évoluer. Ils sont donc mobilisés ici avec prudence, à partir de leur présentation actuelle, comme deux figures provisoires plus que comme deux modèles figés. Polaris, notamment, pourrait tout à fait rencontrer plus explicitement la question de la couche agentique.

Ces deux protocoles sont utiles à notre propos parce qu’ils rendent visible, sous deux formes très différentes, une même question.

Money League se présente comme une infrastructure permissionless pour lancer et coordonner des stablecoins décentralisés, avec une architecture modulaire, des incitations mutualisées et, surtout, une thèse explicite sur l’agentic money : marchés prédictifs dans la boucle monétaire, preuve de compétence des agents, agents comme stabilisateurs, horizon d’une économie inter-agents réglée par des actifs pleinement onchain.

Polaris, de son côté, se présente comme un stablecoin operating system onchain, immutable et trustless, centré sur un cœur monétaire fortement borné, des mécanismes de yield internes et une logique d’extension modulaire.

L’intérêt du rapprochement tient à cet écart. Money League permet de penser jusqu’où l’agentivité peut remonter dans l’infrastructure monétaire. Polaris rappelle qu’avant toute montée en puissance du système, il faut encore décider ce qui doit rester borné, lisible et politiquement supportable.

Money League : pousser plus loin l’horizon agentique

Money League est précieux parce qu’il pousse très loin une hypothèse que beaucoup préfèrent encore traiter comme périphérique : la couche agentique peut remonter jusqu’à la monnaie elle-même.

Dans son imaginaire public, les agents ne restent pas à la marge. Ils entrent dans la boucle de stabilisation, de prévision, de coordination et de gestion. Sa force est de rendre visible cet horizon sans détour. Sa limite, au regard de notre question, est qu’il dit davantage sur la souveraineté du système que sur la souveraineté pratique de celui qui délègue.

Polaris : rappeler la question de la constitution

Polaris est, de ce point de vue, un contrepoint utile.

Son intérêt public ne tient pas d’abord à une agentivité spectaculaire, mais à une architecture plus constitutionnelle : un cœur immuable, un stewardship limité, un petit nombre de paramètres ajustables dans des limites codées.

Sa force est de rappeler qu’un système ne devient pas plus légitime parce qu’il automatise davantage. Il devient plus lisible lorsqu’il sait distinguer ce qu’il doit déléguer, ce qu’il peut ajuster, et ce qu’il doit soustraire à la variation ordinaire.

Ce qu’ils montrent ensemble

Pris ensemble, ces deux cas rendent visible une tension que la DeFi rencontrera de plus en plus souvent : jusqu’où laisser monter l’agentivité, et à partir de quel point faut-il, au contraire, renforcer la constitution du système ?

Ce n’est déjà plus une simple question d’UX. C’est une question monétaire, institutionnelle et opérationnelle.

Morin : aucune limitation locale n’abolit le problème du système

C’est ici que Morin nous aide à éviter deux naïvetés symétriques.

La première consisterait à croire que plus de design, plus de limitations et plus de permissions explicites suffisent à résoudre le problème.

La seconde, à l’inverse, serait de conclure que tout devient aussitôt suspect dès qu’une couche supplémentaire apparaît.

Morin oblige à tenir ensemble deux vérités.

Oui, il faut des limites. Oui, il faut des permissions bornées. Oui, il faut des architectures lisibles.

Mais aucune borne locale, aucun module élégant, aucune preuve ponctuelle d’intégrité ne supprime l’écologie de l’action. Un système peut être bien conçu localement et produire malgré tout des effets d’ensemble inattendus : comportements mimétiques, routines de surconfiance, dépendances nouvelles, coordination procyclique, incitations mal lues, angles morts collectifs.

La question n’est donc pas seulement : l’action était-elle autorisée ? Elle est aussi : que produit la multiplication de ces actions dans un milieu peuplé d’outils, de dashboards, d’agents et d’utilisateurs qui ne voient pas tous le même monde ?

La vérifiabilité : aide précieuse, pas substitut au discernement

Il est normal que les appels à une sovereign AI ou à une verifiable AI rencontrent un écho dans le monde web3. Ils parlent une langue familière : contrôle, intégrité, preuves, réduction de la confiance aveugle.

Cette direction est importante. Elle peut rendre certaines délégations plus lisibles, plus attestables, plus contenues.

Mais il faut maintenir une hiérarchie des problèmes.

La vérifiabilité ne remplace pas le bon sens. Elle ne décide pas, à notre place, ce qu’il fallait déléguer. Elle ne garantit pas que les effets d’ensemble seront désirables.

Les preuves, les logs, les limites, les politiques d’action et les primitives cryptographiques peuvent améliorer l’intégrité de certaines opérations. Elles ne dispensent ni de définir le mandat, ni d’assumer les limites, ni de répondre des usages.

Contrôle, intégrité, mesure

Ce qui monte aujourd’hui dans le monde web3 n’est pas illégitime. Il faut simplement garder l’ordre des problèmes.

Sovereign AI

Traite la question du contrôle : où tourne le système, qui dépend de qui, quelles données sortent, quelles permissions sont engagées.

Verifiable AI

Traite la question de l’intégrité : ce qui peut être attesté, relu, prouvé ou reconstitué.

Mais la mesure reste décisive

Aucune de ces deux directions ne dispense de traiter la vraie question : que déléguer, à quelles limites, et avec quelle possibilité de reprise en main ? Les mathématiques et la cryptographie peuvent rendre certaines opérations plus attestables ; elles ne remplaceront ni le jugement, ni la responsabilité, ni l’écologie de l’action.

Grille minimale pour évaluer un outil DeFi assisté ou agentique

Avant d’utiliser un dashboard, un wrapper, un copilote, un agent ou un service tiers, il vaut la peine de passer l’objet au filtre suivant.

1. Nature de l’objet

S’agit-il d’un protocole, d’une interface, d’un outil tiers, d’un agent, ou simplement d’une couche de visualisation ?

2. Niveau d’intervention

Informe-t-il, recommande-t-il, prépare-t-il une action, ou agit-il réellement ?

3. Permissions

A-t-il accès à un wallet, à des messages, à des données privées, à des automatisations, à une exécution onchain, à des appels externes ?

4. Bornes

Quelles sont les limites explicites : montants, types d’actions, confirmations, délais, whitelist, sandbox, périmètre fonctionnel ?

5. Vérifiabilité

Qu’est-ce qui peut être relu, compris, audité ou reconstitué ?

6. Réversibilité

Peut-on couper l’outil sans perdre l’accès au protocole, au risque de base ou à sa capacité d’action essentielle ?

7. Responsabilité

Qui assume quoi : le protocole, le builder de l’outil, l’opérateur, l’utilisateur ? Si cette réponse reste floue, la confiance l’est aussi.

Ce que cette série voulait montrer

Le parcours peut se résumer simplement.

Le monde crypto a appris à défendre ses actifs contre la capture. Il découvre maintenant qu’il doit apprendre à défendre avec la même rigueur son attention, son discernement, son organisation et sa capacité d’agir.

Le problème ne se résout ni par la nostalgie ni par l’accélération pure.

Il demande des protocoles plus lisibles, des outils mieux bornés, des architectures moins magiques, des builders plus responsables, et des utilisateurs moins enclins à confondre puissance nouvelle et abdication discrète.

Il demande aussi une chose plus difficile : accepter qu’aucune preuve locale, qu’aucune automatisation élégante, qu’aucune intégrité cryptographique ponctuelle ne remplacera jamais entièrement la sagesse sur les effets d’ensemble.

C’est sans doute là que se joue la suite la plus sérieuse de la promesse de la crypto.

Il ne s’agit pas seulement protéger ce que nous possédons. Mais apprendre à ne pas céder trop vite ce qui nous permet encore d’agir.

2. Déléguer sans renoncer

Mon, 13 Apr 2026 12:00:00 +0000

Dans cette série : Self-custody, mais jusqu’où ?

La question n’est plus d’utiliser l’IA mais de savoir jusqu’où la laisser entrer.

Le débat sur l’IA se fige trop souvent dans une alternative paresseuse. D’un côté, l’enthousiasme sans frein : tout brancher, tout automatiser, tout accélérer. De l’autre, la posture de retrait : garder ses distances, se défier de tout, et se flatter d’une austérité supposée plus lucide.

Ni l’une ni l’autre ne tient très longtemps dans la vie ordinaire.

La question sérieuse est plus exigeante : quels types de délégation peut-on consentir sans perdre la maîtrise de sa pratique ?

Nous disposons ici d’une ressource précieuse : nous avons déjà appris, dans d’autres domaines, qu’il ne suffit pas qu’un système soit performant pour qu’il soit légitime. Il faut encore savoir qui contrôle quoi, dans quelles limites, et avec quelle réversibilité.

Appliquée à l’IA, cette intuition doit maintenant devenir une discipline.

Assistance, délégation, abandon

Le premier geste consiste à distinguer ce que l’époque tend à confondre.

L’assistance est simple : l’outil aide, suggère, reformule, accélère. Il augmente la capacité d’agir sans déplacer le centre de décision.

La délégation commence lorsque l’outil ne se contente plus d’aider. Il garde le contexte, réordonne, filtre, prépare, surveille, présélectionne, ou déclenche certaines opérations dans un périmètre défini.

L’abandon commence lorsque la délégation devient trop vaste, trop opaque ou trop confortable pour rester réellement gouvernée. Le système continue alors à fonctionner à notre service, mais il devient de plus en plus difficile d’expliquer ce qu’il fait exactement, pourquoi nous lui faisons confiance, et ce qui se passerait s’il fallait reprendre la main.

Ce n’est pas la même chose. Et pourtant, beaucoup d’usages actuels glissent de la première situation vers la deuxième — parfois vers la troisième — sans jamais le dire franchement.

Le vrai test : la facilité

Le problème de la délégation n’apparaît pas d’abord dans les cas extrêmes. Il apparaît dans les cas faciles.

Ce n’est pas lorsque le système propose de signer une transaction absurde que la vigilance se joue le plus souvent. C’est lorsque, jour après jour, il devient normal qu’il lise à notre place, trie à notre place, relie à notre place, surveille à notre place et prépare notre travail avant même que nous nous y mettions.

Là encore, Morin aide à voir plus juste. Le danger n’est pas seulement l’erreur spectaculaire ; c’est la dépendance qui se forme à bas bruit, dans la continuité du service rendu. Nous finissons alors par confondre l’augmentation de notre puissance avec le dessaisissement progressif de notre présence.

Autrement dit : ce qui menace l’autonomie n’est pas toujours l’hostilité. C’est souvent la douceur.

Où commence la responsabilité individuelle

Les protocoles, les builders et les fournisseurs d’outils ont un devoir d’information, de lisibilité, de bornage et, lorsqu’ils le peuvent, de prudence dans le design. Mais ils ne peuvent pas porter seuls la charge d’éduquer des utilisateurs ou des opérateurs décidés à tout déléguer sans discernement.

Il existe donc une responsabilité proprement individuelle qu’il faut réhabiliter.

On trouve une version particulièrement nette de cette préoccupation chez Vitalik Buterin, lorsqu’il défend un usage local-first, compartimenté et fortement borné des LLM. L’intérêt de ce setup n’est pas de fournir un modèle universel. Il est de rendre visible une chose plus profonde : à mesure que l’IA devient un milieu d’action ordinaire, la question décisive n’est plus seulement celle de la puissance des modèles, mais celle des limites que nous acceptons (ou non) de poser à leur délégation.

Mais la pratique ne consiste ni à devenir paranoïaque ni à revenir à une austérité héroïque. Elle consiste à se demander, avec un peu de fermeté : qu’est-ce que je veux vraiment gagner ? et qu’est-ce que je refuse de perdre en l’obtenant ?

Et cette question est plus difficile qu’il n’y paraît. Parce que nous voulons presque tous la même chose : davantage de vitesse, davantage de clarté, moins de friction, moins de fatigue, plus de continuité. Le problème est que ces gains ont un prix. Et ce prix n’est pas toujours payé en données. Il se paie parfois en habitudes de dépendance.

Une discipline minimale de délégation

Il n’existe pas de stack parfaite. Il existe en revanche une discipline minimale, assez simple pour être pratiquée sans se transformer en programme de pureté.

1. Garder le noyau du jugement

Tout ce qui touche à l’interprétation décisive d’une situation doit rester sous garde directe. On peut se faire aider pour explorer, cartographier, comparer, résumer. Mais le moment où une lecture devient un arbitrage doit demeurer identifiable.

2. Borner l’action avant d’augmenter l’assistance

Le vrai danger n’est pas qu’un système soit intelligent. C’est qu’il soit intelligent et bien branché. Plus l’accès s’étend — messagerie, base documentaire, automatisation, wallet, exécution — plus les bornes doivent être nettes.

3. Préférer les couches lisibles aux couches magiques

Un bon outil n’est pas seulement celui qui marche. C’est celui dont le rôle peut être raconté simplement. S’il faut cinq explications pour comprendre ce qu’il voit, ce qu’il retient, ce qu’il prépare, ce qu’il peut déclencher et ce qui l’arrête, la délégation est déjà trop opaque.

4. Traiter le confort comme un signal d’alerte

Plus un système devient fluide, plus il faut se demander ce qu’il rend invisible. Le confort est un bénéfice réel. Il est aussi, très souvent, le moment où la vigilance décroît.

5. Organiser la reprise en main avant d’en avoir besoin

Une délégation saine doit rester réversible. Si l’on ne peut plus débrancher un outil sans perdre l’intelligibilité de sa pratique, l’accès à ses informations essentielles ou la possibilité d’agir sans lui, alors l’outil tient déjà une place excessive.

Un mini-workflow plus utile qu’une stack idéale

Pour beaucoup d’usages quotidiens, une discipline de délégation suffit déjà à faire une différence nette.

À garder sous garde directe

L’interprétation décisive d’une position, les arbitrages qui engagent du capital, de la réputation ou une relation, ainsi que les accès critiques : clés, secrets, permissions à large rayon d’action.

À assister sans trop de risque

Recherche exploratoire, cartographie d’un sujet, résumé, reformulation, comparaison, structuration de notes.

À déléguer seulement dans un périmètre borné

Veille, monitoring, préparation de brouillons, classements, automatisations à faibles conséquences.

À ne jamais déléguer sans friction explicite

Signature, mouvements de fonds, messages externes, actions irréversibles, modifications de permissions ou de paramètres critiques.

Ce second texte voulait rendre la question praticable

Nous ne sortirons pas de ce moment par le refus pur. Nous n’en sortirons pas non plus par l’abandon ravi.

Il nous faut autre chose : une manière d’habiter l’IA sans lui remettre d’un seul geste ce qu’elle rend justement plus difficile à discerner.

Cela suppose moins une pureté qu’une tenue. Moins une morale grandiose qu’un art des limites.

Le troisième texte déplace cette question sur son terrain d’épreuve le plus net : la DeFi, où toute délégation finit par prendre la forme d’une permission, d’une borne, d’un risque ou d’une architecture.

1. La prochaine étape du self-custody

Mon, 13 Apr 2026 11:00:00 +0000

Ouverture de série : Self-custody, mais jusqu’où ?

Nous avons appris à ne pas confier nos actifs à des dépositaires. Il nous reste à ne pas confier trop vite notre discernement à de nouveaux intermédiaires.

Le monde crypto s’est construit sur une intuition d’abord technique, dont la portée s’est révélée beaucoup plus vaste : lorsqu’un intermédiaire peut être retiré de l’équation, mieux vaut apprendre à vivre sans lui.

De cette intuition sont nés des wallets, des habitudes, des slogans, des gestes de prudence. Not your keys, not your coins n’a pas seulement appris à une génération d’utilisateurs à distinguer la commodité du contrôle. La formule a déplacé leur manière d’habiter le numérique.

Mais cette hygiène de la souveraineté n’a pas encore été transposée à la protection de nos propres facultés de jugement.

Nous savons demander où sont les fonds, qui contrôle les permissions, où se logent les points de capture. Nous savons moins bien demander où tourne le modèle, quelles données il voit, quelle part de notre travail il absorbe, ce qu’il prépare pour nous, ce qu’il nous évite de faire, et quelle dépendance s’installe à mesure qu’il devient indispensable.

Le centre de gravité s’est déplacé. On a beaucoup parlé des empires de la donnée. Il faut maintenant parler des empires de la délégation.

Le vrai déplacement

Le Web2 captait surtout nos traces : nos clics, nos préférences, nos graphes sociaux, notre attention.

L’époque actuelle ajoute une couche autrement plus intime. L’IA entre dans nos notes, nos archives, nos requêtes, nos lectures, nos résumés, nos routines de travail, notre tri de l’information, nos formulations provisoires, nos décisions préparatoires, parfois déjà certaines séquences d’action.

Elle n’est plus seulement un outil. Elle devient un milieu. Parfois un milieu de travail. Parfois un milieu mental.

Et dès qu’un outil devient un milieu, la question change de nature. Il ne s’agit plus seulement de savoir s’il est utile. Il faut demander ce qu’il reconfigure en nous : notre manière de lire, de hiérarchiser, de retenir, d’anticiper, d’arbitrer.

La minimisation de la confiance ne concerne plus seulement les actifs, les contrats ou les rails d’exécution. Elle touche quelque chose de plus difficile à conserver : son discernement.

Une contradiction très crypto

Le monde crypto a toujours été attiré par les outils qui donnent un avantage : plus de vitesse, plus de lisibilité, plus d’asymétrie informationnelle, plus de capacité à explorer, comparer, exécuter. Il est donc parfaitement logique qu’il soit parmi les premiers à adopter des copilotes persistants, des workflows augmentés, des couches agentiques, des systèmes qui gardent le contexte et compriment le temps de travail.

La contradiction n’est donc pas morale. Elle est structurelle.

Deux exigences légitimes entrent en collision. D’un côté, ne pas dépendre d’un tiers de confiance. De l’autre, gagner en vitesse, en clarté et en puissance de traitement grâce à des systèmes toujours plus performants.

La première a fondé une culture. La seconde est en train d’en déplacer les usages.

Et cette tension ne se résoudra pas à coups de slogans.

Le moment des setups

C’est aussi pour cela que la fascination actuelle pour les setups IA mérite d’être prise au sérieux.

Un builder pilote Claude depuis Telegram. Un autre laisse des agents se transmettre l’état d’une tâche dans des fichiers .md. Un troisième organise sa mémoire dans Obsidian, branche des outils de recherche, relie le tout à des workflows de code ou de veille, et commence sa journée avec l’impression que la machine a déjà travaillé pendant la nuit.

Rien de tout cela n’a quoi que ce soit de scandaleux en soi. Mais tout cela dit quelque chose de très précis sur notre actualité.

Nous ne cherchons plus seulement des réponses. Nous cherchons de la continuité.

Nous voulons des systèmes qui gardent le contexte, relient les éléments épars, retrouvent ce qu’il ne faut pas oublier, réordonnent nos notes, surveillent ce qu’il faut surveiller, préparent le terrain, et nous donnent l’impression qu’une part du travail a déjà été faite avant même que nous nous y remettions.

La promesse est puissante. Elle est aussi le point exact où la souveraineté doit être repensée.

Car il ne s’agit plus seulement de savoir si un outil nous espionne. Il faut demander ce qu’il prend en charge dans notre rapport au monde : mémoire, veille, pré-tri, classement, mise en relation, amorce du discernement. Autant d’opérations qui paraissent secondaires jusqu’au jour où l’on s’aperçoit qu’elles formaient déjà une part décisive de notre manière d’agir.

Morin, ou la mauvaise nouvelle utile

C’est ici qu’Edgar Morin redevient précieux.

Morin oblige à penser ensemble ce que nous préférerions séparer : autonomie ET dépendance, puissance locale ET effets d’ensemble, service rendu ET dépossession progressive. Sa leçon, appliquée à l’IA, est sévère mais salutaire : un outil d’augmentation peut devenir une infrastructure de déprise sans jamais cesser, localement, de rendre service.

Le danger ne prend donc pas nécessairement la forme d’une catastrophe visible. Il peut s’installer sous les traits du confort.

On s’aperçoit vite qu’on a confié ses fonds à un dépositaire douteux. On s’aperçoit plus tard qu’on a commencé à déléguer trop largement sa lecture, sa mémoire, sa manière de structurer le réel ou la préparation de ses décisions.

La dépendance cognitive ne ressemble pas toujours à une contrainte. Elle prend souvent la forme d’une aide devenue naturelle.

Le problème n’est pas seulement celui des modèles. C’est aussi celui du milieu logiciel.

La question ne se réduit ni aux grands modèles ni à l’opposition simpliste entre local et cloud.

Elle concerne aussi l’environnement que l’IA permet de faire proliférer autour des protocoles : dashboards, wrappers, outils d’analyse, assistants spécialisés, couches de monitoring, services de coordination, micro-produits développés très vite, parfois relus et solides, parfois non.

Il faut ici être précis. Utiliser l’IA pour produire du software n’a rien, en soi, de condamnable. Tout développement assisté par IA n’est pas du vibe coding au sens fort.

Le problème commence ailleurs : lorsque la vitesse de production d’un service baisse beaucoup plus vite que le coût de sa revue, de sa compréhension et de sa qualification.

Nous n’avons alors pas seulement plus d’outils. Nous avons plus de surfaces de confiance à évaluer.

Ce premier texte voulait simplement rendre la scène visible

La question n’est donc pas de savoir si l’IA est compatible avec la culture web3. Elle l’est déjà, et presque trop bien.

La vraie question est plus embarrassante : le monde crypto saura-t-il étendre à la cognition, à l’organisation et à l’action les exigences de souveraineté qu’il a appris à formuler pour les actifs ?

Nous savons désormais où se situe la faille. Car une culture de la self-custody qui ne se demanderait pas ce qu’elle remet à des intermédiaires cognitifs manquerait peut-être l’étape la plus décisive de son propre développement.

Reste à savoir comment vivre cette époque sans tomber ni dans l’enthousiasme sans bornes ni dans le refus stérile. Le texte suivant part de là : retrouver une discipline de la délégation assez ferme pour être réelle, assez simple pour rester praticable.

Intro — Self-custody, mais jusqu'où ?

Mon, 13 Apr 2026 10:00:00 +0000

Le monde crypto a appris à se méfier des dépositaires pour ses actifs. Il lui reste à étendre cette exigence à son discernement, à son organisation et, demain, à sa manière d’agir.

Pourquoi cette série

Le monde crypto a démontré une chose essentielle : lorsqu’il est possible d’éviter un intermédiaire, mieux vaut apprendre à vivre sans lui.

De cette intuition sont nés des wallets, des réflexes, des slogans, des architectures. Elle a fini par former une culture : self-custody, minimisation de la confiance, résistance à la capture, exigence de lisibilité sur les permissions et les points de contrôle.

Mais avec l’usage croissant de l’IA, quelque chose se dérègle.

Les mêmes milieux qui ont appris à se méfier des intermédiaires pour les actifs acceptent de plus en plus facilement de remettre leurs notes, leurs lectures, leurs routines de travail, leur mémoire de contexte, leurs arbitrages préparatoires, et bientôt des fragments de leur capacité d’agir, à des systèmes qu’ils ne maîtrisent ni complètement ni toujours très bien.

Le problème n’est donc plus seulement celui de la donnée. Il devient celui de la délégation.

Le déplacement est décisif. Le monde crypto sait déjà poser les bonnes questions pour l’argent : qui contrôle quoi, qui détient les clés, où se trouvent les points de capture, à quelles hypothèses de confiance consent-on ?

Reste à savoir s’il saura étendre cette exigence à ses processus de pensée, à son organisation et à la conduite de ses actions.

Ce que cette série veut rendre visible

Nous avons appris le self-custody pour les actifs.

Il nous reste à apprendre le self-custody du discernement.

Cette série suit donc une ligne simple.

Le premier texte nomme la contradiction : nous ne vivons plus seulement dans l’après-Web2 et ses empires de la donnée ; nous entrons dans un monde où se forment maintenant des empires de la délégation.

Le deuxième cherche texte à reconstruire une tenue. L’IA n’est plus seulement un moteur de réponses ; elle devient un milieu de travail, une mémoire de contexte, une couche d’organisation, parfois une préparation de l’action.

Le troisième montre pourquoi la DeFi est l’un des premiers lieux où cette question ne peut plus être éludée : la moindre délégation finit tôt ou tard par prendre la forme d’une permission, d’une borne, d’un risque ou d’une architecture.

La pensée d’Edgar Morin est le fil discret qui guide l’ensemble. Non comme autorité plaquée sur l’époque, mais comme discipline de lecture : tenir ensemble autonomie et dépendance, puissance locale et effets d’ensemble, service rendu et dépossession progressive. Bref, apprendre à lire un milieu complexe sans se raconter qu’une solution locale suffira à en épuiser les conséquences.

Ce que cette série ne promet pas

Ni une stack universelle. Ni une nouvelle pureté numérique. Ni un réquisitoire paresseux contre l’IA.

Elle essaie de faire quelque chose de plus utile : donner des critères pour discerner ce qu’on peut déléguer, ce qu’il faut garder, et ce qu’il faut désormais exiger des outils qu’on laisse entrer dans sa pratique.

Sovereignty on Arem

3. La DeFi, laboratoire de la délégation

En DeFi, une idée devient vite une autorisation, une gestion du risque ou une signature.

Le protocole ne résume plus le système

Ce que l’IA change au contexte

Vibe coding : loin du scandale, un révélateur

Deux protocoles pour rendre le problème visible

Money League : pousser plus loin l’horizon agentique

Polaris : rappeler la question de la constitution

Ce qu’ils montrent ensemble

Morin : aucune limitation locale n’abolit le problème du système

La vérifiabilité : aide précieuse, pas substitut au discernement

Ce que cette série voulait montrer

2. Déléguer sans renoncer

La question n’est plus d’utiliser l’IA mais de savoir jusqu’où la laisser entrer.

Assistance, délégation, abandon

Le vrai test : la facilité

Où commence la responsabilité individuelle

Ce second texte voulait rendre la question praticable

1. La prochaine étape du self-custody

Nous avons appris à ne pas confier nos actifs à des dépositaires. Il nous reste à ne pas confier trop vite notre discernement à de nouveaux intermédiaires.

Le vrai déplacement

Une contradiction très crypto

Le moment des setups

Morin, ou la mauvaise nouvelle utile

Le problème n’est pas seulement celui des modèles. C’est aussi celui du milieu logiciel.

Ce premier texte voulait simplement rendre la scène visible

Intro — Self-custody, mais jusqu'où ?

Pourquoi cette série

Ce que cette série veut rendre visible

Ce que cette série ne promet pas

Les trois textes

1. La prochaine étape de la self-custody

2. Déléguer sans renoncer

3. La DeFi, laboratoire de la délégation