Passer en live : migration dev-vers-prod, Search Console et performance

Vue d'ensemble

Vous avez bâti tout le stack : architecture, auth, données, secrets et paiements. Maintenant vous le passez en live et faites en sorte que le monde puisse le trouver. Passer en live n'est pas un seul bouton - c'est migrer chaque service de son instance de development vers la production dans un ordre soigneux, pointer votre domaine via Cloudflare vers les bons endroits, dire à Google que votre site existe et le rendre rapide. Faites-le dans le bon ordre, et le jour du lancement est calme. Faites-le au petit bonheur, et vous obtenez le classique échec du jour de lancement où une clé oubliée met les logins ou la facturation hors service pendant que les clients regardent. Cette leçon vous donne la version calme.

Ce que vous allez apprendre

Vous allez apprendre un ordre sûr pour migrer Clerk et Convex du development à la production, comment câbler votre domaine et le DNS avec Cloudflare devant votre app, comment vérifier votre site dans la Google Search Console et soumettre votre sitemap pour être indexé, et quelles bases de Lighthouse et de Core Web Vitals comptent vraiment pour la vitesse, le SEO et la conversion.

Prérequis

Un stack complet issu de ce cours - auth, données et paiements, tous fonctionnels en development - car passer en live relie les trois. La leçon de déploiement du Cours 1, car Vercel, DNS et Cloudflare y sont apparus et cette leçon s'appuie dessus. Et les parties setup de production des leçons sur Clerk, Stripe et les secrets, que vous rassemblez maintenant.

Le problème

La migration est là où les builders confiants sont humiliés. Chaque service a ses propres mondes dev et prod (instances Clerk, deployments Convex, modes Stripe), et les basculer dans le mauvais ordre ou oublier une clé laisse une app à moitié live où les utilisateurs peuvent s'inscrire mais leurs données disparaissent, ou peuvent payer mais n'obtiennent jamais l'accès. Pendant ce temps, même un lancement parfait est invisible si Google ne sait pas que votre site existe et que vos pages sont lentes. Les fondateurs versent des semaines dans la construction puis ratent le dernier kilomètre, si bien que le produit démarre cassé ou introuvable. Cette leçon est ce dernier kilomètre, fait dans un ordre délibéré.

Un ordre de migration sûr

Migrez un service à la fois et vérifiez chacun avant le suivant, pour que, si quelque chose casse, vous sachiez exactement quelle étape l'a causé. L'ordre sûr est : domaine et DNS d'abord (pour que l'adresse existe), puis Convex (pour que les données aient un foyer), puis Clerk (pour que l'auth pointe vers le domaine live et la base de données live), puis Stripe (pour que les paiements accordent l'accès au système désormais live), puis déployer avec toutes les clés live en place. Après chaque bascule, testez le vrai flux avant d'avancer. L'échec de loin le plus fréquent est de laisser une clé de test dans l'environnement déployé, alors faites un dernier passage sur chaque variable d'environnement et confirmez qu'aucun sk_test, pk_test ou webhook secret de test ne survit en production.

• Domaine et DNS d'abord : enregistrer le domaine, le pointer via Cloudflare vers votre app et votre site marketing.
• Convex ensuite : créer le deployment de production, poser ses env vars, y déployer votre schema et vos fonctions.
• Clerk ensuite : créer l'instance de production, ajouter ses DNS records, configurer Google OAuth, basculer vers pk_live / sk_live.
• Stripe en dernier : activer le compte, recréer produits et prix en mode live, enregistrer le webhook endpoint live, basculer vers les clés live.
• Dernier passage : confirmer que zéro clé de test ne reste dans les env vars de production, puis déployer et tester le flux complet inscription-vers-paiement en live.

Domaine, DNS et Cloudflare devant

