Installer MongoDB 8 sur Linux et créer un cluster Atlas : tutoriel comparatif

Mettre MongoDB 8 en production ouvre deux voies : l’auto-hébergement sur un VPS Ubuntu (Community Edition gratuite) ou la voie managée MongoDB Atlas (cluster créé en dix minutes, plan M0 gratuit à vie). Les deux mènent au même protocole, à la même API, aux mêmes drivers — mais elles divergent sur le coût, l’effort opérationnel, et la frontière de responsabilité. Ce tutoriel détaille chaque chemin de bout en bout sur MongoDB 8.0 LTS, compare les coûts réels, et donne la grille de décision pour trancher sans regret.

Prérequis

• Pour la voie self-hosted : un VPS sous Ubuntu 22.04 LTS (jammy) ou 24.04 LTS (noble), accès root, 2 Go de RAM minimum.
• Pour la voie Atlas : une adresse e-mail et 10 minutes — pas de carte bancaire requise pour le tier gratuit.
• mongosh 2.x installé localement pour les tests de connexion.
• Temps estimé : 90 minutes pour traverser les 9 étapes des deux voies.

Étape 1 — Choisir entre self-hosted et Atlas

Les deux options répondent au même besoin technique mais à des contraintes opérationnelles différentes. Self-hosted exige une compétence DBA basique : installer, sécuriser, sauvegarder, surveiller. En échange, vous payez seulement le VPS — typiquement 4 à 10 euros par mois pour un Hetzner CX22 ou CPX21. Atlas externalise tout cela : pas d’install, sauvegardes incluses, monitoring intégré, support officiel — mais l’addition grimpe dès qu’on quitte le tier gratuit.

La règle pratique de 2026 tient en trois critères. Un : si l’application a moins de 50 000 utilisateurs et une charge modérée, Atlas M0 (gratuit) ou un VPS à 5 € suffit — choisir selon l’expertise disponible. Deux : pour un MVP ou un side project, Atlas M0 supprime les frictions et accélère le développement. Trois : pour un produit en croissance avec une équipe technique solide, l’auto-hébergement devient compétitif : même un cluster sur trois VPS Hetzner avec replica set coûte moins cher qu’Atlas M20.

Étape 2 — Installer MongoDB 8 sur Ubuntu 22.04 (jammy)

Pour Ubuntu 22.04 LTS, la procédure officielle utilise le repository APT signé par MongoDB Inc. La clé GPG identifie le repository, la ligne sources.list.d indique au système où le trouver, puis apt install mongodb-org installe les paquets mongod, mongosh, mongodump, mongorestore en une seule étape.

# Importer la clé GPG MongoDB 8.0
curl -fsSL https://www.mongodb.org/static/pgp/server-8.0.asc \
  | sudo gpg -o /usr/share/keyrings/mongodb-server-8.0.gpg --dearmor

# Ajouter le repository APT pour Ubuntu 22.04 (jammy)
echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg] \
https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/8.0 multiverse" \
  | sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

# Installer et démarrer
sudo apt update
sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

# Vérifier la version
mongosh --eval "db.version()"
# Attendu : "8.0.x"

La sortie de mongosh --eval "db.version()" doit afficher une version 8.0.x — au moment de la rédaction, la dernière patch publique est 8.0.23, qui inclut les correctifs de sécurité publiés en mai 2026. Le service écoute sur 127.0.0.1:27017 par défaut, les données vivent dans /var/lib/mongodb, les logs dans /var/log/mongodb/mongod.log.

Étape 3 — Installer MongoDB 8 sur Ubuntu 24.04 (noble)

La différence entre Ubuntu 22.04 et 24.04 tient à un mot dans la ligne du repository APT : jammy devient noble. Tout le reste — clé GPG, paquet, service — est identique. Cette substitution simple est la cause N°1 d’erreurs 404 Not Found chez les premiers installeurs : ils copient une procédure 22.04 sur une machine 24.04 et le repository renvoie un code 404 sans explication explicite sur la cause.

# Repository APT pour Ubuntu 24.04 (noble)
echo "deb [arch=amd64,arm64 signed-by=/usr/share/keyrings/mongodb-server-8.0.gpg] \
https://repo.mongodb.org/apt/ubuntu noble/mongodb-org/8.0 multiverse" \
  | sudo tee /etc/apt/sources.list.d/mongodb-org-8.0.list

sudo apt update
sudo apt install -y mongodb-org
sudo systemctl enable --now mongod

Vérification rapide : lsb_release -cs retourne noble sur Ubuntu 24.04. Si vous voyez ce mot, utilisez noble dans la ligne APT ; si vous voyez jammy, utilisez jammy. La ligne complète est sur la page Install on Ubuntu de la documentation MongoDB Server officielle, mise à jour à chaque release Ubuntu LTS.

Étape 4 — Activer authentification et bindIp

