Fin de vie (EOL) de MySQL : dates, risques et checklist de mise à niveau

1. Qu’est-ce que la fin de vie (EOL) de MySQL ? Pourquoi vous devriez le vérifier maintenant

Qu’est-ce que l’EOL de MySQL ? Une explication de base

MySQL est un système de gestion de bases de données relationnelles open source largement utilisé dans le monde entier. Il alimente tout, des applications web aux systèmes d’entreprise—mais aucune version ne peut être utilisée indéfiniment.

MySQL possède également un point « Fin de Vie (EOL) ». Cela fait référence à la date à laquelle Oracle, le développeur, met fin au support de cette version—tels que les mises à jour de sécurité et les corrections de bugs.

Par exemple, MySQL 5.7 a atteint la fin du support en octobre 2023. Ce type d’« information EOL » est extrêmement important car il impacte directement la sécurité et la maintenabilité future des systèmes en production.

« C’était en EOL avant que nous le remarquions » est extrêmement dangereux

De nombreux développeurs et opérateurs ont tendance à être prudents concernant la mise à jour de MySQL. Il est facile de penser « c’est stable, donc nous pouvons le laisser tel quel », mais continuer à utiliser une version en EOL comporte de grands risques.

Plus précisément, les risques comprennent :

• Les vulnérabilités de sécurité ne sont pas corrigées
• La compatibilité avec le système d’exploitation et les autres logiciels est perdue
• Vous ne pouvez plus obtenir de support de la part des fournisseurs
• Les nouveaux développeurs ont plus de difficulté à le maintenir, ce qui augmente les coûts de maintenance

Pour éviter ces risques, il est essentiel de vérifier régulièrement le statut de support de la version MySQL que vous utilisez.

Connaître le statut de support empêche les « incidents »

Surtout pour les entreprises utilisant MySQL dans leurs systèmes d’entreprise, une situation comme « nous avons dépassé l’EOL à notre insu » peut plus tard entraîner des pannes majeures ou des incidents de sécurité.

C’est pourquoi comprendre le cycle de vie du support de votre version MySQL—et effectuer des mises à jour ou migrations planifiées avant l’EOL—est la clé d’opérations stables à l’avenir.

Dans la section suivante, nous organiserons une liste claire des versions qui ont atteint l’EOL et quand, comme référence pratique.

2. Chronologie du support MySQL par version (Résumé EOL)

Connaître les principales versions de MySQL et leurs dates d’EOL

MySQL a été continuellement mis à jour au fil des ans, et chaque version majeure possède une période de support clairement définie. Vous trouverez ci‑dessous un résumé des EOL (dates de fin de support) publiées officiellement pour les versions majeures.

[EOL Table by Version]

Les dates sont basées sur des informations publiques d’Oracle et des principaux fournisseurs de cloud.

MySQL 5.5 (support terminé en 2018)

MySQL 5.5 a été publié en 2010 et adopté par de nombreuses applications web. Cependant, le support a pris fin le 3 décembre 2018. Puisqu’aucun correctif de sécurité ou bug n’est plus fourni, tout système qui l’utilise encore doit migrer dès que possible.

MySQL 5.6 (support terminé en 2021)

MySQL 5.6 est devenu populaire grâce aux améliorations de performance et aux nouvelles fonctionnalités, mais il a atteint l’EOL le 5 février 2021. Les environnements qui l’utilisent encore sont déjà hors support et exposés à un risque important.

MySQL 5.7 (support terminé en octobre 2023)

MySQL 5.7 a été largement utilisé dans les systèmes d’entreprise pendant de nombreuses années, mais le support a pris fin le 21 octobre 2023. De nombreux systèmes utilisent encore cette version, et de plus en plus d’organisations se précipitent pour migrer. Les vérifications de compatibilité et les travaux de migration de données sont désormais des domaines majeurs.

MySQL 8.0 (support premium prévu jusqu’en avril 2025)

MySQL 8.0 est la version stable grand public actuelle, mais le support premium est prévu de se terminer en avril 2025. Après cela, un support étendu ou le passage à une version LTS (Long Term Support) est recommandé. L’attention se porte de plus en plus sur MySQL 8.4 LTS, introduit en 2024, et il vaut la peine de le considérer si vous souhaitez des opérations stables à long terme.

L’information EOL est essentielle pour la planification future

Comme indiqué ci‑dessus, chaque version de MySQL possède un EOL planifié, et vous devez préparer la migration en conséquence. Vérifiez à nouveau la version utilisée par votre système et ne pensez pas « nous sommes bien pour l’instant », mais « quand migrerons‑nous ? ».

