Isula Web

Applications mobiles bancaires : quels critères de sécurité vraiment fiables ?

Une appli bancaire n'est pas un site web : ce que vous pouvez vraiment vérifier tient en trois minutes. Faisons le tri entre marketing, normes techniques et vrais réflexes.

Applications mobiles bancaires : quels critères de sécurité vraiment fiables ?

Un matin de février, un lecteur m'écrit : « Ma banque m'a appelé pour une fraude, mais comment savoir si c'est vraiment elle ? » Vaste question. Et c'est précisément le nœud du problème : sur un smartphone, vous ne voyez ni le numéro réel, ni le site affiché, ni le cadenas du navigateur.

Une application bancaire mobile, ce n'est pas un site web miniature. C'est un logiciel signé par votre banque, installé sur un téléphone que vous ne contrôlez pas totalement. Ce détail change tout. Les critères de sécurité qui comptent ne sont donc pas les mêmes que pour un navigateur, et surtout, la plupart des articles expliquent comment la banque protège son système, pas ce que vous, client, pouvez réellement vérifier.

Je vais faire le tri. Ce qui relève du marketing, ce qui relève d'une vraie norme technique, et ce que vous pouvez contrôler vous-même en trois minutes.

Points clés à retenir

  • L'authentification forte (DSP2) est obligatoire pour les opérations sensibles, mais son déclenchement côté mobile reste variable d'une banque à l'autre.
  • La biométrie ne remplace jamais complètement le code de votre téléphone : elle déverrouille une clé stockée sur l'appareil, pas votre compte lui-même.
  • Un téléphone rooté ou jailbreaké peut faire perdre la protection de l'environnement sécurisé — certaines apps refusent alors de démarrer, à raison.
  • Le contrôle d'appel en cours (détection de vishing) est un dispositif récent, encadré par la CNIL, qui exige votre consentement explicite.
  • Le vrai point faible d'une appli bancaire est rarement l'appli : c'est le navigateur, le SMS ou l'appel téléphonique à côté.
  • Vérifiez toujours que vos opérations passent bien par l'authentification forte — si ce n'est pas le cas, il y a un problème.

Applications mobiles bancaires : la sécurité se joue à trois niveaux

Quand on parle de « sécurité d'une appli bancaire », on mélange en réalité trois choses distinctes. Les confondre, c'est passer à côté de l'essentiel.

Niveau 1 : l'environnement de l'appareil

Avant même que l'appli s'ouvre, elle vérifie l'état du téléphone. Est-il rooté (Android) ? Jailbreaké (iOS) ? Un appareil modifié peut permettre à un logiciel malveillant de lire la mémoire d'une autre app, ce que les systèmes d'exploitation interdisent normalement.

Sur mon propre téléphone, testé avec une ROM alternative l'an dernier, deux de mes trois applications bancaires ont carrément refusé de se lancer. La troisième affichait un avertissement discret. Ce refus n'est pas un bug : c'est un critère de sécurité en action. Une banque qui laisse son app tourner sur un appareil compromis n'assume pas ses responsabilités.

Niveau 2 : le chiffrement et le stockage local

Deux moments comptent. Le premier, le transport : les données échangées avec les serveurs de la banque doivent voyager chiffrées, en HTTPS avec un certificat valide. Le second, plus subtil, le certificate pinning. Concrètement, l'appli ne fait pas confiance à n'importe quel certificat : elle vérifie que celui présenté correspond exactement à celui attendu. Sans ce mécanisme, un attaquant bien placé sur le réseau peut intercepter le trafic en se faisant passer pour un serveur légitime.

Ensuite vient le stockage. Quand vous vous connectez, l'appli conserve un token (un jeton d'accès) pour ne pas vous redemander votre mot de passe à chaque écran. Ce jeton doit être rangé dans la zone protégée du téléphone, pas dans un fichier lisible par n'importe quoi. Sur Android, c'est le KeyStore ; sur iOS, le Keychain. Si une banque stocke ce jeton en clair, tout le reste s'effondre.

Niveau 3 : votre authentification

C'est le niveau que vous connaissez le mieux, et pourtant celui qu'on comprend le moins bien. Code PIN à six chiffres, schéma, biométrie... Ces méthodes ne protègent pas votre compte de la même façon.

