Le mot « cyberattaque » s’envole ce 29 septembre 2026 sur Google France, avec un volume supérieur à 2 000 recherches et une croissance de 1 000 %, et reste actif depuis minuit. D’après les articles de presse liés par Google Trends, la flambée tient à deux alertes précises : d’un côté, un nouveau virus qui s’attaque aux smartphones et aux données bancaires de plus de 30 établissements, avec des variantes développées pour la France, décrit le 28 septembre 2026 par Capital.fr à partir des travaux des chercheurs en cybersécurité de Group-IB, relayés par 01net ; de l’autre, un logiciel malveillant Android qui utilise l’intelligence artificielle pour prendre les commandes du téléphone, décrit le 26 septembre 2026 par le Journal du Geek à partir des analyses de Zimperium. Les vraies saisies des internautes, lues dans les suggestions Google, disent l’inquiétude concrète : « cyberattaque en cours », « cyberattaque France », « cyberattaque impôts », « cyberattaque DGFIP », « cyberattaque éducation nationale ». Ni le grand public ni les entreprises ne cherchent un exposé théorique : ils veulent savoir ce qui se passe sur leur téléphone, si leur argent est menacé et ce qu’il faut faire, dans quel délai, avec quelles preuves. À la date de rédaction, aucune source officielle n’a constaté d’intrusion, de dommage ou de responsabilité dans les cas rapportés par la presse, et les contrats signés avec chaque établissement priment sur toute analyse générale : seul le juge tranche les litiges. Cet article explique le mécanisme décrit par la presse spécialisée, puis le droit applicable en France quand de l’argent quitte un compte sans l’accord du client.
I. Cyberattaque en France : comment un malware Android capte vos codes et vide vos comptes
A. Fausse application, faux VPN et accessibilité détournée : le mode opératoire décrit par la presse spécialisée
Selon Capital.fr, qui cite les chercheurs de Group-IB via 01net, le virus baptisé RemControl est un cheval de Troie actif depuis le mois de mai, présent dans plusieurs pays dont la France, l’Italie, l’Espagne, la Pologne, le Portugal et le Canada. Il cible les appareils fonctionnant sous Android, et les téléphones d’Apple ne seraient donc pas concernés, toujours selon cette source. Pour infecter les téléphones, les pirates utiliseraient de fausses pages imitant une application de télévision par internet qui n’est pas disponible sur la boutique officielle, diffusées par des publicités frauduleuses sur de grands réseaux sociaux et ciblant spécifiquement les internautes qui consultent ces plateformes depuis leur smartphone. Une fois l’application piégée installée, le programme chercherait à neutraliser les protections du téléphone : il utiliserait un faux réseau privé virtuel pour couper la connexion du dispositif de sécurité de Google, puis s’attaquerait aux fonctions d’accessibilité d’Android, prévues pour faciliter l’usage du téléphone par les personnes malvoyantes, afin d’obtenir un contrôle étendu sur l’appareil. Le point le plus redoutable, toujours d’après Capital.fr, tient à l’affichage d’une fausse interface par-dessus la véritable application bancaire : cette superposition permettrait aux pirates de récupérer des informations sensibles comme les identifiants, les codes personnels ou les données de carte bancaire. Le logiciel serait également capable de surveiller l’écran, d’enregistrer les frappes sur le clavier virtuel, de récupérer les schémas de déverrouillage utilisés sur plusieurs grandes marques de smartphones et d’empêcher sa propre désinstallation. Selon Group-IB, plus de 30 établissements financiers auraient été ciblés par les différentes campagnes, et deux variantes auraient été développées spécifiquement pour viser les utilisateurs français.
Le second signalement, publié le 26 septembre 2026 par le Journal du Geek, décrit un programme surnommé RatHat, repéré par des chercheurs en sécurité et documenté par Zimperium. Le chemin d’infection serait désormais bien connu : un message frauduleux ou une publicité malveillante conduit l’utilisateur vers une fausse page de téléchargement, qui peut imiter la boutique officielle et proposer une prétendue version d’un navigateur ou d’une application de vidéo en continu, alors que le fichier téléchargé est en réalité un programme malveillant. Après son installation, l’application réclamerait l’accès aux services d’accessibilité d’Android, parfois sous le prétexte d’une restriction de réseau ou d’un avantage financier. Ces autorisations donneraient accès au contenu affiché à l’écran et permettraient d’appuyer sur des boutons à la place de l’utilisateur. Le programme s’en servirait pour parcourir les réglages du téléphone, ouvrir les options réservées aux développeurs et activer le débogage sans fil : il lirait ensuite le code d’association à six chiffres et connecterait lui-même l’appareil à l’outil de pont de débogage, sans ordinateur ni intervention supplémentaire. Cette connexion ouvrirait une session dotée de droits étendus, grâce à laquelle le logiciel installerait deux composants discrets, l’un chargé d’exécuter des commandes système, l’autre créant un tunnel vers les serveurs des attaquants. Zimperium aurait identifié plus de cent cinquante applications infectées communiquant avec une douzaine de serveurs. La particularité du programme viendrait de son recours à une intelligence artificielle : au lieu de suivre une série d’actions programmées à l’avance, le logiciel lui transmettrait la structure des éléments présents à l’écran, et l’assistant déciderait où appuyer, quand faire défiler une page et quelle étape effectuer, ce qui lui permettrait de s’adapter à différentes versions du système et compliquerait le travail des outils de sécurité. Le programme ciblerait surtout les applications financières et les services bancaires : de fausses fenêtres superposées aux applications serviraient à récupérer identifiants, mots de passe et codes de validation, le logiciel pouvant aussi intercepter les messages courts et enregistrer les coordonnées exactes des pressions sur l’écran afin de reconstituer un code personnel ou un schéma, y compris lorsque celui-ci n’est pas directement lisible. En cas d’infection, une simple désinstallation ne suffirait pas : selon Malwarebytes, cité par le Journal du Geek, une réinitialisation complète du téléphone serait nécessaire. Les conseils de prévention rapportés par les deux sources convergent : installer ses applications depuis une boutique officielle, éviter les liens reçus par message, refuser toute demande d’accès aux fonctions d’accessibilité sans rapport évident avec le service, et contacter directement son établissement en utilisant ses coordonnées officielles en cas de doute.
Ce mode opératoire éclaire la question de droit qui monte dans les recherches : quand l’argent quitte le compte par ce biais, qui supporte la perte, la banque ou le client ? Le téléphone infecté appartient à la victime, les codes ont été captés à son insu, et les opérations ont été passées par un tiers. Le réflexe de beaucoup d’établissements consiste à opposer une faute du client qui aurait installé une application douteuse et livré ses accès. Le droit français des services de paiement encadre strictement cette discussion, et la jurisprudence récente de la Cour de cassation déjoue plusieurs idées reçues : ni la négligence alléguée ni les traces informatiques ne suffisent à elles seules, et l’absence d’authentification forte fait basculer la charge de la perte vers l’établissement, sauf fraude du payeur. Avant d’entrer dans le détail, une précision de méthode s’impose : tout ce qui précède sur le mécanisme relève de ce que rapporte la presse spécialisée à partir des éditeurs de sécurité, et non d’une constatation judiciaire. Les qualifications juridiques qui suivent s’écrivent donc au conditionnel dès qu’elles visent des faits non jugés : tel comportement pourrait être regardé comme une fraude, telle pratique serait susceptible d’engager une responsabilité, et seul le juge, saisi des pièces du dossier, décide.
B. Opérations non autorisées et authentification forte : le droit qui protège le payeur face à sa banque
Le point de départ tient en une règle simple, posée par l’article L. 133-18 du code monétaire et financier : « le prestataire de services de paiement du payeur rembourse au payeur le montant de l’opération non autorisée immédiatement après avoir pris connaissance de l’opération ou après en avoir été informé, et en tout état de cause au plus tard à la fin du premier jour ouvrable suivant » (article L. 133-18 du code monétaire et financier). Le même article ajoute que l’établissement rétablit le compte débité dans l’état où il se serait trouvé si l’opération n’avait pas eu lieu, et prévoit des intérêts majorés en cas de retard : taux légal majoré de cinq points, puis de dix points au-delà de sept jours de retard, puis de quinze points au-delà de trente jours. La seule exception au remboursement immédiat vise le cas où l’établissement « a de bonnes raisons de soupçonner une fraude de l’utilisateur du service de paiement » et les communique par écrit à la Banque de France. Autrement dit, le principe est le remboursement, l’exception est la fraude du client, et c’est à la banque d’établir cette exception. Le délai pour agir est large mais couperet : l’article L. 133-24 du même code dispose que « L’utilisateur de services de paiement signale, sans tarder, à son prestataire de services de paiement une opération de paiement non autorisée ou mal exécutée et au plus tard dans les treize mois suivant la date de débit sous peine de forclusion » (article L. 133-24 du code monétaire et financier). Passé ce délai de treize mois, la demande devient irrecevable, sauf si l’établissement n’a pas fourni les informations relatives à l’opération. Le premier réflexe reste donc le signalement immédiat, puis l’opposition : dès qu’il a connaissance de la perte, du vol, du détournement ou de toute utilisation non autorisée de son instrument ou des données liées, l’utilisateur « en informe sans tarder, aux fins de blocage de l’instrument, son prestataire ou l’entité désignée par celui-ci » (article L. 133-17 du code monétaire et financier).
La bataille se joue ensuite sur deux terrains : la négligence grave du client et l’authentification forte. L’article L. 133-19 du code monétaire et financier prévoit que le payeur supporte toutes les pertes si elles résultent d’un agissement frauduleux de sa part ou s’il n’a pas satisfait intentionnellement ou par négligence grave aux obligations de sécurité (article L. 133-19 du code monétaire et financier). Ces obligations sont rappelées par l’article L. 133-16 : « Dès qu’il reçoit un instrument de paiement, l’utilisateur de services de paiement prend toute mesure raisonnable pour préserver la sécurité de ses données de sécurité personnalisées » (article L. 133-16 du code monétaire et financier). Mais deux verrous protègent le client. D’abord, la charge de la preuve pèse sur l’établissement : l’article L. 133-23 dispose qu’« il incombe à son prestataire de services de paiement de prouver que l’opération en question a été authentifiée, dûment enregistrée et comptabilisée et qu’elle n’a pas été affectée par une déficience technique ou autre », et précise que « L’utilisation de l’instrument de paiement telle qu’enregistrée par le prestataire de services de paiement ne suffit pas nécessairement en tant que telle à prouver que l’opération a été autorisée par le payeur ou que celui-ci n’a pas satisfait intentionnellement ou par négligence grave aux obligations lui incombant en la matière » (article L. 133-23 du code monétaire et financier). Les simples journaux informatiques de la banque ne suffisent donc pas. Ensuite, l’absence d’authentification forte neutralise l’argument de la négligence : « Sauf agissement frauduleux de sa part, le payeur ne supporte aucune conséquence financière si l’opération de paiement non autorisée a été effectuée sans que le prestataire de services de paiement du payeur n’exige une authentification forte du payeur prévue à l’article L. 133-44 » (même article L. 133-19, paragraphe V). Or l’article L. 133-44 impose à l’établissement d’appliquer l’authentification forte lorsque le payeur accède à son compte en ligne, initie une opération de paiement électronique ou exécute une opération à distance comportant un risque de fraude (article L. 133-44 du code monétaire et financier).
Deux arrêts récents de la chambre commerciale de la Cour de cassation donnent à ces textes un relief directement utile aux victimes de malwares mobiles. Dans un arrêt du 22 octobre 2025 (pourvoi n° 24-19.749, arrêt du 22 octobre 2025, n° 24-19.749), un client avait répondu à un courriel qu’il pensait adressé par sa banque et communiqué des données confidentielles permettant un virement vers un compte inconnu ; l’établissement refusait le remboursement en invoquant une négligence grave. La Cour approuve le tribunal qui avait condamné la banque, au motif que « le prestataire de service de paiement doit appliquer l’authentification forte du client définie au f) de l’article L. 133-4 du même code en cas d’opération de paiement à distance et qu’à défaut, il doit rembourser au payeur le montant de l’opération non autorisée, sauf agissement frauduleux du payeur ». Même constatée, la négligence grave du client qui a livré ses codes ne prive pas du remboursement quand l’établissement ne justifie pas avoir exigé l’activation de l’authentification forte. Transposée au smartphone infecté, la leçon est nette : si les opérations passées par le malware n’ont pas été soumises à une authentification forte, la banque devrait rembourser, sauf à démontrer une fraude du client lui-même, ce qui est bien plus exigeant qu’une simple imprudence. Dans un arrêt du 5 mars 2025 (pourvoi n° 23-22.687, arrêt du 5 mars 2025, n° 23-22.687), la Cour casse un jugement qui avait déduit la négligence grave d’une cliente du seul fait que sa clé d’authentification avait été enrôlée sur un nouvel appareil via une adresse inhabituelle et que ses données de sécurité avaient été utilisées. La Cour rappelle « qu’il incombe au prestataire de services de paiement de rapporter la preuve que l’utilisateur, qui nie avoir autorisé une opération de paiement, a agi frauduleusement ou n’a pas satisfait intentionnellement ou par négligence grave à son obligation de prendre toute mesure raisonnable pour préserver la sécurité des données de sécurité personnalisées », et juge que « cette preuve de la négligence grave ne peut se déduire du seul fait que l’instrument de paiement ou les données personnelles qui lui sont liées ont été effectivement utilisés ». Pour la victime dont le téléphone a validé seul des opérations par superposition d’écrans ou interception de messages, cet arrêt constitue un appui solide : l’utilisation effective des codes ne prouve ni l’autorisation ni la négligence grave, et la banque doit rapporter une preuve positive de la faute. Les lecteurs qui ont déjà été confrontés à un vol de numéros de carte sur internet retrouveront des réflexes voisins dans notre dossier consacré aux numéros de carte volés sur des boutiques en ligne, avec l’opposition, le remboursement et la plainte, mais le cas du mobile infecté s’en distingue : ici, c’est le terminal de la victime qui valide, ce qui rend la discussion sur l’authentification forte et la preuve de la négligence encore plus centrale.
II. Cyberattaque en cours : remboursement, plainte et obligations des entreprises face au malware bancaire
A. Opposition, contestation et plainte : la procédure pas à pas pour obtenir le remboursement
Concrètement, la victime qui découvre des débits qu’elle n’a pas autorisés suit un ordre précis, et chaque étape conditionne la suivante. D’abord, faire opposition et bloquer : appeler immédiatement le numéro d’opposition de son établissement ou le serveur interbancaire, puis confirmer par écrit, afin de figer l’instrument et d’éviter de nouveaux débits. Le malware pouvant intercepter les messages et maintenir un accès, il faut aussi assainir le terminal : après sauvegarde des preuves, réinitialiser complètement le téléphone, comme le recommande Malwarebytes cité par la presse, changer depuis un appareil sain tous les mots de passe et codes, et prévenir son opérateur si la ligne a servi à intercepter des codes. Ensuite, contester par écrit auprès de la banque : lettre recommandée ou message tracé décrivant chaque opération litigieuse, affirmant qu’elles n’ont pas été autorisées, demandant le remboursement immédiat et le rétablissement du compte en application de l’article L. 133-18, et rappelant le délai de treize mois de l’article L. 133-24. Joindre le récépissé d’opposition, les relevés annotés, les captures des messages frauduleux et de la fausse application, et le dépôt de plainte. Si l’établissement oppose la négligence grave, répondre point par point : rappeler que les journaux informatiques ne suffisent pas à prouver l’autorisation ni la faute, en vertu de l’article L. 133-23, exiger la preuve de l’authentification forte opération par opération, et invoquer, quand c’est le cas, l’absence d’authentification forte qui neutralise toute conséquence financière hors fraude du payeur. En cas de refus maintenu, saisir le médiateur bancaire, puis le tribunal : à Paris et en Île-de-France, le tribunal judiciaire de Paris concentre l’essentiel de ce contentieux bancaire, et les délais pratiques constatés imposent de constituer le dossier tôt, avec des pièces datées et lisibles. Vérifier aussi ses assurances : carte bancaire haut de gamme, assurance habitation ou protection juridique peuvent couvrir une partie du préjudice ou les frais de procédure, selon les plafonds et exclusions du contrat.
Le volet pénal renforce la demande civile et ouvre des qualifications adaptées au montage. L’escroquerie, définie par l’article 313-1 du code pénal comme « le fait, soit par l’usage d’un faux nom ou d’une fausse qualité, soit par l’abus d’une qualité vraie, soit par l’emploi de manoeuvres frauduleuses, de tromper une personne physique ou morale et de la déterminer ainsi, à son préjudice ou au préjudice d’un tiers, à remettre des fonds, des valeurs ou un bien quelconque, à fournir un service ou à consentir un acte opérant obligation ou décharge », punie de cinq ans d’emprisonnement et de 375 000 euros d’amende (article 313-1 du code pénal), pourrait correspondre aux fausses pages, aux faux prétextes et aux fausses interfaces qui captent les codes. L’accès frauduleux à un système de traitement automatisé de données, puni de trois ans d’emprisonnement et de 100 000 euros d’amende par l’article 323-1 du code pénal, qui dispose que « Le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie d’un système de traitement automatisé de données est puni de trois ans d’emprisonnement et de 100 000 € d’amende » (article 323-1 du code pénal), pourrait viser la prise de contrôle du téléphone et l’installation des composants espions. Quand les codes et identifiants d’autrui sont réutilisés, l’usurpation d’identité de l’article 226-4-1 du code pénal, qui punit « Le fait d’usurper l’identité d’un tiers ou de faire usage d’une ou plusieurs données de toute nature permettant de l’identifier en vue de troubler sa tranquillité ou celle d’autrui, ou de porter atteinte à son honneur ou à sa considération » d’un an d’emprisonnement et de 15 000 euros d’amende (article 226-4-1 du code pénal), pourrait également être retenue selon les circonstances. En pratique, déposer plainte en ligne via la pré-plainte puis au commissariat ou à la gendarmerie, signaler l’escroquerie sur la plateforme officielle du ministère de l’intérieur, et conserver l’attestation : la plainte ne rembourse pas à elle seule, mais elle objective la fraude, écarte le soupçon de fraude du client que la banque pourrait invoquer pour refuser le remboursement, et fonde une constitution de partie civile pour les préjudices annexes comme les frais d’opposition, les agios ou le préjudice moral lié à l’usurpation. Les questions fiscales qui remontent dans les suggestions, « cyberattaque impôts » et « cyberattaque DGFIP », appellent une vigilance distincte : si des identifiants fiscaux ont été captés via le téléphone, surveiller l’espace fiscal en ligne, signaler toute déclaration ou demande inconnue, et ne jamais saisir ses codes fiscaux depuis un appareil suspect.
B. Dirigeant et entreprise : vigilance sur les virements, sort des fonds et notification des violations de données
Le malware bancaire ne menace pas que les particuliers : le salarié qui valide depuis son mobile des opérations pour le compte de la société, l’associé qui gère la trésorerie sur son téléphone et le dirigeant qui reçoit des demandes pressantes de virement sont exposés aux mêmes écrans truqués, avec des montants bien supérieurs. Quand les fonds ont déjà quitté les comptes vers un bénéficiaire désigné par un identifiant, fût-il piégé, l’article L. 133-21 du code monétaire et financier prévoit que l’ordre exécuté conformément à l’identifiant unique fourni est réputé dûment exécuté pour ce qui concerne le bénéficiaire désigné, sans responsabilité de l’établissement pour la mauvaise exécution, mais oblige l’établissement du payeur à s’efforcer de récupérer les fonds, avec l’aide de l’établissement du bénéficiaire, et à mettre à disposition du payeur les informations détenues pour documenter son recours en justice (article L. 133-21 du code monétaire et financier). D’où l’importance d’agir dans l’heure : opposition, demande écrite de rappel des fonds, dépôt de plainte et, si le bénéficiaire est identifié, mise en demeure puis action en répétition. Parallèlement, la jurisprudence impose aux banques une vigilance active quand les ordres présentent des anomalies apparentes. Dans un arrêt du 2 octobre 2024 rendu en matière de fraude dite au président (pourvoi n° 23-13.282, arrêt du 2 octobre 2024, n° 23-13.282), la Cour de cassation a jugé que « la cour d’appel a exactement retenu que la banque était tenue d’alerter la société afin d’obtenir la confirmation des ordres litigieux en exécution de son obligation de vigilance », après avoir relevé des ordres rapprochés et répétés, passés à une période inhabituelle, pour des montants élevés et inhabituels, au profit de sociétés étrangères hors des relations d’affaires de la cliente. Une entreprise dont la banque a exécuté sans alerte des virements manifestement atypiques initiés depuis un terminal compromis pourrait donc discuter la responsabilité de l’établissement, en documentant ses habitudes de paiement et les signaux que la banque aurait dû repérer. En interne, le dirigeant avisé verrouille la procédure : double validation des virements sur deux canaux distincts, plafonds d’opérations mobiles, interdiction d’installer des applications hors boutique officielle sur les terminaux professionnels, et consigne écrite de rappel téléphonique systématique, sur un numéro connu et indépendant du message reçu, avant tout virement inhabituel.
Enfin, toute entreprise dont des données personnelles ont été exposées par ce type d’attaque doit intégrer le réflexe de notification. La Commission nationale de l’informatique et des libertés rappelle que les obligations de notification d’une violation de données sont définies aux articles 33 et 34 du règlement général sur la protection des données, et précise que la notification à la CNIL doit intervenir dans les meilleurs délais et au plus tard dans les 72 heures après que le responsable du traitement en a pris connaissance, via le téléservice dédié, avec une documentation interne de chaque incident (CNIL, violations de données personnelles : les règles à suivre ; CNIL, notifier une violation de données personnelles). Si la violation est susceptible d’engendrer un risque élevé pour les droits des personnes, celles-ci doivent en être informées dans les meilleurs délais, en des termes clairs, avec la nature de l’incident, les mesures prises et les précautions recommandées. Pour l’entreprise cliente d’un prestataire informatique ou d’une banque dont le système serait en cause, cela signifie : exiger du prestataire une information immédiate et écrite, suspendre les flux compromis, auditer les journaux d’accès, et préparer la communication aux personnes concernées. À Paris et en Île-de-France, où se concentrent les sièges, les directions financières et les prestataires, les délais pratiques sont serrés : constituer dès le premier jour une chronologie horodatée, conserver les journaux techniques, et faire constater par huissier ou par un prestataire de réponse à incident les traces volatiles avant toute réinitialisation massive. Ces pièces serviront à la fois devant la CNIL, devant la banque pour le rappel des fonds, et devant le juge pour la réparation.
Conclusion
La vague de recherches sur la « cyberattaque en cours » s’explique par des faits précis rapportés par la presse : un cheval de Troie bancaire visant les téléphones Android en France, des fausses applications qui captent codes et données de carte, et un logiciel capable de valider seul des opérations depuis le mobile de la victime. Face à ce mécanisme, le droit français offre au client des leviers puissants : remboursement au plus tard le premier jour ouvrable suivant, treize mois pour signaler sous peine de forclusion, preuve de la négligence grave à la charge de la banque, et neutralisation de l’argument de la faute quand l’authentification forte n’a pas été exigée. La plainte pénale, l’opposition immédiate et un dossier de preuves méthodique complètent le dispositif, tandis que les entreprises ajoutent la vigilance sur les ordres atypiques, le rappel des fonds et la notification des violations dans les délais. À la date de rédaction, aucun accident, aucune intrusion ni aucun dommage n’a été constaté par une source officielle dans les cas rapportés, aucune responsabilité n’est établie, les contrats signés avec chaque établissement priment sur toute analyse générale, et seul le juge, saisi des pièces, décide de l’issue de chaque litige.