AppSheet : qu'est-ce que c'est et comment l'utiliser en 2026 ?

AppSheet est la plateforme NoCode de Google qui permet de créer des applications métier web et mobiles à partir de données existantes ou d'une base AppSheet Database. Vous y construisez des formulaires, des outils de suivi, des applications terrain et des automatisations sans écrire de code, et l'application obtenue s'utilise sur ordinateur, tablette et smartphone. Depuis l'intégration de Gemini, une première structure d'application peut aussi être générée à partir d'une simple description en langage naturel. Google AppSheet s'adresse avant tout aux équipes qui veulent outiller un processus interne vite, sans passer par un cycle de développement classique.

Mis à jour en septembre 2026.

AppSheet en bref

À quoi sert Google AppSheet ?

AppSheet sert à transformer des données structurées en application utilisable par une équipe. Vous partez d'un jeu de données (un tableau de stocks, une liste d'interventions, un fichier clients), vous décrivez comment il doit être consulté et modifié, et la plateforme génère l'interface, les formulaires de saisie et la logique de synchronisation.

Google présente la plateforme comme un moyen de couvrir des besoins de gestion de projet, d'opérations, de travail terrain, de ressources humaines, de vente et de marketing, avec des applications qui fonctionnent aussi bien sur ordinateur que sur mobile. C'est une nuance importante : AppSheet n'est plus un simple générateur d'applications mobiles, c'est un constructeur d'applications métier multi-supports.

AppSheet a été racheté par Google, qui a annoncé l'acquisition en janvier 2020. Depuis, la plateforme a été intégrée à Google Cloud et à Google Workspace, ce qui explique sa proximité avec Google Sheets, Drive, Gmail et Chat.

Pour quels types de projets ?

AppSheet vise les applications de processus, pas les produits grand public. Les projets qui lui vont le mieux partagent trois caractéristiques : des données déjà structurées ou faciles à structurer, un nombre d'utilisateurs identifiés, et un besoin fonctionnel plus fort que le besoin graphique.

• Suivi d'un stock, d'un parc de matériel ou d'un inventaire.
• Collecte d'informations sur le terrain, avec photos, signatures et géolocalisation.
• Formulaires d'inspection, de contrôle qualité ou de validation.
• Suivi d'activité commerciale léger, de projets ou d'opérations internes.
• Petits outils internes qui remplacent un tableur partagé devenu ingérable.

Si votre besoin est exactement celui-là, la page dédiée à l'application métier avec AppSheet détaille ce cas d'usage précis.

Comment fonctionne AppSheet ?

Le principe d'AppSheet tient en une phrase : l'application est une couche d'interface et de logique posée sur une source de données. Vous ne codez pas d'écrans, vous décrivez des tables, des colonnes, des vues et des règles, et la plateforme se charge du rendu sur chaque support.

Les sources de données : AppSheet Database, Google Sheets, Excel et bases SQL

C'est le point qui a le plus changé depuis les premières versions de l'outil. Longtemps, une application AppSheet supposait une source externe, en général une feuille de calcul. Ce n'est plus le cas : Google propose désormais AppSheet Database, sa propre base de données native, intégrée directement à l'éditeur.

Concrètement, vous avez quatre entrées possibles :

• AppSheet Database : la base native, créée et éditée dans AppSheet, sans fichier externe à gérer.
• Google Sheets : toujours la porte d'entrée la plus naturelle, et souvent la plus rapide quand les données existent déjà.
• Excel et fichiers hébergés : classeurs stockés sur Drive, OneDrive, Dropbox ou Box.
• Bases et services externes : Cloud SQL, Azure SQL, AWS, Salesforce, Smartsheet et d'autres sources, selon l'offre souscrite.

Une feuille Google Sheets existante peut être importée dans une AppSheet Database : la base reprend alors le nom de la feuille d'origine, et Google indique que jusqu'à cinq onglets de la feuille sont repris à l'import. C'est le chemin à privilégier quand un tableur a servi de prototype et qu'il faut passer à quelque chose de plus solide.

Attention toutefois, la base native n'est pas illimitée et ses plafonds dépendent de l'offre. La documentation Google publie les limites suivantes par AppSheet Database.

