Meteor.js est-il toujours pertinent en 2026 ?

Oui : Meteor.js est activement maintenu. La version 3.5.2 est sortie le 4 septembre 2026, d’après le changelog officiel.

Cela peut surprendre si votre dernier contact avec Meteor remonte à quelques années. Le framework bâti sur Fibers, les templates Blaze et un bundler maison de l’ère Babel a été remplacé, et ce qui l’a remplacé mérite d’être compris avant d’enterrer Meteor, ou avant de décider quoi faire d’une application 2.x dont vous avez la charge.

Cet article explique ce que Meteor a été conçu pour faire, pourquoi vous avez cessé d’en entendre parler, ce qui a réellement changé entre 2024 et 2026, et qui devrait — ou non — l’utiliser aujourd’hui.

Meteor.js est-il encore utilisé ? Les faits d’abord

Le framework publie à un rythme régulier. Le changelog recense 18 versions dans la branche 3.x, de la 3.0 en juillet 2024 jusqu’à la 3.5.2, en plus des 17 versions mineures de la série 2.x qui s’est étalée de janvier 2021 à mai 2024. Un détail utile si vous vérifiez par vous-même : le dépôt meteor/meteor ne publie aucune GitHub Release, si bien que l’onglet des releases paraît vide. C’est le changelog qui fait foi, pas GitHub.

Des utilisateurs en production existent toujours, la documentation est à jour, et l’équipe centrale fusionne des pull requests de la communauté à chaque version. Que tout cela fasse de Meteor un bon choix est une autre question, à laquelle répond la suite de cet article.

Pour quoi Meteor a-t-il été conçu ?

Le postulat de conception de Meteor, dès son lancement en 2012, était qu’une application temps réel ne devrait pas avoir besoin d’une couche API. Un seul langage s’exécute côté client, côté serveur et pour les requêtes de base de données. Le serveur publie des curseurs MongoDB via DDP, le protocole WebSocket de Meteor, et le client met les résultats en cache dans MiniMongo, une réimplémentation en mémoire de l’interface de requêtes Mongo. Lorsque les données changent sur le serveur, les clients connectés se mettent à jour automatiquement. Pas d’endpoints REST, pas de resolvers GraphQL, pas de code de synchronisation d’état.

Autour de ce noyau, Meteor embarquait tout ce dont une petite équipe avait besoin : intégration MongoDB, un système de comptes complet avec fournisseurs OAuth, un outil de build sans configuration et un déploiement en une commande. Entre 2012 et 2017, cet ensemble constituait un moyen véritablement plus rapide de livrer une application temps réel que tout ce qui existait dans le monde JavaScript, ce qui explique le nombre de cœurs et de hackathons qu’il a conquis.

Pourquoi avez-vous cessé d’entendre parler de Meteor ?

« React a gagné » n’est qu’un tiers de l’histoire. Blaze, la couche de templates maison de Meteor, a perdu face à React et n’a jamais rattrapé son retard, mais les blessures les plus profondes étaient organisationnelles. Vers 2016, Meteor Development Group a déplacé son attention vers Apollo et GraphQL, et le framework a visiblement cessé d’être la priorité de l’entreprise. L’hébergement gratuit meteor.com a disparu. Des figures importantes de la communauté sont parties, les tutoriels se sont périmés, et des packages sur Atmosphere ont été abandonnés.

Puis est venu l’élément décisif : l’attente de la version qui supprimerait Fibers. Fibers, la bibliothèque de coroutines qui donnait au code serveur de Meteor une apparence synchrone, bloquait les montées de version de Node et divergeait du fonctionnement de toutes les autres bases de code Node. Sa suppression a été discutée pendant des années avant que Tiny ne reprenne Meteor en octobre 2019, et Meteor 3.0 n’est sorti qu’à la mi-2024. Une grande partie de la communauté a cessé d’attendre. La marque est morte plus vite que la technologie, et la technologie a continué de s’améliorer dans le silence.

Qu’est-ce qui a changé entre Meteor 3.0 et 3.5 ?

Meteor 3.0, publié le 15 juillet 2024, a supprimé entièrement Fibers au profit de l’async/await natif et a remplacé Connect par Express comme couche HTTP. Les versions suivantes s’inscrivent dans une même trajectoire, d’après le changelog :

Le fil conducteur compte davantage que chaque ligne prise isolément : Meteor a cessé d’être un runtime sur mesure pour devenir une application Node.js ordinaire. Async/await au lieu de Fibers, Express au lieu de Connect, SWC et Rspack au lieu d’un pipeline Babel personnalisé, et les Change Streams au lieu du tailing de l’oplog. Les Change Streams imposent toutefois un prérequis : votre base de données doit être MongoDB 6 ou une version ultérieure, exécutée en replica set ou en cluster shardé. À défaut, Meteor bascule de lui-même vers le tailing de l’oplog ou le polling. C’est cette normalisation qui rend légitime le fait de réévaluer le framework.

Pour du code 2.x, la migration est mécanique dans sa forme : les appels de collection synchrones deviennent leurs équivalents asynchrones.

// Meteor 2.x
const doc = Tasks.findOne(taskId);
Tasks.insert({ text: "hello" });

