Produit · web
QuickEat
Le client commande depuis sa table, la salle suit en direct, le patron pilote depuis son téléphone.
quickeat.bj
Le problème
Dans un maquis ou une brasserie de Cotonou, une commande fait plusieurs allers-retours : le client appelle, le serveur note sur un bout de papier, la cuisine attend ce papier.
Les bons se perdent entre le passe et la table, l’addition d’une tablée qui a pris trois tournées se reconstitue de mémoire, et le patron ne sait ce qui s’est vendu qu’en fin de journée.
Ce qui a été construit
QuickEat relie les trois acteurs de la salle. Le paiement, lui, reste au restaurant : le client règle comme il l’a toujours fait, le serveur note seulement le mode de paiement.
Ma part
Au sein de l’équipe Layers-Tec, j’ai développé l’interface web : la carte côté client, l’écran de salle des serveurs et le back-office du manager.
J’ai aussi contribué à plusieurs évolutions de l’API FastAPI.
Les choix qui comptent
Le contrat d’API fait foi
Les types TypeScript de l’interface sont générés depuis le schéma OpenAPI de l’API, jamais écrits à la main. Un champ renommé côté serveur casse la compilation, pas l’écran d’un client.
Pensé pour une salle pleine
Zones tactiles de 44 px minimum, 52 px sur la tablette des serveurs, qu’on utilise debout et pressé. Un statut porte toujours un mot en plus de sa couleur.
Un seul vocabulaire
Les statuts viennent de l’API et sont traduits une seule fois, au même endroit. Le client, la salle et le manager lisent les mêmes mots pour la même commande.
Où en est le projet
En bêta depuis septembre 2026, avec des restaurants pilotes à Cotonou.