Kooko livrait les plats de restaurants lausannois. Ils étaient cuisinés sur place, transportés à vélo par des coursiers salariés et conditionnés dans des emballages compostables. Au départ, nous livrions le repas du soir à des particuliers. Puis les commandes sont devenues collectives, le midi a remplacé le soir et les entreprises sont devenues nos clientes.
Kooko était aussi notre propre société. Nous l’avons cofondée et avons développé chacune de ses versions. Ce récit n’est donc pas celui d’un mandat classique, mais celui de cinq années pendant lesquelles le métier a évolué plus vite que la plateforme. Elles nous ont surtout appris qu’une bonne architecture ne le reste pas éternellement : il suffit parfois que le client change pour qu’elle ne réponde plus au bon problème.
Au début, nous livrions le dîner d’une personne
La première promesse était volontairement étroite : Lausanne, le soir, des plats préparés par les restaurants de la ville et livrés à vélo. Nous ne cherchions pas encore à bâtir une place de marché universelle. Il fallait lancer rapidement, limiter les frais d’infrastructure et rendre un petit catalogue instantané sur mobile.
Nous avons donc compilé toute la boutique avec Gatsby. Sylius fournissait les produits, les restaurants, les catégories et les canaux de vente au moment du build. Capacitor emballait ensuite le même résultat pour le web, l’App Store et le Play Store.
{ resolve: "gatsby-source-custom-api",
options: { url: process.env.GATSBY_SYLIUS_CHANNEL_URL, rootKey: "SyliusChannel" } },
{ resolve: "gatsby-source-custom-api",
options: { url: process.env.GATSBY_SYLIUS_PRODUCT_URL, rootKey: "SyliusProductBeta" } },
{ resolve: "gatsby-source-custom-api",
options: { url: process.env.GATSBY_SYLIUS_VENDOR_LAUSANNE, rootKey: "SyliusVendor" } },Un catalogue statique peut sembler étrange lorsque les restaurants modifient régulièrement leur carte. Nous avions prévu une autre voie que la publication d’une nouvelle version mobile : chaque build produisait un paquet web téléchargeable, et l’application vérifiait sa disponibilité pendant la navigation. Une nouvelle carte demandait ainsi un build et une mise à jour légère, pas un nouveau passage par les boutiques d’applications.
Un restaurant ne devrait pas attendre Apple pour modifier sa carte.
Seuls les stocks, le panier et le paiement restaient dynamiques. Pour une seule ville et un unique service quotidien, cette solution était rapide, peu coûteuse et suffisamment simple. Ses limites correspondaient encore à celles du métier : le soir était inscrit dans le build et un panier ne pouvait contenir les plats que d’un restaurant. Une cuisine, un sac, un vélo — à l’époque, cela avait tout son sens.
Puis la commande est devenue collective
Le minimum de commande a changé la donne. Une personne seule l’atteignait rarement ; trois collègues réunis autour d’une table, presque toujours. Mais trois collègues ne choisissent pas forcément le même restaurant, et un panier rempli à plusieurs ne peut pas rester enfermé dans le navigateur de l’un d’eux.
La deuxième application Kooko s’est donc construite autour d’une commande partageable, enregistrée côté serveur. Une personne lançait le panier, envoyait le lien à ses collègues et chacun y ajoutait son repas, y compris depuis un autre restaurant. La commande pouvait être confirmée dès que le groupe atteignait le minimum.
Nous avons également séparé l’éditorial du transactionnel. Strapi permettait à l’équipe de faire évoluer les cartes et les pages des restaurants au rythme du contenu. Medusa gardait la responsabilité des produits, des prix, des paniers et des paiements. Chaque restaurant disposait de sa propre boutique et de ses accès, tandis qu’une relation légère reliait sa carte éditoriale aux produits vendus.
Quand toute une table remplit le panier, celui-ci devient une fonctionnalité du produit.
L’interface a évolué avec la manière de commander. La première application demandait quel plat manger ce soir. La deuxième aidait un groupe à choisir parmi plusieurs cuisines et restaurants. Nous n’avons pas changé de technologie par envie de reconstruire, mais parce que le comportement des clients avait réellement changé.
L’employeur est devenu le client
L’étape suivante est venue de l’économie des tournées. Livrer cinquante repas à cinquante domiciles exige cinquante trajets. Les déposer dans un seul immeuble de bureaux n’en demande qu’un. Cet écart a fait basculer Kooko de la livraison de repas aux particuliers vers une offre de restauration destinée aux entreprises.
Ajouter un simple compte professionnel à la boutique publique n’aurait pas suffi. Chaque société devait retrouver ses propres restaurants, ses tarifs négociés, ses moyens de paiement et ses règles de commande. Nous avons créé un portail dédié dont le contexte commençait dans l’adresse : le segment de l’entreprise déterminait son catalogue, son groupe client, son abonnement et son parcours de paiement.
company: defineRoute('/[companySlug]', {
params: z.object({ companySlug: z.string() }),
}),
cart: defineRoute('/[companySlug]/cart', {
params: z.object({ companySlug: z.string() }),
search: z.object({ cart_id: z.string().optional() }).default({}),
}),Les collaborateurs accédaient ainsi à une expérience propre à leur entreprise. Certaines sociétés réglaient sur facture ; d’autres proposaient la carte ou Twint. Le choix de restaurants pouvait être restreint aux environs immédiats du bureau ou couvrir un secteur plus large. Quant à la commande partagée de l’application précédente, elle est devenue un système de devis et de précommandes adapté aux validations d’une entreprise.
L’automatisation derrière ce portail était l’une des grandes réussites du projet. Une société qui nous contactait depuis le site pouvait être qualifiée, devenir un prospect, recevoir sa propre fiche et son portail, puis commencer avec une sélection de restaurants proches de ses bureaux.
Mais chaque réponse apportée au métier avait aussi alourdi le système. ERPNext gérait les abonnements, les règles tarifaires et les stocks. Medusa s’occupait du commerce, Strapi du contenu, Directus des opérations, de la logistique et des vues internes. n8n assurait les échanges entre les quatre. Cette architecture était pertinente pour vérifier que les entreprises voulaient réellement acheter ce service. Elle ne l’était plus lorsqu’il a fallu envisager l’ouverture de plusieurs villes.
Genève nous a obligés à reformuler le problème
À la question « combien coûte Genève ? », notre architecture répondait : un nouveau déploiement, une nouvelle instance de commerce, un nouveau schéma et un nouveau portail. Nous avions transformé chaque marché en infrastructure ; grandir signifiait recopier le système.
En 2022, chaque client recevait son propre back-end et sa propre base de données. 
En 2025, chaque ville impliquait encore une nouvelle instance de commerce, un schéma et un portail.
Les outils confortaient cette vision. La première version majeure de Medusa ne prévoyait qu’une boutique par installation. Nous avions déjà dû retirer une contrainte de base de données pour héberger plusieurs restaurants. C’était un signal très clair : le modèle de Kooko avait dépassé celui que la plateforme savait représenter.
Un deuxième marché devrait ajouter des données, pas de l’infrastructure.
La quatrième architecture est partie de ce principe. Une ville, un restaurant, une entreprise, un coursier, une carte ou un devis devaient devenir des fiches au sein d’une même plateforme. Les relations devaient remplacer les synchronisations, et l’ouverture d’une ville devait relever de la configuration plutôt que d’un déploiement parallèle.
Cette fois, notre ambition était d’écrire moins. La deuxième version de Medusa fournissait un socle de commerce modulaire. Mercur prenait déjà en charge les vendeurs, la séparation des commandes et les reversements. Une base B2B existante couvrait les entreprises, les collaborateurs, les validations et les devis. Notre travail consistait à réunir ces éléments et à ne développer que ce qui appartenait vraiment à Kooko : les cartes, les coursiers et les tournées.
Ce que Kooko a changé dans notre manière de construire
Genève devait valider ce quatrième modèle avant que Lausanne ne rejoigne la nouvelle plateforme. Kooko a cessé son activité avant ce lancement. Cette architecture est donc restée un projet plutôt qu’une réussite en production, mais le raisonnement qui l’a façonnée compte parmi les enseignements les plus utiles de l’aventure.
Ces cinq années nous ont appris qu’une architecture n’est pas l’expression définitive d’une préférence technique. Elle répond à une clientèle, à une circulation de l’argent et à ce que l’entreprise doit pouvoir répéter. L’application statique convenait à une ville et à une offre du soir. Le panier partagé répondait aux commandes entre collègues. Le portail professionnel a permis de valider le modèle B2B. La plateforme multimarche n’est devenue nécessaire que lorsque Genève a révélé le coût réel de la duplication.
Cette expérience guide encore nos choix. Pour le Cabinet des Alpettes, la bonne réponse était le CMS le plus léger capable de rendre le cabinet autonome. Pour Autocorner, il fallait une couche de données commune pour réunir marques, centres et stock en temps réel. Kooko nous a appris à reconnaître cette différence suffisamment tôt — et à ne construire que la plateforme dont la prochaine étape réelle a besoin.