L’open finance ouvre les comptes avant d’ouvrir les recours

La banque ouverte promettait de rendre un compte transportable. L’open finance promet davantage : faire circuler, avec l’autorisation du client, des données de crédit, d’assurance, d’épargne, de placements et de pension entre des institutions et de nouveaux services. L’intelligence artificielle ajoute une promesse supplémentaire. Elle ne se contenterait plus d’agréger ces données ; elle les lirait ensemble, en tirerait des conclusions et proposerait une action.

Le 16 juillet 2026, l’OCDE a consacré un rapport entier à cette rencontre. Le scénario attirant est facile à dessiner. Un service voit plusieurs comptes, détecte une trésorerie disponible, rapproche les dettes, anticipe une dépense et ajuste un plan d’épargne. Pour une petite entreprise, il peut consolider la trésorerie, préparer un dossier de crédit ou signaler un décalage avant qu’il ne devienne une rupture.

Le problème n’est plus seulement de savoir si la donnée a été ouverte. Il faut savoir ce qui a été fabriqué avec elle. Une suite d’opérations ordinaires peut révéler une fragilité financière, un événement familial, un problème de santé, une pratique religieuse ou une difficulté professionnelle sans que ces informations aient jamais figuré comme telles dans le dossier partagé. Le consentement porte sur des tiroirs ; l’IA travaille sur ce qu’elle déduit en les ouvrant ensemble.

L’open finance risque ainsi de donner au client un bouton pour autoriser l’accès sans lui donner encore un chemin lisible pour contester l’inférence. Elle ouvre les comptes avant d’ouvrir les recours.

L’autorisation d’accès n’est pas une autorisation d’interpréter

Le cadre européen envisagé pour l’accès aux données financières, souvent appelé FIDA, part d’une idée saine : le client doit pouvoir choisir s’il partage ses données, avec qui et pour quel but. La Commission européenne prévoit des interfaces standardisées et des outils permettant de gérer les permissions. L’objectif est de dépasser le seul compte de paiement et de rendre le partage plus sûr que les anciennes méthodes de récupération d’écran ou d’identifiants.

Cette architecture répond bien à une question : qui peut lire quelle donnée ? Elle répond moins directement à trois autres : quelle conclusion peut-il en tirer, combien de temps peut-il la conserver et quelle décision peut-il influencer ?

Prenons une demande de crédit professionnel. L’entreprise peut autoriser l’accès à douze mois de transactions pour mesurer la régularité de ses encaissements. Le service découvre aussi des paiements tardifs, des achats récurrents auprès d’un fournisseur sensible et une forte saisonnalité. Un modèle transforme ces observations en variables, puis en score. Si l’accès est ensuite retiré, le flux peut s’arrêter tandis que le score, les variables dérivées et les journaux restent dans plusieurs systèmes.

L’OCDE nomme ce déplacement le function creep : des données légitimement ouvertes pour un but sont progressivement réutilisées pour un autre. Un accès accordé pour agréger des comptes peut nourrir du ciblage commercial. Un dossier préparé pour comparer des assurances peut enrichir une segmentation. Une donnée utilisée pour vérifier la solvabilité peut contribuer à entraîner, ajuster ou évaluer un modèle destiné à d’autres clients.

La difficulté n’est pas créée par une violation spectaculaire. Elle apparaît justement quand chaque étape semble raisonnable prise séparément. C’est la chaîne entière qui finit par dépasser la permission initiale.

OCDE, Artificial intelligence and open finance et Commission européenne, cadre FIDA, vérifiés le 3 août 2026.

Le tableau de consentement s’arrête trop tôt

Un tableau de permissions est nécessaire. Il permet de voir qu’une banque, un assureur ou une fintech dispose encore d’un accès, d’en réduire la portée et de le révoquer. Le Contrôleur européen de la protection des données a demandé que ces interfaces donnent une information complète, exacte et claire sur le prestataire qui sollicite les données et sur le but poursuivi.

Mais un tableau peut devenir une illusion de contrôle s’il s’arrête au bord de l’API. Le client voit une ligne intitulée « analyse budgétaire » et un interrupteur vert. Derrière cette ligne, les données peuvent traverser un agrégateur, un fournisseur de modèle, un outil de détection de fraude, un entrepôt analytique et un service de recommandation. Chacun produit ses propres traces et parfois ses propres variables.

Le contrôle réel devrait distinguer au moins quatre objets :

Objet	Question que le client doit pouvoir résoudre	Preuve minimale
Donnée source	Quelles catégories ont été ouvertes ?	Liste des comptes, périodes et champs consultés
Inférence	Qu’a-t-on conclu sans que je l’aie déclaré ?	Variables dérivées, score, date et modèle utilisés
Usage	Quelle action ou décision cette conclusion peut-elle influencer ?	But autorisé, destinataires et exclusions explicites
Sortie	Que reste-t-il après révocation ?	Accès coupé, rétention, correction, suppression et voie de recours

