MongoDB : les bases du NoSQL

Les bases de données relationnelles règnent depuis des décennies. Mais quand les données deviennent hétérogènes, volumineuses et que le schéma change tous les sprints, le modèle SQL montre ses limites. C’est là que MongoDB entre en scène : une base de données orientée documents, flexible, scalable, et omniprésente dans les stacks modernes.

En DevOps, tu croiseras MongoDB partout — dans les logs centralisés, les configurations dynamiques, les catalogues produits, ou les plateformes IoT. Comprendre ses fondamentaux, c’est un passage obligé.

🎯 Objectifs de la leçon

• Comprendre la différence fondamentale entre SQL et NoSQL
• Savoir quand choisir MongoDB plutôt qu’une base relationnelle
• Maîtriser les concepts clés : documents, collections, bases de données
• Installer MongoDB avec Docker en quelques minutes

SQL vs NoSQL : deux philosophies, deux usages

Avant de plonger dans MongoDB, il faut comprendre pourquoi il existe. Le modèle relationnel (SQL) organise les données en tables rigides : colonnes fixes, types stricts, relations via des clés étrangères. C’est puissant, éprouvé, mais parfois inadapté.

L’analogie du classeur : imagine SQL comme un tableur Excel — chaque ligne a exactement les mêmes colonnes. Si tu ajoutes un champ, il s’applique à toutes les lignes. MongoDB, c’est plutôt un classeur de fiches cartonnées : chaque fiche peut avoir des champs différents. Une fiche “t-shirt” a taille et couleur, une fiche “laptop” a processeur et ram. Même classeur, structures différentes.

Voici un exemple concret de cette rigidité SQL. Pour stocker des utilisateurs et leurs commandes, il faut deux tables distinctes reliées par une clé étrangère :

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL
);

CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER REFERENCES users(id),
    total DECIMAL(10, 2),
    status VARCHAR(20)
);

En MongoDB, la même information tient dans un seul document. L’utilisateur, son adresse et ses commandes sont regroupés naturellement, sans jointure :

{
  "_id": "ObjectId('507f1f77bcf86cd799439011')",
  "name": "Alice",
  "email": "alice@example.com",
  "address": {
    "street": "Rue du Marché 15",
    "city": "Lausanne"
  },
  "orders": [
    {"product": "Clavier mécanique", "price": 149.90},
    {"product": "Souris ergonomique", "price": 89.00}
  ]
}

Quand choisir quoi ?

Choisis SQL quand tes données ont une structure fixe, que tu as besoin de transactions ACID strictes (banque, finance), et que les relations entre entités sont complexes (many-to-many).

Choisis MongoDB quand tes données sont hétérogènes, quand le schéma évolue souvent, quand tu dois scaler horizontalement, ou quand tes documents sont autonomes (pas besoin de jointures complexes).

🧠 À retenir : MongoDB ne remplace pas SQL. En production, beaucoup d’entreprises utilisent les deux : PostgreSQL pour les transactions critiques, MongoDB pour les données flexibles (logs, contenus, profils).

🔥 Cas réel en entreprise : Une plateforme e-commerce utilise PostgreSQL pour les paiements et la comptabilité (ACID obligatoire), mais MongoDB pour son catalogue produit — parce qu’un t-shirt, un livre et un ordinateur n’ont pas les mêmes attributs, et le catalogue change chaque semaine.

Les concepts fondamentaux de MongoDB

MongoDB organise les données en trois niveaux hiérarchiques, chacun ayant son équivalent SQL :

Le document : l’unité de base

Un document MongoDB est un objet JSON (techniquement BSON — Binary JSON) avec des paires clé-valeur. Il peut contenir des sous-documents, des tableaux, des dates, et bien d’autres types :

{
  "_id": "ObjectId('65a1b2c3d4e5f6a7b8c9d0e1')",
  "name": "Serveur Web",
  "type": "nginx",
  "config": {
    "port": 443,
    "ssl": true,
    "workers": 4
  },
  "tags": ["production", "europe-west"],
  "created_at": "ISODate('2026-01-15T10:30:00Z')"
}

Chaque document possède un champ _id unique. Si tu n’en fournis pas à l’insertion, MongoDB en génère un automatiquement sous forme d’ObjectId — un identifiant de 12 octets qui contient un timestamp, un identifiant machine et un compteur.

La collection : flexible mais disciplinée

Une collection regroupe des documents similaires. Contrairement à une table SQL, elle n’impose aucun schéma : deux documents de la même collection peuvent avoir des champs complètement différents. C’est la force de MongoDB — et aussi son piège si tu ne te disciplines pas.

