Allez sur /service/single. La barre d'outils supérieure est divisée en trois zones.

• Gauche — Historique · Guide · Titre de l'app · Enregistrer (💾)
• Centre — Liste déroulante de modèles (11 options)
• Droite — Liste partagée · Partager · Copier · Exécuter ▶ · Déployer 📦

Le corps contient quatre onglets d'éditeur (prompt · html · scss · vuejs) et un aperçu en direct à droite.

Deux façons de démarrer :

1. Modèles prêts à l'emploi — 11 options dans la liste : E-Commerce · Graphique boursier temps réel · Tableau de favoris · Tarification SaaS · Menu de borne · Réservation de restaurant · Hub créateur YouTube · Détail produit · Application de chat · Compte à rebours d'événement · Tableau de bord admin. Sélectionner un remplit instantanément les quatre onglets.
2. Prompt AI de zéro — décrivez ce que vous voulez dans l'onglet prompt (p. ex. « page menu café avec 3 onglets de catégories »), puis le bouton AI génère automatiquement les onglets HTML/SCSS/Vue.

Changez d'onglet pour modifier chaque couche.

• prompt — la description utilisée pour la régénération par AI. Éditer + régénérer rafraîchit le code.
• html — structure et texte. Numéros de ligne + recherche Ctrl+F.
• scss — couleurs, polices, espacements. La plupart des modèles déclarent les variables de thème en tête du fichier.
• vuejs — données et interactivité. Utilise data() { return { ... } }, methods: { ... }, mounted().

Cliquez Exécuter ▶ à droite de la barre d'outils pour rendre la page en direct dans le panneau d'aperçu. Cliquez à nouveau après modifications pour rafraîchir.

Le bouton Historique en haut à gauche ouvre vos versions enregistrées récentes. L'icône → Charger sur une ligne restaure cet état — votre filet de sécurité quand une modification casse quelque chose.

Deux manières de sortir votre travail :

• Déployer 📦 — bouton tout à droite de la barre d'outils. Après avoir connecté un compte Railway, une modale de progression s'exécute ; en 1–3 minutes votre page est en ligne sur un domaine gratuit.
• Partager — l'icône partage dans la barre. Ajoutez titre/description/tags et publiez à la communauté ; les autres peuvent forker votre travail (c'est un partage de modèle, pas un déploiement en live).

Ouvrez Service > Projet depuis le menu. La disposition :

• Barre latérale gauche — boutons bleus [+ Nouveau projet] / [+ Nouvelle équipe] plus les sections Récents, Solutions publiques, Mes projets, Équipes.
• Fil d'Ariane supérieur — bascule entre les vues liste ↔ détail ↔ programmes ↔ déploiement.
• Corps — cartes montrant pour chaque projet : badge de domaine, type BD, nombre de programmes/routeurs.

Cliquez [+ Nouveau projet] → modale d'assistant.

1. Étape 1 — cartes de fonctionnalités et diagramme de flux.
2. Étape 2 — configuration
   • Domaine (obligatoire) — l'un de vos domaines existants
   • Dataset (obligatoire) — la BD utilisée par ce projet
   • Nom / description du projet
   • Attribution d'équipe (cases à cocher)
3. [Enregistrer] en bas — activé seulement quand domaine et dataset sont choisis.

Un programme est une page ou un bloc fonctionnel du projet. Remplissez les infos de base dans le formulaire de création, puis plongez directement dans l'éditeur de code pour écrire Blade + SCSS + Vue sur un seul écran.

1) Créer un nouveau programme

La barre d'outils du détail projet affiche [+ Nouveau programme] et [+ Nouveau routeur]. Cliquer sur Nouveau programme ouvre une modale formulaire.

• Nom du programme (p. ex. home, admin_dashboard)
• Description — une ligne sur ce qu'est l'écran/la fonctionnalité
• Type — frontend (HTML/CSS/JS) / backend (PHP)
• Routeur — choisir un routeur existant, ou en créer un en inline avec alias + chemin URL + méthode HTTP

2) Ouvrir l'éditeur de code & disposition de l'écran

Cliquer sur l'icône d'une ligne de programme bascule en vue éditeur. L'écran est divisé en trois zones.

• Fil d'Ariane + barre d'outils supérieurs — nom du programme courant, indicateur d'état de sauvegarde, et un groupe de boutons-outils, tous sur la même ligne.
• Barre latérale gauche — liste des autres programmes du même projet. Chaque ligne a des icônes rapides (Code) et (Builder) pour sauter entre vues.
• Éditeur 3 colonnes au centre — trois panneaux CodeMirror 6 (HTML / CSS / JavaScript) côte à côte. Cliquer sur un panneau le met en surbrillance focused, et le thème de l'éditeur suit automatiquement votre réglage Clair/Sombre.

3) Ce que contient réellement chaque onglet

• HTML — HTML pur plus directives Blade (@if, @foreach) et sortie @{{ ... }}. Variables côté serveur, conditions et boucles directement dans le template.
• CSS — syntaxe SCSS (imbrication, références &, variables, mixins) telle quelle. Compilée automatiquement au déploiement.
• JavaScript — forme Vue 3 Options API (data / computed / methods / mounted). Le runtime la capte automatiquement et la lie au template de la colonne HTML.

Les raccourcis CodeMirror standard fonctionnent comme attendu : Ctrl+F pour la recherche dans l'éditeur, Ctrl+Z annuler, Ctrl+/ commenter, fermeture auto des crochets/balises, retour à la ligne doux.

4) État d'édition & cycle de sauvegarde

Dès que vous changez un seul caractère, Non enregistré apparaît dans la barre supérieure pour signaler des changements non sauvegardés. Cliquez sur [ Enregistrer] et les trois onglets partent en même temps ; au succès, un Enregistré clignote brièvement.

Chaque sauvegarde écrit les trois colonnes dans le corps du programme et enregistre simultanément l'instant comme revision. Enregistrer = instantané de version auto — vous pourrez revenir à n'importe laquelle plus tard.

5) Deploy on Save — en live à chaque enregistrement

Basculer la bascule [Deploy on Save] à côté d'Enregistrer sur ON et chaque sauvegarde auto-déploie aussi le changement vers la destination du projet (p. ex. le serveur principal). Un court badge « N déployés » apparaît brièvement après l'envoi, donc pas besoin de cliquer un bouton Déployer séparé — la boucle « éditer → en ligne » se referme toute seule. La bascule est mémorisée par projet.

6) Le cluster d'outils supérieur en coup d'œil

• Base de données — ouvre la pop-up liaison dataset. Donnez un nom de variable, choisissez une table, réglez WHERE/LIMIT/ORDER, et le résultat de la requête est injecté automatiquement dans le programme sous cette variable.
• Builder — bascule vers une vue d'édition à base de blocs du même programme. Vue Code et vue Builder partagent la même sortie.
• Code Search — panneau recherche & remplacement projet-wide (voir 7 ci-dessous).
• Revisions — historique de révisions avec panneau diff (voir 8 ci-dessous).
• Guide de l'extension — pop-up expliquant comment éditer et déployer le même projet localement via l'extension VSCode.

7) Recherche & remplacement projet-wide

Tapez un mot-clé en haut et pressez Entrée ou le bouton . Les onglets de portée donnent deux choix — Project (tous les programmes du projet courant) ou Revisions (inclure les instantanés passés).

• Les résultats montrent un badge de type (HTML / CSS / JS), l'ID du programme, son nom et le nombre de correspondances.
• Les onglets de filtre de type All / HTML / CSS / JS restreignent à une seule colonne, avec le décompte par onglet.
• Cliquer sur la flèche à côté d'un nom de programme saute directement dans l'éditeur de ce programme.
• Cliquer [Show More] sur une ligne ouvre à droite le panneau de contexte avec le code entourant chaque correspondance.

Replace vit sur la deuxième ligne. Choisissez une portée (All / HTML / CSS / JS), remplissez termes de recherche et de remplacement, pressez le bouton — une confirmation « changements effectués dans N fichiers » apparaît, et sur Oui le remplacement projet-wide s'exécute en un coup.

8) Revisions · historique et retour arrière

Chaque sauvegarde ajoute un instantané ici. Dès que le panneau s'ouvre, il lance automatiquement un diff la dernière révision ↔ vos éditions actuelles à droite.

• Gauche : la liste des révisions (paginée). Chaque ligne a trois icônes d'action :
  • Revert — écraser l'éditeur avec cette révision (les changements non enregistrés sont perdus).
  • Diff avec actuel — cette révision ↔ ce qui est dans l'éditeur maintenant.
  • Diff avec la précédente — cette révision ↔ la révision immédiatement avant.
• Droite : diff côte-à-côte avec onglets HTML / CSS / JS. L'onglet qui a réellement changé est auto-sélectionné.

9) L'ordre réel qu'un auteur suit

1. Ouvrir l'éditeur depuis l'icône d'une ligne de programme.
2. Écrire dans les onglets HTML(Blade) → CSS(SCSS) → JS(Vue) selon ce que le changement nécessite.
3. Aller chercher Base de données quand il faut des données, Code Search pour des recherches cross-programmes, Revisions pour comparer avec l'historique.
4. Appuyer [Enregistrer] → attendre « Enregistré ». Si Deploy on Save est ON, le déploiement part aussi.
5. Si quelque chose casse, revenir à l'instantané approprié via le panneau Revisions.
6. Pour un renommage qui traverse beaucoup de programmes, utilisez Code Search → Replace pour le faire en une action confirmée.

Enregistrez des routeurs dans la section pliable des routeurs de la vue détail, ou via [+ Nouveau routeur].

• alias — identifiant interne (p. ex. home, api_orders)
• Chemin URL — chemin public (p. ex. /home, /api/orders)
• Méthode HTTP — GET / POST / PUT / DELETE / ANY

Reliez un routeur à un programme dans le sélecteur de routeur du formulaire du programme — les visiteurs tombant sur cette URL déclencheront le programme.

Cliquez sur l'icône 🚀 (fusée) d'une carte dans la liste des projets pour ouvrir la modale de déploiement.

1. Choisissez un mode de déploiement : integrate (réutiliser le Docker existant) · rebuild · new
2. Cliquez [Lancer le déploiement] → le pipeline en 9 étapes s'exécute (chacune devient verte en fin d'étape) :
   ① Création du pack → ② Préparation BD → ③ Préparation données → ④ Transfert serveur → ⑤ Build Docker → ⑥ Deploy Docker → ⑦ Connexion domaine → ⑧ Installation terminée → ⑨ Stabilisation du service
3. Au final, l'URL du domaine est en ligne et immédiatement joignable.

Ouvrir le Code Builder via l'icône sur une ligne de programme. Huit onglets d'étape en haut (DB · List · Detail · Search · Hook · Style · Code · Menu) ; la plupart des programmes se terminent en les parcourant une fois de gauche à droite.

Le flux en un coup d'œil

• [1] DB
  choisir tables
  choisir champs
  WHERE · ORDER
• [2] List
  placer les champs
  groupes · tri
  cinq layouts
• [3] Detail · Search
  façonner le formulaire
  choisir composants
  séparation insert / update
• [4] Hook · Code
  injecter des hooks
  [Builder] émet le code
  réutiliser les snippets
• [5] Menu
  arbre 4 niveaux
  [menu:code]
  include commun

Onglet DB en détail — si la connexion est coupée, vous voyez d'abord une bannière « DB non connectée » avec un guide de reconnexion. Dès qu'elle vit, le panneau s'ouvre ainsi :

• #list (éditable) — une table principale. Choisissez-la dans la liste déroulante et pressez [Select]. C'est la table dont vous allez éditer / supprimer / insérer des lignes.
• #list2 (lecture seule) — une table secondaire pour les jointures (ex. récupérer des libellés ou des noms).
• #list3, #list4 … — cliquez sur le dans la barre latérale pour ajouter d'autres tables.
• Trois sélecteurs de champs — depuis la même liste de colonnes, vous multi-sélectionnez séparément « champs pour List », « champs pour Detail » et « champs pour Search ». Une case à côté de chacun active / coupe tout d'un coup.
• DB Search Option — trois lignes WHERE · ORDER BY · LIMIT, plus un Raw Query optionnel. Elles deviennent le filtre de requête par défaut de la liste.
• En bas, [Update] enregistre l'étape ; [Reset] recommence.

Les « champs pour List » choisis dans l'onglet DB apparaissent en candidats à gauche. Cet onglet définit à quoi ressemble l'écran de liste et comment chaque colonne se comporte.

Choisissez d'abord un des cinq layouts — les options ci-dessous s'ajustent automatiquement.

• datatable — tableau avec tri et pagination intégrés.
• table — tableau simple avec bascule de tri par colonne.
• grid — grille de cartes.
• modal — liste qui ouvre les lignes en modales sur place.
• slots — intégrée dans les emplacements d'un layout frame.

Ajouter des items (colonnes de champ) — cliquer [+ Add Item] à gauche ouvre la liste des candidats. Choisir un champ existant ou utiliser + new pour ajouter un champ virtuel (pour des valeurs calculées ou composées).

• Par ligne : header_value (libellé d'affichage) · header_text (description) · width · mutator (code personnalisé par champ) · sortable · linkable · use_opt (valeur d'option) · (bascule afficher/masquer).
• ↑↓ pour réordonner, pour supprimer, la baguette pour du code assisté par IA.

Regroupement — [Create Group] en haut à droite regroupe les champs sélectionnés en 1–5 groupes. Tapez … pour assigner des items à un groupe.

• En mode groupe, [Toggle Panel] bascule la vue sur un panneau d'édition de groupe. Vous y saisissez, par groupe, un group name (identifiant interne), un group header (titre affiché) et un layout (comment les colonnes à l'intérieur du groupe sont agencées). En haut du panneau, la group display method décide comment plusieurs groupes sont affichés — onglets, boîtes côte à côte ou une unique ligne input group.

[Update] en bas enregistre l'étape.

L'onglet Detail définit le popup détail / édition (modal) qui s'ouvre quand vous cliquez une ligne de la liste. La mise en page ressemble fortement à l'onglet List ; le supplément clé est le choix d'un composant d'entrée par champ.

• Liste déroulante Component — type d'entrée par champ : text · textarea · select · checkbox · radio · date · datetime · file · editor · hidden …
• opt_name / opt_value — options spécifiques au composant (liste d'options pour select, extensions autorisées pour file, format pour date …).
• Icône triangle insert / update — bascule si le champ apparaît dans le formulaire Add, le formulaire Edit, ou les deux. P. ex. id / created_at sont généralement edit-only.
• Bascule required (+/-) — champ obligatoire.
• layout — placement / largeur de cellule (1/2, 1/3, pleine largeur …).
• Dans la barre d'outils en haut, choisissez la colonne clé primaire (celle qui identifie une ligne de manière unique) et la clé de page de détail (celle qui passera dans l'URL à l'ouverture d'une page détail).

L'onglet Search partage le même éditeur. Différences :

• Match mode — comment la valeur saisie est comparée à la BD : contains (correspondance partielle) · equals (exacte) · one-of (contre une liste séparée par virgules) · full-text (recherche de mot dans un texte long), etc.
• Les composants reflètent l'UX de recherche — saisies libres, filtres à liste déroulante …

Les entrées de recherche sont auto-placées au-dessus de la liste ; leur soumission est combinée en AND avec le WHERE de l'onglet DB.

À ce stade, les étapes 1–3 ont rempli les « ingrédients » de l'écran. Il est temps d'ajouter comportement fin, permissions et logique personnalisée, puis de sortir le code.

Onglet Hook — affiche un petit diagramme du scaffold HTML et JavaScript généré, avec un ensemble de hook points (badges) où injecter du code.

• Squelette HTML / JavaScript miniature en haut — les positions <?php ... ?>, <style>, <body>, modale, data / computed / mounted / methods sont marquées pour que vous voyiez exactement où votre hook atterrit.
• Dépliez n'importe quelle ligne de hook avec pour révéler son éditeur. Double-clic pour le mode large.
• Clic droit dans l'éditeur → Save Snippet / Load Snippet. Sauvegardez une logique récurrente (vérifications de connexion, gardes de permission, pré-traitement d'upload …) sous un ident et réutilisez-la dans n'importe quel autre programme.

Onglet Style — éditeur CSS / SCSS pour ce programme. Basculez css_integrate pour fusionner avec le bundle CSS global du projet ; basculez Backend Code pour attacher aussi un snippet PHP.

Onglet Code · la génération réelle — c'est ici que vous pressez [Builder].

