Automatiser la prévision de trésorerie avec n8n et l'IA

Le tableau de trésorerie que beaucoup de PME tiennent encore dans un fichier Excel a un défaut structurel : il est à jour le jour où quelqu'un prend le temps de le remplir, puis se périme dès la transaction suivante. Résultat, un découvert se découvre souvent le jour même où il survient — quand la banque refuse un prélèvement — plutôt que trois semaines avant, quand il aurait encore été possible de relancer une créance ou de décaler un paiement fournisseur. Les briques nécessaires pour changer ça existent déjà et sont documentées sur ce blog : l'API bancaire de Qonto ou de GoCardless pour le solde réel, l'API de Pennylane ou de Sage Business Cloud pour les factures en attente. Ce guide assemble ces briques en un prévisionnel de trésorerie glissant, actualisé automatiquement, qui alerte avant le découvert plutôt qu'après.

Pourquoi un prévisionnel manuel arrive toujours trop tard

Un prévisionnel de trésorerie tenu à la main souffre de trois défauts qui se cumulent : il demande un temps de saisie que peu de PME s'accordent chaque semaine, il repose sur une extraction manuelle des factures en attente (facilement oubliée dès que l'activité s'accélère), et il ne se met à jour qu'au rythme de la personne qui le maintient — jamais en temps réel. Une étude récente de Bartłomiej Małkus, Szymon Bobek et Grzegorz J. Nalepa, publiée en 2025 (« Financial Management System for SMEs: Real-World Deployment of Accounts Receivable and Cash Flow Prediction », voir l’étude), déployée en conditions réelles auprès de freelances et petites entreprises, part précisément de ce constat : les outils de prévision existants ciblent les grandes entreprises avec des historiques de données abondants, alors que les TPE et PME disposent de peu d'historique et de ressources limitées pour l'exploiter — ce qui justifie une approche combinant prédiction des retards de paiement clients et prévision de trésorerie, taillée pour ces contraintes plutôt qu'un simple report d'un modèle pensé pour un grand groupe.

L'architecture : trois sources, un solde projeté

Le pipeline n8n repose sur trois flux de données qui existent déjà dans vos outils, sans ressaisie :

Schedule Trigger (quotidien, tôt le matin)
        │
        ├─► Solde bancaire réel (API Qonto ou GoCardless)
        ├─► Factures clients impayées + échéances (API Pennylane / Sage)
        └─► Factures fournisseurs à régler + échéances (API Pennylane / Sage)
        │
        ▼
   Code : projection semaine par semaine (13 semaines glissantes)
        │
        ▼
   Seuil de sécurité franchi ? ── non ──► journalisation Supabase
        │ oui
        ▼
   Alerte Slack/email avec détail des mouvements en cause

Récupérer le solde bancaire réel

Un node HTTP Request planifié par un Schedule Trigger quotidien interroge l'API Business de Qonto (GET /v2/transactions) ou l'équivalent GoCardless selon votre banque, pour obtenir le solde du jour et l'historique récent des mouvements. C'est le point de départ non négociable de toute projection : partir d'un solde inexact rend caduque toute la suite du calcul, aussi soignée soit-elle.

Lister les créances et les dettes à échéance

Deux appels supplémentaires vers l'API de votre outil comptable complètent le tableau : les factures clients encore marquées impayées avec leur date d'échéance (l'argent qui doit rentrer), et les factures fournisseurs enregistrées mais non réglées avec leur propre échéance (l'argent qui doit sortir). Si votre comptabilité tourne sous Pennylane, l'endpoint /customer_invoices et son pendant /supplier_invoices couvrent exactement ce besoin, comme détaillé dans notre guide de connexion n8n ↔ Pennylane.

Projeter semaine par semaine

