Ce que votre appli de budget voit quand elle se connecte à votre banque
Vous installez une appli de budget. Deuxième écran : « Connectez votre banque ». Vous choisissez la vôtre, vous vous authentifiez, et trente secondes plus tard toutes vos transactions sont là, catégorisées.
C’est un excellent produit. La question n’est pas de savoir si c’est pratique — ça l’est — mais ce qui a été transmis, à qui, et pour combien de temps. Peu de gens le savent, et l’écran de consentement ne le dit pas vraiment.
D’abord, la bonne nouvelle
Avant la DSP2, ces connexions fonctionnaient par screen scraping : vous donniez vos identifiants bancaires à un tiers, qui se connectait à votre place en se faisant passer pour vous. C’était aussi mauvais que ça en a l’air.
La DSP2 a mis fin à ce modèle. Aujourd’hui, en Europe, l’agrégation passe par des API bancaires et des acteurs agréés — les prestataires de services d’information sur les comptes (AISP), supervisés en France par l’ACPR. Vous vous authentifiez chez votre banque, pas chez le tiers. Il ne voit jamais votre mot de passe.
C’est une vraie amélioration, et il faut la dire avant tout le reste.
Ce qui est transmis, en revanche
L’agrégateur ne reçoit pas votre mot de passe. Il reçoit vos données.
Concrètement, pour chaque compte connecté : le solde, l’IBAN, le type de compte, et l’historique des transactions — date, montant, et libellé. Les fournisseurs du marché annoncent un historique de trois mois minimum, et jusqu’à vingt-quatre mois selon la banque.
Deux ans de relevés. Prenez une seconde pour vous représenter ce que contiennent les vôtres.
Le libellé, pas le montant
C’est le point que presque tout le monde manque.
Un montant tout seul ne dit rien : « 34,90 € » n’est pas une information. Le libellé, lui, nomme le commerçant. Et la liste des commerçants chez qui vous payez raconte votre vie avec une précision qu’aucun questionnaire n’obtiendrait :
- une pharmacie tous les mois, un laboratoire d’analyses, un hôpital ;
- un cabinet d’avocats, un notaire, une agence matrimoniale ;
- une cotisation syndicale, un don à un parti, une association cultuelle ;
- un site de paris, un débit de tabac ;
- des billets de train récurrents vers une même ville, un lundi matin sur deux.
Le RGPD protège plus strictement certaines catégories — santé, opinions politiques, appartenance syndicale, orientation sexuelle. Un relevé bancaire n’est pas juridiquement une donnée de santé. Mais une ligne « Pharmacie du Centre » tous les 28 jours en est un indice fiable, et c’est bien pour ça que la question mérite mieux qu’un haussement d’épaules.
Combien de temps, et sans que vous y pensiez
Depuis la révision des normes techniques de la DSP2, une connexion d’agrégation reste active 180 jours avant de vous redemander une authentification forte — contre 90 auparavant. L’objectif était légitime : les ré-authentifications trop fréquentes cassaient les services.
L’effet de bord l’est tout autant : deux fois par an, c’est peu de rappels qu’un tiers lit vos comptes en continu. Une connexion mise en place un dimanche de janvier « pour essayer » est encore vivante en juin, et vous n’y avez plus pensé depuis.
Ce que ça ne veut pas dire
Il faut être précis, sinon on bascule dans le fantasme.
Les agrégateurs européens sont des acteurs régulés, agréés et supervisés. Ils n’ont pas le droit d’utiliser vos données à d’autres fins que le service consenti, et le RGPD s’applique intégralement. Beaucoup travaillent d’ailleurs en marque blanche : l’appli que vous utilisez n’est souvent pas celle qui détient l’agrément.
Le risque n’est pas qu’on vende votre relevé. Le risque, c’est la surface. Vos données existent en clair, chez un acteur de plus, dans une base de plus, accessibles à un nombre non nul d’employés et à quiconque obtiendrait cet accès. Aucune régulation n’empêche une fuite ; elle organise ce qui se passe après.
Et cette surface, vous ne la choisissez pas vraiment : elle est la condition même du service. Un agrégateur qui ne lirait pas vos transactions ne servirait à rien.
L’autre modèle : ne jamais recevoir la donnée
Il existe une manière de poser le problème différemment : faire en sorte que le serveur ne puisse pas lire, quoi qu’il arrive.
C’est le principe du chiffrement de bout en bout. Votre budget est chiffré sur votre appareil, avec une clé dérivée de votre phrase secrète, avant tout envoi. Le serveur ne stocke que des octets illisibles. Une fuite de la base ne donne rien d’exploitable, et l’éditeur — nous — ne peut pas davantage lire votre budget qu’un attaquant.
C’est le choix qu’Arca a fait, et c’est aussi pour ça qu’Arca ne se connecte pas à votre banque : on ne peut pas à la fois recevoir vos transactions en clair pour les catégoriser et prétendre ne rien pouvoir lire. Il faut choisir.
Ce que ce choix coûte
Soyons francs, parce qu’un article sur la confidentialité qui tairait le prix de sa propre position ne vaudrait rien.
Sans connexion bancaire, vos transactions arrivent à la main ou par import CSV depuis l’export de votre banque. Concrètement :
- il faut y passer quelques minutes par semaine, ou importer un fichier par mois ;
- rien n’apparaît tout seul, il n’y a pas de notification « vous venez de dépenser 12 € » ;
- le rapprochement avec le solde réel du compte est un geste que vous faites, pas un état de fait.
Pour beaucoup de gens, c’est rédhibitoire, et c’est un arbitrage parfaitement raisonnable. Pour d’autres, la saisie est précisément ce qui fait fonctionner le budget — on ne dépense pas de la même façon quand on doit écrire la dépense.
Ce que nous refusons, c’est de faire croire que l’un est gratuit. Les deux modèles ont un coût : l’un se paie en exposition, l’autre en minutes.
Pour aller plus loin
- La méthode elle-même : la méthode des enveloppes appliquée à un vrai budget.
- Comment le chiffrement fonctionne chez nous, en détail : documentation — chiffrement de bout en bout.
Sources
- Autorité bancaire européenne — modification des normes techniques sur l’authentification forte (passage à 180 jours).
- Powens — API de données de transactions (profondeur d’historique).