SMF·STACKBY
Un prompt peut-il remplacer Stackby ?
Bases de données — spreadsheet databases and operational data apps
Bordereau de suivi des pièces
Verdict
Le type de colonne distinctif de Stackby appelle une API par ligne : colle cent URL de vidéo, obtiens cent compteurs de vues. Ce catalogue a déjà une fiche pour la version tableur de cette idée, et la version table est un problème d’ingénierie différent — cent mille lignes veut dire gestion de quota, planification de rafraîchissement par ligne et gestion d’échec partiel, rien de tout ça dont un tableur avec deux cents cellules n’a à se soucier. Bien faire ça, c’est quelques jours et c’est toute la raison de le construire.
Pièce A — Le prompt
Reçu le31.07.2026Construis une base de données de fiches dont la fonctionnalité distinctive est un type de colonne adossé à une requête HTTP, conçu pour fonctionner à des milliers de lignes.
Schéma de base : tables avec des champs typés en texte, nombre, date, booléen, liste déroulante simple, liste déroulante multiple, pièce jointe, lien vers une autre table, formule, et colonne API.
La colonne API, qui est le cœur de ce projet. Sa définition contient :
- Une connexion nommée (URL de base, méthode d’authentification, identifiants chiffrés au repos, et une limite de débit et un quota déclarés).
- Un modèle de requête avec des placeholders référençant d’autres champs de la même ligne.
- Un chemin de réponse sélectionnant la valeur à stocker (un pointeur JSON), plus un type vers lequel la convertir.
- Une durée de vie de cache, après laquelle une valeur est considérée périmée.
- Une politique de rafraîchissement : manuel, au changement de ligne, ou planifié.
Fonctionner à l’échelle, ce qui sépare ça de la version tableur de l’idée :
- Un limiteur de débit partagé à seau de jetons par connexion, respecté à travers chaque colonne et chaque ligne utilisant cette connexion. Rafraîchir trois colonnes API sur dix mille lignes ne doit pas dépasser la limite du fournisseur ni épuiser un quota quotidien avant midi.
- Une file de rafraîchissement avec progression visible, pause et annulation, traitant les lignes par lots et persistant après chaque lot pour qu’une interruption ne perde rien.
- État par cellule : fraîche, périmée, en rafraîchissement, ou échouée avec le message d’erreur propre du fournisseur stocké. Une cellule échouée garde sa dernière valeur réussie et montre les deux, parce qu’une table qui vide une colonne sur un 429 transitoire est pire qu’une table qui montre honnêtement un ancien chiffre.
- Comptabilité de quota par connexion : requêtes utilisées aujourd’hui et ce mois-ci par rapport à la limite déclarée, montrée avant le début de tout rafraîchissement en masse, avec le coût projeté de ce rafraîchissement en requêtes.
- Rafraîchissement conditionnel : seulement les lignes correspondant à un filtre, pour que la colonne coûteuse puisse être rafraîchie pour les cinquante lignes qui comptent plutôt que les dix mille.
Honnêteté sur la péremption : chaque colonne API montre l’âge de ses valeurs dans l’en-tête de colonne, et une vue peut être filtrée sur les lignes dont les valeurs sont périmées. Des données récupérées il y a trois semaines présentées comme actuelles sont le mode d’échec de tout outil de ce genre.
Vues : grille, kanban, galerie, avec filtres et tris enregistrés. Les champs formule peuvent référencer les valeurs de colonnes API.
Construis aussi : import et export CSV, une API REST par-dessus les tables elles-mêmes, et des sauvegardes planifiées.
Hors périmètre : un catalogue de connecteurs préconstruits, l’édition collaborative en temps réel, un constructeur d’automatisation, et tout déploiement multi-locataire hébergé. Note dans le README que la fiche tableur-avec-formules-API de ce catalogue couvre la version à petite échelle de la même idée et pourrait mieux convenir en dessous de quelques centaines de lignes.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 le catalogue de connecteurs d’API prêts à l’emploi
- B.2 la collaboration en temps réel dans la même table
- B.3 l’écosystème d’automatisation et d’intégration
- B.4 l’hébergement géré et les sauvegardes
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : data model flexibility, collaboration, and integrations
Parce que les connecteurs sont le produit. Écrire une colonne d’API contre un fournisseur, c’est un après-midi ; en avoir quarante déjà écrites, authentifiées et maintenues, c’est une entreprise.
Questions
Est-ce que je peux importer ma base Stackby ?
Les tables s’exportent en CSV, donc les données passent bien. Les définitions de colonnes API ne s’exportent pas, donc chaque connexion et modèle de requête se recrée — ce qui est le vrai travail, et représente environ une heure par API en incluant la lecture de sa documentation.
En quoi c’est différent de la version tableur ?
L’échelle change entièrement le problème. Deux cents cellules formule qui appellent une API n’ont besoin ni de comptabilité de quota, ni de file de rafraîchissement, ni de gestion d’échec partiel. Dix mille lignes ont besoin des trois, et se tromper dessus veut dire soit un quota grillé, soit une table pleine de vides après un mauvais après-midi.
Combien ça coûte à faire tourner ?
Un VPS avec PostgreSQL, dix à vingt dollars par mois, plus ce que facturent les API auxquelles tu te connectes. Le second terme est celui à surveiller : un rafraîchissement horaire planifié sur dix mille lignes, c’est 240 000 requêtes par jour, ce qui représente une facture sur la plupart des API.
Quelle est la seule chose qui ne survit pas à la reconstruction ?
Le prochain connecteur. Ta première colonne API marche bien et le second fournisseur a une authentification différente, une pagination différente et un style d’erreur différent. Le produit de Stackby, c’est que le second est une liste déroulante.
Outils proches
Récépissé