Remita a présenté le 22 septembre 2026 une nouvelle version de son application grand public lors de la Nigeria Fintech Week. La promesse est facile à comprendre : permettre à un utilisateur de retrouver plusieurs comptes bancaires dans une même interface, d’en consulter les soldes et d’effectuer ses paiements sans passer constamment d’une application bancaire à une autre.

L’application officielle mentionne les transferts vers les banques, institutions de microfinance et wallets nigérians, ainsi que vers des banques ailleurs en Afrique. Le directeur général de Remita, Deremi Atanda, a par ailleurs déclaré que seize banques avaient été intégrées et que les paiements transfrontaliers devaient s’appuyer sur le Pan-African Payment and Settlement System, PAPSS.

Ces annonces décrivent une évolution importante de l’expérience utilisateur. Elles ne signifient toutefois pas que les comptes, les banques et les infrastructures de paiement sont devenus un seul système. Pour comprendre la portée du produit, il faut séparer l’écran visible de la chaîne qui exécute réellement chaque opération.

Un tableau de bord unique ne crée pas un compte unique

La vue agrégée peut donner l’impression que l’argent a été regroupé. En réalité, les fonds restent détenus par les banques ou institutions auxquelles appartiennent les comptes. Remita fournit une interface commune pour consulter les informations et, selon les services disponibles, initier une opération.

Cette distinction est importante pour le client. Un solde total affiché à l’écran n’est pas nécessairement un solde mobilisable en une seule fois. Chaque compte conserve ses propres règles, plafonds, contrôles, disponibilités et délais de mise à jour. La qualité du service dépend donc autant de la fraîcheur des données reçues que de la présentation de l’application.

Avant même le paiement, plusieurs questions doivent être résolues : comment l’utilisateur autorise-t-il l’accès à un compte ? Quelle authentification la banque exige-t-elle ? Comment le consentement peut-il être révoqué ? Que se passe-t-il lorsqu’un établissement ne répond plus ou renvoie un solde ancien ?

Ce sont des questions opérationnelles, pas seulement techniques. Une interface élégante ne peut pas corriger à elle seule une donnée indisponible ou un contrôle refusé par la banque source.

Quatre couches derrière un même bouton

1. L’agrégation des comptes

L’application récupère et présente les données de plusieurs établissements. Il faut alors vérifier l’identité du titulaire, la portée du consentement et la fréquence d’actualisation. L’utilisateur doit aussi pouvoir distinguer une information confirmée par sa banque d’une information momentanément indisponible.

2. L’initiation du paiement

Lorsqu’un client choisit un compte pour payer, l’application transmet une instruction. L’établissement source doit authentifier le client, contrôler les fonds disponibles et accepter ou refuser l’opération. Une vue centralisée simplifie le geste, mais elle ne supprime ni les règles de la banque ni les contrôles réglementaires.

3. L’exécution domestique

Le paiement traverse ensuite les systèmes de la banque, de Remita et des infrastructures utilisées pour atteindre le bénéficiaire. Chaque intermédiaire peut produire son propre statut : reçu, accepté, en cours, rejeté, crédité ou annulé. L’enjeu consiste à restituer au client un état unique, compréhensible et définitif.

4. Le paiement transfrontalier

Pour un transfert entre deux pays africains, la chaîne s’allonge encore. PAPSS permet d’envoyer et de recevoir dans les monnaies locales et organise la compensation et le règlement entre participants. Le parcours doit néanmoins intégrer les contrôles de conformité, la conversion de change, la liquidité, les frais, la banque du bénéficiaire et la gestion des rejets ou retours.

Remita a cité le Ghana, le Kenya et le Rwanda parmi les destinations visées. Les informations publiques consultées ne donnent cependant pas la liste complète des corridors déjà ouverts, les banques effectivement joignables dans chacun d’eux, les devises disponibles ni le coût total pour le client. Ces éléments devront être confirmés avant d’évaluer la portée réelle de l’offre.

Le vrai test commence lorsqu’une opération n’aboutit pas immédiatement

La simplicité d’un produit multi-banques se juge moins lorsque tout fonctionne que lorsqu’une dépendance ralentit. Un utilisateur peut relancer un paiement s’il ne reçoit pas de confirmation. La première instruction peut pourtant avoir été acceptée, tandis que le retour tarde à traverser la chaîne.

Sans contrôle des reprises, cette situation peut produire un doublon. Sans référence commune, elle peut aussi compliquer le rapprochement entre Remita, la banque source, l’infrastructure de paiement et la banque bénéficiaire. Le client voit alors un débit, un statut incertain ou un bénéficiaire non crédité, sans savoir quel acteur doit intervenir.

Une application qui agrège plusieurs comptes doit donc traiter au moins quatre scénarios avec précision :

  • le compte est visible, mais son solde ne peut pas être actualisé ;
  • l’instruction est refusée avant tout débit ;
  • le compte est débité, mais le statut final n’est pas encore connu ;
  • le paiement transfrontalier est retourné après conversion ou contrôle.

Pour chacun, le produit doit fournir un statut clair, éviter les nouvelles tentatives inutiles, conserver la preuve de l’instruction et définir le délai de régularisation.

Les chiffres qui permettront d’évaluer le service

Remita affirme que des milliers d’utilisateurs ont participé à la phase bêta. Ce chiffre, comme le nombre de banques intégrées, provient de l’entreprise et n’est pas accompagné d’indicateurs publics de performance.

La prochaine étape ne devrait donc pas être mesurée uniquement par les téléchargements. Sept indicateurs seraient plus utiles :

  1. le taux de réussite de la liaison d’un compte, par banque ;
  2. la fraîcheur des soldes et la fréquence des données indisponibles ;
  3. le taux d’autorisation des paiements, par établissement source ;
  4. le taux de réussite de bout en bout, par destination ;
  5. le délai entre l’initiation et le statut final ;
  6. le coût total, change et frais compris ;
  7. le délai de traitement des paiements en attente, retours et réclamations.

Ces mesures permettraient de distinguer trois choses souvent confondues : la disponibilité d’une fonctionnalité, son utilisation et sa fiabilité.

Une promesse utile, qui doit être documentée corridor par corridor

Le nouveau Remita répond à un problème réel : la fragmentation des comptes et des applications. Pour les utilisateurs qui gèrent plusieurs banques, une interface commune peut réduire les manipulations et rendre la situation financière plus lisible. L’ajout de transferts africains peut aussi éviter une nouvelle rupture de parcours.

Mais la valeur ne viendra pas du nombre de services affichés sur l’écran d’accueil. Elle dépendra de la cohérence de toute la chaîne : consentement compréhensible, authentification fiable, soldes à jour, statuts définitifs, frais visibles, rapprochement complet et résolution rapide des incidents.

Remita a rendu visible l’ambition d’une application panafricaine. Il reste maintenant à documenter, corridor par corridor et banque par banque, jusqu’où cette ambition est déjà opérationnelle.

Sources