Migrer de Glide vers du code : les données et les droits d'abord, les écrans ensuite

Pour migrer une app Glide vers du code, on sort d'abord les données (Google Sheets, Glide Tables, Big Tables ou base SQL) vers une vraie base, puis on réécrit les droits d'accès côté serveur ; les écrans viennent en dernier et sont la partie la moins risquée. Si votre app est un outil interne simple, utilisé par une petite équipe et branché sur un tableur, ne refaites pas l'interface tout de suite : sortez le tableur, et décidez ensuite.

La méthode ci-dessous vient de la migration de notre propre SaaS, Tala, sorti de Bubble vers du code avec ses clients payants. Ses pièges n'ont rien de propre à Bubble, on les retrouve, à notre avis, tels quels sur une app Glide. Le récit complet est dans notre retour sur la migration Bubble vers du code.

Glide a lancé GlideOS, un produit présenté sur sa page tarifs comme séparé de la plateforme d'origine, désormais appelée Glide Classic, avec des abonnements payants à partir de 25 $ par mois au 14 octobre 2026. L'éditeur y précise que les apps existantes continuent de fonctionner, mais Glide indique n'avoir aucun outil pour migrer automatiquement une app Classic vers GlideOS. Même passer à la nouvelle version de Glide demande donc de reconstruire.

Pourquoi la migration d'une app Glide se décide sur les données et les droits ?

La migration d'une app Glide se décide sur les données et les droits parce que Glide les gère à votre place sans que vous les voyiez, et que ce sont les deux seules choses qui peuvent faire mal le jour de la bascule. Les écrans sont des listes, des fiches et des formulaires. Avec un agent de code comme Claude Code, les refaire en React prend quelques heures à quelques jours, et un bouton mal placé se corrige le lendemain.

Les données fonctionnent à l'inverse. Une app Glide typique part d'un Google Sheet, puis gagne des colonnes calculées, des relations entre onglets, des colonnes propres à chaque utilisateur. Une bonne part de la logique métier vit là, pas dans les écrans. Une erreur de reprise, comme un total faux, se découvre des semaines plus tard.

Les droits sont le point le plus sous-estimé. Glide télécharge les données sur l'appareil de l'utilisateur pour les afficher, et sa documentation le rappelle : retirer un composant d'un écran n'est pas une mesure de sécurité, puisque la donnée peut quand même arriver sur l'appareil. La protection réelle passe par les row owners, appliqués par les serveurs de Glide. En code, cette règle doit être réécrite côté serveur. Oubliée, l'app a l'air de fonctionner parfaitement et elle expose tout.

Nous recommandons donc de planifier une migration Glide à partir de l'inventaire des tables et des règles d'accès, jamais à partir de la liste des écrans. C'est l'objet d'un audit de votre application et de ce que l'IA peut y reprendre : où sont les données, ce qui est calculé, qui voit quoi, et ce qu'un agent de code peut reconstruire seul.

Que peut-on récupérer d'une app Glide, et que faut-il reconstruire ?

On récupère presque toujours les données brutes, en partie les colonnes calculées sous forme de valeurs figées, et jamais les écrans, les actions ni les règles de calcul. Tout dépend de la source de données. Glide en accepte plusieurs selon le plan souscrit : ses Glide Tables et Big Tables, Google Sheets, Airtable, Excel, et des bases SQL comme PostgreSQL réservées à l'offre Enterprise.

Dans Google Sheets, Airtable ou Excel, les données sont déjà chez vous. Les Glide Tables s'exportent en CSV depuis l'éditeur de données, avec un plafond documenté de 25 000 lignes par Glide Table classique, et 25 000 au total sur les sources de type tableur. Les Big Tables montent jusqu'à 10 millions de lignes et s'exportent en CSV envoyé par e-mail.

Les colonnes calculées demandent plus d'attention. Le centre d'aide de Glide indique qu'elles s'exportent comme de simples valeurs texte, sauf les relations et les requêtes, et que les colonnes vides sont ignorées. Vous récupérez le résultat d'un calcul, pas la règle : une colonne « Montant TTC » arrive comme un nombre figé, et sa formule doit être retrouvée puis codée. Les colonnes propres à chaque utilisateur vivent uniquement dans l'éditeur de données de Glide, hors de votre Google Sheet, et sont liées à l'adresse e-mail.

