Gazprombank.Tech montre comment la personnalisation par IA a accru de 25 % le recouvrement des dettes
Gazprombank.Tech a présenté son système Next Best Action pour le recouvrement des impayés. L'équipe a supprimé un décalage de données de trois jours, s'est branchée sur le processus métier sans charge supplémentaire et a confié le choix du canal de contact à des modèles uplift. Lors du pilote, le taux de règlement a progressé de 25 %, les appels d'opérateurs ont chuté de 73 % et le coût de communication par client a baissé de 10 %. Selon l'équipe, le projet est resté dans le cycle de vie habituel d'un modèle, tout en produisant un effet sensible dès la première étape du recouvrement.
Traité par IA depuis Habr AI ; édité par Hamidun News
Gazprombank.Tech a détaillé le déploiement de Next Best Action pour traiter les créances impayées. L'équipe a associé une nouvelle architecture de données à des modèles uplift afin de choisir le meilleur canal de contact pour chaque client et de récupérer l'argent plus vite, sans surcharger le centre d'appels.
Où les jours se perdaient
Avant le nouveau dispositif, la banque suivait la logique d'une plateforme de données classique : les sources étaient répliquées dans un stockage opérationnel, traversaient les couches Stage et Core de l'entrepôt d'entreprise, puis arrivaient dans des datamarts Hadoop pour l'entraînement et le scoring des modèles. La chaîne était fiable, mais trop lente pour le recouvrement. L'information la plus sensible, le simple fait qu'un impayé soit survenu, parvenait aux modèles avec un décalage pouvant atteindre trois jours. Le client n'avait déjà pas payé, mais la réaction personnalisée de la banque ne démarrait qu'après-demain.
S'y ajoutait l'ancienne logique de communication. Les contrats étaient classés dans une matrice Balance at Risk : plus le risque et le solde étaient élevés, plus le client recevait de contacts. Venait ensuite une cascade d'actions fixe : push, SMS, appel d'un robot, appel d'un opérateur. Cette approche fonctionnait par segments, mais ne répondait pas à la question plus importante : quel canal marchera pour ce client précis, maintenant. Résultat : une partie des gens était dérangée pour rien, et le centre d'appels dépensait des ressources en appels qui auraient pu être évités.
Comment NBA a été construit
L'équipe a choisi de ne pas casser le système métier Collection, déjà très sollicité, ni d'y ajouter un nouveau processus lourd. Les développeurs ont plutôt repéré une tâche automatique existante, déclenchée à l'apparition de l'impayé, et s'y sont raccordés via ETL Framework. Les événements utiles étaient balisés par des tags puis exportés immédiatement vers Hadoop et Data Factory, sans délais superflus. La banque a ainsi commencé à connaître l'impayé presque au moment où il survenait, sans charge supplémentaire sur le circuit principal.
Ensuite, le modèle de décision lui-même a changé. À la place de la segmentation, l'équipe est passée à First Best Action et Next Best Action : le système ne se contente pas d'évaluer le risque, il recommande le meilleur prochain canal de contact. Pour le pilote, plusieurs approches uplift ont été testées : modèles solo, paires de modèles indépendants et dépendants, variantes multiclasses et multi-treatment. Elles ont été évaluées non sur une seule belle métrique, mais sur un ensemble de contraintes : Gini, Balance at Risk, Qini, coût des communications, budget et disponibilité des opérateurs du centre d'appels.
«
Nous avons décidé de ne rien choisir du tout et d'écrire simplement un optimiseur ».
Il en est résulté un optimiseur qui, à chaque étape de l'impayé, entraîne et règle un ensemble de modèles, puis retient la meilleure option selon les contraintes métier précises. À l'étape précoce de First Best Action, le système recommande directement s'il faut écrire au client, envoyer un push ou un SMS, ou transférer le dossier à un robot ou à un opérateur. La banque conserve en outre des modèles de contrôle qualité pour voir non seulement la conversion finale, mais aussi le comportement des modèles uplift au sein de chaque groupe.
Ce qu'a montré le pilote
Le pilote a été conçu comme une expérience rigoureuse. Environ 30 % du flux a été dirigé vers le circuit de test, et le reste réparti entre l'ancienne stratégie et le nouveau système de recommandations. L'accumulation des données a commencé fin 2024, puis deux mois supplémentaires ont été nécessaires pour le développement et la mise en production. Selon l'équipe, le projet est resté dans le cycle de vie habituel d'un modèle, tout en produisant un effet sensible dès la première étape du recouvrement.
- Le taux de règlement a progressé de 25 % par rapport à la stratégie actuelle.
- Selon les canaux de communication, l'effet a apporté de 15 % à 32 % de profit supplémentaire.
- Les appels d'opérateurs ont diminué de 73 % et le coût de communication par client de 10 %.
- La réponse des clients a augmenté de 5 % pour les appels d'opérateur et de 11 % pour les appels de robot.
- L'effet financier a dépassé 3 milliards de roubles de soldes préservés pour 20 000 contrats en un seul mois à l'étape First Best Action.
Ce que cela signifie
Le cas de Gazprombank.Tech montre que, dans les processus sensibles comme le recouvrement, ce n'est pas la communication la plus agressive qui l'emporte, mais la plus précise. En supprimant le décalage des données et en choisissant le canal de contact pour chaque client, l'IA peut à la fois augmenter les recouvrements, réduire les coûts et éviter de griller la fidélité des clients avec des appels inutiles.
Questions clés sur cet article
Que sait-on sur Où les jours se perdaient ?
Avant le nouveau dispositif, la banque suivait la logique d'une plateforme de données classique : les sources étaient répliquées dans un stockage opérationnel, traversaient les couches Stage et Core de l'entrepôt d'entreprise, puis arrivaient dans des datamarts Hadoop pour l'entraînement et le scoring des modèles. La chaîne était fiable, mais trop lente pour le recouvrement. L'information la plus sensible, le simple fait qu'un impayé soit survenu, parvenait aux modèles avec un décalage pouvant atteindre trois jours. Le client n'avait déjà pas payé, mais la réaction personna
Comment NBA a été construit?
L'équipe a choisi de ne pas casser le système métier Collection, déjà très sollicité, ni d'y ajouter un nouveau processus lourd. Les développeurs ont plutôt repéré une tâche automatique existante, déclenchée à l'apparition de l'impayé, et s'y sont raccordés via ETL Framework. Les événements utiles étaient balisés par des tags puis exportés immédiatement vers Hadoop et Data Factory, sans délais superflus. La banque a ainsi commencé à connaître l'impayé presque au moment où il survenait, sans charge supplémentaire sur le circuit principal. Ensuite, le modèle de décision lui-m
Que sait-on sur Ce qu'a montré le pilote ?
Le pilote a été conçu comme une expérience rigoureuse. Environ 30 % du flux a été dirigé vers le circuit de test, et le reste réparti entre l'ancienne stratégie et le nouveau système de recommandations. L'accumulation des données a commencé fin 2024, puis deux mois supplémentaires ont été nécessaires pour le développement et la mise en production. Selon l'équipe, le projet est resté dans le cycle de vie habituel d'un modèle, tout en produisant un effet sensible dès la première étape du recouvrement. Le taux de règlement a progressé de 25 % par rapport à la stratégie actuell
Test Frontier LLMs & Autonomous Agents in One Workspace
Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.
L'essentiel de l'IA — une fois par semaine
Sept actus qui ont vraiment compté, choisies à la main. Sans bruit ni communiqués.
C'est fait ! Vérifiez votre boîte mail pour la confirmation.