Résumé

  • Le 13 octobre 2025, le haut débit ainsi que les services 4G et 5G de Vodafone UK ont subi une interruption nationale d’environ deux heures. NetBlocks a observé la perturbation et le rétablissement, Reuters a rapporté la réponse de l’opérateur et ITV News a relayé sa déclaration selon laquelle un problème logiciel non malveillant chez un partenaire fournisseur avait déclenché l’incident. Les appels et les SMS ont continué, et Reuters a mentionné spécifiquement la voix 2G, sans que cela constitue un audit de chaque service ou de chaque zone.
  • ThousandEyes a observé des retraits BGP importants et simultanés affectant AS25135 et AS5378, avec un espace d’adresses annoncé proche de zéro et de nouvelles annonces autour du retrait puis du rétablissement. Il s’agit d’un effet visible du plan de contrôle, pas d’une cause racine confirmée par Vodafone. Les éléments publics ne nomment pas le fournisseur, n’attribuent pas de responsabilité juridique et ne démontrent pas qu’une prévention de récidive a été achevée ou testée.
  • Le véritable test de responsabilité consiste à savoir qui pouvait modifier l’état de routage, quelles dépendances communes pouvaient atteindre les accès fixes et mobiles, quels seuils auraient dû limiter la portée d’un changement et quelles preuves permettent de distinguer retour des routes, retour du service et restauration durable. Les registres conservent l’identité et l’historique des ressources, mais seule la réalité du réseau en fonctionnement produit la joignabilité.

Deux récits publics qui ne doivent pas être fusionnés

Pour le public, l’événement s’est présenté comme une perte de connectivité. Reuters a indiqué que Vodafone travaillait au rétablissement du haut débit, de la 4G et de la 5G en Grande-Bretagne. NetBlocks a décrit une perturbation nationale du mobile et du haut débit, puis un retour du service environ deux heures plus tard. Cette durée donne une fenêtre d’impact utile, mais ne révèle ni l’heure du premier signal interne, ni le temps de détection, ni le temps consacré à chaque action de récupération.

L’étendue des services exige une formulation prudente. Reuters a rapporté que les appels vocaux 2G n’étaient pas affectés. ITV News a ensuite transmis la déclaration de Vodafone selon laquelle les appels et les SMS avaient continué alors que le haut débit, la 4G et la 5G étaient touchés. Cela permet de distinguer certaines fonctions restées disponibles de l’accès IP interrompu. Cela ne permet pas d’affirmer que chaque appel, chaque message, chaque fonction 2G, chaque emplacement ou chaque sous-système a été vérifié indépendamment.

NetBlocks a aussi observé l’indisponibilité du site de Vodafone et de sa page d’état, ainsi que des effets sur d’autres services utilisant l’infrastructure Vodafone. Une page d’état n’est pas un simple accessoire éditorial pendant une panne. Elle fait partie de la capacité opérationnelle à orienter les clients, à limiter les appels au support et à communiquer des solutions de repli. La perte simultanée du service et de son canal d’explication agrandit le coût pratique de l’incertitude.

Reuters a comptabilisé plus de 50 000 signalements d’utilisateurs sur Downdetector. Ce chiffre indique une vague importante de signalements, non un nombre de clients touchés. Une personne peut envoyer plusieurs signalements, une interruption partielle peut être déclarée, et de nombreux utilisateurs ne signalent rien. La portée nationale peut être retenue sans convertir une mesure de participation à une plateforme en estimation démographique.

Enfin, ITV News a relayé l’explication de Vodafone : un problème logiciel non malveillant impliquant un partenaire fournisseur aurait déclenché l’incident, et le service aurait été rétabli. Cette déclaration décrit l’intention comme non malveillante et situe un problème dans une relation fournisseur. Elle ne nomme pas l’entreprise concernée, ne décrit pas le logiciel, ne publie pas la séquence de commandes et ne dit pas que ce logiciel a directement retiré des routes BGP.

Ce que les observations BGP établissent réellement

L’analyse de ThousandEyes ajoute une dimension qui transforme une panne télécom générale en cas de responsabilité du plan de contrôle. Elle a observé des retraits BGP simultanés et importants affectant AS25135 et AS5378. L’espace d’adresses annoncé par ces deux systèmes autonomes est tombé presque à zéro, tandis que des activités d’annonce accompagnaient le retrait et la récupération.

