Au cours de ces dernières années, le modèle de Rollup-as-a-Service (RaaS) a gagné de la place comme réponse pragmatique à un problème réel de l'écosystème blockchain : lancer et faire fonctionner une propre réseau est coûteux, complexe et exige un niveau de spécialisation que la plupart des équipes produit n'ont pas. Le RaaS apparaît donc comme une abstraction pratique. Il promet de réduire les barrières techniques, d'accélérer le time-to-market et de permettre aux équipes de se concentrer sur le produit, et non sur l'infrastructure.

Ce modèle remplit bien son rôle initial. Mais au fur et à mesure que les applications cessent d'être expérimentales et commencent à soutenir des flux économiques réels, des limites structurelles émergent, qui ne peuvent plus être traitées comme des détails techniques. C'est à ce stade que la discussion passe de « quel stack est le plus facile » à une question de souveraineté, de prévisibilité et de connectivité à long terme.

Cet article propose une analyse comparative sobre entre le RaaS traditionnel et l'approche de @Tanssi , avec un accent spécifique sur ces deux axes. L'intention n'est pas de déclarer des vainqueurs universels, mais de comprendre pourquoi des architectures différentes produisent des résultats différents lorsqu'elles sont confrontées à des cas d'utilisation réels.

Ce que le RaaS traditionnel résout, et où commencent les frictions

RaaS, dans sa forme la plus courante, offre un paquet géré pour le déploiement de rollups. L'équipe choisit une pile connue, définit certains paramètres et hérite d'une infrastructure prête : séquenceur, RPC, explorateur, pont standard, indexation et surveillance. Pour les MVP et les applications en phase initiale, cela fonctionne bien. Le coût cognitif est faible et la prévisibilité opérationnelle initiale est élevée.

Le problème survient lorsque l'application grandit et commence à dépendre de garanties plus fortes. Trois frictions apparaissent fréquemment.

La première est la souveraineté limitée. Bien que le discours soit de « réseau propre », la réalité est qu'une grande partie des décisions critiques reste conditionnée par la pile sous-jacente et l'écosystème de règlement. Des changements profonds dans la logique d'exécution, le modèle économique ou le comportement du réseau tendent à être difficiles ou invivables sans rompre la compatibilité.

La deuxième friction est le séquençage. De nombreux modèles de RaaS dépendent, au moins initialement, d'un séquenceur opéré de manière centralisée pour garantir les performances. Cela résout l'UX à court terme, mais crée une dépendance opérationnelle et un point unique de défaillance qui devient sensible à mesure que le volume augmente.

Le troisième est la connectivité. En général, l'interopérabilité et les ponts sont traités comme des intégrations externes. Cela fonctionne, mais cela ajoute des couches de dépendance, des surfaces de risque et des coûts opérationnels qui ne disparaissent pas avec le temps. Ils s'accumulent simplement.

Ces limites ne rendent pas le RaaS « mauvais ». Elles délimitent simplement clairement le type d'application pour lequel il est adapté.

Souveraineté comme variable économique, pas comme slogan

Lorsque nous parlons de souveraineté dans le contexte de cet article, nous ne parlons pas d'indépendance abstraite, mais de contrôle effectif sur quatre dimensions concrètes : exécution, économie, prévisibilité et gouvernance.

Le contrôle de l'exécution signifie pouvoir définir comment la logique du réseau fonctionne, sans être restreint à un ensemble fermé d'options. Le contrôle économique implique la politique des frais, des subventions, des incitations et comment le coût est perçu par l'utilisateur final. La prévisibilité concerne le débit et la latence stables, indépendamment du comportement des applications externes. La gouvernance concerne qui décide des changements structurels et à quelle vitesse.

L'approche de Tanssi part de la prémisse que, pour de nombreux cas d'utilisation matures, ces quatre dimensions ne peuvent pas être sous-traitées indéfiniment. C'est pourquoi, au lieu d'offrir uniquement des rollups configurables, Tanssi se concentre sur la viabilisation de L1s souverains, avec des runtimes modulaires qui permettent une personnalisation profonde de la logique du réseau sans exiger que chaque équipe construise et opère l'ensemble de l'infrastructure à partir de zéro.

En pratique, cela déplace la souveraineté du niveau du « stack choisi » au niveau de la chaîne elle-même. L'équipe contrôle l'exécution et l'économie, tandis que Tanssi agit comme une couche de provisionnement, de coordination et de fiabilité opérationnelle.

Infrastructure gérée sans dépendance excessive

Un point sensible dans toute comparaison est le compromis entre décentralisation et opérationnalité. La proposition de Tanssi n'est pas d'exiger que chaque projet monte son propre ensemble d'opérateurs, mais aussi de ne pas concentrer des fonctions critiques en un seul agent.

