Abstract teal and amber illustration of a ledger grid, rising budget chart, and piggy bank shapes with a server silhouette, representing a self-hosted double-entry personal finance manager

Firefly III

Firefly III

Firefly III est un gestionnaire de finances personnelles gratuit et auto-hébergé, construit autour d’une vraie comptabilité en partie double, et non d’un simple traqueur de dépenses simplifié. Budgets, catégories, tags, transactions pilotées par des règles, comptes multi-devises : une API REST JSON couvre presque toutes les fonctions de l’application. Le tout tourne entièrement sur du matériel que vous contrôlez et ne contacte jamais de serveur externe sauf demande explicite de votre part. C’est l’argument central pour quiconque est mal à l’aise à l’idée d’envoyer ses relevés bancaires vers une appli de budget dans le cloud.

À retenir : Firefly III est open source sous licence GNU Affero General Public License v3 (AGPL-3.0), confirmée par le fichier LICENSE du dépôt GitHub et son badge de licence. La dernière version stable est la v6.6.3, avec plus de 23 000 étoiles sur GitHub. L’image officielle est fireflyiii/core sur Docker Hub, et le projet est développé principalement par James Cole (JC5), originaire de l’Union européenne et toujours basé là-bas.

Qu’est-ce que Firefly III ?

La plupart des applis de budget se contentent d’afficher un solde cumulé de ce qui rentre et de ce qui sort. Firefly III fait ça aussi, mais en dessous, elle utilise la comptabilité en partie double, le même modèle comptable qu’utilisent les banques et les entreprises : chaque transaction déplace de l’argent d’un compte vers un autre, rien n’apparaît ni ne disparaît tout seul. Résultat, rapprocher des comptes et suivre les virements entre eux devient bien plus fiable qu’avec une simple liste de débits et de crédits.

Viennent ensuite les fonctionnalités qui donnent vraiment envie de s’y tenir. Les budgets peuvent être définis par catégorie et par période, avec report automatique. Les règles appliquent des tags, catégories ou budgets aux transactions entrantes automatiquement, si bien qu’un salaire récurrent n’a pas besoin d’être trié à la main chaque mois. Les tirelires (piggy banks) suivent des objectifs d’épargne par rapport au solde d’un compte, et les transactions récurrentes gèrent les abonnements et les crédits immobiliers. Un outil compagnon distinct, le Firefly III Data Importer, se connecte à des fichiers CSV, des exports bancaires CAMT.05x, ou des fournisseurs comme GoCardless et SimpleFIN pour récupérer les transactions au lieu de les saisir à la main. Rien de tout ça ne nécessite un abonnement ou un compte chez le développeur ; toute la pile applicative vit sur le serveur qui la fait tourner.

Comment installer Firefly III avec Docker

Prérequis : Docker et Docker Compose doivent déjà être installés, et il faut être à l’aise pour générer des chaînes aléatoires servant de secrets. Notre guide de démarrage homelab pour débutants couvre le choix du matériel et les bases de Docker pour un premier projet.

La documentation officielle d’installation Docker fournit une pile à trois conteneurs : un conteneur app qui fait tourner Firefly III lui-même, un conteneur db (MariaDB par défaut, PostgreSQL également pris en charge), et un petit conteneur cron qui interroge le point d’accès cron de Firefly III selon un planning, pour les transactions récurrentes, les budgets automatiques et les mises à jour des taux de change. Ce troisième conteneur est le détail que la plupart des guides d’applications à conteneur unique passent sous silence, et c’est ce qui vaut à cette installation un niveau de difficulté moyen plutôt que facile.

  1. Enregistrez le docker-compose.yml ci-dessous dans un dossier vide.
  2. Générez une chaîne aléatoire de 32 caractères pour APP_KEY, puis une autre pour STATIC_CRON_TOKEN, et remplacez les valeurs par défaut.
  3. Renseignez de vrais identifiants de base de données, en les faisant correspondre entre les blocs de service app et db.
  4. Lancez le fichier compose depuis ce dossier et ouvrez le port mappé pour créer le premier compte.