// Meteor 3.x
const doc = await Tasks.findOneAsync(taskId);
await Tasks.insertAsync({ text: "hello" });

Côté performances : les chiffres de build publiés par Meteor, mesurés sur son application Galaxy Cloud, font état de builds environ 60 % plus rapides avec SWC et de builds plus de 3,5× plus rapides avec des bundles client jusqu’à 88 % plus légers avec Rspack. Un test de charge distinct, réalisé par l’équipe Meteor sur un conteneur Galaxy, rapporte une capacité de connexions simultanées supérieure de 40 % avec les Change Streams par rapport à l’oplog. À considérer comme des benchmarks d’éditeur.

Maintenu ne veut pas dire en bonne santé

Savoir si Meteor est maintenu et savoir si son écosystème est en bonne santé sont deux questions distinctes, avec des réponses différentes. Le framework publie ; l’écosystème qui l’entoure reste maigre. Le vivier de recrutement est restreint, et il s’est réduit pendant une décennie. Atmosphere, le registre de packages de Meteor, ne représente qu’une fraction de ce qu’offre npm dans l’écosystème dominant, et bon nombre des packages vers lesquels vous vous tourneriez sont des forks maintenus par la communauté à partir d’originaux abandonnés. La couche de données est centrée sur MongoDB par conception : si vos données sont relationnelles, vous luttez contre le framework.

Le vrai problème est celui de l’adéquation. La force principale de Meteor, pousser des données en direct via un socket vers des clients connectés, n’est tout simplement pas ce que la plupart des équipes cherchent à optimiser. Une large part du travail sous Node concerne des sites rendus côté serveur, orientés SEO et riches en contenu, et Meteor est le mauvais outil pour cette tâche. Si votre indicateur de succès implique Googlebot, choisissez quelque chose de conçu pour cela.

Faut-il utiliser Meteor.js en 2026 ?

En 2026, Meteor est maintenu, modernisé et constitue un choix raisonnable pour un ensemble précis de cas d’usage : les applications temps réel avant tout, comme les tableaux de bord, les messageries et les outils collaboratifs ; les outils internes où un langage unique et l’absence de couche API l’emportent sur la taille de l’écosystème ; et le prototypage rapide. Si vous avez une application 2.x, le chemin de mise à niveau vers la 3.x est bien réel, documenté dans le guide de migration officiel, et mérite d’être emprunté plutôt que de laisser l’application dépérir sur un runtime en fin de vie. Ce que Meteor n’est pas, c’est un choix par défaut polyvalent : le retenir pour un site de contenu ou une vitrine publique orientée SEO serait une erreur. Consultez le changelog par vous-même, lancez npx meteor sur un prototype si le besoin temps réel est avéré, et jugez le framework tel qu’il existe aujourd’hui plutôt que celui dont vous vous souvenez.

FAQ

Puis-je utiliser une base de données autre que MongoDB avec Meteor ?

C'est possible, mais vous perdez le principal atout du framework. La pile de réactivité de Meteor (publications, MiniMongo et le driver Change Streams) ne fonctionne qu'avec MongoDB, et le système de comptes intégré y stocke les utilisateurs. Des bases comme PostgreSQL fonctionnent via des drivers npm standards à l'intérieur des méthodes Meteor, mais vous écrivez votre propre code de chargement des données et ne bénéficiez d'aucune requête live. Si vos données sont relationnelles dès le premier jour, choisissez un autre framework.

Meteor 3 impose-t-il Blaze, ou puis-je utiliser React, Vue ou Svelte ?

Meteor est agnostique vis-à-vis de la couche de vue. La commande meteor create génère par défaut une application React, et des squelettes officiels existent pour Vue, Svelte, Solid et Blaze. Meteor fournit le système de build, la couche de données DDP et les comptes, tandis que la bibliothèque de votre choix se charge du rendu de l'interface. Blaze fonctionne toujours et reste maintenu par la communauté, mais l'essentiel de la documentation actuelle, des squelettes et de l'activité autour des packages présuppose React.

Puis-je faire évoluer une application Meteor 2.x directement vers la 3.x, ou faut-il des étapes intermédiaires ?

Le chemin recommandé commence en 2.x. Les méthodes de collection asynchrones (findOneAsync, insertAsync et les autres) ont été introduites dans Meteor 2.8 : vous pouvez donc convertir le code serveur progressivement tout en restant en 2.x, puis passer à la 3.x une fois que plus rien ne dépend des appels synchrones à la Fibers. Les packages Atmosphere tiers constituent le blocage habituel : chacun de ceux qu'utilise votre application doit proposer une version compatible 3.x avant que vous ne basculiez.

Ai-je besoin de Galaxy pour déployer une application Meteor ?

Non. La commande meteor build produit une application Node.js standard que vous pouvez exécuter sur n'importe quel hébergement fournissant Node et une connexion MongoDB : un VPS, Docker ou un fournisseur cloud. Galaxy est l'hébergement managé optionnel de Meteor Software. Un détail de déploiement compte en 3.5 : pour bénéficier de la réactivité par Change Streams, votre MongoDB doit être en version 6 ou ultérieure et configurée en replica set ou en cluster shardé. Sinon, Meteor revient de lui-même au tailing de l'oplog ou au polling, sans aucune configuration de votre part.