• Deux éditeurs CodeMirror — template Blade à gauche, Vue Script à droite. Ils aperçoivent le code assemblé à partir des étapes 1–3 et de vos hooks.
• Session Condition, quatre cellules — Add / Delete / Read / Detail. Chacune prend un prédicat de session (p. ex. user_level>=3) qui garde cette opération CRUD.
• Grille de fonctionnalités — activez des fonctionnalités réutilisables (export CSV / Excel, multi-suppression, persistance du tri …) et réglez les paramètres nécessaires.
• Le bouton [Builder] en bas assemble tout en Blade + Vue Script et l'écrit directement dans le code réel du programme. Ensuite l'éditeur de code habituel prend la main — éditer, enregistrer, déployer comme d'habitude.

Une fois que vous avez plusieurs programmes, vous voudrez une navigation partagée. L'onglet Menu est un assistant qui construit un arbre de menu jusqu'à 4 niveaux de profondeur et le laisse déposer partout via un shortcode d'une ligne.

Menu group — un namespace qui contient une définition de menu à l'intérieur du projet.

• Choisissez un groupe existant dans la liste déroulante, ou tapez un nouveau code de groupe (alphanumérique + underscore, 2–9 car.) et appuyez [Create Menu Group].

Éditeur d'arbre à 4 profondeurs — sélectionner un groupe révèle une table Depth 0 à gauche. Percer dans une ligne ouvre la profondeur suivante à sa droite ; jusqu'à quatre colonnes s'alignent au fur et à mesure (Depth 0 → Depth 3).

  Depth 0 ┐
          ├─ Depth 1 ┐
          │          ├─ Depth 2 ┐
          │          │          └─ Depth 3   ← max 4 niveaux
          └─ Depth 1'
           ...

• Chaque table de profondeur a son propre [+ Add Menu] — le popup laisse remplir nom, alias d'URL et condition de session optionnelle.
• Par ligne : éditer, supprimer, flèches pour réordonner.
• Cliquer le bouton check au bout d'une ligne creuse dans les enfants de cet item dans la colonne de droite.

Injecter via un shortcode — une fois l'arbre en place, déposez-le sur vos pages réelles. Dans une zone include commune (un layout frame, un partial d'en-tête / sidebar), une seule ligne suffit :

<?php echo get_menus_by_code($project_id, 'group_code', 'nav nav-menu', 'role="navigation"'); ?>

Au rendu, le helper get_menus_by_code() lit la table project_menu et assemble des <ul>/<li> jusqu'à quatre niveaux. Les lignes de menu portant une session_condition ne s'affichent que si la session de l'utilisateur la satisfait. L'item dont l'URL correspond à la page courante reçoit automatiquement la classe active.

Allez à /layout/page.

• Barre latérale gauche — bouton [+ Nouvelle page] + sections Récents / Partagés / Mes pages.
• Barre d'outils supérieure — recherche (champ + mot-clé), onglets de bascule Block/Frame/Page, bascule Grille/Liste, lignes par page (20/50/100).
• Corps — cartes de pages avec titre, description, frame et indicateur déployé-ou-non.

Cliquer une carte de page ou l'icône de grille ouvre le builder plein écran. Il a trois zones.

• Panneau gauche — haut : bande filmique Frame (choix du modèle responsive) ; milieu : canevas Frame (iframe + overlays de slots) ; bas : bande filmique Block (blocs glissables).
• Panneau central — Data sampler (onglets Architecture / Data) pour le binding API.
• Panneau droit — Déploiement + assistance IA.

Après avoir choisi un Frame, des slots de dépôt transparents apparaissent sur l'iframe. Commencez à glisser un bloc depuis la bande filmique Block — les slots s'illuminent en bleu — relâchez pour installer le bloc dans ce slot.

Les slots installés passent en « filled » ; re-cliquer sur le slot permet de changer. Le même bloc peut remplir plusieurs slots, et une même page mélange librement des blocs différents.

Dans l'onglet Architecture du panneau central, associez les clés de données d'exemple de chaque bloc aux vraies clés de réponse API.

1. La colonne gauche de chaque carte de bloc montre l'arbre de clés d'exemple que le bloc attend.
2. La bascule ⚡ (éclair) au centre active le mode binding API.
3. À droite, choisissez un endpoint construit dans le service Base de données → l'arbre des clés de réponse de cette API se déplie.
4. Cliquez pour apparier une clé d'exemple à une clé d'API — une ligne de mapping les relie et apparaît en bas dans « Pair Map » sous la forme sample_key → api_key.

L'onglet Data affiche la réponse JSON brute pour le débogage.

Utilisez le panneau droit pour déployer.

• Expose parameters — liste des paramètres query/path à exposer dans l'URL. Chaque ligne a une case d'activation, un nom, une source (query/path), une valeur par défaut. [Add] agrandit la liste.
• Deploy URL — taper un slug tel que /my-page met à jour l'aperçu en direct.
• [Deploy] — affiche une barre de progression + label d'étape ; terminé = en ligne sur le domaine.
• En dessous, Deploy history accumule les URL passées que vous pouvez revisiter.

Ouvrez Affichage > Diaporama depuis le menu. La barre latérale gauche a un bouton [+ Enregistrer diaporama] et un filtre « Diaporamas communautaires » ; le corps est une vue Grille/Liste.

Chaque carte montre titre, nombre de scènes, durée totale de lecture et état de déploiement.

Cliquez [+ Enregistrer diaporama].

1. Étape 1 — Introduction : cartes + diagramme de flux (Remote → Upload → Diaporama → Navigateur), expliquant le mapping URI, les canaux, 67 transitions et le contrôle de timeline.
2. Étape 2 — Enregistrer : saisissez titre + description → [Enregistrer] → vous atterrissez dans l'éditeur détaillé.

Le panneau Timeline central définit la lecture.

• Durée totale — curseur, 10–3600 s.
• Nombre de scènes — curseur de plage ; la durée par scène se calcule automatiquement.
• Transitions — choisir parmi un catalogue de 67 (fade, slide, cube, page flip, etc.).
• Confirmez avec le bouton [Enregistrer].

Curseur paramétrique (Page Sequencer) auto-génère N scènes à partir d'une seule page Layout en variant un paramètre.

• Nom du paramètre (p. ex. month), algorithme (by_range / by_comma / by_json), valeurs (p. ex. 1-12 pas 1).
• Résultat : 12 scènes auto-générées, une par mois.

Canaux d'affichage (MAX uniquement) — diffuser le même diaporama avec des compositions différentes sur différents écrans.

• Nom de canal (p. ex. « Catégorie A », « Catégorie B ») + multi-sélection des diapos à inclure.
• Activer « Utiliser un paramètre de requête » mappe les canaux aux URL via ?keyword=value.

Le panneau de déploiement (se-deploy) à droite publie le show.

1. Tapez un chemin URL (p. ex. /menu-signage) + choisissez un domaine dans le menu déroulant.
2. Cliquez [Déployer le diaporama] — barre de progression, messages « Déploiement en cours... » et « Déploiement terminé ».
3. Une carte d'historique de déploiement enregistre domaine / chemin / horodatage.

Pointez le navigateur de chaque écran sur l'URL en plein écran — terminé.

Ouvrez Data > Parser depuis le menu. Barre latérale gauche avec [+ Nouvelle règle de parseur] plus des sections Récentes / Publiques / Mes règles ; le corps est une vue Grille/Liste.

Chaque carte a les icônes (Run) · (Item test) · (Planification — MAX) · (Éditer) · (Dupliquer) · (Supprimer).

[+ Nouvelle règle de parseur] ouvre un assistant en 3 étapes. L'assistant enregistre seulement les infos de base de la règle (nom, description, dataset cible) — l'URL de crawl, les sélecteurs et le mapping de champs sont remplis ensuite sur l'écran de paramétrage du parseur qui s'ouvre automatiquement à la fin de l'assistant.

1. Étape 1 — Vue d'ensemble : introduction « Qu'est-ce qu'une règle de parseur ? » suivie de quatre cartes de fonctionnalités côte à côte (Extraction de données, Crawling web avancé, Mapping de champs, Réutilisation) et un schéma « Parser Pipeline » montrant d'un coup d'œil les quatre flux supportés (Règle parseur → BD / → Macro → BD / → Scheduler → BD / → Endpoint API → lancement de service). Pressez [Suivant].
2. Étape 2 — Connexion base : cliquez une carte de dataset (avec badge db_type, nom de table, domaine) pour choisir où atterriront les lignes extraites. S'il n'y a pas de dataset, seul un lien « Go to Dataset » s'affiche. Presser [Suivant] lance automatiquement un déploiement en 3 étapes (« Agent connect → Parser engine deploy → Deploy complete ») qui provisionne le moteur du parseur sur l'agent docker choisi.
3. Étape 3 — Créer la règle : entrez le nom de la règle et une description optionnelle, puis pressez [Create Rule]. Les infos de base (nom, description, dataset, flag de partage) sont enregistrées, l'assistant se ferme, et l'écran de paramétrage de la règle nouvellement créée s'ouvre automatiquement.

