MongoDB expliqué (2026) : ce que c'est, comment il fonctionne et quand l'utiliser

MongoDB est devenue le choix par défaut des développeurs qui créent des applications modernes qui ne s’intègrent pas facilement dans des lignes et des colonnes. En 2026, ce n’est plus seulement une « alternative NoSQL à SQL » — c’est la couche de données qui alimente une grande partie de l’infrastructure des agents IA, des analyses en temps réel, des backends mobiles et des plateformes SaaS. Ce guide explique ce qu’est réellement MongoDB, ce qui a changé avec MongoDB 8.3 (la version actuelle en disponibilité générale en mai 2026), et comment choisir entre Atlas, Community Edition et Enterprise Advanced. Que vous évaluiez MongoDB pour un nouveau projet, que vous migriez depuis PostgreSQL ou MySQL, ou que vous construisiez des fonctionnalités d’IA nécessitant une recherche vectorielle, voici l’aperçu pratique.

Qu’est-ce que MongoDB ?

MongoDB est une base de données NoSQL open source, orientée documents, conçue autour de l’idée que la plupart des données des applications modernes sont hiérarchiques, et non relationnelles. Au lieu de forcer les données à entrer dans des tables aux colonnes fixes, MongoDB les stocke sous forme de documents — des enregistrements de type JSON pouvant contenir des objets imbriqués, des tableaux et divers types de champs. Le profil d’un utilisateur, l’entrée d’un catalogue de produits ou une session de chat vivent dans un seul document, et non répartis sur six tables jointes.

L’entreprise à l’origine de MongoDB est cotée en bourse (NASDAQ: MDB), et le projet est en développement continu depuis 2009. En 2026, MongoDB alimente des charges de production chez Adobe, Bosch, Cisco, eBay, EA, Forbes, Toyota, Verizon, et des dizaines de milliers d’autres entreprises plus petites. C’est la base de données documentaire la plus utilisée dans le StackOverflow Developer Survey pour la septième année consécutive.

Trois raisons expliquent sa domination :

• Le modèle de données correspond au code moderne. Les documents se mappent directement sur les objets en Python, JavaScript, Go, Java et dans la plupart des autres langages. Aucune couche de mapping objet-relationnel n’est nécessaire.
• Elle s’adapte horizontalement sans refonte. Le sharding est une fonctionnalité de premier plan, pas un ajout bricolé à l’aide d’extensions.
• Elle a intégré l’IA au cœur de la plateforme plus vite que n’importe quel concurrent. La recherche vectorielle, les embeddings sémantiques et la mémoire des agents s’exécutent tous directement dans MongoDB en 2026, ce qui évite d’avoir à assembler plusieurs bases de données séparées.

Concepts clés : documents, collections et BSON

Quatre éléments de base constituent le modèle de données de MongoDB. Les comprendre suffit pour lire 80% du code MongoDB.

• Document — un enregistrement unique, stocké au format BSON (Binary JSON). Il peut contenir des champs imbriqués, des tableaux et n’importe quelle combinaison de types de données. L’équivalent d’une ligne en SQL, mais de manière flexible.
• Collection — un groupe de documents. L’équivalent d’une table en SQL, sauf que les documents d’une même collection n’ont pas besoin d’avoir des champs identiques. Les collections sont sans schéma par défaut ; la validation du schéma est optionnelle.
• Base de données — un conteneur pour les collections. Un seul déploiement MongoDB peut héberger plusieurs bases de données.
• Champ — une paire clé-valeur à l’intérieur d’un document. Les valeurs peuvent être des chaînes, des nombres, des dates, des tableaux, des documents imbriqués, des ObjectID ou des types spécialisés comme Decimal128 pour les données financières.

Un document ressemble à ceci :

{
  "_id": ObjectId("65f3a..."),
  "email": "[email protected]",
  "profile": {
    "name": "Alice Martin",
    "roles": ["admin", "editor"]
  },
  "createdAt": ISODate("2026-05-12T10:23:00Z")
}

Le _id le champ est généré automatiquement et unique au sein de la collection. Tout le reste dépend de vous. Cette flexibilité est à la fois l’atout — et le piège. Sans schéma ne signifie pas sans structure ; cela signifie que le schéma vit dans le code de votre application plutôt que dans la base de données. Considérez cela comme un choix de conception, pas comme une autorisation de faire l’impasse sur la modélisation des données.

Nouveautés de MongoDB 8 (2026)

MongoDB 8 est la version majeure actuelle. La version 8.3 est devenue disponible en disponibilité générale en mai 2026 lors de MongoDB.local London, et représente le plus important bond en matière de performances et d’intégration de l’IA depuis des années.

