Le vendredi 2 octobre 2026, vers 14 h, une partie des internautes français ne parvenait plus à ouvrir des milliers de sites hébergés chez OVHcloud. Selon Generation-NT, cette panne OVH venait d’un défaut d’interconnexion avec le réseau d’Orange. Le même après-midi, l’hébergeur reconnaissait un incident sur ses serveurs dédiés de Roubaix et annonçait un retour à la normale pour la fin de journée. Si votre site répond à nouveau, vous n’avez rien à réparer. Pour la prochaine coupure, en revanche, quelques réglages peu coûteux, faits à froid, limitent nettement les dégâts.
Panne OVHcloud du 2 octobre : chronologie, cause et périmètre
La panne OVHcloud du 2 octobre combine deux faits. L’hébergeur a confirmé un incident sur ses serveurs dédiés RBX4 de Roubaix. Generation-NT a décrit, de son côté, une défaillance du peering avec Orange. OVHcloud a classé l’incident en panne partielle, et non en panne majeure.
Le déroulé de l’après-midi du 2 octobre
Vers 14 h, le routage entre OVHcloud et Orange se dégrade. Pour une partie des visiteurs, les sites ralentissent, puis ne s’affichent plus du tout. Downdetector enregistre plus de 1 000 signalements, et les témoignages se multiplient sur les réseaux sociaux. Sur sa page de statut, OVHcloud écrit :
« nous sommes actuellement confrontés à un incident. Nous avons identifié l’origine du problème affectant notre offre de serveurs dédiés sur le modèle RBX4 en question »
L’hébergeur passe alors l’infrastructure de serveurs dédiés de Roubaix en Partial Outage. Le service revient ensuite par paliers, pour ne pas surcharger les routeurs de secours.
Peering entre OVHcloud et Orange : pourquoi un seul lien bloque des milliers de sites
Le peering est un accord par lequel deux réseaux échangent leur trafic en direct, sans intermédiaire. Quand un abonné Orange ouvre un site hébergé à Roubaix, ses données passent normalement par ce raccordement.
Si ce lien lâche, le trafic part par des chemins détournés, sur des réseaux qui ne sont pas dimensionnés pour absorber un tel volume. Un goulot d’étranglement se forme. La latence grimpe, et les pages mettent très longtemps à charger quand elles finissent par s’afficher. Pendant ce temps, le serveur tourne normalement : seul le chemin qui mène jusqu’à lui est encombré.
Qui a été touché, et ce qui reste à confirmer
Les internautes passant par Orange ont été les plus touchés. Depuis d’autres opérateurs, beaucoup de sites restaient joignables. S’y ajoutent les clients des serveurs dédiés RBX4.
Generation-NT attribue la responsabilité principale à Orange, mais, à notre connaissance, aucun communiqué de l’opérateur ne le confirme. Le lien entre l’incident RBX4 et le défaut de peering n’a pas été détaillé publiquement. On ignore aussi la durée exacte de la coupure et le nombre de sites concernés. Quant aux signalements Downdetector, ils comptent des internautes qui se plaignent, pas des sites hors ligne.
Votre site est inaccessible : vérifier si c’est OVH, votre opérateur ou votre site
Quatre vérifications, dans cet ordre, indiquent si un site inaccessible chez OVH subit une panne d’hébergeur, un problème d’opérateur ou une erreur qui lui est propre. Si un seul opérateur est en cause, vous n’avez rien à réparer : il vous reste à informer vos clients.
- Consultez les pages OVH status (status-ovhcloud.com et status.isp.ovhcloud.com), puis cherchez votre gamme ou votre datacenter.
- Croisez avec Downdetector. Un pic de signalements confirme un problème large, mais ces données restent déclaratives.
- Ouvrez le site depuis un autre réseau, par exemple la 4G d’un autre opérateur ou un VPN. S’il s’affiche, le problème vient du routage d’un opérateur, pas de votre serveur OVH.
- Vérifiez dans l’espace client l’expiration du domaine et la zone DNS, comme l’indique la documentation OVHcloud. Un domaine expiré produit les mêmes symptômes qu’une panne.
Pendant une panne de peering, ne touchez à rien. Redémarrer le serveur ou modifier les DNS dans l’urgence ajoute un risque et ne répare pas la route. Prévenez plutôt par e-mail les clients qui ont une commande en cours, et publiez l’information sur vos réseaux sociaux : les visiteurs concernés, eux, ne voient pas votre site.
Limiter l’effet de la prochaine panne OVH ou d’un autre hébergeur
Cinq mesures réduisent l’effet d’une panne d’hébergeur. Le DNS secondaire, la supervision externe et la page de statut coûtent peu. Le multi-hébergement et le CDN se justifient surtout pour un e-commerce. Pour fixer les idées, prenons une boutique PrestaShop qui vend 2 400 € par jour : elle perd en moyenne 100 € par heure de coupure, sans compter les paniers abandonnés.
DNS secondaire, supervision externe et page de statut : les bases peu coûteuses
Le DNS secondaire confie une copie de votre zone à un second fournisseur, qui répond si les serveurs DNS de l’hébergeur tombent. Il ne protège pas d’un défaut de peering comme celui du 2 octobre, mais il couvre un autre scénario de panne. Réglez aussi un TTL court, c’est-à-dire la durée pendant laquelle les résolveurs gardent votre adresse en mémoire. À 300 secondes, une bascule vers un serveur de secours se propage en cinq minutes. À 86 400 secondes, elle peut prendre jusqu’à une journée.
La supervision externe teste votre site depuis plusieurs zones et plusieurs opérateurs, puis vous alerte par SMS ou par e-mail. Le 2 octobre, une sonde raccordée chez Orange aurait vu le site hors ligne, et une sonde installée chez un autre opérateur l’aurait vu en ligne. En croisant les deux, vous localisez la panne en quelques minutes. Cette surveillance fait partie des tâches d’une infogérance OVH pour serveurs dédiés, VPS et cloud.
Hébergez la page de statut hors de votre infrastructure principale, chez un autre fournisseur, sur une adresse du type status.votresite.fr. Une agence peut y regrouper tous ses clients. Préparez à l’avance un modèle de message et une procédure d’escalade : qui ouvre le ticket chez l’hébergeur, qui appelle le client, et au bout de combien de minutes.
Multi-hébergement et CDN : pour les sites e-commerce critiques
Un CDN (réseau de diffusion de contenu) garde vos pages en cache sur des serveurs répartis et continue de les servir quand le serveur d’origine ne répond plus. Pour un site vitrine WordPress, cela suffit souvent. Sur une boutique, le catalogue reste visible, mais le panier et le paiement ont besoin du serveur d’origine.
Le multi-hébergement fait tourner une réplique du site chez un second hébergeur, avec une base de données synchronisée. En cas de panne, le DNS bascule vers cette réplique (failover). Comptez un budget d’hébergement presque doublé, et testez la bascule au moins deux fois par an. Notre règle : si une heure de coupure vous coûte plus que le prix mensuel de la réplique, la dépense se justifie.
Lire et négocier les clauses de SLA de son hébergeur
Le SLA (accord de niveau de service) fixe la disponibilité garantie et la compensation prévue si elle n’est pas tenue. Lisez les exclusions avec autant d’attention que le taux affiché en tête de contrat.
- Un taux de 99,9 % tolère environ 8 h 45 d’indisponibilité par an. À 99,99 %, ce plafond descend à 52 minutes.
- Les incidents d’opérateurs tiers, peering compris, sont souvent exclus. Le 2 octobre, un site joignable depuis d’autres réseaux pouvait donc être compté comme disponible.
- Les pénalités prennent le plus souvent la forme d’avoirs plafonnés, que vous devez réclamer vous-même dans un délai fixé.
- Le délai d’intervention indique quand un technicien prend l’incident en charge, pas quand il le résout.
Avant de signer ou de renouveler, demandez à votre hébergeur comment il mesure la disponibilité, et depuis quels réseaux.
La panne OVH du 2 octobre s’est résorbée dans la journée. Avant la suivante, commencez par deux tâches d’une heure chacune : installer une sonde de supervision externe et abaisser le TTL de vos enregistrements DNS.
