Utiliser Google Sheets ou Airtable comme base de données d'une véritable application métier surprend souvent, tant ces outils sont associés à un usage bureautique plutôt qu'à une infrastructure logicielle. Pourtant, dans un nombre croissant de projets de développement d'application sur mesure, c'est un choix parfaitement défendable, tant que ses limites sont bien comprises dès la conception.

Cet article détaille jusqu'où cette approche tient techniquement, et surtout à partir de quel moment il devient nécessaire de migrer vers une base de données traditionnelle.

Pourquoi Google Sheets ou Airtable fonctionnent comme base de données

Dans de nombreuses organisations, les données existent déjà dans un tableur avant même qu'une application ne soit envisagée : listes de contacts, suivi de dossiers, inventaire, planning. Construire l'application autour de ce tableur, plutôt que de migrer les données vers un système séparé, présente des avantages concrets :

  • L'équipe métier garde la main directement sur les données, sans dépendre d'un accès technique ou d'une interface d'administration développée spécifiquement
  • Aucune migration de données n'est nécessaire au démarrage du projet, ce qui réduit le risque et le coût de la première version
  • L'API Google Sheets et l'API Airtable sont matures, bien documentées, et permettent un accès en lecture et en écriture fiable depuis une application tierce
  • Avec un mapping dynamique des colonnes, lecture de la ligne d'en tête pour retrouver les champs par leur nom plutôt que par leur position, le tableur peut évoluer, nouvelle colonne, réorganisation, sans casser l'application qui l'exploite

C'est une approche que nous avons par exemple mise en œuvre pour une application de campagnes de SMS et d'emails, où le tableur Google Sheets existant de l'établissement sert à la fois de source des contacts et de journal des envois réalisés, sans aucune base de données technique additionnelle.

Les limites réelles de cette approche

Un tableur reste néanmoins un outil de bureautique, pas un système de gestion de base de données. Plusieurs limites techniques apparaissent au delà d'un certain usage :

  • Plafonds de volume : Google Sheets limite un classeur à un nombre de cellules déterminé, plusieurs millions, ce qui semble large mais peut devenir contraignant avec un historique de données qui s'accumule sans purge
  • Quotas d'appels API : les deux plateformes imposent des limites de requêtes par minute, ce qui peut poser problème pour des applications à fort trafic simultané
  • Absence de transactions et de contraintes d'intégrité : contrairement à une base de données relationnelle, rien n'empêche nativement deux écritures concurrentes de se marcher dessus, ni ne garantit qu'une donnée respecte un format ou une relation attendue
  • Absence de jointures et de requêtes complexes : filtrer, agréger ou croiser des données volumineuses doit être fait côté application plutôt que délégué à un moteur de requêtes optimisé, ce qui devient coûteux en performance à mesure que le volume grandit
  • Latence : chaque lecture ou écriture passe par un appel réseau à une API tierce, plus lent qu'une requête vers une base de données hébergée au plus près de l'application

Pour la grande majorité des applications métier internes, quelques centaines à quelques milliers de lignes, quelques utilisateurs simultanés, ces limites ne sont jamais atteintes. Elles deviennent en revanche déterminantes pour des applications à plus grande échelle.

Les signaux qui indiquent qu'il faut migrer vers une vraie base de données

Plusieurs signes concrets doivent alerter sur la nécessité de faire évoluer l'architecture :

  • Des écritures concurrentes fréquentes provenant de plusieurs utilisateurs ou processus simultanés, avec un risque réel de conflit ou de perte de données
  • Un besoin de requêtes relationnelles complexes, croisement de plusieurs tables, agrégations lourdes, recherche plein texte performante, que le tableur ne peut plus absorber sans ralentir fortement l'application
  • Des exigences de conformité ou de sécurité renforcées sur des données sensibles, nécessitant un contrôle d'accès plus fin qu'un partage de fichier
  • Une croissance du volume de données qui approche les limites techniques de la plateforme, ou qui dégrade significativement les temps de réponse
  • Un besoin de mises à jour en temps réel à forte fréquence, pour lequel la latence des API de tableur devient un frein perceptible pour les utilisateurs

Tant qu'aucun de ces signaux n'est présent, migrer vers une base de données traditionnelle ajoute de la complexité, hébergement, sauvegardes, gestion des accès, sans bénéfice réel pour l'utilisateur final.

Une approche pragmatique plutôt que dogmatique

Notre position sur ce sujet est délibérément pragmatique : nous ne recommandons ni systématiquement Google Sheets ou Airtable, ni systématiquement une base de données traditionnelle. Le bon choix dépend du volume réel, du nombre d'utilisateurs simultanés, et de la complexité des règles de gestion des données. Une architecture bien conçue dès le départ, mapping dynamique des champs, séparation claire entre la couche de données et la logique métier, permet d'ailleurs, le cas échéant, de migrer plus tard vers une base de données traditionnelle sans réécrire l'ensemble de l'application, seule la couche d'accès aux données étant remplacée.