3. Que se passe-t-il après la fin du support ? Explication des risques EOL

Les risques de continuer après la fin du support sont énormes

Lorsque une version de MySQL atteint la fin de sa vie (EOL – End of Life), les mises à jour de sécurité officielles, les corrections de bugs et les améliorations sont complètement arrêtées. En d’autres termes, vous ne pouvez plus recevoir aucun support d’Oracle.

Même si tout semble fonctionner normalement, des risques graves peuvent se cacher sous la surface. Cela est particulièrement critique pour les serveurs web exposés à Internet ou les systèmes métier essentiels.

Vulnérabilités de sécurité non corrigées

Le problème le plus grave est que les vulnérabilités nouvellement découvertes ne seront plus corrigées. Les attaquants utilisent les informations sur les vulnérabilités connues pour cibler les versions EOL.

Et comme MySQL est largement utilisé, c’est aussi une cible attractive. Même si des vulnérabilités sont divulguées après l’EOL, vos options de défense deviennent extrêmement limitées si aucune correction ne sera jamais publiée.

🔒 Aucun correctif disponible = vous restez une cible en permanence.

Risque de violation des lois et des normes de sécurité

De plus en plus d’entreprises et d’institutions publiques sont tenues de se conformer à des normes comme ISMS ou PCI DSS. Ces normes interdisent souvent explicitement l’utilisation de logiciels non pris en charge.

Cela signifie que continuer à exécuter une version EOL de MySQL peut entraîner des résultats d’audit négatifs ou endommager la confiance avec les partenaires commerciaux.

Problèmes opérationnels dus à l’incompatibilité avec l’OS ou d’autres logiciels

Puisque les versions EOL ne sont plus testées pour la compatibilité avec les nouvelles versions d’OS ou d’autres logiciels, elles peuvent causer des pannes inattendues ou des problèmes de performance. Des cas réels incluent MySQL qui ne démarre plus après une mise à jour d’OS ou une dégradation significative des performances.

Cela peut mener à une lutte d’urgence contre les incendies—ou pire, à une interruption de service.

Cela s’accumule comme une dette technique

Maintenir une version EOL en vie accumule une dette technique. Lorsque vous devrez finalement migrer, les coûts de migration peuvent exploser, et vous pourriez découvrir de grandes quantités de code dépendant du comportement ancien.

En résumé, plus vous reportez, plus les coûts et les risques augmentent avec le temps.

Comment maintenir les opérations en sécurité

Pour éviter les risques EOL, vous n’avez pas nécessairement à migrer immédiatement—mais vous devriez élaborer un plan de migration. En comprenant votre version actuelle, le temps restant jusqu’à l’EOL et en choisissant une destination, vous pouvez maintenir un environnement stable en toute confiance.

Dans la section suivante, nous introduirons les principales options de migration et les cas auxquels elles conviennent le mieux.

4. Options de migration : Choisissez la meilleure stratégie pour vos objectifs

Votre réponse à l’EOL dépend de votre « stratégie de migration ».

Lorsque MySQL approche de l’EOL, la décision la plus importante est « où migrer ». Il ne suffit pas de simplement mettre à niveau—choisir une option qui correspond à vos exigences et à votre structure opérationnelle détermine la stabilité future.

Voici trois schémas de migration courants et les types d’utilisateurs auxquels ils conviennent le mieux.

Mise à niveau vers MySQL 8.0 ou 8.4 LTS (conservateur, axé sur la stabilité)

L’option la plus simple est de mettre à niveau vers une version plus récente de MySQL. Actuellement, MySQL 8.0 est la norme, mais depuis 2024, MySQL 8.4 LTS (Long Term Support) attire l’attention.

• Avantages :
• Haute compatibilité avec les environnements MySQL existants
• Peut continuer à utiliser l’open source
• Les outils existants comme MySQL Workbench peuvent continuer à être utilisés
• Inconvénients :
• Des erreurs de compatibilité peuvent survenir en raison de changements de syntaxe/spécifications
• Vous devez faire attention aux paramètres de stockage et aux jeux de caractères
• Idéal pour :
• Les petites et moyennes entreprises et les développeurs qui veulent des opérations stables sans changements majeurs du système

Migration vers une RDBMS alternative comme MariaDB ou TiDB (flexibilité et préparation au futur)

Passer à une RDBMS compatible avec MySQL est aussi un excellent candidat. Deux options populaires sont MariaDB et TiDB.

