Page blanche sur votre site : un arbre de décision de triage pour fondateurs

Ce que signifie souvent une “page blanche"

Une “page blanche” n'est pas toujours un écran blanc littéral. Parfois vous avez un en‑tête sans contenu, un spinner qui ne finit jamais, ou un tableau de bord dont la mise en page s'affiche mais dont les cartes restent vides.

L'erreur que font la plupart des fondateurs est d'essayer des corrections aléatoires (rafraîchir en boucle, tout vider, modifier le code) avant de savoir quel type de problème c'est. Un triage rapide transforme un symptôme effrayant en une étiquette claire : navigateur, compte, ou serveur/build.

Avant de toucher quoi que ce soit, prenez deux minutes pour rassembler des signaux.

Ayez ceci prêt :

• L'URL exacte de la page où ça se produit
• Une fenêtre incognito/privée
• Un deuxième navigateur (ou le même navigateur sur un autre appareil)
• Un compte affecté (et, idéalement, un deuxième compte)
• Une courte note sur ce que vous voyez (écran blanc, spinner bloqué, mise en page à moitié chargée)

Ce que vous cherchez à savoir :

• Marche en incognito, échoue en mode normal : cookies, cache, extensions ou état local du navigateur
• Échoue sur plusieurs navigateurs/appareils : build, déploiement, backend, ou crash côté client qui touche tout le monde
• N'échoue que pour un compte : permissions, données utilisateur, rôles/feature flags ou une réponse API spécifique à l'utilisateur

Exemple : si un fondateur voit un tableau de bord vide après connexion mais qu'un coéquipier peut l'afficher, vous penchez déjà vers « problème lié au compte », pas « site indisponible ».

Capturez les éléments de base avant de modifier quoi que ce soit

De bonnes notes résolvent les problèmes plus vite que des clics frénétiques.

Notez ce que vous attendiez versus ce que vous avez réellement vu. « Le tableau de bord doit afficher mes projets » est exploitable. « C'est cassé » ne l'est pas.

Les détails minimaux qui vous feront gagner des heures plus tard :

• URL exacte (copier depuis la barre d'adresse)
• Heure à laquelle c'est arrivé (ajoutez le fuseau horaire si possible)
• Ce que vous attendiez vs ce qui s'est produit
• Appareil et navigateur (Mac Chrome, iPhone Safari)
• Réseau (Wi‑Fi domestique, Wi‑Fi du bureau, hotspot)

Faites une capture d'écran même si ça ressemble à « rien ». Un écran blanc, un spinner bloqué et un en‑tête manquant pointent souvent vers des causes différentes.

Rafraîchissez une fois, puis arrêtez. Les boucles de rafraîchissement rapides peuvent déclencher des limites de taux, des déconnexions ou mettre l'app dans un état différent.

Étape 1 : Essayez le mode incognito

Le mode incognito/privé est le moyen le plus rapide de séparer « mon navigateur est confus » de « l'app est cassée ». Il démarre avec une session propre.

Faites ceci :

• Ouvrez une fenêtre incognito/privée
• Collez la même URL exacte
• Si la page demande une connexion, connectez‑vous et répétez l'action qui mène à la page blanche
• Notez ce qui se passe (charge, reste blanc, clignote puis devient blanc)
• Copiez tout message d'erreur exactement

Comment interpréter le résultat :

• Si ça marche en incognito, suspectez les cookies (session corrompue), fichiers mis en cache (ancien JavaScript), les valeurs de local storage ou une extension qui interfère.
• Si c'est toujours vide en incognito, ne perdez pas de temps à vider les caches tout de suite. Vous avez appris que ce n'est probablement pas seulement vos cookies existants.

Étape 2 : Essayez un autre navigateur (et un autre appareil si possible)

Ensuite, testez la même URL dans un navigateur différent. Certains problèmes de « page blanche » sont spécifiques à un navigateur même quand le serveur fonctionne.

Gardez le test propre : même connexion, mêmes étapes, pas de changements supplémentaires.

Un ordre simple qui marche :

• Ouvrez la page dans un deuxième navigateur que vous n'utilisez pas habituellement
• Essayez une fenêtre privée dans ce deuxième navigateur
• Vérifiez la page sur votre téléphone
• Si possible, testez votre téléphone en données mobiles (désactivez le Wi‑Fi)

Schémas à surveiller :

• N'échoue que dans un navigateur : extension, stockage bloqué, ressource mise en cache ou particularité du navigateur
• Échoue sur tous les navigateurs du même ordinateur : moins probablement une particularité du navigateur
• Marche en données mobiles mais pas sur le Wi‑Fi du bureau : VPN, filtrage DNS, ou pare‑feu/proxy d'entreprise
• Échoue partout sur tous les appareils et réseaux : déploiement/build/backend ou crash frontend qui touche tout le monde

Tenez un journal de test en une ligne pour ne pas boucler : « Chrome Mac (Wi‑Fi) : blanc. Safari Mac (Wi‑Fi) : charge. iPhone (données mobiles) : charge. »

Étape 3 : Vérifiez si un seul compte est affecté

Maintenant, retirez « mon compte » de l'équation.

1. Déconnectez‑vous et chargez d'abord une page publique (page d'accueil, tarification, page marketing). Si les pages publiques fonctionnent mais que l'espace app est vide après connexion, le problème implique souvent l'authentification, les permissions ou un appel API post‑login.

