On nous pose cette question plus souvent qu’on ne le pense. Voici notre réponse honnête.
C’est une question légitime. Les outils d’IA sont devenus vraiment bons dans beaucoup de choses, et la catégorisation des transactions semble être exactement le genre de tâche structurée et de correspondance de motifs qu’un grand modèle de langage devrait bien gérer. Collez quelques transactions, demandez des catégories, obtenez une sortie propre. C’est assez simple.
Nous avons eu assez de clients qui nous ont posé des questions à ce sujet pour que nous ayons décidé de tester — non pas pour gagner un débat, mais parce que si une IA polyvalente pouvait faire ce que nous faisons, cela vaudrait la peine de le savoir.
Voici ce qu’on a trouvé.
Pour les volumes faibles, ça fonctionne un peu
Si vous construisez quelque chose de petit — un outil de finances personnelles, un prototype interne, une démo — coller des transactions dans ChatGPT ou Claude et obtenir des catégories raisonnables est vraiment viable. Les modèles généraux sont bons pour lire les noms des marchands, déduire le contexte et produire des résultats structurés. Pour 20 ou 50 transactions, vous aurez quelque chose d’utilisable.
Nous voulons être clairs à ce sujet, car le reste n’a de sens que dans le contexte : nous ne sommes pas conçus pour ce cas d’usage. Nous sommes faits pour ce qui vient ensuite.
À grande échelle, les calculs cessent de fonctionner
Notre client médian traite environ 10 000 transactions par jour. Il n’y a pas de moyen pratique de faire passer ce volume dans une interface de clavardage — ce n’est pas pour ça que les interfaces de clavardage sont conçues.
Les clients qui disent « Je l’ai essayé et ça marche » l’ont essayé sur quelques transactions. Ce n’est pas un flux de travail.
Si vous voulez le faire correctement via une API avec un vrai pipeline, vous avez environ 115 $ par mois en coûts de jetons pour un client à volume médian, et plus de 1 700 $/mois pour les utilisateurs à grand volume. C’est avant le temps d’ingénierie pour construire des files d’attente de tâches asynchrones, la logique de retentatives et la gestion des pannes — parce qu’à ce volume, un temps de réponse de 2 à 3 minutes par lot n’est pas un petit inconvénient, c’est un problème architectural.
Notre système donne les résultats en 5 secondes. Ce n’est pas une amélioration marginale. C’est une catégorie d’outil différente.
Le problème plus difficile : quels modèles généraux ignorent
La rapidité et le coût sont réparables, en théorie. L’écart de connaissances dans le domaine ne l’est pas — du moins pas sans reconstruire ce que nous avons accumulé pendant des années.
Voici quelques exemples issus de nos tests :
Nous avons demandé à un modèle d’IA de premier plan : « Quel type de transaction est BR.0072? » Il a répondu avec assurance : « Très probablement une transaction de succursale / un transfert interne. » C’est faux. BR.0072 est un frais NSF — un code interne spécifique utilisé par les banques canadiennes. Notre système la détecte correctement à chaque fois, car nous avons cartographié les codes réels utilisés par les institutions financières canadiennes dans la nature.
Sur la détection des jeux d’argent : les plateformes bien connues ne sont pas le problème. BetMGM, FanDuel, OLG — un modèle général les gère très bien. Les cas difficiles sont les processeurs de paiement et les réseaux de bons par lesquels les plateformes de jeux de hasard acheminent les transactions. GIGADAT. FLEXEPIN. ILIXIUM. BAYTREE. Pour un modèle général, cela ressemble à des entreprises fintech génériques. On sait qu’ils sont proches du jeu. Cette distinction compte énormément pour les évaluations d’abordabilité et le calcul des risques, et elle ne peut pas être corrigée en insistant davantage — elle exige une connaissance approfondie et bien soignée de la manière dont les transactions financières canadiennes se déroulent réellement.
Il en va de même pour les micro-prêteurs. Nous suivons des dizaines de prêteurs canadiens sur salaire et à court terme par leur nom — iCash, Money Mart, GoDay, Lend Direct, Prêts Alpha, et plus encore — et mettons activement à jour cette liste au fur et à mesure que de nouveaux entrants apparaissent. Un modèle général basé sur des données Internet larges ne couvre pas actuellement le paysage du prêt canadien.
La constance compte plus qu’il n’y paraît
Les LLM sont non déterministes par conception. La même description de transaction peut produire différentes catégories selon les séries — surtout via des interfaces de clavardage où les réglages de température ne sont pas contrôlés. Pour la plupart des cas d’utilisation, c’est correct. Pour les données financières, ce n’est pas le cas.
Une transaction ne devrait pas être classée comme LOAN_MICRO mardi et AUTRE mercredi. Cette incohérence n’est pas seulement un problème de qualité des données — c’est un problème de risque et de conformité. Tout système utilisant des données de transactions catégorisées pour la souscription, l’évaluation de l’accessibilité financière ou la détection de fraude doit être capable d’expliquer et de reproduire ses résultats. La catégorisation non déterministe rend cela presque impossible.
Notre modèle est déterministe. Même entrée, même sortie, à chaque fois. La seule chose qui change une prédiction est une mise à jour délibérée du modèle ou une correction du client — les deux sont suivies, vérifiées et intentionnelles.
Le système s’améliore. Un prompt ne le fait pas.
Lorsqu’un client soumet une correction via son tableau de bord, elle est appliquée en temps réel et alimente la rééducation du modèle. Plus un client utilise Flinks longtemps, plus sa catégorisation devient précise — pour ses schémas de transactions spécifiques et sur toute la plateforme.
Une invite générée par l’IA ne s’améliore pas toute seule. Quelqu’un doit remarquer les erreurs, les diagnostiquer, mettre à jour la logique et redéployer. À grande échelle, c’est un emploi à temps partiel.
La version courte
L’IA générale est bonne pour lire 20 transactions. Nous sommes conçus pour 300 000 par mois — avec une connaissance spécifique au domaine canadien, une sortie déterministe, des temps de réponse de 5 secondes, et un modèle qui s’améliore à chaque utilisation.
Si vous évaluez l’infrastructure de catégorisation des transactions et souhaitez discuter de votre volume et de votre cas d’utilisation spécifiques, nous sommes faciles à joindre.

.png)
.png)