⚠️ Attention : La flexibilité du schéma ne signifie pas « pas de schéma ». En production, utilise toujours la validation de schéma MongoDB ($jsonSchema) pour garantir un minimum de structure. Sans ça, ta collection devient un bazar ingérable en quelques mois.

Installation avec Docker

La méthode la plus propre pour démarrer avec MongoDB en local, c’est Docker Compose. On lance une instance MongoDB 7.0 avec des credentials d’admin et un volume persistant pour ne pas perdre les données au redémarrage.

Crée un fichier docker-compose.yml avec la configuration suivante :

services:
  mongodb:
    image: mongo:7.0
    container_name: mongodb
    environment:
      MONGO_INITDB_ROOT_USERNAME: admin
      MONGO_INITDB_ROOT_PASSWORD: secret123
    ports:
      - "27017:27017"
    volumes:
      - mongo_data:/data/db

volumes:
  mongo_data:

Puis lance le conteneur et vérifie qu’il tourne correctement :

docker compose up -d
docker ps
# Tu dois voir : mongo:7.0 / Up / 0.0.0.0:27017->27017/tcp

💡 Tip DevOps : En production, ne mets jamais le mot de passe en clair dans le docker-compose.yml. Utilise des secrets Docker, des variables d’environnement injectées par ton CI/CD, ou un gestionnaire de secrets comme Vault.

Premiers pas avec mongosh

mongosh est le shell interactif de MongoDB. C’est ton outil principal pour explorer, requêter et administrer une instance MongoDB. Pour y accéder, entre dans le conteneur puis lance le shell avec les credentials admin :

docker exec -it mongodb bash
mongosh -u admin -p secret123

Tu arrives sur le prompt test> — c’est la base de données par défaut. Voici les commandes de navigation essentielles :

show dbs              // Lister les bases de données
use myapp             // Créer/changer de base (créée au premier insert)
show collections      // Lister les collections de la base active
db.stats()            // Statistiques de la base courante
exit                  // Quitter mongosh

Une particularité de MongoDB : une base de données n’existe réellement que quand elle contient au moins un document. use myapp ne crée rien sur le disque — c’est le premier insert qui matérialise la base.

Importer un dataset de test

Pour s’exercer avec des vraies données, importons un dataset de villes américaines (29 000+ documents). Depuis le terminal de l’hôte (pas dans mongosh), télécharge le fichier puis injecte-le dans MongoDB :

curl -o zips.json https://dst-de.s3.eu-west-3.amazonaws.com/mongo_fr/zips.json
docker cp zips.json mongodb:/tmp/zips.json
docker exec -it mongodb mongoimport \
  -d myapp -c zips \
  --authenticationDatabase admin \
  -u admin -p secret123 \
  --file /tmp/zips.json

Tu devrais voir 29470 document(s) imported successfully. Tu as maintenant une vraie collection pour pratiquer les requêtes dans le chapitre suivant.

Bonnes pratiques et pièges à éviter

Nommage des collections : utilise le pluriel en snake_case (users, server_configs, deploy_logs). Reste cohérent dans tout le projet.

Modélisation : en MongoDB, la règle d’or c’est « ce qui est lu ensemble est stocké ensemble ». Si tu affiches toujours un utilisateur avec son adresse, embarque l’adresse dans le document utilisateur plutôt que de créer une collection séparée.

Taille des documents : MongoDB limite un document à 16 Mo. Ça paraît beaucoup, mais si tu embarques des tableaux qui grandissent sans limite (logs, historique), tu atteindras la limite. Prévois une stratégie de rotation.

⚠️ Attention : Ne tombe pas dans le piège du « tout embedded ». Si une donnée est partagée entre plusieurs documents (ex: une catégorie référencée par 10 000 produits), utilise une référence (category_id) plutôt que de dupliquer la catégorie partout. Sinon, une mise à jour devient un cauchemar.

🔥 Cas réel en entreprise : Une startup SaaS stockait les logs applicatifs directement dans les documents utilisateurs (tableau embedded). Au bout de 6 mois, certains documents dépassaient 10 Mo, les requêtes étaient lentes, et les backups explosaient. La solution : une collection logs séparée avec un index sur user_id et un TTL index pour la rotation automatique.

Résumé

MongoDB est une base de données orientée documents qui stocke des objets JSON flexibles dans des collections sans schéma imposé. Elle excelle quand les données sont hétérogènes, le schéma évolutif, ou le volume massif.

🧠 À retenir : SQL et MongoDB sont complémentaires, pas concurrents. MongoDB organise ses données en Database → Collection → Document. L’installation avec Docker Compose prend 2 minutes. Et surtout : flexibilité ne veut pas dire anarchie — impose toujours un minimum de structure à tes collections.

➡️ La suite : Chapitre 2 — CRUD et requêtes MongoDB