2. Comparez les comptes. Demandez à un collègue de se connecter et de charger la même page.

3. Si possible, essayez un compte test tout neuf. Les nouveaux comptes ont généralement des données propres, ce qui aide à révéler si un enregistrement utilisateur déclenche le crash.

Lecture rapide sur les résultats :

• Marche pour d'autres comptes, échoue seulement pour le vôtre : session/cookies, enregistrement utilisateur corrompu, bug de rôle/permission, ou une page qui ne gère pas vos données spécifiques
• Échoue pour plusieurs comptes : échec backend/API partagé, crash frontend sur un chemin commun, ou mauvais déploiement
• Pages publiques chargent mais pages app vides : flux d'auth ou requête post‑login qui échoue

Exemple : si le tableau de bord est vide seulement pour un compte admin, un widget réservé aux admins pourrait faire un appel API en échec et faire tomber toute la page.

Si ça marche en incognito : cookies, cache et extensions

Si l'incognito fonctionne, votre serveur est probablement OK. Concentrez‑vous sur ce qui diffère dans votre navigateur normal : données de session stockées, fichiers mis en cache, extensions ou paramètres de confidentialité du navigateur.

Commencez petit. Réparez uniquement pour votre domaine, pas pour tout le navigateur.

Corrections sûres, dans l'ordre

Essayez un changement à la fois et retestez après chaque :

• Effacez les données du site seulement pour votre domaine (cookies et local storage), puis reconnectez‑vous
• Hard refresh (rechargement sans cache)
• Désactivez les extensions, puis réactivez‑les une par une pour trouver la coupable (ad blockers et bloqueurs de scripts sont fréquents)
• Désactivez temporairement la protection stricte contre le tracking pour tester rapidement, puis remettez‑la
• Essayez un profil de navigateur neuf (ou le mode invité) pour confirmer que c'est lié à votre profil habituel

Ce qu'il faut éviter :

• Ne faites pas « tout vider les données de navigation » en premier. Cela efface des indices utiles et vous déconnecte partout.
• Ne modifiez pas le code de l'app si l'incognito fonctionne. Vous risquez de chasser le mauvais type de problème.

Une fois que vous trouvez le déclencheur (une extension, une réinitialisation de cookie, un paramètre de confidentialité), notez‑le. Ce détail empêche généralement les récidives.

Si ça échoue partout : probablement un problème de serveur ou de build

S'il est vide en navigation privée, dans un autre navigateur et sur un autre appareil, considérez‑le comme un problème applicatif jusqu'à preuve du contraire.

D'abord, écartez un cas réseau en changeant de réseau (hotspot téléphone au lieu du Wi‑Fi du bureau). Si cela corrige le problème, suspectez des règles de pare‑feu, un filtrage DNS, VPN ou proxy.

Ensuite, séparez « impossible d'atteindre le site » de « le site charge mais l'app ne se rend pas » :

• Si le domaine ne se résout pas ou que vous ne pouvez rien charger, pensez DNS, hébergement ou certificat.
• Si vous voyez la coquille (en‑tête/mise en page) mais la zone principale est vide, pensez à un crash frontend ou à une erreur d'API.

Puis cherchez les changements récents. Les pages blanches commencent souvent juste après un déploiement, une mise à jour d'une variable d'environnement, un changement de fournisseur d'auth ou une édition de configuration faite dans la précipitation.

Si vous avez accès aux logs, concentrez‑vous sur l'heure exacte où vous l'avez reproduit. Indices fréquents :

