Ce que WeWeb fait très bien
WeWeb construit des interfaces applicatives sans écrire de code, en se branchant sur un back-end existant : une base Supabase, une API REST, un service no-code. Il se distingue des constructeurs de sites par son terrain : il vise l'application, pas la vitrine.
Pour un outil interne à sortir vite, c'est efficace. Un tableau de bord, un écran de saisie, une liste filtrable se montent en quelques jours, sans mobiliser de développeur front-end. Quand l'alternative est un fichier de tableur partagé, le gain est incontestable.
Où la complexité rattrape l'outil
Le plafond n'est pas visuel, il est logique. Une interface applicative sérieuse gère des états : chargement, erreur, données partielles, permissions différenciées, formulaire à moitié rempli, action optimiste annulée. En React, ces états se nomment, se composent et se testent. Dans un éditeur visuel, ils s'empilent en conditions jusqu'à ce que plus personne ne sache pourquoi un bouton reste grisé.
Le deuxième plafond est le travail à plusieurs. Sans branches, sans revue de code et sans historique exploitable, deux personnes ne peuvent pas travailler sereinement sur la même application. C'est une limite d'organisation, pas de technologie, et elle apparaît dès la deuxième personne.
Le troisième est l'accessibilité. Elle dépend entièrement des composants fournis par la plateforme. Si votre organisation est soumise au référentiel d'accessibilité, vous ne pouvez pas garantir un résultat que vous ne contrôlez pas.
Ce que React apporte, et ce qu'il coûte
React ne fait rien de magique : c'est une bibliothèque d'interface, et il faut des développeurs pour s'en servir. Ce qu'il apporte est ailleurs. Un composant est une unité testable. Une bibliothèque de composants documentée avec Storybook se partage entre produits. Une régression est détectée par Playwright avant la mise en production, pas par un utilisateur.
Le coût est réel : plus long à démarrer, plus cher à l'heure, et il faut une équipe. C'est exactement ce qui rend la comparaison intéressante, parce que le bon choix dépend de la durée de vie prévue de l'interface.
Le critère décisif : combien de temps cet écran va-t-il vivre
Un outil interne utilisé six mois par cinq personnes ne mérite pas une équipe front-end. Un produit que vos clients utilisent tous les jours ne mérite pas un éditeur visuel.
Entre les deux, la question à poser est celle du coût de la modification. Si l'écran va évoluer chaque mois pendant trois ans, la lisibilité et la testabilité du code deviennent le facteur dominant, bien avant le délai initial. Si l'écran est figé et remplaçable, l'argument s'inverse.
Nous voyons régulièrement des applications WeWeb qui auraient dû rester des prototypes et sont devenues critiques sans jamais avoir été industrialisées. Le problème n'est pas l'outil, c'est l'absence de décision au moment où le statut de l'application a changé.
