Contexte et enjeux
Moniepoint traite plus de 100 milliards de transactions chaque mois, réparties entre le Nigeria et le Royaume‑Uni. Cette volumétrie impose une infrastructure capable de garantir l’exactitude des données, car chaque transaction alimente les modèles de churn, de scoring crédit et de personnalisation. L’absence d’API bancaires capables de supporter ce volume a conduit à une ingestion manuelle des relevés, créant un point de vulnérabilité initial où le même opérateur pouvait à la fois charger et valider les données.
Le problème de définition du Monthly Active User (MAU) illustre le risque : si l’on considère « au moins une transaction » comme critère d’activité, les frais SMS automatiques gonflent artificiellement le nombre d’utilisateurs actifs, faussant les indicateurs marketing, produit et finance. Cette incohérence se répercute directement sur les algorithmes d’IA, qui reproduisent les biais introduits par une métrique mal définie.
Architecture de gouvernance et chaîne de traçabilité
Pour contrer le risque de confiance, Moniepoint a instauré un système maker‑checker dès la phase d’importation : l’opérateur qui charge le relevé ne peut pas l’approuver. Cette contrainte opérationnelle a été étendue à toutes les étapes suivantes : les rapports de settlement, la réconciliation automatique et l’alimentation de l’ERP sont tous associés à un enregistrement détaillé du pipeline utilisé, du développeur qui a écrit la logique de catégorisation et du moment de la décision. Ainsi, chaque transaction possède une full chain of custody depuis le point de paiement jusqu’à la génération du reporting financier.
Cette traçabilité repose sur des métadonnées stockées avec chaque enregistrement : identifiant du pipeline, version du code, horodatage et utilisateur responsable. En pratique, lorsqu’une transaction est auto‑reconciliée, le système consigne non seulement le match, mais aussi le pipeline de décision et le créateur de la règle de tagging, permettant un audit complet en cas d’anomalie.
Problèmes liés aux définitions de données et impact sur l’IA
Le manque d’une définition unique du statut « actif » a conduit à trois interprétations différentes au sein de l’entreprise : marketing, produit et finance. Cette fragmentation a généré des modèles d’IA qui, sans gouvernance, traitent les clients dormants comme actifs, entraînant des prévisions de churn erronées et des scores de crédit biaisés. Le problème n’est pas algorithmique ; il provient d’une donnée d’entrée mal gouvernée.
Le « SQL problem » a aggravé la situation. Une fois que chaque analyste finance a commencé à écrire ses propres requêtes, les divergences de logique ont produit des résultats incohérents. Cette dispersion a motivé la création d’une couche de gouvernance de données, où les définitions canonisées et la lignée des données sont centralisées, éliminant le besoin d’écrire du SQL ad‑hoc.
Leçons pour la gouvernance de l’IA
Moniepoint montre que la gouvernance n’est pas une fonctionnalité supplémentaire de l’IA, mais le socle qui rend possible toute application fiable. Une interface d’analyse conversationnelle, capable de répondre à des questions en langage naturel comme « Quel est le revenu du mois par entité ? », ne peut fournir des réponses fiables que si la couche sous‑jacente garantit la cohérence des définitions et la traçabilité des transformations.
En résumé, la contrainte opérationnelle (absence d’API), le système maker‑checker, la chaîne de traçabilité complète et la centralisation des définitions de données constituent les piliers d’une architecture d’IA résiliente. Ces pratiques offrent un modèle reproductible pour les fintechs qui souhaitent aligner leurs modèles d’apprentissage automatique avec des exigences de transparence, d’auditabilité et de responsabilité.
