J’utilise Xano, React et du full-code. Pas besoin de choisir un camp

Xano est un outil de ma stack, pas toute ma stack

J’aime sincèrement Xano.

Pas parce que j’essaie d’éviter le code backend. C’est simplement un outil productif.

Je l’ai utilisé pour des schémas de base de données, des relations, des API REST, des permissions, l’authentification, des triggers, des tâches en arrière-plan, des jobs planifiés, des intégrations et beaucoup de logique métier. (Plus de détails sur ma page Xano, en anglais.)

Et dès que l’application devient plus sérieuse, il faut quand même comprendre ce qui se passe vraiment en dessous.

À un moment, certaines API d’un système de production sur lequel je travaillais pouvaient atteindre 5 à 40+ secondes sous charge.

Il n’y avait pas de bouton magique. Il a fallu regarder le vrai backend.

Certaines requêtes étaient coûteuses. Certains flux faisaient trop d’appels à la base. Certaines jointures étaient plus lourdes que nécessaire. Certains triggers faisaient un travail qui n’avait rien à faire dans la requête.

On a ajouté des index PostgreSQL, y compris des index GIN et géospatiaux, amélioré les requêtes, réduit les appels répétés, ajouté la pagination et déplacé le travail lourd vers des tâches en arrière-plan. Les détails sont dans cet article (en anglais).

Le résoudre demandait toujours de comprendre la base de données et le comportement de l’application.

Ce n’était pas vraiment un problème de low-code. C’était un problème de backend.

Ça peut aller plus loin qu’on ne le pense

Le produit principal sur lequel j’ai travaillé n’était pas un petit MVP.

C’était un ATS/CRM de recrutement avec environ 150K fiches de personnes, à peu près 35K candidats, des milliers de jobs et de projets et des dizaines d’utilisateurs internes.

Il y avait des candidatures, des activités, des entreprises, des opportunités, des permissions, des rapports, des migrations, des workflows IA, du matching de candidats et du traitement en arrière-plan. Il se passait beaucoup de choses dans ce système. (Toute l’histoire dans l’étude de cas Talent Match.)

Et Xano restait utile.

Ça ne veut pas dire que je l’utiliserais pour absolument tout. Non.

Mais je ne pense pas non plus qu’un outil devient peu sérieux juste parce qu’une partie du développement est visuelle. S’il résout bien le problème, tient la charge dont vous avez besoin et que votre équipe peut le maintenir, il fait son travail.

Côté front-end, on a pris une autre décision

Le même produit avait à l’origine son front-end dans WeWeb. Et WeWeb nous a aussi aidés à avancer vite.

Mais avec le temps, l’application est devenue beaucoup plus complexe : beaucoup de formulaires, de filtres, de tableaux de bord, de Kanbans, de permissions, de workflows interconnectés et d’état à gérer.

Finalement, on a reconstruit tout le front-end de production en React 19 + TypeScript. Progressivement, pas d’un seul coup :

Pour cette étape du produit, je pense que c’était la bonne décision.

On a gagné un contrôle beaucoup plus direct sur le code. On a pu standardiser proprement avec TanStack Query, React Hook Form, Zod, React Router, des composants réutilisables et TypeScript. Le front-end est devenu une base de code que les développeurs pouvaient comprendre directement. (Plus sur mon travail React.)

Personnellement, pour un gros front-end que je compte faire évoluer, c’est la direction vers laquelle je pencherais aujourd’hui.

Mais je ne regarde pas WeWeb en me disant que c’était une erreur. Il nous a fait avancer vite. Puis les besoins ont changé. Alors la stack a changé aussi.

C’est normal.

L’IA rend le changement beaucoup plus facile

C’est la partie que je trouve la plus intéressante.

Passer du low-code au full-code est bien plus facile aujourd’hui qu’il y a quelques années.

Pendant la migration React, j’ai beaucoup utilisé Claude Code. Il a aidé pour l’implémentation répétitive, le refactoring, repérer des patterns dans le code et transformer plus vite le comportement existant en composants React. Ça a clairement réduit beaucoup de travail mécanique.

Je pense que c’est pareil pour le backend aujourd’hui. Si un jour je dois déplacer une partie d’un système vers Node.js, l’IA peut aider pour le scaffolding, les types, les endpoints répétitifs, les tests, les refactorings et plein de parties ennuyeuses.

