SMF·SMARTSUITE
Un prompt peut-il remplacer SmartSuite ?
Bases de données — spreadsheet databases and operational data apps
Bordereau de suivi des pièces
Verdict
SmartSuite se positionne comme de la gestion de travail plutôt qu’un tableur, et la différence qui compte, c’est qu’une fiche traverse un processus : des états, des transitions autorisées, des champs requis avant qu’une transition ne soit permise. Implémenter ça comme une vraie machine à états — plutôt qu’une liste déroulante de statut que n’importe qui peut régler sur n’importe quoi — est un projet vraiment différent des autres outils de base de données ici, et l’appliquer dans l’API et le chemin d’import autant que dans l’interface, c’est là que passent les deux semaines.
Pièce A — Le prompt
Reçu le31.07.2026Construis une application de fiches où chaque table porte un workflow de statut appliqué.
Schéma : tables avec des champs typés en texte, texte long, nombre, date, booléen, liste déroulante simple, liste déroulante multiple, utilisateur, pièce jointe, et lien vers une autre table avec des correspondances et des agrégats.
Le workflow, qui est le cœur de ce projet. Par table, définis :
- Un ensemble d’états, ordonnés, chacun avec une couleur et une catégorie (ouvert, en cours, terminé, annulé).
- Des transitions autorisées comme des paires explicites — de l’état A vers l’état B. Tout ce qui n’est pas listé est interdit. Un champ de statut où n’importe quelle valeur peut être réglée depuis n’importe quelle autre est une liste déroulante, pas un processus.
- Par transition : les champs qui doivent être non vides avant qu’elle ne soit permise, une condition optionnelle sur les propres valeurs de la fiche, et si une note est requise.
- Des effets de bord automatiques optionnels par transition : fixer un champ, tamponner un champ d’horodatage, ou assigner à un utilisateur.
Application partout, pas seulement dans l’interface. Écris des tests pour chaque chemin :
- L’éditeur de fiche n’offre que les transitions permises depuis l’état actuel, et montre quels champs requis bloquent les autres plutôt que de les cacher.
- L’API rejette une transition invalide avec une erreur explicative nommant la règle.
- Un import CSV qui placerait des fiches dans un état où elles ne peuvent légalement pas être est rejeté avec un rapport par ligne, pas accepté silencieusement.
- Une mise à jour en masse sur une sélection filtrée applique la transition par fiche et rapporte quelles fiches ont été sautées et pourquoi, plutôt que de faire échouer tout le lot ou de forcer toutes à passer.
Historique : chaque transition enregistrée avec l’acteur, l’horodatage, l’état de départ, l’état d’arrivée et une note. À partir de cet historique, calcule des métriques de temps de cycle par table — temps moyen dans chaque état, et l’état où les fiches restent le plus longtemps. Cette mesure est la raison de définir un processus tout court et la plupart des outils de cette catégorie ne la font jamais ressortir.
Vues : grille, kanban avec des colonnes comme états où glisser une carte effectue une transition et est refusé avec une explication quand la transition n’est pas permise, calendrier sur un champ date, et une timeline.
Formulaires : un formulaire crée des fiches dans un état initial déclaré, exposant seulement les champs modifiables à cet état.
Tableaux de bord : comptes par table par état, fiches coincées dans un état au-delà d’un seuil, et un graphique de temps de cycle.
Hors périmètre : une bibliothèque de modèles de processus préconstruits, les intégrations tierces, l’édition collaborative en temps réel, les permissions granulaires par champ, et tout déploiement multi-locataire hébergé.L’ouverture pré-remplit le prompt — il ne reste qu’à appuyer sur entrée.
Pièce B — Ce que tu perds
- B.1 la bibliothèque de modèles de processus métier prêts à l’emploi
- B.2 le catalogue d’intégrations qui se connecte à d’autres systèmes
- B.3 la collaboration en temps réel et les permissions d’équipe granulaires
- B.4 l’hébergement géré, les sauvegardes et le support
Alternatives existantes
Pièce C — Pourquoi certains continuent de payer : data model flexibility, collaboration, and integrations
Parce qu’un outil de processus est acheté par une équipe, et sa valeur, c’est que tout le monde suit les mêmes étapes. Une machine à états auto-hébergée avec un seul utilisateur est une liste de tâches personnelle très bien conçue.
Questions
Est-ce que je peux exporter une solution SmartSuite ?
Les fiches s’exportent en CSV par table. La structure de la solution — champs, liens, permissions et toute automatisation — n’a pas d’export portable, donc le schéma et le workflow se reconstruisent à la main. Écrire la machine à états explicitement est généralement un exercice utile en soi.
Pourquoi appliquer les transitions plutôt que d’utiliser une liste déroulante de statut ?
Parce qu’un champ de statut non contraint dérive. Les fiches finissent marquées terminées sans les champs qui rendent « terminé » significatif, et les chiffres de temps de cycle calculés à partir de cet historique ne valent rien. Exiger que la transition soit légale est ce qui rend l’historique fiable.
Combien ça coûte à faire tourner ?
Un VPS avec PostgreSQL, dix à vingt dollars par mois quel que soit le nombre de personnes qui l’utilisent, face à un prix par siège. L’économie grandit avec la taille de l’équipe et se paie en étant la personne qui le maintient.
Quelle est la seule chose qui ne survit pas à la reconstruction ?
Que tout le monde l’utilise. Un outil de processus fonctionne parce que toute l’équipe est dedans, et l’adoption vient des modèles, des intégrations et de quelqu’un d’autre qui garantit que ça reste en marche. Une machine à états correcte que toi seul utilises n’a résolu que la moitié facile.
Outils proches
Récépissé