Bases de données : définition, fonctionnement et typologie

Réserver un billet d'avion, consulter un dossier médical, payer en ligne, faire défiler un fil d'actualité : à chaque fois, une base de données travaille en coulisses. On ne la voit jamais, mais sans elle, plus rien ne tient. Derrière le sigle « BDD » se cache la brique la plus discrète et la plus structurante de l'informatique moderne (celle qui stocke, organise et restitue la donnée à la demande).

Le terme recouvre pourtant des réalités très différentes. Une base relationnelle vieille de cinquante ans et une base vectorielle taillée pour l'IA générative n'ont presque rien en commun, sinon le nom. Tour d'horizon : ce qu'est une base de données, comment elle fonctionne, et la galaxie de modèles qui se cache derrière le mot.

Qu'est-ce qu'une base de données ?

Une base de données est une collection d'informations organisées pour être stockées, consultées et mises à jour facilement. La définition tient en une phrase, mais le mot qui compte, c'est « organisées ». Une pile de fichiers en vrac n'est pas une base de données. 

Une base, elle, range la donnée selon une structure rigoureuse (le plus souvent en lignes, colonnes et tables) et l'indexe pour la retrouver en une fraction de seconde.

C'est précisément ce qui la sépare d'un simple tableur. Excel stocke des données ; une base de données les gère : accès simultané de milliers d'utilisateurs, intégrité garantie, volumétrie sans commune mesure. 

Là où un tableur plie sous quelques dizaines de milliers de lignes, une base encaisse des milliards d'enregistrements sans broncher.

On en trouve partout : réservations des compagnies aériennes, dossiers patients des hôpitaux, catalogues e-commerce, transactions bancaires, registres d'assurance. 

Dès qu'une organisation manipule de la donnée à grande échelle, une base de données tourne quelque part.

Comment fonctionne une base de données ?