Mais il y a une grande différence entre écrire du code plus vite et comprendre un système.

L’IA ne sait pas automatiquement pourquoi une règle de permission bizarre existe. Elle ne sait pas quel cas limite a causé un bug en production il y a six mois. Elle ne sait pas de quel comportement les utilisateurs dépendent, même si personne ne l’a documenté.

Ça vient toujours de la compréhension du produit. (Le côté IA de mon travail est sur ma page intégration IA.)

L’IA rend la migration moins chère. Elle ne rend pas la décision automatique.

Plus facile à réécrire ne veut pas dire que ça vaut la peine

C’est sûrement la plus grande leçon que j’ai tirée en travaillant avec les deux.

C’est très facile aujourd’hui de regarder un système existant et de se dire : « On pourrait reconstruire ça. »

Et oui, peut-être. Mais faut-il le faire ?

$ ./should-we-rewrite
  utilisateurs contents ?    oui
  performances correctes ?   oui
  l’équipe peut maintenir ?  oui
  vraie raison ?             « plus propre »
→ verdict : ne pas réécrire (pour l’instant)

Si le système actuel fonctionne, que les utilisateurs sont contents, que les performances sont bonnes et que votre équipe peut le maintenir, le réécrire juste parce que le full-code fait plus propre peut vite devenir du travail perdu.

On peut passer des mois à reconstruire ce que les utilisateurs avaient déjà. On peut introduire de nouveaux bugs. On peut oublier d’anciennes règles métier. On peut finir avec une plus belle architecture et presque aucune valeur en plus pour le produit.

Je préfère migrer pour une vraie raison. Pas parce que je veux une stack qui a l’air plus cool.

J’utiliserai sûrement plus Node.js aussi

Je ne vois pas mon avenir comme « Xano pour toujours ».

Il y a clairement des projets où je préfère maîtriser le backend directement : des services sur mesure, des bibliothèques spécifiques, des tests plus poussés, plus de contrôle sur le déploiement ou l’exécution, ou une architecture qui colle mieux à un backend classique. Dans ces cas, quelque chose comme Node.js a du sens.

Et j’ai envie de travailler davantage avec ce type de stack. React + Node.js + PostgreSQL, je me vois tout à fait construire avec.

Mais ça ne veut pas dire que je dois arrêter Xano. Si je peux livrer un backend plus vite avec Xano et que le projet s’y prête, je l’envisagerais sérieusement.

Les deux peuvent être vrais.

Xano est un outil de ma stack, pas toute ma stack.

Les stacks hybrides ont beaucoup de sens pour moi

En fait, je pense que c’est là que ça devient intéressant. On n’a pas à prendre une seule décision pour tout le produit.

Ça me paraît complètement normal.

Utilisez l’outil de plus haut niveau là où il vous fait gagner du temps. Le full-code là où vous avez besoin de contrôle. Et ne réécrivez pas ce qui marche déjà juste parce que vous pouvez. (Côté base de données, c’est le travail que je décris sur ma page performance PostgreSQL.)

Alors, quand est-ce que je quitterais vraiment le low-code ?

Sûrement quand je passerai plus de temps à me battre contre la plateforme qu’à en profiter.

Là, oui, je migrerais. Mais je voudrais que la décision vienne du produit, pas de l’ego.

Où j’en suis aujourd’hui

Je suis développeur full-stack. J’aime React et TypeScript. J’aime travailler directement avec PostgreSQL et des API. J’utiliserai très probablement davantage Node.js et d’autres technologies backend full-code.

Et j’aime toujours Xano. Je ne pense pas que tout ça soit contradictoire.

Xano est un outil de ma stack. Le full-code me donne un autre niveau de contrôle quand j’en ai besoin. L’IA rend le passage de l’un à l’autre plus facile que jamais.

Donc je ne me demande pas vraiment « Le low-code est-il meilleur que le full-code ? » Je préfère me demander : « Qu’est-ce que je devrais vraiment utiliser pour cette partie du produit ? »

Parfois la réponse sera Xano. Parfois Node.js. Parfois React. Parfois WeWeb. Parfois un mélange de tout ça.

Tant que je comprends ce que je construis et pourquoi je choisis l’outil, ça compte beaucoup plus pour moi que de choisir un camp.