• MariaDB :
• Un fork de MySQL avec une syntaxe et une administration similaires
• Développé activement par la communauté
• Riches fonctionnalités d’optimisation des performances
• TiDB :
• Une base de données SQL distribuée, cloud‑native
• Haute disponibilité et évolutivité fortes
• Gère à la fois OLAP et OLTP, adaptée également à l’analyse
• Idéal pour :
• Les organisations envisageant une future migration vers le cloud ou le traitement de données à grande échelle
• Les équipes souhaitant adopter une technologie open‑source avancée

Services de bases de données cloud gérés (charge opérationnelle réduite, évolutif)

Si vous souhaitez réduire la charge opérationnelle sur site, envisagez les services RDB cloud gérés. Des exemples courants incluent :

• Amazon RDS for MySQL
• Un service géré par AWS
• Les sauvegardes automatiques et la redondance sont standard
• Soyez conscient des mises à jour automatiques potentielles au fil du temps
• Google Cloud SQL for MySQL
• Un service géré par Google Cloud
• Évolutif et s’intègre bien avec les autres services GCP
• Facile à gérer via l’interface UI, convivial pour les débutants
• Avantages :
• Pas de maintenance du système d’exploitation ou du matériel
• Moins d’expertise en infrastructure requise
• Inconvénients :
• Coûts cloud continus
• Le réglage fin peut être plus difficile
• Idéal pour :
• Exploiter des applications web de petite à moyenne taille
• Start‑ups et entreprises web qui souhaitent rationaliser les ressources dev/ops

[Comparison Table] Options et caractéristiques

Dans la section suivante, nous détaillerons les étapes pratiques de migration et les précautions clés de manière claire et exploitable. Passons en revue la liste de contrôle pour éviter les erreurs.

5. Étapes de migration MySQL et liste de contrôle (Comment éviter l’échec)

Le succès de la migration repose à 80 % sur la préparation

Migrer en raison de la fin de vie de MySQL est différent d’une simple mise à jour de version—cela nécessite des étapes soigneuses et une préparation approfondie. En particulier pour les systèmes de production, garantir l’intégrité des données et la continuité du service est la priorité absolue.

Voici les étapes clés en cinq phases.

ÉTAPE 1 : Évaluer et inventorier l’environnement actuel

Tout d’abord, identifiez votre MySQL actuel version, configuration et dépendances.
Vérifiez les éléments suivants :

• Version et numéro de build de MySQL
• Jeu de caractères utilisé (ex. : utf8mb4)
• Moteur de stockage (InnoDB, MyISAM)
• Syntaxe SQL et fonctions utilisées (peuvent dépendre de la version)
• Applications connectées et services externes

✅ Objectif : comprendre toutes les dépendances pour éviter les échecs après la migration

ÉTAPE 2 : Vérifier la compatibilité

Validez si votre environnement actuel est compatible avec la version cible. Lors des mises à jour majeures, portez une attention particulière à :

• Syntaxe / mots réservés supprimés que vous pourriez utiliser
• Modifications des paramètres par défaut (ex. : mode SQL)
• Différences dans les variables système et les paramètres

🔎 Vous pouvez diagnostiquer la compatibilité en utilisant la commande mysql_upgrade ou l’outil MySQL Shell Upgrade Checker Utility.

ÉTAPE 3 : Effectuer des sauvegardes et créer un environnement de test

Mettre à jour la production directement est trop risqué.
Tout d’abord, effectuez une sauvegarde complète et utilisez‑la pour créer un environnement de préproduction (test).

• Exporter les sauvegardes avec mysqldump ou mysqlpump
• Sauvegardes basées sur fichiers (ex. : XtraBackup)
• Restaurer dans l’environnement de préproduction et tester le comportement de l’application

En identifiant les problèmes post‑migration et les erreurs SQL à l’avance, vous pouvez minimiser les difficultés lors du basculement en production.

ÉTAPE 4 : Migrer les données en production

Après validation, migrez en production. Si possible, effectuez‑la la nuit ou pendant les périodes de faible trafic.

• Sauvegarde finale juste avant la migration
• Mettre le service en pause temporairement (utiliser une page de maintenance si possible)
• Importer les données dans la nouvelle version de la base de données
• Ajuster les fichiers de configuration et les variables d’environnement

Si vous devez également modifier le côté application (comme changer le point d’accès MySQL), soyez particulièrement attentif au timing.

ÉTAPE 5 : Valider et optimiser

La migration ne se termine pas au basculement.
Vérifiez les points suivants pour confirmer que le nouvel environnement est stable :

• Connectivité depuis l’application
• Vitesse d’exécution des requêtes et éventuelles erreurs
• Surveillance des journaux (journal d’erreurs, journal des requêtes lentes)
• Optimisation des paramètres de cache et reconstruction des index

