Aller au contenu

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é.

  • Version. Le fichier contient un champ schemaVersion, et cette version de Badlen accepte 1, 2, 3 et 4. Un export récent indique 4, et un fichier que vous écrivez doit indiquer 4 lui 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.

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.

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.

Pour réinstaller un export après un incident, ou reprendre une restauration interrompue, voyez le versant exploitation de ce bouton : Restaurer un export.