À ces plafonds s'ajoutent des limites communes à toutes les offres : 20 tables par base, 100 colonnes par table et 2 000 caractères par cellule. Retenez le principe : pour des volumes importants, on ne reste pas sur la base native ni sur un tableur, on branche une base SQL.

Si vous partez d'un tableau et que vous hésitez encore sur l'outil, notre guide sur la manière de créer une application à partir d'un tableau Google Sheets ou Airtable compare d'autres approches possibles.

L'éditeur d'application

Une fois la source connectée, AppSheet lit la structure des données et propose une première application fonctionnelle. L'éditeur est ensuite organisé par grands blocs : les données (tables, colonnes, types, formules), les vues (ce que voit l'utilisateur), les actions (ce qu'il peut déclencher), l'automatisation (ce qui se déclenche tout seul) et la sécurité (qui accède à quoi).

Le typage des colonnes est la partie la plus déterminante. Un champ correctement typé en date, en image, en signature, en adresse ou en référence vers une autre table change radicalement le rendu de l'application et la qualité de la saisie. C'est là que se joue l'essentiel du travail, bien plus que dans l'habillage graphique.

Les vues, formulaires et actions

Une vue est une façon de présenter une table : liste, galerie, tableau, calendrier, carte, graphique, ou formulaire de saisie. Une même table peut alimenter plusieurs vues destinées à des usages différents, et l'affichage s'adapte automatiquement au support utilisé.

Les actions sont les boutons et comportements que vous ajoutez : changer un statut, ouvrir un formulaire, dupliquer une ligne, lancer un appel, ouvrir un itinéraire. Elles peuvent être conditionnées, ce qui permet de n'afficher un bouton que pour certains profils ou certains états d'une fiche.

Les applications peuvent fonctionner hors connexion. Google documente le fait qu'une application AppSheet reste utilisable sur un appareil mobile déconnecté du réseau, la définition de l'application et les données étant stockées localement, avec une synchronisation automatique en arrière-plan lorsque des modifications sont en attente ou lorsque les données locales datent de plus de 30 minutes. Seule condition, l'application doit avoir été lancée une première fois en étant connectée. Pour des équipes en entrepôt, en chantier ou en tournée, c'est un argument décisif.

Les automatisations : bot, event, process, task et action

L'automatisation d'AppSheet repose sur un vocabulaire précis qu'il vaut mieux connaître avant de se lancer.

• Bot : l'automatisation elle-même, celle que vous voulez voir s'exécuter.
• Event : le déclencheur. Google cite une modification dans l'application, une modification dans une AppSheet Database, une planification, une interaction depuis une application Chat, une réponse à un Google Forms ou un changement de libellé Gmail.
• Process : la suite d'étapes exécutées une fois le bot déclenché.
• Step : une étape du processus, qui peut lancer une tâche ou une action sur les données, brancher selon une condition, attendre, appeler un autre processus ou renvoyer des valeurs.
• Task : l'opération concrète réalisée par une étape, par exemple l'envoi d'un email.

En pratique, cela permet de couvrir des besoins très courants sans écrire de script : prévenir un responsable quand un stock passe sous un seuil, envoyer un récapitulatif hebdomadaire, générer un document à la validation d'une fiche, ou relancer automatiquement une intervention non clôturée.

API, webhooks et OData

AppSheet n'est pas un environnement fermé, même si les capacités d'ouverture dépendent de l'offre. Une automatisation peut appeler un webhook pour transmettre des données à un service tiers, ce qui suffit à connecter l'application à un outil externe dans les deux sens les plus courants.

Google publie également une API REST qui expose les opérations Add, Delete, Edit et Find sur les tables d'une application, ainsi que les actions personnalisées définies sur ces tables. La documentation précise que cette fonctionnalité est réservée aux offres Enterprise. Sur la grille publique, l'accès OData et les services de données étendus sont eux aussi rattachés à l'offre Enterprise Plus, tandis que les webhooks déclenchés depuis les événements de l'application ou une planification sont disponibles dès l'offre Core.

AppSheet et Gemini : créer une application avec l'IA

C'est l'évolution la plus visible du produit. Google propose Gemini for App Creation, qui permet de décrire en langage naturel un processus métier ou une idée d'application, et d'obtenir une première structure applicative.

Comment fonctionne Gemini for App Creation ?

La documentation Google décrit un parcours en trois temps, que l'on peut détailler en cinq étapes.

1. Décrire le besoin. Depuis l'écran de vos applications, vous choisissez de démarrer avec Gemini et vous expliquez, en français ou en anglais, le processus que l'application doit servir.
2. Examiner la structure proposée. Gemini répond par une liste de tables, de colonnes et de liens entre les tables. Dans l'exemple documenté par Google, une demande d'application d'inspection produit quatre tables reliées entre elles.
3. Vérifier et corriger avant génération. Vous pouvez renommer les tables, ajouter ou retirer des colonnes, changer les types de données ou ajouter une table entière avant de valider.
4. Générer l'application. Un clic sur la création ouvre l'application dans l'éditeur AppSheet, prête à être prévisualisée, personnalisée et partagée.
5. Reprendre la main. La logique métier fine, l'expérience utilisateur, la sécurité et les automatisations restent à votre charge.

Point à ne pas manquer : l'application générée s'appuie sur une AppSheet Database et contient des données d'exemple. Google demande explicitement de supprimer ces données d'exemple avant tout usage réel, car elles peuvent être inexactes.

Ce que l'IA génère et ce qu'il reste à configurer

Gemini fait gagner du temps sur la mise en place, pas sur la conception. Ce qu'il produit, c'est un schéma de données et une première application assortie de vues et d'actions prédéfinies. Ce qu'il ne produit pas, c'est votre modèle de droits, vos règles de gestion, vos formats de document, vos seuils d'alerte ni vos intégrations.

Autrement dit, la génération vous place au point de départ d'un projet correctement structuré, et vous économise la phase la plus ingrate : modéliser les tables à la main. Le reste du travail est inchangé.

Côté disponibilité, Google indique que la fonctionnalité est accessible à tous les comptes AppSheet payants, ce qui inclut les clients Google Workspace disposant d'AppSheet Core et d'AppSheet Enterprise Plus, ainsi que les comptes individuels AppSheet Publisher Pro, Starter, Core et Enterprise Plus. Aucun abonnement Gemini distinct n'est requis, et un administrateur peut désactiver la fonctionnalité au niveau de chaque équipe.

Tutoriel : créer une application avec AppSheet

Il y a aujourd'hui deux portes d'entrée légitimes. La première part de données qui existent déjà, la seconde part d'une description du besoin. Les deux convergent ensuite vers le même travail de configuration.

Option 1 : partir de données existantes

C'est le chemin historique, et il reste le plus fréquent quand une équipe gère déjà son sujet dans un tableur.

1. Structurer la source. Dans une Google Sheet, la première ligne doit contenir les noms de colonnes, un par colonne, sans ligne vide ni cellule fusionnée au-dessus. Pour une application d'inventaire, vous aurez typiquement des colonnes nom, référence, quantité, seuil d'alerte et emplacement.
2. Choisir entre la feuille et la base native. Pour un prototype rapide, connecter directement la feuille suffit. Pour un outil destiné à durer, importez la feuille dans une AppSheet Database : vous gagnez le typage, les relations entre tables et l'édition directe dans l'éditeur.
3. Connecter la source. Depuis AppSheet, vous créez une application en pointant la source de données. Depuis une Google Sheet, le même geste est accessible par le menu Extensions de la feuille.
4. Laisser AppSheet générer la première version. La plateforme lit la structure et propose une application déjà navigable, qu'il faut ensuite corriger.

Option 2 : partir d'une description en langage naturel avec Gemini

Quand les données n'existent pas encore, ou qu'elles sont éparpillées, il est plus efficace de décrire le processus et de laisser Gemini proposer le modèle.

1. Décrivez le processus avec ses acteurs, ses objets et ses étapes. Plus la description est concrète, meilleure est la structure proposée.
2. Relisez les tables et les colonnes suggérées avant de valider. C'est l'étape à ne pas survoler : une erreur de modèle se paie sur toute la durée de vie de l'application.
3. Générez l'application, puis supprimez immédiatement les données d'exemple.
4. Reprenez ensuite exactement le même chemin que dans l'option 1, à partir de la configuration des vues.

Configurer les vues et les formulaires

Reprenez chaque table et demandez-vous qui la consulte et pour quoi faire. Une vue liste pour le quotidien, une vue détail pour la consultation, un formulaire allégé pour la saisie mobile : c'est souvent suffisant.

Vérifiez ensuite le type de chaque colonne, les valeurs par défaut, les champs obligatoires et les listes de choix. Une saisie contrainte en amont évite des heures de nettoyage de données en aval.

Ajouter des règles et des automatisations

Commencez par une seule automatisation utile plutôt que par cinq automatisations approximatives. Choisissez l'événement déclencheur, décrivez le processus, puis la tâche à exécuter. Testez le bot sur une ligne de données factice avant de l'activer pour tout le monde.

Gérer les accès et sécuriser les données

Activez l'authentification obligatoire, définissez qui peut ouvrir l'application, puis restreignez les données visibles selon le profil. Cette étape se traite avant le déploiement, pas après.

Tester et déployer l'application

AppSheet permet d'inviter des utilisateurs de test sans frais avant tout déploiement, ce qui laisse le temps de valider le parcours réel avec les personnes concernées. Le déploiement ne demande pas nécessairement d'installation : l'application est accessible depuis un navigateur sur ordinateur, et depuis l'application AppSheet sur mobile et tablette. Vous pouvez continuer à faire évoluer l'application après sa mise en service.

Que peut-on créer avec AppSheet ?

La galerie de modèles publiée par AppSheet donne une idée du spectre couvert. Voici les cinq familles d'applications qui reviennent le plus souvent en entreprise.

Gestion des stocks et inventaire

Suivi des quantités, entrées et sorties, alertes de seuil, scan de codes-barres depuis le téléphone. C'est le cas d'usage le plus fréquent, parce qu'il part presque toujours d'un tableur existant et qu'il gagne énormément à la saisie mobile.

Application terrain et collecte de données

Relevés, constats, photos horodatées, signature du client, position GPS. Le mode hors connexion prend ici toute sa valeur : les données saisies dans une zone sans réseau remontent dès que la connexion revient.

CRM et suivi commercial

Fiches comptes et contacts, historique des visites, prochaines actions, relances automatiques. AppSheet ne remplace pas un CRM complet, mais il couvre très bien le suivi d'une petite équipe commerciale ou d'un réseau d'itinérants.

Gestion de projets et opérations

Suivi de chantiers, plannings d'interventions, coordination d'équipes, onboarding de nouveaux collaborateurs. L'intérêt tient souvent à la connexion avec Gmail, Agenda et Chat.

Formulaires, inspections et validations

Contrôles qualité, checklists de sécurité, demandes internes avec circuit de validation. La combinaison formulaire contraint plus automatisation de notification couvre l'essentiel du besoin.

Combien coûte AppSheet en 2026 ?

Tarifs vérifiés en septembre 2026.

Peut-on utiliser AppSheet gratuitement ?

Oui, mais il faut comprendre ce que cela recouvre. Google permet d'accéder sans frais aux fonctionnalités de base de création d'applications et d'automatisation pendant la phase de développement, et d'inviter jusqu'à 10 utilisateurs de test sans coût. Vous pouvez construire un ou plusieurs prototypes, sans limite de durée annoncée.

En revanche, ce n'est pas un plan gratuit équivalent à un déploiement professionnel : dès qu'une application est réellement déployée auprès d'utilisateurs, une licence par utilisateur devient nécessaire. Le gratuit d'AppSheet est un terrain de prototypage et de test, pas un mode d'exploitation.

Starter, Core, Enterprise Plus et Publisher Pro

Voici la grille publiée par Google sur sa page tarifaire officielle. Les montants sont exprimés en dollars, par mois, et la facturation intervient mensuellement ou annuellement selon l'abonnement choisi.

Starter, Core et Enterprise Plus se facturent à l'utilisateur, comptés parmi les utilisateurs uniques des applications déployées. Publisher Pro se facture à l'application, avec une licence par application déployée. L'achat d'Enterprise Plus suppose d'être administrateur Google Workspace.

AppSheet Core inclus dans Google Workspace

C'est l'information qui change le plus souvent le calcul, et elle est trop rarement mentionnée. AppSheet Core est déjà inclus dans plusieurs éditions payantes de Google Workspace, pour chaque utilisateur vérifié du domaine. Google publie la liste suivante :

• Google Workspace Business Starter, Business Standard et Business Plus ;
• Google Workspace Enterprise Starter, Enterprise Standard et Enterprise Plus ;
• Google Workspace for Education Standard et Education Plus ;
• Google Workspace Enterprise Essentials Plus ;
• Google Workspace Frontline Starter et Frontline Standard ;
• Google Workspace for Nonprofits.

Si votre organisation figure dans cette liste, le coût marginal d'une application AppSheet peut être nul. Vérifiez donc votre édition Workspace avant de comparer AppSheet à un concurrent sur le seul prix catalogue : la comparaison peut basculer complètement. Les éditions qui n'incluent pas AppSheet peuvent souscrire un abonnement complémentaire Core ou Enterprise Plus.

Le cas des applications publiques avec Publisher Pro

La facturation par utilisateur devient un problème dès que l'application s'adresse à un public non identifié. C'est exactement l'objet de Publisher Pro : une application publique, sans écran de connexion, facturée à l'application et non à l'utilisateur. Si votre projet vise des clients finaux ou un public large, c'est la seule ligne de la grille qui a du sens, et il faut comparer son coût à celui d'un outil conçu pour le portail public.

La sécurité des données dans AppSheet

La sécurité d'une application AppSheet ne se résume pas à une garantie générale : elle dépend de votre configuration, de votre source de données et de votre offre. Voici les éléments concrets sur lesquels elle repose.

• Authentification. Vous pouvez imposer une connexion obligatoire, avec les fournisseurs d'identité pris en charge par la plateforme, dont Google, Microsoft, Apple, Dropbox, Box, Smartsheet et Salesforce. Google précise qu'AppSheet ne tient pas son propre registre d'identifiants et de mots de passe : la connexion est déléguée au fournisseur choisi.
• Permissions et rôles. L'accès à l'application se contrôle par liste d'adresses autorisées, par domaine, ou par groupes existants de votre annuaire, notamment Google Groups, groupes AD et Okta.
• Security filters. Ils limitent les données réellement envoyées à chaque utilisateur. Sur la grille publique, ils sont disponibles à partir de l'offre Core. Google précise qu'ils ne constituent pas à eux seuls une solution de sécurité complète et que les opérations sensibles doivent aussi être protégées au niveau de la source de données.
• Chiffrement. Les échanges entre l'appareil et les services AppSheet passent en HTTPS, et les données mises en cache localement sont isolées par utilisateur connecté.
• Audit. La plateforme permet de suivre qui a utilisé l'application et quelles fonctionnalités ont été employées.
• Audit externe. Google indique sur sa page sécurité qu'AppSheet fait l'objet d'un audit SOC 2 Type 2, le rapport étant communiqué aux clients sur demande et sous accord de confidentialité.
• Résidence des données. Une organisation Google Workspace disposant de comptes AppSheet Enterprise Plus peut restreindre le stockage et le traitement à la région Union européenne ou à la région Asie-Pacifique, le paramétrage par défaut étant mondial. Le périmètre couvre notamment les définitions d'applications, les configurations de sources de données, les données des AppSheet Databases, les journaux d'audit et les sauvegardes.

Point de vigilance si vos données restent dans une feuille de calcul : la protection ne passe pas par un mot de passe posé sur le fichier, mais par les autorisations de partage de ce fichier. Une feuille correctement cloisonnée est la condition de base d'une application correctement cloisonnée.

Les avantages et les limites d'AppSheet

Les avantages

• Délai de mise en œuvre. Une première application exploitable se construit en quelques heures à partir de données déjà structurées, et en quelques minutes avec Gemini pour la structure de départ.
• Multi-support natif. La même application s'utilise sur ordinateur, tablette et smartphone, sans double travail de conception.
• Fonctionnement hors ligne. C'est le vrai différenciateur face à la plupart des plateformes NoCode concurrentes, et la raison pour laquelle AppSheet reste très présent sur les usages terrain.
• Intégration à Google Workspace. Proximité immédiate avec Sheets, Drive, Gmail, Agenda, Forms et Chat, et déclencheurs d'automatisation qui s'appuient dessus.
• Coût potentiellement nul. Si votre édition Workspace inclut AppSheet Core, la facture d'entrée disparaît.
• Automatisation intégrée. Les bots évitent de recourir à un outil d'automatisation tiers pour les scénarios courants.

Les limites

• Personnalisation de l'interface. Le rendu reste celui d'AppSheet. Vous ajustez les couleurs, les icônes et l'organisation des vues, pas la mécanique d'affichage. Pour une application métier interne, c'est rarement bloquant ; pour un produit destiné à des clients, cela l'est souvent.
• Performances selon la source. Les temps de synchronisation dépendent de la source de données, du volume, du modèle de données et des expressions utilisées. Une feuille de calcul volumineuse est le premier facteur de ralentissement : pour des volumes conséquents, il faut passer sur une AppSheet Database Enterprise Plus ou une base SQL, dont les limites varient selon l'offre.
• Écosystème de connecteurs. Les intégrations prêtes à l'emploi disponibles dépendent de l'offre souscrite et peuvent être moins adaptées que d'autres plateformes à certains services SaaS spécifiques. Les webhooks et l'API REST compensent en partie, mais l'API est réservée aux offres Enterprise.
• Courbe d'apprentissage sur la logique. Les expressions AppSheet, les slices et les références entre tables demandent un vrai temps d'apprentissage dès que le besoin se complexifie.
• Modèle de facturation à l'utilisateur. Il est cohérent pour une application interne, beaucoup moins dès que la population d'utilisateurs devient large ou fluctuante.

Quand choisir AppSheet, et quand ne pas le choisir

AppSheet est particulièrement adapté si

• votre organisation est déjà équipée en Google Workspace, a fortiori dans une édition qui inclut AppSheet Core ;
• vous outillez un processus opérationnel interne plutôt qu'un produit destiné au marché ;
• vos utilisateurs travaillent sur le terrain et ont besoin du mode hors connexion ;
• vos données sont déjà structurées dans un tableur, une base SQL ou un outil connecté ;
• le besoin fonctionnel prime nettement sur le besoin d'une interface sur mesure ;
• vous voulez tester une idée avant d'engager un développement.

Quand AppSheet n'est pas le bon outil

Autant le dire clairement, il y a des projets pour lesquels AppSheet vous fera perdre du temps.

• Une interface fortement personnalisée. Si l'expérience visuelle fait partie de la proposition de valeur, le cadre d'AppSheet devient une contrainte permanente.
• Une application grand public. Parcours d'inscription sur mesure, design produit spécifique, marque forte : ce n'est pas le terrain d'AppSheet, et le modèle de licence n'y est pas adapté non plus.
• Un front-end libre. Si vous avez besoin de maîtriser le rendu jusqu'au détail, orientez-vous vers une plateforme qui expose réellement le front.
• Une architecture applicative complexe. Traitements lourds côté serveur, multiples services interconnectés, logique métier très ramifiée : le modèle tables, vues et bots finit par être détourné.
• Un modèle économique incompatible. Des centaines ou des milliers d'utilisateurs externes rendent la facturation par utilisateur difficile à tenir, et Publisher Pro ne répond qu'au cas de l'application publique sans connexion.

Quelles sont les meilleures alternatives à AppSheet ?

Trois alternatives couvrent la quasi-totalité des situations où AppSheet ne convient pas. Pour un panorama plus large, notre fiche AppSheet récapitule les caractéristiques clés de l'outil et les solutions comparables.

AppSheet vs Glide

Glide part du même principe, transformer des données en application, mais avec un soin nettement supérieur apporté au rendu visuel et à la prise en main. AppSheet garde l'avantage sur le mode hors connexion, la profondeur des automatisations, les sources de données d'entreprise et l'intégration native à Google Workspace. Le choix se joue souvent sur ce point : application terrain exigeante d'un côté, outil interne soigné et rapide à produire de l'autre. Notre comparatif Glide vs AppSheet détaille l'arbitrage.

AppSheet vs Power Apps

Power Apps est l'équivalent Microsoft, et le raisonnement est symétrique : si votre organisation vit dans Microsoft 365, avec SharePoint, Dataverse et Teams, Power Apps s'intègre là où AppSheet devra passer par des connecteurs. Power Apps va plus loin sur les scénarios lourds et la gouvernance, au prix d'une complexité et d'un coût d'entrée supérieurs. AppSheet reste plus rapide à prendre en main pour une équipe non technique.

AppSheet vs Softr

Softr répond à un besoin différent : produire un portail ou une application web à partir d'une base, avec une vraie liberté de mise en page et des espaces clients. Si votre projet est un portail client ou un site applicatif, Softr est plus adapté. Si c'est un outil de saisie utilisé sur le terrain, AppSheet reprend l'avantage.