Cofondateur et CTO · septembre 2024–aujourd’hui
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.
- 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.



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.
Une vue simplifiée des trois rôles de l’application
- Client — Parcourir les restaurants, composer un panier, commander et suivre la livraison.
- Livreur — Accepter une course, récupérer la commande et mettre à jour son avancement.
- Équipe opérationnelle — Maintenir les informations des restaurants et traiter les incidents de commande.
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
- Collecter — Récupérer la structure des cartes, les noms des plats et les prix de chaque source.
- Rapprocher — Comparer les plats au sein de leurs rubriques malgré les différences de noms.
- Vérifier — Relire la comparaison et revenir sur les correspondances ambiguës.
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.
- Livraison plus rapide
- 60 %
- Temps équivalent
- 29 %
- Autres retards
- 6 %
- Retard supérieur à cinq minutes
- 5 %



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.



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.