Saison des coupures : récapitulatif des perturbations d'Internet au deuxième trimestre 2025

Présent dans plus de 125 pays, le réseau Cloudflare couvre actuellement plus de 330 villes et s'interconnecte avec plus de 13 000 opérateurs réseau afin de proposer une vaste gamme de services à des millions de clients. L'étendue de notre réseau et de notre clientèle nous assure un point de vue unique sur la résilience d'Internet et nous permet d'observer les répercussions des perturbations qui l'affligent, à la fois au niveau local et national, ainsi qu'au niveau du réseau.

Comme nous l'avons indiqué par le passé, cet article a pour objectif de proposer un aperçu des perturbations observées et ne constitue pas une liste exhaustive ou complète des incidents survenus pendant le trimestre. Vous trouverez une liste plus complète des anomalies de trafic détectées dans le Cloudflare Radar Outage Center. Veuillez noter que l'article utilise à la fois des graphiques portant sur le trafic en octets et sur le trafic des requêtes afin d'illustrer les effets des perturbations observées. Le choix de l'indicateur a généralement été effectué en fonction des éléments qui présentaient au mieux l'impact de la perturbation.

Dans notre article récapitulatif du premier trimestre 2025, nous signalions n'avoir observé aucune coupure d'Internet d'origine gouvernementale sur cette période. Ces progrès se sont malheureusement révélés éphémères. En effet, nous avons observé des coupures en Libye, en Iran, en Irak, en Syrie et au Panama lors du deuxième trimestre 2025. Internet a clairement démontré sa dépendance envers un réseau électrique stable au cours du trimestre, lorsqu'une panne de courant généralisée a frappé l'Espagne et le Portugal, en perturbant ainsi fortement la connectivité au sein de ces pays. Certains opérateurs d'Haïti et du Malawi ont été affectés par des ruptures de câbles de fibre optique, tandis que les principaux opérateurs nord-américains ont rencontré des problèmes techniques qui ont perturbé le trafic Internet. Enfin, un fournisseur russe a de nouveau été pris pour cible par une cyberattaque de grande ampleur, qui a mis son réseau hors ligne. Nous avons également relevé plusieurs pannes d'Internet de forte amplitude restées inexpliquées au cours du trimestre, car les canaux officiels ne communiquent malheureusement pas toujours sur les causes fondamentales de ces coupures.

Le 16 mai, des perturbations d'Internet ont été observées chez plusieurs fournisseurs de réseau libyens en réponse à des manifestations publiques contre le gouvernement d'unité nationale, qui a dès lors décidé de couper la connectivité. À partir de 13 h 30 UTC (15 h 30 heure locale), le trafic a chuté de plus de 50 % par rapport à la semaine précédente chez Libyan International Company for Technology (AS329129), Giga Communication (AS328539), Aljeel Aljadeed for Technology (AS37284) et Awal Telecom (AS328733). Ce dernier opérateur a d'ailleurs connu une interruption totale de sa connectivité. Nous avons ainsi observé des volumes de trafic plus faibles jusqu'à environ 0 h UTC (2 h heure locale). Le trafic est revenu à la normale entre 23 h UTC (1 h heure locale) et 1 h UTC (3 h heure locale). Giga Communication (AS328539) a connu une deuxième perturbation le 17 mai entre 2 h et 11 h 30 UTC (4 h et 13 h 30 heure locale).

L'Iran a connu plusieurs coupures d'Internet au mois de juin, suite aux premières frappes d'Israël contre les sites nucléaires du pays. La première panne, survenue le 13 juin, s'est produite entre 7 h 15 et 9 h 45 UTC (10 h 45 et 13 h 15 heure locale). Le ministère iranien des Communications a publié une déclaration annonçant la coupure : « À la lumière du contexte particulier qui nous entoure et sur la base des mesures prises par les autorités compétentes, des restrictions temporaires ont été imposées à la connectivité Internet du pays. Ces restrictions seront bien évidemment levées lorsque les conditions normales seront rétablies. » Cet ordre de coupure a affecté plusieurs opérateurs réseau, comme FanapTelecom (AS24631), Rasana (AS205647 et AS31549), MCCI (AS197207) et TCI (AS58224), parmi d'autres.

