# Enka

> Enka est le projet de livraison de repas que j’ai cofondé à Montpellier. En tant que CTO, j’ai travaillé sur l’application et les outils qui l’entourent : données des restaurants, commandes, parcours des livreurs et interfaces entre ces différents usages. Il fallait faire fonctionner un produit pour les clients, les livreurs et l’équipe qui exploite le service.

Cofondateur et CTO · septembre 2024–aujourd’hui

Rubrique: Parcours

[Ouvrir dans le portfolio interactif](<https://zaki.somehow.engineer/#experience/9>)

[English](<https://zaki.somehow.engineer/read/en/enka.md>)

## En bref

| Indicateur | Valeur |
| --- | --- |
| Mon rôle | Cofondateur et CTO |
| Implantation | Montpellier, France |
| Impliqué depuis | Septembre 2024 |
| Produit | Android et iOS |

## Pourquoi j'ai rejoint le projet

Enka est parti de l'idée d'un ami. J'ai apporté mes compétences d'ingénieur pour aider à la concrétiser, et j'en partageais l'objectif : donner davantage de voix aux livreurs dans leur travail et construire un modèle plus juste pour eux comme pour les restaurants. Cela rejoignait ce qui m'avait donné envie de devenir ingénieur : pouvoir créer des solutions pour moi et pour les personnes autour de moi.

## Du choix du repas à sa réception

Enka est disponible sur Android et iOS. Son offre actuelle porte sur la livraison de repas à Montpellier aux prix à emporter des restaurants, sans commission pour ces derniers. Le client choisit un restaurant, compose son panier, paie par carte ou choisit les espèces à la livraison, puis suit la préparation et l'acheminement de sa commande. L'application propose aussi la commande sans compte et une messagerie avec le livreur.

Derrière ces écrans, il y a des restaurants, des livreurs et une équipe qui fait fonctionner le service au quotidien. Mon travail d’ingénieur portait sur ce lien : faire correspondre les informations et les actions de chacun.

### Images et médias

[La proposition de prix et la présentation d’un restaurant.](<https://zaki.somehow.engineer/content/assets/enka/enka1.webp>)

Visuel de présentation d’Enka montrant la proposition de prix et une page de restaurant.

Crédit: Visuels de présentation de l’application Enka.

[La recherche de restaurants et les modes de paiement.](<https://zaki.somehow.engineer/content/assets/enka/enka2.webp>)

Visuel Enka présentant la recherche de restaurants, les catégories et les modes de paiement.

Crédit: Visuels de présentation de l’application Enka.

[Le suivi de la préparation, de la livraison et du livreur.](<https://zaki.somehow.engineer/content/assets/enka/enka3.webp>)

Visuel Enka montrant les étapes de commande, l’heure d’arrivée et le suivi du livreur.

Crédit: Visuels de présentation de l’application Enka.

## Une commande, trois interfaces reliées

En tant que CTO, j’ai travaillé sur l’application et ses bases techniques : informations des restaurants, commandes, parcours des livreurs et administration. Le client qui commande, le livreur qui récupère le repas et la personne qui gère un incident doivent partager une vision cohérente de la situation.

La documentation de l’application distingue trois rôles : client, livreur et administrateur. Mon travail reliait leurs interfaces aux données et aux changements d’état communs. La stack comprend Next.js/React, Supabase/Postgres et Mapbox.

Next.js / React · Supabase / Postgres · Mapbox

Une vue simplifiée des trois rôles de l’application

1. **Client** — Parcourir les restaurants, composer un panier, commander et suivre la livraison.
2. **Livreur** — Accepter une course, récupérer la commande et mettre à jour son avancement.
3. **Équipe opérationnelle** — Maintenir les informations des restaurants et traiter les incidents de commande.

Synthèse des parcours décrits dans la documentation de l’application, et non schéma de déploiement.

## Rendre les informations des restaurants exploitables

En parallèle de l’application, j’ai développé des outils de collecte et de comparaison des cartes de restaurants. Un même plat peut avoir un nom différent, apparaître dans une autre rubrique ou utiliser un autre format de prix selon la source. Récupérer les pages ne résout donc qu’une partie du problème.

J’ai séparé la collecte, le rapprochement des plats et la comparaison. Cela permettait de revoir les correspondances approximatives en tenant compte des rubriques, puis de contrôler le résultat sans recommencer toute la collecte. Un benchmark documenté portait sur dix URL de restaurants aux structures différentes, avec un suivi des temps, des prix observés et des échecs. Il s’agissait aussi de comprendre les limites des données.

Des cartes sources à une comparaison vérifiable

1. **Collecter** — Récupérer la structure des cartes, les noms des plats et les prix de chaque source.
2. **Rapprocher** — Comparer les plats au sein de leurs rubriques malgré les différences de noms.
3. **Vérifier** — Relire la comparaison et revenir sur les correspondances ambiguës.

Travail complémentaire documenté dans UltimateScrapeV1 ; échantillon du benchmark : dix URL de restaurants.

## Comprendre la livraison derrière l’application

Le business plan de l’équipe étudie un modèle de relais en vélo-cargo à Montpellier : récupérer les commandes dans le centre piéton, les regrouper à des points de collecte, puis confier la suite du trajet aux livreurs. Ce travail aide à comprendre les besoins de coordination auxquels le logiciel doit répondre.

Le document présente une simulation AnyLogic de cette organisation. Il indique une livraison plus rapide pour 60 % des commandes simulées, un temps équivalent pour 29 % et un retard pour 11 %. Parmi ces dernières, les retards supérieurs à cinq minutes représentent 5 % de l’ensemble des commandes simulées. Ces résultats font apparaître le bénéfice potentiel, mais aussi les situations qui restent à améliorer.

| Valeur | Indicateur |
| --- | --- |
| 60 % | Livraison plus rapide |
| 29 % | Temps équivalent |
| 6 % | Autres retards |
| 5 % | Retard supérieur à cinq minutes |

> Simulation historique de l’équipe, pas mesure des livraisons réelles. Le business plan fourni ne précise ni l’ensemble des paramètres d’exécution ni la taille de l’échantillon. La modélisation logistique est créditée à l’équipe Enka.

### Images et médias

[Répartition des délais dans la simulation présentée par l’équipe.](<https://zaki.somehow.engineer/content/assets/enka/case-study/delivery-simulation.png>)

Simulation historique : 60 % plus rapides, 29 % équivalentes, 6 % de retard acceptable et 5 % de retard supérieur à cinq minutes.

Crédit: Équipe Enka · Enka Business Plan, p. 22–23. Simulation historique.

[La scène de simulation documentée rue Saint-Guilhem.](<https://zaki.somehow.engineer/content/assets/enka/case-study/montpellier-simulation.jpg>)

Capture de la simulation montrant les agents de livraison rue Saint-Guilhem, à Montpellier.

Crédit: Enka Business Plan, p. 19 · carte © contributeurs OpenStreetMap.

[Une comparaison des émissions modélisées dans l’étude logistique.](<https://zaki.somehow.engineer/content/assets/enka/case-study/emissions-simulation.jpg>)

Courbe issue du modèle comparant les émissions de composés organiques volatils avec et sans vélos-cargos.

Crédit: Équipe Enka · Enka Business Plan, p. 23. Sortie de modèle, sans mesure des émissions dans la rue.

## Travailler avec l’équipe visuelle

J’ai également contribué à l’UX/UI de l’application et participé aux échanges visuels : proposer des idées, demander des révisions et réfléchir au lien entre l’application et sa présentation. Le design était un travail collectif. Amandine Basset a contribué à l’UX/UI, et Rouge Studio a travaillé sur l’identité visuelle et la communication.

Les documents du studio explorent trois pistes : l’emboîtement, la culture du vélo et le mouvement. Cette dernière relie la personne qui livre, les roues du vélo et les relations entre les acteurs du service. Le dossier stratégique prolonge cette idée dans le brief créatif : rendre visibles les personnes derrière une livraison, tout en gardant une expérience simple.

### Images et médias

[Le raisonnement derrière la piste « Mouvement ».](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-movement.jpg>)

La piste Mouvement de Rouge Studio relie le livreur, les roues de vélo et les relations au sein d’Enka.

Crédit: Rouge Studio — Luna Martin, Yasmine Bourhan et Maxine Mulot. Understanding Empathy ENKA, p. 19.

[Des applications de l’identité sur des maquettes de produits et de sacs de livraison.](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-applications.jpg>)

Propositions d’identité Enka appliquées à une gourde et à des sacs de livraison.

Crédit: Rouge Studio — Luna Martin, Yasmine Bourhan et Maxine Mulot. Understanding Empathy ENKA, p. 23. Maquettes de concept.

[Des propositions de communication qui remettent le livreur au premier plan.](<https://zaki.somehow.engineer/content/assets/enka/case-study/brand-campaign.jpg>)

Propositions de communication Enka avec un portrait de livreur et un sac de repas.

Crédit: Rouge Studio — Luna Martin, Yasmine Bourhan et Maxine Mulot. Understanding Empathy ENKA, p. 24. Maquettes de concept.

## Où en est le projet, et ce que j’en retiens

L'application est disponible publiquement. L'équipe cherche à développer la traction nécessaire à un premier financement en pré-seed. Je reste impliqué, avec moins de développement au quotidien pendant cette phase.

Enka a élargi le périmètre de mon travail d'ingénieur. Un écran, un statut de commande et la prochaine action d'un livreur doivent être cohérents entre eux. Construire le produit, c'était réfléchir à ces liens et travailler avec des personnes qui apportaient d'autres compétences que les miennes.

## Liens

- [Visit Enka](<https://enkalivre.fr/>)
- [Android](<https://play.google.com/store/apps/details?id=com.enka.client>)
- [iOS](<https://apps.apple.com/fr/app/id6803603934>)
