La question derrière « pourquoi pas la dernière version ? »

Un catalogue PaaS peut proposer MongoDB 6.0 sans exposer les versions récentes. La première réaction consiste souvent à attribuer cette limite à la SSPL. La licence est bien un élément important pour les bases proposées en service managé, mais elle ne prescrit pas une version unique et n’empêche pas techniquement un fournisseur d’installer un serveur MongoDB.

Il faut séparer trois décisions : la licence de la version, le modèle commercial choisi par l’hébergeur et les versions que son catalogue maintient réellement.

Ce que la SSPL encadre

MongoDB indique que les versions de Community Server publiées depuis le 16 octobre 2018 sont sous SSPL. La section 13 concerne l’organisation qui rend la fonction de MongoDB — ou d’une version modifiée — disponible à des tiers comme service. Elle prévoit la mise à disposition du code source du service correspondant, qui inclut les couches logicielles nécessaires à son exploitation.

Un fournisseur peut donc choisir de ne pas proposer cette édition comme base managée, négocier d’autres conditions, offrir une édition sous licence commerciale ou référencer une alternative. Pour une application qui utilise MongoDB sur sa propre VM, la question n’est pas la même que pour un hébergeur qui vend lui-même MongoDB comme service. La licence exacte et le montage contractuel doivent être vérifiés dans le cas concret.

Pourquoi voit-on encore la version 6 ?

La documentation OVHcloud consultée liste MongoDB 6.0, 7.0 et 8.0 pour son service de base de données managée. La version 6.0 est donc une option du catalogue, pas sa seule version. Ce catalogue ne décrit pas les choix de tous les PaaS, et la SSPL n’exige aucun numéro de version particulier.

Il y a aussi une question distincte de cycle de vie : MongoDB indique que la version 6.0 a atteint sa fin de vie le 31 juillet 2025 et n’est plus maintenue par l’éditeur. En novembre 2026, si un service repose sur cette version, vérifier les engagements de support, les correctifs réellement fournis, les possibilités de mise à niveau et la trajectoire de migration. La présence d’une version au catalogue ne prouve pas, à elle seule, qu’elle reçoit encore les correctifs amont.

Ce qu’il faut demander au fournisseur

Quelle édition et quelle version tournent réellement ? Qui fournit les correctifs ? Jusqu’à quelle date ? Une mise à niveau majeure est-elle possible sans recréer le service ? Quelles versions et quelles options d’export sont disponibles ? Et sur quelle base contractuelle la base managée est-elle proposée ?

Une réponse exploitable relie la version au support et au plan de sortie. « Compatible MongoDB » ne suffit pas à répondre à ces questions.

Sources primaires

À lire aussi