Quelle base de données choisir pour une application web ?
Pour un outil métier ou un espace client, la réponse est presque toujours PostgreSQL. C’est la base relationnelle open source la plus complète du marché : elle gère les transactions, les contraintes d’intégrité, les requêtes complexes et pèse zéro euro de licence. MySQL reste populaire mais PostgreSQL la surpasse sur les fonctionnalités avancées depuis plusieurs versions. Les bases NoSQL comme MongoDB ont leur intérêt pour des cas précis (données très hétérogènes, volumes massifs), mais pour une application métier standard, elles ajoutent de la complexité sans bénéfice réel.
Le seul cas où on s’écarte de PostgreSQL : une application très simple, quasi-statique, où SQLite suffit largement (pas de connexions simultanées, données légères). Au-delà de quelques utilisateurs concurrents ou dès qu’on a des relations entre entités, PostgreSQL s’impose.
Modélisation : la décision la plus structurante du projet
Avant d’écrire la première ligne de code, le schéma de base de données doit être pensé sérieusement. Une modélisation bâclée se paie cash plus tard : requêtes lentes, migrations douloureuses, bugs difficiles à corriger sans tout réécrire. Les erreurs classiques sont les tables fourre-tout avec des colonnes génériques, l’absence de clés étrangères, ou des données JSON stockées là où des colonnes typées feraient le travail proprement.
Concrètement, pour un espace client avec commandes, factures et utilisateurs, on identifie d’abord les entités (client, commande, produit, facture), puis les relations entre elles (un client a plusieurs commandes, une commande contient plusieurs lignes). On normalise jusqu’au troisième niveau en général, sans aller plus loin au risque de complexifier les requêtes. Ce travail de modélisation représente typiquement une journée de travail sur un projet moyen, mais elle conditionne la qualité de tout ce qui vient après.
Hébergement : options et budget réel
Trois grandes familles d’hébergement coexistent. Les bases managées cloud (Supabase, Railway, Neon, Amazon RDS, Render) facturent à l’usage ou à l’abonnement mensuel : de zéro à quelques dizaines d’euros par mois pour un projet de taille modeste, avec sauvegardes automatiques et mises à jour gérées. C’est la solution par défaut pour la majorité des projets, car elle supprime la charge opérationnelle.
L’hébergement sur un VPS dédié (Hetzner, OVH, Contabo) coûte quelques euros à une quinzaine d’euros par mois pour un serveur correctement dimensionné, mais demande une configuration et une maintenance manuelle : sauvegardes, mises à jour de sécurité, monitoring. Pertinent quand on maîtrise le sujet ou qu’on veut regrouper plusieurs services sur la même machine. Enfin, les plateformes comme Heroku ou PlanetScale ciblent la simplicité maximale avec des tarifs plus élevés en contrepartie.
Pour un projet standard, l’hébergement de la base se compte en dizaines d’euros par mois, selon le volume de données et le trafic. Ce coût reste stable si l’application est bien conçue.
Ce qui fait vraiment varier le budget global
Selon mes estimations du marché (juin 2026, pas une étude), une application web avec base de données se situe entre 5 000 et 20 000 euros, parfois davantage pour des projets complexes. Chez moi, elle démarre à 1 900 €. Plusieurs facteurs déplacent l’aiguille de façon significative.
La complexité du schéma de données est le premier levier : une application avec 5 entités simples n’a rien à voir avec un outil gérant des workflows métier, des droits d’accès granulaires et des historiques d’audit. La gestion des migrations (faire évoluer la base sans perdre les données existantes) représente un travail récurrent souvent sous-estimé. Les intégrations avec des services tiers (paiement, email, API partenaires) ajoutent aussi du temps. Un projet avec authentification, gestion des rôles, exports PDF et notifications mail coûtera nettement plus qu’un CRUD basique.
Travailler avec un freelance plutôt qu’une agence allège ces budgets. Pas de frais de structure, pas d’intermédiaires : le devis reflète le travail réel. L’interlocuteur qui conçoit la base de données est le même qui code l’application et répond aux questions.
Pièges fréquents à éviter
Le piège le plus courant est de commencer à coder avant d’avoir un schéma validé. Refactorer une base de données avec des données réelles en production est une opération risquée et coûteuse. Une session de travail en amont sur la modélisation, même de deux ou trois heures, évite des semaines de corrections.
Autre erreur classique : ne pas prévoir de système de migrations dès le départ. Des outils comme Prisma Migrate ou Flyway permettent de versionner les changements de schéma exactement comme on versionne le code. Sans ça, les mises à jour en production deviennent des opérations artisanales et risquées.
Les sauvegardes sont aussi souvent traitées comme secondaires jusqu’au jour où elles deviennent la seule bouée de sauvetage. Sur un hébergement managé, elles sont automatiques. Sur un VPS, elles doivent être configurées explicitement, testées, et stockées à un endroit distinct du serveur principal.
