MongoDB a étendu Atlas en intégrant de nouvelles fonctionnalités destinées à transformer la plateforme de données en une couche de mémoire, de contexte et de récupération d’informations pour les applications et agents d’intelligence artificielle. La société incorpore désormais des embeddings automatisés via les modèles de Voyage AI, une API indépendante pour les embeddings et le reranking, la récupération vectorielle sur des données en streaming, ainsi que le nouveau modèle voyage-code-4, conçu spécifiquement pour la recherche de code pertinent par des agents de programmation.

Les points clés de la nouvelle stratégie de MongoDB en matière de RAG en 20 secondes

• Atlas peut générer et mettre à jour automatiquement les embeddings lorsque les documents évoluent.
• MongoDB propose les modèles de Voyage AI via une API accessible même hors de Atlas.
• voyage-code-4 est spécialisé dans la récupération de code pour les agents de programmation.
• Le reranking natif permet de réorganiser les résultats en fonction de leur pertinence sémantique.
• La société souhaite éviter la complexité d’architectures séparant base opérationnelle, magasin vectoriel et pipelines d’embeddings.

Cette approche répond à un des défis souvent silencieux mais critique des systèmes de génération augmentée par récupération, appelés RAG (Retrieval-Augmented Generation). La performance d’un agent ne dépend pas uniquement du modèle de langage utilisé, mais aussi de la qualité et de la pertinence des informations récupérées avant la prise de décision.

Un grand modèle de langage (LLM) peut être très performant mais recevoir un contexte médiocre ou obsolète.

Si une recherche vectorielle fournit un document erroné, ancien ou peu pertinent, le modèle se basera sur ces données incorrectes pour raisonner. Et lorsque l’agent peut exécuter des actions, le problème dépasse le simple mauvais résultat : cela peut compromettre des processus critiques.

MongoDB veut rapprocher cette récupération des données du lieu où elles résident déjà, c’est-à-dire, les données opérationnelles.

Atlas génère les embeddings en temps réel lors des modifications de données

Au cœur de cette nouvelle stratégie se trouve Automated Embedding.

Jusqu’ici, une architecture RAG classique impliquait plusieurs étapes. Une application insérait des données dans la base, un processus indépendant détectait ces changements, extrayait le texte, appelait un modèle d’embedding, stockait le vecteur dans un autre système, puis synchronisait ces deux versions.

Ce processus fonctionnait, mais complexifiait l’architecture et multipliait les points de défaillance.

MongoDB permet désormais de configurer un modèle Voyage AI directement sur un index de recherche vectorielle. Lors de l’indexation, Atlas génère automatiquement l’embedding du document, de même qu’il construit le vecteur de requête lors d’une recherche.

Si le document change, la plateforme reconstruit son vecteur en temps réel.

Ce mécanisme élimine le besoin de maintenir un pipeline séparé dédié à la détection des modifications et à la mise à jour d’un magasin vectoriel externe.

Cette fonctionnalité a été proposée en preview publique en mai et la documentation indique qu’elle est disponible pour les clusters gratuits M0, Flex, ainsi que pour les clusters dédiés M10 ou plus. Sur ces derniers, il est nécessaire d’activer le scalabilité automatique pour le stockage et la puissance de calcul afin d’accompagner l’initialisation d’index volumineux.

Ce changement est particulièrement avantageux pour les agents manipulant en permanence des données en évolution constante.

Une mise à jour quotidienne du vecteur peut suffire dans un corpus relativement statique. En revanche, si l’agent doit traiter en temps réel des commandes, incidents ou dialogues en cours de modification, la fréquence de mise à jour doit être accrue.

MongoDB vise à éviter le problème de contexte obsolète

L’approche de la société repose sur une idée simple pour définir sa stratégie : un agent doit accéder directement à l’état actuel du business.

Ce but devient plus difficile à atteindre lorsque plusieurs couches indépendantes existent.

Une architecture peut combiner MongoDB comme base opérationnelle, un autre système pour la recherche vectorielle, un service externe pour générer des embeddings, et un modèle supplémentaire pour le reranking. Même lorsque chaque composant fonctionne parfaitement, un décalage temporel peut subsister entre le moment où l’information est recueillie et celui où l’agent la consulte.

MongoDB cherche à réduire ces désynchronisations en faisant en sorte que les opérations et la récupération s’appuient sur une même plateforme unifiée.

