Pourquoi toutes les cartes Revolut ont-elles été refusées le 20 octobre 2026 ? La panne expliquée

Si votre carte Revolut a été refusée ce matin, en caisse, à l’automate d’une station-service ou au distributeur, le problème ne venait ni de la carte ni de vous. Dans la matinée du mardi 20 octobre 2026, Revolut a subi une panne généralisée. Paiements par carte, virements, retraits aux distributeurs et même connexion à l’application ont échoué pour des clients au Royaume-Uni, en France, en Espagne, en Allemagne et en Grèce, ainsi qu’en Irlande. Revolut a confirmé une interruption de service touchant plusieurs services et déclaré que l’argent et les données de tous les clients sont en sécurité. Le déclencheur le plus probable est une défaillance de Google Cloud dans sa région de Londres, qui a commencé à 06 h 08 UTC, soit 08 h 08 à Paris, et que Google a depuis attribuée à un incident d’alimentation électrique. Une personne proche du dossier a déclaré à Reuters que la panne de Revolut était liée à la perturbation de Google Cloud. Aucune des deux entreprises n’a confirmé publiquement ce lien.

Les directs vous apprennent que Revolut est en panne. Ils ne vous disent pas où, dans la chaîne de paiement, se situe la défaillance, pourquoi un automate de station-service refuse votre carte alors qu’une caisse l’accepte parfois, ni comment une seule région cloud à Londres peut bloquer une carte dans une station-service française. Cet article répond à ces questions, distingue la panne des récentes frappes sur les data centers russes et d’une faille de machines virtuelles Linux fraîchement divulguée, et liste ce qu’il faut avoir sur soi pour qu’une simple panne d’émetteur ne vous laisse plus jamais en rade.

Pourquoi ma carte Revolut a-t-elle été refusée le 20 octobre ?

Parce que Revolut, l'entreprise qui approuve chaque paiement effectué avec ses cartes, n'a pas pu répondre pendant plusieurs heures. À partir d'environ 08 h 00, heure de Paris, rapporte Clubic, l'application affichait un message d'erreur, les cartes étaient refusées en boutique et dans les taxis, et les virements échouaient. Revolut compte plus de 8 millions de clients rien qu'en France. La presse tech française a signalé des refus en caisse et aux distributeurs.

La page de statut de Revolut a mis du temps à suivre. À 09 h 42, heure de Paris, elle affichait encore tous les systèmes opérationnels ; elle a ensuite listé 31 services partiellement indisponibles, dont les paiements par carte, les virements, les retraits aux distributeurs, les services premium et la connexion. Voici la matinée telle qu'elle s'est déroulée.

À 13 h 25, heure de Paris, le 20 octobre, Google attribue la panne à un incident d'alimentation électrique dans la zone europe-west2-b, indique que l'incident d'alimentation est atténué et que les services sont rétablis progressivement, mais son incident reste ouvert et son rapport d'incident complet n'a pas été publié. Revolut n'a émis aucun avis de rétablissement et n'a nommé aucune cause. Nous mettrons cet article à jour lorsque Revolut ou Google publieront un post-mortem.

Était-ce Revolut, Visa ou le commerçant ?

