J’ai créé Gitae parce que je revenais sans cesse à la même question pratique : le site est-il réellement indisponible, ou le problème vient-il seulement de mon côté ?
Un seul onglet de navigateur est un mauvais outil de diagnostic. Une page peut ne pas charger parce que le serveur d’origine est en panne, mais aussi à cause du DNS, d’un problème de certificat HTTPS, du routage, d’une règle de pare-feu, d’un port fermé ou filtré, du FAI, d’un chemin VPN, de l’état du navigateur ou d’un cache local. Le symptôme visible est le même ; l’action à entreprendre ne l’est pas.
C’est ce que je voulais résoudre avec Gitae : ne pas simplement afficher du vert ou du rouge, mais aider à réduire le problème à la couche qu’il faut examiner ensuite.
Le vrai problème derrière « le site est down »
Beaucoup de vérificateurs simples répondent à une question étroite : cette URL a-t-elle répondu depuis un emplacement donné à un instant donné ? C’est utile, mais ce n’est pas encore un diagnostic de panne.
Si le DNS est incorrect, redémarrer l’application ne sert à rien. Si HTTPS échoue à cause du certificat, modifier le contenu de la page est hors sujet. Si un port TCP n’est pas accessible, le serveur peut malgré tout fonctionner. Et si le site s’ouvre depuis un serveur externe mais pas depuis ma connexion, le problème peut se trouver quelque part entre mon réseau et la destination plutôt que sur le serveur applicatif.
J’ai donc construit Gitae autour d’une idée simple : un site web est une chaîne de dépendances, et chaque test apporte des éléments sur une partie seulement de cette chaîne.
Une vue externe, pas un verdict absolu
Les tests de Gitae s’exécutent depuis mes propres serveurs VDS à Moscou et Helsinki. J’obtiens ainsi des points de vue extérieurs à la machine et au réseau où j’ai constaté le problème.
Si le site échoue localement mais répond depuis les deux VDS, c’est un indice utile : l’origine n’est au moins pas inaccessible partout. Je regarde alors davantage le DNS local, le routage du FAI, le VPN, le navigateur, le pare-feu ou un autre problème dépendant du chemin réseau. Si les sondes distantes échouent elles aussi, l’hypothèse d’un problème côté serveur, DNS, certificat, routage ou réseau plus large devient plus crédible.
Mais une vérification distante n’est pas automatiquement « plus fiable » qu’une vérification locale. Deux emplacements ne représentent pas tout Internet. Un site peut fonctionner à Moscou et Helsinki tout en échouant depuis un autre pays, FAI, edge CDN ou réseau. Je considère le résultat distant comme un point d’observation supplémentaire, pas comme un verdict mondial.
Ce que Gitae vérifie aujourd’hui
- Website check — vérifie si une URL répond depuis un serveur externe.
- SSL check — examine l’état du certificat HTTPS/TLS et les problèmes liés au certificat.
- DNS check, nslookup et dig — montrent comment un domaine se résout et quels enregistrements DNS sont retournés.
- Reverse DNS et IP check — affichent les informations IP et PTR/reverse-DNS.
- Domain info et domain age — donnent des métadonnées de base sur le domaine.
- Port check — teste si un port cible est joignable depuis le point de contrôle.
- Find your IP — affiche l’adresse IP publique visible par le service.
- Ping et traceroute — fournissent des signaux réseau sur la latence, la perte de paquets et le chemin.
- Hosting check et CMS detection — exposent des indices d’infrastructure et de technologie.
Je traite volontairement ces résultats comme des signaux. Un enregistrement PTR ne prouve pas le propriétaire d’un serveur. Une détection CMS fondée sur des empreintes publiques ne prouve pas le stack exact. Un port inaccessible depuis une sonde peut être filtré sur le chemin plutôt que fermé partout.
Comment j’interprète les résultats
La valeur vient de la combinaison des tests, pas de leur lecture isolée.
Si le DNS renvoie l’adresse attendue, le certificat HTTPS est valide et le site répond depuis les deux VDS alors que je ne peux toujours pas l’ouvrir localement, je vais d’abord enquêter sur le chemin local avant de modifier le serveur. À l’inverse, si la résolution DNS est incohérente ou si la vérification distante échoue aussi, j’ai davantage de raisons d’examiner l’infrastructure.
Ping et traceroute demandent également de la prudence. ICMP peut être filtré ou limité. Un hop absent dans traceroute ne signifie pas automatiquement que ce routeur est en panne, et un hôte qui ne répond pas au ping peut tout à fait servir HTTPS. Ces outils ajoutent du contexte ; ils ne fournissent pas un diagnostic définitif.
Mon principe est donc simple : un test réussi ne prouve pas que tout le système est sain, et un test échoué n’explique pas à lui seul la cause.
Disponibilité et SEO : ne pas confondre les concepts
La disponibilité compte aussi pour le SEO, mais une panne technique n’est pas la même chose qu’un problème de classement. Crawling n’est pas indexing, et indexing n’est pas traffic.
Si un crawler ne peut pas atteindre le site à cause d’une erreur DNS, réseau ou serveur, il ne peut pas récupérer correctement le contenu concerné à cet instant. Google indique que les erreurs réseau et DNS pendant le crawl sont traitées de manière similaire aux erreurs serveur 5xx, et qu’une indisponibilité prolongée peut affecter le crawl et des URL déjà indexées. Cela ne signifie pas qu’une courte panne provoque automatiquement une perte SEO, ni qu’un outil de diagnostic peut prouver qu’une variation de trafic ultérieure a été causée par cette panne.
Pour les utilisateurs, c’est plus simple : s’ils ne peuvent pas accéder au site, ils ne peuvent pas l’utiliser. Selon le projet, cela peut représenter des sessions, leads, conversions ou revenus perdus. Le diagnostic technique ne mesure toutefois pas cet impact commercial.
Un ordre pratique pour diagnostiquer un site « down »
- Confirmer le symptôme depuis un autre réseau. Ne pas supposer que son navigateur représente tout Internet.
- Vérifier le DNS. Confirmer la résolution et les enregistrements attendus.
- Vérifier HTTPS/TLS. Examiner le certificat et les erreurs de connexion.
- Vérifier le port nécessaire. Tester sa joignabilité depuis la sonde.
- Comparer les signaux réseau. Utiliser ping et traceroute comme contexte supplémentaire.
- Regarder IP, reverse DNS, hébergement et CMS. Ces indices peuvent aider à confirmer que l’on atteint l’infrastructure attendue.
- Ensuite seulement, réduire la zone de recherche. Décider si les indices pointent davantage vers l’application, le serveur, le DNS, le chemin réseau ou l’environnement local.
Ce n’est pas un protocole universel d’incident response. C’est surtout un moyen d’éviter l’erreur que je voulais éliminer : modifier la mauvaise couche alors que la seule information de départ est « le site ne s’ouvre pas ».
D’abord l’utilité réelle, ensuite la monétisation
Gitae n’est pas monétisé actuellement. Je l’ai d’abord construit pour moi, parce que je voulais vérifier rapidement un site depuis l’extérieur de ma machine puis passer directement au DNS, au certificat, aux ports et au réseau sans jongler entre des outils séparés.
Mon objectif actuel est de rendre le diagnostic plus utile et de voir si le projet peut gagner du trafic organique grâce au SEO et à une demande réelle. S’il atteint même un trafic modeste, je veux ajouter une surveillance automatique avec alertes instantanées dans les messageries. Ce serait la même logique étendue de la diagnostic manuel à la détection : savoir qu’un service est devenu indisponible, puis donner au propriétaire suffisamment d’éléments pour commencer rapidement l’enquête.
Le cœur de l’idée reste volontairement simple
« Up » et « down » sont des symptômes, pas des explications.
DNS, HTTPS/TLS, routage, ports, hébergement, application et réseau de l’utilisateur peuvent tous produire ce qui ressemble à une simple panne. Gitae n’identifie pas magiquement toutes les root causes et ces points VDS externes ne montrent pas ce que voit tout Internet. Ils peuvent en revanche réunir plusieurs signaux indépendants au même endroit.
C’est l’outil que je voulais : passer de « le site ne s’ouvre pas » à une question bien plus utile : « quelle couche dois-je examiner maintenant ? »