Barka Energies, du tableau de bord au terminal de paiement

Un projet de remplacement ne commence pas par une page blanche. TOMCARD fonctionnait, les cartes circulaient, les stations encaissaient. Ce qu’il fallait, c’était la même chose en propre : une plateforme de gestion et de paiement de cartes carburant qui garantisse l’autonomie technologique de l’entreprise.

Cette phrase a deux conséquences pour un designer. D’abord, on ne conçoit pas pour des gens qui découvrent un usage, mais pour des gens qui en ont déjà un et qui compareront. Ensuite, le périmètre déborde du logiciel : le projet avait un volet matériel, les terminaux et l’infrastructure, mené en parallèle du volet logiciel. Un écran dessiné sans savoir sur quelle machine il tournera est un écran dessiné à moitié.

Avant le premier écran, j’ai posé quatre contraintes, et elles ont tenu jusqu’à la fin :

Double cible utilisateur. Il faut concevoir pour des administrateurs internes, avec des besoins complexes et des tableaux de bord riches, et pour des clients finaux, avec des besoins simples : rapidité et clarté.

Domaine métier spécifique. Le secteur des cartes carburant est réglementé et comporte ses propres spécificités. Il faut comprendre ce métier pour en faire une interface intuitive.

Sécurité et confiance. Une plateforme monétique gère de l’argent. Le design doit inspirer confiance par une esthétique soignée, des messages clairs, et de la transparence sur les transactions.

Synchronisation du logiciel et du matériel. La vision design doit englober l’ensemble du parcours, pas seulement la partie qui s’affiche.

La première décide de tout le reste. Il y avait cinq applications à concevoir : un back office, une application pour le terminal de paiement, une application mobile pour les clients particuliers, une application web pour les gérants de stations, une application web pour les entreprises. Elles ne s’adressent pas au même monde. L’entreprise cliente gère un parc de cartes : elle en commande, elle les recharge, elle suit ses transactions. Le particulier veut savoir combien il lui reste. Le gérant surveille sa station. Trois métiers, et le même argent.

Cette étude en montre trois : le terminal, l’espace du gérant, et l’application du client.

Je n’ai pas découpé le travail par machine, mais par personne. Un client ne vit pas « l’application mobile » puis « l’application du terminal » : il regarde son solde sur son téléphone, il paie sur un terminal qui ne lui appartient pas, et il retrouve la transaction sur son téléphone le soir. Un seul parcours, deux machines.

Découper par support aurait donné cinq applications cohérentes chacune de son côté, et aucune continuité pour celui qui les traverse. C’est pour ça que mes deux parcours portent des noms de gens, et non des noms d’écrans.

Le client particulier entre par son numéro de téléphone, reçoit un code à six chiffres, puis crée ou saisit un code PIN. Pas de mot de passe, pas d’adresse email : sur ce marché, le numéro de téléphone est l’identité la plus fiable dont on dispose.

Le gérant de station entre, lui, par email et mot de passe, et arrive sur une vue générale des paiements et des terminaux. Trois branches partent de là : le suivi des paiements, avec les montants, les heures et le pompiste ; le tableau de bord des terminaux, avec leurs transactions, leur statut (actif ou hors ligne) et les anomalies détectées ; et les paramètres, d’où il ajoute un pompiste avec sa date de début de service.

Deux portes différentes pour deux publics, décidées avant qu’un seul pixel soit posé. Ces fichiers-là ne sont jamais ceux qu’on montre, et c’est dommage : ce sont eux qui évitent de dessiner deux fois.

Le terminal est l’endroit où les deux parcours se croisent. Le pompiste le tient, le client y insère sa carte et y tape son code : deux personnes sur la même machine, debout, en quelques secondes. C’est aussi le support le plus contraint des trois. Pas de clavier, pas de souris, pas de seconde chance.

Un détail le dit mieux que le reste : le champ du code n’est pas intitulé « code PIN », mais Code PIN client. L’écran sait que celui qui le tient n’est pas celui qui tape.

Son écran d’accueil tient en cinq lignes : Ventes, Recharges, Administrateur, Clôture, Téléconnecter. Les trois premières sont pleines, les deux dernières ne sont qu’un contour : ce ne sont pas des opérations de vente, mais des opérations de fin de journée. La hiérarchie le dit sans un mot d’explication.

Le reste du parcours ne demande jamais deux choses à la fois. Un écran pour insérer la carte, et une illustration plutôt qu’une phrase, parce qu’un geste se montre mieux qu’il ne s’écrit. Un écran pour le récapitulatif, où le mode de paiement, les produits, les litres et le total arrivent dans cet ordre. Un écran pour le code PIN, dont le pavé numérique occupe toute la moitié basse.