Chaque paiement par carte fait intervenir trois acteurs. Le terminal du commerçant et sa banque (l'acquéreur) lisent la carte et envoient une demande d'autorisation. Le réseau de cartes, Visa, Mastercard ou CB en France, achemine cette demande. L'émetteur, la banque derrière votre carte, répond oui ou non en temps réel. Le 20 octobre, nous n'avons trouvé aucun incident signalé par Visa, Mastercard ou CB, et aucun autre émetteur de cartes n'a signalé de problème, ce qui, selon toute évidence, situe la défaillance chez Revolut en tant qu'émetteur.

Une panne d'émetteur, c'est quand la banque derrière votre carte ne peut pas répondre à la demande d'approbation du réseau de paiement : tous les terminaux refusent alors la carte en même temps, quel que soit le commerce et quel que soit le pays. C'est pourquoi la situation paraissait si étrange de l'extérieur : la carte échouait partout simultanément, pendant que la personne à côté de vous payait sans difficulté.

Cela explique aussi pourquoi les automates des stations-service refusaient systématiquement alors qu'une caisse acceptait parfois la carte. En France, un automate 24/24 demande à l'émetteur d'approuver un montant maximal fixe avant que vous ne preniez le pistolet, souvent 100 à 150 euros fixés par la station, puis le remplace ensuite par le montant réel. Cette pré-autorisation exige une réponse en direct de l'émetteur : quand l'émetteur reste muet, l'automate dit non à chaque fois. L'automate rend visible une panne d'émetteur ; il ne la cause pas. Une explication possible des paiements qui sont tout de même passés : certains terminaux peuvent approuver de petits montants hors ligne et les régler plus tard, ce qui expliquerait que Clubic ait rapporté que certains clients Revolut pouvaient encore payer dans certains commerces alors que la plupart des cartes étaient refusées.

Quel rapport entre Google Cloud et ma carte bancaire ?

Beaucoup de banques et de fintechs font tourner une grande partie de leurs logiciels sur une infrastructure cloud louée, et quand cette infrastructure tombe, leurs services peuvent tomber avec elle. Google indique que le problème a commencé à 06 h 08 UTC ; sa première mise à jour de statut, publiée à 10 h 35, heure de Paris, soit environ deux heures et demie plus tard, faisait état d'erreurs élevées et de défaillances réseau intermittentes dans europe-west2, sa région de Londres. Pour un porteur de carte, cet écart a compté. Pendant environ deux heures et demie, la page de statut de Google ne disait rien, et à 09 h 42, heure de Paris, celle de Revolut affichait encore tous les systèmes opérationnels. The Register note que europe-west2-b est l'une des trois zones de disponibilité de cette région. La page d'incident de Google liste 38 produits impactés, dont Kubernetes Engine, Cloud Run et BigQuery Data Transfer Service, et Google a présenté ses excuses à toutes les personnes affectées. À 13 h 12, heure de Paris, Google a nommé une première cause : « En raison d'un incident d'alimentation électrique, nous avons subi une panne dans la zone europe-west2-b. L'incident d'alimentation est atténué », indique sa mise à jour, les services étant rétablis progressivement. La déclaration de Google concerne sa propre zone et ne mentionne pas Revolut. Les autres régions Google en Europe, dont Paris et Francfort, n'ont signalé aucun problème.

Le lien avec Revolut reste attribué, pas confirmé. Une personne proche du dossier a déclaré à Reuters que la panne de Revolut était liée à la perturbation de Google Cloud, et les déclarations de Revolut ne mentionnent pas Google. The Journal a rapporté que la perturbation proviendrait d'une panne chez un prestataire tiers, sans en nommer un. Le même matin, Downdetector UK affichait des pics pour Lloyds, Halifax, Bank of Scotland, HSBC, NatWest, Santander UK et MBNA, ainsi que Royal Mail, Rightmove et GOV.UK, et des clients d'ING Allemagne avaient des difficultés à se connecter à leur banque en ligne et à l'application. Personne n'a officiellement rattaché ces signalements à Google Cloud, et les pics Downdetector peuvent tromper, puisque des utilisateurs inquiets vérifient des services qui fonctionnent en réalité très bien.

Quoi que dise le post-mortem final, la forme de l'événement est familière. En septembre, quand ChatGPT, Claude et Grok sont tombés ensemble, un cloud partagé était le premier suspect et s'est révélé ne pas être la cause ; cette fois, une seule région cloud est l'explication privilégiée, bien que toujours non confirmée. Quand beaucoup d'entreprises louent le même immeuble, un défaut dans cet immeuble peut devenir le défaut de tout le monde à la fois, et cette fois le service en question était la carte dans votre poche.

Était-ce une cyberattaque, ou un lien avec les frappes sur les data centers russes ?

Non, au vu des éléments disponibles. Depuis le 8 octobre 2026, des drones ukrainiens ont frappé des data centers de Yandex à Sassovo, Kalouga et Vladimir, perturbant les services Yandex en Russie et dans les pays voisins ; nous avons couvert ces frappes en détail ici. La couverture de ces frappes ne mentionne aucun effet sur les banques européennes, les paiements par carte ou les fournisseurs cloud occidentaux. Revolut n'opère pas en Russie. La panne de Revolut a coïncidé avec un problème dans une installation de Google à Londres, et aucune source ne relie les deux événements. Ils ne se ressemblent que sur un point : tous deux montrent que des services critiques reposent sur un petit nombre de bâtiments physiques. Mais l'un est une frappe militaire contre une infrastructure et l'autre une panne cloud ordinaire, et les confondre n'aide personne.

Rien ne pointe non plus vers un piratage. Aucune source ne rapporte d'intrusion, Revolut affirme que l'argent et les données des clients sont en sécurité, et l'application de budget Emma, également touchée ce matin, a décrit son propre problème comme une défaillance technique et non une faille de sécurité. Une cyberattaque n'est pas formellement exclue tant qu'un post-mortem n'est pas paru, mais tout ce qui est visible aujourd'hui pointe vers un incident cloud, pas une attaque, et Google lui-même attribue désormais sa panne de Londres à un incident d'alimentation électrique dans la zone europe-west2-b, son rapport d'incident complet restant à venir.

Était-ce la faille Linux PwnEscape, ou un épisode d'une série de pannes cloud ?

Une deuxième question mérite le même traitement. Une faille Linux fraîchement divulguée pourrait-elle être en cause ? Le 15 octobre 2026, cinq jours avant la panne, l'équipe CVE du noyau Linux a publié CVE-2026-99999, surnommée PwnEscape, une faille critique dans le code réseau du noyau, dans son traitement des sommes de contrôle IPv4, notée 9,3 sur 10 selon CVSS 3.1. La note est élevée à cause de ce que le bug permet. Une machine virtuelle invitée malveillante peut envoyer des paquets réseau forgés qui corrompent le noyau de la machine hôte sur laquelle elle tourne, et les chercheurs ont démontré des fuites de mémoire de l'hôte, des plantages de l'hôte et l'exécution de code en root sur l'hôte, dans leur propre laboratoire. La faille se situe dans la pile réseau Linux qui gère le trafic des invités, pas dans un hyperviseur en particulier.

La découverte elle-même s'est déroulée dans les règles. L'équipe de recherche PWN.AI a trouvé le bug lors du défi de sécurité du bac à sable de Vercel, l'a signalé en privé aux mainteneurs du noyau le 4 septembre, et le correctif a été intégré au noyau Linux principal le 14 octobre. Surtout, aucune exploitation dans la nature n'a été signalée. L'évaluation de la CISA du 16 octobre, consignée sur la fiche CVE, indique « Exploitation: none » (aucune exploitation), et la faille ne figure pas au catalogue des vulnérabilités exploitées connues de la CISA. Google n'a publié aucun bulletin de sécurité à son sujet, et ses bulletins jusqu'au 19 octobre ne la mentionnent pas. Google attribue la panne de Londres à un incident d'alimentation électrique dans la zone europe-west2-b, les déclarations de Revolut ne mentionnent ni Google ni la moindre vulnérabilité, et Emma a décrit son propre problème comme une défaillance technique et non une faille de sécurité. Aucune source crédible ne relie PwnEscape à cette panne.

Le contexte, lui, est bien réel. Cet automne a apporté une série de grands incidents cloud. Le 1er septembre, des câbles de fibre réseau débranchés pendant une maintenance de routine de routeurs ont isolé des parties de deux zones de la région us-central1 de Google Cloud, dans l'Iowa, pendant environ quatre heures, de 07 h 41 à 11 h 52, heure du Pacifique, affectant 16 produits. Du 30 septembre au 1er octobre, les services de passerelle de Microsoft Azure, dont ExpressRoute, VPN Gateway, Azure Firewall, Application Gateway et Azure VMware Solution, ont été perturbés dans 18 régions à partir de 20 h 30 UTC, et Microsoft a évoqué une corrélation avec une opération de maintenance du système d'exploitation de l'infrastructure. Les 8 et 9 octobre, une mise à jour de configuration de répartition de charge a surchargé des nœuds de Google Cloud Storage dans us-central1, provoquant des erreurs d'écriture pendant un total d'environ 18 heures sur deux jours.

La conclusion honnête découle de ces rapports. La série d'incidents est réelle, et elle montre à quel point tout dépend d'une poignée de fournisseurs, mais les causes annoncées étaient des travaux de maintenance, des changements de configuration et des questions de capacité, et aucun de ces rapports ne mentionne une attaque ou une vulnérabilité. La panne de Londres s'inscrit désormais dans ce schéma : Google l'attribue à un incident d'alimentation électrique, une autre cause sans lien avec une attaque, même si son rapport d'incident complet est encore attendu.

Pourquoi les messages de phishing suivent-ils les pannes ?

Parce qu'une panne offre aux escrocs un scénario clé en main. Des milliers de personnes viennent de voir leur carte refusée, sont inquiètes et attendent un message de leur banque. Un faux SMS annonçant que votre carte a été suspendue, avec un lien pour vérifier vos informations, est bien plus crédible un jour comme aujourd'hui qu'un mardi ordinaire. Attendez-vous à une vague de ces messages dans les prochains jours, par SMS, e-mail et appel téléphonique.

Il y a une raison de prendre cela particulièrement au sérieux avec Revolut. En septembre 2026, un attaquant se faisant passer pour un régulateur gouvernemental italien, écrivant depuis un domaine gouvernemental légitime, a obtenu des données sur environ 650 clients, dont des pièces d'identité, des photos, des relevés de compte et des historiques de transactions. Revolut a qualifié l'affaire d'escroquerie sophistiquée par usurpation d'identité externe, précisé que ses systèmes et les fonds des clients n'étaient pas affectés, et contacté les personnes concernées. Cette fuite n'est pas liée à la panne du 20 octobre, mais elle signifie que les vraies données de certains clients circulent, ce qui rend un message de phishing d'autant plus personnel et convaincant.

Aucun véritable conseiller bancaire n'a besoin de votre code PIN, de vos mots de passe, de vos codes à usage unique ou des données de votre carte, et aucun ne vous demandera d'approuver quelque chose dans votre application parce qu'il vous a appelé ; en cas de doute, raccrochez et contactez la banque via son application. Ne touchez pas aux liens dans les messages au sujet de la panne ; ouvrez directement l'application et lisez ses notifications. En filet de sécurité, le Threat Protection de Le VPN bloque les domaines de phishing et de malware connus avant qu'ils ne se chargent. Il ne peut pas empêcher un SMS d'arriver ni attraper chaque domaine frauduleux flambant neuf, donc votre propre scepticisme reste la première ligne de défense.

Comment éviter d'être bloqué la prochaine fois ?

Vous ne pouvez pas empêcher la prochaine panne de Revolut, mais vous pouvez en faire un non-événement pour vous.

• Ayez une seconde carte d'un autre émetteur. Une seconde carte Revolut tombe en même temps que la première. Pour les résidents de France, une carte CB d'une banque française est un bon complément, puisqu'un émetteur différent l'approuve.
• Gardez un peu de liquide. De quoi payer le carburant et les repas. Les retraits Revolut aux distributeurs étaient aussi en panne, donc le moment de retirer du liquide est avant une panne, pas pendant.
• À la station-service, la caisse avec un employé vaut la peine d'être tentée plutôt que l'automate pendant une panne d'émetteur, même si elle peut refuser aussi.
• Vérifiez d'abord la page de statut et les notifications dans l'application. Avant de conclure que votre carte est bloquée ou compromise, regardez si l'émetteur signale un incident. Revolut liste aussi les raisons ordinaires de refus, comme une carte gelée, un plafond de dépenses, une confirmation 3-D Secure en attente ou un type de paiement désactivé, avec la raison précise affichée dans l'application.
• Ne gelez pas, n'annulez pas et ne réinitialisez pas la carte sous le coup de la panique. Pendant une panne d'émetteur, cela ne change rien, et une carte annulée signifie attendre un remplacement une fois le service revenu.
• Ne donnez jamais vos informations à quiconque vous contacte en se présentant comme le support Revolut, aujourd'hui plus que jamais.
• Conservez des captures d'écran horodatées des paiements refusés et des virements échoués s'ils vous ont coûté de l'argent, et signalez-les au support Revolut via l'application une fois le service rétabli.

Une chose qui n'aurait pas aidé, c'est un VPN, et nous le disons en tant que fournisseur de VPN. L'autorisation d'un paiement par carte circule entre le terminal, le réseau de cartes et l'émetteur ; votre propre connexion, avec ou sans un serveur VPN en France, ne joue aucun rôle dans l'approbation d'un paiement. Un VPN protège votre trafic et, avec Threat Protection, filtre bon nombre des domaines frauduleux qui suivent une journée comme celle-ci. Il ne maintient pas une banque en marche.

Google a donné une première cause, un incident d'alimentation électrique dans sa zone europe-west2-b, mais le rapport d'incident complet reste à venir. Quand il arrivera, trois choses seront à surveiller : ce que l'incident d'alimentation a exactement mis hors service, si Revolut confirme le lien avec Google Cloud dans ses propres mots, et pourquoi sa page de statut affichait tous les systèmes opérationnels alors que des cartes étaient déjà refusées en caisse dans toute l'Europe.