Alternative WeWeb / GUIDE DE MIGRATION
Exporter votre projet depuis WeWeb
WeWeb ne stocke pas de données métier : il stocke des composants d'interface, des liaisons aux données et de la logique de workflow. Ce guide détaille la structure d'un projet WeWeb, ce qui peut être analysé automatiquement et ce qui nécessite une reconstruction en Vue.js natif.
LES DONNÉES
Ce que nous migrons depuis WeWeb
Quitter WeWeb ne signifie pas perdre vos données. Voici les types de données que SmartBooster analyse, extrait et migre vers votre logiciel sur mesure.
- Pages et routes : Arborescence des écrans et configuration du routeur. Recréée en Vue Router natif avec les guards d'authentification et les paramètres de route.
- Composants et mise en page : Éléments d'interface configurés dans l'éditeur visuel : grilles, cartes, tableaux, formulaires. Analysés et reconstruits en composants Vue.js autonomes et réutilisables.
- Collections de données : Liaisons aux APIs (Xano ou autres) définies dans WeWeb. Remappées en appels structurés avec Axios dans des services centralisés, état géré dans Pinia
- Variables et état global : Stores WeWeb (variables globales et locales). Migrés en stores Pinia typés, avec persistance si nécessaire.
- Workflows et actions : Logique événementielle définie dans l'éditeur : actions au clic, soumission de formulaire, navigation conditionnelle. Réécrite en composables Vue.js testables.
- Authentification et rôles : Configuration des sessions, des routes protégées et des rôles utilisateur. Reconstruite avec la stack d'authentification cible (JWT, sessions, OAuth).
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(.*)* |
Analyse des composants et de la 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.
Analyse des 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
Analyse des 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.
Analyse des 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,sessionStorageou 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 depuis WeWeb
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 doit maîtriser pour migrer depuis WeWeb
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 WeWeb
RENDEZ-VOUS DÉCOUVERTE GRATUIT
30 minutes, gratuites, sans engagement
Décrivez votre besoin directement à Nicolas. On écoute votre situation et on vous dit si et comment on peut vous aider.
Appel de 30 min → Analyse gratuite → Proposition sous 5 jours
Pour aller plus loin
Approfondir votre réflexion
Découvrez pourquoi un logiciel sur mesure peut remplacer WeWeb et comment SmartBooster accompagne cette transition.
Symfony, Vue.js, Clever Cloud : les technologies que nous utilisons pour développer des logiciels robustes et maintenables.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.