Méthode Ce qu'elle protège réellement Limite principale
Code PIN de l'appli L'accès local à l'appli sur ce téléphone Peut être observé ou deviné (dates de naissance, suites)
Empreinte / visage Le déverrouillage d'une clé stockée dans l'appareil Ne remplace pas l'authentification forte côté serveur
Code à usage unique (SMS) Une opération ponctuelle Vulnérable au SIM swapping et à l'interception
Authentification forte DSP2 L'opération sensible elle-même Déclenchement variable selon les banques
Notification push signée La validation d'une transaction précise Peut être détournée si l'utilisateur valide sans lire

Le point que personne ne dit assez fort : la biométrie ne remplace pas l'authentification forte. Elle déverrouille une clé locale. C'est le serveur de la banque qui décide ensuite si l'opération nécessite un facteur supplémentaire. Ces deux couches sont indépendantes, et une appli bien conçue ne les confond jamais.

Les applications bancaires sont-elles sécurisées ?

Oui, dans l'ensemble — mieux que la moyenne des applications que vous utilisez. Mais la question est mal posée. Aucune appli n'est « sécurisée » dans l'absolu : elle l'est relativement à un modèle de menace. Et le modèle de menace a changé.

Les applications bancaires sont-elles sécurisées ?

Ce qui a changé ces dernières années

Le vol de données bancaires par piratage pur est devenu rare et difficile. Alors les attaquants ont changé de cible. Ils ne cherchent plus à casser le chiffrement : ils cherchent à vous faire faire le travail à leur place. C'est ce qu'on appelle l'ingénierie sociale, et elle est redoutablement efficace.

Le schéma classique : un appel. « Bonjour, je suis de la cellule fraude de votre banque, nous détectons un paiement suspect, pouvez-vous confirmer ? » La personne au bout du fil connaît votre nom, le nom de votre banque, parfois les quatre derniers chiffres de votre carte. Elle vous guide, avec calme, vers l'action qu'il faut éviter.

Et là, votre appli bancaire ne peut rien faire. Elle est blindée. C'est vous qu'on manipule.

Le contrôle d'appel en cours : comment ça marche vraiment

Face à ce fléau, certaines banques déploient un dispositif de détection de fraude par manipulation en temps réel. Le principe : pendant que vous êtes en communication avec un numéro suspect, l'appli analyse le contexte de l'appel et peut afficher un avertissement.

Techniquement, cela repose sur une permission système. Sur Android, l'accès à l'état du téléphone et à la détection d'appel en cours ; sur iOS, un cadre plus restreint. La base légale côté données personnelles relève du RGPD, et la CNIL a posé un cadre : ce contrôle nécessite votre consentement explicite, il doit être activable et désactivable, et son périmètre doit être limité à la détection de fraude — pas à l'écoute ou à l'enregistrement de vos conversations.

C'est l'angle que je trouve le plus intéressant, et le moins documenté. Beaucoup de banques communiquent sur le dispositif sans expliquer la mécanique. Poser la question à son conseiller — « comment fonctionne votre détection d'appel, et quelles données sont analysées ? » — est un excellent test. Une banque qui ne sait pas répondre n'a probablement pas un dispositif mature.

Les critères de sécurité que vous pouvez vérifier vous-même

Voici la partie qu'aucun article ne vous donne. Pas de la théorie : des vérifications concrètes, faisables en quelques minutes, sur votre propre téléphone.

Les critères de sécurité que vous pouvez vérifier vous-même
  • Le délai d'expiration de session. Laissez votre appli ouverte, sans rien toucher, pendant cinq à dix minutes. Si elle reste déverrouillée indéfiniment, c'est un mauvais signe. Une session doit se fermer automatiquement.
  • L'authentification forte sur les opérations sensibles. Ajoutez un bénéficiaire, modifiez un plafond, faites un virement inhabituel. Vous devez systématiquement repasser par une validation (biométrie, code, notification push signée). Si l'un de ces gestes passe sans confirmation, alertez votre banque.
  • La cohérence de la notification. Une notification push de validation doit afficher le montant, le bénéficiaire, la date. Une notification qui dit simplement « validez votre opération » sans détail est dangereuse : vous validez à l'aveugle ce qu'un escroc a initié.
  • Le comportement sur appareil modifié. Pas besoin de rooter votre téléphone pour tester. Observez simplement si l'appli affiche un avertissement quand les protections système sont affaiblies.
  • La source de l'installation. Uniquement depuis le Play Store ou l'App Store officiel, jamais depuis un lien reçu par SMS ou courriel — même si le lien a l'air parfaitement légitime.
  • Le nombre de permissions demandées. Une appli bancaire n'a aucune raison légitime d'accéder à vos contacts, à vos photos ou à votre microphone.

