Les pages de l'application
Chaque page de l'admin et du portail, en une phrase.
Admin
| Page | Ce qu'elle fait |
|---|---|
| / | Cockpit « qu'est-ce que je dois faire maintenant ? » : file unifiée à traiter, production photos, activité récente. |
| /leads | Pipeline commercial (kanban/liste) Prospect → Lead → Client. |
| /leads/[id] | Fiche lead : carte Ciblage (deux rangées de pastilles, un tap = enregistré, retaper efface ; la définition de chaque choix est sous les yeux ; suggestion « à confirmer » avec sa raison ; alerte « le décideur n'est pas sur place » sur un compte Global/National ; indice « N autres fiches portent ce nom »), édition de l'audit vitrine + aperçu du document exact ; envoi, conversion en client. |
| /leads/[id]/presentation | Mode rendez-vous : l'audit plein écran tel que le lead le voit. |
| /leads/[id]/deck | 🎤 |
| /leads/tableau | Mes prospects (12/10, Sharoon : « l'Excel est plus simple »). Le tableur du commercial dans le CRM : ses 10 colonnes (date, restaurant, type, fixe, mobile/WhatsApp, contact, numéro du contact, e-mail, étape, commentaires) + le rappel, une ligne par fiche qui lui appartient, chaque case modifiable d'un clic (Entrée enregistre). L'étape est une liste fermée dans ses mots (Call, Followup… Fifth Followup, Meeting booked/Conducted, Not interested, Business closed — lib/crm/etape-suivi.ts) qui avance seule d'un cran à chaque commentaire. Le commentaire s'écrit en clair ; « call back Monday at 8 pm » pré-remplit le rappel (lib/crm/rappel-texte.ts), confirmé d'un geste. Historique daté dans crm_commentaires (aussi sur la fiche et dans l'appel). Ajouter une ligne cherche la base pendant la frappe (libre → je le prends ; collègue → pas de doublon). « Donne-moi 20 restaurants » attribue N fiches libres jamais contactées d'une zone. « Coller depuis mon tableur » importe des lignes copiées de Google Sheets (aperçu puis import, rejouable, jamais une fiche d'un collègue). Un admin choisit le tableau d'un membre. |
| /leads | Prospects, UNE page, UNE adresse (21/10, maquette v3 validée par Mehdi : « Prospects et Toute la base, c'est pas clair »). Tout ce qui précède sur /leads/tableau vit ici ; /leads/tableau REDIRIGE vers /leads en gardant ses paramètres (vue, filtre, membre, ajouter). Composition (skill expert-ecran) : en-tête « Qui rappeler, qui relancer, qui rencontrer. Toute la base est en dessous, filtrée par qui s'en occupe. », segment Liste | Kanban | Carte ; quatre tuiles de TOUTE l'équipe — restaurants en base · venus du site (formulaire d'audit) · jamais contactés · clients signés — calculées par UNE fonction pure lib/crm/kpi-base.ts (kpiBase, jamaisContacte, estClose, testée), les MÊMES prédicats que les filtres de la liste ; chaque tuile filtre la liste (?perimetre=equipe&filtre=) ; repli OUVERT « À faire aujourd'hui · N » (ses rappels en retard et du jour, les plus en retard d'abord, six lignes puis « Voir les N autres », chaque ligne ouvre « Comment ça s'est passé ? » ; l'ancienne chip « À faire » disparaît : une seule liste des rappels) ; |
| /leads/import | Import de prospects en masse. Colonnes Type et Category reconnues (19/09) : la liste arrive déjà rangée. À défaut, le nom et l'adresse sont lus (marqueurs « cloud kitchen », « Kitchen Park », « delivery only », enseignes internationales et nationales) — une valeur non reconnue laisse la case VIDE, l'import n'invente jamais. |
| /leads/fusions | Doublons détectés (place_id Google) à fusionner ou écarter. |
| /terrain · /terrain/saisie | PWA mobile du commercial : ajout de prospect, objectifs, RDV du jour, saisie rapide terrain. Depuis le 19/09, une question de plus — « Salle ou livraison seule ? » — posée là où la réponse est gratuite (devant le restaurant) ; enrichissement NON destructif sur une fiche existante. La catégorie de compte ne s'y trouve pas : elle ne se devine pas sur le trottoir. |
| /prospection | Audit flash : une URL Talabat → audit complet ~2 min, lead « démarchage » créé. |
| /performance/sprint | Saisie du soir du sprint terrain (objectifs vs réalisé). |
| /performance/activite | 📊 Activité du commercial (16/09) : appels passés (dont aboutis), portes poussées, argumentaires avec à qui (patron · manager · staff), RDV pris — aujourd'hui, cette semaine, sur le sprint (ou 30 jours si aucun sprint ne couvre le jour), et jour par jour sur 14 jours. Un commercial voit les siens ; un administrateur choisit la personne (défaut : le premier commercial de terrain) et voit le tableau de l'équipe. Faits : interactions, appels sans réponse (journal), argumentaires (journal interaction / argumentaire, posés depuis la fiche 📞 et la saisie terrain), rendez-vous créés — règles pures lib/activite/regles.ts. |
| /carte | QR vCard du commercial connecté. |
| /rendezvous | RDV : à clôturer / à venir / historique — vues Liste, Mois, Semaine, 3 jours. Clôturer (14/10) ouvre une feuille en quatre questions : il a eu lieu ? (sinon nouvelle date, ou rappel le lendemain) · combien de temps ? · résultat (Signé · 2e RDV + date · Attente de réponse · Perdu) · pourquoi il n'a pas signé ? — règle lib/commercial/cloture.ts : issue, objection, 2e RDV (poserRendezvous), rappel (poserRappel), statut de la fiche, raison au journal, résumé dans l'historique. Après un RDV tenu non signé, « Mail d'opportunité » envoie le modèle email_opportunite_post_rdv avec en pièce jointe le récapitulatif d'une page (refonte 13/10, lib/crm/resume-rdv.ts, PDF A4 via genererPdf(…, { pageExacte: true }), aperçu et re-téléchargement GET /api/crm/rendezvous/[id]/resume) : son objectif dans ses mots, le score de sa vitrine, les deux fondateurs et quelques logos clients, trois résultats de clients nommés (registre lib/deck/preuves.ts) et un avant/après de plat, ce qu'il reçoit, l'offre Founding Partner (aucun investissement initial, refonte au prix de GRILLE_2026 offerte, 20 places par zone, place tenue 10 jours après le RDV) et UNE action (WhatsApp ou appel de la personne qui l'a rencontré, lien de prise de RDV). |
| /relances | File de relances commerciales (en retard / aujourd'hui / à venir), journée à l'heure de Dubaï, heure convenue affichée (15/09). |
| /demarchage | 📬 |
| /boite | 📥 |
| /a-appeler | 📞 |
| /boite | 📥 |
| /bibliotheque | Supports de vente FR/EN (grille tarifaire, contrat, deck, scripts). Depuis le 14/10 : Présentation DelivUp (2 pages) (GET /api/bibliotheque/presentation, PDF A4 rendu depuis lib/bibliotheque/presentation.ts : page 1 la refonte depuis ses données, page 2 l'accompagnement dans son espace et la croissance d'activité toutes les deux semaines, chiffres du registre de preuves, sans offre ni prix ; en français avec ?lang=fr, ligne « Présentation DelivUp en français » ; visuels JPEG de public/deck/pdf/ pour un PDF de 2,6 Mo, leçon 126) et E-mail après rendez-vous (Founding Partner) (GET /api/bibliotheque/mail-apres-rdv, objet et texte à copier, mêmes constantes que le récapitulatif joint). Depuis le 16/10 : les quatre scripts de vente de Mehdi (appel à froid, WhatsApp, Instagram, LinkedIn), servis TELS QU'IL LES A ÉCRITS par GET /api/bibliotheque/script-{appel|whatsapp|instagram|linkedin} (fichiers delivup-admin/templates/scripts-vente/*.html, source unique : déposer une nouvelle version suffit). |
| /leads/[id]/script | 📜 |
| /parrainages | Programme de parrainage B2B/B2C : prime LIBRE par partenaire (la famille propose 400 / 250 AED, le champ remplace), code unique, double confirmation calculée ; un admin modifie (nom, famille, prime) ou supprime depuis la ligne, chaque geste journalisé (14/09). Depuis le 15/09 : le commercial PROPOSE, l'admin VALIDE — le commercial propose un partenaire (nom + famille) et ne voit que les siens ; les admins sont notifiés (cloche + Telegram/push) et trouvent en tête de page le bloc rouge « À valider » où ils fixent la prime et valident (le code s'active, le commercial est notifié) ou refusent ; confirmations possibles seulement après validation, paiement/modification réservés aux admins côté serveur. Aucune colonne : l'état se déduit du journal CRM (lib/crm/parrainages-regles.ts, règles pures testées). |
| /portefeuille | Le portefeuille du commercial (25/09, demande Redwane) : SES clients signés (rattachement clients.lead_id → leads.owner_email), chacun avec les 5 cases prouvées du moteur d'avancement, la prochaine action et QUI doit agir, l'argent et l'inactivité. Un admin voit la même page groupée par commercial. Un client créé à la main sans fiche rattachée n'apparaît dans aucun portefeuille (le rattacher : lib/crm/rattacher-client.ts). |
| /portefeuille/[id] | Fiche portefeuille = l'écran de closing : carte Contrat (pré-remplir → aperçu → copier le lien de signature), menu Encaisser (lien carte / cash — le lien 0 AED reste admin), lien espace client (relance photos), les 5 étapes et l'action du moment. Après « Convertir » un lead, un commercial atterrit ICI (fin du cul-de-sac « convertir → /terrain »). 🔒 Gestes ouverts au rôle commercial : les CINQ routes de GESTES_CLIENT_COMMERCIAL (lib/perimetre-commercial.ts) — contrat, contrat/preview, lien-signature, encaisser, espace-link — chacune gardée par exigerAccesClient() (propriété via la fiche de prospection ; règle pure accesClient, « sans propriétaire » = fermé, contrairement aux leads). Tests : perimetre-commercial.test.ts (chemins exacts, jamais un préfixe) et acces.test.ts (structurel). |
| POST /api/clients/[id]/plateformes | statut de mise en ligne d'une plateforme (live exige |
| POST /api/clients/[id]/moments | un des six rendez-vous ; la règle d'ordre (visibilité / |
| GET|POST /api/clients/[id]/conformite | indice de conformité menu d'une plateforme |
| POST /api/clients/[id]/blocage | « bloqué, et par qui » (aucun / delivup / client / plateforme). |
| POST /api/clients/[id]/cycle | champs internes (stade de marque, objectifs) — jamais montrés au client. |
| /clients | Liste des clients : par ligne, le chemin en 5 cases PROUVÉES (Contrat · Menu · Photos · Livrable · En ligne — lib/clients/avancement.ts, 08/09), la prochaine action et qui l'a en main (nous / client / plateforme), l'argent vérifié (ou « non renseigné »), l'inactivité (rien depuis N j), puis les phases 2 (plateformes) et 3 (rendez-vous). Filtres : bloqués, rien depuis 7 j, phase 2, phase 3, partiel. |
| /acces-clients | 🔐 Accès clients (28/09, incident Conestreet) : tous les clients par état d'accès à leur espace (Essais ratés, Jamais connecté, Accès bloqué, Pas de compte, Connecté ; ce qui demande un geste en tête), recherche par nom ou email. Un clic ouvre la feuille du compte (aussi depuis la fiche client, bouton 🔐) : historique des connexions, essais ratés et codes envoyés (client_espace_events, gestes de l'équipe tracés admin_*), nouveau mot de passe provisoire lisible au téléphone + message WhatsApp, bloquer / rétablir, supprimer le compte. Le client se connecte par défaut avec un code reçu par email, le mot de passe reste au choix (portail /espace). Règles pures : lib/clients/acces-espace.ts. |
| /suivi/my-day | 🌅 |
| /suivi | 📈 Suivi clients, vue d'ensemble (23/10, demande Mehdi : « notre dashboard à nous, de suivi… plusieurs graphiques dans la même page, mode SaaS… les onglets dans la sidebar… pas uniquement du visuel, aussi de la gestion »). Entrée « Suivi clients » de la sidebar avec cinq sous-pages (Chiffres · Campagnes · Plans du mois · Règles · Journal). 24/10 (maquette cockpit v2.2) : la pile « À décider » devient « À faire ce matin », calculée par lib/suivi/regles-matin.ts (points ouverts et bilans brouillons en rouge, client en ligne sans chiffre ou lecture en retard de plus de 7 jours, constats d'alerte, boutiques sans fiche en orange) et chaque ligne cite sa règle (R0, R1a, R7…) ; chaque restaurant porte sa position dans le cycle J0→J+14 (lib/suivi/cycle.ts, J0 = lendemain du dernier bilan publié sinon feu vert, repères J+4 pub / J+7 promo, « bilan dû » à 14) ; la part des plateformes est une barre empilée à la palette fixe (lib/suivi/palette-plateformes.ts), plus de camembert. En tête : le nombre de décisions qui attendent l'équipe (points des 14 jours à trancher, bilans de quinzaine en brouillon, boutiques lues sans fiche), tranchables SUR PLACE (Garder / Ajuster / Arrêter, Publier — mêmes routes que la fiche). Tuiles : restaurants en ligne, ventes et commandes sur 30 jours, restaurants avec chiffres. Trois graphiques (recharts) : ventes par jour empilées par plateforme, part de chaque plateforme (le Donut de /performance réutilisé, même palette), commandes contre annulations par semaine. Puis « Restaurant par restaurant » : verdict en une ligne (critique = décision attendue ; attention = en ligne sans chiffre ou dernier jour lu > 7 j ; accent/attention/info selon l'évolution des ventes sur la période précédente), plateformes et dernier jour lu, actions en cours ; un clic ouvre la fiche, onglet Suivi. Chiffres : tableauDeBordClient du socle partagé (les mêmes que le portail du client), fonctions pures testées dans lib/suivi/vue-ensemble.ts (série, parts, semaines, verdict). Fiches de test exclues partout. |
| /suivi/chiffres | 📊 |
| /suivi/chiffres/saisir | ✍️ |
| /suivi/campagnes | 📣 Toutes les promotions et publicités, lues sur les plateformes (collecte) ou déclarées par l'équipe (source = equipe, POST /api/suivi/campagnes, lib/suivi/campagne-equipe.ts), avec filtre d'état et l'effet mesuré : commandes par jour pendant la campagne contre la même durée juste avant (effetCampagne, null sous 3 jours = « trop tôt »). Replié : « Déclarer une campagne » (restaurant, plateforme, nom tel que la plateforme l'affiche, type, dates, taux, minimum, plafond, qui paie, budget) ; le statut se déduit des dates. Aucune table nouvelle. |
| /suivi/regles | 📐 Règles du suivi (24/10, maquette cockpit v2.2) : la table de décision que l'équipe applique chaque matin, une liste par famille (données, fuites, opérations, convertir, revenir, visible, campagne, verdict), chaque règle R0→R9 en « Si / Alors » (R9, 25/10 : stratégie envoyée, pas validée après 7 jours → « Relancer ») avec son seuil interpolé depuis la constante du code (lib/croissance/regles.ts, bilan/regles.ts, point/regles.ts, @delivup/shared) et la date de son dernier recalibrage ; pastille « mesurée » ou « en attente de la donnée » (R2b, R2c, R5b). Catalogue pur : lib/suivi/regles-catalogue.ts (testé). Lecture seule. |
| /suivi/clients/[id] | 🧭 |
| /suivi/clients | 🧭 |
| /suivi/strategies | 🏆 |
| /suivi/performer | 🧠 |
| /suivi/journal | 📜 Qui a fait quoi, quand, sur le suivi : lectures de plateformes, bilans publiés, points tranchés, actions lancées, plans envoyés, campagnes déclarées, jours saisis — une UNION des tables existantes (lib/suivi/journal.ts), 20 par page, heure de Dubaï, auteur. Lecture seule. |
| /plans | 📈 Plans du mois (06/10, demande Mehdi) : une ligne par restaurant (fiches de test exclues) avec l'état de son plan de croissance du mois (Demande de l'aide · À valider et envoyer en rouge ; En attente de la mise en ligne en orange ; Envoyé, Tout est fait), les gestes faits par le restaurant, les données à compléter et le prochain geste. Un clic ouvre le volet client du Cockpit (07/11 ; avant : fiche, onglet Suivi, « 3 · Faire grandir »), où l'équipe relit le plan (ce que le restaurant verra, d'où vient chaque conseil, plats rentables retrouvés) et le valide d'un bouton. Règles pures, aucune IA : lib/croissance/ (regles.ts : heures fortes, week-end, plats rentables de l'onboarding rapprochés de la carte et des ventes, bon de retour ; evenements.ts : calendrier de Dubaï sur 12 mois ; etat-plan.ts). Envoi : POST /api/clients/[id]/plan-croissance (refusé sans feu vert, comme les rendez-vous promo), table plans_croissance (données + instantané bilingue). |
| /clients/[id] | LA fiche client, onglets pilotés par ?onglet= (chaque onglet ne paie que ses requêtes) : |
| /clients/[id]/blueprint | 🧭 |
| /clients/releve | 📤 |
| /clients/[id]/saisie | Vue « Route C » : copier-coller champ par champ pour publier le menu. Photos et bannière se téléchargent en VRAI JPEG (ré-encodées dans le navigateur si besoin, 19/09 — elles partaient en WebP nommé .jpg). |
| /documents | l'archive : retrouver n'importe quel document d'un restaurant. |
| /cdc/[id] | La page d'un document CDC : stepper de cycle de vie, puis (12/09) le journal du document (généré, modifié, recontrôlé, envoyé, validé — qui et quand) et la provenance de chaque décision (champ · règle · source · détail, repliée par famille), édition, envoi, réponse client. L'éditeur interne couvre textes, styles, table du menu, structure proposée (destination + raison par catégorie, colonne « Proposé » reconstruite par lib/cdc/plan-categories.ts) et retraits (un plat coché revient au menu) ; chaque enregistrement est journalisé et recontrôlé. Depuis le 19/09 : bloc « 🧺 Ventes additionnelles sur le plat d'exemple » (retenu, écarté, pourquoi — un seul moteur, D7) et provenance S6 (plats remontés dans les positions utiles : signatures, plats à pousser, ventes) dans « D'où vient chaque décision ». Depuis le 07/11 : bouton « Nouvelle version avec ces demandes » (s'il reste une demande ouverte, document non validé, non archivé, production non lancée) : le rédacteur reprend les textes à partir des demandes OUVERTES seulement (règle 13 du prompt : jamais une décision de prix, retrait ou ordre), la nouvelle version naît en brouillon et montre les demandes reprises (data_json.commentaires_repris, lib/cdc/reprendre-commentaires.ts). Sur Aujourd'hui, la ligne « N demande(s) du client sur son plan de menu » porte le geste « ✓ Traité » sur place, demande par demande, avec Annuler 5 s (TraiterDemandes.tsx). |
| /cdc/regles | Les règles du CDC : ce que le générateur décide pour chaque client, dans l'ordre (verrou, structure, retraits, plats signature, prix, noms, onboarding, traçabilité, rédaction des fiches). Rend docs/planning/REGLES_CDC.md, embarqué au prebuild comme le registre photos ; même composant de rendu (app/components/RegistreRegles.tsx). Lecture seule : une règle change par constat daté → registre → lib/cdc/regles.ts + test sur le cas réel → contrôle de cohérence. Les règles 📋 attendent l'arbitrage de Redwane (brief 09/09, points 7 et 12). |
| /cdc/import | Importer un CDC fait main dans le circuit normal. |
| /cdc/photos | Retoucher les photos d'un CDC HTML autonome. |
| /visuels | Hub de production photos : une carte par client, la prochaine action en évidence. |
| /visuels/essais | Essais internes (avant/après changement de règle), jamais livrés. |
| /performance | Performance commerciale agrégée, filtrable par membre. |
| /commercial | 📊 Pilotage commercial (14/10, admins) : le reporting des admins observateurs (Mehdi, Redwane, Raouf) sur le commercial (Sharoon), rien n'y est saisi. Segment |
| /commercial/guide | 📖 Guide de l'espace commercial (14/10 nuit (7), Mehdi : « la partie prospection fonctionnelle, connectée et claire pour tout le monde ») : la journée type (Aujourd'hui → relances → liste « À faire » → RDV et clôture → bilan de 21 h), chaque écran du menu et à quoi il sert, ce que l'app fait toute seule (lead entrant, décideur, relances, kanban, « Il a réservé »), et les objectifs lus en base (jamais écrits en dur). Au menu Prospection (« Guide » pour le commercial), en anglais pour Sharoon. Contenu unique : lib/commercial/guide.ts ; un test vérifie que chaque écran cité existe, que la charte est tenue (ni tiret cadratin ni « free ») et que chaque texte a sa traduction. |
| /finance | Tableau financier des fondateurs (admins uniquement). |
| /costs | Coûts API réels 30 j + soldes fournisseurs + estimateur. |
| /equipe | Membres, rôles (Commercial/Admin) et objectifs. |
| /retours | Retours sur l'outil (07/11, Redwane) (admin) : ce que l'équipe signale depuis le menu de l'avatar (« Un retour sur l'outil », tous espaces, tous rôles) — thème (quelque chose ne marche pas · idée · écran pas clair · chiffre faux ou manquant · autre), sujet et capture facultatifs, adresse de la page jointe d'office. Héros = retours à lire, segment par statut (Nouveau · Retenu, à intégrer · Intégré · Écarté · Tous), 6 par page ; le statut se change sur la ligne, « Intégré » prévient l'auteur (Telegram/cloche). Stockage : crm_journal (entite outil, champ retour_outil, aucune table nouvelle), capture ré-encodée en JPEG dans documents/retours-outil/. Règles pures lib/retours-outil.ts (testées), route /api/retours-outil (POST tout membre, PATCH admin). Chaque nouveau retour notifie les admins. |
| /visuels/plaques | Bibliothèque d'art direction : archétypes, plaques, décors. |
| /visuels/contenants | 🏠 Bibliothèque de contenants MAISON (16/09 ; CATALOGUE depuis le 02/11) : les contenants nus où l'équipe pioche, sur la fiche client (Identité → 📦 → « Piocher dans la bibliothèque », action depuisCatalogue : copie chez le client). Plus jamais proposés ni appliqués d'office à la génération (garde-fou contenants-catalogue.test.ts). Grille de couverture famille × usage (un trou = un contenant inventé par l'IA). Même mécanique que la carte Packaging d'un client (lib/visuels/contenants-gestion.ts) ; résolution en cascade client → maison → contenant neutre (lib/visuels/contenants-resolution.ts, pur, testé) ; sonde contenants_references sur /sante. |
| /notifications | Centre de notifications : décisions à trancher en tête, non-lues par jour, filtre par famille (?famille=) avec compteurs, lues repliées, réglages d'envoi (13/09). 25/10 : familles en table unique (lib/crm/familles-notif.ts : Gestes des clients, Accès aux plateformes — non coupable, Paiements, Commercial, Générations, Rappels, Système, Divers), lue par l'écran, le réglage et l'envoi ; une validation de stratégie par le client arrive dans « Gestes des clients » (Telegram + appareil, brief pour les gestionnaires de compte). Décisions à trancher : 6 par page (?pd=), avec « N décision(s) ouverte(s) · la plus ancienne depuis le … ». |
| /visuels/matrice | La matrice expliquée : le parcours visuel complet, chiffres lus en base. Les 8 thématiques d'habillage en deux familles (tirées du plat / tirées du client) avec leur couverture RÉELLE sur les plats de la base (moteur rejoué) et la validation humaine posé/nu des 30 derniers jours (12/09). |
| /visuels/regles | Les règles de génération : ce que le moteur décide pour chaque photo, dans l'ordre où il le décide. S'ouvre sur le parcours d'une photo (7 décisions : quel plat, quelle liberté, quel décor, quel angle, quel contenant, quel contenu, quel habillage), puis chaque règle avec son titre en français et son incident d'origine dépliable. Lecture seule : la page rend docs/planning/REGLES_GENERATION.md, embarqué au prebuild — une règle change par le circuit incident → registre → code → banc, jamais par un champ de texte. Affiche aussi les conflits ouverts qui attendent un arbitrage humain. |
| /config/traductions | Traductions de l'admin : chaque libellé français et sa version anglaise (code, IA à relire, corrigé par l'équipe) ; une correction s'applique en ≤ 60 s sans déploiement (table traductions_admin). |
| /visuels/referentiel | Référentiel visuel : images de référence et libellés anglais des styles de bannière (A–E) et des styles photo, montrés au client dans le CDC (« Choose ONE direction »). Cartes premium (28/09) : image et ses deux gestes (uploader, choisir un visuel validé) à gauche, libellés et description du style au centre, aperçu de la carte client à droite ; chaque style photo porte une pastille ✓ / ⚠ par angle déclaré selon qu'un décor maison validé existe sur /visuels/plaques (même définition que la sonde plaques_familles_couvertes). |
| /prompts | Les prompts IA dans l'ordre du process, version réellement en prod ; fiches d'expertise des agents ; blocs de base du moteur photo (poids, usage 7 j, édition par la même API que la consolidation 🔬 — 10/09). |
| /sante | Santé du moteur : modèles IA, BiRefNet, VPS, latence base. |
| /acces/main/[id] | 🖐 |
| /acces/code/[id] | 🔢 |
| /sante?vue=acces | Accès plateformes (19/10, plan socle §9) : une pastille par plateforme (Talabat, Deliveroo, Careem, Keeta, noon, Uber Eats) — « lu aujourd'hui », « code demandé depuis N min », « code transmis, connexion en cours », « accès refusé le … », « geste à faire sur l'écran du portail » (Talabat, 25/10 : lu seul, bouton « Ouvrir l'écran ») — et, quand un collecteur attend un code reçu par e-mail ou SMS, le champ pour le taper depuis le téléphone (CodeAcces). Routes : POST /api/acces/demande (collecteur, Bearer CRON_SECRET ; ouvre la demande et notifie les admins sur Telegram avec le bouton « Taper le code » → /sante?vue=acces), GET /api/acces/demande?id= (le code rendu UNE fois puis marqué consommé), POST /api/acces/code (admin : fournit le code, 4 à 8 chiffres), POST /api/acces/session (collecteur : résultat de la connexion). Tout vit dans crm_journal (acces:demande, acces:session:<plateforme>), aucune migration ; règles pures lib/acces/demandes.ts (testées). Premier collecteur branché : scripts/plateformes-repli/careem-portail.mjs. |
| /workflows | Journal des exécutions robot + registre DV-01→DV-12 (liens n8n). |
| /config | Mode manuel/auto par étape + modèle d'IA par tâche + référentiels CRM + whitelist d'habillage (activer/désactiver une ligne, AJOUTER un terme à la main ou depuis les mots fréquents des menus réels — thématique + code du catalogue, 12/09 ; les anciennes listes épices/végétaux du routage ont été absorbées). |
| /emails | Templates emails/WhatsApp dans l'ordre du parcours, lus en base à l'envoi. |
| /social | Posts des comptes DelivUp (Instagram, Facebook) : 3 posts proposés chaque jeudi pour la semaine suivante (cron VPS social-generer, avant/après et bannières des clients LIVRÉS — PV émis, solde payé ou photos ouvertes ; jamais un clone TEST ni un refus §7 noté dans crm_journal champ portfolio), relus et validés par un admin, publiés à leur heure (cron VPS social-publier, 15 min). Depuis le 01/10 : « Créer un post » (choisir le restaurant puis ses photos ; une photo = avant/après ou bannière, plusieurs = carrousel de 2 à 10 ; photo d'origine retrouvée, montage et légende IA automatiques), « Publier maintenant » sur chaque post, « Autoriser quand même » un restaurant pas encore livré (crm_journal portfolio = autorise, auto pour revenir à la règle), connexion Meta en un clic (jeton de page chiffré dans le stockage). Refonte du 01/10 : héros chiffré sur 30 jours (portée ou interactions, vues, abonnés, taux d'engagement), tuiles des comptes avec logos (Instagram, Facebook ; LinkedIn et TikTok « bientôt »), segment Calendrier (mois, heure de Dubaï, glisser un post vers un autre jour) · À relire · Publiés (chiffres par réseau, relus chez Meta chaque heure pendant 30 jours, stockés dans resultats.<réseau>.stats) · Restaurants ; création en feuille (restaurant, photos, réseaux, moment) et éditeur avec aperçu Instagram. Portée et vues demandent la reconnexion « Activer les statistiques » (?stats=1). Depuis le 04/10 : les posts VIDÉO (genre video, un Reel 9:16 monté hors de l'app et déposé par creerPostVideo : social/<id>.mp4 + couverture social/<id>.jpg) se relisent dans l'éditeur (lecteur vidéo), se valident et partent à leur heure comme les autres : Reel Instagram partagé dans le fil (publierReelInstagram, jusqu'à 4 min d'encodage chez Meta) et vidéo de la page Facebook (publierVideoFacebook). Leurs visuels comptent comme déjà montrés. Table publications_sociales, module lib/social/, variables META_PAGE_ID, META_PAGE_TOKEN, META_IG_USER_ID. Plan : docs/planning/PLAN_RESEAUX_SOCIAUX.md. |
| /sync-notion | (admin) sas de validation des propositions de mise à jour, avant leur envoi vers Notion. |
| /login | connexion admin (OTP email) · /c/[prenom] — carte de visite publique. |
1 / 5