Il existe deux façons de transformer un tableur en application. La première garde la feuille comme base de données et pose une application par-dessus : Glide, AppSheet et Softr le font en un après-midi, et chaque modification dans l'app atterrit dans une cellule. La seconde déplace les données dans une vraie base de données et génère l'application dessus : cela prend un jour ou deux, et en échange vous obtenez des rôles, un historique des modifications et aucune limite de lignes. La règle est simple. Gardez la feuille si une seule équipe l'utilise, surtout pour lire, et qu'elle contient quelques milliers de lignes. Déplacez les données si plusieurs personnes y écrivent chaque jour, si certaines ne doivent pas tout voir, ou si le fichier est discrètement devenu le système de référence de l'entreprise.
Ce guide couvre les deux voies : les limites qui rendent le passage nécessaire, la préparation du fichier, qui représente l'essentiel du travail quelle que soit la voie, une méthode en cinq étapes, et les outils comparés sur le prix, les plafonds de lignes et ce que vous possédez à la fin. Il vaut pour Excel comme pour Google Sheets, et pour l'export CSV de presque n'importe quoi d'autre.
Deux façons de transformer un tableur en application
L'expression « transformer Excel en application » cache deux opérations très différentes. Dans la première, rien ne bouge : un outil se connecte à votre Google Sheet ou à votre fichier Excel, lit les lignes et les affiche sous forme de listes, de formulaires et de fiches, sur un téléphone ou dans un navigateur. Dans la seconde, les lignes sont importées une fois dans une base de données, la feuille est archivée, et l'application possède les données à partir de là.
| Voie | Comment ça marche | Première version | Le tableur devient | Idéal pour |
|---|---|---|---|---|
| Une app posée sur la feuille (Glide, AppSheet, Softr) | L'outil lit et écrit les lignes de la feuille ; chaque colonne devient un champ | Quelques heures | La base de données, toujours | Formulaires, listes et recherches pour une petite équipe ; saisie sur le terrain |
| Une base de données et une app générée (Cadrant, ou du low-code sur PostgreSQL) | Les lignes sont importées dans des tables reliées ; les écrans et les rôles sont générés | Un jour ou deux | Une archive | Outils multi-utilisateurs avec rôles, règles et historique |
Quand un tableur ne suffit plus
Les limites techniques sont généreuses et rarement le vrai problème. Une feuille Excel contient 1 048 576 lignes sur 16 384 colonnes, et un fichier Google Sheets accepte jusqu'à 20 millions de cellules. Les limites qu'on atteint en premier sont humaines.
| Limite | Tableur | Application sur une base de données |
|---|---|---|
| Taille | Excel : 1 048 576 lignes par feuille. Google Sheets : 20 millions de cellules. Ancien format XLS : 65 536 lignes | Des millions de lignes par table, sans plafond produit |
| Plusieurs personnes qui écrivent | Le dernier enregistrement gagne, ou une copie en conflit apparaît | Chaque ligne est enregistrée séparément ; rien n'est écrasé |
| Qui voit quoi | Onglets masqués et plages protégées, faciles à contourner | Des rôles appliqués dans la base, ligne par ligne |
| Qui a modifié quoi | Historique des versions du fichier, pas de la fiche | Un journal par fiche, avec l'auteur et l'heure |
| Règles | Formules et validation des données, supprimables par n'importe quel éditeur | Validations et contraintes que personne ne peut sauter |
Le problème plus discret, c'est l'erreur. La compilation d'audits de terrain de Ray Panko, à l'université d'Hawaï, a établi que 88 % des 113 tableurs opérationnels audités depuis 1995 contenaient des erreurs, la plupart dans des formules que personne n'avait vérifiées. Si votre fichier présente au moins deux des cinq signaux décrits dans notre guide pour créer un outil interne, plusieurs éditeurs, des lignes à cacher, un onglet que personne n'ose toucher, pas d'historique, des données ressaisies, c'est la seconde voie qu'il faut préparer.
Préparer le fichier : des colonnes aux tables
Quel que soit l'outil choisi, il lira votre fichier de la même façon : une ligne d'en-tête, une fiche par ligne, une valeur par cellule. La plupart des tableurs qui ont grandi pendant des années enfreignent ces trois règles quelque part. Une heure de nettoyage avant l'import évite une journée de corrections après.
Vient ensuite l'étape qui transforme une feuille en modèle de données. Cherchez les valeurs qui se répètent : un nom de client saisi sur quarante lignes de commande, un produit et son prix recopiés sur chaque ligne. Chaque chose répétée devient sa propre table, avec un identifiant, et la ligne d'origine ne garde que l'identifiant. Cela s'appelle la normalisation, et c'est la différence entre un fichier et une base de données.
Chaque formule mérite une décision. Une colonne qui calcule un total à partir de la quantité et du prix devient un champ calculé. Une colonne qui signale les commandes en retard devient une règle de l'application. Un onglet de tableau croisé qui résume les ventes par mois devient un écran de tableau de bord, généré à partir de la table des commandes. Aucune n'est importée comme une donnée.
Construire l'application en cinq étapes
- 1. Figez le fichier et exportez-le. Annoncez une date, passez la feuille en lecture seule et exportez un CSV par onglet. Sur la première voie, c'est ici que vous connectez l'outil à la feuille à la place.
- 2. Créez les tables et importez les lignes. Importez d'abord les tables de référence (clients, produits), puis les tables qui pointent vers elles (commandes). Comparez le nombre de lignes avec la feuille avant d'aller plus loin.
- 3. Générez les écrans. Une liste, une fiche, un formulaire et un changement de statut pour chaque table principale. Rien de plus dans la première version : ni reporting, ni notifications.
- 4. Reconstruisez les règles. La validation des données devient des champs obligatoires et des valeurs autorisées. Les formules deviennent des champs calculés. Le code couleur devient des statuts. Écrivez la matrice des rôles : qui peut voir, créer, modifier et supprimer dans chaque table.
- 5. Faites tourner les deux pendant une semaine. Trois vrais utilisateurs, de vraies données, le tableur figé à côté. Rassemblez chaque remarque dans une seule liste, corrigez le modèle de données une fois, puis retirez le fichier.
Sur Cadrant, les étapes 2 à 4 sont ce que la plateforme génère à partir de ce brief. Elle crée une application React reliée à une base PostgreSQL dans votre propre projet Supabase, avec des tables, des relations et des index dérivés de la description, et des pages de connexion sur Supabase Auth avec les rôles que vous avez nommés. Les lignes s'importent depuis un CSV dans le tableau de bord Supabase, que vous ouvrez depuis le panneau Base de données du projet, et les règles de sécurité par ligne qui décident qui voit quoi sont créées dans la base à partir du prompt ; la documentation recommande de les relire avant la mise en production. L'offre Starter coûte 20 € par mois quel que soit le nombre de collègues qui utilisent l'outil, et le code se synchronise vers un dépôt GitHub. Les détails sont sur la page du créateur d'outils internes.
Quel outil pour quel tableur
Les prix sont les tarifs publics de septembre 2026, en facturation annuelle quand le choix existe. Nous plaçons Cadrant en premier parce que c'est notre propre produit et le seul ci-dessous à suivre la seconde voie ; les trois autres sont les outils de référence de la première voie, et pour une petite équipe qui lit plus qu'elle n'écrit, ils sont la réponse la plus rapide.
| Outil | Approche | Tarif | Plafond de lignes | Ce que vous possédez | Idéal pour |
|---|---|---|---|---|---|
| Cadrant | Import dans PostgreSQL, app générée à partir d'une description | Forfait fixe, dès 20 € par mois, sans sièges | Aucun du côté du produit | Base sur votre Supabase, code sur GitHub | Outils multi-utilisateurs avec rôles et règles |
| Glide | App posée sur Sheets, Excel ou ses propres tables | 19 à 199 $ par mois ; utilisateurs professionnels au-delà de 30 à 5 $ chacun ; mises à jour comptées | 25 000 lignes par app sur un tableur | La feuille ; l'app reste chez Glide | Apps mobiles soignées pour une petite équipe |
| AppSheet | App posée sur Sheets, Excel ou une base de données | 5 à 20 $ par utilisateur et par mois ; Core inclus dans la plupart des offres Google Workspace payantes | Celui de la source, avec des limites de synchronisation | La feuille ; l'app reste chez AppSheet | Saisie terrain dans une entreprise sous Google Workspace |
| Softr | Portails sur Airtable, Sheets ou SQL | 25 $, 119 $ ou 395 $ par mois avec quotas d'utilisateurs | Celui de la source | La source ; l'app reste chez Softr | Portails clients sur des données gardées ailleurs |
Si vos données vivent déjà dans Airtable plutôt que dans une feuille, le même raisonnement s'applique avec une variable de plus, la facture par siège ; notre guide des alternatives à Airtable traite ce cas.
- Deux voies : une app posée sur la feuille en quelques heures, ou les données déplacées dans une base et l'app générée en un jour ou deux.
- Un tableur cède sur les gens avant de céder sur la taille : modifications simultanées, pas de rôles, pas d'historique, des règles que n'importe qui peut supprimer.
- La préparation est l'essentiel du travail : une ligne d'en-tête, une valeur par cellule, un identifiant par ligne, les valeurs répétées découpées en tables.
- Importez d'abord les références, générez les écrans minimaux, reconstruisez les règles, faites tourner les deux pendant une semaine.