Lovable vient de livrer le SSR. Voici ce que ça résout, et ce que ça ne résout pas.

Depuis un moment déjà, j'envisageais de migrer hors de Lovable.

Pas parce que quoi que ce soit était cassé. L'app fonctionne. Le design tient. Les clients aiment. Mais dot2.solutions avait un problème de SEO inscrit dans l'architecture. Lovable livrait une SPA côté client, ce qui signifiait que chaque crawler qui compte — celui de Google, le bot d'aperçu de LinkedIn, et désormais les agents de navigation de ChatGPT et de Claude qui sourcent des réponses depuis le web en direct — voyait une div vide jusqu'à ce que JavaScript s'exécute. Pas de classement. Pas de GEO (generative engine optimization). Invisible pour les modèles que les gens commencent à interroger au lieu de rechercher.

J'ai donc commencé à évaluer des alternatives. Vercel avec une reconstruction en Next.js était la voie évidente. Rocket.new avait l'air intéressant. Bolt.new était sur la liste. J'avais quelques semaines de recherche derrière moi — je me débattais avec ça depuis un moment.

Puis j'ai ouvert un nouveau projet Lovable pour demander à l'IA si elle pouvait reconstruire quelque chose en Next.js. Voici ce qu'elle m'a répondu :

Je ne peux pas reconstruire cela en Next.js — ce projet Lovable tourne sur TanStack Start (React 19 + Vite), pas Next.js. Next.js n'est pas supporté ici. La bonne nouvelle : TanStack Start vous donne tout ce que vous avez listé — SSR, routage basé sur les fichiers, méta par page, fonctions serveur, déploiement edge — donc nous pouvons reconstruire votre app avec un SSR complet, en utilisant simplement TanStack Start à la place de Next.js.

C'est comme ça que j'ai découvert que Lovable avait discrètement livré le SSR.

Ce qui a réellement changé

À partir du 20 avril 2026, les nouveaux projets Lovable sont livrés sur TanStack Start avec le rendu côté serveur complet. Du vrai HTML. Des pages crawlables. Des méta-tags qui arrivent au navigateur dès le premier passage, pas après que JavaScript a décidé de s'exécuter.

TanStack Start est un framework React full-stack construit sur Vite — le même outillage que Lovable utilisait déjà. Il est passé en Release Candidate plus tôt cette année et gagne de la traction crédible en tant qu'alternative à Next.js. Contrairement à Next.js, il adopte une approche client-first : vous écrivez une SPA, et le SSR est ajouté par-dessus comme une amélioration. C'est un bien meilleur ajustement pour le code généré par Lovable que le modèle mental server-first des React Server Components que Next.js impose. C'est probablement pourquoi Lovable l'a choisi.

Les gains pratiques pour les nouveaux projets sont réels — le crawler de Google obtient du vrai HTML au premier chargement, les agents de navigation LLM reçoivent une page qu'ils peuvent réellement lire et citer, les cartes sociales fonctionnent sans hacks d'injection au build, la première peinture est plus rapide parce que le contenu n'attend pas JavaScript, et les fonctions serveur vous donnent des appels backend typés sans configurer une couche API séparée.

Sous le capot

Pour ceux qui se demandent ce qu'il y a exactement dans la boîte, voici la stack exacte avec laquelle un projet Lovable frais est livré aujourd'hui : React 19 avec TanStack Start sur Vite 7, TypeScript en mode strict, Tailwind v4 avec un vrai design system (tokens oklch, typographie personnalisée), shadcn/ui sur les primitives Radix, routage basé sur les fichiers via TanStack Router, TanStack Query pour les données, et déploiement edge Cloudflare Workers par défaut.

Certains de ces choix comptent au-delà du seul SSR. L'edge Cloudflare Workers signifie que les crawlers et agents LLM obtiennent la réponse en millisecondes partout dans le monde — et la latence de réponse est un facteur de classement. La chaîne d'outils moderne (Vite 7, écosystème TanStack) maintient des builds rapides et une sortie propre, ce qui compte à mesure que le projet grandit.

J'ai testé cela sur un projet frais que j'ai lancé — contenu complet dans le corps de la réponse, méta-tags dans le head, aucune exécution JavaScript requise pour lire la page. Les nouvelles valeurs par défaut livrent.

TanStack Start vs Next.js pour le SEO

Question légitime que je me posais pendant mes recherches : TanStack Start est-il réellement aussi bon que Next.js pour le SEO, ou Lovable a-t-il simplement choisi l'option plus légère ? Voici comment ils se comparent sur l'essentiel.