Cette grille révèle le vrai manque. La révocation technique n’est pas nécessairement une révocation économique. Elle peut empêcher la prochaine lecture tout en laissant une décision déjà automatisée, un segment commercial ou un prix personnalisé continuer à produire ses effets.

Le rapport de l’OCDE reconnaît que la gestion du consentement devient difficile avec des modèles itératifs. Ceux-ci traitent les données à répétition, changent de version et créent de nouveaux artefacts. Redemander une autorisation à chaque opération serait impraticable ; considérer une autorisation ancienne comme illimitée serait tout aussi fragile. Le bon niveau n’est donc ni chaque calcul, ni une case permanente. Il est le but observable : ce que le service cherche à faire, avec quelles catégories, quelles inférences autorisées et quelle conséquence possible.

Refuser de partager peut devenir un signal de risque

L’open finance se présente comme un régime volontaire. Le client peut partager ou non. Pourtant, un choix reste libre seulement si le refus n’est pas lui-même transformé en pénalité cachée.

L’OCDE décrit un risque précis : à mesure que les institutions s’habituent à des profils financiers complets, les personnes qui conservent leurs données pourraient paraître plus incertaines par défaut. Une assurance pourrait exiger un prix supérieur faute de détails. Un prêteur pourrait demander davantage de garanties. Un service pourrait réserver sa meilleure offre aux dossiers les plus faciles à analyser.

Ce mécanisme n’a pas besoin d’une règle écrite contre la vie privée. Il suffit que le modèle apprenne qu’un profil très documenté réduit son incertitude. L’absence de données devient alors une variable indirecte. Le client garde théoriquement son choix, mais paie pour l’exercer.

La promesse d’inclusion devient ambiguë. Des données alternatives peuvent aider une entreprise jeune ou un ménage sans historique de crédit classique. Elles peuvent aussi multiplier les raisons de classer. Une activité irrégulière, un déménagement, une dépense exceptionnelle ou une période de soins peuvent acquérir une signification financière qu’ils n’avaient pas lorsqu’ils étaient séparés.

La Banque des règlements internationaux documente pourtant de vrais bénéfices : réduction des silos, baisse de certaines asymétries d’information, nouveaux entrants et meilleur accès à des services. C’est le contrepoint nécessaire. L’alternative n’est pas entre le secret total et le profilage total. Elle est entre un partage qui rend le client mobile et un partage qui rend le client transparent sans rendre le modèle contestable.

BRI, Opening doors to open finance et CEPD, avis sur FIDA, vérifiés le 3 août 2026.

Plus de données ne rend pas automatiquement le modèle plus juste

Le récit technique affirme souvent qu’un grand jeu de données diversifié réduit les biais. C’est possible. Des informations plus complètes peuvent éviter qu’un modèle confonde un dossier incomplet avec un mauvais dossier. Elles peuvent aussi aider à tester si une décision tient pour différents secteurs, âges d’entreprise ou formes de revenus.

Mais la quantité ne corrige pas la finalité. Un historique plus riche peut reproduire avec davantage de précision les exclusions passées. Si certains groupes ont reçu moins de crédit, payé plus cher leur assurance ou connu des carrières plus discontinues, leurs données ne deviennent pas neutres parce qu’elles sont standardisées.

L’IA sait également reconstruire des caractéristiques que le service n’avait pas le droit ou pas l’intention de demander directement. Des lieux, des rythmes de dépense, des commerçants ou des variations de revenu peuvent servir de proxys. Le rapport de l’OCDE alerte sur les inférences liées, entre autres, au genre ou à l’origine, puis sur leur possible traduction en prix, refus ou exclusion.

La question de conformité « avons-nous collecté cette caractéristique ? » devient insuffisante. Il faut demander « notre modèle peut-il la déduire et son résultat varie-t-il à cause d’elle ou d’un proxy ? » Cela exige des tests de résultats, pas seulement une inspection de la liste des champs.

La BRI formule la même tension dans ses travaux de 2026 sur les données utilisées par l’IA financière. Les risques classiques de qualité, de confidentialité et de sécurité sont amplifiés par les dépendances envers des tiers et par la concentration des fournisseurs. Une banque peut bien gouverner son entrepôt interne et perdre de la visibilité dès qu’un modèle, un cloud ou une brique spécialisée intervient entre la donnée et la décision.

L’agent financier ne doit pas hériter d’un consentement général

