TanStack Start est toujours en Release Candidate. Une équipe y a quand même migré un SaaS en production.

Adopter un framework avant qu’il atteigne la 1.0 est un pari : que l’équipe derrière tiendra ce qu’elle a promis, et que votre propre code n’aura pas besoin de ce qui sort dans l’intervalle entre Release Candidate et stable. La plupart des comparatifs entre un framework pre-1.0 et un framework établi restent hypothétiques — une todo-list construite deux fois puis benchmarkée. Ce que ça élude, c’est la partie qui compte vraiment : ce qui se passe quand quelqu’un fait ce pari sur un produit payant.

Un cas documenté montre exactement ça. Melvyn Malherbe, qui développe la plateforme de formation en ligne Codeline, a migré son application de production réelle — parcours de paiement, panneau d’administration, comptes utilisateurs, tout — de Next.js vers TanStack Start, et a détaillé la migration en vidéo. La pull request a ajouté environ 100 000 lignes et en a supprimé environ 129 000. Le framework sur lequel il a atterri porte encore l’étiquette Release Candidate, pas 1.0, sur sa propre page d’accueil — il a fait tourner une entreprise vivante sur un logiciel que ses propres mainteneurs qualifient eux-mêmes de pas tout à fait fini.

Cette migration unique n’est pas un verdict sur quel framework est meilleur. C’est un compte-rendu précis et documenté de ce qu’une vraie migration a coûté et rapporté, avec les détails qu’une page marketing aurait laissés de côté — utilisé ici pour illustrer une question plus large : ce que « encore RC » devrait signifier pour quiconque envisage de le suivre.

Ce qu’est réellement TanStack Start

TanStack Start est un framework React full-stack construit sur TanStack Router, la librairie de routing stable en production depuis 2024. Là où Next.js est server-first — le serveur décide par défaut comment une page se rend —, TanStack Start est client-first, avec des briques serveur ajoutées par-dessus : rendu serveur du document complet, streaming, fonctions serveur et routes serveur, le tout construit sur le même arbre de routes typé que Router fournit déjà. Le typage s’applique aux routes, aux paramètres d’URL et aux paramètres de recherche dès la compilation, pas seulement via une extension d’éditeur.

Le site officiel de TanStack Start, qui affiche actuellement le badge « RC » et revendique 18 055 219 téléchargements par semaine et 14 805 étoiles GitHub.

Le framework a livré sa Release Candidate le 23 septembre 2025, l’équipe TanStack déclarant alors vouloir « couper la 1.0 peu après avoir recueilli les retours sur la RC ». À l’heure où ces lignes sont écrites, cette coupe n’a pas eu lieu : la documentation officielle porte toujours le badge RC et recommande de figer les versions de dépendance plutôt que de suivre une plage large. Un vrai manque à connaître avant de s’engager : les React Server Components, la fonctionnalité autour de laquelle Next.js a construit une bonne partie de son identité récente, ne sont pas encore supportés. L’équipe TanStack les liste comme en développement actif, prévus comme un ajout non cassant une fois prêts.

Rien de tout cela n’en fait un jouet. Quatorze entreprises, dont Cloudflare, Netlify, Prisma, Convex et Clerk, figurent comme partenaires officiels de l’écosystème qui construisent des intégrations pour lui. C’est une liste sérieuse pour un logiciel pre-1.0, et c’est en partie ce qui a permis à une plateforme opérationnelle comme Codeline de migrer dessus.

La migration qui s’est réellement produite

Codeline n’est pas un dépôt de démo. C’est le produit commercial de Malherbe : paiement des formations, tableau de bord admin, gestion des comptes utilisateurs, plusieurs centaines de pages de contenu en ligne. La migration elle-même, suivie sous la pull request #315, s’est faite en grande partie via un agent de codage IA (Codex) utilisant un skill maison construit pour l’occasion, migrate-nextjs-to-tanstack, et lui a coûté plusieurs centaines de dollars en tokens de modèle selon ses propres mots. Une migration de cette taille menée en grande partie par un agent, sur un produit payant, est en soi la partie la plus inhabituelle de cette histoire — le choix du framework est presque secondaire face au fait qu’une IA a fait le gros du travail sur le code d’une vraie entreprise.