Cela ne signifie pas que toutes les architectures RAG doivent se centraliser. L’utilisation de produits spécialisés reste pertinente dans certains cas, notamment quand une infrastructure établie doit être conservée ou quand des caractéristiques spécifiques de moteurs tiers sont requises.

L’objectif de MongoDB est plutôt de simplifier en réduisant les composants quand la spécialisation accrue n’apporte pas une valeur opérationnelle justifiée.

L’exemple du Financial Times illustre cette approche. Le journal utilise Automated Embedding avec des modèles Voyage AI pour la recherche sémantique, traitant plus de 100 000 requêtes par jour, tout en expérimentant divers modèles pour équilibrer précision et coûts.

MongoDB mentionne également Eve, une plateforme juridique d’intelligence artificielle, qui teste sa API d’embeddings et de reranking pour retrouver des documents pertinents dans des dossiers légaux.

Il s’agit de retours d’expérience fournis par leurs clients, non de benchmarks indépendants.

voyage-code-4 : rechercher du code nécessite un modèle dédié

Une grosse nouveauté spécifique est voyage-code-4, dédié à la récupération de code.

Le défi qu’il cherche à relever devient de plus en plus courant avec des agents comme Codex, Claude Code, ou des outils exploitant de vastes référentiels de code.

Avant de modifier une application, un agent doit localiser les fichiers, fonctions, classes ou implémentations pertinentes. Une recherche purement textuelle ne suffit souvent pas, et un modèle généraliste d’embedding ne peut pas toujours saisir les relations sémantiques complexes entre morceaux de code.

MongoDB présente voyage-code-4 comme un modèle spécialisé pour cette tâche de récupération.

Les implications vont au-delà de la simple réponse sur la documentation : elles concernent la recherche précise de segments de code liés à une problématique spécifique.

Par exemple, pour corriger un problème d’authentification, un agent doit pouvoir retrouver :

• le middleware de validation des sessions ;
• le modèle utilisateur ;
• les tests associés ;
• une fonction de renouvellement des tokens ;
• les configurations utilisant des noms différents pour une même idée.

La qualité de cette première étape conditionne le succès des étapes suivantes.

MongoDB affirme que ses modèles Voyage figurent en bonne place dans le Benchmark de récupération d’embeddings (RTEB). La société avait déjà montré la supériorité de Voyage 4 dans des tests publics. Cependant, cela repose sur des résultats de benchmark et leur interprétation, ce qui ne garantit pas une supériorité universelle pour tous les cas ou applications réelles.

Embeddings et reranking désormais indépendants de la plateforme MongoDB

Un autre point clé de la stratégie réside dans l’interopérabilité.

La nouvelle Embedding and Reranking API permet d’utiliser directement les modèles Voyage AI depuis Atlas, même si les données ou l’application se trouvent en dehors de MongoDB.

MongoDB devient ainsi fournisseur de modèles de récupération, avec une API séparée que les développeurs peuvent exploiter via leur propre infrastructure.

Les utilisateurs peuvent créer une clé API pour accéder aux modèles depuis Atlas, puis interroger Voyage AI indépendamment de leur stockage. Le système de tarification est basé sur les tokens, sans obligation de stocker les données dans MongoDB.

Cet alignement a été rendu possible après l’acquisition de Voyage AI par MongoDB en 2025.

Les modèles ne se limitent pas à la recherche vectorielle dans Atlas mais peuvent aussi être invoqués comme service isolé pour diverses applications.

Le reranking intervient également : une recherche initiale peut ramener, par exemple, 50 documents, puis un modèle plus précis les réordonne pour ne garder que les plus pertinents.

MongoDB a également annoncé en juin la prise en charge native de cette étape par la phase d’agrégation $rerank dans MongoDB Search et Vector Search.

Dans le contexte RAG, cela permet de réduire le bruit en filtrant les documents non pertinents, ce qui diminue la consommation de tokens et améliore la fiabilité des réponses générées.

Le coût de l’agent s’est aussi anticipé avant l’appel au LLM

Ce lien entre la récupération d’informations et le coût opérationnel reste souvent sous-estimé.

Imaginez un agent répondant à une question à partir de documentation interne :

Une recherche peu précise pourrait nécessiter l’envoi de 20 documents au modèle.

