Rowy Review 2026 : analyse complète du backend low-code pour Firestore

Firebase fournit à une application presque tout : authentification, stockage de fichiers, base de données et fonctions serverless. Ce qu’il ne fournit pas, c’est un moyen raisonnable de consulter ses propres données et de les corriger à la main. Dès qu’un projet dépasse le « hello world », l’éditeur Firestore de la console Google Cloud devient une punition : les documents s’ouvrent un par un, l’édition en masse est impossible, et mieux vaut ne pas y laisser entrer un rédacteur ou un agent de support.

Rowy s’attaque précisément à ce problème. C’est un backend low-code open source qui affiche vos collections Firestore sous forme de tableur classique, à la Airtable, et permet d’écrire de la logique serveur en TypeScript depuis le navigateur, sur le même écran. Les données restent dans votre propre projet Google Cloud et ne partent pas dans le SaaS d’un tiers.

Dans ce test, nous regardons comment Rowy est construit, ce qu’il sait faire en 2026, où ça coince, et si 12 dollars par siège est un prix juste — ou s’il faut aller directement vers des alternatives auto-hébergées.

Qu’est-ce que Rowy

Rowy est une interface web au-dessus de Firebase et Google Cloud. L’architecture est simple : Rowy ne stocke pas vos données. Il se connecte à votre projet GCP, lit vos collections Firestore et les affiche en tableau. Chaque action — modifier une cellule, téléverser un fichier, déclencher une fonction — s’exécute au nom de votre projet, et non via un intermédiaire Rowy.

Deux conséquences en découlent :

1. Vous gardez la pleine propriété des données. Vous choisissez la région de stockage, vous assumez le RGPD, vous payez GCP pour les lectures et le trafic. Rowy ne devient jamais sous-traitant de vos données.
2. Le coût comporte deux parties — l’abonnement Rowy et la facture Google Cloud. À faible volume, la seconde tient dans le palier gratuit, mais elle ne disparaît jamais.

Le produit existe sous deux formes : l’application hébergée sur rowy.io et un dépôt GitHub ouvert que vous pouvez déployer dans votre propre projet. L’équipe revendique plus de 30 000 utilisateurs et environ 6 800 étoiles GitHub. Une nuance importante : le dépôt a migré vers l’organisation buildship-ai et la dernière activité dans le code ouvert date de fin 2024 — l’équipe se concentre désormais sur BuildShip.

À noter aussi BuildShip, la plateforme low-code pour API, tâches planifiées et workflows que la même équipe pousse comme produit distinct. C’est sa réponse à « il nous faut des traitements en arrière-plan, pas seulement des données », et cela montre la direction de toute la gamme : du tableau avec fonctions vers un constructeur de backend complet.

Points forts et points faibles

Ce qui convainc

• Un tableur au lieu de la console Firestore. Tri, filtres, opérations en masse, collage depuis le presse-papiers : tout ce qui manque à l’éditeur natif depuis des années.
• Plus de 30 types de champs et des champs dérivés qui se recalculent dès que les données sources changent.
• Cloud Functions dans l’interface. TypeScript sur la même page que les données, avec accès à n’importe quel paquet npm.
• Vos données dans votre projet GCP. Aucune migration et aucune dépendance si vous quittez la plateforme.
• Palier gratuit sans limite de fonctions ni d’appels API. C’est rare : la plupart des concurrents brident justement cela.
• Contrôle d’accès pour les non-développeurs. Rôles au niveau des champs et audit au niveau des lignes : qui a modifié quoi et quand.
• Open source. Le code peut être lu, forké et modifié ; la licence ne bloque pas l’usage commercial.

Ce qui agace

• Verrouillage strict sur Firestore. Si vous tournez sur PostgreSQL, MySQL ou Supabase, ce n’est pas votre outil et il n’y a pas de contournement.
• Un projet Google Cloud avec facturation activée est nécessaire pour les fonctions et plusieurs intégrations : charge administrative supplémentaire pour une petite équipe.
• Un seul projet dans l’offre gratuite. Un deuxième projet impose Pro, facturé par siège.
• Le produit glisse vers BuildShip. L’attention de l’ingénierie est partie vers le nouveau produit, et le changelog le confirme : moins de versions du cœur.
• L’interface est dense. Un débutant voit des dizaines de champs, d’extensions et de réglages et passe la première demi-heure à cliquer sans comprendre.
• Pas de client mobile. Navigateur uniquement.

Les fonctions en détail

Le tableau de données

L’écran d’accueil est une grille très proche d’Airtable. Les colonnes correspondent aux champs des documents Firestore, les lignes aux documents. Les types vont des chaînes et nombres aux fichiers, images, références vers d’autres collections, coordonnées géographiques, JSON, tableaux et dates avec fuseau horaire.

