Depuis un fichier
Réglages → Données → Vos données → Importer un fichier sert à restaurer une sauvegarde, et c’est aussi la seule façon d’importer en masse sans clé API ni client MCP. Ce bouton lit un fichier JSON au format produit par Exporter vos données, et fusionne son contenu dans le compte avec lequel vous êtes connecté. Le fichier n’a pas besoin de venir d’un export : un fichier écrit à la main, ou converti par un script à partir de ce que fournit votre banque ou d’un tableur, est importé de la même façon.
Seule la version du fichier est contrôlée. Son contenu est écrit tel quel : c’est donc à vous de respecter le format décrit ci-dessous, et c’est le compte rendu affiché ensuite qui vous dira ce qui a été pris en compte et ce qui ne l’a pas été.
Les limites
Section intitulée « Les limites »- Version. Le fichier contient un champ
schemaVersion, et cette version de Badlen accepte1,2,3et4. Un export récent indique4, et un fichier que vous écrivez doit indiquer4lui aussi. Un fichier sans version, ou avec une autre, est refusé en bloc, sans rien écrire. - Taille. 25 Mo au plus. Au-delà, la page refuse le fichier avant même de le lire, et l’API refuse de même une requête plus lourde ; un export de plusieurs années d’opérations reste très en dessous.
- Montants. Les montants, quantités et prix s’écrivent sous forme de chaîne décimale,
"1234.56", jamais de nombre JSON. Un fichier qui en contient un est refusé avant qu’une seule ligne soit écrite, car un nombre JSON a déjà perdu des décimales au moment où on le lit. - Chiffrement. Un export scellé demande d’abord sa phrase de passe. Un fichier que vous écrivez vous-même est en clair.
Le format du fichier
Section intitulée « Le format du fichier »Un fichier contient un seul objet. Tout est facultatif sauf la version, et une clé absente signifie « rien à signaler », jamais « supprimer l’existant ». Le plus petit fichier utile contient un compte, son solde et une opération :
{ "schemaVersion": 4, "accounts": [ { "name": "Compte joint", "type": "checking", "currency": "EUR", "manualBalances": [{ "date": "2026-09-30", "balance": "2140.18", "currency": "EUR" }], "transactions": [ { "date": "2026-09-28", "amount": "-64.90", "currency": "EUR", "label": "Courses" } ] } ]}Un compte exige un name et un type ; s’il lui manque l’un des deux, il est écarté et
signalé dans le compte rendu. Le type doit être l’un des onze que connaît l’application : checking, savings,
cto, pea, av, crypto_wallet, crowdlending, real_estate, loan, object et other.
La restauration ne le vérifie pas : un compte avec un autre mot est créé quand même, et
valorisé comme autre. Recopiez-le donc à l’identique.
Dans un compte :
| Clé | Chaque entrée |
|---|---|
manualBalances |
un solde à une date : date, balance, currency |
transactions |
une opération : date, amount (négatif pour l’argent qui sort), label, currency |
holdings |
une ligne détenue : un asset (son kind, son isin ou son ticker, son name) et une quantity |
trades |
un ordre daté : l’asset de sa ligne, date, side (buy ou sell), quantity, unitPrice, amount, currency |
Écrivez toutes les clés citées dans le tableau. Un ordre sans currency, par exemple, n’est
pas reconnu lors d’un second import, et il est écrit une deuxième fois.
Les dates s’écrivent YYYY-MM-DD. Une opération peut aussi avoir un fee, un tax, une
note et un categoryName, qui la classe dans la catégorie de ce nom si elle existe chez
vous. Une opération sans catégorie arrive sans classement, et Recatégoriser, dans
Réglages → Catégories, la classe selon vos règles. Pour voir toutes les autres clés et leur
orthographe exacte, le plus rapide est d’exporter votre propre compte et d’ouvrir le
fichier : l’export en clair se lit sans peine dans un éditeur de texte.
Rapproché, jamais écrit deux fois
Section intitulée « Rapproché, jamais écrit deux fois »La restauration fusionne. Elle ne vide jamais une table au préalable, et rapproche chaque ligne lue de l’existant à partir d’une clé naturelle, jamais d’un identifiant de base :
| Ligne | Rapprochée par | Si elle existe déjà |
|---|---|---|
| Un compte | son nom et son type, puis son établissement si deux sont à égalité | mis à jour avec celui du fichier |
| Un solde | son compte et son jour | remplacé par celui du fichier |
| Une opération | son empreinte : date, montant et libellé en minuscules | laissée telle quelle |
| Une ligne | son compte et son actif (ISIN, sinon ticker) | mise à jour avec celle du fichier |
| Un ordre daté | chacun de ses chiffres | compté, pas réécrit |
| Une catégorie | son nom et son parent | laissée telle quelle |
| Un cours | son actif et son jour | laissé tel quel |
Importé une deuxième fois, le même fichier donne donc un compte rendu à zéro, et un fichier renvoyé après correction d’un chiffre ne modifie que ce chiffre. On peut ainsi retravailler sans risque un fichier converti : l’importer, lire le compte rendu, corriger le fichier, l’importer de nouveau.
Une opération sans empreinte propre reçoit celle que lui attribuerait la route
d’import : un mois importé
depuis un fichier puis renvoyé par votre assistant n’est donc pas écrit deux fois. Cette
règle a un revers à l’intérieur d’un même fichier : deux opérations identiques le même jour
fusionnent en une seule, et le compte rendu signale celle qui a été écartée. Pour garder les
deux, donnez à chacune son propre dedupHash, n’importe quel texte différent ; c’est ce que
fait l’export pour une opération saisie à la main.
Fusionner veut aussi dire qu’un fichier ne supprime jamais rien. Une ligne absente du fichier reste dans votre compte, et une opération ne se supprime qu’à un seul endroit : depuis son propre onglet.
Quand c’est une sauvegarde
Section intitulée « Quand c’est une sauvegarde »Pour réinstaller un export après un incident, ou reprendre une restauration interrompue, voyez le versant exploitation de ce bouton : Restaurer un export.