MongoDB cas d’usage et tutoriel pratique : démarrer en production

Lecture : 14 minutes · Niveau : développeur intermédiaire · Mise à jour : avril 2026

MongoDB n’est pas la base de données par défaut en 2026 — PostgreSQL l’est —, mais elle reste l’outil le plus pertinent pour des cas d’usage spécifiques : catalogues produits aux attributs variables, ingestion massive de logs ou events, schémas qui évoluent à chaque release, scaling horizontal natif. Ce tutoriel pratique couvre l’installation, le design de schéma documents, l’indexation, l’agrégation, le sharding, l’utilisation de MongoDB Atlas (managed officiel), et explicite quand choisir MongoDB plutôt que PostgreSQL JSONB — la frontière étant moins évidente qu’il y a 5 ans.

Pour le contexte stratégique global (familles BDD, choix), voir le pillar Bases de données PME.

Sommaire

1. Quand MongoDB est le bon choix
2. Installation MongoDB Community
3. MongoDB Atlas : la voie managée
4. Conception schéma documents
5. Indexation MongoDB
6. Agrégations et pipelines
7. Sharding pour scaling horizontal
8. Sécurité et backup
9. MongoDB vs PostgreSQL JSONB
10. Pièges fréquents
11. FAQ

1. Quand MongoDB est le bon choix

Cas d’usage adaptés.

Catalogue produits e-commerce hétérogène.
– Produits aux attributs variables selon catégorie (téléphone vs vêtement vs livre).
– Pas envie de table EAV en SQL ou de schéma sparse.
– MongoDB = un document par produit avec ses attributs propres.

Logs et events structurés.
– Ingestion massive (10 K+ events/sec).
– Format flexible (event types variés).
– Scale horizontal natif.

CMS avec contenus variables.
– Articles, pages, modules avec structures différentes.
– Évolution fréquente du modèle.

Profils utilisateurs riches.
– Données semi-structurées (préférences, historiques, addresses multiples).
– Lecture en une seule opération sans jointure.

Real-time analytics légères.
– Aggregations sur events récents.
– Time-series intégré (depuis MongoDB 5).

Quand MongoDB n’est PAS le bon choix.

• Données fortement relationnelles (commandes ↔ produits ↔ paiements ↔ stocks).
• Reporting complexe avec jointures multiples.
• Transactions multi-tables critiques (paiement, comptabilité).
• Volume modéré + besoin SQL → PostgreSQL JSONB suffit.

MongoDB en 2026 : versions et écosystème.
– MongoDB 7.x stable (production-ready).
– MongoDB 8.x (récent) : améliorations time-series, vector search, aggregation pipeline.
– MongoDB Atlas : managed, fortement intégré (search, vector search, charts, BI).
– Community Edition : self-hosted gratuit.

2. Installation MongoDB Community

Sur Ubuntu 24.04.

sudo apt update
sudo apt install -y wget gnupg
wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | sudo apt-key add -
echo "deb [arch=amd64,arm64] https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
sudo apt update
sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

Vérification.

mongosh --eval "db.version()"

Création utilisateur admin.