Sur le disque, une base de données n'est jamais qu'un fichier (ou, le plus souvent, un ensemble de fichiers) organisés en champs (la plus petite unité d'information), enregistrements (un ensemble de champs) et tables. Ce qui change tout, c'est la couche logicielle posée par-dessus : le système de gestion de base de données, ou SGBD (DBMS en anglais).

Le SGBD est le chef d'orchestre. C'est lui qui lit, écrit, modifie et sécurise la donnée, qui arbitre quand deux utilisateurs veulent toucher au même enregistrement en même temps, et qui veille à ce que rien ne se perde en cas de panne. PostgreSQL, MySQL, Oracle Database ou MongoDB sont des SGBD, pas des bases de données à proprement parler ; la nuance compte.

Avant d'écrire la moindre donnée, on définit en général un schéma : le plan de la base, qui décrit les tables, leurs champs et les relations entre elles. Certaines bases l'imposent strictement, comme le relationnel ; d'autres s'en affranchissent, comme une bonne partie du NoSQL. Et pour les bases transactionnelles, la fiabilité porte un nom : les propriétés ACID.

Beaucoup de bases NoSQL relâchent volontairement ces garanties pour gagner en vitesse et en scalabilité. C'est un arbitrage assumé, pas un défaut : tout dépend de ce qu'on a le droit de perdre.

Les différents types de bases de données

Classer les bases de données n'a rien d'un exercice scolaire : le modèle retenu décide de ce que l'on pourra faire (ou pas) avec la donnée. 

On peut les trier par contenu (texte, chiffres, images), mais l'approche qui compte en informatique reste l'approche organisationnelle. Voici les grandes familles, des ancêtres aux dernières venues.

Les ancêtres : hiérarchique et réseau

La base hiérarchique organise la donnée en arbre : chaque enregistrement dépend d'un seul parent, comme les branches d'un tronc. Simple, rapide, mais rigide. C'est le modèle des systèmes IBM des années 1960-70, aujourd'hui largement remisé.

La base réseau lève cette contrainte : un objet peut avoir plusieurs parents et plusieurs enfants. Plus proche du monde réel, plus souple, mais aussi plus complexe à maintenir. Formalisée par le consortium CODASYL, elle a connu son heure de gloire dans les années 1970.

Le relationnel, toujours sur le trône

C'est la base de données par défaut depuis un demi-siècle. Imaginé par E. F. Codd en 1970 et fondé sur l'algèbre relationnelle, ce modèle range la donnée dans des tables liées entre elles par des clés. On l'interroge en SQL (Structured Query Language), le langage qui reste, aujourd'hui encore, la compétence socle de tout métier de la donnée.

Sa force : une donnée structurée, cohérente, sans redondance, qu'on peut croiser dans tous les sens. PostgreSQL, MySQL, MariaDB, Oracle Database et Microsoft SQL Server se partagent l'essentiel du terrain. Tant que la donnée est bien structurée et que la cohérence prime, le relationnel reste difficile à battre.

La galaxie NoSQL

Le Big Data a fait sauter un présupposé du relationnel : et si la donnée n'avait pas de structure fixe ? Les bases NoSQL (« not only SQL ») répondent à ça. Elles encaissent d'énormes volumes, se répartissent sur des grappes de serveurs et acceptent des données non structurées ou semi-structurées. 

Derrière l'étiquette, plusieurs familles cohabitent :

• Orientée document : la donnée vit dans des objets autonomes, souvent du JSON, un par entité. Idéale pour un catalogue produit où chaque article a ses propres attributs. MongoDB, Couchbase.

• Clé-valeur et en mémoire : un dictionnaire géant, où chaque valeur se récupère par sa clé. Quand tout vit dans la RAM plutôt que sur disque, l'accès devient quasi instantané (parfait pour le cache ou les sessions). Redis en est l'archétype.

• Orientée colonnes (« wide-column ») : taillée pour écrire et lire à très grande échelle. Cassandra, HBase.

• Orientée graphe : elle stocke moins les données que les relations entre elles, via la théorie des graphes. Le moteur des réseaux sociaux et des systèmes de recommandation. Neo4j.

Les nouvelles venues : vectorielles et time-series

Deux familles ont pris une place qu'elles n'occupaient pas il y a cinq ans. La base vectorielle est l'enfant de l'IA générative. Elle stocke des embeddings (des représentations numériques de texte, d'images ou de son) et retrouve les éléments les plus proches par similarité, et non par correspondance exacte. 

C'est la colonne vertébrale du RAG et de la recherche sémantique. Pinecone, Milvus, Qdrant, ou l'extension pgvector qui greffe ces capacités directement sur PostgreSQL.

La base time-series, elle, est optimisée pour la donnée horodatée qui arrive en flot continu : métriques d'infrastructure, capteurs IoT, cours financiers. Là où une base classique souffre, elle ingère des millions de points par seconde. InfluxDB, TimescaleDB, Prometheus.

Où vivent les données : du serveur sur site au cloud

Un dernier axe, transversal celui-là, ne concerne pas le modèle mais l'emplacement. Une base distribuée éclate ses données sur plusieurs sites physiques, répliquées ou réparties sur un réseau, pour la performance et la tolérance aux pannes. 

Une base cloud tourne dans un environnement virtualisé, public, privé ou hybride : on paie l'usage, on monte en charge à la demande, on délègue l'infrastructure. C'est devenu le mode de déploiement par défaut, via des services managés comme Amazon RDS, Google BigQuery ou Azure Cosmos DB.

Data warehouses, data lakes : quand la donnée change d'échelle

De plus en plus, les bases ne vivent plus isolées : on les regroupe pour analyser. L'entrepôt de données (data warehouse) centralise des données déjà structurées, prêtes pour le reporting (Snowflake, BigQuery, Redshift). Le lac de données (data lake) fait l'inverse : il stocke la donnée brute, dans son format d'origine, en attendant qu'on sache quoi en faire. 

Entre les deux, le lakehouse tente la synthèse. Trois réponses à une même question : comment exploiter des téraoctets sans s'y noyer ?

Côté carrière : quelles compétences bases de données s'arrachent en 2026 ?

Pour un professionnel de l'IT, tout cela n'est pas que de la théorie : la maîtrise des bases de données reste l'une des compétences les plus monnayables du marché. Mais le métier a bougé.

L'administrateur de base de données (DBA) classique, celui qui veillait sur un serveur Oracle ou SQL Server, n'a pas disparu, mais il glisse vers des rôles plus larges : data engineer, ingénieur plateforme, expert en bases managées. 

Le cloud a déplacé le travail de la maintenance bas niveau vers la conception, l'optimisation des coûts et la performance à grande échelle.

Quelques repères pour qui veut se positionner :

• SQL reste non négociable. C'est l'alphabet de la donnée ; aucun métier data ne s'en passe.

• La double culture SQL / NoSQL fait la différence. Savoir quand sortir du relationnel (et pourquoi) vaut cher.

• Les compétences cloud (PostgreSQL managé, BigQuery, Cosmos DB) sont passées du bonus au prérequis.

• La vague qui monte : les bases vectorielles. Avec l'explosion du RAG et des applications d'IA, savoir concevoir et alimenter une base vectorielle devient un vrai différenciateur.

Le constat est simple : la donnée ne manque pas. Ce sont les profils capables de la dompter qui manquent.

Un demi-siècle, et toujours au centre du jeu

D'un arbre hiérarchique des années 1960 à une base vectorielle qui alimente un agent conversationnel, les bases de données ont traversé cinquante ans sans jamais quitter le centre du jeu. Le mot est resté ; la réalité technique, elle, n'a plus grand-chose à voir.

Ce qui ne change pas, c'est la question posée à chaque projet : quelle structure pour quelle donnée, quel usage, quelle échelle ? Le bon modèle n'est jamais le plus récent ni le plus à la mode ; c'est celui qui colle au problème. Et à mesure que l'IA réécrit les usages, cette question, loin de se simplifier, n'a jamais été aussi ouverte.

👉 La donnée recrute, et plus fort qu'avant. Découvrez les offres d'emploi en bases de données, SQL, NoSQL et data engineering sur Free-Work. 

Questions fréquentes sur les bases de données

Quelle est la différence entre une base de données et un tableur ?

Un tableur comme Excel stocke des données dans une grille ; une base de données les gère. La différence se joue sur trois terrains : la volumétrie (des milliards d'enregistrements contre quelques milliers de lignes), les accès simultanés (des milliers d'utilisateurs en même temps sans corruption) et l'intégrité (des règles qui empêchent la donnée incohérente d'entrer).

SQL ou NoSQL : comment choisir ?

La question n'est pas « lequel est le meilleur », mais « lequel pour quel besoin ». Le relationnel (SQL) s'impose quand la donnée est structurée, que la cohérence prime et que les transactions doivent être fiables (facturation, comptabilité, gestion de stock). Le NoSQL prend l'avantage sur les gros volumes, la donnée non structurée et le besoin de monter en charge horizontalement (catalogues, flux temps réel, données distribuées). Beaucoup d'architectures modernes combinent les deux plutôt que de trancher.

Comment créer une base de données ?

Tout part de la modélisation. On identifie d'abord les entités (clients, commandes, produits…) et leurs attributs, puis on les répartit dans des tables reliées par des clés, en évitant la redondance ; c'est le rôle de la normalisation. Vient ensuite le choix du SGBD, qui dépend du type de donnée, du volume et du mode de déploiement. 

Quels outils pour gérer une base de données ?

La gestion repose sur le système de gestion de base de données (SGBD) : PostgreSQL, MySQL, Oracle Database ou Microsoft SQL Server côté relationnel, MongoDB, Redis ou Cassandra côté NoSQL. À cela s'ajoutent des clients d'administration (pgAdmin, DBeaver, MySQL Workbench) pour écrire des requêtes et inspecter la structure, et, en production, des outils de supervision et de sauvegarde. Dans le cloud, des services managés comme Amazon RDS ou Google BigQuery prennent en charge l'essentiel de l'exploitation.

Quelle base de données choisir en 2026 ?

Il n'existe pas de « meilleure » base de données dans l'absolu, seulement la plus adaptée à un cas d'usage. PostgreSQL fait figure de couteau suisse du relationnel et s'impose comme un choix par défaut solide. MongoDB domine le document, Redis le cache et la vitesse, Neo4j les données très connectées, et les bases vectorielles comme Pinecone ou pgvector s'imposent dès qu'un projet touche à l'IA générative. 

Qu'est-ce qu'une base de données vectorielle ?

C'est une base conçue pour l'IA. Plutôt que de stocker du texte ou des chiffres bruts, elle stocke des embeddings : des représentations numériques du sens d'un contenu. Elle ne cherche pas une correspondance exacte mais les éléments les plus proches par similarité, ce qui en fait le moteur de la recherche sémantique et du RAG (génération augmentée par récupération).