Infogérance

Que faire si votre hébergeur
subit une panne ?

OVHcloud, Hetzner, Scaleway, Contabo ou IONOS : le serveur ne répond plus, et la première question n'est pas « comment réparer » mais « chez qui est la panne ». Les six étapes dans l'ordre, et ce qu'il vaut mieux ne pas faire pendant ce temps.

Sommaire

1. La réponse courte : six étapes

Quel que soit l'hébergeur, l'ordre est le même. Les deux premières étapes évitent d'aggraver la situation ; les suivantes réduisent sa durée.

1

Savoir si la panne est chez l'hébergeur ou chez vous

Consultez la page de statut de l'hébergeur et testez le serveur depuis un autre réseau — un téléphone en 4G suffit. Tous vos serveurs muets et un incident affiché : c'est l'hébergeur. Un seul serveur muet et un statut vert : c'est probablement le vôtre.

2

Ne rien redémarrer, réinstaller ni restaurer à l'aveugle

Pendant un incident de l'hébergeur, un redémarrage forcé ne répare rien et peut abîmer une base de données en cours d'écriture. Une réinstallation depuis l'espace client efface le disque.

3

Ouvrir un ticket qui fait gagner du temps

Identifiant du serveur, adresse IP, heure exacte du début, ce que vous avez déjà testé, et un traceroute ou un mtr lancé depuis l'extérieur. Un ticket « mon serveur ne marche plus » revient avec des questions.

4

Prévenir vos utilisateurs

Un message court, sur un canal qui ne dépend pas du serveur en panne : une messagerie hébergée ailleurs, une page de statut externe, un réseau social. Dire qu'on sait vaut mieux que se taire.

5

Si la panne dure : basculer, ou restaurer ailleurs

Si l'architecture le prévoit, c'est le moment de basculer vers un second site. Sinon, la seule issue est de remonter le service ailleurs depuis une sauvegarde qui n'était pas stockée chez l'hébergeur en panne.

6

Après : écrire ce qui s'est passé

Chronologie, durée, cause annoncée par l'hébergeur, et surtout ce qui aurait évité la coupure ou l'aurait raccourcie. C'est ce document qui justifie — ou non — d'investir avant la prochaine.

2. Hébergeur ou votre serveur ? Lire les symptômes

Trois observations suffisent le plus souvent : ce qu'affiche la page de statut, combien de machines sont touchées, et ce qui répond encore — la console de secours, le réseau privé, l'adresse publique.

Ce que vous constatez Diagnostic probable Premier geste
Tous vos serveurs chez cet hébergeur sont injoignables, la page de statut annonce un incident Panne de l'hébergeur Suivre la page de statut, ouvrir un ticket si votre zone n'y figure pas, prévenir vos utilisateurs
Un seul serveur ne répond plus, la page de statut est verte Votre serveur : disque plein, service arrêté, noyau bloqué, pare-feu Ouvrir la console de secours depuis l'espace client : si elle répond, la panne est chez vous
Le serveur répond en console, pas sur le réseau Configuration réseau, pare-feu, ou incident réseau localisé Comparer avec un autre serveur du même datacenter, lancer un traceroute depuis l'extérieur
Les serveurs répondent sur Internet mais ne se voient plus entre eux Réseau privé coupé : un cluster peut se retrouver coupé en deux Ne pas forcer le quorum à l'aveugle — voir le retour d'expérience ci-dessous
Tout répond, mais le site est lent ou renvoie des erreurs Rarement l'hébergeur : saturation, base de données, application Regarder la charge et les journaux avant d'accuser l'infrastructure
Statut vert, mais d'autres clients signalent le même symptôme au même moment Incident en cours, pas encore publié Retester, puis ouvrir un ticket : une page de statut est tenue par des humains

Le cas du réseau privé est le plus trompeur : vue d'Internet, chaque machine semble en bonne santé, alors que le cluster ne fonctionne plus. Nous l'avons vécu sur un cluster Proxmox chez OVHcloud, quand le vRack a cessé de transporter le trafic entre les nœuds : le déroulé et la correction, second ring Corosync compris.

3. Les pages de statut des cinq hébergeurs

Adresses vérifiées le 11 septembre 2026. Notez celle de votre hébergeur avant d'en avoir besoin : pendant une panne, ce n'est pas le moment de la chercher. Le réseau privé figure à part parce qu'il peut tomber sans que le reste de l'infrastructure soit touché.

Hébergeur Page de statut officielle Réseau privé à surveiller aussi
OVHcloud www.status-ovhcloud.com — une page par univers : Bare Metal, Public Cloud, Web Cloud vRack
Hetzner status.hetzner.com vSwitch (serveurs dédiés), Networks (Cloud)
Scaleway status.scaleway.com Private Networks
Contabo contabo-status.com Private Networking (option)
IONOS www.ionos-status.fr Selon l'offre souscrite