Une recherche plus précise permettrait de limiter ce nombre à cinq, par exemple.

L’économie ne provient pas forcément d’un LLM moins cher, mais plutôt de fournir moins – mais de meilleure qualité – de contexte au modèle.

Ce principe s’étend aussi aux agents qui réalisent plusieurs recherches pendant une tâche. Si chaque étape introduit du contexte inutile, le coût total s’accroît rapidement.

MongoDB réfléchit à cette relation entre la qualité, la taille des embeddings et le coût. La famille Voyage 4 partage un espace d’embeddings commun, permettant, selon l’éditeur, de construire des vecteurs pour des documents avec un modèle, puis de consulter ce même espace avec un modèle plus léger ultérieurement.

Elle supporte aussi des représentations de différentes dimensions via des techniques de matryoshka learning, permettant de réduire le stockage dans certains scénarios.

Ces options techniques doivent s’évaluer au cas par cas : réduire la taille des vecteurs ou utiliser un modèle plus petit peut diminuer les coûts, mais la précision doit rester adaptée à chaque cas d’usage.

La recherche vectorielle s’étend aussi aux données en mouvement

La quatrième nouveauté annoncée concerne l’intégration de la récupération vectorielle à Atlas Stream Processing.

MongoDB Stream Processing permet déjà d’ingérer des flux de data depuis Kafka ou d’autres bases, de les transformer en continu, puis de les écrire dans des collections ou vers des destinations externes.

L’ajout de la recherche vectorielle à ce processus permet aux agents d’établir des liens sémantiques en temps réel entre des événements en mouvement et des informations proches contextuellement.

Cela ouvre des cas d’usage différents du RAG documentaire traditionnel :

• Comparer une nouvelle incident avec des précédents ;
• Relier de la télémétrie à des cas connus ;
• Enrichir des messages en temps réel avant transmission.

L’enjeu est que les données en flux ne doivent pas forcément devenir statiques pour permettre une récupération sémantique.

Les applications orientées observation, support ou détection d’incidents peuvent ainsi bénéficier d’un contexte immédiat, plutôt que d’attendre la fin de l’événement pour intervenir.

MongoDB au cœur de l’architecture des agents

Toutes ces innovations s’inscrivent dans une vision plus large, illustrée lors du Build Fest du 13 août à San Francisco : mémoire, état, contexte et récupération pour les agents intelligents.

La société a annoncé des intégrations avec Claude, Claude Code, ChatGPT, Codex, Grok Build et Devin, ainsi qu’un serveur MCP géré pour Atlas.

L’objectif commercial est clair : faire de MongoDB non plus uniquement un stockage de documents, mais une couche permettant aux agents d’accéder à l’état vivant, au contexte sémantique et aux outils nécessaires à leur fonctionnement.

Ce positionnement place la base de données au centre de l’essor de l’IA agentique.

Les premiers chatbots fonctionnaient principalement avec un prompt et un modèle. Les agents en production doivent désormais se souvenir, consulter, agir et suivre l’évolution des données.

Et plus un logiciel devient autonome, plus la question cruciale devient : quelles informations ont été récupérées avant de prendre leur décision.

MongoDB mise sur le fait que cette couche s’intègrera naturellement à la plateforme de données elle-même.

Questions fréquentes

Qu’est-ce que l’Automated Embedding de MongoDB Atlas ?

C’est une fonction qui génère automatiquement des embeddings via les modèles de Voyage AI lors de l’indexation des documents et lors des requêtes. Elle reconstruit aussi les vecteurs en cas de modification des données, éliminant la nécessité d’un pipeline séparé.

Qu’est-ce que voyage-code-4 ?

Un modèle Voyage AI spécialisé dans la récupération de code, conçu pour aider agents et applications à retrouver rapidement des fragments pertinents dans de grands dépôts logiciels.

Faut-il utiliser MongoDB pour accéder aux modèles de Voyage AI ?

Pas nécessairement. MongoDB propose une API Embedding and Reranking indépendante, exploitable depuis des applications externes ou autres systèmes de stockage.

À quoi sert le reranking dans un système RAG ?

Il permet de réorganiser un ensemble initial de documents récupérés en utilisant un modèle plus précis, afin de réduire le bruit, limiter la consommation de tokens, et améliorer la qualité du contexte final pour le modèle de langage.