Concept d’application mobileBanque
Coris Bank, une alternative pour qui ne sait ni lire ni écrire
Une interface bancaire est faite de texte : des libellés, des montants écrits, des messages d’erreur. Retirez la lecture et il ne reste presque rien. C’est pourtant la situation d’une grande partie des clients d’une banque en Afrique de l’Ouest.
Coris Bank a son application. Celle-ci en est une alternative, imaginée pour les clients qu’elle ne touche pas : ceux qui ne savent ni lire ni écrire. C’est un concept, travaillé avec les décideurs de la banque : j’ai mené la recherche, dessiné les parcours et les écrans, et construit le système de composants. Il n’a pas été développé, et ce que vous lisez ici est donc un travail de conception, pas un produit en ligne.
Informations sur le projet
- Rôle
- Recherche et analyse concurrentielle, architecture des parcours, conception des écrans, système de composants
- Client
- Coris Bank International
- Nature
- Concept mené avec les décideurs de la banque, en parallèle de l’application existante
- État
- Non développé
Le problème
La banque sert déjà ses clients lecteurs. La question posée était celle des autres : à quoi ressemblerait la même banque pour quelqu’un qui ne sait ni lire ni écrire? J’ai écrit l’objectif en haut de ma spécification avant de dessiner quoi que ce soit : une application de transferts bancaires destinée aux utilisateurs non instruits, qui sont la majorité de la population dans beaucoup de pays du sud global. Quatre exigences en découlaient. L’accessibilité, rendre l’application utilisable sans lecture. La simplicité, réduire au maximum la profondeur des parcours. La fiabilité, rassurer par des confirmations claires. L’inclusivité, proposer plusieurs langues vocales.
La troisième est la plus dure, et c’est elle qui gouverne tout le reste. Il ne s’agit pas d’une application de météo : une erreur coûte de l’argent. Il ne suffit donc pas que l’utilisateur puisse agir sans lire, il faut qu’il puisse vérifier sans lire. Sinon on a seulement déplacé le risque.
Ce que les autres font déjà
Avant de proposer, j’ai regardé. M-Pesa, Wave, Orange Money : des services que ces utilisateurs manipulent déjà tous les jours, donc des habitudes qu’il vaut mieux épouser que combattre. J’ai annoté leurs écrans un par un, ce qui fonctionne et ce qui ne fonctionne pas.
Trois choses à reprendre : le solde visible avec une commande de lecture juste à côté du montant, de gros boutons sur un parcours linéaire d’un ou deux écrans pour une opération simple, et un codage par couleur et pictogramme pour le succès et l’erreur. Une chose à éviter : les icônes employées comme boutons d’action, qui prêtent à confusion dès qu’on ne peut pas lire l’étiquette qui les accompagne.
Et deux trous, là où il y avait quelque chose à prendre. La lecture vocale multilingue n’est industrialisée nulle part, alors que les principes du CGAP la recommandent explicitement pour les publics peu alphabétisés. Et l’haptique n’est presque jamais exploitée de façon systématique par les applications bancaires africaines, alors que c’est un canal gratuit qui ne demande ni écran ni lecture.
On n’écrit pas le montant, on l’empile
C’est la décision centrale du projet, et elle vient d’une observation simple : quelqu’un qui ne sait pas lire reconnaît parfaitement un billet. Il en manipule tous les jours. Ce n’est pas l’argent qui lui est étranger, c’est son écriture.
Alors on ne tape plus de chiffres. On compose le montant en choisissant des coupures, et l’application fait l’addition. Les billets choisis s’accumulent dans « votre pile d’argent », ligne par ligne, chacune retirable : deux mille une fois, cinq mille dix fois, dix mille vingt fois. Total, 252 000 CFA. C’est le geste qu’on fait déjà en sortant l’argent de sa poche.
Trois objets distincts, parce que ce sont trois objets distincts dans la vraie vie : les pièces, les billets, et les liasses pour les grosses sommes, dessinées comme des piles. Les couleurs des pastilles reprennent celles des vrais billets CFA, pour que la reconnaissance soit immédiate et non apprise.
Et la vérification devient visuelle : on ne relit pas un nombre, on regarde une pile. Si elle ne ressemble pas à ce qu’on voulait donner, on le voit.
Trois canaux à la place du texte
Retirer la lecture laisse un vide qu’un seul remplaçant ne comble pas. J’en ai donc monté trois, qui disent la même chose en parallèle.
L’audio, systématique. Un haut-parleur est posé à côté de chaque montant, de chaque solde, de chaque confirmation, et sur chaque ligne de l’historique. Rien d’important ne s’affiche sans pouvoir s’entendre.
La couleur, codée. Vert pour le positif, rouge pour le problème, sans exception, pour que la règle s’apprenne en deux usages.
La vibration, codée elle aussi. Une vibration courte pour une action réussie, deux pour une erreur. C’est le canal que personne n’exploitait, et c’est le seul qui fonctionne quand le téléphone est dans la poche, dans le bruit, ou en plein soleil.
Le même raisonnement vaut pour les personnes : on choisit un destinataire par son visage, pas par son nom. Et les langues ne sont pas des traductions mais des voix : français, dioula, mooré. Les deux dernières sont des langues largement orales, ce qui aurait rendu une simple traduction écrite parfaitement inutile.
Vérifier sans lire
C’est là que se joue la confiance. L’écran de confirmation ne demande pas de relire une ligne : il montre le visage du destinataire en grand, puis le montant, les frais et le total. Une barre de progression en haut dit où l’on en est dans le parcours, parce qu’une personne qui ne lit pas a d’autant plus besoin de savoir combien d’étapes la séparent de la fin.
Et le reçu final existe pour une raison précise : il est montrable. Quelqu’un qui ne lit pas peut le faire lire par un proche, ou le présenter en agence. La trace écrite ne sert pas à lui ; elle sert à ce qu’il puisse se faire aider sans avoir à raconter.
Où le projet s’est arrêté
Un fichier de conception en cinq parties : la recherche et le moodboard, les parcours, les écrans basse fidélité, les écrans finaux, et une bibliothèque de composants avec ses ressources. De quoi discuter sur des écrans plutôt que sur des intentions, ce qui était le but d’un travail mené avec des décideurs.
Le concept n’a pas été développé, et je préfère l’écrire que le laisser deviner. Ce projet ne prouve donc pas qu’une application tient en production ; il prouve comment j’instruis un problème quand la contrainte retire au designer son outil le plus commode, le mot.
Un projet similaire? Parlons-en.
Par email à hello@amadlouis.site, ou sur LinkedIn.
© Copyrights 2026. Tous droits reservés.