# WordPress 7.0 et vos outils de build : ce qu’il faut vérifier avant

> Passer en revue les changements de compatibilité PHP et JavaScript qui peuvent casser une chaîne de build existante avant la montée de version.

- Auteur : Clément Hadrot
- Publié le : 2026-04-07
- Mis à jour le : 2026-04-07
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/wordpress-7-0-outils-de-build-verifier/

## L’essentiel

- Le classement par impact évite de traiter tout au même niveau d'urgence
- Une chaîne de build figée depuis des années est la plus à risque
- Un environnement de test isolé permet de vérifier avant de généraliser

Chaque montée de version majeure de WordPress s'accompagne du même rituel côté agence : avant de laisser les mises à jour automatiques toucher le cœur applicatif sur le parc de sites gérés, une vérification systématique des chaînes de build de chaque projet s'impose. Ce texte se concentre exclusivement sur les outils de build, pas sur les changements visant les extensions elles-mêmes, un sujet traité séparément côté catégorie extensions.

La méthode retenue classe chaque changement potentiellement impactant par niveau d'impact réel observé sur les projets audités, plutôt que de traiter la liste complète des notes de version comme un bloc homogène à vérifier ligne par ligne.

## Impact élevé : les changements qui cassent un build silencieusement

La première catégorie regroupe les changements qui provoquent un échec net et immédiat lors du build, généralement détecté dès la première exécution du pipeline CI après la montée de version. Sur les projets audités, la principale source de rupture a concerné les scripts qui s'appuyaient sur une structure interne de `@wordpress/scripts` supposée stable, alors que le paquet a fait évoluer sa configuration Webpack sous-jacente au passage de version majeure.

```
# Erreur typique observée sur un build figé depuis 2022
Module not found: Error: Can't resolve '@wordpress/babel-preset-default'
in '/var/www/theme-client/node_modules/@wordpress/scripts/config'
```

La correction, dans la majorité des cas, se limite à mettre à jour `@wordpress/scripts` vers sa version courante avant même de toucher au cœur de WordPress lui-même, une dépendance qui avait souvent été négligée pendant plusieurs années sur les projets les plus anciens du parc.

## Impact élevé : la version PHP minimale requise

WordPress 7.0 relève sa version PHP minimale supportée, comme chaque montée majeure le fait progressivement depuis plusieurs années. Sur trois sites du parc, encore hébergés sur une version de PHP antérieure faute de montée de version côté serveur, ce changement bloque purement et simplement l'installation de la nouvelle version tant que le serveur lui-même n'a pas été mis à niveau, une opération qui dépasse le cadre du seul outillage de build.

> L'essentiel à retenir : Le classement par impact évite de traiter tout au même niveau d'urgence ; Une chaîne de build figée depuis des années est la plus à risque ; Un environnement de test isolé permet de vérifier avant de généraliser

## Impact moyen : les avertissements de dépréciation dans les scripts npm

Une deuxième catégorie de changements ne casse rien immédiatement, mais génère des avertissements de dépréciation dans les logs de build, annonçant une suppression future. Ces avertissements méritent d'être traités avant qu'ils ne deviennent des erreurs bloquantes lors d'une montée de version ultérieure, sans urgence immédiate pour la version 7.0 elle-même.

- Certaines API JavaScript internes exposées par `@wordpress/data` signalent leur remplacement futur sans encore être supprimées.
- Des options de configuration de `wp-scripts build` liées à d'anciens formats de sortie affichent un avertissement de compatibilité descendante temporaire.

## Impact faible : les changements cosmétiques sans effet sur le build

La majorité des notes de version qui mentionnent l'outillage de développement, une fois vérifiées, n'avaient en réalité aucun effet sur les chaînes de build des projets audités : ajustements internes de performance du compilateur de blocs, changements de messages de log sans changement de comportement, ou options avancées jamais utilisées par les projets du parc.

## La méthode de vérification retenue

Plutôt que d'appliquer la montée de version directement sur les sites en production, chaque projet a été testé dans un environnement isolé, une instance `wp-env` pointée vers une version de développement de WordPress 7.0, avant toute généralisation :

```
wp-env start --xdebug
wp-env run cli wp core update --version=7.0 --force
npm run build
```

Cette vérification, répétée sur les quarante sites du parc en amont de la publication officielle de la version stable, a permis d'identifier les trois sites bloqués par la version PHP minimale et les sept sites nécessitant une mise à jour de `@wordpress/scripts`, avant que ces problèmes ne se manifestent en production le jour de la mise à jour automatique.

### Tableau de synthèse de l'audit

| Impact | Nombre de sites concernés | Action requise |
| --- | --- | --- |
| Élevé (build cassé) | 7 | Mettre à jour @wordpress/scripts |
| Élevé (PHP obsolète) | 3 | Monter la version PHP serveur avant tout |
| Moyen (avertissements) | 12 | Planifier une correction, non urgente |
| Faible | 18 | Aucune action |

> Une montée de version majeure de WordPress ne surprend jamais celui qui a testé son build en amont dans un environnement jetable, elle surprend toujours celui qui a laissé la mise à jour automatique décider à sa place.

## Pour aller plus loin

Cette vérification concerne uniquement la compatibilité de l'outillage de build. Les changements touchant les API destinées aux extensions elles-mêmes, susceptibles d'affecter le comportement fonctionnel des sites plutôt que leur seule capacité à être construits, relèvent d'un audit distinct mené en parallèle par l'équipe en charge des extensions.

## Notre verdict

Sur ce parc de quarante sites, l'audit préalable a évité un incident de production pour trois sites qui auraient tout simplement refusé de fonctionner après la mise à jour automatique du cœur WordPress. Le coût de cette vérification systématique, réparti sur plusieurs jours en amont de la sortie officielle, reste dérisoire comparé au coût d'une panne découverte en production sur des sites de clients actifs.