Fin de support Joomla : ce que chaque date change vraiment

Derrière l'expression « fin de support », le projet Joomla place en réalité deux dates distinctes, séparées d'environ un an, et qui n'ont pas du tout les mêmes conséquences. Confondre les deux conduit soit à paniquer trop tôt, soit à découvrir trop tard que le site ne reçoit plus rien. Cette page sépare les deux notions, donne le calendrier des quatre versions encore en circulation, et ajoute une contrainte que les tableaux de fin de vie n'affichent pas : la version de PHP que chaque version de Joomla impose.

Deux dates, deux niveaux de risque

La fin du support actif marque l'arrêt des corrections de bugs. La version continue de recevoir des correctifs de sécurité, mais plus aucune anomalie fonctionnelle ne sera traitée : un comportement cassé le restera. C'est gênant, ce n'est pas dangereux. La fin de vie, elle, arrête tout, y compris les correctifs de sécurité. À partir de cette date, une faille publiée sur votre version ne sera jamais corrigée officiellement. Un site en fin de vie ne tombe pas en panne le jour dit, il cesse simplement d'être réparé.

Cette distinction change la nature de la décision. Entre la fin du support actif et la fin de vie, vous avez une fenêtre pour instruire un choix sans urgence. Après la fin de vie, vous n'arbitrez plus, vous rattrapez.

Le calendrier des quatre versions, au 9 août 2026

Source : le calendrier de fin de vie publié pour Joomla, relevé le 9 août 2026. La ligne à retenir est la deuxième. Joomla 4 est en fin de vie, et non en fin de support actif : la branche qui a été la version courante du projet d'août 2021 à octobre 2023, et sur laquelle sont donc arrivés les sites construits ou refaits pendant cette période, ne reçoit plus rien du tout. C'est aussi la moins couverte : les repères de migration disponibles en ligne ont été écrits pour la rupture entre Joomla 3 et Joomla 4, et ils n'ont pas suivi le calendrier depuis.

Une version de Joomla fixe aussi votre version de PHP

C'est la contrainte que les tableaux de fin de vie ne montrent pas, et elle décide souvent du calendrier réel. Joomla 5 accepte PHP 8.1 au minimum. Joomla 6 relève ce plancher : la documentation du projet indique PHP 8.3 en version minimale et supportée, avec PHP 8.4 recommandé. Monter vers Joomla 6 n'est donc pas seulement une opération applicative, c'est aussi un changement d'environnement d'hébergement.

Or PHP a son propre calendrier, et il est plus serré. Selon la page des versions supportées de PHP, PHP 8.1 a atteint sa fin de vie le 31 décembre 2025 et PHP 8.2 ne reçoit plus que des correctifs de sécurité, jusqu'au 31 décembre 2026. Autrement dit : un site en Joomla 5 tournant sur le plancher PHP autorisé par Joomla est déjà sur un PHP qui n'est plus maintenu. Deux calendriers se superposent, et c'est le plus court des deux qui commande.

Ce que la date impose, version par version

• Joomla 6 : rien à décider dans l'immédiat. Le support actif court jusqu'au 17 octobre 2028. Vérifiez seulement que votre PHP suit.
• Joomla 5 : la fenêtre confortable se referme le 13 octobre 2026, puis vous passez en sécurité seule pendant un an. C'est la position idéale pour instruire une décision, à condition de commencer avant que la fenêtre ne soit consommée.
• Joomla 4 : plus aucun correctif depuis le 14 octobre 2025. La question n'est plus « faut-il agir » mais « vers quoi », et elle se tranche sur l'inventaire du site, pas sur le calendrier.
• Joomla 3 : sans correctif officiel depuis le 17 août 2023, et sans chemin de montée directe vers les versions actuelles. Le sujet n'est plus une mise à jour, c'est une reconstruction.
• Dans les quatre cas : la version de PHP servie par votre hébergement se vérifie en même temps, parce qu'elle peut être le vrai facteur bloquant.

Si vous ne pouvez pas migrer cette année

Rester sur une version non supportée est parfois la seule option réaliste, et cela peut se défendre. Ce qui ne se défend pas, c'est de le subir sans le savoir. La différence tient à trois choses : écrire noir sur blanc la version en place et sa date de fin de vie, réduire la surface exposée en désactivant ce qui ne sert plus, et fixer une date de revue plutôt que d'attendre un incident. Une décision de report datée et documentée reste une décision. Un report par oubli n'en est pas une.

Questions fréquentes