Améliorations des performances par rapport à MongoDB 8.0 :

• Jusqu’à 45% plus rapide en lecture
• Jusqu’à 35% plus rapide en écriture
• Jusqu’à 15% plus rapide pour les transactions ACID
• Jusqu’à 30% d’amélioration sur les opérations d’agrégation complexes
• Recherche vectorielle à moins de 100 ms et mises à jour de contexte à moins d’une seconde pour les charges de travail IA

Ces gains ne nécessitent aucun changement de code. Mettez à niveau sur place, redémarrez, mesurez. Les améliorations proviennent du moteur de stockage WiredTiger, des raffinements du planificateur de requêtes et de l’optimisation des collections de séries temporelles.

Fonctionnalités natives pour l’IA :

• Recherche vectorielle dans Community Edition (depuis la version 8.2). La recherche plein texte et la recherche vectorielle s’exécutent désormais directement dans MongoDB — aucune souscription Atlas requise, aucun cluster Elasticsearch ou Pinecone externe nécessaire. Étapes d’agrégation $search, $searchMeta, et $vectorSearch sont disponibles sur les déploiements autogérés.
• Automated Voyage AI embeddings (aperçu public, mai 2026). MongoDB a acquis Voyage AI en février 2025 et a intégré ses modèles d'embedding directement dans Atlas Vector Search. Avec le nouveau autoEmbed type de champ, MongoDB génère automatiquement des embeddings vectoriels à chaque insertion ou mise à jour d'un document.
• LangGraph.js Long-Term Memory Store (GA). MongoDB est la couche de mémoire persistante pour les agents LangGraph, combinant mémoire JSON, organisation par espace de noms, recherche sémantique et nettoyage basé sur le TTL dans un seul backend.
• Queryable Encryption améliorations dans la version 8.2 — des champs chiffrés que vous pouvez toujours interroger sans déchiffrement.

Les modèles d'embedding Voyage 4 sur MongoDB sont facturés par million de jetons : voyage-4-large à $0.12, voyage-4 à $0.06, voyage-4-lite à $0.02, et voyage-code-3 à $0.06. Les 200 premiers millions de jetons par compte sont gratuits, et l'API Batch applique une remise supplémentaire de 33%.

MongoDB Atlas vs Community Edition vs Enterprise Advanced

MongoDB est proposé en trois versions. Choisir la mauvaise est l'une des erreurs les plus courantes que commettent les équipes au cours de leurs six premiers mois.

	Community Edition	Enterprise Advanced	Atlas
Coût	Gratuit	Licence commerciale	Basé sur l'utilisation, niveau gratuit disponible
Déploiement	Auto-géré	Auto-géré	Cloud entièrement géré
Recherche vectorielle	Oui (depuis 8.2)	Oui	Oui + autoEmbed
Sauvegardes	Manuelles	Ops Manager	Continu, automatisé
Multi-région	Manuelles	Manuelles	En un clic, PrivateLink
Meilleur pour	Développement, prototypes, petites productions auto-hébergées	Secteurs réglementés, charges de travail critiques sur site	La plupart des charges de travail de production en 2026

La règle pratique : commencez sur Atlas, sauf si vous avez une raison précise de ne pas le faire. Le niveau gratuit (M0) offre 512 Mo de stockage et suffit pour les prototypes et les petits projets parallèles. Les formules payantes commencent autour de $9/mois (M2) pour les clusters partagés et évoluent vers des clusters dédiés à $57+/mois (M10 et au-delà). Le coût de migration de Community Edition vers Atlas est réel, mais maîtrisé — les économies opérationnelles le justifient généralement en quelques mois.

Community Edition prend tout son sens lorsque vous avez besoin d’un contrôle local complet, que vous déployez dans l’environnement d’un client ou que vous avez des exigences strictes de résidence des données que le cloud managé ne peut pas satisfaire. Enterprise Advanced est destiné aux secteurs réglementés (finance, santé, administration publique) qui ont besoin de MongoDB sur site, avec une prise en charge et des outils de niveau entreprise comme Ops Manager et l’authentification Kerberos.

Premiers pas : installation et première base de données

Pour Atlas, inscrivez-vous sur mongodb.com/cloud/atlas, créez un cluster gratuit M0, ajoutez votre adresse IP à la liste blanche, générez un utilisateur de base de données et récupérez la chaîne de connexion. Temps total de configuration : moins de 10 minutes.

Pour Community Edition sur Ubuntu/Debian :

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

Sur macOS, installez via Homebrew :

