Pannes Internet - deux opérateurs ne garantissent pas deux domaines de panne

Deux opérateurs Internet, deux contrats, deux factures. Pourtant, une seule panne peut toujours arrêter les deux accès. Même problème côté hébergement : choisir deux fournisseurs cloud ne prouve pas que les serveurs sont installés dans deux datacenters distincts.

Le rapport Cloudflare sur les perturbations Internet du troisième trimestre 2026, publié le 27 octobre, remet ces dépendances physiques au premier plan. Il recense 49 perturbations, dont 14 liées à l’électricité. Deux exemples retiennent particulièrement l’attention : une coupure affectant plusieurs opérateurs au Honduras et un défaut de refroidissement dans un datacenter à Phoenix.

Pour une entreprise, la question est concrète : qu’est-ce qui continue à fonctionner lorsque le point commun aux deux fournisseurs disparaît ?

Honduras et Phoenix : des pannes qui dépassent un seul fournisseur

Au Honduras, le 10 septembre, Cloudflare rapporte une panne électrique sur un site d’interconnexion ayant touché au moins onze grands opérateurs pendant environ trois heures. Le trafic HTTP observé à l’échelle du pays a diminué de 63 %. La diversité des opérateurs n’a donc pas empêché un incident d’affecter simultanément plusieurs réseaux. Analyse Cloudflare et courbes de trafic dans Radar.

Le graphique par réseau de Cloudflare Radar montre une différence nette dans la zone d’incident surlignée, autour de 18h00 UTC : trois courbes chutent fortement, tandis que les réseaux AS14754 et AS52262 restent actifs. Cloudflare identifie ces deux exceptions comme Telecomunicaciones de Guatemala et Celtel. Cette comparaison illustre l’intérêt de chemins différents, sans suffire à prouver leur indépendance physique. Le creux commun visible plus tôt dans la journée ne doit pas être confondu avec la panne surlignée.

À Phoenix, le 13 août, le problème vient du refroidissement. Namecheap confirme une défaillance dans le datacenter RadiusDC qui héberge une partie de ses opérations essentielles. Des services ont été arrêtés à la demande de l’exploitant du site pour protéger les équipements de la surchauffe. Compte rendu officiel de Namecheap.

De son côté, phoenixNAP documente aussi une interruption de ses services hébergés dans le datacenter RadiusDC PHX-01, avec une hausse de température liée à des perturbations électriques ayant affecté les groupes de refroidissement. Journal d’incident officiel de phoenixNAP.

Ces communications décrivent des interruptions réseau et d’hébergement, avec des périmètres différents. Elles illustrent un problème commun : le fonctionnement du service dépend aussi de ce qui se trouve sous les serveurs et derrière les connexions.

Un domaine de panne, c’est ce qui peut tomber ensemble

Un domaine de panne regroupe des composants susceptibles d’être affectés par un même incident. Cela peut être un serveur, une baie, une installation électrique, un bâtiment ou une zone géographique.

La redondance doit donc répondre à une panne précise. Deux alimentations peuvent protéger contre la défaillance d’un bloc d’alimentation. Deux serveurs peuvent permettre de maintenir une application lorsqu’un hôte tombe. Mais si ces deux serveurs dépendent du même refroidissement, cette redondance ne couvre pas la perte du datacenter.

Avant d’ajouter un équipement ou un abonnement, il faut nommer le scénario à couvrir : panne matérielle, coupure de fibre, perte d’une salle ou indisponibilité complète d’un site. Les moyens nécessaires ne sont pas les mêmes.

Deux hébergeurs peuvent utiliser le même datacenter

Un fournisseur cloud commercialise des services. Il peut exploiter ses propres bâtiments ou installer ses équipements dans des datacenters tiers. Deux marques différentes peuvent ainsi utiliser le même site physique.

Prenons un exemple d’architecture : la production est chez un fournisseur A, les machines de secours chez un fournisseur B. Les consoles et les contrats sont distincts. Si les deux plateformes occupent le même datacenter, une panne de refroidissement ou un incident électrique majeur peut rendre les deux indisponibles.