Un MongoDB fraîchement installé écoute sur localhost sans authentification — c’est volontaire pour permettre la configuration initiale, mais ne doit jamais rester en l’état pour une instance accessible depuis le réseau. Le scénario classique des fuites massives « MongoDB exposed » (2017-2020) provenait de cette absence d’auth combinée à un bindIp: 0.0.0.0.

# Créer l'utilisateur admin AVANT d'activer l'auth
mongosh
> use admin
> db.createUser({
    user: "admin",
    pwd: passwordPrompt(),
    roles: [
      { role: "userAdminAnyDatabase", db: "admin" },
      { role: "readWriteAnyDatabase", db: "admin" }
    ]
  })
> exit

# Éditer /etc/mongod.conf — activer auth et fixer bindIp
sudo nano /etc/mongod.conf

# /etc/mongod.conf — sections critiques
security:
  authorization: enabled

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.42   # localhost + IP privée VPC, jamais 0.0.0.0

Redémarrer ensuite avec sudo systemctl restart mongod. À partir de cet instant, toute connexion exige des identifiants : mongosh -u admin --authenticationDatabase admin demandera le mot de passe. Un client sans credentials se voit refuser l’accès avec Authentication failed. Le bindIp limite quant à lui l’écoute aux interfaces nommées — les paquets arrivés sur d’autres interfaces sont ignorés par le moteur, avant même l’authentification.

Étape 5 — Créer un cluster Atlas M0 (voie managée)

MongoDB Atlas est la plateforme cloud officielle de MongoDB Inc. Le plan M0, totalement gratuit, offre 512 Mo de stockage, jusqu’à 500 connexions simultanées, et fonctionne sur AWS, Google Cloud ou Azure. C’est l’option la plus rapide pour démarrer : aucun serveur à installer, sécurité par défaut, sauvegardes automatiques.

Étapes manuelles sur cloud.mongodb.com :

1. Créer un compte (e-mail + mot de passe ou SSO Google/GitHub).
2. Build a Cluster → choisir M0 (gratuit).
3. Région : AWS Frankfurt (eu-central-1) recommandée pour l'Europe et l'Afrique.
   Latence typique depuis Paris : 20 ms ; depuis Casablanca : 50 ms ; depuis Lagos : 90 ms.
4. Nommer le cluster (ex : "Cluster0") — création en 1 à 3 minutes.
5. Database Access → Add New Database User
   - Authentication : SCRAM
   - Username : app_user
   - Password : générer 24+ caractères aléatoires
   - Roles : Read and write to any database (suffisant pour MVP)
6. Network Access → Add IP Address
   - Pour dev : "Add Current IP Address" (votre IP publique du moment)
   - Pour prod : IP statique du serveur applicatif uniquement
7. Connect → Drivers → copier la connection string
   mongodb+srv://app_user:<password>@cluster0.xxxxx.mongodb.net/?retryWrites=true&w=majority

L’URI mongodb+srv:// diffère de la classique mongodb:// par sa résolution DNS : Atlas publie les nœuds du replica set via des enregistrements DNS SRV, et le driver les découvre automatiquement. Vous n’avez jamais à connaître les hôtes individuels — c’est ce qui permet à Atlas de basculer un cluster vers une autre région sans casser les clients.

Étape 6 — Tester la connexion aux deux environnements

Une fois le serveur (self-hosted ou Atlas) configuré, la première chose à valider est qu’un client peut s’y connecter et lire la version. Si cette étape rate, rien d’autre ne marchera — autant l’isoler dès le départ.

# Self-hosted local
mongosh "mongodb://admin@localhost:27017/?authSource=admin"
# Demande le mot de passe en interactif

# Self-hosted distant via SSH tunnel (recommandé pour debug)
ssh -L 27017:localhost:27017 user@vps.example.io
# Puis dans un second terminal :
mongosh "mongodb://admin@localhost:27017/?authSource=admin"

# Atlas
mongosh "mongodb+srv://app_user@cluster0.xxxxx.mongodb.net/?retryWrites=true"
# Demande le mot de passe en interactif

Sortie attendue dans chaque cas : une bannière indiquant la version du serveur (8.0.x), puis le prompt test> ou Atlas atlas-xxxxx-shard-0 [primary]> selon l’environnement. Si vous voyez MongoNetworkError, vérifier dans l’ordre : le service tourne (systemctl status mongod pour self-hosted), le port est ouvert (nc -zv host 27017), l’authentification est correcte (chaîne URI bien formée, mot de passe sans caractères mal encodés).

Étape 7 — Comparer self-hosted et Atlas en chiffres

La grille de décision tient en un tableau. Les chiffres ci-dessous sont à jour à la rédaction (mai 2026) et reflètent les tarifs publics MongoDB Atlas et Hetzner Cloud ; la version Atlas Serverless n’est pas comparée parce qu’elle se positionne sur un cas d’usage différent (charges en pic, dormance fréquente).