services:
  app:
    image: fireflyiii/core:latest
    container_name: firefly_iii_core
    hostname: app
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "80:8080"
    environment:
      APP_KEY: "replace_with_32_char_random_string"
      APP_URL: https://firefly.votredomaine.com
      DB_CONNECTION: mysql
      DB_HOST: db
      DB_PORT: 3306
      DB_DATABASE: firefly
      DB_USERNAME: firefly
      DB_PASSWORD: changeme
      STATIC_CRON_TOKEN: "replace_with_32_char_random_string"
      TZ: Europe/Paris
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload

  db:
    image: mariadb:lts
    container_name: firefly_iii_db
    hostname: db
    restart: unless-stopped
    environment:
      MYSQL_RANDOM_ROOT_PASSWORD: "yes"
      MYSQL_DATABASE: firefly
      MYSQL_USER: firefly
      MYSQL_PASSWORD: changeme
    volumes:
      - firefly_iii_db:/var/lib/mysql

  cron:
    image: alpine
    container_name: firefly_iii_cron
    restart: unless-stopped
    depends_on:
      - app
    environment:
      TZ: Europe/Paris
      STATIC_CRON_TOKEN: "replace_with_32_char_random_string"
    command: ["sh", "-c", "apk add tzdata && echo \"0 3 * * * wget -qO- http://app:8080/api/v1/cron/$STATIC_CRON_TOKEN\" | crontab - && crond -f -L /dev/stdout"]

volumes:
  firefly_iii_upload:
  firefly_iii_db:
docker compose up -d

Attention : APP_KEY et STATIC_CRON_TOKEN doivent chacun faire exactement 32 caractères, sinon Firefly III refusera de démarrer correctement. Définissez le mot de passe de la base de données avant le tout premier lancement : le modifier après le démarrage des conteneurs ne le met pas à jour dans le volume de base de données déjà initialisé, et Firefly III perdra l’accès.

Seul le port 8080 a besoin d’être exposé sur le conteneur app ; le côté hôte de ce mapping peut être changé pour n’importe quel port libre. Le conteneur cron n’est pas un simple bonus : sans lui, les transactions récurrentes, les notifications de factures et les mises à jour automatiques des taux de change ne se déclenchent tout simplement jamais, silencieusement, d’après la documentation officielle sur la tâche cron.

Astuce : figez l’image app sur un tag de version précis comme fireflyiii/core:version-6.6.3 plutôt que latest. Firefly III exécute des migrations de base de données au démarrage, et un saut de version majeure non planifié peut arriver en pleine migration si la pile compose tire automatiquement un nouveau tag au redémarrage.

Automatiser Firefly III

Compatible avec : l’API REST de Firefly III et ses webhooks sortants permettent à un outil d’automatisation auto-hébergé de réagir à de nouvelles transactions ou d’y injecter des données sans toucher directement à la base de données.

Puisque presque toutes les fonctions de Firefly III sont exposées via son API, quiconque fait déjà tourner n8n peut le brancher sur une stack d’automatisation plus large : une notification quand un budget dépasse un seuil, des transactions ajoutées à une sauvegarde sous forme de tableur, ou un webhook relayé vers une appli de chat quand une grosse transaction est enregistrée. C’est exactement ce genre de connexion qui fait qu’un homelab ressemble à un système cohérent plutôt qu’à une étagère d’applications isolées.

Firefly III vs Actual Budget

Actual Budget est la comparaison auto-hébergée la plus proche, et les deux visent des philosophies différentes plutôt qu’un simple écart de fonctionnalités. Actual Budget suit une méthode de budgétisation par enveloppes et base zéro, popularisée par YNAB, avec un moteur de synchronisation local-first rapide et une installation Docker à conteneur unique, plus légère. Firefly III est construit autour d’une comptabilité en partie double de niveau professionnel et d’une automatisation par règles, avec une pile à trois conteneurs plus lourde et une courbe d’apprentissage plus raide, mais une profondeur de reporting bien supérieure une fois configuré. Aucun des deux n’est « meilleur » dans l’absolu : Actual Budget convient à un flux de budgétisation par enveloppes rapide avec une installation minimale, tandis que Firefly III convient à qui veut modéliser où l’argent se déplace réellement entre chaque compte qu’il possède.