use admin;
db.createUser({
  user: "admin",
  pwd: passwordPrompt(),
  roles: [{ role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase"]
});

Activation auth.
Dans /etc/mongod.conf :

security:
  authorization: enabled
net:
  bindIp: 127.0.0.1  # ou IP privée VPC, JAMAIS 0.0.0.0 sans firewall

Redémarrer.

Création utilisateur application.

use monapp;
db.createUser({
  user: "monapp_user",
  pwd: passwordPrompt(),
  roles: [{ role: "readWrite", db: "monapp" }]
});

Connexion.

mongosh "mongodb://monapp_user@localhost/monapp" --authenticationDatabase monapp

3. MongoDB Atlas : la voie managée

Pourquoi Atlas pour PME.
– Free tier 512 MB.
– Backups automatiques.
– Monitoring intégré.
– Sharding et replication transparents.
– Atlas Search (full-text) intégré.
– Atlas Vector Search pour RAG.
– BAA disponible pour conformité.

Création cluster Atlas.
1. mongodb.com/cloud/atlas → créer compte.
2. Créer projet → Build a Cluster.
3. Choisir région (AWS Frankfurt ou Cape Town pour AO).
4. Tier : M0 free (512 MB), M10 dédié (~57 USD/mo).
5. Whitelist IP applicative.
6. Créer utilisateur DB.
7. Récupérer connection string.

Connection string typique.

mongodb+srv://user:pass@cluster0.xxxxx.mongodb.net/monapp?retryWrites=true&w=majority

Coût mensuel typique.
– M0 free : 512 MB, basique mais suffit MVP.
– M10 dédié : ~57 USD/mo, 10 GB, 2 vCPU.
– M20 : ~150 USD/mo, scaling production.
– M30+ : production sérieuse, > 250 USD/mo.

Atlas Search (full-text).
– Intégré, basé sur Lucene.
– Requêtes via $search dans aggregation.
– Évite besoin de Elasticsearch séparé pour cas modérés.

Atlas Vector Search (RAG).
– Stocke embeddings, requêtes par similarité.
– Concurrent avec Pinecone, Qdrant pour use cases IA.

4. Conception schéma documents

Principe MongoDB : modéliser selon les requêtes, pas selon l’entité. À l’inverse du SQL où on normalise puis on JOIN, en MongoDB on dénormalise selon les patterns d’accès.

Embedding vs Référence.

Embed (imbriquer) quand :
– Toujours lu ensemble.
– Fréquence mise à jour faible.
– Cardinalité limitée (dizaines max).
– Exemple : adresses dans profil utilisateur.

{
  _id: ObjectId("..."),
  name: "Aïssa Diop",
  email: "aissa@example.sn",
  addresses: [
    { type: "home", city: "Dakar", street: "..." },
    { type: "work", city: "Dakar", street: "..." }
  ]
}

Reference (référencer) quand :
– Lu indépendamment.
– Mise à jour fréquente du sous-document.
– Cardinalité large (milliers+).
– Exemple : commandes par utilisateur.

// users
{ _id: 1, name: "Aïssa" }

// orders
{ _id: 100, user_id: 1, total: 50000, ... }
{ _id: 101, user_id: 1, total: 32000, ... }

Patterns courants.

Bucket pattern pour time-series :

{
  _id: "device_42_2026-04-26",
  device: 42,
  date: ISODate("2026-04-26"),
  measurements: [
    { ts: ISODate("..."), temp: 24.5 },
    { ts: ISODate("..."), temp: 24.6 }
  ]
}

Subset pattern : embed les N derniers éléments fréquemment accédés, référence le reste.

Schema validation.

db.createCollection("products", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["name", "price"],
      properties: {
        name: { bsonType: "string" },
        price: { bsonType: "number", minimum: 0 },
        category: { bsonType: "string" }
      }
    }
  }
});

Validation NoSQL ≠ pas-de-validation : on impose les règles métier critiques au niveau base.

5. Indexation MongoDB

Types d’index.
– Single field : sur une colonne.
– Compound : multi-colonnes (ordre important).
– Multikey : sur arrays.
– Text : full-text basique.
– Geospatial : 2dsphere pour coordonnées.
– Hashed : sharding key.
– TTL : expiration automatique documents.

Création.

db.users.createIndex({ email: 1 }, { unique: true });
db.orders.createIndex({ user_id: 1, created_at: -1 });
db.products.createIndex({ name: "text", description: "text" });
db.events.createIndex({ created_at: 1 }, { expireAfterSeconds: 2592000 });  // 30j

Identifier index manquants.

db.orders.find({ user_id: 42 }).explain("executionStats");
// Si "stage": "COLLSCAN" -> index manquant

Compound index : ordre important.
– { user_id: 1, status: 1, created_at: -1 } couvre :
– Requêtes par user_id seul.
– Requêtes par user_id + status.
– Requêtes par user_id + status + tri created_at.
– Mais PAS les requêtes par status seul.

Index inutilisés.

db.collection.aggregate([{ $indexStats: {} }]);

6. Agrégations et pipelines

Pipeline d’agrégation : équivalent du SQL GROUP BY + jointures + transformations.

Exemple : revenus par catégorie le mois dernier.

