Nzoko Transport

Le problème

Acheter une place dans un bus entre deux villes demande trois choses qu’on trouve rarement au même endroit. Voir en quelques secondes la ligne, l’horaire et le prix. Payer avec le moyen qu’on a réellement dans la poche. Et garder une preuve d’achat que le contrôleur peut vérifier au départ, sans papier à conserver.

De l’autre côté du guichet, une compagnie a le problème inverse : savoir à tout moment quels bus roulent, avec quels chauffeurs, combien de places sont vendues et ce que cela rapporte.

Ce sont deux publics qui n’ont ni les mêmes écrans, ni les mêmes réflexes. Un seul outil ne peut pas les servir tous les deux correctement.

Ce que j’ai construit

Nzoko Transport est un transporteur interurbain qui relie Brazzaville, Pointe-Noire, Dolisie, Nkayi et Ouesso. J’ai réalisé trois interfaces, chacune pour son public.

• Le site vitrine : accueil, lignes et horaires avec recherche par ville de départ et d’arrivée, agences par ville, page À propos, aide en questions fréquentes, mentions légales. Il propose un thème clair et un thème sombre, et un parcours de réservation en trois étapes : connexion, paiement, billet.
• L’application voyageur : une application web installable. Introduction, connexion par téléphone et code SMS, recherche, choix du départ, plan des sièges, paiement par MTN Mobile Money, Airtel Money ou carte, puis billet avec QR code et liste de ses billets, actifs et passés. Le billet se partage et s’imprime depuis le navigateur.
• Le back-office : réservé à l’équipe. Tableau de bord, voyages, flotte, personnel avec chauffeurs et contrôleurs, billets et validations, rapports, édition du contenu du site public et paramètres de la société.

Les trois portent la même identité. Le vert nuit et l’or ne sont pas choisis au goût : je les ai relevés pixel par pixel sur le logo fourni, puis j’ai calculé le reste de la palette autour.

Les choix techniques, et pourquoi

Trois interfaces séparées plutôt qu’une application unique

Un voyageur sur téléphone veut un écran léger qui s’installe. Une équipe au bureau veut des tableaux denses et de grands écrans. Le site public, lui, doit se charger vite et se laisser indexer. Regrouper les trois dans une seule application aurait obligé chacune à porter le poids des deux autres.

Le compromis est réel : trois bases de code à garder cohérentes. Je le paie en partageant les mêmes couleurs, les mêmes logos et les mêmes règles de contraste, et en corrigeant une fois pour vérifier trois fois.

Une application web installable pour le voyageur

Même raisonnement que pour One Zone, avec une nuance. L’application s’ajoute à l’écran d’accueil depuis le navigateur, sans passer par un magasin, et son enveloppe est mise en cache par un service worker. Ouvrir l’application ne demande donc pas de télécharger quoi que ce soit de nouveau. Acheter un billet, lui, demandera toujours du réseau, et je ne prétends pas le contraire.

Le contraste se mesure, y compris sur une identité dorée

L’or vif du logo est superbe sur fond sombre et illisible en texte sur fond blanc : il n’atteint pas le rapport de 4,5 pour 1 que demande le niveau AA. J’ai donc introduit un second ton d’or, plus foncé, réservé au texte sur fonds clairs, et mesuré chaque combinaison finale. Le logo garde sa couleur exacte, le texte reste lisible.

Un audit avant chaque livraison, pas après

Le plus instructif n’est pas ce que j’ai écrit, mais ce que j’ai trouvé en relisant. Sur le site, la barre de recherche des lignes ne faisait rien : les listes n’étaient reliées à aucun état et le bouton n’avait pas d’action. Dans l’application, la date du billet était figée, quelle que soit la date cherchée. Dans le back-office, modifier un chauffeur en créait un second, et supprimer un voyage ne demandait aucune confirmation.

Aucun de ces défauts ne se voit sur une capture. Tous se voient au premier usage.

Ne charger les graphiques que si on les ouvre

Les rapports du back-office reposent sur une bibliothèque de graphiques qui pesait à elle seule plus que tout le reste. En la chargeant seulement à l’ouverture de cette page, le poids initial est passé de 670 Ko à 288 Ko. Un tableau de bord qu’on ouvre pour voir les départs du matin n’a pas à payer pour des courbes qu’on ne regardera peut-être pas.

Où ça en est

Les trois interfaces sont terminées côté écran et en ligne. Elles tournent sur des données de démonstration : il n’y a pas encore de base de données, le code SMS n’est pas vérifié, le paiement est simulé et la connexion du back-office accepte n’importe quelle saisie.

Je l’écris tel quel. Une capture prouve qu’une interface existe, pas qu’une compagnie s’en sert.

J’ai choisi cet ordre exprès : tout le front d’abord, la base ensuite. Les écrans obligent à nommer les objets, voyage, billet, siège, chauffeur, avant d’écrire une seule table, et la base de données, PostgreSQL sur Supabase, sera dessinée à partir d’écrans validés plutôt que l’inverse.

Ce que ce projet m’a appris

Qu’une identité visuelle est un système avant d’être un logo. Trois interfaces qui partagent un vert et un or se reconnaissent tout de suite, mais seulement si chaque couleur a une valeur relevée, une valeur pour le texte et une valeur pour l’arrière-plan, et non une teinte approximative recopiée à l’œil.

Qu’un bouton qui ne fait rien est pire qu’un bouton absent. Une démonstration qui se laisse casser au premier clic ne démontre rien, et la relecture ligne à ligne d’une interface est le seul moyen de le savoir avant l’utilisateur.

Et que dire clairement ce qui est simulé rend le reste crédible.