La connectivité Internet a de nouveau été limitée le 17 juin, cette fois dans le cadre d'une initiative visant à « repousser les cyberattaques », selon un porte-parole du gouvernement. Ce deuxième épisode de coupure a commencé à 17 h 30 heure locale (14 h UTC) et a touché plusieurs réseaux. Le trafic a repris à 15 h 30 UTC (19 h heure locale) sur FanapTelecom (AS24631) et Pars Online (AS16322), à 20 h UTC (23 h 30 heure locale) sur MCCI (AS197207) et IranCell (AS44244), à 22 h UTC le 17 juin (1 h 30 le 18 juin heure locale) sur RighTel (AS57218) et à 6 h UTC le 18 juin (9 h 30 heure locale) sur Rasana (AS31549 et AS205647).

Le trafic Internet entrant aurait également été bloqué lors de ces premières coupures de la connectivité et l'accès des utilisateurs était limité au « réseau national d'information » (National Information Network, NIN) iranien.

Un troisième épisode d'interruption de la connectivité (plus prolongé) a été décidé un jour plus tard, le 18 juin. Cette coupure a duré de 12 h 50 UTC (16 h 20 heure locale) à 5 h UTC (8 h 30 heure locale) le 25 juin. Une fois de plus, la coupure a prétendument été mise en œuvre comme un moyen de se protéger contre les cyberattaques. Un porte-parole du gouvernement l'a d'ailleurs commentée en ces termes : « Nous avons déjà déclaré que, si nécessaire, nous passerions certainement sur un Intranet national et restreindrions l'accès au réseau Internet mondial. € l'heure où la sécurité demeure notre principale préoccupation, nous faisons les frais de cyberattaques sur les infrastructures essentielles du pays et de perturbations dans le fonctionnement de nos banques. De nombreux drones ennemis sont gérés et contrôlés par Internet, tandis qu'une grande quantité d'informations sont également échangées de cette manière. Une plateforme d'échange de cryptomonnaies a également été piratée. Compte tenu de tous ces problèmes, nous avons donc décidé d'imposer des restrictions à la connectivité Internet. » Cette interruption a entraîné une perte quasi totale du trafic jusqu'à 2 h UTC (5 h 30 heure locale) le 21 juin, date où nous avons pu observer une certaine reprise du trafic malgré des niveaux restés bien en dessous des volumes précédant la coupure. Le trafic de cette reprise partielle s'est stabilisé sous la forme d'un cycle régulier pendant plusieurs jours, avant de revenir aux niveaux attendus le 25 juin. Les opérateurs réseau affectés par la perturbation sont les mêmes que ceux qui ont été touchés par les coupures précédentes.

Conformément aux mesures prises ces dernières années (2024, 2023, 2022), les gouvernements d'Irak ont à nouveau décidé des épisodes réguliers d'interruption de la connectivité d'Internet dans l'idée d'empêcher la tricherie lors des examens nationaux. (Nous employons le terme « gouvernements » au pluriel ici, car les coupures ont eu lieu à la fois dans la partie principale du pays et au sein de la région du Kurdistan irakien, dans la partie septentrionale du pays.)

Survenues entre 3 h et 5 h UTC (6 h et 8 h heure locale), à la demande du ministère de l'Éducation, les coupures mises en place sur la majeure partie du territoire ont commencé le 20 mai et se sont poursuivies jusqu'au 4 juin pour les examens de collège, tandis que les examens de lycée ont fait l'objet de coupures du 14 juin au 3 juillet. Les opérateurs réseau qui ont mis en œuvre ces coupures étaient Earthlink (AS199739), Asiacell (AS51684), Zainas (AS59588), Halasat (AS58322) et HulumTele (AS203214).

Dans la région du Kurdistan, les coupures ont commencé le 1er juin et se sont poursuivies jusqu'au 6 juillet. Elles se sont produites entre 3 h 30 et 4 h 30 UTC (6 h 30 et 7 h 30 heure locale) le mercredi et le dimanche. Les opérateurs réseau qui ont mis en œuvre ces coupures étaient IQ Online (AS48492), KorekTel (AS59625), Newroz Telecom (AS21277) et KNET (AS206206).

