Interface et logique à migrer depuis WeWeb

Ce que WeWeb stocke (et ce qu’il ne stocke pas)

WeWeb n’est pas une base de données métier. Votre projet WeWeb contient une interface et de la logique de présentation. Vos données métier (clients, commandes, documents) sont dans le backend que vous avez connecté — Xano le plus souvent, ou une API tierce.

Ce que WeWeb stocke dans votre projet :

• La structure des pages : arborescence des écrans, routes et paramètres de navigation
• Les composants et leur configuration : propriétés, styles, breakpoints responsive
• Les collections : définition des liaisons aux APIs (endpoint, méthode, paramètres, mapping)
• Les variables : état local de chaque page et état global de l’application
• Les workflows : logique événementielle (clics, soumissions, navigation conditionnelle)
• La configuration d’authentification : provider, routes protégées, rôles et permissions
• Les assets uploadés dans WeWeb : images et fichiers utilisés dans l’interface

La migration depuis WeWeb est donc principalement une reconstruction d’interface, pas une migration de données au sens traditionnel.

---

Export d’un projet WeWeb

WeWeb ne propose pas d’export de code directement exploitable pour une équipe de développeurs. Le projet est stocké dans la plateforme WeWeb et n’est accessible qu’via l’éditeur.

Ce qui est disponible pour l’analyse :

• L’interface de l’éditeur : navigation page par page, inspection des composants et de leurs propriétés, lecture des workflows et des collections configurées.
• Les appels API en temps réel : via les outils de développement du navigateur (onglet Réseau), il est possible d’auditer précisément les endpoints appelés, les paramètres envoyés et les structures de données reçues.
• L’export de données backend : si votre backend est Xano, les données sont exportables indépendamment de WeWeb via l’API Xano ou l’export CSV. Consultez le guide de migration depuis Xano pour ce volet.

---

Pages et structure de navigation

L’audit commence par la cartographie de toutes les pages du projet : leur URL, leurs paramètres de route, les guards d’authentification associés et les dépendances entre pages (redirections, navigation conditionnelle après action).

Ce qui est reconstruit en Vue Router

Chaque page WeWeb devient un composant Vue.js de page, enregistré dans Vue Router :

Élément WeWeb	Reconstruction Vue Router
Page simple	Composant de route sans paramètre
Page avec paramètre dynamique (ex : /commandes/:id)	Route avec params typés
Page protégée (authentification requise)	Navigation guard beforeEach
Page avec rôle requis	Guard avec vérification du store Pinia
Page 404 personnalisée	Route catch-all /:pathMatch(.*)*

---

Composants et mise en page

Les composants WeWeb sont analysés visuellement depuis l’éditeur. Pour chaque écran, l’audit identifie :

• La structure de grille et les breakpoints responsive configurés
• Les composants natifs WeWeb utilisés (tableau, formulaire, modal, onglets…)
• Les composants de la marketplace installés (calendrier, éditeur riche, graphique…)
• Les propriétés dynamiques liées à des variables ou à des données de collection

Correspondances avec l’écosystème Vue.js

Type de composant WeWeb	Bibliothèque Vue.js cible
Tableau avec tri et pagination	PrimeVue DataTable ou TanStack Table
Formulaire avec validation	VeeValidate + Zod ou Yup
Sélecteur de date	Vue Datepicker ou PrimeVue Calendar
Éditeur de texte riche	Tiptap
Graphique	Chart.js avec vue-chartjs
Modal et drawer	Headless UI ou PrimeVue Dialog
Kanban	Composant sur mesure (vue-draggable)

Les composants standard se reconstruisent rapidement grâce aux bibliothèques disponibles. Les composants très personnalisés (logique conditionnelle d’affichage complexe, animations spécifiques) nécessitent une analyse plus détaillée.

---

Collections de données

Les collections WeWeb définissent comment l’interface se connecte au backend. Chaque collection est une configuration d’appel API (endpoint, méthode HTTP, paramètres, mapping des champs).

Ce qui est audité dans chaque collection

• L’endpoint appelé et la méthode HTTP (GET, POST, PUT, DELETE)
• Les paramètres d’entrée (filtres, pagination, tri, identifiants dynamiques)
• La structure des données retournées et le mapping vers les composants
• Les actions de rafraîchissement (déclenchement automatique ou manuel)
• La gestion des états de chargement et d’erreur affichés dans l’interface

Reconstruction avec Axios

En Vue.js natif, les collections WeWeb sont remplacées par des services Axios centralisés, appelés depuis des composables ou des actions Pinia. Le pattern type :

• Service Axios par domaine : un fichier par ressource (commandes.service.ts, clients.service.ts…) qui encapsule les appels HTTP et les paramètres
• État géré dans Pinia : les données, l’état de chargement (isLoading) et les erreurs (error) sont stockés dans le store, pas dans les composants
• Intercepteurs globaux : injection automatique du token JWT dans les headers, gestion centralisée des erreurs 401/403/500 sans répéter le code dans chaque composable
• Appels déclenchés par les actions : un appel API = une action Pinia nommée, traçable et testable indépendamment des composants qui l’appellent

---

