Vous connectez votre compte courant professionnel à votre application de comptabilité, et les transactions commencent à affluer automatiquement. Ce que vous voyez rarement, c'est l'entreprise au milieu — l'agrégateur de données qui se connecte à votre banque en votre nom, récupère vos transactions, les nettoie et les transmet à votre application. Quand votre flux se casse, catégorise mal la moitié de vos achats ou rate silencieusement une semaine d'activité, le problème se situe généralement dans cette couche intermédiaire, pas dans votre application.
Trois entreprises acheminent l'essentiel de ces données aux États-Unis : Plaid, MX et Finicity (détenue par Mastercard depuis 2020). Si vous dirigez une petite entreprise, vous en avez choisi une au moment même où vous avez choisi votre logiciel de comptabilité — et si votre flux bancaire continue de mal fonctionner, comprendre les forces et les faiblesses de chaque agrégateur vous indique si changer d'application aidera ou ne fera que déplacer le même problème sur un autre écran.
Ce que fait réellement un agrégateur de données bancaires
Quand vous cliquez sur « connecter votre banque » dans une application de comptabilité, une chaîne d'événements se met en route :
- Authentification. Vous saisissez vos identifiants bancaires (ou approuvez une redirection OAuth auprès de votre banque). L'agrégateur établit une connexion liée à vos comptes.
- Récupération. L'agrégateur récupère soldes et transactions — idéalement via une API bancaire directe, parfois en se connectant à la banque en ligne comme le ferait un navigateur.
- Enrichissement. Des libellés bancaires bruts comme
SQ *COFFEE SHOP 000123sont nettoyés pour en extraire un nom de commerçant, une catégorie et parfois une localisation. - Livraison. Votre application de comptabilité reçoit des données normalisées via l'API de l'agrégateur.
Les étapes 2 et 3 sont celles où les trois fournisseurs diffèrent le plus. La récupération détermine quelles banques se connectent et à quelle fréquence le flux se casse. L'enrichissement détermine si votre comptabilité démarre avec des catégories propres ou avec un tas de transactions « Non catégorisées » que vous devez corriger à la main.
Pourquoi cela compte plus qu'avant
Pendant des années, les agrégateurs obtenaient surtout vos données par scraping d'écran : se connecter à votre banque en ligne avec vos identifiants stockés et lire les pages. Cela fonctionnait, mais c'était fragile — chaque refonte du site d'une banque cassait les connexions — et cela signifiait que votre mot de passe vivait sur les serveurs de quelqu'un d'autre.
L'industrie migre depuis une décennie vers des connexions API directes basées sur des jetons, et la réglementation force désormais la main. La règle d'open banking du Consumer Financial Protection Bureau, au titre de la Section 1033 du Dodd-Frank Act, donnerait aux consommateurs un droit formel de demander à leur banque de partager des données avec des tiers autorisés via des interfaces sécurisées, mettant de fait fin au scraping d'écran. La règle originale de 2024 a été bloquée en justice et une proposition révisée est passée en revue par la Maison-Blanche en août 2026, si bien que la forme finale reste incertaine — mais la direction est irréversible. Les accords directs banque-agrégateur et le standard du Financial Data Exchange (FDX) constituent déjà le mode de fonctionnement de la plupart des connexions aux grandes banques.
Pour vous, en tant que chef d'entreprise, cette migration a deux conséquences pratiques. Premièrement, les connexions aux grandes banques sont généralement plus fiables qu'il y a cinq ans, car les liens API basés sur OAuth se cassent moins souvent que le scraping. Deuxièmement, les connexions aux petites banques et aux coopératives de crédit — celles qui ont le moins de chances de disposer d'API modernes — sont là où les flux échouent encore, et c'est précisément là que les différences de couverture entre agrégateurs se manifestent.
Les trois agrégateurs, côte à côte
Plaid : le choix par défaut à l'empreinte développeur la plus large
Plaid est le nom que vous avez probablement déjà vu — son écran de connexion apparaît dans des milliers d'applications, des outils de budget aux services de paiement. Il documente des connexions à plus de 12 000 institutions financières et est réputé pour son expérience développeur : documentation claire, intégration rapide et chemin le plus court entre « nous avons besoin de données bancaires » et un produit fonctionnel.
Cette étendue fait de Plaid le choix par défaut le plus sûr lorsque votre priorité est simplement de connecter autant de banques différentes que possible. Si votre entreprise banke dans un établissement inhabituel — une banque régionale, une banque en ligne de niche — Plaid est souvent l'agrégateur le plus susceptible de déjà la prendre en charge.
Les compromis apparaissent à l'échelle. Des analyses tierces situent la tarification de Plaid autour de 0,50 à 2,00 $ par connexion réussie, avec des remises sur volume aux paliers supérieurs — un modèle favorable aux petites applications qui devient un véritable poste de coût pour les grandes. Et si l'enrichissement de Plaid est solide, il est généralement considéré comme bon plutôt que meilleur de sa catégorie : noms de commerçants et catégories sont généralement corrects, mais les entreprises aux flux de transactions volumineux et désordonnés constatent parfois que sa catégorisation exige plus de corrections manuelles que celle de MX.
MX : le spécialiste de la catégorisation aux racines de banque communautaire
MX s'est développée en servant directement les banques communautaires et les coopératives de crédit, et cet héritage la façonne encore. Elle publie des chiffres de connexion de l'ordre de 15 000 à 16 000, avec une force particulière auprès des petites institutions — exactement la longue traîne où les connexions Plaid peuvent être minces et où l'orientation entreprise de Finicity se fait moins sentir.
La caractéristique phare de MX est l'enrichissement des données. Son moteur de catégorisation est largement considéré comme le plus performant des trois : identification des commerçants plus propre, catégories plus cohérentes et meilleure gestion des transactions ambiguës. Si vous avez déjà ouvert votre application de comptabilité pour trouver des dizaines de transactions classées dans « Autre » ou « Non catégorisé », vous avez ressenti le coût d'un enrichissement faible — chacune d'elles représente une minute de votre temps en fin de mois. L'argument de MX est que moins de vos transactions y atterrissent.
Le revers, c'est l'accès. MX vend principalement via des contrats entreprises destinés aux banques et aux fintechs plus importantes, si bien qu'en tant que chef de petite entreprise vous choisissez rarement MX directement — vous l'obtenez parce que votre application de comptabilité ou bancaire l'a choisi. Sa tarification est négociée plutôt que publiée, ce qui rend les comparaisons de coûts directes difficiles. Et hors des États-Unis, la couverture est mince.
Finicity : la puissance de vérification de Mastercard
Finicity, acquise par Mastercard en 2020, couvre un nombre similaire de plus de 15 000 institutions et occupe la position la plus forte dans les workflows de prêt et de vérification. Ses sorties structurées pour la vérification des revenus et des actifs s'intègrent directement aux processus hypothécaires et de souscription, où l'acceptation par Fannie Mae et Freddie Mac pèse réellement. Si vous avez récemment demandé un prêt professionnel ou un crédit immobilier et qu'on vous a proposé de « vérifier vos comptes numériquement » plutôt que de téléverser des relevés, il y a de bonnes chances que Finicity ait acheminé ces données.
Soutenue par Mastercard, Finicity dispose également du plus large éventail d'accords directs de partage de données avec les grandes banques, ce qui tend à rendre ses connexions aux grandes banques stables. Comme MX, elle vend via des contrats entreprises négociés, et comme MX, elle est avant tout une histoire américaine.
Là où Finicity est moins distinctive, c'est l'enrichissement des transactions à usage général pour la comptabilité quotidienne. Elle est compétente, mais ce n'est pas la raison pour laquelle on choisit Finicity — on choisit Finicity pour les workflows à forte composante de vérification, et le flux comptable vient avec.
Le tableau comparatif honnête
| Dimension | Plaid | MX | Finicity (Mastercard) |
|---|---|---|---|
| Nombre d'institutions publié | 12 000+ | 15 000–16 000 | 15 000–16 000 |
| Profondeur petites banques / coopératives | Bonne | La plus forte | Bonne |
| Qualité de l'enrichissement des transactions | Bonne | La meilleure | Adéquate |
| Vérification revenus / actifs | Disponible | Disponible | La meilleure (rapports acceptés par les GSE) |
| Modèle tarifaire | Par connexion, environ 0,50–2,00 $ | Entreprise négocié | Entreprise négocié |
| Couverture hors États-Unis | Canada plus Europe limitée | Principalement États-Unis | Principalement États-Unis |
| Qui l'achète | Startups à grandes entreprises | Banques, fintechs plus importantes | Prêteurs, fintechs plus importantes |
Traitez chaque nombre d'institutions avec scepticisme : chaque fournisseur compte différemment les « connexions » et les « sources de données », et aucun total ne dit quoi que ce soit sur la fiabilité de connexion de votre banque. La seule question de couverture qui compte est la vôtre — recherchez le nom de votre banque accompagné du nom de votre application avant de vous engager, et consultez les retours récents, car les connexions évoluent.
Fiabilité : pourquoi votre flux se casse (et à qui la faute)
Les défaillances de flux bancaires se répartissent en trois catégories, et une seule est de la faute de votre application :
- Rupture de connexion. Votre banque modifie son parcours de connexion, ajoute des étapes multifactorielles ou fait tourner son API, et le lien de l'agrégateur casse. Vous recevez l'invite « reconnectez votre banque ». Les connexions API basées sur OAuth se cassent bien moins souvent que celles basées sur identifiants, ce qui explique pourquoi les flux des grandes banques se sont discrètement améliorés.
- Transactions manquantes ou dupliquées. La connexion fonctionne mais les données sont fausses : des débits en attente qui ne deviennent jamais des écritures comptabilisées, un week-end d'activité qui n'arrive jamais, ou le même versement importé deux fois. C'est un problème de récupération côté agrégateur, et c'est le plus difficile à repérer — aucune erreur ne s'affiche, vos livres sont simplement faux.
- Mauvaise catégorisation. Les transactions arrivent mais tombent dans les mauvais comptes. C'est un problème d'enrichissement, et c'est là que l'avantage de MX est le plus visible à l'usage quotidien.
Quand les utilisateurs se plaignent qu'une application « n'arrive pas à rester connectée à ma banque », la cause sous-jacente relève généralement de la catégorie 1, au niveau de l'agrégateur — c'est pourquoi certaines applications permettent désormais de changer d'agrégateur pour une même banque dans leurs paramètres. Si votre application propose Plaid, MX et Finicity comme fournisseurs interchangeables pour une connexion, essayez-en un autre avant de blâmer l'application. Un agrégateur différent peut réellement détenir une meilleure connexion à votre institution.
Prix : ce que vous payez sans voir de facture
Presque aucune petite entreprise ne paie un agrégateur directement. Le coût arrive intégré dans l'abonnement à votre logiciel de comptabilité — c'est pourquoi « quel agrégateur est le moins cher » est la mauvaise question pour vous. La bonne question est ce que le modèle tarifaire incite votre fournisseur à faire.
La tarification par connexion (le modèle public de Plaid) facture votre éditeur d'application à chaque fois qu'une connexion est établie ou actualisée, si bien que les éditeurs sur ce modèle ont une incitation discrète à actualiser les flux moins souvent ou à limiter le nombre de comptes que vous pouvez lier sur les formules bon marché. Les contrats entreprises (l'univers de MX et Finicity) regroupent frais de plateforme et usage, ce qui tend à pousser les éditeurs vers des paliers d'abonnement globalement plus élevés plutôt que vers des limites par compte.
Dans les deux cas, vous payez. Ce qui diffère, c'est où le coût affleure : plafonds de connexion et fréquence d'actualisation d'un côté, prix de base plus élevés de l'autre. Lorsque vous comparez des formules comptables, « combien de comptes bancaires puis-je connecter, et à quelle fréquence le flux s'actualise-t-il » est une question plus utile que « quel agrégateur utilisez-vous » — mais vous savez désormais pourquoi les réponses diffèrent.
Ce que cela signifie pour vos livres
Voici la vérité inconfortable sur les flux automatisés : ce sont des pipelines d'importation, pas des comptables. Chaque transaction nécessite encore un second coup d'œil avant de faire partie de votre dossier financier, car les modes de défaillance ci-dessus sont silencieux. Un flux qui catégorise mal vos prélèvements de dirigeant comme des repas d'affaires ne déclenche aucune erreur — il gonfle simplement et discrètement vos déductions jusqu'à ce que quelqu'un s'en aperçoive.
La routine pratique est une revue hebdomadaire, pas une course mensuelle :
- Passez d'abord en revue les éléments non catégorisés et à faible confiance. La plupart des applications signalent ce dont l'agrégateur n'était pas sûr. Traitez-les chaque semaine pendant que les achats sont encore frais dans votre mémoire.
- Rapprochez avec le solde bancaire, pas avec le flux. Votre contrôle de fin de mois est « mon grand livre correspond-il au relevé », jamais « le flux a-t-il tout importé ». Le relevé fait foi ; le flux est une commodité.
- Surveillez les doublons autour des reconnexions. Chaque fois que vous reliez une banque, vérifiez la fenêtre de chevauchement. Les flux reconnectés sont la première source de transactions comptées double.
Si vous tenez vos livres en texte brut, la même discipline s'applique — la sortie du flux devient des écritures provisoires que vous révisez, pas une vérité que vous acceptez. Un versement synchronisé avec frais, par exemple, doit figurer dans votre grand livre sous ses composantes, et non comme le dépôt net :
2026-10-15 * "Shopify payout #4821" "Oct 12-14 sales, fees split out"
Assets:Checking:Business 1,842.36 USD
Expenses:Fees:Payment-Processing 58.14 USD
Income:Sales -1,900.50 USDEnregistrer séparément la vente brute et les frais — au lieu de comptabiliser le dépôt net comme un revenu — c'est ce qui garde vos chiffres de revenus exacts et vos frais visibles au moment de la déclaration fiscale. Quel que soit votre logiciel, exigez que le flux vous donne assez de détail pour séparer le brut des frais ; un flux qui n'importe que les dépôts nets dissimule des informations dont votre déclaration fiscale a besoin. La documentation Beancount couvre en détail la structure des transactions, et Fava facilite la révision des écritures importées avant qu'elles ne s'installent dans vos livres.
Comment choisir (ou juger ce que vous avez déjà)
Vous ne choisirez probablement pas un agrégateur directement — vous choisirez un logiciel de comptabilité, et l'agrégateur vient avec. Traduisez donc la comparaison en questions d'achat :
- Où bankez-vous ? Dans une banque du top 20, les trois se connectent bien ; choisissez sur l'enrichissement et les fonctionnalités de l'application. Dans une petite banque ou une coopérative de crédit, demandez au fournisseur quel agrégateur gère votre institution et comment la connexion s'authentifie (OAuth bat les identifiants stockés).
- À quel point vos transactions sont-elles désordonnées ? Volume élevé, beaucoup de commerçants similaires, dépenses importantes en espèces — la qualité de l'enrichissement compte davantage, ce qui favorise les applications bâties sur MX.
- Empruntez-vous ? Si votre workflow inclut des demandes de prêt et des vérifications de revenus, une voie soutenue par Finicity peut fluidifier cette étape.
- Pouvez-vous changer de fournisseur dans l'application ? La prise en charge de plusieurs agrégateurs avec un commutateur par connexion est la meilleure fonctionnalité de fiabilité qu'une application puisse offrir. Demandez-la explicitement.
Et gardez un œil sur l'élaboration réglementaire de l'open banking. Quelle que soit la forme finale de la Section 1033, les API bancaires standardisées continueront de remplacer les liens fragiles basés sur identifiants — ce qui signifie que l'écart de couverture entre grandes et petites institutions est ce qu'il faut surveiller. Votre flux continuera de gagner en fiabilité d'abord dans les grandes banques. Si vous bankez petit, l'agrégateur aux racines de banque communautaire les plus profondes reste celui le plus susceptible de maintenir votre connexion en vie.