À l'instar de l'Irak, la Syrie coupent également la connectivité Internet à l'échelle nationale afin d'empêcher la tricherie lors des examens, et ce depuis plusieurs années (2021, 2022, 2023, 2024). Contrairement aux années précédentes, le gouvernement n'a toutefois décidé d'ordonner la coupure que de la seule connectivité mobile en 2025. Une déclaration publiée le précise ainsi en ces mots (traduit) : « dans le cadre de notre engagement à garantir l'intégrité des examens publics et à préserver l'avenir de nos chers étudiants, et sur la base de notre responsabilité nationale visant à assurer un environnement d'examen équitable et transparent, une interruption temporaire des communications mobiles sera mise en place dans les zones situées à proximité des centres d'examen en République arabe syrienne. (…) La coupure des communications mobiles sera mise en œuvre exclusivement dans le cadre géographique et temporel le plus restreint possible, circonscrit à la période où les étudiants se trouvent dans les salles d'examen. »

Au cours du deuxième trimestre, les coupures associées au « certificat d'études primaires » ont eu lieu les 21, 24 et 29 juin, entre 5 h 15 et 6 h UTC (8 h 15 et 9 h heure locale). Les examens du « certificat d'études secondaires » (et les interruptions associées à ces derniers) doivent se dérouler du 12 juillet au 3 août.

Comme ces coupures ont uniquement affecté la connectivité mobile, elles n'ont entraîné qu'une baisse partielle de l'espace d'adressage IP annoncé, contrairement à la chute plus complète constatée les années précédentes.