Le scénario le plus avancé étudié par l’OCDE est celui d’un agent capable d’observer en continu plusieurs sources et d’agir. Il pourrait déplacer un excédent, rembourser une dette, adapter un portefeuille ou anticiper un besoin de crédit. Le rapport précise que ce scénario reste théorique et que les systèmes pleinement autonomes n’ont pas encore la fiabilité nécessaire à la plupart des usages réels en finance.

Cette prudence est essentielle. Un agrégateur lit. Un agent peut lire, conclure et exécuter. Si les trois capacités héritent d’un même consentement général, l’autorisation change de nature sans changer d’écran.

« Optimiser ma trésorerie » n’est pas un mandat. C’est un objectif dont plusieurs interprétations peuvent entrer en conflit : préserver la liquidité, réduire les intérêts, payer plus vite, conserver une réserve fiscale ou saisir une remise fournisseur. Un agent peut poursuivre correctement l’une de ces mesures tout en détériorant les autres.

Avant toute exécution, le mandat devrait nommer les comptes, plafonds, horaires, contreparties et situations d’arrêt. Il devrait séparer la recommandation de l’action. Il devrait surtout empêcher qu’une permission de lecture devienne, par commodité, une permission de transfert.

Pour une PME, le test n’a pas besoin d’un grand pilote. Un dossier synthétique suffit : trois comptes, deux factures, une ligne de crédit, un paiement inhabituel et une règle de trésorerie. On retire ensuite l’accès à l’un des comptes. Le service doit montrer que la lecture cesse, que les prévisions signalent la donnée manquante, que l’agent ne compense pas en inventant, qu’aucun transfert n’est exécuté et qu’un humain peut corriger la décision.

Ce test mesure davantage que la qualité d’une recommandation. Il mesure la capacité du système à perdre proprement un droit.

Un registre d’inférences avant un nouveau tableau de bord

La réponse habituelle à un problème de données est un tableau de bord supplémentaire. L’open finance a besoin d’un objet plus austère : un registre d’inférences.

Pour chaque usage important, il relierait la donnée source, la variable dérivée, le modèle, la version, le but, la décision influencée et la durée de conservation. Il indiquerait aussi si l’inférence peut être corrigée, supprimée ou recalculée après une révocation. Ce registre n’a pas vocation à exposer le secret industriel d’un modèle. Il doit rendre visible la chaîne qui affecte le client.

Une organisation peut commencer avec six colonnes :

1. Permission : quelles données et quelle période ont été ouvertes ?
2. Transformation : quelles variables ou catégories ont été produites ?
3. Décision : quel prix, refus, conseil ou mouvement peut en dépendre ?
4. Responsable : quelle entité répond du résultat, y compris lorsqu’un tiers fournit le modèle ?
5. Fin : que se passe-t-il à l’expiration ou à la révocation ?
6. Recours : qui peut expliquer, corriger et suspendre l’effet ?

Le rapport de l’OCDE sur le marché financier italien apporte ici une nuance utile. Des interfaces standardisées, des taxonomies communes et des cycles de consentement auditables peuvent réduire la dépendance à des passerelles propriétaires et rendre les modèles plus comparables. L’interopérabilité n’est donc pas seulement une ouverture des données ; elle peut aussi devenir une infrastructure de contrôle.

À une condition : standardiser les preuves aussi sérieusement que les API. Si les institutions échangent des champs communs mais gardent des journaux incompatibles, la donnée circule plus vite que la responsabilité.

BRI, In data we trust? et OCDE, Artificial Intelligence in Italian Financial Markets, vérifiés le 3 août 2026.

Ce qu’il faut laisser reposer

Le mot « ouvert » décrit mal le sujet. Les données financières ne deviennent ni publiques ni libres ; elles deviennent transportables sous conditions. L’enjeu n’est pas d’ouvrir davantage, mais de rendre chaque ouverture réversible et chaque conséquence contestable.

L’IA déplace le centre du contrôle. Autrefois, on vérifiait qui possédait le dossier. Désormais, il faut aussi suivre qui fabrique le profil, qui transforme ce profil en décision et qui sait défaire cette décision lorsque la permission disparaît ou que l’inférence est fausse.

Un bouton de consentement sans registre d’inférences protège surtout l’interface. Un droit de révocation sans effet sur les scores protège surtout le futur accès. Un recours sans personne capable de relier la donnée au résultat protège surtout l’institution.

L’open finance peut rendre les clients plus mobiles et les marchés moins fermés. Mais elle ne méritera son nom que lorsque l’ouverture fonctionnera dans les deux sens : ouvrir les données pour obtenir un service, puis ouvrir la décision pour comprendre, corriger et, si nécessaire, reprendre ses tiroirs.