Lorsqu'une institution de microfinance déploie Juakali, le core banking system ne disparaît pas et ne passe pas au second plan. Il reste exactement là où il est déjà : au centre des registres financiers de l'institution.
Ce qui change, c'est la manière dont les prêts sont initiés et traités.
Au lieu d'essayer de forcer des workflows complexes, des circuits d'approbation et des données de contexte dans le CBS, Juakali est utilisé pour gérer le processus autour du prêt, pendant que le CBS continue à faire ce qu'il fait le mieux. Cette séparation apparaît très clairement lorsqu'on déroule un vrai processus de demande de crédit.
En règle générale, le CBS reste le système de référence pour les données core. L'identité client, les comptes, les prêts existants, les soldes, les échéanciers de remboursement et les impayés y sont stockés. C'est bien là qu'ils doivent être.
Les core banking systems sont conçus pour la fiabilité comptable, l'intégrité transactionnelle et la cohérence réglementaire. Ce sont par nature des systèmes stables et prudents.
En revanche, ils ne sont généralement pas conçus pour stocker des données de demande évolutives, appliquer des processus d'approbation multi-étapes entre équipes, ou gérer de grandes quantités d'informations contextuelles comme les données ménage, les documents, les photos ou les observations terrain. Forcer ces responsabilités dans le CBS conduit souvent à des paramétrages fragiles et à des contournements difficiles à maintenir.
C'est là que Juakali intervient pour prendre en charge ce workflow périphérique, sans affaiblir le rôle du CBS.
Une demande commence dans Juakali, généralement lorsqu'un agent terrain saisit les données dans la DFA. À ce stade, l'agent capture le montant demandé, le produit, la durée, l'objet du prêt, les informations ménage ou activité, ainsi que les documents ou photos nécessaires.
À ce stade, rien n'est écrit dans le CBS.
C'est un choix volontaire. Les demandes en phase initiale sont, par nature, incomplètes. Beaucoup seront modifiées, mises en pause ou rejetées. Les faire entrer trop tôt dans le système core crée du bruit et augmente le risque de données incohérentes. En gardant les demandes dans Juakali jusqu'à l'approbation, le CBS reste propre et fiable.
Cela ne signifie pas pour autant que le CBS n'est pas utilisé à ce stade. Si le demandeur est déjà client, le CBS peut être sollicité pour récupérer des informations de base comme l'identité, le statut client, les prêts existants, les encours, les éventuels impayés et l'historique de remboursement pertinent.
Ces informations sont remontées directement dans la DFA pour donner à l'agent tout le contexte utile.
Cette récupération soutient aussi l'étape KYC : les photos client et données d'identité étant déjà présentes dans le CBS lors d'un onboarding précédent, ces données KYC existantes sont réutilisées. De plus, la fonctionnalité de reconnaissance faciale de Juakali permet d'empêcher toute tentative d'utiliser l'identité d'une autre personne pour accéder à un prêt.
Ces données enrichies ont une vraie valeur. Elles simplifient la revue des dossiers par les équipes back-office, qui retrouvent désormais dans l'application web Juakali tout le contexte nécessaire, sans avoir à changer d'outil.
Cette approche garantit l'absence de double saisie et supprime toute ambiguïté sur le système source. Juakali affiche ce que le CBS connaît déjà et s'appuie dessus pour informer les décisions, sans le modifier.
Pour beaucoup d'institutions, ces consultations en lecture seule créent déjà beaucoup de valeur : moins de vérifications manuelles, des analyses plus rapides et plus de cohérence, avec très peu de risque.
À mesure que la demande progresse, Juakali applique les règles de workflow et les validations. Les champs obligatoires sont contrôlés, les documents sont vérifiés, et les contraintes propres à chaque produit sont appliquées. La logique d'éligibilité peut s'appuyer sur des données CBS, mais la logique elle-même vit dans Juakali.
À ce stade, le dossier n'est toujours pas un prêt dans le CBS. C'est une demande de prêt, en cours dans un processus contrôlé.
Cette distinction est essentielle. Elle permet aux institutions de modifier workflows, seuils d'approbation ou règles de validation sans toucher au système core. Le CBS reste stable pendant que Juakali absorbe la complexité opérationnelle.
Les approbations sont entièrement gérées dans Juakali.
Cela implique généralement plusieurs niveaux de validation, des seuils selon montant ou produit, des permissions par rôle et par agence, ainsi qu'une piste d'audit complète indiquant qui a revu et approuvé quoi. Les contrôles maker-checker sont appliqués de manière cohérente au niveau du workflow, plutôt que de dépendre de contrôles partiels ou inégaux dans le CBS.
Seules les demandes ayant franchi toutes les étapes requises peuvent avancer. Tout le reste s'arrête dans Juakali, où le dossier peut être revu, corrigé ou rejeté sans effet de bord dans le système core.
Ce n'est qu'une fois le prêt pleinement approuvé que Juakali écrit dans le CBS.
Le payload transmis est volontairement limité. Il comprend généralement une référence client, l'identifiant du produit de prêt, le montant approuvé, la durée et les paramètres d'intérêt, ainsi que le statut du prêt. À ce moment-là, le prêt existe officiellement dans le CBS et rejoint les registres financiers de l'institution.
Certaines institutions déclenchent aussi le décaissement depuis Juakali. D'autres préfèrent que le décaissement reste entièrement dans le CBS. Les deux approches existent. Ce qui compte, c'est que l'écriture dans le CBS n'ait lieu qu'une seule fois, à un moment clairement défini, et uniquement après la fin de toutes les approbations.
En production, Juakali est parfois connecté au core banking via une couche middleware ou ESB. C'est particulièrement courant avec des CBS plus anciens ou on-premise.
Dans ce cas, le middleware sert d'interface contrôlée entre les systèmes. Il gère des sujets comme l'authentification, l'audit logging, les retries, le rate limiting et la séparation entre environnements de test et de production. Il limite aussi le couplage entre Juakali et une implémentation CBS spécifique, ce qui peut faciliter les mises à jour ou les changements de système.
Pour les core banking systems plus modernes et cloud-native, cette couche supplémentaire n'est pas toujours nécessaire. Ces plateformes proposent souvent des API bien conçues et des mécanismes intégrés de sécurité, monitoring et fiabilité. Dans ces contextes, Juakali peut s'intégrer directement au CBS sans complexité inutile.
Quelle que soit l'architecture technique, l'institution reste responsable de sa relation avec son fournisseur CBS. En pratique, les intégrations fonctionnent mieux lorsque l'interface CBS est documentée, testée et réellement exploitable par l'institution elle-même, sans dépendance permanente au fournisseur.
Avant d'intégrer un core banking system, quelques conditions doivent être réunies. L'API doit être documentée et activement utilisée par l'institution elle-même. La responsabilité de la relation avec le CBS doit être clairement portée en interne, avec la capacité de tester, superviser et maintenir l'intégration.
Si une institution ne peut pas interagir de manière fiable avec sa propre API CBS, l'intégration devient généralement fragile. Dans ces cas, un support externe est souvent nécessaire. En l'absence de portage interne ou de capacité externe suffisante, il vaut souvent mieux reporter l'intégration plutôt que de construire quelque chose qui ne pourra pas être maintenu.
Ce processus de demande de crédit met en évidence une séparation claire des responsabilités entre systèmes.
Juakali gère le processus opérationnel autour du prêt : capture des données, validations, approbations et piste d'audit. Le core banking system reste le système de référence pour les données financières et n'est mis à jour qu'une fois le prêt approuvé et prêt à exister comme objet financier.
Cette approche garde le système core propre et stable, évite les données prématurées ou incohérentes, et permet aux institutions de faire évoluer leur manière d'octroyer les prêts sans reconfigurer leur CBS. La logique de workflow peut évoluer, les structures d'approbation peuvent changer, et les processus terrain peuvent s'adapter, pendant que le système core continue à faire ce pour quoi il a été conçu.