Au besoin, exécutez ANALYZE TABLE ou OPTIMIZE TABLE pour récupérer les régressions de performance introduites par la migration.

Checklist (revue finale)

✅ Confirmer la version et la configuration actuelles
✅ Effectuer les vérifications de compatibilité à l’avance
✅ Effectuer une sauvegarde complète
✅ Tester dans un environnement de préproduction
✅ Exécuter une bascule de production planifiée
✅ Surveiller les erreurs et les performances après la migration

La clé du succès réside dans la planification de l’exécution. Pour les migrations motivées par la fin de vie (EOL), une préparation constante, des tests et une bascule soigneuse constituent la meilleure stratégie de réduction des risques.

6. Gestion de la fin de vie sur les services cloud (pour les utilisateurs AWS et GCP)

Même dans le cloud, on ne peut pas se reposer sur ses lauriers

Même si vous utilisez MySQL sur des plateformes cloud comme Amazon RDS ou Google Cloud SQL, la fin de vie (EOL) reste votre problème. Les fournisseurs cloud peuvent mettre en œuvre des mises à jour automatiques ou même la retraite du service pour les versions non prises en charge, d’où l’importance d’une planification proactive.

Voici un aperçu de la gestion de la fin de vie par les principaux services cloud.

Amazon RDS pour MySQL : attention aux mises à jour automatiques

Avec Amazon RDS pour MySQL, AWS a effectué plusieurs fois des retraits de version et des mises à jour forcées en raison de la fin de support.

• MySQL 5.5 : terminé en 2018 → migré automatiquement vers 5.6
• MySQL 5.6 : terminé en 2021 → mises à jour automatiques vers 5.7 mises en place après 2022

En conséquence, votre version de MySQL peut changer à un moment que vous n’aviez pas prévu, pouvant entraîner des problèmes d’application ou des régressions de performance.

✅ Atténuation : planifiez et exécutez les mises à jour selon votre propre calendrier

AWS fournit un préavis par e‑mail et notifications console, mais si vous l’ignorez, il peut être appliqué automatiquement — soyez prudent.

Google Cloud SQL pour MySQL : retrait de la première génération et incitation à la migration

Cloud SQL pour MySQL progresse également avec le retrait des versions et architectures plus anciennes.

• Les instances de première génération ne peuvent plus être créées
• Il existe des politiques encourageant les mises à jour pour les versions approchant de la fin de support

Google a tendance à respecter la flexibilité des utilisateurs, mais il existe des limites au « support à long terme », il faut donc mettre à jour ou reconstruire plus tôt plutôt que plus tard.

Cloud SQL offre également des fonctionnalités solides comme les sauvegardes automatiques et le basculement, mais des problèmes peuvent survenir si vous négligez des différences telles que les paramètres du mode SQL par défaut ou le comportement du fuseau horaire.

✅ Testez les paramètres spécifiques au cloud et la compatibilité à l’avance

Avantages du cloud — et pièges de la fin de vie

Les services cloud offrent des avantages, mais une préparation insuffisante à la fin de vie peut causer des problèmes.

Même dans le cloud, la réalité est la même : vous restez responsable de la gestion de la fin de vie.

Checklist EOL pour les environnements cloud

✅ Vérifiez votre version actuelle de MySQL et le calendrier EOL
✅ Activez les notifications du fournisseur (e‑mail ou autres canaux)
✅ Confirmez si vous êtes soumis à des mises à jour automatiques
✅ Testez la nouvelle version en préproduction
✅ Planifiez les modifications côté application selon les besoins

Pour tirer le meilleur parti de la commodité du cloud, ne « installez et oubliez ». Maintenez une gestion et une surveillance actives de votre côté. Pour la fin de vie de MySQL en particulier, les environnements cloud nécessitent toujours une préparation solide.

7. Questions fréquemment posées (FAQ)

Q1 : Puis-je continuer à utiliser MySQL après la fin du support ?

R : Techniquement oui, mais ce n’est pas recommandé.
MySQL en fin de vie ne reçoit aucun correctif de sécurité ni correctif de bugs. Cela augmente rapidement le risque d’attaques exploitant des vulnérabilités et peut violer les lois ou les politiques de sécurité.

Même si le système semble fonctionner correctement, vous opérez toujours avec un risque caché sérieux, il faut donc planifier une mise à jour ou une migration tôt.

Q2 : Quelle est la différence entre MySQL 8.0 et MySQL 8.4 LTS?