brew tap mongodb/brew
brew install [email protected]
brew services start [email protected]

Le MongoDB Shell (mongosh) est l’interface CLI officielle depuis MongoDB 5.0+. L’ancien mongo shell est obsolète. Une fois connecté, créez une base de données et une collection implicitement en insérant un document :

use mydb
db.users.insertOne({ email: "[email protected]", role: "admin" })

La base de données mydb et la collection utilisateurs apparaissent tous deux au moment où le premier document est inséré. MongoDB n’exige pas de déclaration de schéma à l’avance.

Opérations CRUD : les commandes essentielles

Quatre opérations couvrent ~90% du travail quotidien sur MongoDB.

Créer (insérer). Utilisation insertOne pour un seul document, insertMany pour des tableaux de documents.

db.users.insertOne({ email: "[email protected]", role: "editor", createdAt: new Date() })
db.users.insertMany([
  { email: "[email protected]", role: "viewer" },
  { email: "[email protected]", role: "viewer" }
])

Lire (rechercher). Les requêtes utilisent une syntaxe de filtre de type JSON. find renvoie un curseur ; findOne renvoie un seul document.

db.users.find({ role: "admin" })
db.users.find({ createdAt: { $gte: ISODate("2026-01-01") } })
db.users.findOne({ email: "[email protected]" })

Mettre à jour. Utilisation updateOne ou updateMany avec des opérateurs de mise à jour comme $set, $inc, $push, $pull.

db.users.updateOne(
  { email: "[email protected]" },
  { $set: { role: "admin", updatedAt: new Date() } }
)

Supprimer. deleteOne et deleteMany fonctionnent de manière symétrique par rapport aux méthodes de mise à jour.

db.users.deleteMany({ role: "viewer", lastLogin: { $lt: ISODate("2025-01-01") } })

Pour des transformations complexes en plusieurs étapes — group by, project, lookup, unwind — utilisez le Cadre d'agrégation. C’est l’équivalent MongoDB du GROUP BY et JOIN, exprimé sous forme d’un pipeline d’étapes.

Indexation et performances

Les index sont le principal levier de performance dans MongoDB. Une requête sans index effectue un parcours de la collection — lit chaque document — ce qui devient ingérable au-delà de quelques milliers de documents. Une requête indexée ne touche que les documents qui correspondent.

MongoDB prend en charge six principaux types d'index en 2026 :

• Champ unique — un seul champ, en ordre croissant ou décroissant. Le mode par défaut.
• Composé — plusieurs champs dans un ordre spécifique. L'ordre des champs compte ; l'index prend en charge les requêtes sur le préfixe initial.
• Multiclé — pour les champs qui contiennent des tableaux. MongoDB indexe chaque élément du tableau.
• Texte — pour la recherche en texte intégral sur les champs de chaîne. En grande partie remplacé par $search dans MongoDB 8.2+ pour les cas d'utilisation sérieux.
• Géospatial (2dsphere, 2d) — pour les requêtes basées sur la localisation.
• Vectoriel — pour la recherche sémantique via des embeddings. Le game-changer de 2026.

Créez un index avec createIndex:

db.users.createIndex({ email: 1 }, { unique: true })
db.users.createIndex({ role: 1, createdAt: -1 })

Les règles cardinales de l'indexation : indexez les champs sur lesquels vous interrogez, indexez les champs sur lesquels vous triez, l'ordre des préfixes compte pour les index composés, et n'en faites pas trop — chaque index a un coût en écriture et en stockage. Utilisez explain("executionStats") sur n'importe quelle requête lente afin de voir si MongoDB utilise un index ou effectue une analyse de collection.

Réplication, sharding et comment MongoDB passe à l'échelle

MongoDB dispose de deux stratégies de mise à l'échelle distinctes. Elles résolvent des problèmes différents et peuvent être combinées.

Réplication concerne la disponibilité et la mise à l'échelle des lectures. Un replica set est un groupe d'instances MongoDB — un primary gère les écritures, les secondary répliquent à partir du primary. Si le primary tombe en panne, une élection promeut un secondary en moins de 10 secondes. Les lectures peuvent être réparties entre les secondary pour les charges de travail à forte intensité de lecture. La réplication est la configuration par défaut dans tout déploiement sérieux, y compris Atlas, qui provisionne d'emblée un replica set à 3 nœuds.

Éclat concerne la mise à l'échelle des écritures et le volume de données. MongoDB partitionne horizontalement une collection sur plusieurs replica sets (shards), acheminés par une shard key que vous choisissez. Chaque shard gère un sous-ensemble des données et les écritures correspondantes. Le sharding ajoute de la complexité opérationnelle et doit être envisagé lorsqu'un seul replica set ne peut plus absorber le débit d'écriture ni stocker le volume de données — généralement au-delà de la plage des multi-téraoctets.