Le 21 juin, un message publié sur X par ASEP Panamá (l'agence de régulation des télécommunications) a annoncé que (traduit) « … conformément au décret n° 27 du 20 juin 2025 et aux instructions formelles du Ministère du Gouvernement, la suspension temporaire des services de téléphonie mobile et d'Internet résidentiel dans la province de Bocas del Toro a été coordonnée. » Selon la publication, la suspension était censée rester en vigueur jusqu'au 25 juin, mais un autre message publié sur X a indiqué qu'elle serait prolongée jusqu'au dimanche 29 juin 2025.

Cette suspension de la connectivité Internet a été décrétée en réponse aux manifestations et aux mouvements de protestation contre les réformes du Fonds de sécurité sociale, de la retraite et des pensions, notamment dans la province de Bocas del Toro.

Le graphique ci-dessous montre une chute effective du trafic de Cable Onda (AS18809) à Bocas del Toro, Panama autour de 3 h 30 UTC le 21 juin (22 h 30 heure locale le 20 juin). Le trafic s'est ensuite rétabli vers 6 h UTC (1 h heure locale) le 30 juin. Le rétablissement est conforme au dernier message lié à ce problème et publié sur X par ASEP, qui précisait (traduit) « … les services Internet et de téléphonie mobile dans la province de Bocas del Toro ont été rétablis à 0 h 01 le lundi 30 juin… ».

La plus importante couverture médiatique autour d'une panne d'électricité survenue au deuxième trimestre concernait l'épisode d'interruption qui a affecté une grande partie du Portugal et de l'Espagne le 28 avril. Les répercussions de l'événement sont présentées en détail dans l'article de blog intitulé How the April 28, 2025, power outage in Portugal and Spain impacted Internet traffic and connectivity » (Comment la panne de courant survenue au Portugal et en Espagne le 28 avril 2025 a affecté le trafic et la connectivité Internet). Cet article détaillait les fluctuations du trafic au niveau du pays/du réseau/de la région, ainsi que la manière dont la coupure d'électricité a affecté la qualité du réseau et l'espace d'adressage IP annoncé.

Le trafic Internet du Portugal est tombé suite à la défaillance du réseau électrique. Par rapport à la semaine précédente, le trafic a immédiatement chuté d'environ 50 % et, cinq heures plus tard, s'est retrouvé à un niveau de près de 90 % de moins que la semaine précédente.

Le trafic Internet espagnol est également tombé suite à la défaillance du réseau électrique du pays. Cette dernière a entraîné une chute immédiate d'environ 60 % par rapport à la semaine précédente, puis une baisse d'environ 80 % par rapport à la semaine précédente dans les cinq heures suivantes.

Le trafic est revenu aux niveaux attendus dans les deux pays vers 1 h heure locale (minuit UTC) le 29 avril. Vous trouverez davantage de détails sur la panne dans l'article de blog mentionné ci-dessus.

Il semble que le Maroc ait également été affecté d'une manière ou d'une autre par la panne d'électricité survenue au Portugal et en Espagne. Orange Maroc l'a été tout du moins. Dans un message publié sur X, l'opérateur a déclaré (traduit) : « Le trafic Internet est perturbé en raison d'une gigantesque panne d'électricité survenue en Espagne et au Portugal. Cette défaillance affecte les connexions internationales. » Le trafic du réseau (AS36925) a brusquement chuté vers 12 h UTC (13 h heure locale), soit 90 minutes après le début de la panne d'électricité, avec une défaillance totale à partir de 15 h UTC (16 h heure locale). Le trafic est revenu aux niveaux attendus vers 23 h 30 UTC le 28 avril (0 h 30 heure locale le 29 avril).

Genera PR, un fournisseur d'électricité de Porto Rico, a publié un message sur X le 16 avril afin de préciser que (traduit) « … l'île connaissait une panne de courant généralisée à travers son territoire en raison de l'arrêt inattendu de l'ensemble des centrales électriques, dont celles de Genera PR et d'autres générateurs privés. Cette situation a entraîné des perturbations importantes des services de distribution d'électricité… ». Luma Energy, l'entreprise privée responsable de la distribution et du transport d'électricité à Porto Rico, a publié son propre message sur X indiquant (traduit) : « Un événement affectant le service à l'échelle de l'île a été enregistré vers 12 h 40. »

La panne d'électricité signalée était annoncée comme « massive » et « à l'échelle de l'île », mais elle n'a pas eu d'incidence démesurée sur le trafic Internet de Porto Rico, qui a chuté d'environ 40 % au début de la coupure. Au cours des jours qui ont suivi, les deux entreprises ont publié plusieurs mises à jour sur leurs comptes X afin de détailler les progrès réalisés dans la restauration de leurs services. À 15 h UTC (11 h heure locale) le 18 avril, le trafic était revenu aux niveaux attendus, conformément à une publication de Luma Energy qui précisait (traduit) : « À 10 h le 18 avril, grâce à la vitesse de réaction extraordinaire de LUMA et aux efforts infatigables des forces vives de l'île (en coordination avec le gouvernement de Porto Rico et les entreprises de production), LUMA a rétabli le service électrique pour 1 450 367 clients, soit 98,8 % des clients totaux, moins de 38 heures depuis le début de la coupure qui a touché l'ensemble de l'île. »

Comme le montrent les graphiques ci-dessous, la panne d'électricité a non seulement affecté la connectivité des utilisateurs finaux (en entraînant une baisse du trafic observé), mais a également eu un impact sur l'infrastructure Internet locale, avec certaines perturbations visibles au sein de l'espace d'adressage IP annoncé.

Un message Facebook publié par SKELEC (The St. Kitts Electricity Company, le fournisseur d'électricité de Saint-Kitts) le 9 mai alertait ses clients de Saint-Christophe-et-Niévès de la situation suivante : « … Une défaillance s'est produite dans notre centrale Needsmust et a entraîné une panne à l'échelle de l'île. Le processus de restauration a commencé et un rétablissement complet des services est prévu dans deux heures. » L'article a été publié à 17 h 31 UTC (13 h 31 heure locale), soit environ 30 minutes après la chute initiale du trafic Internet de l'île. La reprise du trafic a commencé vers 17 h 45 UTC (13 h 45 heure locale), soit une heure parfaitement inscrite dans le délai de deux heures estimé pour le rétablissement complet de la distribution électrique. Le trafic Internet n'est toutefois revenu à son niveau normal qu'à 20 h 15 UTC (16 h 15 heure locale).

Le 18 mai, il a été signalé que « des hautes tensions présentes sur le réseau régional de 400 kV dans un contexte de faible consommation ont provoqué une défaillance de courte durée sur le réseau de transmission de 110 kV de la Macédoine du Nord… », selon MEPSO, l'entreprise de distribution d'électricité publique. La coupure a affecté la majeure partie du pays, mais MEPSO a également remarqué que l'approvisionnement en électricité du pays a été rétabli dans l'heure suivant le début de la panne. Malgré sa brièveté, la panne de courant a entraîné une chute du trafic Internet du pays de près de 60 % par rapport à la semaine précédente sur la période de la perturbation, qui a eu lieu entre 3 h et 4 h 45 UTC (5 h et 6 h 45 heure locale).

Le 1er juin, le trafic Internet des îles Maldives a chuté de près de moitié par rapport à la semaine précédente, lorsqu'une panne d'électricité généralisée a affecté la région du Grand Malé. Les FAI locaux, comme Ooredoo et Dhiraagu, se sont tournés vers les réseaux sociaux pour avertir leurs abonnés d'une interruption potentielle des connexions haut débit fixe et mobile. À l'échelle nationale, le trafic Internet a été perturbé entre 7 h 30 et 13 h UTC (12 h 30 et 18 h heure locale).

La panne d'électricité a également eu une incidence minime sur l'infrastructure Internet, car l'espace d'adressage IPv4 annoncé a connu une baisse modique (de 355 à 350 /24s) qui a commencé peu après l'observation de la chute initiale du trafic. Les niveaux sont toutefois revenus à la normale lorsque la perturbation a pris fin.

Une panne quasi totale d'Internet survenue chez l'opérateur Flow Curaçao (AS52233) les 14 et 15 juin a suscité l'indignation et des demandes de réponses de la part de l'autorité de régulation des télécommunications du pays. Le trafic Internet de Flow a chuté de manière importante à 18 h UTC (14 h heure locale) le 14 juin et a encore diminué dans les heures qui ont suivi. Des signes de reprise sont devenus visibles vers 11 h UTC (7 h heure locale) le 15 juin, tandis que le rétablissement plus complet des services s'est produit à 14 h UTC (10 h heure locale). Un message Facebook publié par Flow Barbados le 18 juin faisait référence à une perturbation locale commencée le 14 juin, mais signalait principalement une coupure de l'exploitation électrique commerciale dans l'une des principales installations de leur réseau régional de Curaçao, probablement à l'origine de cette panne d'Internet.

Deux cas de dégâts à l'infrastructure de fibre optique ont entraîné une coupure totale d'Internet chez Digicel Haïti (AS27653) à partir de 21 h UTC (17 h heure locale) le 28 mai, selon un message publié sur X (traduit) par le Directeur Général de l'entreprise. Les dommages causés aux câbles ont totalement déconnecté le réseau d'Internet, car les espaces d'adressage IPv4 et IPv6 annoncés ont également été réduits à zéro. Digicel Haïti est restée hors ligne jusqu'à 0 h 45 le 29 mai (20 h 45 heure locale le 28 mai), lorsque le trafic et l'espace d'adresse IP annoncé sont revenus aux niveaux attendus.

Airtel Malawi (AS37440) a connu une panne d'Internet de 90 minutes le 24 juin. Cette dernière était due à la poursuite d'actes de vandalisme depuis un certain temps sur son réseau de fibre optique. Le trafic a effectivement disparu entre 12 h 30 et 14 h UTC (14 h 30 et 16 h heure locale), mais le réseau est resté partiellement en ligne, car une partie au moins de l'espace d'adressage IPv4 du réseau a continué à être annoncée sur Internet.  L'espace d'adressage IPv6 annoncé est toutefois tombé à zéro pendant la durée de la panne.

Un problème au niveau d'une mise à jour des routeurs a perturbé le service Internet pour les clients de Bell Canada (AS577) en Ontario et au Québec le 21 mai. Un premier message publié par le fournisseur sur X, à 13 h 52 UTC (9 h 52 heure locale), a informé les clients de l'interruption de service. La publication a suivi le début de la perturbation d'environ une demi-heure. En effet, le trafic a commencé à chuter vers 13 h 15 UTC (9 h 15 heure locale), avec une baisse de 70 % par rapport à la même heure une semaine plus tôt. Le trafic de requêtes vers le résolveur DNS 1.1.1.1 de Cloudflare a aussi connu une chute significative. Nous avons également observé une diminution négligeable de l'espace d'adressage IPv4 annoncé.

La perturbation s'est révélée relativement brève, car le trafic est revenu aux niveaux attendus une heure plus tard. Un message publié par la suite sur X a confirmé que les services avaient été intégralement rétablis à 15 h UTC (11 h heure locale), tandis qu'une autre publication précisait que la mise à jour initiale avait rapidement fait l'objet d'une annulation afin de rétablir le service. 

Dans de nombreux secteurs des États-Unis, les clients de Lumen/CenturyLink (AS209) ont connu une coupure d'Internet de grande envergure le 19 juin. À partir de 21 h 45 UTC, les volumes de trafic ont ainsi chuté de plus de 50 % par rapport à la semaine précédente. La perturbation n'a duré que quelques heures et le trafic est revenu à la normale à 0 h UTC le 20 juin.

Les messages publiés sur les réseaux sociaux par les abonnés affectés suggéraient que le problème pourrait avoir été lié au DNS, car les utilisateurs qui avaient changé de résolveur DNS et opté pour le résolveur 1.1.1.1 de Cloudflare ont pu à nouveau accéder à Internet. Le graphique ci-dessous montre que le trafic vers le résolveur 1.1.1.1 depuis Lumen/CenturyLink a dépassé les niveaux observés la semaine précédente lorsque la perturbation a commencé et qu'il est resté élevé jusqu'au 20 juin. Les problèmes de résolveur DNS d'un FAI peuvent ressembler à une panne d'Internet pour les abonnés, car ces derniers ne peuvent alors plus accéder à quoi que ce soit qui nécessite une recherche DNS (dans les faits, toutes les ressources Internet). Or, ce schéma entraîne inévitablement une baisse du trafic vers ces ressources (de la part des utilisateurs affectés), comme l'illustre le graphique ci-dessus.

Le FAI russe ASVT (AS8752) aurait été la cible d'une attaque DDoS de grande ampleur, qui a entraîné une interruption totale de sa connectivité Internet pendant plusieurs jours. Cette attaque faisait suite à une autre attaque contre le fournisseur russe Nodex (AS29329) au mois de mars, qui avait également entraîné une coupure totale du service. Culminant à 70,07 Gb/s (6,92 millions de paquets par seconde), l'attaque a provoqué la chute du trafic à un niveau presque nul vers 5 h UTC le 28 mai (8 h heure de Moscou) pendant une durée effective d'environ 10 heures. Le trafic a commencé à se rétablir vers 15 h UTC (18 h heure de Moscou), mais il est resté en dessous des niveaux attendus tout au long de la semaine suivante.

Il est intéressant de noter que le volume de requêtes adressées au résolveur DNS 1.1.1.1 de Cloudflare par ASVT a connu une hausse rapide lorsque le trafic a commencé à revenir après la panne initiale et qu'il est resté élevé tout au long de la perturbation. Nous ne pouvons pas déterminer avec clarté si cette augmentation est due à des problèmes au niveau du résolveur DNS natif d'ASVT au cours de l'attaque, qui auraient contraint les utilisateurs à chercher d'autres résolveurs, ou si elle est liée aux abonnés d'ASVT essayant de contourner les problèmes causés par l'attaque.

D'après un « bilan de perturbation » (désormais indisponible) et un message sur X associé à cette dernière publiés par Telia Finland (AS1759), l'entreprise a reconnu « qu'une perturbation généralisée a été détectée au niveau des connexions de données sur les réseaux mobiles et du haut débit fixe. » Cette perturbation de forte amplitude a entraîné une brève panne, bien que quasi-totale, pour les abonnés entre 6 h 30 et 7 h 15 UTC (9 h 30 - 10 h 15 heure locale).

Telia Finland n'a pas révélé la cause de la disruption, mais cette dernière a manifestement affecté la connectivité IPv4, comme le montre le graphique ci-dessous illustrant l'espace d'adressage IPv4 annoncé. (L'espace d'adressage IPv6 annoncé n'a constaté aucune modification.) Cette perte de connectivité IPv4 a entraîné une augmentation simultanée de la part de trafic de Telia Finland transmise en IPv6. Normalement inférieure à 5 %, celle-ci a ainsi dépassé les 30 % au cours de la perturbation. Le trafic de requêtes vers le résolveur 1.1.1.1 de Cloudflare depuis Telia Finland a également connu un pic à ce moment-là.

Le 7 mai, autour de 19 h 15 UTC (3 h 15 heure locale le 8 mai), les abonnés de SkyCable (AS23944) aux Philippines ont subi une panne totale d'Internet. Le trafic Internet du réseau est tombé à zéro, tout comme l'espace d'adressage IPv4 annoncé. La perturbation a duré jusqu'à 3 h UTC le 8 mai (11 h heure locale), mais SkyCable n'a publié aucune information quant à la cause de cette interruption de service de huit heures.

Le 22 mai, l'opérateur mobile thaïlandais TrueMove H (AS132061) a connu une défaillance d'envergure nationale, qui a affecté la connectivité des abonnés. L'opérateur a reconnu la perturbation et s'en est excusé, mais n'a avancé aucune raison officielle à celle-ci. (Un article de la presse locale indiquait « que la panne était causée par des erreurs techniques sur les serveurs informatiques de True » et que d'autres acteurs suggéraient que « le problème pourrait avoir été causé par une erreur sur les serveurs DNS de True »).