Cette moitié basse n’est pas une facilité. Un pavé de cette taille, c’est la garantie qu’on tape juste du premier coup, debout, sans regarder. Et sur ces douze touches, les deux seules qui ne sont pas un chiffre sont les deux seules qui ont une couleur : l’effacement en rouge, la validation en bleu plein.

Une station n’a pas toujours de réseau. C’est une donnée du terrain, pas un incident, et une plateforme de paiement qui l’ignore ne tient pas une journée.

Le terminal a donc un écran qui ne ressemble à aucun autre : les transactions en attente, le total collecté, et la date de la dernière collecte. Quand il n’y en a jamais eu, l’écran affiche Jamais en gros, avec Action requise à côté. Chaque transaction retenue porte son numéro, son type (achat, vente, échange) et son heure. En bas, un seul bouton : Collecter.

Et sur le tableau de bord du gérant, TPE hors ligne est une tuile, posée juste à côté de TPE actifs. Hors ligne n’est pas un message d’erreur qu’on affiche quand ça arrive : c’est un chiffre qu’on surveille. De tout le projet, c’est la décision que je trouve la plus juste.

Côté gérant, c’est l’autre extrémité de la première contrainte : de la densité, assumée. Quatre indicateurs en haut, le volume de paiements mois par mois, puis les transactions récentes : client, référence, terminal, montant, date et heure, statut.

Tout est triable, tout est paginé, et la recherche se fait par terminal ou par référence, c’est-à-dire par les deux seules choses qu’on a sous la main quand un client réclame.

Les statuts sont trois, et ils sont nommés : complété, non complété, en attente. Pas deux. « En attente » est un état légitime dans ce métier, et le confondre avec un échec ferait prendre de mauvaises décisions à celui qui lit l’écran.

Et puis il y a les pompistes. Chaque paiement porte le nom de celui qui l’a encaissé, et le gérant les gère depuis ses paramètres : il en ajoute un avec sa date de début de service, et chacun porte un statut : actif, inactif, en congés.

Rattacher l’argent à une personne n’est pas une décision d’interface, c’est une décision de responsabilité. L’interface se contente de la rendre lisible. Mais si elle ne l’avait pas rendue lisible, la décision n’aurait servi à rien.

L’écran d’entrée du particulier promet une chose, et une seule : prendre en main sa consommation de carburant. Un seul bouton en dessous.

Derrière, l’accueil est bâti autour du solde, un nombre qu’on lit à bout de bras, puis de la carte elle-même, et enfin des dernières transactions, chacune avec sa station et son montant. Quatre onglets en bas, pas davantage.

Une transaction n’a pas la même forme selon qui la regarde. Le gérant en voit la référence, le terminal et le statut, parce qu’il doit pouvoir la retrouver. Le client en voit un nom de station et un montant, parce qu’il veut seulement se souvenir. Un même événement, deux lectures : c’est à cela que sert d’avoir posé la double cible comme une contrainte, et non comme une remarque.

Cinq applications sur trois supports ne tiennent ensemble que par une bibliothèque partagée. Un bouton n’y est pas dessiné une fois mais trois : au repos, enfoncé, désactivé. Les cases du code PIN ont leur état vide et leur état rempli. Les champs ont leur version au repos et leur version active. L’indicatif téléphonique a sa pastille et sa ligne de liste.

Et puis il y a la carte de produit, avec un carburant, son prix au litre, des pastilles de volume et un champ de quantité. C’est le composant le plus métier de tous, et le seul qui ne pourrait servir dans aucun autre projet.

Dessiner les états avant les écrans, c’est ce qui fait qu’on ne discute plus de l’apparence du dixième bouton. Sur un projet à cinq applications, ce n’est pas un confort : c’est la seule façon que le dernier écran ressemble encore au premier.

La conception a été livrée : les parcours, les écrans des trois supports, la bibliothèque. Le développement n’a pas suivi, et je préfère l’écrire que le laisser deviner.

Ce projet ne prouve donc pas qu’une plateforme tient en production. Il prouve autre chose : la capacité à tenir un système entier dans une seule tête. Cinq applications, trois supports, deux publics qui n’ont rien en commun, un métier réglementé, et du matériel à l’autre bout. C’est le genre de projet dont la difficulté n’est jamais dans l’écran qu’on regarde, mais dans ce qui doit rester vrai d’un écran à l’autre.