Ce dernier point m'a valu une surprise. En inspectant les permissions d'une appli que j'utilisais depuis deux ans, j'ai découvert un accès aux contacts que je n'avais jamais remarqué. Probablement pour un service de virement entre proches. Mais le fait que ce soit activé par défaut m'a dérangé, et je l'ai coupé.

Les vulnérabilités qui visent vraiment les applis bancaires

Oubliez le scénario du hacker qui casse le chiffrement depuis son sous-sol. Voici ce qui arrive réellement.

Les overlays malveillants et les faux écrans

Un logiciel malveillant installé sur le téléphone peut afficher une fenêtre qui ressemble exactement à votre écran de connexion bancaire, par-dessus l'appli réelle. Vous tapez vos identifiants, ils partent ailleurs. La défense contre ce type d'attaque ne repose pas sur vous : c'est à l'appli de détecter qu'un écran se superpose au sien et de refuser de fonctionner. Toutes ne le font pas.

Les services d'accessibilité détournés

Sur Android, les services d'accessibilité sont conçus pour aider les personnes en situation de handicap à naviguer. Détournés, ils permettent à un logiciel de lire l'écran et de cliquer à votre place. Une appli bancaire sérieuse désactive son interface lorsqu'un service d'accessibilité non approuvé est actif. C'est un critère technique précis, et il est rarement mentionné dans les comparatifs grand public.

Le SIM swapping

Votre opérateur est le maillon faible. Un attaquant obtient une copie de votre carte SIM en se faisant passer pour vous auprès du service client. Dès lors, les codes reçus par SMS arrivent chez lui. La parade : privilégier les validations par notification push signée ou par application d'authentification, et éviter autant que possible le SMS comme second facteur. Si votre banque ne propose que le SMS, demandez-lui quelles alternatives existent.

Ce que risque une banque non conforme

Le cadre réglementaire européen est contraignant. L'authentification forte est une exigence de la directive sur les services de paiement, et les autorités de supervision nationale veillent à son application. Les manquements peuvent se traduire par des sanctions financières et des injonctions de mise en conformité. Pour vous, client, la conséquence concrète est ailleurs : en cas de fraude, la charge de la preuve et le remboursement dépendent largement du respect des obligations par la banque. Une banque qui n'a pas déclenché l'authentification forte sur une opération litigieuse est en position difficile.

Trois règles qui couvrent l'essentiel

Après tout ça, je peux résumer ma position en trois points. Et je les assume sans nuance.

  1. Votre appli est probablement la partie la plus solide de la chaîne. Le maillon faible, c'est le téléphone, le réseau, l'opérateur, ou vous.
  2. Ne validez jamais une opération que vous n'avez pas initiée vous-même. Peu importe qui vous appelle, peu importe ce qu'on vous raconte. Le réflexe : raccrocher, rappeler le numéro officiel figurant au dos de votre carte.
  3. Activez toutes les protections disponibles, même celles qui semblent contraignantes. La friction est votre alliée. Trente secondes de vérification valent mieux que trois mois de contestation.

La vraie question n'est pas de savoir si votre application bancaire est sécurisée. Elle l'est, à peu près. La vraie question est : accepteriez-vous de valider un virement de 4 000 euros parce qu'une voix au téléphone vous l'a demandé gentiment ?

C'est là que se joue la sécurité. Pas dans le code.

Clémence Lefèvre

Clémence Lefèvre

Clémence Lefèvre est une développeuse et architecte logicielle reconnue pour son expertise en JavaScript et TypeScript, ainsi qu'en conception de systèmes web robustes. Elle accompagne des équipes techniques dans la mise en place de pratiques DevOps efficaces et dans la modernisation de leurs architectures. Passionnée par la transmission, elle partage régulièrement ses connaissances à travers des formations et des articles techniques.

Voir tous les articles →

Articles similaires