MySQL, MariaDB, PostgreSQL : quel choix pour la souveraineté IT ? | Payload Website Template

# Après le rachat de MySQL par Oracle, puis l'ère cloud : quelle base de données pour un SI européen autonome ?

En 2026, MySQL n'est plus tout à fait la base de données relationnelle qu'on croyait connaître. Après des années sous tutelle Oracle — elle-même sous pression de ses propres ambitions cloud —, le projet a connu un nouveau glissement de gouvernance qui mérite d'être lu pour ce qu'il est : un signal de plus indiquant que la maîtrise d'un composant aussi central que le moteur de base de données ne peut pas reposer sur la bonne volonté d'un acteur américain dont les intérêts stratégiques divergent structurellement de ceux des entreprises européennes.

Pour les équipes IT de PME et d'ETI européennes, la question n'est pas abstraite. MySQL est présent dans des milliers de SI — derrière des ERP, des CRM, des applications métier maison. Ce qui change dans sa gouvernance change, directement ou non, les conditions dans lesquelles ces équipes travaillent : stabilité des licences, accès aux correctifs de sécurité, compatibilité des outils, liberté de déploiement.

Cet article compare trois approches concrètes, sans angle commercial : MySQL dans sa trajectoire actuelle, MariaDB, et PostgreSQL. Trois critères de lecture : architecture et autonomie de déploiement, intégration dans l'outillage IT quotidien, et gouvernance réelle du projet.

Ce que signifie concrètement un changement de gouvernance pour une équipe IT

Avant de comparer les moteurs, il faut poser le cadre. Une base de données n'est pas un composant neutre dans un SI. Elle conditionne :

la capacité à migrer sans refonte applicative majeure ;
la fréquence et la transparence des correctifs de sécurité ;
la compatibilité avec les outils d'administration, de monitoring et de sauvegarde ;
et, de plus en plus, les conditions dans lesquelles les données transitent vers des services cloud tiers.

Quand la gouvernance d'un projet change — qu'il s'agisse d'un rachat, d'un glissement de licence, ou d'une réorientation vers une offre managée propriétaire —, ce sont ces quatre dimensions qui bougent. Pas forcément visiblement. Souvent par accumulation de petites décisions qui n'ont l'air de rien prises séparément.

Comparatif : MySQL, MariaDB, PostgreSQL

1. Architecture et autonomie de déploiement

MySQL (Oracle)

MySQL reste techniquement solide. Son architecture est mature, ses performances sur les charges OLTP classiques sont documentées et prévisibles. Mais l'autonomie de déploiement se complique progressivement. La version Community Edition existe, mais Oracle concentre ses efforts — et ses correctifs — sur MySQL HeatWave, son offre cloud propriétaire. En pratique, une équipe IT qui déploie MySQL on-premise en 2026 se retrouve sur un chemin de moins en moins balisé par l'éditeur. Les mises à jour arrivent, mais le centre de gravité du projet s'est déplacé vers le cloud Oracle. Ce n'est pas une rupture franche ; c'est une friction croissante.

MariaDB

MariaDB est né précisément pour répondre à ce risque. Fork communautaire initié dès le rachat de MySQL par Oracle en 2010, il maintient une compatibilité élevée avec MySQL tout en s'émancipant progressivement sur certains aspects du moteur. Son déploiement on-premise est pleinement documenté et supporté. La MariaDB Foundation, structure européenne basée en Finlande, assure une gouvernance indépendante du projet open source. Attention toutefois : MariaDB Corporation, l'entité commerciale, a traversé des turbulences financières significatives ces dernières années, ce qui a semé des doutes légitimes sur la continuité du support entreprise. La distinction entre la fondation (projet) et la corporation (support commercial) est un point que les DSI doivent avoir en tête.

PostgreSQL

PostgreSQL est gouverné par la PostgreSQL Global Development Group, communauté décentralisée sans entité commerciale centrale. C'est sa force et, dans certains contextes, sa contrainte. Son architecture est plus riche fonctionnellement que MySQL ou MariaDB sur les types de données complexes, les extensions, la conformité SQL stricte. Pour une équipe IT qui construit ou fait évoluer une application avec des besoins de structuration de données avancés, c'est souvent le choix le plus pérenne techniquement. Le déploiement on-premise est trivial ; l'écosystème d'hébergeurs européens qui proposent PostgreSQL managé est bien fourni.

2. Intégration dans l'outillage IT quotidien

