Panne du Runet le 8 octobre 2026 : la société de cybersécurité Curator reconnaît sa responsabilité

Le 8 octobre 2026, le Runet a fonctionné pendant longtemps de manière très dégradée dans tout le pays. De nombreux sites ne s'ouvraient plus, et des services populaires ne répondaient plus. La première explication semblait évidente : le même jour, un drone avait attaqué un datacenter de Yandex. La situation a ensuite changé. La cause était la société de cybersécurité Curator. Elle a reconnu sa responsabilité et affirme avoir déjà réglé le problème qui avait coupé l'internet de millions de Russes.

Chronologie et hypothèses

Face à une panne touchant des sites et des services dans tout le pays, on cherche presque mécaniquement la cause dans les plus gros points d'infrastructure. La coïncidence horaire avec l'attaque contre le datacenter de Yandex offrait une explication toute prête, et c'est elle qui a été retenue. Mais, d'après les informations disponibles, les deux événements ne sont pas directement liés.

Ce que l'on sait à ce stade :

• date de l'incident : 8 octobre 2026 ;
• ampleur : toute la Russie, sur une durée prolongée ;
• symptômes : de nombreux sites inaccessibles, des services populaires hors service ;
• première version : conséquences de l'attaque de drone contre le datacenter de Yandex ;
• version finale : la société de cybersécurité Curator est responsable ;
• statut : Curator a reconnu sa responsabilité et affirme avoir résolu le problème.

Il faut dissocier deux choses dans cette affaire. L'attaque contre le datacenter a bien eu lieu, et c'est un fait distinct. Mais, selon les données actuelles, elle n'explique pas l'indisponibilité massive des services à l'échelle du pays.

Ce que nous ne savons pas encore

La source se limite au simple fait de cette reconnaissance. On ne dispose d'aucune donnée sur le mécanisme de la panne, sur les produits ou services de Curator impliqués, sur le nombre d'heures qu'a duré l'incident ni sur les entreprises les plus durement touchées. On ignore aussi ce que Curator a fait concrètement pour corriger le problème, et si l'incident peut être considéré comme entièrement clos.

Tant que ces questions restent sans réponse, toute conclusion sur la nature technique de la panne relèverait de la conjecture. La rédaction attendra une analyse officielle de la part de l'entreprise elle-même, des opérateurs et des services touchés.

Une conclusion s'impose néanmoins. Si l'erreur d'un fournisseur de solutions de sécurité informatique a pu perturber des sites et des services à l'échelle du pays, c'est que ces fournisseurs font partie de la chaîne de dépendances critiques. On ne s'en souvient généralement qu'après un incident.

Ce que les équipes doivent vérifier

Pour les propriétaires de services et les DSI, cet épisode justifie un court audit, sans attendre les détails.

• Dressez la liste des services externes situés sur le chemin du trafic ou influant sur la disponibilité : protection, filtrage, DNS, CDN, fournisseurs de certificats.
• Pour chacun, déterminez ce qui se passe en cas de défaillance : le service continue de fonctionner, se dégrade ou s'arrête complètement.
• Vérifiez qu'une route de secours existe et qui décide de basculer dessus. La nuit et le week-end, un ingénieur d'astreinte doit pouvoir le faire.
• Mettez en place une supervision externe depuis plusieurs réseaux. Vous saurez ainsi rapidement si le problème vient de chez vous, de votre fournisseur ou de l'ensemble du pays.
• Préparez à l'avance un modèle de communication avec les clients. Le 8 octobre, la première version de la cause s'est révélée fausse, ce qui montre le prix des explications hâtives.

Le tableau complet n'apparaîtra qu'après la publication d'une analyse technique. Une chose est toutefois claire : une panne de cette ampleur peut ne pas partir de l'incident le plus visible, mais d'une erreur dans un service dont les utilisateurs ignorent l'existence.