DÉVELOPPEMENT LOCAL · TESTS EN CONDITIONS RÉELLES
Partager localhost : aperçu mobile et tests de webhooks
Votre site tourne sur votre ordinateur. Un lien HTTPS temporaire permet à votre téléphone, à un client ou à un service de webhooks d’y accéder, sans déploiement.
Avant de partager : vérifier l’adresse locale
Regardez l’URL affichée par votre serveur de développement. Le protocole et le port comptent : http://localhost:5173 et https://localhost:7143 sont deux destinations différentes. Ouvrez cette adresse exacte sur votre ordinateur et effectuez une action courante avant de créer le tunnel.
Une application, un port
Si la page et l’API utilisent la même adresse locale, un seul tunnel peut atteindre les deux. Les chemins sont conservés : une requête publique vers /contact atteint /contact dans l’application locale. Le tunnel ne copie ni ne déploie vos fichiers.
Frontend et API sur des ports distincts
Un tunnel vers le frontend ne publie pas automatiquement une API sur un autre port. Un navigateur appelant localhost:3000 contacterait l’appareil du visiteur. Utilisez le proxy API du serveur de développement ou une URL de test accessible pour l’API, puis adaptez le frontend.
Obtenir un lien public
Démarrez votre site ou votre API et vérifiez son accès local. GhostlyShare détecte automatiquement les applications web locales en cours d’exécution. Cliquez sur Go Public pour créer un lien HTTPS public.
- Laissez votre application et GhostlyShare fonctionner pendant le test.
- Ouvrez le lien dans une fenêtre de navigation privée avant de le partager.
- Utilisez des données de test. Ajoutez au besoin un mot de passe pour un aperçu réservé au client.
Windows et Linux. Des liens temporaires gratuits, sans compte, adresse e-mail ni abonnement.
Télécharger GhostlyShare ↗
Ouvrez l’adresse publique sur votre ordinateur puis sur un autre appareil. Si la page locale fonctionne mais pas la page publique, gardez les deux URL à portée de main pour distinguer un problème d’application d’un problème de tunnel ou de configuration d’hôte.
Ouvrir localhost sur votre téléphone
Sur votre téléphone, localhost désigne le téléphone lui-même, pas votre ordinateur. Ouvrez le lien public ou scannez le QR code dans GhostlyShare.
- Passez aux données mobiles pour vérifier l’accès hors de votre Wi-Fi.
- Testez le menu, les formulaires, le clavier et l’envoi de fichiers sur l’appareil réel.
- Ouvrez directement une page interne et rechargez-la. Vérifiez aussi les images et les réponses de l’API.
Vous testez uniquement sur le même Wi-Fi ? L’adresse réseau locale de votre ordinateur peut suffire si le serveur de développement et le pare-feu autorisent l’accès. Un tunnel public est utile depuis d’autres réseaux ou services externes.
Un test mobile utile en cinq minutes
- Navigation et mise en page
- Ouvrez le menu, faites pivoter le téléphone et consultez une longue page. Repérez le défilement horizontal, les boutons masqués et le contenu caché par un en-tête fixe. L’émulation du navigateur est utile, mais ne reproduit pas toutes les interactions d’un appareil réel.
- Formulaires et session
- Touchez chaque champ et envoyez une valeur invalide, puis une valeur valide. Vérifiez que les erreurs restent visibles au-dessus du clavier. Si la connexion fonctionne seulement sur votre ordinateur, testez une nouvelle session et vérifiez l’adresse de rappel et les paramètres des cookies.
- Requêtes et chargement
- Testez une page riche en images et une action qui charge des données. Une réponse lente via votre connexion domestique ne mesure pas les performances en production. Notez la page, l’appareil et l’action en échec pour reproduire le problème localement.
Présenter votre travail à un client
Envoyez la page précise à examiner. Indiquez ce qu’il faut tester et quand l’aperçu sera fermé.
Avant l’envoi
Utilisez un compte de test et du contenu fictif. Vérifiez que le lien fonctionne sans vos cookies ni votre session connectée.
Demander une vérification précise
Remplir le formulaire de contact, tester le menu mobile ou passer une commande avec un paiement de test : une tâche précise rend les retours plus utiles.
Voici l’aperçu pour notre échange d’aujourd’hui. Merci de vérifier le menu mobile et le formulaire de contact. Le lien sera fermé après notre appel.
Rendre les retours reproductibles
Demandez l’URL, l’appareil, le navigateur et la dernière action avant le problème. Une capture accompagnée de « j’attendais X, mais Y s’est produit » aide plus que « la page ne marche pas ». Prévenez si vous modifiez l’application pendant la revue : les visiteurs peuvent voir les changements ou un rechargement immédiat selon la configuration.
Recevoir un webhook en local
Un service de webhooks ne peut pas accéder au localhost de votre ordinateur. Donnez-lui l’adresse publique du tunnel suivie du chemin de rappel. Cet exemple suppose que votre application traite déjà les requêtes POST sur /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Remplacez YOUR-TUNNEL par votre véritable nom d’hôte et saisissez l’URL de rappel complète dans les paramètres de test du fournisseur.
- Gardez la vérification des signatures activée. Stockez le secret du webhook localement et envoyez un événement de test depuis le fournisseur.
- Vérifiez l’état de livraison et les journaux locaux. Renvoyez la réponse de réussite attendue par le fournisseur et gérez les nouvelles tentatives sans répéter l’action.
Une demande de mot de passe dans le navigateur peut bloquer l’émetteur du webhook. Utilisez un point de terminaison accessible au fournisseur et vérifiez ses requêtes signées. CORS concerne les requêtes du navigateur, pas les webhooks entre serveurs.
Vérifier la réponse du webhook, pas seulement la page
Ouvrir l’URL de rappel dans un navigateur envoie généralement une requête GET. Beaucoup de webhooks attendent POST : une erreur du navigateur ne suffit donc pas à conclure que la livraison échoue. Envoyez l’événement de test et comparez son horodatage et son identifiant de livraison avec votre journal local.
- 404 / 405
- Vérifiez le chemin et la méthode HTTP. Utilisez le port de l’API, pas forcément celui du frontend. Une page d’accueil accessible ne prouve pas que le point de terminaison de rappel existe.
- 401 / 403
- Identifiez le refus : mot de passe de l’aperçu, authentification de l’application ou vérification de signature. Pour les données signées, suivez les règles du fournisseur concernant le corps original de la requête ; le lire et le réécrire avant vérification peut invalider la signature.
- 5xx / Timeout
- Vérifiez que l’application tourne et a reçu la requête. Pour les traitements longs, respectez le délai de réponse du fournisseur et utilisez des tâches en arrière-plan si nécessaire. Testez une nouvelle livraison pour éviter de créer des commandes ou messages en double.
Utilisez le mode test du fournisseur et ne journalisez ni secrets ni données personnelles complètes. Un test réussi vérifie la livraison et le traitement par l’application ; il ne remplace pas les exigences d’intégration du fournisseur.
Le lien s’ouvre, mais quelque chose ne fonctionne pas ?
Le lien public n’atteint pas l’application
Ouvrez d’abord l’URL locale. Vérifiez le port, HTTP ou HTTPS, et que l’application et le tunnel fonctionnent toujours.
Des images ou appels API échouent
Recherchez les URL localhost codées en dur. Utilisez des chemins relatifs si possible. Une API sur un autre port nécessite sa propre route accessible.
L’application redirige vers localhost
Vérifiez l’URL de base publique, les proxys de confiance et les URL de rappel de connexion. Autorisez l’hôte exact de l’aperçu sans désactiver globalement les contrôles d’hôte.
Le rechargement à chaud ou les WebSockets échouent
Vérifiez que les WebSockets utilisent l’hôte public et wss sur une page HTTPS. Certains serveurs de développement demandent un hôte HMR distinct.
Le webhook ne reçoit pas de réponse de réussite
Vérifiez le chemin de rappel, la méthode HTTP, le secret de signature et le journal de livraison. Mettez l’URL de rappel à jour après le lancement d’un nouveau tunnel temporaire.
Terminer le test et arrêter le partage
Arrêtez le partage dans GhostlyShare ou le tunnel du terminal avec Ctrl+C. Une expiration peut fermer automatiquement un aperçu planifié. Supprimez aussi les URL de rappel temporaires chez le fournisseur de webhooks.
Besoin d’une adresse fixe pour un usage durable ?
Un aperçu temporaire n’est pas un déploiement. Notre guide d’hébergement à domicile explique les tunnels nommés, les domaines, les services Windows et les frais de fonctionnement.
Configurer un Cloudflare Tunnel permanent →Questions sur les aperçus locaux
FAQ
Pourquoi localhost ne fonctionne-t-il pas sur mon téléphone ?
Localhost désigne l’appareil qui ouvre l’adresse. Utilisez le lien d’aperçu public pour accéder depuis votre téléphone à l’application sur votre ordinateur.
Mon ordinateur doit-il rester allumé ?
Oui. Votre ordinateur, l’application locale et le tunnel doivent rester actifs. La mise en veille ou l’arrêt du tunnel rend l’aperçu indisponible.
Faut-il un domaine pour un aperçu ?
Non. Un tunnel temporaire fournit une adresse HTTPS publique. Mettez les liens partagés et les paramètres des webhooks à jour si cette adresse change.