db.orders.aggregate([
  { $match: {
      created_at: {
        $gte: ISODate("2026-03-01"),
        $lt: ISODate("2026-04-01")
      },
      status: "completed"
    }
  },
  { $unwind: "$items" },
  { $lookup: {
      from: "products",
      localField: "items.product_id",
      foreignField: "_id",
      as: "product"
    }
  },
  { $unwind: "$product" },
  { $group: {
      _id: "$product.category",
      total_revenue: { $sum: { $multiply: ["$items.qty", "$items.price"] } },
      order_count: { $sum: 1 }
    }
  },
  { $sort: { total_revenue: -1 } }
]);

Stages courants.
– $match : filtrer (équivalent WHERE).
– $group : grouper.
– $lookup : jointure (équivalent LEFT JOIN).
– $unwind : déplier array.
– $project : sélectionner / transformer champs.
– $sort, $limit, $skip : tri / pagination.
– $facet : agrégations parallèles dans une requête.

Performance.
– Mettre $match au début pour réduire dataset tôt.
– Indexer les champs $match et $sort.
– Utiliser explain() pour valider plan.

$lookup.
– Possible mais moins performant que JOIN SQL.
– À éviter sur volumes massifs : préférer dénormalisation.

7. Sharding pour scaling horizontal

Principe. Sharding distribue les données sur plusieurs serveurs (shards) selon une shard key. Permet de scaler horizontalement (vs verticalement = ajouter RAM/CPU au serveur).

Architecture sharded cluster.
– Shards : nœuds MongoDB stockant données (chacun replica set).
– Config servers : 3 nœuds stockant métadata cluster.
– mongos : routeur queries → shards.

Choisir la shard key.
– Doit avoir haute cardinalité (beaucoup de valeurs distinctes).
– Distribution équilibrée écritures.
– Permettre filtre efficace (queries ciblent peu de shards).
– Mauvais choix = hot spot ou jumbo chunks.

Exemples shard keys.
– { user_id: "hashed" } : distribue uniformément, écritures équilibrées, mais queries cross-shard fréquentes.
– { region: 1, user_id: 1 } : geo-localité, queries par région performantes.
– { created_at: 1 } : mauvais (toutes nouvelles écritures sur dernière partition = hot spot).

Activer sharding.

sh.enableSharding("monapp");
sh.shardCollection("monapp.events", { user_id: "hashed" });

Atlas vs self-hosted.
– Atlas : sharding transparent, opérations cluster auto.
– Self-hosted : opération complexe, prévoir compétence DBA.

Recommandation PME. Pas de sharding pour < 500 GB / < 50K req/s. Vertical scaling + replica suffit. Sharding = complexité à introduire seulement quand justifié.

8. Sécurité et backup

Sécurité.
– Auth obligatoire (scram-sha-256).
– TLS pour connexions.
– Network isolation (VPC, jamais 0.0.0.0).
– Roles minimaux (readWrite sur sa DB seulement).
– Audit logs (Enterprise / Atlas).
– Rotation mots de passe.

Field-level encryption.
– Client-Side Field Level Encryption (CSFLE).
– Permet de chiffrer champs sensibles (PII) côté client.
– Clés stockées hors MongoDB.

Backup.

mongodump (logique).

mongodump --uri="mongodb://user:pass@host/db" --out=/backup/$(date +%Y%m%d)

Restauration.

mongorestore --uri="mongodb://user:pass@host/db" /backup/20260426

Atlas backups.
– Continuous backup avec PITR : restoration n’importe quel moment.
– Snapshots cron-based.
– Cross-region.

Self-hosted production.
– Filesystem snapshots (LVM, ZFS).
– Replica set + delayed secondary.
– Test restoration trimestriel obligatoire.

9. MongoDB vs PostgreSQL JSONB

PostgreSQL JSONB couvre 80-90 % des cas MongoDB, avec en plus :
– Transactions ACID multi-documents.
– Jointures relationnelles efficaces.
– Plus standard, plus de devs disponibles.
– Plus simple opérationnellement (single-tier).

MongoDB l’emporte quand :
– Volume documents > 100M ou écritures > 10K ops/sec soutenues.
– Sharding horizontal vital.
– Schéma extrêmement évolutif et imprévisible.
– Profils JavaScript / Node.js fortement orientés document.
– Vector Search Atlas bien intégré pour RAG (mais pgvector progresse fort).

Tableau de décision.

Recommandation 2026. Démarrer PostgreSQL avec JSONB. Migrer ou ajouter MongoDB UNIQUEMENT avec un cas d’usage clair où PostgreSQL atteint ses limites mesurables. Hybride PostgreSQL + MongoDB possible mais double coût opérationnel.

