Dépanner · Urgence
Support hébergement, DNS & déploiement : votre site est down, on trouve pourquoi
Votre site est inaccessible alors que « l’hébergement fonctionne » ? Le problème vient rarement d’un seul endroit : ce peut être le DNS, le certificat SSL, le serveur web, le runtime PHP ou Node, un déploiement raté ou une régression dans le code. La même frontière explique les e-mails qui cessent d’arriver : le nom de domaine porte aussi votre courrier (MX, SPF, DKIM, DMARC), et une zone DNS recréée trop vite casse les deux d’un coup. On isole la panne couche par couche, dans l’ordre, en lisant les vrais logs plutôt qu’en devinant — puis on remet le site en ligne et on documente la cause. À distance, sans abonnement, facturé par tranches de 30 minutes, avec une première réponse sous 2 heures ouvrées.
Les situations qu’on remet en ligne
- Le site affiche « Ce site est inaccessible », « DNS_PROBE_FINISHED_NXDOMAIN » ou une page vide, alors que votre hébergeur vous dit que « le serveur tourne ».
- Le certificat SSL a expiré ou le renouvellement Let’s Encrypt a échoué : le navigateur bloque avec « Votre connexion n’est pas privée » / « NET::ERR_CERT_DATE_INVALID ».
- Erreur « 502 Bad Gateway », « 503 Service Unavailable » ou « 504 Gateway Timeout » : le serveur web répond mais l’application derrière (PHP-FPM, Node, conteneur) ne répond plus.
- Un déploiement s’est mal passé — build interrompu, mauvaise branche mise en ligne, variable d’environnement manquante — et depuis, le site est cassé ou coincé sur une ancienne version.
- Vous avez migré de serveur ou changé de registrar, et depuis le domaine pointe au mauvais endroit ou n’envoie plus les e-mails (enregistrements A, CNAME, MX ou TXT/SPF perdus).
- Erreur « 500 Internal Server Error » ou écran blanc apparus après une mise à jour de PHP, de Node ou d’un paquet, sans que rien n’ait changé dans votre contenu.
- Le site est lent jusqu’au timeout ou tombe aux heures de pointe : mémoire saturée, process qui redémarre en boucle, disque plein, base injoignable.
- Le prestataire qui gérait le serveur n’est plus là, vous n’avez plus les accès clairs (SSH, panel, DNS), et personne ne sait comment le site est déployé.
- Après un renouvellement ou un transfert de domaine oublié, le nom ne résout plus du tout et l’activité est totalement à l’arrêt.
- Le site fonctionne « chez vous » mais pas pour vos clients (ou l’inverse) : propagation DNS en cours, cache, ou différence entre la version www et sans www.
- Vos e-mails partent mais arrivent en indésirables, ou sont rejetés avec un message du type « SPF check failed » ou « DMARC policy violation », depuis un changement de DNS, d’hébergeur ou d’outil d’envoi.
- Vous avez branché un nouvel outil (newsletter, facturation, CRM, service d’envoi transactionnel) et vos messages finissent en spam, parce que ce nouvel expéditeur n’est déclaré nulle part dans vos enregistrements d’authentification.
Notre méthode : isoler la couche en panne, dans l’ordre
- On sépare d’abord « le nom » du « serveur ». On vérifie la résolution DNS depuis l’extérieur (les enregistrements A/AAAA, CNAME, la ligne MX pour les e-mails ainsi que les enregistrements TXT d’authentification — SPF, DKIM, DMARC — quand le courrier est concerné, le TTL et l’état de propagation) : si le domaine ne pointe nulle part ou pointe au mauvais endroit, aucune correction serveur ne servira tant que ce n’est pas réglé.
- On teste l’accès réseau et le certificat : le port 443 répond-il ? Le certificat est-il valide, expiré, ou émis pour le mauvais domaine ? On regarde la date d’expiration et l’état du renouvellement Let’s Encrypt (le renouvellement automatique échoue souvent sur un challenge HTTP bloqué ou une redirection mal placée).
- On interroge le serveur web (Nginx, Apache ou l’équivalent) et on lit ses logs d’erreur en direct : une 502/504 pointe vers l’application derrière, une 403/404 vers une mauvaise racine ou de mauvaises permissions, un « connection refused » vers un service qui ne tourne plus.
- On descend dans le runtime : PHP-FPM, le process Node, le conteneur Docker ou le service applicatif tournent-ils réellement ? On vérifie qu’ils sont démarrés, qu’ils ne redémarrent pas en boucle, et on lit les journaux applicatifs — c’est là qu’apparaît la vraie erreur (exception, version incompatible, variable manquante, connexion base refusée).
- On contrôle le déploiement et les ressources : quelle version/branche est réellement en ligne, le dernier build a-t-il abouti, les variables d’environnement sont-elles présentes, le disque est-il plein, la mémoire saturée ? Beaucoup de pannes « inexplicables » sont un déploiement à moitié terminé ou un disque à 100 %.
- Une fois la cause isolée, on applique le correctif minimal pour remettre le site en ligne, on vérifie de bout en bout (site, HTTPS, e-mails si concernés), puis on vous explique en clair ce qui a cassé, comment on l’a réparé, et ce qu’il faut faire pour que ça ne se reproduise pas.
Technologies & environnements — exemples, pas une limite
Votre configuration n’est pas dans cette liste ? Ce n’est pas une liste de compatibilité. On entre dans un existant, quel qu’il soit, pour trouver la bonne couche et intervenir. Décrivez le symptôme (le message d’erreur exact, ce qui a changé avant la panne) et votre environnement (hébergeur, type de site, accès dont vous disposez) : on confirme rapidement la prise en charge.
Questions fréquentes
Comment savoir si mon site est down à cause du DNS ou du serveur ?
C’est le premier tri qu’on fait. Si le nom de domaine ne résout pas ou pointe vers la mauvaise adresse, c’est le DNS — aucune action sur le serveur n’aidera. Si le domaine résout correctement mais que la page renvoie une erreur (500, 502, SSL), le problème est côté serveur, runtime ou déploiement. On vérifie la résolution depuis l’extérieur avant de toucher quoi que ce soit.
Mon certificat SSL a expiré, que faire ?
On vérifie d’abord pourquoi le renouvellement automatique a échoué — le plus souvent un challenge HTTP bloqué par une redirection ou un fichier inaccessible. On relance l’émission du certificat, on corrige la cause du blocage pour que le renouvellement redevienne automatique, puis on contrôle que le HTTPS est valide sur toutes les variantes du domaine (avec et sans www).
Que signifie une erreur 502 Bad Gateway ?
Le serveur web répond, mais l’application derrière (PHP-FPM, un process Node, un conteneur) ne répond pas. Concrètement : le service est tombé, redémarre en boucle, ou met trop de temps à répondre. On lit les logs du serveur web et ceux de l’application pour trouver le service en cause et le remettre en état, plutôt que de simplement le redémarrer à l’aveugle.
J’ai changé de serveur et le site ne s’affiche plus, pourquoi ?
En général les enregistrements DNS n’ont pas suivi la migration, ou la propagation est en cours. On vérifie que le domaine pointe bien vers le nouveau serveur (A/AAAA), que les e-mails restent routés (MX, SPF), et que le nouveau serveur sert bien votre site avec un certificat valide. On peut aussi accélérer le diagnostic en testant avant même la fin de la propagation.
Mes e-mails partent en spam depuis un changement de DNS ou d’hébergeur, pourquoi ?
Parce que le courrier n’est plus authentifié comme avant. Trois enregistrements DNS le décident : SPF dit quels serveurs ont le droit d’envoyer pour votre domaine, DKIM signe le message pour prouver qu’il n’a pas été altéré, DMARC indique au destinataire quoi faire quand l’un des deux échoue. Une migration qui recrée la zone sans les reporter, ou un nouvel outil d’envoi jamais déclaré dans le SPF, suffit à faire classer vos messages en indésirables. On lit les en-têtes d’un message réellement rejeté pour voir lequel des trois échoue, on corrige l’enregistrement, puis on vérifie sur un envoi réel avant de conclure.
Combien ça coûte et sous quel délai intervenez-vous ?
Sans abonnement : on facture au temps réellement passé, par tranches de 30 minutes. La première réponse arrive sous 2 heures ouvrées, à distance partout dans le monde. Un site down se traite souvent en une intervention courte une fois la couche en panne identifiée ; on vous donne une estimation avant d’engager le travail.
Décrivez-nous le symptôme et votre environnement : on identifie la couche en panne et on vous remet en ligne. Beaucoup de premiers diagnostics — résolution DNS, certificat, code d’erreur renvoyé — se font depuis l’extérieur, sans aucun accès de votre part ; pour la correction, on vous indique précisément ce qui est nécessaire et on vous aide à retrouver un accès perdu. Devis clair avant toute intervention.
Besoin d'une intervention ciblée ?
Décrivez le blocage — devis sans engagement, ou rappel sous 2 h ouvrées. Supplément urgence possible (+40€).