Un node Code additionne, pour chaque semaine des trois prochains mois, le solde de départ, les encaissements attendus (factures clients dont l'échéance tombe dans la semaine) et les décaissements prévus (factures fournisseurs à échéance). Cette granularité hebdomadaire sur un horizon glissant d'environ treize semaines n'est pas un choix arbitraire : c'est une méthode de gestion financière éprouvée, suffisamment fine pour être actionnable et suffisamment courte pour rester fiable — contrairement à une projection annuelle qui accumule les incertitudes. Le même node recalcule l'intégralité de la projection à chaque exécution plutôt que de corriger un historique, sur le même principe de recalcul complet que celui détaillé dans notre guide du node Compare Datasets pour d'autres rapprochements.

Affiner avec l'IA : pondérer les échéances par le comportement réel du client

Une première version du prévisionnel suppose que chaque facture client sera payée pile à sa date d'échéance — une hypothèse optimiste que peu d'entreprises vérifient dans les faits. Une fois quelques mois d'historique accumulés dans Supabase (date d'échéance déclarée contre date de paiement réelle par client), un nœud AI Agent ou un simple appel LLM peut pondérer chaque échéance à venir par le retard moyen déjà observé pour ce client précis, plutôt que de traiter tous les clients de façon identique. Cette approche rejoint directement les travaux de Dimitrios Kotios, Georgios Makridis, Georgios Fatouros et Dimosthenis Kyriazis, publiés dans Journal of Big Data en 2022 (« Deep learning enhancing banking services: a hybrid transaction classification and cash flow prediction approach », voir l’étude), qui couple un modèle de classification des transactions bancaires à un modèle de prédiction de trésorerie fondé sur des réseaux de neurones récurrents, dans le cadre d'un service bancaire destiné aux PME — la même logique de personnalisation par entité plutôt que par règle unique et globale.

Concrètement dans n8n, un prompt structuré avec un Structured Output Parser reçoit l'historique de paiement d'un client et la facture en attente, et renvoie une date de paiement probable plutôt que la date d'échéance déclarée :

{
  "facture_id": "F-2026-0842",
  "echeance_declaree": "2026-09-18",
  "date_paiement_probable": "2026-09-27",
  "retard_moyen_observe_jours": 9,
  "niveau_confiance": "moyen"
}

Cette date ajustée, et non la date d'échéance brute, alimente alors la projection semaine par semaine — un solde prévisionnel construit sur des dates optimistes n'a de valeur que pour se faire de fausses idées.

Alerter avant le découvert, pas après

Un node IF compare, pour chaque semaine projetée, le solde calculé à un seuil de sécurité que vous définissez (par exemple un mois de charges fixes). Dès qu'une semaine passe sous ce seuil, une alerte Slack ou email part avec le détail qui explique la baisse — quelles factures clients pèsent sur l'encaissement attendu, quels paiements fournisseurs sont programmés cette semaine-là — pour que la décision reste humaine : relancer une créance en retard via un workflow de relances automatiques, négocier un délai avec un fournisseur, ou mobiliser une ligne de crédit avant l'échéance plutôt qu'en urgence le jour J. Pour les cas ambigus où l'arbitrage mérite une validation avant action (décaler un virement fournisseur programmé, par exemple), le pattern d'approbation humaine via Slack referme la boucle proprement.

Journaliser pour affiner le modèle dans le temps

Chaque projection hebdomadaire, une fois calculée, mérite d'être archivée dans une table Supabase plutôt qu'écrasée par la suivante — sur le même principe de traçabilité que notre piste d'audit RGPD appliqué ici à la donnée financière. Cet historique sert à deux choses : comparer a posteriori la projection à la réalité pour calibrer le seuil de sécurité, et alimenter le calcul du retard moyen par client décrit plus haut, qui s'améliore mécaniquement à mesure que l'historique s'allonge.

Pièges fréquents

• Ignorer les mouvements récurrents non facturés. Un abonnement SaaS prélevé automatiquement ou un salaire versé en fin de mois ne passe par aucune facture : sans une liste séparée de ces charges fixes récurrentes, la projection sous-estime systématiquement les sorties.
• Confondre date d'échéance et date de paiement réelle. C'est l'écart le plus coûteux du modèle naïf, et la raison d'être de la pondération par historique client décrite plus haut.
• Fixer un seuil de sécurité arbitraire une fois pour toutes. Le bon seuil dépend de la saisonnalité de l'activité et évolue avec elle — un commerce avec un pic en décembre n'a pas le même besoin de coussin en janvier qu'en septembre.
• Ne journaliser aucun historique. Sans archivage des projections passées, impossible de savoir si le modèle sur- ou sous-estime systématiquement le solde réel, et donc impossible de le corriger.

Pour aller plus loin

Ce prévisionnel referme la boucle entre la banque et la comptabilité déjà connectées à n8n : si le rapprochement bancaire n'est pas encore automatisé chez vous, nos guides sur Qonto et Pennylane posent les fondations exactes réutilisées ici. Pour la partie journalisation et piste d'audit de chaque projection, le Pack Conformité & Audit (149 €) fournit le schéma Supabase et les workflows de relance déjà prêts à brancher. Si vos factures fournisseurs arrivent encore par email avant tout traitement, le Pack Inbox IA (79 €) prend en charge leur tri initial. Les trois packs, réunis dans le Bundle FlowKit Complet (269 € au lieu de 347 € pris séparément), couvrent l'ensemble du parcours financier, de la réception du document à la vision consolidée de trésorerie.