# Après une migration Joomla, des comptes et jetons jamais révoqués

> Reprendre un site venu de Joomla oblige à traquer chaque accès hérité, bien au-delà du contenu éditorial que la migration a déjà traité.

- Auteur : Clément Hadrot
- Publié le : 2023-12-09
- Mis à jour le : 2023-12-09
- Catégorie : Sécurité
- URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/migration-joomla-comptes-jetons-jamais-revoques/

## L’essentiel

- Un compte administrateur Joomla oublié reste un point d'entrée réel
- Les clés d'API tierces migrent rarement avec le reste de la configuration
- Vérifier le serveur lui-même, pas seulement les deux CMS

`wp user list --role=administrator` : cette commande, exécutée juste après la mise en ligne du nouveau site WordPress, ne révèle qu'une partie de la situation. Un développeur reprenant un site historiquement construit sous Joomla doit vérifier ce qui subsiste ailleurs, sur le serveur lui-même, bien après que le contenu éditorial a été entièrement basculé.

La migration de contenu, souvent traitée comme l'essentiel du travail, ne dit rien des accès hérités de l'ancienne plateforme : comptes administrateur Joomla toujours actifs, jetons d'API d'extensions tierces jamais révoqués, tâches planifiées système qui continuent de s'exécuter en arrière-plan. Voici la checklist suivie lors d'une telle reprise, où six comptes administrateur Joomla fonctionnaient encore un mois après le lancement officiel du nouveau site.

## 1. Recenser les comptes actifs sur l'ancienne plateforme, avant toute désinstallation

Avant de désinstaller ou d'archiver Joomla, il faut extraire la liste complète des comptes administrateur et super-utilisateur depuis la table `#__users` de sa base de données, avec leur dernière date de connexion. Cette liste sert de référence pour vérifier, une fois la bascule effectuée, qu'aucun de ces comptes ne conserve un accès quelconque, y compris indirect.

## 2. Vérifier que Joomla lui-même n'est plus accessible

Un site migré vers WordPress laisse parfois l'ancienne installation Joomla accessible à une URL différente ou un sous-domaine technique, notamment lorsque la migration s'est faite progressivement. Tant que les fichiers Joomla restent présents sur le serveur et que sa base de données existe encore, les comptes recensés à l'étape précédente conservent un accès fonctionnel complet.

> L'essentiel à retenir : Un compte administrateur Joomla oublié reste un point d'entrée réel ; Les clés d'API tierces migrent rarement avec le reste de la configuration ; Vérifier le serveur lui-même, pas seulement les deux CMS

## 3. Auditer les clés d'API et jetons d'intégrations tierces

Les extensions Joomla connectées à des services externes — passerelle de paiement, service d'envoi d'e-mails, outil d'analyse — utilisent généralement leurs propres clés d'API, stockées dans la configuration de chaque extension. Ces clés ne migrent jamais automatiquement vers WordPress et restent valides tant qu'elles ne sont pas explicitement révoquées auprès du service concerné, indépendamment du sort réservé à Joomla lui-même.

```
# Recensement manuel à faire figurer dans le rapport de migration
- Passerelle de paiement : clé API générée le 12/03/2021, jamais révoquée
- Service d'envoi d'e-mails : jeton SMTP actif, utilisé par le formulaire Joomla
- Outil d'analyse : clé de suivi liée au domaine, toujours active côté fournisseur
```

## 4. Contrôler les tâches planifiées et scripts système

Une installation Joomla ancienne s'accompagne souvent de tâches cron système configurées directement au niveau du serveur, indépendamment de toute interface d'administration : sauvegarde automatique, nettoyage de sessions, synchronisation avec un service externe. Ces tâches continuent de s'exécuter tant qu'elles ne sont pas retirées de la table cron du système, quel que soit l'état du CMS qu'elles desservent.

```
crontab -l
# 0 3 * * * /usr/bin/php /var/www/ancien-site-joomla/cli/backup.php
```

## 5. Révoquer, pas seulement désactiver

Changer le mot de passe d'un compte administrateur Joomla ne suffit pas si ce même compte utilise un jeton d'API distinct pour une intégration tierce, ni si une session déjà ouverte reste valide côté serveur. Chaque accès identifié doit être révoqué à sa source : suppression du compte, révocation de la clé auprès du fournisseur, invalidation explicite des sessions actives.

### Vérification concrète après désactivation d'un compte

```
SELECT id, username, lastvisitDate FROM joomla_users WHERE block = 0;
```

Cette requête, exécutée directement sur la base Joomla encore accessible pendant la période de transition, permet de confirmer qu'aucun compte non bloqué ne subsiste avant l'archivage définitif de l'installation.

## 6. Archiver et couper l'accès réseau à l'ancienne installation

Une fois tous les accès révoqués et les clés d'API régénérées, l'installation Joomla doit être archivée hors ligne — export complet des fichiers et de la base, puis suppression du dossier de la racine web accessible. Conserver l'archive sur un stockage non exposé au réseau public répond au besoin de traçabilité sans maintenir la moindre surface d'attaque active.

> Repère retenu de cette reprise : une migration ne se termine jamais à la bascule du contenu. Elle se termine quand plus aucun accès de l'ancienne plateforme ne peut techniquement fonctionner, nulle part.

## En résumé

Cette checklist ne traite volontairement pas la question du contenu éditorial lui-même, déjà couverte par tout projet de migration sérieux. Elle porte sur ce qui reste invisible une fois le nouveau site en ligne : des comptes, des clés, des tâches planifiées qui continuent d'exister tant que personne ne prend la peine de les fermer un par un.