guides

Si vous maintenez un projet JavaScript, une question pratique revient sans cesse : à quelle fréquence les outils dont vous dépendez publient-ils réellement une nouvelle version ? Nous l'avons mesurée plutôt que devinée. À l'aide de l'API publique GitHub Releases, nous avons récupéré les 100 dernières versions de dix projets front-end très utilisés et séparé les véritables versions stables des préversions. L'écart s'est révélé bien plus large que prévu, et un projet se distingue d'une manière qui change la façon dont il faut lire ses numéros de version.

La méthode est volontairement simple pour que n'importe qui puisse la reproduire. Pour chaque dépôt, nous avons demandé les 100 versions publiées les plus récentes, exclu les brouillons, et marqué une version comme préversion si l'API la signalait comme telle ou si son tag contenait alpha, beta, rc, canary, next, experimental, nightly ou un suffixe -pre. La cadence stable est le nombre de jours entre la plus ancienne et la plus récente version stable de cette fenêtre, divisé par le nombre d'intervalles. Chaque chiffre ci-dessous est reproductible sur le même point d'accès public.

La surprise : Next.js publie 88 % de préversions

Le premier résultat est celui qui nous a surpris. Sur les 100 dernières versions publiées par Next.js, seules 12 étaient stables : 88 pour cent étaient des préversions. Ce n'est pas un signe d'instabilité, c'est un modèle de développement délibéré. Next.js publie des builds canary quasi en continu, et les fonctionnalités y atterrissent bien avant d'apparaître dans une version stable. Si vous suivez le flux de versions du dépôt en vous attendant à des versions stables, vous lirez surtout des canaries.

Cela compte en pratique. Un projet qui publie ses canaries comme des versions GitHub paraîtra énormément plus actif qu'un autre qui ne le fait pas, même si les deux publient des versions stables à un rythme comparable. Juger une dépendance au nombre de versions qui défilent vous renseigne sur ses habitudes de publication, pas sur sa stabilité ni sur sa vitesse de changement réel.

L'approche inverse : aucune préversion

À l'autre extrémité, deux projets de notre échantillon n'ont publié aucune préversion sur GitHub pendant la fenêtre : Svelte et React Router, tous deux à zéro. React et Preact en étaient proches, à 2 et 3 pour cent. Ces projets soit n'utilisent pas de préversions, soit ne les publient pas comme versions GitHub, si bien que leur flux de versions se lit comme une liste nette de versions stables.

• Sur les 100 dernières versions de Next.js, seules 12 étaient stables : 88 pour cent étaient des préversions (développement canary-first).
• Svelte et React Router n'ont publié aucune préversion sur GitHub sur la même fenêtre ; React et Preact étaient à 2 et 3 pour cent.
• La cadence stable s'étale sur un facteur d'environ quatre-vingts : Astro affiche une moyenne de 0,5 jour entre versions stables, React près de 40.
• Le nombre de versions, seul, induit en erreur : un projet qui publie ses canaries comme des versions paraît bien plus actif qu'un autre qui ne le fait pas.
• Méthode : les 100 dernières versions GitHub publiées par dépôt, brouillons exclus, préversions identifiées par le drapeau de l'API ou le tag, collecté le 2026-07-27.

Entre les extrêmes se trouvent les projets qui utilisent les préversions de manière substantielle mais non exclusive : Vue à 35 pour cent, Angular à 32, Astro à 31 et Vite à 28. Environ un tiers de ce qu'ils publient est un aperçu de quelque chose qui n'est pas encore terminé.

À quelle fréquence les versions stables sortent vraiment

En ne regardant que les versions stables, les jours qui les séparent se répartissent en groupes nets. Astro affiche une moyenne de 0,5 jour, Svelte 2,8, Angular 3,2 et Vite 4,3. Next.js se situe à 7,2 jours pour les versions stables, Nuxt à 11,9, React Router à 12,5 et Vue à 14,2. Preact affiche une moyenne de 19,1 jours, et React 39,7. Chaque chiffre est mesuré sur la fenêtre propre à chaque projet, celle de ses 100 dernières versions.

Ce qu'il faut retenir, c'est l'écart. Astro a publié une version stable toutes les demi-journées sur sa fenêtre, tandis que React affiche une moyenne de près de 40 jours entre versions stables : une différence d'un facteur d'environ quatre-vingts. Svelte, Angular et Vite se regroupent dans la plage de deux à quatre jours, Next.js autour d'une semaine pour les versions stables, et Nuxt, React Router et Vue entre douze et quatorze jours.

Rapide ne veut pas dire meilleur que lent

Ce serait une erreur de lire l'extrémité lente comme de la négligence. La fenêtre de React remonte à 2016 précisément parce qu'il publie peu de versions, grosses et bien espacées, ce qui est exactement ce que l'on attend d'une bibliothèque fondamentale dont dépendent des milliers de paquets. Une cadence rapide et une cadence lente sont des réponses à des questions différentes, pas un classement.

Pour un mainteneur, la leçon pratique porte sur les attentes. Si vous dépendez d'un projet du groupe sous la semaine, prévoyez des mises à jour fréquentes et petites, et appuyez-vous sur des mises à jour de dépendances automatisées et un lockfile, car relire chaque version à la main ne passera pas à l'échelle. Si vous dépendez d'un projet du groupe mensuel, les mises à jour sont plus rares mais tendent à porter plus de changements par version : budgétez donc plus de temps pour chacune.

Les limites de cette mesure

Les limites de cette mesure comptent autant que les chiffres, alors nous les énonçons clairement. La fenêtre correspond aux 100 dernières versions, ce qui couvre une période différente pour chaque projet : environ dix ans pour React mais seulement environ cinq semaines pour Astro. Ce sont des instantanés du comportement de publication actuel, pas des moyennes historiques comparables. Nous ne mesurons que les versions GitHub, donc un projet qui publie des préversions sur npm sans créer de version GitHub apparaîtra comme n'en ayant aucune. Les monorepos qui publient par paquet peuvent gonfler le nombre de versions. Et tous les chiffres ont été collectés le 2026-07-27 et vont évoluer.

Ce qu'il faut en retenir

La conclusion utile n'est pas qu'un projet vaut mieux qu'un autre. C'est que le nombre de versions, seul, est un mauvais signal. Avant de juger une dépendance à son activité, vérifiez quelle part de ces versions est réellement stable, et sur quelle période elles ont été publiées. Dans cet échantillon, le faire a transformé un projet apparemment hyperactif en un calendrier de publication hebdomadaire normal, enveloppé de canaries continus.