10. Pièges fréquents

Schema anarchique. « NoSQL = pas de schéma » est faux : pas de schéma rigide, mais discipline indispensable. $jsonSchema validation au minimum.

Documents trop gros. Limite MongoDB : 16 MB par document. Approcher cette limite = mauvais design. Splitter en multiples documents avec références.

Jointures massives via $lookup. Performance dégrade vite. Préférer dénormaliser ou utiliser PostgreSQL.

Pas d’index. Coll scan à 1M documents = lenteur garantie. explain() systématique.

Shard key mal choisie. Hot spot ou jumbo chunks impossibles à corriger sans migration. Réfléchir longuement avant shardCollection.

Updates fréquents avec embed. Si sous-document mis à jour souvent, le rewrite complet du document = perf dégradée. Référencer plutôt qu’embed.

Atlas free tier en prod. M0 ne supporte pas la production sérieuse. Tier minimum production = M10 (57 USD/mo).

Pas de monitoring. Slow queries non identifiées, oplog overflow, replication lag = problèmes silencieux. mongoose-stats ou Atlas monitoring obligatoire.

Backup non testé. Comme partout : test trimestriel obligatoire.

Connexion non poolée. ORM mal configuré peut ouvrir trop de connexions. Mongoose / drivers : configurer pool size raisonnable.

Mongo 0.0.0.0 sans auth. Le scénario classique des leaks massifs 2017-2019 (« MongoDB exposed »). Bind sur localhost ou IP privée + auth obligatoire.

FAQ

MongoDB Atlas free tier suffit-il pour démarrer ?

Pour MVP / dev : oui (M0 = 512 MB). Pour production sérieuse : non, passer M10 (57 USD/mo) qui offre instance dédiée, snapshots, alertes. M0 est partagé et limite débit.

Quand passer de PostgreSQL à MongoDB ?

Quand vous mesurez des limites concrètes : tables JSONB de 100M+ rows lentes, schéma qui change toutes les semaines, scaling horizontal vital, écritures > 10K ops/s soutenues. Sinon, PostgreSQL JSONB est suffisant et plus simple opérationnellement.

MongoDB supporte-t-il les transactions ?

Oui depuis MongoDB 4.0 (multi-document) et 4.2 (cross-shard). Mais coût performance. Pour transactions intensives (paiement, compta), PostgreSQL reste plus optimal.

Combien coûte MongoDB en production ?

Atlas M10 : 57 USD/mo. M20 : 150 USD/mo. M30 : 280 USD/mo. Self-hosted : prix VPS (5-50 EUR/mois selon taille). Cluster sharded : multiplier par 3-6 selon nombre shards et replicas.

MongoDB est-il compatible Node.js / Python / autre ?

Oui, drivers officiels pour Node.js, Python, Java, .NET, Go, Rust, Ruby, PHP, Swift. Mongoose ORM populaire pour Node.js. Motor pour Python async.

Comment migrer de PostgreSQL à MongoDB ?

ETL custom : extraction PostgreSQL, transformation en documents, insertion MongoDB. Outils : Kafka Connect avec Debezium pour CDC. Toujours tester sur dataset représentatif avant prod.

Atlas Vector Search vs pgvector ?

Atlas Vector Search : intégré MongoDB, géré, performant, lié à l’écosystème Atlas. pgvector : extension PostgreSQL, gratuit, simple si déjà PostgreSQL en place. Choisir selon stack existante. Pinecone et Qdrant sont alternatives spécialisées.

MongoDB est-il bon pour analytics ?

Pour analytics légères (real-time aggregations sur events récents) : oui, $facet et pipelines puissants. Pour analytics lourdes (data warehouse) : préférer ClickHouse, Snowflake, BigQuery, ou DuckDB.

Articles liés (cluster Bases de données)

• 👉 Bases de données PME : guide complet
• 👉 PostgreSQL tutoriel production
• 👉 Redis cache et performance : tutoriel

Voir aussi : Node.js backend guide complet, Strapi headless CMS, TypeScript JavaScript moderne guide, Django backend Python guide.

Article mis à jour le 26 avril 2026. Pour signaler une erreur ou suggérer une amélioration, écrivez-nous.