Qonto + n8n : automatiser le rapprochement bancaire sans perdre le contrôle

Ce que le workflow doit réellement faire

Un rapprochement utile suit six étapes :

1. charger les transactions nouvelles ou modifiées depuis Qonto ;
2. normaliser les montants, dates, contreparties et références ;
3. enregistrer chaque transaction avec une clé stable ;
4. chercher une facture, un paiement ou une règle déterministe correspondante ;
5. proposer une catégorie lorsque les données le permettent ;
6. faire valider les cas ambigus avant d'écrire dans le système comptable.

La transaction bancaire ne contient pas toujours assez d'information pour déterminer un compte comptable, la TVA ou la nature exacte d'une dépense. Le workflow prépare le rapprochement. Il ne remplace ni la pièce justificative ni les règles définies avec l'expert-comptable.

Authentifier Qonto correctement

La Business API Qonto propose deux méthodes d'authentification. Le choix dépend de l'intégration.

Clé API pour automatiser son propre compte

Pour une automatisation interne sur votre organisation Qonto, la documentation accepte un en-tête de cette forme :

Authorization: sign-in:secret-key

La valeur sign-in:secret-key est envoyée telle quelle. N'ajoutez pas le préfixe Basic et ne l'encodez pas en Base64.

Dans n8n, créez un credential générique Header Auth :

Le secret doit rester dans le gestionnaire de credentials de n8n. Ne le placez ni dans un noeud Code, ni dans une expression visible, ni dans un export de workflow.

OAuth 2.0 pour une intégration destinée à plusieurs clients

Une application qui connecte les comptes Qonto de plusieurs entreprises doit utiliser OAuth 2.0. Les appels portent alors un jeton d'accès :

Authorization: Bearer access-token

Certains endpoints ne sont disponibles qu'avec OAuth. Qonto publie une matrice d'accès par méthode d'authentification. Pour une connexion OAuth, créez une application dans le Developer Portal et suivez le flux d'autorisation. Ne transformez pas une clé API interne en pseudo-intégration multi-client.

L'en-tête X-Qonto-Staging-Token a un rôle distinct : la documentation le réserve aux requêtes vers l'environnement Sandbox. Il ne remplace pas Authorization en production.

Configurer le noeud HTTP Request dans n8n

Le parcours canonique utilise le noeud HTTP Request, disponible dans n8n sans module communautaire.

La requête doit identifier le compte par bank_account_id ou par iban. Ajoutez ensuite les paramètres nécessaires :

La réponse contient un objet meta avec notamment current_page, next_page, total_pages et per_page. Dans n8n, continuez tant que meta.next_page n'est pas nul. Ne déduisez pas le nombre de pages à partir du volume habituel de l'entreprise.

Qonto indique que l'absence de filtre de statut renvoie par défaut les transactions completed. Je préfère garder status[]=completed explicite : la règle reste visible dans le workflow.

Lire la réponse sans inventer de données

Cet exemple est synthétique. Il reprend la structure publiée dans la référence de l'API, mais ne représente pas une transaction cliente :

{
  "transaction_id": "super-transaction-7468",
  "amount": 19.99,
  "amount_cents": 1999,
  "side": "debit",
  "currency": "EUR",
  "label": "FREE MOBILE",
  "settled_at": "2026-08-12T08:32:00.000Z",
  "updated_at": "2026-08-12T08:32:05.000Z",
  "status": "completed",
  "reference": null,
  "attachment_required": true
}

Les champs ont des fonctions différentes :

• transaction_id identifie la transaction ;
• amount_cents évite les comparaisons en virgule flottante ;
• side indique s'il s'agit d'un débit ou d'un crédit ;
• status distingue notamment pending, declined, completed et reversed ;
• updated_at permet de reprendre une transaction modifiée ;
• reference, label et les pièces jointes aident au rapprochement, sans toujours suffire.

Ne supposez pas qu'une contrepartie connue implique toujours la même catégorie. Un même fournisseur peut facturer plusieurs services, et un libellé bancaire ne prouve pas la TVA applicable.

Eviter les pertes et les doublons

Stocker uniquement une liste d'identifiants dans les données statiques du workflow est fragile pour un flux métier. Utilisez une table durable, avec transaction_id comme clé unique, puis faites un upsert.

