Pourquoi votre lien localhost échoue quand vous le partagez

Si le lien fonctionne seulement chez vous, examinez l’adresse envoyée

Vous préparez le programme d’une journée sur votre ordinateur portable. L’aperçu fonctionne et vous copiez son adresse pour l’envoyer ou créer un QR. Votre navigateur affiche le programme, mais le téléphone signale une erreur. Avant de modifier la présentation ou de refaire les images, regardez le nom du serveur : un aperçu local n’est pas forcément une page publiée sur Internet.

Les questions réelles sur l’ouverture de localhost depuis un téléphone ou un autre réseau ont un point commun : transmettre du texte ne rend pas accessible le serveur qui le traite. Ce guide distingue trois situations et propose une méthode pour diffuser un programme public. Il ne transforme pas un environnement de développement en hébergement et ne suppose pas que l’échec concerne les autorisations d’un compte. Vérifiez d’abord où pointe l’adresse.

Localhost désigne l’appareil qui effectue la requête

Le nom localhost a un usage spécial : la RFC 6761 explique qu’il doit se résoudre vers une adresse de boucle locale, ou loopback. Habituellement, le navigateur cherche le service sur son propre appareil. Le localhost du portable ne désigne donc pas ce portable pour le téléphone. Ouvrir la même adresse sur le mobile vise son environnement local, où le programme préparé ne se trouve probablement pas.

Les deux exemples sont des destinations locales, pas des invitations publiques. 127.0.0.1 est une adresse IPv4 de boucle locale ; le port 3000 distingue un service sans modifier la portée de l’adresse. Copier le lien, ajouter des UTM, le raccourcir ou l’inscrire dans un QR ne change pas cette signification. Gardez ces adresses pour votre travail local, sans les prendre pour la destination utilisable par n’importe quel participant. Aucun outil externe n’est nécessaire pour reconnaître ce problème.

http://localhost:3000/programa
http://127.0.0.1:3000/programa

Une adresse privée n’est pas non plus une publication Internet

Remplacer localhost par une adresse du réseau local peut servir à un test autorisé entre appareils, mais ne signifie pas publier. La RFC 1918 réserve des plages privées, dont 192.168.0.0/16. L’exemple 192.168.1.25 pourrait identifier une machine dans un réseau précis ; ce n’est pas une destination universelle pour d’autres réseaux. Même sur le même wifi, le service et les règles d’accès doivent permettre la connexion.

Pour un test interne, convenez de l’adresse et des conditions avec la personne administrant l’environnement. Un réseau d’entreprise ou un accès distant autorisé est un autre contexte, pas une raison de publier des informations internes. Pour un programme public, demandez une adresse publiée appropriée. Ne désactivez pas le pare-feu et n’ouvrez pas des ports du routeur comme solution improvisée pendant la préparation d’une affiche. Vérifier une URL ne remplace pas la configuration et la protection du serveur.

http://192.168.1.25:3000/programa

Obtenez une adresse publiée pour le contenu réellement public

Publier demande de placer le contenu sur un service web accessible au public prévu. MDN distingue les fichiers de travail de leur publication et explique le rôle de l’hébergement et de l’adresse web. Si quelqu’un gère votre site, transmettez-lui le programme approuvé et demandez son URL définitive. Si vous publiez vous-même, suivez la procédure de votre hébergement en vérifiant le contenu et la configuration mis à disposition des visiteurs.

Remplacer le texte localhost par un domaine ne suffit pas : ce domaine doit mener à un service proposant réellement la page. L’adresse fictive utilise example.invalid et ne fonctionne pas comme site de test. Remplacez-la par l’URL réelle seulement après publication. Conservez le chemin correct du programme et vérifiez images, styles et liens. Une page publiée appelant encore des ressources de localhost peut sembler complète sur votre ordinateur et échouer pour les autres.

https://example.invalid/programa

Vérifiez la destination publique avec WikiURL et depuis un autre contexte

Avec une URL publique sans secrets, utilisez Vérifier une URL de WikiURL. Examinez la réponse HTTP et l’adresse finale détectée en cas de redirections. L’outil précise ne pas accepter les adresses de réseaux privés : ne l’utilisez pas pour explorer votre réseau ou tester des services locaux. Si une restriction ou un blocage apparaît, interprétez le résultat dans le cadre de cette vérification, sans conclure automatiquement que le site est inaccessible à tous.

Ouvrez ensuite le lien publié sur votre téléphone, et si possible depuis une connexion différente de celle de l’ordinateur de développement. Vérifiez programme, images et navigation. Une réponse 200 ne prouve pas qu’il s’agit de la page attendue : cela peut être une page d’accueil ou de connexion. Vérification technique et examen visuel répondent à des questions différentes. Assurez-vous aussi qu’aucun lien de la page ne vous ramène à une adresse locale.

Créez les supports de partage à partir de la version approuvée

Utilisez seulement ensuite l’adresse publique confirmée dans votre message, lien court ou générateur QR WikiURL. Vérifiez la destination de la version finale et testez le QR dans le support qui sera distribué. Ne réutilisez pas par erreur le fichier créé avec l’aperçu. Si l’adresse de publication change, actualisez les copies encore sous votre contrôle et notez la version approuvée, plutôt que de supposer qu’un ancien QR s’est modifié automatiquement.

Enregistrez l’adresse publique et les résultats des contrôles séparément des adresses de développement. Si le contenu doit rester interne, conservez l’accès convenu et ne le publiez pas uniquement pour satisfaire un vérificateur externe. L’objectif est de faire correspondre destination et public : travail local pour votre appareil, accès interne pour les personnes concernées et site publié quand le programme doit s’ouvrir depuis l’extérieur.