Les règles du plan de menu
Ce que le générateur décide pour chaque client, section par section, règle par règle.
16 sections · sections repliées, ouvrez celle qu'il vous faut
Le parcours d'un CDC
| Étape | La question que le générateur se pose |
|---|---|
| 1 | Est-ce qu'on a le droit de générer ? Les ventes Talabat et le menu déposé racontent-ils le même restaurant ? |
| 2 | Dans quel ordre le client lit-il la carte ? Signature en premier, puis ce qui se vend. |
| 3 | Que retire-t-on ? Jamais une catégorie entière en silence, jamais le meilleur d'une catégorie. |
| 4 | Quels plats portent la carte ? Ceux que le client a déclarés, puis ceux qui se vendent. |
| 5 | Quel prix bouge, et pourquoi ? Seulement sur un défaut nommé. |
| 6 | Comment chaque fiche est-elle rédigée ? Trouvable, honnête, concrète. |
| 7 | Que propose-t-on avec un plat ? Un supplément, une version plus généreuse, un autre plat — trois blocs, jamais mélangés. |
V · Le verrou
| # | Règle | Constat d'origine |
|---|---|---|
| V1 | Une vente Talabat de 3 unités ou plus sans plat au menu bloque la génération. L'équipe la rapproche d'un plat existant ou l'ajoute au menu (fiche client, bloc Données) ; le lien est écrit en base et retenu pour les prochains imports. | Lets Bowl 11/09 : « A+ Eco Chicken Rice Bowl » vendu 19 fois, « Yoghurt Power Bowl » 12 fois, absents du menu que le CDC proposait. Le document du 09/09 les listait « à rapprocher » en priorité n°1 — et proposait quand même un menu sans eux. |
| V3 | La vitrine en ligne est la référence du menu actuel (décision Mehdi 12/09 : « tu prends le prix Talabat, base-toi sur le menu Talabat ») : noms, catégories, prix de liste et descriptions viennent du relevé de la vitrine ; les sections « Picks for you » et « Offers » sont des vues, pas des catégories ; un plat de la carte imprimée absent en ligne est archivé, sauf s'il s'est vendu au moins 3 fois sur la période — il reste et sort en décision « à relister ? ». Tout écart entre la vitrine et le menu importé se signale plat par plat, jamais fusionné en silence (catalogue du 14/09). | Lets Bowl : le PDF disait 46 AED pour le Teriyaki, Talabat 65,9 ; 31 fiches café/thé sur le PDF, 7 en ligne ; Salmon Sautée vendu 49 fois, absent de la vitrine du 12/09. scripts/importer-menu-talabat-lets-bowl.ts, relevé lib/cdc/fixtures/lets-bowl-talabat-12-09.json. |
| V2 | Une vente orpheline de moins de 3 unités ne bloque pas : elle reste visible dans l'écran de rapprochement, à traiter quand l'équipe a le temps. | Même cas : « Pepsi » 1 vendu, « Açaí Bowl » 1 vendu — un geste par ligne aurait bloqué la génération sur des miettes. |
| V4 | Un plat au menu sans vente n'est une anomalie que si les ventes ont assez parlé (mode ventes, G3) : en mode structure, une absence de vente dit une absence d'exposition, pas une absence de demande. | Catalogue du 14/09 (sa règle V3, renumérotée : V3 désigne ici la vitrine de référence). Lets Bowl, seul client avec des ventes le 14/09 : 553 commandes, mode structure. |
S · La structure
| # | Règle | Constat d'origine |
|---|---|---|
| S1 | La catégorie qui porte les plats signature ouvre le menu ; les autres suivent par commandes décroissantes ; celles sans vente ferment. L'ordre proposé au client est celui-là, et la colonne « Proposé » le suit partout. | CDC Lets Bowl 09/09 : l'ordre proposé était l'ordre du menu actuel, « Combos & Deals » en deuxième position avec 0 vente. |
| S2 | Une catégorie sous 1 % des commandes ne reste jamais seule : le modèle la fusionne avec une voisine cohérente, ou le document la pose en question au client. Le contrôle de cohérence avertit si une telle catégorie reste isolée. | Lets Bowl : « SUPER COMBO » (1 plat, 0 vente), « Other » (1 plat, 3 ventes) rendues en sections à part entière. |
| S3 | Une catégorie sans aucune vente sur la période ne rejoint jamais une catégorie qui vend, et n'est pas retirée : c'est une décision du client — garder, réduire aux meilleures références, ou retirer — posée dans le document avec le nombre de plats concernés. Plusieurs catégories sans vente de même nature peuvent se regrouper entre elles (« Coffee & Tea ») ; la destination porte alors la question. Une catégorie faible rejoint une catégorie de même nature ou garde son nom, jamais une catégorie d'une autre nature. | Lets Bowl : sept catégories, trente-six plats, zéro commande en six mois (toute la carte café et thé). Le CDC du 09/09 les fusionnait en « Coffee & Tea, 30 plats » et n'en disait rien. |
| S4 | Le CDC du 09/09 annonçait « catégories de moins de trois plats regroupées » et en laissait huit sur dix-sept. Une règle qu'on n'applique pas est une règle qu'on ne peut pas expliquer. 14/09 : le catalogue la réintroduisait (S2, S4, S10) ; maintenue retirée faute de donnée nouvelle, elle toucherait 7 catégories sur 18 chez Lets Bowl. | |
| S2.1 | Le moteur choisit la fusion, pas le modèle : une catégorie faible rejoint la catégorie de même famille (S8) la plus proche en commandes ; à défaut, ses plats rejoignent la catégorie de leur meilleur vendeur ; la question n'est posée au client que si ces deux voies échouent. | Catalogue du 14/09 (S2). Aujourd'hui, sans plan déclaratif, les destinations viennent de la proposition du modèle, bornées par S3 : c'est la dernière décision de structure encore laissée au modèle. |
| S5 | Le nombre de catégories reste dans la fourchette de la typologie du restaurant (mono-produit, fast casual, cuisine ethnique complète, café, dessert, healthy, premium, cloud kitchen), hors sections créées par la plateforme ; au-delà, fusion par famille en partant des plus faibles en commandes. | Catalogue du 14/09. Prérequis manquant : aucune question de typologie à l'onboarding ; le type de cuisine y est à choix multiples et ne désigne pas une ligne (Lets Bowl, « healthy » et « turkish » : 4 à 6 ou 7 à 9 catégories selon la ligne retenue). |
| S6 | Les premières fiches de chaque catégorie sont les signatures puis les meilleures ventes ; au-delà des positions utiles, une fiche est considérée comme peu vue. | Catalogue du 14/09 (6 positions utiles). À aligner sur l'indice de conformité, qui attend les fiches porteuses dans les 3 premières : un seul réglage pour les deux. |
| S7 | Un nom de catégorie fait 1 à 3 mots et contient le terme que le client tape ; jamais un nom d'ambiance ou de marque seule ; un régime (vegan, sans gluten) est un filtre porté par un badge, pas une catégorie. | Catalogue du 14/09. Les limites de longueur des noms de catégorie ne sont renseignées pour aucune plateforme (voir D8). |
| S10 | Une catégorie d'usage (Combos, Breakfast, Family) n'est créée que si elle compte assez de plats. | Catalogue du 14/09. À trancher : le catalogue la mesure au plancher de trois plats, retiré (S4) ; il lui faut un autre critère, part des commandes ou nombre de plats propre aux catégories d'usage. |
| S11 | Une catégorie trop longue n'est pas scindée si la scission fait sortir de la fourchette de la typologie : on réordonne (S6) et on alerte l'équipe. | Catalogue du 14/09 (plafond de 12 plats par catégorie). Dépend de S5 et de son prérequis, la typologie. |
R · Les retraits
| # | Règle | Constat d'origine |
|---|---|---|
| R1 | Dans une catégorie qui vend, un plat à zéro vente sur la période est candidat au retrait — une fois les ventes orphelines rapprochées (V1), sinon un plat vendu sous un autre nom serait retiré. | Lets Bowl 09/09 : la règle exigeait au moins une vente pour être retiré, donc les plats à zéro étaient intouchables et ceux à une vente partaient. |
| R2 | Un plat vendu au plus max(2, 1 % du meilleur vendeur), ET au moins cinq fois moins que le meilleur de sa catégorie, est candidat, avec son volume réel consolidé (tous ses noms d'export) affiché à côté. | 09/09 : « Falafel, 1 sold » pour un plat vendu sous trois noms. 12/09 : « Coca Cola, 2 vendus » proposé au retrait dans une catégorie dont le meilleur fait 6 ventes — un plancher absolu ne dit rien dans une petite catégorie. |
| R3 | On ne retire jamais le meilleur vendeur d'une catégorie, ni plus de la moitié d'une catégorie, ni un plat signature, ni un plat protégé (jamais en promotion, rentable déclaré). | 09/09 : quatre smoothies sur quatre proposés au retrait, la catégorie disparaissait de fait sans que personne ne l'ait décidé. |
| R4 | Un plat d'une catégorie sans vente ne se retire pas un par un : la catégorie entière relève de S3. | Treize retraits à une ou deux ventes pendant que trente cafés à zéro restaient : le client lisait un document qui retirait ce qui se vend un peu et gardait ce qui ne se vend pas. |
| R5 | En mode structure (G3), aucun retrait motivé par les ventes : R1 et R2 sont neutralisées et le document ne contient aucun bloc de retrait. | Appliqué depuis le 12/09 par G3, écrit comme règle au catalogue du 14/09. Mesuré le 14/09 : aucun client n'est en mode ventes. |
| R6 | Un retrait n'est jamais présenté sous un bénéfice qu'il ne produit pas : retirer un plat qui ne vend pas ne change ni les annulations, ni le délai, ni la note. | Appliqué depuis le 12/09 par X7 (plus d'étiquette « fewer cancellations »), écrit au catalogue du 14/09. |
| R7 | Une fiche peu vue (au-delà des positions utiles, ou arrivée récemment au menu) n'est pas candidate au retrait sur ses seules ventes. | Revue du 14/09 : l'argument du mode structure (zéro vente, zéro exposition) vaut aussi à l'intérieur d'une catégorie, et l'export des ventes par plat ne dit pas depuis quand un plat est au menu. À trancher avec S6. |
H · Les plats signature
| # | Règle | Constat d'origine |
|---|---|---|
| H1 | Signature = les plats déclarés héros par le client, puis les plats principaux déclarés rentables, puis les meilleurs vendeurs, jusqu'à quatre. Le modèle ne choisit plus. | 09/09 : le modèle choisissait quatre best-sellers ; « Alfredo Chicken », seul plat que Lets Bowl a déclaré rentable, n'apparaissait nulle part. 14/09 : aucun client n'a déclaré de plat héros (0 réponse d'onboarding sur 5), la première branche ne sert pas encore. |
| H2 | Un accompagnement, dessert ou boisson déclaré rentable ne devient pas signature : il devient candidat à la vente additionnelle, selon la matrice du Blueprint (jamais un principal sur un principal, une entrée ne propose pas une entrée). | Brief Redwane point 11 : « aller chercher les plats les plus rentables pour les ajouter, dans une règle cohérente ». Ma première proposition du 11/09 mettait un principal en cross-sell : contraire à la matrice. |
| H1.1 | Sans onboarding ni ventes (vitrine seule), les signatures sont les plats en tête du menu actuel, marqués « à confirmer ». | Catalogue du 14/09 (défaut de H1 en vitrine seule). |
| H3 | Un plat signature n'est jamais un plat sans photo : s'il en manque, la photo sort en première action, avant toute mise en avant. | Catalogue du 14/09. |
P · Les prix
| # | Règle | Constat d'origine |
|---|---|---|
| P1 | Un même plat à deux prix dans deux catégories est aligné sur le prix de la fiche qui se vend. | Défaut fréquent des cartes construites par ajouts successifs. |
| P2 | Une taille plus grande moins chère qu'une plus petite sort en décision : la remonter au prix de la petite. Les tailles s'affichent en écart (« 6 pc +12 »), voir la règle Tailles comme Talabat. | Hoby 11/09 : échelle de tailles relue à la main. 14/09 : reformulée, c'est une décision posée au client avec les deux prix, jamais une correction silencieuse (principe P3). |
| P3 | Sans défaut nommé, aucune proposition de prix. Ni « marge de manœuvre », ni « peut absorber une hausse », ni fourchette de ±15 % laissée au modèle. Une proposition fondée sur la marge n'est possible que si le coût matière est renseigné à l'onboarding (O2). | 09/09 : +13 % sur le best-seller de Lets Bowl (46 → 52 AED) avec objectif déclaré « volume de commandes » et coût matière vide, raison « has proven pricing headroom ». Cinq propositions, zéro règle. |
| P4 | Même constat que P3 : CDC Lets Bowl du 09/09, +13 % sur le best-seller dans une fourchette laissée au modèle. Code réattribué le 12/09 à l'échelle de contenu (voir les compléments). | |
| P6 | Un prix hors de l'échelle de sa catégorie est signalé à l'équipe, jamais corrigé. | Catalogue du 14/09 (au-delà d'un nombre d'écarts-types). À préciser au codage : une catégorie compte souvent 3 à 5 plats, trop peu pour un écart-type ; l'écart à la médiane de la catégorie tient mieux. |
| P7 | Une remise de formule n'existe que si le client l'a déclarée ; elle sort alors en décision avec son montant. | Catalogue du 14/09. |
N · Les noms
| # | Règle | Constat d'origine |
|---|---|---|
| N1 | Un même nom dans deux catégories est un nom ambigu, pas un doublon : le document propose un renommage qui dit la différence (« Iced Matcha Latte »), jamais « une seule fiche ». | Lets Bowl 09/09 : « Matcha Latte en double » en priorité d'action, pour un chaud (WARM COFFEE) et un glacé (ICED MATCHAS). Fausse alerte en tête de document. |
O · Les données d'onboarding
| # | Règle | Constat d'origine |
|---|---|---|
| O1 | Un panier déclaré à moins d'un tiers ou plus de trois fois le panier mesuré est signalé à l'équipe avant génération ; le CDC n'utilise que le mesuré. | Lets Bowl : panier déclaré « 7.00 », mesuré 79,99 — ignoré en silence. |
| O2 | Coût matière vide, aucun plat héros ni rentable déclaré : signalé, parce que ces absences réduisent ce que le document peut décider (P3, H1). | Idem. 14/09 : le coût matière a été retiré du parcours d'onboarding (colonne gelée) ; sa part du signal sonnera pour tous les clients tant qu'elle n'est pas reformulée. |
| O3 | Des add-ons, montées en gamme ou ventes additionnelles déclarés sans groupe d'options sur les plats : signalé, le CDC ne peut que les citer en texte tant qu'ils ne sont pas posés dans l'atelier des options. | Lets Bowl : cinq add-ons, une montée en gamme et trois ventes additionnelles déclarés, zéro groupe d'options, section paniers construite avec des mozzarella sticks. |
| O4 | Toute valeur déclarée montrée au client porte la mention « déclaré par vous ». | Catalogue du 14/09 ; déjà appliqué aux add-ons déclarés de la section 4 (X2), à étendre à toute valeur déclarée. |
| O5 | Une valeur déclarée n'est jamais utilisée quand la valeur mesurée existe. | Catalogue du 14/09 ; déjà vrai pour le panier moyen (O1 : Lets Bowl, 7,00 déclaré, 79,99 mesuré), à généraliser. |
T · La traçabilité
| # | Règle | Constat d'origine |
|---|---|---|
| T1 | Chaque décision du document porte sa provenance — le champ, le code de la règle, la source de données et le détail — enregistrée dans le document et affichée dans l'admin. Le client ne la voit pas. | Brief Redwane point 16 : « on doit savoir très rapidement où telle information a été trouvée et sur base de quelle règle ». Jusqu'au 11/09 : des compteurs de sources, rien par proposition. |
| T2 | Un fait, un chiffre. Les commandes viennent des exports Talabat ; les impressions, vues et ajouts au panier du Hub ; les noms de plats sont ceux consolidés du menu. Le contrôle de cohérence bloque un document qui cite deux valeurs pour un même fait. | Lets Bowl 09/09 : 553 commandes en ligne de vision, 534 dans le levier 3, dans le même document. |
| T3 | Le journal du document remplace le verdict technique en tête de page : qui a généré, ce qui a été corrigé, par qui, quand. | Brief Redwane point 1 : « je ne vois pas l'intérêt de tout ce charabia ». |
| T5 | Chaque document porte son mode (vitrine seule ou données complètes, volume faible ou normal) et la liste des règles neutralisées. | Catalogue du 14/09. Aujourd'hui seul le mode de volume (G3) est tracé dans la provenance. |
| T6 | Le contrôle de cohérence refuse un chiffre sans source, un plat inconnu, une promesse chiffrée, deux valeurs pour un même fait, un compteur faux. Le refus d'une compression qui perd un produit reste à coder (C3). | Refus en place depuis le 09/09 (coherence.ts), liste écrite au catalogue du 14/09. Ce sont des blocages d'intégrité : ils restent durs. |
G · Le mode de génération
| # | Règle | Constat d'origine |
|---|---|---|
| G2 | Un seul état du menu, une seule passe de comptage, puis la rédaction. Le compteur de retraits annonce les lignes rendues, jamais l'état de la base ; une raison de catégorie compte les plats après retraits et déplacements. | Lets Bowl 12/09 : « 17 listings retired » pour 12 listés (le compteur lisait tous les plats archivés, même ceux d'un ancien brouillon) ; « Coffee & Tea · 32 dish(es) » pour 31 rendus. |
| G3 | Mode structure si la vitrine a moins de 6 mois, ou si la médiane des commandes par plat est sous 10, ou si le total des commandes est sous 1 000. En mode structure, R1 et R2 sont désactivées : aucun retrait motivé par les ventes, la carte se réduit par regroupement (C1) et la section « ce qui sort du menu » n'est pas rendue. Le critère des 6 mois ne s'applique pas encore : aucune date d'ouverture n'est collectée, le générateur passe une valeur vide. | Lets Bowl : 553 commandes, médiane de 3 commandes par plat. Une fiche à zéro vente en position 22 d'un menu de 25 catégories n'est pas un plat qui ne se vend pas, c'est un plat que personne n'a vu. |
| G1 | Une règle qui offre une alternative dit quand chaque branche s'applique ; sans critère de bascule, elle ne passe pas en production. | Leçon du 12/09 (une règle de décision porte toujours sa condition d'application), écrite au catalogue du 14/09. |
| G2.1 | Ordre de calcul : import, normalisation, rapprochement des ventes, signature, compression, structure, retraits proposés, prix, offre, rédaction, comptage, rendu. | Catalogue du 14/09 (G2), ordre corrigé à la revue : la compression change le nombre de fiches par catégorie (Lets Bowl, 99 → 68) et doit précéder la structure ; la signature, dont dépendent S1, C2 et R3, n'y figurait pas ; les retraits restent des propositions tant que le client n'a pas tranché. |
| G4 | Deux modes de données : vitrine seule, ou données complètes (portail et exports en plus) ; en vitrine seule, les règles qui lisent le portail ou les exports sont neutralisées et listées (T5). Un troisième cas existe : ni vitrine ni ventes, la carte déposée seule. | Catalogue du 14/09 (sa règle G3, renumérotée : G3 désigne ici le mode de volume). Sista Place : carte déposée, ni vitrine relevée ni ventes. |
| G5 | Aucun seuil, aucune limite de plateforme, aucun nom de plat ou de catégorie n'est écrit en dur hors des réglages ; chaque calcul garde la version des réglages qu'il a utilisés. | Catalogue du 14/09. Revue : une vingtaine de seuils cités dans les règles n'avaient pas de réglage ; les limites de plateforme existent (/config) mais la longueur de titre est vide pour les 5 plateformes ; les plans par client (PL) figent des noms de plats et passent en données journalisées (décision du 14/09). |
| G6 | Le code calcule, le modèle rédige, l'humain valide : aucun chiffre affiché ne vient d'un modèle de langage. | Principe de ce registre depuis le 11/09, écrit au catalogue du 14/09. Exception à lever : le type d'une catégorie peut encore être proposé par un modèle (typage automatique). |
| G7 | Un document passe par « généré » puis « validé en interne » ; le lien client n'existe qu'après. | Catalogue du 14/09. Depuis le 14/09, les trois portes d'envoi passent par une seule fonction qui note l'envoi, et le portail n'ouvre ni ne valide un document jamais envoyé ; l'état « validé en interne » distinct de l'envoi reste à coder. |
| G8 | Une correction interne qui contredit une règle est journalisée et remonte comme constat candidat à une nouvelle règle. | Catalogue du 14/09. L'éditeur interne journalise déjà ses corrections (point 15 du brief du 09/09) ; la comparaison avec les règles reste à coder. |
C · La compression des variantes
| # | Règle | Constat d'origine |
|---|---|---|
| C1 | Des fiches qui ne diffèrent que par un parfum, une température, une garniture, un format ou une marque deviennent UNE fiche et un groupe de choix obligatoire. Prix de base = la variante la moins chère de la carte, les autres en écart (« +5 AED »), comme l'affichage Talabat. Le geste est celui des tailles (lib/menu/tailles-en-groupe.ts) : les fiches absorbées deviennent les variantes de la fiche unique, puis le groupe « Your choice ». | Lets Bowl : 7 smoothies, 7 thés, 6 sodas, 5 matchas, 5 toasts, chaud/glacé ×3… 99 fiches → 68, sans perdre un produit. Appliqué par scripts/appliquer-plan-cdc-lets-bowl.ts. 14/09 : le catalogue écrit « groupe d'options » ; c'est bien un choix obligatoire (M0.1), jamais soumis à la règle de protéine des add-ons (M4). |
| C2 | Une variante garde sa fiche si elle est héros déclaré, signature, ou porte à elle seule plus de la moitié des ventes de sa famille : on la cherche par son nom. | Brief 12/09. |
| C4 | Deux fiches de même famille, même format, prix proche, dans deux catégories, sont candidates à la fusion même si les noms diffèrent — jamais entre deux familles (un smoothie n'est pas un mocktail, un croissant du petit-déjeuner n'est pas le croissant pistache des desserts). | Brief 12/09 ; deux fusions du brief refusées après lecture de la carte. |
| C2.1 | Sans onboarding ni ventes, la variante la plus chère garde sa fiche. | Catalogue du 14/09 (défaut de C2). À trancher : avec deux variantes seulement, ce défaut annule la compression. |
| C3 | Une compression n'est jamais un retrait : chaque variante absorbée reste commandable, et le contrôle refuse une compression qui perd un produit. | Catalogue du 14/09. Le script Lets Bowl vérifiait « zéro produit perdu » (99 → 68 fiches) ; le contrôle automatique reste à coder. |
| C5 | Un plat n'apparaît dans deux catégories que s'il est signature et que la seconde est une catégorie d'usage. | Catalogue du 14/09. |
| C6 | Le nom d'une fiche compressée contient le terme cherché, pas le nom de sa catégorie d'origine. | Catalogue du 14/09. |
A · La complétude des fiches
| # | Règle | Constat d'origine |
|---|---|---|
| A1 | Le taux de fiches avec photo se mesure par catégorie ; toute catégorie sous 100 % sort en action, signatures et meilleures ventes d'abord. | Catalogue du 14/09. Déjà mesuré par l'indice de conformité (hygiène : un visuel validé par fiche), à rendre dans le Blueprint. |
| A2 | Une fiche sans description, sans photo, ou sans groupe d'options alors que son type en appelle un, est listée incomplète avant toute proposition de retrait ou de prix. | Catalogue du 14/09. |
| A4 | Une fiche indisponible depuis longtemps est listée : une rupture permanente pénalise la vitrine entière. | Catalogue du 14/09. Source en cours depuis le 14/09 : une veille surveille 4 vitrines clients (changedetection.io sur le VPS) et signale un changement à l'admin (/api/veille/changement, carte sur /sante) sans transmettre le menu ; aucune durée d'indisponibilité mesurable tant qu'un changement ne déclenche pas une extraction. |
| A5 | Une famille qui pèse plus de 30 % des fiches pour moins de 5 % des commandes est une question de vitrine posée à l'équipe avant génération, jamais tranchée par le moteur. | Lets Bowl : 31 fiches de café et thé sur 87 (36 %) pour 6 commandes en six mois. Deux sorties : une vitrine Talabat dédiée en marque virtuelle, ou 6 références en accompagnement du bowl. |
M · Add-on, montée en gamme, vente additionnelle
| # | Règle | Constat d'origine |
|---|---|---|
| M0 | Trois objets, trois blocs. Add-on = le même plat avec un supplément (groupe, choix multiple, max 4). Montée en gamme = le même plat en plus grand ou plus généreux (groupe, un seul choix). Vente additionnelle = un AUTRE plat ajouté au panier (jamais un groupe d'options). | Le bloc 4 du 12/09 matin affichait les trois sous « Add-on · on the dish » : illisible. |
| M1 | Ordre des sources : les groupes réels de la fiche, sinon les déclarations d'onboarding étiquetées « déclaré par vous », les ventes ne servant qu'à classer. Les exports Talabat donnent les ventes par plat, jamais la composition des paniers : le document ne laisse jamais croire qu'on sait ce qui se commande ensemble. | Brief 12/09. Les groupes « Add-ons / Upgrade / Add a side or a drink » créés depuis l'onboarding le matin sont remplacés par ceux de la carte (page « Build your own bowl »). |
| M2 | Matrice par type de plat : un plat principal propose side, boisson, dessert ; un side propose plat, boisson ; un dessert propose boisson ; une boisson propose side, dessert ; un combo ne propose rien. Jamais un autre plat du même type. | packages/shared/src/menu-roles.ts (MATRICE_CROSS_SELL), lue par l'admin et le portail. 14/09 : une seconde matrice vit dans packages/shared/src/blueprint.ts (MATRICE_VA, Blueprint Phase 3.3) et la contredit sur les boissons et les combos ; à unifier. |
| M3 | Dans les types autorisés : d'abord les plats déclarés rentables, sinon le meilleur vendeur de chaque type ; au plus trois propositions, une par type. | Brief 12/09. Le catalogue du 14/09 fixe aussi la taille des blocs affichés dans la section panier (4 add-ons, 1 montée en gamme, 2 ventes additionnelles) : trois candidats au plus, deux affichés. |
| M4 | Garde-fous : jamais une autre protéine que celle du plat (sauf déclaration explicite) ; jamais plus de 50 % du prix du plat ; au prix du menu ; un article n'est pas à la fois add-on et upgrade ; un principal sans aucun groupe est une fiche incomplète. | 12/09 matin : « Extra chicken +17 » et « protein boost chicken +17 » proposés sur un Beef Rice Bowl. proteineCompatible dans menu-roles.ts. |
| M5 | Chaque ligne proposée porte sa source (groupe réel · déclaré onboarding · matrice M2), sa règle et sa raison — dans l'admin, jamais dans le document client. | Brief 12/09, point 16 du brief du 09/09. Règle M6 du catalogue du 14/09. |
| M0.1 | Quatrième objet : le choix obligatoire (taille, parfum, protéine), un groupe à un seul choix qui porte les variantes d'une fiche (C1), jamais une montée en gamme ni un add-on. | Revue du 14/09 : sans lui, la compression d'un plat en variantes de protéine tomberait sous la règle de protéine des add-ons (M4). C'est le « Your choice » des tailles comme Talabat (12/09). |
| M4.1 | Le plafond de 50 % ne vaut que pour une proposition descendante (un side sur un plat) ; une proposition montante (un plat sur un side ou une entrée) n'a pas de plafond, c'est son but. | Catalogue du 14/09. Aujourd'hui le plafond s'applique à toutes les propositions (cdc-exemple.ts) : un plat principal ne peut jamais être proposé sur un accompagnement. |
| M4.6 | Une règle de vente additionnelle se valide une fois et s'applique à tous les plats de son type, y compris un plat ajouté plus tard. | Catalogue du 14/09. |
| M6 | Le moteur peut corriger les groupes d'options existants (réordonner, aligner un prix d'option sur le menu, renommer, requalifier un groupe mal typé) mais ne supprime jamais une option sans accord du client ; chaque correction sort en décision avec l'ancienne et la nouvelle valeur. | Catalogue du 14/09 (sa règle M5, renumérotée : M5 désigne ici la traçabilité). Limite : aucun export ne donne les ventes par option, « les options les plus prises en tête » n'a pas de source aujourd'hui. |
Compléments aux sections S, P, T, X
| # | Règle | Constat d'origine |
|---|---|---|
| S8 | Ordre par nature avant ordre par ventes : plats, petit-déjeuner, desserts, boissons froides, boissons chaudes. Les ventes n'ordonnent qu'à l'intérieur d'une famille. | Lets Bowl 12/09 matin : CLASSICS (sodas) en position 9 devant VEGAN BOWLS et AÇAÍ BOWLS, chez un restaurant qui s'appelle Lets Bowl. |
| S9 | La catégorie signature DUPLIQUE, ne déplace pas : un plat mis en tête reste dans sa catégorie d'origine, et les fiches dupliquées ne comptent pas. Rendue par le gabarit (signature_category), à dupliquer réellement sur Talabat à la publication. | Brief 12/09. |
| P4 | Échelle de contenu : un format qui contient plus ne coûte jamais moins. Un combo sous le prix du plat seul de même protéine sort en décision explicite du client, jamais corrigé en silence. | Lets Bowl : combo bowl poulet + boisson à 35 AED, bowls poulet seuls à 43 et 46 ; Super Eco Bowl à 29. |
| P5 | Un article proposé en option et en fiche autonome porte le même prix aux deux endroits (nom exact) ; un écart sort en décision avec les deux prix. | Lets Bowl : « Soup » déclaré +16, Lentil Soup 18 au menu ; « Cola » +9, 11 au menu. |
| T4 | Tout nombre cité dans une raison de catégorie ou un compteur égale le nombre d'éléments rendus : contrôle bloquant (compteur_faux). | 12/09 : 96/100 pour un document qui annonçait 32 plats et en rendait 31. |
| X6 | Une catégorie sans décision n'apparaît pas dans la colonne « Proposé ». Si la colonne se vide, le moteur n'a rien fait, et cela doit se voir en interne. | 17 lignes « Unchanged » sur 22 le 12/09 matin. |
| X7 | Une causalité qui n'est pas établie ne figure pas dans un livrable : plus d'étiquette « fewer cancellations » sur les retraits, plus de levier « visibilité » dans un document qui n'agit pas sur la vitrine ; le levier 3 est la rédaction des fiches. | Brief 12/09, section 7. |
| PL | Un plan de CDC déclaratif (lib/cdc/plans/<client>.ts) dicte la structure cible, les plats déplacés, la catégorie signature et les décisions ; le générateur l'applique à la place des propositions du modèle, la provenance dit « plan ». | Brief Lets Bowl 12/09 (section 3). |
X · Le document lui-même
| # | Règle | Constat d'origine |
|---|---|---|
| X1 | Le document commence par les trois leviers, en phrases structurées : ce qu'on change, ce que le client verra, pourquoi pour ce restaurant — au plus un chiffre par levier. Les lignes de vision, la phrase de gain et le bloc « priorité d'action » ne sont plus rendus. | Brief Redwane points 4 et 5 : « trop de texte, le restaurateur n'a pas le temps », deux priorités sur quatre étaient fausses (Matcha, catégories). |
| X2 | La section 4 montre UN plat et ce qui lui est proposé : ses add-ons et sa taille (groupes d'options réels, prix en écart comme Talabat), ses ventes additionnelles (règle du type du plat), et à défaut ce que le client a déclaré à l'onboarding — étiqueté comme tel. Les trois tickets avant/après ne sont plus rendus. Prix en lecture, correction par les commentaires ; l'édition par le client viendra ensuite. | Brief point 10 : « le panier affiché ne correspond pas à ce qui se passe sur les plateformes ». Lets Bowl : tickets construits avec des mozzarella sticks alors que le client avait déclaré Extra chicken, Avocado, Feta. |
| X3 | Le style photo ne se choisit plus dans le CDC : la section est retirée, la validation ne dépend plus que des prix, et le choix se fait sur le portail juste après le mapping des photos, là où il a un sens. Écrit dans le CDC validé, lu par la fiche ADN comme avant. | Brief point 14 : « suppression définitive de toute la partie 5 ». |
| X4 | Les add-ons déclarés à l'onboarding deviennent des groupes d'options réels à la première génération quand le client n'en a aucun, posés sur ses plats principaux par le moteur des plans déclaratifs, relus par l'account manager (raison affichée dans l'atelier). | Décision 11/09 (Mehdi : « je te laisse choisir ») ; Lets Bowl : neuf déclarations, zéro groupe. |
| X5 | La colonne « Proposé » du plan liste toutes les destinations, celles qui gardent leur nom comprises ; sans plan, elle reste vide. | Brief point 6 : « 25 → 17 catégories, 7 affichées » (cdc.ts, contourné le 09/09, corrigé à la source le 12/09). |
| X8 | Aucune cible de performance chiffrée, aucun écart à combler, aucun pourcentage de progression promis (loi fédérale UAE 15/2020, charte). | Refusé par le contrôle de cohérence depuis le 09/09 (cible, écart, « from X to Y »), écrit au catalogue du 14/09. |
| X9 | Une seule zone de commentaire par bloc, placée après son contenu ; les chiffres du client restent en lecture seule. | Catalogue du 14/09. Aujourd'hui quatre zones, envoyées seulement avec la validation finale : un client ne peut pas commenter sans tout valider. |
| X10 | Le Blueprint ne contient aucune projection de chiffre d'affaires : l'état de départ figé à la mise en ligne et le rendez-vous J+90 la remplacent. | Décision du 14/09 (revue du document « Suppression de l'audit ») : la projection demandée n'avait aucune hypothèse de hausse définie et le mot « plancher » promettait un minimum ; celle de l'audit était rédigée par le modèle (DV-08) sur le dernier mois. |
| X11 | Le Blueprint est le seul document client avant production : l'audit de performance disparaît comme document client, ses données restent pour l'écran interne, une seule validation. | Décision du 14/09 (document « Suppression de l'audit ») : deux documents, deux barèmes, des chiffres divergents (Teriyaki 172 dans l'audit, 184 dans le CDC, le 09/09). À trancher avant le code : lequel des deux Blueprints du code porte le document unique (CDC v2 ou Phase 3.3), et la promesse d'audit de la grille tarifaire. |
D · La rédaction des fiches
| # | Règle | Constat d'origine |
|---|---|---|
| D1 | Le terme que le client tape apparaît dans les 30 premiers caractères du titre et les 60 premiers de la description, en anglais naturel, jamais inversé pour forcer le mot en tête. | Les 60 premiers caractères sont tout ce qu'un client voit sur la page du menu. |
| D2 | Rien d'inventé : ni ingrédient, ni quantité, ni contenant, ni mode de cuisson absent de la source. Une protéine que la source ne porte pas est un mensonge sur un marché halal. | Défauts relevés sur une carte en ligne le 07/09 (« bacon » pour des lamelles de dinde, « 6 sticks » pour trois). |
| D3 | Aucun superlatif vide (« best », « amazing », « number one », loi UAE 15/2020), ni prix, ni délai, ni téléphone, ni lien, ni autre plateforme. | Charte et risque de rejet par la modération. |
| D4 | Un différenciateur premium présent dans le nom, la description ou la catégorie survit dans le titre (Wagyu, truffe, saffron…). | C'est ce qui justifie le prix aux yeux du client. |
| D5 | Une box ou un combo nomme chaque composant et pour combien de personnes dans les 60 premiers caractères. | Les clients cherchent « meal for 2 », « family box ». |
| D6 | Pas de phrase de clôture formule (« A tasty, fresh and generous meal. »), la dernière proposition est concrète et propre au plat. | La même phrase retrouvée sur trente fiches. |
| D7 | Ce que ces règles promettent : être trouvé, ne pas être rejeté, donner envie. Elles ne promettent pas un classement. Personne hors de Talabat ne connaît l'algorithme ; une promesse de « montée en ranking » serait une promesse de plus. | Brief Redwane point 12. Réponse honnête plutôt qu'une garantie inventée. |
| D8 | Titres, descriptions et noms de catégorie tiennent dans les limites de la plateforme ; un titre tronqué à l'affichage est un défaut. | Catalogue du 14/09. Les limites de titre ne sont renseignées pour aucune plateforme (sonde limites_plateformes) : plancher de sécurité de 40 caractères en attendant. |
| D9 | Le titre ne commence ni par le nom du restaurant ni par une marque. | Catalogue du 14/09 : les premiers caractères sont la seule zone lue. |
| D10 | Les termes de recherche viennent de la liste observée sur la plateforme, jamais d'une invention du modèle ; en leur absence, le nom générique du plat. | Catalogue du 14/09. À trancher : aucune liste observée n'existe ; la banque actuelle est écrite à la main (matrice du 15/07), 13 « termes Dubaï » n'ont pas de source, et le terme de chaque plat est choisi par le modèle dans cette liste. |
| D11 | La langue de sortie suit la langue déclarée par le client ; une édition du client qui retire un mot-clé déclenche une alerte. | Catalogue du 14/09. Prérequis : la langue n'est pas demandée à l'onboarding (valeur par défaut). |