Tout ce qui manque à la console fonctionne ici : sélection de plages avec collage depuis Excel, duplication de lignes, édition au double-clic, recherche dans la collection, filtres multi-conditions et vues enregistrées. Les grosses collections bénéficient de la pagination et du rendu virtualisé, donc le tableau ne se fige pas sur des dizaines de milliers de documents.

Les champs dérivés sont le héros discret. Le cas classique est un champ total recalculé à partir de price × qty à chaque modification. La logique vit dans la configuration du champ au lieu d’être éparpillée entre client et serveur, ce qui réduit nettement les désynchronisations propres aux projets Firestore.

Les champs d’action sont des boutons dans une ligne qui déclenchent votre fonction : le schéma « un clic pour confirmer une commande / envoyer un e-mail / reconstruire un index », qui fait gagner des heures aux équipes opérationnelles.

Cloud Functions

Rowy permet d’écrire des cloud functions TypeScript dans un éditeur Monaco intégré, avec coloration, autocomplétion et n’importe quel paquet npm. Une fonction est liée à une collection et à un déclencheur : document créé, mis à jour, supprimé, ou appel manuel depuis un champ d’action.

En pratique, c’est l’argument le plus fort de Rowy. Dans un projet Firebase classique, ajouter un déclencheur suppose de monter un environnement local, d’installer la CLI Firebase, d’écrire la fonction dans un dépôt séparé, de la déployer et de penser à redéployer ensuite. Dans Rowy, le cycle est : ouvrir la collection, ajouter la fonction, enregistrer. Pour des tâches comme « envoyer un e-mail au changement de statut » ou « journaliser dans une table analytique », ce cycle court s’amortit vite.

Des limites existent. Le débogage est plus faible qu’un déploiement classique — pas d’exécution locale, pas de points d’arrêt —, donc on débogue par les logs. Les dépendances se gèrent via package.json dans l’interface : pratique pour une ou deux bibliothèques, brouillon avec dix fonctions partageant des modules.

Webhooks et extensions

Les webhooks font entrer les données : formulaire du site, événement d’un prestataire de paiement, réponse d’une API externe. Rowy fournit une URL, vous envoyez un POST JSON, un document apparaît dans la collection. C’est le moyen le plus rapide de relier une landing page à une base sans serveur dédié.

Les extensions font sortir les données : SendGrid pour l’e-mail, Slack et WhatsApp pour les notifications, Algolia et Typesense pour la recherche plein texte. Chacune se configure en quelques champs et fonctionne comme un abonnement en arrière-plan aux changements de collection.

Un flux testé de bout en bout : un lead du formulaire arrive au webhook → le document entre dans leads → un champ dérivé le note selon la taille de l’entreprise → une fonction envoie l’e-mail via SendGrid et la notification Slack → Algolia indexe l’enregistrement pour la recherche du back-office. Le tout sur un seul écran, sans une ligne de code d’infrastructure.

Droits et audit

Essentiel pour les équipes : les non-développeurs accèdent aux données sans gagner de pouvoirs supplémentaires. Les rôles se règlent par table et par champ : un rédacteur peut changer status mais pas price. L’audit au niveau des lignes (créé par, modifié par, horodatages) est inclus dans l’offre gratuite ; l’audit au niveau des champs et les sauvegardes relèvent de Business.

Une limite : la gestion des utilisateurs passe par Firebase Auth, donc Rowy ne remplace pas un SSO d’entreprise. Si votre politique exige une connexion uniquement via Okta, c’est bloquant : il faudra relier Firebase à un fournisseur externe séparément.

Tarifs

• Base — 0 $. Un projet, collections et enregistrements illimités, cloud functions illimitées, appels API illimités sans limitation de débit, plus de 30 types de champs, import/export CSV/TSV/JSON, audit au niveau des lignes, rôles, accès à la communauté Discord.
• Pro — 12 $ par siège et par mois (10 % de remise en paiement annuel). Projets illimités, recherche plein texte, export au-delà de 10 000 lignes, filtres avancés, clonage de code entre projets, plafond de facturation GCP strict, support par e-mail. Un mois d’essai gratuit.
• Business — sur devis. Tout Pro plus domaine personnalisé, support prioritaire, versionnement des données, audit au niveau des champs, sauvegardes automatiques et formulaires.

Le point que beaucoup oublient : 12 $ n’est pas la facture complète. Les frais Google Cloud s’y ajoutent. Sur un petit projet, ils restent souvent à zéro — Firestore offre un palier gratuit généreux en lectures et écritures, Cloud Functions 2 millions d’invocations par mois — mais des collections actives et des déclencheurs fréquents font grimper la note, et personne ne la surveille pour vous. En Pro, activez le plafond de facturation GCP immédiatement.

L’économie est simple : si Rowy fait gagner une journée de développement d’un back-office à un développeur, ou retire à un ingénieur la routine de correction des données, les 12 $ sont amortis instantanément. Un développeur solo peut réellement exploiter un projet en production avec le palier Base gratuit.