Le trafic a ainsi connu une chute initiale de plus de 80 % par rapport à la semaine précédente à 3 h UTC (10 h heure locale). Presque immédiatement, le trafic a commencé à se rétablir lentement, pour revenir aux niveaux attendus vers 8 h UTC (15 h heure locale). Une brève réduction partielle de l'espace d'adressage IPv4 annoncé a également été observée pendant la première heure de la perturbation.

Deux jours après avoir fait les frais d'une panne due à des dégâts subis par des câbles, Digicel Haiti (AS27653) a connu une autre interruption totale de service le 30 mai. Contrairement à la panne précédente, aucune information supplémentaire à ce sujet n'a été publiée sur les réseaux sociaux par Digicel Haïti ou son Directeur Général. Le réseau a effectivement disparu d'Internet à 14 h 15 UTC (10 h 15 heure locale), avec une chute à un niveau nul du trafic et de l'espace d'adressage IP annoncé (IPv4 et IPv6). La panne a duré près de trois heures, avec un retour du trafic et de l'espace d'adressage IP annoncé vers 17 h UTC (13 h heure locale).

Le 10 juin, une interruption du service Internet survenue en Syrie aurait affecté le réseau fixe ADSL dans plusieurs provinces. À 8 h 15 UTC (11 h 15 heure locale), le trafic a ainsi chuté de jusqu'à deux tiers par rapport à la même heure la semaine précédente. La perturbation a duré deux heures. L'espace d'adressage IPv4 annoncé s'est également effondré au cours de la panne, en indiquant un problème potentiel d'infrastructure. Toutefois, comme on peut le voir ci-dessous, le volume de requêtes en provenance de la Syrie vers le résolveur DNS 1.1.1.1 de Cloudflare a également augmenté pendant la panne. Ce comportement a été observé par le passé lors de coupures de la connectivité Internet à l'initiative du gouvernement syrien, lorsque le trafic pouvait quitter le pays, mais ne pouvait pas y entrer ou y revenir. Nous n'avons constaté aucun autre signe que cette panne pourrait résulter d'une coupure intentionnelle, mais aucune explication officielle n'a été avancée quant à la perturbation.

Les coupures d'Internet d'origine gouvernementale sont revenues en force au deuxième trimestre et cette tendance se poursuit au troisième trimestre, bien que les derniers épisodes d'interruption aient été liés aux examens et non à des manifestations. De même, si nous avons effectivement observé de fréquentes perturbations d'Internet liées à des pannes d'électricité par le passé, souvent dans les petits pays disposant d'une infrastructure moins stable, la coupure gigantesque survenue en Espagne et au Portugal le 28 avril nous rappelle qu'à l'instar d'Internet, l'infrastructure électrique est souvent interconnectée entre les différents pays. Les problèmes qui surviennent au sein d'un pays peuvent donc potentiellement causer d'autres perturbations importantes dans d'autres.

L'équipe Cloudflare Radar surveille en permanence les perturbations d'Internet et partage ses observations sur la page du Cloudflare Radar Outage Center (le centre des perturbations de Cloudflare Radar), sur les réseaux sociaux et par le biais d'articles publiés sur blog.cloudflare.com. Suivez-nous sur les réseaux sociaux : @CloudflareRadar (X), noc.social/@cloudflareradar (Mastodon) et radar.cloudflare.com (Bluesky), ou contactez-nous par e-mail.