Panne OVH, Hetzner, Scaleway, Contabo, IONOS : que faire en 6 étapes

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 chez nous ou chez des hébergeurs européens, hors de votre compte d'hébergement.

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. Ces décisions s'écrivent dans un plan de reprise d'activité.

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.

Je ne suis pas client : pouvez-vous intervenir pendant la panne ?

Oui, en intervention ponctuelle réservée aux entreprises immatriculées en France et payée à la commande : 250 € HT, soit 300 € TTC, qui couvrent le déclenchement et les 30 premières minutes d'audit, puis 90 € HT par tranche de 30 minutes, dans la limite que vous fixez, de 0 à 10 heures. Un ingénieur vous rappelle sous 4 heures, 24/7, à compter de la validation du paiement ; sinon, remboursement intégral. Les délais liés à une absence de réponse de votre part sont hors GTI. Les 250 € HT sont dus dès le déclenchement de l'astreinte, même si la panne ne peut pas être réparée : celle de l'hébergeur ne se répare que chez lui, et nous établissons où elle est et ce qu'il reste comme options.

Pas encore client ? Intervention d'urgence, rappel sous 4 heures

Votre serveur est tombé et personne chez vous n'est là pour regarder ? Commandez une intervention ponctuelle : un ingénieur vous rappelle sous 4 heures^*, de jour comme de nuit, week-end compris. Le délai court à partir de la validation de votre paiement, pas de la commande.

Ce que nous faisons : l'audit de la panne, pour établir si elle est chez l'hébergeur ou sur votre serveur, puis sa résolution quand elle est possible depuis votre serveur, avec une obligation de moyens, sans garantie de rétablissement. Si la panne est chez l'hébergeur, nous ouvrons et suivons le ticket chez lui, et vous disons ce qu'il reste comme options : attendre, basculer, ou restaurer ailleurs si une sauvegarde le permet. Ce que personne ne peut faire, nous non plus : réparer la panne de l'hébergeur à sa place.

Le prix

Déclenchement : nous réveiller	160 € HT
30 premières minutes d'audit	90 € HT
Prélevé à la validation du paiement	250 € HT soit 300 € TTC

Le temps passé au-delà des 30 minutes incluses est prélevé ensuite sur la même carte, par tranche de 30 minutes à 90 € HT (108 € TTC), dans la limite que vous avez fixée (de 0 à 10 heures).

Les conditions

Remboursement intégral si nous ne vous avons pas rappelé dans les 4 heures^* qui suivent le paiement : les 300 € TTC vous sont rendus.
Les 250 € HT sont dus dès le déclenchement de l'astreinte, même si la panne ne peut pas être réparée : nous avons été réveillés, nous avons regardé, nous avons qualifié la panne.
Un numéro de téléphone obligatoire : c'est par là que nous vous rappelons.
Vous attestez être propriétaire du serveur ou autorisé par son propriétaire, et c'est vous qui nous ouvrez l'accès, depuis le panneau de votre hébergeur ou une console de secours. Nous ne vous demanderons jamais d'identifiants.
Exécution immédiate demandée : l'astreinte étant déclenchée dès la validation du paiement, vous renoncez au délai de rétractation.

Comment se passe la commande

1Vous remplissez le formulaire ci-dessous. Réservé aux entreprises immatriculées en France : indiquez le SIREN ou le SIRET de la société. Vous recevez un e-mail avec un lien valable 24 heures : utilisez une adresse que vous pouvez consulter maintenant, une adresse Gmail par exemple si votre messagerie est en panne. Le lien vous mène sur notre portail client, où vous vous connectez ou créez votre compte.
2Vous enregistrez votre carte.
3Vous décrivez l'incident : serveur, hébergeur, symptômes, accès dont vous disposez.
4Vous choisissez le nombre maximal d'heures au-delà des 30 minutes, puis validez le prélèvement de 300 € TTC : à ce moment seulement, l'astreinte est déclenchée et nous vous rappelons sous 4 heures^*.

Tant que le paiement n'est pas validé, personne n'est réveillé et rien ne vous est prélevé.

Commander une intervention d'urgence

Vérification de la disponibilité de l'astreinte…

Déjà client sous astreinte ? Suivez votre procédure habituelle : elle passe avant.

* Les délais liés à une absence de réponse de votre part sont hors GTI : ils ne comptent pas dans les 4 heures.

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

Que faire si votre hébergeursubit une panne ?

Sommaire