Une page qui refuse de s’ouvrir peut vite devenir agaçante, surtout au moment de payer, de publier ou de reprendre le travail. Notre vérificateur vous apporte un second point de vue : saisissez l’adresse publique, consultez la réponse et choisissez la prochaine vérification utile. Le résultat concerne l’URL et l’heure indiquées ; une page introuvable ne devient pas, par raccourci, une panne mondiale.
Comment vérifier si un site est en panne ?
Saisir l’adresse pertinente
Utilisez la page précise si un lien est cassé, ou l’accueil si tout le site semble indisponible. Nous ajoutons HTTPS à un simple domaine. Un lien partagé remplit la saisie sans lancer le test.
Lire le résultat et son horaire
Commencez par le nom d’hôte, le code HTTP et l’heure. Dépliez les adresses DNS, les durées et les redirections. « Non vérifié » signifie que les preuves manquent, pas que le test est réussi.
Confirmer, comparer ou conserver
La confirmation ajoute une observation après une courte pause. La comparaison teste l’accueil séparément. Les formats PNG, TXT et JSON conservent les horaires, résultats et limites.
Des vérifications pour des situations concrètes
Un client ne peut pas ouvrir un produit
Vérifiez l’URL du produit, puis l’accueil. Un accueil accessible avec un produit en 404 oriente vers le lien ou la route, sans prouver une panne de la boutique. Le paiement reste non testé.
Votre nouveau site semble indisponible
Après un changement de domaine ou d’hébergement, examinez le DNS et la destination finale. Notez les adresses et l’heure. Évitez de modifier plusieurs réglages avant d’isoler la couche concernée.
Un service fonctionne pour quelqu’un d’autre
Gardez le résultat externe avec votre erreur de navigateur. Essayez un autre navigateur ou réseau. Une différence aide l’assistance, mais ne diagnostique pas une panne nationale.
Préparer une demande d’assistance utile
Téléchargez l’URL, l’heure, le code et les redirections. Décrivez séparément ce qui échoue dans votre navigateur. Retirez les paramètres confidentiels avant tout partage.
Que permet d’établir notre vérificateur ?
Comprendre la disponibilité d’un site
Pourquoi un site fonctionne-t-il pour une personne, mais pas pour une autre ?
« Chez moi, ça marche » décrit un seul parcours. L’appareil, le navigateur et le réseau peuvent différer. Notre vérification ajoute un point de vue sans invalider votre expérience.
Comparez la même URL dans un autre navigateur, puis sur un autre réseau si possible. Notez l’heure et l’erreur ; changez une chose à la fois. Ne désactivez pas largement les protections de sécurité.
Une réponse externe avec une page vide sur votre appareil invite à vérifier rendu, extensions ou connexion. Deux échecs similaires justifient une enquête, sans établir que tous les visiteurs sont touchés.
Une page cassée équivaut-elle à une panne du site ?
Des produits supprimés, campagnes anciennes ou routes modifiées laissent des liens cassés sur un site sain. Tester le chemin exact et tester le domaine répondent à deux questions différentes.
Comparez l’accueil sans perdre le premier résultat. Un accueil réussi peut circonscrire un problème de page. Il peut aussi rester accessible alors qu’une autre partie de l’application échoue.
Conservez l’URL complète dans votre message à l’assistance. Une capture générale « site en panne » rend la reproduction difficile. Notre rapport rassemble l’adresse et l’heure réellement vérifiées.
Que disent les codes HTTP, et que ne disent-ils pas ?
La référence des codes HTTP distingue succès 2xx, redirection 3xx, erreurs liées à la requête 4xx et erreurs serveur 5xx. Un refus 403 ou une page 404 diffère d’une absence totale de réponse.
Un code n’explique pas la cause profonde. Une erreur de passerelle ne révèle ni la dépendance ni le déploiement responsable. Les gestionnaires ont besoin de leurs journaux ; les visiteurs peuvent conserver les preuves et contacter le service.
Retry-After demande d’attendre un délai ou une date avant de réessayer. Nos boutons respectent une indication exploitable. Sans indication, une pause évite tout de même les clics répétés.
Une réponse HTTP 200 peut-elle mener à une page défectueuse ?
Oui. Une réponse réussie peut contenir le mauvais contenu, une demande de connexion ou une erreur. Des scripts et requêtes ultérieures peuvent échouer. Notre verdict ne teste pas ces interactions.
Une porte ouverte ne prouve pas que tout fonctionne à l’intérieur. L’accueil d’une boutique peut répondre tandis que le panier ou le paiement échoue. Nous confirmons une réponse, pas l’intégralité d’un processus commercial.
L’explication de Google sur le traitement JavaScript distingue récupération et rendu. Ouvrez la page et utilisez notre test de rendu si son apparence pose problème. Les essais de compte ou de paiement nécessitent une autorisation et des données adaptées.
Comment le DNS a-t-il rendu les adresses de sites utilisables à grande échelle ?
Les noms lisibles évitent de mémoriser une adresse numérique. La RFC 1034 de novembre 1987 décrit une architecture hiérarchique distribuée et la mise en cache. Cela éclaire la séparation entre nom et disponibilité de l’application.
Trouver une adresse publique ne prouve pas qu’une application y répond. À l’inverse, un échec de résolution peut arrêter le parcours avant HTTP. Notre résultat sépare ces deux étapes.
Notez les modifications de configuration du domaine et leurs horaires. Des réponses mises en cache compliquent les comparaisons. Le TTL affiché ne garantit pas l’instant où tous les réseaux adopteront un changement.
Pourquoi une vérification ne donne-t-elle pas un taux de disponibilité ?
Une observation ne fournit aucun historique complet. Deux confirmations restent deux observations, pas une courbe de 24 heures. Les recommandations sur les niveaux de service de Google définissent les indicateurs sur une période choisie.
Exemple purement fictif : 30 jours entièrement observés représentent 43 200 minutes. Avec 30 minutes indisponibles, (43 200 − 30) ÷ 43 200 × 100 donne environ 99,9306 %. Notre outil n’a pas mesuré ces valeurs.
La surveillance doit définir les échecs, traiter les données manquantes et choisir les parcours utilisateurs importants. Utilisez un service de monitoring pour les mesures planifiées et alertes, notre outil pour une investigation ponctuelle.
Que conserver avant de signaler une panne ?
Gardez l’URL publique exacte, l’heure avec le fuseau, l’erreur du navigateur et notre résultat. Mentionnez un VPN ou réseau différent si cela compte. Ne publiez ni mot de passe, ni cookie de session, ni lien signé.
Si vous gérez le site, rapprochez l’incident des publications, changements DNS et journaux. Reproduisez la plus petite action en échec. Un accueil accessible invite à examiner la route concernée avant de redémarrer tout le serveur.
Conservez aussi les erreurs après le rétablissement. Une confirmation différente aide à comprendre l’évolution, sans préciser le début ou la fin de l’incident : l’intervalle entre les observations n’a pas été mesuré en continu.
Précision, limites et corrections
Nous effectuons une requête externe anonyme vers l’adresse publique saisie, examinons le DNS, suivons les redirections autorisées et classons la réponse. La durée DNS couvre la résolution. Le parcours couvre les requêtes HTTP, redirections et résolutions de leurs destinations ; la durée finale couvre la dernière requête jusqu’à ses en-têtes. Sans réponse finale, sa durée et son protocole ne sont pas vérifiés.
Ce n’est ni une surveillance continue ou mondiale, ni un audit de certificat, ni un rendu de navigateur, ni un parcours connecté. Annuler empêche un résultat tardif de modifier l’écran ; une requête externe déjà lancée peut encore finir dans son délai. Les paramètres sont transmis lors d’un test explicite, mais exclus de l’historique local. Ne partagez que des adresses publiques non sensibles.
Si le résultat semble incorrect, gardez l’URL, l’heure, le code et l’étape en échec. Confirmez une fois ou comparez l’accueil, puis envoyez les preuves non confidentielles via notre page de contact. Nous examinons classification, formulation et défauts reproductibles, sans pouvoir changer un site tiers ou mesurer rétroactivement une panne non observée.
Vos questions
Mon site est-il en panne, ou suis-je le seul concerné ?
Un succès externe avec un échec du navigateur indique des conditions différentes, pas une cause locale certaine. Comparez navigateur ou réseau. Un échec externe doit être confirmé et replacé dans son étape.
Un code 403 ou 429 signifie-t-il que le site est hors ligne ?
Non. Le serveur a refusé ou limité la requête. Essayez un navigateur et respectez le délai indiqué. Nous parlons de restriction, pas d’une panne générale.
Un code 404 signifie-t-il que tout le site est en panne ?
Non. Il concerne la page demandée. Comparez l’accueil et vérifiez le chemin de l’URL. Une page absente et un hôte injoignable demandent des démarches différentes.
Pourquoi la durée diffère-t-elle de celle de mon navigateur ?
Nous mesurons un parcours externe, pas le chargement complet sur votre appareil. Réseau, redirections et activité du navigateur peuvent différer. Ce n’est pas une mesure de débit.
Puis-je vérifier un réseau privé ou une URL signée ?
Les destinations privées, identifiants et ports inhabituels sont interdits. Ne soumettez pas de lien secret. Les paramètres restent présents lors d’une vérification publique explicite ; examinez-les avant.
La confirmation vérifie-t-elle plusieurs pays ?
Non. Elle ajoute une observation et conserve les deux heures, sans choisir un autre pays, surveiller le monde ou calculer un taux historique.
Que contient le rapport téléchargé ?
URL, heure, verdict, réponse HTTP, DNS, redirections, durées et limites. Les observations complémentaires disponibles sont incluses. PNG ajoute ClockTools et le lien de l’outil.
Que se passe-t-il quand j’annule ou réinitialise ?
La requête du navigateur est annulée et les résultats anciens ne peuvent plus remplacer l’écran. Réinitialiser efface aussi la saisie et les résultats. Une requête externe déjà lancée peut encore terminer dans son délai.