Migrer Vers WordPress 7.0 Sans Casse : Checklist WP-CLI, Staging Et Rollback

Une mise à jour majeure WordPress ne devrait jamais se faire au hasard entre deux cafés. Même quand le bouton « Mettre à jour » est tentant, un site professionnel mérite une méthode : sauvegarde vérifiée, clone de staging, audit des extensions, tests éditoriaux, validation technique et plan de retour arrière. Voici une checklist opérationnelle pour migrer vers WordPress 7.0 sans transformer votre lundi matin en intervention d’urgence.

Avant de commencer : définir le périmètre

La première erreur consiste à traiter tous les sites WordPress de la même façon. Un blog vitrine avec dix pages statiques n’a pas le même risque qu’une boutique WooCommerce, un site multilingue, un intranet connecté à un SSO ou un média avec 40 rédacteurs. Avant toute commande, notez les éléments critiques : thème actif, plugins payants, version PHP, hébergement, cache, CDN, formulaires, moyens de paiement, webhooks, API externes et tâches cron.

Créez ensuite une fenêtre de maintenance réaliste. Pour un site simple, une heure peut suffire. Pour un WooCommerce, prévoyez un créneau calme, une personne capable de tester les commandes et une personne capable de valider le tunnel client.

Étape 1 : sauvegarder, puis vérifier la sauvegarde

Un backup non testé est une promesse, pas une sécurité. Il faut sauvegarder les fichiers et la base, puis vérifier que l’archive existe, qu’elle n’est pas vide et qu’elle peut être restaurée sur un environnement isolé.

# Créer un dossier daté hors racine publique si possible
mkdir -p ~/backups/wp-$(date +%F)

# Export SQL avec WP-CLI
wp db export ~/backups/wp-$(date +%F)/database.sql

# Archive fichiers hors uploads de cache
zip -r ~/backups/wp-$(date +%F)/files.zip . 
  -x "wp-content/cache/*" 
  -x "wp-content/uploads/cache/*" 
  -x "node_modules/*"

Si votre hébergeur fournit des snapshots, utilisez-les aussi. L’idéal est d’avoir deux niveaux : snapshot serveur pour rollback rapide, export SQL + fichiers pour restauration contrôlée.

Étape 2 : cloner en staging

Ne testez pas WordPress 7.0 directement sur la production. Un staging doit reprendre la même version PHP, la même base et les mêmes extensions. Si le domaine de staging est public, bloquez l’indexation et protégez l’accès par mot de passe.

# Après import du clone, remplacer l'URL proprement
wp search-replace 'https://www.exemple.com' 'https://staging.exemple.com' 
  --all-tables --precise --skip-columns=guid

# Bloquer l'indexation côté WordPress
wp option update blog_public 0

# Vérifier la configuration
wp core version
wp plugin list --status=active
wp theme status

Attention aux webhooks : Stripe, PayPal, CRM, emailing, ERP, Make, Zapier ou n8n peuvent déclencher de vraies actions depuis un staging mal isolé. Désactivez les clés live et remplacez-les par des clés de test.

Étape 3 : auditer plugins et thème

La majorité des incidents de migration viennent rarement du coeur WordPress seul. Ils viennent d’une extension non maintenue, d’un constructeur de pages ancien, d’un thème enfant qui surcharge des templates obsolètes ou d’un snippet PHP oublié.

# Lister les mises à jour disponibles
wp plugin list --update=available --fields=name,version,update_version,status
wp theme list --update=available

# Repérer les extensions inactives
wp plugin list --status=inactive

# Vérifier les checksums du coeur
wp core verify-checksums

Supprimez ce qui est inutile, mais sans brutalité : exportez les réglages des plugins importants et vérifiez qu’aucune fonctionnalité visible ne dépend d’une extension apparemment secondaire. Sur WooCommerce, testez au minimum panier, paiement, emails transactionnels, taxes, livraison et espace client.

Étape 4 : mettre à jour dans le bon ordre

Sur le staging, commencez par les extensions et le thème, puis seulement le coeur WordPress. Cette séquence réduit les incompatibilités connues, car les éditeurs publient souvent leurs correctifs avant ou pendant la sortie majeure.

# Staging uniquement
wp plugin update --all
wp theme update --all
wp core update
wp core update-db

# Nettoyer les transients après migration
wp transient delete --all
wp cache flush

Si vous utilisez Composer pour gérer WordPress ou des plugins premium, respectez le workflow du projet plutôt que de mélanger Composer, FTP et mises à jour dashboard. Un seul système de déploiement évite les états incohérents.

Étape 5 : tester l’éditeur, le front et les tâches cron

WordPress 7.0 touche surtout l’expérience d’administration et les fondations de l’éditeur. Testez donc les parcours réels : créer un article, modifier une page, insérer un bloc réutilisable, changer un template, enregistrer un menu, mettre à jour un produit, envoyer un formulaire et publier une modification.

# Voir les événements planifiés
wp cron event list --fields=hook,next_run_relative,recurrence

# Lancer un événement précis si nécessaire
wp cron event run wp_version_check

# Vérifier les erreurs PHP récentes côté serveur
# Exemple selon hébergeur : adapter le chemin
 tail -n 80 ~/logs/php-error.log

Côté front, contrôlez les pages qui rapportent du chiffre ou de la crédibilité : accueil, pages SEO principales, formulaires, tunnel d’achat, login, recherche, pages multilingues, sitemap et flux RSS. Mesurez aussi la performance avant/après, car un changement de plugin ou de thème peut déplacer le problème.

Étape 6 : préparer le rollback

Le rollback doit être écrit avant la mise en production. En cas d’erreur, personne ne doit improviser. Notez où se trouve le backup, quelle commande restaure la base, quels fichiers remplacer et qui valide la remise en ligne.

# Exemple de restauration SQL si rollback nécessaire
wp db reset --yes
wp db import ~/backups/wp-2026-06-09/database.sql
wp cache flush

# Vérification rapide
wp option get siteurl
wp core version
wp plugin list --status=active

Sur un e-commerce, attention : restaurer une base ancienne peut supprimer des commandes passées après le backup. Dans ce cas, mettez le site en maintenance pendant la fenêtre critique ou utilisez une stratégie spécifique pour préserver les nouvelles commandes.

Étape 7 : passer en production

Quand le staging est validé, reproduisez exactement la séquence en production. Activez une page de maintenance si nécessaire, désactivez temporairement les tâches externes sensibles, lancez les mises à jour, puis refaites les tests de surface. Gardez les logs ouverts pendant les premières heures.

wp maintenance-mode activate
wp plugin update --all
wp theme update --all
wp core update
wp core update-db
wp cache flush
wp maintenance-mode deactivate

Conclusion

Une migration WordPress 7.0 réussie n’est pas une question de chance. C’est une procédure. Sauvegarder, cloner, tester, mesurer, documenter, puis déployer. Cette discipline prend un peu plus de temps que le clic direct dans le dashboard, mais elle évite les vraies pertes : site cassé, commandes bloquées, formulaires muets, éditeur inutilisable ou rollback impossible.

Pour une agence ou un administrateur sérieux, cette checklist peut devenir un modèle réutilisable. Adaptez-la à votre hébergeur, à votre stack et au niveau de risque du site. Le coeur de la méthode reste le même : aucune mise à jour majeure sans staging, backup vérifié et plan de retour arrière.

Sources et références

WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.

Migrer vers WordPress 7.0 sans casse : checklist WP-CLI, staging et rollback