USSD : l'interface qui tient quand le réseau lâche

On a tendance à enterrer l'USSD un peu vite. Vu depuis une métropole bien connectée, ces menus en texte brut qui défilent sur l'écran semblent appartenir à une autre époque. La réalité du terrain est tout autre : selon les marchés, 75 à 90% des utilisateurs passent encore par l'USSD pour leurs opérations courantes. Ce n'est pas un héritage qui s'éteint, c'est un canal qui tient.

Et il tient pour de bonnes raisons. Là où la data est chère, où la couverture est inégale, où le téléphone est basique et le forfait compté, l'USSD est souvent le seul moyen fiable d'accéder à un service. Le comprendre, et le servir sérieusement, n'est pas une concession au passé. C'est une condition pour atteindre vraiment tout le monde.

Pourquoi l'USSD domine encore

La règle se vérifie marché par marché : plus la data coûte cher et moins le réseau est déployé sur le territoire, plus l'USSD est utilisé. Là où une heure de navigation représente une part sensible du budget, personne ne dépense de la data pour consulter un solde ou envoyer de l'argent. L'USSD, lui, ne consomme pas de forfait data et passe par le réseau voix, bien plus largement déployé.

S'ajoute la question du terminal. Une part importante du parc reste constituée de téléphones basiques, sans navigateur moderne ni capacité d'installer une application. Pour ces utilisateurs, il n'y a pas d'alternative : c'est l'USSD ou rien. Concevoir d'abord pour le smartphone haut de gamme, c'est concevoir pour une minorité et exclure la majorité.

Au fond, l'enjeu dépasse la technique : c'est celui de l'inclusion. Exiger une application et de la data, c'est dresser une barrière à l'entrée pour des millions de personnes parfaitement solvables mais mal équipées ou mal couvertes. L'USSD lève cette barrière. Il ne s'agit pas de viser le plus petit dénominateur commun, mais de ne laisser personne au bord de la route faute du bon téléphone.

Un canal résilient par construction

La force de l'USSD tient à ce qu'il ne demande presque rien. Pas d'application à installer, pas de connexion data, pas de compte préexistant. L'utilisateur compose un code court, et une session interactive s'ouvre en quelques secondes sur n'importe quel mobile. Quand l'app plante, quand la data ne passe pas, quand le smartphone est resté à la maison, l'USSD, lui, répond.

C'est précisément cette résilience qui en fait un filet de sécurité. Sur une plateforme transactionnelle, il n'est pas rare que l'USSD soit le canal qui sauve la journée un jour de panne data ou de saturation réseau. Le traiter comme un canal de second rang, c'est se priver de son meilleur recours quand tout le reste se dégrade.

Cette légèreté a un autre avantage : la rapidité. Une session s'ouvre et se conclut en quelques secondes, sans téléchargement ni page à charger. Pour un agent qui enchaîne les clients, ou pour quelqu'un qui veut juste vérifier un solde, cette immédiateté compte autant que la couverture. Le canal le plus simple se révèle souvent le plus rapide.

La contrainte cachée : la session

Cette simplicité a un prix côté ingénierie. Une session USSD est courte, synchrone, et sans mémoire entre deux échanges : le client ne conserve aucun état, tout repose sur le serveur. Et la session se coupe vite. Si le back-end met trop de temps à répondre, l'opérateur ferme la session et l'utilisateur se retrouve devant un écran mort.

Bien concevoir l'USSD, c'est donc tenir deux exigences à la fois : des parcours courts, qui tiennent en quelques menus clairs, et un back-end qui répond en quelques centaines de millisecondes, à chaque étape. C'est une discipline aussi stricte que celle d'une application moderne, simplement avec d'autres contraintes. Rien d'un sous-produit.

Derrière l'USSD, il y a l'opérateur

Une particularité change tout dans la conception : l'USSD ne vous appartient pas de bout en bout. La session transite par la passerelle de l'opérateur mobile, qui en fixe les règles, à commencer par la durée maximale avant coupure. On construit donc un service critique sur une dépendance qu'on ne maîtrise pas entièrement, et qui varie d'un opérateur et d'un pays à l'autre.

Cela impose une double discipline. Côté technique, il faut intégrer proprement chaque passerelle, absorber les différences de comportement, et souvent passer par des agrégateurs pour couvrir plusieurs opérateurs sans multiplier les intégrations. Côté exploitation, il faut superviser ces liens comme des dépendances de premier ordre : une passerelle qui ralentit, et c'est tout un canal qui se ferme pour une partie de la population.

Un bon plan B pour l'authentification

L'USSD a un autre usage qu'on sous-estime : l'authentification. Le réflexe habituel est d'envoyer un code à usage unique par SMS. Or le SMS n'est pas toujours fiable : réception aléatoire, délais de plusieurs minutes, messages qui n'arrivent jamais aux heures de congestion. Quand l'authentification dépend d'un SMS qui ne vient pas, l'utilisateur est tout simplement bloqué.

L'USSD offre une alternative robuste. Comme la session est lancée par l'utilisateur lui-même et confirmée en direct, on ne dépend plus d'un message entrant qui peut se perdre. Pour confirmer une opération sensible ou valider une identité quand la réception SMS est mauvaise, c'est souvent le canal le plus sûr et le plus rapide.

Concevoir des parcours pour de vrais usages

L'USSD impose des contraintes d'interface que beaucoup d'équipes ont désappris à respecter. Pas d'images, peu de caractères par écran, une saisie réduite au clavier numérique, et une attention qui se perd vite si les menus s'enfoncent sur trop de niveaux. Un bon parcours USSD va droit au but : peu d'étapes, des libellés sans ambiguïté, et les opérations fréquentes accessibles en deux ou trois touches.

À cela s'ajoute la diversité réelle des utilisateurs : plusieurs langues à servir, des niveaux d'alphabétisation variables, des habitudes différentes selon les régions. Concevoir pour ce public, c'est tester sur le terrain plutôt qu'en salle de réunion, et accepter que la simplicité d'un menu en texte demande souvent plus de soin qu'une belle interface graphique.

Le servir au même niveau que l'app

La tentation, dans beaucoup d'équipes, est de soigner l'application mobile et de bâcler l'USSD, vu comme un reliquat. C'est une erreur d'analyse : sur la plupart des marchés que nous opérons, l'USSD porte la majorité du volume. Lui donner la même rigueur que l'app, la même supervision, les mêmes temps de réponse, ce n'est pas de la nostalgie. C'est servir les utilisateurs tels qu'ils sont.

Concevoir pour le terrain réel, c'est accepter que l'interface la plus moderne n'est pas toujours la plus utile. La meilleure plateforme n'est pas celle qui impose le dernier canal à la mode, c'est celle qui rejoint l'utilisateur là où il se trouve, avec le téléphone qu'il a et le réseau dont il dispose.