La preview fonctionne mais le site live échoue : quoi vérifier

Ce que « la preview fonctionne » et « la production échoue » veut vraiment dire

Un lien de preview est une version temporaire de votre appli qui tourne dans un environnement contrôlé fourni par votre outil de build ou votre hébergeur. Il utilise souvent un domaine standard, des réglages par défaut et un environnement “ami” où moins de règles gênent le fonctionnement.

Un site en production est votre vrai domaine avec des réglages réels. Les navigateurs le traitent différemment : les cookies sont attachés au domaine, les règles HTTPS s'appliquent et votre appli doit communiquer avec le bon backend en ayant les permissions adéquates.

Donc quand on dit « la preview fonctionne mais la production échoue », cela signifie généralement que l'interface a l'air correcte en démonstration, puis casse quand elle doit respecter les règles du vrai domaine.

L'échec peut se manifester de plusieurs façons : une page blanche ou un spinner infini, une boucle de connexion (connexion puis retour à la page de login), des boutons qui ne font rien parce que les appels API échouent, des données manquantes même si l'UI s'affiche, ou des erreurs qui n'apparaissent que sur le domaine live.

Aussi, « ça marche » peut être trompeur. Beaucoup d'apps générées par IA « marchent » en preview parce que l'UI se rend. Les parties importantes échouent silencieusement en production : requêtes API, authentification, uploads, paiements ou lectures en base.

Un exemple simple : en preview, votre appli appelle une API via une URL de test et un CORS permissif, donc les requêtes réussissent. Sur le domaine live, les mêmes appels sont bloqués, ou l'appli pointe encore vers localhost. La page se charge, mais les données n'apparaissent jamais.

C'est pourquoi la première question n'est pas « est-ce que ça se charge ? » mais « est-ce que les appels réseau réussissent sur le domaine live ? » Si vous avez hérité d'un prototype généré par IA, un audit rapide du code (comme celui que réalise FixMyMess) trouve souvent le décalage rapidement : variable d'environnement erronée, cookie configuré pour le domaine de preview, ou règle HTTPS que la preview n'appliquait pas.

Différences de domaine qui modifient le comportement de l'appli

Quand la preview fonctionne mais la production échoue, suspectez le nom d'hôte dès le départ. Les navigateurs traitent app-preview.example et example.com comme deux endroits différents, même si le code est identique. Cela change quels cookies sont envoyés, quelles règles de sécurité s'appliquent et vers quelles URLs votre appli est autorisée à faire des appels.

Un piège fréquent est de passer d'un domaine temporaire de preview à un vrai domaine en supposant que tout se transpose. En réalité, beaucoup de réglages sont liés à une origine exacte (schéma + hôte + port). Une différence d'un caractère peut rendre des fonctionnalités cassées.

Sous-domaine vs domaine apex : petit changement, gros impact