Sur Tala, nous n'avons pas recopié le modèle Bubble : chaque « assistant » (un message d'accueil et un prompt) a été traduit en workflow à nœuds. Pour Glide, une relation entre onglets devient une clé étrangère, une colonne calculée devient une colonne, une vue ou une fonction en base, un onglet « Paramètres » rempli à la main devient une vraie table. Migrer, c'est transformer.

Comment réécrire les row owners et les rôles côté serveur ?

On traduit chaque colonne marquée comme row owner en une règle écrite dans l'API ou dans la base, puis on la teste avec un vrai compte de chaque rôle. Chez Glide, quand une table a des row owners, l'utilisateur connecté ne peut télécharger que les lignes qui lui appartiennent, et plusieurs colonnes de propriétaires se combinent en « OU ». Les rôles s'ajoutent par-dessus : on peut faire d'un rôle comme « Admin » le propriétaire de certaines lignes.

Les conditions de visibilité, elles, ne protègent pas les données, rappelle le guide de sécurité de Glide. Dans beaucoup d'apps, une partie des « droits » n'est qu'un filtre d'affichage : l'onglet est masqué pour les techniciens, mais les données restent téléchargées. À la migration, on trie. Un vrai row owner devient une règle serveur. Un simple masquage est requalifié : soit c'était une confidentialité mal protégée, qu'on sécurise enfin, soit c'était du confort d'interface, qui reste dans l'interface.

En code, la règle vit dans l'API, qui vérifie l'utilisateur et son organisation à chaque requête, ou dans la base : PostgreSQL sait filtrer ligne par ligne selon l'utilisateur connecté, et Supabase l'expose directement. Sur Supabase, nous mettons les règles dans la base : un filtre oublié dans un écran ne fait alors rien fuiter. Avec une API dédiée, nous les testons en appelant chaque route avec le mauvais compte.

La recette est le moment où tout se joue. Sur Tala, juste après la bascule, nous nous sommes connectés avec un vrai compte client migré : l'utilisateur ne voyait pas ses agents, car l'organisation avait été rattachée au mauvais identifiant. Un compte administrateur, qui voit tout, ne l'aurait pas révélé. Avec Glide, le risque existe dans les deux sens : une règle trop stricte qui vide l'écran, ou une règle oubliée qui montre les lignes du voisin. Prévoyez un compte par rôle et vérifiez ce qu'il ne doit pas voir, en interrogeant l'API directement.

Application web ou vraie app sur les stores : que faut-il aux équipes terrain ?

Si vos utilisateurs travaillent avec un réseau fiable, une application web suffit ; si une équipe terrain doit saisir et corriger des données sans réseau, il faut une vraie app mobile, et c'est souvent la meilleure raison de quitter Glide. Les apps Glide sont des applications web progressives, installées depuis le navigateur sur l'écran d'accueil, et le centre d'aide est explicite : la publication sur l'App Store ou Google Play n'est pas prise en charge.

Le hors ligne est plus limité qu'on ne le croit. Sans connexion, l'utilisateur peut consulter l'app et seulement ajouter de nouvelles lignes, à condition d'avoir chargé l'app au préalable, et ce mode n'existe pas avec les Big Tables ni les bases SQL. Un technicien dans un sous-sol peut créer un rapport d'intervention, mais pas corriger celui de la veille ni cocher une tâche existante. Pour une équipe terrain, la vraie limite est là.

Pour ce cas, nous proposons une app React Native ou Flutter, avec une base locale sur le téléphone, une API et une base dédiée côté serveur. Le vrai coût est la synchronisation : si deux personnes modifient la même fiche hors ligne, le métier doit fixer qui l'emporte. C'est le poste qui peut faire varier un projet de développement d'application mobile du simple au double.