Un enregistrement minimal peut contenir :

transaction_id
updated_at
status
amount_cents
side
label
reference
matched_document_id
proposed_category
review_status

Le fonctionnement est alors simple :

const transaction = $json;

return [{
  json: {
    transactionId: transaction.transaction_id,
    updatedAt: transaction.updated_at,
    status: transaction.status,
    amountCents: transaction.amount_cents,
    side: transaction.side,
    label: transaction.label ?? null,
    reference: transaction.reference ?? null,
  },
}];

Le noeud suivant effectue l'upsert dans PostgreSQL, Airtable ou un autre stockage qui garantit l'unicité. Une nouvelle valeur de updated_at met à jour la ligne existante au lieu d'en créer une autre.

Pour réduire le risque de manquer une transaction à la frontière entre deux exécutions, relisez une courte fenêtre de recouvrement, puis laissez l'upsert dédupliquer. N'enregistrez le nouveau point de passage qu'après une exécution complète et réussie.

Rapprocher avant de demander à une IA

Commencez par les règles déterministes :

• référence de facture exacte ;
• montant et devise identiques ;
• sens du flux cohérent ;
• date comprise dans une fenêtre définie ;
• IBAN ou contrepartie déjà validés ;
• règle récurrente approuvée par l'équipe comptable.

Une IA devient utile lorsque les libellés sont irréguliers ou que plusieurs catégories restent plausibles. Elle doit alors produire une proposition structurée et pouvoir demander une revue.

Classe cette transaction dans une catégorie autorisée.
N'invente aucune information absente du libellé ou de la référence.
Si les éléments sont insuffisants, utilise review_required.

Catégories autorisées :
- telecom
- logiciels
- deplacements
- frais_bancaires
- impots_taxes
- recettes_clients
- virements_internes
- review_required

Réponds uniquement en JSON :
{"category":"review_required","reason":"libelle insuffisant"}

Le "score de confiance" renvoyé par un modèle n'est pas une probabilité calibrée. N'utilisez pas un seuil arbitraire pour passer directement une écriture. Mesurez d'abord les erreurs sur un jeu de transactions validées, par catégorie, puis définissez les règles d'automatisation avec la personne responsable de la comptabilité.

Organiser la validation humaine

Un routage exploitable peut avoir trois sorties :

1. rapprochement déterministe : référence et montant correspondent à un document attendu ;
2. proposition à valider : une catégorie est plausible, mais une personne confirme ;
3. exception : document manquant, montant différent, transaction inversée ou libellé insuffisant.

Journalisez la règle ou le modèle utilisé, les données d'entrée, la proposition et la décision humaine. Evitez de copier des données bancaires complètes dans des outils d'IA qui ne sont pas autorisés par votre politique interne.

La même logique de contrôle est détaillée dans l'article sur la validation humaine d'un agent IA en production.

Tester avant d'activer le workflow

Préparez un jeu de test représentatif, sans utiliser les données d'un client sans autorisation :

• transactions completed, pending et reversed ;
• deux pages ou plus de résultats ;
• même transaction_id avec un updated_at plus récent ;
• montants identiques pour deux factures différentes ;
• référence absente ;
• pièce justificative manquante ;
• erreur Qonto 401, 429 ou 5xx ;
• échec d'écriture dans le stockage final.

Vérifiez qu'une exécution interrompue peut reprendre sans doublon et qu'aucune décision automatique n'est prise quand la source est incomplète. Ajoutez une alerte pour les échecs, les retards et l'accumulation d'exceptions.

Sources officielles

• Qonto : choisir la méthode d'authentification
• Qonto : authentification par clé API
• Qonto : endpoint List transactions
• n8n : documentation du noeud HTTP Request

Ce que je mettrais en production

Je garderais Qonto comme source bancaire, un stockage durable pour l'idempotence, des règles déterministes en premier et une file de revue pour le reste. L'IA proposerait une catégorie, sans décider seule d'une écriture ou d'un traitement fiscal.

Ce montage demande plus de discipline qu'un export CSV, mais il reste lisible et réversible. Si votre processus implique aussi les factures fournisseurs, la logique décrite pour automatiser Pennylane avec n8n complète ce flux. Kirako peut également concevoir une automatisation n8n adaptée à votre système comptable.