C'est ici que le débat devient concret pour les équipes.

|---|---|---|---|

| Migration entre versions | Risque de friction sur versions majeures | Migrations documentées, outillage communautaire solide | Migrations rigoureuses, moins de compatibilité ascendante implicite |

Pour une équipe IT qui opère MySQL depuis des années, passer à MariaDB est techniquement le chemin de moindre résistance : le protocole est compatible, les outils existants fonctionnent sans réécriture des procédures d'administration. La migration applicative est, dans la majorité des cas, transparente ou quasi-transparente.

Passer à PostgreSQL demande davantage. Les dialectes SQL diffèrent sur certains points, les types de données ne se mappent pas toujours directement, et les équipes doivent investir dans la montée en compétence. Ce n'est pas un obstacle rédhibitoire, mais c'est un projet qui se planifie, pas une bascule opportuniste.

Ce que les deux alternatives ont en commun : elles permettent de choisir librement son hébergeur — y compris un hébergeur européen soumis au droit européen, ce qui n'est pas un détail anecdotique depuis l'entrée en vigueur des différentes couches réglementaires autour de la localisation des données.

3. Gouvernance réelle du projet

C'est le critère le moins visible au quotidien, et le plus structurant à moyen terme.

MySQL : gouvernance Oracle. Les décisions sur les licences, les fonctionnalités, les correctifs de sécurité et la roadmap appartiennent à une entreprise américaine cotée au NYSE, soumise aux priorités de ses actionnaires et, le cas échéant, aux injonctions des autorités américaines (CLOUD Act compris). La Community Edition reste disponible sous GPL, mais Oracle n'a aucune obligation de maintenir ce modèle indéfiniment.

MariaDB : gouvernance duale. La MariaDB Foundation garantit la pérennité du projet open source avec une structure de gouvernance européenne. La MariaDB Corporation assure le support commercial — mais son histoire récente rappelle que s'appuyer sur une seule entité commerciale pour le support d'un composant critique comporte des risques de continuité. Les DSI qui choisissent MariaDB ont intérêt à documenter leur capacité à opérer en autonomie ou à diversifier leurs prestataires de support.

PostgreSQL : gouvernance communautaire décentralisée, sans entité commerciale centrale. Pas de propriétaire unique, pas de changement de licence possible sans consensus large de la communauté. C'est le modèle le plus robuste du point de vue de la souveraineté à long terme — à condition que les équipes internes montent en compétence ou s'appuient sur un écosystème de prestataires de support qui, en Europe, existe et se structure.

4. Implications pour la maîtrise du SI

La vraie question n'est pas laquelle des trois bases de données est « la meilleure ». C'est : laquelle laisse à l'équipe IT le plus de leviers de contrôle sur la durée ?

MySQL, dans sa trajectoire actuelle, pousse vers une dépendance croissante à l'écosystème Oracle Cloud. Ce n'est pas un choix neutre pour un SI européen qui veut rester maître de sa localisation des données et de ses conditions de traitement.

MariaDB offre une sortie de cette trajectoire avec le minimum de friction technique. Mais elle n'est pas exempte de risques propres, notamment sur la continuité du support commercial.

PostgreSQL offre la gouvernance la plus solide et la plus indépendante, au prix d'un investissement de migration et de montée en compétence qui doit être anticipé et budgété comme un projet à part entière — pas comme une simple mise à jour.

Ce que les équipes IT doivent surveiller maintenant

Le changement de gouvernance de MySQL n'est pas une crise immédiate. C'est une pression lente, exactement le type de situation dans laquelle les décisions se prennent par inertie plutôt que par choix délibéré. Pour les DSI et CTO d'ETI européennes, la bonne posture n'est pas la panique migratoire, c'est l'audit lucide :

Quels applicatifs métier reposent sur MySQL, et dans quelles conditions contractuelles ?
Quelle est la politique de mise à jour effective en production ?
L'hébergeur actuel de la base de données est-il soumis au droit européen ?
L'équipe IT a-t-elle les compétences pour opérer une alternative en autonomie ?

Ces quatre questions ont des réponses. Les obtenir est un préalable à toute décision d'architecture. Les ignorer, c'est laisser la gouvernance de son SI se décider par défaut — au profit d'acteurs dont les intérêts ne sont pas alignés sur ceux des entreprises européennes.

Après le rachat de MySQL par Oracle, puis l'ère cloud : quelle base de données pour un SI européen autonome ?