Variables et état global

WeWeb distingue les variables de page (locales à un écran) et les variables globales (partagées entre plusieurs pages). Les deux sont analysées lors de l’audit.

Correspondance avec Pinia

Type de variable WeWeb	Équivalent Pinia
Variable de page (état local)	ref ou reactive dans le composant
Variable globale persistante	Store Pinia avec persistedstate
Variable calculée (formula)	computed dans le composant ou le store
Variable de collection active	Store Pinia avec action de sélection

Les stores Pinia sont typés en TypeScript, ce qui garantit la cohérence des données entre les composants et facilite la maintenance.

---

Workflows et actions

Les workflows WeWeb définissent la logique événementielle de l’application : ce qui se passe quand un utilisateur clique sur un bouton, soumet un formulaire, navigue vers une page ou déclenche une action conditionnelle.

Types d’actions WeWeb et leur reconstruction

Type d’action WeWeb	Reconstruction Vue.js natif
Appel API (collection)	Action Pinia avec appel Axios
Navigation vers une page	router.push() avec params
Afficher / masquer un composant	v-if ou v-show conditionnel
Modifier une variable	Action Pinia ou ref local
Afficher une notification	Composable de toast (Sonner ou PrimeVue Toast)
Ouvrir / fermer une modal	ref booléen ou store dédié
Logique conditionnelle (if/else)	Guard dans le handler d’événement

Les workflows simples se reconstruisent ligne pour ligne. Les workflows avec plusieurs branches conditionnelles imbriquées sont décomposés en fonctions nommées, ce qui améliore la lisibilité et permet l’ajout de tests.

---

Authentification et gestion des rôles

La configuration d’authentification WeWeb (provider, routes protégées, permissions par rôle) est analysée et reconstruite avec la stack d’authentification cible.

Points spécifiques à auditer :

• Provider d’authentification : JWT natif Xano, OAuth (Google, GitHub…) ou autre provider
• Structure des rôles : liste des rôles définis, règles d’accès par page et par action
• Stockage de la session : token JWT dans localStorage, sessionStorage ou cookie HttpOnly
• Comportement à l’expiration : redirection vers login, rafraîchissement automatique du token

La reconstruction utilise un store Pinia dédié à l’authentification, avec des guards Vue Router pour les routes protégées et des directives conditionnelles pour les éléments d’interface visibles selon le rôle.

---

Assets et images

Les assets (images, icônes, fichiers) uploadés directement dans WeWeb sont hébergés sur l’infrastructure de WeWeb. Ils sont téléchargés pendant la migration et ré-hébergés sur le stockage cible (cellar chez Clever Cloud équivalent).

Points d’attention :

• Les images référencées depuis Xano (attachments) sont gérées dans le cadre de la migration Xano, pas dans la migration WeWeb
• Les icônes SVG intégrées directement dans les composants sont recréées nativement
• Les polices importées dans WeWeb sont vérifiées pour leur licence d’utilisation

---

Ce qui nécessite une décision avant la migration

Certains éléments de l’interface WeWeb ne peuvent pas être migrés mécaniquement :

• Animations personnalisées : effets de transition configurés dans WeWeb ; analysés cas par cas pour décider si elles sont reprises, simplifiées ou abandonnées selon leur valeur réelle
• Composants marketplace très spécifiques : si un composant WeWeb tiers n’a pas d’équivalent Vue.js direct, une décision est prise sur le développement d’un composant sur mesure
• Logique de workflow très imbriquée : certains workflows complexes sont l’occasion de repenser la logique métier plutôt que de la reproduire à l’identique

---

Ce qui peut rester dans WeWeb

Si votre organisation utilise WeWeb pour plusieurs projets distincts, la migration ne doit pas forcément être totale :

• Les projets internes non critiques qui fonctionnent bien et n’évoluent pas
• Les prototypes ou démos qui ne sont pas en production active
• Les modules annexes sans logique métier complexe

SmartBooster identifie explicitement ce qui doit migrer et ce qui peut rester lors de l’audit initial.

---

Ce qu’un prestataire sérieux doit faire

Avant de démarrer une migration depuis WeWeb, ces questions permettent d’évaluer la rigueur du prestataire :

• Audit de l’interface existante : cartographie de toutes les pages, composants et workflows avant d’écrire la moindre ligne de code cible.
• Inventaire des collections et APIs : chaque endpoint appelé par WeWeb doit être documenté avant la reconstruction du frontend.
• Environnement de recette dédié : le nouveau frontend est développé et testé dans un environnement isolé, connecté au même backend (Xano ou autre) via un mode staging.
• Tests sur les composants critiques : les composants qui encapsulent de la logique métier (calculs, validations, permissions) doivent être couverts par des tests unitaires.
• Plan de bascule progressif : la migration se fait page par page ou module par module, pas en remplacement total en une seule mise en production.

Chez SmartBooster, ces points font partie du cadrage initial de chaque projet de migration.

---

Références techniques

• Documentation WeWeb : bases de données & API
• Axios : client HTTP pour le navigateur et Node.js
• Pinia : gestion d’état Vue.js
• Vue Router : guards de navigation