Bases de données : au-delà du réflexe SQL

Encore aujourd'hui, une grande majorité de développeurs ne jurent que par les bases SQL. C'est ce qu'on leur a appris en école, c'est ce qu'ils retrouvent dans la plupart des entreprises. Pourtant, depuis une quinzaine d'années, le paysage des bases de données s'est considérablement élargi. Et certains de ces choix peuvent avoir un impact direct sur la productivité de vos équipes.

Les familles de bases de données

Le réflexe naturel est de tout mettre dans une seule base. En réalité, la plupart des produits matures combinent au moins deux de ces familles, chacune pour ce qu'elle sait faire de mieux.

Bases relationnelles : solides mais pas universelles

PostgreSQL, MySQL, MariaDB. Ce sont les piliers historiques. Elles excellent quand votre modèle de données est très structuré, que les relations entre entités sont nombreuses et que vous avez besoin de transactions ACID (atomicité, cohérence, isolation, durabilité). Pour un système bancaire ou un ERP, c'est souvent le bon choix.

En revanche, il y a un point de friction que tout développeur backend connaît bien : le décalage entre le modèle objet de votre code et la structure en tables de votre base. Vous pensez en termes d'objets métier dans votre code — un utilisateur avec ses préférences, ses commandes, ses adresses — et vous devez ensuite découper tout ça en tables séparées reliées par des clés étrangères. Ce va-et-vient constant entre deux logiques de modélisation est contre-intuitif et consomme un temps considérable, même avec un bon ORM. C'est d'ailleurs ce qui a poussé de nombreux frameworks à développer des couches d'abstraction de plus en plus épaisses, avec la complexité que ça implique.

Bases document : la DX comme accélérateur

C'est probablement la famille qui a le plus progressé ces dix dernières années. MongoDB en tête, les bases document permettent de stocker directement des objets JSON. Votre modèle métier dans le code devient un document dans la base, sans transformation intermédiaire.

Chez Wizbii, nous avons fait le choix de MongoDB comme base principale dès le départ. Quand j'ai quitté l'entreprise, nous en étions à 9 nœuds en production et ça tournait comme un charme. Mais le plus frappant n'était pas la scalabilité technique : c'était l'impact sur les équipes. Tous les développeurs qu'on a embauchés — et certains ne juraient que par les bases SQL — ont très vite changé d'avis. La simplicité des concepts, la rapidité de prise en main, l'alignement naturel avec le code... Au bout de quelques semaines, aucun n'aurait voulu revenir en arrière.

Les bases NoSQL ont aussi longtemps souffert d'une réputation de "pas sérieuses" côté garanties de données. C'est de moins en moins vrai. MongoDB supporte les transactions multi-documents depuis plusieurs versions et offre des mécanismes de réplication solides. Les lacunes historiques se comblent progressivement, pendant que l'avantage en expérience développeur reste intact.

Bases de graphe : attention à l'effet de mode

Les bases de graphe (Neo4j, ArangoDB) ont un cas d'usage légitime : quand les relations entre vos données sont le cœur de votre produit. Réseaux sociaux, moteurs de recommandation, détection de fraude dans des réseaux complexes. Dans ces contextes, elles sont redoutablement efficaces.

Le problème, c'est que j'ai vu plusieurs startups partir sur des bases de graphe simplement parce que c'était à la mode. Elles se sont retrouvées avec des requêtes d'une complexité folle et des problèmes de performance qu'elles n'avaient pas anticipés. En réalité, elles utilisaient leur base de graphe comme un mix entre du relationnel et du NoSQL — sans jamais exploiter ce qui fait la vraie force de ce type de base. Et changer de base de données à chaud, c'est toujours un chantier douloureux. Ça n'a pas raté : elles ont toutes perdu un temps considérable ensuite. Bien choisir sa base au démarrage reste un sujet critique, même dans des approches Agile où le changement régulier est pourtant la règle sur beaucoup d'autres aspects.

Clé-valeur et cache : le complément indispensable

Redis est devenu un standard de fait. Cache applicatif, gestion de sessions, files d'attente, rate limiting... C'est rarement votre base principale mais c'est presque toujours un complément nécessaire dès que votre produit prend de l'ampleur. Sa force, c'est sa vitesse : tout est en mémoire. Son coût est faible, sa mise en place rapide, et l'impact sur les performances de votre application est souvent spectaculaire.

Moteurs de recherche : savoir déléguer

Faire de la recherche full-text dans une base généraliste, c'est possible. C'est surtout un calvaire dès que vous avez des volumes ou des besoins de pertinence un minimum avancés.

Chez Wizbii, on s'en est rendu compte assez vite : la recherche dans MongoDB n'avait aucun sens à notre échelle. On a basculé sur Elasticsearch. C'est un outil puissant mais exigeant : dur à maintenir en production, complexe à configurer pour des données multilingues, et surtout ce n'était pas notre métier. On a fini par migrer vers Algolia, une solution managée. Ça coûte de l'argent chaque année, mais ça permet aux équipes de se concentrer sur ce qu'elles maîtrisent le mieux et de laisser de côté ce qui ne leur sert pas. Un arbitrage classique entre le build et le buy, qu'il vaut mieux faire tôt que tard.

Séries temporelles : pas toujours besoin d'une base dédiée

InfluxDB, TimescaleDB, QuestDB... Les bases de séries temporelles ont le vent en poupe avec l'IoT et le monitoring. Mais avant de foncer, posez-vous la question de ce dont vous avez réellement besoin.

Chez Winter, nous gérons des séries temporelles. Il existe plein de bases spécialisées pour ça, mais elles ne sont généralement pas bonnes pour gérer les autres types de données. On s'est posé la question différemment : qu'est-ce qu'une série temporelle dans notre contexte ? De quoi a-t-on réellement besoin ? Quels types de requêtes va-t-on faire ? On s'est rendu compte qu'un simple tableau stocké dans un document MongoDB allait suffire. Si la série grossit, on en fait une sorte de liste chaînée de tableaux. C'est tout. Pas besoin d'une base dédiée, pas de nouvelle technologie à maintenir, pas de compétence supplémentaire à recruter.

Le vrai sujet : choisir selon son contexte

Aucune base de données ne permet de tout faire. Et c'est précisément pour ça que le choix est important. Il dépend de votre modèle de données, du volume attendu, des compétences de votre équipe, et de ce que vous êtes prêt à maintenir sur le long terme.

Quelques principes qui fonctionnent :

• Commencez simple. Une base document ou relationnelle couvre 80% des besoins d'une startup. Ne rajoutez une technologie que quand la douleur est réelle, pas parce que c'est à la mode.
• Pensez DX. La base qui rend vos développeurs productifs et heureux a un impact direct sur votre vélocité. Ne sous-estimez pas ce critère, surtout en phase de construction d'équipe.
• Déléguez ce qui n'est pas votre métier. Elasticsearch, c'est bien. Algolia, ça coûte plus cher mais ça vous libère du temps. Ce temps, il vaut de l'argent. Ce même raisonnement s'applique à votre choix d'hébergement.
• Anticipez la migration. Si vous partez sur une base exotique, demandez-vous comment vous en sortirez. Les changements de base à chaud sont parmi les chantiers les plus coûteux et les plus risqués qu'une équipe technique puisse affronter.

Le bon choix de base de données, c'est celui qui colle à votre réalité d'aujourd'hui tout en ne vous enfermant pas pour demain. C'est rarement la techno la plus récente ou la plus populaire. C'est celle qui permet à votre équipe d'avancer vite, en confiance.