MongoDB et la fin de l'open source : ce que les DSI européens doivent vraiment comprendre

La rupture de contrat implicite

Pendant des années, des milliers d'équipes techniques ont bâti leurs applications sur MongoDB avec une conviction partagée : le logiciel libre, c'est de la liberté durable. En 2018, MongoDB a tiré le premier fil en adoptant la licence SSPL — Server Side Public License — que l'Open Source Initiative a explicitement refusé de reconnaître comme une licence open source. En 2026, les conséquences de ce choix se lisent désormais dans les budgets, les contrats et les architectures de données de PME et ETI qui n'avaient pas vu venir le coup.

Ce n'est pas une crise soudaine. C'est une transformation lente qui arrive à maturité, et c'est précisément pour ça qu'elle est dangereuse.

Ce qui s'est passé, sans euphémisme

L'histoire commence en 2018, quand MongoDB, cotée en bourse depuis un an, décide que son modèle économique souffre d'un problème structurel : les grands fournisseurs cloud — Amazon Web Services en tête — monétisent MongoDB à grande échelle sans reverser un centime à l'éditeur. La réponse est la SSPL, une licence qui impose des obligations extrêmement contraignantes à quiconque offre MongoDB comme service. En clair : si vous hébergez MongoDB pour d'autres, vous devez libérer l'intégralité de votre stack logicielle. Une condition que personne dans l'industrie cloud ne peut accepter.

Le résultat concret ? AWS a créé DocumentDB, sa propre implémentation compatible MongoDB. MongoDB Inc. a continué à prospérer commercialement avec MongoDB Atlas, son offre cloud propriétaire. Et la communauté open source a répondu en forkant la dernière version réellement libre — la 4.0 — pour donner naissance à Percona Server for MongoDB et surtout à FerretDB, un projet qui réimplémente le protocole MongoDB par-dessus PostgreSQL.

En 2026, MongoDB Atlas représente la très grande majorité des revenus de MongoDB Inc. La version communautaire existe toujours, mais elle est désormais sous SSPL. Le mot « open source » dans les présentations commerciales de MongoDB mérite d'être mis entre guillemets.

Ce que ça change concrètement pour un DSI européen

La dette de dépendance s'est accumulée silencieusement

La plupart des équipes qui utilisent MongoDB aujourd'hui ne sont pas passées à Atlas par choix stratégique délibéré. Elles y sont arrivées progressivement : d'abord une instance auto-hébergée, puis la tentation de déléguer l'opérationnel à l'offre managée, puis la migration des données, puis l'intégration des fonctionnalités propriétaires — le search full-text, les triggers, les fonctions serverless. Chaque étape était rationnelle. L'ensemble crée une dépendance profonde.

Cette dépendance a un nom dans l'industrie : le *vendor lock-in*. Et dans le contexte européen de 2026, il prend une dimension supplémentaire. MongoDB Inc. est une société américaine cotée au NASDAQ. Ses données — les vôtres — transitent et résident dans des infrastructures soumises au droit américain, notamment le Cloud Act. Pour une ETI qui stocke des données clients, des données RH ou des informations commerciales sensibles dans Atlas, cette question n'est plus théorique depuis les clarifications successives du cadre juridique transatlantique.

Les changements de licence se répercutent sur vos contrats

Si vous utilisez MongoDB dans un produit SaaS que vous revendez à vos propres clients, la SSPL vous concerne directement. Votre service juridique a-t-il audité vos obligations de conformité licences ? La question mérite d'être posée sérieusement. Un cabinet d'avocats spécialisé en droit du logiciel vaudra toujours mieux qu'une interprétation interne de la SSPL — ce texte est volontairement ambigu sur les contours de l'obligation de divulgation.

L'argument du coût de migration a changé de camp

Il y a trois ans, la réponse standard à ces questions était : « Migrer coûte trop cher. » Ce calcul mérite d'être refait. Pas parce que migrer est devenu gratuit — ça ne l'est pas — mais parce que le coût de rester a lui aussi augmenté. Les tarifs d'Atlas ont évolué. La dépendance aux fonctionnalités propriétaires s'est creusée. Et le risque réglementaire européen, lui, s'est alourdi.

La vraie question n'est plus « combien coûte la migration ? » mais « quel est le coût total de possession de cette dépendance sur cinq ans, en intégrant le risque juridique et le risque de renégociation tarifaire ? »

Ce que certains font déjà

Il serait réducteur de dresser une liste d'alternatives comme si le problème se réglait en changeant de produit sur une étagère. La réalité des organisations qui s'en sortent bien est plus nuancée.