• Pic d'erreurs 500
• "Failed to fetch" ou erreurs CORS
• Échecs de vérification de token/auth
• Variables d'environnement manquantes lors du build
• Timeouts ou erreurs de connexion à la base

Pièges courants qui font perdre du temps

Les pages blanches semblent urgentes, donc on commence à tout faire en même temps. C'est comme ça qu'on perd le signal.

Les plus gros gouffres temporels :

• Boucles de rafraîchissement qui ne changent rien et n'apprennent rien
• Changer plusieurs variables à la fois (vider le cache, se déconnecter, désactiver des extensions, redeployer) ce qui empêche de savoir ce qui comptait
• Tester uniquement avec votre compte admin et rater un échec lié à un rôle ou à des données utilisateur
• Oublier le dernier vrai changement (déploiement, plugin, update d'une variable d'env, réglage d'auth)

Une règle utile : changez une chose, observez, notez.

Checklist de 5 minutes pour restreindre le problème

Répondez à ces questions dans l'ordre et notez chaque résultat :

• Test incognito : ça charge dans une fenêtre privée après s'être reconnecté ?
• Test navigateur : ça charge dans un navigateur différent ?
• Test compte : ça charge pour un autre utilisateur (ou un compte test neuf) ?
• Test appareil/réseau : ça charge sur un deuxième appareil ou sur un autre réseau (hotspot OK) ?
• Preuves : avez‑vous l'URL exacte, l'horodatage et une capture d'écran ?

Comment agir selon le schéma :

• Marche seulement en incognito : quelque chose dans votre navigateur normal gêne (cookies, cache, extension, local storage)
• Échoue sur deux navigateurs et deux réseaux : arrêtez les corrections locales et investiguez le déploiement/build/backend/frontend
• N'échoue que pour un compte : concentrez‑vous sur les données utilisateur, les rôles/permissions et les enregistrements limites

Quand vous escaladez, envoyez des faits : l'URL, l'heure, les tests effectués, ce que vous attendiez, ce que vous avez vu et tout texte d'erreur de la console que vous pouvez copier.

Exemple : tableau de bord vide pour un utilisateur vs pour tout le monde

Situation courante : les pages marketing chargent, mais le tableau de bord devient vide juste après la connexion.

Scénario A : un seul compte

Vous voyez un écran blanc. En incognito ça marche. Dans un autre navigateur ça marche.

C'est un problème d'état local (cookie/session/bundle mis en cache/extension) ou lié aux paramètres de votre compte que votre session normale lit différemment. Arrêtez une fois que vous pouvez reproduire le schéma de façon cohérente et escaladez avec les preuves.

Scénario B : la plupart des utilisateurs

L'incognito est vide. Un deuxième navigateur est vide. Un autre appareil ou un coéquipier voit la même chose.

Cela indique un échec de déploiement/build/backend ou un crash frontend sur une route commune. N'envoyez pas d'hypothèses. Envoyez une note de reproduction courte :

• URL exacte et quel écran est vide
• Les tests que vous avez faits (incognito, navigateur, appareil) et leurs résultats
• Si c'est un ou plusieurs comptes
• Quand ça a commencé et ce qui a changé récemment
• Capture d'écran et tout texte d'erreur de la console

Étapes suivantes : escaladez clairement (et quand faire appel à FixMyMess)

Si la page blanche apparaît sur plusieurs navigateurs/appareils, traitez‑la comme une panne. Visez la rapidité et la clarté, pas plus d'expérimentations.

Escaladez immédiatement si :

• Les nouvelles inscriptions ne peuvent pas se terminer
• La connexion échoue pour de nombreux utilisateurs
• Le paiement/checkout échoue
• L'app est vide sur plusieurs appareils et réseaux
• Le problème a démarré juste après un déploiement ou un changement de variable d'environnement

Demandez trois choses : ce qui échoue, pourquoi c'est arrivé, et ce qui sera changé pour réparer (plus comment la correction sera vérifiée).

Si l'application a été générée par des outils comme Lovable, Bolt, v0, Cursor ou Replit, les écrans vides sont souvent causés par des flux d'auth fragiles, des secrets manquants ou exposés, ou des discordances de build/déploiement qui n'apparaissent qu'en production. Dans ces cas, un diagnostic externe rapide peut coûter moins cher que des essais pendant un incident. FixMyMess propose un audit de code gratuit et se concentre sur la transformation des prototypes générés par IA en logiciels prêts pour la production, y compris la réparation de la logique, le renforcement de la sécurité et la préparation au déploiement.