MySQL / MariaDB

MySQL / MariaDB : très présents chez les hébergeurs et dans les SI. On ne force pas une migration PostgreSQL « pour le principe ». Si ça tient la charge, que l’équipe la connaît et que les besoins restent relationnels classiques : MySQL fait le job.

Changer de BDD a un coût (migration, risques, compétences). On le paie seulement s’il y a un vrai gain : features absentes, perf, conformité, ou alignement d’équipe. Sinon on construit sur l’existant — et on documente pourquoi.

MySQL et MariaDB sont des bases relationnelles très répandues en hébergement mutualisé et legacy PHP. On les garde quand l’existant tourne déjà dessus et tient la charge — sans forcer une migration PostgreSQL « pour le principe ».

MySQL / MariaDB, dans le socle Innovation Digitale, ce n’est pas une case à cocher sur une slide commerciale. C’est une brique qu’on assume en production : on sait l’installer, la documenter, la tester, et la transmettre à une autre équipe. Le positionnement « quand l’existant est déjà là » résume le job ; le reste de cette fiche explique comment on l’utilise sur des projets réels — apps métier, APIs, modernisation, automatisation.

Beaucoup d’agences empilent les logos. Nous documentons le pourquoi et le comment. MySQL / MariaDB fait partie du socle parce qu’il tient dans le temps : documentation solide, communauté active, écosystème de talents, et une trajectoire qui ne force pas à tout jeter tous les dix-huit mois. C’est exactement le critère qu’on applique quand un client demande un système qui doit encore tourner dans cinq ans.

On s’aligne sur votre réel. Si la stack tient et que l’équipe la connaît, on construit dessus — c’est du bon sens.

Le critère n°1, c’est la stabilité opérationnelle. MySQL / MariaDB s’inscrit dans un écosystème où les données, les requêtes et l’intégrité sont des sujets documentés, pas des bricolages. Quand un incident arrive à 2h du matin, on veut des patterns connus, des logs lisibles, une communauté qui a déjà croisé le même cas — pas un framework abandonné six mois après le lancement.

Le critère n°2, c’est la documentation et la transmissibilité. Un logiciel qui vous appartient, c’est aussi un logiciel qu’une autre équipe peut reprendre. MySQL / MariaDB se recrute, s’audit, se forme. On peut écrire une doc courte, des critères Gherkin, une CI qui reste verte : le savoir ne reste pas dans la tête d’un seul prestataire.

Le critère n°3, c’est l’alignement avec la souveraineté numérique. Open source ou API maîtrisée, hébergement UE/FR possible selon le projet (Scaleway, OVHcloud), code remis au client : MySQL / MariaDB n’impose pas une cage propriétaire. On encapsule derrière des ports hexagonaux quand c’est pertinent, pour pouvoir changer de brique sans réécrire le métier.

Sur un Brief ou un audit build, on part du problème métier — pas de la techno. Ensuite seulement, MySQL / MariaDB entre en scène si c’est le bon outil. Exemple typique : une application métier Symfony + React, une API documentée, une base PostgreSQL, une CI (GitHub Actions ou Bitbucket Pipelines), et des tests (PHPUnit, Playwright, Gherkin) qui protègent le cœur du domaine. MySQL / MariaDB trouve sa place dans ce puzzle sans forcer le reste.

Concrètement, on pose des frontières : domaine métier au centre, adapters pour l’UI, la BDD, les SaaS externes. MySQL / MariaDB peut être au cœur (backend, BDD, méthode) ou en périphérie (observabilité, IA, hébergement). Dans tous les cas, on documente le « pourquoi ce choix » dans le dépôt : un futur mainteneur ne doit pas devoir deviner.

La qualité & méthode n’est pas un chapitre à part. TDD, analyse statique, CI : dès que MySQL / MariaDB touche du code ou de l’infra, on le branche dans le pipeline. Vert = on peut livrer. Rouge = on arrête avant la casse. C’est banal à écrire, radical à tenir — et c’est ce qui sépare un POC fragile d’un actif logiciel.

Pour les startups (POC / MVP / scale) comme pour les PME/ETI, le même standard s’applique. On ne « fait pas du MySQL / MariaDB pour faire du MySQL / MariaDB ». On l’utilise pour accélérer une livraison propre : moins de dette sémantique, moins de double saisie, plus de capacité à évoluer sans tout casser.

MySQL / MariaDB est un excellent choix quand le besoin touche données, requêtes ou scalabilité, et que l’horizon du projet dépasse le trimestre. Si vous devez recruter, auditer, ou transmettre le SI, une brique mainstream et documentée comme MySQL / MariaDB réduit le risque opérationnel.

On passe son tour quand un autre outil du socle couvre mieux le cas, ou quand l’existant client impose une contrainte claire (stack imposée, hébergeur, compétences internes). Exemple : on ne force pas PostgreSQL si MariaDB tient déjà la charge et que l’équipe la maîtrise. On ne force pas une usine React pour un site marketing Eleventy. L’honnêteté du discours fait partie de la méthode.

On évite aussi les empilements « parce que c’est moderne ». Ajouter MySQL / MariaDB doit résoudre un goulot : perf, clarté du domaine, ops, conformité, time-to-market. Si le seul argument est le buzzword, ce n’est pas un argument.

Donc oui : MySQL peut faire le job. On explique pourquoi on le garde ou pourquoi on migre — projet par projet, besoins, charge, compétences. Pas de religion « tout Postgres ».

Innovation Digitale choisit des technologies avec une trajectoire longue : versions majeures gérables, guides officiels à jour, issues et discussions publiques. MySQL / MariaDB coche ces cases. Ce n’est pas une garantie absolue — rien ne l’est — mais c’est un filtre qui élimine les paris jetables.

La communauté active, ça veut dire des réponses, des packages, des retours d’expérience. Ça veut aussi dire qu’un prestataire suivant pourra reprendre le flambeau. Pour un dirigeant, c’est aussi important que la feature list : la dépendance à une seule personne ou à un éditeur opaque, on la refuse autant que possible.

Côté souveraineté made in France / Europe : selon le rôle de MySQL / MariaDB (runtime, cloud, IA, analytics), on privilégie les options UE (Scaleway, OVHcloud, Mistral, PostHog EU) quand le sujet data ou politique l’exige. Le site vitrine iD peut tourner sur Netlify ; vos apps métier, elles, choisissent l’hébergeur adapté.

En résumé : MySQL / MariaDB dans le socle iD, c’est une garantie de continuité : méthode avant magie. Une brique qu’on explique, qu’on teste, qu’on documente — et que vous possédez avec le reste du code.

Si vous hésitez entre plusieurs options (BDD, front, cloud, IA), le Brief 45 min sert exactement à ça : clarifier le problème, le risque, le périmètre, puis proposer un audit build si le sujet tient la route. La stack suit le besoin — pas l’inverse.

Pour aller plus loin : consultez la documentation et le dépôt officiels ci-dessous, parcourez les autres fiches du socle, et regardez les réalisations (problématique → solution → résultat) pour voir MySQL / MariaDB (ou ses cousins) en situation réelle.