Le choix de la shard key est la décision la plus déterminante dans un déploiement sharded. Une mauvaise shard key crée des points chauds ; une bonne répartit les écritures de manière uniforme. Utilisez des shard keys hachées pour des écritures réparties uniformément lorsque les requêtes par plage ne sont pas importantes, et des shard keys par plage lorsque la localité compte.

MongoDB pour l'IA : recherche vectorielle, embeddings Voyage et mémoire d'agent

Le changement stratégique le plus important chez MongoDB en 2026 est qu'il est devenu une véritable plateforme d'infrastructure IA — pas seulement une base de données utilisée par des applications IA, mais la couche de données unifiée qui regroupe les données opérationnelles, les embeddings, les index vectoriels et la mémoire d'agent au même endroit.

L’idée centrale : la plupart des applications d’IA doivent combiner le raisonnement des LLM avec un contexte externe. Ce contexte provient de documents, de transcriptions, de bases de connaissances et de données métier en direct. Traditionnellement, cela signifiait faire fonctionner trois systèmes distincts — une base de données vectorielle (Pinecone, Weaviate) pour les embeddings, une base de données opérationnelle (PostgreSQL, MongoDB) pour les données métier, et un service d’embedding (OpenAI, Cohere) pour générer des vecteurs. Le pari de MongoDB est que ces trois éléments peuvent être réunis en un seul.

Voici à quoi cela ressemble en pratique :