Il donne trois raisons pour ce changement, et les deux plus solides s’accompagnent de chiffres qu’il a mesurés lui-même plutôt que de chiffres qu’on lui a rapportés.

Le temps de build a été à peu près divisé par deux. Sur des dizaines de déploiements, ses builds Next.js allaient de 3 minutes 17 secondes au plus rapide à 3 minutes 47 secondes au plus lent, avec une moyenne autour de 3 minutes 30. Sur TanStack Start, la même fourchette allait de 1 minute 9 secondes à 1 minute 35 secondes, avec une moyenne d’environ 1 minute 20. C’est un écart constant de plus de 2 minutes à chaque déploiement — le genre d’écart qui compte le plus exactement au moment où on ne veut pas qu’il compte : un incident de production où quelqu’un attend qu’un correctif parte.

La navigation a paru différente sous une connexion lente, pas seulement rapide. Malherbe a fait une démo des deux applications côte à côte avec un throttling réseau simulant de la 3G. Next.js montrait la cascade familière : un placeholder, puis un loader, puis un re-rendu une fois les données arrivées. TanStack Start, avec le prefetching de TanStack Router et des skeletons ciblés sur ce qui charge réellement, affichait immédiatement le skeleton pertinent sans empiler d’états de chargement superflus. C’est une comparaison subjective, sur une seule démo, pas un benchmark indépendant — mais c’est une démo faite sur son propre produit, pas sur un exemple soigneusement choisi.

L’argument qui a le plus compté pour lui n’était pas la vitesse

Malherbe a été explicite : sa raison principale de changer n’était ni les temps de build ni le ressenti de navigation. C’est que TanStack Start est plus facile à manipuler correctement pour un agent de codage IA, parce que son API est déclarative et centralise chaque route en un seul bloc :

export const Route = createFileRoute('/path')({
  beforeLoad: checkAuth,             // middleware
  validateSearch: searchSchema,      // paramètres de recherche typés
  loaderDeps: ({ search }) => search,
  loader: async ({ deps }) => fetchData(deps),
  pendingComponent: SkeletonUI,      // UI de chargement
  component: PageComponent,          // rendu
  head: () => ({ meta: [...] }),     // SEO
})

À comparer au vocabulaire qu’un projet Next.js a accumulé : use server, use client, des server actions renommées en cours de route, une séparation page directory versus app directory, des comportements de middleware et de proxy qui se recoupent assez pour brouiller quel nom s’applique, et use cache ajouté plus récemment encore. Aucune de ces décisions n’est mauvaise prise isolément — la plupart remontent à Next.js résolvant de vrais problèmes à mesure que le modèle de React évoluait autour de lui. Mais un agent qui génère du code doit savoir à quelle époque terminologique appartient un code donné, et le constat de Malherbe est que son agent se trompait constamment sur l’ancienne stack et se trompe rarement sur la nouvelle.

Ce constat reste son impression personnelle sur une seule migration, pas un benchmark mesuré, et il faut le lire comme tel. Ce n’est pas non plus une affirmation à balayer d’un revers de main : le caractère IA-friendly de la surface d’API d’un framework est une variable réelle, largement non mesurée, qui ne comptait pas beaucoup tant que les humains écrivaient tout le code de route à la main.

Ce que la migration lui a coûté

La version « one-shot » de cette histoire s’arrêterait aux chiffres ci-dessus. Elle ne devrait pas. La migration pilotée par IA a produit de vrais bugs à corriger après coup : un bouton de notification mal placé et des avatars cassés en sont deux qu’il a mentionnés spécifiquement. Un agent qui déplace 100 000 lignes d’un produit vivant n’est pas un processus propre et silencieux — c’est un processus qui a besoin qu’un humain vérifie le résultat avant sa mise en production, comme n’importe quel gros refactor, peu importe qui l’a écrit.