Pour un outil interne utilisé derrière un écran (planning, stock, suivi de dossiers, CRM léger), une application web en Next.js avec Supabase ou PostgreSQL fait le travail. Elle s'installe aussi sur un téléphone, sans validation de store. Si personne dans votre équipe ne travaille hors réseau, ne faites pas d'app native : vous paieriez deux plateformes et des mises à jour validées par Apple pour rien. Si vous hésitez entre outils no-code mobiles, notre comparatif Glide vs Adalo pose les critères.

Dans quel ordre migrer une app Glide, et comment basculer sans perdre les utilisateurs ?

L'ordre qui limite les risques est le suivant : les données, puis les droits, puis les écrans, puis la bascule. Sortir le tableur avant de refaire l'interface est souvent le meilleur premier pas, parce que c'est l'étape qui révèle le vrai périmètre.

Sortir le tableur, c'est construire la base cible et le script de reprise pendant que l'app Glide continue de tourner. On nettoie les identifiants, on fixe les types, on décide quelle table fait foi. En offre Enterprise, Glide sait lire une base PostgreSQL et l'app existante peut s'y brancher, même si la documentation prévient qu'un changement de source peut obliger à refaire une partie de l'app. Sinon, le script tourne à blanc sur des exports frais jusqu'à passer sans erreur.

Ce script doit être rejouable. Celui de Tala offrait un mode de validation sans écriture, une option pour ne traiter que quelques organisations, une reprise à une étape donnée, et une table de correspondance entre ancien et nouvel identifiant : on pouvait le relancer dix fois sans doublon. Export complet l'après-midi pour la répétition à blanc, export final le soir, bascule dans la nuit : les surprises sont arrivées avant les clients.

Les utilisateurs sont une bonne nouvelle. Les apps Glide se connectent par code PIN envoyé par e-mail ou par SMS, éventuellement avec un lien magique, par Google ou par SSO : aucun mot de passe Glide à transférer. Gardez une connexion par code e-mail dans la nouvelle app. Sur Tala, nous avons recréé les comptes avec leur e-mail déjà vérifié, sans qu'aucun e-mail ne parte pendant la nuit.

Dernier piège, les réglages implicites. Sur Tala, la transcription vocale passait en anglais tant que la langue n'était pas fixée à « fr ». Pour une app Glide, vérifiez le fuseau horaire, le format des dates, le tri des listes et les arrondis. Après la bascule, passez l'app Glide en lecture seule et verrouillez le script : sur notre propre site, relancer une reprise depuis un export figé aurait effacé ce qui avait été créé depuis. La source de vérité a changé de camp.

Quand vaut-il mieux rester sur Glide ?

Restez sur Glide si votre app est un outil interne simple, utilisé par peu de personnes, avec des données dans un tableur que l'équipe édite directement, et si personne n'a besoin de modifier des fiches hors ligne ni de passer par les stores. Dans ce cadre, Glide fait très bien son travail, et une app en code vous coûterait plus à maintenir qu'elle ne vous ferait gagner.

Les chiffres le confirment pour une petite équipe. Au 14 octobre 2026, la page tarifs de Glide Classic affiche l'offre Business à 199 $ par mois en facturation annuelle, ou 249 $ au mois, avec 30 utilisateurs inclus, 5 $ par utilisateur supplémentaire en annuel, 5 000 updates incluses puis 2 cents par update, et jusqu'à 100 000 lignes sur les sources à grande échelle. Les tables natives de Glide, précise la documentation, ne consomment pas d'updates quand on les modifie dans l'app (hors API Glide et offre Enterprise), contrairement à Google Sheets. Pour vingt personnes qui consultent un planning, difficile de faire moins cher en code, maintenance comprise.

Les signes qui doivent faire reposer la question sont concrets. Le plafond de lignes approche et le passage aux Big Tables casse des calculs, dont plusieurs sont limités à 100 lignes correspondantes sur ce type de table. La facture d'updates grimpe avec une source externe très active. La logique est éparpillée entre formules du tableur, colonnes Glide et automatisations. Ou l'app devient un produit vendu, qui exige des tests automatisés.

Si vous restez, assainissez : row owners partout où il y a des données personnelles, colonnes calculées documentées, onglets de paramètres sortis du tableur. Notre guide des apps internes sur Glide détaille ce qui fonctionne bien sur l'outil, et une agence Glide peut reprendre une app existante sans la reconstruire. Si vous migrez un jour, l'inventaire sera fait.

