AppSheet coûte 5–20 $ par utilisateur et par mois — mais le vrai problème est invisible : sa configuration à base de clics ne peut pas être pilotée par un agent IA. Sortie vers le config-as-code.

Résumé

Question	Réponse courte
Combien coûte AppSheet pour une vraie équipe ?	15 utilisateurs en Core ≈ 150 $/mois (1 800 $/an) ; 25 utilisateurs en Enterprise Plus ≈ 500 $/mois (6 000 $/an)
Le paiement par utilisateur est-il le vrai problème ?	Non — gérable à 10 utilisateurs, douloureux à 25+
Quel est le problème que personne ne chiffre ?	Chaque modification est un travail manuel dans l’interface — pas de config-as-code, donc aucun agent IA ne peut exploiter votre app pour vous
Quand AppSheet reste-t-il pertinent ?	≤10 utilisateurs, flux standard, quelqu’un en interne aime en être le propriétaire

Les tarifs AppSheet sont publics et simples : Starter 5 $, Core 10 $, Enterprise Plus 20 $ par utilisateur et par mois (tarifs, août 2026), avec le prototypage gratuit jusqu’à 10 utilisateurs. Mais deux coûts n’entrent jamais dans la comparaison d’abonnements : la dérive des sièges à mesure que l’équipe grandit, et le goulot d’étranglement de maintenance apparu en 2026 — l’année où presque tout autre type de logiciel est devenu maintenable par IA. Sauf le vôtre.

(Une nuance avant les calculs : si vous avez une édition payante de Google Workspace, vérifiez quelles éditions incluent AppSheet Core — certaines l’intègrent. Cela change la donne pour les utilisateurs de votre équipe disposant de ces licences.)

Le calcul des sièges, mené honnêtement

Équipe	Niveau réellement nécessaire	Mensuel	Par an	Sur 3 ans
5 utilisateurs	Starter	25 $	300 $	900 $
10 utilisateurs	Core	100 $	1 200 $	3 600 $
15 utilisateurs	Core	150 $	1 800 $	5 400 $
25 utilisateurs	Enterprise Plus	500 $	6 000 $	18 000 $
40 utilisateurs	Enterprise Plus	800 $	9 600 $	28 800 $

Deux choses se cachent dans ce tableau :

• Vous restez rarement sur Starter. Il manque les contrôles de sécurité et la gestion des apps — dès que les rôles ou la propriété des données comptent, vous êtes sur Core.
• Les API et les vraies bases de données relèvent d’Enterprise Plus. Connecter AppSheet à PostgreSQL ou à des services externes vit dans la tranche à 20 $. Si vos données débordent Sheets (c’est pourquoi vous lisez ceci), c’est la tranche qui vous attend.

À 25 utilisateurs, vous payez 18 000 $ sur trois ans pour le droit d’utiliser la plateforme — avant même de comptabiliser le temps de quiconque. Et le temps de quelqu’un est le coût suivant.

Le problème de 2026 : votre app ne peut pas être pilotée par un agent

Voici ce qui a changé récemment, et pourquoi c’est plus important que le calcul des sièges.

Presque toute autre forme de logiciel métier est devenue maintenable par agent : si votre système est une base de code normale, vous pouvez dire à un agent IA « modifie la règle d’approbation des remises pour exiger un signalement manager au-delà de 500 $ » — et l’agent lit le code, effectue une petite modification vérifiable, et met à jour les tests. Des minutes de travail, sans développeur salarié.

AppSheet n’a aucun chemin équivalent. Sa configuration — tables, slices, bots, comportements, filtres de sécurité, colonnes virtuelles — vit dans un éditeur web qu’on pilote en cliquant. Pas de config-as-code, pas de CLI, pas d’API pour modifier l’application elle-même. Donc quand vous demandez à une IA de modifier votre app AppSheet, la réponse honnête est : elle ne peut pas. Un humain doit ouvrir l’éditeur, naviguer vers le bon écran parmi des dizaines, éditer l’expression, enregistrer et tester sur un appareil. Multipliez par chaque demande de changement que génère votre entreprise.

