Base de données

Une base de données est le système qui permet à une application de stocker des informations de manière durable, de les organiser pour y accéder rapidement et de les restituer quand on en a besoin. Les comptes utilisateurs, les commandes, les messages, les paramètres, l’historique des actions — toutes ces données vivent dans une base de données.

Si l’application est un restaurant, la base de données est le garde-manger et le livre de recettes combinés : sans elle, il n’y a rien à servir et aucun moyen de retrouver ce qu’on a préparé hier.

Bases relationnelles (SQL) et bases non relationnelles (NoSQL)

Il existe deux grandes familles de bases de données, chacune adaptée à des contextes différents.

Les bases relationnelles (SQL) organisent les données en tables structurées avec des lignes et des colonnes, un peu comme un tableur. Chaque table a un schéma défini à l’avance : une table “utilisateurs” contient un nom, un email, une date de création. Les relations entre les tables (un utilisateur a plusieurs commandes, chaque commande contient plusieurs produits) sont gérées de façon rigoureuse. PostgreSQL, MySQL et MariaDB sont les exemples les plus courants.

Les bases non relationnelles (NoSQL) stockent les données sous forme de documents flexibles (souvent en JSON), de paires clé-valeur ou de graphes. Il n’y a pas de schéma rigide : un document peut contenir des champs que le voisin n’a pas. MongoDB, DynamoDB et Redis sont les plus connues. On distingue plusieurs sous-catégories :

• Bases documentaires (MongoDB, CouchDB) : stockent des documents JSON flexibles, idéales pour des structures de données variables.
• Bases clé-valeur (Redis, DynamoDB) : associent une clé unique à une valeur, optimisées pour des lectures et écritures ultra-rapides.
• Bases orientées colonnes (Cassandra, HBase) : conçues pour gérer de très gros volumes de données réparties sur plusieurs serveurs.
• Bases orientées graphes (Neo4j) : modélisent les relations complexes entre entités (réseaux sociaux, recommandations).

Comment choisir entre SQL et NoSQL

Pour la grande majorité des SaaS, la réponse est simple : commencer avec une base relationnelle. Les données d’un SaaS — utilisateurs, abonnements, factures, projets — sont naturellement structurées et relationnelles. PostgreSQL est le choix le plus courant et pour de bonnes raisons : c’est un système mature, performant, très bien documenté et capable de gérer des millions d’enregistrements sans difficulté.

Les bases NoSQL prennent tout leur sens dans des contextes spécifiques : des données dont la structure change fréquemment, des volumes de lecture extrêmement élevés, ou des données hiérarchiques complexes. En pratique, la plupart des problèmes de performance qu’on attribue à SQL viennent de requêtes mal écrites ou d’index manquants, pas de la technologie elle-même.

Il est aussi courant de combiner les deux approches : une base relationnelle (PostgreSQL) pour les données métier critiques et une base clé-valeur (Redis) comme couche de cache pour les données fréquemment consultées.

Les concepts fondamentaux

Quelques notions sont essentielles pour comprendre comment une base de données fonctionne et pourquoi certaines décisions techniques ont un impact direct sur le produit.

Transactions ACID

Les transactions ACID garantissent la fiabilité des opérations. L’atomicité assure qu’une opération est exécutée en totalité ou pas du tout (on ne prélève pas l’argent sans enregistrer la commande). La cohérence garantit que les données restent valides après chaque opération. L’isolation empêche deux opérations simultanées de se marcher dessus. La durabilité assure que les données survivent même en cas de panne. Les bases SQL offrent ces garanties nativement, ce qui explique leur prédominance pour les opérations critiques (paiements, facturation).

Index

Les index sont des raccourcis que l’on crée pour accélérer les recherches. Chercher un utilisateur par email dans une table de 100 000 lignes sans index peut prendre plusieurs secondes. Avec un index sur la colonne email, la même recherche prend quelques millisecondes. C’est l’une des optimisations les plus simples et les plus efficaces — et l’une des plus souvent oubliées.

Attention cependant : chaque index ralentit légèrement les opérations d’écriture (insertion, mise à jour, suppression), car la base doit maintenir l’index à jour. Il faut indexer les colonnes fréquemment recherchées, pas toutes les colonnes sans distinction.

Migrations

Les migrations sont les modifications de structure de la base de données : ajouter une colonne, renommer un champ, créer une nouvelle table. Chaque migration est versionnée et traçable, ce qui permet à toute l’équipe de travailler sur la même structure et de déployer les changements de façon contrôlée. C’est une pratique essentielle pour maintenir la cohérence entre le code et la base de données, notamment dans un contexte de CI/CD.