BGP permet à des réseaux exploités indépendamment de s’indiquer quels préfixes IP ils peuvent joindre et par quels chemins. Lorsqu’une route est retirée, les réseaux voisins cessent d’utiliser l’ancien chemin vers le préfixe concerné. Une ligne physique peut rester connectée et un téléphone peut toujours afficher un signal radio ; si la carte interdomaines vers les destinations disparaît, les paquets ne disposent plus de la joignabilité attendue.

La simultanéité entre deux systèmes autonomes rend légitime une enquête sur une dépendance commune. Des accès fixes et mobiles peuvent reposer sur des technologies d’accès différentes tout en partageant une couche de contrôle, une automatisation, une politique ou un chemin d’administration capable d’influencer leur présentation au reste d’Internet. Ce constat définit une question à instruire. Il ne révèle pas l’architecture interne de Vodafone.

Les données publiques de routage montrent les préfixes annoncés ou retirés, l’ampleur du changement et sa chronologie depuis l’extérieur. Elles ne montrent généralement pas la commande interne, le contrôleur, le réflecteur de routes, l’identité humaine ou automatique, le composant logiciel ou la règle d’approbation qui a produit l’état. ThousandEyes a présenté des scénarios compatibles avec ses observations ; ces scénarios restent des hypothèses et non des faits internes confirmés.

Il serait donc incorrect d’écrire que Vodafone a confirmé BGP comme cause racine. Il serait tout aussi incorrect de transformer le terme « fournisseur » en accusation contre une entreprise supposée. Les deux dossiers sont compatibles : un effet de routage a été observé et l’opérateur a séparément signalé un problème logiciel chez un partenaire. Leur articulation est précisément ce qu’un examen post-incident devrait documenter.

La joignabilité est produite par le réseau actif

Les registres d’ASN et d’adresses IP jouent un rôle nécessaire. Ils associent des ressources uniques à des titulaires, conservent des contacts et établissent un historique administratif. Ils ne font cependant pas circuler les paquets. Un enregistrement exact ne garantit ni qu’un préfixe est annoncé à cet instant, ni que la politique de routage est sûre, ni qu’une route retirée pourra être rapidement restaurée.

Cette différence place l’analyse sur une couche de réalité. L’identité enregistrée rend l’attribution et la coordination possibles ; l’état produit par les logiciels, les configurations, les sessions et les annonces détermine la continuité effective. Lorsqu’un dossier administratif indique qu’une ressource appartient à un opérateur mais que son espace annoncé tombe presque à zéro, c’est le comportement du réseau en fonctionnement qui décrit ce que l’utilisateur peut atteindre.

La taille de l’entreprise, l’importance géographique du service ou l’autorisation réglementaire d’opérer ne rétablit pas une route. De même, un contrat fournisseur ne prouve pas qu’un mécanisme d’isolement fonctionne. La responsabilité doit donc se concentrer sur des éléments vérifiables : quelle autorité pouvait changer l’état, quelle enveloppe technique limitait cette autorité, quelle surveillance indépendante pouvait détecter une divergence et quelle voie de récupération restait utilisable lorsque la voie normale échouait.

Le cas Vodafone montre aussi pourquoi la précision des ressources numériques est une exigence opérationnelle et pas seulement documentaire. Pendant un incident, il faut savoir quels préfixes, systèmes autonomes, pairs et services appartiennent au périmètre affecté. Des identifiants stables permettent d’aligner les journaux de changement, les observations extérieures et les symptômes clients. Sans cette correspondance, le retour partiel du trafic peut masquer des zones encore injoignables.

Cette approche évite deux excès. Le premier serait de traiter la visibilité BGP comme une preuve complète de l’organisation interne. Le second serait d’accepter un message de rétablissement comme preuve suffisante du bon état du plan de contrôle. La responsabilité se situe entre les deux : relier le comportement observable aux décisions autorisées sans inventer ce que les preuves publiques ne contiennent pas.

La frontière fournisseur ne transfère pas la conséquence

Les réseaux télécoms modernes utilisent des plateformes, logiciels, services managés et expertises de fournisseurs. Un partenaire peut livrer une version, exécuter une opération, maintenir un outil ou conseiller l’opérateur. Vodafone peut conserver l’approbation finale, déléguer une partie de l’exploitation ou dépendre d’un service dont les mécanismes internes sont moins visibles. Le dossier public ne dit pas lequel de ces modèles s’appliquait.

Cette incertitude interdit d’assimiler « problème logiciel chez un partenaire » à une attribution complète de faute. Vodafone exploitait le réseau qui servait les clients et a communiqué le rétablissement. Un fournisseur pouvait contrôler un composant pertinent, mais les sources ne montrent ni ses droits exacts, ni ses obligations contractuelles, ni une négligence, ni un défaut de produit juridiquement établi.