C'est là que l'assistant prend fin. Sur l'écran de paramétrage du parseur, vous remplissez alors l'URL cible, les options HTTP, le Loop Splitter, les sélecteurs XPath/JSON et le mapping de champs (voir ▶︎ Étape 3 · URL cible & sélecteurs d'extraction), vérifiez sur l'onglet « Test » et sauvegardez — alors seulement le parseur est prêt à vraiment tourner.

Une barre d'étapes en haut suit la progression ; [Retour] revient à l'étape précédente (désactivé pendant le déploiement). La modale de l'assistant ne se ferme que via le bouton [x] en haut à droite.

(Description de l'écran d'édition de règle du parseur : URL cible, Loop Splitter, sélecteurs XPath/JSON, fonctions de post-traitement et auto-enregistrement de la règle via AI Prompt. Le détail ci-dessous n'est pas encore entièrement traduit en français.)

Enter the Target URL at the top of the editor and combine three techniques to extract rows.

• Loop Splitter (3 inputs — primary + 2 secondary) — string patterns that chop HTML into repeated units.
• XPath selectors — up to 3 levels, extracting fields inside each unit. The selector should point at a node set (array), not a leaf value — if the actual data sits at //h3/a/text(), enter just //h3/a so the result comes out as an array.
• JSON selectors — for JSON APIs, dot/bracket paths. Same idea: point at the array path. If the data has a shape like data.items[0].title, enter data.items as the selector so the item array is produced.
• Post-processing functions — chain trim(@p), replace(...), regex(...), strtoupper(@p), slice(), remove() per column.

The fastest path is to feed a slice of the source (via the Loop Splitter) into the AI Prompt and let the AI response auto-register the rule. Hand-tuning selectors one by one is much slower — especially when the page structure is non-trivial.

Auto-register with an AI prompt (recommended)

Instead of hand-filling selectors, hand the sample to an AI and apply the completed rule it returns.

1. Prerequisite — enter the Target URL and run the extract test once from the "Test" tab so a response body exists. That body is injected into the prompt automatically.
2. Click the highlighted "AI Prompt" button (wand icon) at the top of the test result panel. A prompt is auto-built in the editor area just below it, picking the right language for the document out of 8 supported (Korean · English · Japanese · Chinese · Russian · German · French · Spanish) and the right document type (HTML / JSON / XML).
3. Click inside the editor panel → Ctrl+A → Ctrl+C to copy everything.
4. Paste into an AI such as ChatGPT / Claude / Gemini and run → the AI returns a rule JSON.
5. Copy the response, then click the "Import Pattern" button (import icon) in the same panel — a paste-in textarea opens. Paste and click [Apply Pattern].
6. Loop splitter, selectors, unique key, and every column are mapped into the right slots of the rule automatically; the editor switches to the "fields" tab so you can check the result immediately. A summary toast like "Pattern applied: N fields" appears at the bottom.

If the AI response isn't valid, you'll see an "Invalid JSON" toast and your existing values stay untouched — safe to retry.

L'icône (fiole) sur une carte ou l'onglet « Test » dans l'éditeur ouvre la modale de test.

• Barre du haut : « N items / M colonnes »
• Export : CSV · XLSX · JSON · HTML
• Grille : Row# + en-têtes de colonnes auto-détectés
• Hover sur une cellule → bouton « Copy »

Ajustez les sélecteurs, testez, ajustez encore, testez — boucle jusqu'à ce que la sortie colle.

(Usage de la modale « Run » ouverte via l'icône ▶ (lecture) d'une carte de règle — interface en trois panneaux (liste d'URLs / Plan & Execute / retour de résultat), étapes URI · Fuzzer · Preview · Run mode · feedback live et effets attendus. Le détail ci-dessous n'est pas encore entièrement traduit.)

Clicking the (Play) icon on a rule card opens the Run modal — the single screen where you decide where to hit, with what parameter combinations, how to run, and where to store results, then launch and monitor in place.

• [1] URI
  Target address
  {param} tokens
  path · query
• [2] Fuzzer
  Parameter mix
  1-N · A,B · DB
  combine / pair
• [3] Preview
  Expand URLs
  Fill left panel
  Verify count
• [4] Run · Save
  Runtime / Schedule
  DB / CSV / JSON
  Items per run
• [5] Start
  Flow checks
  [Start] enables
  Pause anytime
• [6] Feedback
  Progress · stats
  Per-URL log
  Macro chain

Interface at a glance — 3-panel layout

• Left panel · URL list — shows the preview URLs generated from the center panel, numbered. While a run is in progress the current row is highlighted and finished rows show a check, so you can see progress at a glance. Each row has a button to test-parse that single URL in isolation, and a at the top-right loads past run configurations for reuse.
• Center panel · Plan & Execute — the main body: define URI, fuzzer parameters, run/save mode, then launch from the flow diagram's [Start] button.
• Right panel · Result feedback — two tabs. "Results" shows live statistics and log during a run; "Parse Test" shows the cell-level preview when you click on the left.

Step-by-step

1. URI input — first card in the center panel. Two example styles — path-token (/category/{param}/list) and query-string (?param={param}) — are pinned to the header as clickable hint badges. Names inside the curly braces {...} must match the parameter names defined in the next card so substitution works.
2. Fuzzer parameters — the card that builds the list of values injected into each {...}. A top toggle picks one of two modes:
   • Combination — cartesian product of every parameter's values. E.g. {page}=1..10 × {cat}=A,B → 20 URLs.
   • Paired — zip-style: the n-th value of every parameter together. All lists must have the same length.
   For each parameter pick a name and a generator — 1-N (range with step), A,B (comma list), DB (pull from a dataset column with optional WHERE/ORDER/LIMIT), [,] (JSON array), or \n (newline list). adds another parameter.
3. URL preview — the [URL preview] button at the bottom of the card expands the URI + parameter combinations into real URLs listed in the left panel. The count shows in the header badge, so you can immediately verify the expected size (e.g. range 10 × categories 2 = 20).
4. Run mode & Save mode — the third card.
   • Run: Runtime (one-off) / Schedule (periodic, MAX plan). Schedule reveals start-time and interval (minutes) inputs inline.
   • Items per run: Page / PK.
   • Save: DB (dataset, or a custom external DB via host/user/password/database), CSV, JSON, or SQL. DB mode also surfaces table (collection) name and a DBMS badge so you can confirm the destination visually.
5. Visual flow guide & Start — below the cards, a small flow diagram chains URI → Parameter → Preview → Save → [Start] → Macro. Each node lights up with a green check as its input is filled. Once required nodes are valid the [Start] button at the top-right activates. (If you pin a macro on the trailing node, it runs automatically right after the scrape.)
6. Live feedback while running — the moment you press Start, the top progress bar fills up (parsed / total) and the right-panel "Results" tab updates in real time.
   • Stat cards: Total · Passed · Failed · Remaining — the red "Failed" card only appears when a failure actually happens.
   • Log view: one line per URL as it's processed, latest highlighted, each showing time · URL · +rows added; failed URLs carry an badge.
   • Pause / Resume: the Start button switches to [Pause] during a run — stop at any time safely.
   • File-save modes (CSV/JSON/SQL): the Output textarea below fills with the generated file body; a button grabs it immediately.

What this run screen buys you

• Plan, run and observe in one screen — no tab hopping. Tweak the URI, parameter list, or save target and immediately re-run. The configure → run → verify loop is as tight as it gets.
• A fuzzer that scales — generate tens of thousands of URLs without writing one by hand. Ranges, comma lists, DB columns, JSON arrays, newline lists — category × page × date combinations are ready in seconds.
• DB-backed parameters (by_db_field) read a key table column and iterate detail pages on top of it — the classic "list → detail" two-stage crawl works end-to-end without spreadsheets or glue scripts.
• Transparent live feedback — per-URL checkmarks, streaming log, and success/fail counters make it easy to spot exactly where things stalled. Rerun a failed row on its own via to isolate the cause.
• Resource-friendly architecture — the actual HTTP and parsing runs on your docker agent, not the QuickStart server. Large crawls don't affect the service's bandwidth.
• Macro chaining — attach a macro to run right after the scrape for notifications, aggregation, or post-processing, turning collect → clean → notify into a single action.

(Structure de la carte de planification (MAX uniquement), diagramme de flux en 5 étapes, vérification des résultats dans l'éditeur de base de données, astuce de chaînage avec un macro, etc. Le détail ci-dessous n'est pas encore entièrement traduit.)

Scheduled runs are a hands-off mode: the docker agent executes the rule on a fixed interval on its own, even while the screen is closed. Rows flow straight into the dataset (DB), so to actually see the results you open the target table in the Database editor.

• [1] Schedule setup
  Start time
  Interval (min)
  Active toggle
• [2] Agent sync
  [Save] pushes
  config to the
  docker agent
• [3] Auto periodic run
  Agent runs alone
  QuickStart idle
  Background task
• [4] DB accumulation
  Rows INSERT into
  dataset table
  Dup keys skipped
• [5] Check in Database editor
  Data > Database
  Open the table
  Query with WHERE/ORDER

The (clock) icon on a card opens the schedule modal (FREE/PRO plans show a "Max" ribbon).

• Start time (hour 0–23, minute 0–59)
• Interval (minutes)
• Active toggle
• Run mode: Single URL / URL list (batch)

[Save] persists to QuickStart and auto-syncs to the selected docker agent. The agent is what actually runs the schedule — QuickStart never sits in the traffic path.

Verify results in the "Database editor"

Because scheduled runs are headless, the way to check the output is to open the target dataset directly and inspect the rows that piled up.

1. Open Data > Database from the left menu.
2. Click the dataset card that the parser rule is linked to — this opens the Database editor.
3. Pick the target table from the left table list (e.g. items, products, etc.).
4. Use WHERE / ORDER BY at the top to bring recent rows to the top (ORDER BY created_at DESC, ORDER BY id DESC) and inspect what the last scheduled run added.
5. A quick row count (COUNT) or a date-range filter is enough to sanity-check trend — if the count grows each interval, the schedule is healthy.

The run log itself is shown as a table in the Run modal's right-panel "Results" tab when schedule mode is active, but for content verification of the actual harvested data, the Database editor is always the source of truth.

Ouvrez Data > Macro depuis le menu. Barre latérale gauche avec les sections Récents / Communauté / Mes macros ; le corps est une vue Grille/Liste. La barre d'outils supérieure prend en charge la recherche par nom ou description.

Cliquez sur [+ Nouveau macro] dans la barre latérale pour ouvrir immédiatement l'assistant de création.

[+ Nouveau macro] ouvre un assistant en 4 étapes. Cet unique assistant couvre à la fois l'enregistrement des infos de base du macro et la préparation de son serveur d'exécution.

1. Étape 1 — Intro macro : un « Qu'est-ce qu'un macro ? » d'introduction avec quatre cartes (Chaînage de pipelines, Pattern adaptateur, Entrée → Sortie, Génération de code) et un diagramme de flux montrant quatre topologies supportées (Requête BD · Chaînage · Parseur · Planificateur). Aucune saisie — pressez [Suivant].
2. Étape 2 — Mode de connexion : préparer l'endroit où le macro tournera vraiment. Deux options :
   • Déployer un nouveau serveur de macro — connectez votre compte Railway (collez le token), puis choisissez langue · framework · stack principale · add-ons optionnels (MongoDB / FFmpeg / Puppeteer / WebSocket, etc.) · identifiants BD. Cliquer [Déployer le serveur] lance un pipeline en 6 étapes (Receive → Decrypt → Docker build → Deploying → Network → Verify) et votre compte se retrouve avec un runtime de macro dédié.
   • Connecter un serveur de macro existant — si vous avez déjà un serveur qui fait tourner votre code macro, entrez ses infos de connexion pour vous y rattacher.
   Une fois le serveur prêt, l'assistant passe automatiquement à la suite.
3. Étape 3 — Sélection du type : choisissez l'un des 24 types de macros (pipeline ETL · API batch · migration de données · import CSV/Excel · et plus). Le code de départ correspondant au type — avec paramètres d'entrée, squelette de boucle et structure de sortie — est auto-généré comme point de départ pour l'étape suivante.
4. Étape 4 — Enregistrer : entrez un nom de macro (p. ex. « Sync BD de nuit », « Traduction en masse ») et une courte description, puis pressez [Créer]. Le macro est enregistré, l'assistant se ferme, et la vue détaillée (éditeur de code) s'ouvre automatiquement.

Une barre d'étapes en haut suit la progression ; [Retour] renvoie à une étape précédente (désactivé pendant un déploiement). La modale ne se ferme que via le bouton [x] en haut à droite.

À la fermeture de l'assistant, un éditeur à 3 volets s'ouvre : à gauche, la définition des champs d'entrée ; au centre, l'éditeur de code avec onglets PHP / Node.js / Python ; à droite, le volet AI Prompt. L'éditeur est prérempli d'un scaffold pour le type de macro choisi à l'étape 3, donc vous ne modifiez généralement que l'essentiel.

Note : la localisation complète de cette longue section (grille de 6 cartes, tableau run_data, exemple de code, section AI Prompt) sera réalisée lors d'une prochaine passe. Messages clés : run_data.input_data arrive d'abord comme un tableau { item_name, item_value, item_type } qu'il faut retourner en objet clé/valeur ; run_data.conn_string/table_name/file_name sont pré-remplis ; les champs de retour data / json / download_links / message correspondent au type de sortie choisi dans l'assistant ; le volet AI Prompt à droite construit à partir d'un badge de scénario + votre textarea un prompt à copier dans ChatGPT/Claude/Gemini et dont vous collez le code retour dans l'éditeur central.

Basculez sur l'onglet Quick Test (icône fiole 🧪) en haut du volet gauche. Quick Test fait tourner le code à travers le serveur de macro préparé à l'étape 2.

1. Remplissez les paramètres d'entrée ligne par ligne.
2. Cliquez [Exécuter] → spinner « Running… ».
3. L'affichage du résultat dépend de la forme de retour :
   • data → tableau
   • json → visualiseur JSON
   • download_links → liste de boutons de téléchargement
   • message/error → bloc texte <pre>

Stdout et stderr streamant en temps réel dans le volet terminal du bas — parfait pour le debug.

Une fois que Quick Test passe bien, confiez le macro à une planification pour exécution sans surveillance. Dans la section Schedule de la vue détaillée, deux valeurs suffisent.

• Heure de début (offset) — format HH:MM (p. ex. 00:00 = minuit, 03:30 = 3 h 30). C'est l'ancre du planning récurrent.
• Intervalle N (minutes) — le macro tourne toutes les N minutes à partir de l'heure de début. Entrez 5 pour toutes les 5 min, 60 pour toutes les heures, 1440 pour une fois par jour.
• Interrupteur Active — pause ou reprise sans perdre la config.

Exemples : heure de début 00:00 + intervalle 5 → toutes les 5 minutes dès minuit (00:00, 00:05, 00:10…). Heure de début 09:00 + intervalle 1440 → une fois par jour à 9 h.

Une fois enregistré, le serveur de macro fait tourner ce macro à cette cadence tout seul. QuickStart ne fait que signaler — l'exécution réelle et le trafic vivent sur le serveur de macro. (Pas d'expressions cron — le planificateur n'utilise que heure de début + intervalle.)

Ouvrez Data > Base de données depuis le menu. La barre latérale gauche a un bouton bleu [+ Nouveau dataset] et des sections Récents / Publics / Mes / Équipe ; le corps est une vue en cartes Grille/Liste.

Les quatre icônes de chaque carte : ▶ (éditeur DB) · table (éditeur de cellules) · (réglages API) · copier/supprimer.

[+ Nouveau dataset] → modale d'assistant.

1. Étape 1 — trois options de connexion : Déployer une nouvelle BD (Railway) · Connecter une BD existante · Fichier local (JSON/CSV/Excel). Liste déroulante Type de BD (MySQL 3306 · MariaDB 3306 · PostgreSQL 5432 · MongoDB 27017) · hôte · port · BD · utilisateur · mot de passe → [Tester la connexion] vérifie que les identifiants atteignent la base.
2. Étape 2 — en cas de succès, choisissez une table ; ses champs se déploient.
3. Étape 3 — enregistrer le dataset : nom · description · table · PK · colonnes (* ou séparées par virgule) · WHERE · LIMIT · ORDER BY · shared. Le panneau de droite [Tester la requête] prévisualise le résultat ; puis [Enregistrer].

Cliquez l'icône ▶ (lecture) d'une carte de dataset pour ouvrir l'éditeur plein écran, qui comporte trois panneaux.

• Gauche — onglets (Tables/Views/Procedures/Functions), inspecteur de structure de table, icônes de commandes (Copier CREATE · Drop · Update · Insert · Delete · Join · Reverse · Refresh).
• Centre — éditeur SQL multi-onglets. ▶ Run ou F5/F9. Export en TSV/CSV/JSON/SQL, ou envoi direct à un macro via « Send to Macro ».
• Droite — grille de résultat avec édition cellule par cellule.

Cliquez le bouton Réglages API (icône prise) sur une carte, la modale des réglages API s'ouvre.

1. Bases : Namespace (obligatoire, queue d'URL) · Table · Table JOIN · Var de page (par défaut page) · Par page (50) · cache (0–1440 min).
2. [Auto-générer] → assemble la forme JSON (main_container → main_fields → item_container → item_fields → detail). Chaque champ est un couple « clé JSON → variable SQL ».
3. [Enregistrer] → [Déployer] active l'endpoint.

Les endpoints sont en ligne à GET https://happycat.apidealder.net/endpoint/{namespace}. La section ACL de la modale les verrouille.

• Clé API (bouton auto-générer · transport header/param · nom d'en-tête X-API-KEY)
• Liste blanche IP — wildcards / CIDR
• Restriction Referer — domaines autorisés
• Limite de débit — max req/min

Exemple : curl -H "X-API-KEY: ..." https://happycat.apidealder.net/endpoint/menu_list

Remote Management se divise en quatre zones. Sachez où regarder avant de cliquer.

• Liste de serveurs à gauche — tous les domaines que vous gérez, avec un petit point d'état. Vous pouvez replier ce panneau sur les seules icônes pour gagner de la place.
• Zone de fichiers centrale — l'explorateur de fichiers du serveur sélectionné. La barre d'outils en haut contient la barre de chemin, les boutons de tri et le bouton du terminal ; en dessous, le contenu des dossiers se déploie en colonnes au fur et à mesure que vous descendez.
• Barre d'actions en bas — Envoyer · Nouveau dossier · Nouveau fichier · Télécharger · Supprimer. Les boutons ne s'allument qu'après avoir choisi un fichier ou un dossier.
• Panneau terminal — console qui monte depuis le bas à la demande. Cliquez l'icône terminal de la barre d'outils pour l'afficher/masquer.

Cliquez un domaine dans la liste de gauche. Le point près du nom indique son état :

• Point vert — en ligne. La liste de fichiers s'ouvre immédiatement.
• Point gris — hors ligne. Le conteneur dort peut-être, ou le réseau est bloqué.
• Point blanc — vérification en cours, ou état inconnu.

Si la liste est vide, vous verrez un message « Déployez d'abord un serveur » avec des boutons raccourcis vers les écrans de déploiement Single File, projet et base de données.

La zone centrale est un navigateur en colonnes — chaque dossier cliqué s'ouvre en nouvelle colonne à droite. Jusqu'à quatre colonnes visibles à la fois ; les chemins plus profonds replient automatiquement la colonne la plus à gauche.

• Barre de chemin — l'icône maison revient à la racine (/), et chaque segment séparé par un slash au-dessus est cliquable pour sauter exactement là.
• Saisie de chemin — tapez un chemin complet comme /var/www/html/storage/logs et Entrée pour y aller directement sans cliquer.
• Boutons de tri — nom · taille · date de modification. Rappuyez sur le même bouton pour inverser l'ordre.
• Sélection — un clic sélectionne un élément, Shift+clic sélectionne une plage, Ctrl/⌘+clic ajoute ou retire un à un. Dès que plusieurs éléments sont sélectionnés, un badge « N sélectionnés » apparaît en haut à droite de la barre d'actions.

Cliquez une fois un fichier pour le sélectionner. Cliquez une seconde fois et il s'ouvre — la vue adaptée apparaît automatiquement à droite selon le type.

• Fichiers texte/code → un éditeur avec coloration syntaxique s'ouvre au centre. HTML, PHP, Vue, CSS/SCSS, JavaScript/TypeScript, JSON et d'autres sont détectés automatiquement.
• Images (PNG · JPG · GIF · SVG · WebP · BMP · ICO) → s'ouvrent dans une visionneuse pour vérification visuelle.
• Fichiers binaires / exécutables déclenchent un message « Impossible d'éditer un fichier binaire » et ne s'ouvrent pas.
• Le bouton [Enregistrer] en haut à droite de l'éditeur pousse immédiatement la modification au serveur — pas besoin de redéployer. Esc ou [Annuler] ferme sans sauvegarder.
• L'éditeur n'ouvre que les fichiers jusqu'à 10 Mo ; au-delà, un message « trop volumineux » s'affiche.

Combinez la barre d'actions du bas et le panneau terminal pour vraiment travailler.

• Envoyer une archive — glissez ou cliquez pour choisir un .zip · .tar · .tar.gz · .tgz. Un aperçu du contenu de l'archive apparaît ; après Start Upload, le fichier part par blocs de 1 Mo avec une barre de progression, et le dossier courant se rafraîchit automatiquement en fin d'envoi.
• Envoyer des fichiers — choisissez un ou plusieurs fichiers en une fois, ils sont envoyés tels quels dans le dossier courant (pas de décompression).
• Nouveau dossier / Nouveau fichier — demande un nom. Lettres, chiffres, point, tiret et underscore uniquement.
• Télécharger — les fichiers sont téléchargés tels quels ; choisissez un dossier et il est automatiquement zippé en un seul ZIP.
• Supprimer — confirme une fois ; si plusieurs éléments sont sélectionnés, tout passe en une opération.
• Déplacer / copier — glissez un fichier sur un dossier : un dialogue de confirmation s'ouvre. Ou Ctrl+X/Ctrl+C met la sélection de côté, puis Ctrl+V dans un autre dossier colle via le même dialogue de confirmation.
• Terminal — l'icône terminal dans la barre d'outils fait monter le panneau du bas et vous connecte à la shell du serveur sélectionné. Tapez une commande et Entrée — stdout apparaît en blanc, stderr en rouge. ↑/↓ rappelle les commandes précédentes, et le répertoire courant est suivi pour vous : après cd some/path, la commande suivante s'exécute depuis là.

Après connexion, ouvrez depuis la navigation supérieure ou le tableau de bord Services → Single File. L'écran se divise en une barre d'outils supérieure et le corps :

• Barre d'outils supérieure — à gauche : Historique · Guide · Saisie du titre · Enregistrer (💾). Au centre : liste déroulante de modèles. À droite : Partager · Exécuter ▶ · Déployer 📦.
• Éditeur au centre — quatre onglets en haut : prompt · html · scss · vuejs. Cliquez pour basculer.
• Panneau d'aperçu à droite — rend quand vous cliquez sur Exécuter.

Ouvrez la liste déroulante de modèles au centre de la barre d'outils et choisissez « Restaurant Booking System ». Le déroulement :

1. Dès que la valeur de la liste change, le modèle sélectionné est appliqué automatiquement.
2. Les quatre onglets (prompt · html · scss · vuejs) se remplissent automatiquement du code pré-construit et du prompt AI utilisé pour le régénérer.
3. L'onglet actif bascule par défaut sur prompt — ce texte est celui qu'utilisera l'IA si vous demandez une régénération.
4. Cliquez Exécuter ▶ dans la barre d'outils, et l'aperçu à droite rend un écran de réservation à 3 colonnes (calendrier / créneaux horaires / formulaire de réservation).

Remarque : ce modèle est un écran d'opérateur permettant au propriétaire de gérer dates, créneaux et disponibilité des tables — pas une simple page d'accueil menu pour visiteurs.

Ce modèle se personnalise sur deux niveaux : une modale de paramètres (sans code) et des modifications de code directes. Le point d'entrée est l'icône ⚙ Paramètres en haut à droite de la page rendue, à côté du bouton de thème (☀/🌙).

A. Modale de paramètres — données seulement, pas de code

1. Cliquez ⚙ → un overlay plein écran ouvre une modale centrée (4 onglets).
2. Time Ranges — ajustez les heures de début et de fin du matin / déjeuner / dîner avec des champs numériques. Une barre de visualisation en haut reflète les segments colorés en direct. Si début == fin, le segment est marqué « (inactif) ».
3. Time Slots — choisissez un pas (10 / 30 / 60 / 120 min), puis basculez chaque créneau de la grille actif/inactif. Les compteurs actif/inactif s'affichent en haut.
4. Tables — liste avec renommage inline + suppression, et un champ en bas pour ajouter des tables. Cette liste alimente le sélecteur « Table » du formulaire de réservation.
5. Holidays — jours de fermeture récurrents (Dim–Sam, 7 boutons bascules) + jours fériés spécifiques (champ date + texte de motif, liste avec ajout/suppression). Les motifs n'apparaissent que dans les paramètres, jamais sur l'écran public.

B. Modifications de code — nom du commerce, thème, etc.

• onglet html — remplacez la chaîne du titre d'en-tête "레스토랑 예약" par le nom de votre établissement. Utilisez Ctrl+F pour la trouver.
• onglet vuejs — mounted() contient une génération de données factices (D+1 ~10 %, D+2 ~5 %, D+3 ~2 % de réservations aléatoires + un tableau de noms coréens). En production, videz ce bloc ou remplacez-le par un appel d'API serveur. Les jours fériés sont récupérés depuis https://date.nager.at/api/v3/PublicHolidays/{year}/KR — remplacez KR par un autre code pays au besoin.
• onglet scss — le thème utilise des propriétés CSS personnalisées, pas des variables SCSS. Définies sous .reservation (clair) / .reservation.dark (sombre) : --primary (accent de marque), --bg (fond de page), --card-bg, --text / --text-sub, --border, --holiday (rouge jour férié), --closed-bg (ambre jour de fermeture), --occ-bg / --occ-border (créneau avec places restantes). Modifier uniquement ces variables décale l'apparence globale de façon cohérente.

Après édition : Enregistrer (💾) → Exécuter ▶ pour rafraîchir. Les onglets non sauvegardés affichent un petit point (●).

Maintenant, essayez vous-même une réservation comme si vous étiez un client. C'est exactement ce que feront votre équipe ou vos visiteurs après mise en ligne. Suivez cet ordre dans l'aperçu :

1. Choisissez une date dans le calendrier (gauche) — cliquez n'importe quelle date à partir d'aujourd'hui. Les jours rouges sont fériés, les ambrés sont des fermetures spécifiques que vous avez définies, les grisés sont des jours de fermeture réguliers — non cliquables. Les jours qui ont déjà des réservations affichent dans le coin un petit nombre comme « +2 », pour voir d'un coup d'œil l'état des réservations.
2. Choisissez une heure (centre) — après avoir choisi une date, les horaires disponibles apparaissent comme des boutons arrondis. Le nombre « 2/5 » signifie « 2 déjà réservé / 5 tables au total ». Teinte claire = beaucoup de places, sombre = presque complet, barré = complet et non cliquable.
3. Voir qui a déjà réservé — cliquer sur un bouton horaire ouvre dessous la liste des réservations existantes à cet horaire (nom du client, table, nombre de convives). Évite les doubles réservations.
4. Remplissez le formulaire (droite) — la date et l'heure choisies apparaissent en synthèse en haut. Remplissez du haut en bas :
   • Nom du client
   • Téléphone : tapez simplement les chiffres, formaté automatiquement en « 010-1234-5678 »
   • Table : les tables déjà prises à cet horaire sont automatiquement masquées pour éviter une double réservation
   • Nombre de convives : de 1 à 20
   • Note : demandes spéciales (anniversaire, accès fauteuil roulant, etc.)
5. Cliquez le bouton [Réserver] — si le nom est vide, un avertissement apparaît. Sinon une confirmation « Réservation terminée » s'affiche, et le « +N » du calendrier ainsi que le « N/M » du bouton horaire augmentent immédiatement de 1. Le formulaire se vide tout seul et est prêt pour la réservation suivante.
6. Essayez les thèmes clair et sombre — cliquez l'icône ☀/🌙 en haut à droite. Votre établissement peut être utilisé en plein jour comme le soir en pénombre — vérifiez la lisibilité dans les deux cas.

Pour vérifier le rendu téléphone et tablette, tirez simplement à la souris la fenêtre du navigateur pour la rétrécir. À mesure que l'écran devient étroit, les 3 colonnes se réarrangent en 2, puis finissent empilées sur 1. L'équipe utilise souvent des tablettes et les clients leur téléphone — assurez-vous que textes et boutons restent assez grands pour être touchés facilement sur écran étroit.

Le déploiement utilise l'hébergeur Railway. Au premier clic sur Deploy, une modale « Connecter le compte Railway » s'affiche. L'ordre :

1. Cliquez Log in with Railway → la page de connexion Railway s'ouvre dans un nouvel onglet.
2. Pas encore de compte Railway ? Créez-en un gratuitement (e-mail ou GitHub).
3. Sur l'écran « QuickStart demande l'autorisation de déployer », cliquez Authorize.
4. Vous êtes redirigé vers QuickStart, un toast « Connecté » apparaît.

À faire une seule fois — les déploiements suivants sautent cette étape.

Une fois le compte connecté, cliquez à nouveau Deploy. Une modale de progression s'ouvre et parcourt 8 étapes — chacune devient verte à la fin.

1. Pack — empaqueter votre code.
2. Upload — envoyer le paquet à Railway.
3. Install — installer les bibliothèques nécessaires.
4. Build — compiler SCSS et bundler Vue.
5. Migrate — placer les fichiers statiques au bon endroit pour le serveur web.
6. Start — démarrer le conteneur.
7. Health — vérifier que le site répond vraiment.
8. Complete — finaliser et attribuer l'URL.

En général 1 à 3 minutes au total. Dépliez Afficher les logs en bas de la modale pour suivre en direct.

À la fin du déploiement, un bouton Ouvrir le domaine apparaît en bas de la modale. Cliquez : le domaine gratuit attribué automatiquement (p. ex. happycat.apidealder.net) s'ouvre dans un nouvel onglet. Partagez cette URL avec qui vous voulez.

Plus tard, pour lier votre propre domaine (p. ex. myname.com), allez dans Paramètres → Gestion des domaines du tableau de bord, enregistrez le domaine personnalisé, et ajoutez chez votre fournisseur DNS les enregistrements indiqués.

Depuis la navigation supérieure ou le tableau de bord, cliquez sur Services → Base de données pour ouvrir la page de base de données. L'écran se divise en une barre latérale gauche et un corps central.

• Barre latérale gauche — en haut un bouton bleu [+ Nouveau dataset], suivi des sections « Récents », « Datasets publics », « Mes datasets », « Équipe ».
• Corps central — la barre d'outils supérieure propose une boîte de recherche (nom / table / URI), un commutateur grille⇄liste, et un sélecteur de lignes par page (20/50/100). Plus bas, vos datasets existants apparaissent sous forme de cartes.
• Quatre icônes sur chaque carte — ▶ (lecture) ouvre l'Éditeur de base de données · icône table ouvre l'Éditeur de cellule · bouton Réglages API (icône prise) ouvre les réglages d'API · plus copier/supprimer. Double-clic sur le nom de la carte pour renommer en ligne.

Cliquez [+ Nouveau dataset] dans la barre latérale gauche — un assistant modal en 3 étapes s'ouvre au centre. Le flux :

1. Étape 0 — Aperçu : cartes explicatives sur les datasets et leurs capacités. Cliquez Next pour continuer.
2. Étape 1 — Mode de connexion : choisissez l'une des trois grandes options.
   • Déployer une nouvelle BD — provisionne un nouveau conteneur BD sur Railway.
   • Connecter une BD existante (le plus fréquent) — se connecter à une BD existante.
   • Fichier local — uploader un JSON / CSV / Excel comme dataset.
3. Pour « Connecter une BD existante » :
   • Liste déroulante Type de BD — MySQL (port 3306 par défaut) · MariaDB (3306) · PostgreSQL (5432) · MongoDB (27017). La sélection remplit automatiquement le port par défaut.
   • Hôte · Port · Nom de base · Utilisateur · Mot de passe
4. Cliquez [Tester la connexion] en bas — en cas de succès, l'assistant avance automatiquement à l'étape 2 ; en cas d'échec, une erreur rouge apparaît dessous.

Une fois connecté, l'assistant enchaîne automatiquement deux étapes supplémentaires.

Étape 2 — Sélection de table

• Les tables de la BD apparaissent en lignes (nom · icône · nombre de lignes · commentaire).
• Cliquer sur une table déploie le panneau de droite et montre sa liste de champs.

Étape 3 — Enregistrer le dataset (c'est ici que les métadonnées « dataset » sont finalisées)

• Gauche — formulaire d'enregistrement :
  • Nom du dataset (obligatoire) — ex. « Liste menu »
  • Description du dataset
  • Liste déroulante de la table cible (obligatoire)
  • Champ clé primaire — sélectionne automatiquement id s'il existe.
  • Colonnes incluses — * (toutes) ou séparées par virgules comme id,name,price
  • Clause WHERE — p. ex. stock_flag = 1
  • LIMIT — p. ex. 0,100 (offset 0, 100 lignes)
  • ORDER BY — p. ex. created_at DESC
  • Case Shared — exposer en lecture seule aux autres utilisateurs.
• Droite — testeur de requête : cliquer [Tester la requête] exécute le SQL réel avec vos paramètres courants et affiche le nombre de lignes, de colonnes et un aperçu en direct. Ajustez les conditions à gauche jusqu'à voir ce que vous voulez.
• Cliquez [Enregistrer] → l'assistant se ferme → une nouvelle carte de dataset apparaît sur l'écran principal.

Le clic sur l'icône ▶ (lecture) d'une carte de dataset ouvre l'Éditeur de base de données en overlay plein écran. Il a trois panneaux.

• Gauche — explorateur d'objets : onglets en haut (Tables / Views / Procedures / Functions). Cliquez une table pour voir en dessous, dans l'inspecteur, colonnes · types · commentaires. La bande de commandes au-dessus de la liste couvre Copier le script CREATE, Drop, Update, Insert, Delete, Join, Reverse, Refresh.
• Centre — éditeur SQL : gère plusieurs requêtes sous forme d'onglets. Double-clic sur un onglet pour renommer. La barre d'outils contient un bouton ▶ Run plus les raccourcis F5 / F9. Les résultats s'exportent en TSV / CSV / JSON / SQL, ou passent directement à un Macro via « Send to Macro ».
• Droite — grille de résultats : lignes de la dernière requête, édition au niveau de la cellule.

Utilisez cette étape pour confirmer que les données que vous allez exposer ressemblent vraiment à ce que vous voulez. Sinon, corrigez ici d'abord.

Exposez maintenant ce dataset en REST API. Cliquez sur le bouton Réglages API (icône prise) sur la carte du dataset pour ouvrir la modale Réglages API.

1. Bases
   • Namespace (obligatoire) — devient la queue de l'URL. menu_list produit /endpoint/menu_list.
   • Table — table cible (auto-remplie depuis le dataset)
   • Table JOIN — seconde table optionnelle si vous voulez joindre
   • Var de page — nom du paramètre de pagination (par défaut page)
   • Par page — 50 par défaut
   • Temps de cache — 0 à 1440 minutes
2. Auto-générer la réponse : cliquer [Auto-générer] construit la forme JSON en main_container → main_fields → item_container → item_fields → (optionnel) detail. Chaque champ est un couple « clé JSON → variable SQL » (p. ex. name → $customer_name). Vous pouvez ajouter ou retirer des champs à la main.
3. Contrôle d'accès (ACL) — détaillé ci-dessous.
4. Cliquez [Enregistrer] pour sauvegarder la définition de l'API.
5. Cliquez [Déployer] pour lancer le pipeline de déploiement — une barre de progression apparaît, et l'endpoint passe live quand c'est fini.

Une fois déployé, l'endpoint est public (avec un domaine personnalisé) à :

• GET https://happycat.apidealder.net/endpoint/menu_list
• GET https://happycat.apidealder.net/endpoint/menu_list?page=2
• GET https://happycat.apidealder.net/endpoint/menu_list/csv — téléchargement CSV

Authentification par API Key (section ACL dans la modale API) :

• API Key — cliquez [Auto-générer] pour une clé aléatoire au format UUID.
• Transport — header ou param.
• Nom d'en-tête, p. ex. X-API-KEY / Nom de paramètre, p. ex. api_key.

Exemples d'appel

Par en-tête :

curl -H "X-API-KEY: your-secret-key" https://happycat.apidealder.net/endpoint/menu_list

Par paramètre :

curl "https://happycat.apidealder.net/endpoint/menu_list?api_key=your-secret-key"

Fetch navigateur :

const res = await fetch('https://happycat.apidealder.net/endpoint/menu_list', { headers: { 'X-API-KEY': 'your-secret-key' } });
const data = await res.json();

Garde-fous supplémentaires (tous dans la section ACL) :

• Liste blanche IP — wildcards (192.168.1.*) et CIDR (10.0.0.0/24).
• Restriction Referer — liste des domaines autorisés.
• Limite de débit — nombre max de requêtes par minute.

Depuis la navigation supérieure ou le tableau de bord, cliquez sur Services → Collecte de données pour ouvrir l'écran de liste des règles du parseur. La disposition ressemble à la page Base de données.

• Barre latérale gauche — en haut un bouton bleu [+ Nouvelle règle de parseur], puis « Récents », « Règles publiques » et « Mes règles » (avec filtre par utilisateur).
• Corps central — barre d'outils avec recherche, bascule grille/liste, pagination. En dessous, vos règles existantes s'affichent en cartes (ou lignes de tableau).
• Icônes sur chaque carte — ⚗️ (tube) Test d'items · ⏱ (horloge) Planification (affiche un ruban « Max » si hors de votre plan) · modifier · dupliquer · supprimer. Les cartes indiquent nom de règle, page de test, description et date de création.

Cliquez [+ Nouvelle règle de parseur] dans la barre latérale gauche → un assistant en 3 étapes s'ouvre.

1. Étape 1 — Vue d'ensemble : quatre cartes d'info (Extraire / Crawler / Mapping de champs / Réutilisation) et un diagramme de pipeline (Règle parseur → Base / Macro / Planificateur / API). Pas de saisie, juste contexte.
2. Étape 2 — Connexion base de données : choisir un dataset dans une liste de cartes comme destination des données collectées. Chaque carte indique nom de dataset, type BD, table et domaine. Après sélection, pressez [Suivant] — un flow auto en 3 phases (« Connexion de l'agent → Déploiement moteur parseur → Déploiement terminé ») installe le moteur sur l'agent docker choisi.
3. Étape 3 — Enregistrement de la règle :
   • Nom de la règle (obligatoire) — p. ex. « Naver News section IT »
   • Description — une ligne sur ce qu'elle collecte
   • Cliquez [Créer la règle] et l'assistant se ferme, vous atterrissez directement sur l'écran de configuration du parseur.

L'éditeur de règle s'ouvre avec un champ URL cible en haut. Saisissez la page à scraper (p. ex. https://news.example.com/it), puis configurez l'extraction. Le parseur combine trois approches.

• Loop Splitter (3 entrées — principal + 2 secondaires) — un motif textuel qui découpe le HTML en unités répétées. Exemple : utiliser un bout de <li class="article"> comme splitter pour que chaque article devienne un item.
• Sélecteurs XPath (jusqu'à 3 niveaux) — récupère titre / URL / image à l'intérieur de chaque unité répétée via XPath. Le sélecteur doit pointer vers un ensemble de nœuds (tableau) ; si la valeur est en //h3/a/text(), entrez juste //h3/a.
• Sélecteurs JSON (3 niveaux) — si la page renvoie du JSON, utilisez la syntaxe point/crochet pour pointer sur le chemin tableau. Pour des données de forme data.items[0].title, entrez data.items afin que le tableau d'items soit produit.
• Post-traitement par fonction — la colonne « function » s'applique à chaque valeur extraite :
  • trim(@p) — supprime les blancs (@p est la valeur courante)
  • replace(old,new) / regex(pattern,replacement)
  • Appels PHP directs comme strtoupper(@p)
  • Helpers intégrés : get_data() · slice() · remove() · map()

Le plus rapide n'est pas de taper des sélecteurs à la main — c'est de passer une tranche de la source (via le Loop Splitter) dans l'AI Prompt et laisser la réponse de l'IA enregistrer automatiquement la règle. C'est exactement ce que couvre l'étape 4 ci-dessous.

Au lieu de taper à la main des dizaines de sélecteurs, vous pouvez passer l'échantillon à une IA et appliquer la règle complète qu'elle retourne. C'est la voie recommandée pour les débutants.

Prérequis — avoir saisi une URL cible à l'étape 3 et lancé au moins une fois le test d'extraction depuis l'onglet « Test » de l'éditeur, pour qu'un corps de réponse existe. Ce corps rejoint automatiquement le prompt.

A. Construire & copier le prompt

1. Dans le panneau de résultats du test, cliquez en haut sur le bouton 🪄 « AI Prompt » (icône baguette) en surbrillance.
2. Le type de document (HTML / JSON / XML) est auto-détecté, le corps est extrait puis assemblé en prompt.
3. Le panneau d'éditeur juste sous le bouton se remplit d'un prompt au format markdown. Il contient :
   • Un paragraphe d'introduction à la tâche
   • L'échantillon HTML/JSON
   • Les définitions cibles — délimiteur de répétition, champ detail-URL, clé unique, et pour chaque colonne : libellé, nom de variable, type, règles de découpe, fonction de post-traitement
   • Un JSON d'exemple et l'instruction explicite « N'émettre aucun texte autre que du JSON »
4. Le prompt est multilingue (8 langues : coréen · anglais · japonais · chinois · russe · allemand · français · espagnol) — un document coréen produit des libellés coréens, un document chinois des libellés chinois, etc.
5. Cliquez dans le panneau → Ctrl+A → Ctrl+C pour tout copier.

B. Coller dans l'IA choisie et exécuter

1. Coller dans ChatGPT / Claude / Gemini et envoyer.
2. L'IA répond par un JSON de règle.
3. Copier la réponse (ou seulement la partie JSON).

C. Coller la réponse pour remplir automatiquement les champs de la règle

1. Revenez dans le même panneau, cliquez le bouton 📥 « Import Pattern » (icône d'import) — une zone de texte avec indice de format s'ouvre.
2. Collez votre JSON, puis cliquez [Appliquer le pattern].
3. Délimiteur de répétition, sélecteurs, clé unique et champ detail-URL se placent automatiquement en haut de la règle, et chaque colonne (libellé, variable, type, règles de découpe, fonction de post-traitement) est remplie d'un coup dans la liste des champs. Les noms de variable dupliqués sont renommés auto pour éviter les collisions.
4. L'éditeur passe automatiquement sur l'onglet « fields » pour vérification immédiate, et un toast résumé « Pattern applied: N fields » apparaît en bas.

Une fois les sélecteurs grossièrement en place, vérifiez qu'ils extraient bien ce que vous voulez. Deux points d'entrée :

• L'icône ⚗️ sur la carte d'une règle
• Ou l'onglet « Test » en haut de l'éditeur de règle

La modale Test d'items s'ouvre avec :

1. Barre de statut en haut — résumé « N items / M colonnes ». Si N vaut 0, le Loop Splitter est faux — corrigez-le en premier.
2. Boutons d'export — CSV · XLSX · JSON · HTML, pratiques pour partager un échantillon avec l'équipe.
3. Grille de résultats — Row# + en-têtes de colonnes auto-dérivés du premier item, une ligne par item extrait.
4. Hover de cellule — un bouton « Copy » apparaît au survol pour copier la valeur dans le presse-papiers.

Si les résultats sont faux, fermez la modale, ajustez sélecteurs/fonctions et retestez — cette boucle représente ~70 % du travail de parseur.

Une fois le test propre, confirmez les réglages de sauvegarde dans la section « Save » de l'éditeur.

• Menu Save type — sur « Database » (déjà auto-défini si vous avez choisi un dataset dans l'assistant).
• Table cible / nom de collection — où atterrissent les lignes. Si elle n'existe pas, l'agent la crée au premier lancement, avec les colonnes détectées dans votre test.
• Mode DB — Dataset (lié) / Custom. Custom permet de saisir directement hôte · utilisateur · mot de passe · base de données (utile pour écrire dans une BD différente de celle de l'assistant).

Ce qui se passe à l'exécution

1. Vous exécutez la règle (bouton « Persist » du test ou la planification de l'étape suivante), et l'agent docker frappe l'URL cible.
2. Les items sont extraits : Loop Splitter → sélecteurs XPath/JSON → traitement fonctions.
3. Les items extraits sont insérés dans la table cible. Les doublons (par hash d'URL ou par la clé choisie) sont sautés ou mis à jour automatiquement.
4. Comme cette table vit dans la même BD que la carte de dataset de l'étape 5, l'endpoint API /endpoint/... construit avant sert désormais les données les plus fraîches.

La dernière étape la fait tourner toute seule. Cliquez sur l'icône ⏱ (horloge) d'une carte de règle pour ouvrir la modale de planification. Cette fonctionnalité est exclusive MAX — sur les autres plans, l'icône affiche un ruban « Max ».

1. Champs du planning :
   • Heure de début — heure (0–23) + minute (0–59). Ex. 03h30.
   • Intervalle (minutes) — 60 = toutes les heures, 1440 = une fois par jour.
   • Active — interrupteur. Off garde la config mais met les runs en pause.
   • Run mode — Single URL (une seule URL cible) ou Batch (boucle sur une liste d'URL, une par ligne).
2. Cliquez [Enregistrer] — le planning est sauvegardé dans QuickStart et auto-synchronisé avec l'agent docker sélectionné, qui exécute réellement.
3. À partir de là, l'agent déclenche la règle à votre intervalle et alimente le dataset. QuickStart ne fait que signaler — il n'est pas sur le chemin du trafic, donc aucun surcoût de bande passante.

Chaînage avec un macro (optionnel) — dans le diagramme de flux de l'éditeur, utilisez la liste déroulante « Select macro » pour choisir un macro. Juste après la fin d'un scrape, il s'exécute. Exemple : comparer les prix produits fraîchement scrapés à ceux d'hier ; s'ils ont baissé de N%, envoyer une alerte Slack.

Pousser directement de la base de production (B) vers la base analytique (C) paraît le plus simple, mais en pratique les noms de colonnes diffèrent, des données personnelles traînent et les fuseaux horaires ne correspondent pas — il faut un sas pour nettoyer au passage. Le dataset QuickStart (A) joue exactement ce rôle.

• B (source externe) — la boutique ou l'ERP en exploitation. Y toucher, c'est arrêter le service, donc lecture seule.
• A (mon dataset · Docker) — votre atelier. Renommer des colonnes, réécrire les URL, écarter les champs inutiles, ajouter des agrégats — tout se fait ici.
• C (cible externe) — la base BI, celle d'un partenaire, toute destination. Seule la version propre sortie d'A y entre.

Atouts de ce schéma :

1. B et C peuvent tourner sur des moteurs différents (MySQL ↔ PostgreSQL …) — A fait le pont.
2. Les données restent dans A, si C est effacé on reprousse. Rollback facile.
3. Dans A on itère autant qu'il faut et on ouvre la vanne vers C quand tout est prêt.

On commence par créer le dataset (A) qui accueillera les données de B.

1. Menu haut → Données → Base de données. La liste s'ouvre.
2. En haut à droite [+ Nouveau dataset]. Saisir :
   • Nom — ex. replication_staging
   • Type de BDD — MySQL ou PostgreSQL. Même moteur que B = moins de conversions.
   • Hôte — par défaut la BDD incluse dans l'agent Docker (pré-remplie).
   • Nom de la BDD — ex. my_staging
3. [Enregistrer] — une ligne apparaît avec les icônes 🔌 test · édition · migration · export.
4. Cliquer d'abord 🔌 et obtenir « Connexion réussie » avant de continuer.

Le dataset A est le tampon intermédiaire où transitent brièvement les données venues de B et celles qui iront vers C.

Dans la liste, sur la ligne A, cliquer l'icône Migration. Une grande modale en trois colonnes s'ouvre.

• Gauche · Deck A — votre dataset (replication_staging) est déjà branché, ses tables et champs sont visibles immédiatement.
• Centre · barre d'outils — indicateur de direction (A → B / B → A), bouton [Inverser], et la liste d'actions (⚡ hard_sync, 🔄 soft_sync, ➕ append …).
• Droite · Deck B — le formulaire de connexion distante.

Le sens par défaut est A → B (pousser vers l'extérieur), mais on veut tirer depuis B : cliquer [Inverser] au centre pour passer à B → A. Le badge de Deck B devient « source », celui de Deck A « target ».

Remplir alors dans Deck B la connexion de la base de prod externe (B) :

1. Hôte — ex. origin.acme.com ou 10.0.1.23
2. Type de BDD — MYSQL · POSTGRESQL · MONGODB · ELASTICSEARCH
3. Nom de la BDD — ex. sales_db
4. Compte / mot de passe — fortement recommandé : compte en lecture seule. Avec uniquement SELECT, impossible d'abîmer B.
5. [Test de connexion] → « Connexion réussie » et la liste des tables distantes se charge toute seule.

Après une connexion réussie, Deck B affiche la liste des tables et un bouton [Suivant] apparaît en haut à droite. Il fait passer Deck B de « connexion » à « sélection des tables ».

1. Sélection des tables — cocher celles à importer. [Toutes les tables] coche tout. Démarrer petit (orders · customers · products) est plus sûr.
2. Filtre (optionnel) — le champ WHERE en bas de Deck B accepte created_at > '2026-01-01'. LIMIT 0, 1000 ne prend que 1000 lignes d'échantillon. Toujours limiter au premier essai.
3. Inspecter les champs (optionnel) — l'icône à côté d'une table ouvre la liste des colonnes ; décocher celles qu'on ne veut pas copier (password_hash, national_id …).
4. ⚡ hard_sync — dans la barre centrale, cliquer [hard_sync] (icône éclair). La fenêtre « Exécuter hard_sync sur {count} tables ? » demande confirmation. Côté A, chaque table est DROP → CREATE → INSERT. La barre de progression montre table courante / total et l'avancement par ligne.
5. À la fin, le log en bas affiche « Success » et la liste des tables de Deck A se rafraîchit avec les nouvelles tables.

Autres actions que hard_sync :

• 🔄 soft_sync — UPDATE/INSERT/DELETE par clé primaire seulement ; les lignes déjà dans A absentes de la source ne sont pas supprimées. Pour la sync régulière.
• ➕ append — insère uniquement les id absents d'A. Idéal pour l'incrémental.
• 🔀 merge — insère uniquement les lignes dont l'id ne collisionne pas avec A.

Les données brutes sont dans A, mais les envoyer telles quelles à C casse en général quelque chose. Deux façons de nettoyer.

① Substitution depuis la modale de migration — en bas de la barre centrale, le bloc « Configuration de la substitution » remplace en masse. Exemple : B stocke https://cdn-old.acme.com/, C attend https://cdn.acme.com/ :

1. Choisir [Texte] (ou [Regex]).
2. Zone de gauche : https://cdn-old.acme.com/
3. Zone de droite : https://cdn.acme.com/
4. Au prochain hard_sync / soft_sync, la valeur est remplacée à la volée et écrite dans A (ou dans C à l'étape 6). La source n'est pas modifiée.

② Via l'éditeur SQL — retour à la liste des datasets, icône sur la ligne A, lancer du SQL.

• ALTER TABLE orders DROP COLUMN password_hash; — retirer des colonnes sensibles
• UPDATE orders SET created_kst = CONVERT_TZ(created_at, 'UTC', 'Asia/Seoul'); — conversion de fuseau
• CREATE TABLE orders_summary AS SELECT product_id, COUNT(*) cnt, SUM(amount) total FROM orders GROUP BY product_id; — table agrégée

Avant l'étape 6, valider dans l'éditeur : SELECT * FROM orders_summary LIMIT 20;.

On pousse maintenant les données propres d'A vers la cible externe (C). Retour à la liste des datasets, cliquer à nouveau sur la ligne A.

1. Vérifier la direction — au centre on doit lire A → B, où B dans l'UI désigne désormais notre C. S'il reste B → A depuis l'étape 3, cliquer [Inverser]. Deck A devient source, Deck B cible.
2. Connexion cible dans Deck B (= C) — hôte warehouse.acme.com, type POSTGRESQL, base reporting, compte avec droits INSERT/UPDATE. [Test de connexion] → réussite.
3. Tables à envoyer dans Deck A — cocher orders_summary · products · customers_clean ou celles déjà préparées.
4. Choisir l'action :
   • C est créé pour la première fois : ⚡ hard_sync, la structure est recopiée, les tables absentes sont créées.
   • C contient déjà des données et c'est une sync régulière : 🔄 soft_sync, UPDATE/INSERT/DELETE sur C depuis A.
   • C accumule seulement : ➕ append, seuls les nouveaux id d'A sont ajoutés à C.
5. Lancer — confirmer et suivre la barre. Si le réseau tousse, les lignes sont découpées ; relancer reprend au point d'arrêt.

Une fois le pipeline passé à la main, emballez-le dans une macro pour le planifier. Service → Macro, nouvelle macro, appelez la migration depuis le code.

• Le corps ressemble à fetch('/dataset/api/mig_run', { method: 'POST', body: JSON.stringify({ dataset_id: 123, action: 'soft_sync', deck_b: {host, db_name, user, password}, sel_tables: ['orders'] }) }). Le plus sûr : exécuter une fois le bouton à la main et copier la requête depuis l'onglet Network.
• Dans l'onglet Planification de la macro, posez un cron. Ex. tous les jours à 3 h : 0 3 * * *.
• Gardez B → A et A → C en deux macros distinctes, pour qu'un échec d'un côté ne gèle pas l'autre. Chaînez l'ordre B → A puis A → C en regardant le success du résultat de la première.

Check-list de vérification :

1. SELECT COUNT(*) FROM orders sur C et comparer avec A et B.
2. Un id récent au hasard : comparer les colonnes entre B · A · C.
3. Insérer exprès une ligne dans B et vérifier qu'elle arrive en 5–10 min dans A puis dans C. Si non, consulter le log d'exécution de la macro et celui de la migration.

Dans ces cas, un coller écrase largement un SQL à la main :

• Un marketeur envoie un Excel avec 500 codes promo à pousser en BDD.
• Un designer fournit une Google Sheet nom · prix · catégorie à charger d'un coup.
• Un partenaire livre un CSV liste de membres à importer tel quel.
• On veut préparer pour l'assistant IA une table de 100 exemples déjà faits.

L'Éditeur de cellules se comporte comme Excel : une grille lignes × colonnes. Un Ctrl+C côté Excel et un Ctrl+V dans n'importe quelle cellule — tabulations ou virgules détectées automatiquement et les lignes se placent. Pas de dialogue de mapping : les colonnes se remplissent de gauche à droite depuis la cellule de départ.

Menu haut → Données → Base de données. La liste de vos datasets s'affiche en cartes ou en lignes.

1. Trouver la ligne d'un dataset dont vous êtes propriétaire (user_id = vous). Les datasets partagés sont en lecture seule.
2. Cliquer l'icône Éditeur de cellules dans les actions de la ligne. Un modal plein écran s'ouvre.
3. Disposition : à gauche panneau d'options (sélection de table · pas de page · tri · recherche · remplacement) ; au centre la grille ; à droite la barre d'outils (enregistrer · +/– ligne · Undo/Redo · copie · export CSV/SQL · ✨ assistant IA).
4. Choisir la table cible dans le déroulant de gauche. Ses lignes existantes se chargent. Table vide → grille vide.

Avant de coller, s'assurer que l'ordre des colonnes Excel = celui de la table. Un décalage place les valeurs dans les mauvaises colonnes.

• En-têtes — la première ligne de la grille affiche noms et types. Les colonnes Excel doivent suivre cet ordre, de gauche à droite.
• Clé primaire (PK) — les colonnes avec 🔑 sont la PK. Avec id en auto_increment, ne pas inclure id dans la sélection Excel ; la BDD l'affecte à l'INSERT.
• Colonnes NOT NULL — en-têtes en rouge, pas de vide possible ; remplir dans chaque ligne.
• Trop/pas assez de colonnes — le surplus à droite est ignoré ; ce qui manque à droite reste vide.

Si le schéma ne colle pas : régénérer via Créer une grille (X × Y) dans le panneau de gauche, ou réordonner Excel avant de copier.

Cœur du flux. Dans Excel/Sheets, sélectionner la plage sans la colonne id et Ctrl+C. Retour dans l'éditeur :

1. Cliquer la cellule de départ. Généralement la colonne la plus à gauche, une ligne sous la dernière existante — les nouvelles lignes s'ajoutent à la fin.
2. Ctrl+V. L'éditeur détecte tabulation (par défaut Excel) ou virgule (CSV) et répartit lignes/colonnes automatiquement.
3. La grille s'étend, les nouvelles lignes apparaissent avec un fond légèrement teinté — "nouvelle, non enregistrée".
4. Coller d'autres plages en choisissant une nouvelle cellule de départ.

Séparateur manuel — déroulant Séparateur à gauche : tab · virgule · virgule sûre (respect des guillemets). CSV avec virgules dans des guillemets → virgule sûre, les portions entre guillemets restent dans une seule cellule.

Avant d'enregistrer, passer les yeux sur la grille. Trois états sont marqués par couleur.

• Ligne teintée — "nouvelle" ligne fraîchement collée, deviendra un INSERT.
• Point jaune au coin d'une cellule — cellule modifiée d'une ligne existante, UPDATE.
• Ligne grisée — en file d'attente de suppression. La barre d'état affiche « 🗑 X lignes seront supprimées » et un bouton [Restaurer].

Gestes courants :

• Double-clic sur une cellule pour y taper directement.
• Barre de droite / — ligne vide au curseur / suppression de la ligne courante.
• Ctrl+Z · Ctrl+Y — annuler/refaire (jusqu'à 50 instantanés).
• Rechercher/Remplacer — panneau gauche ; texte ou regex, s'applique à toute la grille.

La barre d'état affiche ✏ X lignes, Y cellules modifiées. Si le nombre surprend, corriger avant d'enregistrer.

Quand tout semble bon, enregistrer via Enregistrer à droite ou Ctrl+S. L'éditeur assemble et exécute :

• Nouvelles lignes → INSERT INTO table (col1, col2, ...) VALUES (...). Les PK auto_increment sont affectées par la BDD.
• Lignes avec cellules modifiées → UPDATE table SET col=val WHERE id=..., seulement les colonnes changées.
• Lignes en file de suppression → DELETE FROM table WHERE id=....

Succès : toast « X lignes enregistrées ». Le teinté des nouvelles lignes disparaît, les id vides reçoivent le numéro de la BDD. Ces lignes sont désormais des données normales.

Échec — le panneau memo affiche l'erreur, souvent NOT NULL manqué, type incorrect ou doublon unique. Corriger la ligne et enregistrer à nouveau.

as if to be est une instruction par apprentissage de motif : « Si le résultat déjà abouti (Souhaitée) ressemble à ceci, alors transforme le brut (Actuelle) de la même façon ». Au lieu de formuler la règle en mots, on montre à l'IA quelques sorties de la règle, elle généralise au reste.

L'Éditeur de cellules propose deux marqueurs (couleur 1 · couleur 2).

• Marqueur 1 (Souhaitée · par défaut turquoise) — cellules exemples corrects du rendu.
• Marqueur 2 (Actuelle · par défaut orange) — cellules brutes que l'IA doit compléter.

Pourquoi c'est puissant :

1. Pas besoin de formuler la règle en langage naturel — les exemples parlent pour elle.
2. Fonctionne même pour les règles trop subtiles pour les mots (ton, nuance, registre).
3. Un seul prompt couvre des centaines de cellules. Le « coller chaque ligne vers l'IA » disparaît.
4. Ajouter/retoucher des exemples améliore la qualité instantanément. Boucle de tuning en secondes.

Dataset ouvert dans l'éditeur, préparez cette structure :

1. Colonne source — ce que l'IA lit. Ex. fr_text, product_desc, address_raw.
2. Colonne cible — ce que l'IA remplit. Ex. en_text, summary, city. Manquante ? Ajoutez-la en SQL : ALTER TABLE ... ADD COLUMN en_text TEXT;.
3. 2–5 lignes de graine — colonne cible remplie à la main. Trois bons exemples déterminent la qualité de 500 lignes.

Choisir de bons exemples :

• Variété — court, long, cas spécial. Des exemples trop semblables laissent l'IA en difficulté sur les cas limites.
• Niveaux — facile, moyen, épineux.
• Style explicite — sauts de ligne, majuscules, registre formel/informel doivent apparaître dans les exemples.

Dans la palette de marqueurs du panneau droit, cliquer la première pastille (turquoise · Souhaitée) pour l'activer (liseré renforcé).

1. Cliquer chaque cellule d'exemple remplie à la main — elle devient turquoise, donc marquée comme « Souhaitée ».
2. Les marqueurs basculent : recliquer dé-marque.
3. Sélectionner une plage par glisser puis cliquer la pastille pour marquer en bloc.

Renommer l'étiquette — crayon à côté de l'étiquette (« Souhaitée » par défaut). Pour une traduction « Traduction anglaise », pour un résumé « Résumé une ligne », pour une classification « Catégorie ». L'étiquette entre dans le prompt à l'étape 5 et précise la tâche pour l'IA.

Activer la deuxième pastille (orange · Actuelle).

1. Sélectionner par glisser les cellules vides ou brutes de la colonne cible — ex. en_text de la ligne 4 à la fin.
2. Un clic sur la pastille orange ; toutes passent en orange, ce sont les cibles pour l'IA.
3. La colonne source (fr_text) ne se marque pas ; l'IA lit automatiquement la source de chaque ligne cible.
4. Renommer aussi cette étiquette : « Vers l'anglais », « Plus court », « Assigner une catégorie » — une instruction d'un mot.

Au final la grille montre cellules turquoises (exemples justes) + cellules oranges (vides à remplir) côte à côte — c'est la forme canonique de « as if to be ».

Clic sur ✨ Assistant IA dans la barre de droite. L'éditeur lit les marqueurs, assemble un prompt structuré et le met automatiquement dans le presse-papiers. Toast « Prompt IA copié ».

Structure typique (textes variables selon étiquettes et exemples) :

1. Message système — "You are a data transformation assistant"
2. Énoncé de tâche — depuis les étiquettes. Ex. "Transform each 'Current Value' cell according to the pattern shown in 'Desired Value' examples."
3. Liste d'exemples — (ligne, colonne, valeur) de chaque cellule turquoise.
4. Liste de cibles — (ligne, colonne, valeur brute) de chaque cellule orange.
5. Contrat de sortie — seul un tableau JSON [{"pos":"ligne,colonne","return_txt":"valeur"}, ...] est accepté.

Arrêt — zéro marqueur turquoise et zéro orange déclenche une alerte. Retour aux étapes 3 et 4.

Coller le prompt dans Claude · ChatGPT · Gemini et envoyer. L'IA répond par un tableau JSON.

1. Sélectionner uniquement la partie JSON et Ctrl+C. Texte autour sans importance — ne prendre que le tableau.
2. Dans l'éditeur, Ctrl+V dans la zone Memo en bas à droite. Memo est la zone d'atterrissage pour la sortie IA.
3. Vérifier d'un œil : [{"pos":"3,5","return_txt":"Translated"},{"pos":"4,5","return_txt":"Another"}, ...].

Nettoyer le bavardage — l'IA précède souvent le JSON par « Here is the JSON you asked for: ». Ne prendre que le tableau (de [ à ]). Le bouton « Appliquer » de l'étape 7 parse du JSON strict.

JSON dans Memo — bouton 📥 Appliquer le résultat IA à droite. L'éditeur parse et écrit return_txt à pos. Toast « X cellule(s) appliquée(s) ».

• Les cellules écrites portent le point jaune modifié — présentes dans la grille, pas encore en BDD.
• Une cellule vous déçoit ? Ctrl+Z annule mais perd tout le lot IA. Souvent plus rapide : corriger à la main les mauvaises cellules.
• OK → Ctrl+S. Même chemin UPDATE que section 1 étape 6.

Boucle et stratégie de lots :

1. Avant d'appliquer tout le lot, regardez 10 échantillons. Qualité qui dérive : retouchez exemples/étiquettes en 3–4 et régénérez le prompt.
2. Qualité ok : page suivante, nouveau marquage, étapes 5–7 de nouveau.
3. À la fin, maintenez une colonne méta (batch_note) listant les exemples utilisés par lot — relancer une section devient trivial si le style change.

Un cas concret rend tout plus parlant. Le café "Sodam" veut une carte numérique sur tablette à l'entrée. Construire de zéro est lent ; prendre la solution menupan du marché et la rhabiller aux couleurs du café est radicalement plus rapide.

Ce qu'on boucle en 30–45 min :

• Logo — remplacer le logo menupan par celui du café "Sodam".
• Articles du menu — supprimer la démo (Americano 4500 KRW, etc.) et ajouter la vraie carte.
• Couleurs et police — passer du bleu par défaut à un beige chaud + brun foncé, et la police corps à une police lisible en coréen.
• Mise en ligne — publier sur un domaine à vous, par ex. menu.sodam.kr.

Pourquoi forker ?

1. Mise en page, schéma de BD et back-office sont déjà faits — 90 % de temps de construction économisé.
2. Le fork tourne sous votre compte, votre domaine, votre BD ; l'original reste intact, seule votre copie est éditable.
3. Si menupan se met à jour plus tard, votre fork n'est pas affecté — vos personnalisations restent.

Menu haut → Communauté → Marché de solutions (ou /solution). Galerie de cartes.

1. Filtres en haut (Tout / Project / Macro / Community / Direct) — choisir Project — ou taper menupan / carte numérique dans la recherche.
2. Clic sur la carte : page de détails avec aperçus, fonctionnalités et ressources requises (domaine / BD).
3. Sur la page : Forker comme nouveau projet. Le modal de fork s'ouvre.
4. Saisir :
   • Domaine — parmi vos domaines actifs, ex. menu.sodam.kr. Pas de domaine ? Ouvrir un autre onglet sur Paramètres → Domaines et obtenir un sous-domaine gratuit (~.apidealder.net) avant de revenir.
   • Dataset — la BD pour les données du menu. Nouveau ou existant.
   • Nom & description — ex. nom sodam_menu, description « tableau de menu en magasin Café Sodam ».
   • Bascule "Auto-déploiement" — l'activer pour que la première mise en ligne se lance dès le fork terminé. Recommandé la première fois.
5. Cliquer [Lancer le fork]. 30 s à 2 min plus tard, toast de fin. Une nouvelle ligne apparaît en haut de Mes projets dans la barre latérale, et l'espace de travail s'ouvre seul.

Deux moitiés : (a) uploader le nouveau logo via Gestion distante ; (b) changer l'URL du logo dans l'éditeur de programmes.

(a) Upload du logo via Gestion distante

1. Menu haut → Service → Gestion distante. Dans la liste de serveurs à gauche, sélectionner le domaine de votre projet forké (menu.sodam.kr). Le voyant doit être vert.
2. Au centre, taper /public/assets dans la barre de chemin et Entrée.
3. En bas, [Uploader un fichier] et choisir le logo (sodam_logo.png). Pas besoin d'archive pour un seul fichier.
4. Vérifier dans le navigateur : https://menu.sodam.kr/assets/sodam_logo.png doit renvoyer 200 OK et afficher l'image.

(b) Remplacer l'URL dans l'éditeur

1. Retour dans l'espace de travail → projet → Programmes. Liste des programmes (souvent main, menu_list).
2. Double-clic sur celui qui affiche le logo (souvent main) → l'éditeur s'ouvre.
3. Rechercher/Remplacer (Ctrl+H) : chercher l'ancien chemin, généralement /assets/menupan_logo.png.
4. Rechercher menupan_logo.png, remplacer par sodam_logo.png, Tout remplacer. HTML et CSS d'un coup.
5. Ctrl+S. Aperçu à droite : votre logo doit apparaître.

menupan livre une page admin pour que le personnel ajoute / édite / supprime les plats. Deux voies, privilégiez fortement l'admin.

(Recommandé) page admin

1. Aller à https://menu.sodam.kr/admin (ou le chemin défini par menupan) et se connecter. Les identifiants par défaut sont dans le README de la page de détails.
2. Menu de gauche : Gestion du menu. Catégories (Café · Dessert · Sans café) et articles (Americano · Latte · …) en tableaux/cartes.
3. Supprimer toutes les entrées de démo, puis ajouter votre carte ligne par ligne :
   • Nom (Americano) · prix (4500) · description (...) · catégorie (Café) · photo (URL d'une image uploadée via Gestion distante).
4. Le quotidien — édition, ré-ordonnancement, bascule afficher/masquer — tout passe par là. Cette page est aussi pour le personnel du café.

(Alternative) Éditer directement la BD

• Pour les opérations en masse non couvertes par l'admin (ex. +500 sur tous les cafés d'un coup) : Données → Base de données → le dataset créé au fork → Éditeur de cellules.
• Sélectionner menu_item et éditer, ou en SQL : UPDATE menu_item SET price = price + 500 WHERE category='Café';. (Voir Best Practices → Éditeur de cellules · Coller dans la BD.)
• Attention : modifier des colonnes inconnues à l'admin ou casser des PK/FK peut rendre l'admin inutilisable. C'est pourquoi le quotidien reste dans l'admin.

Avant de toucher au code, trouvez la couleur qui plaît dans le navigateur. Les modifications sont temporaires — un rafraîchissement les efface — donc on expérimente sans crainte.

1. Ouvrir le menu publié (https://menu.sodam.kr) dans Chrome, F12 pour DevTools (ou clic droit → Inspecter).
2. L'icône flèche dans un carré en haut à gauche (sélecteur d'élément) : la cliquer puis sélectionner la zone à recolorer (en-tête, fond de carte). À droite, le panneau Styles liste les règles CSS appliquées.
3. Survoler une valeur de couleur (background-color: #2563eb;) : un petit carré apparaît. Le cliquer ouvre le color picker ; glisser ou taper un hex.
4. font-family: ...; se modifie pareil : taper un autre nom ('Pretendard', 'Noto Sans KR', sans-serif).
5. Quand la combinaison plaît, noter les codes hex et les polices. Étape 6 (IA) ou étape 7 (code) s'en serviront.

Astuces utiles :

• Comparer plusieurs éléments — un changement d'en-tête « casse » le corps ? Ajustez les deux à la fois.
• Onglet Computed — affiche la valeur réellement appliquée (avec héritage). Pratique pour traquer « d'où vient cette valeur ? ».
• Forcer :hover — le bouton :hov au-dessus de Styles fixe :hover·:focus pour vérifier les couleurs hover.

Si la sélection de l'étape 5 ne convainc pas, demandez à l'IA ; vous obtenez 5 à 10 candidats d'un coup. Prompt type pour Claude / ChatGPT :

Je fais le tableau d'affichage du menu en magasin pour le café "Sodam".
Ambiance : « café coréen chaleureux et calme ».
Espace : décoration en bois, lumière jaune chaude.

Palette actuelle :
- Fond en-tête : #2563eb (bleu)
- Fond corps : #ffffff
- Texte : #1f2937
- Accent : #2563eb

Suggérez 5 jeux de palettes plus en phase avec cette ambiance.
Pour chaque jeu, donner les 4 hex (en-tête / fond corps / texte / accent)
et une ligne courte décrivant la sensation.

Aussi 3 polices Google (ou polices coréennes libres) bien lisibles
en coréen et adaptées à cette ambiance.

L'IA répondra en gros :

• Jeu 1 (beige chaud · brun foncé) — en-tête #6b4423, fond #f5ecd9, texte #3c2415, accent #c97a4a · se fond naturellement avec bois et lumière chaude
• Jeu 2 (minimal moderne) — …
• …

Vérification des candidats :

1. Retour à F12 (étape 5) : tester chaque hex un par un et choisir le jeu préféré.
2. Les hybrides (« en-tête du 1, accent du 3 ») gagnent souvent. À noter aussi.
3. Pour les polices : https://fonts.google.com, recherche, vérifier les glyphes sur votre menu.

Reporter le choix F12 + IA dans le vrai code. Après cela, le rendu survit au rafraîchissement et tous le voient.

1. Espace de travail → projet → Programmes — double-clic sur le programme de design (souvent main ou theme).
2. Onglet SCSS (ou CSS). Les variables couleur sont en général en haut du fichier ($primary-color, $bg-color …).
3. Brancher les hex sur les variables :
   $header-bg: #6b4423;
$body-bg: #f5ecd9;
$text-main: #3c2415;
$accent: #c97a4a;
4. Pour la police coréenne, ajouter en tout début de SCSS @import url('https://fonts.googleapis.com/css2?family=Pretendard&display=swap'); et mettre font-family: 'Pretendard', sans-serif; sur body.
5. Ctrl+S. L'aperçu en bas doit refléter le changement immédiatement.

Deux façons de publier

• Option A — déploiement manuel (par défaut) : bouton 🚀 Déployer dans la barre haute. 1–2 min de build et de livraison ; menu.sodam.kr bascule sur le nouveau design. Sûr la première fois.
• Option B — déploiement à la sauvegarde (parfait pour les itérations) : basculer la « sauvegarde = déploiement » dans la barre haute. Chaque Ctrl+S déclenche un déploiement. Idéal pour balayer rapidement couleurs / polices / menus en voyant le résultat en prod. À désactiver pendant les heures de service du café (clignotements en plein éditer).

Une fois déployé, ouvrir https://menu.sodam.kr sur smartphone et tablette pour la vérification finale. La même URL sur la tablette à l'entrée — c'est ce que verront les clients.

Au lieu d'écrire fetch() à la main et son v-for, il existe un schéma : prendre un composant déjà conçu (block), le glisser dans un slot d'un frame, brancher un dataset — la page est faite. Ce guide fait la boucle de bout en bout.

Encore l'analogie : un cadre photo vide (frame) reçoit des photos mises en page (blocks) ; un album (dataset) fournit le texte ; accrocher le cadre au mur, c'est le déploiement.

La page d'aujourd'hui — « la liste de produits de notre boutique » : un en-tête en haut, dix cartes au centre (vraies lignes du dataset), un pied de page en bas. Une page banale.

• Un pas plus loin : sur des montages avancés, on relie 8 à 10 tables de dataset — cotations, news, classements — à plusieurs variables en même temps (list / list3 ... list10) et la page entière se rend depuis une seule spec JSON. Ce guide reste sur le premier point de couture : une variable (list) + un dataset (products).
• Pourquoi ce schéma marche — le designer s'occupe seulement de l'apparence du block, le data ownerr du dataset, le responsable de la page de l'appariement des slots dans le Programme Builder. Les rôles se séparent proprement. Les données changent sans casser le design, et inversement.

D'abord les vraies données. Construire l'écran sur une table vide ne prouve rien. Données d'abord, écran ensuite, c'est la règle.

1. Menu haut → Données → Base de données. Pas de dataset à vous ? [+ Nouveau dataset]. Ex. nom shop, MySQL/PostgreSQL.
2. Dans son éditeur SQL (), créer la table :
   CREATE TABLE products (id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), price INT, image_url TEXT);
3. Ouvrir l' Éditeur de cellules sur products, ajouter 5 à 10 lignes. Coller depuis Excel (Ctrl+V) est le plus rapide (voir Best Practices → Éditeur de cellules · Coller pour insérer).
4. Vérification rapide : SELECT * FROM products LIMIT 3;. À l'étape 6 ce dataset alimentera la variable list.

Quelles colonnes — uniquement celles que le block utilisera. name · price · image_url suffit. Plus, ça ne gêne pas, mais commencer simple accélère le débogage.

Maintenant le block qu'on glissera dans le slot. Menu haut → Design → Block (ou /layout/block) ouvre la bibliothèque. [+ Nouveau block].

1. Nom — quelque chose de mémorisable comme product_card_list.
2. Zone HTML — gabarit grille de cartes. Astuce : nommer la variable list :
   <div class="card-grid">
  <div class="card" v-for="item in list" :key="item.id">
    <img :src="item.image_url">
    <div class="name">@{{ item.name }}</div>
    <div class="price">@{{ item.price }}</div>
  </div>
</div>
3. Zone CSS/SCSS — grille basique :
   .card-grid { display:grid; grid-template-columns:repeat(3,1fr); gap:16px; }
.card { padding:14px; border:1px solid #eee; border-radius:8px; }
4. sample_data — données factices en JSON, clé list :
   { "list": [
  {"id":1,"name":"Échantillon A","price":1000,"image_url":"/assets/sample.jpg"},
  {"id":2,"name":"Échantillon B","price":2000,"image_url":"/assets/sample.jpg"}
] }
5. Enregistrer. La prévisualisation du Block Builder doit afficher automatiquement deux cartes depuis sample_data. Cette prévisualisation est la vérification critique. Si rien ne sort : vérifier que le nom de variable dans le HTML (list) correspond à la clé dans sample_data (list).

La page (programme) maintenant. Service → Projet → [mon projet] → + Nouveau programme, ou ouvrir un programme existant dans le Programme Builder (Coder Builder). Même outil, deux noms. Huit onglets d'étape.

1. Huit onglets — db · list · detail · search · hook · style · code · menu. On clique le second, list.
2. Bascule de mode — en haut de l'onglet list, deux modes : « champs / slots ». Par défaut « champs » (table-like). On veut des blocks designés → on bascule en slots. L'UI passe en config en 3 étapes :
   • 1) Sélection du frame — quel cadre, combien de slots et leur disposition.
   • 2) Configuration des slots — quel block dans quel slot, comment mapper les variables.
   • 3) Aperçu du code — résultat synthétisé.
3. Si « frame / slot » paraît abstrait : pensez « un cadre 3 rangées qui attend trois photos ». On choisit le frame à l'étape 5.

Dans 1) Sélection du frame en mode slot, ouvrez la dropdown et choisissez quelque chose de simple — « 3-row (haut/milieu/bas) » convient. Frame choisi, [Appliquer], et 2) Configuration des slots crée automatiquement les lignes slot 1, slot 2, slot 3 …

1. Au slot 2 (milieu), ouvrez la dropdown sélection du block et prenez product_card_list de l'étape 3. Les options s'affichent souvent en id - nom - auteur.
2. Dès la sélection, l'aire du slot affiche la prévisualisation du block via sample_data — deux cartes. Si vous les voyez, le block est bien posé.
3. Slot 1 (haut) et slot 3 (bas) : on peut y mettre les blocks header/footer préparés à l'avance, ou les laisser vides. Pour le premier passage, le slot 2 suffit.
4. Chaque ligne de slot a aussi un data_placer (sélecteur source) et un data_selector (sélecteur cible). Pour l'instant les deux à list. Sens à l'étape 6.
5. Le block est dans le slot, mais il fonctionne encore avec le sample. Le dataset réel arrive juste après.

L'étape la plus importante. On câble la variable list du block sur les vraies lignes de la table products.

À quoi servent les deux champs :

• data_placer (sélecteur source) — nom de variable tel qu'écrit dans le block. Notre block contient v-for="item in list", donc list.
• data_selector (sélecteur cible) — nom de variable au niveau de la page. Avec deux listes de cartes sur une même page, list entrerait en collision ; on mappe vers product_list et review_list. Une seule liste ? list reste list.

Pour rester simple, on garde les deux à list.

Brancher le vrai dataset — section « variables de données / data_vars » en haut du Programme Builder (ou panneau latéral). Vide ? + Ajouter une ligne.

1. Nom de variable : list (doit correspondre au data_selector de l'étape 5).
2. Dataset : sélectionner shop de l'étape 2.
3. Table : products.
4. WHERE (optionnel) : vide = tout. Ex. price > 0.
5. LIMIT (optionnel) : 0, 20 pour les 20 premières lignes.
6. ORDER BY (optionnel) : id desc pour les plus récentes en premier.
7. Enregistrer.

En interne, ça donne une fiche JSON (vous ne l'écrivez pas, mais conceptuellement) :

{"var_name":"list","dataset":{"id":42,"table_name":"products","str_limit":"0, 20","str_order":"id desc"}}

C'est la spec que suivra le moteur de rendu : à l'exécution il fera SELECT * FROM products ORDER BY id desc LIMIT 20, dépose les lignes dans list, et le v-for du block enchaîne.

Tout câblé ? Direction 3) Aperçu du code en mode slot (ou l'onglet code) pour laisser le système synthétiser le résultat.

1. Générer le code (synchroniser). Le système assemble :
   • Squelette HTML du frame + HTML de chaque block dans <[slot-1]>·<[slot-2]>·…
   • À l'intérieur de chaque block, list → data_selector de l'étape 5 (toujours list ici).
   • Les définitions data_vars sont ajoutées à l'init de la page.
2. Inspectez la sortie. v-for="item in list" intact, et en haut un list = await fetch('/api/...') ou injection serveur — c'est bon.
3. Ctrl+S ou Enregistrer. La prévisualisation doit afficher les vraies cartes products. 5 à 10 cartes du dataset, plus seulement les 2 du sample_data.
4. Final : 🚀 Déployer dans la workspace (ou « sauvegarde = déploiement » activé), vérification sur le domaine en ligne.

Pourquoi la spec JSON est le frontend — à ce stade, tout le comportement de la page tient en trois JSONs :

• slot_info — quel frame + quels slots + quels blocks.
• data_vars — chaque variable reliée à quel dataset, table, filtre.
• ui_info — options UI supplémentaires (presque vide ici).

Plus de code à la main : ajustez ces trois JSONs et la page se redessine. Ça devient magique : faire 10 écrans s'approche du coût d'un seul, parce que chaque nouvel écran est surtout une nouvelle combinaison de blocks et de liaisons existants.

Pour un site simple, une URL GET comme https://site.com/search?q=hello suffit. Mais plus de la moitié des sites du quotidien ne sont pas si simples.

• Résultats visibles uniquement après login — sans cookie de session, on récupère une page vide ou l'écran de connexion.
• POST + corps JSON — le mot-clé n'est pas dans l'URL, il vit dans le corps : {"q":"hello","page":1,"size":20}.
• Jetons CSRF / Bearer — chaque requête a besoin d'un en-tête supplémentaire, sinon réponse vide.
• X-Requested-With · Referer · User-Agent — sans ces marqueurs AJAX, le serveur répond souvent volontairement vide.

Recopier chaque en-tête à la main n'est pas raisonnable. Le chemin le plus rapide : copier la vraie requête du navigateur en une commande cURL d'une ligne, tout laisser comme capturé, et remplacer uniquement les morceaux qui varient par ligne par des variables.

Ce que nous allons construire — un dataset de N mots-clés (par ex. keyword_list), puis appeler N fois l'API de recherche du site et empiler les réponses dans un second dataset (par ex. search_results).

Ouvrez le site cible dans Chrome (ou Edge) et lancez une recherche normale.

1. F12 ouvre les DevTools, puis onglet Network.
2. La recherche remplit la liste de requêtes. Celle qu'il faut contient en général search, list, query ou api dans son nom et renvoie du JSON.
3. Cliquez la ligne, vérifiez dans le panneau Response à droite que le corps est bien les données voulues.
4. Clic droit sur la ligne → Copy → Copy as cURL (bash). Même sous Windows : la version bash a le quoting le plus propre.

Votre presse-papiers contient maintenant une seule ligne du genre curl 'https://...' -H 'Cookie: ...' -H 'Authorization: ...' --data-raw '{...}'. C'est long, mais cela contient URL · cookies · tous les en-têtes · corps d'un coup.

Ne collez pas le cURL directement dans le parseur. Confirmez d'abord dans Postman (ou Insomnia / Bruno) qu'un appel passe exactement. Si ça bloque ici, la règle de parseur bloquera aussi.

1. Ouvrir Postman → en haut à gauche Import → onglet Raw text.
2. Coller la ligne cURL avec Ctrl+V, cliquer Continue → Import.
3. Un nouvel onglet de requête s'ouvre, en-têtes et corps préremplis. Cliquer Send en haut à droite.
4. Statut 200 et corps identique au navigateur → c'est bon. Corps vide, 401, 403 ou 302 → vérifiez la liste ci-dessous.

• Cookie expiré — la cause la plus fréquente. Retournez dans le navigateur, vérifiez que vous êtes encore connecté, puis F12 → Copy as cURL à nouveau.
• En-tête perdu à l'import — Postman laisse parfois tomber 1–2 en-têtes. Ouvrez les Headers du navigateur et de Postman côte à côte et comparez ligne par ligne.
• Referer / Origin — certains sites renvoient vide sans ces deux. Si le navigateur les envoie, ajoutez-les ici.

En regardant la requête Postman qui marche, marquez ce qui changera au prochain appel. Candidats classiques :

• Mot-clé dans le corps POST — "q":"hello" → "q":"${query}"
• Page / offset — "page":1 → "page":${page} (les nombres sans guillemets)
• Catégorie / filtre — "cat":"food" → "cat":"${category}"
• Plage de dates — "from":"2026-04-01" → "from":"${date_from}"
• Variable dans le chemin URL — /api/user/12345 → /api/user/${user_id}

L'astuce : nommer chaque variable exactement comme la colonne du dataset que vous allez créer. Si vos colonnes vont s'appeler query · page · category, écrivez aussi ${query} · ${page} · ${category} dans le cURL. Noms identiques → mapping automatique à l'étape suivante, sans câblage manuel.

Format — le parseur reconnaît le motif ${nom}. Lettres ASCII, chiffres et underscore uniquement (pas d'espaces, pas de caractères localisés, pas de ponctuation).

Le parseur lit le dataset ligne par ligne et alimente les emplacements de variables du cURL. Donc dans cette étape, on prépare les N combinaisons d'entrée comme un dataset.

1. Menu latéral Données > Datasets → en haut à droite + Nouveau dataset.
2. Nom évident, par ex. keyword_list. Ajoutez des colonnes dont les noms correspondent exactement aux variables de l'étape 4 — par ex. query (varchar) · page (int) · category (varchar).
3. Lignes au choix — (a) tapées dans l'UI une à une, (b) préparées dans Excel/Sheets puis collées via le Cell Editor en mode coller → insérer en BDD (voir guide cell-paste).
4. Ne voyez pas trop grand. 3–5 lignes suffisent pour démarrer. À 100 lignes, une erreur = 100 appels foirés.

Pratique aussi de préparer dès maintenant le dataset de sortie. Par ex. search_results avec query, rank, title, url, snippet. Vous y pointerez le parseur à l'étape 6.

Maintenant on crée la règle dans le parseur et on relie le cURL au dataset.

1. Menu latéral Données > Parseur → en haut à droite + Nouvelle règle.
2. Champ Page de test (URL de base) — collez l'endpoint du début du cURL, par ex. https://example.com/api/search. Si l'URL contient elle-même une variable, écrivez-la pareil : ${user_id}.
3. Champ cURL — Ctrl+V sur la ligne avec variables marquées de l'étape 4. Le parseur sépare automatiquement méthode, en-têtes, cookies, corps, et trouve les motifs ${...} qu'il enregistre comme variables candidates.
4. Choisir le dataset d'entrée — keyword_list de l'étape 5. Les noms identiques se mappent tout seuls, les non-identiques affichent un dropdown de mapping à côté.
5. Choisir le dataset de stockage des réponses — search_results. Indiquez dans le champ JSON path quel chemin (par ex. data.items[*]) se déplie en une ligne.
6. Sauvegarder. La règle est enregistrée — aucun appel n'a encore eu lieu.

Deux modes d'exécution.

• ① Override direct, un coup — sur la page de la règle, à côté du bouton ▶ Exécuter, le panneau saisie de variables permet de taper directement query="café paris", page=1 et de lancer un seul appel. Aperçu de la réponse et lignes extraites côte à côte. Restez dans ce mode tant que la forme de la réponse n'est pas pleinement comprise.
• ② Boucle sur dataset — basculer le panneau de variables sur « Depuis dataset », choisir keyword_list de l'étape 5, cliquer Exécuter. La barre de progression monte de 0/N à N/N, les réponses s'ajoutent ligne par ligne à search_results.

Pendant l'exécution, surveillez — nombre d'erreurs (vide / 401 / 5xx), échantillon de réponse, lignes stockées. Une ou deux lignes en échec, c'est normal ; au-delà de 50 % d'échec, arrêtez immédiatement et revoyez le cURL.

Planification — l'onglet Schedule de la règle permet de lancer chaque jour, chaque heure, ou à n'importe quel horaire cron. Une liste de mots-clés en entrée → des résultats frais empilés tous les jours à la sortie.

Avant de téléverser, emballez tout ce que le designer a fourni dans une seule archive zip. La façon de zipper détermine les chemins sur le serveur — respectez ces règles.

• Emballez le tout dans un dossier racine unique — par ex. mettez images et css dans design_assets/, puis zippez ce dossier lui-même. Après extraction vous obtiendrez /chemin-cible/design_assets/logo.png, le nom du dossier restant sur un niveau.
• Nommez uniquement avec lettres, chiffres, trait d'union (-) et soulignement (_) — les espaces ou caractères non ASCII cassent facilement les références d'URL. Exemple : bannière principale.png ❌ → main-banner.png ✅
• Formats pris en charge — .zip · .tar · .tar.gz · .tgz. En général .zip suffit. Sous Windows, clic droit sur le dossier → « Compresser au format ZIP » ; sur macOS, dans Finder, clic droit → « Compresser ».
• Exemple d'arborescence —
  design_assets/
 ├─ images/logo.png
 ├─ images/hero.jpg
 ├─ fonts/pretendard.woff2
 └─ css/theme.css

Depuis la barre de navigation supérieure ou le tableau de bord, allez dans Services → Gestion distante. La liste des serveurs est à gauche, l'explorateur de fichiers à 4 colonnes au centre, la barre d'actions en bas.

1. Dans la liste à gauche, cliquez le domaine cible (par ex. myshop.apidealder.net). Le petit cercle indique l'état.
   • Point vert — prêt ; la liste de fichiers s'ouvre immédiatement.
   • Point gris — hors ligne. Le conteneur est arrêté ou non encore déployé.
   • Point blanc — vérification de l'état en cours.
2. Si la liste est vide, le message « Déployez d'abord un serveur » apparaît. Déployez alors un single-file ou un projet avant de revenir.
3. Une fois sélectionné, le centre affiche la racine (/) et l'arborescence réelle.

Les assets seront chargés par le navigateur via URL, ils doivent donc vivre dans un dossier accessible publiquement. Sur les serveurs à base single-file, on utilise généralement public/assets.

• Barre de chemin — l'icône maison en haut revient à la racine ; chaque segment entre les slashes est cliquable pour y sauter directement.
• Saisie directe du chemin — dans le champ adjacent, tapez /public/assets puis Entrée pour y atterrir en un seul geste.
• Si le dossier assets n'existe pas — utilisez [Nouveau dossier] dans la barre d'actions en bas pour créer assets, puis entrez dedans. Seuls lettres, chiffres, point (.), trait d'union (-) et soulignement (_) sont autorisés.
• Après le déplacement, vérifiez que la barre de chemin affiche /public/assets. C'est là que l'archive sera décompressée — un mauvais emplacement impose suppression et nouvel envoi.

Avec le chemin sur /public/assets (ou tout autre dossier public), cliquez [Téléverser l'archive] (icône nuage + flèche haut) dans la barre d'actions du bas. La modale s'ouvre en trois phases.

1. Zone de dépôt — glissez-déposez le zip dans le cadre pointillé ou cliquez pour ouvrir le sélecteur de fichiers. .zip · .tar · .tar.gz · .tgz sont pris en charge.
2. Aperçu — la modale dessine l'arborescence des dossiers/fichiers dans l'archive et affiche en haut le nom, la taille et la cible d'extraction (/public/assets). Vérifiez que l'enveloppe extérieure est correcte et qu'aucun fichier caché intrus (.DS_Store de macOS, etc.) ne s'est glissé. Le [x] en haut à droite permet de changer de fichier.
3. Envoi — cliquez [Envoyer]. Le fichier est envoyé par morceaux de 1 Mo avec une barre de progression en direct ; les réseaux capricieux reprennent proprement et les gros fichiers (centaines de Mo) passent de façon stable.
4. Une fois le transfert terminé, le serveur décompresse automatiquement l'archive, le dossier courant se rafraîchit, le design_assets nouvellement envoyé (ou images/fonts/css) apparaît. Un toast de fin confirme l'opération.

Besoin d'envoyer quelques fichiers isolés plutôt qu'une archive ? Le bouton voisin [Téléverser des fichiers] permet la sélection multiple — ils sont copiés tels quels dans le dossier courant, sans extraction.

Les fichiers téléversés sont servis directement depuis le domaine déployé. Par exemple, si vous avez envoyé /public/assets/design_assets/images/logo.png sur myshop.apidealder.net, l'URL du navigateur est https://myshop.apidealder.net/assets/design_assets/images/logo.png. (public est la racine web et disparaît de l'URL.)

Ouvrez maintenant l'éditeur single-file (Services → Single File) et référencez les assets téléversés.

• Insérer des images dans l'onglet HTML —
  <img src="/assets/design_assets/images/logo.png" alt="logo">
<img src="/assets/design_assets/images/hero.jpg">
• Référencer arrière-plans et polices dans l'onglet SCSS —
  .hero { background: url("/assets/design_assets/images/hero.jpg") center/cover; }
@font-face { font-family: 'Pretendard'; src: url("/assets/design_assets/fonts/pretendard.woff2") format('woff2'); }
• Règle clé — utilisez toujours un chemin absolu commençant par /. Les chemins relatifs (../assets/...) peuvent se comporter différemment entre l'aperçu et la production et sont à éviter.
• Pour inclure un CSS externe en entier, ajoutez @import url("/assets/design_assets/css/theme.css"); en haut de l'onglet SCSS.

Une fois les références câblées, cliquez [Run ▶] en haut à droite de l'éditeur single-file pour voir l'aperçu. Si tout va bien, appuyez sur [Deploy 📦] pour pousser sur le domaine.

1. Aperçu Run — le panneau de droite rend le résultat en temps réel. Vérifiez que les images apparaissent, que les polices se chargent, que le CSS n'est pas cassé.
2. Deploy — le bouton lance un déploiement étape par étape, en 1 à 2 minutes en général. Un lien vers le domaine apparaît dans la zone de résultat à la fin.
3. Vérification sur le domaine déployé — ouvrez le lien dans un nouvel onglet ou allez directement sur https://votre-domaine/. Faites un rechargement forcé (Ctrl+F5 ou Cmd+Shift+R) pour ignorer le cache.
4. Si une image n'apparaît pas, revenez à la gestion distante et revérifiez le chemin. Si la structure extraite ne correspond pas à ce que vous attendiez, supprimer le dossier et réenvoyer depuis l'étape 4 est plus rapide que corriger les chemins à la main.

Les symptômes en surface se ressemblent, mais les causes varient. Dans l'un de ces cas, lire les logs côté serveur est la voie la plus rapide.

• Erreurs serveur 500 / 502 / 504 — le navigateur affiche seulement « Une erreur est survenue » ; la vraie cause vit dans le log serveur.
• Page blanche — généralement une erreur fatale PHP qui a coupé la sortie. Le log contient très probablement une ligne Fatal Error ou Parse Error.
• API qui renvoie 400/422 avec une cause floue — la règle de validation exacte qui a bloqué est consignée dans le log du contrôleur.
• Tâches d'arrière-plan (queue, planificateur, macro) « qui semblent tourner sans résultat » — les échecs silencieux laissent des traces uniquement dans le log.

Principaux fichiers de log à consulter :

• storage/logs/laravel.log — le log principal PHP/Laravel. Le plus souvent consulté.
• storage/logs/laravel-YYYY-MM-DD.log — si la rotation quotidienne est activée.
• storage/logs/worker.log et les logs spécifiques à une fonctionnalité (macros, parseurs) quand ces sous-systèmes tiennent leurs propres fichiers.

Dans le navigateur, direction Services → Gestion distante.

1. Dans la liste des serveurs à gauche, cliquez le domaine concerné. Point vert = conteneur joignable. Point gris/blanc = conteneur endormi — attendez une minute et réessayez.
2. Cliquez l'icône terminal (▷_) dans la barre d'outils centrale. Un panneau terminal monte depuis le bas. Re-cliquer la même icône le replie.
3. L'entête affiche le répertoire de travail courant (par ex. /var/www/html) et le curseur clignote dans la zone de saisie. Ce curseur est branché directement sur le shell du serveur sélectionné ; les commandes tapées s'exécutent là.
4. Situez-vous d'abord :
   pwd
ls
   Vous atterrissez généralement à la racine du projet (/var/www/html).

Dans un projet Laravel, les logs vivent dans storage/logs. Depuis le terminal, on y saute.

• cd storage/logs — relatif au dossier courant ; une ligne suffit si vous êtes déjà dans /var/www/html.
• cd /var/www/html/storage/logs — chemin absolu ; fonctionne d'où que vous soyez.
• pwd — confirmez être dans /var/www/html/storage/logs.

Le terminal se souvient du répertoire de travail, donc toutes les commandes suivantes s'exécutent par rapport à ce dossier — pas besoin de retaper le chemin.

Alternative : allez d'abord sur /storage/logs dans l'explorateur, puis ouvrez le terminal — le chemin suit automatiquement. Pratique si vous n'aimez pas saisir des chemins.

Une fois dans le dossier, regardez d'abord quels fichiers existent et lesquels ont été modifiés récemment, puis ouvrez leur contenu.

• ls -lhrt — listing trié par date de modification croissante ; le plus récent est en bas. -h affiche des tailles lisibles (Ko/Mo).
• cat laravel.log — affiche tout le fichier. Sûr seulement pour les petits fichiers ; plusieurs Mo saturent le terminal.
• tail -n 100 laravel.log — les 100 dernières lignes. Le moyen le plus rapide de voir l'erreur la plus récente. Ajustez le nombre.
• tail -f laravel.log — suivi en direct. Les nouvelles lignes apparaissent dès qu'elles sont écrites ; reproduisez le bug dans le navigateur et regardez les entrées défiler. Arrêt par Ctrl+C.
• head -n 50 laravel.log — 50 premières lignes ; utile pour les entrées de démarrage en tête de fichier.
• wc -l laravel.log — nombre total de lignes. Au-delà de centaines de milliers, passez directement à grep.

Quand le fichier est long, tail seul ne suffit pas. grep imprime uniquement les lignes contenant un motif donné — l\'outil-clé du débogage par log.

• grep -i error laravel.log — toutes les lignes contenant « error » ; -i rend la recherche insensible à la casse, donc « Error », « ERROR » et « error » matchent.
• grep -in "fatal\|exception" laravel.log — lignes avec « fatal » ou « exception », avec numéros de ligne (-n). Plusieurs motifs se combinent en OR avec \|.
• grep -A 5 -B 2 "SQLSTATE" laravel.log — trouve les lignes contenant SQLSTATE et imprime 2 lignes avant (-B 2) et 5 après (-A 5) comme contexte. Idéal pour voir la stack trace à côté de l\'exception.
• grep "2026-04-25 15:4" laravel.log — restreint à une fenêtre horaire (plage 15 h 40). Combiné à la fenêtre de l\'étape 1, la recherche se resserre rapidement.
• grep -c "production.ERROR" laravel.log — n\'imprime que le nombre de correspondances. Utile pour « à quelle fréquence cela arrive ».
• tail -f laravel.log | grep -i error — suivi en direct + filtre. Seules les lignes contenant « error » passent à l\'écran.

Flux typique — grep -i error pour la vue d\'ensemble → choisir un message saillant et rejouer grep -A 10 "ce message" pour le contexte → noter les chemins de fichiers et numéros de lignes qui en sortent.

Les lignes d\'erreur relevées par grep portent en général un chemin de fichier et un numéro de ligne (par ex. /var/www/html/app/Services/Order.php:127). Utilisez-les pour aller droit au correctif.

1. Repliez le terminal, collez /var/www/html/app/Services dans le champ de chemin de l\'explorateur et tapez Entrée.
2. Double-cliquez sur le fichier cible pour l\'ouvrir dans l\'éditeur avec coloration syntaxique. Corrigez la ligne, appuyez sur [Enregistrer] — l\'effet est immédiat, sans redéploiement.
3. Rouvrez le terminal, lancez un suivi en direct avec tail -f /var/www/html/storage/logs/laravel.log, puis reproduisez le bug dans le navigateur.
4. Si la même erreur ne revient pas, Ctrl+C et c\'est fini. Si une autre apparaît, retour à l\'étape 5 pour affiner.

Quand il faut du log de debug temporaire — ajoutez une ligne \Log::info('[debug] ' . json_encode($variable)); dans le code suspect, enregistrez, reproduisez, puis relisez la valeur avec grep "[debug]" laravel.log. Une fois la cause comprise, retirez la ligne Log::info(). C\'est la manière la plus sûre.

Presque toutes les équipes de dev sérieuses suivent ce flux. De petits changements, vérifiés à chaque étape. Lancer un changement directement en prod, c'est casser la prod d'un coup.

• Local est rapide. Sauvegarder → rafraîchir, une seconde. Premier endroit où vous confirmez que la modif correspond à l'intention.
• Stage reflète le domaine/BDD/trafic de la prod. Dernier filet pour les surprises « ça marchait chez moi ».
• Prod est ce que voient les vrais utilisateurs. Un problème découvert ici devient une plainte client.

Aujourd'hui on parcourt les trois étages d'un bout à l'autre. Le travail effectif passe par des demandes à Claude ou Codex dans VS Code en langage naturel. Votre rôle n'est plus de taper ligne par ligne, mais de formuler clairement, vérifier le résultat et décider si on peut envoyer plus loin.

Cinq minutes une fois, et tout le reste de la journée va plus vite.

1. Sur QuickStart Web, ouvrir Télécharger le paquet de votre projet, dézipper, dans VS Code File > Open Folder.
2. Le panneau QUICKSTART en bas apparaît automatiquement. L'authentification est silencieuse — l'empreinte du .env connecte sans formulaire de login.
3. Onglet UTIL → tout en bas [🚀 SMART SETUP]. Lance composer dump-autoload → npm install → vite build à la suite. À la fin, vite dev et le serveur PHP intégré sont tous deux en route.

Ouvrez http://localhost:<port> — votre projet tourne. Voilà la ligne de départ.

Deux voies, généralement utilisées ensemble.

• ① Panneau de chat VS Code + MCP — branchez Claude (ou Cursor / Copilot Chat / Codex CLI) sur un serveur MCP du projet. Dans le chat : « ajoute une colonne phone à la table users et une ligne au formulaire d'inscription ». L'IA écrit le SQL, modifie blade/vue/scss et lance le build, en un seul passage.
• ② Boutons IA de l'onglet UTIL — sélectionnez du code et cliquez UTIL → groupe IA → [CODE REVIEW] · [REFACTOR] · [EXPLAIN] · [i18n TS]. Chacun construit un prompt riche en contexte projet à coller dans Claude/Codex pour une réponse plus fine.

Bien rédiger une demande — soyez précis sur « quoi, où, sous quelle forme ». Exemple : « Sur /admin/users, montrer la colonne phone juste après email ; afficher \"-\" quand vide. » Avec ça l'IA ne se perd pas.

Au moment où l'IA sauvegarde, vite dev fait du hot-reload du navigateur. Presque tous les .blade.php·.scss·.vue·.js se rafraîchissent à la sauvegarde ; les changements PHP sont pris par php artisan serve.

1. Regardez le vrai écran — bonne place, bon comportement, bonne forme ?
2. Coup d'œil rapide à la console F12 — pas d'erreur rouge avant de continuer.
3. UTIL → SYSTEM → [CLEAN CACHE] vide le cache view/route de Laravel pour que les changements de template/config arrivent proprement.

Pas bon → courte demande IA suivante : « déplace cette colonne phone au-dessus du code postal » — puis rafraîchir. En rythme, un tour en moins d'une minute, c'est la cadence normale.

Local validé → push vers stage.

1. Onglet QS DEPLOY en bas.
2. Barre latérale gauche : Source = L (Local), cocher Destination = stage.
3. Sur chaque nœud, cliquer [CONNECT] et [TEST CONFIG] une fois — confirmer la connexion réelle. Point rouge → vérifier le .env du nœud (host/port/compte BDD).
4. Cliquer le [SRC → DST] central. Côté droit, vérifier que [Save on Deploy] est ON — si ON, tous les éditeurs ouverts se sauvegardent avant le déploiement.
5. La visionneuse de log montre en direct code + assets (images/build) + schéma & données BDD partir vers stage en un seul passage.

Une fois fini, ouvrir le domaine stage et vérifier non seulement le changement de code mais aussi que la nouvelle colonne phone est bien dans la BDD stage.

Stage est le miroir de la prod. Seul le domaine diffère ; le code et la BDD sont exactement ce qui va partir.

• Aller sur le vrai domaine stage et utiliser le changement vous-même. Cache, CDN, sessions — les soucis qui se cachent en localhost ressortent ici.
• Partager le lien à quelqu'un d'autre. Il voit ce que vous ne voyez plus parce que c'est vous qui l'avez écrit.
• QS DEPLOY → [DIFF] compare stage ↔ local. Des différences signifient que quelqu'un a touché stage à la main — nettoyer avant le déploiement prod.
• [BROWSER] ouvre l'arborescence réelle de stage pour inspecter un fichier suspect.

Régression trouvée → retour local, redemander à l'IA → étape 4 → si OK, retour étape 5. Un tour de plus ici coûte radicalement moins qu'un incident en prod.

Stage validé → étape finale. Mêmes boutons qu'à l'étape 5, mais les vrais utilisateurs voient immédiatement.

1. QS DEPLOY → Source = stage (ou L avec le même code), Destination = main (nœud de prod).
2. Reconfirmer que [Save on Deploy] est ON. Le tenir toujours ON est le défaut sûr.
3. Cliquer [SRC → DST]. Rester sur la visionneuse de log jusqu'à la fin — au moindre 5xx ou ligne rouge, on arrête.
4. Ouvrir le domaine prod. Refaire la nouvelle fonctionnalité, plus les flux clés non touchés (login, paiement, etc.) — confirmer qu'ils marchent toujours.
5. Si quelque chose cloche, [SWITCH] échange Source/Destination et l'état précédent de stage repart vers la prod — c'est votre rollback rapide.

Un tour complet bouclé — VS Code → Claude/Codex(MCP) → Local → Stage → Prod. Toutes les modifs futures empruntent le même rail, juste plus vite.