Réplication et haute disponibilité

La réplication consiste à maintenir des copies de la base de données sur plusieurs serveurs. Cela permet d’assurer la continuité du service en cas de panne d’un serveur (haute disponibilité) et de répartir les lectures sur plusieurs instances pour améliorer les performances. Pour un SaaS qui vise une disponibilité de 99,9 %, la réplication est une brique indispensable de l’architecture logicielle.

Les erreurs qui coûtent cher

L’erreur la plus fréquente est le problème N+1 : au lieu de récupérer toutes les données nécessaires en une seule requête, le code les charge une par une dans une boucle. Avec 10 utilisateurs, c’est invisible. Avec 10 000, l’application devient inutilisable. La solution est de regrouper les requêtes (via des jointures en SQL ou du chargement anticipé dans un ORM).

Une autre erreur classique est l’absence de sauvegardes testées. Avoir un système de sauvegarde automatique, c’est bien. Vérifier régulièrement qu’on peut réellement restaurer ces sauvegardes, c’est indispensable. Trop d’équipes découvrent que leurs sauvegardes sont corrompues le jour où elles en ont besoin.

Le manque d’attention à la sécurité des données est une erreur aux conséquences potentiellement graves. Les injections SQL restent l’une des vulnérabilités les plus courantes : elles permettent à un attaquant de manipuler les requêtes pour accéder à des données sensibles ou les détruire. Utiliser un ORM ou des requêtes paramétrées élimine ce risque. Au-delà des injections, il faut aussi chiffrer les données sensibles au repos et en transit, et appliquer le principe du moindre privilège pour les accès à la base.

Enfin, beaucoup de projets sous-estiment l’importance du monitoring des requêtes lentes. Une requête qui met 200 millisecondes aujourd’hui peut en prendre 5 000 dans six mois quand le volume de données aura été multiplié par dix. Surveiller les performances en continu permet d’anticiper les problèmes au lieu de les subir.

Les bases de données managées dans le cloud

La plupart des SaaS modernes utilisent des bases de données managées hébergées dans le cloud plutôt que de gérer leurs propres serveurs. Des services comme Amazon RDS, Google Cloud SQL ou Supabase prennent en charge la maintenance, les mises à jour de sécurité, les sauvegardes automatiques et la réplication.

L’avantage principal est de libérer l’équipe technique pour qu’elle se concentre sur le produit plutôt que sur l’infrastructure. Le coût est prévisible et la scalabilité se gère en quelques clics. C’est le choix recommandé pour les startups et les équipes qui veulent avancer vite sans sacrifier la fiabilité.

Les outils pour travailler avec une base de données

Un ORM (Object-Relational Mapping) comme Prisma ou TypeORM traduit les requêtes en objets TypeScript, ce qui simplifie le développement et protège contre les injections SQL. C’est le choix recommandé pour la grande majorité des projets, même si quelques cas très spécifiques (requêtes analytiques complexes, performance critique) justifient d’écrire des requêtes manuellement.

Pour l’administration et l’exploration des données, des outils comme pgAdmin (PostgreSQL), DBeaver (multi-bases) ou TablePlus permettent de visualiser les tables, d’exécuter des requêtes et de surveiller les performances.

Pour le monitoring en production, des outils comme pg_stat_statements (PostgreSQL), Datadog ou New Relic permettent d’identifier les requêtes lentes, de suivre l’utilisation des ressources et de détecter les anomalies avant qu’elles n’impactent les utilisateurs.

Comment Polara Studio gère les bases de données

Chez Polara Studio, nous choisissons PostgreSQL par défaut pour les SaaS que nous construisons. C’est un choix qui tient la route de la première centaine d’utilisateurs jusqu’à plusieurs millions, sans avoir à changer de technologie en cours de route.

Nous utilisons Prisma comme ORM pour combiner la sécurité du typage TypeScript avec la simplicité des requêtes. Chaque changement de structure passe par une migration versionnée, testée en environnement de développement avant d’être déployée en production. Les sauvegardes sont automatisées quotidiennement avec possibilité de restauration à n’importe quel point dans le temps.

Côté performance, nous mettons en place des index dès la conception, surveillons les requêtes lentes via des alertes automatiques et utilisons Redis comme couche de cache pour les données fréquemment consultées (sessions, configurations, résultats de calculs coûteux). L’objectif est que la base de données ne soit jamais le maillon faible du produit — ni à 100 utilisateurs, ni à 100 000.