La bonne unité d’analyse est le droit de décision. Qui approuve une version ou une configuration ? Qui définit le périmètre de déploiement ? Quelle identité humaine ou automatique initie le changement ? Quel système autorise ou refuse l’action ? Qui possède la surveillance des routes extérieures ? Qui peut imposer un arrêt, isoler la dépendance, choisir un état connu comme sûr et décider de reprendre ?

Un opérateur n’a pas besoin d’effectuer lui-même chaque geste pour rester responsable de la continuité. Il doit néanmoins connaître les actions capables de modifier la joignabilité critique, fixer des limites à leur portée, observer leurs effets indépendamment du composant qui agit et conserver une capacité de récupération. La délégation peut être solide si le fournisseur agit dans un domaine borné et si l’opérateur peut arrêter ou inverser l’action.

Le risque apparaît lorsqu’une partie contrôle le logiciel et l’autre supporte la conséquence, ou lorsque chacune suppose que l’autre surveille l’état externe. Un contrat peut distribuer des obligations ; le réseau actif révèle si les interfaces entre ces obligations ont fonctionné. L’objet d’un examen sérieux n’est donc pas de trouver rapidement un coupable, mais de rendre cette chaîne de décision traçable.

Le mot « défaillance » dans le titre reste dans cette limite. Il renvoie au problème logiciel opérationnel rapporté par Vodafone. Il ne signifie pas qu’un tribunal, un régulateur ou une expertise contradictoire a établi une faute, une responsabilité contractuelle ou un produit défectueux.

Détecter un symptôme ne suffit pas à contrôler l’incident

Une panne peut être détectée par des signalements clients, des alarmes d’application, des mesures d’accès, des journaux d’équipement ou une surveillance BGP externe. Chaque signal répond à une question différente. Un signalement prouve une expérience dégradée. Un test synthétique révèle qu’un parcours échoue. Une observation BGP montre que la visibilité d’un préfixe a changé. Une réponse responsable relie ces signaux sur une chronologie commune.

Les sources retenues ne donnent pas l’heure de la première alarme interne de Vodafone, le temps nécessaire à l’escalade ou l’ordre des diagnostics. La durée d’environ deux heures ne peut donc pas être transformée en délai de détection ou de réparation. Elle décrit une expérience externe entre perturbation et retour du service rapporté.

La question de conception essentielle est l’indépendance de l’observation. Si la plateforme qui publie les routes produit aussi le seul indicateur de sa propre santé, une défaillance commune peut supprimer simultanément action et visibilité. Des collecteurs externes, des sondes depuis d’autres réseaux et des tests de service sur plusieurs chemins réduisent cette dépendance. Ils ne remplacent pas les journaux internes, mais ils peuvent signaler qu’un état déclaré sain ne l’est pas depuis Internet.

Lorsque l’espace annoncé chute fortement, l’alerte doit être rattachée aux préfixes, aux ASN, aux pairs, aux services clients et aux changements récents. Il faut aussi vérifier les canaux de communication. L’indisponibilité observée du site et de la page d’état suggère qu’une mesure de continuité doit porter à la fois sur le trafic de service et sur le chemin utilisé pour informer le public.

La qualité de détection ne se résume pas à la vitesse du premier voyant rouge. Elle dépend de la capacité à déclencher la bonne contrainte. Une alarme mobile peut orienter vers le réseau radio alors que la visibilité interdomaines s’est effondrée. Une panne de site peut sembler applicative alors que les routes de destination ont disparu. La corrélation entre service, routage et changements autorisés raccourcit ce détour.

Isoler avant de prétendre connaître la cause

Une équipe d’incident doit souvent agir avant d’avoir une explication complète. Si deux systèmes autonomes retirent simultanément une grande partie de leur espace annoncé, elle a besoin d’actions bornées capables de limiter ou de restaurer la joignabilité sans attendre la fin de l’analyse forensique. Les sources ne disent pas quelles actions Vodafone a utilisées ; les mesures suivantes sont donc des critères d’assurance, pas la description de son architecture.

Le premier critère est l’existence d’un chemin de contrôle indépendant pour chaque domaine critique. Une plateforme partagée peut simplifier l’exploitation courante, mais sa défaillance ne devrait pas supprimer toutes les voies permettant de préserver ou de rétablir des routes. Des accès d’urgence séparément authentifiés, des états connus comme sûrs et des limites de propagation constituent des moyens de réduire ce risque.

