Plateforme opérationnelle Dieture

Une opération qui couvre une cuisine, une chaîne de conditionnement, une flotte de livraison et un support produit la même information quatre fois, à quatre endroits. Avant la plateforme, chacun de ces maillons tournait sur son propre outil — tableurs, fils de discussion, feuilles imprimées — et aucun ne concordait avec les autres.

Le coût se voit aux questions auxquelles personne ne peut répondre vite : où en est cet abonnement dans le cycle du jour, pourquoi cette livraison a échoué, quelle quantité de cet ingrédient il faut pour demain. Au-delà de 10 000 clients actifs, les écarts entre outils ont cessé d'être une gêne pour devenir la limite à la croissance.

Un backend en microservices porte le domaine — abonnements, clients, menus, stock, livraisons — et chaque surface au-dessus n'est qu'un client fin, propre à un rôle, sur ce modèle unique. Aucune règle métier n'est réimplémentée dans une application.

Chaque application métier est volontairement étroite. Un chef en plein service, un préparateur sur la chaîne et un livreur avec son téléphone dans une main n'ont pas besoin du même écran, et aucun n'a besoin d'un écran généraliste. Chaque application répond à la seule question que son utilisateur se pose à cet instant.

• Application cuisine — les besoins de production par service, dérivés des données d'abonnement en direct vers ce qu'il faut réellement cuisiner
• Application préparateur — la file de la chaîne de conditionnement, article par article, avec la vérification intégrée au flux
• Application livreur — la tournée et les arrêts du jour, pensée pour un usage à une main en véhicule
• Tableau de bord backoffice — la surface de contrôle sur l'ensemble

C'est le tableau de bord qui a remplacé le plus d'outils. Un ERP et un CRM sur mesure en un : abonnements et historique complet, progression client, livraisons, conditionnement, flux de cuisine, comptes revendeurs B2B, et collecte interne des réclamations et retours — avec la configuration qui pilote toutes les autres applications de la plateforme.

Deux parties ont demandé le plus de travail. La couverture de livraison est modélisée en zones géographiques éditables plutôt qu'en liste de secteurs acceptés : les opérations redessinent ce qui est livrable sans développeur. Et chaque action significative écrit une entrée de journal structurée, ce qui a transformé le « pourquoi est-ce arrivé » d'une enquête en une requête.

• Cartographie de la couverture de livraison, éditable par l'équipe opérationnelle
• Cycle de vie de l'abonnement — pauses, changements de formule, renouvellements et historique client sur une seule frise
• Comptes revendeurs B2B aux côtés des abonnements grand public
• Thématisation et configuration avancées, propagées jusqu'aux applications métier
• Journalisation structurée détaillée et vision opérationnelle en temps réel

J'ai fortement contribué au backend et porté de larges pans du tableau de bord pendant trois ans — les fonctionnalités complexes plutôt que les écrans : la cartographie de couverture, la couche de configuration, la gestion des états d'abonnement, et la journalisation qui a rendu le reste débogable.

Construire là où un bug a une conséquence physique change la manière de travailler. Un mauvais chiffre dans l'application cuisine, c'est de la nourriture perdue ; une mauvaise tournée, c'est un client qui ne mange pas ce jour-là. C'est la discipline que cette base de code m'a apprise.