Votre site marketing et votre app vivent à des adresses différentes, généralement le domaine nu (yoursite.com) pour le marketing et un sous-domaine (app.yoursite.com) pour l'app, exactement comme la leçon d'architecture le décrivait. Vous pointez les deux via DNS, et un schéma courant et solide est de mettre Cloudflare devant : gérer le DNS chez Cloudflare, obtenir son HTTPS gratuit et son CDN global et router chaque nom vers le bon endroit (typiquement Vercel pour les deux surfaces). Souvenez-vous des sous-domaines Clerk de la leçon 2 - ces CNAME records veulent généralement être DNS-only (nuage gris) plutôt que proxifiés, pour ne pas casser le handshake TLS de l'auth. Cloudflare devant vous donne vitesse et protection de base gratuitement, ce pour quoi la plupart des builders l'utilisent. Faites attention à ne pas double-proxifier ni gérer le HTTPS en double, le piège du Cours 1.

; Example DNS layout (real targets come from Vercel / Clerk)
; Type   Name      Value / target            Proxy
CNAME    @         cname.vercel-dns.com      proxied   ; marketing site
CNAME    app       cname.vercel-dns.com      proxied   ; the app
CNAME    clerk     frontend-api.clerk.services  DNS only ; auth - do NOT proxy
CNAME    accounts  accounts.clerk.services      DNS only ; auth - do NOT proxy

Google Search Console et votre sitemap

Un site live dont Google ne sait rien ne reçoit aucun trafic de recherche. La Google Search Console est l'outil gratuit qui dit à Google que votre site existe, montre comment il vous indexe et rend les problèmes visibles tôt. Le flux : ajoutez votre site comme property, vérifiez qu'il vous appartient (la méthode la plus simple est généralement un DNS TXT record que la Search Console vous donne et que vous ajoutez chez Cloudflare), puis soumettez l'URL de votre sitemap. Votre sitemap est la liste lisible par machine de vos pages - ce projet en génère déjà une avec le script generate:sitemaps - et la soumettre dit à Google exactement quoi crawler. Ensuite, la Search Console devient votre système d'alerte précoce : elle montre la couverture d'indexation, pour quelles queries vous apparaissez et toute erreur de crawl, pour que vous attrapiez les problèmes SEO avant qu'ils ne vous coûtent du trafic.

; Vérifier la propriété dans la Search Console avec un TXT record (valeur venant de Google)
; Type   Name   Value
TXT      @      google-site-verification=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

; Puis soumettre l'URL de votre sitemap dans l'UI de la Search Console :
; https://yoursite.com/sitemap.xml

L'indexation n'est pas instantanée. Après soumission, Google met des jours à des semaines pour crawler et indexer un nouveau site, et la Search Console montre la progression. Soumettre le sitemap et corriger toute erreur qu'il signale est l'action SEO la plus impactante que vous puissiez entreprendre au lancement.

Lighthouse et les bases de vitesse de page qui comptent

Lighthouse est l'audit gratuit intégré à Chrome (et exécutable en CI) qui note vos pages sur la performance, l'accessibilité, les best practices et le SEO. Les pages rapides convertissent mieux et rankent mieux - Google utilise les Core Web Vitals comme signal de ranking, et les crawlers d'IA préfèrent aussi les pages rapides et propres -, donc traiter la vitesse comme partie du lancement paie double. Vous n'avez pas à chasser un 100 parfait sur chaque métrique, mais vous devriez comprendre la poignée de choses qui bougent vraiment l'aiguille, car la plupart des pages lentes sont lentes pour les mêmes quelques raisons. Lancez Lighthouse surtout sur vos sites marketing, car ils sont la porte d'entrée de votre funnel et là où la vitesse compte le plus.

