Imaginez une place de marché qui ouvre ses portes, allume les néons, aligne les étals, puis demande encore un peu de patience avant le premier échange. C’est à peu près l’image que donne THORChain ce 2 octobre 2026 : le pool Zcash est bien là, les nœuds surveillent déjà la chaîne, mais le trading natif n’a pas basculé. Entre une promesse de venue permissionless et un avertissement très clair sur une liquidité encore mince, le protocole place ZEC dans une zone grise que les marchés détestent autant qu’ils guettent. Rien n’est anodin dans ce calendrier. Zcash n’est pas un actif quelconque, THORChain n’est pas un pont ordinaire, et le contexte des semaines précédentes n’a rien d’un simple lancement technique.
Le message officiel tient en quelques phrases sèches. Le churn est terminé. Chaque nœud regarde désormais Zcash. La venue se veut vraiment permissionless. Le trading est l’étape suivante. La liquidité restera faible au départ et montera avec le temps, d’où l’appel à la prudence dès les premiers jours. Aucun chiffre de profondeur n’accompagne l’annonce. Aucune heure précise de bascule non plus. Cette retenue, rare dans un secteur qui aime les comptes à rebours, dit déjà beaucoup sur la manière dont le réseau aborde l’arrivée d’une chaîne à la mécanique particulière.
Un pool ouvert avant le premier échange
La distinction peut sembler scolaire. Elle ne l’est pas. Activer un pool et autoriser les swaps, ce n’est pas la même opération. Le premier geste crée un réservoir d’actifs et une présence protocolaire. Le second ouvre le robinet des échanges pour les utilisateurs. THORChain a choisi de séparer les deux, et de le dire sans détour : trading is the next step. En français courant, le trading vient après. Le pool existe. Le marché, lui, attend encore le feu vert.
Pourquoi cette séquence ? Parce qu’un pool de liquidité n’est utile que si les nœuds savent déjà lire la chaîne source, valider les dépôts, calculer les frais et signer sans se contredire. Zcash impose une grammaire UTXO, des règles de frais qui ne ressemblent pas à celles de Bitcoin, et une logique d’expiration de transaction capable de faire diverger des nœuds s’ils ne regardent pas la même hauteur. Lancer les échanges avant que cette grammaire soit stable reviendrait à ouvrir une caisse alors que les caissiers ne comptent pas encore de la même façon.
Sur l’explorateur du réseau, ZEC apparaît déjà comme suivi, au même titre que Bitcoin, Ethereum et d’autres chaînes affichées pour un nœud actif. Ce statut « OK » ne signifie pas que le carnet d’ordres déborde. Il signifie que la surveillance est en place. Pour un protocole dont la promesse repose sur des actifs natifs, sans version enveloppée, cette surveillance est le vrai sas d’entrée. Tant qu’elle n’est pas partagée par l’ensemble des nœuds, le pool n’est qu’une intention.
Repère du 2 octobre
Pool activé, nœuds en observation, trading encore en attente, profondeur non chiffrée. La prudence n’est pas une formule de style : elle est le mode d’emploi du premier jour.
Ce que « permissionless » veut dire ici
Le mot revient souvent, parfois jusqu’à l’usure. Ici, il a un sens opératoire. Une venue permissionless n’exige pas qu’un émetteur liste l’actif, ni qu’un gardien central approuve chaque dépôt. L’utilisateur conserve un actif natif. Le protocole route l’échange via son actif de règlement, RUNE, qui siège dans les pools et sert de pivot entre chaînes supportées. Pas de jeton enveloppé à fabriquer, pas de coffre unique qui concentre la garde. C’est le modèle que la documentation du réseau décrit depuis longtemps : une collection de pools de liquidité continue, capables de traiter des actifs natifs.
Cette architecture a un prix. Elle déplace la confiance vers les nœuds, les règles de solvabilité et la qualité du code spécifique à chaque chaîne. Ajouter Zcash, ce n’est pas coller un logo sur une interface. C’est apprendre à une machine collective à parler UTXO selon les règles de ZEC, à mesurer le gaz, à refuser la poussière, à respecter le rythme des blocs et à n’accepter un dépôt que lorsqu’il remplit des conditions d’entrée précises. Le travail préparatoire, étalé sur plusieurs mois, montre que le réseau a traité cette intégration comme un chantier, pas comme une annonce marketing.
Pourquoi la liquidité mince change tout
Un pool peu profond ne se comporte pas comme un grand lac. Une ordre modeste y déplace le prix davantage, le glissement s’élargit, et l’arbitrage met plus de temps à recoller les écarts. THORChain le dit sans chiffre : la liquidité est faible pour l’instant, elle grossira, il faut trader avec prudence au début. L’absence de profondeur publiée n’est pas un détail. Sans taille de pool, sans estimation de glissement, un utilisateur ne peut pas distinguer une opportunité d’un piège de prix.
Les premiers jours d’un nouveau pool attirent deux profils qui se croisent mal. D’un côté, les fournisseurs de liquidité qui veulent capter des frais sur un actif peu présent ailleurs en version native. De l’autre, des traders qui testent le routage, parfois avec des montants trop gros pour le réservoir. Le résultat classique est une volatilité locale, décorrélée du marché spot plus large. ZEC peut bouger « normalement » sur les places établies et, au même moment, afficher un prix déformé dans un pool naissant. Ce n’est pas une anomalie du protocole. C’est la physique d’un réservoir étroit.
La consigne pratique tient en une discipline simple. Fractionner. Comparer. Ne pas confondre la présence d’un pool avec la présence d’un marché profond. Attendre que le trading soit effectivement ouvert avant de raisonner en termes d’exécution. Et accepter que les premiers blocs d’activité servent autant à observer le comportement des nœuds qu’à échanger.
Le calendrier réel, pas le récit accéléré
Le 2 octobre n’est pas une apparition spontanée. Le 4 mars, une mise à niveau du protocole avait déjà ajouté la gestion UTXO propre à Zcash et la logique RPC associée. Un autre changement avait placé ZEC dans l’oracle enchâssé du protocole, afin que le prix natif soit suivi à l’intérieur de la logique du réseau, et non bricolé à côté. En mars encore, un correctif a retouché le reporting des frais réseau et les calculs de solvabilité. En septembre, un autre correctif a traité des divergences de signature liées à l’expiration des transactions. Le 17 septembre, le blog du projet présentait Zcash comme prochain sur le mainnet, tout en gardant le calendrier conditionnel, après une période centrée sur la stabilité.
Lire cette suite dans l’ordre évite une erreur fréquente : prendre l’annonce du pool pour le début du travail. C’est la fin visible d’une chaîne de correctifs. Le churn du 2 octobre, ce moment où les nœuds tournent et où l’ensemble se met à observer Zcash, est le point où le chantier devient un état du réseau. Le trading, lui, reste une porte encore fermée.
Le pool est vivant. La surveillance est collective. L’échange utilisateur n’est pas encore l’étape en cours.
Ce que les nœuds surveillent vraiment
Dire que « chaque nœud regarde Zcash » peut sonner abstrait. Concrètement, un nœud doit voir les blocs, reconnaître une adresse valide, estimer un frais acceptable, repérer un dépôt entrant et refuser ce qui ne respecte pas le seuil de poussière ou le format attendu. Zcash a été classé comme chaîne UTXO, avec des réglages dédiés : validation d’adresse, unités de gaz, seuils de poussière, cadence de blocs, paramètres de coinbase, exigences sur les transactions entrantes. Chacun de ces réglages est une porte. Une seule mal calée suffit à faire entrer un dépôt que le reste du réseau ne saura pas solder, ou à rejeter un dépôt légitime.
Le churn compte ici plus que le communiqué. Tant que tous les nœuds actifs n’observent pas la même chaîne avec les mêmes règles, le consensus sur un dépôt reste fragile. Le fait que l’ensemble soit passé en observation le même jour réduit ce risque de décalage. Il ne l’élimine pas pour les cas limites, notamment ceux qui touchent à l’expiration et à la hauteur utilisée pour signer. C’est précisément le sujet du correctif de septembre.
L’oracle enchâssé, prix interne plutôt que prix collé
Placer ZEC dans l’oracle du protocole n’est pas une coquetterie. Un réseau qui route des swaps a besoin d’une référence de prix cohérente avec ses propres règles, ne serait-ce que pour surveiller la solvabilité et éviter qu’un pool ne dérive sans que les nœuds s’en aperçoivent. Un oracle enchâssé signifie que ce suivi vit dans la logique protocolaire, pas dans un module externe que l’on pourrait ignorer. Pour un actif dont le marché spot est plus étroit que celui de Bitcoin ou d’Ether, cette référence interne devient un garde-fou. Elle ne remplace pas la profondeur. Elle empêche seulement le protocole d’être aveugle.
Il reste une limite évidente. Un oracle dit ce que vaut un actif selon ses sources et ses règles. Il ne crée pas d’acheteurs. Si le pool est mince, le prix exécuté peut s’écarter de la référence sans que l’oracle soit « faux ». L’utilisateur voit alors deux vérités : celle du protocole, et celle de son glissement. Les confondre est le meilleur moyen de sortir perdant d’un premier échange.
Le piège des frais ZIP-317
Le correctif de mars mérite qu’on s’y arrête, parce qu’il touche à l’argent réel du réseau : les frais et la solvabilité. L’implémentation précédente pouvait gonfler la tolérance au gaz. Le frais complet prévu par ZIP-317 était traité, dans un calcul de solvabilité, comme s’il s’agissait d’un taux par octet. Le correctif fusionné a changé la manière dont la taille de transaction était prise en compte pour ZEC. En clair, le réseau risquait de croire qu’une opération coûtait autre chose que ce qu’elle coûtait, et d’en tirer une conclusion fausse sur sa capacité à rester solvable.
Ce genre de bug ne fait pas la une. Il fait les incidents, six semaines plus tard, quand un volume inattendu révèle l’erreur. Le fait qu’il ait été corrigé avant l’ouverture du pool est un signe de sérieux. Ce n’est pas une garantie. Les frais Zcash ne se calculent pas comme les frais Bitcoin, et toute intégration UTXO qui copie un réflexe bitcoinien se trompe. ZIP-317 a précisément été conçu pour sortir d’une logique trop rudimentaire. Un protocole tiers qui le relit mal recrée le problème qu’il croyait avoir importé.
Pour l’utilisateur, la conséquence est indirecte mais nette. Des frais mal estimés dégradent l’expérience, retardent les confirmations, ou poussent le réseau à refuser des transactions qu’il aurait dû accepter. Dans un pool jeune, ces frictions se confondent avec la faible liquidité. On accuse le marché alors que c’est parfois le compteur qui déraille. Le correctif de mars visait ce compteur.
Quand deux nœuds ne signent pas la même chose
Le chantier de septembre est plus subtil, et plus dangereux s’il reste ouvert. Des incohérences de signature apparaissaient lorsque l’expiration d’une transaction ZEC était calculée à partir de pointes de chaîne locales différentes. Deux nœuds, deux hauteurs locales, deux empreintes de signature. Pour un réseau qui doit s’accorder, c’est un poison lent. Chacun croit signer le bon message. Le collectif n’arrive pas à une transaction unique.
Le changement fusionné attache l’expiration à une hauteur ZEC convenue, figée à une hauteur THORChain donnée, et conserve cette valeur pendant les nouvelles tentatives et les redémarrages. Des mises à jour périodiques de cette hauteur convenue passent par les rapports de frais réseau. Les tentatives de signature expirées sont traitées autrement. L’idée est simple : ne plus laisser chaque machine recalculer l’expiration depuis sa propre pointe. Une hauteur commune, un message commun, une signature qui peut être vérifiée par les autres.
Ce point explique en partie la prudence du 2 octobre. Ouvrir le trading alors que l’expiration pouvait encore diverger aurait multiplié les transactions coincées, les retries incohérents et les doutes sur la solvabilité. Attacher l’expiration à une hauteur convenue ne rend pas Zcash « facile ». Cela rend le désaccord visible et corrigeable. C’est le minimum pour une chaîne que l’on prétend surveiller ensemble.
RUNE, le pivot que l’on oublie trop vite
On parle de ZEC. Le rouage, lui, s’appelle RUNE. Dans ce modèle, l’actif de règlement siège dans les pools et sert de route entre chaînes. Un échange Zcash vers un autre actif natif ne se fait pas par un couloir direct unique dans tous les cas de figure : il passe par la logique de pools continus dont RUNE est le pivot. Cela a deux effets. Le premier est une composabilité réelle, sans envelopper ZEC. Le second est une exposition indirecte à la profondeur des pools RUNE concernés. Un pool ZEC mince, adossé à un pivot lui-même tendu, amplifie le glissement.
Les fournisseurs de liquidité ne déposent donc pas « dans le vide ». Ils entrent dans une paire dont le comportement dépend du flux cross-chain, des frais, et de la capacité du réseau à rester solvable. Les premiers déposants captent une part plus grande des frais, et portent aussi une part plus grande du risque d’écart de prix. Ce n’est pas un défaut du lancement. C’est le contrat implicite d’un pool jeune. Le protocole le rappelle en demandant la prudence. Il appartient à chacun de la prendre au sérieux, surtout tant que le trading n’est pas officiellement l’étape en cours.
| Étape | État au 2 octobre | Ce que cela change |
|---|---|---|
| Code UTXO et RPC | Intégré depuis mars | Le réseau sait parler Zcash |
| Oracle enchâssé | ZEC suivi en interne | Référence de prix protocolaire |
| Frais et solvabilité | Correctif ZIP-317 mergé | Moins de tolérance au gaz gonflée |
| Expiration des signatures | Hauteur ZEC convenue | Moins de digests divergents |
| Churn et observation | Tous les nœuds actifs | Surveillance collective réelle |
| Trading utilisateur | Étape suivante | Le robinet n’est pas encore ouvert |
Zcash n’est pas un ticker de plus
Ajouter une chaîne connue pour ses options de confidentialité n’a pas le même écho qu’ajouter un réseau de contrats générique. Zcash repose sur une base UTXO et sur des constructions cryptographiques qui permettent, selon l’usage, des transferts plus opaques que ceux d’une chaîne entièrement transparente. Cette propriété est défendue par une partie des utilisateurs comme une condition de la fongibilité : un jeton traçable à vie n’est pas équivalent à un autre. Elle est critiquée par d’autres comme un obstacle au contrôle des flux illicites. Le lancement d’un pool natif ne tranche pas ce débat. Il le déplace sur un protocole qui, par conception, ne veut pas choisir les adresses.
C’est là que le 2 octobre cesse d’être un simple fait technique. Le même réseau vient de refuser, quelques jours plus tôt, de bloquer sélectivement des flux liés à un vol massif. Ouvrir Zcash juste après, ce n’est pas prouver un lien. C’est ajouter un actif sensible à un protocole déjà au centre d’une dispute sur ce qu’il peut, et ne peut pas, refuser. Les lecteurs pressés colleront les deux sujets. Les lecteurs rigoureux les tiendront ensemble sans les fusionner : l’un concerne la capacité d’échange, l’autre concerne les limites d’un arrêt d’urgence.
Le contentieux qui colle aux swaps
Le contexte est lourd, et il serait malhonnête de lancer le pool comme si la semaine précédente n’existait pas. Bitget a indiqué que des transferts non autorisés avaient commencé le 24 septembre, puis a relevé le montant dirigé vers des adresses contrôlées par l’attaquant à environ 387,5 millions de dollars, une fois inclus des mouvements liés à Zcash et à Tron. L’enquête associe, selon la plateforme, Mandiant et SlowMist à ses équipes sécurité et technique. Les actifs cités couvrent un éventail large : XRP, ETH, USDT, ZEC, USDC, XAUt, BNB, AVAX, TRX. Des adresses de réception principales ont été publiées sur plusieurs réseaux.
Dans ce dossier, un portefeuille lié à l’attaquant a réalisé 27 swaps via THORChain, convertissant environ 2 390 ETH en 75,2 BTC, pour une valeur d’environ 6,3 millions de dollars au moment des faits. Bitget avait demandé au protocole de refuser les transactions venant d’adresses liées à l’attaquant. La réponse a été un refus de restriction sélective. Les mécanismes d’arrêt d’urgence, a expliqué le réseau, protègent les opérations et la solvabilité. Ils ne fournissent pas un moyen de geler une adresse ou un swap en particulier.
Le 1er octobre, un texte du projet a précisé la position. Les opérateurs de nœuds peuvent mettre en pause une chaîne, ou le protocole entier, lorsque la solvabilité est en jeu. Le même système d’urgence ne peut pas retirer sélectivement une transaction. Les décisions majeures exigent l’adoption par les opérateurs, avec un seuil de consensus des deux tiers pour les changements importants du réseau. Cette architecture est cohérente avec un modèle permissionless. Elle est aussi, aux yeux des plateformes lésées, une fin de non-recevoir.
Mettre en pause pour sauver la solvabilité n’est pas la même action que barrer une adresse. Le protocole affirme pouvoir faire la première, et pas la seconde.
Bybit, le précédent qui revient à chaque incident
La dispute ne naît pas en septembre 2026. Elle rejoue un épisode de février 2025, lorsque le vol subi par Bybit, d’environ 1,5 milliard de dollars d’actifs virtuels, a été attribué par le FBI à l’activité TraderTraitor liée à la Corée du Nord. L’agence avait alors appelé plateformes, ponts, opérateurs RPC, services de finance décentralisée et autres acteurs à bloquer les transactions liées aux adresses identifiées. Le directeur général de Bybit, Ben Zhou, a déclaré que 72 % d’environ 900 millions de dollars d’actifs convertis étaient passés par THORChain. Ce chiffre lui est attribué. Ce n’est pas une estimation du protocole.
Un autre regard sur l’activité de la période de blanchiment initiale évoquait 2,91 milliards de dollars de volume d’échange et environ 3 millions de dollars de frais, en citant l’analyste on-chain Yu Jin. Là encore, il s’agit d’une lecture externe, pas d’un bilan officiel. Elle suffit toutefois à expliquer pourquoi chaque nouveau pool rallume la même question : un protocole qui ne filtre pas les adresses devient, mécaniquement, un couloir utile pour qui veut sortir d’un actif vers un autre, vite, sans dépositaire unique.
Deux lectures s’opposent, et aucune n’a besoin d’être caricaturée. La première dit qu’un outil neutre n’est pas complice de l’usage qu’on en fait, et qu’un gel sélectif transformerait les nœuds en censeurs sans mandat clair. La seconde dit que la neutralité, lorsqu’elle persiste après identification publique d’adresses, devient un choix politique, pas seulement une contrainte technique. Le texte du 1er octobre tente de sortir de ce dilemme en distinguant pause de solvabilité et filtre d’adresse. Le dilemme, lui, ne sort pas du débat public.
La prime de 5 % et ses limites
La page de récupération liée à Bitget liste des adresses d’attaquant sur des réseaux EVM, sur le XRP Ledger, sur Zcash et sur Tron, et propose une prime de 5 % aux parties éligibles dont le travail volontaire aboutit directement à un gel ou à une récupération. Une prime n’est pas un bouton d’arrêt. Elle déplace l’incitation vers ceux qui peuvent, ailleurs, faire geler des fonds : plateformes, prestataires, parfois autorités. Elle ne change pas la règle interne d’un protocole qui dit ne pas pouvoir retirer une transaction isolée.
Pour Zcash, cette liste a un poids symbolique supplémentaire. L’actif figure à la fois parmi les avoirs touchés par le dossier Bitget et parmi les chaînes que THORChain vient d’apprendre à surveiller. Cela ne signifie pas que le pool du 2 octobre sert ce dossier. Cela signifie que le même ticker circule dans deux récits que le public va superposer : celui de l’intégration technique, et celui de la récupération. Un article honnête tient les deux récits visibles, sans fabriquer un lien que les faits publiés ne démontrent pas.
Ce que les utilisateurs peuvent vérifier eux-mêmes
Avant le premier échange, quelques contrôles valent mieux qu’un fil de rumeurs. Le statut de chaîne sur un nœud actif doit rester cohérent. Le trading doit être annoncé comme ouvert, pas seulement « prochain ». La profondeur, dès qu’elle devient visible, doit être lue en montant et pas en slogan. Le glissement estimé d’un ordre test, même minuscule, dit plus qu’un prix affiché. Les frais ZEC doivent rester compréhensibles au regard de ZIP-317, sans tolérance aberrante. Enfin, toute transaction qui expire ou qui repart en signature mérite une seconde lecture : c’est exactement le scénario que le correctif de septembre voulait stabiliser.
- Ne pas confondre pool ouvert et trading ouvert.
- Traiter la liquidité initiale comme un réservoir étroit, pas comme un marché.
- Comparer le prix exécuté à une référence externe avant d’augmenter la taille.
- Surveiller les retries : une expiration recalculée était le bug à éviter.
- Séparer le chantier technique du contentieux sur les adresses.
Ces réflexes ne rendent pas un pool sûr. Ils évitent les erreurs les plus chères, celles qui viennent de la hâte. Un lancement sans heure de trading et sans profondeur chiffrée est, en soi, une information. Il dit que le réseau préfère une porte entrouverte à une ouverture bruyante. Les marchés impatients liront cela comme un retard. Les opérateurs liront cela comme une séquence.
Ce que le pool ne règle pas
Un pool natif ne rend pas ZEC plus liquide sur l’ensemble du marché. Il ajoute un lieu. Si ce lieu reste mince, il peut même, à la marge, fragiliser le prix local sans améliorer le prix global. Un pool natif ne règle pas non plus la question des échanges déjà passés par le protocole dans des dossiers de vol. Il n’efface pas le précédent Bybit, ni les 27 swaps évoqués dans le dossier Bitget. Il ne crée pas un filtre d’adresse que le réseau dit ne pas avoir.
En revanche, il teste une promesse que peu de lieux tiennent jusqu’au bout : échanger un actif natif sans le transformer en version gardée. Pour une partie des détenteurs de ZEC, c’est le seul critère qui compte. Pour une autre, le critère décisif reste la capacité d’un réseau à coopérer lorsqu’une adresse est publiquement liée à un vol. Les deux critères ne se rangent pas sur la même ligne. Le 2 octobre les pose côte à côte, sans les réconcilier.
Lecture froide des prochains jours
Trois signaux méritent plus d’attention qu’un nouveau communiqué. Le premier est l’ouverture effective du trading, avec une formulation aussi nette que celle du 2 octobre. Le deuxième est l’apparition d’une profondeur qui cesse d’être « faible » au sens où le protocole l’entend, c’est-à-dire une profondeur où un échange modeste ne déforme plus le prix. Le troisième est le comportement des signatures sous charge : si les hauteurs convenues tiennent, le correctif de septembre aura passé son vrai examen. S’ils divergent à nouveau, le pool pourra rester ouvert tout en devenant impraticable.
Il faudra aussi regarder si la liquidité vient de déposants patients ou d’allers-retours opportunistes. Un pool qui grossit par à-coups, puis se vide, n’est pas un marché. C’est une scène. Zcash a déjà une scène ailleurs. Ce qui manquait, aux yeux du protocole, c’était une venue native et permissionless. Ce qui manque encore, aux yeux de l’utilisateur, c’est la preuve que cette venue peut encaisser un flux sans se tordre.
Le débat sur les pauses restera en fond. Tant que la règle publique distingue solvabilité et adresse, chaque incident extérieur reposera la même demande, et recevra la même réponse, sauf changement adopté par au moins deux tiers des opérateurs. Ce seuil n’est pas un détail de gouvernance. C’est la condition pour qu’une exception devienne une règle. En l’absence de cette adoption, le pool Zcash héritera de la doctrine déjà écrite le 1er octobre.
Une intégration qui se juge sur la durée
Les lancements crypto se jugent souvent à l’heure. Celui-ci se juge mieux sur la saison. Mars a posé la langue UTXO, l’oracle et le correctif de frais. Septembre a figé une hauteur commune pour l’expiration et a annoncé Zcash comme prochain, sous condition. Le 2 octobre a fait tourner les nœuds et a allumé le pool. La suite n’est pas un mystère marketing. C’est une liste courte : ouvrir le trading, laisser la liquidité grossir, tenir les signatures, ne pas confondre pause et filtre.
Si cette liste se coche sans incident de solvabilité, le pool deviendra un lieu parmi d’autres, avec l’avantage d’un actif natif. S’il se coche dans le bruit d’un nouveau dossier de fonds détournés, il deviendra surtout un argument dans une dispute plus vieille que lui. Les deux issues restent ouvertes le jour même de l’annonce. C’est précisément pour cela que la phrase la plus utile n’est pas « le pool est live ». C’est l’autre : tradez avec prudence, la liquidité est encore faible, le trading vient après.
Pour qui suit Zcash, l’intérêt est réel : une route native de plus, construite lentement, assumée comme permissionless. Pour qui suit la sécurité des plateformes, l’intérêt est ailleurs : un protocole qui répète, à la veille de ce lancement, qu’il ne retirera pas une transaction isolée. Tenir les deux intérêts dans la même lecture, sans les fondre, est la seule façon de ne pas se raconter d’histoire. Le pool est ouvert. La porte des échanges, elle, attend encore qu’on la pousse.