Le résultat est le schéma que je ne cesse de rencontrer : un office manager qui « connaît l’app » et s’est discrètement mué en développeur non reconnu — chaque évolution de flux passe par son calendrier. La plateforme se vend comme no-code ; la réalité opérationnelle est du code par clics, et les clics ne passent pas à l’échelle et ne se délèguent pas à un logiciel.

Ce que j’en ai fait : la config AppSheet en code lisible par agent

J’ai récemment migré une configuration AppSheet complexe — du genre bâtie pendant des années, avec des slices, bots et filtres de sécurité entremêlés — vers une base de code conventionnelle. Voici la mécanique honnête de ce chemin, car la peur est toujours « nous allons perdre l’app que nous avons » :

• Ce qu’AppSheet donne à l’export : un dossier de fichiers de définition (genre YAML/JSON) décrivant tables, colonnes et règles. Ce sont des données, mais ce n’est pas lisible — sémantique dispersée entre fichiers, sans ordre, sans explication de pourquoi une règle existe.
• Le mapping qui fonctionne : tables → schéma de base de données ; slices → requêtes/vues ; bots → workflows planifiés ; colonnes virtuelles → champs calculés ; filtres de sécurité → contrôle d’accès au niveau des lignes, à un seul endroit auditable.
• Ce que l’équipe garde : le même flux de travail, les mêmes écrans par fonction, les mêmes données. Ce qui change, c’est où vit la logique — dans du code qu’une personne ou un agent IA peut lire, diffuser, modifier à un seul endroit et vérifier contre une suite de tests.

La différence au premier jour est banale mais décisive : un changement de règle qui relevait d’une demi-journée de chirurgie minutée dans l’interface (ouvrir le bon écran, ne pas toucher l’expression voisine, retester à la main) devient une petite modification de code qu’un agent applique en minutes et qu’une suite de tests valide. La maintenance cesse d’être un exercice de clics de spécialiste et devient un travail vérifiable.

C’est le vrai fossé en 2026 — pas la base de données, pas le framework d’interface, mais si l’artefact est lisible par l’agent que vous utiliserez inévitablement pour le maintenir. Le code évolué par prompts et les apps configurées aux clics échouent tous deux cette épreuve ; le code délibérément structuré la réussit.

Quand AppSheet reste la bonne réponse

La même honnêteté que d’habitude : petite équipe (≤10 utilisateurs), flux standard (formulaires, listes, approbations qui ressemblent à des modèles) et quelqu’un en interne qui veut être propriétaire de l’app. Pour ce profil, AppSheet à 50–100 $/mois est une offre correcte, et je le dis — l’article sur les alternatives couvre quand rester.

Partez dès que l’un de ces points devient vrai : les sièges dépassent 10–15, vous avez besoin de connexions API/base de données (tarifs Enterprise Plus), les changements font la queue derrière le calendrier d’une seule personne, ou les Sheets en dessous atteignent 50 000+ lignes.

Ce qu’aucun abonnement par utilisateur n’inclut

AppSheet, Glide, Retool — toutes les plateformes de cette classe vous louent une capacité. Aucune n’inclut la couche humaine : quelqu’un qui étudie comment votre opération tourne réellement, migre les données avec leur histoire intacte, déploie sur une infrastructure que vous contrôlez (un VPS modeste fait tourner une vraie plateforme d’ops sans problème — il n’a pas besoin d’une facture cloud) et reste responsable quand quelque chose casse. Cette couche n’existe nulle part comme abonnement. C’est une personne, et c’est mon métier.

Sources et lectures complémentaires

• Tarifs AppSheet — tranches 5/10/20 $ par utilisateur/mois, vérifiées en août 2026 ; éditions Workspace incluant Core
• Alternatives à AppSheet en 2026 — les trois sorties honnêtes
• Glide vs AppSheet vs un développement sur mesure en 2026 — où se situe GlideOS désormais
• Migrer un CRM AppSheet vers Express + base relationnelle — la migration de bout en bout