La question qui revient le plus souvent quand j'anime des sessions sur Joomla, ce n'est pas « comment installer un template » — ça, tout le monde sait le faire en une heure. C'est : « comment je fais pour être sûr que ma base de données ne se fera pas siphonner ? » Et là, le silence gêné. Parce que la plupart des formations Joomla que j'ai vues (et j'en ai suivi quelques-unes, payé certaines de ma poche) traitent la sécurité du site et la gestion de la base comme deux mondes séparés.
Résultat : on sait activer un pare-feu, on sait changer le préfixe jos_, mais on ne sait pas ce qui se passe réellement quand une requête malformée touche la base de données elle-même. Or c'est là que tout se joue.
Points clés à retenir
- Une formation sérieuse sur la gestion sécurisée d'une base Joomla doit couvrir la couche SQL, pas seulement l'interface d'administration.
- Le préfixe de tables n'est pas une sécurité : c'est une commodité. Beaucoup de formateurs le présentent comme un rempart — c'est faux.
- Un utilisateur MySQL à privilèges minimaux bloque la majorité des dégâts en cas d'injection réussie.
- La sauvegarde chiffrée testée (restauration incluse) vaut plus que dix plugins de sécurité empilés.
- Le RGPD impose de savoir quelles données personnelles dorment dans vos tables, et pendant combien de temps.
Une formation Joomla pour sécuriser sa base de données : ce qu'on devrait vraiment vous apprendre
La première fois que j'ai vu une base Joomla se faire vider, c'était sur un site client que je maintenais — un site d'association, franchement pas sexy, 400 visiteurs par mois. L'attaquant n'a pas touché aux fichiers. Il est passé par une extension de formulaire obsolète, a injecté du SQL par un champ non filtré, et a récupéré la table utilisateurs. Le préfixe de tables avait été changé. Ça n'a rien empêché du tout.
Ce jour-là, j'ai compris un truc que j'enseigne maintenant dès la première heure de mes interventions : la sécurité de la base ne se joue pas dans la configuration Joomla, elle se joue dans la façon dont l'application parle à MySQL. Et ça, très peu de catalogues de formation le mettent au programme.
Pourquoi la sécurité du site et la sécurité de la base sont souvent enseignées à part
Parce que c'est plus simple à vendre. Une formation de deux jours qui promet « sécurisez votre Joomla » va empiler du concret visible : réglages de l'admin, gestion des droits, extensions de sécurité. La base de données, elle, demande d'ouvrir un terminal, de lire des requêtes, de comprendre ce que fait JDatabase sous le capot. C'est moins vendeur.
Et pourtant. Une injection SQL réussie, c'est l'équivalent d'un cambriolage où on vous laisse les clés de la cave. Le site reste en ligne, il a toujours l'air normal, mais vos données sont parties.
- Les données clients (noms, emails, parfois adresses) dorment dans les tables.
- Les comptes utilisateurs, avec leurs hashs de mots de passe.
- Les logs d'activité, qui trahissent les habitudes d'un site.
- Et les journaux de commandes si vous avez une boutique.
Bref, la cible n'est pas le site. C'est ce qu'il y a derrière.
L'injection SQL dans Joomla : le chapitre que le programme oublie
Avouons-le, quand j'ai commencé avec Joomla il y a plusieurs années, je pensais que le CMS me protégeait automatiquement. C'est partiellement vrai : le cœur de Joomla utilise l'API JDatabase avec des requêtes préparées depuis des années, et le framework filtre pas mal de choses. Sauf que vos extensions ne suivent pas forcément cette discipline, et vos développements maison non plus.
Le piège classique : une extension mal codée qui concatène directement une variable dans une requête. Un champ de recherche, un paramètre d'URL, et ça passe.
À quoi ressemble une requête préparée, concrètement
Dans le code Joomla moderne, on écrit quelque chose comme :
- On construit une requête avec
$db->getQuery(true). - On lie les valeurs utilisateur avec
$db->quote()ou via des paramètres nommés. - On n'insère jamais directement une variable
$_GETdans la chaîne SQL.
Une bonne formation devrait vous faire écrire ça à la main, pas juste vous le montrer à l'écran. J'ai testé récemment une session où le formateur a déroulé un exemple d'injection en direct — voir une requête se transformer sous vos yeux, avec un ' OR 1=1 -- qui renvoie toute la table, ça marque bien plus qu'un slide.
L'utilisateur MySQL à privilèges minimaux : le réglage à 5 minutes qui sauve tout
Voilà le truc que je répète en boucle et qui n'apparaît presque jamais dans les programmes : l'utilisateur MySQL qui se connecte à votre Joomla ne devrait avoir que les droits nécessaires. Pas ALL PRIVILEGES. Pas DROP. Pas GRANT.
Pourquoi ? Parce que si une injection passe quand même, l'attaquant se retrouve avec un compte qui peut lire et écrire dans les tables applicatives — mais pas supprimer votre base, ni créer d'utilisateurs, ni toucher aux autres schémas du serveur. Ça limite la casse à un incident qu'on peut gérer, pas à un désastre.
Ce réglage demande littéralement cinq minutes dans phpMyAdmin ou en ligne de commande. Et je n'ai jamais vu une formation « gestion base de données Joomla » l'aborder ne serait-ce qu'en passant.
Sauvegarde, chiffrement, restauration : les trois étapes que tout le monde saute
Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde. C'est un fichier avec un nom rassurant. J'ai appris ça à mes dépens sur un projet, il y a un moment déjà : le backup tournait chaque nuit, tout semblait vert dans le tableau de bord, jusqu'au jour où il a fallu restaurer. Le fichier était corrompu depuis des semaines. Personne ne s'en était rendu compte.
Pour la base de données d'un site Joomla, une procédure décente doit couvrir :
- Une sauvegarde automatisée de la base seule, pas juste des fichiers.
- Un stockage hors du serveur — un dossier
/backupsur le même hébergement ne protège de rien. - Un chiffrement du fichier de sauvegarde, parce qu'un dump SQL en clair contient toute votre base utilisateurs.
- Un test de restauration planifié, disons une fois par trimestre, sur un environnement de test.
- Une définition claire de votre RPO (combien de données vous acceptez de perdre) et de votre RTO (combien de temps d'indisponibilité).
Un chiffrement au repos côté base elle-même est possible chez la plupart des hébergeurs sérieux, mais ce n'est pas quelque chose que vous configurez dans Joomla — c'est une conversation à avoir avec votre fournisseur.
Faut-il passer par Akeeba Backup ou faire autrement ?
J'utilise Akeeba Backup depuis longtemps et je continuerai — c'est un outil éprouvé, la version gratuite couvre déjà la sauvegarde planifiée, et la restauration est guidée. Mais soyons clairs : Akeeba sauvegarde, il ne sécurise pas votre base. Il ne change pas les privilèges MySQL. Il ne vous aide pas sur le RGPD.
| Besoin | Akeeba Backup | Configuration manuelle / hébergeur | Compétence attendue en formation |
|---|---|---|---|
| Sauvegarde planifiée de la base | Oui, intégrée | Possible via cron + mysqldump | Savoir mettre en place l'un ou l'autre |
| Chiffrement du fichier de sauvegarde | Oui (option) | Oui, avec gpg ou openssl | Savoir le faire et le vérifier |
| Privilèges MySQL | Non | Oui, à la main | Indispensable |
| Gestion RGPD des données en base | Non | Non | Trop souvent absent |
RGPD : ce que votre base Joomla contient sans que vous le sachiez
Combien de tables dans votre installation Joomla stockent des données personnelles ? Si vous répondez « je ne sais pas », vous n'êtes pas seul. Sur un site que j'ai audité l'an dernier, il y avait la table users bien sûr, mais aussi des tables d'extension qui gardaient les adresses IP de chaque visiteur depuis deux ans. Deux ans d'IP, sans purge, sans mention dans la politique de confidentialité.
Une formation qui se veut sérieuse sur la « gestion base de données sécurisée » doit au minimum vous apprendre à :
- Cartographier les tables qui contiennent des données personnelles (nom, email, IP, logs).
- Mettre en place une purge automatique ou une anonymisation après la durée de conservation choisie.
- Chiffrer les champs vraiment sensibles, quand il y en a.
- Documenter tout ça — parce qu'en cas de contrôle, la bonne foi ne suffit pas.
Je suis assez tranché là-dessus : une formation Joomla qui ne parle pas du tout de RGPD en 2026 est incomplète. Pas parce que c'est à la mode, mais parce que la base de données est précisément l'endroit où le RGPD s'applique.
Comment choisir sa formation sans se faire avoir
Le marché propose des sessions d'une journée (souvent 7 heures, autour de 600-800 € HT), d'autres sur trois jours. Le format INTRA (chez vous, sur votre site) coûte plus cher mais vaut souvent le coup, parce qu'on travaille sur vraies données.
Trois questions à poser avant de signer :
- Est-ce qu'on parle d'injection SQL et des requêtes préparées, avec des exercices pratiques ?
- Est-ce qu'on aborde les privilèges de l'utilisateur MySQL ? Si le formateur hésite, passez.
- Y a-t-il un module sur la sauvegarde testée et le RGPD ?
Et une quatrième, plus personnelle : demandez si la formation utilise votre propre site comme terrain d'exercice. Les meilleures heures que j'ai passées en formation, c'était quand le formateur m'a fait auditer mon installation, pas une démo. On trouve toujours quelque chose à corriger — c'est humiliant, et c'est exactement pour ça que ça marche.
Le vrai indicateur, au fond, c'est peut-être celui-là : à la fin de la formation, savez-vous répondre à cette question simple — si votre base était attaquée ce soir, qu'est-ce qui vous empêcherait de tout perdre ? Si la réponse tient en une phrase claire et vérifiable, vous avez eu affaire à une bonne formation. Sinon, vous avez surtout acheté des slides.