Passer de app.example.com à example.com (ou l'inverse) peut casser des comportements dépendant de la portée du domaine. Les cookies peuvent être définis pour un hôte et ne jamais apparaître sur l'autre. Certains systèmes d'authentification attendent aussi un domaine précis pour les callbacks et les origines autorisées.

Il en va de même pour www vs sans-www. Si votre site live redirige de www.example.com vers example.com, l'app peut se charger mais la connexion échouer parce que le fournisseur d'auth voit une URL de callback différente de celle enregistrée.

Les discordances de domaine qui causent le plus souvent des pannes immédiates sont :

• www vs sans-www (les redirections changent l'URL finale)
• domaine apex vs sous-domaine (portée des cookies et origines autorisées différentes)
• noms d'hôtes de preview différents par déploiement (URLs codées en dur qui ne correspondent plus)
• domaines de staging vs production (auth et API pointent au mauvais endroit)
• slash final ou différences de chemin dans les URLs de callback (certains fournisseurs les considèrent distinctes)

Un exemple rapide : votre preview tourne sur un domaine temporaire, et le fournisseur de connexion est configuré avec ce callback. Vous lancez sur www.votreapp.com, le fournisseur rejette le callback et les utilisateurs voient une page blanche ou une boucle vers le login. Rien dans l'UI n'explique pourquoi.

C'est particulièrement courant avec les apps générées par IA parce que les domaines se retrouvent codés en dur à plusieurs endroits (frontend, backend, réglages d'auth). FixMyMess trouve souvent plusieurs endroits où un seul nom d'hôte doit correspondre exactement pour que la production se comporte comme la preview.

Réglages d'environnement : le casseur silencieux en production

Les environnements de preview « fonctionnent souvent » parce que la plateforme injecte discrètement des valeurs par défaut. Votre site live ne le fera habituellement pas. Cet écart est une des principales raisons pour lesquelles la preview réussit alors que la production échoue, même si le code est identique.

Un schéma courant est que la preview injecte une URL API de secours, une base de données de démonstration ou un mode d'auth permissif. La production attend des valeurs réelles. Quand elles manquent, l'app continue de tourner mais se comporte étrangement : boutons inactifs, pages vides, ou toutes les requêtes qui échouent.

Les problèmes d'environnement les plus fréquents en production ressemblent à cela :

• Une variable requise est absente (URL de base API, secret d'auth, URL de la base de données, clés de paiement).
• Une valeur est présente mais incorrecte (endpoint dev, clé de test, ancien domaine de staging).
• Les variables sont définies à un endroit mais lues d'un autre (définies dans le dashboard d'hébergement mais la build attend un .env au moment de la compilation).
• Les noms ne correspondent pas exactement (NEXT_PUBLIC_API_URL vs NEXT_PUBLIC_API_BASE).
• La valeur contient une faute subtile (slash en trop, mauvaise région, mauvais client ID).

Un autre piège est l'endroit où la variable est utilisée. Les variables côté client se retrouvent dans le navigateur, elles doivent donc être sûres à exposer. Les variables côté serveur restent sur le serveur, mais seulement si le code s'exécute vraiment côté serveur. Les apps générées par IA fuguent parfois des secrets dans le code frontend. Ça peut « marcher » en preview, puis casser en production quand les clés sont tournées ou que des règles de sécurité s'appliquent. C'est aussi un vrai risque de sécurité.

Pour repérer rapidement un problème d'env, vérifiez les logs live et la console du navigateur pour :

• des erreurs mentionnant undefined ou null
• des réponses 401/403 (mauvaise clé, audience ou issuer incorrect)
• des requêtes vers le mauvais hôte (domaine de dev affiché en production)
• des erreurs de build/démarrage comme “Missing required env var”

Exemple : la connexion fonctionne en preview parce qu'elle utilise une URL de callback de preview, mais la production pointe encore vers le domaine de preview. Le fournisseur d'auth la rejette et les utilisateurs voient un 401 ou une boucle de connexion.

Si vous avez hérité d'une base de code générée par IA et ne savez pas d'où vient une valeur, FixMyMess peut lancer un audit gratuit du code et lister ce qui manque ou est mal configuré avant que vous ne changiez quoi que ce soit.

HTTPS, redirections et problèmes de contenu mixte

Une preview peut marcher parce qu'elle tourne sur un domaine de la plateforme avec une configuration connue comme bonne. Quand vous passez sur votre propre domaine, le navigateur devient plus strict. De petites mauvaises configurations peuvent empêcher l'app de charger, de se connecter ou d'appeler les API.

HTTPS est plus strict que la plupart des setups de preview

HTTPS n'est pas juste une icône de cadenas. Ça change ce que le navigateur autorise. Des requêtes peuvent être bloquées, des cookies se comporter différemment, et des redirections peuvent créer des boucles qui ne se voyaient pas en preview.

Un exemple typique : le site live se charge via https://, mais l'app appelle encore une API en http://api.example.com. En preview, vous ne le remarquez peut‑être pas parce que tout est sur le même domaine plateforme ou les avertissements sont faciles à manquer.

Contenu mixte : le bloqueur silencieux

Le contenu mixte survient quand une page HTTPS charge quelque chose via HTTP (API, images, scripts). Les navigateurs modernes bloquent souvent ces requêtes, ce qui peut rendre l'app « cassée » sans erreur visible à l'écran.

Pour confirmer rapidement :

• Ouvrez le site live (pas la preview).
• Ouvrez la console du navigateur et rechargez.
• Cherchez « Blocked mixed content » ou erreurs similaires.
• Vérifiez le panneau Réseau pour des requêtes bloquées, annulées ou coincées dans des redirections.

Redirections, HSTS et boucles

Les boucles de redirection apparaissent souvent quand plusieurs couches ne sont pas d'accord. Par exemple :

• l'app force HTTPS, mais la plateforme d'hébergement le fait déjà
• un CDN force www, mais l'app force sans-www
• HSTS est activé, donc le navigateur refuse de retenter en HTTP

Quand cela arrive, la page peut clignoter, se recharger sans fin, ou échouer avant que votre code ne s'exécute.

Les certificats comptent aussi. Si le certificat est invalide ou n'est pas encore émis pour le domaine personnalisé, certains navigateurs bloqueront les requêtes ou empêcheront les flux de connexion de s'ouvrir correctement.

Si la console est remplie d'avertissements de contenu mixte et d'erreurs de redirection, FixMyMess commence généralement par cartographier chaque requête que l'app fait en production, puis corrige les URLs HTTPS et les règles de redirection pour que la production se comporte comme la preview.

Cookies et authentification : pourquoi les connexions échouent en production

Quand la preview fonctionne mais la production échoue, la connexion est souvent la première chose qui casse. La preview paraît « normale », mais le domaine live change la façon dont le navigateur traite les cookies, les redirections et le stockage de session.

Les cookies sont liés à un domaine. Si la preview tourne sur un domaine de plateforme et le site live sur votre domaine personnalisé, le navigateur peut cesser d'envoyer le cookie de session même si vous n'avez pas touché au code.

Flags de cookie qui causent la plupart des surprises

Trois réglages décident si votre cookie de connexion survit au passage en production :

• Domaine (Domain scope) : un cookie défini pour preview.example-host.com ne sera pas envoyé à www.votredomaine.com. Hardcoder le domaine du cookie fonctionne souvent en preview et échoue silencieusement en production.
• SameSite : les logins basés sur redirections (Google, GitHub, magic links) peuvent casser si SameSite=Strict bloque le cookie au retour. Lax est souvent plus sûr pour les flux basiques.
• Secure : les cookies Secure ne sont envoyés qu'en HTTPS. Si votre site live a une étape HTTP (ou une chaîne de redirections compliquée), le cookie peut ne jamais être conservé.

Symptômes typiques :

• la connexion « réussit » mais vous retombez sur la page de login
• vous avez une boucle : connexion, redirection, connexion à nouveau
• ça marche en navigation privée mais pas en mode normal
• ça marche en preview mais seulement échoue sur votre domaine réel

OAuth et authentification hébergée : origines autorisées et URLs de redirection

Les fournisseurs d'auth ne font pas confiance automatiquement à votre domaine personnalisé. Les environnements de preview sont parfois whitelistés par défaut, tandis que votre domaine réel ne l'est pas. Le fournisseur peut rejeter le callback, ou votre appli peut recevoir le callback mais échouer l'échange de code parce que l'origine ne correspond pas.

Exemple : la preview utilise https://random-preview-host.com et le fournisseur est configuré pour ça. Vous passez à https://app.votredomaine.com, mais le fournisseur n'autorise toujours que l'origine de preview. La redirection semble correcte, puis vous tombez sur une page blanche, une notification d'erreur, ou l'écran de login à nouveau.

Avant de toucher au code, faites ces vérifications dans DevTools :

• Confirmez que le site live est entièrement HTTPS sans étape HTTP.
• Inspectez l'en-tête Set-Cookie (Domain, SameSite, Secure, expiration).
• Vérifiez que le cookie apparaît dans le stockage du domaine live et qu'il est envoyé sur la requête suivante.
• Pour OAuth, confirmez que le domaine live figure dans les origines autorisées et les réglages de redirect/callback.

Les problèmes d'auth sont une réparation courante pour FixMyMess. Nous traçons le cookie et le chemin de redirection bout à bout et corrigeons les réglages dépareillés pour que la connexion fonctionne de façon fiable en production.

CORS et appels API bloqués uniquement en production

Parfois l'interface se charge, mais tous les appels de données échouent parce que le navigateur refuse que votre frontend contacte votre API. Ce refus, c'est CORS (Cross-Origin Resource Sharing). En clair : le navigateur bloque un site web qui envoie des requêtes vers un domaine différent à moins que le serveur n'autorise explicitement cette origine.

C'est plus visible en production que sur la preview parce que les hôtes de preview sont parfois « traités différemment ». Votre API peut autoriser la preview mais pas votre vrai domaine.

À quoi ressemblent les échecs CORS

Dans la console ou l'onglet Réseau, vous verrez « blocked by CORS policy » ou une requête préflight qui échoue. Une préflight est une requête OPTIONS automatique que le navigateur envoie d'abord pour demander « est-ce autorisé ? »

Les préflights arrivent plus souvent qu'on ne le croit. Envoyer du JSON avec des en-têtes personnalisés, utiliser des méthodes comme POST/PUT, ou inclure des credentials (cookies) peut déclencher une préflight. Si le serveur ne répond pas correctement à OPTIONS, le navigateur bloque l'appel réel, même si l'API fonctionne dans des outils comme curl.

Côté API (ou fonctions serverless), contrôlez en priorité :

• autoriser l'origine exacte du site live (schéma + domaine + port)
• si vous envoyez cookies/headers d'auth, autoriser les credentials et ne pas utiliser l'origine wildcard
• autoriser les en-têtes réellement envoyés (souvent Content-Type, Authorization)
• autoriser les méthodes utilisées et répondre correctement aux OPTIONS
• vérifier que votre reverse proxy/CDN ne supprime pas les en-têtes CORS en production

Un scénario courant : une app générée par IA appelle api.myapp.com depuis preview.mytool.app et ça marche. Après le lancement, le frontend tourne sur myapp.com, mais l'API n'autorise toujours que preview.mytool.app, donc la connexion et les sauvegardes échouent dans le navigateur.

Si vous êtes bloqué, FixMyMess trouve souvent des problèmes CORS accompagnés d'autres bloqueurs (cookies non envoyés à cause des réglages de credentials) et vérifie la correction avec de vrais tests navigateur avant le relancement.

Cache, service workers et déploiements obsolètes

Parfois rien n'est « cassé » dans le code. Le domaine live sert simplement une version plus ancienne. Les serveurs de preview contournent souvent les couches de cache que votre domaine réel utilise.

Quand les caches servent la mauvaise version

Un CDN ou le cache du navigateur peut garder d'anciens bundles JavaScript même après un redeploy. Si votre build génère des fichiers comme app.123.js, mais que le HTML pointe encore vers app.122.js, les utilisateurs chargent un mélange d'anciens et de nouveaux fichiers. Le résultat semble aléatoire : boutons inopérants, pages blanches, ou erreurs impossibles à reproduire localement.

Signes communs d'assets obsolètes :

• l'UI ressemble à un ancien design après un déploiement
• des fichiers JavaScript ou CSS retournent des 404 dans l'onglet Réseau
• erreurs mentionnant des chunks manquants ou « unexpected token » dans un fichier JS
• seuls certains utilisateurs voient le problème (souvent mobiles)
• actualiser change le comportement

Service workers : une mauvaise version peut rester collée

Si votre appli a un service worker (commun dans les templates PWA), il peut continuer à servir une coque mise en cache du site. Une mauvaise release peut s'installer et persister même après correction. Les utilisateurs doivent parfois fermer tous les onglets, ou le flux de mise à jour du service worker doit être réparé.

Un autre piège facile est un changement de base URL. Si vous êtes passé d'un sous-domaine de preview à votre domaine réel, ou avez modifié le chemin d'hébergement, les chemins vers les assets statiques peuvent casser. Vous verrez des 404 pour des fichiers qui existent mais pas au chemin attendu.

Tests rapides pour éviter de deviner :

• ouvrez une fenêtre incognito et testez le site live
• faites un hard refresh (Ctrl/Cmd + Shift + R)
• dans DevTools, désactivez le cache et rechargez
• cherchez des réponses 304/404 pour les fichiers JS et CSS
• si un service worker existe, désenregistrez-le et rechargez

Si le domaine live continue à servir la mauvaise build, FixMyMess peut identifier si c'est un problème de cache, de service worker ou de sortie de déploiement avant que vous ne passiez des heures à chasser des « bugs fantômes ».

Étapes pas-à-pas : diagnostiquer la panne en 20 minutes

Commencez par nommer le symptôme exact sur le site live. Est-ce une page blanche (chargement), une page qui se charge mais sans données (appel API), ou une connexion qui marche en preview mais échoue en production (auth/cookies) ? Si vous choisissez le mauvais symptôme, vous pouvez perdre une heure à chasser la mauvaise piste.

Ouvrez le site live dans une fenêtre privée, puis ouvrez DevTools. Gardez deux onglets ouverts : Console et Réseau. La Console montre les échecs évidents (erreurs rouges). Le Réseau montre la première requête qui casse réellement.

1) Trouver la première vraie erreur