Combien de temps faut-il pour migrer une app Glide vers du code ?

La durée dépend de quatre facteurs bien plus que du nombre d'écrans : le volume de tables et de colonnes calculées, la complexité des droits, le besoin hors ligne et les stores, et les intégrations à rebrancher. Entre un outil interne web à deux rôles et une app mobile de terrain synchronisée hors ligne, l'écart se compte en multiples.

Chaque colonne calculée oblige à retrouver la règle, à la faire valider par le métier, puis à vérifier que la version codée donne le même résultat que Glide sur les données réelles. Chaque règle de droits demande son test. Chaque workflow Glide qui envoie un e-mail ou appelle une API doit être réécrit et testé contre le vrai service.

Les agents de code ont changé l'équation. Il y a deux ans, l'interface et la plomberie (formulaires, listes, API de base, authentification) faisaient l'essentiel du devis. Aujourd'hui, Claude Code les produit vite à partir des captures de l'app Glide ; Dominique en parle dans sa vidéo sur le no-code et l'IA. Restent incompressibles la compréhension du métier, la reprise des données et la recette.

Nous ne donnons pas de prix sans avoir vu l'app. Pour situer les ordres de grandeur, notre article sur le coût d'une application no-code face au code donne des repères. Pour un chiffrage, nous partons de cet inventaire et découpons la migration d'une app Glide vers du code sur mesure en étapes livrables. Si le projet dépasse la reprise de l'existant, notre offre de développement sur mesure couvre la suite.

Questions fréquentes

Peut-on exporter le code d'une app Glide ?

Pas à notre connaissance : pour une app Glide Classic, la documentation ne décrit que l'export CSV des Glide Tables et des Big Tables, et vos Google Sheets restent chez vous. Les écrans, les actions et les workflows se reconstruisent à partir de captures et d'un inventaire. Les colonnes calculées sortent comme des valeurs figées, sauf les relations et les requêtes. Documentez donc chaque formule avant de couper l'app, tant qu'elle est encore consultable.

Quelle alternative à Glide pour une app interne ?

Pour un outil interne utilisé au bureau, une application web en Next.js avec Supabase ou PostgreSQL est l'alternative la plus directe : une seule base de code, des droits écrits dans la base, aucune validation de store. Pour une équipe terrain qui travaille sans réseau, une app React Native ou Flutter avec une base locale est plus adaptée. Si l'app reste simple et peu utilisée, la meilleure alternative est parfois de rester sur Glide en assainissant les données.

Mes utilisateurs devront-ils créer un nouveau mot de passe ?

Pas forcément. Les apps Glide se connectent par code PIN envoyé par e-mail, par Google ou par SSO selon la configuration, donc il n'y a pas de mot de passe Glide à transférer. Si la nouvelle app garde une connexion par code ou lien envoyé par e-mail, les utilisateurs se connectent avec la même adresse et ne remarquent presque rien. Recréez les comptes avec l'e-mail déjà vérifié et coupez tout envoi automatique pendant la bascule.

Peut-on garder Google Sheets avec une app en code ?

Techniquement oui, mais nous le déconseillons au-delà d'une phase de transition. Un tableur ne garantit ni les types, ni l'unicité des identifiants, ni les droits ligne par ligne, et toute personne qui a accès au fichier peut casser l'app d'un copier-coller. Le bon compromis consiste à passer les données dans une vraie base et à proposer un export vers Google Sheets pour ceux qui analysent les chiffres dans un tableur.

Combien de temps garder l'app Glide après la bascule ?

Gardez-la en lecture seule quelques semaines, le temps que chacun vérifie ses données dans la nouvelle app et que vous compariez les chiffres clés. Retirez-lui toute possibilité d'écriture dès la bascule : deux apps modifiables en parallèle produisent à coup sûr des données divergentes. Conservez aussi l'export final et le script de reprise, verrouillé, pour pouvoir expliquer d'où vient chaque donnée si une question arrive plusieurs mois plus tard.