MongoDB : base documentaire, Atlas, recherche vectorielle et usages IA

MongoDB désigne deux choses liées : une base de données NoSQL orientée documents, et l'entreprise américaine qui la développe, MongoDB Inc. La base est l'une des plus utilisées au monde pour les applications web et mobiles. L'entreprise vend principalement un service cloud qui l'héberge et l'exploite, MongoDB Atlas, auquel elle a ajouté au fil des années la recherche plein texte, la recherche vectorielle et des services pour les applications d'IA.

La société est fondée en 2007 à New York sous le nom 10gen par Dwight Merriman, Eliot Horowitz et Kevin Ryan. Les deux premiers avaient auparavant travaillé ensemble chez DoubleClick, société de publicité en ligne cofondée par Dwight Merriman et Kevin Ryan. Le projet initial est une plateforme applicative en ligne ; l'équipe en extrait la base de données, publiée en open source en 2009, qui rencontre un succès rapide auprès des développeurs. L'entreprise prend le nom MongoDB Inc. en 2013 et entre en bourse au Nasdaq en 2017. Elle rachète le moteur de stockage WiredTiger en 2014, lance Atlas en 2016, rachète Realm en 2019 et Voyage AI en 2025.

Dev Ittycheria a dirigé l'entreprise de 2014 à novembre 2025, date à laquelle Chirantan « CJ » Desai lui a succédé. Après le départ de ce dernier, annoncé le 28 septembre 2026, Dev Ittycheria est redevenu directeur général par intérim.

Sa place dans l'écosystème de l'IA tient à un argument simple : une application d'IA a besoin de données opérationnelles, de documents et d'embeddings. MongoDB propose de les réunir dans une même base plutôt que d'ajouter une base vectorielle séparée comme Pinecone ou Weaviate.

À retenir : MongoDB n'est pas une base vectorielle à l'origine. C'est une base documentaire généraliste qui a intégré la recherche vectorielle pour servir les applications d'IA.

Dans MongoDB, chaque enregistrement est un document, stocké au format BSON, une version binaire et typée du JSON. Les documents sont regroupés en collections. Contrairement à une base relationnelle, une collection n'impose pas de schéma fixe : deux documents peuvent avoir des champs différents, et un document peut contenir des sous-documents et des listes. On modélise ainsi un objet métier, par exemple une commande avec ses lignes, en un seul document plutôt qu'en plusieurs tables jointes. Les principes des bases NoSQL et leurs différences avec le relationnel sont détaillés dans notre guide MongoDB.

Les requêtes s'écrivent avec un langage propre et, pour les traitements avancés, avec un pipeline d'agrégation : une suite d'étapes de filtrage, de regroupement, de jointure ou de recherche. La haute disponibilité repose sur des replica sets, qui copient les données sur plusieurs serveurs, et la montée en charge sur le sharding, qui répartit une collection entre plusieurs groupes de serveurs.

La recherche vectorielle dans MongoDB

MongoDB Vector Search fonctionne avec un index déclaré sur un champ qui contient des vecteurs. Les requêtes passent par une étape d'agrégation dédiée, $vectorSearch, qui retrouve les documents les plus proches d'un vecteur de requête et peut appliquer des filtres sur les autres champs, par exemple la langue, la date ou les droits d'accès. Les index reposent sur l'algorithme HNSW et acceptent la quantification des vecteurs pour réduire la mémoire nécessaire. Les étapes $rankFusion et $scoreFusion combinent recherche vectorielle et plein texte, et une étape de reranking fondée sur les modèles Voyage AI a été ajoutée en 2026.

Ces index sont gérés par un processus distinct du serveur, appelé mongot, qui se synchronise avec les données au fil des écritures. Sur Atlas, il peut tourner sur des nœuds de recherche dédiés, dimensionnés indépendamment de la base. C'est ce qui permet d'utiliser MongoDB comme socle d'un RAG : le texte, ses métadonnées et ses embeddings vivent dans le même document, et une seule requête retrouve et filtre les passages pertinents. Le fonctionnement général d'un RAG est expliqué dans notre article RAG : tout savoir.

La réponse dépend de l'époque et de la définition retenue. MongoDB a été publié sous licence AGPL de 2009 à 2018. En octobre 2018, l'entreprise a adopté la Server Side Public License (SSPL), une licence qu'elle a rédigée pour empêcher des fournisseurs de cloud de proposer MongoDB en service sans contribuer en retour.

• Ce que permet la SSPL : lire, modifier et utiliser le code du serveur, y compris pour faire tourner ses propres applications commerciales.
• Ce qu'elle impose : quiconque propose MongoDB comme service à des tiers doit publier sous la même licence le code de l'ensemble des logiciels qui font fonctionner ce service. En pratique, cette clause vise les offres de base de données managée concurrentes.
• Son statut : l'Open Source Initiative ne reconnaît pas la SSPL comme une licence open source, et plusieurs distributions Linux ont retiré MongoDB de leurs dépôts. On parle plutôt de licence « source disponible ».
• Le reste de l'écosystème : les pilotes officiels sont sous licence Apache 2.0. Atlas, l'édition Enterprise Advanced et les modèles Voyage AI sont des offres commerciales ; un petit modèle de la série Voyage 4 est toutefois publié avec ses poids.

Pour une entreprise qui utilise MongoDB dans ses propres applications, la SSPL a peu d'effets concrets. Elle devient un sujet lorsque l'on redistribue un logiciel incluant MongoDB ou que l'on propose une base de données en service.

À retenir : le code de MongoDB est public, mais sa licence n'est pas open source au sens de l'OSI. La licence se vérifie au regard de l'usage prévu, pas seulement de la disponibilité du code.

La comparaison revient dans presque tous les projets de RAG. Elle oppose deux approches : intégrer la recherche vectorielle à la base opérationnelle, ou confier les vecteurs à une base spécialisée.

Lequel choisir ? MongoDB Vector Search se justifie lorsque les documents et leurs métadonnées sont déjà dans MongoDB, ou que l'on veut limiter le nombre de systèmes à exploiter : les vecteurs restent cohérents avec les données sans pipeline supplémentaire. Pinecone se justifie lorsque la recherche vectorielle est le cœur du besoin, avec de très gros volumes et une équipe qui préfère un service dédié. Une troisième voie fréquente consiste à rester sur PostgreSQL avec l'extension pgvector, si l'application est déjà relationnelle. Dans tous les cas, comparez la qualité de recherche sur vos données, la latence, le coût au volume réel et la charge d'exploitation.