Dans la Console, cherchez des erreurs qui mentionnent des requêtes bloquées, CORS, contenu mixte, boucles de redirection ou variables d'environnement manquantes. Ignorez les warnings jusqu'à avoir expliqué la première erreur rouge.

Ensuite, allez dans Réseau, rechargez, et cliquez sur la première requête qui échoue (souvent le premier XHR/fetch). Notez l'URL de la requête, le code de statut et le message de réponse :

• 401/403 pointe généralement vers l'auth, les cookies ou un mauvais key/audience/issuer.
• 404 signifie souvent une URL erronée, une route manquante ou un chemin d'asset cassé.
• 500 indique la logique serveur ou une configuration cassée.
• Requêtes qui ne se terminent jamais peuvent être DNS, HTTPS ou une requête bloquée par le navigateur.

2) Comparer preview vs production à l'identique

Ouvrez la preview et la production côte à côte et répétez la même action (charger la page, cliquer sur connexion, récupérer des données). Comparez les détails de la requête qui échoue :

• différences d'URL (domaine, chemin, http vs https)
• en-têtes (absence de Authorization, Origin incorrect)
• cookies (non posés, non envoyés, domaine incorrect)
• corps de réponse (message d'erreur différent entre preview et production)

Si la preview appelle api.preview-host.com mais la production appelle localhost, c'est habituellement un problème de variable d'environnement, pas un bug profond en production.

Enfin, vérifiez les variables d'environnement en production chez votre fournisseur d'hébergement (pas seulement dans votre repo), puis faites un redeploy propre. Beaucoup d'apps générées par IA gardent d'anciennes valeurs jusqu'à une rebuild et un redeploy.

Si vous êtes bloqué après ces vérifications, FixMyMess peut lancer un audit gratuit du code et déterminer si c'est un problème d'env vars, domaine/CORS, HTTPS ou auth, puis le réparer avec vérification humaine.

Erreurs courantes qui font perdre le plus de temps

Quand quelqu'un dit « la preview fonctionne mais la production échoue », la cause n'est généralement pas un bug profond. C'est souvent un simple décalage entre environnements qui est négligé.

Les coupables répétés

La plupart du temps est perdu à poursuivre des symptômes (écran blanc, login cassé, 401) alors que la cause est une configuration basique :

• URLs de redirection d'auth non mises à jour pour le domaine réel. Le fournisseur n'autorise que le nom d'hôte de preview, donc les connexions en production rebondissent ou bouclent.
• URLs de preview codées en dur dans le frontend. Un seul https://preview-xyz... restant dans les appels API, callbacks OAuth ou websockets peut casser la production.
• Secrets envoyés au navigateur. Les apps générées par IA mettent parfois des clés privées dans les env vars côté client ou les intègrent au build frontend. Ça peut casser la production et c'est un problème de sécurité.
• Preview et production pointent vers des bases de données différentes. La preview peut utiliser des données de test alors que la production est vide ou a un schéma différent.
• Correctif appliqué mais pas réellement déployé. Caches de build, mauvais targets de déploiement ou variables d'env non mises à jour donnent l'impression que la correction n'a pas marché.

Un exemple réaliste : vous corrigez le mismatch du callback OAuth, mais la production échoue toujours parce que le frontend appelle encore la base API de preview. Deux petites erreurs, un résultat confus.

Comment éviter les tunnels temporels

Avant de réécrire du code, faites ces vérifications :

1. Confirmez que le domaine de production est listé partout où le fournisseur d'auth l'attend.
2. Cherchez dans la base de code le nom d'hôte de preview et remplacez-le par une configuration adaptée à la production.
3. Vérifiez quelles variables d'environnement sont côté serveur vs exposées au navigateur.
4. Confirmez que la connexion à la base de données de production et les migrations correspondent à ce que la preview utilisait.
5. Redeployez et videz les caches CDN/build pour que le site live serve le nouveau bundle.

Chez FixMyMess, ce sont les premières choses que nous regardons lors d'un diagnostic de codebase parce qu'elles sont fréquentes dans les prototypes générés par IA et faciles à manquer.

Checklist rapide et prochaines étapes

Quand la preview fonctionne mais le site live échoue, considérez d'abord une différence de configuration entre environnements. Vous ne poursuivez généralement pas un bug mystérieux, mais une différence entre deux environnements.

Commencez par l'essentiel sur le domaine live :

• Confirmez que le domaine pointe vers le déploiement prévu (bon projet, bonne branche, build le plus récent).
• Comparez les env vars de production aux valeurs de preview (URL base API, clés d'auth, URLs de callback, URL de DB).
• Chargez le site live avec la console ouverte et cherchez des avertissements HTTPS, des boucles de redirection et des erreurs de contenu mixte.
• Testez l'auth de bout en bout en production (inscription, connexion, déconnexion, actualisation). « Ça marche jusqu'au refresh » pointe souvent vers des cookies ou un réglage de domaine.
• Retestez en fenêtre privée et sur mobile. Les anciens cookies, assets en cache et service workers peuvent masquer le vrai problème.

Un exemple simple : en preview votre appli appelle http://api.myapp.local (OK en dev), mais en production la page est HTTPS et l'API est HTTP. Le navigateur bloque la requête. L'UI semble correcte jusqu'à ce que vous cliquiez sur un bouton, puis tout échoue.

Si vous ne parvenez toujours pas à isoler le problème, arrêtez de deviner et faites un audit ciblé. Les corrections les plus rapides proviennent souvent d'une revue conjointe de trois domaines : auth et cookies, secrets exposés, et architecture globale (les prototypes générés par IA embarquent souvent une logique emmêlée qui casse uniquement en production).

Si votre projet a été généré avec des outils comme Lovable, Bolt, v0, Cursor ou Replit et plante maintenant sur un vrai domaine, FixMyMess (fixmymess.ai) est conçu pour cette situation : diagnostiquer ce qui diffère entre preview et production, puis réparer la base de code pour qu'elle tienne en production.