Imaginez un réseau qui, depuis des années, promet une montée en charge progressive sans jamais sacrifier sa sécurité fondamentale. C’est exactement le pari que Cardano s’apprête à tenir avec l’upgrade Dijkstra. Alors que beaucoup d’autres chaînes multiplient les hard forks précipités, l’équipe derrière le projet a choisi une voie plus lente, plus méthodique, et surtout plus transparente. Le calendrier officialisé récemment fixe deux jalons majeurs : Linear Leios d’ici la fin 2026, puis Ouroboros Peras au deuxième trimestre 2027. Derrière ces noms techniques se cache une transformation profonde de la façon dont les blocs sont validés, certifiés et finalisés.
Le découpage stratégique de Dijkstra en deux phases distinctes
Contrairement à ce que l’on pourrait croire, Dijkstra n’est pas un simple hard fork unique. Intersect, l’organisation qui coordonne une partie importante du développement, a clairement séparé le déploiement en deux temps. La première phase introduit l’ère ledger Dijkstra et active Linear Leios. La seconde phase, un an plus tard, active le protocole Peras via un hard fork intra-ère. Cette approche permet de tester chaque brique séparément et de réduire les risques de régression.
Le calendrier publié insiste sur un point essentiel : les dates restent des estimations. Les tests communautaires, les retours des opérateurs de pools et les votes de gouvernance peuvent facilement décaler l’activation mainnet. Pourtant, l’équipe Haskell vise une livraison de code complète pour la phase 1 avant la fin 2026. C’est un engagement clair, même s’il n’est pas juridiquement contraignant.
Linear Leios : le moteur de scalabilité de la phase 1
Linear Leios constitue le cœur technique de la première vague. Plutôt que de remplacer le modèle de sécurité Praos, il l’enrichit. Le principe repose sur l’introduction d’Endorser Blocks. Ces blocs particuliers peuvent référencer un ensemble supplémentaire de transactions et les faire certifier par des comités basés sur le stake. Le résultat attendu est une augmentation significative du débit sans modifier les garanties de base du consensus.
Concrètement, les transactions ordinaires continuent de vivre dans les blocs classiques. Les Endorser Blocks agissent comme une couche d’accélération. Ils permettent de traiter plus de volume pendant que la chaîne principale conserve sa solidité. Cette conception hybride explique pourquoi l’équipe insiste tant sur le fait que Linear Leios n’est pas une révolution brutale, mais une évolution contrôlée.
La phase 1 ne se limite pas à Leios. Elle apporte aussi les Nested Transactions, de nouvelles structures de sérialisation pour les transactions et les blocs, des évolutions PlutusV4 et plusieurs paramètres de protocole inédits. Tous ces éléments sont livrés ensemble pour préparer le terrain. Un détail souvent sous-estimé : les codecs et les paramètres nécessaires à Peras seront déjà installés, même si le protocole lui-même restera désactivé jusqu’en 2027.
Pourquoi Peras arrive seulement en 2027
Ouroboros Peras introduit une couche de vote. Des comités d’opérateurs de stake pools peuvent se prononcer sur les tips de chaîne récents. L’objectif est d’atteindre une finalité plus rapide que celle offerte par les règles de profondeur de chaîne classiques de Praos. En d’autres termes, les utilisateurs n’auront plus besoin d’attendre autant de confirmations pour considérer une transaction comme définitivement installée.
Ce mécanisme de vote nécessite que les structures de ledger et les paramètres de la phase 1 soient déjà en place. C’est la raison pour laquelle Peras ne peut pas être activé en même temps que Linear Leios. Le hard fork intra-ère prévu au deuxième trimestre 2027 suivra un processus classique : déploiement sur Preview, puis Pre-production, avant le vote de gouvernance mainnet.
Intersect a confirmé que cette feuille de route reste inchangée. Les équipes se concentrent désormais sur la préparation de l’écosystème, les rapports de testnet et le support des implémentations alternatives de nœuds. La coordination devient aussi importante que le code lui-même.
Amaru : vers une vraie diversité de nœuds
Un autre volet majeur de Dijkstra concerne la diversification des clients. Pendant longtemps, Cardano a dépendu presque exclusivement de l’implémentation Haskell. Cette situation créait un risque de point unique de défaillance. Amaru, un nœud écrit en Rust, change la donne.
Aujourd’hui, Amaru est déjà capable d’agir en tant que relais. Il valide et synchronise jusqu’au tip de la chaîne. L’objectif suivant est ambitieux : production de blocs sur le mainnet dès novembre 2026. Le tracker de développement d’Amaru détaille plusieurs jalons intermédiaires. Une version générale de block producer est attendue fin septembre, une version compatible Dijkstra fin octobre, et une version compatible Leios fin novembre.
Ces dates sont des objectifs de développement, pas des garanties d’activation mainnet. Pourtant, elles montrent une progression concrète. Intersect invite d’ailleurs les équipes de nœuds alternatifs à participer au Hard Fork Working Group hebdomadaire. La diversité n’est plus un slogan, elle devient une réalité technique.
La gouvernance doit avancer avant le code
Dijkstra introduit de nouveaux paramètres de protocole. Or, sur Cardano, ces paramètres ne peuvent être modifiés que s’ils figurent explicitement dans les garde-fous de la Constitution. Input Output prépare donc un amendement constitutionnel étroit. Il se limite à ajouter les paramètres concernés et les plages de valeurs autorisées. Aucun changement de rôles, de seuils de vote ou de principes constitutionnels n’est prévu.
La cible actuelle est de soumettre cette action de gouvernance au plus tard à l’époque 655, qui commence le 11 septembre 2026. Le portail d’amendement constitutionnel d’Intersect a déjà reçu plusieurs propositions. La discussion communautaire est ouverte et structurée. Sans cet amendement, certains paramètres de Dijkstra ne pourraient tout simplement pas être activés.
Cette séquence illustre parfaitement la philosophie Cardano : le code et la gouvernance avancent ensemble. On ne déploie pas d’abord et on ne demande pas l’autorisation ensuite. L’ordre est inversé, et c’est volontaire.
Ce que Linear Leios change concrètement pour les utilisateurs
Pour un utilisateur lambda, Linear Leios se traduira d’abord par une meilleure capacité à absorber les pics d’activité. Les applications décentralisées qui souffrent aujourd’hui de congestions devraient gagner en fluidité. Les frais, eux, dépendront toujours de la demande, mais le plafond de transactions traitables par unité de temps sera relevé.
Les Nested Transactions ouvrent également de nouvelles possibilités pour les développeurs. Des opérations complexes pourront être encapsulées plus proprement. PlutusV4 apporte des améliorations de langage qui faciliteront l’écriture de smart contracts plus efficaces et plus sûrs. L’ensemble forme un paquet cohérent plutôt qu’une collection de correctifs isolés.
Il faut toutefois rester réaliste. Linear Leios n’est pas une solution miracle qui multiplie le débit par cent du jour au lendemain. C’est une étape dans une trajectoire de scalabilité plus large. Les équipes elles-mêmes le présentent comme tel.
Peras et la question de la finalité rapide
La finalité reste l’un des points sensibles de nombreux protocoles proof-of-stake. Sur Cardano, les règles de profondeur de chaîne imposent d’attendre un certain nombre de blocs avant de considérer une transaction comme irréversible. Peras ajoute une couche de vote qui permet d’accélérer cette certitude.
Des comités d’opérateurs de pools se prononcent sur les tips récents. Si le vote atteint un seuil de consensus, la chaîne peut avancer plus vite vers une finalité économique. Ce mécanisme ne remplace pas Praos, il le complète. La sécurité reste ancrée dans le modèle existant, tout en offrant une expérience utilisateur plus proche de ce que proposent certaines chaînes concurrentes.
L’activation en 2027 laisse le temps de tester le comportement des comités, de mesurer les risques de collusion et d’ajuster les paramètres. C’est une approche prudente, caractéristique de la culture technique de Cardano.
Les risques de calendrier et les facteurs de retard
Le roadmap officiel le dit sans détour : les dates sont des cibles, pas des garanties. Plusieurs éléments peuvent retarder l’activation mainnet. Les tests de performance sur les testnets, les retours des opérateurs, les bugs de dernière minute, ou encore le temps nécessaire pour faire passer les votes de gouvernance. Chaque étape possède son propre rythme.
La phase 1 doit absolument être stable avant que la phase 2 ne démarre. Si Linear Leios rencontre des difficultés inattendues, Peras glissera automatiquement. Cette dépendance est assumée. Elle évite de superposer deux changements majeurs au même moment.
Intersect insiste aussi sur la nécessité de préparer l’écosystème. Les explorateurs de blocs, les portefeuilles, les outils de monitoring et les services d’indexation doivent tous être prêts. Un hard fork réussi ne se limite pas au code du nœud principal.
Le rôle d’Intersect dans la coordination
Depuis plusieurs mois, Intersect publie des mises à jour régulières. Celle du 14 août dernier a confirmé que le périmètre technique et le calendrier restaient inchangés. L’organisation oriente désormais ses efforts vers la préparation de l’écosystème, les rapports de testnet et le soutien aux nœuds alternatifs.
Le Hard Fork Working Group hebdomadaire devient un lieu de coordination important. Les équipes de nœuds, les développeurs d’applications et les opérateurs de pools y échangent. Cette gouvernance technique collégiale est l’une des particularités de Cardano. Elle ralentit parfois les décisions, mais elle réduit les risques de décisions unilatérales.
La transparence des communications permet à la communauté de suivre l’avancement sans dépendre uniquement des annonces marketing. Les trackers publics, les comptes rendus et les portails de discussion constituent une documentation vivante du processus.
Ce que cela change pour les développeurs d’applications
Les équipes qui construisent sur Cardano doivent anticiper deux vagues de changements. La première, fin 2026, apportera de nouvelles possibilités de conception grâce aux Nested Transactions et à PlutusV4. La seconde, en 2027, modifiera les attentes de finalité. Les applications qui reposent sur des confirmations rapides devront adapter leur logique métier.
Les bibliothèques de sérialisation devront être mises à jour. Les outils de simulation de frais et de charge devront intégrer les nouveaux paramètres. Les développeurs qui suivent déjà les testnets auront une longueur d’avance. Ceux qui attendent le dernier moment risquent de devoir courir.
La présence d’Amaru comme client alternatif est aussi une bonne nouvelle pour la résilience. Une application qui peut parler à plusieurs implémentations de nœuds est plus robuste. La diversité de clients devient un argument de robustesse technique, pas seulement un idéal théorique.
La place de Dijkstra dans la trajectoire longue de Cardano
Dijkstra s’inscrit dans une série d’upgrades qui, depuis plusieurs années, ajoutent des capacités sans jamais remettre en cause le modèle de sécurité de base. Chaque hard fork a apporté son lot d’améliorations. Van Rossem a préparé le terrain en passant au protocole version 11. Dijkstra reprend le flambeau avec une ambition de scalabilité plus marquée.
La philosophie reste la même : prouver mathématiquement autant que possible, tester longuement, gouverner de façon décentralisée. Cette approche contraste avec certaines chaînes qui privilégient la vitesse de déploiement au détriment de la formalisation. Les partisans de Cardano y voient une force. Les critiques y voient une lenteur excessive. Les deux lectures coexistent.
Ce qui est certain, c’est que le réseau arrive à un moment où la pression concurrentielle sur la scalabilité est forte. Linear Leios et Peras sont des réponses concrètes à cette pression. Elles ne prétendent pas tout résoudre d’un coup, mais elles avancent sur deux axes complémentaires : le débit et la finalité.
Les points de vigilance pour les prochains mois
Plusieurs indicateurs méritent d’être suivis de près. Le premier est l’avancement réel du code Haskell vers la complétion de la phase 1. Le deuxième est le rythme d’adoption d’Amaru par les opérateurs de pools. Le troisième est la capacité de la communauté à faire passer l’amendement constitutionnel dans les délais. Le quatrième est la qualité des tests sur les réseaux de préproduction.
Si l’un de ces piliers prend du retard, l’ensemble du calendrier glisse. C’est le prix de la méthode choisie. Cardano préfère un déploiement maîtrisé à un déploiement précipité. Cette culture est désormais bien ancrée.
Les prochains mois seront donc riches en publications techniques, en votes de gouvernance et en discussions sur les paramètres. La communauté a l’habitude de ce rythme. Elle sait que les annonces de calendrier sont des points de départ, pas des dates gravées dans le marbre.
Une transformation silencieuse mais profonde
Dijkstra ne fera peut-être pas la une des médias grand public. Pourtant, les changements qu’il apporte touchent au cœur du protocole. La façon dont les transactions sont groupées, certifiées et finalisées évolue. La diversité des nœuds progresse. La gouvernance s’adapte pour accueillir de nouveaux paramètres. Chaque élément, pris isolément, peut sembler technique. Ensemble, ils dessinent une nouvelle version de Cardano.
Linear Leios d’abord, Peras ensuite. Deux phases, deux temporalités, une même ambition : augmenter les capacités du réseau sans compromettre les fondations qui ont été posées au fil des années. Le calendrier 2026-2027 est désormais public. Il reste à le transformer en réalité opérationnelle.
Les équipes techniques, les opérateurs de pools, les développeurs d’applications et les détenteurs d’ADA auront tous un rôle à jouer. Les votes de gouvernance, les tests sur les testnets et les retours d’expérience seront décisifs. Cardano a choisi la voie de la co-construction. Dijkstra en est la prochaine illustration concrète.
Dans les mois qui viennent, chaque mise à jour d’Intersect, chaque jalon d’Amaru et chaque discussion sur le portail constitutionnel apportera un peu plus de clarté. Le chemin est tracé. La vitesse d’exécution dépendra de la capacité collective à le suivre avec la même rigueur que celle qui a présidé à sa conception.
La scalabilité n’est jamais un problème résolu une fois pour toutes. C’est un continuum d’améliorations. Dijkstra marque une étape importante de ce continuum. Linear Leios et Peras ne sont pas des points d’arrivée, mais des stations intermédiaires vers un réseau capable d’accueillir davantage d’usage tout en conservant ses propriétés de sécurité et de décentralisation.
Ceux qui suivent Cardano depuis longtemps reconnaîtront le style. Méthodique, documenté, parfois lent aux yeux de certains, mais cohérent avec la vision initiale. Pour les nouveaux arrivants, ce calendrier offre une fenêtre claire sur ce qui se prépare. Deux années de travail intense se profilent. Le résultat déterminera en grande partie la position concurrentielle de Cardano dans la deuxième moitié de la décennie.
Il reste encore beaucoup de travail. Le code doit être finalisé, les tests doivent être exhaustifs, la gouvernance doit suivre son cours. Mais le cadre est posé. Dijkstra n’est plus seulement un nom de code. C’est un plan d’exécution avec des jalons, des dépendances et des responsabilités clairement identifiées. La suite se jouera dans les détails de l’implémentation et dans la qualité de la coordination entre tous les acteurs de l’écosystème.
La phase 1 se prépare déjà. Les équipes Haskell avancent. Amaru gagne en maturité. Le portail d’amendement constitutionnel reçoit des contributions. Les testnets seront bientôt mis à contribution. Chaque brique s’ajoute à la précédente. C’est ainsi que Cardano a toujours procédé. Dijkstra ne déroge pas à la règle. Il l’applique à une échelle plus ambitieuse encore.
À l’horizon 2027, si le calendrier tient, le réseau disposera à la fois d’une meilleure capacité de traitement et d’une finalité plus rapide. Ces deux améliorations, combinées, devraient rendre Cardano plus attractif pour un plus large éventail d’applications. Le chemin est long, mais il est balisé. Et dans un écosystème où les promesses sont nombreuses, un calendrier transparent et une méthode rigoureuse restent des atouts rares.
Le véritable test commencera lorsque les premiers blocs Linear Leios apparaîtront sur les testnets. C’est à ce moment-là que les hypothèses de performance se confronteront à la réalité. Les mesures de débit, de latence et de consommation de ressources diront si le design tient ses promesses. En attendant, le travail de fond se poursuit, loin des projecteurs, dans les dépôts de code et les discussions techniques.
Cardano a choisi de ne pas précipiter. Dijkstra incarne ce choix. Deux phases, deux années, une progression mesurée. Pour ceux qui croient à la valeur de la méthode, c’est une confirmation. Pour ceux qui préfèrent la vitesse pure, c’est un rappel que d’autres priorités existent. Le débat n’est pas nouveau. Il se poursuit simplement avec de nouveaux arguments techniques et un calendrier concret.
Dans tous les cas, l’année 2026 s’annonce décisive pour la feuille de route de Cardano. Linear Leios en est le premier grand rendez-vous. Peras suivra. Entre les deux, le réseau aura le temps d’absorber les changements, de stabiliser les paramètres et de préparer la suite. C’est précisément ce temps d’adaptation que la conception en deux phases permet. Une décision de conception qui, une fois encore, privilégie la robustesse à la précipitation.
