Base de données · usage courant
Agence MongoDB à Nice
La base documentaire que nous employons là où les données n'ont pas de forme stable d'un enregistrement à l'autre.
Ce que nous en faisons
MongoDB chez nos clients, concrètement
Nous la retenons en complément de PostgreSQL, jamais à sa place : documents hétérogènes, réponses d'API tierces conservées telles quelles, historiques d'événements dont le format évolue. Nous ne basculons pas une base relationnelle vers une base documentaire sans une raison qui se mesure.
Les limites
Quand nous recommandons autre chose
Dès que les données ont des relations stables et des contraintes à faire respecter — factures, stocks, comptabilité — PostgreSQL protège mieux, et pour longtemps.
Réalisations
Nos projets menés avec MongoDB
LLM Monitor
SaaS qui mesure la visibilité des marques dans les réponses des IA.
MongoDB : Stockage des réponses des IA, dont le format varie d'un modèle à l'autre.
Lire l'étude de cas LLM Monitor
Méthode
Comment nous intégrons MongoDB
Avant d'écrire la première ligne, nous délimitons ce qui ira dans MongoDB et ce qui restera dans PostgreSQL, puis nous fixons le lien entre les deux : en général, l'identifiant de l'enregistrement PostgreSQL stocké dans chaque document, pour rattacher une réponse d'API ou un événement à la fiche métier concernée. Chaque collection reçoit ses index dès sa création, pensés à partir des recherches que l'application fera réellement, et une durée de conservation lorsque les données perdent leur intérêt avec le temps, comme les historiques d'événements.
En développement, MongoDB tourne dans un conteneur à la même version qu'en production. Les tests automatiques insèrent des documents volontairement incomplets ou d'un format ancien, pour vérifier que le code les lit sans erreur. Les évolutions de format passent par des scripts de transformation versionnés dans le dépôt, exécutés au déploiement et rejouables sur une copie.
Les sauvegardes des deux bases sont restaurées ensemble lors des tests, car un document privé de son enregistrement relationnel n'a plus de sens. À la livraison, vous recevez la procédure de restauration conjointe, les comptes d'administration créés à votre nom et la liste des index avec la recherche que chacun sert.
Pour votre entreprise
Ce que ça change concrètement
Vos utilisateurs ne voient pas MongoDB. Ce qu'ils constatent, c'est qu'un fournisseur qui modifie le format de ses données ou l'arrivée d'un nouveau type de document ne provoque ni panne ni attente : l'application enregistre ces informations telles qu'elles arrivent, et leur exploitation s'adapte ensuite. Vos données de facturation et de stock restent à l'abri dans la base relationnelle, si bien qu'une source externe mal formée ne peut pas les dégrader.
Le revers est à connaître dès le départ : un moteur supplémentaire, c'est un élément de plus à surveiller, à mettre à jour et à remettre en route après un incident. Nous le rendons tenable en limitant MongoDB aux données qui en ont besoin, en vérifiant que les deux bases repartent ensemble dans un état cohérent et en laissant dans le dépôt, qui vous appartient dès le premier jour, les scripts et procédures nécessaires. Un autre prestataire peut ainsi reprendre l'ensemble sans dépendre de nous, et vous savez à l'avance quelles fonctions seraient touchées si l'une des deux bases devait être restaurée.
Notre lecture
Ce que nous retenons de MongoDB
MongoDB se justifie quand la forme des données n’est pas stable : documents dont les champs varient d’une source à l’autre, historiques d’événements aux structures hétérogènes, données issues de capteurs ou d’API dont le format évolue sans préavis. Dans ces cas, forcer un schéma relationnel revient à ajouter des colonnes vides et des tables satellites pour rien.
Cette souplesse a un prix qu’il faut annoncer : ce que le schéma ne vérifie plus, le code applicatif doit le vérifier, et la discipline se relâche vite. Dès que les données ont une forme connue et des relations à faire respecter, nous partons plutôt sur PostgreSQL, ou sur MySQL quand l’hébergement l’impose. La pile naturelle autour reste Node.js, où l’on manipule les mêmes objets JSON de bout en bout.
Grille de décision
Faut-il choisir MongoDB ?
MongoDB ou PostgreSQL pour la base principale de notre application ?
PostgreSQL, dans la grande majorité des cas. Si vos données décrivent des clients, des commandes, des factures ou des stocks, elles ont des relations stables et des règles à faire respecter, et une base relationnelle les garantit au niveau du moteur. Nous ajoutons MongoDB à côté lorsqu'une partie des données change de forme d'un enregistrement à l'autre : documents hétérogènes, réponses d'API tierces, historiques d'événements. La base principale reste relationnelle, la base documentaire sert de complément ciblé.
Stocker les réponses d'API tierces dans MongoDB ou dans des colonnes JSON de PostgreSQL ?
Cela dépend du volume et de l'usage. Si vous conservez quelques réponses pour l'audit ou le débogage, une colonne JSON dans PostgreSQL suffit et évite un second moteur à maintenir, sauvegarder et surveiller. MongoDB devient pertinent quand ces documents forment un ensemble à part entière, interrogé selon des champs variables et alimenté en continu par plusieurs sources dont le format évolue sans prévenir. Un second moteur a un coût d'exploitation réel : il se justifie par l'usage, pas par la commodité.
Une petite équipe peut-elle maintenir MongoDB en plus de PostgreSQL ?
C'est la question à poser avant d'ajouter MongoDB. Deux moteurs, ce sont deux procédures de sauvegarde, deux politiques de droits d'accès et deux séries de mises à jour de sécurité. Pour une équipe de deux ou trois développeurs, nous réservons MongoDB aux cas où il retire une vraie complexité du code, par exemple quand chaque nouveau format de données obligerait sinon à modifier le schéma relationnel. Sans ce bénéfice mesurable, PostgreSQL seul reste plus simple à tenir dans la durée.
Questions de clients
Ce qu'on nous demande sur MongoDB
Nos données sont-elles moins sûres dans MongoDB que dans une base classique ?
Pas par nature, mais les garde-fous diffèrent. Par défaut, MongoDB accepte des documents de structure différente : un champ manquant ou mal saisi peut passer sans alerte. Nous ajoutons des règles de validation sur les collections, activons l'authentification, restreignons l'accès réseau et chiffrons les échanges. Pour les données comptables ou contractuelles, nous gardons PostgreSQL, qui impose ces contraintes au cœur du moteur.
Un autre prestataire pourra-t-il reprendre une application qui utilise MongoDB ?
Oui, MongoDB est largement connu des développeurs et bien documenté. La difficulté de reprise vient rarement du moteur, plutôt de l'absence de description des documents stockés. Comme la base n'impose pas de schéma, nous documentons dans le dépôt du projet la structure attendue de chaque collection et ses règles de validation. Le développeur qui arrive sait ce qu'il va trouver, sans le deviner à partir des données.
Peut-on migrer notre base MongoDB existante vers PostgreSQL ?
Oui, et c'est parfois la bonne décision quand des données devenues stables, comme les clients ou les commandes, ont été placées dans MongoDB par défaut. Nous inventorions d'abord les formats réellement présents dans les collections, qui s'écartent souvent de la documentation. Nous déplaçons ensuite les données structurées vers des tables relationnelles et laissons dans MongoDB ce qui reste hétérogène. La bascule doit résoudre un problème identifié.
MongoDB peut-il tourner sur notre propre serveur, ou faut-il un service en ligne ?
Les deux sont possibles. MongoDB s'installe sur votre serveur, souvent dans un conteneur, ou se loue sous forme de service géré chez un hébergeur. Le service géré prend en charge les mises à jour et les sauvegardes, en contrepartie d'un abonnement et de données hébergées hors de vos murs. L'installation sur votre serveur garde les données chez vous mais vous en confie l'exploitation. Nous comparons les deux options dans le plan d'action chiffré, avant toute dépense.
Que se passe-t-il si le serveur MongoDB tombe en panne ?
Tout dépend de la configuration retenue. Avec un seul serveur, les fonctions qui s'appuient sur MongoDB s'arrêtent jusqu'à la restauration, et les données écrites depuis la dernière sauvegarde sont perdues. MongoDB sait aussi maintenir plusieurs copies synchronisées sur des machines distinctes : si l'une tombe, une autre prend le relais automatiquement. Cette redondance augmente le coût d'hébergement ; nous la proposons lorsque l'indisponibilité des données concernées bloque réellement votre activité.
Aller plus loin
MongoDB s'inscrit dans notre Développement logiciel
Une technologie ne fait pas un projet. C'est la méthode autour qui décide du résultat : cadrage, maquettes, cycles courts, et réversibilité.
Technologies voisines
Un projet MongoDB en tête ?
Le premier échange est gratuit. Nous vous dirons franchement si cette technologie est la bonne, et sinon laquelle.
Mis à jour le