Firefly IIIActual Budget
Modèle de baseComptabilité en partie doubleBudgétisation par enveloppes / base zéro
Déploiement par défautTrois conteneurs (app + BDD + cron)Conteneur unique
Import bancaireData Importer séparé (CSV, CAMT, GoCardless, etc.)Synchronisation bancaire intégrée (extension payante pour certains fournisseurs)
AutomatisationMoteur de règles, API REST complète, webhooksRègles basiques, API limitée
LicenceAGPL-3.0MIT
  • Vraie comptabilité en partie double, pas un traqueur de dépenses simplifié
  • Le moteur de règles automatise la catégorisation et le tag des transactions entrantes
  • API REST complète et webhooks pour construire des automatisations sur mesure
  • Prend en charge toutes les devises, avec suivi intégré des taux de change
  • La pile à trois conteneurs (app, base de données, cron) ajoute un vrai coût de mise en place
  • Courbe d’apprentissage plus raide que les applis de budgétisation par enveloppes comme Actual Budget
  • L’import bancaire nécessite un outil Data Importer séparé, pas intégré au cœur de l’application

FAQ

Firefly III est-il gratuit ?

Oui. Le serveur auto-hébergé est entièrement gratuit et open source sous licence AGPL-3.0, sans fonctionnalité payante. Le développeur accepte les dons via Patreon, GitHub Sponsors et Ko-fi, mais rien de tout ça n’est nécessaire pour le faire fonctionner.

Firefly III a-t-il besoin d’une base de données séparée ?

Oui. Contrairement aux applications à conteneur unique livrées avec SQLite, Firefly III nécessite MySQL/MariaDB ou PostgreSQL tournant comme son propre service. Le fichier Docker Compose officiel inclut un conteneur MariaDB précisément pour cette raison.

Firefly III peut-il importer automatiquement les transactions bancaires ?

Pas tout seul. Un outil officiel séparé, le Firefly III Data Importer, gère les fichiers CSV, les exports bancaires CAMT.05x, et les connexions à des fournisseurs comme GoCardless, SimpleFIN et Enable Banking, puis transmet les transactions extraites à Firefly III via son API.

Pourquoi le conteneur cron est-il important ?

Les transactions récurrentes, les budgets automatiques, les alertes d’abonnements/factures et les mises à jour des taux de change ne fonctionnent que si quelque chose appelle le point d’accès cron de Firefly III selon un planning. Sous Docker, c’est le petit conteneur cron du fichier compose officiel ; sans lui, ces fonctionnalités ne se déclenchent tout simplement jamais, silencieusement.

Firefly III convient-il à un foyer, pas seulement à une personne ?

Il prend en charge plusieurs utilisateurs et des groupes multi-utilisateurs partageant la même administration financière, si bien qu’un couple ou une famille peut suivre des comptes partagés sous une seule installation. Les permissions sont plus simples que celles d’un outil multi-tenant dédié, donc ça convient surtout à un foyer où chacun fait confiance aux autres pour voir l’ensemble des comptes, plutôt qu’à un besoin de contrôles d’accès granulaires.

Firefly III suit la même logique de « garder les données sensibles hors des serveurs de quelqu’un d’autre » que notre comparatif des gestionnaires de mots de passe auto-hébergés, simplement appliquée aux transactions plutôt qu’aux identifiants. Les données financières comptent parmi les plus sensibles qui soient, et faire tourner ce gestionnaire sur du matériel qui héberge déjà d’autres services auto-hébergés garde un morceau de plus de la vie numérique d’un foyer hors des serveurs tiers. Notre guide de démarrage homelab pour débutants couvre les bases Docker dont dépend cette installation.