L’autre coût honnête est celui inscrit dans le numéro de version du framework. L’écosystème de TanStack Start, ses plugins, ses guides tiers, ses réponses Stack Overflow, sont tous nettement plus minces que ceux de Next.js, parce que Next.js a eu des années d’usage grand public pour les accumuler. Adopter un framework pre-1.0 est un pari : que les changements d’API restants avant la 1.0 seront mineurs, et que son écosystème grandira assez vite pour rattraper son retard. Codeline est le produit personnel de Malherbe, donc c’est lui qui absorbe directement ce risque. Une équipe qui livre le produit d’un client, ou une plateforme soumise à un processus de validation conformité, prend une exposition différente en faisant le même choix.

La page d’accueil officielle de Next.js, le framework dont Codeline s’est éloigné.

Ce que ça indique vraiment

Ce que ça indique vraiment.

C’est une seule migration, documentée par la personne qui l’a menée, pas un consensus du marché ni un benchmark contrôlé. Traitez les chiffres de build et le constat sur l’IA-friendliness comme des données réelles issues d’un vrai système, pas comme une loi générale sur l’un ou l’autre framework. Ce que ça établit, c’est que TanStack Start est désormais assez mature, et assez soutenu par son écosystème, pour qu’au moins un vrai produit commercial tourne dessus sans s’effondrer. Que ce soit un feu vert pour votre propre projet dépend de votre besoin réel des React Server Components aujourd’hui, du niveau de certitude de production qu’exige votre projet avant que ses dépendances n’atteignent la 1.0, et de la part de votre code de route qui sera réellement écrite par un agent plutôt que par une personne.

FAQ

TanStack Start est-il prêt pour la production ? Ça dépend de votre tolérance au risque, pas d’un simple oui ou non. Il est étiqueté Release Candidate sur son propre site, pas 1.0, et l’équipe TanStack recommande de figer les versions de dépendance plutôt que de suivre une plage large. Au moins un vrai produit commercial, Codeline, tourne dessus en production, ce qui montre qu’il est utilisable à cette échelle — pas que ses changements pre-1.0 restants sont sans risque.

TanStack Start supporte-t-il les React Server Components ? Pas encore. L’équipe TanStack les liste comme en développement actif, prévus comme un ajout non cassant une fois prêts. Si votre projet dépend des RSC aujourd’hui, c’est actuellement une raison de rester sur Next.js.

TanStack Start est-il réellement plus rapide à builder que Next.js ? Sur une migration documentée, oui, de façon constante : environ 3 minutes 30 en moyenne sur Next.js contre environ 1 minute 20 sur TanStack Start, sur des dizaines de déploiements de la même application. Ce sont les chiffres réels d’une seule équipe, pas un benchmark indépendant et contrôlé sur de nombreux projets — à traiter comme un signal fort plutôt qu’un résultat garanti pour tout code base.

Pourquoi les agents de codage IA travailleraient-ils mieux avec TanStack Start ? Le constat, issu de la même migration, est que TanStack Start centralise la logique, le middleware, l’état de chargement et la récupération de données de chaque route dans un seul objet nommé de façon déclarative, tandis que Next.js a accumulé plusieurs concepts qui se recoupent ou ont été renommés (server actions, use server, use client, middleware versus proxy) à mesure que le modèle de React changeait sous lui. Un agent doit deviner correctement à quelle époque de terminologie Next.js appartient un code base ; l’API de TanStack Start lui laisse moins de marge pour se tromper. C’est une impression rapportée sur une seule migration, pas un benchmark mesuré et reproductible.

Faut-il migrer une application Next.js existante vers TanStack Start ? Seulement si vous êtes prêt à accepter le risque pre-1.0 et que vous avez une raison spécifique : un workflow de développement fortement assisté par IA, un besoin de builds plus rapides sur une grosse application, ou un projet greenfield où l’écosystème plus mince coûte moins cher. Si votre projet a besoin des React Server Components maintenant, ou exige une certitude de production totale avant que son framework central n’atteigne la 1.0, Next.js reste le choix par défaut le plus sûr.