La comptabilité personnelle de Sumner Evans est passée par Mint, Rocket Money, des fichiers Markdown, Origin, puis un format qui ressemble presque à un retour en arrière : des lignes de texte dans Git.1
Sauf que le retour en arrière est trompeur.
Le plain text accounting ne consiste pas à remplacer un logiciel de comptabilité par Notepad. Le terme désigne une famille de pratiques où le journal reste un fichier texte lisible, tandis que des programmes comme Ledger, hledger ou Beancount se chargent des contrôles, imports et rapports.2
Evans a choisi hledger. Son argument le plus intéressant n’est d’ailleurs pas la nostalgie du terminal : après des connexions bancaires peu fiables et plusieurs limites de logiciels grand public, il voulait surtout comprendre ses flux et apprendre la double entrée.1
Nous avons donc essayé de casser le modèle, avec hledger 1.52.1, un faux compte bancaire et quelques euros imaginaires.
Quatre couches
Un journal hledger peut être extrêmement banal :
2026-08-08 * Hosting
expenses:hosting 24.00 EUR
assets:bank -24.00 EUR
Deux lignes disent où la valeur apparaît et d’où elle vient. Leur somme vaut zéro. hledger lit le fichier et refuse une transaction explicitement déséquilibrée.3
Mais cette petite scène contient déjà quatre systèmes distincts.
Le journal répond à « qu’avons-nous enregistré ? ». hledger répond à « est-ce cohérent avec les règles que nous lui avons données ? ». Git répond à « qu’est-ce qui a changé et quand ? ». Puis viennent les éléments qui n’entrent pas magiquement dans ces trois couches : relevés, factures, justificatifs, échanges bancaires, obligations fiscales ou processus d’équipe.
Le texte brut n’a rien supprimé. Il a seulement arrêté de tout cacher derrière la même interface.
Un euro
Premier test : nous partons d’un journal équilibré avec 1 500 EUR sur le compte bancaire à la fin du mois. Une assertion indique explicitement que ce solde doit correspondre au relevé :
assets:bank 0.00 EUR = 1500.00 EUR
Nous changeons ensuite une dépense d’hébergement de 24 à 25 EUR sur une seule ligne, sans modifier le compte bancaire en face.
hledger check s’arrête immédiatement : la transaction somme désormais à +1 EUR.
Rien de spectaculaire. C’est précisément la qualité recherchée : une erreur structurelle devient impossible à ignorer.
Puis nous faisons quelque chose de plus réaliste et plus gênant. Nous remplaçons 24 par 25 des deux côtés.
La transaction reste parfaitement équilibrée.
La double entrée n’a aucun moyen de savoir si notre hébergeur a facturé 24 ou 25 EUR. Elle sait seulement que ce que nous avons écrit est cohérent avec lui-même.
L’assertion de fin de mois, elle, compare le résultat à une information extérieure. hledger calcule 1 499 EUR alors que nous avons déclaré en attendre 1 500, et refuse le journal.3
Ce test résume peut-être tout le sujet : une règle comptable vérifie ce qu’elle est capable de connaître, pas la réalité entière.
Le diff
Le même faux changement produit aussi un diff presque absurdement lisible :
- expenses:hosting 24.00 EUR - assets:bank -24.00 EUR + expenses:hosting 25.00 EUR + assets:bank -25.00 EUR
À cet instant, Git devient autre chose qu’un gadget de développeur collé aux finances.
Dans une base opaque, « le solde a changé » peut demander une interface d’audit dédiée. Dans ce journal, la modification est une paire de lignes. Le commit peut porter une explication, le diff peut être relu et un état antérieur peut être comparé.
Evans utilise lui aussi un dépôt Git pour ses données financières ; le portail Plain Text Accounting présente plus généralement les fichiers lisibles et contrôlables en version comme une caractéristique centrale de cette famille d’outils.12
Cela ne signifie pas que Git transforme une comptabilité personnelle en système d’audit réglementaire. Il donne simplement une histoire technique très compréhensible des fichiers.
Export sans prison
Nous avons ensuite demandé à hledger de ressortir le journal en CSV :
hledger -f journal.journal print -O csv
La version 1.52.1 testée produit directement des lignes contenant date, description, compte, montant, commodity, débit et crédit. Le manuel documente également les lectures CSV et les fichiers de règles utilisés pour convertir des exports bancaires en écritures.3
Ce détail est moins glamour qu’une interface avec graphiques, mais il touche à une propriété importante : le fichier source n’est pas le seul moyen de récupérer ses données.
La source reste inspectable à la main ; hledger peut en fabriquer d’autres représentations. Le jour où un graphique, un notebook ou un tableur devient plus pratique, les données ne doivent pas être ressaisies à la souris, activité que notre espèce continue curieusement à considérer comme du travail.
Deux humains
Git devient moins gracieux dès que deux personnes écrivent au même endroit.
Nous avons créé deux branches depuis le même journal. Alice ajoute une dépense de voyage à la fin du fichier ; Bob ajoute une dépense de repas, lui aussi à la fin.
Au merge : conflit de contenu.
Les deux transactions sont valides. Git ne sait simplement pas dans quel ordre assembler deux modifications concurrentes faites au même emplacement.
Nous avons rejoué exactement le test avec un fichier principal contenant :
include journals/*.journal
Alice écrit journals/alice.journal, Bob journals/bob.journal. Le merge est automatique, puis hledger check valide le journal composé.
Ce n’est pas une preuve que « plusieurs fichiers règlent la collaboration ». Deux personnes peuvent évidemment modifier le même fichier séparé et retrouver le conflit. Il s’agit seulement d’un levier architectural très concret : réduire la surface commune réduit certaines collisions Git.
À mesure que l’équipe grandit, arrivent ensuite permissions, revues, verrouillage éventuel, conventions de classement, rapprochement concurrent et contrôle des modifications. À ce stade, une interface métier spécialisée peut redevenir nettement plus agréable que demander au service comptable de résoudre des marqueurs <<<<<<<.
Le secret revient
Le test le plus important n’a rien à voir avec la double entrée.
Nous avons ajouté dans le journal une fausse donnée sensible :
TEST-ACCOUNT-1234
Commit. Puis suppression de la ligne. Nouveau commit.
La chaîne disparaît du fichier actuel. Elle reste pourtant lisible avec git show sur le commit précédent.
C’est le comportement normal d’un système d’historique, mais il inverse brutalement une intuition courante : Git améliore la traçabilité précisément parce qu’il rend l’oubli plus difficile.
GitHub consacre d’ailleurs une procédure au retrait d’informations sensibles déjà entrées dans l’historique et recommande de révoquer ou faire tourner immédiatement les secrets exposés avant même de réécrire les commits.5
Une comptabilité contient rarement seulement des catégories inoffensives : noms, comptes, références de paiements, commentaires, revenus ou fournisseurs peuvent être confidentiels suivant l’usage. Un dépôt privé ne suffit donc pas, à lui seul, comme stratégie de sécurité.
Pas les factures
Le ledger décrit très bien les événements comptables ; une facture PDF appartient à une autre couche.
On peut évidemment ajouter dans une note un chemin vers un justificatif, organiser un dossier adjacent ou construire une convention. L’écosystème PTA répertorie d’ailleurs une multitude d’outils autour de la facturation, de l’import, du reporting et des interfaces.2
Mais c’est justement le point : ces capacités sont autour du journal.
Le journal texte ne garantit pas qu’une facture possède les mentions exigées dans votre pays, qu’un justificatif soit archivé selon la bonne durée, qu’une déclaration fiscale soit correcte ou qu’une connexion bancaire ait été rapprochée. Les obligations dépendent du lieu, de l’activité et du workflow choisi.
Pour une entreprise, « mes écritures sont dans Git » n’est donc pas synonyme de « mon système comptable est complet ».
Complexité visible
Le billet d’Evans montre aussi que la simplicité du fichier survit à des situations assez riches : plusieurs moyens de paiement dans une même transaction, actions et prix de marché, transferts entre comptes, remboursements professionnels, assertions de solde et journaux multiples.1
C’est une qualité remarquable. Les lignes restent des lignes alors que le modèle devient plus sophistiqué.
Mais la courbe d’apprentissage se déplace vers la comptabilité elle-même. Savoir si un remboursement est une dépense négative, une créance ou autre chose n’est pas un problème de syntaxe hledger. Comprendre coût d’acquisition, lots, gains, devises ou comptes de transition demande de comprendre le modèle que le texte expose.
hledger 1.52 a justement continué à travailler des fonctions comme les annotations de coût et leur export ; en parallèle, le projet publiait déjà des préversions de sa future branche 2.0.4
Le fichier reste simple. Ce qu’il décrit n’a aucune obligation de l’être.
Comprendre
Voilà pourquoi le plain text accounting est plus intéressant comme outil de compréhension que comme geste rétro.
Une application financière classique cherche souvent à faire disparaître la mécanique. C’est généralement confortable : connecter une banque, reconnaître un marchand, afficher un camembert, laisser l’utilisateur corriger les exceptions.
Le journal texte fait l’inverse. Il vous oblige à nommer les comptes, à voir les deux côtés du mouvement et à décider où ranger une ambiguïté. hledger automatise la vérification et les rapports sans cacher la source.13
Beancount suit une philosophie voisine avec son propre langage de double entrée, autre signe que l’idée dépasse largement un programme particulier.6
Pour quelqu’un qui veut apprendre ce que son argent fait, cette friction peut être la fonction principale.
Où ça marche
Notre petit laboratoire ne peut évidemment pas décider pour une entreprise de 200 personnes. Il dessine plutôt une frontière pratique.
Le modèle est particulièrement séduisant lorsque :
- une ou quelques personnes techniquement à l’aise tiennent les comptes ;
- la lisibilité et la propriété des données importent beaucoup ;
- des imports ou scripts maison doivent rester possibles ;
- l’historique Git apporte réellement quelque chose ;
- on accepte de construire ou choisir séparément le workflow des pièces et obligations externes.
Il devient moins évident quand l’interface doit empêcher les utilisateurs de connaître Git, quand des dizaines de personnes modifient les mêmes livres, ou lorsque le produit attendu comprend dès le départ validation métier, documents, droits fins, automatisations bancaires et conformité locale.
Le texte brut n’échoue pas pour autant : on atteint simplement la frontière où la représentation des écritures ne suffit plus à constituer le produit entier.
Les ennuis
Après le test, la promesse la plus forte n’est finalement pas « votre comptabilité tient dans un .journal ».
C’est plutôt : vous pouvez voir où chaque garantie commence et où elle s’arrête.
La double entrée attrape notre première faute de 1 EUR. L’assertion attrape la seconde. Git montre le diff. Le découpage en fichiers change le comportement du merge. Git conserve aussi le faux secret que nous pensions avoir supprimé. Le CSV ressort sans négociation avec une API propriétaire.
Le texte brut n’est donc pas magique, et tant mieux.
Il est intéressant parce qu’il laisse les mécanismes suffisamment exposés pour qu’on puisse les comprendre, les tester et même les voir échouer.