Conclusion pratique. Pour un MVP, Atlas M0 sans concurrent. Pour un produit en croissance jusqu’à 50 €/mois de budget DB, l’option dépend de l’expertise interne — self-hosted est moins cher mais demande du temps. Au-delà, Atlas devient sensiblement plus coûteux et les équipes outillées migrent souvent vers un self-hosted Kubernetes avec opérateur officiel.

Étape 8 — Importer ou exporter des données entre les deux

Que l’on parte d’Atlas vers un self-hosted ou l’inverse, la méthode de référence est mongodump + mongorestore. Les outils sont neutres : ils exportent un dump BSON portable, puis le réinjectent ailleurs sans préoccupation de version exacte (à condition de rester dans la même branche majeure 8.x).

# Export depuis Atlas vers un fichier local
mongodump \
  --uri="mongodb+srv://user:pass@cluster0.xxxxx.mongodb.net/" \
  --db=ecom \
  --gzip \
  --archive=/tmp/ecom-atlas.gz

# Import vers self-hosted (préserve les indexes)
mongorestore \
  --uri="mongodb://admin@vps.example.io:27017/?authSource=admin" \
  --gzip \
  --archive=/tmp/ecom-atlas.gz

# Validation post-import
mongosh "mongodb://admin@vps.example.io:27017/?authSource=admin" \
  --eval 'use ecom; db.produits.countDocuments();'

Trois précautions à connaître. Une : mongodump n’est pas un snapshot atomique sur une base très active — pour une cohérence parfaite, utiliser l’option --oplog et restaurer avec --oplogReplay, ou faire le dump depuis un secondary. Deux : les utilisateurs et les rôles ne sont pas portés par mongodump par défaut ; il faut les recréer côté cible. Trois : pour des migrations live sans coupure, Atlas Live Migration (gratuit) ou mongosync de MongoDB Inc. permettent une synchronisation continue avant bascule définitive.

Étape 9 — Checklist de mise en production

• MongoDB 8.0 LTS installé via le repository officiel (jammy pour 22.04, noble pour 24.04).
• security.authorization: enabled dans /etc/mongod.conf.
• Utilisateur admin créé puis service redémarré.
• bindIp limité à 127.0.0.1 ou à l’IP privée du réseau interne, jamais 0.0.0.0 sans firewall strict.
• Utilisateur applicatif créé avec rôle readWrite limité à une seule base.
• Pour Atlas : Database User en SCRAM, Network Access restreint aux IPs applicatives.
• Replica set initialisé (minimum 3 nœuds) pour activer les transactions.
• Sauvegardes mongodump programmées en cron (self-hosted), ou activées en Continuous Backup (Atlas M10+).
• Test de mongorestore validé sur VM ou Atlas séparé — un backup non testé n’est pas un backup.
• Alertes configurées sur l’espace disque, la latence des requêtes, le retard de réplication.

Erreurs fréquentes

FAQ

Q : Atlas M0 suffit-il pour la production ?
R : Pour un MVP avec moins de 500 utilisateurs actifs, oui. M0 est en cluster partagé avec d’autres tenants, ce qui limite le débit. Au moindre signal de production sérieuse (charges régulières, données critiques), passer à M10 dédié à ~57 USD/mois.

Q : Quelle version de MongoDB choisir en 2026 ?
R : 8.0 LTS, sortie en octobre 2024, supportée jusqu’à octobre 2029. La branche 8.3 (mai 2026) est une rapid release réservée à Atlas Auto-Upgrade, pas conseillée en self-hosted où la 8.0 LTS reste la cible stable.

Q : Atlas et le RGPD ?
R : Atlas propose des régions UE (Frankfurt, Ireland, Paris, Stockholm) pour stocker les données dans l’Union. MongoDB Inc. signe un DPA (Data Processing Agreement) standardisé. Pour les données sensibles, activer Client-Side Field Level Encryption (CSFLE) côté driver.

Q : Mongoose ou driver natif pour démarrer ?
R : Mongoose si vous voulez un schéma typé, des hooks, et une expérience proche d’un ORM Node. Driver natif si vous tenez à la performance brute et à un contrôle fin du BSON. Les deux s’utilisent contre n’importe quel cluster (self-hosted ou Atlas).

Q : Comment passer d’Atlas à self-hosted plus tard ?
R : mongodump depuis Atlas, mongorestore vers le self-hosted, recréer les utilisateurs et rôles côté cible, basculer la connection string applicative. Pour zéro downtime, utiliser mongosync en synchronisation continue puis bascule.

Pour aller plus loin

• MongoDB : NoSQL en pratique — point d’entrée du parcours.
• Replica sets MongoDB et élections — étape obligatoire après l’installation pour activer transactions et haute disponibilité.
• Mongoose et PyMongo en production — configurer les drivers Node et Python pour cette installation.
• Install MongoDB on Linux — Manual — procédure officielle versionnée par distribution.
• Atlas Getting Started — guide officiel pour créer un cluster Atlas.