No-Code
Du MVP à la plateforme : Xano, Weweb & Retool en pratique
Xano, Weweb et Retool permettent de livrer une plateforme métier en quelques semaines. Le piège est de les choisir pour leur vitesse et d'oublier la suite. Voici comment je répartis les rôles et ce que je fixe dès le départ pour que le MVP puisse grandir.
Trois outils, trois rôles
La confusion la plus courante consiste à mettre de la logique un peu partout. Je donne à chaque outil un rôle unique, et je m'y tiens.
| Outil | Rôle | Utilisateurs | Ce qu'il fait bien |
|---|---|---|---|
| Xano | Backend : base de données, API, logique, tâches planifiées | Personne directement | Endpoints REST, règles métier, authentification |
| Weweb | Interface client | Clients, partenaires | Interface sur mesure, connexion native à Xano |
| Retool | Back-office interne | Équipe | Tableaux, formulaires et actions d'administration en quelques heures |
Commencer par le modèle de données
Avant d'ouvrir un éditeur visuel, je pose le modèle de données sur une page. C'est la décision la plus coûteuse à changer une fois la plateforme en service.
- Les entités et leurs relations (client, contrat, mission, facture...)
- Les statuts possibles de chaque entité et les transitions autorisées
- Qui peut lire, créer, modifier ou supprimer quoi
- Les données qui viennent d'outils externes, et leur fréquence de mise à jour
Toute la logique dans Xano
Ma règle : le front affiche, le back décide. Calcul de prix, vérification des droits, changement de statut, envoi d'e-mail : tout se passe dans un endpoint Xano. Weweb et Retool appellent les mêmes endpoints, il n'existe donc qu'une seule version des règles.
Le jour où une application mobile ou un partenaire doit se brancher, l'API est déjà là et déjà testée.
Authentification et droits
Xano gère l'authentification par jeton. Le point d'attention est ailleurs : masquer un bouton dans Weweb ne protège rien. Chaque endpoint vérifie lui-même le rôle de l'utilisateur et son droit sur la ressource demandée.
Environnements et mises en production
Je sépare au minimum un environnement de test et un environnement de production, des deux côtés. Les modifications de l'API se testent sur des données de test, puis passent en production avec le front qui les utilise. Sans cette séparation, chaque correctif se fait directement sous les yeux des clients.
Quand le no-code atteint ses limites
Ces outils couvrent la grande majorité des plateformes métier. Certains signes indiquent qu'un module mérite d'en sortir :
- des calculs lourds ou longs sur de gros volumes ;
- des besoins de temps réel poussés ;
- des contraintes d'hébergement ou de conformité spécifiques.
Le découpage type d'un MVP
- Cadrage et modèle de données
- API Xano et règles métier
- Back-office Retool pour l'équipe
- Interface client Weweb
- Tests avec de vrais utilisateurs
- Mise en production et suivi
Le back-office arrive avant l'interface client : l'équipe peut saisir et vérifier les données réelles pendant que le front se construit.
Checklist
- Le modèle de données est écrit et validé avant de construire
- Toute règle métier vit dans un endpoint Xano
- Chaque endpoint vérifie les droits de l'utilisateur
- Les environnements de test et de production sont séparés
- Les modules hors limites sont identifiés tôt
Travaillons ensemble
Un projet similaire à mettre en place ?
Décrivez-moi votre contexte en quelques lignes. Je vous réponds sous 24 h avec une première analyse et les prochaines étapes.
Me contacter