De la donnée brute à la mise à jour du modèle : une pipeline de catégorisation automatique

La catégorisation automatique de transactions bancaires est souvent perçue comme un problème classique de classification supervisée. En pratique, elle se situe à l’intersection de plusieurs difficultés structurelles : les libellés sont bruités et peu normalisés, l’ambiguïté sémantique est élevée, la taxonomie attendue compte près de 90 catégories et la distribution des classes est fortement déséquilibrée (e.g: les dépenses alimentaires sont fréquentes, les saisies sur compte sont rares).

Un même libellé peut recouvrir des réalités différentes selon le contexte : par exemple “Amazon” peut désigner un achat du quotidien, un abonnement ou des frais liés à l’utilisation de la plateforme (frais Marketplace ou des coûts liés à une activité e-commerce). Par ailleurs, un même marchand peut apparaître sous de multiples variantes dans les libellés bancaires. Ces variations proviennent des systèmes de paiement, des agrégateurs ou des formats propres aux banques, et se traduisent par des différences parfois importantes dans la chaîne de caractères : abréviations, identifiants techniques, localisations ou suffixes transactionnels. Ainsi, une transaction liée à Amazon peut apparaître sous des formes telles que “AMZN Mktp FR”, “Amazon EU Sarl”, “AMZN Digital” ou “Amazon Prime”.

Dans ce contexte, la performance d’un modèle dépend moins de l’architecture que de la qualité, de la diversité et de la mise à jour continue des données d’entraînement.

Pour relever ces défis, nous n’avons pas abordé le problème comme une simple optimisation de modèle, mais comme la conception d’un système complet capable de produire, valider et exploiter des données annotées de manière continue. D’un point de vue infrastructure, la pipeline est construite comme une plateforme de traitement de données, où chaque étape s’active en réponse à des événements précis : arrivée de nouvelles transactions, complétion d’un lot d’annotations ou génération d’un nouveau modèle. Cette approche minimise le surcoût opérationnel, découple les composants et garantit résilience et scalabilité, tout en permettant de ré-exécuter indépendamment chaque étape et de contrôler finement les coûts de calcul.

1. Stratégie d'échantillonnage des données et annotation humaine

La pipeline commence par un échantillonnage périodique depuis l’entrepôt de données anonymisées. Nous combinons plusieurs stratégies complémentaires : un échantillonnage aléatoire servant de base non biaisée pour refléter la distribution globale des données, et un sur-échantillonnage des classes rares afin d’améliorer la couverture des catégories minoritaires. Cette combinaison permet de générer un jeu de données représentatif, équilibrant exploration des cas rares et exploitation des transactions fréquentes.

Les transactions sélectionnées sont ensuite pré-annotées via un modèle de langage, mobilisé à travers un schéma de prompting structuré combinant instructions explicites et few-shot learning. Le prompt intègre des exemples représentatifs, des contraintes sur l’espace de sortie et des règles métier, afin de guider le modèle vers des prédictions cohérentes avec la taxonomie cible. Cette étape permet de générer des labels candidats de manière contrôlée qui servent de base à la validation et à l’annotation humaine.

Les transactions pour lesquelles le LLM a une confiance très élevée sont traitées automatiquement, tandis que les transactions ambiguës sont soumises à annotation par des expert·e·s. Les corrections humaines sont réinjectées dans la pipeline et alimentent la prochaine itération du modèle, ce qui permet d’améliorer progressivement la précision au fil du temps. Ce dispositif permet une forme d’active learning pragmatique, où le système sélectionne automatiquement les exemples les plus informatifs pour l’annotation humaine, maximisant ainsi l’impact de chaque correction et assurant un enrichissement optimisé des jeux d’entraînement.

2. Évaluation et déploiement des modèles

Chaque nouvelle version de modèle est évaluée sur un jeu de test stratifié, jamais utilisé lors de l’entraînement, et comparée au modèle actuellement en production selon plusieurs métriques : précision globale, F1 pondéré et performance par classe. Aucune régression sur les catégories critiques à la décision n’est acceptée, et en cas d’égalité ou d’incertitude, le modèle existant est conservé. Lorsque les critères sont validés, une nouvelle version peut être déployée en mode shadowing, où ses prédictions sont évaluées en parallèle du système en production sans impacter les traitements opérationnels. Cette approche permet de détecter d’éventuelles anomalies, de comparer les comportements des deux versions et de sécuriser l’introduction des évolutions du modèle.

3. Traçabilité, gouvernance et conformité réglementaire

Pour que ce processus reste fiable et aligné avec les principes de l’AI Act, l’ensemble des données et des transformations fait l’objet d’un versionnement et d’une traçabilité complète. Chaque modèle peut être relié aux transactions annotées qui l’ont alimenté, permettant de retracer précisément son origine. Le suivi des expérimentations journalise les paramètres, les métriques et les artefacts associés, tandis qu’un catalogue de données enrichi de métadonnées métier facilite la navigation et la traçabilité. Parallèlement, des contrôles automatiques détectent les anomalies en amont:  données corrompues, incohérences de schéma, réduisant ainsi le risque d’erreurs en production.

Pour conclure

Ainsi, la catégorisation des transactions s’inscrit dans une démarche itérative d’amélioration continue. Les performances du modèle et les choix de conception sont régulièrement réévalués à partir des retours d’usage, des erreurs observées et des évolutions des données. Le système est ainsi amené à évoluer progressivement afin de mieux répondre aux contraintes métier et plus particulièrement aux nouveaux cas rencontrés.

‍

Wissal El Achouri, Data Scientist chez Algoan.