Certaines équipes reviennent à PostgreSQL. Pas comme un retour en arrière, mais comme un choix architectural mûri. PostgreSQL supporte le JSON et le JSONB nativement depuis plusieurs années, avec des performances qui ont considérablement progressé. FerretDB, qui expose une interface compatible avec le protocole wire de MongoDB par-dessus PostgreSQL, permet même dans certains cas de migrer sans réécrire entièrement le code applicatif. Ce n'est pas une solution magique — la compatibilité n'est pas totale et les cas d'usage les plus avancés demandent du travail — mais c'est une direction sérieuse pour les équipes qui veulent reprendre la main.

D'autres choisissent de rester sur MongoDB, mais de changer leur posture contractuelle. Négocier des clauses de portabilité des données, exiger des formats d'export standards, limiter l'adoption des fonctionnalités propriétaires d'Atlas au strict nécessaire. Ce n'est pas spectaculaire, mais c'est pragmatique. Un fournisseur qui sait que vous pouvez partir négociera différemment de celui qui vous sait captif.

Quelques ETI françaises et allemandes explorent ScyllaDB ou Apache Cassandra pour leurs cas d'usage à fort volume de données non structurées. Ces technologies ont des courbes d'apprentissage réelles et ne conviennent pas à tous les contextes, mais elles répondent à des besoins spécifiques que MongoDB ne couvre pas toujours mieux.

Ce qui frappe dans les organisations qui gèrent bien cette transition, c'est moins le choix technologique que la méthode : elles ont fait un audit de dépendance honnête avant de décider quoi que ce soit.

Trois réflexions de pair à pair

Faites l'audit avant la crise. Cartographier vos usages MongoDB — quelles applications, quelles données, quelles fonctionnalités Atlas spécifiques — est un travail de quelques semaines. Attendre qu'un renouvellement de contrat vous force la main, c'est négocier en position de faiblesse. Un DSI qui sait exactement ce qu'il peut migrer et ce qu'il ne peut pas migrer a un levier que son homologue dans le flou n'a pas.

Distinguez les nouvelles applications des applications existantes. La migration d'un système en production, c'est un projet complexe avec des risques réels. Mais pour les nouveaux développements, la question se pose différemment : pourquoi choisir MongoDB Atlas aujourd'hui en connaissance de cause ? Si la réponse est « parce que c'est ce que l'équipe connaît », c'est une réponse légitime mais qu'il faut assumer explicitement, pas subir passivement.

Ne laissez pas la décision aux seuls architectes. Ce que MongoDB a fait en 2018 — et continue de faire — relève autant du droit et de la stratégie commerciale que de la technique. La décision de continuer ou de migrer doit impliquer le DSI, le juriste interne ou externe, et idéalement la direction générale si les données concernées sont stratégiques. Ce n'est pas une décision de stack, c'est une décision de risque d'entreprise.

Ce que ça révèle d'une tendance plus large

MongoDB n'est pas un cas isolé. Depuis 2018, plusieurs éditeurs majeurs ont suivi une trajectoire similaire : Elastic, HashiCorp, Redis Labs. Le modèle open source traditionnel — donner le logiciel, vendre le support — s'est révélé insuffisant face à la puissance de distribution des hyperscalers. La réponse de l'industrie a été d'inventer des licences qui préservent la rhétorique de l'ouverture tout en fermant les usages commerciaux.

Pour les DSI européens, cette tendance a une implication simple : le label « open source » ne garantit plus rien en termes de liberté d'usage à long terme. La due diligence sur la licence d'un composant critique doit devenir aussi systématique que la due diligence sur la sécurité ou la performance. Ce n'est pas du dogmatisme idéologique pro-open source, c'est de la gestion de risque.

La question qui reste ouverte — et sur laquelle je serais curieux d'avoir vos retours — est celle de la coordination européenne. Des initiatives comme le Sovereign Tech Fund allemand, qui finance directement des projets d'infrastructure open source critique, montrent qu'il existe un modèle alternatif : la puissance publique comme financeur de biens communs numériques. Est-ce que ça suffit à changer les équilibres face à des éditeurs dont la capitalisation boursière dépasse le PIB de certains États membres ? Probablement pas seul. Mais c'est peut-être le début d'une réponse collective qui mérite d'être encouragée, y compris par les organisations qui se reconnaissent dans ce débat.

Vos architectures de données sont des actifs stratégiques. Qui en détient réellement les clés ?