Notre test

Nous avons déployé Rowy sur un projet Firebase de test avec une collection de commandes (environ 12 000 documents, 18 champs, dont une référence vers une collection de clients et un tableau de lignes de commande), en observant trois choses : la réactivité de l’interface, le comportement des fonctions et la prise en main par un non-technicien.

Installation. L’assistant web s’en charge : connexion Google, choix du projet, attribution des rôles au compte de service, initialisation des collections Rowy. Le premier lancement prend une dizaine de minutes, l’essentiel partant en facturation et IAM plutôt qu’en produit.

Le tableau. À 12 000 documents, l’interface est restée fluide : défilement souple, filtres appliqués avec un délai perceptible mais tolérable, car chaque requête part vers Firestore et est facturée comme lecture. Le collage de 200 lignes CSV s’est terminé sans erreur mais a pris nettement plus longtemps qu’un tableur local : c’est le prix du modèle serverless, pas un bug de Rowy. Modifier un champ sur 500 documents a demandé plusieurs passes : une partie du lot a heurté les limites d’opérations par lot de Firestore.

Fonctions. Un déclencheur sur changement de statut envoyant un e-mail via SendGrid a fonctionné au deuxième enregistrement — la première version échouait sur un paquet manquant, car les dépendances s’ajoutent à la main dans package.json. Stable ensuite. Les logs se lisent dans l’interface, mais confirment que le débogage est le point faible : sans émulateur local, le cycle « enregistrer et lire le log » finit par lasser.

Un non-développeur. Un rédacteur sans bagage technique a maîtrisé les filtres et l’édition de champs en une vingtaine de minutes : probablement le meilleur signal du produit. Les restrictions par champ ont fonctionné comme prévu : un champ interdit n’est simplement pas éditable.

Bilan du test : Rowy supprime réellement la routine autour de Firestore, mais ne transforme pas Firebase en base relationnelle et ne fait pas de miracle sur les opérations en masse.

Alternatives

• Airtable — plus joli et plus simple, mais les données vivent chez Airtable et non chez vous, et les tarifs équipe piquent. Rowy gagne sur la propriété des données et la logique backend.
• Retool — plus fort sur les outils internes (formulaires, tableaux de bord, dizaines de composants), mais ce n’est ni un CMS de données ni un remplaçant du back-office Firestore. Les deux se complètent souvent.
• NocoDB et Baserow — frontends tableur open source pour bases SQL (PostgreSQL, MySQL). Si votre stack n’est pas Firebase, regardez par là.
• Un back-office maison en React Admin — flexible et gratuit, mais des semaines de travail et une maintenance perpétuelle. Rowy revient moins cher tant que les tâches restent standard.

Pour qui

À acheter si : vous êtes sur Firebase/Firestore, vous avez des données opérationnelles (commandes, leads, catalogue, utilisateurs) à éditer régulièrement, et surtout si des non-développeurs doivent y accéder sans back-office sur mesure. Bon signe : vous vous surprenez déjà à ouvrir la console GCP pour corriger un champ et à y perdre cinq minutes pour une tâche de cinq secondes.

À éviter si : votre base n’est pas Firestore ; il vous faut un SSO d’entreprise clé en main ; vous prévoyez de l’analytique lourde et de l’ETL massif — c’est BigQuery et des outils spécialisés. Réfléchissez à deux fois si la prévisibilité du produit compte : le focus de l’équipe est passé à BuildShip.

Cas intermédiaire : une startup partie sur Firebase et qui migre doucement vers PostgreSQL. Rowy n’aide pas : il ne facilite pas la migration et devient inutile ensuite. En faire une base d’administration durable n’a de sens que si Firestore reste votre base principale un an ou deux.

Verdict

Rowy est un outil étroit et très affûté. Il ne cherche pas à être une plateforme low-code universelle et ne se bat pas avec Retool sur les tableaux de bord ; il bouche un trou précis de Firebase — l’absence d’interface humaine pour les données — et le fait proprement.

Forces : le tableau, les champs dérivés et d’action, les fonctions TypeScript intégrées, la pleine propriété des données. Faiblesses : Firestore uniquement, débogage des fonctions limité, et concurrence croissante de BuildShip pour l’attention de l’équipe.

Pour un projet Firebase où les données sont éditées à la main plus d’une fois par semaine, le palier Base gratuit couvre l’essentiel, et Pro à 12 $ par siège est raisonnable pour des projets illimités et la recherche plein texte. Pour tous les autres stacks, Rowy n’est simplement pas le bon outil — et il ne l’a jamais prétendu.

Note : 8 sur 10 — un excellent outil spécialisé, avec un modèle tarifaire honnête et une limite importante : une seule base de données prise en charge.