Cela apparaît, par exemple, dans le modèle de séquençage. Au lieu de dépendre exclusivement d'un séquenceur fixe, l'architecture prévoit des ensembles de séquenceurs attribués et rotatifs. L'objectif n'est pas d'atteindre un idéal théorique immédiat, mais de réduire les risques opérationnels réels sans sacrifier les performances.

De plus, l'existence de nœuds dédiés à la préservation des données et à la lecture historique renforce l'idée d'une infrastructure persistante. Pour les applications qui traitent de l'audit, de l'historique financier ou des données réglementaires, ce n'est pas un détail technique, mais une exigence fonctionnelle.

Connectivité comme partie de l'architecture, pas comme accessoire

Un autre point de distinction important réside dans la manière dont la connectivité est traitée. Dans le modèle de Tanssi, l'interopérabilité n'est pas seulement un ensemble d'intégrations optionnelles, mais un composant structurel.

Au sein de l'écosystème, la communication entre réseaux se fait de manière native, permettant l'échange de messages et d'actifs sans dépendre de solutions externes pour chaque cas. Pour l'accès à la liquidité et aux actifs d'Ethereum, le pont est conçu avec un modèle de confiance minimisée, évitant la dépendance à des gardiens ou à des multisigs opaques.

Cette combinaison réduit le coût cognitif et opérationnel de maintenir la connectivité au fil du temps, ce qui devient particulièrement pertinent lorsque l'application cesse d'être expérimentale.

Gotas : quand l'échelle de consommateur expose des limites architecturales

Le cas de Gotas aide à illustrer ces différences de manière concrète. La plateforme opère dans le contexte brésilien, avec un fort accent sur l'engagement des utilisateurs finaux et des marques. Ses chiffres sont pertinents : des centaines de milliers de portefeuilles, des millions d'interactions et des campagnes en temps réel.

Ce type de charge de travail rend inviable de dépendre d'un espace de bloc partagé imprévisible. Les campagnes promotionnelles, les échanges et les interactions doivent fonctionner indépendamment des congestions externes. De plus, la logique de récompenses nécessite des ajustements fréquents dans l'économie du réseau, ce qui est difficile à soutenir dans des piles rigides.

Le choix d'une L1 souveraine a permis à Gotas d'isoler son environnement d'exécution, de contrôler les coûts et de réduire la dépendance à un séquenceur unique, tout en maintenant en même temps la connectivité avec d'autres écosystèmes. Ici, la souveraineté n'apparaît pas comme une idéologie, mais comme une conséquence directe des exigences opérationnelles.

Rivool : prévisibilité comme exigence, pas comme bonus

Alors que Gotas expose des défis d'échelle de consommateur, Rivool met en évidence un autre type de pression : prévisibilité dans des contextes financiers et productifs.

Rivool agit, dans son cas d'utilisation initial, avec du crédit agricole on-chain, connectant les producteurs à des instruments financiers numériques. Dans ce scénario, la variabilité des taux, la latence imprévisible ou la dépendance à des décisions externes au réseau ne sont pas acceptables. La logique de crédit, de garanties et de délais exige un environnement contrôlé, auditables et stable.

Encore une fois, le choix d'une architecture souveraine n'est pas esthétique. Il répond directement à la nécessité d'aligner l'infrastructure blockchain aux responsabilités du monde réel.

Connectant les douleurs aux conceptions architecturales

En observant ces cas, il devient plus facile de comprendre où chaque modèle s'inscrit.

Le RaaS traditionnel reste une solution efficace pour les applications qui priorisent la vitesse de lancement et acceptent des limitations structurelles en échange de simplicité. L'approche de Tanssi a plus de sens lorsque l'application exige un contrôle approfondi sur l'exécution, l'économie et la connectivité, sans renoncer à une couche de support opérationnel.

Il ne s'agit pas d'une évolution linéaire, mais de choix architecturaux différents pour des stades et des besoins différents.

Considérations finales

Le marché de l'infrastructure blockchain est saturé de promesses génériques. Des comparaisons honnêtes exigent d'aller au-delà des slogans et d'observer comment les systèmes se comportent lorsqu'ils sont soumis à une charge réelle, à des utilisateurs réels et à des responsabilités réelles.

En positionnant Tanssi face au RaaS traditionnel, le point central n'est pas d'affirmer qu'un modèle remplace l'autre, mais de montrer que la souveraineté et la connectivité cessent d'être des « fonctionnalités avancées » lorsque les applications mûrissent. Elles deviennent des conditions de base pour que la blockchain cesse d'être simplement une couche expérimentale et commence à soutenir une économie réelle.