• Atlas Vector Search indexe des embeddings de haute dimension (jusqu'à 2 048 dimensions) aux côtés des données opérationnelles dans la même collection. Une requête peut combiner la similarité vectorielle avec des filtres sur des champs classiques — « trouver des documents sémantiquement similaires à X, appartenant à l'utilisateur Y, créés après la date Z » — en une seule opération.
• autoEmbed génère automatiquement des embeddings Voyage AI chaque fois que vous insérez ou mettez à jour un document avec un champ texte désigné. Aucun pipeline externe.
• LangGraph Memory Store conserve l'état des conversations pour les agents IA, avec la recherche sémantique intégrée.
• intégration de la feature store Feast connecte MongoDB aux pipelines de fonctionnalités ML.

La propre statistique de MongoDB pour le moment : 79 % des entreprises construisent des agents IA, et seulement 11 % en ont un en production. L'écart, comme l'a formulé Pablo Stern, Chief Product Officer for AI de MongoDB, ne concerne pas le modèle — il concerne l'infrastructure de données en dessous. Ce positionnement n'est pas du marketing creux ; c'est l'histoire commerciale la plus solide que MongoDB ait eue depuis cinq ans.

MongoDB vs PostgreSQL, MySQL et DynamoDB

L'opposition « MongoDB vs SQL » était utile en 2015. En 2026, la vraie comparaison est contextuelle.

	MongoDB	PostgreSQL	MySQL	DynamoDB
Modèle de données	Document	Relationnel + JSONB	Relationnel	Clé-valeur / document
Schéma	Flexible	Strict (assouplissable)	Strict	Flexible
Jointures	Recherche (limitée)	Natif, puissant	Indigène	Aucun
Mise à l’échelle horizontale	Sharding natif	Manuel (Citus)	Manuelles	Natif, transparent
Recherche vectorielle	Indigène	Extension pgvector	Aucun	Aucun (utiliser OpenSearch)
Transactions ACID	Multi-document, jeux de réplicas, sharded	Meilleur de sa catégorie	Fort	Limité
Verrouillage propriétaire dans le cloud	Atlas fonctionne sur AWS, GCP, Azure	Neutre vis-à-vis des fournisseurs	Neutre vis-à-vis des fournisseurs	Uniquement AWS

Choisissez MongoDB lorsque vos données sont naturellement hiérarchiques, lorsque la flexibilité du schéma est importante, lorsque vous construisez des fonctionnalités d’IA qui nécessitent une recherche vectorielle, ou lorsque la mise à l’échelle horizontale est une exigence future connue.

Choisissez PostgreSQL lorsque vos données sont véritablement relationnelles, lorsque les jointures complexes sur plusieurs tables sont au cœur du besoin, lorsque les garanties ACID sont non négociables, ou lorsque vous souhaitez une seule base de données qui gère bien à la fois les charges de travail relationnelles et JSON (JSONB réduit largement l’écart, et pgvector gère la recherche vectorielle).

Choisissez MySQL lorsque votre écosystème MySQL est clairement adapté, que vous disposez d’une expertise opérationnelle existante, ou lorsque vous exécutez sur PlanetScale ou AWS Aurora.

Choisissez DynamoDB lorsque vous êtes déjà profondément ancré dans AWS, que vous avez besoin d’une économie entièrement serverless avec mise à l’échelle à zéro, et que vos schémas d’accès sont de simples requêtes clé-valeur ou single-table-design.

Bonnes pratiques et pièges courants

Six schémas distinguent les équipes qui réussissent avec MongoDB de celles qui reprochent à la base de données des problèmes causés par l’utilisation :

1. Concevez le schéma de votre document avant d’écrire le code. Sans schéma ne veut pas dire sans réflexion. Modélisez les documents en fonction de la manière dont l’application lit les données, et non de la façon dont un esprit relationnel les normaliserait. Intégrez les données liées lorsqu’elles sont lues ensemble ; faites référence lorsqu’elles sont indépendantes.
2. Utilisez les index de manière délibérée et vérifiez-les. Toute requête lente doit être exécutée via explain("executionStats"). Si MongoDB effectue une analyse complète de la collection, vous avez une lacune d’indexation, pas un problème de base de données.
3. N’imbriquez pas trop. Un document comportant des milliers d’éléments de tableaux imbriqués et qui continue de grossir est un piège. MongoDB impose une limite de taille de document de 16 Mo, mais la limite pratique est bien plus basse.
4. N’utilisez les transactions que lorsque vous en avez besoin. Les transactions ACID multi-documents fonctionnent, mais elles ont un coût en performance. La plupart des cas d’usage qui nécessiteraient une transaction dans SQL peuvent être modélisés pour tenir dans un seul document dans MongoDB, ce qui élimine le besoin de transaction.
5. Activez l’authentification dès le premier jour. Par le passé, MongoDB était livré par défaut sans authentification — cette époque est révolue, mais des instances auto-hébergées mal configurées laissent encore régulièrement fuiter des données. Atlas gère cela automatiquement.
6. Surveillez avant de passer à l’échelle. Les métriques intégrées d’Atlas (Performance Advisor, Real-Time Performance Panel) détectent 90 % des problèmes avant qu’ils ne soient remarqués par les utilisateurs. Les déploiements auto-hébergés nécessitent une surveillance équivalente via Ops Manager ou des outils externes.

FAQ : MongoDB

MongoDB est-il gratuit ?

MongoDB Community Edition est gratuite et open source sous la Server Side Public License. MongoDB Atlas propose un niveau gratuit (M0, 512 Mo) avec des niveaux payants à partir d’environ 9 $/mois. MongoDB Enterprise Advanced est sous licence commerciale.

Quelle est la version actuelle de MongoDB ?

MongoDB 8.3 est généralement disponible depuis mai 2026, annoncé lors de MongoDB.local London. La série 8.x est la version majeure actuelle, 8.0 servant de base de support à long terme et 8.3 ajoutant des fonctionnalités axées sur l’IA ainsi que des gains de performance.

MongoDB est-il plus rapide que PostgreSQL ?

Pas de façon universelle. MongoDB est plus rapide pour les charges de travail de type document avec un débit d’écriture élevé et des besoins de mise à l’échelle horizontale. PostgreSQL est plus rapide pour les requêtes relationnelles complexes avec jointures, agrégations et charges analytiques. La bonne réponse dépend des données et des requêtes, pas de la base de données.

Qu'est-ce que MongoDB Atlas ?

MongoDB Atlas est la version cloud entièrement gérée de MongoDB, disponible sur AWS, Google Cloud et Azure. Elle prend automatiquement en charge le provisionnement, les sauvegardes, la mise à l’échelle, la surveillance et le basculement. La plupart des déploiements MongoDB de production en 2026 s’exécutent sur Atlas plutôt que sur Community Edition autogérée.

MongoDB peut-il effectuer une recherche vectorielle ?

Oui. MongoDB propose une recherche vectorielle native sur Atlas (avec autoEmbed et l’intégration Voyage AI) et dans Community Edition (depuis la version 8.2). Il prend en charge la recherche hybride, la récupération sémantique et la génération augmentée par récupération (RAG) sans nécessiter de base de données vectorielle externe.

Quelles entreprises utilisent MongoDB ?

MongoDB alimente des charges de production chez Adobe, Bosch, Cisco, eBay, EA, Forbes, Toyota, Verizon, ainsi que des dizaines de milliers de plus petites entreprises dans les secteurs du SaaS, de la fintech, de la vente au détail, du jeu vidéo et de la santé.