Une page de statut dit ce que l'hébergeur sait et a publié. Elle ne dit rien de votre serveur en particulier : un incident limité à un châssis ou à une baie n'y figure pas forcément, et la publication suit la détection avec quelques minutes de décalage. Un statut vert n'innocente pas l'hébergeur ; il vous invite à regarder votre serveur d'abord.

4. Ce qu'il vaut mieux ne pas faire pendant la panne

Les pannes d'hébergeur font rarement perdre des données par elles-mêmes. Ce sont les gestes faits dans l'urgence, pour « faire quelque chose », qui transforment une coupure en perte.

Réinstaller depuis l'espace client

Une réinstallation efface le disque. Elle ne corrige jamais une panne de l'hébergeur, et elle rend irrécupérable ce que la panne n'avait pas touché.

Enchaîner les redémarrages forcés

Si le datacenter ou le réseau est en cause, le serveur redémarre dans le même état injoignable. Si une base de données écrivait au moment de la coupure, chaque arrêt brutal ajoute un risque d'incohérence.

Restaurer par-dessus la production

Restaurer un instantané sur le serveur d'origine avant d'avoir compris l'incident, c'est écraser tout ce qui a été écrit depuis la dernière sauvegarde. Si vous devez restaurer, faites-le à côté, pas par-dessus.

Changer les DNS dans la précipitation

Pointer les enregistrements vers une machine de secours jamais testée déplace le problème, et le retour en arrière dépend de la durée de vie des enregistrements (TTL) réglée bien avant la panne.

5. Si la panne dure : basculer, ou restaurer ailleurs

Quand la panne s'installe, la question change : ce n'est plus « quand l'hébergeur aura-t-il fini », mais « peut-on servir sans lui ». La réponse dépend entièrement de ce qui a été préparé avant.

Si l'architecture le prévoit : basculer

Un service réparti sur deux sites, ou chez deux hébergeurs, peut continuer sans attendre la réparation. Avec une architecture à deux étages, la bascule est automatique ; avec un anycast interne multi-site, le trafic est servi par le site qui reste joignable.

Sinon : restaurer ailleurs

Sans second site, la seule issue est de remonter le service sur une autre machine, idéalement chez un autre hébergeur, depuis une sauvegarde qui n'était pas stockée chez celui qui est en panne. La méthode complète est dans notre plan de reprise d'activité Proxmox.

Une sauvegarde rangée dans le même datacenter que la production disparaît avec lui. C'est la leçon de l'incendie du datacenter OVHcloud de Strasbourg, en mars 2021 : des sauvegardes stockées sur le même site ont été perdues en même temps que les serveurs. Notre sauvegarde externalisée NimbusBackup est hébergée à Equinix Paris, hors de l'infrastructure de votre hébergeur.

Dans les deux cas, ce qui décide n'est pas la qualité de l'hébergeur, c'est d'avoir essayé avant : une bascule jamais testée et une restauration jamais faite échouent le jour où l'on en a besoin.

6. Ce que personne ne peut faire pendant la panne de l'hébergeur

Autant le dire nettement : aucun infogérant ne répare le datacenter d'OVHcloud, le réseau de Hetzner ou l'alimentation électrique de Scaleway. Quand la panne est chez l'hébergeur, la réparation est chez l'hébergeur.

Ce qu'un infogérant fait pendant ce temps est moins spectaculaire, et plus utile :

  • établir en quelques minutes que la panne n'est pas sur votre serveur, et le montrer ;
  • ouvrir et suivre le ticket chez l'hébergeur, avec les éléments qui évitent les allers-retours ;
  • vous tenir informé, pour que vous puissiez informer vos propres clients ;
  • déclencher la bascule ou la restauration ailleurs, si elles ont été préparées ;
  • vérifier au retour que tout est revenu : services, réplication, sauvegardes, certificats.

Pour nos clients sous astreinte, c'est cette prise en charge que la GTI engage — 4h ou 1h selon le niveau, 24/7 —, pas la durée de la panne de l'hébergeur, sur laquelle personne n'a la main. Le vrai levier se situe avant l'incident : une sauvegarde hors de l'hébergeur, et une architecture qui ne dépend pas d'un seul site.

7. Et le dédommagement ?

Il dépend du SLA de votre offre, et il se lit avant la panne. Dans la plupart des contrats d'hébergement, la compensation prend la forme d'un avoir calculé sur le prix du service indisponible — pas sur le chiffre d'affaires que vous avez perdu. Pour un serveur facturé quelques dizaines d'euros par mois, l'avoir est sans rapport avec le coût d'une journée d'arrêt, que vous pouvez estimer avec notre calculateur du coût d'indisponibilité.

Réclamez-le quand même, avec votre chronologie : c'est aussi ce qui documente l'incident pour la suite.

8. Après la panne : ce qui aurait évité la coupure

Le post-mortem ne sert pas à désigner un coupable chez l'hébergeur. Il sert à décider ce que vous changez, en connaissant désormais le coût réel d'une coupure.

Une sauvegarde hors de l'hébergeur

C'est la condition pour pouvoir restaurer ailleurs. Vérifiez où partent vos sauvegardes aujourd'hui, et quand elles ont été restaurées pour la dernière fois.