Le deuxième critère est une portée progressive. Une modification valide pour un préfixe ou un domaine ne doit pas pouvoir s’étendre silencieusement à l’échelle nationale. Le système peut exiger une confirmation renforcée pour un retrait inhabituellement large, limiter une première étape à un périmètre représentatif et arrêter l’exécution lorsque l’espace annoncé franchit un seuil défini. Ces contraintes doivent couvrir les chemins exploités par un partenaire comme les chemins internes.

Le troisième critère est l’indépendance du retour arrière. Une procédure de récupération qui dépend du même logiciel, des mêmes identifiants ou du même plan de gestion que le composant en défaut peut être inutilisable au moment critique. Un état de routage de référence, conservé avec des identifiants stables et des accès protégés, n’est utile que si des exercices montrent qu’il peut être restauré sous conditions dégradées.

Le quatrième critère concerne la communication. La page d’état, la coordination de crise et le support doivent éviter une dépendance totale à l’infrastructure dont ils rendent compte. Cela ne signifie pas qu’aucun composant ne peut être partagé ; cela signifie que l’équipe doit connaître les défaillances communes et prévoir une voie de repli testée.

Ces critères ne démontrent pas le mécanisme d’octobre 2025. Ils définissent la preuve qu’un opérateur et ses fournisseurs devraient pouvoir présenter : limites déclarées, état avant changement, télémétrie indépendante, décision d’arrêt, action de confinement et comparaison entre état attendu et état obtenu.

Le rétablissement comporte plusieurs états

Une route qui réapparaît est un jalon important, mais pas une clôture automatique. Des préfixes peuvent être de nouveau annoncés alors que certaines sessions convergent encore, que des chemins restent dégradés, que des applications n’ont pas récupéré ou que les systèmes de surveillance fonctionnent en mode réduit. La communication de Vodafone indiquait que l’incident actif était terminé ; elle ne publiait pas un audit de toutes ces dimensions.

Une preuve de récupération devrait distinguer au moins le retour des annonces, la joignabilité depuis plusieurs réseaux, le rétablissement des services fixes et mobiles, la disponibilité des canaux de statut et la stabilité pendant une fenêtre d’observation. Elle devrait aussi séparer un retour obtenu manuellement d’une prévention durable de récidive.

Le mot « résolu » peut signifier que les utilisateurs retrouvent le service et que l’événement n’est plus en cours. Il ne prouve pas que l’isolation a été refondue, qu’un mécanisme de retour arrière indépendant a été testé, qu’un contrat a été modifié ou que le même enchaînement ne peut pas se reproduire. Les preuves publiques retenues ne permettent aucune de ces affirmations.

Un dossier crédible relierait la chronologie externe aux journaux internes : premières anomalies, premières alertes, changements et identités autorisées, état des routes, décisions de confinement, étapes de récupération et critères de clôture. Il identifierait les dépendances communes entre AS25135 et AS5378 sans supposer d’avance leur nature. Il expliquerait aussi comment la surveillance et la communication restaient disponibles si le plan normal de gestion ne l’était plus.

La restitution devrait préserver les incertitudes. Elle pourrait établir qu’une action donnée a produit un état de routage, ou au contraire montrer que le logiciel mentionné par l’opérateur agissait ailleurs dans la chaîne. Tant que cette liaison n’est pas publiée, l’effet BGP et la déclaration sur le fournisseur doivent rester deux faits distincts.

Ce que le dossier ne permet pas de conclure

Les quatre sources ne fournissent pas de rapport post-incident complet de Vodafone. Elles ne révèlent ni le fournisseur, ni le logiciel, ni les droits d’accès, ni les contrôleurs internes, ni la topologie exacte. Elles ne déterminent pas si le même événement aurait pu être évité par un contrôle particulier.

Elles ne prouvent pas non plus une cyberattaque, une intention malveillante, une négligence, une violation réglementaire, une responsabilité contractuelle ou une décision de justice. Aucun montant de perte, aucun dommage public précis et aucun nombre audité de clients touchés ne peut être tiré du total Downdetector.

Le constat admissible reste puissant parce qu’il est limité : une perturbation nationale des services IP a coïncidé avec des retraits de routes simultanés sur deux systèmes autonomes ; Vodafone a séparément attribué l’incident à un problème logiciel non malveillant chez un partenaire ; les informations publiques ne relient pas techniquement ces deux éléments. Cette lacune délimite l’enquête de responsabilité au lieu d’autoriser la spéculation.

Sources