A : MySQL 8.4 LTS est une version stable prise en charge pendant une période plus longue.
MySQL 8.0 suit le cycle de publication régulier, et le support premium doit se terminer en avril 2025. En revanche, MySQL 8.4 LTS (Long Term Support) a été introduit comme une version stable avec environ cinq ans de support à long terme.

Si vous privilégiez la stabilité à long terme pour les systèmes d’entreprise, la migration vers MySQL 8.4 LTS est recommandée.

Q3 : Combien coûte la migration ?

A : Cela dépend fortement de l’ampleur et du chemin de migration.
Par exemple, une mise à niveau de version sur le même serveur peut être possible sans coût direct. Mais migrer vers des services cloud ou changer de produit (MariaDB/TiDB) peut nécessiter des efforts et des dépenses pour la conception, le développement, les tests et le support technique.

Vous devez également prendre en compte les coûts liés à l’atténuation des temps d’arrêt et à la préparation d’un environnement de préproduction.

Q4 : À quoi faut‑il faire attention lors de la migration de systèmes de production ?

A : Les pré‑tests et la migration par phases sont essentiels.
En production, vous devez effectuer des vérifications de compatibilité, des sauvegardes et des tests en préproduction. L’utilisation de réplicas de lecture ou d’un déploiement blue‑green (exécution simultanée des environnements ancien et nouveau avec basculement progressif) peut réduire les temps d’arrêt.

Il est plus sûr d’effectuer ces opérations la nuit ou le week‑end, lorsque le trafic est faible.

Q5 : Puis‑je arrêter les mises à jour automatiques dans le cloud ?

A : Vous pouvez contrôler certaines parties, mais vous devez finalement respecter la politique du fournisseur.
RDS et Cloud SQL permettent un certain contrôle, comme le report ou l’ajustement des plannings de mise à jour automatiques, mais des mises à jour forcées peuvent toujours survenir après la fin de vie (EOL).

Comme il est difficile d’éviter les mises à jour à long terme, l’approche la plus fiable est des mises à jour planifiées pilotées par vous.

Q6 : Comment choisir une base de données alternative ?

A : Utilisez ces trois critères.

1. Compatibilité : dans quelle mesure votre application et votre SQL existants fonctionneront tels quels
2. Scalabilité / pérennité : si elle peut gérer la croissance des données et du trafic
3. Capacité opérationnelle : si vous pouvez la maintenir en interne ou si vous avez besoin du support d’un fournisseur

Pour les systèmes d’entreprise, le choix doit se baser sur votre capacité opérationnelle réaliste plutôt que sur les tendances.

8. Résumé : La meilleure décision à prendre avant la fin du support

La fin de vie (EOL) n’est pas « lointaine »—elle est imminente

La fin de vie de MySQL (EOL) ne concerne pas uniquement le personnel informatique. Elle affecte l’ensemble de l’organisation en matière de sécurité, performance, disponibilité et gestion des coûts.

MySQL 5.7 a déjà atteint la fin du support en octobre 2023, et MySQL 8.0 devrait atteindre la fin du support premium en avril 2025. Si vous pensez « ça fonctionne encore, donc c’est bon », vous pourriez vous retrouver à exploiter avec un risque critique avant même de vous en rendre compte.

La migration planifiée est la meilleure stratégie d’évitement des risques

Comme le montre cet article, la migration n’est pas difficile lorsqu’elle est réalisée étape par étape :

• Identifier la version actuelle
• Vérifier la compatibilité et choisir une destination de migration
• Tester dans un environnement de préproduction
• Effectuer la migration par phases et la bascule finale

En suivant ces étapes, vous pouvez terminer la migration en toute sécurité tout en évitant les temps d’arrêt et la perte de données.

Même en utilisant des services cloud, ne laissez pas tout au fournisseur — comprenez votre situation et élaborez de manière proactive un plan de mise à jour.

« Je ne savais pas » n’est plus une excuse

Dans les opérations systèmes modernes, il ne suffit pas d’avoir des connaissances techniques, il faut aussi une conscience continue de la maintenance. Connaître les dates de fin de support, évaluer les risques et choisir la meilleure option de migration sont des compétences essentielles pour tous les opérateurs et développeurs.

Enfin : trois actions à entreprendre dès maintenant

1. Vérifier la version MySQL utilisée dans votre système
2. Confirmer la date de fin de vie et la noter dans votre agenda
3. Discuter de votre approche de migration (mise à jour vs. changement de base de données) avec votre équipe

Même en ne faisant que cela, votre prochaine étape sera claire.

Gérer la fin de vie de MySQL est une « police d’assurance » contre les incidents futurs.
Utilisez cet article comme déclencheur pour examiner vos opérations et créer un environnement plus sûr et durable.