Un second site, si le métier le justifie

Toutes les applications n'en ont pas besoin. Celles dont l'arrêt coûte plus cher qu'une infrastructure doublée, oui : les quatre architectures de haute disponibilité, de la plus simple à la plus robuste.

Quelqu'un qui décroche à 3h du matin

Diagnostic, ticket, bascule : il faut quelqu'un de réveillé. Notre astreinte 24/7 démarre à 90 € par serveur et par mois en GTI 4h, et reprend votre serveur là où il est, sans migration.

9. Questions fréquentes

Comment savoir si OVH est en panne ?

Consultez la page de statut d'OVHcloud, www.status-ovhcloud.com, qui publie les incidents par univers : Bare Metal pour les serveurs dédiés, Public Cloud, Web Cloud pour l'hébergement web. Testez ensuite votre serveur depuis un autre réseau, un téléphone en 4G suffit. Si tous vos serveurs OVH sont injoignables et qu'un incident est affiché sur votre datacenter, la panne est chez OVH. Pensez aussi au vRack : si vos serveurs répondent sur Internet mais ne se voient plus entre eux, c'est le réseau privé qui est coupé.

Hetzner est down : que faire ?

Vérifiez status.hetzner.com, en distinguant les serveurs dédiés de l'offre Cloud, qui n'ont pas les mêmes incidents. Si un incident couvre votre datacenter, ne réinstallez rien et ne multipliez pas les redémarrages : ouvrez un ticket avec l'identifiant du serveur, l'adresse IP, l'heure de début et un traceroute, puis prévenez vos utilisateurs. Si la panne dure et que votre service le permet, basculez vers un autre site ou restaurez ailleurs depuis une sauvegarde stockée hors de chez Hetzner.

Mon serveur Contabo ne répond plus : panne de Contabo ou problème chez moi ?

Regardez d'abord contabo-status.com. Si aucun incident n'est affiché, ouvrez la console de secours depuis votre espace client : si le système répond en console mais pas sur le réseau, la cause est presque toujours de votre côté, par exemple un pare-feu, un disque plein ou un service arrêté. Si la console elle-même est inaccessible et que d'autres clients signalent le même symptôme, ouvrez un ticket : la page de statut peut avoir quelques minutes de retard sur la réalité.

Scaleway annonce un incident : mes données sont-elles en danger ?

Un incident réseau ou une panne de l'interface de gestion n'efface pas les disques : le plus souvent, les données sont intactes mais inaccessibles. Le danger vient surtout des gestes faits dans l'urgence, comme une réinstallation ou une restauration par-dessus la production. Consultez status.scaleway.com, attendez que l'incident de votre zone soit clos, puis vérifiez vos services et vos bases de données. Si le site lui-même est perdu, seule une sauvegarde stockée hors de Scaleway permet de repartir.

Faut-il redémarrer le serveur depuis l'espace client pendant une panne ?

Pas tant que la page de statut annonce un incident sur votre zone : le serveur redémarrera dans le même état injoignable, et un arrêt brutal pendant qu'une base de données écrit ajoute un risque d'incohérence. Le redémarrage forcé se justifie quand la page de statut est verte, que seul votre serveur est touché et que la console de secours montre un système bloqué. Et jamais de réinstallation : elle efface le disque.

L'hébergeur me doit-il un dédommagement ?

Cela dépend du SLA de votre offre, à lire avant la panne. Dans la plupart des contrats d'hébergement, la compensation prend la forme d'un avoir calculé sur le prix du service indisponible, pas sur le chiffre d'affaires perdu. Pour un serveur facturé quelques dizaines d'euros par mois, l'avoir est sans rapport avec le coût d'une journée d'arrêt. Réclamez-le quand même, avec votre chronologie de l'incident.

Un infogérant peut-il réparer la panne de mon hébergeur ?

Non, et aucun ne le peut : quand la panne est dans le datacenter ou sur le réseau de l'hébergeur, la réparation est chez l'hébergeur. Un infogérant établit que la panne n'est pas sur votre serveur, ouvre et suit le ticket, vous tient informé, déclenche la bascule ou la restauration ailleurs si elles ont été préparées, puis vérifie que tout est revenu. Pour nos clients sous astreinte, la GTI de 4h ou 1h engage cette prise en charge, pas la durée de la panne de l'hébergeur.

Préparez la prochaine panne maintenant

Dites-nous chez quel hébergeur tournent vos serveurs et ce qu'ils portent. Nous vous répondons avec ce qui manque aujourd'hui pour traverser une panne de l'hébergeur : sauvegarde, second site, astreinte.

Demander un devis

À lire aussi

Les 4 architectures de haute disponibilité

De la relance de VM à l'anycast multi-site.

Astreinte informatique 24/7

Ce qui réveille quelqu'un, et en combien de temps.

Reprise d'un serveur existant

Vous gardez votre hébergeur, nous reprenons l'exploitation.

Accès et réversibilité

Ce que vous gardez, et comment vous nous sortez.