• Images : le coupable numéro un. Livrez des formats modernes (WebP/AVIF), dimensionnez-les correctement et lazy-loadez les images sous la ligne de flottaison.
• JavaScript : livrez-en moins. C'est exactement pour ça que le site marketing utilise un framework content-first - moins de scripts, pages plus rapides.
• Largest Contentful Paint (LCP) : à quelle vitesse le contenu principal apparaît. Optimisez votre image hero et vos fonts pour l'améliorer.
• Cumulative Layout Shift (CLS) : les choses qui sautent pendant le chargement. Réservez de la place pour les images et pubs, pour que rien ne bouge.
• Fonts : chargez-les efficacement et évitez les flashs de texte invisible. Le self-hosting et le preloading aident.
• Caching et le CDN : Cloudflare devant livre déjà les assets statiques vite dans le monde entier - appuyez-vous dessus.

Erreurs fréquentes

Les classiques du jour de lancement : laisser une clé de test en production, si bien que les logins ou paiements échouent en silence ; migrer les services dans un ordre embrouillé, si bien que vous ne pouvez dire ce qui a cassé ; proxifier les sous-domaines d'auth de Clerk via Cloudflare et casser le handshake TLS ; oublier d'enregistrer le webhook endpoint Stripe live, si bien que les paiements de production n'accordent jamais l'accès ; ne jamais vérifier le site dans la Search Console ni soumettre le sitemap, si bien que le lancement est invisible pour Google ; et shipper des images lourdes et non optimisées qui font s'effondrer Lighthouse et la conversion. Chacune est évitée par la checklist ordonnée et un dernier passage sur les variables d'environnement.

ROI business

Le dernier kilomètre est là où toute votre construction paie ou échoue en silence. Une migration propre signifie que le jour du lancement est ennuyeux au lieu d'une panne devant vos premiers clients. La Search Console et le sitemap sont la différence entre un produit qui accumule du trafic sur des mois et un que personne ne trouve. Et la vitesse de page est un levier direct sur la conversion et le ranking - les pages plus rapides gagnent littéralement plus d'argent et rankent plus haut, chaque jour qu'elles sont en live. Pour une fondatrice, bien faire le dernier kilomètre protège tout l'investissement de la construction du produit en premier lieu.

Checklist

Vous avez terminé le Cours 3 quand tout ceci est vrai sur le produit live.

• Clerk, Convex et Stripe sont tous en production, et zéro clé de test ne reste dans les env vars de production.
• Votre domaine sert le site marketing et l'app via HTTPS, avec Cloudflare devant et les sous-domaines Clerk en DNS-only.
• Votre site est vérifié dans la Google Search Console et votre sitemap est soumis.
• Lighthouse sur vos sites marketing est sain, avec des images et du JavaScript optimisés.

Ressources

Gardez ouverts les guides de déploiement de production de Clerk et Convex, la checklist go-live de Stripe et la Google Search Console pendant le lancement - chacun est à jour, là où ce cours renvoie à des docs. Lancez Lighthouse depuis les Chrome DevTools ou votre CI sur chaque site marketing. La leçon de déploiement du Cours 1 est votre référence pour les bases de Vercel, DNS et Cloudflare. Vous pouvez maintenant bâtir et lancer un produit complet et payant de bout en bout.

Votre mission

Passez un projet de ce cours en live, même petit. Migrez Clerk et Convex vers la production dans l'ordre sûr, pointez votre domaine via Cloudflare, faites le dernier passage sur les env vars pour tuer chaque clé de test, vérifiez le site dans la Search Console et soumettez le sitemap, puis lancez Lighthouse sur votre homepage et corrigez les deux plus gros problèmes qu'il signale. Faire tout le dernier kilomètre une fois transforme le lancement d'une inconnue effrayante en une checklist de routine pour chaque produit que vous bâtissez ensuite.

Prochaine leçon

Vous pouvez maintenant bâtir et lancer un vrai produit payant de bout en bout : architecture, auth, données, secrets, paiements et un passage en live propre. Le Cours 4 va au-delà d'une seule app, dans l'automatisation et les systèmes agentiques - n8n et les outils de workflow, l'automatisation de navigateur, les sandboxes et la construction de vos propres outils d'IA qui abattent du travail pour vous pendant que vous dormez.