Il faut donc connaître la localisation réelle du principal, des sauvegardes et du secours. Deux salles dans un même bâtiment ne couvrent pas les mêmes risques que deux sites géographiquement séparés. Deux sites proches peuvent encore partager certaines dépendances régionales.

Le choix dépend de l’activité, des délais de reprise et du budget. L’objectif est de vérifier que la séparation retenue couvre bien les incidents contre lesquels on souhaite se protéger.

Deux accès Internet peuvent emprunter le même chemin

Le raisonnement s’applique aussi à la fibre. Deux opérateurs commerciaux peuvent s’appuyer sur une infrastructure physique commune : un même parcours, un même fourreau ou une seule entrée dans le bâtiment. Un chantier au mauvais endroit peut alors couper les deux accès.

La diversité doit se vérifier sur le chemin effectivement livré, pas uniquement sur les noms des opérateurs. À l’intérieur du site, un switch unique ou une alimentation commune peut également annuler le bénéfice de deux connexions.

Un secours mobile peut apporter une diversité de support intéressante. Il faut néanmoins vérifier sa couverture, sa capacité et la disponibilité des services par ce chemin : VPN, restrictions d’adresses IP, téléphonie ou accès aux applications métier. Un lien qui affiche « connecté » n’est pas encore un service de secours validé.

Un second site doit permettre de reprendre les services

Pour une infrastructure principale hébergée ailleurs, un site à Larçay, près de Tours, peut servir à conserver des sauvegardes hors site ou à préparer une reprise. C’est notamment un usage possible de notre partenariat d’infogérance avec Castle IT. Le choix se fait après vérification de la localisation du principal, des dépendances réseau et des moyens nécessaires au redémarrage.

La réciproque est importante : si la production se trouve déjà sur ce site, il faut chercher ailleurs la séparation géographique attendue. Ajouter un second fournisseur dans le même bâtiment ne crée pas cette séparation.

Il faut également pouvoir accéder aux sauvegardes, aux procédures et aux secrets lorsque le principal est indisponible. Un DNS ou une identité d’administration communs méritent aussi d’être examinés, sans perdre de vue le premier sujet : où les équipements se trouvent et ce qui les fait fonctionner.

Tester la perte du site, pas seulement débrancher une interface

Débrancher un accès permet de vérifier une bascule réseau. Pour valider un PRA, l’exercice doit aller jusqu’au service rendu : accéder aux données, démarrer les dépendances dans le bon ordre et effectuer une opération métier représentative.

Les scénarios se préparent selon le périmètre à couvrir :

• Perte de l’accès principal : vérifier le fonctionnement des applications depuis le chemin de secours.
• Perte de la connectivité du site : vérifier les accès depuis l’extérieur et les moyens d’administration disponibles.
• Indisponibilité du site principal : reprendre sur le site de secours sans utiliser un composant resté sur le principal.

Pour chaque service, le résultat doit être comparé au délai de reprise et à la perte de données acceptables. Notre article sur les tests de PRA et les RTO/RPO par service détaille ce cadrage.

Chez Forget About IT, ce travail relie conception et exploitation : cartographier les dépendances, qualifier les choix des fournisseurs, préparer les bascules et maintenir les procédures. C’est une partie du périmètre que nous construisons dans notre offre d’infogérance de serveurs Linux.

Votre principal et votre secours peuvent-ils réellement fonctionner séparément ? C’est une bonne question à poser avant la prochaine panne, documents et tests à l’appui.

Questions fréquentes

Deux opérateurs Internet différents garantissent-ils une connexion de secours indépendante ?

Non. Les deux accès peuvent emprunter le même parcours fibre, dépendre d’un équipement commun ou arriver par la même entrée de bâtiment. Il faut vérifier la diversité physique auprès des fournisseurs et tester la bascule avec les services réellement utilisés.

Deux fournisseurs cloud suffisent-ils pour protéger un PRA contre une panne de datacenter ?

Non. Deux fournisseurs peuvent héberger leurs équipements dans le même datacenter. Le site principal et le secours doivent être choisis en fonction des pannes à couvrir, avec une séparation physique vérifiée et des tests de reprise par service.