Une couche de mémoire déterministe pour les données financières, construite pour que des agents IA probabilistes puissent l'interroger et raisonner dessus de façon fiable. Pas un simple historique de conversation. Un registre structuré et réconcilié de ce qui s'est réellement passé dans les relevés.
La mémoire, au sens où ChatGPT et Claude l'entendent, est ce qu'un agent IA conversationnel retient de vous d'une session à l'autre : vos préférences, vos demandes passées, le contexte qu'il doit reporter. La mémoire financière étend cette même idée aux registres financiers : un endroit où la mémoire qu'un agent a de vos finances est aussi durable et interrogeable que sa mémoire de la conversation.
La différence tient à l'origine de la mémoire. Une couche de mémoire dérivée de la conversation retient ce qui a été dit. La mémoire financière est déterministe parce qu'elle est dérivée de documents et vérifiée par réconciliation : chaque fait remonte à une page précise d'un relevé bancaire précis, et chaque solde est vérifié avant d'être considéré comme fiable. Un agent IA qui raisonne dessus ne raisonne pas sur un résumé que quelqu'un a tapé une fois. Il raisonne sur les documents source eux-mêmes, structurés et vérifiés.
Le plan n'a jamais été de simplement convertir des relevés bancaires
Au départ, je pensais que Bankstatemently deviendrait une entreprise de Vision Financière. Ces derniers mois, j'ai conclu que c'était trop étroit. La vision n'est qu'une partie du problème. Voir est important, oui. Mais ce qui vient ensuite, c'est la compréhension : interpréter à travers un modèle cohérent de la réalité. C'est, à mon avis, encore de loin la partie la plus difficile pour rendre exploitables les données de documents financiers.
Les modèles d'IA deviennent de meilleurs yeux. L'époque où l'on se débattait avec une précision OCR de 90 % est largement révolue, et l'extraction de données depuis des relevés financiers ne cesse de s'améliorer. Mais ce avec quoi l'IA a encore du mal, c'est de construire une représentation cohérente des données financières, surtout quand le monde réel est plein d'incohérences, d'ambiguïtés et de formats de documents différents.
C'est pourquoi je commence à penser l'avenir de Bankstatemently comme une Mémoire Financière. Un endroit où les données financières vivent dans un modèle unique, cohérent et structuré. Une couche de mémoire déterministe, facile à interroger et sur laquelle raisonner pour des agents IA probabilistes.
Si cette couche de mémoire existe, peu importe que le raisonnement vienne de ChatGPT, de Claude ou d'un modèle open source
Un agent IA chargé aujourd'hui de raisonner sur un PDF de relevé bancaire doit le relire et le réinterpréter à chaque fois, depuis zéro, sans aucune garantie qu'il lira deux fois le même relevé de la même façon. La mémoire financière inverse ce schéma : le relevé est analysé une seule fois dans un modèle structuré et vérifié — transactions, soldes, comptes, dates — et chaque agent qui l'interroge ensuite obtient la même réponse déterministe.
Cette structure est ce qui rend les données financières exploitables par un agent, et non simplement visibles pour lui. Un modèle de langage peut décrire un PDF. Il ne peut pas, seul, garantir que chaque transaction de chaque page a été capturée, ni qu'un solde courant s'est correctement reporté d'un relevé à l'autre. La couche de mémoire effectue cette vérification une fois, en amont, afin qu'un agent qui l'interroge ensuite raisonne sur des faits vérifiés, et non sur une nouvelle supposition.
Vous devriez pouvoir poser une question en langage naturel et obtenir une réponse avec la précision d'un comptable. Cette confiance se brise dès qu'une couche de mémoire peut silencieusement perdre une transaction. Une couche canonique construite à la main qui fusionne des faits en comparant montant et date, par exemple, peut fondre en une seule ligne deux frais identiques du même mois, et rien en aval ne le signale jamais : le total est simplement faux.
La mémoire financière ici est construite autour de la réconciliation de continuité des soldes : chaque transaction d'un relevé doit expliquer le passage du solde d'ouverture au solde de clôture, page par page. Une transaction manquante, ou une fusion ayant fait disparaître un doublon, rompt cette chaîne et produit un échec de réconciliation bien visible, jamais un total silencieusement faux. La complétude n'est pas supposée. Elle est prouvée, relevé par relevé, avant qu'un agent ne puisse interroger les données.
Une couche de mémoire qui semble toujours confiante est plus dangereuse qu'une qui admet ses lacunes. Quand une requête touche une période de relevé qui n'a pas encore été réconciliée, ou un document qui n'a pas encore été capturé, la réponse le dit au lieu de répondre silencieusement à partir de ce qui se trouve être disponible. L'honnêteté de couverture fait partie de la réponse elle-même, pas un ajout après coup.
Chaque fait qu'un agent reçoit porte une provenance jusqu'à la page exacte du relevé exact d'où il vient, afin qu'une affirmation puisse toujours être vérifiée par rapport à la source plutôt qu'acceptée sur parole. Et la même question, posée deux fois, renvoie la même réponse : pas de reclassement, pas de re-résumé, pas de dérive d'une session à l'autre.
L'API REST renvoie du JSON structuré : transactions, métadonnées de compte et soldes, résolus par le même pipeline déterministe utilisé partout ailleurs sur le site. Tout framework d'agent capable d'appeler un point de terminaison HTTP peut appeler celui-ci — sans logique d'analyse de PDF à construire soi-même. Voir la référence complète sur /developers/api.
Le serveur Model Context Protocol expose la même couche de mémoire comme un ensemble d'outils qu'un agent peut appeler directement : convertir un relevé, lister les relevés, en récupérer un précis, obtenir les crédits d'un compte. C'est le moyen le plus rapide de donner à Claude, ChatGPT, Codex, Cursor ou à un framework d'agent personnalisé un accès aux données de relevés bancaires sans construire une intégration à la main. Voir /developers/mcp pour la configuration.
Connectez le serveur MCP, téléversez un relevé (ou pointez l'agent vers un relevé), et posez une question en langage naturel : « Quelle était ma dépense mensuelle moyenne en abonnements logiciels ? » ou « Liste chaque transfert supérieur à 2 000 € au dernier trimestre. » L'agent raisonne sur des données structurées et réconciliées au lieu d'essayer de lire le PDF lui-même, ce qui fait toute la différence entre une réponse à laquelle vous pouvez faire confiance et une réponse que vous devez vérifier vous-même.
Les agents de comptabilité construits sur un LLM héritent de la même faiblesse que tout LLM face aux documents source : ils résument au lieu de capturer de façon exhaustive. Une couche de mémoire financière donne à ces agents un grand livre déterministe sur lequel se réconcilier : chaque transaction de chaque page, recoupée pour la continuité des soldes, afin qu'un flux de comptabilité automatisé ne fasse pas silencieusement disparaître des lignes qu'il n'a jamais correctement lues au départ.
Connectez-vous via MCP en quelques minutes, ou essayez directement l'API.