Sur les fondamentaux qui font bouger les classements — SSR, HTML crawlable, méta-tags, sitemaps — ils sont à égalité. Next.js a plus de commodités prêtes à l'emploi : le composant <Image> gère la conversion de format et le dimensionnement pour vous, l'ISR est natif, et la Metadata API est bien documentée. C'est juste — Next.js existe depuis plus longtemps et Vercel a fortement investi dans la surface SEO.

TanStack Start égale sur les fondamentaux et bat Next.js sur la flexibilité de déploiement. Nitro vous permet de livrer sur Cloudflare, Netlify, Deno, Bun, Node, ou n'importe où ailleurs sans verrouillage. Le framework embarque aussi un guide d'optimisation LLM dans sa documentation officielle, ce qui est un petit signal révélateur que l'équipe pense à où la recherche va, pas seulement à où elle a été. Et pour un projet généré par Lovable, la chaîne d'outils basée sur Vite est un meilleur ajustement que le système de build dogmatique de Next.js.

Pour un site qui doit se classer sur Google et être cité par des LLM, les deux font le travail. Aucun n'est un compromis.

Ce qui n'a pas changé

Voici le piège que l'IA n'a pas signalé de lui-même : si votre projet Lovable existait avant le 20 avril, vous êtes toujours sur l'ancien template Vite côté client. Pas de bouton de migration. Pas de chemin de mise à niveau automatisé. Lovable n'a pas auto-migré les projets existants — et c'est cohérent avec comment les migrations de framework à framework se passent généralement, car elles ne le sont jamais complètement. Différentes sémantiques de routage, différents patterns de chargement de données, différentes frontières de composants, différentes sorties de build.

Ce qui signifie : le problème de SEO et de GEO qui allait me pousser à quitter la plateforme est toujours là, sur l'ancienne stack.

Ce que je ferais concrètement

Je suis exactement dans cette situation, donc voici le plan que j'exécute.

Déplacer le blog vers Ghost. Cette semaine.

C'est là que la vélocité SEO et GEO compte réellement. Les sites marketing se classent pour les recherches de marque — votre nom, votre entreprise, vos services. Ce trafic atterrit une fois que les gens savent déjà que vous existez. Le blog est là où vous concourez pour la recherche longue traîne, pour les citations d'assistants LLM, et pour le contenu qui se cumule. Ghost est natif SSR, conçu pour le contenu, et vous donne des données structurées, du RSS, des méta corrects et des URLs propres sans rien construire. Résolvez d'abord la couche de contenu.

Pour votre site marketing existant — des contournements existent.

J'ai construit le mien et ils tiennent. Qu'une reconstruction complète sur la nouvelle stack vaille le coup dépend de combien l'ancienne architecture vous coûte réellement. Pour dot2.solutions, mes contournements gèrent assez pour qu'une reconstruction ne soit pas urgente. Pour des projets plus riches en contenu — surtout des sites clients où la recherche organique est le principal canal d'acquisition — reconstruire vaut l'effort, et je prévois exactement cela pour plusieurs des miens.

Pour les nouveaux projets, construisez simplement sur Lovable.

La plus grande raison pour laquelle je regardais d'autres plateformes a disparu. Le SEO et la GEO sont résolus au niveau de la plateforme maintenant. Ça change le calcul pour quiconqui a écarté Lovable il y a six mois parce que son site ne risquait pas de se classer.

Où ça me laisse

Le problème qui allait me pousser hors de Lovable est résolu. Je reste.

Les nouveaux projets clients sont construits sur la nouvelle stack. Certains de mes travaux existants restent sur l'ancienne stack avec des contournements en place. Le blog migre vers Ghost cette semaine parce que c'est là que la vélocité de contenu compte réellement.

Et la partie dont je suis vraiment enthousiaste : Ghost expose une Admin API complète — création, édition et gestion programmatiques de tout sur la plateforme. Ce qui signifie que je peux reconstruire mon workflow de blog entièrement dans Lovable, avec Ghost comme backend de contenu natif SSR. Chaque plateforme jouant ses forces. Ça va être génial.

La couche de contenu et de connaissances reste mienne à posséder — aucune plateforme ne résout cette partie à votre place. Mais la couche d'infrastructure vient de s'améliorer significativement, et ça change qui devrait être sur cette plateforme. Si vous avez écarté Lovable parce que votre site ne se classait pas ou n'apparaissait pas dans une réponse IA, ça vaut le coup de jeter un nouvel œil.

Et ensuite

Je partagerai comment la migration se passe réellement — la configuration Ghost, le workflow de publication piloté par Lovable, et tout ce qui casse en chemin. Si vous pesez les mêmes décisions, suivez sur LinkedIn, ou envoyez-moi un message.